[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-431) Review Re-authentication mechanism
[ 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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]