https://bugzilla.mindrot.org/show_bug.cgi?id=2319
--- Comment #21 from Damien Miller <d...@mindrot.org> --- A few people have asked (well, complained) why this hasn't been committed. The answer is basically that: 1) Tt depends on a GPL library which is a licensing conflict we don't want. 2) The spec is insufficient - we need more than "put this blob from the library that's specified for Javascript on the wire". 3) The spec as it stands has some problems. As someone who knows more than U2F that I said (privately): > The draft, as I read it, does not do any validation of the > username provided prior to sending a list of key handles for the > user. This is somewhat of a security concern, since it reduces the > "2F" in universal second factor to a single factor. Personally, > I'm willing to overlook that one a little: if we believe attackers > can easily get at your passwords, then this loss is a small one. > > The other concern I have with their approach is that it doesn't > protect the user's privacy. The regular SSH protocol relies > on a leap of faith, in that neither the client nor the server > have any way to authenticate one another the first time they're > introduced, so one must assume that there's no attacker present > at that time. Still, it's customary for an SSH client to generate > a new key pair for every server it's introduced to, in order for > one server not to be able to correlate one user with another. One > SSH server could reveal a user's public key to another, but that > wouldn't compromise the user's privacy: the client would not use > the key pair for server A with server B. > > In U2F, the assumption is that the U2F devices themselves > may be storage-less. As a result, the server sends a "key > handle" to remind the U2F device which key pair to use. The > application parameter is a means by which the key pair is bound > to a particular place. It's the web origin in the case of web > authentication flows. The keys are cryptographically bound to the > application parameter, such that no server that is associated with > a different application parameter can exercise the key. (This > protection relies on a trusted piece of software, i.e. the web > browser in the case of the web, to tell the U2F device which > server it is.) In this way, the key handles are safe: even if > server A reveals the key handle for Alice to server B, server B > can't learn that the key pair is in fact associated with an entity > of interest to B, because B can't exercise Alice's key handle for > server A. > > By using a static application parameter, their protocol leaves > users exposed to a new attack. (some of the details about how SSH works wrt user key exposure in the above are incorrect, but the broader point still stands.) ... which brings me to 4) I'm not familiar enough with U2F to review it. Without a proper specification that has been reviewed by people who are properly familiar with U2F and a way to remove the licensing conflict, please do not expect any progress here. -- 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
