openssh unix dev - Jul 2020 - Automatic FIDO2 key negotiation (request for comments)

On Tue, 2020-07-21 at 14:47 +1000, Damien Miller wrote:
> On Mon, 20 Jul 2020, Jordan J wrote:
[...]
> > Firstly, would the following or some combination thereof be
> > possible or is there an obvious impediment. Secondly, if it proved
> > possible are the maintainers open to a patch providing it?
> > 
> > 1. Update the SSH ecdsa-sk public key type to contain the
> > key_handle and other relevant details (it doesn't contain
sensitive
> > information or accessible key material so this is safe to do)
> > 2. Add a method to send a list of understood *-sk" publickeys
from
> > authorized_keys to the client
> 
> I'm not keen on making the public keys contain the key handle. IMO
> being able to offer some protection of the key handle on disk by
> setting a password on the key is valuable and we'd lose that if
> everything were public by default.
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.

James

> 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.

On Sun, 2020-07-26 at 18:50 +0100, Jordan J wrote:
> > 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.
But that's a server side option.  It works if you control the server,
but not if you're using an external one (think github ssh key).  That's
why I like my second factor on the user side.
> 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.
Heh, well, I've been using TPM based two factor authentication in ssh
for years (I actually use it for all my secure keys): it's nice and
seamless and entirely controlled on the user side, but really hard to
get the engine patch it requires upstream.
>  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.
Absolutely provisioning machines in a data centre is a royal pain when
you have to get everyones ssh keys on to the new system correctly ...
having an LDAP database simply do it is very convenient.  It's just not
the only use case.
> 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.
Well, the key handle is already a fully opaque data blob.  Encrypting
it only makes sense to add an extra authentication factor on the user
side.

James