Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses?

From: Justin Richer <[email-masked]>
Date: Thu, 1 Jul 2010 09:03:01 -0400

#2 is the best route forward. If a particular extension requires its
parameters to be present and handled, then it has a few different
options. One is breaking at the server side, either with an explicit
error or throwing away some other required bit, which has been
mentioned. Another is looking for a callback return parameter on the
client side. If the server doesn't return it, then the server didn't
support that extension and the client should break the flow at that
point. 

I want to ask the list though: what exactly do we mean by ignoring
parameters? Is it that a server library will ignore unknown parameters
coming in when doing its processing? That I agree with completely. Same
with parameters coming back to the client from the server. If you don't
know about it, don't try to do anything with it. The one case that I
don't think libraries can *ignore* extra parameters is when using a
client library to build a request to a server. A particular server
implementation may require extra parameters on the request in order to
function (such as MediaWiki's title parameter), and a client needs to be
able to pass such things through. These parameters can effectively be
thought of as part of the address of the server URL, can be ignored by
the OAuth part of the server process, but cannot be dropped by the
client building the request. So "ignore" in this case means "quietly
pass through" and not "drop".

In most instances outside of the Big Web Companies, OAuth is going to be
the new kid being grafted onto an existing framework or application. As
such, it really needs to play nice.

 -- Justin

On Mon, 2010-06-28 at 20:59 -0400, 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
> extensions hard, and at a minimum requires 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 – this is the usual way of dealing
> with extensible 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 normal flow to break).
> 
>  
> 
> 3. Same as #2 but include a directive which means ‘must not ignore any
> parameter; 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 use 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 security issues. Note that with the expectation of error codes,
> my upcoming extensibility proposal does not allow adding any new
> parameter values (only new parameters).
> 
>  
> 
> EHL
> 
>  
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Yaron Goland
> Sent: Monday, June 28, 2010 3:02 PM
> To: [email-masked]
> Subject: [OAUTH-WG] How do we deal with unrecognized elements in
> requests and responses?
> 
> 
>  
> 
> In a private thread with Eran an issue came up regarding how to handle
> 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
> it 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 contains
> a JSON 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. Typically the rule is ‘ignore what you don’t recognize’
> but there is a countervailing 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
> 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?
> 
>  
> 
>                                 Thanks,
> 
>  
> 
>                                                 Yaron
> 
>

---

From: Pelle Braendgaard <[email-masked]>
Date: Thu, 1 Jul 2010 09:42:49 -0400

#2 makes most sense to me

On Thu, Jul 1, 2010 at 9:03 AM, Justin Richer <[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
http://agree2.com - Reach Agreement!
http://stakeventures.com - My blog about startups and agile banking

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Jul 2010 09:37:49 -0700

Ignore as in, pretend it wasn't sent (from either the client or server).

EHL

> -----Original Message-----
> From: Justin Richer [mailto:[email-masked]]
> Sent: Thursday, July 01, 2010 6:03 AM
> To: Eran Hammer-Lahav
> Cc: Yaron Goland; OAuth WG
> Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in
> requests and responses?
> 
> #2 is the best route forward. If a particular extension requires its parameters
> to be present and handled, then it has a few different options. One is
> breaking at the server side, either with an explicit error or throwing away
> some other required bit, which has been mentioned. Another is looking for a
> callback return parameter on the client side. If the server doesn't return it,
> then the server didn't support that extension and the client should break the
> flow at that point.
> 
> parameters? Is it that a server library will ignore unknown parameters coming
> in when doing its processing? That I agree with completely. Same with
> parameters coming back to the client from the server. If you don't know
> about it, don't try to do anything with it. The one case that I don't think
> libraries can *ignore* extra parameters is when using a client library to build a
> request to a server. A particular server implementation may require extra
> parameters on the request in order to function (such as MediaWiki's title
> parameter), and a client needs to be able to pass such things through. These
> parameters can effectively be thought of as part of the address of the server
> URL, can be ignored by the OAuth part of the server process, but cannot be
> dropped by the client building the request. So "ignore" in this case means
> "quietly pass through" and not "drop".
> 
> the new kid being grafted onto an existing framework or application. As such,
> it really needs to play nice.
> 
>  -- Justin
> 
>

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Jul 2010 11:07:04 -0700

> such, it really needs to play nice.

Just a side note, with extensions also being simple names added to the
protocol chances of a collision with an existing framework are much
higher. Using MediaWiki as an example, if an extension proposes to use
'title' as a parameter name it will be approved if it does not collied
with other OAuth 2 parameter names (core or extensions), but
frameworks will not be checked (that is impossible).

Marius

---

From: Justin Richer <[email-masked]>
Date: Thu, 1 Jul 2010 14:29:23 -0400

> frameworks will not be checked (that is impossible).

Right, and it's exactly for reasons like this that I had argued for
namespacing all of the OAuth parameters. But was shot down by the WG.

 -- Justin