[PATCH] U2F support in OpenSSH

[Daniel Dent]

> On Feb 26, 2015, at 10:57 AM, Damien Miller <djm at mindrot.org> wrote:
> On Thu, 26 Feb 2015, Michael Stapelberg wrote:
>> 
>> Do you think, right now, based only on the information you have so
>> far, that you?ll eventually merge a patch adding U2F to OpenSSH? It?s
>> okay to reverse your decision later and I?m not taking this as a
>> promise, but what I do want to know is the upstream sentimen, i.e. if
>> you?re rather adverse to having U2F support in OpenSSH at all.
> 
> I'm not opposed to it, but U2F is pretty new and I'd probably like to
> see how it pans out for a bit first, both in terms of changes made to
> the upstream protocol and in how widely adopted it becomes.

Michael,

I've read through the draft and published versions of the U2F spec and I think there are lots of things to figure out.

The U2F standards really only describe integration with websites and mobile applications. I think the following mental mappings from the standard may be appropriate:

   * Relying Party: The OpenSSH Server
   * U2F Client: The OpenSSH Client
   * Origin: A specific SSH server
   * Registration step: Provides data similar in nature to the public portions of key files which are placed in authorized_keys files. To ease the creation of inexpensive authentication U2F devices, the relying party is responsible for storing this data and providing it during the authentication process.  This allows nearly stateless authentication dongles.
   * Authentication step: Provides evidence of possession of the same device which was used during the registration step.
   * Application ID: This is where things get messy. Applications can have multiple "facets". For example, paypal.com and the PayPal Android/iOS application can both share an application ID, allowing a single enrolment to be re-used for each of these facets of the application. In earlier drafts of the U2F, it was proposed that "paypal.com" and "ebay-payments.com" could choose to share an application ID. In the final draft, the rules around which websites sharing a single application ID appear to have been tightened.  I believe the intention is to improve user privacy (although I'm unclear why mobile applications get an exemption from these concerns).

Unlike Kerberos/GSS, U2F is designed so that one or more users can use the same device with multiple applications while having a distinct identity with each application. That promise relies on the U2F Client (the OpenSSH server) following certain constraints which protect the user.

Origins must only be allowed to request authentication for the application ID with which they are associated. One simple implementation would be to simply have an SSH configuration option specifying which application ID to use.

In the web implementation of U2F there is a list of acceptable facets for an application which is provided at a public HTTPS URL with restrictions designed to allow anonymous access of that URL (no per-user personalization of that URL is allowed). OpenSSH config options could specify how to retrieve the facet list from a file and/or URL (perhaps with a caching mechanism). Facets could be considered as server fingerprints, IP/Port pairs, etc.

U2F also has group device attestation certificates (the same public/private keypair is supposed to be used for an entire manufacturing run). The process for choosing which U2F device manufacturers have a design which adequately protects private keys is a concern which is currently left to implementers. In any event, there needs to be a way to specify which certificates are acceptable (or simply allow users to use any device).

I was not involved in the U2F standardization process so the above is just my personal interpretation of the documents that have been published.

I'm excited at the prospect of U2F authentication for SSH and would be happy to offer additional feedback if it would be helpful.

Regards,

Daniel

---
Daniel Dent
https://www.danieldent.com/
https://twitter.com/DanielDent
https://www.linkedin.com/in/danieldent