Question about webauthn signatures?

[Tyson Whitehead]

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