Re: [OAUTH-WG] Call for Adoption

Justin Richer <jricher@mit.edu> Thu, 28 January 2016 02:02 UTC

Return-Path: <jricher@mit.edu>
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 466511A1AA6 for <oauth@ietfa.amsl.com>; Wed, 27 Jan 2016 18:02:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 ri-KdhBvbWmh for <oauth@ietfa.amsl.com>; Wed, 27 Jan 2016 18:02:23 -0800 (PST)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8234B1A1A9C for <oauth@ietf.org>; Wed, 27 Jan 2016 18:02:23 -0800 (PST)
X-AuditID: 12074424-b7fff70000000938-2f-56a976ad6939
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 58.F5.02360.DA679A65; Wed, 27 Jan 2016 21:02:21 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u0S22Kck015345; Wed, 27 Jan 2016 21:02:21 -0500
Received: from [192.168.128.48] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u0S22I1r005899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Jan 2016 21:02:19 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_C702C0CD-8572-41B5-84F2-B9B7650D6A41"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <CABzCy2B6Py5-RJ3VL5w8Yxm1hm=XxQjiHVG15wEQVVsQhZVO5w@mail.gmail.com>
Date: Wed, 27 Jan 2016 21:02:18 -0500
Message-Id: <1955C44F-BE12-4F1E-899F-546C65ACB657@mit.edu>
References: <569E2076.2090405@gmx.net> <CABzCy2DehwZh2gd_6oNy69O+qxowva00qZWnX8uWX2n4h+kPLw@mail.gmail.com> <BY2PR03MB442EA7CE4F9728C2E39BBEAF5C30@BY2PR03MB442.namprd03.prod.outlook.com> <EE414329-AA2A-4F99-841B-0581E4F4605F@mit.edu> <CABzCy2A9RCONixTG+ZFD8sz6FTD-o1Do8iV2gX2=pKu+PenT-A@mail.gmail.com> <BY2PR03MB442DE057967872C63A56DF8F5C40@BY2PR03MB442.namprd03.prod.outlook.com> <CABzCy2Co2okoC_hxy3bLTzbGm3nuQiULM3XqkJMwiV_5iU9-=Q@mail.gmail.com> <CA+k3eCSfXQng6PzhWR-Qjyp=SO1LYnfXH7qqzb-5btqWaJJX-A@mail.gmail.com> <BY2PR03MB4422882B74ED659DB47CECDF5C40@BY2PR03MB442.namprd03.prod.outlook.com> <CABzCy2CC8jN6kzxbJ70m900g4J1VW2b65gM_M1dhx6YXfWVhdQ@mail.gmail.com> <CA+k3eCSiEcE-YRG+ej+zJuEHOwqO4oyvvGmKWv5SeMUu4dVPrA@mail.gmail.com> <56A78EEF.4090706@aol.com> <CA+k3eCQh+KfX8+NONECjVj2ZX_e=JFFM4fF7XXcxwWJ-kii9Tw@mail.gmail.com> <56A7C3E8.8080601@aol.com> <CA+k3eCREJUx4Mb_aciKJoq03j0tdmwB2LEPw7GvZA1ZOBNhq+w@mail.gmail.com> <CABzCy2C69JAadYfaZNXgfMaAiJJOuXoKGkC3vC+x8KnhXPHpKw@mail.gmail.com> <56A8794C.2040304@pingidentity.com> <c8c693abce3e7f013d3af38f3b9333fb@gmail.com> <E63EF38B-8A63-4490-8A07-56CD2A3B7E4B@ve7jtb.com> <CA+k3eCT4VneEPSgBX0Ydf=QwUcpHN-2w7rsmQ3gOCs1T44vjvQ@mail.gmail.com> <CABzCy2AKhajiCpJO8FgL1sTLRBvDWjUkj-bzAXaobmBR2FHCsQ@mail.gmail.com> <E6CE5F6B-E973-4570-8EA5-080FB27CBBE7@mit.edu> <CABzCy2B6Py5-RJ3VL5w8Yxm1hm=XxQjiHVG15wEQVVsQhZVO5w@mail.gmail.com>
To: Nat Sakimura <sakimura@gmail.com>
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixCmqrLu2bGWYQd9yG4vV/28yWpx8+4rN 4sytFYwWq+/+ZXNg8dg56y67x5IlP5k87h69yOJx+/ZGlgCWKC6blNSczLLUIn27BK6M5cf/ MxZ8n8xY8fxhE3sD4+u6LkZODgkBE4kni6ewdjFycQgJtDFJfHn/iAnC2cgocevEczaQKiGB 20wSG2ZndjFycDALJEgs3eEBEuYV0JN4desyK4gtLKApsf/uGxYQm01AVWL6mhYmEJtTIFBi wawJYDYLUPzkp82MIPOZBToYJVbNXMIEMchKYuedxSwQi/9xSRzdvQlsqghQR9Pew6wQp8pK 7P79iGkCI/8shDtmIbkDxGYW0JZYtvA1M4QNdFP3chZMcQ2Jzm8TWRcwsq1ilE3JrdLNTczM KU5N1i1OTszLSy3SNdfLzSzRS00p3cQIigF2F5UdjM2HlA4xCnAwKvHwMkStDBNiTSwrrsw9 xCjJwaQkyquRDxTiS8pPqcxILM6ILyrNSS0+xCjBwawkwjsrGSjHm5JYWZValA+TkuZgURLn 3dUxN0xIID2xJDU7NbUgtQgmK8PBoSTBG1UK1ChYlJqeWpGWmVOCkGbi4AQZzgM0vBOkhre4 IDG3ODMdIn+KUVFKnHcZSEIAJJFRmgfXC0pRCW8Pm75iFAd6RZg3FaSKB5je4LpfAQ1mAhp8 UH45yOCSRISUVAPjikufliYJqPGefrrk3fqZTow7D3+dd3B9p07sr9jsvzYqJ6qOqkzxtl1y a59IYmN0mjKf4W37wJxnPZdzF9d/mOnizdfduoEzbVfO3iquddJZN+NWHe96yd5zzmCqz85W nvs8t8oupuZZz+24V/t4Yv5emVsJbq+v3t7dwFRku1Bg14LyK4EBSizFGYmGWsxFxYkAjHx9 BiwDAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/EQmQE4WyRsHGUZhsROcysQU9oSs>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Call for Adoption
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: Thu, 28 Jan 2016 02:02:27 -0000

Definitely the latter. I don’t think the requirement actually helps secure things in practice and artificially limits things otherwise.

 — Justin

> On Jan 27, 2016, at 7:19 PM, Nat Sakimura <sakimura@gmail.com>; wrote:
> 
> You mean the string comparison on authority section would allow execution of some code? Or are you suggesting that not checking the path portion would allow the attacker to plant something on the other paths on the host? 
> 
> Yes, the later is possible especially when there are user generated content on the same host, and if we are worried on it, we would have to do the discovery. 
> 
> Nat 
> 
> 2016年1月28日(木) 5:45 Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>>:
> Unless I’m missing something, requiring the authority section to match discounts attackers being able to deploy executable code on a path. This kind of hole was exploited in a number of Facebook hacks. Yes I’m aware that those were dealing with redirect URIs but we’re talking about the same kind of sub-component URI matching here, and I can only see it getting us into trouble.
> 
>  — Justin
> 
> 
>> On Jan 27, 2016, at 1:15 PM, Nat Sakimura <sakimura@gmail.com <mailto:sakimura@gmail.com>> wrote:
>> 
>> yeah. 
>> 
>> But for Google, Microsoft, etc., every RP can whitelist, cannot they? ;-)
>> 
>> Otherwise, for a code phishing attack, you need to implement discovery of some sort. My thinking before reading your email was: 
>> 
>> if( authority(authz_ep)==authority(token_ep) ) {
>>    get_token(token_ep, code, client_credential);
>> } else {
>>     get_token(token_ep_from_discovery(), code, client_credential);
>> } 
>> 
>> where token_ep_from_discovery() either returns the value of the toke_endpoint member from .well-known/openid-configuration OR the value of turi parameter in the query. 
>> 
>> 2016年1月28日(木) 2:03 Brian Campbell <bcampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>>:
>> There's at least one smallish deployment that has a different authority for the Authorization Endpoint and the Token Endpoint.
>> 
>> from https://accounts.google.com/.well-known/openid-configuration <https://accounts.google.com/.well-known/openid-configuration> :
>> 
>> {
>>  "issuer": "https://accounts.google.com <https://accounts.google.com/>";,
>>  "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth <https://accounts.google.com/o/oauth2/v2/auth>";,
>>  "token_endpoint": "https://www.googleapis.com/oauth2/v4/token <https://www.googleapis.com/oauth2/v4/token>";,
>>  "userinfo_endpoint": "https://www.googleapis.com/oauth2/v3/userinfo <https://www.googleapis.com/oauth2/v3/userinfo>";,
>>  "revocation_endpoint": "https://accounts.google.com/o/oauth2/revoke <https://accounts.google.com/o/oauth2/revoke>";,
>>  "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs <https://www.googleapis.com/oauth2/v3/certs>";,
>>  ...
>> }
>> 
>> 
>> On Wed, Jan 27, 2016 at 6:30 AM, John Bradley <ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>> wrote:
>> It think requiring a common authority segment for the authorization endpoint and the token endpoint might work in common cases, but there are legitimate cases where the URI of the Authorization endpoint might be a alias in the case of multi tenants, all using a common token endpoint.
>> 
>> The larger problem would be the RS, it is not uncommon to have the AS and RS in different domains,  so with bearer tokens unless you make the same authority restriction for RS then you are not really stoping the attacker.   They can get the AT by impersonating the RS.
>> 
>> I think trying to enforce a common origin policy over OAuth would be a bad direction to go.
>> 
>> I understand that it seems like a easy fix on the surface, and it works for most of the things people are using OAuth for today, but would be quite limiting over the long term.
>> 
>> John B.
>> > On Jan 27, 2016, at 7:31 AM, sakimura@gmail.com <mailto:sakimura@gmail.com> wrote:
>> >
>> > Hi Hans,
>> >
>> > Sorry, I mixed up the IdP mix-up attack and the code phishing attack.
>> >
>> > Mandating the Authorization and Token Endpoint being in the same
>> > authority would solve the later without changing the wire protocol.
>> >
>> > For AS mix-up attack, mandating the client to change the redirection endpoint
>> > per AS would solve the problem without change the wire protocol.
>> >
>> > If these are not possible, then we would have to look at changing the
>> > wire protocol. The solution that solves the both cases must
>> > provide the token endpoint URI authoritatively, which means
>> > you have to mandate some variation of discovery mandatory.
>> >
>> > Nat
>> >
>> >
>> > At 2016-01-27 17:01  Hans Zandbelt wrote:
>> >> I don't see how that can deal with the specific form of the attack
>> >> where the Client would have sent the authorization request to the
>> >> legitimate authorization endpoint of a compromised AS and believes it
>> >> gets the response from that, where in fact it was redirected away to
>> >> the good AS.
>> >> IOW, I don't think this is so much about mixing up endpoints where to
>> >> send stuff to, but mixing up the entity/endpoint from which the Client
>> >> believes the response was received. That may just be terminology
>> >> though.
>> >> Bottom line as far as I see is that a wire protocol element in the
>> >> response is needed to tell the Client who issued it, regardless of how
>> >> the Client deals with configuration of the AS information.
>> >> Hans.
>> >> On 1/27/16 1:31 AM, Nat Sakimura wrote:
>> >>> So, is there a lot of cases that the authority section of the Good AS's
>> >>> Authorization Endpoint and the Token Endpoints are different?
>> >>> If not, then requiring that they are the same seems to virtually remove
>> >>> the attack surface for the mix-up related attacks. It does not introduce
>> >>> new parameter nor discovery. If it can be done, it probably is not worth
>> >>> adding a new wire protocol element to mitigate the mix-up variants.
>> >
>> >
>> > _______________________________________________
>> > 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>
>