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

Benjamin Kaduk <kaduk@mit.edu> Mon, 04 May 2020 05:59 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 3121E3A0CBA for <oauth@ietfa.amsl.com>; Sun, 3 May 2020 22:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 zGV9ocuq7Oq9 for <oauth@ietfa.amsl.com>; Sun, 3 May 2020 22:59:32 -0700 (PDT)
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 01E2B3A0CB9 for <oauth@ietf.org>; Sun, 3 May 2020 22:59:31 -0700 (PDT)
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 0445xOxZ012423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 4 May 2020 01:59:26 -0400
Date: Sun, 03 May 2020 22:59:23 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Denis <denis.ietf@free.fr>
Cc: Vittorio Bertocci <vittorio.bertocci@auth0.com>, "oauth@ietf.org" <oauth@ietf.org>
Message-ID: <20200504055923.GH27494@kduck.mit.edu>
References: <CAGL6epKuHTqLrZEjm0goKV+3jaPfTkN_JSLc0jfQyPqNzeP3aA@mail.gmail.com> <125f32d3-dd3b-3add-1172-391acd831cde@free.fr> <MWHPR19MB150159025ECBAD75B6DDE1DFAEAD0@MWHPR19MB1501.namprd19.prod.outlook.com> <79748d92-c084-c6f9-20b1-163cb5760d11@free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <79748d92-c084-c6f9-20b1-163cb5760d11@free.fr>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/_uzGnaFiPHNRGawxruOY3mT4MT8>
Subject: Re: [OAUTH-WG] Second 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: Mon, 04 May 2020 05:59:35 -0000

Hi Denis,

You seem to be continuing to be operating under incorrect assuptions about
how OAuth 2.0 works, and have proceeded to make long chains of reasoning
that, unfortunately, are not based on a solid foundation.  In order to
reduce the amount of frustration amongst all participants, in the future I
strongly suggest that you make sure you have the fundamentals correct
before going into long chains of reasoning.

Furthermore, while you have indeed identified some areas where the current
OAuth ecosystem could be improved, I reiterate that the current document,
defining a token format that is optional to use, is not the place to make
changes to how OAuth works.  I think you do everyone a disservice for
attempting to suggest that this document should do so.

Because there is so much based on a flawed foundation, I will not respond
inline to every point, but do see a few things where further clarification
would be useful.

On Thu, Apr 30, 2020 at 11:50:04AM +0200, Denis wrote:
> Hello Vittorio,
> 
> Your reply was amazingly fast. Responses are between the lines.
> 
> > Thanks Denis for the thorough commentary.
> >
> > /> The title of this spec./
> >
> > Fixed, thanks!
> >
> 
> > /> The client MUST NOT inspect the content of the access token/
> >
> >
> > This is really a sticky point. I really want to acknowledge your PoV 
> > on this, but at the same time I found this to be one of the biggest 
> > sources of issues
> > in the use of JWT for access tokens hence I feel we really need to 
> > give solid guidance here. Let me expand further on the reasoning 
> > behind it,
> > and perhaps we can get to language that satisfies both PoVs.
> >
> >
> > To me the key point is that clients should not write /code/ that 
> > inspects access tokens. Taking a dependency on the ability to do so is 
> > ignoring fundamental information
> > about the architecture and relationships between OAuth roles, and 
> > suggests an ability of the client to understand the semantic of the 
> > content that cannot be assumed
> > in the general case. I expanded on the details in my former reply to 
> > you on this topic, I would recommend referring to it.
> >
> > Clients violating this simple principle has been one of the most 
> > common sources of production issues I had to deal with in the past few 
> > years, and one of the hardest
> > to remediate given that clients are hard to update and sometimes the 
> > things they relied on were irremediably lost. This is why I am 
> > inclined to put in here strong language.
> >
> > That said: I have nothing against client developers examining a 
> > network trace and drawing conclusions based on the content of what 
> > they see. That doesn’t create any hard
> > dependencies and has no implications in respect to changes in the 
> > solution behavior. However I am not sure how to phrase that in the 
> > specification, given that referring
> > to the client inevitably refers to its code. I am open to suggestions.
> >
> First of all, a "*MUST NOT* "should not be placed in a privacy 
> considerations section, but in the main body of the document.
> The goal of a privacy considerations section is to provide explanations, 
> but not to introduce additional requirements.

That's not actually a requirement.  In many cases it makes sense to avoid
putting normative requirements in the security and/or privacy
considerations sections, but it is very much a thing that is done in many
RFCs, and in some cases it is useful to do so.

> Then after, since this section is about privacy considerations, it is 
> important to refer to an ISO standard that has been published 9 years ago.

Is it?  I don't see much precedent for IETF documents referencing this ISO
standard.  If it's so important you'd think that we'd have been citing it
with regularity.  Since this will be the first or second time, I think you
need to provide some additional justification as to how the topics it
covers fit within the existing IETF BCPs for how we treat security and
privacy considerations before we conclude that it is the appropriate
reference.

> It is ISO 29100 (Information technology — Security techniques — Privacy 
> framework). Most of the ISO standards need to be bought.
> However, there are a few exceptions and this standard can be freely 
> downloaded from the ISO web site, if you accept some conditions,
> using this URL:
> 
>     https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
> 
> ISO 29100, even if it is outdated on some aspects (it only deals with 
> two entities), identifies ten principles (See Table 3).
> 
>     1. Consent and choice
> 
>     2. Purpose legitimacy and specification
> 
>     3. Collection limitation
> 
>     4. Data minimization
> 
>     5. Use, retention and disclosure limitation
> 
>     6. Accuracy and quality
> 
>     7. Openness, transparency and notice
> 
>     8. Individual participation and access
> 
>     9. Accountability
> 
>     10. Information security
> 
>     11. Privacy compliance
> 
> If the client is unable to inspect the token, then openness and 
> transparency do not exist any more.
> 
> Since there is no formal protocol in OAuth 2.0  for "consent and 
> choice", the only way for a client for denying its consent is to inspect 
> the token
> and to stop its transmission if the content of the token is not 
> considered to be adequate for it.
> 
> Since you are open to suggestions, would you please reconsider the text 
> I proposed: it simply states that if the client wants to inspect the token,
> it will not necessarily be in a position to do it. It is simply a 
> warning, but this warning does not prevent the client to attempt to 
> inspect the token .
> 
> I will go one step further: if the client wants to inspect the token and 
> if the format of the token is unknown to the client, then the client 
> will simply
> stop its further transmission. For some clients, preserving their 
> privacy may be more important than performing an access to a RS.

That may be true, but I agree with Vittorio that this document needs to
strongly discourage clients from doing so, since they would be breaking a
protocol invariant if they do.

Thanks,

Ben

