[OASIS Issue Tracker] (MQTT-431) Review Re-authentication mechanism

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/MQTT-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=66276#comment-66276 ] 

Ken Borgendale commented on MQTT-431:
-------------------------------------

As a history, enhanced authentication was proposed a MQTT-255 and extensively discussed at the Bellevue F2F and the September Hursley F2F.  At that time the TC decided to approve the connect time enhanced authentication and to create another issue for reauthorization.  There were actually 2 such issues created MQTT-315 and MQTT-317.  We closed MQTT-315 and designed reauthorization as MQTT-317.  One of the issues we raised was whether anybody actually wanted reauthorization enough to add it, and the consensus of the TC was to proceed with it.  The technical issues and limitations were discussed in a subgrouip and accepted by the TC.

We can of course re-open any of the decisions previously made by the TC, but doing this risks ever getting to closure of the spec.

While the enhanced authentication avoids using the name SASL, it is clearly designed to be SASL conforming and to allow SASL mechanisms to be used as Auth Methods.  In SASL authentication is all initiated by the client.  Some protocols which implement SASL do allow the server to request the client to initiate authentication or reauthentication.

In response to the concerns raised:
1. To exploit the AUTH flow for some other purpose requires both a client and server which agree on such usage.  In a client application using a client library this would presumably mean that the client library is involved.  If we just want to flow data between client application and server, or client library and server, much better means already exist (using PUBLISH to system topics for instance) which have none of the limitations of using AUTH.

2. The SASL mechanisms with time limited tokens generally make known to the client the time limit of the token.  Initiating reauthentication from the server seems to be the thing which is not used as it is not required to implement SASL.

3. Either a client or server is free to not implement reauthentication if it believes there is no requirement.  Indeed, they are free to not implement any part of enhanced authentication.

> Review Re-authentication mechanism
> ----------------------------------
>
>                 Key: MQTT-431
>                 URL: https://issues.oasis-open.org/browse/MQTT-431
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 5, wd13
>            Reporter: Richard Coppen
>             Fix For: 5
>
>
> MQTT v5.0 introduces a new AUTH mechanism. This allows MQTT to bind with various authentication mechanisms such as SASL within the CONNECT / CONNACK exchange.
> In its current form the Client is permitted to flow an Auth Packet for re-authenication at any point. There are a few potential issues with this approach:
> 1. Implementations might exploit the AUTH flow for application data and control.
> 2. Only the Client can initiate the re-authentication. In many cases the Server is likely to coordinate Clients to refresh keys.
> 3. It is likely that existing deployments simply use DISCONNECT to coordinate re-authentication and this might lead to little uptake on re-auth.
> There are benefits to the current approach, for example in reducing bandwidth.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)