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 522DF1A9102 for ; Thu, 21 May 2015 21:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 Y_HmcBhEKLOI for ; Thu, 21 May 2015 21:59:35 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 2435C1A9100 for ; Thu, 21 May 2015 21:59:35 -0700 (PDT) Received: (qmail 12695 invoked by uid 0); 22 May 2015 04:59:34 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy9.mail.unifiedlayer.com with SMTP; 22 May 2015 04:59:34 -0000 Received: from host125.hostmonster.com ([74.220.207.125]) by cmgw4 with id WysJ1q00A2is6CS01ysMbx; Fri, 22 May 2015 04:52:23 -0600 X-Authority-Analysis: v=2.1 cv=D8zUdJhj c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=UGkfVyPCAAAA:8 a=rE68L1KyjUoA:10 a=UMhCEPvdHqkA:10 a=h1PgugrvaO0A:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=2oeSqxxVzlsA:10 a=CjxXgO3LAAAA:8 a=48vgC7mUAAAA:8 a=yMhMjlubAAAA:8 a=Mhp_Scw7AAAA:8 a=FRLKbgmKAAAA:8 a=A1X0JdhQAAAA:8 a=ezbKcNVf1CGz8qYZWE8A:9 a=wlMw84Jn-1DgN8g1:21 a=wwBTGdFpht061CwM:21 a=QEXdDO2ut3YA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=KfHwbhnLY3UA:10 a=SSmOFEACAAAA:8 a=Vnlrxu0Y_mNYl-c7b6sA:9 a=KT8SHni5eztKEv9A:21 a=PVHk_3XDUuwWdjAQ:21 a=f94tU6mJ6O7vuYQj:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=X5faoHxxbHa5RV59tQx3ch9Wk8lT4LbVU2sy0F+uUZQ=; b=dYQUlRajs+umuBriKSfQUH3GlgKZbXlxbqP1MeZu2thepgWbNPSw+qGIx/DnjogiGuqkBgfhyvWXkN43wihFdbtKO8wxxM8l8hUOecgiTpFttobBArrg4EWBrpAVhDtO; Received: from [104.176.153.192] (port=49914 helo=HPPavilionElite) by host125.hostmonster.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1Yvf3R-0007o0-4q; Thu, 21 May 2015 22:59:29 -0600 From: "Donald F. Coffin" To: "'Bill Mills'" , "'Mike Jones'" , "'Antonio Sanso'" , "'John Bradley'" References: <1842692772.4820975.1432239207731.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1842692772.4820975.1432239207731.JavaMail.yahoo@mail.yahoo.com> Date: Fri, 22 May 2015 00:59:25 -0400 Organization: REMI Networks Message-ID: <006301d0944c$15766390$40632ab0$@reminetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01D0942A.8E662320" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJhc5N+hDct3Esc9dP/ZqVih7PDhAIgFNF2nFSwTJA= Content-Language: en-us X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 104.176.153.192 authed with donald.coffin@reminetworks.com} Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] redircet_uri matching algorithm 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: Fri, 22 May 2015 04:59:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0064_01D0942A.8E662320 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable +1 =20 Best regards, Don Donald F. Coffin Founder/CTO =20 REMI Networks 2335 Dunwoody Crossing Suite E Dunwoody, GA 30338-8221 =20 Phone: (949) 636-8571 Email: = donald.coffin@reminetworks.com =20 From: Bill Mills [mailto:wmills_92105@yahoo.com]=20 Sent: Thursday, May 21, 2015 4:13 PM To: Mike Jones; Antonio Sanso; John Bradley Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] redircet_uri matching algorithm =20 +1 =20 =20 On Thursday, May 21, 2015 12:29 PM, Mike Jones = > = wrote: =20 +1 I vehemently concur that that working group should stay completely clear = of facilitating this insecure practice. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Antonio Sanso Sent: Thursday, May 21, 2015 12:41 AM To: John Bradley Cc: oauth@ietf.org =20 Subject: Re: [OAUTH-WG] redircet_uri matching algorithm On May 21, 2015, at 4:35 AM, John Bradley > wrote: > I think the correct answer is that clients should always assume exact = redirect_uri matching, and servers should always enforce it. =20 >=20 > Anything else is asking for trouble. FWIW I completely agree with John here... regards antonio >=20 > If clients need to maintain some state the correct thing to do is use = the state parameter, and not append extra path or query elements to = there redirect_uri. >=20 > A significant number of security problems in the wild come from = servers not enforcing this. >=20 > I may be taking an excessively hard line, but partial matching is not = something we should be encouraging by making easier. >=20 > I did do a draft on a way to safely use state = https://tools.ietf.org/id/draft-bradley-oauth-jwt-encoded-state-04.txt >=20 > John B. >=20 >=20 >> On May 16, 2015, at 4:43 AM, Patrick Gansterer > wrote: >>=20 >> "OAuth 2.0 Dynamic Client Registration Protocol" [1] is nearly = finished and provides the possibility to register additional "Client = Metadata". >>=20 >> OAuth 2.0 does not define any matching algorithm for the = redirect_uris. The latest information on that topic I could find is [1], = which is 5 years old. Is there any more recent discussion about it? >>=20 >> I'd suggest to add an OPTIONAL "redirect_uris_matching_method" client = metadata. Possible valid values could be: >> * "exact": The "redirect_uri" provided in a redirect-based flow must = match exactly one of of the provided strings in the "redirect_uris" = array. >> * "prefix": The "redirect_uri" must begin with one of the = "redirect_uris". (e.g. "http://example.com/path/subpath" would be valid = with ["http://example.com/path/", "http://example.com/otherpath/"]) >> * "regex": The provided "redirect_uris" are threatened as regular = expressions, which the "redirect_uri" will be matched against. (e.g. = "http://subdomain.example.com/path5/" would be valid with = ["^http:\\/\\/[a-z]+\\.example\\.com\\/path\\d+\\/"] >>=20 >> If not defined the server can choose any supported method, so we do = not break existing implementations. On the other side it allows an = client to make sure that a server supports a specific matching algorithm = required by the client. ATM a client has no possibility to know how a = server handles the redirect_uris. >>=20 >> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29 >> [2] http://www.ietf.org/mail-archive/web/oauth/current/msg02617.html >>=20 >> -- >> Patrick Gansterer >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org =20 > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 ------=_NextPart_000_0064_01D0942A.8E662320 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