> > >  3)…
> >
> > I have a pretty hard time following the chain of reasoning in this 
> > section. Let me attempt to tackle it to the best of my understanding.
> >
> > I think the key might be
> >
> > /> a client should be able to choose whether it wishes the sub claim 
> > to contain [..]
> >
> > /
> >
> > I don’t think that should be a choice left to the client. In business 
> > systems, my experience is that the type of identifiers to be used 
> > (when the IdP gives any choice at all)
> >  is established at resource provisioning time. I am not aware of 
> > mechanisms thru which a client signals the nature of the identifier to 
> > be used, nor that would be fully
> > feasible (the resource knows what it needs to perform its function).
> >
> Consent and choice is the first of the ten privacy principles. Since 
> OAuth has not been constructed taking into considerations this privacy 
> principle,
> it is quite "normal" that you don't observe protocols able to do it at 
> the present time.
> 
> > Furthermore:
> >
> > /> which has nothing to do with uniqueness since the value changes for 
> > every generated token.
> >
> > /
> >
> > Again, this is something that was touched on in my former reply to 
> > your message. As long as an identifier identifies one resource only, 
> > it satisfies uniqueness. It doesn’t have to be a singleton.
> >
> It is a matter of interpretation. I stick to the definition given in RFC 
> 7519 (section 4.1.2):
> 
> *T**he subject value MUST either be scoped to be locally unique in the 
> context of the issuer or be globally unique.*
> 
> However, the "context of the issuer" is left undefined.
> 
> > Finally, the scope is optional (for good reasons: 1^st party and non 
> > delegation scenarios don’t require it) hence it cannot be relied upon 
> > for properties that should hold in every scenario.
> >
> I would not say that the scope request parameter is a nice way to choose 
> which attributes should be placed in a JWT. However, considering the 
> limitations placed
> in this document, it is the ONLY way to do. In my email sent before the 
> virtual meeting, I wrote: "Allowing a client to only specify a scope and 
> a resource is very restrictive".
> 
> Clause 2.2.2 (second paragraph) states:
> 
> ***This profile does not introduce any mechanism for a client to**
> ******directly request the presence of specific claims in JWT access**
> ******tokens*, as the authorization server can determine what additional
> claims are required by a particular resource server by taking in
> consideration the client_id of the client, the scope and the resource
> parameters included in the request.
> 
> Currently, the client has no control of the claims that will be placed 
> in a JWT and further more the current wording of privacy consideration 
> section
> prevents the client to have any inspection of the attributes that have 
> been placed in a JWT. Privacy principles 1 and 7 from ISO 29100 are not 
> fulfilled.
> 
> There are more implications. If, in the future, a mechanism is defined 
> to allow the client to choose the type of the attributes that should be 
> placed in a JWT,
> then the "sub" claim is insufficient. Taking into consideration my 
> previous email, four types of attributes types would need to be specified:
> 
> The client should be able to choose whether it wishes a claim that contains:
> 
>   *      a global unique identifier for all ASs ("globally unique"),
>   *      a unique identifier for each AS ("locally unique in the context
>     of the issuer"),
>   *      a different pseudonym for each RS, or
>   *      a different pseudonym for each authorization token request.
> 
> Clause 2.2.2 states:
> 
> *   the authorization server can determine what additional**
> ******claims are required by a particular resource server* by taking in
> consideration the client_id of the client, the scope and the resource
> parameters included in the request.
> 
> I don't believe this is true in general. Considering its privacy 
> preferences, only the client may know what is appropriate: not the AS, 
> neither the RS.
> 
> > In summary: per the preceding thread on this topic, the consensus was 
> > that varying the sub content was a satisfactory way of protecting 
> > against correlation.
> >
> "/if all you have is a hammer, everything looks like a nail/".
> 
> When the only parameter that can be used is the "sub" claim, then the 
> only solution is to place everything into it.
> 
> > I don’t a gree that clients should have a mechanism to request 
> > different sub flavors, as that decision should be done out of band by 
> > the AS and RS; and the scope isn’t always available anyway.
> >
> While it would be nice to have such a mechanism, we are not going to 
> define such a mechanism during a second WGLC.
> 
> The privacy considerations section should only inform the readers about 
> the limitations of the protocol in terms of privacy.
> I have proposed text to address the point. If you would prefer a 
> different wording to address this point, please make another proposal.
> 
> > /> targeting of access tokens/
> >
> > Let me think about that a bit longer.
> >
> > I acknowledge that the decision of including an audience has the 
> > effect of letting the AS track when the client accesses a particular 
> > resource,
> > but at the same time that’s completely mainstream and very much by 
> > design in a very large number of cases. As such, I find the language
> > you are suggesting to be potentially confusing, as it positions this 
> > as an exception vs a privacy protecting mainstream that is in fact not 
> > common,
> > and ascribes to the client more latitude than I believe is legitimate 
> > to expect or grant.
> >
> > I’ll try to come up with concise language that clarifies to the reader 
> > that the current mechanism does allow AS tracking.
> >
> Please do so.
> 
> Denis
> 
> > *From: *OAuth <oauth-bounces@ietf.org> on behalf of Denis 
> > <denis.ietf@free.fr>
> > *Date: *Wednesday, April 29, 2020 at 09:12
> > *To: *"oauth@ietf.org" <oauth@ietf.org>
> > *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile 
> > for OAuth 2.0 Access Tokens"
> >
> > You will find four comments numbered 1) to 4).
> >
> > *1) *The title of this spec. is:
> >
> > JSON Web Token (JWT) Profile for OAuth *2.0* Access Tokens
> >
> > So, this spec. is supposed to be targeted to OAuth *2.0. * However, 
> > the header at the top of the page omits to mention it.
> >
> > Currently, it is :
> >
> > Internet-Draft OAuth Access Token JWT Profile           April 2020
> >
> > It should rather be:
> >
> > Internet-Draft OAuth *2.0* Access Token JWT Profile           April 2020
> >
> > *2)* The following text is within section 6.
> >
> > The client MUST NOT inspect the content of
> > the access token: the authorization server and the resource server
> > might decide to change token format at any time (for example by
> > switching from this profile to opaque tokens) hence any logic in the
> > client relying on the ability to read the access token content would
> > break without recourse.
> > Nonetheless, authorization servers should
> > not assume that clients will comply with the above.
> >
> > It is of a primary importance that clients MAY be able to inspect 
> > tokens before transmitting them.
> > The "MUST NOT" is not acceptable.
> >
> > The above text should be replaced with:
> >
> > Reading the access token content may be useful for the user to verify 
> > that
> > the access token content matches with its expectations. However,
> > the authorization server and the resource server might decide to 
> > change the
> > token format at any time.  Thus, the client should not expect to 
> > always be
> > in a position to read the access token content.
> >
> > The remaining of the text about this topic is fine.
> >
> >
> > *3) *The next topic is about the sub claim.
> >
> > The text states:
> >
> > Although the ability to correlate requests might be required by
> > design in many scenarios, there are scenarios where the authorization
> > server might want to prevent correlation to preserve the desired
> > level of privacy. Authorization servers should choose how to assign
> > sub values according to the level of privacy required by each
> > situation.
> >
> > I have a set of questions:
> >
> >  1. How can authorization servers choose how to assign sub values
> >     according to the level of privacy required "by each situation" ?
> >  2. How can authorization servers know the level of privacy required
> >     "by each situation" ?
> >  3. How can the users be informed of the level of privacy required "by
> >     each situation" ?
> >  4. How can the users *consent* with the level of privacy required "by
> >     each situation" ?
> >
> > Currently, the request MUST include either a resource parameter or an 
> > aud claim parameter, while it MAY include a scope parameter.
> >
> > The syntax of the scope parameter is a list of space-delimited, 
> > case-sensitive strings (RFC 6749). It is thus subject to private 
> > agreements
> > between clients and Authorization Servers. Since the scope is being 
> > returned, it is a primary importance that the returned scope matches
> > with its expectations before transmitting the token to a Resource Server.
> >
> > In theory, a client should be able to choose whether it wishes the sub 
> > claim to contain :
> >
> >   * a global unique identifier for all ASs ("globally unique"),
> >   * a unique identifier for each AS ("locally unique in the context of
> >     the issuer"),
> >   * a different pseudonym for each RS, or
> >   * a different pseudonym for each authorization token request.
> >
> > The only variable parameter that it can use for this purpose in the 
> > token request is the scope parameter.
> >
> > RFC 7519 states is section 4.1.2:
> >
> > The subject value MUST either be scoped to be locally unique in the 
> > context of the issuer
> > or be globally unique.
> >
> > It is quite hard to recognize that the sub claim is able to carry a 
> > different pseudonym for each RS, i.e. for case (c), or
> > a different pseudonym for each authorization token request, i.e. for 
> > case (d), which has nothing to do with uniqueness
> > since the value changes for every generated token.
> >
> > This has implications about the following text:
> >
> > For instance: if a solution requires preventing tracking
> > principal activities across multiple resource servers, the
> > authorization server should ensure that JWT access tokens meant for
> > different resource servers have distinct sub values that cannot be
> > correlated in the event of resource servers collusion.
> >
> > Since it addresses case (c).
> >
> > and also about the following text:
> >
> > 4.b) Similarly: if a solution requires preventing a resource server from
> > correlating the principal’s activity within the resource itself, the
> > authorization server should assign different sub values for every JWT
> > access token issued.
> >
> > Since it addresses case (d).
> >
> > This means that the current text placed in the privacy considerations 
> > section was a good attempt to address the case,
> > but that the text needs to be revised.
> >
> > Proposed text replacement for all the previously quoted sentences:
> >
> > According to RFC 7519 (4.1.2): The subject value MUST either be scoped 
> > to be locally unique in the context of the issuer or be globally unique.
> >
> > When the sub claim contains a globally unique identifier, this allows 
> > to correlate principal activities across multiple resource servers, 
> > while in addition,
> > this globally unique identifier may also allow to correlate the 
> > principal activities on servers where no access has been performed by 
> > the principals
> > to these servers but where the same globally unique identifiers are 
> > being used by these servers.
> >
> > When the sub claim contains a locally unique identifier in the context 
> > of the issuer, this also allows the tracking of principal activities 
> > across multiple resource servers.
> >
> > The scope request parameter is the only way to influence on the 
> > content of the sub claim parameter. Its meaning is subject to a 
> > private agreement
> > between the client and the AS, which means that the use of the scope 
> > parameter is the only way to choose between a locally unique identifier
> > in the context of the issuer or a globally unique identifier.
> >
> > Since the scope parameter is being returned, it is a primary 
> > importance that the returned scope matches with the expectations of 
> > the client before transmitting
> > the token to a Resource Server.
> >
> > However, there are other cases where the client would like to be able 
> > to choose whether it wishes the sub claim to contain :
> >     - a different pseudonym for each RS so that different resource 
> > servers will be unable to correlate its activities, or
> >     - a different pseudonym for each authorization token request, so 
> > that the same resource server cannot correlate its activities 
> > performed at different instant of time.
> >
> > Considering the semantics of the sub claim, these two cases cannot be 
> > currently supported.
> >
> >
> > *4) *The next topic is about the targeting of access tokens
> >
> > Text had been proposed before the last conference call. Then, the 
> > topic has been presented at the very end of the last conference call, 
> > but no text has been included
> > in the next draft.
> >
> > Here is a revised text be included in the privacy considerations section:
> >
> > For security reasons, some clients may be willing to target their 
> > access tokens but, for privacy reasons, may be unwilling to disclose 
> > to Authorization Servers
> > an identification of the Resource Servers they are going to access, so 
> > that Authorization Servers will be unable to know which resources 
> > servers are being accessed.
> > The disclosure of the Resource Servers names allows the Authorization 
> > Servers to list all the Resource Servers being access by all its users 
> > and in addition to list pairs
> > of (Principal, Resource Servers) which allow to trace all the users 
> > accesses to Resource Servers performed through a given Authorization 
> > Server. When a token is targeted,
> > this profile does not contain provisions to address these two threats.
> >
> > Denis
> >
> >     Hi all,
> >
> >     This is a second working group last call for "JSON Web Token (JWT)
> >     Profile for OAuth 2.0 Access Tokens".
> >
> >     Here is the document:
> >
> >     https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06
> >
> >     Please send your comments to the OAuth mailing list by April 29, 2020.
> >
> >     Regards,
> >
> >      Rifaat & Hannes
> >
> >
> >
> >     _______________________________________________
> >
> >     OAuth mailing list
> >
> >     OAuth@ietf.org  <mailto:OAuth@ietf.org>
> >
> >     https://www.ietf.org/mailman/listinfo/oauth
> >
> 

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