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

Torsten Lodderstedt <torsten@lodderstedt.net> Tue, 20 November 2018 07:36 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 55C781277D2 for <oauth@ietfa.amsl.com>; Mon, 19 Nov 2018 23:36:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 fjNwHW9suGaC for <oauth@ietfa.amsl.com>; Mon, 19 Nov 2018 23:36:23 -0800 (PST)
Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.98]) (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 A55D512870E for <oauth@ietf.org>; Mon, 19 Nov 2018 23:36:23 -0800 (PST)
Received: from [46.183.103.17] (helo=[172.18.243.21]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <torsten@lodderstedt.net>) id 1gP0Zx-0005PO-4R; Tue, 20 Nov 2018 08:36:19 +0100
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_877B6901-5F4B-46AE-8217-8439AF1A2BDE"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Tue, 20 Nov 2018 08:35:17 +0100
In-Reply-To: <BL0PR00MB029244CACC634E2D2E923B77F5D80@BL0PR00MB0292.namprd00.prod.outlook.com>
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, oauth <oauth@ietf.org>
To: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
References: <VI1PR0801MB211266BA6F6E06FFB3081425FAD80@VI1PR0801MB2112.eurprd08.prod.outlook.com> <BL0PR00MB029244CACC634E2D2E923B77F5D80@BL0PR00MB0292.namprd00.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.101.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/CEvk_mfhYyoF_0xChJ_NQuBbysg>
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: Tue, 20 Nov 2018 07:36:27 -0000

Hi Mike, 

I agree that OIDC hybrid flows offer additional security over the OAuth implicit grant and are used in the wild. On my slides and in the initial version of the new section, we had included the hybrid OIDC flows because of their known token injection countermeasures.

I nevertheless feel very uncomfortable to recommend those flows and any flow issuing access tokens in the front channel. In the course of the detailed review of the new text we realized two issues: 

1) Since the access token is exposed in the URL, such flows possess a significantly higher risk to leak the access token (e.g. through browser history, open redirection and even referrer headers) than the code grant.
2) There is no viable way to sender constrain access tokens issued in the front channel. Given the WG decided to recommend use of sender constraint tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2.2), it seems contradictory to recommend response types not supporting such an approach. 

kind regards,
Torsten. 

> Am 19.11.2018 um 23:13 schrieb Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>:
> 
> This description of the situation is an oversimplification.  OpenID Connect secures the implicit flow against token injection attacks by including the at_hash (access token hash) in the ID Token, enabling the client to validate that the access token was created by the issuer in the ID Token (which is also the OAuth Issuer, as described in RFC 8414).  (Note that this mitigation was described in draft-ietf-oauth-mix-up-mitigation.)
>  
> Given the prevalence of this known-good solution for securing the implicit flow, I would request that the draft be updated to describe this mitigation.  At the same time, I’m fine with the draft recommending the code flow over the implicit flow when this mitigation is not used.
>  
>                                                                 Thank you,
>                                                                 -- Mike
>  
> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Hannes Tschofenig
> Sent: Monday, November 19, 2018 2:34 AM
> To: oauth <oauth@ietf.org>
> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
>  
> 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 (seehttps://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