IETF Logo Mail Archive

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

"Richard Backman, Annabelle" <richanna@amazon.com> Fri, 17 January 2020 16:34 UTC

Return-Path: <prvs=278f7ad0d=richanna@amazon.com>
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 1D93E120024 for <oauth@ietfa.amsl.com>; Fri, 17 Jan 2020 08:34:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
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 yqm2DN5XJACf for <oauth@ietfa.amsl.com>; Fri, 17 Jan 2020 08:34:24 -0800 (PST)
Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (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 9A3F9120018 for <oauth@ietf.org>; Fri, 17 Jan 2020 08:34:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1579278865; x=1610814865; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=e8pVIErCbYr1bDmDjUH3c1NFxSq/hxN6uB0EJNr7HAc=; b=k/LkURjpdNIJadNoSSxdeJUFAGSYlbD9CYOaZdZiq4YH0ko+3Kw7y8Im 2ZUNIUjRPZ5/g+Vhhr7d+NM6g5FxySVQApqykeYN+TmU6IKfGnSQF+KnG vmen4LCEwMina4gW+dvP1Im+sqL+QTeynAj53Wll8kmowNBsi4wsz7pA3 w=;
IronPort-SDR: BZtUfWhIdP79snfwWMj+eWf82UggDxaYj82uP2cAbygyS2jzNuLWQG5l2r69rrzs2cZlTiLtOf a/PQvKE8nIYw==
X-IronPort-AV: E=Sophos;i="5.70,330,1574121600"; d="scan'208";a="10958638"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2b-a7fdc47a.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 17 Jan 2020 16:34:12 +0000
Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2b-a7fdc47a.us-west-2.amazon.com (Postfix) with ESMTPS id 564F4C5DFE; Fri, 17 Jan 2020 16:34:11 +0000 (UTC)
Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 17 Jan 2020 16:34:10 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 17 Jan 2020 16:34:10 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Fri, 17 Jan 2020 16:34:10 +0000
From: "Richard Backman, Annabelle" <richanna@amazon.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: Neil Madden <neil.madden@forgerock.com>, IETF oauth WG <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object
Thread-Index: AQHVyBgJ47SBXlMdXkypCDJuQVGWtKfkpDcAgACLVgCAAK0VgIAC52cAgAGpqICAAdBVgIAAqQMAgAATAYCAAAUzAIAAZCeAgAAVAoCAAAw5AIAAwAMAgADTEic=
Date: Fri, 17 Jan 2020 16:34:10 +0000
Message-ID: <93218BD9-EB9D-4F58-AB37-7F2A78A634E4@amazon.com>
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>
In-Reply-To: <20200117035844.GQ80030@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/JCi0H4ndVxt-ytljZpnKgMiNcbg>
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: Fri, 17 Jan 2020 16:34:28 -0000

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

v2.15.0 | Report a Bug | By Email