[PATCH] Early request for comments: U2F authentication

[Michael Stapelberg]

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