[Ace] Token (In)Security

Stefanie Gerdes <gerdes@tzi.de> Fri, 14 December 2018 15:15 UTC

Return-Path: <gerdes@tzi.de>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E3A12130DD0 for <ace@ietfa.amsl.com>; Fri, 14 Dec 2018 07:15:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id pI1GH2jV7mdY for <ace@ietfa.amsl.com>; Fri, 14 Dec 2018 07:15:00 -0800 (PST)
Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CCA612F1A5 for <ace@ietf.org>; Fri, 14 Dec 2018 07:15:00 -0800 (PST)
Received: from [] (p508A4EFC.dip0.t-ipconnect.de []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 42966203E2; Fri, 14 Dec 2018 16:14:58 +0100 (CET)
From: Stefanie Gerdes <gerdes@tzi.de>
To: Ludwig Seitz <ludwig.seitz@ri.se>, Jim Schaad <ietf@augustcellars.com>, ace@ietf.org
References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <cbd083d1-cb95-0732-aa8b-7c7de3f480d1@ri.se> <a0cdd836-7fe3-339e-0c48-961503857447@tzi.de> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se>
Message-ID: <b0d3ff24-5842-62ca-3d16-1dd7b4875c66@tzi.de>
Date: Fri, 14 Dec 2018 16:14:43 +0100
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/tS9UW8HhFbdjqU9r2kXgBEMlL4c>
Subject: [Ace] Token (In)Security
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: Fri, 14 Dec 2018 15:15:03 -0000

Hi all,

as I understand the current proposal of the ACE framework, an attacker
can send an access token to the RS that only contains a scope and is not
signed or otherwise protected. Section (titled verifying an
access token) does not state that RS must check the authenticity of the
token, therefore RS can accept it. Since the token does not contain an
exp field, it is infinitely valid. The attacker thus gains infinite
unconditional access. Is this really what we want from a security framework?

I would expect section to provide information if and when RS
must check that the token stems from an authorized AS to prevent this

Viele Grüße