I have several text proposals to accommodate my previous comments.
1. On page 4, delete :
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 :
Authorization Server shall process each parameter of the request. As a
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:
4. In section 5, on page 9 replace:
5. In section 6.3 on page 14, ad at the very end of this section:
be processed. *
6. On page 16, at the end of section 10 add:
could then use. Integrity protection and authentication of the source 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*
access token to be issued shall be used (e.g. using an "aud"
parameter). If this parameter is specified as a URL, the
token it issues will be used. It is thus recommended to use a value
8. On page 1 in the abstract, change :
9. On page 17, section 11.1 change:
Post by Kathleen MoriartyHi,
Hello,
I have only recently subscribed to this mailing list and hence I
was not present when the WGLC was launched on this document.
*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.
*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
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
-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 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):*
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.
(...) 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.
The authorization request object MUST be either
(a) JWS signed; or
(b) JWE encrypted; or
(c) JWS signed and JWE encrypted.
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.)
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
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura
Chairman of the Board, OpenID Foundation