IETF Logo Mail Archive

Re: [OAUTH-WG] Ignoring unrecognized request parameters

Eran Hammer <eran@hueniverse.com> Thu, 16 February 2012 23:09 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 2A78221E8029 for <oauth@ietfa.amsl.com>; Thu, 16 Feb 2012 15:09:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.512
X-Spam-Level:
X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.086, 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 xMw01lxC9UxX for <oauth@ietfa.amsl.com>; Thu, 16 Feb 2012 15:08:58 -0800 (PST)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id A086E21E8051 for <oauth@ietf.org>; Thu, 16 Feb 2012 15:08:57 -0800 (PST)
Received: (qmail 5197 invoked from network); 16 Feb 2012 23:08:56 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Feb 2012 23:08:53 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 16 Feb 2012 16:08:51 -0700
From: Eran Hammer <eran@hueniverse.com>
To: Mike Jones <Michael.Jones@microsoft.com>, "oauth@ietf.org" <oauth@ietf.org>
Date: Thu, 16 Feb 2012 16:09:08 -0700
Thread-Topic: [OAUTH-WG] Ignoring unrecognized request parameters
Thread-Index: Aczs//EtdmyQc80jSnWWdPtNtKkeyw==
Message-ID: <CB62CBC6.12FF9%eran@hueniverse.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943663A7EA2@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CB62CBC612FF9eranhueniversecom_"
MIME-Version: 1.0
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, 16 Feb 2012 23:09:02 -0000

The change came from multiple feedback provided from AD and other reviews. MUST is required to guarantee forward compatibility with future extensions. This was a known issue in 1.0 when some clients added body_hash support and caused servers to fail for no reason.

A server that is unaware of a new extension will remain at the same security level if ignoring unknown extensions. The server can require new extensions. Please demonstrate how this can lead to a less secure implementation.

EH

From: Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>>
Date: Thu, 16 Feb 2012 11:16:04 -0700
To: "oauth@ietf.org<mailto:oauth@ietf.org>" <oauth@ietf.org<mailto:oauth@ietf.org>>
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

v2.23.0 | Report a Bug | By Email