[PATCH] Early request for comments: U2F authentication

Michael Stapelberg
2014-11-11T14:30:24Z

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