Re: [Ace] I-D Action: draft-ietf-ace-pubsub-profile-02.txt

Cigdem Sengul <> Mon, 11 January 2021 22:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 399AD3A137B for <>; Mon, 11 Jan 2021 14:18:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dHoSae_95djT for <>; Mon, 11 Jan 2021 14:18:52 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::a35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E6D713A1387 for <>; Mon, 11 Jan 2021 14:18:51 -0800 (PST)
Received: by with SMTP id k9so161923vke.4 for <>; Mon, 11 Jan 2021 14:18:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Uz+PJgsWt2+eVkylscVivzWprVLtz8Kodznw2bJ97kE=; b=iWQvzx2hOl8D6ceQnHhYSxJTNKa6DmMWmyfzkMlT4uscCOseqzyHqOG4zxqWPYwjcJ HDh6UuaGhwel5Eo+Y3U1XJUqGnwX+zJokhT9oFrB4pLE3V4+qFjlF61KBP156DKH3BjG WUte0gRVGoqm24YFmetQ3VHx1KnETNP/VYeyyp7r2FrYDQbZSraOibYOjKnv+7h47p4+ 5dtiMlUX3OBrosxISPbC37UMYuxqspvQsFHPHIxc5ecSSSxEDurjXMNWC71JsXKJfU+a 5Ki2IV5ZsenkDZmhJlrVPGTfBLrEs3EeiXxaYBQ5iRECx970BuCyeZS+tr4DD2UuiHcF 8AMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Uz+PJgsWt2+eVkylscVivzWprVLtz8Kodznw2bJ97kE=; b=Lqs9fSMzgDa3qStTzNHl6q1LlMlCzX7964nxJtCaDi94YbbcLZ8+hOe0HAV4Hl9kS8 4DlSvgqDAipABG3Lhy2LJelvzfUJOmIM9t1vgny8Znyf0G3OX91MY/o3UTZ8WRbX4fo5 NAyPZc01COzWe17lycPgU0QLFh3y8vPwk0f6il/n9Agd1wIMuO0kGGx+XeKf1vvZLu3w webJl3kFxlDqIug9aLnjcvVw7C8CTgFuVfZ6hYNtNgsoRYD9anAQOqaH+QTw55cPoCM1 pPim8DgVQv8hEgAmRpuCKu3DQdHRYvvHDIcujYQgA6Smrb6aBRuOpWyA8wmszWLLXTJ0 09OQ==
X-Gm-Message-State: AOAM5302ZK9xbKzEAmY8C2z757zm/K6CMNLlsuwqi4imlp2FDbBVoQnY CHhpMSD0tKeS1hqmIjGFC2xuAsSxqFPVNpTfrtQ=
X-Google-Smtp-Source: ABdhPJzRGQP127zDXSWJ6hVyEM9V3P/mW0w575OWQm7QvhdinAMJ4jFyfA5etzDElwUtJzPc8p0Kp05cdOR0rrD4Q90=
X-Received: by 2002:a1f:99d2:: with SMTP id b201mr1946145vke.11.1610403530691; Mon, 11 Jan 2021 14:18:50 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Cigdem Sengul <>
Date: Mon, 11 Jan 2021 22:18:40 +0000
Message-ID: <>
To: Francesca Palombini <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000006457cb05b8a74a0d"
Archived-At: <>
Subject: Re: [Ace] I-D Action: draft-ietf-ace-pubsub-profile-02.txt
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, 11 Jan 2021 22:18:54 -0000

Thank you, Francesca,

