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

From: Roman Danyliw <[email-masked]>
Date: Wed, 17 Jul 2019 16:17:00 +0000

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.

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

(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_signed_response_alg).  Am I missing something?   

My bias is to say something on the order of "TLS MUST be used".

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

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

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

** Section 4.  Editorial.  Per "introspection_encrypted_response_enc":
s/REQUIRED for encrypting introspection responses/
REQUIRED for authenticated encryption of introspection responses/

Regards,
Roman

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 22 Jul 2019 12:58:30 +0200

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

> On 17. Jul 2019, at 18:17, Roman Danyliw <[email-masked]> wrote:
> 
> Hi!
> 

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

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

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. 

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

> ** 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 fie…

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 ex…

modfied text

> REQUIRED for authenticated encryption of introspection responses/

done

kind regards,
Torsten.  

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

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 23 Jul 2019 00:51:03 +0000

Hi Torsten!

> -----Original Message-----
> From: Torsten Lodderstedt [mailto:[email-masked]]
> Sent: Monday, July 22, 2019 6:59 AM
> To: Roman Danyliw <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-
> response-03
> 
> Hi Roman,
> 

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

> > (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.
> 
> 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:
> >
> > [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
> 
> 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.
> 
> 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
> 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."
> >
> > 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?
> >
> 
> > ** 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
> 
> >

Thanks for all of the above.

Regards,
Roman

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 23 Jul 2019 00:56:07 +0000

Hi Torsten!

Separately from the below, idnits is troubled by the lack of an RFC2119 section and the presence or absence of some reference despite citation:

==[ snip ]==

Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The document seems to lack the recommended RFC 2119 boilerplate, even if
     it appears to use RFC 2119 keywords. 

     (The document does seem to have the reference to RFC 2119 which the
     ID-Checklist requires).

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Missing Reference: 'RFC5322' is mentioned on line 471, but not defined

  == Missing Reference: 'RFC3966' is mentioned on line 537, but not defined

  == Missing Reference: 'RFC4627' is mentioned on line 562, but not defined

  ** Obsolete undefined reference: RFC 4627 (Obsoleted by RFC 7159)

  == Unused Reference: 'RFC2119' is defined on line 606, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC2246' is defined on line 611, but no explicit
     reference was found in the text

  == Outdated reference: A later version (-06) exists of
     draft-ietf-oauth-jwt-bcp-04

  == Outdated reference: A later version (-13) exists of
     draft-ietf-oauth-security-topics-11

  ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346)
==[ snip ]==

Roman

> From: OAuth [mailto:[email-masked]] On Behalf Of Roman Danyliw
> Sent: Monday, July 22, 2019 8:51 PM
> To: Torsten Lodderstedt <[email-masked]>
> Cc: [email-masked]
> Thanks for the update. I have one refinement below based on the new
> language around TLS.  Details are inline ...
> 
> > introspection_signed_response_alg?  If that's the case, it is worth
> > explicitly saying.
> >
> > Section 3 states “Depending on the specific resource server policy the
> > JWT is either signed, or signed and encrypted. “
> 
> > > [1] If "introspection_encrypted_response_alg" is specified, the
> > > default for
> > this value is A128CBC-HS256.
> > >
> > is required.  However, the first sentence seems more tentative by
> > saying that "if introspection_encrypted_response_enc" is present.
> >
> > 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.
> >
> > 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.
> 
> > 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
> > 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."
> 
> > harvest introspection meta-data.  I was looking for guidance related
> > to the authorization of the introspection transactions.  I found:
> > >
> > returned for each protected resource to prevent a protected resource
> > from learning more about the larger network than is necessary for its
> operation."
> > >
> > 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."
> > >
> > 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."
> 
> > [OpenID.Core])", would it be more timeless to say the fields specified
> > in "OAuth Token Introspection Response" registry?
> > >
> >
> > [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
> >
> > >
> > > s/REQUIRED for encrypting introspection responses/ REQUIRED for
> > > authenticated encryption of introspection responses/
> > >
> >
> > done
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 23 Jul 2019 23:06:04 +0200

Hi Roman, 

the latest revision -05 should address all points you raised.

https://www.ietf.org/id/draft-ietf-oauth-jwt-introspection-response-05.txt

kind regards, 
Torsten. 

> On 23. Jul 2019, at 02:56, Roman Danyliw <[email-masked]> wrote:
> 
> Hi Torsten!
>

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 23 Jul 2019 22:02:16 +0000

Hi Torsten!

Thank you for this update.  It does address my key issues.

With the IETF LC feedback can you please address this idnit introduced in this update:

  ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259)

Thanks,
Roman

> Sent: Tuesday, July 23, 2019 5:06 PM
> Cc: [email-masked]; Vladimir Dzhuvinov <[email-masked]>
> > Separately from the below, idnits is troubled by the lack of an RFC2119
> section and the presence or absence of some reference despite citation:
> >
> > ==[ snip ]==
> >
> > Miscellaneous warnings:
> >> With the new language you added for item #2, I now understand.  Thanks
> for
> >> clearing it up.
> >>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 24 Jul 2019 00:15:38 +0200

> Am 24.07.2019 um 00:02 schrieb Roman Danyliw <[email-masked]>:
> 

sure