Mailing List Archive

webauthn signatures: SecurityKeyProvider, json parsing
Greetings,

I was recently exploring OpenSSH's support for security keys and webauthn signatures, and had the following questions.

(1) Could you confirm that the client doesn't support creating signatures of type "webauthn-sk-ecdsa-sha2-nistp256@openssh.com"? To me, it looked like SecurityKeyProvider implementers of sk-api.h aren't provided fields in the sk_sign_response struct in which to return the origin, clientData, and extensions signature fields, and sshsk_sign in ssh-sk.c cannot create signatures of type "webauthn-sk-ecdsa-sha2-nistp256@openssh.com". What considerations would there be against augmenting sk-api.h with a webauthn signature type with fields for origin, clientData, and extensions, so that SecurityKeyProvider implementers can provide webauthn signatures?

(2) Am I correct to understand, from my reading of webauthn_check_prepare_hash in ssh-ecdsa-sk.c, that the server requires the webauthn signature's clientData field to begin with the type, challenge, and origin json fields, and ignores all fields after origin; and the hash is computed over the entire clientData blob? I'm asking to clarify since I notice Google Chromium [0] and the webauthn spec [1] warn that the json could be extended in the future, so they discourage verifiers from relying upon the order of the keys.

(3) I happened upon regress/unittests/sshsig/webauthn.html, which is very useful; however, the script hardcodes the relying party as "mindrot.org". I edited out that domain and hosted the site on my own domain to get this page to work. Is this page already hosted on mindrot.org, and if so, what's the path?

Thanks for your patience with my questions,


Scott C Wang

[0] https://goo.gl/yabPex
[1] https://w3c.github.io/webauthn/#dictdef-collectedclientdata
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: webauthn signatures: SecurityKeyProvider, json parsing [ In reply to ]
PS - Ignore my question (2), below. I've just observed that the webauthn spec sanctions a "limited verification algorithm" for clientData, and assures that the type, challenge, origin, and crossOrigin fields will always appear first in the json [2].

I would still appreciate your thoughts on my questions (1) and (3).

Thanks,


Scott C Wang

[2] https://w3c.github.io/webauthn/#clientdatajson-verification





From: Scott C Wang <wangsc@cs.wisc.edu>
Sent: 10 January 2022 22:55
To: openssh-unix-dev@mindrot.org <openssh-unix-dev@mindrot.org>
Subject: webauthn signatures: SecurityKeyProvider, json parsing
?
Greetings,

I was recently exploring OpenSSH's support for security keys and webauthn signatures, and had the following questions.

(1) Could you confirm that the client doesn't support creating signatures of type "webauthn-sk-ecdsa-sha2-nistp256@openssh.com"? To me, it looked like SecurityKeyProvider implementers of sk-api.h aren't provided fields in the sk_sign_response struct in which to return the origin, clientData, and extensions signature fields, and sshsk_sign in ssh-sk.c cannot create signatures of type "webauthn-sk-ecdsa-sha2-nistp256@openssh.com". What considerations would there be against augmenting sk-api.h with a webauthn signature type with fields for origin, clientData, and extensions, so that SecurityKeyProvider implementers can provide webauthn signatures?

(2) Am I correct to understand, from my reading of webauthn_check_prepare_hash in ssh-ecdsa-sk.c, that the server requires the webauthn signature's clientData field to begin with the type, challenge, and origin json fields, and ignores all fields after origin; and the hash is computed over the entire clientData blob? I'm asking to clarify since I notice Google Chromium [0] and the webauthn spec [1] warn that the json could be extended in the future, so they discourage verifiers from relying upon the order of the keys.

(3) I happened upon regress/unittests/sshsig/webauthn.html, which is very useful; however, the script hardcodes the relying party as "mindrot.org". I edited out that domain and hosted the site on my own domain to get this page to work. Is this page already hosted on mindrot.org, and if so, what's the path?

Thanks for your patience with my questions,


Scott C Wang

[0] https://goo.gl/yabPex
[1] https://w3c.github.io/webauthn/#dictdef-collectedclientdata
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: webauthn signatures: SecurityKeyProvider, json parsing [ In reply to ]
On Tue, 11 Jan 2022, Scott C Wang wrote:

