F-1 Send a valid CTAP2 command HMAC extension should allow for both boolean and map

[ve7jtb]

By submitting this issue you are acknowledging that any information regarding this issue will be publicly available.

If you have privacy concerns, please email [email protected]

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
• [ x] 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 [email protected]

What is the version of the tool are you using?

1.7.19-1

What is the OS and the version are you running?

For desktop tools

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

For UAF mobile tools

• iOS
• Android

Issue description

F-1 Send a valid CTAP2 authenticatorMakeCredential(0x01) message, "extensions" containg "hmac-secret" set to a random type, wait for the response, and check that Authenticator returns an error

The problem is that the random types include map. That is a valid type for the extension.
The confusion is that hmac-secret has two valid types boolean used on get and map used on make.
So hmac-secret with a type of map sent on a makeCredential is not supported, and the spec requires ignoring unsupported extensions.

Not ignoring unsupported extensions would be an interoperability problem. Ignoring is the correct thing.
This is probably causing what look like random errors in the tool to testors.

if(!hmacSecretSupported)
this.skip();
return refreshPUAT()
.then(() => {
let makeCredStruct = generateGoodCTAP2MakeCredential(pinUvAuthToken, pinUvAuthProtocol);
let extensions = {
'hmac-secret': generateRandomTypeExcluding('boolean')
}
let commandBuffer = generateMakeCredentialsReqCBOR(
makeCredStruct.clientDataHash,
makeCredStruct.rp,
makeCredStruct.user,
makeCredStruct.pubKeyCredParams,
undefined,
extensions,
undefined,
makeCredStruct.pinUvAuthParam,
makeCredStruct.pinUvAuthProtocol
)
return expectPromiseToFail(sendValidCTAP_CBOR(commandBuffer))
})

The test should exclude both boolean and map from the random types.

[nuno0529]

Shouldn't this be a new test item behavior for new extension hmac-secret-mc?

[iirachek]

@ve7jtb

The confusion is that hmac-secret has two valid types boolean used on get and map used on make.

Isn't it the other way around? create / makeCredential uses boolean and get / getAssertion uses map. (Ref)

So hmac-secret with a type of map sent on a makeCredential is not supported, and the spec requires ignoring unsupported extensions.

I believe it's less of an extension being unsupported (since the extension ID is correct) and more of handling an invalid parameter, since the extension specification doesn't describe sending map in makeCredential requests, only in getAssertion.

This particular test only covers makeCredential. Based on the above, my understanding is that map should be processed like any other value of invalid/unexpected type sent in extension.

[ve7jtb]

Yes, I had that backwards. We have a grey area where one part of the specification clearly says that we need to ignore unknown extensions. We did actually consider changing the extension in CTAP2.2 to allow a map so that PRF on make could be supported. We did not in the end because sending a map would cause an error with implementations not ignoring it.

We can take it back up in the TWG to clarify. Our behavior is to lean towards ignoring unknown extensions.