Hi Hannes,
> if a token is created for access to server S1 and S2 then any party
> that gets access to the token can obviously access both servers. This
> should not be super surprising.
>
> So, if you have a deployment where you want to grant access to
> resources at multiple servers and the attack you describe is a concern
> then you need to create multiple tokens.
>
> The content of the token defines what the token can be used for.
>
> The bearer token specification does not define the content of the
> token and therefore it is difficult to say more about it beyond what
> it already says.
>
> If you think it is worth to specify highlight this type of attack then
> the appropriate place to describe it is the threats document.
Why shouldn't this attack be discussed in the security considerations
section of the protocol spec? The security considerations section
already addresses two closely related attacks: "token redirect" and
"token replay". It could use the following language to address
together this attack and the "token redirect" attack:
* If there are multiple resource servers, and different resource
* servers provide client access to different resources, and resource
* servers are not entitled to access resources others than those that
* they provide client access to, then care must be taken to prevent a
* malicious resource server from using an access token presented by a
* client to access, through another resource server, a resource that
* that the malicious server does not provide client access to. This
* can be accomplished in two different ways:
*
* 1. By including in the access token a specification of the set of
* resources that can be accessed by the token. The set must satisfy
* the following condition: every resource server that provides
* client access to a resource in the set must provide client access
* to all the resources in the set. Or,
*
* 2. By including in the access token a specification of the set of
* servers that the token can be presented to. A resource server
* must verify that it is a member of the set when presented with the
* token. The set must satisfy the following condition: all the
* resource servers in the set must provide client access to the same
* set of resources.
Best,
Francisco
> if a token is created for access to server S1 and S2 then any party
> that gets access to the token can obviously access both servers. This
> should not be super surprising.
>
> So, if you have a deployment where you want to grant access to
> resources at multiple servers and the attack you describe is a concern
> then you need to create multiple tokens.
>
> The content of the token defines what the token can be used for.
>
> The bearer token specification does not define the content of the
> token and therefore it is difficult to say more about it beyond what
> it already says.
>
> If you think it is worth to specify highlight this type of attack then
> the appropriate place to describe it is the threats document.
Why shouldn't this attack be discussed in the security considerations
section of the protocol spec? The security considerations section
already addresses two closely related attacks: "token redirect" and
"token replay". It could use the following language to address
together this attack and the "token redirect" attack:
* If there are multiple resource servers, and different resource
* servers provide client access to different resources, and resource
* servers are not entitled to access resources others than those that
* they provide client access to, then care must be taken to prevent a
* malicious resource server from using an access token presented by a
* client to access, through another resource server, a resource that
* that the malicious server does not provide client access to. This
* can be accomplished in two different ways:
*
* 1. By including in the access token a specification of the set of
* resources that can be accessed by the token. The set must satisfy
* the following condition: every resource server that provides
* client access to a resource in the set must provide client access
* to all the resources in the set. Or,
*
* 2. By including in the access token a specification of the set of
* servers that the token can be presented to. A resource server
* must verify that it is a member of the set when presented with the
* token. The set must satisfy the following condition: all the
* resource servers in the set must provide client access to the same
* set of resources.
Best,
Francisco
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@xxxxxxx>
To: Francisco Corella <fcorella@xxxxxxxxxx>; ietf@xxxxxxxx
Sent: Wednesday, February 1, 2012 4:33 AM
Subject: RE: REVISED Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0Authorization Protocol: Bearer Tokens) to Proposed Standard
Hi Francisco,if a token is created for access to server S1 and S2 then any party that gets access to the token can obviously access both servers. This should not be super surprising.So, if you have a deployment where you want to grant access to resources at multiple servers and the attack you describe is a concern then you need to create multiple tokens.The content of the token defines what the token can be used for.The bearer token specification does not define the content of the token and therefore it is difficult to say more about it beyond what it already says.If you think it is worth to specify highlight this type of attack then the appropriate place to describe it is the threats document.Ciao
HannesFrom: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of ext Francisco Corella
Sent: Wednesday, February 01, 2012 6:53 AM
To: ietf@xxxxxxxx
Subject: REVISED Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0Authorization Protocol: Bearer Tokens) to Proposed StandardThe bearer token protocol described in the document referenced in the
subject line is vulnerable to the following attack by a malicious
resource server.
There are two resource servers S1 and S2, S1 hosting a resource R1,
and S2 hosting a resource R2. Servers are not entitled to access
resources that they do not host. S1 is malicious. The client obtains
a broadly scoped access token that allows access to both resources.
The client uses the access token to obtain resource R1 from server S1.
Malicious server S1 then presents the access token received from the
client to server S2 and gains access to resource R2, which it is not
entitled to access.
Including the identity of the intended recipients in the token, as
recommended in Section 4.2, does not help, since the intended
recipients of the broadly scoped token include both R1 and R2.
Francisco
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf