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

[Nat Sakimura <[e-mail]>]

Hi,

Comments inline:

2017年1月4日(水) 1:52 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.*
>

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]
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation