Authentication

(Assuming the adoption of the connect flags changes in _ https://issues.oasis-open.org/browse/MQTT-576 ). Section 5.2.2 MsgType Add AUTH MsgType to table 3.  Value 0x03 Section 5.4.4 CONNECT Change 'Flags' to 'Connect Flags' in table 9 Length and MsgType: see Section 5.2 Connect Flags: Authentication: if set, an AUTH packet follows for authentication Will: (unchanged) CleanSession: (unchanged) Section 5.4 Format of Individual Messages 5.4.5.1 AUTH Length (octet 0) MsgType       (1) Reason Code       (2) Auth Method Length (k)               (3) Auth Method       (4:4+k) Auth Data (optional) (5+k:n) The AUTH message is first sent by the client as part of an authentication exchange.  The server responds with another AUTH message and so on until the authentication is complete.  The server then responds with a CONNACK message. Length and MsgType: see section 5.2 Reason Code: The sender of the AUTH Packet MUST use one of the Authenticate Reason Codes: Value Hex Reason Code Name Sent by Description 0 0x00 Success Server Authentication is successful 24 0x18 Continue authentication Client or Server Continue the authentication with another step 25 0x19 Re-authenticate Client Initiate a re-authentication Auth Method Length: the length of the Auth method string Auth Method String: an UTF-8 Encoded String containing the name of the authentication method Auth Data: Binary Data containing authentication data. The contents of this data are defined by the authentication method For a simple cleartext password analogous to MQTT user name and password, the SASL PLAIN method can be used. 6.15 Authentication Authentication involves the exchange of AUTH packets between the Client and the Server after the CONNECT and before the CONNACK packets. To begin an authentication exchange, the Client sets the AUTH flag in the CONNECT packet. It then sends an AUTH packet with an Authentication Method. This specifies the authentication method to use. If the Server does not support the Authentication Method supplied by the Client, it MAY send a CONNACK with a Reason Code of 0x8C (Bad authentication method) or 0x87 (Not Authorized) and MUST close the Connection. The Authentication Method is an agreement between the Client and Server about the meaning of the data sent in the Authentication Data and any of the other fields in CONNECT, and the exchanges and processing needed by the Client and Server to complete the authentication. Non-normative comment The Authentication Method is commonly a SASL mechanism, and using such a registered name aids interchange. However, the Authentication Method is not constrained to using registered SASL mechanisms. If the Authentication Method selected by the Client specifies that the Client sends data first, the Client SHOULD include an Authentication Data property in the AUTH packet. This property can be used to provide data as specified by the Authentication Method. The contents of the Authentication Data are defined by the authentication method. If the Server requires additional information to complete the authentication, it can send an AUTH packet to the Client. This packet MUST contain a Reason Code of 0x18 (Continue authentication). If the authentication method requires the Server to send authentication data to the Client, it is sent in the Authentication Data. The Client responds to an AUTH packet from the Server by sending a further AUTH packet. This packet MUST contain a Reason Code of 0x18 (Continue authentication). If the authentication method requires the Client to send authentication data for the Server, it is sent in the Authentication Data. The Client and Server exchange AUTH packets as needed until the Server accepts the authentication by sending a CONNACK with a Reason Code of 0. If the acceptance of the authentication requires data to be sent to the Client, it is sent in the Authentication Data. The Client can close the connection at any point in this process by sending a DISCONNECT packet. The Server can reject the authentication at any point in this process by sending a CONNACK with a Reason Code of 0x80 or above as described in section 4.13. The implementation of authentication is OPTIONAL for both Clients and Servers. If the Client does not include an Authentication Method in the CONNECT, the Server MUST NOT send an AUTH packet. If the Client does not set the Authentication Flag in the CONNECT, the Client MUST NOT send an AUTH packet to the Server. If the Client does not set thean Authentication Flag in the CONNECT packet, the Server SHOULD authenticate using some or all of the information in the CONNECT packet and Network Connection. Non-normative example showing a user name and password authentication: · Client to Server: CONNECT Authentication Flag=1 Authentication Data=client-first-data · Client to Server: AUTH rc=0x01 Authentication Method="PLAIN" Authentication Data=client-first-data · Server to Client CONNACK rc=0 Where client-first data is the content of the SASL PLAIN message as described in RFC 4616: The mechanism consists of a single message, a string of [UTF-8]   encoded [Unicode] characters, from the client to the server. The [UTF-8] client presents the authorization identity (identity to act as), followed by a NUL (U+0000) character, followed by the authentication identity (identity whose password will be used), followed by a NUL (U+0000) character, followed by the clear-text password. As with other SASL mechanisms, the client does not provide an authorization identity when it wishes the server to derive an identity from the credentials and use that as the authorization identity.