On Thu, 2015-02-05 at 18:26 +0000, David Woodhouse 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. > That's true when using it for HOTP/TOTP too, isn't it? I guess so. The advantage however of U2F over HOTP/TOTP is that you don't need an additional shared secret with the server. The relation is pretty asymmetric as the server only needs to hold your public key similarly to ssh. > > 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. > Perhaps there is scope for driving some real standardisation there? Do you mean on the anyconnect protocol part, or the U2F part? My understanding from U2F is that apart from the javascript API there is nothing else planned. A standardization of the anyconnect protocol would have helped here as we could simply add this method. btw. I'm slowly documenting the existing protocol at https://github.com/openconnect/protocol regards, Nikos
