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

At present whenever non-resident keys are used the key_handle required
to use the token must be given by selecting the ssh 'private key' file
generated by ssh-keygen during negotiation.

In the more common webauthn context this key_handle would be stored on
the server and then transmitted to the client during authentication.
The client then checks connected tokens for one that reports it
understands that key_handle and can sign on its behalf. Compared to
SSH this approach means there are no external files required to use
the hardware key (use is just plug and play).

The initial patches for U2F added it as a new authentication method
and were dropped in favour of the current implementation where it is
mostly just another key type with an external signature provider. This
is a less invasive change but means that the information required to
do a more 'typical' negotiation supporting this plug-and-play use
isn't available.

However that degree of plug-and-play is desirable in some
circumstances. Particularly those where the user may be logging in
from different transient machines. The current method requires the
user to carry around the security key as well as the 'private key' on
a USB stick so that both can be accessed. Not fatal by any means, but
not ideal compared to a more typical webauthn flow.

(onto the questions)

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

An appropriate method to implement #2 without reverting to the more
invasive alternate-auth-method would seem to be via SSH extensions
(RFC8308). If both the client and the server signal their support for
the extension a list of known *-sk keys could be sent after a user is
selected. This would then let the client select a key without needing
the private key file. This should also prevent any incompatibilities
between clients with and without support. They can use the external
file the same as they do now.

Comments?

On Mon, 20 Jul 2020, Jordan J wrote:
> At present whenever non-resident keys are used the key_handle required
> to use the token must be given by selecting the ssh 'private key'
file
> generated by ssh-keygen during negotiation.
> 
> In the more common webauthn context this key_handle would be stored on
> the server and then transmitted to the client during authentication.
> The client then checks connected tokens for one that reports it
> understands that key_handle and can sign on its behalf. Compared to
> SSH this approach means there are no external files required to use
> the hardware key (use is just plug and play).
> 
> The initial patches for U2F added it as a new authentication method
> and were dropped in favour of the current implementation where it is
> mostly just another key type with an external signature provider. This
> is a less invasive change but means that the information required to
> do a more 'typical' negotiation supporting this plug-and-play use
> isn't available.
Right, this was an deliberate decision. Another motivating factor
was being able to use existing non-OpenSSH SSH tooling and workflows
with only small changes.
> However that degree of plug-and-play is desirable in some
> circumstances. Particularly those where the user may be logging in
> from different transient machines. The current method requires the
> user to carry around the security key as well as the 'private key'
on
> a USB stick so that both can be accessed. Not fatal by any means, but
> not ideal compared to a more typical webauthn flow.
> 
> (onto the questions)
> 
> 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.
> An appropriate method to implement #2 without reverting to the more
> invasive alternate-auth-method would seem to be via SSH extensions
> (RFC8308). If both the client and the server signal their support for
> the extension a list of known *-sk keys could be sent after a user is
> selected. This would then let the client select a key without needing
> the private key file. This should also prevent any incompatibilities
> between clients with and without support. They can use the external
> file the same as they do now.
If you do this, then you don't need step #1 at all: the server
could send the key handles registered for a user at the start
of userauth and the client could proceed to match them against their
available hardware authenticators and return a signature using one.

-d

> Right, this was an deliberate decision. Another motivating factor
> was being able to use existing non-OpenSSH SSH tooling and workflows
> with only small changes.
Hopefully with extensions this can keep that benefit!
> 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.
> [snip]
> If you do this, then you don't need step #1 at all: the server
> could send the key handles registered for a user at the start
> of userauth and the client could proceed to match them against their
> available hardware authenticators and return a signature using one.
I was thinking putting the key_handle in the public key is potentially
an easy way to inform the server of the key handles using the existing
add authorized key flow; but I can understand the desire to be able to
password it. As the private key contains the public key as well as the
key handle, is there any reason we couldn't allow people to upload the
(not passworded) private key file to authorized_keys as a way of
specifying both? It's useless without the hardware key anyway. That
also provides a way for the user to choose if they want to avail of
the feature by which key file they upload and do so on a per-key basis
if they choose. It's a very subtle way of enabling a feature though
that people probably wouldn't intuit so it'd need to be clearly
documented - but that shouldn't be an issue.

I'm trying to avoid something that would add new configuration files
if it's not necessary, but a seperate file for a list of key handles
the user wants to advertise is also an option of course.

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