Subject: [Ace] Comments on the MQTT draft

From: Jim Schaad <[email-masked]>
Date: Sun, 8 Mar 2020 12:03:56 -0700

1.  I want to verify that the following is the desired statement:  There is
a strong preference that TLS not use PSK for authentication.  This follows
from the recommendation to use TLS:Anon-MQTT:ace for the authentication
option.  I have no problems with this statement, I just want to be sure that
the group as a whole is ok with this position.   I found that I implemented
the SHOULD NOT option for PSK to start with, but that is because I was
trying to be completist not because I think the position is wrong.

2.  While implementing I found that there did not appear to be a mandatory
to implement validation algorithm, one needs to be specified.

3.  After reading the log of bugs which have been showing up on the MQTT
code base that I have been using, I think there needs to be text put into
the document to deal with the clean session requirement that this profile is
enforcing.  I am seeing a lot of people who are relying on the fact they are
not reconnecting with clean session to get QoS information back from the
server in the event of unexpected disconnects.

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.  

Jim

---

From: Cigdem Sengul <[email-masked]>
Date: Sun, 8 Mar 2020 22:29:32 +0000

Hello Jim,

Comments inline.

> trying to be completist not because I think the position is wrong.

To tell the truth, I've put the RECOMMENDED as I believed it was expected
that I provide a recommendation.
Otherwise, any of the methods are OK (with some exceptions for anon:anon,
and over authenticating/authorising with the last mode).

> to implement validation algorithm, one needs to be specified.

Do you mean mandatory-to-implement certificate validation policy?

> server in the event of unexpected disconnects.

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.

Session State in the Server consists of:

·         The existence of a Session, even if the rest of the Session State
is empty.

·         The Clients subscriptions, including any Subscription Identifiers.

·         QoS 1 and QoS 2 messages which have been sent to the Client, but
have not been completely acknowledged.

·         QoS 1 and QoS 2 messages pending transmission to the Client and
OPTIONALLY QoS 0 messages pending transmission to the Client.

The Session Expiry is also set by the client:

When a client connects with a long Session Expiry Interval, it is
requesting that the Server maintain its MQTT session state after it
disconnects for an extended period. Clients should only connect with a long
Session Expiry Interval if they intend to reconnect to the Server at some
later point in time. When a client has determined that it has no further
use for the Session it should disconnect with a Session Expiry Interval set
to 0.

---

From: Jim Schaad <[email-masked]>
Date: Sun, 8 Mar 2020 17:08:56 -0700

From: Cigdem Sengul <[email-masked]> 
Sent: Sunday, March 8, 2020 3:30 PM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; Ace Wg <[email-masked]>
Subject: Re: Comments on the MQTT draft

Hello Jim,

Comments inline.

On Sun, Mar 8, 2020 at 7:04 PM Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

To tell the truth, I've put the RECOMMENDED as I believed it was expected that I provide a recommendation. 

Otherwise, any of the methods are OK (with some exceptions for anon:anon, and over authenticating/authorising with the last mode).  

[JLS]  I approve of having a recommended method, that is one which everybody will implemented, I just want to ensure people think this is the right one.

[JLS]  What cryptographic algorithm is used to implement the hash/signature for the two authentication methods – it can be the same for both.

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 existence of a Session, even if the rest of the Session State is empty.

*         The Clients subscriptions, including any Subscription Identifiers.

*         QoS 1 and QoS 2 messages which have been sent to the Client, but have not been completely acknowledged.

*         QoS 1 and QoS 2 messages pending transmission to the Client and OPTIONALLY QoS 0 messages pending transmission to the Client.

When a client connects with a long Session Expiry Interval, it is requesting that the Server maintain its MQTT session state after it disconnects for an extended period. Clients should only connect with a long Session Expiry Interval if they intend to reconnect to the Server at some later point in time. When a client has determined that it has no further use for the Session it should disconnect with a Session Expiry Interval set to 0.  

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

Jim

---

From: Cigdem Sengul <[email-masked]>
Date: Mon, 9 Mar 2020 12:35:23 +0000

Hello Jim,
Comments inline.

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

> 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

---

From: Jim Schaad <[email-masked]>
Date: Mon, 9 Mar 2020 09:12:00 -0700

Sent: Monday, March 9, 2020 5:35 AM

Hello Jim,

Comments inline.

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

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

---

From: Cigdem Sengul <[email-masked]>
Date: Tue, 10 Mar 2020 10:39:42 +0000

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

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