Same PRF regardless of UV?

[My1]

Is there a specific reason the document defines that

Let PRF be a pseudo-random function whose outputs are exactly 32 bytes long, selected uniformly at random from a set of at least 2^256 such functions. The choice of PRF MUST be independent of the state of user verification. The selected PRF SHOULD NOT be used for other purposes than implementing this extension. Associate PRF with the current credential for the lifetime of the credential.

(emphasis mine)

it seems like an easy way to gain the PRF's output from a short contact with the authenticator, solely by having the credential ID, which is near-public anyway as they are given out by the RP solely by knowledge of a user identtifier for said RP, and the input (given out by the RP to actually do the authentication anyway)

considering PRF outputs are supposed to be used for en/decrypting data potentially present on a device already, I'd say this would significantly weaken the assurances you can give a PRF.

[iinuwa]

Which document are you looking at? Can you link to it?

The reason I ask is that the current spec (WebAuthn Level 3) requires user verification for the prf extension:

This extension only exposes a single PRF per credential and, when implementing on top of hmac-secret, that PRF MUST be the one used for when user verification is performed. This overrides the UserVerificationRequirement if neccessary.

[My1]

https://w3c.github.io/webauthn/#prf-extension
subsection Authenticator extension processing

it still states what you state but only specifically for the hmac-secret backend.

[iinuwa]

Ah, I see; it's on the editor's draft, I missed that and the extra markup in index.bs made my search for the text fail.

There was prior discussion here: #2298 (comment). It seems that it is a backwards compatibility concern.

[My1]

Backwards compat to what tho, there iirc has been no other backend to prf the first place, has there? And if platform authenticators had something, to my experience those were intrinsically alwaysuv anyway.

I would think to either just make it that webauthn can just access it with uv for all backends or let the ctap2 hmac secret style having the secret split between uv and non-uv stay for new backends, as the way it's currently defined would allow easy access to the output without uv in future potential backends, which is my main worry.

[Firstyear]

The PRF needs to change if UV is or is not present, so that an attacker with physical access to the key can request UV=false, and then get the PRF outputs. UV must influence the PRF output so that it proves the UV was also present, and protects the PRF from disclosure without UV.

So I agree that PRF must require UV, and must change depending on UV state.

[ve7jtb]

FIdo CTAP always provides different HMAC outputs for UV vs non UV. That is one of the conformance tests for certified authenticators.

Web Authn says that:
This extension only exposes a single PRF per credential and, when implementing on top of hmac-secret, that PRF MUST be the one used for when user verification is performed. This overrides the UserVerificationRequirement if neccessary.

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.

So I think it is clear that a platform authenticator implementing PRF with or without HMAC Secret must always require UV if it is returning PRF. Given that identical would include UV true in the response. Anything else would be a violation of the spec.

Can you explain what is unclear?

[iinuwa]

Backwards compat to what tho, there iirc has been no other backend to prf the first place, has there? And if platform authenticators had something, to my experience those were intrinsically alwaysuv anyway.

In that referenced thread, it seems that Google Password Manager gives the same PRF whether or not UV is provided. They said that they'd be willing to change given reason, but the text was input to reflect status quo.

I agree that non-CTAP authenticators should follow the same pattern as CTAP ones; to do otherwise is confusing for RPs and for authenticator developers.

For example, I initially understood from

This overrides the UserVerificationRequirement if neccessary

to mean that WebAuthn PRF always requires UV, and that if userVerification: discouraged and extensions.prf is set, then the WebAuthn client would either:

• upgrade the request to userVerification: required,
• or drop the PRF extension from the request.

(Which one the client chooses is undefined behavior in the spec, but either seems fine to me.)

The draft text implies that WebAuthn PRF can be executed without UV and produce the same result, which is in conflict with:

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.

It'd be interesting to sample how these different clients/authenticators behave. I have a gut feeling that this wouldn't break too many deployed sites, since the primary PRF authenticator implementations are in CTAP keys, which would have produced UV-dependent PRF, and macOS/iOS in the last year. Password managers would be the wild card.

I think this is worth breaking some sites that have been relying on UV-independent PRFs, for the security implications raised in the main issue text.

[My1]

@ve7jtb the key problem is that the editor draft here on github specifies the restriction to only use the UV version of the prf in webauthn for the ctap2 hmac-secret backend only (because ctap2 can't use the same prf for non-uv but it already exists). It further states that other backends have to use the same prf regardless of UV.

I saw this in the editor's draft and thought like that's a bad idea and wanted to open this so it doesn't advance to places where it can't easily be changed or get an explanation for this.

@iinuwa dont platform passkeys like Google or apple implicitly always use UV regardless of the request?

Although granted i might need to do more testing around that.