Subject: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-07: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 02 Sep 2019 15:44:27 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-jwt-introspection-response-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Per the ongoing discussion on the WG list, it's unclear that we can
retain the behaviors we describe and still comply with the requirements
of RFC 7519 requirements for being a JWT (e.g., regarding "jti", "iat",
etc.).  That is, in the present formulation, there are two "token"s
involved -- the input that is being introspected, and the "token" that
is the introspection response.  We are claiming that certain fields are
describing the input token, when they are defined to be statements about
the current (response) token.
Relaxing our statements to say that we merely use JWS as opposed to JWT
may be a workaround, though I have thought about it hard enough to have
an opinion on whether it is the best workaround.

I also think we need more clarity about the use of dynamic client
registration by a resource server as outlined in Section 4 (where it's
mentioned as "with a resource server posing as the client", without
reference to RFC 7591.  As far as I can tell this document/section is
introducing this use of dynamic client registration by an RS for the
first time, so we cannot easily just refer to some other document.
Specifically, are there any fields that MUST NOT be supplied?  Is a
human-readable client_name useful?  How does the supplied client_uri
need to relate to any existing AS representation of a resource in
audience, scope, etc. (e.g., for the "resource" request parameter from
draft-ietf-oauth-resource-indicators)?

Is this usage considered to be a "new use of JWTs"?  If so, it seems
that we should follow the recommendation of draft-ietf-oauth-jwt-bcp and
use explicit typing.

I think there are some missing links in the document between a RS
registring client policy and the resulting AS enforcement of encryption
of introspection reponses.  I think the intent is roughly that the
policy will be applied based on the audience of the token being
presented for introspection (as opposed to the identity of the
RS-as-client making the introspection request), but we don't seem to
explicitly say that.  Also, we'd need to say something about the
interaction of multiple RSs' policy when a given token has multiple
valid audiences.  There is a very brief discussion in Section 6.5, but
it seems to be more of a description of what is possible than mandating
particular forms of enforcement.

I think we should discuss whether we want some statement from the OpenID
Foundation or related bodies before we register claims that point to
their documents with the IESG listed as change controller.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

idnits notes that RFC 5646 is mentioned but not present in the
references section.

Section 1

We probably need to move the 7519 reference up here to where JWT is
first used.

   OAuth 2.0 Token Introspection [RFC7662] specifies a method for a
   protected resource to query an OAuth 2.0 authorization server to
   determine the state of an access token and obtain data associated
   with the access token.  This allows deployments to implement
   identifier-based access tokens in an interoperable way.

Does "identifier-based access tokens" mean "tokens that are opaque keys
to a (central) database lookup" or "access tokens that convey user
identity information" (or something else)?  We may want to tweak the
wording.

Section 3

Can we double-check the base64 form of the response in this example?  I
am seeing output that backslash-escapes the '/' characters in URLs,
which I did not think was needed in this context.
I also see an "extension_field" claim in the base64 but not the decoded
form of the example, and "given_name"/"family_name"/"birthdate" in the
decoded example vs. "username" in the base64 version.

   Note: If the resource server policy requires a signed and encrypted
   response and the authorization server receives an unauthenticated
   request containing an Accept header with content type other than
   "application/jwt", it MUST refuse to serve the request and return an
   HTTP status code 400.  This is done to prevent downgrading attacks to
   obtain token data intended for release to legitimate recipients only
   (see Section 6.2).

I'd suggest a forward-reference to section 4 for how the AS will know
the RS's policy.  Although, given that "unauthenticated request" is
included in the preconditions, perhaps we do not need the conditional on
"resource server policy" at all?

Section 4

   The authorization server determines what algorithm to employ to
   secure the JWT for a particular introspection response.  This
   decision can be based on registered metadata parameters for the
   resource server, supplied via dynamic client registration with the
   resource server posing as the client, as defined by this draft.

nit: I suggest s/posing as the/acting as a/, and s/by this draft/below/,
since it's right here in this section.

   introspection_encrypted_response_alg  OPTIONAL.  JWE [RFC7516]
           algorithm ("alg" value) as defined in JWA [RFC7518] for
           encrypting introspection responses.  If this is specified,
           the response will be encrypted using JWE and the configured
           algorithm.  The default, if omitted, is that no encryption is

This text is slightly confusing with respect to the interaction between
the introspection_encrypted_response_alg "alg" value and the
introspection_encrypted_response_enc "enc" value.  My understanding is
that the "enc" is a symmetric bulk encryption scheme that directly
protects the payload, whereas the "alg" is a key-wrap or key-agreement
mechanism used to establish the key used as input for the "enc" method.
So, while "algorithm ("alg value") for encrypting introspection
responses" and "the response will be encrypted using the confugred
["algo"] algorithm" are technically true, they're also a bit misleading,
since this is not what encrypts the "bulk" of the response.  Using the
term from RFC 7158, "key management algorithm", would probably alleviate
this confusion.

   Resource servers may register their public encryption keys using the
   "jwks_uri" or "jwks" metadata parameters.

Should we cite 7591 for these (or, really, the whole section)?  We don't
currently mention it until the IANA considerations.

Section 5

Is it worth a note that resource servers will fetch these metadata and
use them as input to their dynamic registrations in the previous section
(i.e., picking from the list of supported algorithms)?

   introspection_encryption_alg_values_supported  OPTIONAL.  JSON array
           containing a list of the JWE [RFC7516] encryption algorithms
           ("alg" values) as defined in JWA [RFC7518] supported by the
           introspection endpoint to encrypt the response.

Similarly to the above, some refined text about "key management
algorithm" used to encrypt the response, would probably be helpful.

Section 6

There seem to be notable privacy considerations about quite a few of the
claims registered in Section 8.3.

Section 6.1

I'm surprised to not see discussion of explicit typing (and, IIUC, how
it's not a reliable mitigation) here.

   JWT introspection responses and OpenID Connect ID Tokens are
   syntactically similar.  An attacker could therefore attempt to
   impersonate an end-user at a OpenID Connect relying party by passing
   the JWT as an ID token.

nit: "response JWT" or "JWT response"

   Such an attack can be prevented like any other token substitution
   attack.  The authorization server MUST include the claims "iss" and
   "aud" in each JWT introspection response, with the "iss" value set to
   the authorization server's issuer URL and the "aud" value set to the
   resource server's identifier.  [...]

Related to the Discuss point, how does this relate to the dynamic client
registration parameters?

   [OpenID.Core].  Relying parties SHOULD also use and check the "nonce"
   parameter and claim to prevent token and code replay.

Is this SHOULD just referring to the behavior already described in
OpenID.Core (and only applicable to OIDC implementations as opposed to
JWT-instrospection consumers)?  If so, maybe descriptive language is
more appropriate, like "Relying parties are also expected to use and
check [...]".

   Resource servers utilizing JWTs to represent self-contained access
   tokens could be susceptible to replay attacks.  Resource servers
   should therefore apply proper counter measures against replay as
   described in [I-D.ietf-oauth-security-topics], section 2.2.

I'm not sure what part of this is specific to the introspection case.
Is it supposed to be tied to the risk that JWT-instrospection produces a
new route for the generation of JWT objects that could be confused for
self-contained access tokens?
nit: "countermeasures" is valid as a single word.
nit: it looks like it's section 3.2, now.

Section 6.2

Please cite RFC 7525 as BCP 195 as well as RFC 7525 (e.g., "per BCP 195
[RFC7525]").

   To prevent introspection of leaked tokens and to present an
   additional security layer against token guessing attacks the
   authorization server may require all requests to the token
   introspection endpoint to be authenticated.  As an alternative or as
   an addition to the authentication, the intended recipients may be set
   up for encrypted responses.

Do we want to make either of these "may"s into normative recommendations
(or make a recommendation for prevention of introspection data leakage
even in the face of token leakage, which can be satisfied by either
mechanism)?

Also, we could say more about how configuring encryption for intended
recipients protects against unencrypted replies to unintended
recipients...

   In the latter case, confidentiality is ensured by the fact that only
   the legitimate recipient is able to decrypt the response.  An
   attacker could try to circumvent this measure by requesting a plain
   JSON response, using an Accept header with the content type set to,
   for example, "application/json" instead of "application/jwt".  To
   prevent this attack the authorization server MUST NOT serve requests
   with content type other than "application/jwt" if the resource server
   is set up to receive encrypted responses (see also Section 3).

...such as by saying that the introspection response will only be made
available to RSes that are intended recipients of (in the audience of?)
the access token being introspected.

Section 6.3

   Authorization servers with a policy that requires token data to be
   kept confidential from OAuth clients must require all requests to the
   token introspection endpoint to be authenticated.  As an alternative
   or as an addition to the authentication, the intended recipients may
   be set up for encrypted responses.

[this also seems to be assuming a link not stated between RS policy and
AS enforcement, but it seems unlikely that a fix would need to touch
this text]

Section 8.1.1

nit: using nested lists might make this more readable.

   o  Client Metadata Description: String value specifying the desired
      introspection response encryption algorithm (alg value).

[same bit about "key management algorithm"]

Section 8.2.1

   o  Metadata Description: JSON array containing a list of algorithms
      supported by the authorization server for introspection response
      encryption (alg value).

[and here]

Section 8.3

I think we should make some mention earlier in the document
(Introduction?) that we also register some common claim values that are
in use in the wild (or whatever text you feel is appropriate to describe
the claims in question).

The nested lists would be great here as well.

Is there any expectation that some combination of "given_name",
"middle_name", and "family_name" will produce identical content to the
full "name" claim?

   o  Name: "preferred_username"

   o  Description: Shorthand name by which the End-User wishes to be
      referred to at the RP, such as janedoe or j.doe.  This value MAY
      be any valid JSON string including special characters such as @,
      /, or whitespace.

It seems like there may be some security considerations about sanitziing
this field before using it in an application's logic.

   o  Name: "profile"

   o  Description:URL of the End-User's profile page.  The contents of
      this Web page SHOULD be about the End-User.

It's slightly surpising to see this claimed for the end-user's profile
when it might equally apply to a protocol profile or variant in use.
But I assume this is already deployed, so there's no real point in
objecting to its registration...

   o  Name: "birthdate"

   o  Description:Time the End-User's information was last updated.  Its
      value is a JSON number representing the number of seconds from
      1970-01-01T0:0:0Z as measured in UTC until the date/time.

This seems potentially confusable with the user's day/year of birth.
(Also, are leap seconds excluded?)

   o  Name: "zoneinfo"

   o  Description: String from zoneinfo [zoneinfo] time zone database
      representing the End-User's time zone.  For example, Europe/Paris
      or America/Los_Angeles.

We seem to be missing the actual reference entry for [zoneinfo].

---

From: Justin Richer <[email-masked]>
Date: Wed, 4 Sep 2019 19:59:32 +0000

One of the issues I have with the current structure aligns with Ben’s comments below — we have two things that feel token-ish, the input token and the resulting JWT response. However, the JWT in the response is not actually a :token: in the OAuth sense. Instead, it’s an assertion that carries payload information :about: a token. The response itself isn’t a token and shouldn’t be treated as a token unto itself.

— Justin

On Sep 2, 2019, at 6:44 PM, Benjamin Kaduk via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:

Section 1

Section 3

Section 4

Section 5

Section 6

Section 6.1

Section 6.2

....such as by saying that the introspection response will only be made
available to RSes that are intended recipients of (in the audience of?)
the access token being introspected.

Section 6.3

Section 8.1.1

Section 8.2.1

[and here]

Section 8.3

  o  Name: "profile"

  o  Name: "birthdate"

  o  Name: "zoneinfo"

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 20 Sep 2019 15:01:13 +0200

Hi Ben, 

thanks a lot for your review comments.  

We just published a new revision that is intended to resolve all your DISCUSS and COMMENT.

https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08

> On 3. Sep 2019, at 00:44, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 

I thought about this as well but I think it wouldn’t solve the problem entirely. As you said, there are two token involved and we need to make the difference clear. 

We enhanced the wording of the draft to make the difference between the introspected token (that could be a JWT) and the introspection response in JWT format. I hope that helps.

Re the concrete issue: In my opinion, the use case brought up requires the AS to attest the time when the introspection endpoint response was created. It’s about non-repudiation for attesting that the access token was active at that time. 

We extended the text in section 5 accordingly. 

> first time, so we cannot easily just refer to some other document.

I understand. It’s being used in the wild but has never been mentioned in an OAuth draft. 

We added a section on trust management between AS and RS including references to dynamic client registration. 

https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08#section-3

> draft-ietf-oauth-resource-indicators)?

https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08#section-3 lists all fields we consider reasonable. 

> that we should follow the recommendation of draft-ietf-oauth-jwt-bcp and

We added a media type "application/token-introspection+jwt” and language describing it's use.

> explicitly say that.  

We added text about this to Sections 3 & 5.

> Also, we'd need to say something about the

Section 3 now states

The authorization server MUST be able to determine whether an RS is
   the audience for a particular access token and what data it is
   entitled to receive, otherwise the RS is not authorized to obtain
   data for the access token.  The AS has the discretion how to fulfil
   this requirement.  The AS could, for example, maintain a mapping
   between scopes values and resource servers.

Section 5 now states

If the access token is “..." is not
   intended to be consumed by the calling resource server (audience),
   the authorization server MUST set the value of the response claim
   "active" to "false".  Otherwise, this claim is set to "true”.

If possible, the AS MUST narrow down the "scope" value to the scopes
   relevant to the particular RS.

Does this work for you?

> their documents with the IESG listed as change controller.

After a discussion with the designated expert (Just Richer), we decided to remove the registration since the claims we want to include are already registered in the JWT Claims Registry. That’s sufficient for the use cases of this draft. 

Gone since we removed the OIDC claims registration. 

>   identifier-based access tokens in an interoperable way.

Done

> identity information" (or something else)?  We may want to tweak the

Changed to "opaque tokens"

> decoded example vs. "username" in the base64 version.

Re-worked the example

> "resource server policy" at all?

Since we added section 3, the prerequisites should be clearer now. 

> since it's right here in this section.

Done

> term from RFC 7158, "key management algorithm", would probably alleviate

Changed the text to consistently use “content key encryption" and "content encryption” 

> currently mention it until the IANA considerations.

It’s mentioned in Section 3 now.

> algorithm" used to encrypt the response, would probably be helpful.

Changed the text to consistently use “content key encryption" and "content encryption” 

> it's not a reliable mitigation) here.

Added this discussion to (now) Section 8.1

Any relying party processing the "typ" JWT header element should
   detect the attack since token introspection responses in JWT format
   set this header to the value "token-introspection+jwt".
   Unfortunately, this is not a well established practice yet.

> Related to the Discuss point, how does this relate to the dynamic client

The “aud" value depends on the way the AS identifies RSs (see section 3). Dynamic client registration is just one option for client management, I assume the AS would use the client_id in that case. 

> check [...]”.

Modified the text according to your suggestion.  

> self-contained access tokens?

yes.

> [RFC7525]”).

done 

> even in the face of token leakage, which can be satisfied by either

Changed it to MAY(s)

> the access token being introspected.

We now state this in Sections 3 & 5.

> AS enforcement, but it seems unlikely that a fix would need to touch

It’s now in Section 3.

> [same bit about "key management algorithm”]

Same changes as above

> in use in the wild (or whatever text you feel is appropriate to describe

We added a paragraph in Section 5 about use of OpenID Connect claims in introspection responses. 

> We seem to be missing the actual reference entry for [zoneinfo].

Thanks a lot again for your review and I hope we have resolved all of your DISCUSS and COMMENT with the new revision. 

best regards,
Torsten.