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

[Pelle Braendgaard <[e-mail]>]

#2 makes most sense to me

On Thu, Jul 1, 2010 at 9:03 AM, Justin Richer <[e-mail]> wrote:
> #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
>>
>>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>



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