Re: [OAUTH-WG] AD review of draft-ietf-oauth-jwsreq

[Denis <[e-mail]>]

Hello,

I have only recently subscribed to this mailing list and hence I was not 
present when the WGLC was launched on this document.


I have several concerns and comments about this draft :


*1°. The draft will be unable to move to Draft Standard*

The Intended status of draft-ietf-oauth-jwsreq is Standards Track.

RFC 5657 states: Advancing a protocol to Draft Standard requires 
documentation of the *interoperation *and implementation *o**f the 
protocol.*

The goal of RFC standard Track document is define *interoperable 
protocols, *hence not simply to define the syntax of a request leaving
dozens of possibilities about the treatment of the parameters that may 
be included in the request to the AS.

Generally speaking, the text is silent about the treatment of _every_ 
parameter of the JAR. In particular, what kind of verification and 
processing
SHALL be done by the Authorization Server on "aud", since both "iss" and 
"aud" SHOULD be present (see page 6) in the Authorization Request.

The document currently fails to *clearly indicate which parameters of 
the JAR are used by the Authorization Server to validate the JAR itself
and which parameters are used to build the requested access token*.

For example, is the "aud" parameter supposed to identify the AS or the RS ?

This means that the text should be sufficiently clear so that two 
different implementations can interoperate. This will not be the case if 
the text stays like this.

The goal of Standard Tracks RFCs is not to define frameworks but 
*interoperable protocols.*


In addition to this major concern, I have other concerns:

*2°. Security consideration: the Alice and Bob Collaboration attack (ABC 
attack)*

Since the time RFC 6819 was written, a new kind of attack has been 
mentioned on the WG mailing list:
the ABC attack (*Alice and Bob Collaboration attack*) where Bob accepts 
to collaborate with Alice to get an access token that Alice will then be 
able to use.

There is no external attacker, but only two users who agree to 
collaborate to cheat an application server.
It is a major problem typically when an access token only contains a 
claim like "older then 18".

This kind of attack is not mentioned in this draft, nor if it can be 
countered in the context of RFC 6749 (OAuth 2.0 Authorization Framework).

It would not be reasonable to consider the Alice and Bob Collaboration 
attack as being out of scope of the OAuth 2.0 Authorization Framework;
or ... if it is, this should be clearly stated in the abstract and in 
the security considerations section.


But in the later case, this would be as if a security hole would be left 
out of the scope of the OAuth 2.0 Authorization Framework.


OAuth was designed from a perspective that there is a trust relationship 
between the AS and RS so that things like AT token format were left 
unspecified.
This is a major design error. As long as the AT token format will be 
left unspecified, it will not be possible to counter the ABC attack.


JAR is applicable to all kinds of OAuth authorization request. It is 
considered as just another kind of encoding instead of query parameters.
In case query parameters are being transmitted within the URL, the ABC 
attack remains. So the ABC attack is not specific to this document only,
but to all this series of documents. :-(

Readers might think that the authentication of authorization requests 
solves one left opened security issue but in practice it does not.
Hence, this document can mislead many readers.

IMO, in order to counter the ABC attack it is first necessary to specify 
one or more token syntax and the trust relationships :

-between the token requestor and the AS,

-between the AS ands the RS, and

-between the token requestor and the RS,

The global security picture is governed by:

-the two ways protocol between the token requestor and the AS, as well 
as the format the access token request and the processing of each of its 
parameters by the AS,

-the construction of each of parameter of the access token by the AS,

-the two ways protocol between the token requestor and the RS, as well 
as the format of the access token itself and the validation of each of 
its parameters by the RS,

*3°.**Privacy consideration: Authorization Servers may be able to act as 
Big Brother*

Section 11 (Privacy Considerations) does not contain text to explain 
that an Authorization Server might be able to act as Big Brother
if it is able to know where each access token it issues will be used. 
The use of a audience parameter without any semantics in it should be 
recommended.

Other people have already pointed it out.

Basically, in this context, trust means that a user A trusts a server 
/_B for doing some actions C_/ (and not for any kind of action).
Thus, a user A can trust a server B to provide him with a subset of his 
attributes in an access token but he does not necessarily trust
that same server B to keep private the list of the servers where he will 
use this access token (if B would be in a position to know
the identity of these resource servers).

OpenID Connect is based on OAuth 2.0. OpenID Connect does either take 
into consideration this privacy issue.

*4°. Minors issues (when compared to the others):*

1) The abstract states:

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.

(...)

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.

Since the main purpose is integrity protection and authentication, the 
JAR SHALL be signed and MAY be encrypted.

Replace with:

(...) which allows the request to be JAR to be signed and optionally 
encrypted (...)

2) On page 9 the text states:

The authorization request object MUST be either

(a)  JWS signed; or

(b)  JWE encrypted; or

(c)  JWS signed and JWE encrypted.

This should be replaced by:

The authorization request object MUST be either

(a)  JWS signed;

(b) JWE encrypted (when secret keys are being used); or

(c)  JWS signed and JWE encrypted.

4) On page 14, in section 6.3, the text states:

the Authorization Server then validates the request as specified in 
OAuth 2.0 [RFC6749].


This is rather vague, since no specific section from RFC 6749 is being 
pointed at.RFC 6749 is a framework with many options.
In the context of this draft, it would be beneficial to indicate which 
kind processing of the JAR parameters shall be done by the Authorization 
Server.
This issue clearly relates to the first major issue: interoperability.

Denis