[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=66315#comment-66315 ] 

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

I have added a proposal for a simple mechanism for a server to request a re-authentication.  This is still not symmetrical re-authentication as the client actually initiates any such flow, but this allows the server to request it.  This allows for cases such as when the client does not have a clock, or does not keep track of when its credentials will expire.

There are a number of issues around coordinating this request from a authentication flow.  This proposal gets around these by making the sever to client request for re-authentication totally asynchronous to the actual re-authentication flow.  We might need to say the client must ignore this request if a re-authentication flow is in progress.

I would prefer to leave re-authentication as it exists, but if we feel that we need the ability of the server to say that re-authentication is required, this simple mechanism can be added.

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