>
>
> [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
