Uploaded image for project: 'OASIS Message Queuing Telemetry Transport (MQTT) TC'
  1. OASIS Message Queuing Telemetry Transport (MQTT) TC
  2. MQTT-319

Client Reauthentication

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 5
    • Fix Version/s: 5, wd08
    • Component/s: core
    • Labels:
      None
    • Proposal:
      Hide

      Add a new Return code (Re-authenticate) which is used only on the AUTH packet.

      At any time after a CONNACK packet is received, the client can send an AUTH packet with a Re-authenticate return code. This starts a re-authentication 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. If the re-authentication fails, the Server SHOULD send a DISCONNECT with an appropriate return code and MUST close the network 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.

      Show
      Add a new Return code (Re-authenticate) which is used only on the AUTH packet. At any time after a CONNACK packet is received, the client can send an AUTH packet with a Re-authenticate return code. This starts a re-authentication 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. If the re-authentication fails, the Server SHOULD send a DISCONNECT with an appropriate return code and MUST close the network 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.

      Description

      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.

        Attachments

          Activity

            People

            • Assignee:
              ken.borgendale Ken Borgendale (Inactive)
              Reporter:
              kdot Konstantin Dotchkoff [X] (Inactive)
            • Watchers:
              3 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved: