Hi Nat,
My replies to your proposed disposition of comments are embedded
in the text.
Thanks Denis. Here is my proposed disposition on
your comments.
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.
Accepted.
Thanks.
2. In Section 12 : Please remove my
name (Denis Pinkas) from this section.
Accepted.
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.
Noted.
There are bunch of MUST. At IETF we usually prefer MUST
to SHALL, unlike in ISO.
OK.
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.
Reject.
There are 4 flows in RFC6749. In each flow, there is a
sub-section dedicated to the Authorization request.
In them, the parameters used in the authorization request
are very clearly indicated. For example,
4.1.1. Authorization Request
The client constructs the request URI by adding the following
parameters to the query component of the authorization endpoint URI ...
It is very difficult to miss.
Then, the possibility for the extension parameters are
discussed in 8.2. Needless to say, those extension
parameters are going to be discussed in other
specifications.
Thus, it would be misleading just to say the parameters
defined in 4.1.1, 4.2.1, etc.
As an editor, I feel better with the current language
because it is at least not wrong nor misleading.
draft-ietf-oauth-jwsreq-11
states on page 7.
To sign, JSON Web
Signature (JWS) [RFC7515]
is used. The result is
a
JWS signed JWT [RFC7519]. If signed, the
Authorization Request
Object SHOULD contain the
Claims
"iss" (issuer) and "aud" (audience)
as members, with their
semantics being the
same as defined in the JWT
[RFC7519] specification.
This should be changed into:
To sign, JSON Web
Signature (JWS) [RFC7515]
is used. The result is
a
JWS signed JWT [RFC7519]. If signed, the
Authorization Request
Object MUST contain a
client_id
parameter and SHOULD contain a
"iss" (issuer) parameter
and an "aud" (audience) parameter, with
their semantics being
the same as
defined in the JWT RFC7519]
specification.
In section
5.2. Message Signature or MAC Validation, the text states:
When validating a JWS,
the following steps
are performed.
(...)
See Section 10.6
for security
considerations on algorithm
validation.
There is no
section 10.6 in this document. It seems to be section 10.3
Anyway, it
is not the right place to place requirements in a security
considerations
section and the appropriate text
should be moved in the main body of the
document.
RFC 6749
states in clause 4. Obtaining
Authorization on page
6.2. JWS Signed Request Object
To perform JWS Signature
Validation, the
"alg" Header Parameter in
the JOSE Header MUST match the value of the
pre-registered
algorithm.
The signature MUST be validated against the appropriate
key for that
"client_id" and algorithm.
The
important point is to provide guidance on how to map the client_id
parameter with the appropriate key.
There
is none at the present time.
Add:
Identifying
the appropriate
key MUST be done according to section 6
of RFC 7515 and using
the Registered
Header Parameter Names defined
in section 4.1 of RFC
7515, e.g.
using the Header Parameters "jku",
"jwk", "kid",
"x5u", "x5c", "x5t", or "x5t#S256".
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 ;
Reject.
This paragraph is talking about the integrity
protection and not the source authentication.
And even for source authentication, saying that
encryption under a secret key is not accurate as it was
discussed earlier in the WG mail.
I am not sure if "Introduction" needs to state everything
that is explained later. The idea of introduction probably
is to give main points. The list is not an exhaustive list
of the benefit of using JWT as the authorization request
format. For example, being able to encrypt the request,
which is not listed there, has an advantage of preventing
MITB to eavesdrop the request. So I think it is ok as is.
Integrity protection cannot be verified
without knowing the source of
the information. Using encryption (which supports at the same
time
an integrity
service when secret keys are being used) is another way to be
able to check the
integrity of the request.
So I maintain may comment.
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.
Reject
The third party indeed signs the request on behalf of the
client as the result of verification that the permission is
the same as previously agreed.
If it were the case, the client_id would
indicate the name of the third
party and the name of the user would be missing (or vice versa).
So I maintain my comment.
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.
Reject.
In the above sentence, "with then considered
appropriate algorithm" applies both on JWS
and JWE.
The intent of the phrase is that a vulnerable algorithm
should not be used.
Also, I do not understand why the algorithm has to be
symmetric key algorithm.
Maybe, this explains why you didn't
understand the previous comment.
With public key encryption, it is not possible to authenticate
the source of
the request, while it is possible with secret key encryption
when the encrypted
data includes a cryptographic checksum
like a hash value and an error
propagation method for the encryption algorithm.
So I maintain my comment.
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.
Reject.
The implication is given right after the sentence. There
is no variable called "nonce" in RFC6749. Since this
document is just defining
another encoding method for OAuth 2.0 authorization request
as a framework, it does not mandate these.
An extension specification should define those requirements.
Note that this section belongs to the
security considerations section
which SHOULD NOT be normative and should only provide guidance.
The sentence right after is the following:
It has a performance
disadvantage, but
where such disadvantage is
permissible, it should be
considered.
It does not provide any guidance.
The key point is that a parameter able to
detect replay needs to be
included in the request. This should be indicated in the
normative part.
It is
unfortunate that RFC 7515 has not addressed replay protection of
JWS and only
mentions the problem is section 10.10 which is in the
security considerations
section. Here it is:
10.10. Replay
Protection
While
not directly in scope
for this specification, note that
applications
using JWS (or
JWE) objects can thwart replay attacks by
including
a unique message
identifier as integrity-protected content
in
the JWS (or JWE) message
and having the recipient verify that the
message
has not been
previously received or acted upon.
The text on page 7 should be changed
into:
To sign, JSON Web
Signature (JWS) [RFC7515]
is used. The result is
a
JWS signed JWT
[RFC7519]. If signed,
the Authorization Request
Object MUST
contain a client_id
parameter and a "nonce" extension
parameter
allowing to detect
replay attacks and SHOULD
contain an "iss"
(issuer) parameter
and an
"aud" (audience) parameter, with their
semantics being the
same as defined
in the JWT specification[RFC7519].
Note that Page 7 uses the
"nonce" parameter in the example.
"Nonce" is mentioned in OpenID Connect Core
1.0 incorporating
errata set 1.
It is described as :
|
nonce
|
Value used to associate a Client session
with an ID Token
|
This is too restrictive since now a nonce
should be included in a JWS
token.
The registration is as follows:
- Parameter
name: nonce
- Parameter
usage location: Authorization Request
- Change
controller: OpenID Foundation Artifact Binding Working Group -
openid-specs-ab@xxxxxxxxxxxxxxxx
- Specification
document(s): Section 3.1.2 of this
document
- Related information: None
Section 3.1.2 states:
3.1.2.
Authorization Endpoint
The Authorization Endpoint performs
Authentication of the End-User. This
is done by sending the User Agent to the Authorization Server's
Authorization
Endpoint for Authentication and Authorization, using request
parameters defined
by OAuth 2.0 and additional parameters
and parameter values defined by OpenID
Connect.
Communication with the Authorization
Endpoint MUST utilize TLS. See Section 16.17
for more
information on using TLS
This has nothing to do with the nonce. Hence
the nonce registration
information has been badly defined.
The OpenID specification also states:
"The Client
SHOULD check the nonce value for replay
attacks. The precise method for detecting replay
attacks is Client specific".
This does not allow to interoperate.
Rather than correcting the registration
information in the OpenID
specification, it would be better to suppress it from the OpenID
specification
and incorporate it within an IETF RFC.
In order to avoid nonces to be kept in a
memory for ever, a good
practice is to split the nonce in two parts:
- one of them
includes a UTC NumericDate
using the format defined in RFC 7519, and
- the other one
includes a random number.
In
this way only recent nonces (e.g. received during the last 5
minutes) need to
be kept in memory.
Three or four bytes
for the random number will be sufficient.
In order to allow for interoperability,
a format should be specified.
I
propose a NumericDate defining the UTC time concatenated with a
random number
with three bytes.
"Nonce" has not been officially registered
by IANA. An IANA
Considerations section should be added in draft-ietf-oauth-jwsreq-
to register the "nonce" parameter.
On page 14, section 6.2., after the previous
proposed text which is:
Identifying
the appropriate
key MUST be done according to section 6
of RFC 7515 and using
the Registered
Header Parameter Names defined
in section 4.1 of RFC
7515, e.g.
using the Header Parameters "jku",
"jwk", "kid",
"x5u", "x5c", "x5t", or "x5t#S256".
I proposed to add the following text:
To perform JWS Signature
Validation, the
"nonce" Header Parameter in
the JOSE Header MUST be
present and MUST be
checked to verify that
the signed request is
not the replay
of a previous signed request.
A section defining the nonce parameter should be
added.
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.
Accepted with modification.
You mean, symmetric key algorithm, is that right? I would
add "or verifying that the symmetric key for the JWE encryption is a correct one"
Accepted
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.
Reject.
It is referring to the first paragraph of the
sub-section. Also, precaution when security is in question
is a good thing.
This sentence is simply
useless and thus should be
deleted. Hence, I maintain this comment.
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).
Reject.
You are not getting what OAuth does. The party that holds
personal data is the authorization server / resource.
It is not the client. The client is the party who is
getting those "resources" which may contain personal data.
Yes, the client can provide some personal data to the
resource depending on what that resource endpoint is, but
that is out of scope for OAuth.
As far as OAuth is concerned, what is being sent from the
client to the resource is the access token.
The dispute is whether the protected resource
contains or not personal data.
The data contained by the protected resource may
well be public data (or/and personal data).
It does not need to be only "personal data".
Hence, I
maintain my comment.
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.
Noted.
RFC6749 only defines how to define extension parameters.
This specification draws from OpenID Connect for some
examples of extension parameters such as nonce.
See section 4 for example.
See my earlier comments where client_id and nonce shall be
mandatory.
Denis
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
_______________________________________________
OAuth mailing list
OAuth@xxxxxxxx
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura
Chairman of the Board, OpenID Foundation