[Ace] Review for draft-palombini-ace-coap-pubsub-profile

[Cigdem Sengul <[e-mail]>]

Hello,


As I remotely promised in the WG meeting in Singapore, here is my review of
the pubsub-coap document.


When reviewing the document, I have kept two things in mind: how the
document reads now, and whether it can easily be extended to include MQTT
as well.  I’ve understood including MQTT is in scope for this document in
the workgroup meeting in Singapore. I would be happy to help, if you need
me to, for MQTT-specific contributions to this draft.  Doing this would
allow the mqtt_tls profile to progress independently of this document by
stating that content protection is out of scope for mqtt_tls profile and
referring to this document for a solution.


I want to repeat my support for the adoption of this profile, as it
addresses a significant problem for publishers to constrain the content of
their publications to only their subscribers. It does handle the multiple
publishers to a single topic case well (allowing subscribers to learn about
all the publishers to a specific topic).


In the following, I list a few things reading the draft made me think,
especially in its applicability to MQTT:

(1) What is planned to make this document a generic pubsub solution? Will
there a generic architecture section, and specific descriptions for each of
the protocols?

For instance, if an MQTT client implements this,  the client would talk to
AS1 to get a token based on the way we describe in the mqtt-tls profile,
and then get keying material for topics from AS2.

I expect the MQTT client would use a different profile name like
mqtt_tls_app to signal to AS1 that it is supporting the application layer
security. This is because the draft hints that there should be a policy
agreement between AS1 and AS2: “Note that AS1 and AS2 might either be
co-resident or be 2 separate physical entities, in which case access
control policies must be exchanged between AS1 and AS2, so that they agree
on rights fo  joining nodes about specific topics.”


(2) If we keep AS1 as the mqtt-tls profile AS, then for consistency sake,
the MQTT client would expect to talk to HTTPS to AS2, but the coap-pubsub
draft describes these, expectedly, in CoAP. Will there be support for HTTPS?


(3) In the mqtt_tls profile, the AS grants tokens that identify both
“publish” and “subscribe” rights and the topics by adding scopes in the
format, e.g. “publish_topic1” “subscribe_topic2/#”.  This format allows
representing all publish/subscribe permissions concisely for the client
which may be acting both as a publisher and a subscriber.

In the coap-pubsub, this is separated between AS1 and AS2. “AS1 hosts the
policies about the Broker: what endpoints are allowed to Publish on the
Broker.” “The AS2 hosts the policies about the topic: what endpoints are
allowed to access what topic. “

The coap-pubsub also permits that AS1 can host policies about what
endpoints are allowed to Subscribe to the Broker.


However, wouldn’t this separation between AS1 and AS2 have the following
issue: Publisher P, having the permission to publish to topic1 and hence,
successfully getting an access token from AS1, then goes ahead and sends a
PUBLISH on topic 2, which it doesn’t have a right to publish.

Wouldn't the broker would pass this message to subscribers, and the
subscribers would discard the message because the publisher does not belong
to their “publishers list” (subscribers have all the public keys of all
publishers). Have I missed something, does the draft protect against this
at the broker?


Differently, with the current way mqtt_tls scopes are described, AS1 would
need to know not only who can publish or subscribe, but also the policies
on topics.


(4) That brings me to another point regarding this note in coap-pubsub
profile. The profile says: “How the policies are exchanged [between AS1 and
AS2] is out of scope for this specification.” I wonder whether the token
the client gets from AS1 should also be usable towards AS2, and AS2 is
replaced with an RS for retrieving the keying material for topics (more on
this later), i.e., AS2 does not need to host/manage/coordinate policies
with AS1.


(5) Regarding groups and group memberships, it seems like for the draft
group = a single topic.


In MQTT, topics can have level separators and multi-level (#) and
single-level (+) wildcards.  Similarly, CoAP would also have hierarchies.


Consider the case when a PUBLISHER is allowed to publish to
sport/tennis/player1/# but not sport/tennis/player2/#.  The players'
directory may have sub-levels like “rankings”.

And a subscriber has permissions to get content from sport/tennis/#.

It seems like sport/tennis/player1 would be a group, and
sport/tennis/player2 be another group.

And, the subscriber needs to be in two groups. This is fine, I believe,
according to this document.


In MQTT token scopes, we also accepted that a publisher represents its
PUBLISH rights with topic filters (note a PUBLISH message cannot be sent to
a filter, but the topic filters are useful in summarising permissions).

Let’s assume there is a publisher with scope
“publish_sport/tennis/+/rankings“?

Then being a part of all groups (player 1 and player2) is too general as
this publisher cannot publish to everything but only to “rankings”.


Another approach could be each publisher creating its group. This way the
number of groups scales with the number of publishers (and the COSE keys is
per publisher).

So, the subscriber still asks permissions for and subscribes to topic
filters.

There needs to be a solution that maps the topics to a publisher list...

AS1  (see my earlier discussion on who keeps the policy information) knows
who has the right to publish to these topics in their policy database and
has the public key information for them. AS2 hosts the COSE key for this
publisher.


Putting all this information together,  when a message is received, the
subscriber would use the publisher's public key to verify the publisher
signature (the draft already supports this), then locate the symmetric key
it received from the AS2 for this publisher to decrypt the message.



Would there be any problems with this approach?


Nits:

Figure 2: Negociation -> Negotiation


Kind regards,

--Cigdem