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

[Roman Danyliw <[e-mail]>]

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

> -----Original Message-----
> From: Torsten Lodderstedt [mailto:[e-mail]]
> Sent: Tuesday, July 23, 2019 5:06 PM
> To: Roman Danyliw <[e-mail]>
> Cc: [e-mail]; Vladimir Dzhuvinov <[e-mail]>
> Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-
> response-03
> 
> 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 <[e-mail]> wrote:
> >
> > 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
> >
> >> -----Original Message-----
> >> From: OAuth [mailto:[e-mail]] On Behalf Of Roman
> Danyliw
> >> Sent: Monday, July 22, 2019 8:51 PM
> >> To: Torsten Lodderstedt <[e-mail]>
> >> Cc: [e-mail]
> >> Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-
> >> response-03
> >>
> >> 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-respons
> >>> e-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
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/oauth