Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

"Richard Backman, Annabelle" <richanna@amazon.com> Fri, 10 January 2020 21:22 UTC

Return-Path: <prvs=27136b9e3=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 E7681120100 for <oauth@ietfa.amsl.com>; Fri, 10 Jan 2020 13:22:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.518
X-Spam-Level:
X-Spam-Status: No, score=-14.518 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 U3-53sxZ7kNM for <oauth@ietfa.amsl.com>; Fri, 10 Jan 2020 13:22:16 -0800 (PST)
Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.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 CBC2B1200CC for <oauth@ietf.org>; Fri, 10 Jan 2020 13:22:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578691336; x=1610227336; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=K69SGuYvsv/OUFx7Y+Izgb5dVhociwvPj/9fIxbDMZ4=; b=YDvA7ApQZCxuigdjQRafRel3VI/qc0DizZ5SbHrDuXoHaGgwzvzxd3/z mg8/JE7tdpqKVNvkrX0xTA88MxGdDieN+HRAfKrQnVCA4vmytLBgTOh40 iNRccPexRT5rLuM6XhE3frvoA/cmctwaMdXddWet3yz0PR1vDZ58Yrcek Y=;
IronPort-SDR: 7L/hUavI2456z0pMWfNSi97FEr5thbl6AVD8kfl2/c1Cyre/EcJFQL2zsaG17nsBTZecRlgm2y HwZZP0nF4hqw==
X-IronPort-AV: E=Sophos; i="5.69,418,1571702400"; d="scan'208,217"; a="11947881"
Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-1a-821c648d.us-east-1.amazon.com) ([10.43.8.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP; 10 Jan 2020 21:22:15 +0000
Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1a-821c648d.us-east-1.amazon.com (Postfix) with ESMTPS id D9C9FA1F7F; Fri, 10 Jan 2020 21:22:12 +0000 (UTC)
Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 10 Jan 2020 21:22:11 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 10 Jan 2020 21:22: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, 10 Jan 2020 21:22:10 +0000
From: "Richard Backman, Annabelle" <richanna@amazon.com>
To: Dick Hardt <dick.hardt@gmail.com>, Neil Madden <neil.madden@forgerock.com>
CC: Aaron Parecki <aaron@parecki.com>, oauth <oauth@ietf.org>, Mike Jones <Michael.Jones@microsoft.com>
Thread-Topic: [UNVERIFIED SENDER] Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
Thread-Index: AQHVx+drfYDyunsQfU+Jcs71iQJM4KfkQEeA//+h1wA=
Date: Fri, 10 Jan 2020 21:22:10 +0000
Message-ID: <99A2BC24-C265-48DB-9353-4CE4105ED435@amazon.com>
References: <CAGBSGjpFMKTCNYgeh4p7Nyh6urTbmQ0qYFHPUa+OX51Hj88UVg@mail.gmail.com> <23D54EBE-359C-40FF-8204-9F03E45D09E9@forgerock.com> <CAD9ie-vCzedTkdb-GXBVgahFb1jZcA9NdUfb0rsOAqrtup95cg@mail.gmail.com> <CAD9ie-u52XjXYd8RiMgOYFpLVd7fhiBOMLOwECD3u60ygovZRw@mail.gmail.com>
In-Reply-To: <CAD9ie-u52XjXYd8RiMgOYFpLVd7fhiBOMLOwECD3u60ygovZRw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.160.48]
Content-Type: multipart/alternative; boundary="_000_99A2BC24C26548DB93534CE4105ED435amazoncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/vuDD9KmQ6b9h1ueW7wPNMDalFpE>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
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, 10 Jan 2020 21:22:18 -0000

Having different JWKS URIs in the metadata document for different purposes would address the issue, but I’m not sure off-hand if we can clearly delineate purposes in a robust way without making it too complicated. So it may be correct for the working group to accept the situation for what it is.

However, if we do that then we need to stop pretending that “use different keys” is a viable option. That tool needs to be tossed out of the toolbox, because our specifications do not allow implementers to do that in a meaningful way. The fact that we’ve used that argument despite this limitation demonstrates that this is a non-obvious result of the trust model we’ve adopted. If we stick with that model, we need to be more conscious of this issue in our future work. Some documents will need Security Considerations that draw attention to it, others may need more attention. We also need to recognize that we will be ruling out certain types of deployments, and certain use cases.

–
Annabelle Richard Backman
AWS Identity


From: Dick Hardt <dick.hardt@gmail.com>
Date: Friday, January 10, 2020 at 11:00 AM
To: Neil Madden <neil.madden@forgerock.com>
Cc: Aaron Parecki <aaron@parecki.com>, oauth <oauth@ietf.org>, Mike Jones <Michael.Jones@microsoft.com>, "Richard Backman, Annabelle" <richanna@amazon.com>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

To restate my previous point, we may not be able to change what is currently specified and deployed, but we can for future extensions such as RAR and PAR.

To paraphrase Annabelle, this ship may have already sailed.

On Fri, Jan 10, 2020 at 10:52 AM Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>> wrote:
The metadata document is declarative, and can easily be yet another separate role in the AS.

In large organizations, different people are empowered different roles, so the team owning the metadata document could be different from the team generating ID tokens, and different from the team generating JWTs.


On Fri, Jan 10, 2020 at 10:27 AM Neil Madden <neil.madden@forgerock.com<mailto:neil.madden@forgerock.com>> wrote:
The problem with specifying a property on the key itself is that a microservice might lie about what it’s keys are for. I think you either need separate documents or some separate metadata mapping uses to key ids.

— Neil


On 10 Jan 2020, at 18:19, Aaron Parecki <aaron@parecki.com<mailto:aaron@parecki.com>> wrote:
!
Can the keys in the document at the jwks_uri indicate what they are for? Either by adding other top-level properties next to "keys" or by specifying a property on a key itself? At least that way implementations that expect just one value of jwks_uri wouldn't have to change.

Aaron



On Fri, Jan 10, 2020 at 12:16 PM Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>> wrote:
Yes. Thanks for clarifying.
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=373436a5-294f-48b6-a06d-73c59fdafe0d]ᐧ

