u2f

[Kevin Cernekee]

On Thu, Feb 5, 2015 at 8:45 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> Hi,
>  One of the presentations in fosdem's security devroom was about U2F. As
> far as I understood U2F is smart card which provides unique per server
> ECDSA256 keys. Those could be stored in the card or in the PC similarly
> to TPM (i.e., encrypted using a key that depends on the card and the
> site). The protocol includes registration, and is a simple
> challenge-response process. The differences between a PKCS #11 smart
> card and that one, is the specified registration protocol as well as its
> driverless nature. The U2F protocol is however limited to secp256r1 curve
> and cannot be extended beyond it. What do you think of that? Would it make
> sense to support it in openconnect?

>From an ease-of-use standpoint, U2F is much nicer than typing OTPs.
The Yubico NEO-N can be left in your USB slot indefinitely, and used
on demand.

On the client side we'd need to invent a new way of adding the U2F
challenge to the auth flow.  Possibly adding a tag similar to
<client-cert-request> to the XML sequence (XML POST only).  Should
openconnect clients indicate in the headers that they can handle
non-Cisco authentication methods?  An AnyConnect client would get very
confused by seeing an undefined tag, and wouldn't be able to complete
the handshake, at any rate.

In the U2F setup that I use, the web site presents a challenge and
asks the user to touch the security key.  But it also provides a
clickable link for "use OTP instead."  Multiple OTP/U2F dongles can be
registered on one account.  If we wanted to support this, the various
options would need to be represented in the XML and in the UI.

Also, on non-U2F-capable browsers, websites automatically downgrade to
OTP mode.  This is one option for supporting AnyConnect clients.

One thing I noticed reading through the various U2F presentations is
that the API is in JavaScript.  i.e. there aren't standard HTTP
headers or TLS messages that initiate the challenge/response.  So
we'll have to invent our own, and if Cisco or Juniper implement it
later, they'll probably do it differently.

On the ocserv side you'll also need to figure out what registration
looks like (is this as simple as "auto-register on first logon,"
something involving one-time registration codes, or something else?),
and also maintain a database of registered tokens.  Along with the
usual questions of adding/revoking/identifying the different tokens.