> Greetings,
>
> I was recently exploring OpenSSH's support for security keys and
> webauthn signatures, and had the following questions.
>
> (1) Could you confirm that the client doesn't support creating
> signatures of type "webauthn-sk-ecdsa-sha2-nistp256@openssh.com"?
> To me, it looked like SecurityKeyProvider implementers of sk-api.h
> aren't provided fields in the sk_sign_response struct in which to
> return the origin, clientData, and extensions signature fields,
> and sshsk_sign in ssh-sk.c cannot create signatures of type
> "webauthn-sk-ecdsa-sha2-nistp256@openssh.com". What considerations
> would there be against augmenting sk-api.h with a webauthn signature
> type with fields for origin, clientData, and extensions, so that
> SecurityKeyProvider implementers can provide webauthn signatures?

What use for this do you have in mind?

It wouldn't be too hard to allocate a SSH_SK_* flag that indicates
that the data to be signed is a webauthn request and that the result
should be a webauthn signature, but I don't see how this would be used
in OpenSSH itself.

> (2) Am I correct to understand, from my reading of
> webauthn_check_prepare_hash in ssh-ecdsa-sk.c, that the server
> requires the webauthn signature's clientData field to begin with the
> type, challenge, and origin json fields, and ignores all fields after
> origin; and the hash is computed over the entire clientData blob? I'm
> asking to clarify since I notice Google Chromium [0] and the webauthn
> spec [1] warn that the json could be extended in the future, so they
> discourage verifiers from relying upon the order of the keys.

We worked with the webauthn team to avoid this. Strictly the
signed/verified data isn't JSON, but a JSON-compatible format that
strictly specifies the ordering of fields in a way to *not* require
a JSON parser in a signature verifer, as that would be a deal-breaker
for SSH use :)

> (3) I happened upon regress/unittests/sshsig/webauthn.html, which
> is very useful; however, the script hardcodes the relying party as
> "mindrot.org". I edited out that domain and hosted the site on my
> own domain to get this page to work. Is this page already hosted on
> mindrot.org, and if so, what's the path?

it's at https://www.mindrot.org/webauthn

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: webauthn signatures: SecurityKeyProvider, json parsing [ In reply to ]
Damien, thanks for clarifying.

(1 SecurityKeyProvider)

I don't have a FIDO security key, but I do have an Android phone, and the Android phone can act as a webauthn key via Google Chrome. So these were the shower thoughts I had for getting this to work.

I implement a SecurityKeyProvider that prints a https URL upon sk_sign. I open this URL in Google Chrome. The script on the page calls the webauthn authentication API; Google Chrome prompts me to choose an authentication method, and I pick my phone. Authenticating my fingerprint on my phone yields a webauthn signature to the script, which POSTs the signature, origin, clientData, and extensions back to the same URL. The SecurityKeyProvider polls the URL (or some endpoint) until the signature arrives, which it returns, along with the origin, clientData, and extensions, to the OpenSSH client. The OpenSSH client now has what it needs to pack a "webauthn-sk-ecdsa-sha2-nistp256@openssh.com" signature message, all of which the OpenSSH server currently already supports validating.

More generally, this one SecurityKeyProvider implementation would be able to bridge the OpenSSH client's security key authentication to any platform running a web browser exposing the webauthn API.

I've only given preliminary thought to this as yet -- have I gone mad?

(2 json key order) Perfect! Very prudent.

(3 mindrot.org) Excellent, thank you for the link. (I was trying /webauthn.html, but hadn't thought to try /webauthn.) Perhaps the hardcoded "mindrot.org" relying party can be changed to window.location.host, so that the standalone page can be hosted without modification on anyone's domain.



Scott C Wang


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

> Greetings,
>
> I was recently exploring OpenSSH's support for security keys and
> webauthn signatures, and had the following questions.
>
> (1) Could you confirm that the client doesn't support creating
> signatures of type "webauthn-sk-ecdsa-sha2-nistp256@openssh.com"?
> To me, it looked like SecurityKeyProvider implementers of sk-api.h
> aren't provided fields in the sk_sign_response struct in which to
> return the origin, clientData, and extensions signature fields,
> and sshsk_sign in ssh-sk.c cannot create signatures of type
> "webauthn-sk-ecdsa-sha2-nistp256@openssh.com". What considerations
> would there be against augmenting sk-api.h with a webauthn signature
> type with fields for origin, clientData, and extensions, so that
> SecurityKeyProvider implementers can provide webauthn signatures?

What use for this do you have in mind?

It wouldn't be too hard to allocate a SSH_SK_* flag that indicates
that the data to be signed is a webauthn request and that the result
should be a webauthn signature, but I don't see how this would be used
in OpenSSH itself.

> (2) Am I correct to understand, from my reading of
> webauthn_check_prepare_hash in ssh-ecdsa-sk.c, that the server
> requires the webauthn signature's clientData field to begin with the
> type, challenge, and origin json fields, and ignores all fields after
> origin; and the hash is computed over the entire clientData blob? I'm
> asking to clarify since I notice Google Chromium [0] and the webauthn
> spec [1] warn that the json could be extended in the future, so they
> discourage verifiers from relying upon the order of the keys.

We worked with the webauthn team to avoid this. Strictly the
signed/verified data isn't JSON, but a JSON-compatible format that
strictly specifies the ordering of fields in a way to *not* require
a JSON parser in a signature verifer, as that would be a deal-breaker
for SSH use :)

> (3) I happened upon regress/unittests/sshsig/webauthn.html, which
> is very useful; however, the script hardcodes the relying party as
> "mindrot.org". I edited out that domain and hosted the site on my
> own domain to get this page to work. Is this page already hosted on
> mindrot.org, and if so, what's the path?

it's at https://www.mindrot.org/webauthn

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: webauthn signatures: SecurityKeyProvider, json parsing [ In reply to ]
Scott C Wang wrote:
> I implement a SecurityKeyProvider that prints a https URL upon sk_sign.
> I open this URL in Google Chrome. The script on the page calls the
> webauthn authentication API; Google Chrome prompts me to choose an
> authentication method, and I pick my phone. Authenticating my
> fingerprint on my phone yields a webauthn signature to the script,
> which POSTs the signature, origin, clientData, and extensions back
> to the same URL. The SecurityKeyProvider polls the URL (or some
> endpoint) until the signature arrives, which it returns, along with
> the origin, clientData, and extensions, to the OpenSSH client.
> The OpenSSH client now has what it needs to pack a
> "webauthn-sk-ecdsa-sha2-nistp256@openssh.com" signature message,
> all of which the OpenSSH server currently already supports validating.
..
> have I gone mad?

FWIW I think the data spray and the complexity are mad, each on their own.

I guess that it'll be popular, I hope not in mainline OpenSSH. ;)


//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: webauthn signatures: SecurityKeyProvider, json parsing [ In reply to ]
Sounds kind of like oidc but with webauthn switched out for some of the plumbing. Would straight up oidc work cleaner for your use case? You can still use all sorts of authentication methods like fingerprints with it.

________________________________________
From: openssh-unix-dev <openssh-unix-dev-bounces+kevin.fox=pnnl.gov@mindrot.org> on behalf of Peter Stuge <peter@stuge.se>
Sent: Tuesday, January 11, 2022 10:31 AM
To: openssh-unix-dev@mindrot.org
Subject: Re: webauthn signatures: SecurityKeyProvider, json parsing

Check twice before you click! This email originated from outside PNNL.


Scott C Wang wrote:
> I implement a SecurityKeyProvider that prints a https URL upon sk_sign.
> I open this URL in Google Chrome. The script on the page calls the
> webauthn authentication API; Google Chrome prompts me to choose an
> authentication method, and I pick my phone. Authenticating my
> fingerprint on my phone yields a webauthn signature to the script,
> which POSTs the signature, origin, clientData, and extensions back
> to the same URL. The SecurityKeyProvider polls the URL (or some
> endpoint) until the signature arrives, which it returns, along with
> the origin, clientData, and extensions, to the OpenSSH client.
> The OpenSSH client now has what it needs to pack a
> "webauthn-sk-ecdsa-sha2-nistp256@openssh.com" signature message,
> all of which the OpenSSH server currently already supports validating.
..
> have I gone mad?

FWIW I think the data spray and the complexity are mad, each on their own.

I guess that it'll be popular, I hope not in mainline OpenSSH. ;)


