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

From: "S.P.Zeidler" <[email-masked]>
Date: Tue, 3 Jan 2017 13:16:49 +0100

Happy New Year,

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.

regards,
	spz
-- 
[email-masked] (S.P.Zeidler)

---

From: Ron Frederick <[email-masked]>
Date: Tue, 3 Jan 2017 20:46:15 -0800

> 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.

Was a prototype of this ever implemented?
-- 
Ron Frederick
[email-masked]

---

From: "S.P.Zeidler" <[email-masked]>
Date: Wed, 4 Jan 2017 14:26:31 +0100

Hi,

Cc'ing the proposers, so keeping the mail unweeded:

> 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 allowi…

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

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 5 Jan 2017 23:29:22 +0100

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

> > > and wondered if this august forum had an opinion both on making
> > > u2f available in SSH and the draft given.
> > 
> > 
> > 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.
>

---

From: Mouse <[email-masked]>
Date: Thu, 5 Jan 2017 08:52:41 -0500 (EST)

>> https://www.ietf.org/archive/id/draft-josefsson-secsh-u2f-00.txt

Assuming this has the same content as
http://www.ietf.org/archive/id/draft-josefsson-secsh-u2f-00.txt:

It is misnamed.  I see nothing "universal" about this. (Cf xkcd #927.)

I agree that registration does not belong here, any more than editing
authorized-keys or known-hosts records, or new key generation, belongs
in the base protocol.

The referenced fidoalliance document points to at least two references
which are 404 (at least for me; given the content of the 404 page, this
might be the usual nginx bogon, but the first document working suggests
not).  In any case, depending on external documents for
implementability strikes me as a good way to not get implemented.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B