XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: No Action
    • Affects Version/s: 5, wd13
    • Fix Version/s: 5
    • Component/s: core
    • Labels:
      None
    • Proposal:
      Hide

      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.

      Show
      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.

      Description

      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.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              coppen Richard Coppen (Inactive)
            • Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: