Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8E223A6947 for ; Tue, 29 Jun 2010 12:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.967 X-Spam-Level: X-Spam-Status: No, score=-9.967 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lj0mPoaB+71p for ; Tue, 29 Jun 2010 12:32:49 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 155463A6C38 for ; Tue, 29 Jun 2010 12:32:32 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 29 Jun 2010 12:32:36 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.23]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0160.007; Tue, 29 Jun 2010 12:32:38 -0700 From: Yaron Goland To: Eran Hammer-Lahav , David Recordon Thread-Topic: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses? Thread-Index: AQHLFyjkSOxwQISS7UeqPRPyI6kTDpKZVRZA Date: Tue, 29 Jun 2010 19:32:31 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C579D2202@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C579D0F52@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB4@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C579D2202TK5EX14MBXC117r_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 19:33:03 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C579D2202TK5EX14MBXC117r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Personally I think we should go with #2. Those who need 'mandatory to implement' extensions should do exactly what E= ran suggested and implement the extension in a way that breaks the core syn= tax so they are guaranteed that those who don't support the extension will = fail. Just my two cents, Yaron From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Monday, June 28, 2010 6:17 PM To: David Recordon Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in reques= ts and responses? There are times when the client wants the server to fail if it doesn't supp= ort an extension. The client developer might consider the server as being l= ess secure without the added protection of the extension and would like the= server to be able to tell it was making such a request and fail. This clearly belongs in the use cases driving discovery, as in the core spe= cification, the client is expected to be familiar with the details of the s= erver. So we just need to make sure that we don't prevent such use cases. #= 2 doesn't prevent it, but requires the client to break something else. For = example, an extension having to do with client identity should replace the = client_id parameter with something else, making a server unaware of this ex= tension fail (because the required client_id parameter will be missing). EHL From: David Recordon [mailto:recordond@gmail.com] Sent: Monday, June 28, 2010 6:11 PM To: Eran Hammer-Lahav Cc: Yaron Goland; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in reques= ts and responses? For #2, if an extension defines required parameters then you're not support= ing the extension if you ignore them. Or am I missing something? On Mon, Jun 28, 2010 at 5:59 PM, Eran Hammer-Lahav > wrote: There are 3 general ways to deal with this: 1. Break on unrecognized parameters - this tends to make the use of extensi= ons hard, and at a minimum requires an error to include the bad parameter i= n a machine readable way (so a library can figure out an extension is not s= upported). 2. Ignore unrecognized parameters - this is the usual way of dealing with e= xtensible protocols. It has security implications when extension parameters= must not be ignored. However, the workaround is simply to break something = else (i.e. replace the client_id with something else that will cause the no= rmal flow to break). 3. Same as #2 but include a directive which means 'must not ignore any para= meter; return error if any parameter is unknown'. XRD used to include such = a 'must-support' attribute for properties but was dropped due to lack of us= e cases. I think #2 offers a good enough balance here, but am happy to discuss #3 if= people have actual use cases where ignoring an extension will cause securi= ty issues. Note that with the expectation of error codes, my upcoming exten= sibility proposal does not allow adding any new parameter values (only new = parameters). EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Yaron Goland Sent: Monday, June 28, 2010 3:02 PM To: oauth@ietf.org Subject: [OAUTH-WG] How do we deal with unrecognized elements in requests a= nd responses? In a private thread with Eran an issue came up regarding how to handle unre= cognized arguments in OAuth requests and responses. For example, if a token endpoint receives an access token request that cont= ains both a client_id and a client_foo_bar argument, what should it do? Sho= uld it reject the request since it doesn't recognize client_foo_bar? Should= it ignore client_foo_bar and just process the request based on client_id? Similarly imagine that a response to an access token request contains a JSO= N member with some unrecognized name. What's the right behavior? Ignore the= unrecognized value? Or treat the response as badly formatted and fail out? We need to define in the spec how to deal with unrecognized extensions. Typ= ically the rule is 'ignore what you don't recognize' but there is a counter= vailing rule which applies here which is "security is different". Typically= ignoring unrecognized elements in a security context can lead to security = holes. Just looking at the history of OAuth I suspect we need to go with the ignor= e rule and then explore ad nauseam in the security considerations section a= ll the ways that the ignore rule can go wrong if extensions aren't handled = carefully. Thoughts? Thanks, Yaron _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_7C01E631FF4B654FA1E783F1C0265F8C579D2202TK5EX14MBXC117r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Personally I think we sho= uld go with #2.

 <= /p>

