Thank you Dominik for your review of the draft. We mentioned in the virtual interim that we approached to OASIS MQTT TC for reviewers; Dominik kindly agreed to review our draft.
Indeed, the PINGREQs were not included for checking token expiry as they do not signal a token (like CONNECT) or topic permissions (like PUBLISH/SUBSCRIBE). But, your suggestion would be a very useful optimization for early detection of token expiry. As Anthony said, we will add it to the draft (possibly as a SHOULD). Very glad to hear that your ongoing project is in agreement with the draft. It would be very useful to get input from your deployment experience. Sincerely, --Cigdem On Wed, Nov 8, 2017 at 1:34 PM, Anthony Kirby <[email protected]> wrote: > Hi Dominik, > many thanks for the review! It's appreciated. > > We didn't initially consider the keepalive / PINGREQ, because we'd seen it > as (effectively) a lower layer issue. But I understand value of using it > as an opportunity to check for token expiry: Even if it happens > frequently, each check will be a low cost for the broker. Thank you for > the suggestion, I'll add it to the draft. > > Thinking aloud, it might not be straightforward to implement this when > extending an existing broker (for example the mosquitto auth plugin) so I > expect it would be a SHOULD rather than a MUST. > > Anthony > > > ________________________________________ > From: Ace <[email protected]> on behalf of Dominik Obermaier < > [email protected]> > Sent: 07 November 2017 21:29 > To: [email protected] > Subject: [Ace] MQTT-TLS profile of ACE > > All, > > I had the opportunity to review the MQTT-TLS profile for ACE [1] and > I’d like to share my thoughts with this list. > > > The document at hand proposed that token expiry checks take place on > PUBLISH, SUBSCRIBE or CONNECT actions. I’d like to note that it might > be worthwhile to have the token expiry checks for PINGREQ packets in > order to make sure that “sleeping” MQTT clients which do not send > PUBLISH or SUBSCRIBE packets can get disconnected at the next possible > client interaction with the broker. > > On a sidenote: In a recent MQTT project with millions of constrained and > untrusted devices (connected via unreliable communication channels), an > almost identical approach as proposed in the draft was implemented. The > authentication and authorization was implemented exactly as described in > this document with the use of the Introspection API and “offline > validation” of JWTs. So I can confirm that the approach proposed is > actually usable at scale and works very well with some existing MQTT > brokers. > > All the best, > Dominik > > [1] https://www.ietf.org/id/draft-sengul-ace-mqtt-tls-profile-01.txt > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
