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

Daniel Fett <fett@danielfett.de> Wed, 28 October 2020 10:08 UTC

Return-Path: <fett@danielfett.de>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1D1213A047D for <oauth@ietfa.amsl.com>; Wed, 28 Oct 2020 03:08:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id e3_BcOlefuGT for <oauth@ietfa.amsl.com>; Wed, 28 Oct 2020 03:08:27 -0700 (PDT)
Received: from d3f.me (redstone.d3f.me []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ABC93A0112 for <oauth@ietf.org>; Wed, 28 Oct 2020 03:08:27 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id DBC6814548 for <oauth@ietf.org>; Wed, 28 Oct 2020 10:08:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1603879704; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=+RFc5HfQTh1iKjuR+/kRoI5ckF5QyyjnKIDleX919EA=; b=GKpL8WDMSPmVJEHUIuYwLsFz+FjMRuqCRaw67D9HXqzeRGgVA6WVizwYOyxMTX6yN8Cqmt shTln3yJBcZfferLyN1+bZs+Nx5heneH+HXShA9uhr59U02BxJ23GCCyyBC3OCUiX19o4r R6nLrRJUb9IuyuC5xmkM5kBXhXQ4edU=
From: Daniel Fett <fett@danielfett.de>
To: oauth@ietf.org
Message-ID: <cd853162-c784-2910-ac1d-d57d8dd0fdf1@danielfett.de>
Date: Wed, 28 Oct 2020 11:08:24 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------58A99793222E896804F8CFAA"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1603879705; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=+RFc5HfQTh1iKjuR+/kRoI5ckF5QyyjnKIDleX919EA=; b=gj5ksysJzrYhmyTWBaTkfDfwPH8w1K9ZfaH6D8jXktULff+6WK6umew8rI/lV5ntqeVfwS fHiIQjcDaDdR6KkgtLgkt5d4NKzS55xR08XMdraQloLWyunUiYeo8QFD2NR9oamd7L8XoA YVeiQZgAddAR2xXhNM9HEetJhKpJvsY=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1603879705; a=rsa-sha256; cv=none; b=ie0frJCmGRYt0njbMoUpPy6I8IfPX+3RoldN215mi+RkopqZx1z5chYSU0D+GkhmiAOwi/ HC+TOl75LA+saFI3J463QgQsiFxdsTM8yHMH+MmHgRQRUHKHSpEFhkRjiUJT78DgW78MRl Z4oNatBGqiFDl0EWQzB9bkPlCAMntDQ=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: /
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/RjbSwFRmLsk0EgAY2Ter-nw66EY>
Subject: [OAUTH-WG] Mix-up mitigation is not so easy...
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Oct 2020 10:08:29 -0000

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

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,