[Ace] Reviewing ace-aif

"Christian M. Amsüss" <christian@amsuess.com> Thu, 11 March 2021 11:28 UTC

Return-Path: <christian@amsuess.com>
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 134363A19C1; Thu, 11 Mar 2021 03:28:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id eovSee-5Kzuo; Thu, 11 Mar 2021 03:28:42 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A7A23A19A9; Thu, 11 Mar 2021 03:28:41 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net []) by prometheus.amsuess.com (Postfix) with ESMTPS id 932F4408A0; Thu, 11 Mar 2021 12:28:39 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com []) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 394A6D3; Thu, 11 Mar 2021 12:28:38 +0100 (CET)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:8628:563f:7c92:13bc]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 05EF517C; Thu, 11 Mar 2021 12:28:38 +0100 (CET)
Received: (nullmailer pid 3678100 invoked by uid 1000); Thu, 11 Mar 2021 11:28:37 -0000
Date: Thu, 11 Mar 2021 12:28:37 +0100
From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= <christian@amsuess.com>
To: draft-ietf-ace-aif@ietf.org, ace@ietf.org
Message-ID: <YEn+5bX7AhOmtX/h@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JHIztqhhj/So1Svb"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/F6H-JFLDsQu4M8w85PHSH7DlzNA>
Subject: [Ace] Reviewing ace-aif
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: Thu, 11 Mar 2021 11:28:48 -0000

Hello Carsten, hello AIF,

as promised I've had a look at AIF:

"need to ascertain that other devices they place requests on are the ones they intended"

This is an important statement which I don't see taken up outside the
introduction. Especially considering how the requester not only needs to
be sure it places the requests on the intended target, but also how to
get from the intention to the operation.

It's hard to place concretely, given that most of the remaining document
talks about the REST and it *is* trivial there (once there is clarity of
the target).

Suggested addition for seccons bullets:

* ensure that both subject and target map Toid/Tperm pairs to the same

(This links back to the CoRE RD discussion about a client that wants to
perform a single Toid/Tperm action, but got fed metadata by an untrusted
party that makes it express that to a differen URI on the same target
host, causing a different Toid/Tperm that it may also be authorized for
but did not intend).

"AIF MUST be used in a way that it is unambiguous who is the target"

There might be a case for many alike targets that all receive the same
configuration (thinking of homogenous sensor cloud where a client gets a
token to access any device's /s/temp); s/unambiguous/clear/ would open
it up for that.

REST model / Uri-Query

The way the path tstr includes the Uri-Query seems to indicate the
strict resource definition in which /foo is completely distinct from
/foo?x=y, which I appreciate.

To a reader coming from different mindsets that could be pointed out
more pronouncedly, for example by extending (double asterisks marking

  One might be tempted to extend the model towards URI templates
  [RFC6570]; **this would open things up for local-parts like
  `/s/temp{?any*}`**. However, that requires some considerations of the
  ease and unambiguity of matching a given URI against a set of
  templates in an AIF object.


I didn't check the CDDL by running it through a parser, but trust you
did at some point. (Someone with a bit of time at their hands might
want to add support for this at the datatracker, and then we'd have a
nice 🌊🐗 logo where YANG based documents have their ☯ ).

REST on "point of enforcement"

In all the examples the point of enforcement is a full authority. I'm
currently thinking of a media device roughly described as follows


where whoever is authorized to write to /media.public may decide what
inside /media/ is public and what is not (but doesn't get to open up
/config/ to the public).

I *think* from reading the spec that all is in place for such
applications to work (where the way of linking AIF documents to the
subjects is out of scope, as is the relation type and how the relation
type is used to set the target unambig... aeh, clearly).

If it is, I'd leave it up to your judgement whether it's worth words or
not. If it is not, please help me understand why not (maybe it can be
helped) or what I missed that rules it out.

Looking forward to implementing this as an authroization model,
thanks for this document

Build a man a fire, and he'll be warm for a day. Set a man on fire, and
he'll be warm for the rest of his life.
  -- Terry Pratchett (attributed)