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

[Torsten Lodderstedt <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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 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. 
  

> 
> 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.

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


> 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)?

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

> 
> 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.

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

> 
> 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.  

We added text about this to Sections 3 & 5.

> 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.

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?

> 
> 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.

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. 

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> idnits notes that RFC 5646 is mentioned but not present in the
> references section.

Gone since we removed the OIDC claims registration. 

> 
> 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.

Done

> 
> 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.

Changed to "opaque tokens"

> 
> 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.

Re-worked the example

> 
>   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?

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

> 
> 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.

Done

> 
>   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.

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

> 
>   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.

It’s mentioned in Section 3 now.

> 
> 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.

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

> 
> 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.

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.


> 
>   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?

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. 

> 
>   [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 [...]”.

Modified the text according to your suggestion.  

> 
>   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?

yes.

> 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]”).

done 

> 
>   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)?

Changed it to MAY(s)

> 
> 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.

We now state this in Sections 3 & 5.

> 
> 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]

It’s now in Section 3.

> 
> 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”]

Same changes as above

> 
> 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).

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

> 
> 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].

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. 

> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth