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
________________________________
From: "Tschofenig, Hannes (NSN - FI/Espoo)"
<hannes(_dot_)tschofenig(_at_)nsn(_dot_)com>
To: Francisco Corella <fcorella(_at_)pomcor(_dot_)com>;
ietf(_at_)ietf(_dot_)org
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
Hannes
From:ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of ext Francisco Corella
Sent: Wednesday, February 01, 2012 6:53 AM
To: ietf(_at_)ietf(_dot_)org
Subject: REVISED Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth
2.0Authorization Protocol: Bearer Tokens) to Proposed Standard
The 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf