Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-response-03

[Roman Danyliw <[e-mail]>]

Hi Torsten!

> -----Original Message-----
> From: Torsten Lodderstedt [mailto:[e-mail]]
> Sent: Monday, July 22, 2019 6:59 AM
> To: Roman Danyliw <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-
> response-03
> 
> Hi Roman,
> 
> thanks a lot for your review feedback.
> 
> I just published a new revision of the draft incorporating changes based on
> your comments.
> 
> https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-04

Thanks for the update. I have one refinement below based on the new language around TLS.  Details are inline ...

> > On 17. Jul 2019, at 18:17, Roman Danyliw <[e-mail]> wrote:
> >
> > Hi!
> >
> > The following is my AD review of draft-ietf-oauth-jwt-introspection-
> response-03.
> >
> > (1) Section 4.  Per introspection_encrypted_response_alg, how is either
> signing or encryption being requested?  Is it by also including an
> introspection_signed_response_alg?  If that's the case, it is worth explicitly
> saying.
> 
> The response is always signed. The resource server may decide to
> additionally turn on encryption.
> 
> Section 3 states “Depending on the specific resource server policy the JWT is
> either signed, or signed and encrypted. “

With the new language you added for item #2, I now understand.  Thanks for clearing it up.

> > (2) Section 4.  Per introspection_encrypted_response_enc, I'm having
> trouble deconflicting these two sentences:
> >
> > [1] If "introspection_encrypted_response_alg" is specified, the default for
> this value is A128CBC-HS256.
> >
> > [2] When "introspection_encrypted_response_enc" is included,
> "introspection_encrypted_response_alg" MUST also be provided
> >
> > Sentence [2] explicitly states that "introspection_encrypted_response_alg"
> is required.  However, the first sentence seems more tentative by saying that
> "if introspection_encrypted_response_enc" is present.
> 
> introspection_encrypted_response_enc is optional but must not be
> specified without introspection_encrypted_response_alg
> 
> I changed the text to better get this across:
> 
> introspection_encrypted_response_alg
> OPTIONAL. JWE algorithm (alg value) as defined in JWA 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 performed. If both signing and encryption are requested, the
> response will be signed then encrypted, with the result being a Nested JWT,
> as defined in JWT.
> 
> introspection_encrypted_response_enc
> OPTIONAL. JWE algorithm (enc value) as defined in JWA for authenticated
> encryption of introspection responses. The default, if omitted, is A128CBC-
> HS256. Note: This parameter MUST NOT be specified without setting
> introspection_encrypted_response_alg.

Thanks for this new text.  It is clearer.

 
> >
> > (3) I want to talk through the personally identifiable information being
> specified as new introspection fields per Section 8.3 (e.g., name, birthday)
> being exposed.  I was looking to ensure that it would always be encrypted in
> transit (and that only authorized clients could get it).  I read that in Section
> 3, "[d]epending on the specific resource server policy the JWT is either
> signed, or signed and encrypted" and that per Section 4 that "[t]he
> authorization server determines what algorithm to employ to secure the
> JWT for a particular introspection response."  Section 6.2 explicitly notes the
> threat of token data leakage (a more general case of my concern so thanks
> for that text). [RFC7662], Section 4 notes only that "the server MUST support
> Transport Layer Security (TLS) 1.2", but "support" is different than "the
> server MUST _use_ TLS". Therefore, it seems like there could be a case where
> the server could return an introspection response in the clear (e.g., no TLS,
> introspection_sig
> > ned_response_alg).  Am I missing something?
> >
> > My bias is to say something on the order of "TLS MUST be used”.
> 
> Section 6.2. now starts with “The authorization server MUST use Transport
> Layer Security (TLS) 1.2 (or higher) in order to prevent token data leakage."

Works for me to was use TLS.  I'd recommend a statement that provides more guidance "The authorization server MUST use Transport Layer Security (TLS) 1.2 (or higher) per RFC7525 in order to prevent token data leakage."

> > (4) I also want to talk through an unscrupulous protected resource trying to
> harvest introspection meta-data.  I was looking for guidance related to the
> authorization of the introspection transactions.  I found:
> >
> > Section 2.2 of [RFC7662] says important things like "For instance, an
> authorization server MAY limit which scopes from a given token are
> returned for each protected resource to prevent a protected resource from
> learning more about the larger network than is necessary for its operation."
> >
> > Section 4 of [RFC7662] says "If left unprotected and un-throttled, the
> introspection endpoint could present a means for an attacker to poll a series
> of possible token values, fishing for a valid token.  To prevent this, the
> authorization server MUST require authentication of protected resources
> that need to access the introspection endpoint and SHOULD require
> protected resources to be specifically authorized to call the  introspection
> endpoint."
> >
> > Section 6.2 of this draft provides guidance on defending against
> unauthenticated clients.
> >
> > How does the authorization server restrict a protected resource that _can_
> authenticate to it from getting meta-data is shouldn't have access to?
> Something on the order of "the authorization server <uses the following
> data> to determine what a given protected resource is allowed to see”.
> 
> I added Section 6.3, which states “The authorisation server determines the
> token data a resource server is allowed to see based on the resource server’s
> client_id and suitable token data, e.g. the scope value."

Great. Thanks for the clarity.

> >
> > (5) Editorial Nits
> >
> > ** Section 3.  Per "This JWT MAY furthermore contain all other claims
> described in Section 2.2. of [RFC7662] and beyond (e.g. as defined in
> [OpenID.Core])", would it be more timeless to say the fields specified in
> "OAuth Token Introspection Response" registry?
> >
> 
> This text pre-dated the addition of the IANA registry section. Thanks for
> spotting the inconsistency.
> 
> I modified the text as you suggested.
> 
> > ** Section 4.  The first sentence of each parameters descriptions don't
> parse -- for example with introspection_signed_response_alg: "JWS
> [RFC7515] 'alg' algorithm JWA [RFC7518] REQUIRED", fully expanded that's
> "JSON Web Signature (JWS) [RFC7515] "alg" algorithm JSON Web Algorithms
> (JWA) [RFC7518] REQUIRED ...".  The same is true for the write-ups in Section
> 5.
> 
> modfied text
> 
> >
> > ** Section 4.  Editorial.  Per "introspection_encrypted_response_enc":
> > s/REQUIRED for encrypting introspection responses/
> > REQUIRED for authenticated encryption of introspection responses/
> >
> 
> done

Thanks for all of the above.

Regards,
Roman

> kind regards,
> Torsten.
> 
> 
> > Regards,
> > Roman
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth