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

Hans Zandbelt <hzandbelt@pingidentity.com> Fri, 22 January 2016 09:11 UTC

Return-Path: <hzandbelt@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B091ACE1B for <oauth@ietfa.amsl.com>; Fri, 22 Jan 2016 01:11:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26UPq9_RVBQN for <oauth@ietfa.amsl.com>; Fri, 22 Jan 2016 01:11:41 -0800 (PST)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B411ACE16 for <oauth@ietf.org>; Fri, 22 Jan 2016 01:11:40 -0800 (PST)
Received: by mail-wm0-x229.google.com with SMTP id u188so10566205wmu.1 for <oauth@ietf.org>; Fri, 22 Jan 2016 01:11:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; 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; d=1e100.net; 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 10.28.136.148 with SMTP id k142mr2396516wmd.41.1453453899503; Fri, 22 Jan 2016 01:11:39 -0800 (PST)
Received: from [192.168.10.222] (5ED52E8A.cm-7-6a.dynamic.ziggo.nl. [94.213.46.138]) by smtp.gmail.com with ESMTPSA id y124sm1995636wmg.3.2016.01.22.01.11.37 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jan 2016 01:11:38 -0800 (PST)
To: Mike Jones <Michael.Jones@microsoft.com>, John Bradley <ve7jtb@ve7jtb.com>, Nat Sakimura <sakimura@gmail.com>
References: <569E22E1.5010402@gmx.net> <CANSMLKHjAHr6rUZny5EkX0KBHnOcLuUOZBL0Wwf6V8Y3tt_kNw@mail.gmail.com> <CABzCy2C-_57dO5n6GN6wazA9ozuPivrQd95g_XvdkPWx6zDwAA@mail.gmail.com> <CANSMLKE98FVdDV-7bwW3wZ=-ao5=oXkn9LO5s_M1KmMAt7Drcw@mail.gmail.com> <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com> <CABzCy2DD9K7hMV+AG8RaYJ5ESiiN+PCC-bXDSRHX-OVNf_VyFA@mail.gmail.com> <2019564A-9F00-4FDA-9AD8-420F9789DF44@ve7jtb.com> <BY2PR03MB4425923CAC5A0B0A46BA1A6F5C40@BY2PR03MB442.namprd03.prod.outlook.com>
From: Hans Zandbelt <hzandbelt@pingidentity.com>
Message-ID: <56A1F249.3020307@pingidentity.com>
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: <BY2PR03MB4425923CAC5A0B0A46BA1A6F5C40@BY2PR03MB442.namprd03.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/sU0PA3sKw1y_7kQTy9kHcu1y4JI>
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 22 Jan 2016 09:11:44 -0000

+1 to everything Mike stated

Hans.

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 [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradley
> *Sent:* Thursday, January 21, 2016 4:48 PM
> *To:* Nat Sakimura <sakimura@gmail.com>
> *Cc:* oauth@ietf.org WG <oauth@ietf.org>
> *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 <sakimura@gmail.com
>     <mailto:sakimura@gmail.com>> 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 <ve7jtb@ve7jtb.com
>     <mailto:ve7jtb@ve7jtb.com>>:
>
>         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 <jmandel@gmail.com
>             <mailto:jmandel@gmail.com>> 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" <sakimura@gmail.com
>             <mailto:sakimura@gmail.com>> 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 <jmandel@gmail.com
>                 <mailto:jmandel@gmail.com>>:
>
>                     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
>                     https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00
>
>                     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
>                     http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html.
>                     More
>                     time for analysis is provided due to the complexity
>                     of the topic.
>
>                     Ciao
>                     Hannes & Derek
>
>
>                     _______________________________________________
>                     OAuth mailing list
>                     OAuth@ietf.org <mailto:OAuth@ietf.org>
>                     https://www.ietf.org/mailman/listinfo/oauth
>
>                     _______________________________________________
>                     OAuth mailing list
>                     OAuth@ietf.org <mailto:OAuth@ietf.org>
>                     https://www.ietf.org/mailman/listinfo/oauth
>
>             _______________________________________________
>             OAuth mailing list
>             OAuth@ietf.org <mailto:OAuth@ietf.org>
>             https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Hans Zandbelt              | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity