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

Raphael Cohn commented on MQTT-255:
-----------------------------------

I like this proposal. It seems to cover all scenarios I think we should care about, and all the modern authentication mechanisms. Sending CONNACK as the final packet, whilst a 'breaking' change, ensures that a server only reveals details to an authenticated client. The only thing I'm not so sure about is "LIST". I worry that this could get us into some of the same problems as TLS ClientHello / ServerHello ciphersuite agreement over the years. I also think there might be a security issue of a downgrade attack if the LIST is offered to a client over a plaintext connection OR to an unauthenticated client. Of course, one can argue it is a broker's responsibility to only offer secure mechanisms, but the reality's no different to the TLS 1.0 / 1.1 / 1.2 issue on the internet today - if you want to support an older client, even during migration...

Also, just as a client can either use TLS or not, and won't swap to the other, I think the same is true for a connection mechanism. Either it has the credentials (and the user's / system administrator's approval) for SCAM-SHA-256, or it doesn't. So I think LIST in practice is probably unnecessary. It might be useful to supply it on CONNACK, though.

With this mechanism now in place, the opportunity exists to deprecate the user of username / password and call password 'initial client auth data' or the like. That might be a step too far, but an auth identifier can be:-
- <nothing> => no username, no password
- ANONYMOUS => username only
- LOGIN => username, password
- PLAIN => username, password, role
etc

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