Re: [OAUTH-WG] Ignoring unrecognized request parameters

Eran Hammer <eran@hueniverse.com> Thu, 08 March 2012 02:12 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B9321E8061 for <oauth@ietfa.amsl.com>; Wed, 7 Mar 2012 18:12:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.534
X-Spam-Level:
X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wQw66JDuyCh for <oauth@ietfa.amsl.com>; Wed, 7 Mar 2012 18:12:54 -0800 (PST)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 09E1E21E8053 for <oauth@ietf.org>; Wed, 7 Mar 2012 18:12:54 -0800 (PST)
Received: (qmail 4788 invoked from network); 8 Mar 2012 00:18:04 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Mar 2012 00:18:01 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Wed, 7 Mar 2012 17:17:39 -0700
From: Eran Hammer <eran@hueniverse.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Date: Wed, 07 Mar 2012 17:17:31 -0700
Thread-Topic: [OAUTH-WG] Ignoring unrecognized request parameters
Thread-Index: AczulspwqLx1aonfQmGsGNazNyaP+gOKfa9A
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFCD407C@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <CB62CAAF.12FF3%eran@hueniverse.com> <B02AAED0-795F-4D5A-A487-A19B6933C3B6@ve7jtb.com>
In-Reply-To: <B02AAED0-795F-4D5A-A487-A19B6933C3B6@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453AFCD407CP3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Ignoring unrecognized request parameters
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2012 02:12:57 -0000

Our "mustUnderstand" is extension grant types. Define a new one and everything will break if the server doesn't understand something as defined by the new grant type spec.

EH

From: John Bradley [mailto:ve7jtb@ve7jtb.com]
Sent: Saturday, February 18, 2012 3:41 PM
To: Eran Hammer
Cc: William Mills; oauth@ietf.org
Subject: Re: [OAUTH-WG] Ignoring unrecognized request parameters

It is a general problem with security protocols like SOAP, SAML, X.509.

Sometimes when you define an extension you want to be certain that the Authorization server understands it,  or you want an error.

As an example if someone did a authentication context extension (Not proposing it just an example).   They would perhaps rather have an error if the Authorization server did not understand the extension,  they could then retry without the extension if that worked for them.

This is generally dealt with by marking something as mustUnderstand<http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383500> in SOAP or critical in x.509.

Without that functionality (I am not asking to add it) it may be reasonable for some Authorization servers to return an error if they do not completely understand what is being sent to them.

One school of thought feels that anything you don't understand in a message could be an indication of a problem or tampering.

I am sympathetic to the Forward compatibility argument,  however without some sort of mustUnderstand semantics it is not going to always work.

One thing that might help is an error message to indicate that it is being rejected due to unknown extensions so a client can retry.

John B.


On 2012-02-16, at 8:01 PM, Eran Hammer wrote:


Can you give an example where an unknown parameter being ignored can lead to security issues?

EH


From: John Bradley <ve7jtb@ve7jtb.com<mailto:ve7jtb@ve7jtb.com>>
Date: Thu, 16 Feb 2012 11:55:21 -0700
To: William Mills <wmills@yahoo-inc.com<mailto:wmills@yahoo-inc.com>>
Cc: "oauth@ietf.org<mailto:oauth@ietf.org>" <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Ignoring unrecognized request parameters

If you have a generic client that works across multiple Authorization endpoints some that have extension X and others not, I can see that having the Authorization servers ignore unknown parameters is desirable.

However there are some endpoints that are not going to be able to allow unknown parameters due to there security policy.   They are often a indication of an attack.

If this remains a MUST then some endpoints will have to ignore it, and be non compliant.

I would be OK with something like "MUST ignore unknown parameters unless the endpoint is required to return an error due to local security policy."

There is probably no perfect compromise on this one.

John B.


On 2012-02-16, at 3:32 PM, William Mills wrote:


No, this is required for forward compatibility.  Implementations that send extended parameters like capability advertisements (i.e. CAPTCHA support or something) shoudl not be broken hitting older implementations.

________________________________
From: Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>>
To: "oauth@ietf.org<mailto:oauth@ietf.org>" <oauth@ietf.org<mailto:oauth@ietf.org>>
Sent: Thursday, February 16, 2012 10:16 AM
Subject: [OAUTH-WG] Ignoring unrecognized request parameters

In core -23, the last paragraph of section 3.1<http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-3.1> now says:

                The authorization server MUST ignore unrecognized request parameters.

In -22, this said:

                The authorization server SHOULD ignore unrecognized request parameters.

In a security protocol, it seems unreasonable to require that information be ignored.  As I see it, it SHOULD be legal to return an error if unrecognized information is received.

Why the change?  And can we please have it changed back to SHOULD in -24?

                                                                Thanks,
                                                                -- Mike


_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth