Client Identifier - clarify its use

[ciseng]

In Figure 2, I think the use of Client Identifier is somewhat confusing. I think this is supposed to be the token as the Client Identifier is a different thing in MQTT. Either that or you need to do a better job of describing the property block.

I am worried about the text on the Client Identifier in this section. It is not clear to me that having the client generate a random value for this field is good just in terms of the possibility of collisions occurring on the server. The text in the MQTT 5.0 document appears to say that this is more interesting for the situation of getting back state that was left on the server after a disconnect and not so much for a clean session.

[ciseng]

Section 2.1.2.1 - I am having a problem computing the MAC over the payload of the CONNECT message. The password where the value is placed is included in the payload and I am not clear if it should be computed up to that value or if a fixed value should be used for the computation.

OK. I think it got muddled because I was trying to find a solution for a scenario where the ClientId is used across sessions, and hence, not random.

Two cases. 1) Client ID uniquely random across each Client connection attempt to Broker: MAC over Payload - Payload begins with ClientID and MAY include Will Properties if Client indicated that it will have a will. 2) Client ID NOT uniquely random: MAC over Authentication Data.

It may be best to choose one method and just say MUST always have a nonce in Authentication Data, and MAC is computed over that?

[ciseng]

12. I don't know where the nonce in this section is coming from. Discussion on where it comes from and where it is passed in the protocol is needed.

    As explained in 10. Will clarify in text.

[ciseng]

JLS] Lets step back and look at the problem I think you are trying to solve.

If you are trying to make sure that there is not a replay of the signature, then this would require that the server keep track of the list of nonce values that the client has provided. If you are trying to make sure that the signature is “fresh” then the server would need to be able to provide some type of data as part of the value being signed. As I think I have said before the latter can be satisfied by getting your nonce value from the TLS session using a tls-exporter.

If neither of these problems is trying to be solved, then there is no need for the nonce at all.

[CS] Thanks, taking that step back helped. It is the latter problem we are trying to solve. Then tls-exporter would indeed work and simplify the descriptions for MQTT v5 and v3.1.1., as there was a question on where the nonce was placed in v3.1.1.

[anthonykirby]

I started trying to understand this, but got lost at the tls-exporter bit. While parsing it, I noticed a couple of typos & ended up rewriting as:

The CONNECT payload has at least a Client Identifier, and if the Will Flag is set to 1,
  may contain Will-related information. The Client Identifier MUST be a UTF-8 Encoded String
  (i.e., is prefixed with a two-byte integer length field that gives the number of
bytes in a UTF-8 encoded string itself). The Client Identifier MUST be 1-23 UTF-8 encoded bytes,
and contain only the characters "0-9a-zA-Z".
Note that this is a subset of the MQTTv5 standard, which allows longer Client Identifiers
and characters not included in the list above.

[ciseng]

This section will have to change completely, and Client Identifier will not be used, rather a nonce from the TLS-Exporter will be used from the TLS session.

[ciseng]

Removed mention of the Client Identifier as nonce, still need to fix the nonce coming from the TLS-exporter bit.

[ciseng]

Added tls-exporter references for getting the nonce from the tls session.