Those who need ‘man= datory to implement’ extensions should do exactly what Eran suggested= and implement the extension in a way that breaks the core syntax so they are guaranteed that those who don’t support the extension will = fail.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;  Just my two cents,

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      Yaron

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Monday, June 28, 2010 6:17 PM
To: David Recordon
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in= requests and responses?

 

There are times when the = client wants the server to fail if it doesn’t support an extension. T= he client developer might consider the server as being less secure without the added protection of the extension and would like the server to= be able to tell it was making such a request and fail.

 <= /p>

This clearly belongs in t= he use cases driving discovery, as in the core specification, the client is= expected to be familiar with the details of the server. So we just need to make sure that we don’t prevent such use cases. #= 2 doesn’t prevent it, but requires the client to break something else= . For example, an extension having to do with client identity should replac= e the client_id parameter with something else, making a server unaware of this extension fail (because the required clien= t_id parameter will be missing).

 <= /p>

EHL

 <= /p>

From: David Re= cordon [mailto:recordond@gmail.com]
Sent: Monday, June 28, 2010 6:11 PM
To: Eran Hammer-Lahav
Cc: Yaron Goland; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in= requests and responses?

 

For #2, if an extension defines required parameters = then you're not supporting the extension if you ignore them. Or am I missin= g something?

 

On Mon, Jun 28, 2010 at 5:59 PM, Eran Hammer-Lahav &= lt;eran@hueniverse.com> wrote= :

There are 3 general ways to deal wit= h this:

 

1. Break on unrecognized parameters = – this tends to make the use of extensions hard, and at a minimum req= uires an error to include the bad parameter in a machine readable way (so a library can figure out an extension is not= supported).

 

2. Ignore unrecognized parameters &#= 8211; this is the usual way of dealing with extensible protocols. It has se= curity implications when extension parameters must not be ignored. However, the workaround is simply to break something = else (i.e. replace the client_id with something else that will cause the no= rmal flow to break).

 

3. Same as #2 but include a directiv= e which means ‘must not ignore any parameter; return error if any par= ameter is unknown’. XRD used to include such a ‘must-support’ attribute for properties but was dropped due = to lack of use cases.

 

I think #2 offers a good enough bala= nce here, but am happy to discuss #3 if people have actual use cases where = ignoring an extension will cause security issues. Note that with the expectation of error codes, my upcoming extensi= bility proposal does not allow adding any new parameter values (only new pa= rameters).

 

EHL

 

From: oauth-bounces@i= etf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Yaron Goland
Sent: Monday, June 28, 2010 3:02 PM
To: oauth@ietf.o= rg
Subject: [OAUTH-WG] How do we deal with unrecognized elements in req= uests and responses?

 

In a private thread with Eran an issue came up regarding how to ha= ndle unrecognized arguments in OAuth requests and responses.

 

For example, if a token endpoint receives an access token request = that contains both a client_id and a client_foo_bar argument, what should i= t do? Should it reject the request since it doesn’t recognize client_foo_bar? Should it ignore client_foo_bar= and just process the request based on client_id?

 

Similarly imagine that a response to an access token request conta= ins a JSON member with some unrecognized name. What’s the right behav= ior? Ignore the unrecognized value? Or treat the response as badly formatted and fail out?

 

We need to define in the spec how to deal with unrecognized extens= ions. Typically the rule is ‘ignore what you don’t recognize= 217; but there is a countervailing rule which applies here which is “security is different”. Typically ignoring unre= cognized elements in a security context can lead to security holes.

 

Just looking at the history of OAuth I suspect we need to go with = the ignore rule and then explore ad nauseam in the security considerations = section all the ways that the ignore rule can go wrong if extensions aren’t handled carefully.=

 

           =      Thoughts?

 

           =             &nb= sp;        Thanks,

 

           =             &nb= sp;            =             Yaron


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

 

--_000_7C01E631FF4B654FA1E783F1C0265F8C579D2202TK5EX14MBXC117r_--