[Proposal] Add a generic device-based addressing scheme for "WAN" networks about kotori

[amotl]

Thoughts about channel isolation and authentication

Problem

We will have to take care that this implementation does not accidentally weaken Kotori's security concept, which is mostly based around limiting access to certain topics by path prefix, and mapping that to channel user/owner ACLs in Mosquitto, which are reflected on the second path level of the MQTT topic, after the realm component, which is mqttkit-1 in the example below.

You will recognize that it is not possible to apply an ACL rule on the MQTT topic mqttkit-1/d/owner-*, as wildcards are usually applied to MQTT topics only on the path segment level, and not mid-segment. ¹²

If we don't apply any countermeasures here, direct-device-addressing will open the door to access the write path to anyone else's channels, even if they would be protected by a MQTT full-channel ACL.

Example

Those examples demonstrate the MQTT topics for the same data channel, while using different addressing schematics, classical channel-based vs. the new device-based scheme.

# Channel-based MQTT WAN addressing.
mqttkit-1/owner/foo/bar/data.json

# Device-based MQTT WAN addressing.
mqttkit-1/d/owner-foo-bar/data.json

A typical Mosquitto ACL item currently looks like this.

user <username>
topic readwrite mqttkit-1/owner/#

Solutions

I see two possible solutions.

1. When enabling this feature in the corresponding Kotori .ini file, the operator would need to permit it for specific owners only, like

   [channel]
   permit_device_addressing = ["acme", "peter"]

   We may allow to explicitly configure *, in order to tear down that wall completely, but otherwise, allowing no user to use direct-addressing, would be a sane choice by default.

2. Adjust the specification.
   This effectively shrinks the headroom to two path components. It feels a bit cleaner, but I don't know if it is possible to implement. Also, it would defy @thiasB idea to run the application for the whole hiveeyes realm.

# Device-based MQTT WAN addressing.
mqttkit-1/owner/foo-bar/data.json

Conclusion

Currently, for @thiasB use case, I see no other choice than 1., adding a permit_device_addressing configuration option. While it is sad that the feature would not be completely maintenance-free then, I see no other chance to hold up the minimal amount of channel isolation/protection Kotori offers.

Please do not hesitate to share any ideas you might have about this detail. Thanks.

Footnotes

1. https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/ ↩

2. https://cedalo.com/blog/mqtt-topics-and-mqtt-wildcards-explained/ ↩