From: Cigdem Sengul <[email protected]> Sent: Wednesday, January 15, 2020 4:44 AM To: Jim Schaad <[email protected]> Cc: [email protected]; Ace Wg <[email protected]> Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile - Validating a subscription is in scope Hello, 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/+"? [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. [CS] Agreed. Another issue that we should say something about is the case when multiple permission strings aggregated together gives enough permission to the subscription request, based on the _current_ topic hierarchy. Example: Scope strings in the token were: publish_sport/tennis publish_sport/basketball and then the client asks for publish_sport/+ If tennis and basketball are the only topics under sport, then this is a valid request. But, if the topic hierarchy is changes during the connection time (adds sport/baseball) then subscriber gets PUBLISH messages for something they should not. When topic subscriptions are not protected, the broker would send anything at the single level for sport/+ and would not worry about the new additions after the subscription. When topic subscriptions are protected, the Broker can choose to do two things: 1) Allow the subscription but internally subscribe the clients to sport/basketball and sport/tennis only. or 2) Reject the subscription and the client needs to ask for subscriptions that are a subset or equal to their permission strings. So the client specifically needs to ask for publish_sport/tennis and publish_sport/basketball matching its scope strings. But then scope parameter cannot be optional and must be included in the AS response. or 3) Allow the subscription, when a new level is added, check the permissions of all active subscribers, send DISCONNECT if the current permissions do not apply to the new hierarchy. 1 would need to be again signalled to the client, 2 might be too restrictive, and 3 may introduce a processing load if things are changing all the time (which I do not expect). Leaning towards 3... Any thoughts? [JLS] My first thought was to run and hide. I think you have the scope strings setup wrong, they all should be “subscribe_” not “publish_” as a client is never going to ask to publish with a wildcard (MQTT-3.3.2-2). I would far prefer that the answer be 2 rather than 1 and I think that 3 is right out. For 3 you are saying we are going to subscribe you, and then potentially disconnect you at a later time for something you never heard about. I don’t really care about 1, only because there is no way to communicate this information back to the client that one is changing the set of subscriptions that was requested. I am not sure what you are requesting in terms of returning the scope parameter. The current OAuth specification states that if the Authorization server returns a token that contains a different scope that the one requested by the client, then it is required to return the modified scope to the client. Is that what you are looking for. Jim --Cigdem Jim --Cigdem Jim _______________________________________________ Ace mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ace
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
