Mailing List Archive

Question about webauthn signatures?
I see the PROTOCOL.u2f file defines a webauthn signature type

string "webauthn-sk-ecdsa-sha2-nistp256@openssh.com"
string ecdsa_signature
byte flags
uint32 counter
string origin
string clientData
string extensions

and it is also listed as supported by my OpenSSH client and sever

$ ssh -V
OpenSSH_8.5p1, OpenSSL 1.1.1k 25 Mar 2021
$ ssh -Q sigs
...
webauthn-sk-ecdsa-sha2-nistp256@openssh.com
$ ssh -v localhost
...
debug1: kex_input_ext_info: server-sig-algs=<...,webauthn-sk-ecdsa-sha2-nistp256@openssh.com>

I am very curious what this is for and am hoping someone could elaborate in case it might be useful to us? If I try and limit my connection to it, it seems to imply there should be some corresponding key type

$ ssh -v -o PubkeyAcceptedAlgorithms=webauthn-sk-ecdsa-sha2-nistp256@openssh.com localhost
...
debug1: Skipping sk-ecdsa-sha2-nistp256@openssh.com key /home/tyson/.ssh/id_ecdsa_sk - corresponding algo not in PubkeyAcceptedAlgorithms
...

Is there anything that currently uses it? Is it to support ssh client running on a server and proxing back the challenge to user via a web-browser? Part of certificates somehow?

Thanks! -Tyson

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Question about webauthn signatures? [ In reply to ]
On Wed, 5 May 2021, Tyson Whitehead wrote:

> I see the PROTOCOL.u2f file defines a webauthn signature type
>
> string "webauthn-sk-ecdsa-sha2-nistp256@openssh.com"
> string ecdsa_signature
> byte flags
> uint32 counter
> string origin
> string clientData
> string extensions
>
> and it is also listed as supported by my OpenSSH client and sever
>
> $ ssh -V
> OpenSSH_8.5p1, OpenSSL 1.1.1k 25 Mar 2021
> $ ssh -Q sigs
> ...
> webauthn-sk-ecdsa-sha2-nistp256@openssh.com
> $ ssh -v localhost
> ...
> debug1: kex_input_ext_info:
> server-sig-algs=<...,webauthn-sk-ecdsa-sha2-nistp256@openssh.com>
>
> I am very curious what this is for and am hoping someone could elaborate in
> case it might be useful to us? If I try and limit my connection to it, it
> seems to imply there should be some corresponding key type

Without knowing your needs I can't really say whether it would be useful
to you :)

The webauthn signature type (note: note a key type) was added to support
browser-based SSH clients that can only interact with FIDO keys via the
webauthn APIs. These APIs do not allow "bare" FIDO signatures, but
implictly include weborigin information in the signed data.

> $ ssh -v -o
> PubkeyAcceptedAlgorithms=webauthn-sk-ecdsa-sha2-nistp256@openssh.com localhost
> ...
> debug1: Skipping sk-ecdsa-sha2-nistp256@openssh.com key
> /home/tyson/.ssh/id_ecdsa_sk - corresponding algo not in
> PubkeyAcceptedAlgorithms

Yeah, I need to add it to myproposal.h so it's in the default accepted set.
Until then users need to configure it manually.

> Is there anything that currently uses it? Is it to support ssh client running
> on a server and proxing back the challenge to user via a web-browser? Part of
> certificates somehow?

The only thing that AFAIK uses it is the test Javascript that I wrote:
regress/unittests/sshsig/webauthn.html in the source distribution. If you
stick it on a web server then you can generate FIDO keys and webauthn
signatures that you can verify using ssh-keygen -Y. It's the basis of
the webauthn signature unit tests.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Question about webauthn signatures? [ In reply to ]
On 5/6/21 2:02 AM, Damien Miller wrote:
> On Wed, 5 May 2021, Tyson Whitehead wrote:
> Without knowing your needs I can't really say whether it would be useful
> to you :)

Sorry if I wasn't clear here. I was just meaning I wanted to understand in case, upon doing so, I would see a use case.

The background would be that I work for one of the members of the Canadian academic super computing consortium Compute Canada. We have a very large user base across Canada (free accounts for all Canadian researchers and their students) with a wide range of computing experience. When we have been compromised, it has been by local privilege escalation from a user account compromised elsewhere.

Ideally we would like to help our users avoid their accounts being compromised without raising any usability hurtles to our many non-unix-savvy users.

> The webauthn signature type (note: note a key type) was added to support
> browser-based SSH clients that can only interact with FIDO keys via the
> webauthn APIs. These APIs do not allow "bare" FIDO signatures, but
> implictly include weborigin information in the signed data.

Thank you for the clarification. I believe I understand now it is for the signature in the SSH_MSG_USERAUTH_REQUEST when the client only has access to the device via the webauthn API. That makes sense.

Many of our non-unix savvy users just use passwords as settings up keys is difficult for them. From reading up on the FIDO2 standard, it would seem that it should be possible to just have server-side FIDO2 keys. This could be a huge plus as we could generate and register these keys on our clusters for them off our website. They could just use them without having to setup anything on their end.

I was looking at RFC4252 (The SSH Authentication Protocol) to see if FIDO2-based server-side could be retrofitted into the SSH protocol, and it seemed to me like it could be done. Specifically, the "publickey" authentication protocol has the client send

byte SSH_MSG_USERAUTH_REQUEST
string user name in ISO-10646 UTF-8 encoding
string service name in US-ASCII
string "publickey"
boolean FALSE
string public key algorithm name
string public key blob

and the server respond with

byte SSH_MSG_USERAUTH_PK_OK
string public key algorithm name from the request
string public key blob from the request

so I am thinking it could be (slightly) abused by

1. creating a another esk-ecdsa key type where the key handle was stored with the public key
2. have the client pass an empty "public key blob" when sending the SSH_MSG_USERAUTH_REQUEST message for this key type
3. have the server respond back with the key handle (or the entire public key with the key handle) in the "public key blob" of its SSH_MSG_USERAUTH_PK_OK response

Support for multiple keys could be done by having repeated queries return subsequent ones. The server could also reply with fakes to avoid leaking information about whether any such keys actually exist.

> The only thing that AFAIK uses it is the test Javascript that I wrote:
> regress/unittests/sshsig/webauthn.html in the source distribution. If you
> stick it on a web server then you can generate FIDO keys and webauthn
> signatures that you can verify using ssh-keygen -Y. It's the basis of
> the webauthn signature unit tests.

Very interesting. I added a bit on top of your javascript to also export the private key to see if we could do the key generation sever side in order to make things easier for our non-unix-savvy users

https://staff.sharcnet.ca/tyson/webauthnkey.html

The resulting keys seem to work fine in SSH, which makes me think, if SSH could support pure server-side key, and we could generate these keys with Webauthn, it would actually make things even easier for our non-unix-savvy users (buy a key, press a button on our website to register it) while really tightening up user accounts and thereby decreasing the attack vectors against us.

Would love to hear your thoughts on it.

Thanks! -Tyson
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Question about webauthn signatures? [ In reply to ]
On Thu, 6 May 2021, Tyson Whitehead wrote:

> > The webauthn signature type (note: note a key type) was added to support
> > browser-based SSH clients that can only interact with FIDO keys via the
> > webauthn APIs. These APIs do not allow "bare" FIDO signatures, but
> > implictly include weborigin information in the signed data.
>
> Thank you for the clarification. I believe I understand now it is for the
> signature in the SSH_MSG_USERAUTH_REQUEST when the client only has access to
> the device via the webauthn API. That makes sense.
>
> Many of our non-unix savvy users just use passwords as settings up keys is
> difficult for them. From reading up on the FIDO2 standard, it would seem that
> it should be possible to just have server-side FIDO2 keys. This could be a
> huge plus as we could generate and register these keys on our clusters for
> them off our website. They could just use them without having to setup
> anything on their end.

That's true of FIDO web authentication. What we implemented in SSH
(ab-)uses the FIDO spec to fit SSH's existing publickey user
authentication, because users and lots of tooling is built around that.

This unfortunately precluded the use of server-side keys, as there is no
mechanism for the server to communicate key handles to the client.

I do have vague plans to do a more web-like FIDO authentication method
for OpenSSH in the future, but haven't got around to it yet.

