[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:comment-tabpanel&focusedCommentId=62210#comment-62210 ] 

Ken Borgendale commented on MQTT-255:
-------------------------------------

In MQTT v3.1.1 the CONNECT has two security fields, username (a string) and password (binary data).  While this is enough to handle a large number of forms of authentication, it does not handle cases of mutual authentication using a two way exchange of authentication data, nor various forms of challenge response.  While MQTT should not be in the business of requiring particular authentication, it should allow more complex authentication by some simple additions to the existing CONNECT and CONNACK.

As we have defined a metadata mechanism for PUBLISH in MQTT-256, a similar mechanism can be used for CONNECT and CONNACK.

- Add an AuthMethod metadata (string) to CONNECT (the auth data is in the password)
- Add either a flag to CONNECT to indicate that this is a challenge response.  
- Add AuthMethod (string) and AuthData (binary) metadata fields to CONNACK
- Add a return value to CONNACK for MoreAuthNeeded.  The connection would not be closed.  
- Allow a second CONNECT packet with the response flag in a connection after MoreAuthNeeded is returned
- Remove the requirement on CONNECT to have a username if there is a password

If the AuthMethod string is an SASL method ID, then this mechanism would conform to SASL.  We can define the condition where the server responds with a list of possible methods.

We could then suggest in a non-normative text section the correct way to implement various SASL methods.  Any server which does not wish to implement this can simply ignore the AuthMethod metadata on the CONNECT, and never return toe MoreAuthNeeded return code in CONNACK. 

This should all be allowed under the proposed charter which allows us to add data fields and return codes to various packets, but not to add required security mechanisms.


> 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
>            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)