This is the multi-page printable view of this section. Click here to print.
The main goal of SMOKER is it, to provide an easy and anonymous way for clients to authenticate themselves at a broker and provide a possibility to set up authorization rules at topic level. The claims are managed exclusively by the clients by claiming/unclaiming them. The broker only has to take care of the secure storage of claims and the enforcement of their rules for MQTT publish/subscribe activities.
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.
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.
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.
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:
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.
The following figure shows a successful and unsuccessful MQTT session establishment using the SMOKER authentication method:
CONNECT packet with 'SMOKER' set as authentication method and the base32 (incl. padding) encoded public key.AUTH packet containing a unique 32 byte nonce.AUTH packet.CONNACK packet which accepts or denies the connection.Authenticated parties are allowed to claim topics and authorize other clients to subscribe or publish on the claimed resource. Such a claim is fully client-managed – only the initiator can ever change or delete the claim again. If an authenticated client wants to subscribe or publish on a claimed topic, the broker must decide whether this is permitted or not on the basis of the available claims made by the clients.
An attacker could manipulate the data source of the broker where claims are stored. Therefore, several precautions must be taken in order to ensure the attacker is not able to manipulate data to its favor.
The broker must have the possibility to verify that a claim was not modified since creation. Therefore, the client must provide a signature of the given claim at creation time. The signature must be created with the secret counterpart of the clients public key that acts as clientID in the authenticated MQTT session. This allows the broker to verify a claim is valid when it evaluates it for further processing. If verification fails, the claim record must be considered compromised and may not further be used.
The restricted area is a dedicated branch within the tree of topics. The topic to be claimed, must start with a predefined segment followed by the clientID and the effective topic name (e.g. restricted/{clientID}/temperature). This implicitly creates a dedicated client space, which can only be managed by the clientID present in the topic name.
Any user with access to the claim store could possibly modify an existing claim, and enter itself as the owner and use its self-calculated valid signature. The steal of the claim would allow it to listen to the communication on the topic without anyone ever noticing it. In order to prevent this, the clientID must be present in the topic name which has to be claimed. If this is not the case, the claim has to be considered to be invalid by the broker. This ensures that the relationship between signature, the owners’ clientID and the topic name, is always upright.
Any authenticated client is allowed to claim topics. A client can theoretically claim topics for itself at arbitrary intervals. Fortunately, MQTT does not allow to publish on wildcard topics. This prevents claiming wide topic ranges within one claim.
If the implementation of the persistence logic within the broker includes direct I/O access, it can lead to enormous loss of performance or even end up in a server crash. This problem is not solved by the SMOKER protocol and must be solved when implementing the claim store.
A client can basically use the following SMOKER interactions:
The following figure visualizes a successful sequence of a topic claim. This example is used for the subsequent definitions on client and broker side.
The client initiates a topic claim by publishing a claim to a predefined system topic. This message must be published with QoS 1 as the broker submits feedback information within the PUBACK packet.
The claiming payload sent by the client, is classified as a whitelist or blacklist and contains a restriction. A restriction must contain at least one or more authorization rules consisting of the targeting topic, and a set of rules for read (subscribe) and write (publish) actions. All containing rules are implicitly interpreted with the allow (whitelist) or deny (blacklist) operator based on the classification. Rules can be defined for all (wildcard *) or specific clientID’s. If a client gets whitelisted on a topic, all other clients automatically get blacklisted and vice versa. The only exception is the owner itself, which is always guaranteed to have full access to all topics owned by it. In case a client only wants to authorize specific clients, it must know their clientID’s.
Further, the client must provide a signature of the restriction within the claim. As the client is fully responsible for his claims it needs to make sure that claims can not be manipulated by anyone else. Therefore, it’s evident that the restriction which is provided to the broker must be signed with the clients private key. Thus, the broker is able to verify that the restriction it is looking up is not compromised.
The fully detailed structure of claims is described in the API docs.
Updates of claims are only accepted by the owner itself. An update can be triggered by publishing a new version of the claim on the same topic. The broker must then completely replace the previous claim with the new one.
Deletions of claims are only accepted by the owner itself. If a client wants to unclaim a topic, this must be achieved by publishing the concerned topic name within the payload of the message on a specific unclaim topic.
A client can publish and subscribe to any topic he wants to. If the topic is within the restricted area, the SMOKER topic validation on the broker must kick in and decide whether the client is allowed to perform the activity or not.
A client is basically allowed to subscribe any wildcard topic. Such subscriptions may also include resources where access to the subscribing client is not granted by the claim owner. However, the client may only receive messages it is allowed to.
For each incoming claim configuration, the broker must perform various validations to complete the topic claim. If the validation fails, the broker returns a 0x99 Payload format invalid reason code within the PUBACK packet. This can happen if at least one following cases occur:
+ or #)If the validation succeeds, the broker must store the claim and its corresponding signature. This store must be accessible throughout different sessions.
The broker must check for each incoming publish or subscribe activity whether the underlying client has permission to do so or not. This decision must be based on the persisted claims already submitted by other clients or the requesting client itself. A successful subscription is visualized in the figure below:
Before the broker can evaluate a specific claim, it needs to check its integrity with various validation rules. If one of the validation rules fails it must be assumed that the claim is compromised and can not be used for further evaluation. In this case the broker must return the 0x83 Implementation specific error reason code. The following rules must be validated:
If the integrity check succeeds, the requested action will be allowed or denied based on the given claim permission. For allowed subscriptions, no further work is necessary on the broker side. An allowed publish messages gets enqueued on the broker to be delivered to authorized clients.
Because of the following reasons it may be mandatory to perform further security checks for any outbound message.
The broker must accept wildcard subscriptions by clients without considering any permissions. If a publish message, matches a clients’ wildcard subscription, the broker must evaluate whether the client is allowed to receive this message or not. If it’s not, the message delivery must be discarded. Otherwise, the message is delivered as usual.
As claims are client-managed, they can be updated at any time. This may cause an authorized subscription, to become deprecated. It is a decision of the broker implementation whether permissions have to be enforced immediately or not – with the acceptance of the respective consequences.
Every cryptographic operation of SMOKER is using the Edwards-curve Digital Signature Algorithm (EdDSA). EdDSA is a digital signature scheme using a variant of Schnorr signature based on Twisted Edwards curves. It is designed to be faster than existing digital signature schemes without sacrificing security.