Return-Path: 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 ; 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 ; 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 ; 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 In-Reply-To: Date: Wed, 27 Jan 2016 21:02:18 -0500 Message-Id: <1955C44F-BE12-4F1E-899F-546C65ACB657@mit.edu> References: <569E2076.2090405@gmx.net> <56A78EEF.4090706@aol.com> <56A7C3E8.8080601@aol.com> <56A8794C.2040304@pingidentity.com> To: Nat Sakimura 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: Cc: "" Subject: Re: [OAUTH-WG] Call for Adoption X-BeenThere: oauth@ietf.org 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: Thu, 28 Jan 2016 02:02:27 -0000 --Apple-Mail=_C702C0CD-8572-41B5-84F2-B9B7650D6A41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Definitely the latter. I don=E2=80=99t think the requirement actually = helps secure things in practice and artificially limits things = otherwise. =E2=80=94 Justin > On Jan 27, 2016, at 7:19 PM, Nat Sakimura wrote: >=20 > 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?=20 >=20 > 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.=20 >=20 > Nat=20 >=20 > 2016=E5=B9=B41=E6=9C=8828=E6=97=A5(=E6=9C=A8) 5:45 Justin Richer = >: > Unless I=E2=80=99m 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=E2=80=99m aware that those were dealing with redirect URIs but we=E2=80=99= re talking about the same kind of sub-component URI matching here, and I = can only see it getting us into trouble. >=20 > =E2=80=94 Justin >=20 >=20 >> On Jan 27, 2016, at 1:15 PM, Nat Sakimura > wrote: >>=20 >> yeah.=20 >>=20 >> But for Google, Microsoft, etc., every RP can whitelist, cannot they? = ;-) >>=20 >> Otherwise, for a code phishing attack, you need to implement = discovery of some sort. My thinking before reading your email was:=20 >>=20 >> if( authority(authz_ep)=3D=3Dauthority(token_ep) ) { >> get_token(token_ep, code, client_credential); >> } else { >> get_token(token_ep_from_discovery(), code, client_credential); >> }=20 >>=20 >> 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.=20 >>=20 >> 2016=E5=B9=B41=E6=9C=8828=E6=97=A5(=E6=9C=A8) 2:03 Brian Campbell = >: >> There's at least one smallish deployment that has a different = authority for the Authorization Endpoint and the Token Endpoint. >>=20 >> from https://accounts.google.com/.well-known/openid-configuration = : >>=20 >> { >> "issuer": "https://accounts.google.com = ", >> "authorization_endpoint": = "https://accounts.google.com/o/oauth2/v2/auth = ", >> "token_endpoint": "https://www.googleapis.com/oauth2/v4/token = ", >> "userinfo_endpoint": "https://www.googleapis.com/oauth2/v3/userinfo = ", >> "revocation_endpoint": "https://accounts.google.com/o/oauth2/revoke = ", >> "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs = ", >> ... >> } >>=20 >>=20 >> On Wed, Jan 27, 2016 at 6:30 AM, John Bradley > 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. >>=20 >> 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. >>=20 >> I think trying to enforce a common origin policy over OAuth would be = a bad direction to go. >>=20 >> 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. >>=20 >> John B. >> > On Jan 27, 2016, at 7:31 AM, 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 >> > https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 --Apple-Mail=_C702C0CD-8572-41B5-84F2-B9B7650D6A41 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Definitely the latter. I don=E2=80=99t think the requirement = actually helps secure things in practice and artificially limits things = otherwise.

 =E2=80= =94 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=E5=B9=B41=E6=9C=8828=E6=97=A5(=E6=9C=A8) = 5:45 Justin Richer <jricher@mit.edu>:
Unless I=E2=80=99m 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=E2=80=99m aware that those were dealing with redirect URIs = but we=E2=80=99re talking about the same kind of sub-component URI = matching here, and I can only see it getting us into trouble.

 =E2=80=94 = Justin


On Jan = 27, 2016, at 1:15 PM, Nat Sakimura <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)=3D=3Dauthority(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=E5=B9=B41=E6=9C=882= 8=E6=97=A5(=E6=9C=A8) 2:03 Brian Campbell <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 :

{
 "issuer": "https://accounts.google.com",
 "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
 "token_endpoint": "https://www.googleapis.com/oauth2/v4/token",
 "userinfo_endpoint": "https://www.googleapis.com/oauth2/v3/userinfo",
 "revocation_endpoint": "https://accounts.google.com/o/oauth2/revoke",
 "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
 ...
}


On Wed, Jan 27, 2016 at 6:30 AM, = John Bradley <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 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
> https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


= --Apple-Mail=_C702C0CD-8572-41B5-84F2-B9B7650D6A41--