[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=63771#comment-63771 ] 

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

I put in the LIST function as it is a part of SASL, but I agree that it is not of very high value and I would prefer to drop it.  We also need to decide if we want to do revalidation.

The assumption on revalidation is that the client starts this at a point before the credentials expire.  There should not be a issue with other packets flowing at the same time.  The proposal is that the Server can decide what to do if the revalidation fails.

Another thing to discuss is that sending an AuthMethod on CONNECT (at least with some methods) assumes that the client is willing to accept a challenge and therefore must not send any packets othere than AUTH before getting the CONNACK.   

> 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: Improvement
>          Components: core
>    Affects Versions: 5
>            Reporter: Peter Niblett
>            Assignee: Ken Borgendale
>             Fix For: 5
>
>
> 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)