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

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-jwt-introspection-response-08: 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:
----------------------------------------------------------------------

Thank you for the updates in the -08; they address the bulk of the
substantive issues!  I have a few points remaining on the -08 text but I
think there are more localized issues to resolve.

Can IANA please confirm that the new allocations in the -08 have
received appropriate Expert (e.g., media type) review?  I see some
updates in the datatracker history relating to the -08 but nothing in
the email archives.

It looks like we need to register 'active' as a JWT claim?

I don't think the new semantics for "jti" in the introspection response
are compatible with the RFC 7519 definition.  Specifically, we say that
"jti" will be tied to the input access token, but 7519 says that "jti"
has to change when the contents of the JWT change ("MUST be assigned in
a manner that ensures that there is a negligible probability that the
same value will be accidentally assigned to a different data object"),
and we admit at least the possibility of "active" and "iat" changing.

Section 5 says that:

   If the access token is considered active, it MUST contain the claims
   "iss" and "aud" in order to prevent misuse of the JWT as an ID or
   access token (see Section 8.1).

But I don't think the predicate is correct -- misuse is still possible
by services that do not check the "active" claim's value.  Shouldn't the
"iss"+"aud" requirements be unconditional?


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

[New comments on the added text in the diff from -07 to -08.]

Section 3

   To support encrypted token introspection response JWTs, the
   authorization server MUST also be provided with the respective
   resource server encryption keys and algorithms.

IIRC, based on some list discussion this text was going to be tweaked to
avoid implying that JWE is mandatory.  (Unfortunately, this is the
thread that evolved into "client certs and TLS Terminating Reverse
Proxies", so it's hard to be sure whether I saw any other followups.)

   The AS MUST restrict the use of client credentials by a RS to the
   calls it requires, e.g. the AS MAY restrict such a client to call the
   token introspection endpoint only.  How the AS implements this
   restriction is beyond the scope of this specification.

This should probably be clarified a bit more, in the context of "client
credentials tend to be used by privileged, fixed endpoints, and the
default may just be to allow them all access to all endpoints".  Right
now it's not clear what's being restricted (and who "it" is that
requires calls)

Section 5

   This specification registers the "application/token-
   introspection+jwt" media type, which is used as value of the "typ"
   header parameter of the JWT to indicate that the payload is a token
   introspection response.

Do we also want to note that checking 'jti' is not mandatory and so this
does not necessarily provide full protection?  (I guess Section 8.1
covers this in more detail.)

   The value of the "aud" claims MUST identify the resource server
   receiving the token introspection response.

We may want to dig into this a bit more: should there be any
relationship between this "aud" value and the "client_id" that an RS
might be using (as obtained from dynamic registration)?
Does this value need to be different from the audience that is used in
access tokens for which this RS is the audience?  (Should it be the
same?)  My instincts lean towards "different" but I would like broader
input.

   exp     The "exp" claim indicates when the access token passed in the
           introspection request will expire.

On the face of it this seems divergent from RFC 7519's "the expiration
time on or after which the JWT MUST NOT be accepted for processing",
though upon further examination the distinction is not quite so large.
That is, it's in effect saying that the introspection response should
not be accepted for processing after the base token has expired, which
usually makes sense.  There is a bit of a complication, though, in that
the "active" claim implies that we might still have RSes that plan to
use the introspection response after the "exp" date has passed, which
sounds a lot like a DISCUSS-level internal inconsistency.

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

This sounds kind of like a "SHOULD"...

   The example response header contains the following JSON document:

I think this is the JOSE header in the HTTP response (body), not the
(HTTP) response header.

Section 8.1

   As an alternative approach, such an attack can be prevented like any
   other token substitution attack by restricting the audience of the

I'd suggest avoiding describing these as "alternatives"; they seem more
like complementary approaches as part of a defense-in-depth solution
(especially since we are basically mandating both of them).

   "aud" value set to the resource server's identifier.  Any recipient
   of an JWT MUST check these values in order to detect substitution
   attacks.

This "MUST" might be out of place -- this is a requirement from RFC
7519, and not an attempt by this document to make new requirements on
the behavior of all JWT consumers (if it was, that would be a DISCUSS
point!).

   Resource servers MUST additionally apply the countermeasures against
   replay as described in [I-D.ietf-oauth-security-topics], section 3.2.

In a similar vein, which set of resources servers is this normative
"MUST" intended to be binding upon?

Section 9

   In any case, the AS MUST ensure that the scope of the legal basis is
   enforced throughout the whole process.  The AS MUST retain the scope
   of the legal basis with the access token, e.g. in the scope value,
   and the AS MUST determine the data a resource server is allowed to
   receive based on the resource server's identity and suitable token
   data, e.g. the scope value.

I suspect I'm just being dense, but could you walk me through how the
access token "scope" value can encode the legal basis for data transfer?