[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-319) Client Reauthentication
[ https://issues.oasis-open.org/browse/MQTT-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ken Borgendale updated MQTT-319:
--------------------------------
Proposal:
Add a new Return code (Re-authenticate) which is used only on the AUTH packet.
At any time after the CONNACK packet is received, the client can send an AUTH packet with a Re-authenticate return code. This starts a re-validation of the client. anytime after it has received a CONNACK.
The AUTH packet with Re-authenticate MUST contain an Auth Method and this MUST match the authentication method originally used to authenticate the client. The AUTH packet with a Re-authenticate MAY contain an Auth Data and acts just like the initial CONNECT for an authentication. This exchange ends with an AUTH sent from the Server to the Client with a Return code of 0 (Success) or a DISCONNECT packet. It the re-authentication fails, the server SHOULD send a DISCONNECT with an appropriate return code and MUST close the connection.
During the re-authentication both the Client and Server can continue to send other packets using the existing authentication.
Non normative comment: The server MAY fail the re-authentication if the client changes authentication data so that existing authorization is no longer valid. For instance if the server has done authorization based on a username, it might fail the re-authentication if the username is changed.
was:
Add a new Return code (Re-authenticate) which is used only on the AUTH packet.
At any time after the CONNACK packet is received, the client can send an AUTH packet with a Re-authenticate return code. This starts a re-validation of the client. anytime after it has received a CONNACK.
The AUTH packet with Re-authenticate MUST contain an Auth Method and this MUST match the authentication method originally used to authenticate the client. The AUTH packet with a Re-authenticate MAY contain an Auth Data and acts just like the initial CONNECT for an authentication. This exchange ends with an AUTH sent from the Server to the Client with a Return code of 0 (Success) or a DISCONNECT packet. It the re-authentication fails, the server SHOULD send a DISCONNECT with an appropriate return code and MUST close the connection.
During the re-authentication both the Client and Server can continue to send other packets using the existing authentication.
Non normative comment: The server MAY fail the re-authentication if the client changes authentication data so that existing authorization is no longer valid. For instance if the server has done authorization based on a username, it might fail the re-authentication if the username fails.
> Client Reauthentication
> -----------------------
>
> Key: MQTT-319
> URL: https://issues.oasis-open.org/browse/MQTT-319
> Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
> Issue Type: New Feature
> Components: core
> Affects Versions: 5
> Reporter: Konstantin Dotchkoff
> Assignee: Ken Borgendale
> Labels: Proposed
> Fix For: 5
>
>
> For improved security, in many scenarios, security tokens with an expiration time are used to authenticate Clients. When the token expires, the Server will disconnect the Client, since the authentication information is not valid anymore. Re-establishing the Client connection is expensive operation and also interrupts the message exchange between the Client and Server.
> For those cases having the ability to re-authenticate the Client on an existing/open connection is very beneficial.
> At the at the 2016-10-13 MQTT TC meeting it was decided to move the re-authentication out of MQTT-255 into a separate issue.
--
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]