5 Security (non-normative)

5.1 Introduction

MQTT is a transport protocol specification for message transmission, allowing implementers a choice of network, privacy, authentication and authorization technologies. Since the exact security technologies chosen will be context specific, it is the implementer's responsibility to include the appropriate features as part of their design.

 

MQTT Implementations will likely need to keep pace with an evolving security landscape.

 

This Chapter provides general implementation guidance so as not to restrict choices available and is therefore non-normative. This should not detract from its importance.

 

It is strongly recommended that Server implementations that offer TLS [RFC5246] should use TCP port 8883 (IANA service name: secure-mqtt).

 

There are a number of threats that solution providers should consider. For example:

• Devices could be compromised
• Data at rest in Clients and Servers might be accessible
• Protocol behaviors could have side effects (e.g. “timing attacks”)
• Denial of Service (DoS) attacks
• Communications could be intercepted, altered, re-routed or disclosed
• Injection of spoofed MQTT Control Packets

 

MQTT solutions are often deployed in hostile communication environments. In such cases, implementations will often need to provide mechanisms for:

• Authentication of users and devices
• Authorization of access to Server resources
• Integrity of MQTT Control Packets and application data contained therein
• Privacy of MQTT Control Packets and application data contained therein

 

In addition to technical security issues there could also be geographic (e.g. U.S.-EU Privacy Shield Framework [USEUPRIVSH]), industry specific (e.g. PCI DSS [PCIDSS]) and regulatory considerations (e.g. Sarbanes-Oxley [SARBANES]).

5.2 MQTT solutions: security and certification

An implementation might want to provide conformance with specific industry security standards such as NIST Cyber Security Framework [NISTCSF], PCI-DSS [PCIDSS], FIPS-140-2 [FIPS1402] and NSA Suite B [NSAB].

Guidance on using MQTT within the NIST Cyber Security Framework [NISTCSF] can be found in the MQTT supplemental publication, MQTT and the NIST Framework for Improving Critical Infrastructure Cybersecurity [MQTTNIST]. The use of industry proven, independently verified and certified technologies will help meet compliance requirements.

5.3 Lightweight crytography and constrained devices

Advanced Encryption Standard [AES] is the most widely adopted encryption algorithm. There is hardware support for AES in many processors, but not commonly for embedded processors. The encryption algorithm ChaCha20[CHACHA20] encrypts and decrypts much faster in software, but is not as widely available as AES.

ISO 29192 [ISO29192] makes recommendations for cryptographic primitives specifically tuned to perform on constrained “low end” devices.

5.4 Implementation notes

There are many security concerns to consider when implementing or using MQTT. The following section should not be considered a “check list”.

An implementation might want to achieve some, or all, of the following:

5.4.1 Authentication of Clients by the Server

The CONNECT packet contains User Name and Password fields. Implementations can choose how to make use of the content of these fields. They may provide their own authentication mechanism, use an external authentication system such as LDAP [RFC4511] or OAuth [RFC6749] tokens, or leverage operating system authentication mechanisms.

 

MQTT v5.0 provides an enhanced authentication mechanism as described in section 4.12. Using this requires support for it in both the Client and Server.

 

Implementations passing authentication data in clear text, obfuscating such data elements or requiring no authentication data should be aware this can give rise to Man-in-the-Middle and replay attacks. Section 5.4.5 introduces approaches to ensure data privacy.

 

A Virtual Private Network (VPN) between the Clients and Servers can provide confidence that data is only being received from authorized Clients.

 

Where TLS [RFC5246] is used, TLS Certificates sent from the Client can be used by the Server to authenticate the Client.

 

An implementation might allow for authentication where the credentials are sent in an Application Message from the Client to the Server.

5.4.2 Authorization of Clients by the Server

If a Client has been successfully authenticated, a Server implementation should check that it is authorized before accepting its connection.

 

Authorization may be based on information provided by the Client such as User Name, the hostname/IP address of the Client, or the outcome of authentication mechanisms.

 

In particular, the implementation should check that the Client is authorized to use the Client Identifier as this gives access to the MQTT Session State (described in section 4.1). This authorization check is to protect against the case where one Client, accidentally or maliciously, provides a Client Identifier that is already being used by some other Client.

 

An implementation should provide access controls that take place after CONNECT to restrict the Clients ability to publish to particular Topics or to subscribe using particular Topic Filters. An implementation should consider limiting access to Topic Filters that have broad scope, such as the # Topic Filter.

 

5.4.3 Authentication of the Server by the Client

The MQTT protocol is not trust symmetrical. When using basic authentication, there is no mechanism for the Client to authenticate the Server. Some forms of extended authentication do allow for mutual authentication.

 

Where TLS [RFC5246] is used, TLS Certificates sent from the Server can be used by the Client to authenticate the Server. Implementations providing MQTT service for multiple hostnames from a single IP address should be aware of the Server Name Indication extension to TLS defined in section 3 of [RFC6066].This allows a Client to tell the Server the hostname of the Server it is trying to connect to.

 

An implementation might allow for authentication where the credentials are sent in an Application Message from the Server to the Client. MQTT v5.0 provides an enhanced authentication mechanism as described in section 4.12, which can be used to Authenticate the Server to the Client. Using this requires support for it in both the Client and Server.

 

A VPN between Clients and Servers can provide confidence that Clients are connecting to the intended Server.

5.4.4 Integrity of Application Messages and MQTT Control Packets

Applications can independently include hash values in their Application Messages. This can provide integrity of the contents of Publish packets across the network and at rest.

 

TLS [RFC5246] provides hash algorithms to verify the integrity of data sent over the network.

 

The use of VPNs to connect Clients and Servers can provide integrity of data across the section of the network covered by a VPN.

5.4.5 Privacy of Application Messages and MQTT Control Packets

TLS [RFC5246] can provide encryption of data sent over the network. There are valid TLS cipher suites that include a NULL encryption algorithm that does not encrypt data. To ensure privacy Clients and Servers should avoid these cipher suites.

 

An application might independently encrypt the contents of its Application Messages. This could provide privacy of the Application Message both over the network and at rest. This would not provide privacy for other Properties of the Application Message such as Topic Name.

 

Client and Server implementations can provide encrypted storage for data at rest such as Application Messages stored as part of a Session.

 

The use of VPNs to connect Clients and Servers can provide privacy of data across the section of the network covered by a VPN.

5.4.6 Proof of Delivery of message transmission

Application designers might need to consider appropriate strategies to achieve end to end Proof of Delivery.

5.4.7 Detecting compromise of Clients and Servers

Client and Server implementations using TLS [RFC5246] should provide capabilities to ensure that any TLS certificates provided when initiating a TLS connection are associated with the hostname of the Client connecting or Server being connected to.

 

Client and Server implementations using TLS can choose to provide capabilities to check Certificate Revocation Lists (CRLs[RFC5280]) and Online Certificate Status Protocol (OSCP) [RFC6960] to prevent revoked certificates from being used.

 

Physical deployments might combine tamper-proof hardware with the transmission of specific data in Application Messages. For example, a meter might have an embedded GPS to ensure it is not used in an unauthorized location. [IEEE8021AR] is a standard for implementing mechanisms to authenticate a device’s identity using a cryptographically bound identifier.

5.4.8 Detecting abnormal behaviors

Server implementations might monitor Client behavior to detect potential security incidents. For example:

• Repeated connection attempts
• Repeated authentication attempts
• Abnormal termination of connections
• Topic scanning (attempts to send or subscribe to many topics)
• Sending undeliverable messages (no subscribers to the topics)
• Clients that connect but do not send data

 

Server implementations might close the Network Connection of Clients that breach its security rules.

 

Server implementations detecting unwelcome behavior might implement a dynamic block list based on identifiers such as IP address or Client Identifier.

 

Deployments might use network-level controls (where available) to implement rate limiting or blocking based on IP address or other information.

5.4.9 Handling of Disallowed Unicode code points

Section 1.5.4 describes the Disallowed Unicode code points, which should not be included in a UTF-8 Encoded String. A Client or Server implementation can choose whether to validate that these code points are not used in UTF-8 Encoded Strings such as the Topic Name or Properties.

 

If the Server does not validate the code points in a UTF-8 Encoded String but a subscribing Client does, then a second Client might be able to cause the subscribing Client to close the Network Connection by publishing on a Topic Name or using Properties that contain a Disallowed Unicode code point. This section recommends some steps that can be taken to prevent this problem.

 

A similar problem can occur when the Client validates that the payload matches the Payload Format Indicator and the Server does not.  The considerations and remedies for this are similar to those for handling Disallowed Unicode code points.

5.4.9.1 Considerations for the use of Disallowed Unicode code points

An implementation would normally choose to validate UTF-8 Encoded strings, checking that the Disallowed Unicode code points are not used. This avoids implementation difficulties such as the use of libraries that are sensitive to these code points, it also protects applications from having to process them.

 

Validating that these code points are not used removes some security exposures. There are possible security exploits which use control characters in log files to mask entries in the logs or confuse the tools which process log files.  The Unicode Noncharacters are commonly used as special markers and allowing them into UTF-8 Encoded Strings could permit such exploits. 

5.4.9.2 Interactions between Publishers and Subscribers

The publisher of an Application Message normally expects that the Servers will forward the message to subscribers, and that these subscribers are capable of processing the messages.

These are some conditions under which a publishing Client can cause the subscribing Client to close the Network Connection. Consider a situation where:

• A Client publishes an Application Message using a Topic Name containing one of the Disallowed Unicode code points.
• The publishing Client library allows the Disallowed Unicode code point to be used in a Topic Name rather than rejecting it.
• The publishing Client is authorized to send the publication.
• A subscribing Client is authorized to use a Topic Filter which matches the Topic Name. Note that the Disallowed Unicode code point might occur in a part of the Topic Name matching a wildcard character in the Topic Filter.
• The Server forwards the message to the matching subscriber rather than disconnecting the publisher.
• In this case the subscribing Client might:
  • Close the Network Connection because it does not allow the use of Disallowed Unicode code points, possibly sending a DISCONNECT before doing so.  For QoS 1 and QoS 2 messages this might cause the Server to send the message again, causing the Client to close the Network Connection again.
  • Reject the Application Message by sending a Reason Code greater than or equal to 0x80 in a PUBACK (QoS 1) or PUBREC (QoS 2).
  • Accept the Application Message but fail to process it because it contains one of the Disallowed Unicode code points.
  • Successfully process the Application Message.

 

The potential for the Client to close the Network Connection might go unnoticed until a publisher uses one of the Disallowed Unicode code points.

5.4.9.3 Remedies

If there is a possibility that a Disallowed Unicode code point could be included in a Topic Name or other Properties delivered to a Client, the solution owner can adopt one of the following suggestions:

1. Change the Server implementation to one that rejects UTF-8 Encoded Strings containing a Disallowed Unicode code point either by sending a Reason Code greater than or equal to 0x80 or closing the Network Connection.
2. Change the Client library used by the subscribers to one that tolerates the use of Disallowed Code points. The client can either process or discard messages with UTF-8 Encoded Strings that contain Disallowed Unicode code points so long as it continues the protocol.

5.4.10 Other security considerations

If Client or Server TLS certificates are lost or it is considered that they might be compromised they should be revoked (utilizing CRLs [RFC5280] and/or OSCP [RFC6960]).

 

Client or Server authentication credentials, such as User Name and Password, that are lost or considered compromised should be revoked and/or reissued.

 

In the case of long lasting connections:

• Client and Server implementations using TLS [RFC5246] should allow for session renegotiation to establish new cryptographic parameters (replace session keys, change cipher suites, change authentication credentials).
• Servers may close the Network Connection of Clients and require them to re-authenticate with new credentials.
• Servers may require their Client to reauthenticate periodically using the mechanism described in section 4.12.1.

 

Constrained devices and Clients on constrained networks can make use of TLS [RFC5246] session resumption, in order to reduce the costs of reconnecting TLS [RFC5246] sessions.

 

Clients connected to a Server have a transitive trust relationship with other Clients connected to the same Server and who have authority to publish data on the same topics.

5.4.11 Use of SOCKS

Implementations of Clients should be aware that some environments will require the use of SOCKSv5 [RFC1928] proxies to make outbound Network Connections. Some MQTT implementations could make use of alternative secured tunnels (e.g. SSH) through the use of SOCKS. Where implementations choose to use SOCKS, they should support both anonymous and User Name, Password authenticating SOCKS proxies. In the latter case, implementations should be aware that SOCKS authentication might occur in plain-text and so should avoid using the same credentials for connection to a MQTT Server.

5.4.12 Security profiles

Implementers and solution designers might wish to consider security as a set of profiles which can be applied to the MQTT protocol. An example of a layered security hierarchy is presented below.

 

5.4.12.1 Clear communication profile

When using the clear communication profile, the MQTT protocol runs over an open network with no additional secure communication mechanisms in place.

 

5.4.12.2 Secured network communication profile

When using the secured network communication profile, the MQTT protocol runs over a physical or virtual network which has security controls e.g., VPNs or physically secure network.

 

5.4.12.3 Secured transport profile

When using the secured transport profile, the MQTT protocol runs over a physical or virtual network and using TLS [RFC5246] which provides authentication, integrity and privacy.

 

TLS [RFC5246] Client authentication can be used in addition to – or in place of – MQTT Client authentication as provided by the User Name and Password fields.

5.4.12.4 Industry specific security profiles

It is anticipated that the MQTT protocol will be designed into industry specific application profiles, each defining a threat model and the specific security mechanisms to be used to address these threats. Recommendations for specific security mechanisms will often be taken from existing works including:

 

[NISTCSF] NIST Cyber Security Framework

[NIST7628] NISTIR 7628 Guidelines for Smart Grid Cyber Security

[FIPS1402] Security Requirements for Cryptographic Modules (FIPS PUB 140-2)

[PCIDSS] PCI-DSS Payment Card Industry Data Security Standard

[NSAB] NSA Suite B Cryptography