Authentication

Concept of the enhanced authentication flow

SMOKER authentication completely voids session hijacking for the MQTT protocol and provides authenticity without the need for any network security nor channel security. The broker does not require to keep any secrets for session handling. Moreover, it allows the clientID, which represents the identification for a session, to be publicly known. The presented approach allows completely anonymous but authentic sessions, hence the broker does not need any priory knowledge of the client party. As it is especially targeted for applications within the world of IoT, SMOKER is designed to require only the minimum in extra power in terms of energy and space. SMOKER does not define any new concept, but simply combines a state of the art cryptographic signature scheme with the existing MQTT 5.0 specification. Thus, no protocol extension is required in order to provide the targeted security properties. The described approach is completely agnostic to the application layer at the client side and is only required during MQTT session establishment.

MQTT Enhanced Authentication

The MQTT CONNECT packet supports basic authentication of a network connection using the username and password fields. While these fields are named for a simple password authentication, they can be used to carry other forms of authentication such as passing a token as the password.

Enhanced authentication extends this basic authentication to include challenge / response style authentication. It might involve the exchange of AUTH packets between the Client and the Server after the CONNECT and before the CONNACK packets.

SMOKER uses this challenge / response authentication flow as the client needs to be able to retrieve authentication data from the broker while connection establishment.

Client ID

As the SMOKER protocol uses a (base32 encoded) representation of a EdDSA public key for the MQTT client ID, this key-pair must be generated before the connection can be established. Depending on the use case, the client could also generate a new key-pair for every connection. Base32 is used to fit the public key into the allowed character set specified by the MQTT protocol itself.

An example how a valid client ID looks like:

T5LKBKSPOWU43HVKN7ZCB54VQB2ZVR3ZOQRV6EZSDDF5JX4HX4SQ====

Note that the clientId must be encoded with padding.

Client ID collisions

It is possible that clients, even without SMOKER authentication, connect with a client ID that is already used by an authenticated client. The default behavior of most brokers is that the already connected client is disconnected, and the new client is accepted. In such a case, when implementing a SMOKER extension for a broker, it is mandatory to ensure that the already connected client does not get disconnected. One of the following treatments should be implemented:

  1. The broker accepts the connection but assigns a new unique clientId to the connecting client.
  2. The broker denies the connection with a 0x85 Client Identifier not valid or 0x87 Not authorized reason code and a corresponding message.

If a client connects with a clientId already assigned by the broker but can prove its authenticity using the SMOKER protocol, the client should be accepted and for the already connected client the default behavior of the broker should be applied.

Establish a connection

The following figure shows a successful and unsuccessful MQTT session establishment using the SMOKER authentication method:

Successful and unsuccessful MQTT session establishment using the SMOKER authentication method.

  1. The client starts the connection establishment by sending a CONNECT packet with 'SMOKER' set as authentication method and the base32 (incl. padding) encoded public key.
  2. The broker responds with a AUTH packet containing a unique 32 byte nonce.
  3. The client must sign this message with his already generated private key which is the counter part of the public key used as client id in the MQTT session. The signed message is sent back to the broker within a AUTH packet.
  4. The broker verifies the received signature and responds with a CONNACK packet which accepts or denies the connection.
Last modified May 30, 2021