Webauthn signatures working in the wild, and client-agent support

[Carlos Cabanero]

Thanks a lot for the prompt reply!

It definitely does not sound like there is an easy way out of this
one. I want to put on the table one more possibility though.

On Mon, Sep 19, 2022 at 6:15 PM Damien Miller <djm at mindrot.org> wrote:

> Unfortunately this webauthn keys via the agent isn't going to
> work ATM and I'm not immediately sure how to fix it.
>
> The problem is between sshconnect2.c:sign_and_send_pubkey() and
> identity_sign().
>
> In sign_and_send_pubkey() we have to assembled the data to be
> signed (basically the SSH2_MSG_USERAUTH_REQUEST we're about to
> send), and that includes the signature algorithm:
>
> >    if ((r = sshbuf_put_u8(b, SSH2_MSG_USERAUTH_REQUEST)) != 0 ||
> >        (r = sshbuf_put_cstring(b, authctxt->server_user)) != 0 ||
> >        (r = sshbuf_put_cstring(b, authctxt->service)) != 0 ||
> >        (r = sshbuf_put_cstring(b, method)) != 0 ||
> >        (r = sshbuf_put_u8(b, 1)) != 0 ||
> >        (r = sshbuf_put_cstring(b, alg)) != 0 ||
> >        (r = sshkey_puts(id->key, b)) != 0) {
> >            fatal_fr(r, "assemble signed data");
>
> Unfortunately, we don't learn that the key is only capable of making
> webauthn signatures until we attempt signing via identity_sign() and
> observe (via sshkey_check_sigtype()) that we got a webauthn signature
> back.
>
> Perhaps there should be some way for ssh-agent to signal to the client
> that a particular key can only make webauthn signatures, but I'm not
> sure how best to do this.
>

Between sshconnect2.c:sign_and_send_pubkey() and identity_sign(),
there is a call to key_sig_algorithm and its output is used for
SSH2_MSG_USERAUTH, and so on... key_sig_algorithm makes use of
sshkey:sshkey_ssh_name_from_type_nid. The issue there is that webauthn
and sk both are declared as the same type: KEY_ECDSA_SK.

At the moment webauthn-sk is considered just a signature only type,
per sshkey:keytypes, and per your "experiment", the pubkey type is
made sk-ecdsa. But, trying to force things, if you create the pubkey
as webauthn-sk-ecdsa, sshd will log you in if you add webkey-sk-ecdsa
as an Allowed Pubkey Method.

As you said, it is a violation that the key and signature are
different, but could a case be made to grant webauthn-sk-ecdsa the
full "key type" status? At the end of the day, it is not fully true
that KEY_ECDSA_SK and Webauthn represent the same type of key, even if
until now things have been "forced" to fit that way.

I may be missing something or not have the full scope of a change like
that, but just want to run it through you to see if it may be a viable
possibility.

Thanks again!