Re: [Ace] ACE Framework Review
Ludwig Seitz <ludwig.seitz@ri.se> Mon, 12 November 2018 14:50 UTC
Return-Path: <ludwig.seitz@ri.se>
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 8F484130E3E for <ace@ietfa.amsl.com>; Mon, 12 Nov 2018 06:50:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 cn_hzW4trxNZ for <ace@ietfa.amsl.com>; Mon, 12 Nov 2018 06:50:26 -0800 (PST)
Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA50127333 for <ace@ietf.org>; Mon, 12 Nov 2018 06:50:25 -0800 (PST)
Received: from 1gMDXh-000ovP-Uz by out10b.electric.net with emc1-ok (Exim 4.90_1) (envelope-from <ludwig.seitz@ri.se>) id 1gMDXh-000oxR-Vx for ace@ietf.org; Mon, 12 Nov 2018 06:50:21 -0800
Received: by emcmailer; Mon, 12 Nov 2018 06:50:21 -0800
Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10b.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from <ludwig.seitz@ri.se>) id 1gMDXh-000ovP-Uz for ace@ietf.org; Mon, 12 Nov 2018 06:50:21 -0800
Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Mon, 12 Nov 2018 15:50:21 +0100
To: ace@ietf.org
References: <4519f58c-c6f7-5ac0-003c-7ae4f59bccd4@tzi.de> <31652.1542033061@localhost>
From: Ludwig Seitz <ludwig.seitz@ri.se>
Message-ID: <f258b57e-bb1b-728a-1c4f-e77e2f015008@ri.se>
Date: Mon, 12 Nov 2018 15:50:20 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <31652.1542033061@localhost>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.116.0.226]
X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162)
X-Outbound-IP: 194.218.146.197
X-Env-From: ludwig.seitz@ri.se
X-Proto: esmtps
X-Revdns:
X-HELO: sp-mail-2.sp.se
X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128
X-Authenticated_ID:
X-Virus-Status: Scanned by VirusSMART (c)
X-Virus-Status: Scanned by VirusSMART (s)
X-PolicySMART: 14510320
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/7LVoFlZiTyNIyHrZkB4MiNWMltI>
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 14:50:28 -0000
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. 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] ACE Framework Review Stefanie Gerdes
- Re: [Ace] ACE Framework Review Ludwig Seitz
- Re: [Ace] ACE Framework Review Jim Schaad
- Re: [Ace] ACE Framework Review Stefanie Gerdes
- Re: [Ace] ACE Framework Review Stefanie Gerdes
- Re: [Ace] ACE Framework Review Jim Schaad
- Re: [Ace] ACE Framework Review Michael Richardson
- Re: [Ace] ACE Framework Review Ludwig Seitz
- Re: [Ace] ACE Framework Review Jim Schaad