Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request))

[Nat Sakimura <[e-mail]>]

My take is that the basic assumption of OAuth 2.0 Framework is that there
is a strong relationship between AS and RS.
I feel that it is quite unrealistic that an RS would trust the access token
issued by an AS that it has no strong relationship with.
Your scenario is more like in the case where a user was authenticated at an
IdP, gets an assertion and go to the AS of the RS domain to get the token
for the RS to access it.

Also, you assume that the response to a tampered request comes back to the
honest client. That may not be the case.
The response to the tampered authorization request may go to the attacker's
client. So, the comparison approach does not work.

Best,

Nat Sakimura

On Tue, Jun 2, 2020 at 5:27 PM Denis <[e-mail]> wrote:

> Hi Benjamin and Aaron,
>
> Note: This is also a reply to Aaron who wrote:
>
> Typically in OAuth it's the authorization server's job to inform users and
> protect access to their resources.
> Obviously in order to do that the AS must know about the details of the
> request.
>
> Can you please clarify the scenario in which you would want the AS to have
> no information about the request that it's authorizing?
>
> The start of the answer comes from the text that was inserted in my first
> email of this thread, which is copied again below:
>
> OAuth initially assumed a static relationship between clients,
> authorization servers and resource servers.
>
> The original model for OAuth was making the assumption that the AS and the
> RS had a strong bilateral relationship.
>
> *A key question is whether such strong relationship will be maintained for
> ever * or
> whether it will be allowed to perform some evolutions of this relationship
> .
>
> In order to respect the privacy of the users, there is the need to
> encompass other scenarios. One of these scenarios is
> that the AS and the RS do not need any longer to have such a strong
> relationship. In terms of trust relationships, a RS
> simply needs to trust the access tokens issued by an AS. The AS does have
> any more a "need to know" of all the RSs
> that are accepting its access tokens. This would be a major simplification
> of the current global architecture.
>
> oauth-security-topics states:
>
>   The privileges associated with an access token SHOULD be restricted to
> the minimum required for the particular
>   application or use case.
>
> This means that the client should be able to select *by itself * the
> claims it would like to be placed into an access token
> with respect to the operations it is willing to perform on a RS.
>
> As long as only the scope request parameter will be usable in an access
> token request to select the claims to be placed
> into an access token, it will not be possible to remove this strong
> relationship.
>
> *1° About d**raft-ietf-oauth-rar-01*
>
> In draft-ietf-oauth-rar-01, it is acknowledged that the parameter "scope"
> that allows OAuth clients to specify the requested scope
> is not sufficient to specify fine-grained authorization requirements.
>
> If the OAuth WG believes that the AS and the RS relationship are not
> necessarily any more *bilateral *but may also be *unilateral*,
> i.e. an AS may be trusted by several RS, but the ASs do not need to know *in
> advance* the RSs, then some evolutions are possible
> as explained below.
>
> A RS must know which attributes from a client are necessary in order to
> accomplish a given operation. After being informed by the RS
> of which attributes are necessary in order to accomplish a given
> operation, a client may request these attributes to any AS that is
> trusted
> by the RS for these types of attributes. If the client also has a trust
> relationship with one or more of these AS, then it may proceed.
>
> For example, a  RS may request three attributes to an AS: a "sub" claim
> which is a value locally unique in the context of the AS
> or that is globally unique, a home address and an indicator stating
> whether the user is over 21 years old. If the client finds these three
> attributes
> as being acceptable for the kind of operation it is willing to perform on
> the RS, then it may request these three attributes to one or more
> appropriate ASs.
>
> In this way, the AS does not know which operation(s) will be performed on
> an AS. Hence, there is no need to define JSON objects
> with "type" fields such as "account_information" and "payment_initiation"
> as given as examples in draft-ietf-oauth-rar-01.
>
> However, JSON objects able to indicate e.g. a pseudonym, a home address, a
> family name, a first name, etc ... should be defined.
>
> To respond to Aaron, the AS does not need to know the details of the
> operations that will be performed by a client on a RS but only needs to
> provide
> the attributes that are being requested by the client. The job of the RSs
> is to inform its clients about which attributes are necessary in order to
> perform
> a given operation and to indicate which ASs are trusted to provide these
> attributes.
>
> This does not mean that all this information shall necessarily be made
> publicly available: it may only be available to authenticated clients
> at the time they are willing to perform a given operation.
>
> ASs do not need to know (and hence to control) which attributes are
> necessary to perform *every* operation on *every* RS.
> Unilateral relationships would make the whole architecture more scalable.
>
>
> *2° About draft-ietf-oauth-jwsreq-22 *
>
> draft-ietf-oauth-jwsreq-22 introduces the ability to send request
> parameters in a JSON Web Token (JWT) which allows the request to be signed
> with JSON Web Signature (JWS) (...) so that the integrity [and] source
> authentication (...) property of the Authorization Request is attained.
>
> It should be realized that a simpler mechanism could be used in some
> cases: integrity "protection" of a message is in fact the "detection" of
> the integrity
> of a message by a receiver. It is possible to *detect *that the *request *has
> been modified by observing the *response*, i.e. the content of the JWT.
> Let us assume
> that no cryptographic mechanism is used in the request, then when a client
> receives a JWT, *if it may verify its content*, it may then know whether
> or not
> the request parameters have been modified while in transit. For example,
> if a client requested a pseudonym claim, a home address claim, a family
> name
> claim and a first name claim to be present in the JWT, unless an error is
> reported, it can verify that these claims are indeed present in the JWT.
>
> This is another reason why a client should be able to inspect the content of the access token.
>
> Denis
>
> On Wed, May 27, 2020 at 07:20:29PM +0200, Denis wrote:
>
> As indicated in the abstract:
>
>     "This document introduces the ability to send request parameters in
>     a JSON Web Token (JWT) instead,
>        which allows the request to be signed with JSON Web Signature (JWS)".
>
> This approach has a major consequence which is not indicated in the
> "Privacy Considerations section:
> the AS will have the knowledge of these request parameters such as
> "please let me make a payment with the amount of 45 Euros"
> or "please give me read access to folder A and write access to file X".
>
> Such an approach has privacy issues which are currently not documented
> in the Privacy Considerations section.
>
> The AS would be in a position to know, not only which resources servers
> are going to be accessed, but also what kind of operations
> are going to be performed by its clients on the resource servers. With
> such an approach, ASs will have a deep knowledge of every
> operation that can be performed by a user on every RS.
>
> As a consequence, the AS would also be in a position to trace the
> actions performed by its users on the resources servers.
>
> Other approaches that are more "privacy friendly" should be considered
> to address the initial problem.
>
> Do you have the start of a list of such other approaches to seed the
> discussion?  There seemms to be some inherent tension between the
> authorization server knowing what it is authorizing and the privacy
> properties you are advocating...
>
> Thanks,
>
> Ben
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en