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.
