Feature: Allow RP to opt out of certain transports

[denniskniep]

My request is related to a high-risk enterprise workforce scenario.
As a Relying Party I want to be able to opt-out of the Hybrid transport
flow (cross‑device via QR-Code & BLE) within the WebAuthn request. Furthermore, I want to be able to authoritatively check in the WebAuthn response that no Hybrid transports were used during FIDO authentication.
To prove this in a reliable way, this has to be part of what is signed.

The reason for this request is, that I see a realistic attack vector described in detail here:
https://denniskniep.github.io/posts/14-fido-cross-device-phishing/

[LBBO]

Wow, I'm 5 hours late to ask this exact question! 🤯

However, I'd like to add that it would be nice to add integrity protection not only for PublicKeyCredential.authenticatorAttachment, but also for PublicKeyCredentialRequestOptions.allowCredentials, where RPs are also able to forbid hybrid transport from the get-go. As it's currently implemented, an AitM can manipulate both properties (e.g. in a spear phishing attack) and successfully be authenticated via QR-initiated CDA without the RP realizing that the authenticator was even attached cross-platform.

Just like Dennis, I wrote a blog post on this with a demo video (great minds really do think alike, I guess). I'll also be talking about this at this year's German OWASP Day, in case anyone is interested in an in-person discussion.

[timcappalli]

high-risk enterprise workforce scenario.

In these scenarios, managed contexts should be leveraged to meet your desired workforce security outcomes.

I am not in favor of adding this at the Web Platform layer due to the adverse effects it is likely to have in the greater ecosystem (consumer, unmanaged context).

[LBBO]

... the adverse effects it is likely to have in the greater ecosystem (consumer, unmanaged context)

Could you perhaps elaborate on this a bit? What issues would arise from signing one (or both) of these properties or including them in objects that already have integrity protection?

And purely out of curiosity: why are these properties exposed to the RP in the first place if they're not guaranteed to not have been manipulated? Why can an RP limit the transports of the allowed credentials if that limitation can simply be removed by an AitM without anyone ever being able to detect this manipulation?

[timcappalli]

@LBBO

Could you perhaps elaborate on this a bit? What issues would arise from signing one (or both) of these properties or including them in objects that already have integrity protection?

My response was to the OP, not your proposal.

And purely out of curiosity: why are these properties exposed to the RP in the first place if they're not guaranteed to not have been manipulated?

They are not security properties. They are primarily used to craft user experiences in more advanced use cases.

[emlun]

I think the attack seems legitimate, but I'm not sure it would be solved by, for example, adding a transport value to clientDataJSON.

The attack begins with overriding navigator.credentials.get, so the victim's client isn't involved at all in the WebAuthn ceremony. I don't know in detail how the hybrid transport works, but from skimming the spec it looks to me like the "authenticator" end still acts purely in the authenticator role, and it's still the "client" end that acts as the client, which in particular includes constructing the clientDataJSON value that the authenticator signs. In the attack scenario, this role is performed by the attacker's server, so the attacker can simply lie about any or all of the values in clientDataJSON (indeed, it already lies about origin which is why the attack works in the first place).

So considering that the first step of the attack is to sidestep the WebAuthn API altogether, I don't think there's much we can do within the WebAuthn API to prevent or detect it. I don't know how the hybrid transport protocol could be strengthened to prevent it either - I'd say the authenticator would need to somehow authenticate both the relay server and the client at the other end, but that probably means you can't have the inline setup on first use. But somehow locking down the initial pairing procedure seems to me like one of few possible ways to prevent this.

But yeah, I don't think we could add any signed attribute in WebAuthn that would make the attack preventable or detectable, since the attacker completely sidesteps WebAuthn and is in full control of what's being signed.

I can currently think of only one workaround that'll work with no spec or implementation changes: require attestation, and only allow authenticators that are known to not support the hybrid transport (i.e., only built-in, USB and NFC). That would ensure that the victim's client can't be sidestepped in this way, since the attacker won't have connectivity to the authenticator.

[timcappalli]

It's also important to remember that WebAuthn and passkeys are designed to prevent remote phishing attacks. Physical proximity attacks are largely outside the threat model. That said, there is additional work happening to evolve the FIDO Cross-Device Authentication experience.

Also, if the client or client platform is compromised, most other bets are off. There are other ways to mitigate risks in high assurance workforce scenarios, which are largely outside the scope of the WebAuthn specification.

[LBBO]

@timcappalli

Physical proximity attacks are largely outside the threat model.

Makes sense. If that means that WebAuthn won't consider any changes aimed at preventing such attacks, the rest of my comment is irrelevant. But I think WebAuthn could be modified to prevent the attacks described by @denniskniep and me, so I'll share my thoughts just in case my suggestions end up being acceptable after all.

Also, if the client or client platform is compromised, most other bets are off.

