Re: [OAUTH-WG] AD Review of draft-ietf-oauth-access-token-jwt-10

Vittorio Bertocci <vittorio.bertocci@auth0.com> Fri, 22 January 2021 22:15 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 6D62B3A0CFF for <oauth@ietfa.amsl.com>; Fri, 22 Jan 2021 14:15:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 u8ek1Pz99Pqz for <oauth@ietfa.amsl.com>; Fri, 22 Jan 2021 14:15:43 -0800 (PST)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 7BB223A1484 for <oauth@ietf.org>; Fri, 22 Jan 2021 14:14:54 -0800 (PST)
Received: by mail-pg1-x52f.google.com with SMTP id z21so4765341pgj.4 for <oauth@ietf.org>; Fri, 22 Jan 2021 14:14:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=1WIM5hueFDfkBB2SHWn3yVuSX6qp8Y6cI6kFF7cksVE=; b=MsmbUgQwEk2DMc9tWIINR0YviuiXQ5FwXD28u7K5GPxNxX4eIx8ITGqbrVRhlSAWeu iAVVdYkYVEwkQMcjGk0YTHzFwtVKT7F3hMLdyTWVRwcy6kwRk0Xc+3OAGlfXJCMTVdey nw7Ax9D7k4PfZsE019f3QTW/OYOcp/C8Yu82kufW18Eyezu6PmswJcu6Slu/A5oFWQzv HYcywL7NHG5cFvPhJBkSJUwuvyEYrElVY2XTH2lNVZIxzbBwJFUfLljV2teJCO9Oomhb 3aDNhnA4NCkxbzWjJrEN21wg79v0Xuqg2xsXOtqf11stSEeb9hsbkiNtws/T71KmImac u9xQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=1WIM5hueFDfkBB2SHWn3yVuSX6qp8Y6cI6kFF7cksVE=; b=OTl/ZAts2FOb8a9d+O2cykTb4cKbzRtTnh4qg9FYvY7LamKG3aDpfhAoIMYdDtzlyq y5jgccRravNLJItSFE79JP5fQLZWj7TyZOuHBvnjob7V43CusXsXYqooMx4BuPsqIr55 0UPAtES+s1Ftdac364uA3mzvwZijssNrKJ78Q1hZATvspQ/7OmoUjV8GM+odberZZ5AN nalIedN0PV2PJhlcIn0Xuhq4fr99D0VKTAhnFP3jfBn432gyi3Fb/uVncDmsehN2Sy8P NbZhK6uwIG5XLtbnm6ZqxHzirc9fMbglH2G6We7cOv1t2nsKWCRyDzEUiaBOW4M7OouS rzCw==
X-Gm-Message-State: AOAM532k47fhceop+sgi1how5XGypwOocHHuVLO/9dVosIUesRc+Okc5 cX00RdWFUyWPNnoBJqHVSjj51Jed1z2SPw==
X-Google-Smtp-Source: ABdhPJxWMTev4LvOsrUoIzEo1NL8zAWWsg4DlsKMWKOqxk8uee2TjVimL/n/FJ3LAqios9jQ2dYXSQ==
X-Received: by 2002:a62:8801:0:b029:1b9:c4af:8148 with SMTP id l1-20020a6288010000b02901b9c4af8148mr7199465pfd.18.1611353693555; Fri, 22 Jan 2021 14:14:53 -0800 (PST)
Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id c4sm3090249pfo.35.2021.01.22.14.14.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jan 2021 14:14:52 -0800 (PST)
From: Vittorio Bertocci <vittorio.bertocci@auth0.com>
To: Roman Danyliw <rdd@cert.org>, "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] AD Review of draft-ietf-oauth-access-token-jwt-10
Thread-Index: Ada7bYibjuDIkiTCR8eXer4b6TfeyQC4rcyECus6VlABw7Xgdw==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Fri, 22 Jan 2021 22:14:51 +0000
Message-ID: <CO6PR18MB40520FB85F76BAD976D7FE75AEA09@CO6PR18MB4052.namprd18.prod.outlook.com>
References: <c55fe95c27fd4d00a2685db2f847330c@cert.org> <MWHPR19MB1501B53CB115878B196F4DFDAEE00@MWHPR19MB1501.namprd19.prod.outlook.com> <bde2d97fdb63468ab300fb2dbe352e6a@cert.org>
In-Reply-To: <bde2d97fdb63468ab300fb2dbe352e6a@cert.org>
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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/8xAM87oI8K9nS1jrSh9TvZUljEs>
Subject: Re: [OAUTH-WG] AD Review of draft-ietf-oauth-access-token-jwt-10
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, 22 Jan 2021 22:15:45 -0000

NP, thank you for the followup!
I posted an update reflecting the feedback and comments. We're version 11. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-11
Thanks
V.

On 1/14/21, 06:35, "Roman Danyliw" <rdd@cert.org> wrote:

    Hi Vittorio!
    
    So sorry for the delay, I didn't appreciate this was awaiting on a response.
    
    > -----Original Message-----
    > From: Vittorio Bertocci <vittorio.bertocci@auth0.com>
    > Sent: Thursday, November 19, 2020 3:45 AM
    > To: Roman Danyliw <rdd@cert.org>rg>; oauth@ietf.org
    > Subject: Re: [OAUTH-WG] AD Review of draft-ietf-oauth-access-token-jwt-10
    > 
    > Thank you Roman for the thorough review!
    > I applied all the editorial and typo fixes. I have a few questions on some
    > comments, once solved I'll update accordingly and push a new version.
    > Thanks!
    > Inline
    > 
    > 
    > >On 11/15/20, 08:39, "OAuth on behalf of Roman Danyliw" <oauth-
    > bounces@ietf.org on behalf of rdd@cert.org> wrote:
    > >[..]
    > >    ** Section 2.2.2.  Per "Any additional attributes whose semantics   Any
    > additional attributes whose semantics are well described by the attribute's
    > description found in Section 5.1 of [..]
    > >   Maybe my read it wrong, but it seems like this text saying that beyond the
    > required claims listed in section 2.2, you can use any of the other claims as long
    > as they are in the IANA JWT registry.  Isn't that simpler, since the Section 5.1.
    > OpenID.Core attributes are registered?
    >  You are right, that's not very clear.
    > In a nutshell, what I am trying to say is "if you want to express an attribute for
    > which there's already a well-established claim available, use that rather than
    > inventing  new one.".
    > That still allows for non-IANA claims to be introduced, as long as the
    > implementer has done the due diligence and verified that the attribute they
    > convey isn't covered in the IANA JWT registry.
    > I explicitly mention OpenID Connect as source of claims mostly to ensure that
    > the reader will understand at first glance that when it comes to user
    > information a JWT AT can convey the same information obtained via OpenID
    > Connect, without the need to follow the link and consult the change
    > controller/reference column of the claims to realize that. One of the goals I am
    > hoping this spec will achieve is to stop people from abusing ID tokens and using
    > them in lieu of access tokens (as Kubernetes routinely does, for example),
    > hence the "denormalized" language of that section.
    > Here's an alternative formulation that tries to preserve that clarity while
    > referring to the registry:
    > 
    > "Any additional identity attribute whose semantic is well described by an entry
    > in the JSON Web Token (JWT) IANA registry introduced in [RFC7519] SHOULD
    > be encoded using the corresponding claim name.
    > Note that the JWT IANA registry includes the claims found in Section 5.1 of
    > [OpenID.Core]."
    > 
    > What do you think? Waiting for your feedback before changing the language in
    > the draft
    
    This looks fine to me.
    
    > >    ** Section 3.  What would be the case where it would not be appropriate
    > for the resource parameter value to be the same as the aud claim in the access
    > token (the text currently says SHOULD, why not MUST?)?
    > This was actually a MUST until draft 3, then Brian pointed out that this would
    > have made this profile more restrictive than resource indicators itself- which
    > led me to soften the requirement accordingly. Brian's comment in its entirety:
    > |Resource Indicators is about how the client conveys the target to the AS and
    > says " The authorization server may use the exact 'resource' value as the
    > audience or it may map from that value to a more general URI or abstract
    > identifier for the given resource". The following from |sec 3 is more restrictive /
    > prescriptive, which seems to reach beyond the scope of the JWT access token
    > profile.
    > ||  "If the request includes a resource parameter (as defined in
    > || [ResourceIndicators]), the resulting JWT access token aud claim MUST
    > ||   have the same value as the resource parameter in the request."
    
    Oh, got it.  Thanks for explaining.
    
    > >    ** Section 4. Per the validation guidelines on access token validation, is
    > there parallel text needed to discuss the RS use of the token say: checking that
    > the acr has a value that is appropriate (so it can have confidence in the security
    > of > the authentication used between client/AS)? Or that the right
    > entitlements/groups/etc were present for the requested operation?
    > That's a good point. The last paragraph of section 4 was meant to be a catch-all
    > for those cases, mentioning entitlements under the "authorization claims"
    > umbrella and everything else as "any other contextual information". The thing
    > that makes me hesitate before getting more specific than that is that it can be
    > a slippery slope (acr, amr, entitlements etc are good candidates, but the same
    > might be said about auth_time for max_age like scenarios, for example... where
    > to draw the line?) and being those optional, not everyone might readily
    > understand without adding more color/context. Combined with how difficult
    > reaching consensus for the inclusion of session properties in access tokens, plus
    > the fact thatRFC6750 does not give RS specific guidance for how to act on
    > authorization info (scopes), I opted for generic language.
    > If you feel strongly about more specific guidance being required for those
    > claims, I can propose more specific language- but before doing so, I wanted to
    > offer the context above to see if it changes things.
    
    Hmm.  I wish it could be clearer but I now understand the trade off you made.  Please leave the text as is.
    
    >  >   ** Section 5.  This text seems to restate much of the text from
    > [OAuth2.Security.BestPractices].  Do other section apply here?  Perhaps also
    > add that the SecCons of individual claims apply here too if used in the profile
    > (as this profile allows pretty much anything in the JWT registry to be used).
    > I combed draft-ietf-oauth-security-topics-16 and besides the parts about sub,
    > client_id and aud (already referenced by the current spec, or further restricted-
    > as it the case for the audience considerations), the BCP doesn’t appear to offer
    > further guidance that would vary depending on the content of the token. The
    > guidance seems mostly on how the token is obtained, and the mechanisms
    > described operate at the message level hence apply to JWT access tokens and
    > opaque tokens in the same way. Did you have any specific section of the BCP in
    > mind?
    > I also took a look at rfc7519 SecCon and it doesn’t appear to offer claims-
    > specific considerations. Finally, I combed thru rfc8725 and it seems the current
    > spec covers all the content specific recommendations that apply to this
    > scenario, namely in section 4 for the audience, issue and subject validation, and
    > section 2.1 and 4 for the strong typing.
    > Bottom line: I could add a generic recommendation to consider
    > OAuth2.Security.BestPractices, rfc7519 and rfc8725 when considering the
    > security of a JWT access token, but the only section that seem directly
    > applicable seems the 4.14 we already reference. What do you think? Do we
    > need that blanket reference?
    
    I re-read [OAuth2.Security.BestPractices] and my suggestion; and agree with your assessment.  Almost nothing in the BCP is about specific to the token content and format which this narrow focus of this draft.
    
    Again, sorry for delay.
    
    Regards,
    Roman
    
     
    >