Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Torsten Lodderstedt <torsten@lodderstedt.net> Wed, 28 November 2018 22:38 UTC

Return-Path: <torsten@lodderstedt.net>
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 889DF13107A for <oauth@ietfa.amsl.com>; Wed, 28 Nov 2018 14:38:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 FLcTdC0A97ow for <oauth@ietfa.amsl.com>; Wed, 28 Nov 2018 14:38:08 -0800 (PST)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C41D124C04 for <oauth@ietf.org>; Wed, 28 Nov 2018 14:38:08 -0800 (PST)
Received: from [84.175.172.56] (helo=torstens-mbp.speedport_w_921v_1_44_000) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <torsten@lodderstedt.net>) id 1gS8T6-0002gZ-LF; Wed, 28 Nov 2018 23:38:04 +0100
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_D38A91DD-696F-4B78-B726-6D8D7C752A1C"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Wed, 28 Nov 2018 23:38:03 +0100
In-Reply-To: <OSBPR01MB2869E83F37046C7FCD4463DDF9D10@OSBPR01MB2869.jpnprd01.prod.outlook.com>
Cc: Dick Hardt <dick.hardt@gmail.com>, Hannes Tschofenig <hannes.tschofenig@arm.com>, "oauth@ietf.org" <oauth@ietf.org>
To: n-sakimura <n-sakimura@nri.co.jp>
References: <VI1PR0801MB211266BA6F6E06FFB3081425FAD80@VI1PR0801MB2112.eurprd08.prod.outlook.com> <CAD9ie-v3onmKc498cg_-a0AD58ZV=aZANtz=UV+Q0f=9N3nSzQ@mail.gmail.com> <OSBPR01MB2869E83F37046C7FCD4463DDF9D10@OSBPR01MB2869.jpnprd01.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.101.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/pG2Pk61GXQhkar4R5IAuwendWZ4>
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 28 Nov 2018 22:38:19 -0000

Hi Nat, 

> Am 28.11.2018 um 21:10 schrieb n-sakimura <n-sakimura@nri.co.jp>:
> 
> I would support
> 
> 1) clearly defining Implicit as the flow that returns access token from the authorization endpoint ( some people confuses implicit as the flow that returns ID Token in the front channel)

That’s the current text: 

In order to avoid these issues, Clients SHOULD NOT use the implicit
   grant or any other response type causing the authorization server to
   issue an access token in the authorization response.

What would you like to modify? 

> 
> 2) Banning the returning of the access token that are not sender constrained from the authorization endpoint

In order to avoid these issues, Clients SHOULD NOT use the implicit
   grant or any other response type causing the authorization server to
   issue an access token in the authorization response, if this access tokens is not sender-constraint.

What about this?

kind regards,
Torsten.

> 
> Best,
> 
> Nat
> 
> 
> Outlook for iOS を入手
>  
> 差出人: OAuth <oauth-bounces@ietf.org> (Dick Hardt <dick.hardt@gmail.com> の代理)
> 送信日時: 水曜日, 11月 28, 2018 8:58 午後
> 宛先: Hannes Tschofenig
> Cc: oauth@ietf.org
> 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
>  
> +1
> 
> While there are various mechanisms to alleviate some of the issues of implicit, I don't think we can recommend specifics, and there may be future ones in the future. I think we all agree that implicit without any mitigation is problematic. 
> 
> How about we recommend against using implicit alone? 
> 
> 
> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
> Hi all,
> 
> The authors of the OAuth Security Topics draft came to the conclusion that it is not possible to adequately secure the implicit flow against token injection since potential solutions like token binding or JARM are in an early stage of adoption. For this reason, and since CORS allows browser-based apps to send requests to the token endpoint, Torsten suggested to use the authorization code instead of the implicit grant in call cases in his presentation (see https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
> 
> A hum in the room at IETF#103 concluded strong support for his recommendations. We would like to confirm the discussion on the list.
> 
> Please provide a response by December 3rd.
> 
> Ciao
> 
> Hannes & Rifaat
> 
>  
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth