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

Benjamin Kaduk <> Tue, 26 November 2019 15:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3629B1208E8 for <>; Tue, 26 Nov 2019 07:51:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DlOy38M_cQ3a for <>; Tue, 26 Nov 2019 07:51:20 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD8F51208D1 for <>; Tue, 26 Nov 2019 07:51:20 -0800 (PST)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id xAQFpGOl004529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Nov 2019 10:51:18 -0500
Date: Tue, 26 Nov 2019 07:51:16 -0800
From: Benjamin Kaduk <>
To: Pedram Hosseyni <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <>
Subject: Re: [OAUTH-WG] WGLC review of draft-ietf-oauth-security-topics-13
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Nov 2019 15:51:22 -0000

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 ), 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.)