+1

 

Best = regards,

Don

Donald F. = Coffin

Founder/CTO<= /p>

 

REMI = Networks

2335 Dunwoody Crossing Suite = E

Dunwoody, GA = 30338-8221

 

Phone:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 (949) 636-8571

Email:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 donald.coffin@reminetworks.com

 

From:<= /b> = Bill Mills [mailto:wmills_92105@yahoo.com]
Sent: Thursday, = May 21, 2015 4:13 PM
To: Mike Jones; Antonio Sanso; John = Bradley
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] = redircet_uri matching algorithm

 

= +1

=  

=  

On = Thursday, May 21, 2015 12:29 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

 

+1

I = vehemently concur that that working group should stay completely clear = of facilitating this insecure practice.

    =             -- = Mike

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On = Behalf Of Antonio Sanso
Sent: Thursday, May 21, 2015 12:41 AM
To: = John Bradley
Cc: oauth@ietf.org
Subject: Re: = [OAUTH-WG] redircet_uri matching algorithm


On May 21, 2015, = at 4:35 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

> I think the correct answer is that clients should = always assume exact redirect_uri matching, and servers should always = enforce it. 
>
> Anything else is asking for = trouble.

FWIW I completely agree with John = here...

regards

antonio


>
> If = clients need to maintain some state the correct thing to do is use the = state parameter, and not append extra path or query elements to there = redirect_uri.
>
> A significant number of security problems = in the wild come from servers not enforcing this.
>
> I may = be taking an excessively hard line, but partial matching is not = something we should be encouraging by making easier.
>
> I = did do a draft on a way to safely use state https://tools.ietf.org/id/draft-bradley-oauth-jwt-encod= ed-state-04.txt
>
> John B.
>
> =
>> On May 16, 2015, at 4:43 AM, Patrick Gansterer <paroga@paroga.com> = wrote:
>>
>> "OAuth 2.0 Dynamic Client = Registration Protocol" [1] is nearly finished and provides the = possibility to register additional "Client = Metadata".
>>
>> OAuth 2.0 does not define any = matching algorithm for the redirect_uris. The latest information on that = topic I could find is [1], which is 5 years old. Is there any more = recent discussion about it?
>>
>> I'd suggest to add = an OPTIONAL "redirect_uris_matching_method" client metadata. = Possible valid values could be:
>> * "exact": The = "redirect_uri" provided in a redirect-based flow must match = exactly one of of the provided strings in the "redirect_uris" = array.
>> * "prefix": The "redirect_uri" = must begin with one of the "redirect_uris". (e.g. "http://example.com/path/subpath" would be = valid with ["http://example.com/path/", "http://example.com/otherpath/"])
>> = * "regex": The provided "redirect_uris" are = threatened as regular expressions, which the "redirect_uri" = will be matched against. (e.g. "http://subdomain.example.com/path5/" would be = valid with = ["^http:\\/\\/[a-z]+\\.example\\.com\\/path\\d+\\/"]
>>= ;
>> If not defined the server can choose any supported = method, so we do not break existing implementations. On the other side = it allows an client to make sure that a server supports a specific = matching algorithm required by the client. ATM a client has no = possibility to know how a server handles the redirect_uris.
>> =
>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29<= /a>
>> [2] http://www.ietf.org/mail-archive/web/oauth/current/msg0= 2617.html
>>
>> --
>> Patrick = Gansterer
>>
>> = _______________________________________________
>> 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

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

 

------=_NextPart_000_0064_01D0942A.8E662320--