Re: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00

[George Fletcher <[e-mail]>]

Hi Denis,

If I understand your arguments correctly, you'd like a way to ask the AS 
to add an RS supplied nonce to the access_token. This is done in OpenID 
Connect with the id_token but nothing like this exists within OAuth2. 
Largely because the entity asking for the token (client) is different 
from the entity that will consume the token (resource server).

I see this oauth-resource-indicators spec trying to address a different 
problem. Namely, allowing the AS to not issue a token if the requested 
"resource" is suspect or does not in some way meet the AS policy.

It's unclear from the spec, how the RS should do audience restriction 
though I suspect that the RS will introspect the token and then compare 
the returned audience(s) in some way with itself. [Brian/John/Hannes I'd 
recommending adding a section on audience restriction processing in the RS.]

The model you suggest in this thread is much closer to UMA (User Managed 
Access) [1] where the client first tries to access a resource and then 
is told they need to obtain some additional claims before access will be 
granted.

Thanks,
George

[1] https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html

On 11/22/16 12:22 PM, Denis wrote:
> Hi John,
>
>> The privacy problem is a touch hypothetical the way that OAuth 
>> currently works. There is not standard access token, a AS producing 
>> access tokens that could be used across a number of RS in different 
>> security domains would be a security disaster, unless they are proof 
>> of possession tokens. If all of the RS trust each other by being in 
>> the same security domain they can all collude and the AS can know 
>> where the tokens are used without the resource being indicated to the 
>> AS directly. If the RS are in different security domains then 
>> potentially some privacy is disclosed.
>
> I am dealing with scenarios where RS may be in the same security 
> domain or in different security domains.
> More precisely, none of the RS will necessarily be in the same 
> security domain as the AS.
>
>> The only way to deal with that is the alternative of POP AT that the 
>> WG is documenting separately.
>
> I disagree.  There are some cases, where an access token should be 
> targeted to a RS and the target RS should be indicated
> in the access token.
>
> draft-campbell-oauth-resource-indicators should say that data that can 
> be recognized by the RS may be incorporated
> into the access token.
>
> This has nothing to do with POP which is another issue.
>
> draft-ietf-oauth-pop-architecture-08 does not, unfortunately, provides 
> a solution since a major threat has been omitted:
>
>     Collusion between users
>
>           Users can collude and one user may attempt to use an access
>     token legitimately obtained from an AS
>           and then transmit it to another user so that it can be used
>     on the same RS.
>
>
> This document states on page (clause 3.3):
>
>   * the important assumption in this use case is that a resource
>     server does not have TLS support
>     and the security solution should work in such a scenario.
>
> This means that binding the access token to HTTP (see 
> draft-ietf-tokbind-https-06) is not a valid solution
> since it is unable to address the Alice and Bob Collusion (ABC) attack.
>
>> I think it is fine to say that if the AS are in separate security 
>> domains and privacy is a issue, then use PoP rather than resource to 
>> protect the AT from replay.
>
> I do not think this is what should be said.
>
> If an access token cannot be replayed on another RS, then it does not 
> necessarily need to be targeted to a RS (... but it will not heart).
>
> If privacy is a concern _and_ if there is a need to include a target 
> RS in an access token because the access token might be forwarded
> to another RS, then a pseudo-random number shall be used to identify 
> the RS rather than an absolute URI.
>
>> The reason for using a URI for the resource is that it is something the client knows.
>> If we use a abstract name the client might be tricked into giving a token to the wrong resource.
>
> Please take another look at the example I have provided below. The 
> problem you mention does not exist.
>
> Denis
>> John B.
>>
>>
>>> On Nov 22, 2016, at 9:34 AM, Denis<[e-mail]>  wrote:
>>>
>>> Hi Hannes,
>>>
>>> I do not deny the fact that it is necessary to provide some information to the authorization server
>>> to indicate the resource server where the access token shall only be used.
>>>
>>> Let us illustrate the concept with a simple scenario.
>>>
>>> A user first connects to a resource server and announces some actions he would like to perform.
>>> In its response, the resource server indicates "demonstrate that you are older than 18 and incorporate
>>> in your access token the random value (some kind of challenge) I have just generated for you only".
>>>
>>> The client forwards that random value to the authorization server which is blindly copied and pasted
>>> into the access token. If the resource server does not recognize this value, the access will be denied.
>>>
>>> In this way, the authorization server has no way to know where the access token will be used.
>>>
>>> On the contrary, an absolute URI would allow the authorization server to know which resources the user is accessing.
>>> The use of an absolute URI should be deprecated because of this privacy concern.
>>>
>>> Denis
>>>
>>>> Hi Denis
>>>>
>>>> draft-campbell-oauth-resource-indicators gives the authorization server
>>>> information about the resource server the access token will be used with.
>>>>
>>>> Without this information there is the risk that the access token is
>>>> replayed at other resource servers and with the proof-of-possession /
>>>> token binding work there obviously has to be an indication of where the
>>>> token is used.
>>>>
>>>> The reason for using an absolute URI is that the resource server needs
>>>> to take the information from the incoming access token and to compare it
>>>> with its own information in order to determine whether the token is
>>>> indeed intended for itself.
>>>>
>>>> If the authorization server does not know to whom it gives rights to
>>>> access protected information then this is also a privacy risk (namely
>>>> unauthorized access).
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>> On 11/15/2016 12:50 PM, Denis wrote:
>>>>> Hello everybody,
>>>>>
>>>>> Since I am not present at the meeting, I read the minutes from the first
>>>>> session, in particular:
>>>>>
>>>>>      Brian Campbell and John did a draft allowing the client to tell the
>>>>>      AS where it plans to use the token
>>>>>      draft-campbell-oauth-resource-indicators
>>>>>
>>>>>                    This enables the AS to audience restrict the access
>>>>>      token to the resource
>>>>>                    Phil Hunt:  We should keep the audience restriction
>>>>>      idea on the table
>>>>>
>>>>> The introduction contains the following sentences:
>>>>>
>>>>>      Several years of deployment and implementation experience with OAuth
>>>>>      2.0 [RFC6749] has uncovered a need, in some circumstances,
>>>>>      for the client to explicitly signal to the authorization sever where
>>>>>      it intends to use the access token it is requesting.
>>>>>
>>>>>      A means for the client to signal to the authorization sever where it
>>>>>      intends to use the access token it's requesting is important and
>>>>>      useful.
>>>>>
>>>>> The document contains a "security considerations" section but
>>>>> unfortunately no "privacy considerations" section.
>>>>>
>>>>> Clause 2 states:
>>>>>
>>>>>      The client may indicate the resource server(s) for which it is
>>>>>      requesting an access token by including the
>>>>>      following parameter in the request.
>>>>>
>>>>>      resource
>>>>>
>>>>>      OPTIONAL. The value of the resource parameter indicates a resource
>>>>>      server where the requested
>>>>>      access token will be used.*It MUST be an absolute URI*, as specified
>>>>>      by Section 4.3 of[RFC3986],
>>>>>
>>>>> With such an approach, the authorization server would have the ability
>>>>> to *act as a Big Brother *and hence to know exactly
>>>>> where the user will be performing activities.
>>>>>
>>>>> However, some users might be concerned with their privacy, and would
>>>>> like to restrict the use of the access token
>>>>> to some resource servers without the authorization server knowing which
>>>>> are these resource servers.
>>>>>
>>>>> The key point is whether the information is primarily intended to the
>>>>> authorization server or to the resource server(s).
>>>>>
>>>>> I believe that it is primarily intended to the resource server(s) rather
>>>>> than to the authorization server in order to be included
>>>>> in an access token. Obviously, the information needs to transit through
>>>>> the authorization sever, that should simply be copied
>>>>> and pasted into the access token. Its semantics, if any, does not
>>>>> necessarily needs to be interpreted by the authorization sever.
>>>>>
>>>>> I believe that a "privacy considerations" section should be added.
>>>>>
>>>>> The sentence "*It MUST be an absolute URI*, as specified by Section 4.3
>>>>> of [RFC3986]" should be removed or
>>>>>   replaced by : "*It MAY be an absolute URI*, as specified by Section 4.3
>>>>> of [RFC3986]".
>>>>>
>>>>> Obviously, other changes would be necessary too.
>>>>>
>>>>> Denis
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth