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

[Cigdem Sengul <[e-mail]>]

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
AS1/AS2?).
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,
--Cigdem


On Sun, Jan 3, 2021 at 10:38 PM Francesca Palombini <francesca.palombini=
[e-mail]> 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 [e-mail]" <
> [e-mail] on behalf of [e-mail]> 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:
>     https://datatracker.ietf.org/doc/draft-ietf-ace-pubsub-profile/
>
>     There is also an HTML version available at:
>     https://www.ietf.org/archive/id/draft-ietf-ace-pubsub-profile-02.html
>
>     A diff from the previous version is available at:
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-pubsub-profile-02
>
>
>     Please note that it may take a couple of minutes from the time of
> submission
>     until the htmlized version and diff are available at tools.ietf.org.
>
>     Internet-Drafts are also available by anonymous FTP at:
>     ftp://ftp.ietf.org/internet-drafts/
>
>
>     _______________________________________________
>     Ace mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/ace
>
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
>