openssh unix dev - Nov 2014 - [PATCH] Early request for comments: U2F authentication

Hey,

Recently, the FIDO alliance announced U2F [1], and Google announced
that it supports U2F tokens (?security keys?) for Google accounts [2].
As the spec is not a very short read, I gave a presentation last week
about U2F which may be a good quick introduction to the details [3].
For the rest of this mail, I?ll assume that you read either my
presentation or the spec, but feel free to post any questions about
U2F and I?ll try to answer them. (side note: I?m not working on U2F,
playing around with it and implementing it in OpenSSH is my private
fun project :))

I?ve spent some time (together with Christian and Thomas) hacking on
U2F support in OpenSSH, and I?m happy to provide a first patch ? it?s
not complete, but it should be good enough to get the discussion going
:). Please see the two attached files for the patch. Due to their
size, I?ve not posted them in-line.

The way it currently (!) works:

1) Use ?AuthenticationMethods publickey,u2f? in sshd_config (or
<whatever>,u2f)
2) Recompile SSH with the patch and change userauth_u2f() to use
packet_put_int(0) (== registration) instead of packet_put_int(1)
(=authentication). Sorry about that. See my question below.
3) You need to do this step only once: ssh into your server, touch
your security key when prompted, and you?ll see a ssh-u2f key line,
which you should copy&paste into the server?s ~/.ssh/authorized_keys
for the corresponding user.
4) Recompile with packet_put_int(1).
5) ssh into your server, touch your security key when prompted, enjoy
the additional security :).

There are a couple of open questions:

1) Will you accept this patch (let?s ignore details for now) at all?
Everyone I?ve talked to in the last couple of days was pretty excited
about having U2F support in OpenSSH, so I think it?d be a great
feature.

(the rest are detail questions about the implementation)

2) Could we make the server write to authorized_keys to avoid the
copy&paste step? Probably not a good idea, but I figured I?d ask
anyway.

3) What would be a good way to trigger the different U2F modes on the
client? Should we add a new flag to ssh(1)? Registration is very
rarely triggered, authentication should be the default.

4) What should we use as U2F appid? Currently I just set
?ssh://localhost? (it must be a URL), and we could use
?ssh://<hostname>?. Christian suggested using the host key
fingerprint, which would decouple the appid from the hostname (which
may be good if the hostname frequently changes, because U2F security
keys are registered for a specific appid).

5) What should we use as the origin (in the ssh client)? In the case
where U2F is used by a web browser, this is set to the canonical
representation of the domain (i.e. lowercased, after idn etc.). At the
moment, I?m using either the host alias or the hostname. Is that
acceptable or is there a better method?

6) Not a question, but a note: the patch does not yet handle multiple
registered U2F security keys.

7) I?d like to use SSL_load_error_strings() so that the human-readable
error messages actually contain some content and are not just NULL :).
It?ll require linking with -lssl. Is that okay or is there a reason
why we don?t do it so far?

Thank you very much for any replies :).

[1] https://fidoalliance.org/
[2]
http://googleonlinesecurity.blogspot.ch/2014/10/strengthening-2-step-verification-with.html
[3] https://www.noname-ev.de/w/File:C14h-u2f-how-security-keys-work.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-add-u2f-to-automake.patch
Type: text/x-patch
Size: 3002 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20141105/1893b630/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-add-u2f-auth-module-not-done-yet.patch
Type: text/x-patch
Size: 42448 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20141105/1893b630/attachment-0003.bin>

