Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Vittorio Bertocci <vittorio.bertocci@auth0.com> Tue, 31 March 2020 21:33 UTC

Return-Path: <vittorio.bertocci@auth0.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 5F8AD3A096E for <oauth@ietfa.amsl.com>; Tue, 31 Mar 2020 14:33:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.188
X-Spam-Level:
X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.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 B3sjfLNXb-UY for <oauth@ietfa.amsl.com>; Tue, 31 Mar 2020 14:33:52 -0700 (PDT)
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 C2F2D3A094B for <oauth@ietf.org>; Tue, 31 Mar 2020 14:33:52 -0700 (PDT)
Received: by mail-pf1-x436.google.com with SMTP id c138so1357982pfc.0 for <oauth@ietf.org>; Tue, 31 Mar 2020 14:33:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=WC7Vji+Ng4FXybgyY5AVOw4Wda+ZPbGJ290e8Q7BLuQ=; b=E7izdkoTGcrTiQytKmmtrggO3QmaE5qQz9m/L3pnGumLpALYI3XDIAvQIt4StVdK8s jq0XMt46N+CqQyYk0kWOMZRoZOrN8spAwNwytvl6bMjnXy0N+DNmwt/1/7MSoQUXh3tP OZJAJHr0OjhghByRsE82lffT2AYQuA3c1HU4nSsPazxi+grHHCB1KVfYsszfEmVdMnAb q6Nsz+EU0+m4viXzg6mVgmalM+hJLCeBtUkU8Cd/UDHoIuc5JwiICDMcKXLcl6QnGPTp 1peqEZjIBv/0cheQitnb++ntAFb7fqEQUlm9TXglzq6BlHyvyMukJamPsmhyDLSS8lHU Jgaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=WC7Vji+Ng4FXybgyY5AVOw4Wda+ZPbGJ290e8Q7BLuQ=; b=jZL4uR+FTuaTrVJzfZY38+WNAR8ts47PD+mf5GJA28yQ7Ow1T8khmLOArX2RHzuRku 8d7+jdB91KvQDhkuNsJG3AXNR9uJ0D0PB+12akGT3Hv3G+2YmuH4PB/KCpRx87r//SWf /SdeRcNLgPYlUkzPLCkwKP9NpNzNA//VLowUc69gUJrUgC/Jpgl1/wMzBqkejsMSU75K UCkmt0Yjz0okhisEFimsjBsqr14qxij86aBFWMi4kv8+OIwOaMtOyBLRjZDqbUu1qMcZ wvOYYdbN598McNFNxaX7OTtAWkV+gJEPNTkmzI/pRLJQjPKzq6UhPozFezgphYT9ziZ9 ngxQ==
X-Gm-Message-State: ANhLgQ2ynK2yl3N3Fj0Rl9sWg9PGIehcZ8ISefhnKNnpq2xRANRhGBi0 TdZpnW33C0njig+rUTybX+nZdA==
X-Google-Smtp-Source: ADFU+vvRNe7QRf3ekxYh8u8jX0kXnpkXj+e8cnnI6AhQK9oxpprz5qQXhsC0zwDne5JmL5qfi2rx/w==
X-Received: by 2002:a65:4544:: with SMTP id x4mr18674886pgr.388.1585690431805; Tue, 31 Mar 2020 14:33:51 -0700 (PDT)
Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id mq6sm42268pjb.38.2020.03.31.14.33.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Mar 2020 14:33:51 -0700 (PDT)
From: Vittorio Bertocci <vittorio.bertocci@auth0.com>
To: Brian Campbell <bcampbell@pingidentity.com>
CC: George Fletcher <gffletch@aol.com>, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Thread-Index: AUEycU9mO6vgAQI5B0OjX8F3/L/kmDAwNTE1qCC4FwCACCvDhg==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Tue, 31 Mar 2020 21:33:50 +0000
Message-ID: <MWHPR19MB150117B2239E05047C469665AEC80@MWHPR19MB1501.namprd19.prod.outlook.com>
References: <AM0PR08MB37160B8A021052198699CD17FAF00@AM0PR08MB3716.eurprd08.prod.outlook.com> <01ec01d6017c$162eb2e0$428c18a0$@aueb.gr> <CAHdPCmMzRn8iYG025Vq0sQNzgZTOkQJuMJwttDgjMDLESpjptw@mail.gmail.com> <CAO_FVe5UXY4Jxd3LdG6zyXJ8B8nFKYevcHQTVJEAFSdW0ku9tg@mail.gmail.com> <52f18114-4f8e-da86-5735-4c4e8f8d2db5@aol.com> <BL0PR08MB5394CA3CB524E95EA87CD6B6AEF10@BL0PR08MB5394.namprd08.prod.outlook.com> <74da4cc3-359c-c08a-0ae5-54c8ca309f32@aol.com> <D080BE8B-BD0D-4F63-9F33-BA23C2FB42DD@amazon.com> <DM6PR08MB5402639817677AD59898CD65AECE0@DM6PR08MB5402.namprd08.prod.outlook.com> <CA+k3eCS29X28CBXGiUtDAV8nceTcpfJ4Jr_x=E3x8_9crOqsOQ@mail.gmail.com> <13b6801d602c0$02ebea00$08c3be00$@auth0.com> <CA+k3eCSTKNMchR_20z7VRi1XS+kkzi3+8ey_+hB7bK-onRv2Bg@mail.gmail.com> <a0842eb4-582b-59ab-855d-8e48828e92ee@aol.com> <CA+k3eCQdQggPrVatvT2COrtEw2E4F2TTp_3uU6iSk1AsXeRwMg@mail.gmail.com> <13c4701d602d5$5990cdc0$0cb26940$@auth0.com> <29046ca9-71df-430c-80ec-8cf1700be0d9@aol.com> <13c7701d602d7$403eccd0$c0bc6670$@auth0.com> <CA+k3eCTRhfsnjBnJKKjOrkqjcqVi6qDjh1TQTjE2KSFMMmhLdA@mail.gmail.com> <DM6PR08MB540216A182DA915C41A7F02AAECE0@DM6PR08MB5402.namprd08.prod.outlook.com> <CA+k3eCT856ieb+GsagCa_v4rna+YP7d1K8q8TL-qBjZdbRQyFg@mail.gmail.com>
In-Reply-To: <CA+k3eCT856ieb+GsagCa_v4rna+YP7d1K8q8TL-qBjZdbRQyFg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_MWHPR19MB150117B2239E05047C469665AEC80MWHPR19MB1501namp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/3cL-pNwVsg8Vw333nV6IvL5pUeo>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 31 Mar 2020 21:34:04 -0000

Thank you! I updated the language accordingly, and added a warning in the security section aligned with Annabelle’s concerns.
Updating the draft shortly.

From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thursday, March 26, 2020 at 09:47
To: Vittorio Bertocci <vittorio.bertocci@auth0.com>
Cc: George Fletcher <gffletch@aol.com>om>, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>rg>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Preventing token substitution/confusion was not at all the aim of my comment. I only brought that up in an attempt to bridge what looked like a communication gap in Annabelle's and your discussion. Sorry for any confusion that might have caused.

That discussion did lead me to think again about the more general issue of signalling/figuring out what key from jwks_uri (which has content that isn't static and likely changes over time for key rotation) used to sign. Then looking again at draft-ietf-oauth-access-token-jwt-04 to realize that it's pretty much silent about this bit that I think is an important aspect to interop.

The text you suggested definitely works better, yes. Thank you. I could say that there'd be value in saying more but, as previously promised, I won't argue it further.

On Wed, Mar 25, 2020 at 5:46 PM Vittorio Bertocci <vittorio.bertocci@auth0.com<mailto:vittorio.bertocci@auth0.com>> wrote:
I think I am missing something here. It’s not that I don’t want to give guidance, is that it seems that the guidance you are thinking of isn’t necessary unless we think that enforcing explicitkey-token type assignment declaration is necessary. I didn’t get the impression that it was the proposal so far, what I have read was “if the intent was to prevent token confusion/substitution, this is insufficient”, to which the answer was “that was not the intent”.
And if preventing token substitution/confusion is not the aim, then the only guidance required here to the RS is “expect that any key published in the doc pointed by jwks_uri could be used to sign the AT” which seems actionable enough.
I do agree that the language could be more explicitly aimed at that outcome. Would something to the effect of “The RS should expect the AS to use any of the keys published in the JWKS doc to sign JWT ATs” work better?

From: Brian Campbell <bcampbell@pingidentity.com<mailto:bcampbell@pingidentity.com>>
Date: Wednesday, March 25, 2020 at 14:26
To: Vittorio Bertocci <vittorio.bertocci@auth0.com<mailto:vittorio.bertocci@auth0.com>>
Cc: George Fletcher <gffletch@aol.com<mailto:gffletch@aol.com>>, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org<mailto:40pingidentity.com@dmarc.ietf.org>>, oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

It seems to me that leaving that out of scope is rather antithetical to the previously stated reason for the profile using only asymmetric signatures, namely that "this profile focuses on a solution that is as close to turnkey as possible for developers." And I'd suggest that, to borrow your words, looking at this from the useful guidance standpoint rather than the “lawyering up” perspective, some guidance on determining the correct key to use from the keys at the jwks_uri to verify the signature on the AT would be very useful in general and also prevent the kind of potential missteps you described. I mean, if nothing is said about it or even if it'd said to be out of scope, a working interoperable approach could probably be inferred by knowing and applying bits of JWS, JWA, JWK, etc.. But, to me anyway, it seems incongruent to expect folks to figure all that out but at the same time believe them capable of mistakes that would be prevented by only pointing out that ATs and ID tokens might be signed by different keys.

FWIW there's some ~8 year old text in OIDC that kinda attempts to give that kind of guidance in the Asymmetric bit of https://openid.net/specs/openid-connect-core-1_0.html#Signing and https://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys - it's not perfect (this issue<https://bitbucket.org/openid/connect/issues/1161/key-rotation-should-require-a-delay> was raised just recently) but attempts to convey how verification key selection is to be done and account for key rotation too.

This seems rather cut and dry to me but maybe I'm "in the weeds" on this one. And I've spent more time here than I'd like to admit so I won't argue it further.



On Wed, Mar 25, 2020 at 12:57 PM <vittorio.bertocci@auth0.com<mailto:vittorio.bertocci@auth0.com>> wrote:
That works for me!

From: George Fletcher <gffletch@aol.com<mailto:gffletch@aol.com>>
Sent: Wednesday, March 25, 2020 11:56 AM
To: vittorio.bertocci@auth0.com<mailto:vittorio.bertocci@auth0.com>; 'Brian Campbell' <bcampbell=40pingidentity.com@dmarc.ietf.org<mailto:40pingidentity.com@dmarc.ietf.org>>
Cc: 'Brian Campbell' <bcampbell@pingidentity.com<mailto:bcampbell@pingidentity.com>>; 'oauth' <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

If we don't want to give guidance on how the RS determines the correct key to use to validate the token, then maybe we should state that explicitly. "The mechanism used by the RS to determine the correct key to use to validate the access token is out of scope for this specification".

That way at least we are being very clear that the spec is not trying to specify how that happens.

Thoughts?
On 3/25/20 2:44 PM, vittorio.bertocci@auth0.com<mailto:vittorio.bertocci@auth0.com> wrote:

Brian, there are plenty of ways in which an RS can surprise you with odd behavior- for example, developers might see that you used a key for signing an IDtoken and use that for init all their validation middleware for ATs as well, say because the library only supports one key at a time, and then end up failing at runtime when/if the assumption ceases to apply in the future.



Would that be legitimate of them to take such a dependency, even without warning text? No. However I am not looking at this from the “lawyering up” perspective, but from the useful guidance standpoint as well. I am well aware that being concise is a feature, but I am also not crazy about making every specification into an intelligence test for the reader. If a 16 words sentence can help prevent a likely misstep, I’d be inclined to keep it. But if the consensus is that the sentence is confusing, I can also take it out.







Brian & George, in the spirit of keeping things simple, and given that this was more of a “just in case” warning rather than a security feature clamored for- if the language is problematic I’d be more inclined to take the sentence out rather than complicating the guidance further.







From: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org><mailto:bcampbell=40pingidentity.com@dmarc.ietf.org>

Sent: Wednesday, March 25, 2020 11:21 AM

To: George Fletcher <gffletch@aol.com><mailto:gffletch@aol.com>

Cc: Brian Campbell <bcampbell@pingidentity.com><mailto:bcampbell@pingidentity.com>; Vittorio Bertocci <vittorio.bertocci@auth0.com><mailto:vittorio.bertocci@auth0.com>; oauth <oauth@ietf.org><mailto:oauth@ietf.org>

Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"







I don't think you are missing anything, George (except that, to be pedantic, `kid` is a header rather than a claim).







The question gave me pause, however, and makes me think that maybe the draft, with the aim of improved interoperability, should have some more explicit text about the use of the 'kid' header in a JWT AT and how it references the verification key in the content at the jwks_uri.























On Wed, Mar 25, 2020 at 11:54 AM George Fletcher <gffletch=40aol.com@dmarc.ietf.org<mailto:gffletch=40aol.com@dmarc.ietf.org> <mailto:40aol.com@dmarc.ietf.org><mailto:40aol.com@dmarc.ietf.org> > wrote:



Can we not use the 'kid' claim to inform the RS as to which key is being used? What am I missing?



On 3/25/20 1:51 PM, Brian Campbell wrote:



I think, even without that statement in the draft, that ASes already have

license to use different keys if they so choose. And maybe I'm not creative

enough but I can't think of what problematic assumptions RSes might make

that would prevented by it. So perhaps just removing that whole sentence,

"An authorization server MAY elect to use different keys to sign id_tokens

and JWT access tokens."? Just a thought anyway.



On Wed, Mar 25, 2020 at 10:11 AM <vittorio.bertocci=

40auth0.com@dmarc.ietf.org<mailto:40auth0.com@dmarc.ietf.org> <mailto:40auth0.com@dmarc.ietf.org><mailto:40auth0.com@dmarc.ietf.org> > wrote:





Thank you for the perspective- I guessed something similar (“there would

be no way for the RS to know what key is used for what").



As stated below, the intent wasn’t to prevent substitution/confusion, but

mostly to give ASes license to use different keys if they choose to (for

the reasons listed below, or any other reason they might have) and a

headsup to RSes so that they don’t make assumptions.







*From:* Brian Campbell  <mailto:bcampbell=40pingidentity.com@dmarc.ietf.org><mailto:bcampbell=40pingidentity.com@dmarc.ietf.org> <bcampbell=40pingidentity.com@dmarc.ietf.org><mailto:bcampbell=40pingidentity.com@dmarc.ietf.org>

*Sent:* Wednesday, March 25, 2020 8:48 AM

*To:* Vittorio Bertocci  <mailto:vittorio.bertocci@auth0.com><mailto:vittorio.bertocci@auth0.com> <vittorio.bertocci@auth0.com><mailto:vittorio.bertocci@auth0.com>

*Cc:* Richard Backman, Annabelle  <mailto:richanna@amazon.com><mailto:richanna@amazon.com> <richanna@amazon.com><mailto:richanna@amazon.com>; oauth <

oauth@ietf.org<mailto:oauth@ietf.org> <mailto:oauth@ietf.org><mailto:oauth@ietf.org> >

*Subject:* Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth

2.0 Access Tokens"







I'm gonna go out on a limb and guess/suggest that implicit in Annabelle's

comment was an assumption that signing ATs and ID Tokens with different

keys would be done to prevent token substitution/confusion. And there's not

really a practical way to achieve that with the mechanics of the jwks_uri..







On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci <vittorio.bertocci=

40auth0.com@dmarc.ietf.org<mailto:40auth0.com@dmarc.ietf.org> <mailto:40auth0.com@dmarc.ietf.org><mailto:40auth0.com@dmarc.ietf.org> > wrote:



*>§4 p3: The only practical way for the AS to sign ATs and ID Tokens with

different keys is to publish the keys in two different JWK sets. This only

way to do this today is by publishing separate OAuth 2.0 authorization

server metadata and OIDC Discovery metadata files, where the JWK set in the

former applies to access tokens and the JWK set in the latter applies to ID

Tokens.*



Hmm, I don’t follow. The OIDC jwks_uri can contain multiple keys, and they

all can be used for signing. What prevents the AS to use one key from that

list for IDtokens and another for ATs? Separate discovery docs shouldn’t be

necessary. Sure, there would be no way for the RS to know what key is used

for what- but similar mechanisms are already in place today for handling

signing key rotation: e.g. the discovery doc lists the current key and the

future key, but uses only the current- and the RS has no way of

distinguishing between the two. The situation here can be analogous, any

key in the discovery doc should be considered valid by the RS, and in fact

there’s no requirement about selecting specific keys in the validation

section. That doesn’t mean this is useless, an AS might elect to use

different keys for its own purposes (eg separation of concerns for

forensics, different strengths, different lifecycles, and so on).













*CONFIDENTIALITY NOTICE: This email may contain confidential and

privileged material for the sole use of the intended recipient(s). Any

review, use, distribution or disclosure by others is strictly prohibited...

If you have received this communication in error, please notify the sender

immediately by e-mail and delete the message and any file attachments from

your computer. Thank you.*









_______________________________________________

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org><mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth







_______________________________________________

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org><mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth









--
[Image removed by sender. Ping Identity]<https://www.pingidentity.com/>
Brian Campbell
Distinguished Engineer
bcampbell@pingidentity.com<mailto:bcampbell@pingidentity.com>
w: +1 720.317.2061
c: +1 303.918.9415
Connect with us:
[Image removed by sender. Glassdoor logo]<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>[Image removed by sender. LinkedIn logo]<https://www.linkedin.com/company/21870>[Image removed by sender. twitter logo]<https://twitter.com/pingidentity>[Image removed by sender. facebook logo]<https://www.facebook.com/pingidentitypage>[Image removed by sender. youtube logo]<https://www.youtube.com/user/PingIdentityTV>[Image removed by sender. Blog logo]<https://www.pingidentity.com/en/blog.html>
[Image removed by sender.]<https://www.pingidentity.com/en/lp/e/enabling-work-from-home-with-MFA.html>
If you’re not a current customer, click here<https://www.pingidentity.com/en/lp/e/work-from-home-sso-mfa.html?utm_source=Email&utm_campaign=WF-COVID19-New-EMSIG> for a more relevant offer.

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.