OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (MQTT-255) Alternate authentication mechanisms


     [ https://issues.oasis-open.org/browse/MQTT-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Borgendale updated MQTT-255:
--------------------------------

    Proposal: 
Add an Identifier/Value pair of 15 (0xF) Auth Method.  The data is a UTF-8 string which is the name of the authentication method.  This is commonly a registered SASL mechanism, but it can be any string which is understood by both the Client and Server.

Add an identifier/Value pair of 47 (0x2F) Auth Data.  This is added to the CONNECT, CONNACK, and AUTH packets.  The type is BinaryData.

Add a new Control Packet: AUTH: Command=0xF, Flags=0x1   The variable header for AUTH consists of a Return code, and an Identifier/Value length, followed by 0 or more Identifier/Value pairs.  There is no payload.

On CONNECT, the Client MAY include an AuthMethod Idendifier/Value pair with the name of an authentication method.  If this is not specified, the Server does the authentication based only on information in the CONNECT packet (as it does in MQTTv3.1.1).

If the CONNECT packet has enough information for the Server to authenticate the Client, it sends a CONNACK with an Return code of 0.  The Server MAY send an AuthMethod field in the CONNACK to indicate the authentication method is used.  The Server MUST NOT send an AUTH token if it has not received an AuthMethod from the Client on the CONNECT packet.

If the AuthMethod specified on the CONNECT has the value "LIST", the Server MUST either return a comma separated list of authentication methods it supports in the AuthMethod field of a AUTH packet or close the connection.  If the server returns the list it MUST offer at least one authentication method in this list.  If it does not support any form of extended authentication, it should close the connection (it MAY send a CONNACK return and MUST close the connection).

If the Server does not support the authentication method selected by the client, it MAY send a Not authorized return code on CONNACK and MUST close the connection.  If the Client does not accept any of the authentication methods returned by the server, it MAY send a DISCONNECT packet and MUST close the connection.

If the Server needs additional information to complete the Authorization, it sends a AUTH packet with a Return code of More Auth Needed and the AuthMethod selected by the client.  The Sever MAY send the first piece of server authentication data as the AuthData field in the AUTH packet. 

The Server and Client can continue to send AUTH packets to one another until the Server accepts the authentication by sending a CONNACK with a Return code of 0, or rejects the connection by sending a CONNACK with a non-zero return code.  The Client MAY close the connection at any time and MAY send a DISCONNECT to the server informing it of the reason.  These intermediate AUTH packets sent from the Server have a Return code of "More auth needed", and all AUTH packets sent by the Client have a Return code of 0.

If the Server receives an AUTH packet after it has sent a CONNACK, it MUST have a Return code of "Revalidate" set to indicate that this is a revalidate.  The revalidate acts just like the CONNECT and starts an authentication.  This ends with a AUTH sent from Server to Client with a Return code of other than "More auth needed".  A zero Return code indicates that the revalidation is successful.  The Server MAY close the connection if the revalidate fails.  

The Client MUST NOT send an AUTH packet if it did not receive an AuthMethod id/value pair on the CONNACK.  

The spec update consists of two parts, the mechanism which is the addition of the AuthMethod and AuthData id/value pairs and the new AUTH control packet.  In addition there is a chapter 4 section describing the use and showing the sequence for a common challenge / response auth method such as SCRAM.

For instance, the exchange for SCRAM as an example of a simple challenge response is:

client to server:   CONNECT AuthMethod="SCRAM-SHA-256"  AuthData=client-first-data
server to client:   AUTH rc="More auth" AuthMethod="SCRAM-SHA-256" AuthData=server-first-data
client to server    AUTH rc=0 AuthMethod="SCRAM-SHA-256" AuthData=client-final-data
server to client    CONNACK rc=0 AuthMethod="SCRAM-SHA-256"  AuthData=server-final-data

An example of an Kerberos challenge:

client to server   CONNECT AuthMethod="GS2-KRB5" 
server to client   AUTH  rc="More auth"  AuthMethod="GS2-KRB5"
client to server   AUTH  rc=0 AuthMethod="GS2-KRB5" AuthData=inital context token
server to client   AUTH  rc="More auth"  AuthMethod="GS2-KRB5" AuthData=reply context token
client to server   AUTH  rc=0 AuthMethod="GS2-KRB5" 
server to client   CONNACK  rc=0 AuthMethod="GS2-KRB5" AuthData=outcome of authentication

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]