//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mindrot.org%2Fmailman%2Flistinfo%2Fopenssh-unix-dev&amp;data=04%7C01%7CKevin.Fox%40pnnl.gov%7Ce22d8ea52399494a387208d9d530e42a%7Cd6faa5f90ae240338c0130048a38deeb%7C0%7C0%7C637775228267088932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=DHoJZiyxh8w35fqkDuauIVmnPFOH9mgZxECsdcoEckQ%3D&amp;reserved=0
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: webauthn signatures: SecurityKeyProvider, json parsing [ In reply to ]
On 11/01/2022 18:52, Fox, Kevin M wrote:
> Sounds kind of like oidc but with webauthn switched out for some of the plumbing. Would straight up oidc work cleaner for your use case? You can still use all sorts of authentication methods like fingerprints with it.

You can also trade an OIDC login for an SSH certificate, using Hashicorp
Vault (amongst other solutions)

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: webauthn signatures: SecurityKeyProvider, json parsing [ In reply to ]
On Tue, 11 Jan 2022, Scott C Wang wrote:

> Damien, thanks for clarifying.
>
> (1 SecurityKeyProvider)
>
> I don't have a FIDO security key, but I do have an Android phone, and
> the Android phone can act as a webauthn key via Google Chrome. So
> these were the shower thoughts I had for getting this to work.
>
> I implement a SecurityKeyProvider that prints a https URL upon
> sk_sign. I open this URL in Google Chrome. The script on the page
> calls the webauthn authentication API; Google Chrome prompts
> me to choose an authentication method, and I pick my phone.
> Authenticating my fingerprint on my phone yields a webauthn signature
> to the script, which POSTs the signature, origin, clientData, and
> extensions back to the same URL. The SecurityKeyProvider polls
> the URL (or some endpoint) until the signature arrives, which it
> returns, along with the origin, clientData, and extensions, to the
> OpenSSH client. The OpenSSH client now has what it needs to pack a
> "webauthn-sk-ecdsa-sha2-nistp256@openssh.com" signature message, all
> of which the OpenSSH server currently already supports validating.
>
> More generally, this one SecurityKeyProvider implementation would be
> able to bridge the OpenSSH client's security key authentication to any
> platform running a web browser exposing the webauthn API.
>
> I've only given preliminary thought to this as yet -- have I gone mad?

No, I've wondered about the same thing too :)

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. AFAIK clientData is
prepared from origin, extensions and H(message), so there's not need
to pass that explicitly.

That just leaves signalling that the signer wants an origin rather
than a bare application, and signalling back from the signer that the
signature should be packed as a webauthn one.

Am I missing anything? (I apologise for forgetting most of the details
since I implemented webauthn in OpenSSH)

> (2 json key order) Perfect! Very prudent.
>
> (3 mindrot.org) Excellent, thank you for the link. (I was trying
> /webauthn.html, but hadn't thought to try /webauthn.) Perhaps
> the hardcoded "mindrot.org" relying party can be changed to
> window.location.host, so that the standalone page can be hosted
> without modification on anyone's domain.

good idea - done.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: webauthn signatures: SecurityKeyProvider, json parsing [ In reply to ]
On Tue, 11 Jan 2022, Peter Stuge wrote:

> FWIW I think the data spray and the complexity are mad, each on their own.
>
> I guess that it'll be popular, I hope not in mainline OpenSSH. ;)

The SecurityKeyProvider interface exists largely to make this sort of
experimentation possible outside of OpenSSH itself.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: webauthn signatures: SecurityKeyProvider, json parsing [ In reply to ]
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])

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

Could you clarify what you mean by passing back the origin in the "existing application field"? Since the origin is part of clientData, which as discussed above the SecurityKeyProvider needs to pass back anyway, the OpenSSH client can parse it out of there to populate the signature with.

> That just leaves signalling that the signer wants an origin rather
> than a bare application, and signalling back from the signer that the
> signature should be packed as a webauthn one.

To be clear, the SecurityKeyProvider will want the application ("mindrot.org") from the key, as opposed to the origin. The SecurityKeyProvider will pass the application into the webauthn credential request as the relying party ID. Nobody knows the origin ("https://www.mindrot.org") until it appears as the output of the webauthn credential request as part of the clientData.


Scott C Wang

[0] https://chromium.googlesource.com/chromium/src/+/refs/heads/main/content/browser/webauth/client_data_json.cc#146



From: Damien Miller <djm@mindrot.org>
Sent: 11 January 2022 16:33
To: Scott C Wang <wangsc@cs.wisc.edu>
Cc: openssh-unix-dev@mindrot.org <openssh-unix-dev@mindrot.org>
Subject: Re: webauthn signatures: SecurityKeyProvider, json parsing
?
On Tue, 11 Jan 2022, Scott C Wang wrote:

