Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-jwsreq-07

From: John Bradley <[email-masked]>
Date: Fri, 1 Jul 2016 11:04:53 -0400

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth