Mailing List Archive: Automatic FIDO2 key negotiation (request for comments)

Automatic FIDO2 key negotiation (request for comments)

Jul 20, 2020, 10:46 AM

Post #1 of 6 (514 views)

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?
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: Automatic FIDO2 key negotiation (request for comments) [ In reply to ]

djm at mindrot

Jul 20, 2020, 9:47 PM

Post #2 of 6 (514 views)

Permalink

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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: Automatic FIDO2 key negotiation (request for comments) [ In reply to ]

jordandev678 at gmail

Jul 21, 2020, 4:13 AM

Post #3 of 6 (514 views)

Permalink

> 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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: Automatic FIDO2 key negotiation (request for comments) [ In reply to ]

James.Bottomley at HansenPartnership

Jul 26, 2020, 9:34 AM

Post #4 of 6 (509 views)

Permalink

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

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: Automatic FIDO2 key negotiation (request for comments) [ In reply to ]

jordandev678 at gmail

Jul 26, 2020, 10:50 AM

Post #5 of 6 (509 views)

Permalink

> 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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: Automatic FIDO2 key negotiation (request for comments) [ In reply to ]

James.Bottomley at HansenPartnership

Jul 26, 2020, 12:13 PM

Post #6 of 6 (509 views)

Permalink

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

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev