Return-Path: 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 6C9F421F8485 for ; Mon, 12 Dec 2011 18:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.078, 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 Bi3L2cmVpnFW for ; Mon, 12 Dec 2011 18:33:21 -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 6DB0821F84A8 for ; Mon, 12 Dec 2011 18:33:16 -0800 (PST) Received: (qmail 10534 invoked from network); 13 Dec 2011 02:33:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 Dec 2011 02:33:15 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Mon, 12 Dec 2011 19:33:15 -0700 From: Eran Hammer-Lahav To: Mike Jones , "oauth@ietf.org" Date: Mon, 12 Dec 2011 19:33:10 -0700 Thread-Topic: [OAUTH-WG] Using OAuth error_code to glean information from the server Thread-Index: Acy5GRQ8DCUDRcpaSEuLOrJymTfgmAAF5PRwAAOQbdA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723452856C7C78@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <8DA2949DB77C2547B14546D35E22A20002D328EC@CH1PRD0302MB127.namprd03.prod.outlook.com> <4E1F6AAD24975D4BA5B16804296739435F75FBF7@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435F75FBF7@TK5EX14MBXC283.redmond.corp.microsoft.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_90C41DD21FB7C64BB94121FBBC2E723452856C7C78P3PW5EX1MB01E_" MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 02:33:23 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723452856C7C78P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 'Client credentials' needs to be removed from invalid_grant. It is not appr= opriate. Use invalid_client all the way to a fully authenticate client. ANY failure = to authenticate the client should result in invalid_client. Use unauthorized_client for an authenticate client which is not permitted t= o use this grant type. There are no other issues with an invalid grant rela= ted to client credentials. I'll drop it from the e.g. list. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Monday, December 12, 2011 4:52 PM To: oauth@ietf.org Subject: [OAUTH-WG] Using OAuth error_code to glean information from the se= rver I recently received an inquiry regarding invalid_client vs. invalid_grant. = It seems that there is a potential information disclosure in the specifica= tion 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 whe= n 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 t= he leak is meaningful? If so, what mitigation might be suggested? For ins= tance, might a server choose to use a single error code for both (and poten= tially other) cases? Thanks, -- Mike --_000_90C41DD21FB7C64BB94121FBBC2E723452856C7C78P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

‘Cl= ient credentials’ needs to be removed from invalid_grant. It is not a= ppropriate.

 

Use invalid_client all the way to= a fully authenticate client. ANY failure to authenticate the client should= result in invalid_client.

 

Use unauthorized_c= lient for an authenticate client which is not permitted to use this grant t= ype. There are no other issues with an invalid grant related to client cred= entials.

 =

I’ll drop it from the e.g. lis= t.

 

EHL

 

&nb= sp;

 

From: oauth-bounces@ietf.org [mail= to:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: M= onday, December 12, 2011 4:52 PM
To: oauth@ietf.org
Subject= : [OAUTH-WG] Using OAuth error_code to glean information from the serve= r

 

I recently received an inquiry regarding inva= lid_client vs. invalid_grant.  It seems that there is a potential info= rmation disclosure in the specification with respect to how these error cod= es are used:

 

invalid_client

&= nbsp;           &nbs= p;  Client authentication failed (e.g. unknown client, no

 &nbs= p;             = client authentication included, or unsupported

  &= nbsp;            aut= hentication method).  The authorization server MAY

= &nbs= p;            &= nbsp; return an HTTP 401 (Unauthorized) status code to indicate<= /span>

            = ;   which HTTP authentication schemes are supported.  If the=

          = ;     client attempted to authenticate via the "Au= thorization"

       =         request header field, the author= ization server MUST

      &nbs= p;        respond with an HTTP 401 (Unau= thorized) status code, and

     &n= bsp;         include the "WWW-= Authenticate" response header field

   &= nbsp;           matching = the authentication scheme used by the client.

invalid_grant
    &n=
bsp;          The provided aut=
horization grant (e.g. authorization
 =
;            &n=
bsp; code, resource owner credentials, client credentials) is
           &n= bsp;   invalid, expired, revoked, does not match the redirection<= o:p>
       =
        URI used in the authorization re=
quest, or was issued to
   =
            another =
client.

 

If one uses invalid_client when the= client is unknown and invalid_grant when the client credentials are invali= d, then an attacker could deduce whether or not a particular client exists.=

 <= /p>

First, do people agree that this is a potent= ial information leak and that the leak is meaningful?  If so, what mit= igation might be suggested?  For instance, might a server choose to us= e a single error code for both (and potentially other) cases?

 

         &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;            Tha= nks,

   &nb= sp;            =             &nb= sp;            =             &nb= sp;      -- Mike

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723452856C7C78P3PW5EX1MB01E_--