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

Torsten Lodderstedt <torsten@lodderstedt.net> Thu, 28 November 2019 10:40 UTC

Return-Path: <torsten@lodderstedt.net>
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 2304E120133 for <oauth@ietfa.amsl.com>; Thu, 28 Nov 2019 02:40:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=lodderstedt.net
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 3YlCyvP1UXXA for <oauth@ietfa.amsl.com>; Thu, 28 Nov 2019 02:40:44 -0800 (PST)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C38120132 for <oauth@ietf.org>; Thu, 28 Nov 2019 02:40:44 -0800 (PST)
Received: by mail-wm1-x331.google.com with SMTP id n5so11122077wmc.0 for <oauth@ietf.org>; Thu, 28 Nov 2019 02:40:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mxUs7I27EurhXljqMSs3vqpkwpsnKAW54zCmzThEZGA=; b=oGlQW+wfr+9eMdPWdvIYSFz1OWU9DkGRSkUftvTDjzWrbWIzcs/m5Oqa5EptUen6sY 71wmGigeQPyt5lyQkFeGRnlbOD4TvIHcprV0js2eG4jKBcEXC4C73QzR8spuu6f3Luto eTkzTgrHkuG3kwMMd3LwN6XmOh0RHVQiMr9XREZYVwM5j6+8lOBlZmaPz8jWfa7ruPBK ND8TJ3YiGTxhHXQVsFoJ0mluIAheX+oZqMzwLIp18mNz7sKv+7+yBuEW2qFybBccsVxV mbHeE7Za8Jm+vHGfDGJQ5ObRUJzxFPB73UwIpHgCfwPzdJLvm0d8RhECm3Qy65+rVj+p zCpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mxUs7I27EurhXljqMSs3vqpkwpsnKAW54zCmzThEZGA=; b=uliwoB62PecARm/rPBmkZR+Od4iYLsN1jmngyEUzoY0Z5dOC9vJTf5NxaApQ1G+IDD NEjldgOaKh/O2Ao4Jas9CDQujeTfbbkgLBqaaZ3lppB8KvCDZ7/m8FjQhLDTnrTT+WZn egoRvJHJCFefGVQ85Y6zyFhHWn5N4JXggDHmYmueYGbnwYLWOr9WKEV3jagy3CvafTOw K9w0Qf9xMCjycjTVhkz2ZplcdygPkAzpQySGxu1mh0rnwEEU0WORyFZ8nk+0nkt07q5R JgF3oZpo0XleNT/XXOO9XPhoIUXjzVyALNqugyK4sIsU2XvFaoBaZumq7F9RmT0QduqJ oGig==
X-Gm-Message-State: APjAAAUPGNiuPerR1WVB4m9Xf/lhi2qbhWB9FWZxpPa6+vtT0N5fy78Q EtiTkicW/9bYiiMTkB+ti3cOgQ==
X-Google-Smtp-Source: APXvYqwqt9pyijHo459wdmg3PRMw1z7lduDe7Dz4H1mqwAbLmui1oELbNXFFMnPkMbrAiVtC3LvG8Q==
X-Received: by 2002:a05:600c:210b:: with SMTP id u11mr8982151wml.170.1574937642172; Thu, 28 Nov 2019 02:40:42 -0800 (PST)
Received: from [192.168.71.123] (p549EE7F4.dip0.t-ipconnect.de. [84.158.231.244]) by smtp.gmail.com with ESMTPSA id l10sm24863511wrg.90.2019.11.28.02.40.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Nov 2019 02:40:41 -0800 (PST)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <33429332-8648-4D94-AD79-2824ECC39A8E@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_0A971E5D-9D36-4FC5-951E-94BF0EFA7462"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Thu, 28 Nov 2019 11:40:27 +0100
In-Reply-To: <13df62f4-e53f-6a35-443d-2a88db741e55@sec.uni-stuttgart.de>
Cc: "Peck, Michael A" <mpeck@mitre.org>, Benjamin Kaduk <kaduk@mit.edu>, "oauth@ietf.org" <oauth@ietf.org>
To: Pedram Hosseyni <pedram.hosseyni@sec.uni-stuttgart.de>
References: <fc5c22c1-7459-0337-4a27-5f666bd271ad@sec.uni-stuttgart.de> <20191126155116.GW32847@mit.edu> <2ad7e9d7-ac6f-aef2-afa8-36ce4b30fac2@sec.uni-stuttgart.de> <31267_1574793090_5DDD6F81_31267_173_1_20191126183109.GZ32847@mit.edu> <A6A5B0CC-FC91-48D9-A7EC-79163EF08F55@mitre.org> <13df62f4-e53f-6a35-443d-2a88db741e55@sec.uni-stuttgart.de>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/x1nvjqGUHw66VjSKWGvm45dalNE>
Subject: Re: [OAUTH-WG] [EXT] Re: 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, 28 Nov 2019 10:40:47 -0000

Hi,

> On 27. Nov 2019, at 15:04, Pedram Hosseyni <pedram.hosseyni@sec.uni-stuttgart.de> wrote:
> 
> Hi Mike,
> 
> > Wouldn't most RSs only trust access tokens from a single AS anyways?
> 
> At the last OSW, there was broad agreement that this is typically the case. Otherwise, the mitigation that we suggested in the paper would not prevent the attack.
> 
> > Would it be reasonable for the document to recommend that clients designate a specific AS for each RS that the client accesses (and not allow the user to select a different AS)? Would that help prevent the attack?
> 
> In principle, this should prevent the attack. However, this would require the client to identify the correct AS for each RS, which might not always be possible (e.g., in more dynamic settings) and more complicated than just delegating this decision to the RS.
> 
> Any opinions (also from other OAuth WG members) on this?

I think one can observe all possible combinations of AS and RS in the wild. 

In the traditional OAuth setup, there is a 1:1 relationship between RS and AS. 

There are also deployments where a single RS works with multiple ASs, e.g. because those ASs represent different portions of the overall user base. In this case, the RS determines the base set of ASs and the user selects the AS to be used from that base set. 

As far as I understand, in UMA any AS can provide access tokens to any RS as long as the relationship had been set up by the user beforehand.   

best,
Torsten. 

> 
> Best regards,
> Pedram
> 
> 
> On 26.11.19 21:08, Peck, Michael A wrote:
>> Hi Pedram,
>> 
>> I understand why a client would need to allow use of multiple authorization servers if the client needs to access various resource servers each of which may trust different ASs (e.g. the client supports accessing resources at multiple cloud storage services).
>> 
>> However, how common is the case that a client would need to allow selecting from multiple authorization servers for accessing a particular resource server?
>> 
>> Would it be reasonable for the document to recommend that clients designate a specific AS for each RS that the client accesses (and not allow the user to select a different AS)? Would that help prevent the attack? Wouldn't most RSs only trust access tokens from a single AS anyways?
>> 
>> Thanks,
>> Mike
>> 
>> On 11/26/19, 1:32 PM, "OAuth on behalf of Benjamin Kaduk" <oauth-bounces@ietf.org on behalf of kaduk@mit.edu> wrote:
>> 
>>     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: +49 711 685 88454
>>     > https://sec.uni-stuttgart.de
>>     >
>>          _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org
>>     https://www.ietf.org/mailman/listinfo/oauth
>>     
> -- 
> 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
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth