Clarification for User Verification in GetAssertion, potential mismatches in CTAP2 standard

[Antoine FERRON [BitLogiK]]

Designing a CTAP2 software on secure chip, we don't clearly understand the UserVerified flag in the GetAssertion part of CTAP2 standard. This provides mixed directions, so we need some explanations and debunking around theses specific points.

In the GetAssertion directives ( §5.2 ) :

- "uv" option in request : Instructs the authenticator to require a gesture that verifies the user to complete the request.

- If the "uv" option was specified and set to true :
If device doesn’t support user-identifiable gestures, return the CTAP2_ERR_UNSUPPORTED_OPTION error.

- User identifiable information (name, DisplayName, icon) MUST not be returned [in the user part of the authenticator response] if user verification is not done by the authenticator.

In the provided GetAssertion Example 5 ( §6.1 ) :

The command has the uv:true option, then the authenticator responds with a "01" data flag, means UV=false, and then provides all user data.

In case the authenticator doesn't support "uv", it must report UNSUPPORTED_OPTION error. Does that means in the example case, the authr supports uv but didn't verified the user this single time? Still the example request instructed "the authenticator to require a gesture that verifies the user".

If uv is not done by the authenticator, user data must not be provided in the answer back.Maybe the command with "uv:true" falls in the "uv done by authr" case, the authr can in this case answer the user data part, even if no uv is actually done. This is assuming there no discrepancy in the standard.

Additionally, in one of the testing software we are using to test our CTAP2 implementation (a robust one, not the tool provided by the FIDO alliance), one of the test performed is to test if user credential and numberOfCredentials are indeed absent, when the GetAssertion query is "simple (no option).

Our understanding is that the case a "uv:true" with a uv=0 answer is not possible. Also, when uv=0 response, 0x04 user data shall not be part of the response.

The uv:true command force the authr to get a user verification. Then either the authr can't perform uv and shall answer ERR_UNSUPPORTED_OPTION, or it can do it and answer with the uv flag =1 and the user 0x04 data. There's also a 3rd possibility where the uv on the authr fails and it responds ERR_OPERATION DENIED (user verification failed).

To our understanding, there's no way an authr following the standard can respond uv=0 with 0x04 user data following a uv:true GetAssertion command.

We hope some people aware of the CTAP standard can clarify all these, eventually making some fixes in the standard or in the examples provided.

[Tshimangadzo Ndou]

thank you so much

T.ndou

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/14ce3f99-83c8-49a5-aee8-7ccc5a1aeef8%40fidoalliance.org.

[Fabian Henneke]

Disclaimer: I am also not a FIDO Alliance member, but have implemented an authenticator with internal UV.

I believe your understanding of the spec to be entirely correct here. The examples seem to be meant mostly as references for the CBOR serialization of particular requests and responses.

That a request with UV requested cannot be answered with a uv=0 assertion is implicitly confirmed here: https://github.com/w3c/webauthn/pull/1313#discussion_r335412622 (note that an authenticator with support for UV cannot distinguish between whether the RP labeled UV as "required" or "preferred", as both will result in a CTAP request with UV=true).

The question whether user information can be returned without UV having been performed seems to be clearly answered by the CTAP 2 spec. I find it very likely that the example only includes user info in order to show how it is serialized.
Note though that if this is indeed the correct understanding, then the FIDO Conformance Tools suffer from a bug: They expect authenticators with UV support to return user information even for requests without UV, but do not do so for clientPIN (see https://github.com/fido-alliance/conformance-tools-issues/issues/528, which has been closed without a fix). Unfortunately, I do not have access to a FIDO Certified authenticator with internal UV.

[ALI EBU EL-HASANAIN]

[Thomas Duboucher]

Hi Antoine,

I'm pretty sure this is indeed a typo in the example, as confirmed by
the WebAuthn specification. The authData flags should be indeed 04h or 05h.

> If user verification is required for this assertion, verify that the
> User Verified bit of the flags in authData is set.

I don't know which other tool you are using for testing, but user (04h)
MAY be returned even with uv = false (default). It simply SHALL NOT
include identifying information (name, displayName and icon keys).
Actually, this is even needed for a very abstruse use case.

Regards,

Le 13/02/2020 à 12:01, Antoine FERRON [BitLogiK] a écrit :
> Designing a CTAP2 software on secure chip, we don't clearly understand
> the UserVerified flag in the GetAssertion part of CTAP2 standard. This
> provides mixed directions, so we need some explanations and debunking
> around theses specific points.
>
> In the GetAssertion directives ( §5.2 ) :
>
> - "uv" option in request : Instructs the authenticator to require a
> gesture that verifies the user to complete the request.
>
> - If the "uv" option was specified and set to true :
> If device doesn’t support user-identifiable gestures, return the
> CTAP2_ERR_UNSUPPORTED_OPTION error.
>
> - User identifiable information (name, DisplayName, icon) MUST not be

> returned [in the /user /part of the authenticator response] if user

--
Thomas Duboucher