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

[Vladimir Dzhuvinov <[e-mail]>]

Hi Benjamin,

Thanks a lot for your comments.

We discussed them and applied several changes to the draft to address them.

Those changes can be previewed here:

https://github.com/oauthstuff/draft-ietf-oauth-jwt-introspection-response/compare/address-comments-benjamin-kaduk-2021-01-26

Further comments inline:

On 27/01/2021 06:32, Benjamin Kaduk via Datatracker wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-oauth-jwt-introspection-response-10: 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:
> ----------------------------------------------------------------------
>
> We've made a lot of progress at unravelling the gnarly issues relating
> to merging the introspection response and JWT claims namespaces, which
> is good.  That said, I'd still like to discuss a little bit more the
> behavior described in Section 5, where the "token_introspection" claim
> in the response can also contain JWT claims (''' In addition, claims
> from the JSON Web Token Claims registry [IANA.JWT] established by
> [RFC7519] MAY be included as members in the "token_introspection"
> claim.''')  That seems to be granting carte blanche to do the thing that
> was deemed problematic, i.e., mix the namespaces.  As such, the current
> formulation in the document, in the general case of independent
> uncoordinated implementations, seems to admit the prospect of an AS
> adding something to an introspection response under the guise of the JWT
> claim exception that is interpreted by the recipient RS as a new
> introspection response parameter (or, I think, vice versa).  Yes, this
> would require conflicting registrations to occur, but we still don't
> have a procedure in place that would prevent such conflicting
> registrations from occurring in the future.  How can we add some
> low-cost safety controls that mitigate the risk while still enabling the
> desired functionality?
>
> I have a couple thoughts on this: there is already an exception for
> implementation/service-specific (unregistered) claims in the
> introspection response, which could apply to JWT claims under the same
> requisite conditions of administrative control, if that's going to cover
> the scenarios in question.  One could also imagine a new registration
> procedure for introspection response parameters whereby (for example)
> any non-conflicting value already registered as a JWT claim can be
> mechanically propagated into the introspection response registry
> potentially just by IANA without even expert review.  Then we would just
> require the contents to be registered introspection response parameters,
> and someone who wants to use JWT claims can trivially get them
> registered before using them.

To recap, the moving of the RFC 7662 response parameters into a
token_introspection claim was to keep the JWT-specific claims - iss,
iat, aud (RFC 7519) and the introspection parameters nicely separated
and thus prevent potential conflicts / confusion between them.

Speaking of the token introspection parameters, it was identified that
certain applications need to obtain additional attributes related to the
resource owner, besides the need to have the introspection response
signed. For those attributes there happen to be suitable claims, such as
email, name, etc., already registered in the JWT IANA registry, and it
may make sense to reuse those names. Those are names from OpenID Connect
intended to be used inside ID tokens and UserInfo JWTs.

We updated the draft to state that when such claims get included, care
must be taken.

> selected claims from the JSON Web Token Claims registry established by
> RFC7519 MAY be included as members in the token_introspection claim,
> provided their names don't collide with OAuth Token Introspection
> Response registry claims and care is taken to prevent other potential
> conflicts and ambiguity. 

In OpenID Connect there is a certain allowance for mixing claims from
two "namespaces", for example in ID tokens which may include claims
about the end-user besides those that are defined for the ID token
itself. What helps here is having clear indication in the IANA JWT
registry what the originating spec for a claim name is.


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I'm not balloting this at a DISCUSS-level, because it may just be me
> failing to understand the intended meaning (or being forgetful), but I'm having a hard time
> seeing how we're self-consistent about the requirement for an RS to
> authenticate and authorize a given RS for a given introspection
> transaction.  In particular, in Section 3 we see that "the authorization
> server MUST be able to identify, authenticate and authorize resource
> servers" and that "[t]he 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".  While I see that there is also some
> discussion about using the "scope" parameter of the token being
> introspected as an indicator of the RS it is to be used for (and thus
> the identity of the RS that would legitimately be making an
> introspection request), and I also see discussion of using an encrypted
> introspection response as a way to ensure that the contents are only
> viewable by the intended RS, I'm not sure how clearly either (or both)
> mechanisms constitute "authentication" of the introspection request.
> Since we already require a "strong two-way trust relationship", it's not
> clear to me that it would be difficult to strongly authenticate the
> actual introspection request itself or that there is much gained by
> skipping such a check in favor of other mechanisms.  Several of my
> inline comments touch on this topic (on the assumption that there is a
> strong MUST for strong authentication); I left them in place to benefit
> from the context of where they appear, rather than constructing a
> laundry list of all of them.  That said, it will suffice to explain how
> I'm wrong/confused just once; there's no need to repeat it at each place
> I bring up the topic.

The draft was updated to make the MUST requirement for client
authentication consistent.

Originally, the intent was to allow for RFC 7662 style behaviour
alongside the JWT response style, but as you pointed out there are
issues with that, and it was dropped entirely.


>
> 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.
>
> That seems more of a descriptive than a normative "must", to me.

The section was updated to

> The authorization server MAY additionally encrypt the token
> introspection response JWTs. If encryption is used the authorization
> server is provisioned with encryption keys and algorithms for the RS.


>
> Section 4
>
>    A resource server requests a JWT introspection response by including
>    an "Accept" HTTP header "application/token-introspection+jwt" in the
>    introspection request.
>
> nit: "header field". and probably also something about "containing" or
> "with body".

Fixed.


>
>    The AS SHOULD authenticate the caller at the token introspection
>    endpoint.  Authentication can utilize client authentication methods
>    or a separate access token issued to the resource server.  Whether a
>    resource server is required to authenticate is determined by the
>    respective RS-specific policy at the AS.
>
> I don't think this can be only a SHOULD-level requirement and be
> consistent with the MUST-level requirements in the previous section
> (most notably, "[AS] MUST be able to determine whether an RS is the
> audience for a particular access token".  It is hard to believe that an
> unauthenticated RS could have such authorization.

The draft was updated to make this consistent everywhere.

We now have:

> The AS MUST authenticate the caller at the token introspection
> endpoint. Authentication can utilize client authentication methods or
> a separate access token issued to the resource server and identifying
> it as subject.



>
>    The following is a non-normative example request with client
>    authentication:
>
>    POST /introspect HTTP/1.1
>    Host: as.example.com
>    Accept: application/token-introspection+jwt
>    Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
>
> (side note: "Authorization: Basic" makes me sad.)

Updated the example for private_key_jwt authentication.


>
> Section 5
>
>    The introspection endpoint responds with a JWT, setting the "Content-
>    Type" HTTP header to "application/token-introspection+jwt" and the
>
> nit: "header field" again.

Fixed.


>
>            If possible, the AS MUST narrow down the "scope" value to the
>            scopes relevant to the particular RS.
>
> What's the difference between "if possible, <X> MUST" and "<X> SHOULD"?

Edited to

> The AS SHOULD narrow down the scope value to the scopes relevant to
> the particular RS.

>
>    The JWT MAY include other claims, including those from the "JSON Web
>    Token Claims" registry established by [RFC7519].  The JWT SHOULD NOT
>    include the "sub" and "exp" claims as an additional prevention
>    against misuse of the JWT as an access token (see Section 8.1).
>
> nit: I think a comma after "'exp' claims" would increase clarity.

Thanks, fixed.


>    The JWT is cryptographically secured as specified in [RFC7662].
>
> I think that this was intended to refer to 7519 (JWT), not 7662
> (introspection)?

Thanks, the RFC ref was corrected.


>
>    Depending on the specific resource server policy the JWT is either
>    signed, or signed and encrypted.  If the JWT is signed and encrypted
>    it MUST be a Nested JWT, as defined in JWT [RFC7519].
>
>    Note: If the resource server policy requires a signed and encrypted
>
> (nit?) Just to confirm: the "resource server policy" here is a policy
> that's applied at the AS on a per-resource-server basis?  If so, perhaps
> writing it "resource-server-specific policy" would clarify.

Clarified as suggested.


>
>    response and the authorization server receives an unauthenticated
>    request containing an "Accept" header with content type other than
>    "application/token-introspection+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 8.2).
>
> An unauthenticated request should be denied unconditionally, right?
> Should this MUST apply to just requests containing the "Accept" header
> (field) with other content-types?

The section was rewritten to

> Note: If the AS requires signed introspection responses for some or
> all resource servers it MUST refuse to serve introspection requests
> that don't authenticate the caller 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
> "token_data_leakage").

This greatly simplified things and allowed the security recommendations
section to be shortened significantly.



>
>    The example response JWT payload contains the following JSON
>    document:
>    [...]
>      "token_introspection":
>         {
>            [...]
>            "scope":"read write dolphin",
>
> Is there any chance the minimizer that was run on this payload as input
> to JWT generation also removed the spaces in the scope string?  I seem
> to be having some unexpected behavior from my local tooling, but it is
> looking like the claims set from the example HTTP payload lists
> "scope":"readwritedolphin".

I'm not sure what the issue here is, but we'll keep an eye on the
formatting of this example.


> Section 8.2
>
>    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.
>
> Isn't this ("require all requests to be authenticated") also a MUST now?

This section was removed entirely with the requirement to have all
requests authenticated.

The potential loophole of using a bearer access token for the
introspection endpoint where the authorised subject is not identified
(RFC 7662, section 2.2) is closed now.

https://tools.ietf.org/html/rfc7662#section-2.2


Vladimir

-- 
Vladimir Dzhuvinov