Hi Hanness, Apparently, this mail did not go out so here it is ...
Hi Hannes, Thanks for the comment. Please see inline below. -----Original Message----- > From: OAuth [mailto:[email protected]] On Behalf Of Hannes Tschofenig > Sent: Wednesday, June 29, 2016 10:58 PM > To: [email protected] > Subject: [OAUTH-WG] Review of draft-ietf-oauth-jwsreq-07 > > Hi Nat, Hi John, > thanks for your work on draft-ietf-oauth-jwsreq. I would like to get the > document ready for the IESG and have therefore reviewed it. > Despite some minor issues I believe the document is in good shape. > Here are my comments: > ** Introduction > The example request in the introduction is longer than 72 characters. > s/textaual nature/textual nature done > s/The request may be encrypted so that end-to-end confidentiality may be > obtained even if in the case TLS connection is terminated at a gateway or a > similar device. /The request may be encrypted so that end-to-end > confidentiality can be provided even if the TLS connection is terminated at a > gateway. done > FROM: > The request can be signed so that an integrity check can be implemented. If a > suitable algorithm is used for the signing, then it will provide verification > of the client making the request. > TO: 1. The request may be signed so that the signer can be authenticated and > the integrity of the request can be checked. done > There are a few cases that request by reference are useful such as: > FROM: > When it is desirable to reduced the size of transmitted request. Since we are > using application layer security, it may substantially increase the size of > the request particulary in the case of using public key cryptography. > TO: > When it is desirable to reduce the size of transmitted request. The use of > application layer security increases the size of the request, particularly > when public key cryptography is used. done > You write: > Static signature: The client can make a signed Request Object and put it at a > place that the Authorization Server can access. This may just be done by a > client utility or other process, so that the private key does not have to > reside on the client, simplifying programming. Downside of it is that the > signed portion just become a token. > The downside is that there is that there is no indication of freshness and I > believe this is what you mean by "just became a token". I am not sure that > the term 'static signature' is the right term here. Just delete the 'Static > Signature:'. done > Is the JWT a good match to encode the parameters of the request? Why don't > you just use a regular JSON object and apply the JOSE security mechanisms to > it. We are using regular JSON object and applying the JOSE security mechanisms (e.g., adding iss, etc.) to create a JWT encoded JWS/JWE. > Section 3: Request Object > You write: " To encrypt, JWE [RFC7516] is used. Note that JWE is always > integrity protected, so if only integrity protection is desired, JWS > signature is not needed. " > I think the last sentence should say: "... if only integrity protection is > desired then JWE is not needed." Here, we are talking about whether to sign+encrypt or encrypt only, i.e., talking about the difference between the integrity protection and the potentially legally binding signature. For something to be "signed", the signer has to be able to find what is being signed. However, if the content was encrypted by the recipient's key, he cannot find what is in it. As the result, signing over it has not much value. > You write: > " It can also be signed then encrypted. This is sometimes desired to reduced > the repudiation risk from the point of view of the receiver. In this case, it > MUST be signed then encrypted, with the result being a Nested JWT, as defined > in JWT [RFC7519]. "client_secret > What do you mean by "reduced the repudiation risk"? The repudiation risk here is the risk of the signer start claiming that he has agreed to sign a statement. > It may help if you reference the example in Appendix A.2 of RFC 7519 > regarding a nest JWT. > You write: > " REQUIRED OAuth 2.0 Authorization Request parameters that are not included > in the Request Object MUST be sent as query parameters. If a required > parameter is missing from both the query parameters and the Request Object, > the request is malformed. " > s/REQUIRED/Required > That's a bit unfortunate that you have to send parameters twice -- once as > query parameters and then again in the request object. Is there no better way > to design this? It is not sending twice. It is saying that if the required parameter is not sent in the signed object, then it has to be sent as a query parameter. If it is included in the signed request object, it does not have to be sent in a query parameter. > Section 4: Authorization Request > You write: > " The authorization request object MAY be signed AND/OR encrypted. " > Why is this sentence needed when you have extensively spoken about this topic > already in earlier chapters? If you include it then write "The authorization > request object MAY be signed and/or encrypted." Just making doubly sure that people reads it. Perhaps it is redundant. > For the entire document I believe it is worthwhile to state in the > terminology section that your usage of the term "signed" means digitally > signing with asymmetric crypto system as well as using a MAC (which is a > symmetric key primitive). For combined cases, we should use "JWS Signature" which is a defined term in RFC7515 so that siganture (Digital Signature) retains its meaning. > You write: > " Servers MAY cache the contents of the resources referenced by Request URIs. > If the contents of the referenced resource could ever change, the URI SHOULD > include the base64url encoded SHA-256 hash as defined in FIPS180-2 > [FIPS180-2] of the referenced resource contents as the fragment component of > the URI. If the fragment value used for a URI changes, that signals the > server that any cached value for that URI with the old fragment value is no > longer valid. " > I am not sure what this means. Can you provide an example? OK. At the same time, I feel it would be better just to mandate different URI rather than asking for this specific mechanism. > You list a couple of restrictions of the request URI below" > " The entire Request URI MUST NOT exceed 512 ASCII characters. There are > three reasons for this restriction. > Many WAP / feature phones do not accept large payloads. The restriction are > typically either 512 or 1024 ASCII characters. > > The maximum URL length supported by older versions of Internet Explorer is > 2083 ASCII characters. > > On a slow connection such as 2G mobile connection, a large URL would cause > the slow response and using such is not advisable from the user experience > point of view. " > > I wonder how relevant they are (given that the size of the URI is > substantially increased due to the use of JWT & the JOSE work). For example, > are there still many WAP phones around that want to use this mechanism? Are > old versions of the Internet Explorer still an issue? The draft, as you may recall, was initially proposed in 2009. Compared to that, we have much less issues with longer URIs. Never-the-less, I would like to point out that this clause is only applicable when you are using Request URI, and in this case, this restriction deos not hart too much, while it would still be useful on 2G networks and legacy infrastructures like ATMs, which could be using Windows Embedded 2009 with IE6.0, which is going to be shipped till 2024. > Is a request by value even an option for a 2g mobile phone? Sure. It can be done on an iPhone on Edge network. > Section 5. Validating JWT-Based Requests > You write: "The Authorization Server MUST return an error if decryption > fails." and "The Authorization Server MUST return an error if signature > validation fails." Could you be a bit more precise about the error message > that is returned? From Section 6 I don't see what the right error response > would be. I have clarified it in the draft. > Section 8. Security Considerations: > FROM: > In addition to the all the security considerations discussed in OAuth > 2.0 [RFC6819], the following security considerations SHOULD be taken into > account. > TO: > In addition to the all the security considerations discussed in OAuth > 2.0 [RFC6819], the following security considerations should be taken into > account. > You write: > " When sending the authorization request object through "request" parameter, > it SHOULD be signed with then considered appropriate algorithm using > [RFC7515]. The "alg=none" SHOULD NOT be used in such a case. " > The use cases presented in the document talk about end-to-end security and > signed / encrypted requests. Now, in the security consideration section it > almost appears if there is the possibility that the request object would not > experience any security protection at all. > That does not appear right. It does not make sense to just send the > parameters in a different encoding only, or does it? I would only see a > disadvantage doing that, namely the much larger size. Correct. And that's why it is saying you should not do it. It is rather stupid to do it, but you never know what the developpers would do. I would agree to strengthen the language that alg=none MUST NOT be used, etc. > You write: > " If the request object contains personally identifiable or sensitive > information, the "request_uri" MUST be of one-time use and MUST have large > enough entropy deemed necessary with applicable security policy. For higher > security requirement, using [RFC7516] is client_secretstrongly recommended. " > Why is this so? Today, we send the same request in OAuth over TLS. Why is > there only a problem with the request_uri and not with sending the request > object? This came around to address privacy concerns if I remember correctly. If a same request URI was used persistently, it was pointed out that a third party Javascript can find that from browser history and use it to identify the user. The second sentence "For higher security ... " should probalby a separate paragraph as it is not directly related to the first sentence. Also, I feel that we should have a separate privacy consideration section and put them there. > I believe the biggest issue that should be discussed in the security > consideration section is the possibility that the request object may not be > fresh. This introduces the possibility for replay attacks and lowers the > quality of the end-to-end security protection. Right. > It may also be good to motivate the application layer security mechanisms a > bit more. For example, what information is in the request itself that > requires encryption? In OpenID Connect, some of the claims in the request may be sensitive. In pure OAuth context, scope value may be sensitive depending on the application. Encrypting these will protect leakage to a third party through browser history etc. > When I looked at the example I noticed the client_id and the absence of the > client_secret. I wonder how the mechanism intersects with the client_id and > the client_secret. If a client has, for example, a public / private key pair > configured then the use of JWS (with those credentials) would provide much > better security than a client_id and a client_secret. The example only depects the authorization request so client_secret is not being sent. I agree that public key crypto would give much better security than a client_secret, but this bit is out of scope of this spec. > ** Section 11: References > [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) > Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, > http://www.rfc-editor.org/info/rfc5246. > Could you reference the TLS BCP instead? https://tools.ietf.org/html/rfc7525 done. > [FIPS180-2] U.S. Department of Commerce and National Institute of Standards > and Technology, "Secure Hash Signature Standard", FIPS 180-2, August 2002. > Defines Secure Hash Algorithm 256 (SHA256) > Could you reference RFC 6234 instead? https://tools.ietf.org/html/rfc6234 > Ciao Hannes -- PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