On Wed, Nov 5, 2014 at 7:21 AM, Michael Stapelberg
<stapelberg+openssh at google.com> wrote:
> Hey,
>
> Recently, the FIDO alliance announced U2F [1], and Google announced
> that it supports U2F tokens (?security keys?) for Google accounts [2].
> As the spec is not a very short read, I gave a presentation last week
> about U2F which may be a good quick introduction to the details [3].
> For the rest of this mail, I?ll assume that you read either my
> presentation or the spec, but feel free to post any questions about
> U2F and I?ll try to answer them. (side note: I?m not working on U2F,
> playing around with it and implementing it in OpenSSH is my private
> fun project :))
>
> I?ve spent some time (together with Christian and Thomas) hacking on
> U2F support in OpenSSH, and I?m happy to provide a first patch ? it?s
> not complete, but it should be good enough to get the discussion going
> :). Please see the two attached files for the patch. Due to their
> size, I?ve not posted them in-line.
>
> The way it currently (!) works:
>
> 1) Use ?AuthenticationMethods publickey,u2f? in sshd_config (or
<whatever>,u2f)
> 2) Recompile SSH with the patch and change userauth_u2f() to use
> packet_put_int(0) (== registration) instead of packet_put_int(1) (=>
authentication). Sorry about that. See my question below.
> 3) You need to do this step only once: ssh into your server, touch
> your security key when prompted, and you?ll see a ssh-u2f key line,
> which you should copy&paste into the server?s ~/.ssh/authorized_keys
> for the corresponding user.
> 4) Recompile with packet_put_int(1).
> 5) ssh into your server, touch your security key when prompted, enjoy
> the additional security :).
>
> There are a couple of open questions:
>
> 1) Will you accept this patch (let?s ignore details for now) at all?
> Everyone I?ve talked to in the last couple of days was pretty excited
> about having U2F support in OpenSSH, so I think it?d be a great
> feature.
>
> (the rest are detail questions about the implementation)
>
> 2) Could we make the server write to authorized_keys to avoid the
> copy&paste step? Probably not a good idea, but I figured I?d ask
> anyway.
>
> 3) What would be a good way to trigger the different U2F modes on the
> client? Should we add a new flag to ssh(1)? Registration is very
> rarely triggered, authentication should be the default.
>
> 4) What should we use as U2F appid? Currently I just set
> ?ssh://localhost? (it must be a URL), and we could use
> ?ssh://<hostname>?. Christian suggested using the host key
> fingerprint, which would decouple the appid from the hostname (which
> may be good if the hostname frequently changes, because U2F security
> keys are registered for a specific appid).
>
> 5) What should we use as the origin (in the ssh client)? In the case
> where U2F is used by a web browser, this is set to the canonical
> representation of the domain (i.e. lowercased, after idn etc.). At the
> moment, I?m using either the host alias or the hostname. Is that
> acceptable or is there a better method?
>
> 6) Not a question, but a note: the patch does not yet handle multiple
> registered U2F security keys.
>
> 7) I?d like to use SSL_load_error_strings() so that the human-readable
> error messages actually contain some content and are not just NULL :).
> It?ll require linking with -lssl. Is that okay or is there a reason
> why we don?t do it so far?
>
> Thank you very much for any replies :).
I haven?t seen any replies yet, and it?s been almost a week. It could
just be that none of you care, or all who care are incredibly busy.
Still, I?d appreciate a ?don?t know about the details, but we?ll most
likely merge your patch? so that I know any further work on this is
not in vain :).

Thank you!
>
> [1] https://fidoalliance.org/
> [2]
http://googleonlinesecurity.blogspot.ch/2014/10/strengthening-2-step-verification-with.html
> [3] https://www.noname-ev.de/w/File:C14h-u2f-how-security-keys-work.pdf

Michael Stapelberg wrote:
> Thank you very much for any replies :).
> I haven?t seen any replies yet, and it?s been almost a week. It could
> just be that none of you care, or all who care are incredibly busy.
> Still, I?d appreciate a ?don?t know about the details, but we?ll most
> likely merge your patch? so that I know any further work on this is
> not in vain :).
>
> Thank you!
Now it has been almost a month. :)

In case it is helpful, here are my 2 cents:
1) It looks cool to support U2F in openssh.
2-3) No, sshd writing the users authorized_keys file doesn't seem a good 
idea :)
I would put the client registration process in ssh-copy-id

4) For the server to identify itself, the only think it knows about its 
identity is its own [set of] host key. The hostname or gethostid(2) can 
be quite useless. Perhaps a sshd_config param? :/

5) Looks good. From the client point of view, I would use 
hostname[:port], as currently checked by ssh in known_hosts. That seems 
more consistent with ssh way. I also suspect that using the server 
fingerprint would allow some attacks, in addition of avoiding possible 
issues with multiple hosts with the same key (shared fs, cloned 
machines?).  Note that if the server is exposed to the origin value, it 
may deserve to be hidden (hashed?) first  (I understand the server shall 
treat the origin as an opaque value)

7) Wouldn't ERR_load_crypto_strings() be enough?
> +// TODO: use auth_info() so that in log messages about accepted auths we
will see a message that identifies the key. perhaps we can just use the human
readable suffix that you can specify in the authorized_keys file(s)?
Just that suffix won't help root to figure things out. A fingerprint 
-like it's now provided for public keys- could help here.


And a few u2f questions: What is the purpose of the challenge provided 
by the server on registration? What is a u2f key expected to do if asked 
to register an system it already has already registered? Should it be 
appended or replaced?

Regards