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 <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. “ > > (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. > > (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." > > (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." > > (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 kind regards, Torsten. > Regards, > Roman > > _______________________________________________ > 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
