Bug 204111 – [WebAuthn] User Verification (UV) option present on a CTAP2 authenticatorMakeCredential while the authenticator has not advertised support for it

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

The latest public FIDO2 CTAP spec mandates authenticators to terminate any ongoing procedures with CTAP2_ERR_UNSUPPORTED_OPTION if any of the options passed are not supported by the authenticator. In this case, a CTAP2 authenticatorMakeCredential from Safari sets the UV option to FALSE even if the authenticator never advertised support for it in authenticatorGetInfo response. The expected behavior here would be to not include the UV option at all since it is not supported (and not set it to FALSE or TRUE). See chapter 5.3 in latest FIDO2 CTAP spec, step 3 in the procedure of authenticatorMakeCredential and step 5 in the procedure for authenticatorGetAssertion. Please note, that the above is applicable to the authenticatorGetAssertion requests as well.

Latest public spec: https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html

[login Llama]

It seems bug (198408) has landed in iOS 13.3.1 and for desktop.

Good but that makes this bug much worse.  

Now almost no CTAP 2 keys are working, unless they support builtin UV. 

I have tested that and they work. 

There are some authenticators that for whatever reason don't properly check like some of the early Yubico 5ci with software 5.2.3.  All of the shipping ones with 5.2.4 fail to work with Safari because of this bug.  I tested other CTAP 2 authenticators and they also don't work almost certainly for the same reason.

So basically all CTAP2 authenticators without built in UV are currently broken.

[Radar WebKit Bug Importer]

<rdar://problem/58342561>

[Jiewen Tan]

<rdar://problem/57019604>

[Jiewen Tan]

Created attachment 387887 [details]
Patch

[Brent Fulgham]

Comment on attachment 387887 [details]
Patch

r=me

[Jiewen Tan]

Comment on attachment 387887 [details]
Patch

Thanks Brent for r+ the patch.

[WebKit Commit Bot]

Comment on attachment 387887 [details]
Patch

Clearing flags on attachment: 387887

Committed r254710: <https://trac.webkit.org/changeset/254710>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Jiewen Tan]

(In reply to kostas from comment #0)
> The latest public FIDO2 CTAP spec mandates authenticators to terminate any
> ongoing procedures with CTAP2_ERR_UNSUPPORTED_OPTION if any of the options
> passed are not supported by the authenticator. In this case, a CTAP2
> authenticatorMakeCredential from Safari sets the UV option to FALSE even if
> the authenticator never advertised support for it in authenticatorGetInfo
> response. The expected behavior here would be to not include the UV option
> at all since it is not supported (and not set it to FALSE or TRUE). See
> chapter 5.3 in latest FIDO2 CTAP spec, step 3 in the procedure of
> authenticatorMakeCredential and step 5 in the procedure for
> authenticatorGetAssertion. Please note, that the above is applicable to the
> authenticatorGetAssertion requests as well.
> 
> Latest public spec:
> https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-
> authenticator-protocol-v2.0-ps-20190130.html

Thanks for reporting the issue, please follow our STP release to verify the fix or you could use our nightly to do that.

[login Llama]

Thanks Jiewen

When will this land in the STP?

I think Kostas is on vacation, and I am traveling but will have a computer to test on Monday.

I will let you know once I can test.

[Jiewen Tan]

(In reply to login Llama from comment #10)
> Thanks Jiewen
> 
> When will this land in the STP?
> 
> I think Kostas is on vacation, and I am traveling but will have a computer
> to test on Monday.
> 
> I will let you know once I can test.

Even for (In reply to login Llama from comment #10)
> Thanks Jiewen
> 
> When will this land in the STP?
> 
> I think Kostas is on vacation, and I am traveling but will have a computer
> to test on Monday.
> 
> I will let you know once I can test.

Sorry, even for STP, we don't usually comment on its future release. But you can definitely follow webkit.org's release note to see if the next one contains the fix.

[login Llama]

I tested with build 254850 from today.

The UV bug for make credential seems to be fixed.

For Get Assertion I am still seeing a problem.

Is there any debugging like Chrome's chrome://device-log/ That will let me see the messages?

[login Llama]

If option clientPin=0 then it works for makeCradential and getAssertion.

If clientPin=1 then both makeCradential and getAssertion fail.

I expect that for makeCredential because pintoken is required to be able to make the credential over CTAP2.

getAssertion should work as long as WebAuthn has UV unset or discouraged.

Given I cant see the cbor message going to the authenticator I cant say if this is the same bug or another one related to Pin triggered when getInfo contains clientPin=1.

[Jiewen Tan]

(In reply to login Llama from comment #13)
> If option clientPin=0 then it works for makeCradential and getAssertion.
> 
> If clientPin=1 then both makeCradential and getAssertion fail.
> 
> I expect that for makeCredential because pintoken is required to be able to
> make the credential over CTAP2.
> 
> getAssertion should work as long as WebAuthn has UV unset or discouraged.
> 
> Given I cant see the cbor message going to the authenticator I cant say if
> this is the same bug or another one related to Pin triggered when getInfo
> contains clientPin=1.

It should be a bug about our immature ClientPIN support. Bug 206547.

[login Llama]

While there may be a pin bug, I don't think this is that.

I modified a authenticator to ignore the extra UV option in the request and that works for getAssertion with no "uv" option advertised in getInfo and clientPin=1

I think there is still a bug with getAssertion.  Are you perhaps sending options with uv=0 for iterating through the allow list or something?

[Jiewen Tan]

(In reply to login Llama from comment #15)
> While there may be a pin bug, I don't think this is that.
> 
> I modified a authenticator to ignore the extra UV option in the request and
> that works for getAssertion with no "uv" option advertised in getInfo and
> clientPin=1
> 
> I think there is still a bug with getAssertion.  Are you perhaps sending
> options with uv=0 for iterating through the allow list or something?

Maybe you could tell me the model of the key you are using and the parameters you pass to the API? So, I can try to reproduce the bug. Otherwise, I'm not seeing any problems with our current code.

[login Llama]

I think I must have just been having trouble with the version from the build archives.

STP 99 with webkit 15610 seems to be working fine.

With and without pin configured as long as you don't send UV required.

Thanks big improvement in STP 99

[Jiewen Tan]

(In reply to login Llama from comment #17)
> I think I must have just been having trouble with the version from the build
> archives.
> 
> STP 99 with webkit 15610 seems to be working fine.
> 
> With and without pin configured as long as you don't send UV required.
> 
> Thanks big improvement in STP 99

I don't think STP 99 contains this fix. It will be great if you could redo your test with the next one, which will probably have the fix.