Re: [OAUTH-WG] oauth-meta: turi allows user to mislead app

"Nat Sakimura" <n-sakimura@nri.co.jp> Thu, 28 January 2016 04:02 UTC

Return-Path: <n-sakimura@nri.co.jp>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442951B323E for <oauth@ietfa.amsl.com>; Wed, 27 Jan 2016 20:02:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.909
X-Spam-Level: ***
X-Spam-Status: No, score=3.909 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vr68b_gajqZB for <oauth@ietfa.amsl.com>; Wed, 27 Jan 2016 20:02:11 -0800 (PST)
Received: from nrifs04.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EADF1B323F for <oauth@ietf.org>; Wed, 27 Jan 2016 20:02:10 -0800 (PST)
Received: from nriea03.index.or.jp (unknown [172.19.246.38]) by nrifs04.index.or.jp (Postfix) with SMTP id A4F90472EE0; Thu, 28 Jan 2016 13:02:09 +0900 (JST)
Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea03.index.or.jp (unknown) with ESMTP id u0S429oN029023; Thu, 28 Jan 2016 13:02:09 +0900
Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u0S429SF033086; Thu, 28 Jan 2016 13:02:09 +0900
Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u0S42995033085; Thu, 28 Jan 2016 13:02:09 +0900
X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf13.index.or.jp ([172.100.25.22]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u0S4298H033082; Thu, 28 Jan 2016 13:02:09 +0900
From: "Nat Sakimura" <n-sakimura@nri.co.jp>
To: "'Manger, James'" <James.H.Manger@team.telstra.com>, <oauth@ietf.org>
References: <255B9BB34FB7D647A506DC292726F6E13BB6E3B8E0@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BB6E3B8E0@WSMSG3153V.srv.dir.telstra.com>
Date: Thu, 28 Jan 2016 13:02:10 +0900
Message-ID: <056601d15980$a996bfd0$fcc43f70$@nri.co.jp>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0567_01D159CC.1980FFE0"
X-Mailer: Microsoft Outlook 15.0
X-MailAdviser: 20141126
Thread-Index: AQI8p81KlwM1SsaMd83m7w23juHIdp45pfZA
Content-Language: ja
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/cFOMHfoBc4YPQIq1K5iVv5oXjSk>
Subject: Re: [OAUTH-WG] oauth-meta: turi allows user to mislead app
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 28 Jan 2016 04:02:14 -0000

Hi James, 

 

Right. I thought of the man-in-the-browser case and was originally thinking
of sending them in signed JWT(state,c_hash,a_hash,turi,ruri,duri,.) or
sending HMAC(sha256, state+code+turi+ruri, client_secret) together but
subsequently dropped the idea as anything is broken in the
man-in-the-browser case. The bad user case did not occur to me then. I
should not have dropped the idea. Incidentally, this probably fixes the
cut-n-paste attack as well. For OpenID Connect, it amounts to returning
these parameters in ID Token in the front channel. As you can expect, this
is my preferred way. 

 

If we do not want any crypto, then there has to be additional checks. 

In case of duri, mandating the client to check that the duri = issuer +
.well-known/openid-configuration. 

For turi, it has to match one of the entry listed in the discovery document
or or pre-set configuration. The same applies for ruri. 

We probably want to have a cut-n-paste attack control in place as well. 

 

For the token endpoint response that does not go through user browser, it
should be ok to accept it as true. 

 

--

PLEASE READ :This e-mail is confidential and intended for the

named recipient only. If you are not an intended recipient,

please notify the sender  and delete this e-mail.

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Manger, James
Sent: Thursday, January 28, 2016 11:38 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] oauth-meta: turi allows user to mislead app

 

The OAuth-Meta draft <draft-sakimura-oauth-meta-05> returns the token
endpoint (in a "turi" query parameter) when redirecting a user from the
authorization endpoint back to an app. The app presumably then POSTs the
"code" (also in the redirect) to "turi" to get an access token. However,
apps typically send their client_secret to the token endpoint to
authenticate. Sending a client_secret to a URI that came from a user is
insecure.

 

A RESTful OAuth would be a great improvement, but it doesn't look like
providing the token endpoint (nor discovery endpoint) in a redirect is the
right approach.

 

--

James Manger