Re: [OAUTH-WG] Report an authentication issue

John Bradley <ve7jtb@ve7jtb.com> Fri, 29 June 2012 19:16 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 D42E021F8883 for <oauth@ietfa.amsl.com>; Fri, 29 Jun 2012 12:16:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.46
X-Spam-Level:
X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 81VC0Sdy-1xs for <oauth@ietfa.amsl.com>; Fri, 29 Jun 2012 12:16:34 -0700 (PDT)
Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8A621F8885 for <oauth@ietf.org>; Fri, 29 Jun 2012 12:16:34 -0700 (PDT)
Received: by ggnc4 with SMTP id c4so3419763ggn.31 for <oauth@ietf.org>; Fri, 29 Jun 2012 12:16:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=zOUMe6wRbRgPWvgkUcyR3OaTGUbbcFiF8uEPJtEJspY=; b=BDL3IbQaXCQf1+wzPFDXm4s4W3xritDROWJIw5MnreqOJZCNHekvlixA0OW42noHCR 4uW5s/o2cGNRgdr5f+eS1q/qVIvEX8VDF1Bz0XoLK5X7ARjea0hvgqcmgZV3vtB9MgSr /KrShu86FYSSaM6q2spFekQCW4ZKanBTS/2BpOHMtve5Bp/VUPgA0udCraaBcHZpQ7Rl IBGZE5VTFFuOb8c664E+WPCr7NjXPTbq+kAfBtBuGgA4e4PuAPowgicZcYZ2XZ6Eksp1 xgtxHvNkdFuIkrc1uGKj9IEA+2UVrTJUNu591UWiENRWv8oyzARPn9uSIS1vZrx8d2IH kAMw==
Received: by 10.236.156.5 with SMTP id l5mr4579414yhk.94.1340997394176; Fri, 29 Jun 2012 12:16:34 -0700 (PDT)
Received: from [192.168.1.211] (190-20-59-251.baf.movistar.cl. [190.20.59.251]) by mx.google.com with ESMTPS id c12sm3994464ank.14.2012.06.29.12.16.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 12:16:33 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/signed; boundary="Apple-Mail=_AB6E7700-E217-4574-916A-01DFFA095E43"; protocol="application/pkcs7-signature"; micalg="sha1"
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <353091D2-F63F-4D48-A49B-99E53FE31954@oracle.com>
Date: Fri, 29 Jun 2012 15:16:25 -0400
Message-Id: <7ED8AA4B-85D0-4D60-AFB6-C50503042A52@ve7jtb.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> <71899C6B-40A6-46E8-BCF8-BF9C43B83C64@oracle.com> <83124DF5-8D21-4D63-9D37-BBFBA0932065@ve7jtb.com> <353091D2-F63F-4D48-A49B-99E53FE31954@oracle.com>
To: Phil Hunt <phil.hunt@oracle.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQmiF388tkA6zlWKSEB87ZQxjoG+apojU2XodRWUmp922BVEITyerqvpkTn/KVW97FDdpVEV
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 19:16:36 -0000

The same thing can be done with code.

If the token endpoint checks the client_id before giving out the access token then the attack on code can be prevented, as the token endpoint won't return the access token.

The spec dosen't require authenticating public clients currently so it is a slightly more difficult attack but possible.

Dick and I are suggesting closing the hole at the token endpoint so that nether confidential nor public clients using the code flow are susceptible to this substitution attack.

John B.

On 2012-06-29, at 2:53 PM, PhiIt helps with the code flow when l Hunt wrote:

> I'm not seeing how client id helps if a proxy server is somehow involved with inserting the bearer token as the researchers suggested. 
> 
> Phil
> 
> On 2012-06-29, at 11:30, John Bradley <ve7jtb@ve7jtb.com> wrote:
> 
>> I think they only exploited the implicit flow.   
>> 
>> My point was that there is a way you could do the same thing with code if it is a public client that is not authenticating to the token endpoint.
>> 
>> In general making identity assumptions in the client based on a code or access_token has risks that are out of scope for OAuth.
>> 
>> We do however want to provide good advice about specific things that can leave systems insecure when using OAuth.
>> 
>> John B.
>> 
>> On 2012-06-29, at 2:22 PM, Phil Hunt wrote:
>> 
>>> 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
>>> 
>>