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

Raphael Cohen commented on MQTT-255:
------------------------------------

Richard,

I'd like to support SASL (a standard set of RFCs for authentication) to do this properly and solve the problem once and for all. In particular, there are 3 SASL mechanisms I'd like to see used in MQTT:-

- SCRAM-SHA-1 (client sends user name + nonce, server sends nonce + salt + number of rounds to apply SHA1 to salt + password + sever nonce + client nonce, client sends hashed, salted, iterated value, servers sends OK [ie our CONNACK])  (https://tools.ietf.org/html/rfc5802)
- SAML20 (SAML 2.0)
- OPENID20 (OpenID 2.0)
We can convert the existing 3 login approaches to SASL mechanisms, too  (see Notes below for details), these being PLAIN, ANONYMOUS and EXTERNAL.

SASL also can work with TLS channel binding, so integrating TLS more tightly if implementers desire.
To use SASL in MQTT we need to make the following modifications:-

- Set a bit in the CONNECT packet to identify the login as SASL (eg reserved bit 0 of connect flags*), and set the username to the SASL mechanism desired (or use a specially formatted username or password and no new bit; not that nice), and the password to the initial challenge (for SCRAM, the client nonce)
- Introduce a variant of CONNACK that uses either Reserved bits 0 -3 of byte 1, or bits 1 - 7 of Connect Acknowledge Flags, that acts as 'continue', OR sets Connect return code to 255. The last is preferable, because it means a client just needs to check return codes first (like it would currently)
- this CONNACK packet contains a 'response' field
- SASL mechanisms that don't require challenge-response (eg LOGIN, PLAIN, EXTERNAL) can be made to work without any protocol changes at all, but don't add very much
- do we want to actually have this mean 'extension flags' or 'new variant payload' or some such?
  - or do we want to define byte 7 as inferring the interpretation of byte 8



SASL availability to implementers:-

https://www.gnu.org/software/gsasl/  is a good, free, LGPL, embedded-C friendly SASL library that works under C89 (Windows, Unix, POSIX, etc). that supports the 3 SASL mechanisms
https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml list of SASL mechanisms

Notes
- Making this change allows non-SASL challenge response implementations to also work, but I'm not convinced about supporting that
- This design doesn't support the ability of a client to choose the SASL implementation (ie either the client or the server offers a list of SASL mechanisms; the danger of this is as that a man-in-the-middle can modify the list of mechanisms if not using TLS and select a 'weaker' or 'known vulnerable' one) - it has to 'know' what that server will accept, perhaps making client migrations slightly harder
- using SASL has the potential to allow integration with, say, LDAP-based authentication (eg using saslauthd)
- using GS2-* APIs (effectively, Kerberos) places new problems on MQTT, as we do not have server-initiated Disconnects which are needed for Kerberos token expiry (and no way of telling the client that disconnect was due to token expiry).
- I am actually in favour of redefining byte 8 such that -
  - User Name / Password flags are 'adjusted', and User Name become SASL mechanism and Password becomes SASL initial message
    - This allows backwards compatible authentication for servers, so that:-
      -  password-less becomes mechanism EXTERNAL
      - username + password becomes mechanism PLAIN
      - no username or password becomes mechanism ANONYMOUS


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