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

Pedram Hosseyni <pedram.hosseyni@sec.uni-stuttgart.de> Thu, 21 November 2019 13:51 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 []) by ietfa.amsl.com (Postfix) with ESMTP id E2D34120811 for <oauth@ietfa.amsl.com>; Thu, 21 Nov 2019 05:51:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id woXv4oth4JlE for <oauth@ietfa.amsl.com>; Thu, 21 Nov 2019 05:50:59 -0800 (PST)
Received: from mxex1.tik.uni-stuttgart.de (mxex1.tik.uni-stuttgart.de []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F85120A8E for <oauth@ietf.org>; Thu, 21 Nov 2019 05:50:56 -0800 (PST)
Received: from localhost (localhost []) by mxex1.tik.uni-stuttgart.de (Postfix) with ESMTP id 965E6600FE for <oauth@ietf.org>; Thu, 21 Nov 2019 14:50:54 +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:mime-version:user-agent:date:date:message-id :subject:subject:from:from:received:received; s=dkim; i= @sec.uni-stuttgart.de; t=1574344252; x=1576083053; bh=WJMRYvibWy iFFQ9i5ifbRYXkXh0gNFEJ4AaRebHQmLM=; b=WV2IzOprMSCw0Ber4DF4Y/Mx64 xh1+5OXndofYAPjPsOENm9IOpSdJCxsK4q5GYHT83W0PsM2n1/+n3zxDBLLKvzfu L2oftT1SD+nZgpELcCeT/H9c/flmaGS9l1G3nJNtXUHDyR5yMkTYBSEUoRMxBg/y VGow540yDnGmLKYi+bH5jY0W33sz3O1cXkE5622850VSG+uQVJDZK1E3+J2xy2Ix n2lS9FkdycQWNAfwDcLc0vV9zpN0klfxpSYPwbpGE2wQ6zYuYxwhOjMrmhHuvhNf q4c3BtAfQi9tC5Ut+xsf7ZvV3YfRhbLzmExkqbsCuv2pYm0tPN1aYPTYu9Tw==
X-Virus-Scanned: USTUTT mailrelay AV services at mxex1.tik.uni-stuttgart.de
Received: from mxex1.tik.uni-stuttgart.de ([]) by localhost (mxex1.tik.uni-stuttgart.de []) (amavisd-new, port 10031) with ESMTP id MQiO0WGNqoho for <oauth@ietf.org>; Thu, 21 Nov 2019 14:50:52 +0100 (CET)
Received: from [IPv6:2001:7c0:2049:1d4:1ce0:2fef:f426:f8cd] (unknown [IPv6:2001:7c0:2049:1d4:1ce0:2fef:f426:f8cd]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mxex1.tik.uni-stuttgart.de (Postfix) with ESMTPSA for <oauth@ietf.org>; Thu, 21 Nov 2019 14:50:52 +0100 (CET)
From: Pedram Hosseyni <pedram.hosseyni@sec.uni-stuttgart.de>
To: oauth@ietf.org
Message-ID: <fc5c22c1-7459-0337-4a27-5f666bd271ad@sec.uni-stuttgart.de>
Date: Thu, 21 Nov 2019 14:50:52 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
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/_nRwpVEkuDXYEdWBGJY1nKR_gIg>
Subject: [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: Thu, 21 Nov 2019 13:51:02 -0000

Dear all,

I have a few comments about the leakage of access tokens and the 
underlying assumptions:

Section 2, A5 should be clarified:

"a resource server can be compromised by an attacker": Is the assumption 
that the attacker cannot get access to the resources stored at the 
compromised RS (or only parts of it)? Otherwise, the attacker does not 
need to get an AT anymore. A more differentiated view on RS 
compromisation is already given in Section 4.8.2, but this is not 
reflected in A5.

Also, A5 states that "an access token may be sent to an 
attacker-controlled resource server due to a misconfiguration," which 
does not require the compromisation of an honest RS.

Perhaps one could be more generic here and just say that the AT leaks to 
the attacker. However, a misconfigured RS endpoint not only gets the 
request to this endpoint (containing an AT) but can also respond and 
provide the RO with wrong resources. At the same time, if, say, the RO 
thinks that she is connected to her cloud storage, the attacker would 
get access to all uploaded data.

Is this really what A5 should express, or is the primary focus on the 
leakage of the AT?

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.

Typo: Section 3.5: MTLS -> mTLS

Best regards
Pedram Hosseyni

Pedram Hosseyni, M.Sc.
Room V38 2.438
Institute of Information Security - SEC
Universität Stuttgart
Universitätsstraße 38
D-70569 Stuttgart
Phone: +49 711 685 88454