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
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
