https://bugzilla.mindrot.org/show_bug.cgi?id=2319
--- Comment #9 from Simon Josefsson <si...@josefsson.org> --- Btw, I've updated the draft a bit -- see earlier URL. > > 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. Sure -- and it enables the SSH server to perform various other checks on the U2F registration too, similar to how U2F is done on the web. I think I changed my mind on this, although I'm not yet certain I like how the user has to perform manual tasks after the registration step is completed. It feels that either U2F registration is completly out of scope, or it is completely in scope, so that the server makes sure that once U2F registration has succeeded, U2F authentication should work for that user. Maybe the server could put succeeded registrations into /etc/ssh/u2f/ instead of user's home directories? Just an idea. > 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). This brings up the question about appid/facetid. I don't like how ssh://localhost is used. Kerberos/GSSAPI has the same hostname comparison issue that you describe, FWIW, and I believe its security is better than no hostname comparison at all. > > 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. It is a bit better -- it is as safe as having an uncopyable unprotected SSH authentication key on a USB drive. The private key never leaves the device, and human interaction is required for every authentication operation. I don't care strongly about this -- just saying it may be possible if there is interest. /Simon -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. _______________________________________________ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
