Re: Universal 2nd Factor (U2F) Authentication for Secure Shell?

[Simon Josefsson <[e-mail]>]

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 ([e-mail]):
> 
> > On Jan 3, 2017, at 4:16 AM, S.P.Zeidler <[e-mail]> 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