Hello Paul, Again, thank you very much for your comments. 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.
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. > 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). > > 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. > 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. > > 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. > > 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. > > 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). 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! > > Not at all, we wholeheartedly appreciate the response & opportunity for discussion! Thanks, Cigdem and Anthony
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
