webauthn signatures: SecurityKeyProvider, json parsing

[Scott C Wang]

> Sure, but OpenSSH is the thing requesting the signature to begin with
> and isn't going to requesting extra stuff. So AFAIK there's no need
> to pass clientData from OpenSSH to the signer.

Sorry Damien, I had misunderstood your message. Yes, I agree with you that OpenSSH does not pass clientData to the signer, but instead the signer returns to OpenSSH the clientData that the browser generated.

> AFAIK extensions are the extra things that go in clientData, no?

For the avoidance of doubt, the extensions are not part of the clientData blob, but rather the separate authenticatorData blob. Therefore, the signer does need a way to provide the extensions when returning to OpenSSH. To elaborate, I understand the security key's signature to be over the concatenation of the following:

- authenticatorData blob
    - rpIdHash (the relying party ID resides in the OpenSSH public key as the "application" field, so OpenSSH passes it to the signer in the "application" parameter. No code change needed in OpenSSH)
    - flags (the sk_sign_response struct already has a field for this)
    - counter (the sk_sign_response struct already has a field for this)
    - extensions
- H(clientData)

So the pieces that are missing from sk-api.h to support a webauthn signature are the struct fields for the signer to return (1) extensions and (2) the entirety of the clientData blob. If the signer returns both of these, then the OpenSSH client knows what it needs to to construct a webauthn signature message.

Thank you!


Scott C Wang


From: Damien Miller <djm at mindrot.org>
Sent: 12 January 2022 17:00
To: Scott C Wang <wangsc at cs.wisc.edu>
Cc: openssh-unix-dev at mindrot.org <openssh-unix-dev at mindrot.org>
Subject: Re: webauthn signatures: SecurityKeyProvider, json parsing 
 
On Wed, 12 Jan 2022, Scott C Wang wrote:

> Awesome! Thank you, Damien.
> 
> > AFAIK clientData is
> > prepared from origin, extensions and H(message), so there's not need
> > to pass that explicitly.
>
> The trouble with not passing clientData is that the spec reserves
> the right to append new keys to it in the future. To validate
> the signature, the OpenSSH server has to be apprised of the
> entire clientData blob returned from the webauthn API. Ergo, the
> OpenSSH client does need to be passed the entire clientData blob
> explicitly, as opposed to reconstructing it, lest there be extra keys.
> (Chromium already randomly appends an extra "reminder" key to break
> implementations that attempt such a construction. [0])

Sure, but OpenSSH is the thing requesting the signature to begin with
and isn't going to requesting extra stuff. So AFAIK there's no need
to pass clientData from OpenSSH to the signer.

> > As far as communicating with the webauthn signer via the ssh-sk API,
> > nothing in OpenSSH uses the extensions field and the existing
> > application field could be used to pass origin.
>
> Are you referring to passing in, or passing back? Does "extensions"
> refer to the authenticatorData attestedCredentialData and extensions
> [0]? If so, then the SecurityKeyProvider will need to pass those
> back to OpenSSH so that the server can include them in the hash
> computation, even if it doesn't parse them.

AFAIK extensions are the extra things that go in clientData, no?

-d


From: Damien Miller <djm at mindrot.org>
Sent: 12 January 2022 17:00
To: Scott C Wang <wangsc at cs.wisc.edu>
Cc: openssh-unix-dev at mindrot.org <openssh-unix-dev at mindrot.org>
Subject: Re: webauthn signatures: SecurityKeyProvider, json parsing 
 
On Wed, 12 Jan 2022, Scott C Wang wrote:

> Awesome! Thank you, Damien.
> 
> > AFAIK clientData is
> > prepared from origin, extensions and H(message), so there's not need
> > to pass that explicitly.
>
> The trouble with not passing clientData is that the spec reserves
> the right to append new keys to it in the future. To validate
> the signature, the OpenSSH server has to be apprised of the
> entire clientData blob returned from the webauthn API. Ergo, the
> OpenSSH client does need to be passed the entire clientData blob
> explicitly, as opposed to reconstructing it, lest there be extra keys.
> (Chromium already randomly appends an extra "reminder" key to break
> implementations that attempt such a construction. [0])

Sure, but OpenSSH is the thing requesting the signature to begin with
and isn't going to requesting extra stuff. So AFAIK there's no need
to pass clientData from OpenSSH to the signer.

> > As far as communicating with the webauthn signer via the ssh-sk API,
> > nothing in OpenSSH uses the extensions field and the existing
> > application field could be used to pass origin.
>
> Are you referring to passing in, or passing back? Does "extensions"
> refer to the authenticatorData attestedCredentialData and extensions
> [0]? If so, then the SecurityKeyProvider will need to pass those
> back to OpenSSH so that the server can include them in the hash
> computation, even if it doesn't parse them.

AFAIK extensions are the extra things that go in clientData, no?

-d