RFC 9431: Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework

Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9431.¶

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

2. Authorizing Connection Requests

This section specifies how Client connections are authorized by the AS and verified by the MQTT Broker. Figure 1 shows the basic protocol flows during connection setup. The token request and response use the token endpoint at the AS, specified for HTTP-based interactions in Section 5.8 of the ACE framework [RFC9200]. Steps (D) and (E) are optional and use the introspection endpoint specified in Section 5.9 of the ACE framework [RFC9200]. The discussion in this document assumes that the Client and the Broker use HTTPS to communicate with the AS via these endpoints. The Client and the Broker use MQTT to communicate between them. The C-AS and Broker-AS communications MAY be implemented using protocols other than HTTPS, e.g., CoAP or MQTT. Whatever protocol is used for the C-AS and Broker-AS communications MUST provide mutual authentication, confidentiality protection, and integrity protection.¶

If the Client is resource constrained or does not support HTTPS, a separate Client Authorization Server may carry out the token request on behalf of the Client (Figure 1, steps (A) and (B)) and, later, onboard the Client with the token. The interactions between a Client and its Client Authorization Server for token onboarding and support for MQTT-based token requests at the AS are out of the scope of this document.¶

                              +---------------------+
                              | Client              |
                              |                     |
   +---(A) Token request------| Client -            |
   |                          | Authorization       |
   |   +-(B) Access token-----> Server Interface    |
   |   |                      |       (HTTPS)       |
   |   |                      |_____________________|
   |   |                      |                     |
+--v-------------+            |  Pub/Sub Interface  |
|  Authorization |            |   (MQTT over TLS)   |
|  Server        |            +----------------^----+
|________________|                 |           |
   |    ^                 (C) Connection   (F) Connection
   |    |                     request +        response
   |    |                     access token     |
   |    |                          |           |
   |    |                      +---v--------------+
   |    |                      |     Broker       |
   |    |                      |  (MQTT over TLS) |
   |    |                      |__________________|
   |    +(D) Introspection-----|                  |
   |         request (optional)| RS-AS interface  |
   |                           |     (HTTPS)      |
   +-(E) Introspection-------->|__________________|
         response (optional)

0             8             16
+---------------------------+
|Protocol name length = 4   |
+---------------------------+
|     'M'            'Q'    |
+---------------------------+
|     'T'            'T'    |
+---------------------------+
|Proto.level=5|Connect flags|
+---------------------------+
|        Keep alive         |
+---------------------------+
| CONNECT Properties Length |
|      (up to 4 bytes)      |
+---------------------------+
| ( ..Other properties..)   |
+---------------------------+
|  Authentication Method    |
|      (0x15)  |   Len      |
|      Len     |   'a'      |
|      'c'     |   'e'      |
+---------------------------+
|  Authentication Data      |
|     (0x16)   |    Len     |
|      Len     |   token    |
|  or token + PoP data      |
+---------------------------+

+-----------------------------------------------------------------+
|Authentication|Token Length|Token   |MAC or Signature            |
|Data Length   |            |        |(over TLS exporter content) |
+-----------------------------------------------------------------+

+------------------------------------+
|Authentication|Token Length|Token   |
|Data Length   |            |        |
+------------------------------------+

+--------------------------+
|Authentication|RS Nonce   |
|Data Length   |(8 bytes)  |
+--------------------------+

+---------------------------------------------------------+
|Authentication|Client Nonce |MAC or Signature            |
|Data Length   |(8 bytes)    |(over RS nonce+Client nonce)|
+---------------------------------------------------------+

