On Thu, 2015-02-05 at 09:59 -0800, Kevin Cernekee wrote: > 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. That's true when using it for HOTP/TOTP too, isn't it? > 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). And *that* would be true if we wanted to support OATH with server challenges. > 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? -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20150205/5c3fa7a7/attachment.bin>
