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
