[OASIS Issue Tracker] (MQTT-255) Alternate authentication mechanisms

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

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

Peter Niblett updated MQTT-255:
-------------------------------

    Description: 
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. 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.


  was:
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. Three reasons why we might consider adding an alternative  third mechanism, 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 established challenge-response protocol. 



> 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
>            Reporter: Peter Niblett
>
> 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. 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.



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