Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwsreq-11.txt> (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Comments on I-D Action: draft-ietf-oauth-jwsreq-11.txt

 

Two editorial comments first :

 

1. Guidance is a mass noun, not a count noun, plural doesn't make sense. Please change "guidances" into "guidance" twice in Section 11.

 

2. In Section 12 : Please remove my name (Denis Pinkas) from this section.

 

Other comments:

 

3. Section 1.1 (from boiler plate) states: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

There is not a single other occurrence of the word SHALL within this document. In such case, I wonder how this document can be normative.
There are however many (useful) "
non-normative examples. A non-normative example does not replace requirements.

 

Section 4 states:

 

   A Request Object (Section 2.1) is used to provide authorization

   request parameters for an OAuth 2.0 authorization request.  It

   contains OAuth 2.0 [RFC6749] authorization request parameters

   including extension parameters. 

 

RFC 6749 contains 75 pages, but does not contain a single occurrence of the wording "authorization request parameter" nor of "extension parameter".
There should be either references to one or more specific sections of this document or, even better, a list of the mandatory/recommended/possible
authorization request parameters as well as a list of mandatory/recommended/possible extension parameters should be included in this document.


A clear distinction should be made between the parameters used to authenticate the request and the other ones.

 

4. The introduction states on page 4:

 

     (a) (integrity protection) The request can be signed so that the integrity of the request can be checked ;

 

This should be changed into:

 

     (a) (integrity protection) The request can be authenticated either using a digital signature or using encryption under a secret key
          so that the integrity of the request can be checked ;

 

 

5. The introduction states on page 4:

 

(d) (collection minimization) The request can be signed by a third party attesting that the authorization request is compliant to certain policy.

The request is not signed by a third party.


However, later on, there is the following explanation:

 

   In addition, it allows requests to be prepared by a third party so that a client application cannot request
   more permissions than previously agreed. 

 

If it is the intent, the sentence should be rephrased as:

 

(d) (collection minimization) The request can be verified by a third party attesting that the authorization request is compliant to certain policy.

 

 

6. Section 10.1. the text states:

 

   When sending the authorization request object through "request"

   parameter, it MUST either be signed using JWS [RFC7515] or encrypted

   using JWE [RFC7516] with then considered appropriate algorithm.

 

The wording" with then considered appropriate algorithm" is too vague. This should be changed into:

 

   When sending the authorization request object through "request"

   parameter, it MUST either be signed using JWS [RFC7515] or encrypted

   using JWE [RFC7516] using a symmetric key algorithm.

 

 

7. Section 10.2 states:

 

   This means that the request object is going to be prepared fresh each

   time an authorization request is made and caching cannot be used. 

 

What are the implications ? Is it required/recommended to use a nonce ? The text should be made clearer.

 

8. Section 10.3 states:

 

10.3.  Request Source Authentication

 

   The source of the Authorization Request MUST always be verified.

   There are several ways to do it in this specification.

 

   (a)  Verifying the JWS Signature of the Request Object.

 

It seems that the case of using a JWE encrypted using a secret key algorithm has been forgotten here. Please add it.

 

9. Section 10.3 states at its very end:

 

   An extension specification

   should be created as a preventive measure to address potential

   vulnerabilities that have not yet been identified.

 

Writing a document for vulnerabilities that have not yet been identified is speculative. It would rather be better
either to remove this sentence or to explain what is meant by it.

 

10. Section 11.1 states:

 

11.1.  Collection limitation

 

   When the Client is being granted access to a protected resource

   containing personal data, the Client SHOULD limit the collection of

   personal data to that which is within the bounds of applicable law

   and strictly necessary for the specified purpose(s).

 

The presentation of personal data should be limited whether or not the protected resource contains personal data.

 

It is proposed to change this text into:

 

   When the Client requests an access to a protected resource, the Client

   SHOULD limit the presentation of personal data to that which is within

   the bounds of applicable law and strictly necessary for the specified

   purpose(s).

 

11. Section 11.2.1 states:

 

11.2.1.  Request Disclosure

 

   This specification allows extension parameters.

 

It would be useful to name either all of them or some of them. RFC 6749 is not crystal clear about this.

 


Denis Pinkas (DP Security Consulting SAS)

 

==============================================================




The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document:
- 'The OAuth 2.0 Authorization Framework: JWT Secured Authorization
   Request (JAR)'
  <draft-ietf-oauth-jwsreq-11.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2017-02-13. Exceptionally, comments may be
sent to iesg@xxxxxxxx instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   The authorization request in OAuth 2.0 described in RFC 6749 utilizes
   query parameter serialization, which means that Authorization Request
   parameters are encoded in the URI of the request and sent through
   user agents such as web browsers.  While it is easy to implement, it
   means that (a) the communication through the user agents are not
   integrity protected and thus the parameters can be tainted, and (b)
   the source of the communication is not authenticated.  Because of
   these weaknesses, several attacks to the protocol have now been put
   forward.

   This document introduces the ability to send request parameters in a
   JSON Web Token (JWT) instead, which allows the request to be JWS
   signed and/or JWE encrypted so that the integrity, source
   authentication and confidentiality property of the Authorization
   Request is attained.  The request can be sent by value or by
   reference.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information: 
    rfc6234: US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) (Informational - IETF stream)
    rfc6819: OAuth 2.0 Threat Model and Security Considerations (Informational - IETF stream)
    rfc6973: Privacy Considerations for Internet Protocols (Informational - IAB stream)
Note that some of these references may already be listed in the acceptable Downref Registry.


_______________________________________________
OAuth mailing list
OAuth@xxxxxxxx
https://www.ietf.org/mailman/listinfo/oauth



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]