u2f seed

Fox, Kevin M Kevin.Fox at pnnl.gov
Sat Jan 4 03:40:36 AEDT 2020

Ohhh... sorry. Somehow I missed that. I understand now. Yeah. there is nothing we can do then.

Thanks for all the help.


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.


More information about the openssh-unix-dev mailing list