Test “P-10” of the FIDO Conformance Tool mentions the following [sic]:
Send a valid MakeCredential request, and check that authenticator returns CTAPHID_KEEPALIVE(0x3B) while its waiting for user action.
Send CTAPHID_CANCEL(0x11) and check that authenticator responds with CTAPHID_CBOR(0x90) with error code CTAP2_ERR_KEEPALIVE_CANCEL(0x2D).
Send another CTAPHID_CANCEL(0x11) and check that authenticator does not respond with anything
The test is implemented in a way where a FIDO authenticatorMakeCredential request is sent to the authenticator, followed by a HID cancel request. If the response is anything but CTAP2_ERR_KEEPALIVE_CANCEL(0x2D), the test will fail.
On some authenticators, an authenticatorMakeCredential request waiting for user interaction (be that touch or fingerprint match) requires a roundtrip to the fingerprint sensor, which translates to having to relay messages through additional chips. This operation takes some time, potentially greater than 100 ms, which may be greater than the specification mandated keep-alive time of 100 ms. As a consequence of this, one or more keep-alive messages are scheduled before the HID cancel operation is completed and the CTAP2_ERR_KEEPALIVE_CANCEL(0x2D) response is sent out.
As mentioned above, the first response after a HID cancel request must be CTAP2_ERR_KEEPALIVE_CANCEL(0x2D) for the test to pass.
To the best of our knowledge, the FIDO CTAP2 specification doesn’t disallow responding with keep-alive messages while a HID cancel request is being processed.
We argue that the test logic is flawed and suggest that it be changed to allow for either a response to the HID cancel request, or as many valid (i.e. with any allowed status code) keep-alive messages as necessary until the cancel request has been fully processed.
The keep-alive messages are required to keep the channel open until the HID cancel request response is received.
nuno0529
commented
3 weeks ago
By submitting this issue you are acknowledging that any information regarding this issue will be publicly available.
If you have privacy concerns, please email conformance-tools@fidoalliance.org
FIRST PRE CHECK
What protocol are you implementing?
NOTE: UAF 1.0 certification have been officially sunset. U2F 1.2 only supported version of U2F.
What is your implementation class?
If you are platform authenticator vendor, please email conformance-tools@fidoalliance.org
What is the version of the tool are you using?
1.7.20.3
What is the OS and the version are you running?
For desktop tools
For UAF mobile tools
Issue description
Test “P-10” of the FIDO Conformance Tool mentions the following [sic]:
Send a valid MakeCredential request, and check that authenticator returns CTAPHID_KEEPALIVE(0x3B) while its waiting for user action.
Send CTAPHID_CANCEL(0x11) and check that authenticator responds with CTAPHID_CBOR(0x90) with error code CTAP2_ERR_KEEPALIVE_CANCEL(0x2D).
Send another CTAPHID_CANCEL(0x11) and check that authenticator does not respond with anything
The test is implemented in a way where a FIDO authenticatorMakeCredential request is sent to the authenticator, followed by a HID cancel request. If the response is anything but CTAP2_ERR_KEEPALIVE_CANCEL(0x2D), the test will fail.
On some authenticators, an authenticatorMakeCredential request waiting for user interaction (be that touch or fingerprint match) requires a roundtrip to the fingerprint sensor, which translates to having to relay messages through additional chips. This operation takes some time, potentially greater than 100 ms, which may be greater than the specification mandated keep-alive time of 100 ms. As a consequence of this, one or more keep-alive messages are scheduled before the HID cancel operation is completed and the CTAP2_ERR_KEEPALIVE_CANCEL(0x2D) response is sent out.
As mentioned above, the first response after a HID cancel request must be CTAP2_ERR_KEEPALIVE_CANCEL(0x2D) for the test to pass.
To the best of our knowledge, the FIDO CTAP2 specification doesn’t disallow responding with keep-alive messages while a HID cancel request is being processed.
We argue that the test logic is flawed and suggest that it be changed to allow for either a response to the HID cancel request, or as many valid (i.e. with any allowed status code) keep-alive messages as necessary until the cancel request has been fully processed.
The keep-alive messages are required to keep the channel open until the HID cancel request response is received.