Hi I would like to make some comments on the draft draft-sengul-ace-mqtt-tls-profile-00.
Since this is my first post to the group, let me briefly introduce myself. I have previously sat on the MQTT TC at OASIS and I also have participated in the W3C and OASIS before. I haven't yet done anything at the IETF, so I realise that I have to learn a different approach, which I'm looking forward to. I also am the lead author on one a paper that is cited by the draft [1]. Since then I have extended the flows around MQTT and OAuth2 to include use of the Authorization Code flow and Refresh Flow, which are documented in [2] and also available in an open source repository in Github [3]. My approach so far has used Bearer tokens, not PoP tokens, so the cited work is not directly applicable to the proposal, but I believe may have some useful input. There is also another paper on the subject at [5]. 1) I think this proposal is really useful and welcome. 2) I'd like to make an overall comment regarding the MQTT specification. The current standard (v3.1.1) is widely adopted and used, and will likely remain so for a while still. However, there are issues in using it with OAuth2, especially around request-response flows. These issues seem to be resolved in the proposed working draft [4] for MQTT 5.0 (the replacement version). Therefore it would seem like a good idea for this proposed mapping of ACE to MQTT to look at the current 3.1.1 and proposed 5.0 versions as two different approaches, where it might be positive to postpone certain aspects into the 5.0 approach that are hard to deal with in 3.1.1. I will call these out below. 3) I'd be interested to know why the specification calls out the Will message handling, as it seems that it proposes the normal MQTT behaviour. Maybe I misunderstood? 4) The proposal to allow clients to include the token in the payload of publish messages (2.2.1) seems to me to be challenging. The problem is that MQTT 3.1.1 has no way of adding headers to the message, so I can understand that this is a way around this. However, I feel that this mixes up the layering of the protocol. This is one area where MQTT 5.0 will solve a problem (with MQTT Properties, and the ability to reauthenticate), so I would suggest considering that this be removed and dealt with in a MQTT 5.0 specific way. 5) There is some description of how the server should acknowledge messages in 2.2.1. Again, as in point 3, if there is no change to the default behaviour of MQTT then it maybe better not to call it out in this specification. 6) In 2.2.2, the specification calls out the behaviour of the broker onbound, once a publish message is received. This seems to imply that all the publishers and subscribers to a broker are using ACE. Is that an assumption of this spec or can it support both ACE and non-ACE systems. For example, an ACE-based publisher and a subscriber that uses a traditional MQTT authorisation scheme? Since the authorisation of subscribers using ACE is covered in 2.3, maybe it is not necessary to have 2.2.2 at all 7) The approach proposed in Appendix B seems to enable DoS attacks against the broker. It is not clear to me on reading this what the benefits are, but that is probably my lack of knowledge of the ACE approach. Can someone please help me understand the purpose of this flow. 8) Appendix C seems to be trying to deal with the situation where a client's token has expired but it may carry on working with reduced permissions and this will be signalled with a special message to a system topic. This seems overly complex to put in the specification. Again, this will be resolved with MQTT 5.0 where the broker will be able to request the client to re-authenticate without dropping the connection, and also will be able to drop the connection more gracefully. Looking at this from a client device development perspective, it seems that there are two options: a) Build a client that can cope with listening for "downgrade" messages and that can cope with downgraded permissions when tokens expire b) Build a client that can cope with abrupt disconnections, and can deal with expired tokens. Since clients already have to have logic to handle (b) anyway, the value of (a) seems less. 9) I hope this hasn't come across as overly negative. There is a lot I like about this specification but I felt that a detailed set of comments would be useful to the authors. Also I may well have misunderstood aspects of this spec! 10) I'd be very interested in adding support for flows that are currently out of band in this spec. At the moment, as I understand it, a device would need to support HTTPS or another protocol to interact with the AS. In [2] I have mapped the token flows, refresh flows etc into MQTT and it might be useful to standardise these. Let me know if that is of interest. Thanks Paul [1] Fremantle, Paul, et al. "Federated identity and access management for the internet of things." *Secure Internet of Things (SIoT), 2014 International Workshop on*. IEEE, 2014. [2] Fremantle, Paul, and Benjamin Aziz. "OAuthing: privacy-enhancing federation for the Internet of Things." (2016). [3] https://github.com/pzfreo/oauthing [4] MQTT v5.0 Working Draft 13: https://www.oasis-open.org/committees/download.php/60716/mqtt-v5.0-wd13.pdf [5] Fremantle, Paul, Jacek Kopecký, and Benjamin Aziz. "Web api management meets the internet of things." *European Semantic Web Conference*. Springer International Publishing, 2015. -- Paul Fremantle Doctoral Researcher, University of Portsmouth, School of Computing Visiting Scientist, Institute of the Architecture of Application Systems, Stuttgart Visiting Lecturer, Software Engineering Programme, Oxford University Co-Founder, WSO2 Apache Member and Committer email: [email protected], [email protected] twitter: pzfreo / skype: paulfremantle / blog: http://pzf.fremantle.org
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
