[ https://issues.oasis-open.org/browse/MQTT-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Coppen updated MQTT-255:
--------------------------------
Affects Version/s: 5
> Alternate authentication mechanisms
> -----------------------------------
>
> Key: MQTT-255
> URL: https://issues.oasis-open.org/browse/MQTT-255
> Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
> Issue Type: Bug
> Components: futures
> Affects Versions: 5
> Reporter: Peter Niblett
> Priority: Critical
>
> MQTT 3.1.1 permits two client authentication mechanisms:
> 1. Authentication by TLS (using a certificate/private key) prior to the CONNECT packet being sent
> 2. Authentication via a username and password (or similar token) provided by a client in the CONNECT packet.
> The second mechanism also requires the use of TLS encryption in order for it to be secure.
> There are three reasons why we might consider adding alternative mechanisms, for example one involving server-directed challenge response during the MQTT CONNECT exchange:
> i) TLS might be considered too heavyweight for some particularly constrained devices.
> ii) There are many deployments where people are ok with TLS, but don't want to provision devices with bespoke Certificates. Some of these might not have a need to encrypt the MQTT protocol, but with approach 2 you end up having to encrypt all MQTT packets just in order to protect the password field in the CONNECT
> iii) The organization (or standard building on top of MQTT) might already have an alternative authentication protocol.
> Notes:
> 1. The emphasis in this requirement is on composing with existing security mechanisms, rather than inventing new ones
> 2. Some of this could be achieved by publishing Committee Notes (e.g. OAuth 2.0) rather than changing the CONNECT protocol packet exchange
--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
