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

From: Yaron Goland <[email-masked]>
Date: Mon, 28 Jun 2010 22:01:48 +0000

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: Marius Scurtescu <[email-masked]>
Date: Mon, 28 Jun 2010 15:08:40 -0700

It also depends on how extensions will work, looking forward to read -09.

If extensions are namespaced somehow then you could ignore unknown
extension but be strict with core parameters (those would be
parameters with no namespace) and with known extensions.

Marius

On Mon, Jun 28, 2010 at 3:01 PM, Yaron Goland <[email-masked]> wrote:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Ian McKellar <[email-masked]>
Date: Tue, 29 Jun 2010 11:32:45 +1200

If we define that unrecognized arguments / elements are ignored then
we can define extensions such that if their arguments / elements are
ignored they don't introduce insecurity.

Ian

-- 
Ian McKellar  <http://ian.mckellar.org/>
[email-masked]: email | jabber | msn
ianloic: flickr | aim | yahoo | skype | linkedin | etc.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 28 Jun 2010 17:59:40 -0700

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?

                Thoughts?

                                Thanks,

                                                Yaron

---

From: David Recordon <[email-masked]>
Date: Mon, 28 Jun 2010 18:11:28 -0700

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

On Mon, Jun 28, 2010 at 5:59 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> 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?
>
>
>
> 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?
>
>
>
> 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: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 28 Jun 2010 18:17:13 -0700

There are times when the client wants the server to fail if it doesn't support an extension. The 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.

This clearly belongs in the 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 replace the client_id parameter with something else, making a server unaware of this extension fail (because the required client_id parameter will be missing).

EHL

From: David Recordon [mailto:[email-masked]]
Sent: Monday, June 28, 2010 6:11 PM
To: Eran Hammer-Lahav
Cc: Yaron Goland; OAuth WG ([email-masked])
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 missing something?

On Mon, Jun 28, 2010 at 5:59 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
There are 3 general ways to deal with this:

EHL

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Yaron Goland
Sent: Monday, June 28, 2010 3:02 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses?

                Thoughts?

                                Thanks,

                                                Yaron

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 28 Jun 2010 22:43:38 -0400

I agree.

I think we indeed should clearly articulate the use cases driving 
discovery (maybe Zachary could report on those?), but I also think that 
we will probably need to get something like "procedures," which describe 
expected usages, within the protocol specification. For one thing, all 
extensions whose support is essential under specific circumstances 
should be described listing such circumstances and recommending the 
action. (I also think that the idea of specifying pre- and post- 
conditions in use cases will help.)

Igor

Eran Hammer-Lahav wrote:
>
> There are times when the client wants the server to fail if it doesn’t 
> support an extension. The 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.
>
> This clearly belongs in the 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 replace the client_id parameter with something 
> else, making a server unaware of this extension fail (because the 
> required client_id parameter will be missing).
>
> EHL
>
> *From:* David Recordon [mailto:[email-masked]]
> *Sent:* Monday, June 28, 2010 6:11 PM
> *To:* Eran Hammer-Lahav
> *Cc:* Yaron Goland; OAuth WG ([email-masked])
> *Subject:* Re: [OAUTH-WG] How do we deal with unrecognized elements in 
> requests and responses?
>
> On Mon, Jun 28, 2010 at 5:59 PM, Eran Hammer-Lahav 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> 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).
>
> 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]> 
> [mailto:[email-masked] <mailto:[email-masked]>] *On 
> Behalf Of *Yaron Goland
> *To:* [email-masked] <mailto:[email-masked]>
> 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.
>
> section all the ways that the ignore rule can go wrong if extensions 
> aren’t handled carefully.
>
> Thoughts?
>
> Thanks,
>
> Yaron
>
>
> [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Yaron Goland <[email-masked]>
Date: Tue, 29 Jun 2010 19:32:31 +0000

Personally I think we should go with #2.

Those who need 'mandatory 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.

                                Just my two cents,

                                                Yaron

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

EHL

EHL

                Thoughts?

                                Thanks,

                                                Yaron

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Wed, 30 Jun 2010 17:24:16 -0500

Igor,

Discovery of the address needed for obtaining the client credentials, the end-user authorization endpoint, and the token endpoint is common for many use cases, where a client does not have this information. I am not aware of the use cases with the specific requirements for discovery.

Zachary 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Faynberg
Sent: Monday, June 28, 2010 10:44 PM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses?

I agree.

Igor

Eran Hammer-Lahav wrote:
>
> There are times when the client wants the server to fail if it doesn't 
> 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 
> 1. Break on unrecognized parameters - this tends to make the use of 
> 2. Ignore unrecognized parameters - this is the usual way of dealing 
> 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 
> it do? Should it reject the request since it doesn't recognize 
> a JSON member with some unrecognized name. What's the right behavior? 
> extensions. Typically the rule is 'ignore what you don't recognize' 
> "security is different". Typically ignoring unrecognized elements in a 
> aren't handled carefully.
>
> Thoughts?
>
> Thanks,
>
> Yaron
>
>

---

From: Robert Sayre <[email-masked]>
Date: Wed, 30 Jun 2010 20:03:33 -0700

On Mon, Jun 28, 2010 at 6:17 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> support an extension.

Implementations that have such requirements also have the option of
making a new protocol that shares a lot of code with OAuth.

How much feature negotiation to allow in a protocol can be a tough
question, but it's probably not a goal to allow any combination of
mandatory extensions to be called "OAuth".

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."