Reauthentication messages need to be defined

[jimsch]

I am not positive that I know the correct sequence for doing a re-authentication. The message I sent recently just sent a token in the first message, but in my code comments it is talking about both a token and a nonce. Should be documented.

[ciseng]

Yes, needs to be clarified. As discussed in the interim, re-authentication should only use the challenge-response method as TLS-EXPORTER returns the same value for the same label; and would want to be re-used.

[ciseng]

Also, the question is should the broker accept AUTH message with reason code re-authentication, if the CONNECT message did not contain a token.

MQTT allows clients to send AUTH and DISCONNECT after CONNECT (From MQTT v5 Spec: If a Client sets an Authentication Method in the CONNECT, the Client MUST NOT send any packets other than AUTH or DISCONNECT packets until it has received a CONNACK packet [MQTT-3.1.2-30].).

The server is allowed to only process AUTH messages before sending a CONNACK. (From MQTT v5 spec: If the Server rejects the CONNECT, it MUST NOT process any data sent by the Client after the CONNECT packet except AUTH packets).

But. it does not say it MUST process AUTH packets.

I am in favour of saying: The Client SHOULD not send AUTH messages (e.g., with reason code reauthentication) after CONNECT and before CONNACK. As it is, at least to me, uncertain that the server will always process an AUTH before responding to CONNECT.

So, the first token SHOULD be transported using one of the methods described in 2.2.2 or 2.2.3.

If the client does that, since re-authentication flow triggers the token validation flow, the server MAY still be able to accept the connection. The token validation flow for re-authentication MUST be the challenge/response flow.

[jimsch]

The only requirement for re-authentication is that a) some authentication has been done according to the spec and b) the authentication method cannot change. The client can send a new AUTH message to do re-authentication any point in time after the CONNACK has been received. If we define method "ace" with no authentication data as forcing a CONNACK w/ failure then what I originally suggested cannot happen because of the CONNACK failure. However, if a client gets a new/updated token it wants to be able to re-authenticate and continue operating so that needs to be covered.

[ciseng]

Added the following to Section 4: Token Expiration and Reauthentication Section: "The Client MUST have used challenge-response PoP as defined in Section 4 and MUST use the same method for re-authentication. The Broker accepts re-authentication requests if the Client has already submitted a token (may be expired) and validated via challenge-response. Otherwise, the Broker MUST deny the request."

Moved to AS discovery section under the Broker's Response to Client Connection Request - clarified that it can be sent when the Client does not provide a valid token (includes omitting the Authentication Data). Added:

"The Broker MUST NOT process any data sent by the Client after the CONNECT packet including AUTH packets (Note that this is different in MQTT v5, the Broker is allowed to process AUTH packets even if the Broker rejects the CONNECT)."

This is to avoid cases when the client does not send a CONNECT with a valid token, but then does AUTH with reauthentication with a valid token.

[ciseng]

Discussed in 108 WG meeting: The text introduced is fine.