>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 Thu, 2020-01-02 at 23:35 +0000, Fox, Kevin M wrote:> 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.That's right ... there wouldn't be much use to the token otherwise.> 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?To operate like a website, you need the two stage registration then login/authentication process. When you register with a U2F CTAP token, the registration info that must be stored by the remote website includes a 'key handle'. In most of the implementations, the key handle is, in fact, a wrapped key which can be unwrapped by the token. So on Login (or Authentication in the FIDO speak), the website presents they key handle and some parameters (including origin information) which are validated and if the validation passes, the token unwraps the key handle to get the website unique key and signs the challenge combined with a key or token unique counter and returns the signature and the counter value, which is used by the remote site to verify the login. To get this to work with ssh, you need something that corresponds to the data that is stored on registration. My understanding of the way ssh works is that we don't really have that ... the server expects you to sign a challenge which it then compares with your remote public key. There's nothing the remote server initially passes back to the local that would allow the U2F token to use as a key handle ... at least not without significantly altering the current protocol. James
On Thu, 2 Jan 2020, James Bottomley wrote:> To get this to work with ssh, you need something that corresponds to > the data that is stored on registration. My understanding of the way > ssh works is that we don't really have that ... the server expects you > to sign a challenge which it then compares with your remote public > key. There's nothing the remote server initially passes back to the > local that would allow the U2F token to use as a key handle ... at > least not without significantly altering the current protocol.Right - you wouldn't be doing pubkey authentication any more, you'd be doing some new authentication method. I chose not to go this way when implementing FIDO support in OpenSSH because SSH users are familiar with public key authentication and there is a large amount of infrastructure that already uses them. -d