https://bugzilla.mindrot.org/show_bug.cgi?id=2319
--- Comment #8 from Michael Stapelberg <michael+mind...@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. _______________________________________________ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
