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

Hans Zandbelt <> Fri, 22 January 2016 09:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 91B091ACE1B for <>; Fri, 22 Jan 2016 01:11:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 26UPq9_RVBQN for <>; Fri, 22 Jan 2016 01:11:41 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 11B411ACE16 for <>; Fri, 22 Jan 2016 01:11:40 -0800 (PST)
Received: by with SMTP id u188so10566205wmu.1 for <>; Fri, 22 Jan 2016 01:11:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=/DJe/QUBsINUKc3Zj7La4cmnQkZErIFfHW/oKHGcWq0=; b=ZLOPQsM9hXx0+/UKG7XFBFuzI15k16PQFyt3UegdUlXiOeUFsxKq1GT3Bk1yHwdjKZ Ow8OEE0IbukuBsW6e+Lq6yM+BequJ6UvoeUv01Xx968aBMOPhIPORYBRoGe9d60MwPZy K7yShloVzkc2e0wUOU/CP5fcFsQFsWktZV3eg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=/DJe/QUBsINUKc3Zj7La4cmnQkZErIFfHW/oKHGcWq0=; b=lLzPXdKoR5iNnOlosBc1s9izqMDGe1V60A/JQSDGWFCNlg1ko1IfOmfSz55AUTYrF5 mIB9tyT6MXExoTh5x1fmfY2l76cQt7tqEsEQ+9WTIVpmV2qcw3rKeyQaJW7OjeMSD2uU TINEcLQ6VPM4w65RbmaqGaWXQ4qQ2QedBo5G5d+DrPnljDSVFxfM+VeJbYqj0Ejw7VYs RCkRPyfGSwKU4I9A/AQ5/3/oo/nlFyGjVa5eWrL3937/9BEK3tdjie8vjpy+vteOxTuq xL1YFeY4zedoDWXuwyhOGo2QDV71IHmy+h6zGS1pP6XwCtp2MntGzPRxUFlbGARvSwgB N58Q==
X-Gm-Message-State: AG10YORCtAc08ZBNP2KjXn2c5OAdWW5nT4i3F1rJjrWvjrE5bC145qpvUFCVrz/r8fxJ+5+U
X-Received: by with SMTP id k142mr2396516wmd.41.1453453899503; Fri, 22 Jan 2016 01:11:39 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id y124sm1995636wmg.3.2016. (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jan 2016 01:11:38 -0800 (PST)
To: Mike Jones <>, John Bradley <>, Nat Sakimura <>
References: <> <> <> <> <> <> <> <>
From: Hans Zandbelt <>
Message-ID: <>
Date: Fri, 22 Jan 2016 10:11:37 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
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 09:11:44 -0000

+1 to everything Mike stated


On 1/22/16 2:04 AM, Mike Jones wrote:
> I believe that it’s simpler and more elegant to return an issuer, from
> which the discovery metadata document can be retrieved, which contains
> **all** the configuration information about the authorization server,
> than to return some of the configuration parameters but not most of them
> (which is what the oauth-meta proposal does).  There’s lots more in a
> typical discovery document than just a few endpoint addresses. For
> instance, there are statements about what response types are supported,
> other configuration choices, keys, etc.
> I also think that returning the issuer is more future-proof than trying
> to decide now what all the configuration information is that might want
> to be verified by the client and hoping we get it right.  With the
> issuer, assuming that discovery is supported, it can retrieve and check
> all of it, should the client want/need to do so.  Even when discovery
> isn’t supported, the issuer still provides a concrete identifier for the
> authorization server that can be checked for equality.
> We talked about the value of that approach in the side meetings in
> Yokohama and people were supportive then.
>                                                                  -- Mike
> *From:*OAuth [] *On Behalf Of *John Bradley
> *Sent:* Thursday, January 21, 2016 4:48 PM
> *To:* Nat Sakimura <>
> *Cc:* WG <>
> *Subject:* Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
> I will point out for clarification that this would be like IdP discovery
> in openID 2 that everyone did.  I think IdP not doing RP discovery in
> openID 2 is a weak argument.
> There may be other evidence that RP will not do discovery, but if that
> is the case why are we doing a OAuth discovery spec?
> Many people see your spec as discovery as well just in a different way.
> I think both ways can work, but doing both leaves too many options.
> John B.
>     On Jan 21, 2016, at 9:38 PM, Nat Sakimura <
>     <>> wrote:
>     Still doing the analysis. We spent 1.5 hours today with John,
>     George, nov and me on the OpenID Connect WG call on this issue. John
>     explained the mitigation, but none of us was convinced that it works.
>     Then, after the call, I and nov went on with various scenarios. The
>     interim conclusion is that:
>       * client_id response parameter does not help. There are legitimate
>         cases that client_id duplicates out there and we cannot ban that.
>       * iss response parameter does not help unless the discovery is
>         performed and the value of iss is checked against the value of
>         OAuth issuer inside the document. (<- Discovery becomes
>         mandatory. From our experience on RP discovery step in OpenID
>         2.0, chance of this being done properly seems to be rather slim.)
>       * sending the state to the token endpoint helps in the case code
>         was stollen, but code should not be stolen to start with.
>     Cheers,
>     Nat
>     2016年1月22日(金) 7:59 John Bradley <
>     <>>:
>         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 <
>                 <>>:
>                     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

Hans Zandbelt              | Sr. Technical Architect | Ping Identity