Is `hmac-secret` required for `prf` for non-CTAP authenticators

[zacknewman]

According to the prf extension, the hmac-secret authenticator extension seems to be required; however the below quote (emphasis added) suggests hmac-secret may not actually be needed:

This extension only exposes a single PRF per credential and, when implementing on top of hmac-secret,…

I'm asking since my iPhone reports true for the prf extension when using Safari; however the authenticator data doesn't have the hmac-secret extension let alone the hmac-secret extension with a value of true. I'm unsure if there is a bug in Safari/iPhone or a misunderstanding of the PRF extension. If the hmac-secret extension is required, then what is the point of saying "when implementing on top of hmac-secret" since that's always the case?

[yackermann]

Could that be password manager issue? I know that dashlane still does not support prf, but system might return that prf is supported?

[zacknewman]

I'm using a demo website whose backend is based on my webauthn_rp library. My library is intentionally strict. One of the things it does is verifies that if prf is true, then hmac-secret is true. The demo website sends pretty basic JavaScript that manually sends the PublicKeyCredential since I don't like how much superfluous data is returned from toJSON:

{
  attestationObject: encodeToB64Url(cred.response.attestationObject),
  authenticatorAttachment: cred.authenticatorAttachment,
  clientDataJSON: encodeToB64Url(cred.response.clientDataJSON),
  clientExtensionResults: cred.getClientExtensionResults(),
  transports: cred.response.getTransports(),
}

I'm connecting to this demo website via Safari and use the iPhone's native Passwords app. If hmac-secret is indeed required as I thought, then there is an issue somewhere. I think the issue would exist with Safari (perhaps in addition to others) since the spec states:

Set enabled to the value of hmac-secret in the authenticator extensions output. If not present, set enabled to false.

If there is no hmac-secret, then Safari is not following the spec.

[zacknewman]

I spent more time looking into this, and iPhone 15 Pro Max + iOS 18.4.1 + Safari + the Passwords app never uses the hmac-secret authenticator extension. This suggests that perhaps the spec should be updated to not require hmac-secret and change the directives that require prf to be based on hmac-secret.

In fact I'm able to use the PRF extension even if I create a passkey without the PRF extension. No matter what there is no hmac-secret in the authenticator data for both registration and authentication.

This seems like a good thing, so I can submit a PR that clarifies the hmac-secret extension is only relevant for CTAP authenticators like security keys if that is desired. There is so much mentioning of the hmac-secret extension that it's not clear at all that PRF can be used without it. There is this note:

Note: This extension may be implemented for authenticators that do not use [FIDO-CTAP] so long as the behavior observed by a Relying Party is identical.

However "the behavior observed" is definitely not "identical" since an RP can clearly "observe" one has an hmac-secret authenticator extension while the other does not.

[kopy]

I did a deep dive into PRF recently. Most current authenticators return PRF values even when the credential hasn’t been created with PRF enabled (e.g., iCloud, Google Password Manager, YubiKey). This behavior aligns with CTAP 2.2, helps the extension, but wasn’t entirely clear to me from reading the specification.

[zacknewman]

I did a deep dive into PRF recently. Most current authenticators return PRF values even when the credential hasn’t been created with PRF enabled (e.g., iCloud, Google Password Manager, YubiKey). This behavior aligns with CTAP 2.2, helps the extension, but wasn’t entirely clear to me from reading the specification.

Indeed. CTAP 2.2 states:

Note: Authenticator SHOULD generate CredRandomWithUV/CredRandomWithoutUV and associate them with the credential, even if hmac-secret extension is not present in authenticatorMakeCredential request.

This is only a recommendation though, but I do think it should be called out in the WebAuthn spec. Something like:

Some authenticators require prf to be passed during registration if prf is to ever be used during authentication; thus RPs SHOULD pass prf during registration.

In summary I think changes need to be made that remove a lot of the talk about hmac-secret or at least make more clear this only applies to CTAP authenticators, the directive that prf is assigned values based on hmac-secret needs to be changed (since hmac-secret isn't always applicable), and call out that prf can be used during authentication even if the extension was not passed during registration for some (most?) authenticators.

[zacknewman]

Assuming hmac-secret is not completely removed from the prf section (e.g., a commentary note mentioning that it will be used for CTAP authenticators), hmac-secret-mc should also be mentioned.

[nsatragno]

We do not use hmac-secret to implement on top of non-CTAP authenticators, and we should update the text to reflect this.