7 Security

7.1 Introduction

The MQTT servers authenticate the clients (both CSEs and AEs) that connect to them and authorize access to Topics used to communicate. The clients do not authenticate each other, instead they use the MQTT server to do this.

Background. The MQTT binding makes use of one or more MQTT Servers to transport messages between AEs and CSEs (or between CSEs) as described in clause 5. The AE/CSEs both act as MQTT Clients of an MQTT Server that mediates delivery of messages between the two. As described in clause 6, the topic in the MQTT PUBLISH packet either indicates the Originator's identity and Receiver's identity, or includes the Originator's Credential and the Receiver's Identity (in the case that the Originator has not yet been assigned an identifier).

Trust and the MQTT Server. When the oneM2M binding to MQTT is used, some security functions are performed by the MQTT Server, as described further in this clause. In particular:

  1. The MQTT Server authenticates the AEs and CSEs as they connect as MQTT Clients. These MQTT Clients themselves never directly authenticate the CSE or AE that is using another MQTT Client - instead they trust the MQTT Server to authenticate the MQTT Clients, and trust the MQTT Server to route the messages between the Originator and Receiver indicated in the topic.
  2. The MQTT Server enforces access control policies to ensure that unidentified or unauthorized clients are not able to publish messages to oneM2M topics or subscribe to receive messages from them.

The remainder of clause 7 concerns Authentication and Authorization when the MQTT protocol binding is being used for the Mca or Mcc reference points. Details of Authentication and Authorization over the Mcc' reference point need to be agreed between the relevant service providers.

7.2 Authorization

There are two levels of authorization in the oneM2M binding to MQTT.

  • The MQTT Server is responsible for verifying identifiers, for routing messages to the expected CSE or AE, and providing the correct Credential-ID during initial registration

    The MQTT Server is responsible for verifying that the Client Identifier field in a MQTT CONNECT packet matches the expected AE-ID, CSE-ID or Credential-ID.

    The MQTT Server is responsible for controlling those topics to which an MQTT Client may subscribe and receive published MQTT packets, and those topics to which an MQTT Client may publish MQTT packets.

    Since the topic includes the Receiver's CSE-ID, the Originator can trust that the MQTT packets are routed to and from the expected Receiver. If the topic includes the Originator's CSE-ID or AE-ID, then the Receiver can trust that the MQTT packets are routed to and from the expected Originator.

    If the topic includes the Originator's Credential-ID (which should only occur at initial registration), then the Receiver can use this Credential-ID to determine the CSE-ID or AE-ID or list of allowed AE-ID(s) which are to be used in assigning a CSE-ID or AE-ID to the Originator (as described in TS-0003 [7]). This Credential-ID can be trusted to have been verified by the MQTT Server.

  • The Receiver is responsible for authorizing requests to specific resources, and assigning CSE-ID or AE-ID during initial registration.

    When the MQTT topic includes the Originator's CSE-ID or AE-ID, then the Receiver is responsible for making access control decisions on requests to perform operations on specific resources hosted on the Receiver. The access control decisions are dictated by the applicable accessControlPolicy resources and the Originator's CSE-ID or AE-ID (and other factors not relevant to the present discussion). This authorization process is as defined in the Architecture Specification [2], the Core Protocol Specification [3] and Security Solutions specification [7].

    When the MQTT topic includes the Originator's Credential-ID (which should only occur at initial registration), then the Receiver is responsible for assigning a CSE-ID or AE-ID to the Originator (which may be dependent on the Originator's Credential-ID).

7.3 Authentication

An MQTT Client and MQTT Server shall apply Transport Layer Security (TLS) using any of the Security Association Establishment Frameworks in TS-0003 [7].

The Security Association Establishment Frameworks provide mutual authentication of the MQTT Client and MQTT Server. The Security Association Establishment Frameworks are described using two main entities Entity A and Entity B: in the case of the oneM2M binding to MQTT, Entity A is a CSE or AE using an MQTT Client, and Entity B is an MQTT Server.

NOTE: In TS-0003 [7], Entity A is described as establishing the CSE-ID of Entity B as a result of Security Association Establishment. The application to MQTT differs because Entity A establishes the identity of the MQTT Server instead. However, the procedures are still applicable.

The Remote Security Provision Frameworks in TS-0003 [7] may be applied to provision a symmetric key shared by a CSE/AE using an MQTT Client and an MQTT Server, with the MQTT Server assuming the role of the Enrolment Target.

Identification of Originator and Receiver. TS-0003 [7] describes a variety of approaches by which successful Security Association Establishment results in Entity B determining the CSE-ID or AE-ID or list of allowed AE-ID(s) for the CSE/AE using the Entity A. These approaches can also be used in the oneM2M binding to MQTT.

It is assumed that the MQTT Server is configured with the information necessary to determine the CSE-ID of the Receiver following successful Security Association Establishment with the Receiver's MQTT Client.

In some scenarios, the MQTT Server can be configured with appropriate information to verify the CSE-ID or AE-ID of the Originator. However, in cases where the Originator has not yet been assigned its CSE-ID or AE-ID, and the MQTT Server has also not been provided with the CSE-ID or AE-ID of the Originator, then the Receiver is responsible for determining the applicable CSE-ID or AE-ID. In these cases, the MQTT Server forms a Credential-ID, identifying the Credential used to authenticate the Originator, and includes this in the topic when forwarding to the initial registration request to the Receiver's MQTT Client. The Receiver extracts the Credential-ID, and the procedures in TS-0004 [3] and TS-0003 [7] determine the CSE-ID or AE-ID of the Originator.

Password Field Authentication . The present document does not specify use of the password field of the MQTT CONNECT control packet. Authentication is performed using the TLS mechanisms described in TS-0003 [7].

7.4 Authorization by the MQTT Server

This procedure describes how an MQTT Server authorizes topics to which an MQTT Client may subscribe. The M2M Service Provider is responsible for configuring the MQTT Server with the relevant information used in these authorization decisions:

  1. In the case that the MQTT Server determines that the MQTT Client represents a CSE, and if the CSE has been assigned a CSE's SP-Relative-CSE-ID (which is denoted by ), then:
      1. the MQTT Server authorizes the MQTT Client to subscribe to the topic /oneM2M/req/+/
      1. for the set of
      1. if this CSE is registered to a CSE and the SP-Relative-CSE-ID of this CSE is then the MQTT Server authorizes the MQTT Client to perform the following:
        1. to subscribe to:
        /oneM2M/resp/
        1. to publish to:
        /oneM2M/resp/
  2. In the case that the MQTT Server determines that the MQTT Client represents an AE which has been assigned an S-Type AE-ID Stem equal to < AE-ID-Stem>, then:
      1. If the MQTT Server determines that the AE is currently registered, and the AE's Registrar CSE has SP-Relative-CSE-ID equal to then the MQTT Server authorizes the MQTT Client to perform the following:
        1. to subscribe to /oneM2M/resp/
        1. to publish to /oneM2M/req/
        1. to subscribe to /oneM2M/req/
        1. to publish to /oneM2M/resp/
      1. Otherwise, the MQTT Server authorizes the MQTT Client to perform the following:
        1. to subscribe to /oneM2M/reg_resp/
        1. to publish to /oneM2M/reg_req/
      where [7].
  3. In the case that the MQTT Server determines that the MQTT Client represents a AE with C-Type AE-ID-Stem equal to
      1. to subscribe to /oneM2M/resp/
      1. to publish to /oneM2M/req/
      1. to subscribe to /oneM2M/req/
      1. to publish to /oneM2M/resp/
  4. In all other cases, the MQTT Server authorizes the MQTT Client to perform the following:
      1. to subscribe to /oneM2M/reg_resp/
      1. to publish to /oneM2M/reg_req/

where is obtained from the Security Association Establishment procedure as described in TS-0003 [7].

7.5 General Considerations

Implementors should take note of the Security considerations listed in chapter 5 of the MQTT Specification [1].