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

[Denis <[e-mail]>]

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.
>
> On Fri, Feb 3, 2017 at 8:11 PM Denis <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     *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 <https://tools.ietf.org/html/rfc6749#section-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-11states 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_idparameter 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
>     tocertain 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
>     tocertain 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 madeand 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.


    JSON Web Token Claims are listed at:
    https://www.iana.org/assignments/jwt/jwt.xhtml

"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
    - [e-mail]
  * Specification document(s): Section 3.1.2
    <http://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint>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 
<http://openid.net/specs/openid-connect-core-1_0.html#TLSRequirements>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 noncevalue 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 fourbytes 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 theJWE 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
>>     [e-mail] <mailto:[e-mail]>  mailing lists by 2017-02-13. Exceptionally, comments may be
>>     sent [e-mail] <mailto:[e-mail]>  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
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
> -- 
>
> Nat Sakimura
>
> Chairman of the Board, OpenID Foundation
>