[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-293) Recommendations for securing an MQTT server
[ 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, 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."
was:
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, 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:
"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 the Client Identifier 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 may additionally 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."
> 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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]