Now I've added an mqtt branch to github, adding some references, and
clarifications, but a number of comments as well.
If I sum things up from the MQTT perspective (with the way the draft is
currently written):
A publishing client can get a token from AS1 to publish to MQTT broker
(there is mention of HTTP,  but do MQTT clients need to speak CoAP to
Both types of clients (Publisher/Subscriber) get tokens from AS2, and use
it towards the AS2-KDC to get the latest keys.
MQTT broker authorises CONNECTs for Publisher tokens from AS1, it doesn't
expect anything for subscribe-related permissions (unless subscribers are
authorised). (There is not distinction Publisher/Subscriber for MQTT -
client can provide a token with some publish permissions during connect,
and then does PUBLISH/SUBSCRIBE messages).
Broker does the mqtt-tls-profile checks for PUBLISH messages. It doesn't do
any checks on SUBSCRIBE messages and when its forwarding published messages
to subscribers, This is because subscribers are authorised as long as they
can decrypt messages.
One thing we may add is that the MQTT broker does not support retained
messages (as keying material may have changed for new clients, and it would
be basically sending jibberish to them).

Since the clients initiate a connection to the broker with CONNECT and
maintain it as they send PUBLISH SUBSCRIBE messages, I think all of the
above can be described in a single section for MQTT in the draft. So,
should we reorganise the draft so that CoAP PubSub is in one section, and
MQTT PubSub is in one section (rather than 4. Publisher: 4.1 CoAP publisher
- 4.2 MQTT publisher / 5. Subscriber: 5.1 CoAP Subscriber / 5.2 MQTT
Subscriber etc.)

Finally,  I think the things that need to be more clear:
* The current work division of AS1 and AS2 - for some reason, I relate more
to the case of AS1 being the AS, and AS2 being the KDC, AS1  handing out
tokens to talk to KDC and the broker.
To me it makes it easier to handle policy changes and revocations in both
ASes (as defined as out of scope in the draft).   I am sure I am missing
something with regards to why AS2 needs to be both an AS and KDC.

* For MQTT the scope format is AIF-MQTT; the case where the scope includes
permissions to multiple topics with wildcards, these wildcards may expand
to a number of topics handled by different keys. This part would need to be
explained better for MQTT.

* Maybe it is useful to define formally what a group is. Is it clients
holding the same set of keys, and so, each time a new client comes, the
group needs to be re-keyed.
In case of wildcards in MQTT, if Client1 has keys to publish to a/b/* and
Client 2 has subscriptions to a/b/* and Client 3 to a/b/topic1:
Client 1-Client2-Client3 is one group for a/b/topic, and Client 1 and
Client 2 is a second group for the rest.
It would be good to discuss if such things are only a problem for MQTT or
needs to be generally discussed.

Best wishes,

On Sun, Jan 3, 2021 at 10:38 PM Francesca Palombini <francesca.palombini=> wrote:

> Hi all,
> This is a keep-alive update. It also adds Cigdem as co-author of the
> document who is going to especially help with the MQTT parts of the
> document (to come).
> Francesca
> On 03/01/2021, 23:23, "Ace on behalf of" <
> on behalf of> wrote:
>     A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>     This draft is a work item of the Authentication and Authorization for
> Constrained Environments WG of the IETF.
>             Title           : Pub-Sub Profile for Authentication and
> Authorization for Constrained Environments (ACE)
>             Authors         : Francesca Palombini
>                               Cigdem Sengul
>         Filename        : draft-ietf-ace-pubsub-profile-02.txt
>         Pages           : 21
>         Date            : 2021-01-03
>     Abstract:
>        This specification defines an application profile for authentication
>        and authorization for publishers and subscribers in a pub-sub
> setting
>        scenario in a constrained environment, using the ACE framework.
> This
>        profile relies on transport layer or application layer security to
>        authorize the publisher to the broker.  Moreover, it relies on
>        application layer security for publisher-broker and
> subscriber-broker
>        communication.
>     The IETF datatracker status page for this draft is:
>     There is also an HTML version available at:
>     A diff from the previous version is available at:
>     Please note that it may take a couple of minutes from the time of
> submission
>     until the htmlized version and diff are available at
>     Internet-Drafts are also available by anonymous FTP at:
>     _______________________________________________
>     Ace mailing list
> _______________________________________________
> Ace mailing list