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

["S.P.Zeidler" <spz%serpens.de@localhost>]

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
-- 
spz%serpens.de@localhost (S.P.Zeidler)