From: Cigdem Sengul <cigdem.sen...@gmail.com> Sent: Tuesday, January 14, 2020 6:24 AM To: Jim Schaad <i...@augustcellars.com> Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg <ace@ietf.org> Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile - Validating a subscription is in scope Hello Jim, Topic filter and permission filter matching is something that I would like to have a better resolution as well. Responses inline. On Mon, Jan 13, 2020 at 1:38 AM Jim Schaad <i...@augustcellars.com <mailto:i...@augustcellars.com> > wrote: I have run across an interesting question for doing validation of subscriptions that I would like to get an opinion on. When doing a publish, there is not an issue. One simply takes the set of values in the scope field as topic filters and checks the publication topic against the set of permissible publication topic filters in the scope. [CS] Yes. When doing a subscribe, there are four distinct cases that can arise: 1. The subscription is for a single topic and either is or is not successfully matched against the scope topic filter. [CS] Yes. 2. The subscription is for a topic filter and it is identical to the scope topic filter. [CS] Yes. 3. Both are topic filters and are not the same. Is one supposed to do some type of subset matching on the two filters or does one always say that this is not a match. This is not addressed in the MQTT document and I am not sure where it would be addressed. As an example: Scope value is subscribe_sport/# Subscription topic is sport/tennis/# The second is clearly a subset of the first and thus it would seem logical to include it, but it gets more complicated if one instead asks for Subscription topic is sport/+ In this case the two wild cards are not the same value. We were thinking using a subset matching to check whether the token would permit the subscription request. For your example, a subscription request "sport/+" would cover all the single-levels under "sport" - including "sport/" but not "sport" . So if the scope is "subscribe_sport/#" which covers all multi-levels under "sport" (including "sport", the subscription request should still succeed. (i.e., the subscriber has a larger set of permissions than the request) Now when the broker receives a publication with "sport/tennis" then it should pass this message on to the subscriber. When it receives a publication "sport/tennis/player1" then it should not. This would be normal broker behaviour as well (without using ace). [JLS] This is what I expected the answer to be, I will need to figure out what this algorithm looks like now for all of the corner cases. It gets interesting when the scope is more restricted than the subscription request. For instance, the scope is sport/+ But subscription is sport/# Should this be refused? Obviously the subscriber is attempting to subscribe to more than it has permission for. But does the broker still allow the subscription but reduce it to "sport/+"? Currently would opt for the former, because the second option may be hard to signal to the subscriber - the SUBACK reason string together with the user property field may be used for such feedback to the subscriber but would need to be defined properly. [JLS] Given that this is not defined in the base MQTT specification, most clients would not expect this if the ACE is grafted on the side of the program. I would therefore say this is a “not authorized” and go on. Jim --Cigdem Jim _______________________________________________ Ace mailing list Ace@ietf.org <mailto:Ace@ietf.org> https://www.ietf.org/mailman/listinfo/ace
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
