getPinUvAuthTokenUsingPinWithPermissions if no clientPin option

[YoHidden]

Hi all,

I am now implementing FIDO 2.1 spec, so now running FIDO Conformance Tools v1.7.20-4 || CTAP2.1 - MDS3.

The metadata statement in the tool says this in the extension & options fields of authenticatorGetInfo:

     "extensions": [
      "credProtect",
      "hmac-secret"
     ],

     "options": {
        "up": true,
        "uv": true,
        "pinUvAuthToken": true,
        "makeCredUvNotRqd": true,
        "noMcGaPermissionsWithClientPin": true
     },

My authenticator returns this in the options field of the authenticatorGetInfo:

2: ["hmac-secret", "credProtect"], 

4: {
"up": true,
"uv": true,
"pinUvAuthToken": true,
"makeCredUvNotRqd": true,
"noMcGaPermissionsWithClientPin": true
},

 I have checked the mandatory features as stated in chapter 9 and, since my authenticator uses ONLY non-discoverable credentials ('rk' is absent, so false by default), these mandatory features for me implies:  

- 'hmac-secret' is implemented

- 'clientPin' is absent (as you can see in the info above) and 'uv' is true

-  'credMgmt' is absent (since 'rk' is false)

- 'credProtect' is implemented

- 'pinUvAuthToken' is true sice 'uv' is also true

- 'pinUvAuthProtocol'  has value 2 (and it's implemented)

When running the conformance test for ClientPin protocol 2, it passes ok the first tests for subcommands getKeyAgreement, setPin, changePin and getPinToken. But then it calls subcommand getPinUvAuthTokenUsingPinWithPermissions which is NOT mandatory since 'clientPin' is false. I have even added a first processing for this subcommand and return CTAP2_ERR_UNAUTHORIZED_PERMISSION as stated on section 6.5.5.7.2, point 4.4. But still the test tool returns a non-expected error (it was expecting this command to be succesfull).

So, am I missing something in the expected configuration or is this a tool bug?

Thanks.

[YoHidden]

Moreover, I have temporarily added the support for this subcommand getPinUvAuthTokenUsingPinWithPermissions just to try to get rid of the test tool failure at this point, but now I have encountered two additional inconsistencies with the spec (from my point of view).

At the beginning of the section titled "Authr-ClientPin2-GetPinUvAuthTokenUsingPinWithPermissions Test authenticatorClientPin(0x06), of version 0x02 support of getPinUvAuthTokenUsingPinWithPermissions(0x09) commands" I have detected that the subcommand being sent is invalid but the test expects it to succeed. And this happens twice. 

The first invalid subcommand 0x09 has the following content (this is the actual data being received by the authenticator):

6, 

{

   1: 2, 

   2: 9, 

   3: {

      1: 2, 

      3: -25, 

      -1: 1, 

      -2: h'EAC4B8E3FA032D36FEB8B95224E73945AF16057DDC1F2303DF61905636663D1E', 

      -3: h'7D382128A0241CC7D1D43BFD187742D5D013C678302B92541443B6B4C58902E2'

   }, 

   6: h'B083AB994A36DF7EDF5E2A8F34BF1247996A4CF99247EF885FB22BCE896D2150', 

   9: 0, 

   10: "plumporter.gi"

}

so the permissions input (item 9) is 0, and the command MUST be rejected with code CTAP1_ERR_INVALID_PARAMETER. (as stated in 6.5.5.7.2 - point 3.4.3). The authenticator is properly rejecting the command, but the test tool expects the return to be a success and, therefore, marks the test as failed.

The second one is:

6, 

{

   1: 2, 

   2: 9, 

   3: {

      1: 2, 

      3: -25, 

      -1: 1, 

      -2: h'800F4535297B429151A9A828E290D885F510E95C074CFF641B4F75754F484833', 

      -3: h'10BEC7145C9603D6FF90224D1A3C46A651A240408501B196004D6218DF51276C'

   }, 

   6: h'0BCCEE851AC8AB4EB5CB7D3A3A34A846FA0968038F9E9E156E79C42A30055F13', 

   9: 1, 

   10: "successfulburst.de"

}

so the permissions input now is 1 (for makeCredential). However, as you can see in the response to the authenticatorGetInfo command I included in my previous post, I am using option noMcGaPermissionsWithClientPin as true. So, as stated in 6.5.5.7.2 - point 3.4.4, this command MUST be rejected with code CTAP2_ERR_UNAUTHORIZED_PERMISSION, and so is doing the authenticator. But, again, the test tool expectes the command to succeed and, therefore, marks ths test as failed.

By the way, I have no major interest in using this option noMcGaPermissionsWithClientPin, I just included it as a way of avoiding the use of this subcommand 0x09 by the test tool (which obviously didn't work).

Please, can you provided clarification about the use of this subcommands in an authenticator with a configuration  as shown in my previous post ? Is this a tool bug or am I missing something?

Thanks.

[YoHidden]

...and, by the way, after the failure of these 2 tests, every further test in this section fails with CTAP2_ERR_PIN_AUTH_INVALID.

El viernes, 26 de julio de 2024 a las 10:57:22 UTC+1, YoHidden escribió: