u2f

[David Woodhouse]

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>