Re: [OAUTH-WG] WGLC review of draft-ietf-oauth-security-topics-13

[Benjamin Kaduk <[e-mail]>]

Hi Pedram,

Thanks for confirming that the scenario is as I was trying to understand
it.  I don't think it's universal that all clients will give transitive
access from the user to the accessed resource, though it's certainly
common; the lack of exposition on that point is what I had been stumbling
on.

-Ben

On Tue, Nov 26, 2019 at 06:33:04PM +0100, Pedram Hosseyni wrote:
> Hi Ben,
> 
> The attacker uses the (honest) client shown in Figure 4 as a regular 
> user. For example, the client might provide access to a cloud storage 
> via its website, i.e., by using the clients' website, a user can access 
> her files stored at the resource server.
> 
> I'll try to clarify the attack with a simplified example.
> 
> Let's assume that the client supports two authorization servers 
> AS_honest and AS_attacker. Intuitively, if the attacker phishes an 
> access token created by AS_honest for an honest user (Alice), one would 
> expect that sender-constraining the access token (e.g., via mTLS) 
> prevents the attacker from using this access token.
> 
> The overall goal of the attacker is to use the sender-constrained access 
> token (which he cannot use directly at the resource server) to access 
> Alices cloud storage.
> 
> The attack works as follows:
> 
> First, the attacker visits the website of the client. Usually, the 
> attacker would now choose an AS, and after successful authentication, 
> access his files stored in the cloud. When selecting the AS, the 
> attacker chooses AS_attacker. In Step 5 of Figure 4, AS_attacker now 
> provides the phished access token. As this token is bound to this 
> client, the client can use it at the resource server for getting access 
> to the cloud storage of Alice. As the attacker is using the client 
> (through the clients' website), he now gets access to these files 
> (stored at the RS).
> 
> Please let me know if you have any other questions.
> 
> Best regards,
> Pedram
> 
> 
> On 26.11.19 16:51, Benjamin Kaduk wrote:
> > Hi Pedram,
> >
> > On Thu, Nov 21, 2019 at 02:50:52PM +0100, Pedram Hosseyni wrote:
> >> Also, for this or the next version of this document, the Cuckoo's Token
> >> attack (see Section IV-A of http://arxiv.org/abs/1901.11520/ ), should
> >> be addressed. We also discussed this issue extensively at the last OSW
> >> in Stuttgart.
> > I took a look at the paper, and I'm not sure I'm properly understanding the
> > "Cuckoo's Token" attack.  Looking at Figure 4 of the paper to have
> > something concrete to refer to, I assume that the client, as a white box,
> > is presumed to be honest.  Since the access token is bound to the client, I
> > assume that the attacker has to return the phished access token to the same
> > client that originally (honestly) got it, as otherwise the token will not
> > be usable at the RS.  The paper concludes that in step 6, the client gets
> > access to the honest resource owner's resources, and furthermore that the
> > attacker has access to those resources through the client.  It's that last
> > part that I'm not sure I understand -- if the client is honest, why would
> > it return resource information to the attacker?  The best I can come up
> > with is that there's some sense of a "session" between the user and client,
> > such that the client links its resource accesses with the "session" on
> > behalf of which the access occurs, and is willing to return such
> > information back to the user only on the "linked session".  (The
> > countermeasure makes sense and is a good practice, of course.)
> >
> > Thanks,
> >
> > Ben
> 
> -- 
> Pedram Hosseyni, M.Sc.
> Room V38 2.438
> Institute of Information Security - SEC
> Universität Stuttgart
> Universitätsstraße 38
> D-70569 Stuttgart
> Germany
> Phone: [phone]
> https://sec.uni-stuttgart.de
>