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

From: Francesca Palombini <[email-masked]>
Date: Fri, 13 Dec 2019 15:10:16 +0000

Hi Cigdem,

Thanks a lot for your review and your support of this document! Your points are very valid, and of course you are right with noticing that a revision is needed to adapt the text to make it work for MQTT. I appreciate your comments about topics hierarchy as well, that is something we did not think about before and definitely need some discussion.

Detailed answers inline.

Francesca

From: Ace <[email-masked]> on behalf of Cigdem Sengul <[email-masked]>
Date: Friday, 29 November 2019 at 17:12
To: Ace Wg <[email-masked]>
Subject: [Ace] Review for draft-palombini-ace-coap-pubsub-profile

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?

FP: Yes, I am planning to make some updates to the text to make this generic. In general, I think the structure of the draft will be the same, but each section would either have a sentence or (if longer text is needed) a subsection talking about the different alternatives. For example, Section 2 would remove current specific text about CoAP pubsub (only talk about general pubsub) and would replace that text with an additional paragraph mentioning that the pubsub protocol can be CoAP or MQTT. Section 3 would have 2 subsections, coap_pubsub_app and mqtt_pubsub_app, etc.

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

FP: That is all correct. Moreover, we can also discuss details such as what communication protocol the Client uses to talk to AS2. Right now ace-key-groupcomm is only defined for CoAP, but if MQTT prefers to use HTTP, that is very easy to define.

(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?

FP: I promise I did not read this question before answering the text above :) Yes. This is really easy to specify, we already do this with CBOR/JSON, in ace-key-groupcomm:

The ACE framework is based
   on CBOR [RFC7049], so CBOR is the format used in this specification.
   However, using JSON [RFC8259] instead of CBOR is possible, using the
   conversion method specified in Sections 4.1 and 4.2 of [RFC7049].

We would add CoAP/HTTP in the same way ("CoAP is default, but HTTP works the same way"). Then the pubsub-profile could specify which protocol is used in the different profiles.

(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?

FP: No, the broker would not accept this message. In fact, during the ACE exchange between Publisher, AS1, and Broker, the Publisher would post a token to the Broker that contains the resource it is allowed to publish to, namely in this case topic 1. If it does have rights to publish to topic 2 as well, that would be included in the token. That is covered by the transport profile used, as you mentioned (MQTTL-TLS/CoAP OSCORE). Orthogonally to this, when getting the keys from AS2 to protect the publication, if the Publisher has tried to publish to topic 2 without having the correct content encryption keying material, the decryption of the publication at the subscriber would fail even before signature verification. But the Subscriber would not get the publication if the Publisher is not authorized to publish on that topic. Note that if the owner wants to protect topic 1 and topic 2 with the same keying material, that is possible, but then the case above would not be an attack but an acceptable scenario (Publisher allowed to post to both topics, publication protected with the same key).

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.

FP: By policies on AS1 I mean exactly that: "what endpoints are allowed to publish on what topics". If one wants to control who can subscribe, that would also be part of the so-called policies.

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

FP: That is a possibility. Right now this is not the case because I thought it would be better to keep the two ("authorization to publish on one or more topics on Broker" and "authorization to get encryption keys for one or more topics") independent. The reason for that was that the same key could be used for several topics, i.e. Publisher P could be allowed to publish on topic 1 but not on topic 2, even though topic 1 and 2 use the same encryption key. Yes, that could be a way to do it, but I am not sure about the advantage, apart from the obvious policies synchronization (i.e. in this way there would be no need for synchronizing since in practice AS1 would know both what topic Publisher P can publish to and what content encryption key it can retrieve). But I'd be happy to discuss that further.

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

FP: Thank you for bringing this up. You are right, hierarchies are something not really thought through right now in this document.

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.

FP: Yes, what you describe is a valid scenario covered by the 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“?

FP: The first question I have is if it is even possible to indicate scope like this in ACE. I do not think so (and please correct me if I am wrong), and in this case the scope would have to be expressed as the union of the following URIs: publish_sport/tennis/player1/rankings and publish_sport/tennis/player2/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”.

FP: But once the scope is expressed for "rankings" only, then the doc should cover this case too. Then it is up to the topic owner (and reflected on the AS2) to decide if the keying material is the same for rankings and for the upper-topics (? as opposed to sub-topic) player1 and player2. And similarly, it will be up to the broker to verify that the authorization for publishing to rankings is separate from publishing to player1 and player2. It is also a valid case to make it so sub-topics inherit authorizations, but that would be up to the application to decide. Anyway, these are all valid considerations that need to be made in the document.

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

FP: I don't think this scales well, but yes, an application could also do this.

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?

FP: No I don't see problems with this, although I am not sure we need to describe this in this document. If I understand correctly, the scenarios should be covered by the current spec. Or did I miss something?

Nits:
Figure 2: Negociation -> Negotiation

FP: Ok, will fix.

Kind regards,
--Cigdem

---

From: Cigdem Sengul <[email-masked]>
Date: Wed, 18 Dec 2019 15:47:04 +0000

Dear Francesca,

Thank you for your responses to my comments.
My comments are inline.

> (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?
>
>
>
> FP: Yes, I am planning to make some updates to the text to make this
> generic. In general, I think the structure of the draft will be the same,
> but each section would either have a sentence or (if longer text is needed)
> a subsection talking about the different alternatives. For example, Section
> 2 would remove current specific text about CoAP pubsub (only talk about
> general pubsub) and would replace that text with an additional paragraph
> mentioning that the pubsub protocol can be CoAP or MQTT. Section 3 would
> have 2 subsections, coap_pubsub_app and mqtt_pubsub_app, etc.
>
>
>

CS: YEs, sounds good.

> 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.”
>
>
>
> FP: That is all correct. Moreover, we can also discuss details such as
> what communication protocol the Client uses to talk to AS2. Right now
> ace-key-groupcomm is only defined for CoAP, but if MQTT prefers to use
> HTTP, that is very easy to define.
>
>
>
>
> (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?
>
>
>
> FP: I promise I did not read this question before answering the text above
> :) Yes. This is really easy to specify, we already do this with CBOR/JSON,
> in ace-key-groupcomm:
>
>
>
> We would add CoAP/HTTP in the same way ("CoAP is default, but HTTP works
> the same way"). Then the pubsub-profile could specify which protocol is
> used in the different profiles.
>

CS: Cool. Because, I imagine a client or its AS would follow the same
protocol, HTTPS,  to talk to the ASes, and then talk to MQTT to RS.

> (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?
>
>
>
> FP: No, the broker would not accept this message. In fact, during the ACE
> exchange between Publisher, AS1, and Broker, the Publisher would post a
> token to the Broker that contains the resource it is allowed to publish to,
> namely in this case topic 1. If it does have rights to publish to topic 2
> as well, that would be included in the token. That is covered by the
> transport profile used, as you mentioned (MQTTL-TLS/CoAP OSCORE).
> Orthogonally to this, when getting the keys from AS2 to protect the
> publication, if the Publisher has tried to publish to topic 2 without
> having the correct content encryption keying material, the decryption of
> the publication at the subscriber would fail even before signature
> verification. But the Subscriber would not get the publication if the
> Publisher is not authorized to publish on that topic. Note that if the
> owner wants to protect topic 1 and topic 2 with the same keying material,
> that is possible, but then the case above would not be an attack but an
> acceptable scenario (Publisher allowed to post to both topics, publication
> protected with the same key).
>

CS: OK, it wasn't clear to me what the scope of the token for the publish
permission the Publisher P got from the AS1. It read as it got a token that
just said Publish, without constraining the resource. Your explanation now
clarifies this, and maybe it should be put in the text as well how publish
tokens are scoped.

> 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.
>
>
>
> FP: By policies on AS1 I mean exactly that: "what endpoints are allowed to
> publish on what topics". If one wants to control who can subscribe, that
> would also be part of the so-called policies.
>

CS: Yes, this is more clear now.

>
>
> (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.
>
>
>
> FP: That is a possibility. Right now this is not the case because I
> thought it would be better to keep the two ("authorization to publish on
> one or more topics on Broker" and "authorization to get encryption keys for
> one or more topics") independent. The reason for that was that the same key
> could be used for several topics, i.e. Publisher P could be allowed to
> publish on topic 1 but not on topic 2, even though topic 1 and 2 use the
> same encryption key. Yes, that could be a way to do it, but I am not sure
> about the advantage, apart from the obvious policies synchronization (i.e.
> in this way there would be no need for synchronizing since in practice AS1
> would know both what topic Publisher P can publish to and what content
> encryption key it can retrieve). But I'd be happy to discuss that further.
>

CS: I could not understand the reason for two ASes: "Publisher P could be
allowed to publish on topic 1 but not on topic 2, even though topic 1 and 2
use the same encryption key."
In my head, AS1 would grant a token that would tell Client C what
publish/subscribe permissions they have.
Client C submits the token to AS2, which returns the encryption keys for
these topics.
Client C submits the token to RS, which checks what publish/subscribe
permissions the Client has - it would not allow client C to publish to
topic 2, if it doesn't have permission.
But client C can subscribe (if the token says it can) to topic 2 and use
the same encryption key as topic 1 to read the messages.

A JWT/CWT can have multiple audiences as an array, so the token can be used
for both.
To me,  the advantage of not having to synchronise policies in two
different ASes would be considerable.

>
>
> 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).
>
> FP: The first question I have is if it is even possible to indicate scope
> like this in ACE. I do not think so (and please correct me if I am wrong),
> and in this case the scope would have to be expressed as the union of the
> following URIs: publish_sport/tennis/player1/rankings and
> publish_sport/tennis/player2/rankings
>

CS: This is possible in the mqtt_tls profile because MQTT accepts topic
filters. And, we defined our scopes such as publish_topic1/#
subscribe_+/topic2 etc.

>
> 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”.
>
>
>
> FP: But once the scope is expressed for "rankings" only, then the doc
> should cover this case too. Then it is up to the topic owner (and reflected
> on the AS2) to decide if the keying material is the same for rankings and
> for the upper-topics (? as opposed to sub-topic) player1 and player2. And
> similarly, it will be up to the broker to verify that the authorization for
> publishing to rankings is separate from publishing to player1 and player2.
> It is also a valid case to make it so sub-topics inherit authorizations,
> but that would be up to the application to decide. Anyway, these are all
> valid considerations that need to be made in the document.
>

CS: I see that I wasn't clear in my thinking before and mixed up things. I
was trying to understand how groups map to topics and the topic hierarchy;
and how group maintenance scales with the increasing number of topics,
publisher and subscribers. Said another way, who creates groups, and
creates/updates keys for these groups to be maintained in the KDC?

I agree topic hierarchies require more thought. Here is my second attempt
at explaining my thinking, which is by no means complete:
In MQTT, it is possible to publish to all levels in a topic hierarchy e.g.,
if you have sport/tennis/player1/rankings, it is possible to publish to the
sport, sport/tennis, sport/player1, sport/player1/rankings...
One option is to have as many keys as the nodes on the hierarchy
independent of actual publishers and subscribers to them.  (Assuming this
hierarchy is pre-built, and AS2 maintains a complete topic-key database).
So, if publisher P1 comes with rights to publish to sport/tennis - he gets
the keys for that. But, if he comes with the right to publish to
sport/tennis/#, he gets multiple keys, one each for every node under
tennis.

The other option is creating groups dynamically and subtopics inherit
authorisations (as captured by the wildcards), i.e., publisher and
subscribers that have an exact match in their topic filters form a group.
Going back to the previous example, assuming AS2 is generating the keys
(need to read the groupcomm in detail to understand how the KDC and its
endpoints work in general), I imagine something like this may work:
Publisher P1 - publish_sport/tennis/#  -> AS2 checks if a matching group
exists, doesn't find one, generates the key, and hands it out to P1, stores
the mapping.
Publisher P2 - publish_sport/tennis/# -> AS2 checks if a matching group
exists, find one, gives out the key to P2.
Subscriber S1 - publish_sport/tennis/# -> AS2 checks if a matching group
exists, find one, gives out the key to S1. Until now, assumed no rekeying
when the new members join an existing group, as this would work well with
MQTT RETAIN option, which enables the publisher to indicate
to the Broker that it should store the most
 recent message for the associated topic.  Hence, the new subscribers
can receive
the last sent message from the publisher of that particular topic
without waiting
for the next PUBLISH message.
Subscriber S2 - publish_sport/tennis/+/rankings - AS2 checks if a matching
group exists, does not find an exact match -> generates new key, but then
needs to update P1, P2, S1 as well as publish_sport/tennis/+/rankings will
be sent encrypted with the new key, and the rest will be with the old key.
When they are rekeyed, the publishers may send RETAINED messages again with
the new key.

i.e.,
P1-P2-S1 are one group
P1-P2-S1-S2 would be another group
Two groups - two keys.

Do not know what is best, or there is a third option.

Another thing to consider would be rekeying policies of course.

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

CS: Yes, scratch that - that actually wouldn't work.

Thanks,
--Cigdem

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 19 Dec 2019 14:30:15 -0800

On Wed, Dec 18, 2019 at 03:47:04PM +0000, Cigdem Sengul wrote:
> > about the advantage, apart from the obvious policies synchronization (i.e..
> > encryption key it can retrieve). But I'd be happy to discuss that further..
> >
> 
> 
> > publishing to rankings is separate from publishing to player1 and player2..

Having to always send all the keys would get frustrating (and/or expensive
in terms of bytes!), but the "other option" below feels quite messy with
respect to having to push out updates when membership/number of groups
changes.  I suppose the right balance depends on actual usage patterns, but
I would mostly expect a flow where permissions on a hierarchy grant the
ability to get any (per-topic) key from the hierarchy, but you still have
to explicitly request the individual key for the individual topics you are
going to post to, to be of most generic applicability.  Am I forgetting a
reason why that's not possible?

Thanks,

Ben

> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Cigdem Sengul <[email-masked]>
Date: Fri, 20 Dec 2019 12:03:04 +0000

Hello Ben,
Response below.

> reason why that's not possible?
Yes, both have problems - mainly used them to talk about the differences
between (semi-)static grouping (topics define groups) and dynamic grouping
(active publisher/subscribers and their topic permissions determine groups).

Yes, a token with scopes that use the wildcard will give you the right to
get any key from the hierarchy. In the "first approach," you would need the
get the specific one for the individual topic because any number of
publisher/subscribers may be on that topic (but not on others).
If I understand correctly, you suggest that the client asks for the right
key just-in-time before a publish/subscribe message?
This is a good solution if the client can connect to AS2 at all times, but
in ACE, I thought, we did not assume ASes are always reachable by clients.
Therefore, I was always thinking of a scenario where the client is
provisioned with the right keys beforehand (determined by their
permissions).

But the "second option", where the same encryption key may be used across
different topics,  has the same connectivity requirements due to rekeying
expected as groups change.

I hinted this in my previous e-mail by having to consider rekeying
policies, as I haven't seen it mentioned in coap-pub-sub.

Need to also consider rekeying as a separate problem that needs to be
addressed regardless of what approach is taken: ace-key-groupcomm refers
to  [RFC2093], [RFC2094] and [RFC2627] for rekeying mechanisms and I am not
exactly sure how to use them for client-broker communication.

 ace-key-groupcomm also states: If the application requires forward
security, the KDC MUST generate new group keying material and securely
distribute it to all the current group members but the leaving node, using
the message format of the Key Distribution Response"
If it is the AS2 (KDC) that needs to rekey groups, then AS2 should be able
to connect to the clients and push this information? Am I missing something
here?

(In MQTT, things were easier when tokens expire. The Broker knows a token
expired and disconnects the client, which forces the client to get a new
token. But, the Broker here has no idea of rekeying.  So, the trigger for
that needs to come from AS2. )

Regards,
--Cigdem

> > > FP: I don't think this scales well, but yes, an application could also
> do
> > > this.
> > >
> >

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 24 Dec 2019 11:32:49 -0800

> provisioned with the right keys beforehand (determined by their

Yes, I was thinking of having the client ask for the key "just in time",
but you are also right that we do consider cases where such connectivity is
not always available.  So perhaps there is not a single clear answer for
all cases...

> to connect to the clients and push this information? Am I missing something

I think we need to hear from other members of the WG to make progress here;
I don't have a clear picture, myself.

-Ben