[OAUTH-WG] Mix-up mitigation is not so easy...

[Daniel Fett <[e-mail]>]

Hi all,

during my work to update the Security BCP, I stumbled upon a problem in
our current recommendations against mix-up attacks.

Until now, our understanding was that adding an "iss" parameter in the
authorization response and using a distinct redirect URI for each
configured issuer provided the same level of security. This is
unfortunately not the case when mix-up is combined with a client
impersonation attack.

Let's start with the "iss" parameter: The assumption is, that an AS
"knows" which issuer it belongs to. Therefore, an uncompromised AS will
always send the identifier for this (correct) issuer in the "iss"
parameter in the authorization response. The client will see that it
started the process with the attacker's issuer, but receives the
identifier for another issuer in the authorization response, and will
abort the interaction.

With the distinct redirect URIs, the situation is similar. Let's look at
how the client would defend against mix-up:

  * For the attacker's AS configuration (attacker Authorization
    Endpoint, attacker Token Endpoint), the client would register
    https://client.com/redir/attacker as the redirection URI at the
    attacker's AS.
  * For the honest AS configuration (honest Authorization Endpoint,
    honest Token Endpoint), the client would register
    https://client.com/redir/honest as the redirection URI at the honest AS.

In the normal mix-up attack, the following would happen:

  * The user selects "attacker" as AS.
  * The user is being redirected to the attacker's authorization endpoint.
  * The attacker redirects the user to the honest AS's authorization
    endpoint, replacing the client ID in the original authorization
    request with the client ID of the client at the honest AS.
  * The user authorizes the client at honest AS.
  * Honest AS redirects the user back to the client, using
    https://client.com/redir/honest as the redirect URI.
  * The client notices a mismatch between the redirection URI and the
    expected redirect URI (which would be .../attacker).

Therefore, the mix-up attack is mitigated. The problem is, however, that
the attacker can circumvent the protection by *registering a new client
with the honest AS, giving https://client.com/redir/attacker as the
redirection URI* and using this new client ID in step 3 of the attack.

This would mean that the client would see the attacker's redirect URI as
the incoming URI for the authorization response and would not detect the
attack. It would forward the authorization code to the token endpoint of
the attacker, who would be able to redeem it.

Note that the user would not grant access to the honest client, but to
the attacker's client. The attacker's client would need to "impersonate"
the honest client, i.e., using the same name, icon, etc.; This approach
is similar to existing OAuth phishing attacks with counterfeit clients,
however, in this case, a *redirect URI of the honest client* is used.
Therefore, the usual mitigation whereby the AS shows the redirect URI to
the user would not provide any protection (see also
https://tools.ietf.org/html/rfc6819#section-3.5).

What can we do against this attack?

  * PKCE does not protect against this attack, as the attacker would be
    able to change the code_challenge parameter.
  * I think that PAR and JAR probably won't help either, since the
    honest client "legitimately" speaks to the attacker's AS, who in
    turn speaks "legitimately" to the honest AS (as the attacker's
    client). All sides would use the correct endpoints and keys, and the
    attacker would be able to receive and modify the authorization
    request, forwarding it to the honest AS under his own client ID.
  * For the same reason, a DPoP-like sender-constraining of the
    authorization code is unlikely to help.
  * What would help is if client registrations would depend on an
    ACME-like demonstration of control over the origin of the redirect
    URI. This not something mandated for OAuth today and is unlikely to
    be seen in broad use.
  * The "iss" parameter solution is robust against this attack as long
    as an authorization server never returns an issuer controlled by the
    attacker. In essence, by declaring the issuer, the AS is providing a
    pointer to a metadata file which points to the "correct" token
    endpoint - this is why this solution is robust. We have shown the
    robustness of the "iss" solution in our formal analysis, but never
    analyzed the redirect uri solution formally.

For the security BCP, this means that we depend on the "iss" parameter
solution even more. (It also means that OAuth 2.1 should probably
include this parameter.)

We need to think about how we can proceed with the security BCP without
too much delay. 

Sorry for poking another hole into the spec,
Daniel

-- 
https://danielfett.de