Tool fails test when authenticatorReset returns a CTAP2_ERR_NOT_ALLOWED

[Molyna]

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

• [X] I SOLEMNLY SWEAR THAT I HAVE SEARCHED DOCUMENTATION AND WAS NOT ABLE TO RESOLVE MY ISSUE

What protocol are you implementing?

• [ ] FIDO2 Server
• [ ] CTAP2.0
• [X] CTAP2.1
• [ ] UAF 1.1
• [ ] U2F 1.1
• [ ] U2F 1.2

NOTE: UAF 1.0 certification have been officially sunset. U2F 1.2 only supported version of U2F.

What is your implementation class?

• [X] Security Key / FIDO2 / U2F authenticators
• [ ] Server
• [ ] UAF Client-ASM-Authenticator combo
• [ ] UAF Client
• [ ] UAF ASM-Authenticator

If you are platform authenticator vendor, please email conformance-tools@fidoalliance.org

What is the version of the tool are you using?

1.7.17

What is the OS and the version are you running?

For desktop tools

• [ ] OSX
• [x] Windows
• [ ] Linux

For UAF mobile tools

• [ ] iOS
• [ ] Android

Issue description

When starting the tests they will fail fairly fast when a reset command returns CTAP2_ERR_NOT_ALLOWED. Part of the 2.1 Specification for Reset says

Additionally:

In order to prevent an accidental triggering of this mechanism, evidence of user interaction is required.

In case of authenticators with no display, request MUST have come to the authenticator within 10 seconds of powering up of the authenticator.

If all conditions are met, authenticator returns CTAP2_OK. If this command is disabled for the transport used, the authenticator returns CTAP2_ERR_OPERATION_DENIED. If user presence is explicitly denied, the authenticator returns CTAP2_ERR_OPERATION_DENIED. If a user action timeout occurs, the authenticator returns CTAP2_ERR_USER_ACTION_TIMEOUT. If the request comes after 10 seconds of powering up, the authenticator returns CTAP2_ERR_NOT_ALLOWED.

So expectation would be that the tests demand a reboot of the device when CTAP2_ERR_NOT_ALLOWED is returned from reset.

[iirachek]

Current implementation of the tests operates on an assumption that once the dialog about requiring reset is shown, the authenticator gets power cycled before continuing. Easy to do for HID authenticators, but may be troublesome in case of BLE to time it correctly.

I'll see if its possible to retry the reset procedure when it fails due to CTAP2_ERR_NOT_ALLOWED instead of outright failing tests.

[Molyna]

Not sure how easy it would be. Power reset on BLE is in general quite cumbersome in how much time it takes as it needs to redo the connection as well. We have in general had big issues with the ClientPin tests for example triggering timeout as they on average take about 55 seconds. So doing a power cycle would probably need to include a pause in the test running similar to ClientPin with a popup, but it might also require longer timeout then.

[iirachek]

The solution is currently being worked on, and there are some ideas for ways to improve the experience. Unfortunately, it will take a bit more time, so it won't be ready for the next 1.7.18 version.

[iirachek]

Improvements regarding this were introduced in the latest 1.7.19 version.

Should the reset operation return the CTAP2_ERR_NOT_ALLOWED code, you will be prompted with a popup dialog to retry it without failing a test. Hitting this dialog will also slightly increase the timeout.

This is only the case for CTAP2_ERR_NOT_ALLOWED. Other error codes will still cause a fail as usual.

[Molyna]

Ran a full BLE test, the Reset test category fails with 0x30 as it takes more than 10 seconds from boot. Otherwise all works with the fix.

[iirachek]

the Reset test category fails with 0x30 as it takes more than 10 seconds from boot.

Accidentally missed this block of tests. Should work properly in the latest 1.7.19-1 version.