[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: çå: [mqtt-comment] [mqtt-security] Security Suggestions on MQTT Authorization
If I may:
The Will message is accepted at the time it is set. That act of acceptance grants the permission for it to be delivered at a later time. The key MQTT 5.0 spec sentence is in 3.1.3.2.2 âThe Server
delays publishing the Clientâs Will Message until the Will Delay Interval has passed or the Session ends, whichever happens firstâ. That implies that the server has accepted it and will deliver it later, at its discretion. With that, the client is out of the
picture.
A retained message is accepted at the time it is set and becomes part of the topic state. The MQTT 5.0 spec states in 3.3.1.3 âWhen a new Nonâshared
Subscription is made, the last retained message, if any, on each matching topic name is sent to the Client as directed by the Retain Handling Subscription Optionâ â which is an act by the server that is independent of who sent that message and a relationship
to the sender is not maintained.
The specification does not mandate any particular authorization method. Itâs legitimate, and this is how I would implement it, to enforce an authorization check when a session is being recovered.
Itâs also legitimate to cut an existing connection when the access control rule is changed or an access token expires, and Iâm aware of brokers who do that. Thatâs not a vulnerability in the spec, because the spec doesnât take a stance.
From: mqtt-comment@lists.oasis-open.org <mqtt-comment@lists.oasis-open.org>
On Behalf Of Jia, Yan This wiki link maybe helpful for understanding such kind of problem. It's called "time of check to time of use". https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use Yan JIA åää: Bird, Rob <rbird@akamai.com> Wouldnât this then be true for
any delivery delay+ACL change race condition? For example:
It seems that aside from the âwillâ message case (where publication is actually initiated after the ACL change) that the others (including the one I list above) would imply requiring
generically that all MQTT ACLs are implemented (at least) as delivery-side guarantees. This issue would appear to raise potential philosophical questions. From: <mqtt-comment@lists.oasis-open.org> on behalf of "Jia, Yan" <yj15@iu.edu> Thanks for your response. That's the point. And I believe , in some scenarios, these issues will pose practical security risks.
I will track this issue on this mailing list and the MQTT issue system. We
are happy to address the issues with TC. Best Regrads, Yan JIA åää: Ken Borgendale <kwb@us.ibm.com> Thank you for you comment. I have forwarded it on to the full mqtt TC mailing list as many TC members do not monitor the mqtt-comment list. I have created this as issue NQTT-536
in the MQTT TC issue system. https://issues.oasis-open.org/projects/MQTT/issues/MQTT-536
Note that the MQTT TC has not been very active since the publication of MQTTv5.0.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]