> I was looking at RFC4252 (The SSH Authentication Protocol) to see if
> FIDO2-based server-side could be retrofitted into the SSH protocol, and it
> seemed to me like it could be done. Specifically, the "publickey"
> authentication protocol has the client send
>
> byte SSH_MSG_USERAUTH_REQUEST
> string user name in ISO-10646 UTF-8 encoding
> string service name in US-ASCII
> string "publickey"
> boolean FALSE
> string public key algorithm name
> string public key blob
>
> and the server respond with
>
> byte SSH_MSG_USERAUTH_PK_OK
> string public key algorithm name from the request
> string public key blob from the request
>
> so I am thinking it could be (slightly) abused by
>
> 1. creating a another esk-ecdsa key type where the key handle was stored with
> the public key
> 2. have the client pass an empty "public key blob" when sending the
> SSH_MSG_USERAUTH_REQUEST message for this key type
> 3. have the server respond back with the key handle (or the entire public key
> with the key handle) in the "public key blob" of its SSH_MSG_USERAUTH_PK_OK
> response
>
> Support for multiple keys could be done by having repeated queries return
> subsequent ones. The server could also reply with fakes to avoid leaking
> information about whether any such keys actually exist.

I was thinking something like:

c->s

byte SSH_MSG_USERAUTH_REQUEST
string username
string service name
string "fido-discover-v00@openssh.com"
string reserved

s->c

byte SSH_MSG_USERAUTH_INFO_REQUEST
string reserved
string[] key_info

(this message number was defined for GSS authentication, w/
SSH_MSG_USERAUTH_INFO_REQUEST always going in the s->c direction and
SSH_MSG_USERAUTH_INFO_RESPONSE always going c->s).

where each key_info member contains

string pkblob
string key handle
uint8 flags
string reserved

The client could then try the key handles supplied against their attached
security keys to find one that will sign a challenge and then make a
regular public key authentication attempt:

byte SSH_MSG_USERAUTH_INFO_RESPONSE
string username
string service name
string "publickey"
bool true
string pkalg
string pkblob
string signature

**

The protocol bits are pretty easy, the UI is a bit more complicated. The
main problem is that we need some way to store the keys eligible for
fido-discover-v00@openssh.com.

One possibility is marking them using some tag in authorized_keys, but
the information we need to return is more than currently exists in the
sk-* public key formats. So we'd need a new encoding that stores the
extra information and likely some ugly special-casing to glue it all
together.

Perhaps authorized_keys entries like

fido[,option...] sk-ecdsa-sha2-nistp256@openssh.com pubkeyblob keyhandleblob

flags would be reconstructed from the options listed on the key:
no-touch-required, verify-required, etc.

Another alternative would be to define a pubkey blob format that includes
all the information. Not sure which is nicer...

> > The only thing that AFAIK uses it is the test Javascript that I wrote:
> > regress/unittests/sshsig/webauthn.html in the source distribution. If you
> > stick it on a web server then you can generate FIDO keys and webauthn
> > signatures that you can verify using ssh-keygen -Y. It's the basis of
> > the webauthn signature unit tests.
>
> Very interesting. I added a bit on top of your javascript to also export the
> private key to see if we could do the key generation sever side in order to
> make things easier for our non-unix-savvy users
>
> https://staff.sharcnet.ca/tyson/webauthnkey.html

ah good idea, this inspired me to add a similar feature to mine now too.
https://github.com/openssh/openssh-portable/commit/c0d7e36e979

> The resulting keys seem to work fine in SSH, which makes me think, if SSH
> could support pure server-side key, and we could generate these keys with
> Webauthn, it would actually make things even easier for our non-unix-savvy
> users (buy a key, press a button on our website to register it) while really
> tightening up user accounts and thereby decreasing the attack vectors against
> us.

yep, agree. I think a FIDO-style authn method would be a nice addition.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Question about webauthn signatures? [ In reply to ]
On 5/6/21 10:41 PM, Damien Miller wrote:
> I do have vague plans to do a more web-like FIDO authentication method
> for OpenSSH in the future, but haven't got around to it yet.

This is very good news! :)

