Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

John Bradley <> Mon, 25 January 2016 14:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A8DC81ACD0C for <>; Mon, 25 Jan 2016 06:11:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I-YD49h60qMi for <>; Mon, 25 Jan 2016 06:11:32 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A56C91ACD02 for <>; Mon, 25 Jan 2016 06:11:31 -0800 (PST)
Received: by with SMTP id s68so54362028qkh.3 for <>; Mon, 25 Jan 2016 06:11:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=C3Mx3LWglIko2y1L6rLleraqCa5VfADOra6cYLFKEyI=; b=QWYj92Oe+OseiwQGVPA2t6uLjOxXknKSLXzCwD1XeQu4iu8oN/92WPhhCszrINWSSF NPgha8gohzRTBmRpXY3T9p5ZbZY6LAIRgVBYKDlfRXRWQMPwwOSnVw6V6QfDvul3YnLs 5p1dWi5gX6Miy8qOv5R31MbKCNxWl9FMAy/r4UPIi3GFNLe1/s4knbCGek1H1OOY4jo4 k9RV+5/pEBIHsnzHZGKE86JXeAS0YMkKbPIdENimAJrDKoGjclEq32CthUwZXrkgNrFS 7qjQDXmDXDKvbrOZiczMc+4YVImWr/tQtumH458+JrCE0cDrfVzq1go04siGb806/da2 M1ZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=C3Mx3LWglIko2y1L6rLleraqCa5VfADOra6cYLFKEyI=; b=d7CrnQ82tB6tO/BQmVEXUIWfLTRfU+J0grwpodasrEhSSd9EqKGnqGhhb4CjujKwwG LZ3etfIYLM3sB/MXoUhLaWwYRgo/qz7jB9bNWXpMPrdYFk8n+/7yvS0prGTEs0C3XREM dv0JqjtfcOlBToyrB1WueSJFkvhQdMDIXM7TRL/FpMnJZuSrH0RCoWaHoG8DbgXlzC1b khVBv9q9V9Nf5PAS8jsTsx6pTfgxaVkyvImV3K5IaoODtLFS+1xl/Rdkgjvl5qTwG+CD y09534i98ld5ryqLZjtsW4VHlS+5CnNU3VbNxBCUvpC7bVVrPoen0+PTMKn5SOdujXFD dkBA==
X-Gm-Message-State: AG10YOSYrUkiqCXiRBv3xRK/V9qSxIwK5UdTv9QQpeOswyNT9fNYvzKB62OZRHeI73Z9ww==
X-Received: by with SMTP id z76mr21101359qkg.42.1453731090667; Mon, 25 Jan 2016 06:11:30 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id 107sm8786058qge.16.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jan 2016 06:11:29 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_5C460D1C-826D-4281-8A6F-43AC0AC989DC"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley <>
In-Reply-To: <>
Date: Mon, 25 Jan 2016 11:11:24 -0300
Message-Id: <>
References: <> <> <> <> <> <>
To: William Denniss <>
X-Mailer: Apple Mail (2.3112)
Archived-At: <>
Cc: " WG" <>
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Jan 2016 14:11:35 -0000

The mixup attack where the client is confused about who the response is coming from is posable both by providing bad configuration information and by compromising a existing AS.

The point was that telling clients to only register with “good” AS or somehow validating the configuration information is not sufficient to stop the attack.

If a AS is completely compromised you would be able to do the same attack.   In principal the OAuth protocol should not intertwine the security of different AS so that if one is compromised it degrades the security of all the others.

You are correct that in the compromised log flow the RS would not be able to leak the token unless it is compromised as well or the introspection endpoint on the AS is. 

Given that the log attack is just one example we do also want to cover the ones where a client is given bad discovery information with a evil RS.   

This RS attack is not dissimilar to the attack that Eran was concerned about  where a client starts at the RS and gets a insufficient_scope error and then goes to it’s AS and requests a token with a new scope.
This would also be an example of client becoming confused about who it is dealing with.  I recall that bearer took the URI of the Authorization endpoint URI out of the error response to prevent that.
It is also not the current pattern to start with the resource except in UMA that might have an issue (it is probably mitigated some other way George can comment, he know the UMA spec)

The ways that I can think of to avoid the confused client RS attack are:
1. Proof of Possession tokens.  That was Eran’s solution, and there are other good reasons to do it and the work is already chartered, but perhaps overkill for many applications.

