[Bug 2319] [PATCH REVIEW] U2F authentication

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

--- Comment #8 from Michael Stapelberg <michael+mindrot at stapelberg.de> ---
(In reply to Simon Josefsson from comment #7)
> Hi everyone.
> 
> I agree that it would be nice to write up the protocol spec in IETF
> form -- talking to Michael, he would be positive to this so I
> started that effort.  See:
> 
> https://gitorious.org/ietf-simon/u2f-secsh/source/
> 
> In particular:
> 
> https://gitorious.org/ietf-simon/u2f-secsh/raw/draft-josefsson-secsh-
> u2f.txt

Thanks for getting this started!

> I'm not sure if this bug report is the best place for design
> discussions, but I believe one aspect of Michael's protocol should
> be discussed further.  Maybe this protocol shouldn't do U2F
> registration.  The U2F Registration can happen out-of-band using
> some command line tools (see our u2f-host and u2f-server projects). 

The reason why I decided to put registration into the protocol is that
it makes the entire process of starting to use U2F _much_ simpler and
more robust against human mistakes. If we provide U2F, but it’s hard to
use, nobody will use it.

When having the registration in a separate tool, the user needs to make
sure that the appid and origin are specified in the same way as OpenSSH
uses them. By keeping registration and authentication closely together,
there cannot be a mismatch here, and if we ever need to change the
appid/origin, they can never drift apart (think a user has one version
of the registration utility but uses a different OpenSSH version,
likely without knowing).

> Then you could use U2F as a single-factor protocol too.  I find that
> the server admin part of handling registration is a bit strange.  It
> may be that I'm not just getting what is achieved here.

I don’t think U2F should be used as a single-factor protocol in OpenSSH
(or the web). That’s essentially as safe as having an unprotected SSH
authentication key on a USB drive. I’m worried that people might think
it’s more than that and get a false sense of security.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.