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

[Eran Hammer-Lahav <[e-mail]>]

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

EHL

> -----Original Message-----
> From: Justin Richer [mailto:[e-mail]]
> 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.
> 
> 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: [e-mail] [mailto:[e-mail]] On Behalf
> > Of Yaron Goland
> > Sent: Monday, June 28, 2010 3:02 PM
> > To: [e-mail]
> > 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
> >
> >
>