Re: [OAUTH-WG] Ignoring unrecognized request parameters

John Bradley <ve7jtb@ve7jtb.com> Thu, 16 February 2012 18:55 UTC

Return-Path: <ve7jtb@ve7jtb.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 815B521E801F for <oauth@ietfa.amsl.com>; Thu, 16 Feb 2012 10:55:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.165
X-Spam-Level:
X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 m0sSZ0LOeVpa for <oauth@ietfa.amsl.com>; Thu, 16 Feb 2012 10:55:26 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C83121E8018 for <oauth@ietf.org>; Thu, 16 Feb 2012 10:55:26 -0800 (PST)
Received: by yhkk25 with SMTP id k25so1649449yhk.31 for <oauth@ietf.org>; Thu, 16 Feb 2012 10:55:25 -0800 (PST)
Received: by 10.236.9.33 with SMTP id 21mr5164065yhs.39.1329418525746; Thu, 16 Feb 2012 10:55:25 -0800 (PST)
Received: from [192.168.1.213] (186-107-144-162.baf.movistar.cl. [186.107.144.162]) by mx.google.com with ESMTPS id h29sm11063948ann.16.2012.02.16.10.55.23 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Feb 2012 10:55:24 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_5E29FD83-6240-4E6F-8234-1B2EE6D2ADEA"; protocol="application/pkcs7-signature"; micalg="sha1"
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <1329417179.41387.YahooMailNeo@web31809.mail.mud.yahoo.com>
Date: Thu, 16 Feb 2012 15:55:21 -0300
Message-Id: <95549D89-B2AB-4A40-96CE-C689DB07BF88@ve7jtb.com>
References: <4E1F6AAD24975D4BA5B1680429673943663A7EA2@TK5EX14MBXC284.redmond.corp.microsoft.com> <1329417179.41387.YahooMailNeo@web31809.mail.mud.yahoo.com>
To: William Mills <wmills@yahoo-inc.com>
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQkWgNxiGIf8jKk1K623oCiDy3A6H6xDozx3HkmqMCI3DFEcW1iInqc3qxffrzo136+/ncsm
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, 16 Feb 2012 18:55:30 -0000

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>
> To: "oauth@ietf.org" <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 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
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth