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 4D73521F8880 for ; Mon, 12 Dec 2011 17:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.426 X-Spam-Level: X-Spam-Status: No, score=-17.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 6Q+ytUnqZSUy for ; Mon, 12 Dec 2011 17:47:02 -0800 (PST) Received: from nm15-vm0.bullet.mail.ac4.yahoo.com (nm15-vm0.bullet.mail.ac4.yahoo.com [98.139.52.236]) by ietfa.amsl.com (Postfix) with SMTP id 40FBB21F84FB for ; Mon, 12 Dec 2011 17:47:02 -0800 (PST) Received: from [98.139.52.197] by nm15.bullet.mail.ac4.yahoo.com with NNFMP; 13 Dec 2011 01:46:55 -0000 Received: from [98.139.52.140] by tm10.bullet.mail.ac4.yahoo.com with NNFMP; 13 Dec 2011 01:46:54 -0000 Received: from [127.0.0.1] by omp1023.mail.ac4.yahoo.com with NNFMP; 13 Dec 2011 01:46:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 947166.72833.bm@omp1023.mail.ac4.yahoo.com Received: (qmail 98999 invoked by uid 60001); 13 Dec 2011 01:46:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1323740814; bh=Tf3rA7FgZ6fzcWPKs0dUbbCYgobvA2QkgTcUHCIKKFQ=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=S+I/IeUxD0x8Tlu10CuXeegDAGcRsXV9zetTiSxHWWDw4nDpv+aNFUTzddLQ1zexPV11WqWO5eZxCro35RWJvGOqfSflkyy3lEbuLqgs4XsuIu8/Y5QmYw0B8u+NEItho18/TQsttUHYEeAYkvQ9nAXRmGzdfWnsnDh8Lwi0liE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=V1Yi/mDtNJO5FrqR238mTWkj5Rx1itam4crh0JhtqCkSU+QrYwlcrPqQ6H+fM8aU0tbtPkLMqkDbxGuZoeouDgdoc1LFHFCSR30sZ3lPtXBzj2gB0YXnf95dZX3PmDlkstF+sBFb0B1+yXC0iQ4HMrcQSMg6pNBSKO9zb2jLH20=; X-YMail-OSG: p96UtzsVM1kas6XakJnkIi2QmSTgrSfQ_KDpni87.eYROE5 EiyIrpOY58tB5ltG2_OoRtzkIst1jlZUBEvsFf7X8o5e0SB3e6V7XwBmnYEC gmCSDhXuikvz97Ca1BiyGF1YBANSqRlamSq8kxXYVY1ZaqJ24xZxxLYc0jd. ZRn494mS_e3uZ.d41NY.gijBn5GThpbW5npuIcPaixFACpcGg7E54UIE0A27 DA7dkpzBMHuOpT8Qs8qn4vLwEjcBX5VhoiHMxymsJK6a_0vT_NzdEsaQHRnf r0fy088aNJKGbadvXxxMGBe3drV4AT1FH3FWfsK9jNv67vE7E4VoFOns043F 7DiZTe5kySu123dPrbDMLELHlr33h2FjHiYfCzYrP4pigu5uuLQwMQSurwTn 1BgzyRmEVVRmKJ9x1ZsmPHTgj4iLUhtY8jNE- Received: from [209.131.62.113] by web31816.mail.mud.yahoo.com via HTTP; Mon, 12 Dec 2011 17:46:54 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <8DA2949DB77C2547B14546D35E22A20002D328EC@CH1PRD0302MB127.namprd03.prod.outlook.com> <4E1F6AAD24975D4BA5B16804296739435F75FBF7@TK5EX14MBXC283.redmond.corp.microsoft.com> Message-ID: <1323740814.90630.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Mon, 12 Dec 2011 17:46:54 -0800 (PST) From: William Mills To: Mike Jones , "oauth@ietf.org" In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435F75FBF7@TK5EX14MBXC283.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-1519221104-1323740814=:90630" 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 Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 01:47:03 -0000 ---1238014912-1519221104-1323740814=:90630 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I don't think the leak of client IDs is a big issue, in any cleartext proto= col you can just sniff them.=A0 We don't mandate SSL on the protected resou= rces.=0A=0A=0AAnyone relying on ClientID for a stronger assurance will want= to be using SSL and an unguessable ID anyway.=0A=0A=0A=0A_________________= _______________=0A From: Mike Jones =0ATo: "oa= uth@ietf.org" =0ASent: Monday, December 12, 2011 4:51 PM= =0ASubject: [OAUTH-WG] Using OAuth error_code to glean information from the= server=0A =0A=0A =0AI recently received an inquiry regarding invalid_clien= t vs. invalid_grant. =A0It seems that there is a potential information disc= losure in the specification with respect to how these error codes are used:= =0A=A0=0Ainvalid_client=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Client= authentication failed (e.g. unknown client, no=0A=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 client authentication included, or unsupported=0A=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 authentication method).=A0 The authori= zation server MAY=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return an HT= TP 401 (Unauthorized) status code to indicate=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 which HTTP authentication schemes are supported.=A0 If the= =0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 client attempted to authentic= ate via the "Authorization"=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 re= quest header field, the authorization server MUST=0A=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 respond with an HTTP 401 (Unauthorized) status code, = and=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 include the "WWW-Authentic= ate" response header field=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 mat= ching the authentication scheme used by the client.=0Ainvalid_grant=0A=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The provided authorization grant (e= .g. authorization=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 code, resour= ce owner credentials, client credentials) is=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 invalid, expired, revoked, does not match the redirection= =0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 URI used in the authorization= request, or was issued to=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ano= ther client.=0A=A0=0AIf 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.=0A=A0=0AFirst, do = people agree that this is a potential information leak and that the leak is= meaningful?=A0 If so, what mitigation might be suggested?=A0 For instance,= might a server choose to use a single error code for both (and potentially= other) cases?=0A=A0=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Thanks,=0A=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike=0A=A0=0A___________________________________________= ____=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/l= istinfo/oauth ---1238014912-1519221104-1323740814=:90630 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I don't think the leak of client IDs is a big issue, in any cleartext pro= tocol you can just sniff them.  We don't mandate SSL on the protected = resources.

Anyone re= lying on ClientID for a stronger assurance will want to be using SSL and an= unguessable ID anyway.

From: Mike Jones <Michael.Jones= @microsoft.com>
To:= "oauth@ietf.org" <oauth@ietf.org>
Sent: Monday, December 12, 2011 4:51 PM
Subject: [OAUTH-WG] Using OAuth error_= code to glean information from the server
=0A
=0A=0A =0A =0A=0A=0A
=0A=0A
I recently received an in= quiry regarding invalid_client vs. invalid_grant.  It seems that there= is a potential information disclosure in the specification with=0A respect= to how these error codes are used:
=0A
&= nbsp;
=0A
invalid_client
=0A
    &= nbsp;          Client authenti= cation failed (e.g.=0Aunknown client, no
=0A
  &nb= sp;            clien= t authentication included, or unsupported
=0A
         &n= bsp;     authentication method).  The authorizatio= n server MAY
=0A
 &nbs= p;             = return an HTTP 401 (Unauthorized) status code to indicate
=0A<= div class=3D"yiv999268650MsoNormal" style=3D"margin-left:.5in;">      &nbs= p;        which HTTP authentication sche= mes are supported.  If the
=0A
           =     client attempted to authenticate via the "Authorization"=
=0A
   &nbs= p;           request head= er field, the authorization server MUST
=0A
         &nbs= p;     respond with an HTTP 401 (Unauthorized) status c= ode, and
=0A
  &n= bsp;            incl= ude the "WWW-Authenticate" response header field
=0A
        &= nbsp;      matching the authentication scheme used= by the client.
=0A
invalid_grant
=0A
      &nb=
sp;        The provided authorization gr=
ant (e.g. authorization
=0A
        =
       code, resource owner credentials, client credentials) is
= =0A
 &nbs=
p;             =
invalid, expired, revoked, does not match the redirection
=0A<= pre style=3D"margin-left:.5in;">  &n= bsp;            URI = used in the authorization request, or was issued to =0A
   &n=
bsp;           another cl=
ient.
=0A
 
=0A
If one us= es invalid_client when the client is unknown and invalid_grant when the cli= ent credentials are invalid, then an attacker could deduce whether or not= =0A a particular client exists.
=0A
  =0A
First, do people agree that this is a potential informatio= n leak and that the leak is meaningful?  If so, what mitigation might = be suggested?  For instance,=0A might a server choose to use a single = error code for both (and potentially other) cases?
=0A
 
=0A
      &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   Thanks,
=0A
    =             &nb= sp;            =             &nb= sp;            =       -- Mike
=0A
 
=0A
=0A
=0A=0A

______________________________= _________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.o= rg/mailman/listinfo/oauth


---1238014912-1519221104-1323740814=:90630--