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 protected]> on behalf of Cigdem Sengul <[email protected]> Date: Friday, 29 November 2019 at 17:12 To: Ace Wg <[email protected]> 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
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
