|
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", 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. 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".
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 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
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 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
|