MQTT-255 Support alternate authenticaion mechanisms

1. MQTT-255 Support alternate authenticaion mechanisms Ken Borgendale 2016-04-21

2. Authentication background • In MQTT v3.1.1 there are two fields on CONNECT used for authorization: username and password. The username is a string, and the password is binary data. • The client is not required to wait for a CONNACK before sending additional packets. • MQTT v3.1.1 does not describe how the server does authentication and authorization, only that these fields are available and there are two return codes on CONNACK. • In fact, these two fields are being used to implement a number of token based authorization in addition to a simple userid:password authentication. • As the password (or credentials stored in the password) are passed in the clear, it is necessary to secure the connection (TLS or ipsec) external to MQTT. TLS is also used to the authenticate the server at the client.

3. Authentication requirements • Reason for additional authentication support • Support constrained devices where TLS is not otherwise required • Desire for mutual authentication • Organizations already have standards of an authentication mechanism • Allow revalidation during a connection • While the MQTT v3.1.1 authentication mechanism can support many forms of token authentication (such as OAuth) it does not handle mutual authentication, nor the passing of authentication data in localized encryption. It does not provide for re-validation during a sesson. • There is no way in MQTT v3.1.1 for a server to say what forms of authentication it accepts. • The mechanism used for this in many other protocols is SASL • In many cases, servers are content with the TLS:username:password authentication and do not need more. Therefore we have a requirement to not require servers to implement additional forms of security. This is also required by the new charter.

4. SASL backgroud • SASL (Simple Authentication and Security Layer) is defined in RFC 4422 • SASL defines an abstraction layer for a set of authentication mechanisms. It does not define the syntax. • SASL defines a set of named authentication methods, and a registry for them. • The basic SASL has multiple possible flows, but a common flow is: • Client sends request authentication • Server sends challenge • Client sends challenge response • Server sends authentication complete • Some flows do not require the challenge, and some require multiple challenge exchanges.

5. Design – all proposals • Add an optional value field AuthMethod which contains the name of the authorization mechanism. Add non-normative text to indicate that this should be a SASL auth mechanism. If not specified the client and server implicitly agree on the authentication method (as in v3.1.1). • Add an optional value field AuthData which contains the data as required for the auth method. • Rename the password field on CONNECT to be an AuthData field to indicate that it is commonly used for data other than passwords. • Servers which do not want to use enhanced authentication only need to parse the fields (as in v3.1.1 where MQTT does not require any action for username and password other than to parse them) • Either the client and server can terminate the authentication flow at any point by closing the connection, perhaps having first sent a DISCONNECT or CONNACK. • Do not require a username even if the AuthData (password) is given • The authorization completion results in a CONNACK

6. MQTT v5 proposal 1 • Add the additional AuthMethod and AuthData fields to CONNECT and CONNACK. • Add a return code MoreAuthNeeded in CONNACK to indicate an authentication challenge • Add a flag in CONNECT to indicate this is a challenge response. This can only be sent after the server has sent a CONNACK with the MoreAuthNeeded return code. This is essentially a new form of the CONNECT with only additional auth related fields. • The authentication complete is set back on CONNACK. • Can handle any number of challenge and responses • Could handle re-validation by allowing a later CONNET with response flag • Does not require any new control packet types • Flow for challenge / response like SCRAM • CLIENT SERVER • CONNECT UserName=user AuthMethod=SCRAM AuthData=Nonce ------ • ---- CONNACK RC=MoreAuth AuthMethod=SCRAM AuthData=Nonce+Salt • CONNECT (response) AuthMethod=SCRAM AuthData=Nonce+Proof --- • ---- CONNACK RC=0 AuthMethod=SCRAM AuthData=ServerProof

7. MQTT-255 proposal 2 • Create a new control packet: AUTH • The AUTH packet has a type and the optional fields AuthMethod and AuthData • The AUTH types are • Challenge – sent from server to client to say more authorization information is required. • Response – sent from the client to the server as the response to a challenge. It may not be sent unless the server as sent a challenge. • Validate – sent from the client to the server to revalidate the credentials. This can be sent after a CONNACK has been received. • This is a bit cleaner at the expense of creating a new packet type. Otherwise very similar. • After the CONNACK, the validate can be sent to re-validate the connection. • Flow for challenge / response like SCRAM • CLIENT SERVER • CONNECT UserName=user AuthMethod=SCRAM AuthData=Nonce ----- • ------ AUTH (challenge) AuthMethod=SCRAM AuthData=Nonce+Salt • AUTH(response) AuthMethod=SCRAM AuthData=Nonce+Proof ------- • ------ CONNACK RC=0 AuthMethod=SCRAM AuthData=ServerProof