Cigdem and Anthony Thanks for the feedback.
We would be very happy to work with you on this draft. We can try together > to incorporate some of your suggestions and your OAuth/MQTT work into the > draft. > I'd be very happy to collaborate. > > Answers are below for the rest of your comments. > > >> 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. >> > > Indeed. We were aware of the work on MQTT version 5.0 when we set out > to write the draft. But, we did not know when it would be approved. So, we > decided to base the work on the official standard. But, we hinted in the > draft that some of the implementation difficulties can be ironed out with > the new version of MQTT. > Once the new version becomes official, it would be useful to update the > spec to cover both versions. > That seems like a great approach. I'd be happy to help with this. > > >> 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? >> > > In our draft, we included all the MQTT messages that would be affected > by an authorisation decision. This was to make sure we do not leave any > gaps, when the MQTT v3.1 is considered. Also, in our draft, the broker > triggers server disconnects due to authorisation problems. Hence, we are > creating a condition where a WILL message would be appropriate (the WILL > message should be sent of course only if the client specified it in the > CONNECT). > I see. I think this is a good idea, but I think it would be useful to state that this is the default MQTT behaviour and that this spec is not overriding it. > > >> >> 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. >> > > We were aware this does cross protocol layers, but we wanted an mechanism > for the client to push a new token without disconnecting, reconnecting & > re-subscribing to topics. It is optional - the fallback would be to > disconnect & reconnect with a new token. We're open to further feedback > about whether this is a good idea. > I would be interested to hear what others think. My own experience of MQTT and other pub/sub systems would make me believe we would be better to support this in MQTT 5, but not in MQTT 3. I understand that it is optional, but in general I feel that constrained choices are better in constrained device scenarios. > > >> 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. >> > > Yes, this can be shortened. We can just say: "the broker behaves > according to the MQTT spec and may or may not send an ACK depending on the > QoS level". We wish to still keep some information for the broker response > for completeness sake. > Sounds good. > >> 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 >> > > We thought about the possibility of supporting ACE & non-ACE clients. > This is an interesting idea: would allow us to support legacy clients. > But, in a mixed scenario, the broker then also needs an authorisation > function, e.g. using ACLs, separately from the authorisation server. > This is to make sure that only “authorised” clients publish/subscribe to > “protected” topics. > The draft doesn't exclude this possibility. > It's worth including 2.2.2 for clarity, to explain how the broker forwards > the PUBLISH messages to clients, and specifically the behaviour on token > expiry. We'll try to make it more concise. > Couldn't we point to the next section and say that "when the subscriber is also using this profile, the broker then behaves as in 2.2.3" or something similar? I agree that dealing with token expiry is important. > > >> >> 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. >> > > This, as stated by Ludwig, was put in to support /authz-info of ACE. It > was to support the PoP keys to be used in TLS handshake between the client > and the broker. But yes, the MQTT server needs to be resistant to DoS > attempts pre-authorisation. MQTT needs to resist DoS before and during > CONNECT (TCP holding, excess data). MQTT with /authz-info needs to > implement similar resistance, for example dropping connections that fail to > authenticate in a timely fashion, and blocking repeated offenders, so > there's little difference in theory - although resistance pre-CONNECT may > already exist in some broker implementations. A discussion can be put in > Security Considerations > I agree that a discussion of the pros and cons of this approach would be valuable. I'm not clear on the benefits of using POP keys in TLS handshakes. Can you please point me where to look? > > >> >> 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. >> >> > Indeed, this section was put in for better error handling. Some of these > issues may be resolved with the new MQTT v5.0. > The option of feeding new tokens can be handled here - but, again the > reauthentication approach may help with this issue in MQTT v5. We need to > check MQTT v5 and think a bit more on this. > We need to clarify the draft so that this section is described more > clearly (also to include some of the points Ludwig raised). > I'm still not clear that it isn't simpler and more effective to force the client to reconnect. In MQTT clients and servers are expected to be able to deal with unannounced disconnects. For example, many people use MQTT over 3G connections or other unreliable connections. Thanks for the feedback. Let me know how I can best join in the contribution. Best Paul -- 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
