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

William Denniss <> Fri, 22 January 2016 00:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 44FB41B357E for <>; Thu, 21 Jan 2016 16:43:44 -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 hTaFe3MERb7Y for <>; Thu, 21 Jan 2016 16:43:40 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4E141B3583 for <>; Thu, 21 Jan 2016 16:43:40 -0800 (PST)
Received: by with SMTP id o124so37810699oia.3 for <>; Thu, 21 Jan 2016 16:43:40 -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=NVXC6Dog32ffwul+rjhukobuddvXEcWnbUEpt56L8f0=; b=oOwt1Lr/flBOs0Ltn+MLe470pk5sBD327yNmWq7diqE5JNKnJUMoXkr/7KAQN5qhyZ 6W5cxsrJogJCSaz/RJ0c/pReapsNVevjKK2RiVD9GBZ9Rsf8jc3B9TdDI8Jw3K6N+Bay 0gmWb8hmTTpWuN2P8cMS3C0Y1sXeSk7ER4LVsss5dOUSS1plaX/RmSBz4QiLiFjXpIqZ l+FwLGhr44RhGav70pz2/GvZ9JBiS0KASf8mr0Sy7GsbX1OP/pRG4Q6wFtio7Jll8CvY cwOEwcCSi5ai7AD97AcTrq9Syqb5Q5vbeb0a1LxPtEl6evAb7cl1kSXI8jI8TcoWassr NIqw==
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=NVXC6Dog32ffwul+rjhukobuddvXEcWnbUEpt56L8f0=; b=Ku0TN31exs9UtlNLeoSwvViaJZMC267Jc+L8xvips7ZGLJjU8BS6PQf4uFsHZAswF0 tgm78bjSjh6HPuexSdU/mt6k8F0d+hqduirw06mVfXq+ITid/lYkoIm+W9yhGMGOHz+e /478Ecn4M4QCuNaKeAAjyd1oohsO1yW0d2ala3KqwzTLX49ZdNL8Y3zH3O4axQOaZjPR lS9V4jBoTeJWDxNdBmdaY/eZTY+ADeAyL7v2bblEUnU7UJ3WzgflLUYbaSQmRQD7Gjzm GwEYWFfdBSQgoyNYWU94+bV4K1y4a4ek8NiaO7h+FUESIjTsXDM6jID0EM/emqvr5HVV MTCA==
X-Gm-Message-State: AG10YOTDREWqFNPvlJ8ngd6YN1Bo8s3QGBZZE20HY5K9fY42ypbZQbg3gaNUPOBAqFQA1IQY7mWAGnxv9EFtNHaa
X-Received: by with SMTP id c83mr159959oia.13.1453423419987; Thu, 21 Jan 2016 16:43:39 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 21 Jan 2016 16:43:20 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
From: William Denniss <>
Date: Fri, 22 Jan 2016 08:43:20 +0800
Message-ID: <>
To: John Bradley <>
Content-Type: multipart/alternative; boundary=001a113d45d8a8609c0529e18264
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: Fri, 22 Jan 2016 00:43:44 -0000

When I first heard Nat's proposal in Yokohama I thought it was pretty
elegant. And remember that it was first proposed to add more RESTful
behavior to OAuth and not just as a mix-up mitigation.

For the mix-up topic, I wonder if this comes down to: if you are already
doing OpenID Connect, the issuer/discovery path feels natural, as that's
what you're used to. But if you're pure OAuth, without those concepts then
Nat's solution is more natural?

I do recall some contention in Yokohama around returning the same info
twice (e.g. returning the token endpoint, and returning a discovery
document URL which could potential reference a different token endpoint).

There's something quite nice about the possibility for the AS returning
more detailed configuration like the relevant resource servers where the
token can be used – something that discovery can't do as it doesn't have
the context of the authorization grant.

On Fri, Jan 22, 2016 at 6:59 AM, 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.
> 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.
> 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.
> 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