Re: [OAUTH-WG] [EXTERNAL] Re: First Draft of OAuth 2.1

Torsten Lodderstedt <torsten@lodderstedt.net> Thu, 12 March 2020 19:00 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 4F5FF3A107F for <oauth@ietfa.amsl.com>; Thu, 12 Mar 2020 12:00:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
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 JZTbRO9pj4hw for <oauth@ietfa.amsl.com>; Thu, 12 Mar 2020 12:00:26 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA2BA3A1057 for <oauth@ietf.org>; Thu, 12 Mar 2020 12:00:25 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id m3so7607398wmi.0 for <oauth@ietf.org>; Thu, 12 Mar 2020 12:00:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=JQIHFt0g6giBgaL1nT4sRH9tVAPDePQ56GXgkPUGRJ0=; b=S8pcWoWXGQWnVuZztIR38At1ZKXsBjkFghyaPe3lNA2k5oWIe5lT3voioTjcn3LhFp qLb3X9vMppkiW+F/DLvdNXw/xX/vm5M4b9I1KVtE97usQbHJduGm7huRXtmgBPfhOrzg f99kWgDQ+v7STuAF4rBAZi2yp1zHk7nsAbbnHk3CuCHcFCUtT/Smz31r2EYfj1lWSl5o Q8ODoMY5uvkxmGKbmFEWZY8I4jxgECzj5ByIMEXvAQrePGIIKnPUoU7/E2P0dUWFlkkC yBCbvhlk4438RnQ3omMDKd9NWpkfQRcFTM6wyiGJg3eqFFr2dkESbjR5pJF5lLOvKXmo HSBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=JQIHFt0g6giBgaL1nT4sRH9tVAPDePQ56GXgkPUGRJ0=; b=FJCNlUPJ1zo0aGZUSEx+iLlVaPcmlt/yWz/KsZCvlA3qJQ3asoZQHNr2P2kABvRn4K CtsX3GjjB0xyjAczLj6l48209kgqB46dmkzrEqqrSxDH+NMj0ByFLfdxH6Ujy8/ZEodz FlLhBiqPjf/FydlonipG6EiPPemr3LXb7lCMyp8QFVcWaVQJgJCQ0ztMAZs2AB4YVmpa 3IwENp6JXrUYsWKJp/l1QaMg0htUxYPv63cCSknlQgKPdYFAEv6NH/uYXUjjzSgSNbpO g4zeymowioCTlTYb+P//G3BkrKxp4Gf0PtoRFbX8IQQmg292b+mi2sT2Zg7PrHSQSTa5 lWNg==
X-Gm-Message-State: ANhLgQ1ut0gLKoqo8R8/3yd3i08Bamz8DXG/xMP3aqY+tC1r43FICZqt A0NjF4AwlUYukgY03Bgxd0TR4A==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vsDaCQwFE2LJlOGNp+nwNJJye1Yns0XhMrfNxk9?= =?utf-8?q?YWqJAMdQYzXw7Z9exVeNOIZSxYW3Rt1qGg=3D=3D?=
X-Received: by 2002:a1c:bcd4:: with SMTP id m203mr6052389wmf.35.1584039623958; Thu, 12 Mar 2020 12:00:23 -0700 (PDT)
Received: from [192.168.71.105] (p5B0D94B9.dip0.t-ipconnect.de. [91.13.148.185]) by smtp.gmail.com with ESMTPSA id 98sm15404777wrm.64.2020.03.12.12.00.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2020 12:00:23 -0700 (PDT)
Content-Type: multipart/signed; boundary=Apple-Mail-48956852-34E3-44F3-B917-7FE5B9D1F8BD; protocol="application/pkcs7-signature"; micalg=sha-256
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Mime-Version: 1.0 (1.0)
Date: Thu, 12 Mar 2020 20:00:16 +0100
Message-Id: <1B8143EA-DEA3-4CF7-9FDD-C943CE2867FB@lodderstedt.net>
References: =?utf-8?q?=3CDM6PR00MB0682F47006D70256AA7D86A3F5FD0=40DM6PR00MB0?= =?utf-8?q?682=2Enamprd00=2Eprod=2Eoutlook=2Ecom=3E?=
Cc: Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>, Aaron Parecki <aaron@parecki.com>, OAuth WG <oauth@ietf.org>
In-Reply-To: =?utf-8?q?=3CDM6PR00MB0682F47006D70256AA7D86A3F5FD0=40DM6PR00MB?= =?utf-8?q?0682=2Enamprd00=2Eprod=2Eoutlook=2Ecom=3E?=
To: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
X-Mailer: iPhone Mail (17D50)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/kDKEv6KvsNMKTPPigT8gZdXUfmU>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: First Draft of OAuth 2.1
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: Thu, 12 Mar 2020 19:00:38 -0000

I think we need to change wording. Sender constraining for confidential client and refresh tokens does not require any signature. It’s client authentication + checking the client id matches. I don’t see an issue with this.

> Am 12.03.2020 um 19:36 schrieb Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>rg>:
> 
> 
> +1 on sender constraints being RECOMMENDED but not REQUIRED.  Different applications have different risk profiles.  We should enable people to make reasonable choices for their use cases.
>  
> Remember that OAuth 1.0 was rejected by the marketplace because implementing the sender-constraint mechanism specified was perceived as too hard.  That’s why we have OAuth 2.0.  Particularly given that there’s not a deployable sender-constraint standard (other than MTLS, which is deployable for some use cases), we should put ourselves in developer’s shoes when telling them what they MUST do.  If we overreach, the OAuth 1.0 experience tells us they’ll likely just rebel and we’ll lose credibility.
>  
>                                                        -- Mike
>  
> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Vittorio Bertocci
> Sent: Thursday, March 12, 2020 11:28 AM
> To: Aaron Parecki <aaron@parecki.com>
> Cc: OAuth WG <oauth@ietf.org>
> Subject: [EXTERNAL] Re: [OAUTH-WG] First Draft of OAuth 2.1
>  
> damnit, i hit enter too soon.
>   Hey guys,
> thanks for putting this together.
> I am concerned with the real world impact of imposing sender constraint | rotation as a MUST on refresh tokens in every scenario.
> Sender constraint isn't immediately actionable - we just had the discussion for dPOP, hence I won't go in the details here.
> Rotation isn't something that can be added without significant impact on development and runtime experiences:
> ·  on distributed scenarios, it introduces the need to serialize access to shared caches
> ·  network failures can lead to impact on experience- stranding clients which fail to receive RTn+1 during RTn redemption in a limbo where user interaction might become necessary, disrupting experience or functionality for scenarios where the user isn't available to respond.
> - remediations currently in the wild for this are either clunky (grace periods) or downright cumbersome (waiting for the AT refreshed via RTn to be used by the client to invalidate RTn, which locks RS and AS in a transaction that is both expensive and itself subject to network failure)
> I think it's fine to recommend using those mechanisms with a SHOULD, but imposing those complexities to everyone in the core is asking too much IMO.
> Thanks
> V.
>  
> On Thu, Mar 12, 2020 at 11:24 AM Vittorio Bertocci <Vittorio@auth0.com> wrote:
> Hey guys,
> thanks for putting this together.
> I am concerned with the real world impact of imposing sender constraint | rotation as a MUST on refresh tokens in every scenario.
> Sender constraint isn't immediately actionable - we just had the discussion for dPOP, hence I won't go in the details here..
> Rotation isn't something that can be added without significant impact on development and runtime experiences:
> on distributed scenarios, it introduces the need to serialize access to shared caches
> network failures can lead to impact on experience- stranding clients which fail to receive RTn+1 during RTn redemption in a limbo where user interaction might become necessary, disrupting experience or functionality for scenarios where the user isn't available to respond.
>  
>  
>  
> On Wed, Mar 11, 2020 at 5:28 PM Aaron Parecki <aaron@parecki.com> wrote:
> I'm happy to share that Dick and Torsten and I have published a first
> draft of OAuth 2.1. We've taken the feedback from the discussions on
> the list and incorporated that into the draft.
> 
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01
> 
> A summary of the differences between this draft and OAuth 2.0 can be
> found in section 12, and I've copied them here below.
> 
> > This draft consolidates the functionality in OAuth 2.0 (RFC6749),
> > OAuth 2.0 for Native Apps (RFC8252), Proof Key for Code Exchange
> > (RFC7636), OAuth 2.0 for Browser-Based Apps
> > (I-D.ietf-oauth-browser-based-apps), OAuth Security Best Current
> > Practice (I-D.ietf-oauth-security-topics), and Bearer Token Usage
> > (RFC6750).
> >
> >   Where a later draft updates or obsoletes functionality found in the
> >   original [RFC6749], that functionality in this draft is updated with
> >   the normative changes described in a later draft, or removed
> >   entirely.
> >
> >   A non-normative list of changes from OAuth 2.0 is listed below:
> >
> >   *  The authorization code grant is extended with the functionality
> >      from PKCE ([RFC7636]) such that the only method of using the
> >      authorization code grant according to this specification requires
> >      the addition of the PKCE mechanism
> >
> >   *  Redirect URIs must be compared using exact string matching as per
> >      Section 4.1.3 of [I-D.ietf-oauth-security-topics]
> >
> >   *  The Implicit grant ("response_type=token") is omitted from this
> >      specification as per Section 2.1.2 of
> >      [I-D.ietf-oauth-security-topics]
> >
> >   *  The Resource Owner Password Credentials grant is omitted from this
> >      specification as per Section 2.4 of
> >      [I-D.ietf-oauth-security-topics]
> >
> >   *  Bearer token usage omits the use of bearer tokens in the query
> >      string of URIs as per Section 4.3.2 of
> >      [I-D.ietf-oauth-security-topics]
> >
> >   *  Refresh tokens must either be sender-constrained or one-time use
> >      as per Section 4.12.2 of [I-D.ietf-oauth-security-topics]
> 
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-12
> 
> I'm excited for the direction this is taking, and it has been a
> pleasure working with Dick and Torsten on this so far. My hope is that
> this first draft can serve as a good starting point for our future
> discussions!
> 
> ----
> Aaron Parecki
> aaronparecki.com
> @aaronpk
> 
> P.S. This notice was also posted at
> https://aaronparecki.com/2020/03/11/14/oauth-2-1
> 
> _______________________________________________
> 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