> 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