Bug 207951 – [WebAuthn] Yubikey 5ci lightning does not work in iOS 13.4 beta

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: New Bugs

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

[Jiewen Tan]

(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?

[Jiewen Tan]

It is probably a duplicate of Bug 204111, which is fixed in Beta 2.

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
        }
      ]
    }

The beta 2 build as you suggested is 17E5233g

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

[Jiewen Tan]

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

[Jiewen Tan]

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

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.

[Jiewen Tan]

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

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.

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?

[Jiewen Tan]

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