openssh unix dev - Jan 2022 - webauthn signatures: SecurityKeyProvider, json parsing

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 at
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 at mindrot.org>
Sent: 11 January 2022 00:32
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 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 at
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 at 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

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

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