[OAUTH-WG] Redirection URI registration feedback (Yaron Goland)

Eran Hammer-Lahav <eran@hueniverse.com> Tue, 16 August 2011 21:25 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B630C11E80CA for <oauth@ietfa.amsl.com>; Tue, 16 Aug 2011 14:25:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.554
X-Spam-Level:
X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMQ83vl6Q-Xj for <oauth@ietfa.amsl.com>; Tue, 16 Aug 2011 14:25:08 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 82D1911E80AA for <oauth@ietf.org>; Tue, 16 Aug 2011 14:25:08 -0700 (PDT)
Received: (qmail 8668 invoked from network); 16 Aug 2011 21:25:56 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Aug 2011 21:25:56 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 16 Aug 2011 14:25:48 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: OAuth WG <oauth@ietf.org>
Date: Tue, 16 Aug 2011 14:24:34 -0700
Thread-Topic: Redirection URI registration feedback (Yaron Goland)
Thread-Index: AcxcWeH24dAQPEiRRnqiHahTQZ/41A==
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498D1F3@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234502498D1F3P3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: [OAUTH-WG] Redirection URI registration feedback (Yaron Goland)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 16 Aug 2011 21:25:10 -0000

(Working group feedback requested at the end)



Moved here to solicit additional feedback from the group.



> 3.1.2.2. Registration Requirements: Comment on last word "path": "Huh?

> Scheme, authorization and path is a complete URI minus a query

> component.  Is the goal to specifically mandate that only the query

> component can vary and the rest of the URI MUST be static? If so that should

> be stated explicitly rather than implicitly as it is now.  But I think, if that is the

> intent, it goes too far. We should also allow for additional path segments to

> be added to the URI path beyond the registered prefix. Assuming we can

> address the security problem in the next comment."



Added after 'path': "(allowing the client to dynamically change only the query component of the redirection URI when requesting authorization)".



As for allowing dynamic changes to the path, that's still allowed but not the recommended way. Basically, full registration is best, then dynamic query second best, but anything else is still permitted.



> 3.1.2.3. Dynamic Configuration: Comment on "section 6":  "The reference to

> section 6 is incomplete. Section 6 defines no less than 6 different axis's on

> which URI comparisons can vary. Furthermore as recently documented in

> draft-thaler-iab-identifier-comparison-00.txt it is trivially easy to screw up URI

> comparisons and the security implications are pretty dire. Personally I think

> that the only sane approach given the issues in the previous link is to adopt

> section 6.2.1 of RFC 3986.

>

> I am a bit scared of how to handle partial matches. It's tempting to argue that

> so long as the schema has an authority and at least one path segment then

> we can just use a partial string match but boy oh boy do I see people

> screwing that one up royally. This is scary enough that I think I can be argued

> into saying that partial pre-registered URIs MUST only differ by the query

> component.

>

> In any case this issues needs to be explicitly called out for all URI comparisons

> required by the spec and normatively defined. Otherwise we will end up

> with all the security issues in Dave's ID."



Looks like you are contradicting yourself. First you say that limiting to query only is to limited and now you recommend it.



It is well established that URI comparison is hard because normalization is hard. That was the main issue in OAuth 1.0. It is also the motivation behind recommending registration of the complete URI. I'm open to requiring string comparison for fully registered URIs but not for dynamic URIs because of the difficulty in applying such a rule to partial registration.

Existing text in 3.1.2.3:

   When a redirection URI is included in an authorization request, the
   authorization server MUST compare and match the value received
   against at least one of the registered redirection URIs (or URI
   components) as defined in [RFC3986] section 6, if any redirection
   URIs were registered.

Suggested addition:

   If the client registration included the full redirection URI, the authorization
   server MUST compare the two URIs using simple string comparison as defined
   in [RFC3986] section 6.2.1.

I'm looking for feedback on this proposed addition.

EHL