RE: REVISED Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0Authorization Protocol: Bearer Tokens) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]