Ludwig Thanks very much for the quick response and the useful info.
For the first issue, I can see that there is an analogous model to the ACE approach on CoAP. I guess there is a difference with MQTT. In MQTT, for the client to publish to an unsecured topic, they need to CONNECT with no credentials, which many MQTT users would not like. While a DoS attacker could make many CONNECT messages with incorrect credentials, this is something that is already expected from the MQTT server's perspective, and the server can disconnect the connection quickly. In the case where a DoS attacker can connect without credentials, they can simply leave the connection open without publishing, or attempt to publish to other topics, etc, whereby they can use a lot more resources on the server than if they simply try a bad CONNECT packet. This is because of the connection-oriented model of MQTT. As for the second point, I now understand it much better. I will need to think about this in more detail. Best Paul On 8 June 2017 at 13:43, Ludwig Seitz <[email protected]> wrote: > Hello Paul, > > although I'm not one of the authors of this draft, I feel I can help with > the two questions concerning appendices B and C. Please find my comments > inline. Feel free to ask for further clarifications. > > /Ludwig > > On 2017-06-08 12:14, Paul Fremantle wrote: > >> Hi >> >> I would like to make some comments on the draft >> draft-sengul-ace-mqtt-tls-profile-00. >> >> ... > >> 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. >> > As you described in 4), sending the token in the payload of MQTT messages > is challenging. Therefore Appendix B describes a way to submit tokens to > the broker previous to requests (both publish and subscribe). > > Obviously you can overload the broker with fake access tokens using the > authz-info topic, but since all clients (both publishers and subscribers) > will be unauthorized before they first transmit their access token (in > whatever way they do that), the broker has to make a leap of faith to > accept data that might potentially be an access token in some way. I don't > see this way as being more dangerous than any other method of initially > providing an access token to the broker. > > This flow is analogous to what the ACE framework defines, i.e. an > unprotected REST resource "authz-info" to which client can POST their > access tokens. > > > 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. >> > > I think there is a slight misunderstanding in the second part of that > sentence. Appendix C deals with the situation where a client's token has > either expired or otherwise become invalid and the broker whishes to inform > the client of this situation. I was told that there is currently no message > defined in MQTT for signaling a broker side disconnect to the client. This > was created as a workaround to that problem. > Furthermore the proposal in Appendix C deals with cases where a client has > a successful connection and a valid token, but whishes to submit an > additional token granting further access rights. > > > -- > Ludwig Seitz, PhD > Security Lab, RISE SICS > Phone +46(0)70-349 92 51 > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace > -- 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
