Question about webauthn signatures?

[Damien Miller]

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