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:tors...@lodderstedt.net] > Sent: Tuesday, July 23, 2019 5:06 PM > To: Roman Danyliw <r...@cert.org> > Cc: oauth@ietf.org; Vladimir Dzhuvinov <vladi...@connect2id.com> > 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 <r...@cert.org> 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:oauth-boun...@ietf.org] On Behalf Of Roman > Danyliw > >> Sent: Monday, July 22, 2019 8:51 PM > >> To: Torsten Lodderstedt <tors...@lodderstedt.net> > >> Cc: oauth@ietf.org > >> Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection- > >> response-03 > >> > >> Hi Torsten! > >> > >>> -----Original Message----- > >>> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] > >>> Sent: Monday, July 22, 2019 6:59 AM > >>> To: Roman Danyliw <r...@cert.org> > >>> Cc: oauth@ietf.org > >>> 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 <r...@cert.org> 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 > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
