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

William Denniss <> Mon, 25 January 2016 04:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AAFB31A6FD7 for <>; Sun, 24 Jan 2016 20:11:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lmK8n8W8CSx4 for <>; Sun, 24 Jan 2016 20:11:25 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 348D31A6FD8 for <>; Sun, 24 Jan 2016 20:11:25 -0800 (PST)
Received: by with SMTP id is5so106606782obc.0 for <>; Sun, 24 Jan 2016 20:11:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PkBWNPnd4gPJeKI2mc+faV9XlNRixWfWfqdMG1wHggI=; b=Yn8pERt5Z162+ppEjm4OnRFXuxSk1ftu9cWL9qwser6cC3xltHcD+ekmUQ0iHx6sae mE7byzGKt8Bn+pznudXc/lw6C8D9CiK2KsyyRdu5dutWcqb5ab61LiDZmiu51KXs9qGk VZFTk68qsAzfuW6ZeSu6+WE1C6W9FTmOQ20aK9nrN/3la1iM581N+qj+0y6p6oEujDRc 4sEqM/S6YyH7sTd3ZesIDoboN6c0BHBrtASCujvZ3DmInpWzOjq6W1q3iu+NMZzCWicE D4A9nxL/PKK69ZStialUZfSXqxiW9WP+FE5kcQCGFQUErhHv0oMnR2oT1rwWmh+OO03V XQgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PkBWNPnd4gPJeKI2mc+faV9XlNRixWfWfqdMG1wHggI=; b=V7SNgQorIsrfgWFyuGE1POCCICADMWueQa5iZt5Thy1JEe/uMU+GK90IJ1oDmOqxQy cHHhMPrw9oUweT06GtPbxaRlS5mA3cn3RMc6EALS1FJB5+jd8gUgUmxdrUiOGd7TxD4P ma7QGhV8rIpvwWiBwCLDPnu6OLH535pY7Bi2mLFVu2xQoa95XgJzPCTotI1BPw5SvOG1 5qCkxzRYDrG03/2fF9SzN+2fJebdforw048ofMwck5rHEkBgGNrVzRFLa4tRc4AW/UtD 6iKKaVLmGoCiIg5bsfYIME51QsytDt32RsPGF69pmrTK4ruDP5mIyzmKGiPDE9otaZVu VQ0A==
X-Gm-Message-State: AG10YOS6jkD7M/7eDohjFbGZFpbachDzkUTgTi1NN0xV3+FBmZqbfRQi4V5oNNBsVFU8OF363JOQM2KrxYMFGAmP
X-Received: by with SMTP id qo3mr11334350oeb.80.1453695084361; Sun, 24 Jan 2016 20:11:24 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 24 Jan 2016 20:11:04 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
From: William Denniss <>
Date: Sun, 24 Jan 2016 20:11:04 -0800
Message-ID: <>
To: John Bradley <>
Content-Type: multipart/alternative; boundary=047d7b2e465a1dc151052a20c392
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 04:11:28 -0000

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.
> On Jan 21, 2016, at 11:50 AM, Josh Mandel <> wrote:
> Thanks Nat - that's helpful. If both mitigations *can* work effectively,
> then I would like to see this group consider the decision between them
> carefully (if that hasn't happened yet). Again, don't hesitate to let me
> know if this is the wrong place/time for such discussion.
> At a high level, I would rather ask server developers to do some "coding",
> for two reasons:
> 1. Most OAuth servers talk to many, many clients. So consolidating the
> security critical work in one place (server) is a net savings of work
> (rather than asking each client to implement these checks.
> 2. OAuth server developers are typically more sophisticated than client
> developers, and therefore more likely to understand the implications and
> more likely to get these critical details correct. Asking each client
> developer to do something right is likely to result in heterogenius
> implementation and persistent security holes. But if the server does the
> heavy lifting, and clients just have to pass along an extra parameter, this
> is more likely to see consistent implementation (for example, clients will
> fail to work if misconfigured, which will prompt developers to fix them).
> On Jan 21, 2016 09:40, "Nat Sakimura" <> wrote:
>> Hi Josh,
>> It is similar but slightly different IMHO.
>> Section 4.6.4 of the RFC6819 is the access token phishing by a
>> counterfeit resource server.
>> The mix-up attack described here is the code phishing by a counterfeit
>> token endpoint.
>> In my view, both can be mitigated by the server returning the next step:
>> i.e., authorization endpoint returning the legitimate token endpoint uri,
>> and token endpoint returning legitimate resource endpoint uris. This
>> involves no discovery endpoint, which is good.
>> Your way also works. It is just the reverse of my proposal. The
>> difference being that my proposal does not need any coding on the server
>> but just configuration, and it can return more metadata if needed.
>> Cheers,
>> Nat
>> 2016年1月21日(木) 23:04 Josh Mandel <>om>:
>>> Apologies if this is the wrong forum for my comment (and please direct
>>> me to the appropriate place in that case), but I have two questions about
>>> the propose mitigation (and the thinking behind it) that I think the
>>> write-up could address:
>>> 1. Could the writeup clarify whether/how the primary "mixup" threat
>>> differs from what RFC6819 identifies as in section 4.6.4?
>>> 2. Has the workgroup considered a mitigation that puts more
>>> responsibility on the authorization server, and less on the client? For
>>> example, if would be helpful for the writeup to clarify why having the
>>> client send an "audience field" (in the terminology of RFC6819) to the
>>> authorization endpoint would not mitigate the threat. (In that scenario,
>>> the authorization server can recognize that the audience does not
>>> correspond to a resource server it knows, rather than asking clients to
>>> make this check). I assume this approach has been considered and rejected
>>> as an incomplete mitigation, but I don't have visibility into where/how
>>> that discussion went.
>>> Thanks,
>>> Josh
>>> Hi all,
>>> this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
>>> Please let us know by Feb 9th whether you accept / object to the
>>> adoption of this document as a starting point for work in the OAuth
>>> working group.
>>> Note: This call is related to the announcement made on the list earlier
>>> this month, see
>>> More
>>> time for analysis is provided due to the complexity of the topic.
>>> Ciao
>>> Hannes & Derek
>>> _______________________________________________
>>> OAuth mailing list
>>> _______________________________________________
>>> OAuth mailing list
>> _______________________________________________
> OAuth mailing list
> _______________________________________________
> OAuth mailing list