Re: [OAUTH-WG] Report an authentication issue

John Bradley <ve7jtb@ve7jtb.com> Fri, 29 June 2012 18:06 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 0286621F8831 for <oauth@ietfa.amsl.com>; Fri, 29 Jun 2012 11:06:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.445
X-Spam-Level:
X-Spam-Status: No, score=-3.445 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 pPXmmZgo46Ff for <oauth@ietfa.amsl.com>; Fri, 29 Jun 2012 11:06:54 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A6B7F21F8821 for <oauth@ietf.org>; Fri, 29 Jun 2012 11:06:54 -0700 (PDT)
Received: by yenq13 with SMTP id q13so3342726yen.31 for <oauth@ietf.org>; Fri, 29 Jun 2012 11:06:54 -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=esRoBC0aH4zwAeVDBLItHDcx/ufo22zrCN1WF4PQAws=; b=iovvqkZE4UHd6UgQKTkKrlHciPcWDvPolOjvgM4ejiQkpdcpj/dR33F7o+0gPC3S2G hWo22olFU90v3FtqSib/2E2PArAyTMJfFW2IlC0/uGuwzOBGQ15PPqCysCK0zMMuAhb5 2awETztpXi5NlN/m9mKvWK2lKkHskxAl4wySjMq0Wp38K6t2tlKvvU5rYEBOThP9P2VO XTDO9iC9d6CQLYHmvGuoZ5gC6e/3KI0rVD1itvByPu/kOTlA96di9BEwRnb0CSLfgBUr jU+7M8ByV8paRsJYHqP/Y6uNqV44Hl6douS8D124JrpnRz89AlZCHWZZAJ3F5YPjxKAl dnQw==
Received: by 10.236.192.162 with SMTP id i22mr4256744yhn.83.1340993214189; Fri, 29 Jun 2012 11:06:54 -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 e19sm3735455ann.10.2012.06.29.11.06.51 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 11:06:53 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/signed; boundary="Apple-Mail=_9ED9E059-97AB-4048-9D3A-1BBC9C6F9425"; protocol="application/pkcs7-signature"; micalg="sha1"
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <4FEDE4AF.9030107@mitre.org>
Date: Fri, 29 Jun 2012 14:06:44 -0400
Message-Id: <4DD23AA1-C319-477A-B0CB-34E558EB7FCC@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>
To: Justin Richer <jricher@mitre.org>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQmXJiVwIrLuaIXwqSWUtJgpT4qZBkY+455NPtmchCmPMcX/DU9WaRHR6GDTrAU1ACdtfLT5
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:06:56 -0000

It is nice to know that I may occasionally be correct:)

For Server based confidential clients the risks are quite minimal as Justin points out.   There are likely other more interesting things you could do if you already have the ability to run arbitrary code on the server.

No matter what flow or client you are using, passing the access token from that client to some other server as a method of authentication is not a good idea unless you have some way to guarantee that it is a legitimate client that hasn't been compromised.   Creating a fake App with a stolen client ID is trivial.   So passing access tokens as a proxy for authentication between unauthenticated apps is a recopy for disaster.
It sort of falls under the category of bad things that can happen if you just make up new flows for tokens that are not in the spec.

Where it gets a bit grey is public clients using the code flow.  
If you look at Sec 3.2.1 only confidential clients Must Authenticate to the token endpoint.

A public client like a native app:
A public client that was not issued a client password MAY use the
   "client_id" request parameter to identify itself when sending
   requests to the token endpoint (e.g. for the purpose of providing
   end-user context, client usage statistics).

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 it has to do with the precept of threat.

If you are simply using OAuth strictly for Authorization then it would make mo sense for an attacker who gets a valid code to not use it directly to access the protected resource.

However if you can escalate the codes privilege by impersonating the resource owner at a legitimate public client then an attacker might do it to get into another system.

So if the public client is perhaps vulnerable.  Now I can't imagine someone running a public client on a web server, but this would be a good reason not to.  
In general the public client would be a native app, and not easy to inject a stolen code into.

I don't have a explanation as to why public clients using the code flow are not minimally identified via their client_id.  
I suspect most implementations are doing that if they have public clients using the code flow, but I have not tested that theory.

So the code flow is safer but there are some things you need to be careful of with any public client.

John B.

On 2012-06-29, at 1:23 PM, Justin Richer wrote:

> It's all about how you can swipe a token and inject it into another application. It's easier to trap and inject a token in the implicit flow because it's exposed to the user agent and there's no client secret tied to the token's issuance. To get the same trick to work with the code flow on server-based confidential clients, you'd need to inject your rogue token into the client's configuration or state. With the implicit flow and on devices, it's a bit easier just because the parts of the system that need access to the token are more accessible.
> 
> -- Justin
> 
> On 06/29/2012 12:53 PM, Antonio Sanso wrote:
>> Hi John
>> 
>> On Jun 29, 2012, at 1:43 AM, John Bradley wrote:
>> 
>>> Authenticating to the client is NOT safe with all of the flows
>> you are perfectly right here. At the begin of this discussion and reading your blog post I was under the impression that this "attack" was tight to the use of the implicit grant flaw.
>> But this is not actually the case as I could reproduce the same scenario against a client using the Authorization Code flaw.
>> 
>> Regards
>> 
>> Antonio
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
>