Re: [OAUTH-WG] Report an authentication issue

Phil Hunt <phil.hunt@oracle.com> Fri, 29 June 2012 18:22 UTC

Return-Path: <phil.hunt@oracle.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 2EA9A21F867A for <oauth@ietfa.amsl.com>; Fri, 29 Jun 2012 11:22:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.491
X-Spam-Level:
X-Spam-Status: No, score=-10.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 GWNyhT4o4FHJ for <oauth@ietfa.amsl.com>; Fri, 29 Jun 2012 11:22:46 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 05A0821F86A7 for <oauth@ietf.org>; Fri, 29 Jun 2012 11:22:45 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5TIMhQD027433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jun 2012 18:22:44 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q5TIMhh1008304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 18:22:43 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5TIMh8W011931; Fri, 29 Jun 2012 13:22:43 -0500
Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 29 Jun 2012 11:22:42 -0700
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <8C18C43D-AC63-465A-ADC2-966CE7F38685@gmail.com>
Date: Fri, 29 Jun 2012 11:22:42 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <71899C6B-40A6-46E8-BCF8-BF9C43B83C64@oracle.com>
References: <CAEEmcpEcNqNHwfVozD-NtfkruiB-v0MTszwNL4cob2rL=QQTSA@mail.gmail.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <CABzCy2CLe_DVcxiD1EasuhtG1_6+6tCtV5TckZ80fvqyjan_bA@mail.gmail.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <CABzCy2A_zJ3vaauoo6VwsmLWsTesdTujuQ4dHdVpc5Nh==iEFg@mail.gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <CABzCy2DzmNgmMALNfc1qp95fwD2WULb-49Dk yLiZnjXngAmaPg@mail.gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> <04C05FAA-63BC-4441-8540-36280E40DB98@adobe.com> <4FEDE4AF.9030107@mitre.org> <! 4 DD23AA1-C319-477A-B0CB-34E558EB7FCC@ve7jtb.com> <8C18C43D-AC63-465A-ADC2-966CE7F38685@gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
X-Mailer: Apple Mail (2.1278)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Report an authentication issue
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: Fri, 29 Jun 2012 18:22:47 -0000

I'm not clear whether the MS Security Researcher hack was with the authorization code or the access token. If the latter, the client_id is out of the picture isn't it?

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-06-29, at 11:14 AM, Dick Hardt wrote:

> 
> On Jun 29, 2012, at 11:06 AM, John Bradley wrote:
> 
>> It is nice to know that I may occasionally be correct:)
> 
> You must be delighted when it happens! ;)
> 
>> While you may assume that it is reasonable for a client with a code to make a request to the token endpoint including it's client_id and the server to only give out the access token if the client_id in the token request matches the one in the original authorization request.   However the spec specifically doesn't require that.
> 
> I think that is an error in the spec and should be changed, or text adding saying that the client_id SHOULD be checked.
> 
> -- Dick
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth