[Bug 2319] New: [PATCH REVIEW] U2F authentication

[bugzilla-daemon at mindrot.org]

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

            Bug ID: 2319
           Summary: [PATCH REVIEW] U2F authentication
           Product: Portable OpenSSH
           Version: 6.7p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Miscellaneous
          Assignee: unassigned-bugs at mindrot.org
          Reporter: michael+mindrot at stapelberg.de

Created attachment 2511
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2511&action=edit
patch 1/2

I’ve been told to file a ticket here in order to get a response to the
patch I posted to openssh-unix-dev. Here is what I originally wrote to
the list:

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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.