> Damien, thanks for clarifying.
>
> (1 SecurityKeyProvider)
>
> I don't have a FIDO security key, but I do have an Android phone, and
> the Android phone can act as a webauthn key via Google Chrome. So
> these were the shower thoughts I had for getting this to work.
>
> I implement a SecurityKeyProvider that prints a https URL upon
> sk_sign. I open this URL in Google Chrome. The script on the page
> calls the webauthn authentication API; Google Chrome prompts
> me to choose an authentication method, and I pick my phone.
> Authenticating my fingerprint on my phone yields a webauthn signature
> to the script, which POSTs the signature, origin, clientData, and
> extensions back to the same URL. The SecurityKeyProvider polls
> the URL (or some endpoint) until the signature arrives, which it
> returns, along with the origin, clientData, and extensions, to the
> OpenSSH client. The OpenSSH client now has what it needs to pack a
> "webauthn-sk-ecdsa-sha2-nistp256@openssh.com" signature message, all
> of which the OpenSSH server currently already supports validating.
>
> More generally, this one SecurityKeyProvider implementation would be
> able to bridge the OpenSSH client's security key authentication to any
> platform running a web browser exposing the webauthn API.
>
> I've only given preliminary thought to this as yet -- have I gone mad?

No, I've wondered about the same thing too :)

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. AFAIK clientData is
prepared from origin, extensions and H(message), so there's not need
to pass that explicitly.

That just leaves signalling that the signer wants an origin rather
than a bare application, and signalling back from the signer that the
signature should be packed as a webauthn one.

Am I missing anything? (I apologise for forgetting most of the details
since I implemented webauthn in OpenSSH)

> (2 json key order) Perfect! Very prudent.
>
> (3 mindrot.org) Excellent, thank you for the link. (I was trying
> /webauthn.html, but hadn't thought to try /webauthn.) Perhaps
> the hardcoded "mindrot.org" relying party can be changed to
> window.location.host, so that the standalone page can be hosted
> without modification on anyone's domain.

good idea - done.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: webauthn signatures: SecurityKeyProvider, json parsing [ In reply to ]
Thanks! Indeed, Brian and Kevin are right, the user experience does resemble OIDC. Besides Brian's suggestion of HashiCorp Vault, I've also heard of Smallstep, which are great out-of-the-box solutions. And, to Peter's point, OIDC is significantly more complex than what I came up with ....

Having said that, there is only one user logging into this homelab machine, so OIDC would be a bit overkill for now :) Eventually, the homelab will expand, whereupon I'll definitely put OIDC in front of ssh and other services besides.

In any case, in this thread I really only wanted to probe the potential of OpenSSH's webauthn support -- there isn't actually an acute problem I need to solve apart from playing with this ball of yarn for a bit.


Scott C Wang


From: openssh-unix-dev <openssh-unix-dev-bounces+wangsc=cs.wisc.edu@mindrot.org> on behalf of Brian Candler <b.candler@pobox.com>
Sent: 11 January 2022 13:24
To: openssh-unix-dev@mindrot.org <openssh-unix-dev@mindrot.org>
Subject: Re: webauthn signatures: SecurityKeyProvider, json parsing
?
On 11/01/2022 18:52, Fox, Kevin M wrote:
> Sounds kind of like oidc but with webauthn switched out for some of the plumbing. Would straight up oidc work cleaner for your use case? You can still use all sorts of authentication methods like fingerprints with it.

You can also trade an OIDC login for an SSH certificate, using Hashicorp
Vault (amongst other solutions)

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: webauthn signatures: SecurityKeyProvider, json parsing [ In reply to ]
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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: webauthn signatures: SecurityKeyProvider, json parsing [ In reply to ]
> 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@mindrot.org>
Sent: 12 January 2022 17:00
To: Scott C Wang <wangsc@cs.wisc.edu>
Cc: openssh-unix-dev@mindrot.org <openssh-unix-dev@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@mindrot.org>
Sent: 12 January 2022 17:00
To: Scott C Wang <wangsc@cs.wisc.edu>
Cc: openssh-unix-dev@mindrot.org <openssh-unix-dev@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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev