Thanks, I will try and get to the changes before the cut off. John B.
> On Jun 29, 2016, at 9:57 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net> > wrote: > > 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 > > 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. > > FROM: > > > 1. 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. > > > There are a few cases that request by reference are useful such as: > > FROM: > > 1. 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: > > 1. 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. > > > You write: > > 2. 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:'. > > > 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. > > 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." > > 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"? > > 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? > > 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." > > 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). > > > 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? > > > 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. > > 1. Many WAP / feature phones do not accept large payloads. The > restriction are typically either 512 or 1024 ASCII characters. > > 2. The maximum URL length supported by older versions of Internet > Explorer is 2083 ASCII characters. > > 3. 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? > > Is a request by value even an option for a 2g mobile phone? > > 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. > > > 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. > > > 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? > > 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. > > 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? > > 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. > > ** 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 > > > [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 > > _______________________________________________ > 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
