Automatic FIDO2 key negotiation (request for comments)

[Jordan J]

> Your worry is that webauthn isn't true two factor because it's only
> based on a thing you possess rather than both a thing you know and a
> thing you possess?  I agree, I've always thought the ability to steal
> someone's token was a big flaw in the scheme.  However, it is trivially
> fixable: if you encrypt the fido key handle with a passphrase before
> sending it to the remote then even if I steal your token, I still can't
> use it to access your account because when the remote presents the
> encrypted key handle I don't know the passphrase to decrypt it.
> This double encryption scheme should work for openssh public keys
> containing the key handle as well.  The only drawback is that to change
> the passphrase you now have to change every public key in every account
> you possess.

To add some more context about why I'm looking to implement this on
that note. Personally, I make it a second factor by setting
AuthenticationMethods=password,u2f in the original patches or
AuthenticationMethods=password,publickey in the current version. This
makes the encryption of the key_handle unnecessary as there's a
separate verification of 'something you know' and the keys only job is
to verify 'something you have'. The key_handle just isn't sensitive
information in this setup.

The rationale is that the AuthenticationMethods approach integrates
better in environments with centralised user/password management and
importantly allows the administrator to ensure that it is /actually/ a
two factor authentication. There's no such guarantee with the current
encryption approach as the user could just choose not to encrypt their
key handle. To put it another way, it lets the administrator ensure
that everyone uses two factor authentication compared to leaving it a
per-user choice.

My hope is to make SSH two factor auth in that environment/setup as
easy and simple as possible and not requiring the user to carry around
both the token and the key_handle unencrypted on a usb seems like easy
low-hanging fruit that I would hope isn't particularly contentious a
feature. Secondarily to that it opens up the elegant possibility of
AuthorizedKeysCommand pulling the users CTAP key details from a
centralised system. That lets other non-ssh services share the setup
and manage it centrally in which case ssh-keygen may not have been the
original CTAP key registrar and thus leaves the user without a private
key file to make use of - so the SSH server would need to send the
key_handle for the token to function.

On that basis encrypting or handling encryption of the key_handle is
out of scope for this as I see it. If you want to encrypt it just
continue using SSH as you do now. I'm aiming this at scenarios where
encrypting the key_handle doesn't really make sense or is just
unnecessary.