Section 6. Reduced Protocol Interactions for MQTT v3.1.1

This section describes a reduced set of protocol interactions for the
   MQTT v3.1.1 Clients.  An MQTT v5.0 Broker MAY implement these
   interactions for the MQTT v3.1.1 Clients; the flows described in this
   section are NOT RECOMMENDED for use by MQTT v5.0 Clients.  Brokers
   that do not support MQTT v3.1.1 Clients return a CONNACK packet with
   reason code 0x84 (Unsupported Protocol Version) in response to the
   connection requests.
6.1.  Token Transport
   As in MQTT v5.0, the token MAY either be transported before, by
   publishing to the "authz-info" topic, or inside the CONNECT packet.
   If the Client provided the token via the "authz-info" topic and will
   not update the token in the CONNECT packet, it MUST authenticate over
   TLS.  The Broker SHOULD still be prepared to store the Client access
   token for future use (regardless of the method of transport).
   In MQTT v3.1.1, after the Client has published to the "authz-info"
   topic, the Broker cannot communicate the result of the token
   validation because PUBACK reason codes or server-side DISCONNECT
   packets are not supported.  In any case, the subsequent TLS handshake
   would fail without a valid token, which can prompt the Client to
   obtain a valid token.
   To transport the token to the Broker inside the CONNECT packet, the
   Client uses the User Name and Password fields.  Figure 10 shows the
   structure of the MQTT CONNECT packet.
                      0             8             16
                      +---------------------------+
                      |Protocol name length = 4   |
                      +---------------------------+
                      |     'M'            'Q'    |
                      +---------------------------+
                      |     'T'            'T'    |
                      +---------------------------+
                      |Proto.level=5|Connect flags|
                      +---------------------------+
                      |        Keep alive         |
                      +---------------------------+
                      |        Payload            |
                      |  Client Identifier        |
                      |  (UTF-8-encoded string)   |
                      | User Name as access token |
                      |   (UTF-8-encoded string)  |
                      | Password for signature/MAC|
                      |     (Binary Data)         |
                      +---------------------------+
       Figure 10: MQTT CONNECT Variable Header Using a User Name and
                              Password for ACE
   Table 2 shows how the MQTT connect flags MUST be set to initiate a
   connection with the Broker.
   +================+==========+========+======+======+=======+=======+
   | User Name Flag | Password | Will   | Will | Will | Clean | Rsvd. |
   |                | Flag     | Retain | QoS  | Flag |       |       |
   +================+==========+========+======+======+=======+=======+
   |       1        |    1     |   X    | X X  |  X   |   X   |   0   |
   +----------------+----------+--------+------+------+-------+-------+
              Table 2: MQTT CONNECT Flags (Rsvd. = Reserved)
   The Client SHOULD set the Clean flag to 1 to always start a new
   Session.  If the Clean flag is set to 0, the Broker MUST resume
   communications with the Client based on the state from the current
   Session (as identified by the Client Identifier).  If there is no
   Session associated with the Client Identifier, the Broker MUST create
   a new Session.  The Broker MUST set the Session Present flag in the
   CONNACK packet accordingly, i.e., 0 to indicate a new Session to the
   Client and 1 to indicate that the existing Session is continued.  The
   Broker MUST still perform PoP validation on the provided Client
   token.  MQTT v3.1.1 does not use a Session Expiry Interval, and the
   Client expects that the Broker maintains the Session State after it
   disconnects.  However, the stored Session State can be discarded as a
   result of administrator action or policies (e.g., defining an
   automated response based on storage capabilities), and Brokers SHOULD
   implement administrative policies to limit misuse.
   The Client MAY set the Will Flag as desired (marked as "X" in
   Table 2).  User Name and Password flags MUST be set to 1 to ensure
   that the Payload of the CONNECT packet includes both the User Name
   and Password fields.  The MQTT User Name is a UTF-8-encoded string,
   and the MQTT Password is Binary Data.
   The CONNECT in MQTT v3.1.1 does not have a field to indicate the
   Authentication Method.  To signal that the User Name field contains
   an ACE token, this field MUST be prefixed with the keyword "ace",
   i.e., the User Name field is a concatenation of 'a', 'c', 'e', and
   the access token represented as:
             'U+0061'||'U+0063'||'U+0065'||UTF-8(access token)
                      Figure 11: User Name in CONNECT
   To this end, the access token MUST be encoded with base64url,
   omitting the "=" padding characters [RFC4648].
   The Password field MUST be set to the keyed message digest (MAC) or
   signature associated with the access token for PoP.  The Client MUST
   apply the PoP key on the challenge derived from the TLS session, as
   described in Section 2.2.4.2.1.
6.2.  Handling Authorization Errors
   Error handling is more primitive in MQTT v3.1.1 due to not having
   appropriate error fields, error codes, and server-side DISCONNECTs.
   Therefore, the Broker will disconnect on almost any error and may not
   keep the Session State, necessitating that clients make a greater
   effort to ensure that tokens remain valid and do not attempt to
   publish to topics that they do not have permissions for.  The
   following lists how the Broker responds to specific errors.
   CONNECT without a token:
           The tokenless CONNECT attempt MUST fail.  This is because the
           challenge-response-based PoP is not possible for MQTT v3.1.1.
           It is also not possible to support AS discovery since a
           CONNACK packet in MQTT v3.1.1 does not include a means to
           provide additional information to the Client.  Therefore, AS
           discovery needs to take place out of band.
   Client-Broker PUBLISH authorization failure:
           In the case of a failure, it is not possible to return an
           error in MQTT v3.1.1.  Acknowledgment messages only indicate
           success.  In the case of an authorization error, the Broker
           MUST ignore the PUBLISH packet and disconnect the Client.
           Also, as DISCONNECT packets are only sent from a Client to
           the Broker, the server disconnection needs to take place
           below the application layer.
   SUBSCRIBE authorization failure:
           In the SUBACK packet, the return code is 0x80, indicating
           failure for the unauthorized topic(s).  Note that, in both
           MQTT versions, a reason code is returned for each Topic
           Filter.
   Broker-Client PUBLISH authorization failure:
           When the Broker is forwarding PUBLISH packets to the
           subscribed Clients, it may discover that some of the
           subscribers are no longer authorized due to expired tokens.
           These token expirations MUST lead to disconnecting the Client
           rather than silently dropping messages.