Re: [OAUTH-WG] Using OAuth error_code to glean information from the server
Shane B Weeden <sweeden@au1.ibm.com> Tue, 13 December 2011 03:11 UTC
Return-Path: <sweeden@au1.ibm.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 A589321F8532 for <oauth@ietfa.amsl.com>; Mon, 12 Dec 2011 19:11:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 E5b8JRGIWbY1 for <oauth@ietfa.amsl.com>; Mon, 12 Dec 2011 19:11:15 -0800 (PST)
Received: from e23smtp01.au.ibm.com (e23smtp01.au.ibm.com [202.81.31.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5162521F851F for <oauth@ietf.org>; Mon, 12 Dec 2011 19:11:14 -0800 (PST)
Received: from /spool/local by e23smtp01.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <oauth@ietf.org> from <sweeden@au1.ibm.com>; Tue, 13 Dec 2011 03:06:36 +1000
Received: from d23relay03.au.ibm.com ([202.81.31.245]) by e23smtp01.au.ibm.com ([202.81.31.207]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 13 Dec 2011 03:06:33 +1000
Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pBD3B0Et4669620; Tue, 13 Dec 2011 14:11:03 +1100
Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pBD3B04A001976; Tue, 13 Dec 2011 14:11:00 +1100
Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pBD3B0ce001969; Tue, 13 Dec 2011 14:11:00 +1100
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435F75FBF7@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <8DA2949DB77C2547B14546D35E22A20002D328EC@CH1PRD0302MB127.namprd03.prod.outlook.com> <4E1F6AAD24975D4BA5B16804296739435F75FBF7@TK5EX14MBXC283.redmond.corp.microsoft.com>
X-KeepSent: EDA06529:6C841E9C-4A257965:000A00B5; type=4; name=$KeepSent
To: Mike Jones <Michael.Jones@microsoft.com>
X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010
Message-ID: <OFEDA06529.6C841E9C-ON4A257965.000A00B5-4A257965.00117996@au1.ibm.com>
From: Shane B Weeden <sweeden@au1.ibm.com>
Date: Tue, 13 Dec 2011 13:10:52 +1000
X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.2FP1HF437 | June 7, 2011) at 13/12/2011 14:14:59
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
x-cbid: 11121217-1618-0000-0000-0000004F1F42
Cc: "oauth@ietf.org" <oauth@ietf.org>, oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] Using OAuth error_code to glean information from the server
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: Tue, 13 Dec 2011 03:11:26 -0000
I don't think one can presume that client identifiers are any kind of secret particularly given that for web-based flows they are transmitted in browser redirects. The "meaningful"-ness of the information is debatable as on the other hand security best practices generally support the idea that the less an attacker can ascertain from error messages the better. From: Mike Jones <Michael.Jones@microsoft.com> To: "oauth@ietf.org" <oauth@ietf.org> Date: 13/12/2011 10:56 AM Subject: [OAUTH-WG] Using OAuth error_code to glean information from the server Sent by: oauth-bounces@ietf.org I recently received an inquiry regarding invalid_client vs. invalid_grant. It seems that there is a potential information disclosure in the specification with respect to how these error codes are used: invalid_client Client authentication failed (e.g. unknown client, no client authentication included, or unsupported authentication method). The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. If the client attempted to authenticate via the "Authorization" request header field, the authorization server MUST respond with an HTTP 401 (Unauthorized) status code, and include the "WWW-Authenticate" response header field matching the authentication scheme used by the client. invalid_grant The provided authorization grant (e.g. authorization code, resource owner credentials, client credentials) is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client. If one uses invalid_client when the client is unknown and invalid_grant when the client credentials are invalid, then an attacker could deduce whether or not a particular client exists. First, do people agree that this is a potential information leak and that the leak is meaningful? If so, what mitigation might be suggested? For instance, might a server choose to use a single error code for both (and potentially other) cases? Thanks, -- Mike _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] Using OAuth error_code to glean inform… Mike Jones
- Re: [OAUTH-WG] Using OAuth error_code to glean in… William Mills
- Re: [OAUTH-WG] Using OAuth error_code to glean in… Eran Hammer-Lahav
- Re: [OAUTH-WG] Using OAuth error_code to glean in… Shane B Weeden