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. > > > > 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. Thanks, -Cigdem > > > > Jim > >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
