[Webkit-unassigned] [Bug 220415] New: [WebAuthn] Safari ignores maxMsgSize in Message encoding

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=220415

            Bug ID: 220415
           Summary: [WebAuthn] Safari ignores maxMsgSize in Message
                    encoding
           Product: WebKit
           Version: Safari Technology Preview
          Hardware: iPhone / iPad
                OS: iOS 14
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebCore Misc.
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: loginllama at gmail.com

The problem can be reproduced on https://webauthntest.azurewebsites.net/ or other test pages by registering 12 or more credential ID with authenticator A, then register Authenticator B (Registration can be done on any platform.) Tests were done with a Yubikey 5 NFC, other keys will behave the same but may have different sized credentialID and or transport buffers.

On iOS use Authenticator B to authenticate via NFC tap.

The encoded request will be larger than the 1200byte maxMsgSize supported by a YubiKey

The authenticator will appear unresponsive.  

Over NFC the authenticator will return a NFC layer error SW_DATA_INVALID.  iOS is not capturing that error and continues to wait for a response.

Over USB the behavior is harder to debug. 
Due to transport differences a CTAP error is returned TAP1_ERR_INVALID_LENGTH after the first APDU is received. 

iOS seems to continue sending APDU but eventually stops and retries using CTAP1/U2F commands if user verification is set to discouraged at the WebAuthn level.


If we look at Message encoding https://fidoalliance.org/specs/fido-v2.1-rd-20201208/fido-client-to-authenticator-protocol-v2.1-rd-20201208.html#message-encoding
The platform needs to look at maxMsgSize and not send larger messages.  

The current code clearly breaks over NFC with a large allow list and over USB with a large allow list if user verification is required.

In get Assertion 6.2.1 https://fidoalliance.org/specs/fido-v2.1-rd-20201208/fido-client-to-authenticator-protocol-v2.1-rd-20201208.html#sctn-getAssert-platf-actions step 1.1 pre-flight is discussed as a way to process large allow lists. 

The getInfo maxCredentialCountInList (0x07) and maxCredentialIdLength (0x08) should be used to filter the allow list and batch credentalID into requests with PinTokens to step through the allow list rather than falling back to U2F. 

This has been seen to be a problem over NFC with Google Advanced Protection accounts when multiple authenticators are registered.  As Google sends uv discouraged authentication the U2F fallback works for those accounts over USB. 

There are other sites that set user verification preferred or required in WebAtuthn, those sites will break over both NFC and USB if the allowlist is too large.

In the short term over NFC you could try immediately falling back to U2F if the allow list size would cause a request to be too large.  

The correct long term solution is to refactor the code to properly deal with large allow and exclude lists, using the information in getInfo.

I hope the additional platform info in CTAP2.1 can help explain things.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210107/b0b42202/attachment-0001.htm>