u2f seed

[Jochen Bern]

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>