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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
