Thanks Paul, I will be responding to your comments soon (away from my desk at rsac unplugged today :) )
And thanks Ludwig, for offering clarifications. Later, --Cigdem On Thursday, June 8, 2017, 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 >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
