[OASIS Issue Tracker] (MQTT-293) Recommendations for securing an MQTT server

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ https://issues.oasis-open.org/browse/MQTT-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Niblett updated MQTT-293:
-------------------------------

    Proposal: 
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, Authorisation and secure communications options, such as those discussed in Chapter 5. Applications concerned with critical infrastructure,  personal data or other sensitive information, or applications that expose MQTT connectivity over the public Internet 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 on any connection request that is received across the public Internet. 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:
"An implementation may restrict access to Server resources based on the identity established by the authentication process, and/or on other information such as the hostname/IP address of the Client.

In particular, an implementation should protect the MQTT Session state (described in section 3.1.2.12). The Session State is accessed via the Client Identifier, so this means that the implementation should check that the client in question is entitled to use the Client Identifier that it provides in the CONNECT request. If it doesn’t do this check, then there is a risk that one client could, accidentally or maliciously, provide a Client Identifier that is already being used by some other client. If this were to happen, the other client would be disconnected and messages that were destined for it would instead get delivered to the new client. 

Once the CONNECT has been accepted the implementation may use the Client Identifier and/or the identity used to authorise the CONNECT to authorise access to Topics in subsequent PUBLISH or SUBSCRIBE requests."


I have added a proposal containing the main things that I think we should include.

I haven't included Raph's TLS recommendations, as he points out that some of them might better be handled outside the main MQTT spec.   The one that would need an addition to the spec is the ALPN extension proposal.  I think this is interesting, but I suggest we handle it in a separate JIRA.

> Recommendations for securing an MQTT server
> -------------------------------------------
>
>                 Key: MQTT-293
>                 URL: https://issues.oasis-open.org/browse/MQTT-293
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 5
>            Reporter: Richard Coppen
>            Assignee: Peter Niblett
>
> 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)



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)