How does a u2f website then authenticate the same user, with the same keyfob, on a different machine? If that actually works, then we should be able to use the same mechanism. Maybe it doesn't, and some people are going to be locked out of their account when their machine fails and they have to go to another one. portability was one of the selling points of u2f though I thought. Maybe I'll try and dig up the u2f spec and see if there is any detail in it. Thanks, Kevin ________________________________________ From: openssh-unix-dev <openssh-unix-dev-bounces+kevin.fox=pnnl.gov at mindrot.org> on behalf of Christian Weisgerber <naddy at mips.inka.de> Sent: Friday, January 3, 2020 5:01 AM To: openssh-unix-dev at mindrot.org Subject: Re: u2f seed On 2020-01-02, "Fox, Kevin M" <Kevin.Fox at pnnl.gov> wrote:> That sounds like the application param is still used as part of the process though? Would allowing the user to specify the application work in the Solokey case?Let's cut this short without losing ourselves in details: Even if you resend exactly the same U2F registration message, the token may still create a different key pair. Only a very minimal U2F token without an on-board RNG might derive the key pair purely from the parameters in the registration message; I don't know if any such devices exist. This actually made me curious and I checked the simple FIDO1 U2F token I have here (HyperFIDO Titanium): It issues a different key pair each time, even if the registration message is exactly the same. As would the Solokey. Every time you run "ssh-keygen -t ecdsa-sk", the token will give you a different key pair, and this is enforced by the token itself.> What is stored in the private keyfile? The documentation says no private key is stored there. So is it just information used to reseed the public/private key?The OpenSSH private key file stores the U2F key handle. The key handle is an opaque blob which you need to pass back to the token so it can find the private key. -- Christian "naddy" Weisgerber naddy at mips.inka.de _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://protect2.fireeye.com/v1/url?k=102d876a-4c98b8d3-102dad7f-0cc47adc5fce-f963eec20cc653fd&q=1&e=445ca71b-c946-44b4-a663-d2d3fc1f288f&u=https%3A%2F%2Flists.mindrot.org%2Fmailman%2Flistinfo%2Fopenssh-unix-dev
On Fri, 2020-01-03 at 16:15 +0000, Fox, Kevin M wrote:> How does a u2f website then authenticate the same user, with the same > keyfob, on a different machine?I thought I was clear the last time: The remote website account creation process stores a u2f key handle in the remote website as part of the user registration information (the token generates a new key for *every* registration meaning every remote website has a different authentication key). This key handle is usually implemented as the wrapped key for the specific website, so every time you access that website account from whatever client system, the server presents the client with the stored key handle, which the client passes on to the token, so you get the same key back because the token unwraps the key handle from the server to use as the authentication key.> If that actually works, then we should be able to use the same > mechanism. Maybe it doesn't, and some people are going to be locked > out of their account when their machine fails and they have to go to > another one. portability was one of the selling points of u2f though > I thought. Maybe I'll try and dig up the u2f spec and see if there is > any detail in it.There's nothing in the current ssh public key based process that can present remote information to the local client. Without that, you have to get the token's key handle locally which means if you take the token to a different local client, you also need to bring the key handle as well because the remote won't provide it. James
On 2020/01/03 16:15, Fox, Kevin M wrote:> How does a u2f website then authenticate the same user, with the same > keyfob, on a different machine? If that actually works, then we should > be able to use the same mechanism. Maybe it doesn't, and some people > are going to be locked out of their account when their machine fails > and they have to go to another one. portability was one of the selling > points of u2f though I thought. Maybe I'll try and dig up the u2f spec > and see if there is any detail in it.With a website, the site can store information that is passed back via the client's browser to use as a key handle. As said in James Bottomley's message and djm's reply, doing similar in ssh is not possible without significantly changing the protocol: https://lists.mindrot.org/pipermail/openssh-unix-dev/2020-January/038092.html
Ohhh... sorry. Somehow I missed that. I understand now. Yeah. there is nothing we can do then. Thanks for all the help. Kevin ________________________________________ From: James Bottomley <James.Bottomley at HansenPartnership.com> Sent: Friday, January 3, 2020 8:34 AM To: Fox, Kevin M; Christian Weisgerber; openssh-unix-dev at mindrot.org Subject: Re: u2f seed On Fri, 2020-01-03 at 16:15 +0000, Fox, Kevin M wrote:> How does a u2f website then authenticate the same user, with the same > keyfob, on a different machine?I thought I was clear the last time: The remote website account creation process stores a u2f key handle in the remote website as part of the user registration information (the token generates a new key for *every* registration meaning every remote website has a different authentication key). This key handle is usually implemented as the wrapped key for the specific website, so every time you access that website account from whatever client system, the server presents the client with the stored key handle, which the client passes on to the token, so you get the same key back because the token unwraps the key handle from the server to use as the authentication key.> If that actually works, then we should be able to use the same > mechanism. Maybe it doesn't, and some people are going to be locked > out of their account when their machine fails and they have to go to > another one. portability was one of the selling points of u2f though > I thought. Maybe I'll try and dig up the u2f spec and see if there is > any detail in it.There's nothing in the current ssh public key based process that can present remote information to the local client. Without that, you have to get the token's key handle locally which means if you take the token to a different local client, you also need to bring the key handle as well because the remote won't provide it. James
On Fri, 3 Jan 2020, Stuart Henderson wrote:> As said in James Bottomley's message and djm's reply, doing similar in > ssh is not possible without significantly changing the protocol: > > https://lists.mindrot.org/pipermail/openssh-unix-dev/2020-January/038092.htmlso how does Google change the protocol to support u2f? not supporting authentication from multiple machines seems to defeat the purpose of adding u2f support. David Lang
On 01/03/2020 05:34 PM, James Bottomley wrote:> There's nothing in the current ssh public key based process that can > present remote information to the local client.Remote information *external to the SSH authentication procedure itself*. IIUC, at the point where the client starts to authenticate, both sides are already in agreement what the server's (hopefully unique) pubkey is, that the server has demonstrated possession of the matching private key, and which server-side account the client asks to access. In other words, we may not be able to come up with a wrapped key that is unique to the combo of target account and token and kept secret from everyone else, but we can hash us a long-lived ID for the target account alone that at least promises to have some good randomness, if poor secrecy. Would that, compared to doing the token auth essentially memoryless/"first time ever" every time, buy us some worthwhile top-level properties? *Beyond* the "hold, that's a *different* pubkey the server has now!" check that the known_host cacheing already allows *sans* the U2F part? Regards, -- Jochen Bern Systemingenieur Binect GmbH Robert-Koch-Stra?e 9 64331 Weiterstadt -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4278 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20200103/1b90d970/attachment-0001.p7s>