Re: [Ace] ACE Framework Review

Jim Schaad <ietf@augustcellars.com> Mon, 12 November 2018 15:07 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B954130E0A for <ace@ietfa.amsl.com>; Mon, 12 Nov 2018 07:07:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 sD93lSvMHwXq for <ace@ietfa.amsl.com>; Mon, 12 Nov 2018 07:07:50 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5A412D4E8 for <ace@ietf.org>; Mon, 12 Nov 2018 07:07:50 -0800 (PST)
Received: from Jude (101.51.59.25) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 12 Nov 2018 07:02:33 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Ludwig Seitz' <ludwig.seitz@ri.se>, <ace@ietf.org>
References: <4519f58c-c6f7-5ac0-003c-7ae4f59bccd4@tzi.de> <31652.1542033061@localhost> <f258b57e-bb1b-728a-1c4f-e77e2f015008@ri.se>
In-Reply-To: <f258b57e-bb1b-728a-1c4f-e77e2f015008@ri.se>
Date: Mon, 12 Nov 2018 22:07:18 +0700
Message-ID: <037701d47a99$6ae451c0$40acf540$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJDl5Bm99e9zGnxaPJuM5ZpOzU3eQGk5zLLAf9/nLKkUN/0UA==
Content-Language: en-us
X-Originating-IP: [101.51.59.25]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/car-nwe2gonDC7hRmHmXEWRpgAA>
Subject: Re: [Ace] ACE Framework Review
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Nov 2018 15:07:52 -0000


> -----Original Message-----
> From: Ace <ace-bounces@ietf.org>; On Behalf Of Ludwig Seitz
> Sent: Monday, November 12, 2018 9:50 PM
> To: ace@ietf.org
> Subject: Re: [Ace] ACE Framework Review
> 
> On 12/11/2018 15:31, Michael Richardson wrote:
> 
> >
> >      > Management of the authz-info resource: * The authz-info resource
is
> >      > vulnerable to DoS attacks: clients may (with or without
intention) send
> >      > large numbers of access tokens to RS. A constrained RS may soon
run
> out
> >      > of memory/storage space if it needs to store large numbers of
> >
> > This seems like a really serious issue, and it seems that we need an
> > additional RTT to really fix it.
> >
> 
> Note Steffi's words were: "store large numbers of tokens".
> 
> In order to have the RS store a large number of tokens, an attacker would
> need to have a large number of valid tokens for starters (since invalid
tokens
> are not stored but discarded).
> 
> Furthermore, since the RS checks whether the audience of a token applies,
> and can safely discard tokens that do not have a matching audience the
> attacker would need to have a large number of tokens that all match an
> audience that this RS identifies with.
> 
> Finally we just learned at IETF 103 that OAuth typically does not use
multiple,
> simultaneous access tokens for the same pair of client-RS.
> Thus if the token has a subject (sub claim) or some other binding to the
> client, the RS can safely discard all older tokens bound to the same
client.

Putting the last three "checks" into the text someplace about DoS attacks as
well as pointing to the echo option would be a good start to helping people
make sure that they think about this problem and that they look at it
solidly.

I would also suggest that sending the same token over and over should not be
a good attack as the RS can look at the AS and the token ID and not process
if it is the same.

Jim

> 
> Therefore I propose that an attack that induces the RS to store a large
> number of tokens is quite hard to pull of.
> 
> Even so, lets still assume it would be possible, there is this part in the
spec:
> 
> ==========================
> 5.8.1.  The Authorization Information Endpoint
> 
> ....
>     The RS MUST be prepared to store at least one access token for future
>     use.
> ....
> ==========================
> 
> 
> This means that the RS can limit the total number of tokens it stores for
> future use based on its memory and storage space, as long as it stores at
> least one (in total, not per client).
> 
> Thus I'm curious what additional protections you would suggest are
feasible
> and necessary for the authz-info endpoint?
> 
> /Ludwig
> 
> 
> 
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51
> 
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace