In the u2f protocol, my understanding is in the normal case, the web browser seeds the keypair process with the hostname of the remote server. In the case of ssh, the hostname is probably not what I would want to do. But the u2f protocol seems to have a way to handle this. It just needs to be exposed to the user. The content of the private keyfile in ssh is generated somehow. Where is that done? Thanks, Kevin ________________________________________ From: Damien Miller <djm at mindrot.org> Sent: Wednesday, January 1, 2020 9:36 PM To: Fox, Kevin M Cc: openssh-unix-dev at mindrot.org Subject: Re: u2f seed On Tue, 31 Dec 2019, Fox, Kevin M wrote:> When using openssh with a u2f key, you generate a key via: > ssh-keygen -t ecdsa-sk > > Each time you run it, it gives a different key pair. (Randomly seeming). > > A differently generated key pair is not valid with the first's public key. > > All good so far, but you run into a problem if: > > You generate a keypair (A). > You register your public key for (A) on a bunch of ssh servers. > You take your fido2 key to a second client machine and try and login to your servers. > > It kind of defeats the purpose of being able to have a portable > keyfob.It's possible to use the key on another machine if copy the private key you generated on the original machine over. U2F is almost completely stateless, so there's no way of storing the key on the token itself (for U2F-only tokens anyway)> If there was a way to seed the generation phase manually, then > the same seed can be used on each client machine so that the ssh > pub/private key doesn't have to be transferred along with the u2f > keyfob?That's not possible unfortunately, the U2F protocol doesn't offer any way to set the seed and AFAIK doesn't specify how the tokens generate the keys. There is some good news though, the FIDO2 protocol does support "resident keys" - i.e. keys that can be stored on, and retrieved from a token. I've just started landing support for these in OpenSSH last week. To use them, you'll need a FIDO2 token that support resident keys. You'll also need to set a PIN on the token, as retrieving the keys requires authentication. Once you've done this, you can generate a resident key by running "ssh-keygen -Oresident -t ecdsa-sk" (along with any other usual options). You'll get back a keypair that you can use exactly like any other, but you'll also be able to download it again from the token if you move it to another host. At present the only way I've implemented so far is via "ssh-add -O", which will download all resident keys and add them to a ssh-agent, but I'll add an option to ssh-keygen to explicitly download them to public/private key files shortly. -d
On Thu, 2 Jan 2020, Fox, Kevin M wrote:> In the u2f protocol, my understanding is in the normal case, the web > browser seeds the keypair process with the hostname of the remote > server. In the case of ssh, the hostname is probably not what I would > want to do. But the u2f protocol seems to have a way to handle this. > It just needs to be exposed to the user. The content of the private > keyfile in ssh is generated somehow. Where is that done?The key generation is done solely by the token. There are several strings (challenge, application) that OpenSSH sends to the token that are inputs the the process, but I'd expect most tokens would have onboard CSPRNGs that they use the actually generate the keys. -d
>From my understanding, somehow a website talking through the web browser is able to get the same keypair used no matter which computer the keyfob is plugged into. I'm wondering if we can use the same mechanism there. If application is part of the process, maybe allowing the application to be specified by the user rather then being randomly generated by openssh would be enough?Thanks, Kevin ________________________________________ From: Damien Miller <djm at mindrot.org> Sent: Thursday, January 2, 2020 2:36 PM To: Fox, Kevin M Cc: openssh-unix-dev at mindrot.org Subject: Re: u2f seed On Thu, 2 Jan 2020, Fox, Kevin M wrote:> In the u2f protocol, my understanding is in the normal case, the web > browser seeds the keypair process with the hostname of the remote > server. In the case of ssh, the hostname is probably not what I would > want to do. But the u2f protocol seems to have a way to handle this. > It just needs to be exposed to the user. The content of the private > keyfile in ssh is generated somehow. Where is that done?The key generation is done solely by the token. There are several strings (challenge, application) that OpenSSH sends to the token that are inputs the the process, but I'd expect most tokens would have onboard CSPRNGs that they use the actually generate the keys. -d
On 2020-01-02, "Fox, Kevin M" <Kevin.Fox at pnnl.gov> wrote:> In the u2f protocol, my understanding is in the normal case, the web browser seeds the keypair process with the hostname of the remote server. In the case of ssh, the hostname is probably not what I would want to do. But the u2f protocol seems to have a way to handle this.There is no guarantee that the U2F token derives the key pair in a deterministic fashion from the challenge/application parameters passed during registration. For instance, if I read the firmware code correctly, the Solokey creates the key material using its built-in random number generator and only uses its master secret and the application parameter to wrap the key for the key handle. -- Christian "naddy" Weisgerber naddy at mips.inka.de
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? 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? 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: Thursday, January 2, 2020 3:42 PM To: openssh-unix-dev at mindrot.org Subject: Re: u2f seed On 2020-01-02, "Fox, Kevin M" <Kevin.Fox at pnnl.gov> wrote:> In the u2f protocol, my understanding is in the normal case, the web browser seeds the keypair process with the hostname of the remote server. In the case of ssh, the hostname is probably not what I would want to do. But the u2f protocol seems to have a way to handle this.There is no guarantee that the U2F token derives the key pair in a deterministic fashion from the challenge/application parameters passed during registration. For instance, if I read the firmware code correctly, the Solokey creates the key material using its built-in random number generator and only uses its master secret and the application parameter to wrap the key for the key handle. -- 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=c4371812-988227ab-c4373207-0cc47adc5fce-56c2948a65834232&q=1&e=0f45e6c0-4544-44ae-af8d-3d64af881ea7&u=https%3A%2F%2Flists.mindrot.org%2Fmailman%2Flistinfo%2Fopenssh-unix-dev