> (this message number was defined for GSS authentication, w/
> SSH_MSG_USERAUTH_INFO_REQUEST always going in the s->c direction and
> SSH_MSG_USERAUTH_INFO_RESPONSE always going c->s).
>
> where each key_info member contains
>
> string pkblob
> string key handle
> uint8 flags
> string reserved

This all seems really good to me. I'm guessing, however, you meant to have "key handle" and "flags" reversed here to match the private key layout you defined.

> Perhaps authorized_keys entries like
>
> fido[,option...] sk-ecdsa-sha2-nistp256@openssh.com pubkeyblob keyhandleblob
>
> flags would be reconstructed from the options listed on the key:
> no-touch-required, verify-required, etc.
>
> Another alternative would be to define a pubkey blob format that includes
> all the information. Not sure which is nicer...

I'm not expert, but I would probably lean towards maintaining the "options, keytype, base64-encode, key, comment" format of the authorized_keys file by combining the pubkey and keyhandle blob as currently is done in the private key format.

The user clearly isn't going to want to mix and match different pubkeyblobs and keyhandleblobs, the only real purpose of letting them specify both is to make it so they can optionally not include the keyhandleblob.

So, perhaps, the authorized_keys "sk-ecdsa-sha2-nistp256@openssh.com" keytype could be for either a base64 encoded sk-* public or private key. The private key starts with the public key, so decoding would just be a matter of continue on decoding the private bit if there is still stuff left over after the public bit is done.

I guess this doesn't make it so obvious to the user how to distinguish the two though, so maybe a new authorized_keys "skc-ecdsa-sha2-nistp256@openssh.com" (security key combined?) keytype would be better to use to explicitly distinguish whether it is a base64 encoded sk-* public or private key for the user?

A third option would be to just make it so you can specify the key handle in base64 as one of the options. A bit ugly due to being on the long side for an option, but maybe the most in keeping with the spirit of the authorized_keys file format?

key-handle=MDAwMDAwMDA6IDViIDFlIGJjIDNmIDMyIGIwIDg4IDFjIGI3IDBiIGI3IGFiIGNjIDA4IDY0IDkwCjAwMDAwMDEwOiBiZiA1OSBjYSBiOSBkZCAzZSAyMiA3OCBiYyAyNyAyOCBmMSA3ZSA2NiBjMiBhYQowMDAwMDAyMDogY2UgYzUgYjYgYzkgYzAgZGUgMzkgNzQgMjAgMDMgNjUgYzkgNTggZmQgZDAgZGYKMDAwMDAwMzA6IDc0IDRiIDE3IGM1IDRkIDE5IDNmIGI0IDQ1IGIxIDhkIGY0IGU0IGQ1IGU2IDg5Cg== sk-ecdsa-sha2-nistp256@openssh.com pubkeyblob comment

Anyway, really excited to hear that you have been thinking about these things! Thanks for letting us in on your thoughts. Looking forward to whatever comes of it.

Cheers! -Tyson
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Question about webauthn signatures? [ In reply to ]
> That's true of FIDO web authentication. What we implemented in SSH
> (ab-)uses the FIDO spec to fit SSH's existing publickey user
> authentication, because users and lots of tooling is built around that.
>
> This unfortunately precluded the use of server-side keys, as there is no
> mechanism for the server to communicate key handles to the client.
>
> I do have vague plans to do a more web-like FIDO authentication method
> for OpenSSH in the future, but haven't got around to it yet.
>

FWIW after taking on board the discussion from this previously I did
go off and implement a proof-of-concept for this via ssh-extensions.
If the client and server understood the extension you get to use
server-side keys otherwise it fell back to the current implementation.
Seemed to work fine. I'd planned to spend some of early June turning
it from a proof-of-concept into something more review suitable to
bring back here for people to have a go with.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Question about webauthn signatures? [ In reply to ]
> FWIW after taking on board the discussion from this previously I did
> go off and implement a proof-of-concept for this via ssh-extensions.
> If the client and server understood the extension you get to use
> server-side keys otherwise it fell back to the current implementation.
> Seemed to work fine. I'd planned to spend some of early June turning
> it from a proof-of-concept into something more review suitable to
> bring back here for people to have a go with.

This sounds great! My opinion isn't one that matters here, but, when
you have something you are ready to share, I would be more than happy
to try out and give you any feedback I may have if you are looking for
testers.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev