Uploaded image for project: 'OASIS Message Queuing Telemetry Transport (MQTT) TC'
  1. OASIS Message Queuing Telemetry Transport (MQTT) TC
  2. MQTT-293

Recommendations for securing an MQTT server

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 5
    • Fix Version/s: wd07
    • Component/s: core
    • Labels:
      None
    • Proposal:
      Hide

      A. Add a new section 1.6 and renumber the existing 1.6 to become 1.7. The new section to say

      "1.6 Security

      MQTT client and server implementations SHOULD offer Authentication, Authorization and secure communications options, such as those discussed in Chapter 5. Applications concerned with critical infrastructure, personally identifiable information, or other personal or sensitive information are strongly advised to use these security capabilities."

      B. Replace Step of 3.1.4 Connect / Response.

      Existing Text:
      "The Server MAY check that the contents of the CONNECT Packet meet any further restrictions and MAY perform authentication and authorization checks. If any of these checks fail, it SHOULD send an appropriate CONNACK response with a non-zero return code as described in section 3.2 and it MUST close the Network Connection."

      Replacement Text:
      "3. The Server MAY check that the contents of the CONNECT Packet meet any further restrictions and SHOULD perform authentication and authorization checks. If any of these checks fail it MUST close the Network Connection. Before closing the connection it MAY send an appropriate CONNACK response with a non-zero return code as described in section 3.2. "

      C. Add the following text after step 3 of 3.1.4 Connect / Response.

      "Non-normative comment

      It is recommended that authentication and authorization checks be performed if the server is being used to serve any form of sensitive data. If these tests succeed, the server responds by sending a CONNACK with a return code of zero. If they fail, the server is advised not to send a CONNACK at all, as this could alert a potential attacker to the presence of the MQTT server and encourage such an attacker to launch a denial of service or password-guessing attack. "

      D. Replace section 5.4.2.

      Existing Text:
      "An implementation may restrict access to Server resources based on information provided by the Client such as User Name, Client Identifier, the hostname/IP address of the Client, or the outcome of authentication mechanisms."

      Replacement Text:
      "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 3.1.2.12). 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 client's ability to publish to particular Topics or to subscribe using particular Topic Filters. In particular an implementation should consider limiting access to Topic Filters that have broad scope, such as the # Topic Filter."

      Show
      A. Add a new section 1.6 and renumber the existing 1.6 to become 1.7. The new section to say "1.6 Security MQTT client and server implementations SHOULD offer Authentication, Authorization and secure communications options, such as those discussed in Chapter 5. Applications concerned with critical infrastructure, personally identifiable information, or other personal or sensitive information are strongly advised to use these security capabilities." B. Replace Step of 3.1.4 Connect / Response. Existing Text: "The Server MAY check that the contents of the CONNECT Packet meet any further restrictions and MAY perform authentication and authorization checks. If any of these checks fail, it SHOULD send an appropriate CONNACK response with a non-zero return code as described in section 3.2 and it MUST close the Network Connection." Replacement Text: "3. The Server MAY check that the contents of the CONNECT Packet meet any further restrictions and SHOULD perform authentication and authorization checks. If any of these checks fail it MUST close the Network Connection. Before closing the connection it MAY send an appropriate CONNACK response with a non-zero return code as described in section 3.2. " C. Add the following text after step 3 of 3.1.4 Connect / Response. "Non-normative comment It is recommended that authentication and authorization checks be performed if the server is being used to serve any form of sensitive data. If these tests succeed, the server responds by sending a CONNACK with a return code of zero. If they fail, the server is advised not to send a CONNACK at all, as this could alert a potential attacker to the presence of the MQTT server and encourage such an attacker to launch a denial of service or password-guessing attack. " D. Replace section 5.4.2. Existing Text: "An implementation may restrict access to Server resources based on information provided by the Client such as User Name, Client Identifier, the hostname/IP address of the Client, or the outcome of authentication mechanisms." Replacement Text: "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 3.1.2.12). 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 client's ability to publish to particular Topics or to subscribe using particular Topic Filters. In particular an implementation should consider limiting access to Topic Filters that have broad scope, such as the # Topic Filter."

      Description

      Jira opened following discussion on TC call 11.08.2016

      Review Section 3.1.4 Connect / Response
      e.g., The Server MAY check that the contents of the CONNECT Packet meet any further restrictions and MAY perform authentication and authorization checks. If any of these checks fail, it SHOULD send an appropriate CONNACK response with a non-zero return code as described in section 3.2 and it MUST close the Network Connection.

      Review Section 5 (Security)

        Attachments

          Activity

            People

            • Assignee:
              PeterNiblett Peter Niblett
              Reporter:
              coppen Richard Coppen
            • Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: