Revisit Verifier Impersonation Resistance Requirements
Opened this issue · 1 comments
AAL3 requires verifier impersonation resistance, as defined in Section 5.2.5.
The relevant paragraph states as follows (emphasis added)
A verifier impersonation-resistant authentication protocol SHALL establish an authenticated protected channel with the verifier. It SHALL then strongly and irreversibly bind a channel identifier that was negotiated in establishing the authenticated protected channel to the authenticator output (e.g., by signing the two values together using a private key controlled by the claimant for which the public key is known to the verifier). The verifier SHALL validate the signature or other information used to prove verifier impersonation resistance. This prevents an impostor verifier, even one that has obtained a certificate representing the actual verifier, from replaying that authentication on a different authenticated protected channel.
Practically speaking, I believe this means you must cryptographically bind a value derived from the TLS handshake to the output from your authenticator.
The only mechanisms I'm aware of that would meet this requirement as written would be client-auth TLS or FIDO/WebAuthn with token binding.
Unfortunately, a major browser vendor announced its intent to drop support for token binding just as the standard was nearing competition. This would leave client-auth TLS the only way to achieve AAL3.
However, even without token binding, FIDO/WebAuthn are far more phishing resistant than most other MFA options. The authenticator output isn't bound to the TLS channel, but it is bound to the domain name. As such, it is resistant to phishing attacks from look-alike domains, but not advanced MitM attacks where an attacker can get valid certificate for the target domain.
Perhaps more worrisome, the MitM attack should work in cases where the user clicks through a certificate warning.
Realistically, I think we're already vulnerable to such attacks because we allow session management to rely on cookies even at AAL3. So, we should consider this in light of the session management requirements, which suggests we should either weaken the verifier impersonation resistance requirements, or strengthen the session management requirements to forbid the reliance on bearer tokens (e.g., cookies) at AAL3.
It would be useful to consider other mitigations. For instance, if the main threat is a user clicking through cert warnings, would it make sense to require HSTS on verifiers?
In U2F and WebAuthn there is no certificate click through atleast in Chrome and Edge. That is something I will raise in the WebAuthn WG to make it clear to all browsers.
I agree as you know about securing cookies. That was another thing we wanted token binding for.
One thing we have discussed is including the server cert in the returned client data.
The browsers don't like that because it is not clear at the JS - API layer what that host certificate was. The JS may have been cached for a long time. There might be multiple TLS connections open to the same host that could have different certs. I am told that matching a cert to the request is hard for browsers to do. That is one reason Token Binding was introduced to act as an abstraction between the JS layer and the TLS connection.
I am happy to explore options.