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

Pedram Hosseyni <pedram.hosseyni@sec.uni-stuttgart.de> Tue, 26 November 2019 17:33 UTC

Return-Path: <pedram.hosseyni@sec.uni-stuttgart.de>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFC1121122 for <oauth@ietfa.amsl.com>; Tue, 26 Nov 2019 09:33:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni-stuttgart.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWxAS1IweCzO for <oauth@ietfa.amsl.com>; Tue, 26 Nov 2019 09:33:11 -0800 (PST)
Received: from mxex2.tik.uni-stuttgart.de (mxex2.tik.uni-stuttgart.de [IPv6:2001:7c0:2041:24::a:2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A659E121123 for <oauth@ietf.org>; Tue, 26 Nov 2019 09:33:10 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mxex2.tik.uni-stuttgart.de (Postfix) with ESMTP id 50D6B60341; Tue, 26 Nov 2019 18:33:08 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=uni-stuttgart.de; h=content-language:content-transfer-encoding:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:subject:subject:received :received; s=dkim; i=@sec.uni-stuttgart.de; t=1574789586; x= 1576528387; bh=zGjhYqjJWd5ntN2WhZNBkI00APA+/TmZKl/5GrG+LWo=; b=q x4Pi8pVQhlb4jWsIJMJtSAi9+6KVandqn1mle7ePDgvWoIYIbGdB+zTgqIOuMIf8 2F2Ps+6F/Mi4Ap4VyCGivOuHs4i5/s3vM3qJ78u2yscp6qRKGVsp1kMmx+rs4m/I M4GGv6AGuWDS+GCLWWTjAjZuIoMcRcv+8ROHomPqnaR1mqQ1fqmkU/7jRJTIlmSf LNfnW08Pf7NQrMddioVcgdBq/lnBTLhWdUUf6AkFaYq/7a5mr+flCHXRdrrGdodX TDTtADBhfh85qhvPVKOz0qAlGPmGYanZvYTidgiULXc6UKVNzeXiDIDWUsxvJCA+ 0bcwuzybO/SC4qJT5lf7g==
X-Virus-Scanned: USTUTT mailrelay AV services at mxex2.tik.uni-stuttgart.de
Received: from mxex2.tik.uni-stuttgart.de ([127.0.0.1]) by localhost (mxex2.tik.uni-stuttgart.de [127.0.0.1]) (amavisd-new, port 10031) with ESMTP id b46dbhrYEw1J; Tue, 26 Nov 2019 18:33:06 +0100 (CET)
Received: from [IPv6:2001:7c0:2015:182::1:9c] (unknown [IPv6:2001:7c0:2015:182::1:9c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mxex2.tik.uni-stuttgart.de (Postfix) with ESMTPSA; Tue, 26 Nov 2019 18:33:05 +0100 (CET)
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: oauth@ietf.org
References: <fc5c22c1-7459-0337-4a27-5f666bd271ad@sec.uni-stuttgart.de> <20191126155116.GW32847@mit.edu>
From: Pedram Hosseyni <pedram.hosseyni@sec.uni-stuttgart.de>
Message-ID: <2ad7e9d7-ac6f-aef2-afa8-36ce4b30fac2@sec.uni-stuttgart.de>
Date: Tue, 26 Nov 2019 18:33:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <20191126155116.GW32847@mit.edu>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/xyZ5ZJDnvqX4W5UqI7SGRkgFPJ8>
Subject: Re: [OAUTH-WG] WGLC review of draft-ietf-oauth-security-topics-13
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Nov 2019 17:33:14 -0000

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: +49 711 685 88454
https://sec.uni-stuttgart.de