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