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

[Denis <[e-mail]>]

Hello  Nat,

I have several text proposals to accommodate my previous comments.

1. On page 4, delete :

**

*The parameters "request" and "request_uri" are introduced as*

*additional authorization request parameters for the OAuth 2.0*

*[RFC6749] flows.The "request" parameter is a JSON Web Token (JWT)*

*[RFC7519] whose JWT Claims Set holds the JSON encoded OAuth 2.0*

*authorization request parameters.This JWT is integrity protected*

*and source authenticated using JWS.*


and move it after the first paragraph of section 4 where this text belongs.

2. At the very end of the Introduction on Page 5, add :

*This document defines the syntax of the JAR but does not define the 
semantics of every parameter of the request nor the way the 
Authorization Server shall process each parameter of the request. As a 
consequence, the document defines a framework for protecting the 
parameters of the token request, but does not specify how to construct 
an access token using the parameters of the request. This document used 
alone does not allow for interoperability. Additional documents are needed.*

3. On page 7, replace:

***To encrypt, JWE [RFC7516] is used.Unless the algorithm used in JWE*

*allows for the source to be authenticated, JWS signature should also*

*be applied.*

by:

*To encrypt, JWE [RFC7516] is used.Unless the algorithm used in JWE*

*uses symmetrical cryptography and thus allows for the source to be 
authenticated, JWS signature should also be applied.*

4. In section 5, on page 9 replace:

*The authorization request object MUST be either*

**

*(a)JWS signed; or *

*(b)JWE encrypted; or *

*(c)JWS signed and JWE encrypted.*

by:

*The authorization request object MUST be either*

**

*(a)JWS signed using an asymmetrical algorithm; or *

*(b)JWE encrypted using a symmetrical algorithm; or *

*(c)JWS signed using an asymmetrical algorithm and JWE encrypted using an 
asymmetrical algorithm.*

5. In section 6.3 on page 14, ad at the very end of this section:

*This document does not define how the parameters of the request should 
be processed. *

6. On page 16, at the end of section 10 add:

*10.5.Alice and Bob collaboration attack*

**

*This is an attack towards the Authorization server where Bob works in 
collaboration with Alice in order to obtain an access token that Alice 
could then use. Integrity protection and authentication of the source of 
the communication of the JAR is not sufficient to counter that type of 
attack. *

7. On page 18, at the end of section 11 add:

*11.3. No disclosure to the AS where the access tokens will be used*

**

*One of the request parameters of the JAR may indicate where the
access token to be issued shall be used (e.g. using an "aud"
parameter). If this parameter is specified as a URL, the
Authorization Server will be able to know exactly where each access
token it issues will be used. It is thus recommended to use a value
that contains no semantics and that changes for every access token
request.*

**

In addition, there are two typos:

8. On page 1 in the abstract, change :

*authentication and confidentiallity property of the Authorization*

into:

*authentication and confidentiality property of the Authorization*

9. On page 17, section 11.1 change:

***Provider.Then, the Auhtorization Server issues HTTP GET request to*

into:

*Provider.Then, the Authorization Server issues HTTP GET request to*

Denis

> Hi,
>
> Comments inline:
>
> 2017年1月4日(水) 1:52 Denis <[e-mail] 
> <mailto:[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.*
>
>
> It is interoperabole, in so much as RFC6749 and RFC7515 is.
>
>
>     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.
>
>
> I disagree. In OAuth, AS and RS has pre-defined relationship - they 
> are tightly bound together and knows how to interpret/resolve the 
> access token.
> Access token format is totally out of scope of OAuth.
>
>
>     JAR is applicable to all kinds of OAuth authorization request. It
>     is considered as just another kind of encoding instead of query
>     parameters.
>
>
> Indeed it is.
>
>     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. :-(
>
>
> ABC attack is out of socpe for OAuth. It is not a new attack. The 
> resource owner handing a bearer token to another party willfully is 
> not a threat in the bearer token model.
>
>     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.
>
>
> OAuth is not a federated authentication protocol.
> OAuth is not even a federated authorization protocol by itself. You 
> need to build a profile upon it to do so.
>
>     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,
>
>
> Sorry, but they are out of scope of this document as ABC attack is out 
> of scope of RFC6749 and RFC6750. They can be dealt with in POP 
> document but not this one.
>
>     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,
>
>
> That depends on the security assumptions. You should challenge RFC6749 
> and not this document. This document merely provides another encoding 
> for the authorization request so that the request can be integrity 
> protected and source authenticated.
>
>     *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
>
>
> There is no notion of "his attributes" in OAuth. You seem to be 
> conflating general OAuth framework with some kind of identity protocols.
>
>     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).
>
>
> Big Brother or "calling home problem" is very well known, but as I 
> have pointed out earlier, in OAuth, the authorization server and 
> resource servers are tightly bound together, so it is not a problem. 
> In this kind of model, if you cannot trust your authorization server, 
> you had better stop using it altogether instead of asking for "better 
> privacy". The consequence of using an untrusted authorization server 
> is much more grave.
>
>     OpenID Connect is based on OAuth 2.0. OpenID Connect does either
>     take into consideration this privacy issue.
>
>
> OpenID Connect is a federated identity protocol built upon OAuth 2.0 
> and that's why it is considering these privacy issues. OAuth does not 
> need to do the same.
>
>     *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 (...)
>
>
> As far as the integrity protection is concerned, JWE covers it.
> For the source authentication, if the JWE uses symmetric key, it is 
> also covered.
> So, JWS is not always required.
>
>     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.
>
>
> That's acceptable. (Thanks for amending your proposal after several 
> private exchanges.)
>
>     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.
>
>
> Indeed it would be beneficial, but is also error prone. The 
> implementer of this document needs to consult RFC6749 closely anyways 
> as all the verificaiton requirements still holds, so as an editor, I 
> would rather keep it as it is. It is not "reader friendly" but cannot 
> go wrong with the approach to just referencing RFC6749.
>
> Nat
>
>
>
>     Denis
>
>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
> -- 
>
> Nat Sakimura
>
> Chairman of the Board, OpenID Foundation
>