Client      Broker
 |             |
 |<===========>| TLS connection setup
 |             |
 |             |
 +------------>| CONNECT with Authentication Data
 |             | contains only token
 |             |
 <-------------+ AUTH 0x18 (Cont. Authentication)
 |             | 8-byte RS nonce as challenge
 |             |
 |------------>| AUTH 0x18 (Cont. Authentication)
 |             | 8-byte Client nonce + signature/MAC
 |             |
 |             |---+ Token validation
 |             |   | (may involve introspection)
 |             |<--+
 |             |
 |<------------+ CONNACK 0x00 (Success)

 AIF-MQTT = AIF-Generic<mqtt-topic-filter, mqtt-permissions>
 AIF-Generic<Toid, Tperm> = [* [Toid, Tperm]]
 mqtt-topic-filter = tstr ; as per Section 4.7 of MQTT v5.0
 mqtt-permissions = [+permission]
 permission = "pub"/"sub"

 [["topic1",["pub","sub"]],["topic2/#",["pub"]],["+/topic3",["sub"]]]

3. Authorizing PUBLISH and SUBSCRIBE Packets

Using the cached token or its introspection result, the Broker uses the scope field to match against the Topic Name in a PUBLISH packet or a Topic Filter in a SUBSCRIBE packet.¶

4. Token Expiration, Update, and Reauthentication

The Broker MUST check for token expiration whenever a CONNECT, PUBLISH, or SUBSCRIBE packet is received or sent. The Broker SHOULD check for token expiration on receiving a PINGREQ packet. The Broker MAY also check for token expiration periodically, e.g., every hour. This may allow for early detection of a token expiry.¶

The token expiration is checked by checking the "exp" claim of a JWT or introspection response or via performing an introspection request with the AS, as described in Section 5.9 of the ACE framework [RFC9200]. Token expirations may trigger the Broker to send PUBACK, SUBACK, and DISCONNECT packets with the return code set to "Not authorized". After sending a DISCONNECT packet, the Network Connection is closed, and no more messages can be sent.¶

The Client MAY reauthenticate a response to PUBACK and SUBACK, which signal loss of authorization. The Clients MAY also proactively update their tokens, i.e., before they receive a packet with a "Not authorized" return code. To start reauthentication, the Client MUST send an AUTH packet with reason code 0x19 (Reauthentication). The Client MUST set the Authentication Method as "ace" and transport the new token in the Authentication Data. If reauthenticating during the current TLS session, the Client MUST NOT use the method described in Section 2.2.4.2.1, i.e., proof of possession using a challenge from the TLS session, to avoid reusing the same challenge value from the TLS-Exporter. Note that this means that servers will either need to record in the session ticket or database entry whether the TLS-Exporter-derived challenge was used or always deny use of the TLS-Exporter-derived challenge for resumed sessions. In TLS 1.3, the resumed connection would have a new exporter value, but the requirement is phrased this way for simplicity. For reauthentications in the same TLS-session, the Client MUST use the challenge-response PoP, as defined in Section 2.2.4.2.2. The Broker accepts reauthentication requests if the Client has already submitted a token (may be expired), for which it performed proof of possession. Otherwise, the Broker MUST deny the request. If the reauthentication fails, the Broker MUST send a DISCONNECT packet with reason code 0x87 (Not Authorized).¶

5. Handling Disconnections and Retained Messages

In the case of a Client DISCONNECT, if the Session Expiry Interval is set to 0, the Broker doesn't store the Session State but MUST keep the retained messages. If the Broker stores the Session State, the state MAY include the token and its introspection result (for reference tokens) in addition to the MQTT Session State. The MQTT Session State is identified by the Client Identifier and includes the following:¶

The token/introspection state is not part of the MQTT Session State, and PoP validation is required for each new connection, regardless of whether existing MQTT Sessions are continued.¶

The messages to be retained are indicated to the Broker by setting a RETAIN flag in a PUBLISH packet. This way, the publisher signals to the Broker to store the most recent message for the associated topic. Hence, the new subscribers can receive the last sent message from the publisher for that particular topic without waiting for the next PUBLISH packet. The Broker MUST continue publishing the retained messages as long as the associated tokens are valid. In the MQTT standard, if QoS is 0 for the PUBLISH packet, the Broker may discard the retained message any time. For QoS > 1, the message expiry interval dictates how long the retained message is kept. However, it is important that the Broker avoids sending messages indefinitely for the Clients that never update their tokens (i.e., the Client connects briefly with a valid token, sends a PUBLISH packet with the RETAIN flag set to 1 and QoS > 1, disconnects, and never connects again). Therefore, the Broker MUST use the minimum of the token expiry and message expiry interval to discard a retained message.¶

In case of disconnections due to network errors or server disconnection due to a protocol error (which includes authorization errors), the Will Message is sent if the Client supplied a Will in the CONNECT packet. The Client's token scope array MUST include the Will Topic. The Will Message MUST be published to the Will Topic, regardless of whether the corresponding token has expired (as it has been validated and accepted during CONNECT).¶

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

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)         |
+---------------------------+

'U+0061'||'U+0063'||'U+0065'||UTF-8(access token)

7. IANA Considerations

8. Security Considerations

This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework [RFC9200]. Therefore, the security considerations outlined in [RFC9200] apply to this work.¶

In addition, the security considerations outlined in the MQTT v5.0 OASIS Standard [MQTT-OASIS-Standard-v5] and MQTT v3.1.1 OASIS Standard [MQTT-OASIS-Standard-v3.1.1] apply. Mainly, this document provides an authorization solution for MQTT, the responsibility of which is left to the specific implementation in the MQTT standards. In the following, we comment on a few relevant issues based on the current MQTT specifications.¶

After the Broker validates an access token and accepts a connection from a client, it caches the token to authorize a Client's publish and subscribe requests in an ongoing Session. The Broker does not cache any tokens that cannot be validated. If a Client's permissions get revoked, but the access token has not expired, the Broker may still grant publish/subscribe to revoked topics. If the Broker caches the token introspection responses, then the Broker SHOULD use a reasonable cache timeout to introspect tokens regularly. The timeout value is application specific and should be chosen to reduce the risk of using stale introspection responses. When permissions change dynamically, it is expected that the AS also follows a reasonable expiration strategy for the access tokens.¶

The Broker may monitor Client behavior to detect potential security problems, especially those affecting availability. These include repeated token transfer attempts to the public "authz-info" topic, repeated connection attempts, abnormal terminations, and Clients that connect but do not send any data. If the Broker supports the public "authz-info" topic, described in Section 2.2.2, then this may be vulnerable to a DDoS attack, where many Clients use the "authz-info" public topic to transport tokens that are not meant to be used and that the Broker may need to store until they expire.¶

For MQTT v5.0, when a Client connects with a long Session Expiry Interval, the Broker may need to maintain the Client's MQTT Session State after it disconnects for an extended period. For MQTT v3.1.1, the Session State may need to be stored indefinitely, as it does not have a Session Expiry Interval feature. The Broker SHOULD implement administrative policies to limit misuse by the Client resulting from continuing existing Sessions.¶

9. Privacy Considerations

The privacy considerations outlined in [RFC9200] apply to this work.¶

In MQTT, the Broker is a central trusted party and may forward potentially sensitive information between Clients. The mechanisms defined in this document do not protect the contents of the PUBLISH packet from the Broker, and hence, the content of the PUBLISH packet is not signed or encrypted separately for the subscribers. This functionality may be implemented using the proposal outlined in the ACE Pub-Sub Profile [ACE-PUBSUB-PROFILE]. However, this solution would still not provide privacy for other fields of the packet, such as Topic Name.¶

Appendix A. Checklist for Profile Requirements

Based on the requirements on profiles for the ACE framework [RFC9200], this document fulfills the following:¶

Acknowledgments

The authors would like to thank Ludwig Seitz for his review and his input on the authorization information endpoint; Benjamin Kaduk for his review, insightful comments, and contributions to resolving issues; and Carsten Bormann for his review and revisions to the AIF-MQTT data model. The authors would like to thank Paul Fremantle for the initial discussions on MQTT v5.0 support.¶

Authors' Addresses