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

[Carlos Cabanero]

On Mon, Sep 19, 2022 at 8:05 PM Damien Miller <djm at mindrot.org> wrote:
>
> On Mon, 19 Sep 2022, Carlos Cabanero wrote:
>
> > 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.
>
> Well, this is similar to what I suggested wrt having the agent send the
> keys back as "webauthn-sk-ecdsa-sha2-nistp256" but a little more
> officially :)
>
> There are two ways to do this. One is keeping the key type id
> as KEY_ECDSA_SK and adding a key->flags entry to indicate that it's
> webauthn-only. Another is a whole separate key type.
>
> At the moment, adding a new key type means a lot of duplicated
> boilerplate code. I have some WIP changes to reduce this[1], but even
> after they land it there is so much overlap with regular ecdsa-sk keys
> it probably makes more sense to go the other way.
>
> -d
>
> [1] https://github.com/djmdjm/openssh-wip/pull/10/commits

Ahhh I think I see now. Using key->flags we could indicate that it is
webauthn only, but as you mentioned in your first message, we would
also need some way for the agent to communicate that when listing, or
to make it fallback to a webauthn-signature at one point, correct?

Now that I have an idea of the scope I think it is doable, but we will
definitely not make it for v1. We will launch as-is to see what
adoption we get, and if we get requests to add forwarding capabilities
at least we know there could be a way. Hopefully we can contribute
that to the project :)