2. AS based Discovery where the RS are listed in the AS discovery document.  This is what Connect provides with the “userinfo_endpoint” claim in discovery.   This depends on having a logical identifier for the AS.

3. Providing the URI of the resource the token is being requested for in the token request.  This is what the “aud" parameter in POP key distribution is doing (that may wind up as a separate spec if adopted)

4. Providing the list of URI that the token can be used at in the response from the token endpoint.   This is basically Nat’s proposal.

Certainly some combination of them is also possible.

Connect provides mitigation for the mix up attack in some flows, specifically “code id_token” “token id_token” and “code token id_token”.

The mitigation doesn’t work for the code flow, because the client sends the code to the token endpoint before it can validate the id_token. 

Returning the iss and client_id from the authorization endpoint per Mike’s draft allows the client to reject the authorization response and not leak the code.

John B.

On Jan 25, 2016, at 1:11 AM, William Denniss <> wrote:
> On Thu, Jan 21, 2016 at 2:59 PM, John Bradley < <>> wrote:
> There have been a lot of discussions. I think Hannes posted some minutes of the F2F meeting we had with the security researchers.
> The problem can’t be mitigated without some action on the client side.  It boils down to the client making a request to AS1 (From it’s perspective) and getting back a response from AS 2 (that it thinks is AS1)
> This can be done if AS1 is a good AS but has it’s logs compromised so that an attacker can read them. Hans Zandbelt built a proof of concept for the attack. 
> So for mix-up, we're only talking about a compromised logs attack and not a completely compromised AS?
> In some cases the attacker gets the code and the credential to use it at the good AS token endpoint and in others it just gets the code and can replay that at the client to extract information from the API through the client by binding the api access to a new account.
> PKCE unfortunately mitigates a different attack, where the client is impersonated and trys to replay a intercepted code.  It however assumes the token endpoint is good, and is no help in the case of a compromised token endpoint.
> The client in these attacks is vulnerable because it relies on some local state, or the value of the state parameter to know who the response is coming from.  This allows a authorization request that is intercepted to be used to create a new request in that browser to a different AS, or trick the client into using a Authorization endpoint for a different authorization server.
> One problem is that OAuth doesn’t really have a unified concept of what a AS is.  Traditionally it is a Authorization endpoint URI, token end point URI and resource server URI that some one gives the client in some documentation.   
> As ling as a client only talks to one AS then there is no problem.   However once a client is configured to talk to more than one AS, we have problems if one of those AS lies about it’s endpoints, or is compromised and used to attack another AS.   As a design goal you don’t want the overall  security to be limited by the weakest system.
> One approach as Nat promotes is to have the authorization endpoint return the next hop, token endpoint for code or RS URI for token. The token endpoint must also return the RS URI or the client must push the RS URI to the token endpoint or the attacker just replaces the RS URI in the config and captures the token that way. 
> I believe the RS URI would not be needed to defeat the compromised logs mix-up attack for the code flow. The client will send the client_id it got when registering at AS1 to the token endpoint returned by AS2 (using Nat's spec), which will then cause a failure due to client_id mis-match. So simply returning the "token_endpoint" URI in the AS2 authorization response would defeat the compromised-logs mix-up attack, would it not? 
> The other way is to provide a name for each AS as part of registration and the client not allow duplicate registrations with the same name.  When the response comes back the client checks the name against the one it made the request to.  If the name dereferences to a discovery document then the client can check that name at registration or runtime to validate the net hops.
> I think the two approaches mitigate the attack in similar ways.  Nat’s is more REST friendly and returns the next hop as a parameter of header.  
> The one Mike and I wrote up based on the meeting in Germany provides identifiers (iss and client_id) that can be checked for validity in the simple case and be dereferenced via .well-known to get the information Nat’s proposal is providing.
> Perhaps the main difference is Nat is using the token endpoint as the identifier for the AS and Mike’s is using location for a discovery document as the identifier.
> I don’t recall the reasons using the token endpoint as the identifier was rejected at the meeting.  Perhaps others can post the reasons.
> Can you help clarify something that I've yet to discern from the minutes, does OpenID Connect solve the mix-up attack by binding all the tokens together and to the issuer via the ID Token?
> We need to close on this quickly, otherwise if we are indecisive fixes will not go into products for another year or so until this is a RFC.
> That is my main concern.
> John B.
[snip]  For readability of a long thread.