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

On Wed, Dec 18, 2019 at 03:47:04PM +0000, Cigdem Sengul wrote:
> Dear Francesca,
> 
> Thank you for your responses to my comments.
> My comments are inline.
> 
> >
> >
> > 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.
> >
> >
> >
> 
> 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:
> >
> >
> >
> > 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.
> >
> 
> 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).
> >
> > 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
> >
> 
> 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.

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

> 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).
> >
> >
> >
> > FP: I don't think this scales well, but yes, an application could also do
> > this.
> >
> 
> CS: Yes, scratch that - that actually wouldn't work.
> 
> Thanks,
> --Cigdem
> 
> 
> 
> >
> >
> > Kind regards,
> >
> > --Cigdem
> >

> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace