From: Cigdem Sengul <cigdem.sen...@gmail.com> Sent: Monday, March 9, 2020 5:35 AM To: Jim Schaad <i...@augustcellars.com> Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg <ace@ietf.org> Subject: Re: Comments on the MQTT draft Hello Jim, Comments inline. Yes, I can see this can be problematic but this was to avoid the broker keeping state for clients that are no more authorised to receive those messages. The session state can include actual messages if QoS>=1, so maybe high overhead. The Session Expiry is also set by the client: [JLS] All of that makes a great deal of sense to me. What if a session expires when a token expires independent of the client’s request for a long session expiry interval. After all, if the token is the identity then if the token expires you can no longer prove you are the same person and thus can have the same session back. You probably need some weasel text about allowing for an expired session to get a new token if it is kept open perhaps, but I have not looked exactly when a connection would be forced closed due to token expiration yet. [CS] Yes. We opted for not keeping any state because that indeed had too many problematic issues. One was, as I already mentioned, extra state kept for a time determined by the client (session expiry) - which we thought would cause trouble. There are some non-normative text in MQTT spec about how the server storage limits or admin policies can overwrite client-set expiry. The other issue is that the broker checks existing session with the (MQTT) Client Identifier. This info is not burned into the token (note that this client id is different than ACE client id used for e.g., authenticating to AS) So, I feel that is problematic as well... So, there is a security-qos trade-off. [JLS] I was planning to put a pointer to the token into my session state so that it could be checked. However, as I stated in the original. This needs to be justified one way or the other in the document. 4. I keep going back and forth on a recommendation that we channel bind in the challenge response case. I don't have the knowledge to be able to do a formal proof, but I think that all of necessary conditions are going to be met without it. However, having the binding included would most likely make the proofs that much easier. [CS] I am confused about this as well. Because, as we discussed in the interim meeting, the exporter-based flow only works at the connection time, and not for reauthentication (that is why we kept the challenge/response flow). I am aiming to submit the v04 - but I will probably need to submit v05 to clarify all this. [JLS]] You can do the exporter at any time. I was thinking in terms of signing the triple of <server challenge, client challenge, tls-exporter value> Thanks, -Cigdem Jim
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
