> > > [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. > > >
[CS] I added some text to the v04 of the document to explain the reasons behind having clean session. However, I am wondering whether MUST is too strong, and whether to opt for SHOULD, and make other SHOULDs on broker behaviour i.e., 1) Session state includes information of the token used in the session. 2) There is a MAX session expiry set by the broker admin policy allowing capping what the client puts for session expiry. 3) The client still submits a token in every CONNECT - the broker checks if the token matches the current token (may or may not introspect in case of a token match); if new token, validate token, replace the session token. 4) Session state is updated: Subscription Identifiers, that are part of the session state, validated if new permissions. (Although it will do this anyway when publishing a packet to the subscriber. ) Pending messages are re-evaluated based on permissions. > > > > 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> > > > [CS] I seem to recall a reauthentication discussion in the interim, but now, thinking again do not see why that was an issue. Thanks, -Cigdem
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace