Hello, The draft is indeed an unfinished work, and the issues you bring up are relevant. I don't have cycles to drive this draft right now, but I'm happy to merge patches and publish new versions if someone wants to step up and become co-author. I'm happy to hand over control too. The draft is on gitlab: https://gitlab.com/jas/ietf-secsh-u2f /Simon > Hi, > > Cc'ing the proposers, so keeping the mail unweeded: > > Thus wrote Ron Frederick (ronf%timeheart.net@localhost): > > > On Jan 3, 2017, at 4:16 AM, S.P.Zeidler <spz%serpens.de@localhost> wrote: > > > I've encountered > > > https://www.ietf.org/archive/id/draft-josefsson-secsh-u2f-00.txt > > > and wondered if this august forum had an opinion both on making > > > u2f available in SSH and the draft given. > > > > > > There are multiple things that don’t make sense to me or that I’d > > want to change in this draft. > > > > First and foremost, I don’t think it makes sense for the > > RegisterRequest to be done inside an SSH_MSG_USERAUTH_REQUEST. This > > is not part of authenticating a client. It’s a step which would > > have to be done on the server machine by the owner of the account > > which is being logged into where they decide what U2F tokens they > > want to accept and they create appropriate entries in > > authorized_keys. I could imagine a took like ssh-keygen being > > augmented to speak the necessary protocol to generate the U2F > > registration request and retrieve the response and convert it into > > an appropriate form for insertion into authorized_keys, but I don’t > > see it as making sense during SSH client authentication. That step > > should only need to do the SignRequest/SignResponse handshake, > > assuming there was an appropriate U2F key entry which was trusted. > > > > That leads to the next issue, which is that there’s no description > > of what this authorized_key entry should look like. Also, since the > > authorized_key file is used today for public keys and certificates, > > is this really the right file? Perhaps registered U2F keys should > > be kept in a separate file designed specifically for this purpose. > > I don’t really see the advanced in combining the two, unless there > > is an intention of wanting to take advantage of the options > > available in authorized_keys. Some of those (like cert-authority > > and principals) don’t really make sense, though, and since U2F is > > designed to be used as a secondary authentication to strengthen > > other auth mechanisms, it’s not clear it makes sense for these keys > > to end up deciding things like what SSH features should be allowed > > to be used. If a combination of public key and U2F authentication > > is used, which set of options should apply to the resulting > > connection? > > > > In terms of the specifics of the proposed messages, it appears that > > the values SSH2_MSG_USERAUTH_INFO_REQUEST and > > SSH2_MSG_USERAUTH_INFO_RESPONSE defined for use in > > keyboard-interactive authentication are being repurposed here. I > > think it would be better to define new SSH2_MSG_USERAUTH values > > specific to U2F here, even if the assigned numbers are reused. For > > instance, the message names could be SSH2_MSG_USERAUTH_SIGN_REQUEST > > and SSH2_MSG_USERAUTH_SIGN_RESPONSE. If the registration is done > > out of band, there’s also no need for the “U2F mode” integer in the > > original USERAUTH request. > > > > Finally, setting both “origin” and “appId” to “ssh://localhost > > <ssh://localhost>” when creating the U2F tokens also doesn’t seem > > quite right. It seems to me like there might be some value in > > allowing tokens associated with specific user or host principals, > > similar to what is done for SSH certificates. However, I’m not all > > that familiar with U2F, so I don’t know how those fields are > > typically used. > > I would like to be able to discern targets for U2F too, i.e. > list both the token logging in, and the user@host being logged in to, > in their appropriate fields. > > > Was a prototype of this ever implemented? > > As patches against OpenSSH, with some discussion too: > https://bugzilla.mindrot.org/show_bug.cgi?id=2319 > > regards, > spz
Attachment:
pgpPT3MOR0PdH.pgp
Description: OpenPGP digital signatur