To me this feels different than a compromised client. I understand that most bets are off if there's malware running on the victim's client. But in this scenario, the victim's client is completely uncompromised. The authenticator is simply communicating with a different client than the victim thinks it is. While this is unimaginable for platform-attached authenticators and probably even for other transports used by cross-platform-attached authenticators, it's now suddenly feasible and it might be worth considering it separately from "ordinary" compromised clients.

@emlun

I'm not sure it would be solved by, for example, adding a transport value to clientDataJSON

Yeah, I guess modifying clientDataJSON wouldn't work. But since the authenticator knows how it's communicating with the client, couldn't it add that information to its response (e.g. by using one or more of the reserved flags in authenticatorData)?

Another option could be promote allowCredentialDescriptorList to a security property, add it to the authenticator's signature and require the authenticator to validate the listed transports before completing the authentication. That way an AitM could either add the hybrid transport to the allow-list, but that manipulation would then be detected by the RP, or the AitM doesn't add it and the authenticator refuses to complete authentication because an unallowed transport is being used.

[timcappalli]

But since the authenticator knows how it's communicating with the client,

That is only the case for traditional authenticators using external transports (USB, NFC, Bluetooth), not for software-based credential managers.

To me this feels different than a compromised client.

I brought this up because you mentioned wanting to sign attributes relating to the transports. That seems to stem from the assumption that you don't trust the client.

[denniskniep]

@emlun

I can currently think of only one workaround that'll work with no spec or implementation changes: require attestation, and only allow authenticators that are known to not support the hybrid transport (i.e., only built-in, USB and NFC).

I tested it with a Security Key on Android and it worked. So it works also with authenticators that are known to not support the hybrid transport (see https://denniskniep.github.io/posts/14-fido-cross-device-phishing/#security-keys-also-affected)

But yeah, I don't think we could add any signed attribute in WebAuthn that would make the attack preventable or detectable, since the attacker completely sidesteps WebAuthn and is in full control of what's being signed.

As you said this attack acts as CTAP client and is in full control what he sends to the Authenticator (e.g. origin). The Authenticator receives the crafted CTAP messages. But this attack is not in control of the Authenticator on the other side of the TunnelServer.

Maybe the CTAP client is not directly connected to the final Authenticator. It could be that there is e.g. an OS Credential "Router" (does this has an official name?) in between. I guess that is what @timcappalli was referring to:

That is only the case for traditional authenticators using external transports (USB, NFC, Bluetooth), not for software-based credential managers.

Example 1: Directly connected

.get() --webAuthnReq---> [CTAP Client] --CTAP Msg--> [TunnelServer] --CTAP Msg--> [Authenticator]

Example 2: OS Credential "Router"

.get() --webAuthnReq---> [CTAP Client] --CTAP Msg--> [TunnelServer] --CTAP Msg--> [OS Credential "Router"] --CTAP Msg-->  [Authenticator]

Because this attack can not control the execution of the components on the other end of the Tunnel Server, we might be able to leverage that situation to better secure that scenario.

What if the listener that is connected to the TunnelServer (e.g. OS Credential "Router" or Authenticator - see above examples) are adding to the CTAP message flow a signal that hybrid was used.
This signal will then be part of the signature e.g. as proposed here by @LBBO

But since the authenticator knows how it's communicating with the client, couldn't it add that information to its response (e.g. by using one or more of the reserved flags in authenticatorData)?

Now the webAuthnResponse contains a verifiable proof that hybrid was used, independent of the actually used Authenticator.
The RelyingParty is now able to reject the authentication.

[Firstyear]

My request is related to a high-risk enterprise workforce scenario.
As a Relying Party I want to be able to opt-out of the Hybrid transport
flow (cross‑device via QR-Code & BLE) within the WebAuthn request. Furthermore, I want to be able to authoritatively check in the WebAuthn response that no Hybrid transports were used during FIDO authentication.
To prove this in a reliable way, this has to be part of what is signed.

The only viable option is attestation - this allows you to precisely control the authenticators in use.

[denniskniep]

The only viable option is attestation - this allows you to precisely control the authenticators in use

@Firstyear why should that technically prevent the hybrid flow?

From my point of view the Authenticator is not necessarily aware how the CTAP messages are transported to the Authenticator. Even if its an attested USB Security Key, CTAP Messages might be relayed by the Operating System through a different channel beforehand (hybrid flow) and finally sent via USB to the Security Key.

I tested exactly that scenario on Android. After you scanned the qr code with your Android phone you are able to select a Security Key to complete the authentication.

[joostd]

@denniskniep How did you test this on Android?
My understanding was that CTAP forwarding from hybrid to usb transports was not allowed on Android, and when I retested this just now on my Pixel device I am not offered to use my security key after scanning the QR-encoded FIDO uri (unless I use a credential provider that explicitly features this forwarding).