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

John Bradley <ve7jtb@ve7jtb.com> Fri, 22 January 2016 00:48 UTC

Return-Path: <ve7jtb@ve7jtb.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 E04B21B3591 for <oauth@ietfa.amsl.com>; Thu, 21 Jan 2016 16:48:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uf1UBnMlL6Cr for <oauth@ietfa.amsl.com>; Thu, 21 Jan 2016 16:48:00 -0800 (PST)
Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (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 55E221B358F for <oauth@ietf.org>; Thu, 21 Jan 2016 16:48:00 -0800 (PST)
Received: by mail-qg0-x22f.google.com with SMTP id o11so46328431qge.2 for <oauth@ietf.org>; Thu, 21 Jan 2016 16:48:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ToGJZ/qyXmwGyoWXj3GcD7QTBZ/XKmD2Z7/UrSrm18M=; b=PoaXa309jqd2mIVcWpTe5vWysqYCSTsB5zeWRiwnZHbOElGdBa4oil7wi7RNMvhq+M Gr710nfKmal5KDnBUFpML6s37pgCVZO9tH4AAEhk94V0lLhFjCMRPSxIvzcmIBt3P80x zkOeOyPwodkIyKK3PKyJTlJNgk3EBx0UlDp68wkEBmfFSFmjeRVGFjrirFvaasMMGhNE WPDZd3UOxurKxOBpQ+xsOeYALHnpxVG+ATHNRB6yHcnVubx6WIrunY7Qxk8PBJMns4nG Zj/3ol1K/B+nYYsQ65H/Fn2Vs8vegC36HqXoorGueIIMJAzdcECxLzEOn235UHNosdUl Yoyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ToGJZ/qyXmwGyoWXj3GcD7QTBZ/XKmD2Z7/UrSrm18M=; b=QnbmKK4YduHB9wC2/6PynjmeFSEO6K8WPxIVIZ42IklDvfRGcOpfmpmlFS99nooe76 GLVAY0LRMKdHm/Xqj/RUdzfFiS7VBV1h+6DfFk8g+En6eYrIKsRF1vYQic5NJFKg131Q 6X76pCtjrwwUXkwnvUbvfPvJQf9UmxXCNzi7GHtUpyN6A6NcDbYzV4pXJZUJsLM2xHxW SrV8KbjlJFrmuPboYT4m5TwbAeK9ufVJ5afOMt87Vawp0TpEzUs2Gq5YAQASiyne1RBo IUG/ZKv9IPol7piEYOMEC3ahiRmAt0FZOy7Fsku9Y2aEItHl562wepGMSC43Vy/afqth N++g==
X-Gm-Message-State: AG10YOTZVaX8xKvg6Y1U+MStDSKcz149uxaHIZHxad7MIGyFnq4DUYH5FVBWCYv4cyMHbw==
X-Received: by 10.140.216.15 with SMTP id m15mr325899qhb.22.1453423679327; Thu, 21 Jan 2016 16:47:59 -0800 (PST)
Received: from [192.168.8.101] ([181.202.192.227]) by smtp.gmail.com with ESMTPSA id y104sm1712175qgd.33.2016.01.21.16.47.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jan 2016 16:47:58 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_FAA8757F-CF7A-4465-A264-271AF06E2913"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <CABzCy2DD9K7hMV+AG8RaYJ5ESiiN+PCC-bXDSRHX-OVNf_VyFA@mail.gmail.com>
Date: Thu, 21 Jan 2016 21:47:54 -0300
Message-Id: <2019564A-9F00-4FDA-9AD8-420F9789DF44@ve7jtb.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>
To: Nat Sakimura <sakimura@gmail.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/33mZvoFzHg4IMAH-Tjq8bjCZfqY>
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 00:48:05 -0000

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>; 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 <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 <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 <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>