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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
