Re: [OAUTH-WG] redircet_uri matching algorithm

"Donald F. Coffin" <donald.coffin@reminetworks.com> Fri, 22 May 2015 04:59 UTC

Return-Path: <donald.coffin@reminetworks.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 522DF1A9102 for <oauth@ietfa.amsl.com>; 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 <oauth@ietfa.amsl.com>; 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 <oauth@ietf.org>; 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 <donald.coffin@reminetworks.com>) id 1Yvf3R-0007o0-4q; Thu, 21 May 2015 22:59:29 -0600
From: "Donald F. Coffin" <donald.coffin@reminetworks.com>
To: "'Bill Mills'" <wmills_92105@yahoo.com>, "'Mike Jones'" <Michael.Jones@microsoft.com>, "'Antonio Sanso'" <asanso@adobe.com>, "'John Bradley'" <ve7jtb@ve7jtb.com>
References: <BY2PR03MB4423D6CD3799CEB1F321DB8F5C10@BY2PR03MB442.namprd03.prod.outlook.com> <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: <http://mailarchive.ietf.org/arch/msg/oauth/vytv7G7nA2FL9VuqkbAdndVtmGA>
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 <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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 May 2015 04:59:37 -0000

+1

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

2335 Dunwoody Crossing Suite E

Dunwoody, GA 30338-8221

 

Phone:      (949) 636-8571

Email:        <mailto:donald.coffin@reminetworks.com> donald.coffin@reminetworks.com

 

From: 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 <mailto: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 <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 <mailto:oauth@ietf.org> 
Subject: Re: [OAUTH-WG] redircet_uri matching algorithm


On May 21, 2015, at 4:35 AM, John Bradley <ve7jtb@ve7jtb.com <mailto: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-encoded-state-04.txt
> 
> John B.
> 
> 
>> On May 16, 2015, at 4:43 AM, Patrick Gansterer <paroga@paroga.com <mailto: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
>> [2] http://www.ietf.org/mail-archive/web/oauth/current/msg02617.html
>> 
>> --
>> Patrick Gansterer
>> 
>> _______________________________________________
>> 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 <mailto:OAuth@ietf.org> 
https://www.ietf.org/mailman/listinfo/oauth