On Fri, Jan 10, 2020 at 10:14 AM Torsten Lodderstedt <torsten@lodderstedt.net<mailto:torsten@lodderstedt.net>> wrote:
You mean additional JWKS URIs, for example?


Am 10.01.2020 um 19:09 schrieb Dick Hardt <dick.hardt@gmail..com<mailto:dick.hardt@gmail.com>>:
Perhaps I am misunderstanding what Annabelle was getting at, but having more than one key in the metadata document would solve the the issue. IE, extensions would define their own key instead of using the same one.

The metadata document itself was an extension.


On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodderstedt <torsten@lodderstedt.net<mailto:torsten@lodderstedt.net>> wrote:


> Am 10.01.2020 um 18:23 schrieb Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>>:
>
> As OAuth 2.0 has been extended, the AS is now also an OpenID Connect Provider, and the access token is being defined. These extensions have assumed all of this functionality is a monolith.
>
> I'm not suggesting that we MUST make changes to existing extensions, but design future extensions so that an implementation can separate duties if desired.

How do you envision this to work? As you said, OAuth 2.0 is built on the assumption the AS is (at least logically) a monolith. All extension were built on that underlying assumption. I don’t see how an arbitrary extension can relax that assumption and still be compatible with the rest (just revisit the discussion re PAR and keys).

I think we should accept this design assumption, in the same way we should accept form encoding as request format instead of JSON, for OAuth 2.0 extensions.

OAuth 3.0 could explicitely be developed with different architectures in mind.
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
----
Aaron Parecki
aaronparecki.com<http://aaronparecki.com>
@aaronpk<http://twitter.com/aaronpk>

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth