Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

Benjamin Kaduk <kaduk@mit.edu> Sat, 18 January 2020 02:50 UTC

Return-Path: <kaduk@mit.edu>
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 97DEE120086 for <oauth@ietfa.amsl.com>; Fri, 17 Jan 2020 18:50:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 cOw7jWmtWGq7 for <oauth@ietfa.amsl.com>; Fri, 17 Jan 2020 18:50:08 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 42603120041 for <oauth@ietf.org>; Fri, 17 Jan 2020 18:50:08 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00I2o1J4029320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Jan 2020 21:50:03 -0500
Date: Fri, 17 Jan 2020 18:50:01 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: Neil Madden <neil.madden@forgerock.com>, IETF oauth WG <oauth@ietf.org>
Message-ID: <20200118025001.GU80030@kduck.mit.edu>
References: <CAO7Ng+vZk2OCuc_JOp6Nwh=+GXrDnOop4KBhierFCvoBOOcw6Q@mail.gmail.com> <CCE34816-FBAF-4971-B75B-3F70769E56AE@forgerock.com> <20200116143233.GJ80030@kduck.mit.edu> <CABzCy2C1Bi_ic8XoELCw=qpo_3UcuEb8opX9s_6QFMq3ZBkCTA@mail.gmail.com> <57F86DC4-F413-4D94-BFF8-2425222A69ED@forgerock.com> <20200117035844.GQ80030@kduck.mit.edu> <93218BD9-EB9D-4F58-AB37-7F2A78A634E4@amazon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <93218BD9-EB9D-4F58-AB37-7F2A78A634E4@amazon.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ACCrjR1RqiYkkU4dMSOkBJyQdGo>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object
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: Sat, 18 Jan 2020 02:50:10 -0000

Definitely; thanks for raising that explicitly.

-Ben

On Fri, Jan 17, 2020 at 04:34:10PM +0000, Richard Backman, Annabelle wrote:
> We should not be prescriptive about how the AS recognizes request URIs from itself. Trusted authority or custom URI scheme are fine as examples, but ultimately this is an internal implementation of the AS. It could just as easily be using data URIs containing a symmetrically encrypted database record ID.
> 
> > On Jan 16, 2020, at 8:00 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> > 
> > On Thu, Jan 16, 2020 at 04:31:30PM +0000, Neil Madden wrote:
> >> The mitigations of 10.4.1 are related, but the section heading is about (D)DoS attacks. I think this heading needs to be reworded to apply to SSRF attacks too or else add another section with similar mitigations. 
> >> 
> >> Mitigation (a) is a bit vague as to what an "unexpected location" is. Perhaps specific wording that it should be a URI that has been pre-registered for the client (and validated at that time) or is otherwise known to be safe (e.g., is a URI scheme controlled by the AS itself as with PAR).
> > 
> > pedantic nit: "URI scheme" is probably not what we want, as the authority
> > component of the URI (per RFC 3986) seems more likely to match "controlled
> > by the AS itself"
> > 
> > -Ben
> > 
> >> In addition for this to be effective the AS should not follow redirects when fetching the URI. It's not clear to me whether that is implied by "not perform recursive GET" so it may be worth explicitly spelling that out.
> >> 
> > 
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth