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

Nicholas O'Leary commented on MQTT-255:
---------------------------------------

For the initial connect exchange, only AUTH packets are exchanged between the CONNECT and CONNACK.

What is the behaviour after a client sends a Revalidate AUTH packet regarding other packet types? Can either the client or server continue to send other commands packets whilst the Revalidate AUTH flow is in progress or must all other packet flows be suspended until the AUTH flow has completed?


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