[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-568) Authentication
[ https://issues.oasis-open.org/browse/MQTT-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ian Craggs updated MQTT-568:
----------------------------
Proposal:
_(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._
Â
Â
Â
was:
_(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
(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.
Â
Â
Â
> Authentication
> --------------
>
> Key: MQTT-568
> URL: https://issues.oasis-open.org/browse/MQTT-568
> Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
> Issue Type: Improvement
> Components: MQTT-SN
> Affects Versions: MQTT-SN-1.2
> Reporter: Ian Craggs
> Assignee: Ian Craggs
> Priority: Major
>
> Authentication has been raised as an important omission.Â
> Mirroring the MQTT 5.0 AUTH packet seems like a good idea.
--
This message was sent by Atlassian Jira
(v8.3.3#803004)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]