[Bug 2319] [PATCH REVIEW] U2F authentication

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

--- Comment #25 from jordandev678 at gmail.com ---
So in the interests of keeping this moving I've been chatting with some
of the guys above and I thought I’d pick this up and try to push it
forward a little. So here’s a recap of what immediate issues seemed
outstanding and some possible resolutions/thoughts.

1) It depends on a GPL library which is a licensing conflict we don't
want.

Libfido2 (https://github.com/Yubico/libfido2) is now BSD. I’ve got an
updated patch I’m working on with this library instead.
https://bitbucket.org/Jordandev678/ - I could use some testers if
anyone is interested.

Damien - does that sufficiently knock this concern on the head?


2) The spec is insufficient - we need more than "put this blob from the
library that's specified for Javascript on the wire".

The spec as it stands now (xml2rfc WIP version also in bitbucket above)
breaks it down a little more into the individual fields. That said the
fields are the CTAP CBOR format - there isn't really any getting away
from that. OpenSSH is always going to be mostly a relay in this process
between the client device and the libfido2 sever library. But this is a
'natural' breakdown of the U2F segments for SSH to work with I think.
N.B. U2F registration has been kicked out-of-spec (at least for now) so
that should simplify things too. One thing at a time!

Does that move some way towards making people more comfortable with
this?

3) The spec as it stands has some problems. As someone who knows
more than U2F than I said (privately):

> The draft, as I read it, does not do any validation of the
> username provided prior to sending a list of key handles for the
> user. This is somewhat of a security concern, since it reduces the
> "2F" in universal second factor to a single factor. Personally,
> I'm willing to overlook that one a little: if we believe attackers
> can easily get at your passwords, then this loss is a small one.

The draft does suggest not advertising the u2f method until another has
been successfully completed. The patch also won’t run U2F and send the
keys until you’ve made it that far in one of the allowed
AuthenticationMethod lists. So if you have the setup as “password,u2f”
it will never trigger unless you first get a valid username/password
combination. I tested attempting to have the client ‘jump-ahead’ and it
didn’t seem to work:
$ sudo sshd -d -o U2FAuthentication=yes -o
AuthenticationMethods=password,u2f
$ ssh -p 2222 -o PreferredAuthentications=u2f,password jordan at 127.0.0.1
true
>debug1: userauth-request for user jordan service ssh-connection method none [preauth]
>debug1: authentication methods list 0: password,u2f
>debug1: userauth-request for user jordan service ssh-connection method password [preauth]
>debug1: userauth-request for user jordan service ssh-connection method u2f [preauth]

Unless there's a different way to ‘skip ahead’ I don’t know about in
OpenSSH (happy to be corrected here) - then I believe this concern is
solved practically in the patch. From a specification perspective if
people want to make the spec a bit stronger (i.e. SHOULD to MUST) I
have no strong objections. Although perhaps there’s merit to catering
to people using just U2F keys if they manually configure it as valid
method on its own? It's better than keeping an unencrypted key on a USB
stick (hey, I’ve seen people do it!). At least with U2F the key can’t
be copied of and re-used without the users knowledge.

> The other concern I have with their approach is that it doesn't
> protect the user's privacy. The regular SSH protocol relies
> on a leap of faith, in that neither the client nor the server
> have any way to authenticate one another the first time they're
> introduced, so one must assume that there's no attacker present
> at that time. Still, it's customary for an SSH client to generate
> a new key pair for every server it's introduced to, in order for
> one server not to be able to correlate one user with another. One
> SSH server could reveal a user's public key to another, but that
> wouldn't compromise the user's privacy: the client would not use
> the key pair for server A with server B.
> In U2F, the assumption is that the U2F devices themselves
> may be storage-less. As a result, the server sends a "key
> handle" to remind the U2F device which key pair to use. The
> application parameter is a means by which the key pair is bound
> to a particular place. It's the web origin in the case of web
> authentication flows. The keys are cryptographically bound to the
> application parameter, such that no server that is associated with
> a different application parameter can exercise the key. (This
> protection relies on a trusted piece of software, i.e. the web
> browser in the case of the web, to tell the U2F device which
> server it is.) In this way, the key handles are safe: even if
> server A reveals the key handle for Alice to server B, server B
> can't learn that the key pair is in fact associated with an entity
> of interest to B, because B can't exercise Alice's key handle for
> server A.
>
> By using a static application parameter, their protocol leaves
> users exposed to a new attack.

That's technically correct - but SSH has no suitable replacement for
the 'relying party ID' (RPID) in U2F. I'm kicking around the idea of
using host keys as the RPID for but that has a few serious issues too.

I would point out though that the stated scenario only avoids this
issue by having the user manually select the key for each connection.
When an agent is involved standard SSH publickeys are just as
susceptible to this. The standard SSH agent doesn't lock keys to hosts
and just iterates though keys until one works. All we're doing here is
replacing the software SSH-agent with a more secure hardware agent. In
short - SSH already suffers from this, it's not just a U2F thing.

So with that in mind what I'd like to get nailed down though to guide
said development is if people (OpenSSH) would consider this type of
issue blocking for this considering the above and:
i) It requires B to get the list of keys for the user on A - which
requires B to have cracked the first factor (password) for the user on
A to get sent the list. Or both hosts are hostile to you and root on A
is sharing your keys behind the scenes with B.
ii) It requires the user to accept the host key of an actively hostile
host, if not two.
iii) The user has to expect to find U2F on the hostile host - if they
didn’t expect it then they wouldn’t touch the U2F key when prompted and
never confirm they hold it.


4) I'm not familiar enough with U2F to review it.

Perhaps if we can get one of the Yubico people or some other
appropriate entity to attest this is a reasonable implementation within
the constraints of SSH? If we could get this to a state where you guys
(OpenSSH) are happy with the status of what is here pending approval of
some appropriate entity of the U2F specifics that would probably be
easier to swing. Is that a reasonable approach from your perspective?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.