Re: [Ace] ACE Framework Review

Michael Richardson <> Mon, 12 November 2018 14:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06F03130E3E for <>; Mon, 12 Nov 2018 06:31:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jJHvCqbd6Guq for <>; Mon, 12 Nov 2018 06:31:02 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C6208130E30 for <>; Mon, 12 Nov 2018 06:31:02 -0800 (PST)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 839D42008C; Mon, 12 Nov 2018 09:30:57 -0500 (EST)
Received: by (Postfix, from userid 179) id 705A0CA1; Mon, 12 Nov 2018 09:31:01 -0500 (EST)
Received: from (localhost []) by (Postfix) with ESMTP id 6D7579DB; Mon, 12 Nov 2018 09:31:01 -0500 (EST)
From: Michael Richardson <>
To: Stefanie Gerdes <>
cc: "Ace\" <>
In-Reply-To: <>
References: <>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Mon, 12 Nov 2018 09:31:01 -0500
Message-ID: <31652.1542033061@localhost>
Archived-At: <>
Subject: Re: [Ace] ACE Framework Review
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Nov 2018 14:31:05 -0000

Thanks for this amazing analysis.
It languished in my inbox because it was not bikeshed material, and I had to
think about things :-)

Stefanie Gerdes <> wrote:
    > The minimal security requirements for the communication between two
    > communication partners should be listed (C-AS, RS-AS, C-RS,
    > respectively). Which pieces of information do they require prior to the
    > communication? How must the communication be secured? Which keying
    > material do they need to use? The framework should point out that all
    > claims that influence the security must stem from claimants that were
    > approved by the respective human being that is responsible for the
    > device, i.e., the requesting party for the client and the resource
    > owner for the AS and RS. Otherwise the solution is not secure.

It seems that the answers should start with 
   "which keying material do they need to use"

and then move upwards.

    > 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.

]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]        |   ruby on rails    [