Bug 207951 - [WebAuthn] Yubikey 5ci lightning does not work in iOS 13.4 beta
Summary: [WebAuthn] Yubikey 5ci lightning does not work in iOS 13.4 beta
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: Other
Hardware: iPhone / iPad iOS 13
: P2 Major
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 181943
  Show dependency treegraph
 
Reported: 2020-02-19 11:03 PST by sweeden
Modified: 2020-02-19 21:16 PST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sweeden 2020-02-19 11:03:21 PST
In testing WebAuthn on iOS 13.4 beta with an iPad Air 2 using a Yubikey 5ci authenticator, I used the WebAuthn parameters for requireResidentKey: false, userVerification: discouraged. The lightning key did NOT blink when performing a registration operation. The key does blink (and can be used) with the same parameters on the same device using iOS 13.3.1 (although there is a different problem with the AAGUID in the attestation result in that version).
Comment 1 Jiewen Tan 2020-02-19 12:21:51 PST
(In reply to sweeden from comment #0)
> In testing WebAuthn on iOS 13.4 beta with an iPad Air 2 using a Yubikey 5ci
> authenticator, I used the WebAuthn parameters for requireResidentKey: false,
> userVerification: discouraged. The lightning key did NOT blink when
> performing a registration operation. The key does blink (and can be used)
> with the same parameters on the same device using iOS 13.3.1 (although there
> is a different problem with the AAGUID in the attestation result in that
> version).

Could you tell me the exact beta version like: 17E5233g? BTW, we release beta 2 today, can you try that as well?
Comment 2 Jiewen Tan 2020-02-19 12:26:10 PST
It is probably a duplicate of Bug 204111, which is fixed in Beta 2.
Comment 3 sweeden 2020-02-19 15:51:41 PST
I just installed 13.4 beta 2. Same behaviour. Key does not blink at all when registering with the following options:

{
      "extensions": {},
      "attestation": "direct",
      "challenge": "9MmAkj8jroow3kq_gKb5jjs8YjSA9jgMk-YXb86Xxj8",
      "authenticatorSelection": {
        "userVerification": "discouraged",
        "requireResidentKey": false
      },
      "user": {
        "displayName": "REDACTED",
        "name": "REDACTED",
        "id": "k-rsnTR5Q6CWAmU_VMwjeA"
      },
      "rp": {
        "name": "fidointerop.securitypoc.com",
        "id": "fidointerop.securitypoc.com"
      },
      "timeout": 60000,
      "pubKeyCredParams": [
        {
          "type": "public-key",
          "alg": -7
        },
        {
          "type": "public-key",
          "alg": -257
        }
      ]
    }
Comment 4 sweeden 2020-02-19 15:56:09 PST
The beta 2 build as you suggested is 17E5233g
Comment 5 sweeden 2020-02-19 16:18:32 PST
Ok so more details. I got *another* Yubikey 5ci brand new and it worked. I think the defining difference is the yubikey that did not work had a PIN set whereas the one that did work did NOT have a PIN set.

Not sure why that should make any difference when uv=discouraged is set in options...
Comment 6 Jiewen Tan 2020-02-19 16:38:54 PST
(In reply to sweeden from comment #5)
> Ok so more details. I got *another* Yubikey 5ci brand new and it worked. I
> think the defining difference is the yubikey that did not work had a PIN set
> whereas the one that did work did NOT have a PIN set.
> 
> Not sure why that should make any difference when uv=discouraged is set in
> options...

Alright then. Can you please try STP 101 which should have the fix for Bug 206547? I will close this bug as "configuration changed". Feel free to reopen it if you still see your issues on STP 101.
Comment 7 Jiewen Tan 2020-02-19 16:46:28 PST
(In reply to Jiewen Tan from comment #6)
> (In reply to sweeden from comment #5)
> > Ok so more details. I got *another* Yubikey 5ci brand new and it worked. I
> > think the defining difference is the yubikey that did not work had a PIN set
> > whereas the one that did work did NOT have a PIN set.
> > 
> > Not sure why that should make any difference when uv=discouraged is set in
> > options...
> 
> Alright then. Can you please try STP 101 which should have the fix for Bug
> 206547? I will close this bug as "configuration changed". Feel free to
> reopen it if you still see your issues on STP 101.

Actually, I'm wrong. You are talking about registrations. According to CTAP2 authenticatorMakeCredential Step 6:
"If pinAuth parameter is not present and clientPin been set on the authenticator, return CTAP2_ERR_PIN_REQUIRED error."

Link here:
https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#authenticatorMakeCredential

Yes, if your authenticator has a PIN, registrations won't work.
Comment 8 sweeden 2020-02-19 18:54:16 PST
Is it reasonable to conclude that the reason my key stopped working for registration between 13.3.1 and 13.4 is that Safari is moving from CTAP1 to CTAP2?

When using CTAP1 / U2F attestation, the presence or absence of the PIN would have been irrelevant. This is no longer the case with CTAP2.
Comment 9 Jiewen Tan 2020-02-19 19:03:39 PST
(In reply to sweeden from comment #8)
> Is it reasonable to conclude that the reason my key stopped working for
> registration between 13.3.1 and 13.4 is that Safari is moving from CTAP1 to
> CTAP2?
> 
> When using CTAP1 / U2F attestation, the presence or absence of the PIN would
> have been irrelevant. This is no longer the case with CTAP2.

That's probably not accurate. WebKit should always prefer CTAP2 if it is available. There was a bug that WebKit doesn't recognize authenticator that supports more than 2 protocols, and treat them all like U2F.
Comment 10 sweeden 2020-02-19 19:23:35 PST
Ok thanks for letting me know. I am fine with leaving this one closed for now with an understanding that PIN-based authenticators simply are not yet supported.
Comment 11 sweeden 2020-02-19 19:39:43 PST
Hmm - one additional question on this. When I use Chrome and set rk=false, uv=discouraged, I am not prompted for a PIN even if one is set on the authenticator, and I am able to register and get a fido2-u2f attestation. I guess with this combination of flags, Chrome is falling back to CTAP1. As soon as I change uv=preferred, then I get PIN prompt, plus I get a CTAP2 packed attestation format.

This is not the case with WebKit. Is this a bug, or just a different interpretation of how to map webauthn parameters to CTAP?
Comment 12 Jiewen Tan 2020-02-19 21:16:48 PST
(In reply to sweeden from comment #11)
> Hmm - one additional question on this. When I use Chrome and set rk=false,
> uv=discouraged, I am not prompted for a PIN even if one is set on the
> authenticator, and I am able to register and get a fido2-u2f attestation. I
> guess with this combination of flags, Chrome is falling back to CTAP1. As
> soon as I change uv=preferred, then I get PIN prompt, plus I get a CTAP2
> packed attestation format.
> 
> This is not the case with WebKit. Is this a bug, or just a different
> interpretation of how to map webauthn parameters to CTAP?

Probably later, I don't think the CTAP 2.0 spec has specified such a fallback.