[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:all-tabpanel ]

Ken Borgendale updated MQTT-431:
--------------------------------

    Proposal: 
1. Add a new Reason Code 26 0x1A Request re-authentication

2. Add the following at the end of section 4.12.1 Re-authentication

If the Client supplied an Authentication Method in the CONNACT packet the Server is allowed to request that the Client initiate re-authentication any time after it sends the CONNACK packet.  It does this by sending an AUTH packet with a Reason Code of 0x1A (Request Re-authentication).  The Server MUST set the Authentication Method to the same value as the Authentication Method originally used to authenticate the Network Connection.  The Client MAY respond to this request by initiating a re-authentication, but it is not required to do so.

Non-normative comment:
The request for re-authentication from the server is used when the server knows that a re-authentication is required, but the client might not. 


  was:
We review the current re-authentication structure and consider:

1. Remove the re-authentication flow and disallow the use of AUTH packets outside of the CONNECT/CONNACK sequence.
2. Make the re-authentication flow symmetric so that the Server can initiate token refresh.
3. Offer additional guidance around the use of the AUTH packet outside of the initial authentication sequence.



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