RFC 9431
Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework
Part 1 of 9 🎀
Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework 🦋
Okay bestie, let's do the vibe check first 💅 This is RFC 9431 (Request for Comments 9431), a Standards Track document from the Internet Engineering Task Force (IETF) with ISSN 2070-1721. It was published in July 2023. The authors are C. Sengul (Brunel University) and A. Kirby (Oxbotica). Its header doesn't list anything it obsoletes or updates, so no drama there 🙈
Abstract 🌸
Here's the tea ☕ This document is a profile for the ACE framework, and it's all about authorization in a publish-subscribe messaging system built on Message Queuing Telemetry Transport (MQTT). Proof-of-Possession keys, bound to OAuth 2.0 access tokens, are what get used to authenticate and authorize MQTT Clients 🔑 The protocol leans on TLS for confidentiality and for authenticating the MQTT server (Broker). Main character energy, honestly ✨
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.
Table of Contents 🗂️
1. Introduction
1.1. Requirements Language
1.2. ACE-Related Terminology
1.3. MQTT-Related Terminology
2. Authorizing Connection Requests
2.1. Client Token Request to the Authorization Server (AS)
2.2. Client Connection Request to the Broker (C)
2.2.1. Overview of Client-RS Authentication Methods over TLS
and MQTT
2.2.2. authz-info: The Authorization Information Topic
2.2.3. Client Authentication over TLS
2.2.3.1. Raw Public Key Mode
2.2.3.2. Pre-Shared Key Mode
2.2.4. Client Authentication over MQTT
2.2.4.1. Transporting the Access Token inside the MQTT
CONNECT
2.2.4.2. Authentication Using the AUTH Property
2.2.5. Broker Token Validation
2.3. Token Scope and Authorization
2.4. Broker Response to Client Connection Request
2.4.1. Unauthorized Request and the Optional Authorization
Server Discovery
2.4.2. Authorization Success
3. Authorizing PUBLISH and SUBSCRIBE Packets
3.1. PUBLISH Packets from the Publisher Client to the Broker
3.2. PUBLISH Packets from the Broker to the Subscriber Clients
3.3. Authorizing SUBSCRIBE Packets
4. Token Expiration, Update, and Reauthentication
5. Handling Disconnections and Retained Messages
6. Reduced Protocol Interactions for MQTT v3.1.1
6.1. Token Transport
6.2. Handling Authorization Errors
7. IANA Considerations
7.1. TLS Exporter Labels Registration
7.2. Media Type Registration
7.3. ACE OAuth Profile Registration
7.4. AIF
8. Security Considerations
9. Privacy Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Checklist for Profile Requirements
Acknowledgments
Authors' Addresses1. Introduction 💖
Okay so this doc is a profile for the ACE framework [RFC9200] 💜 Clients and Servers (Brokers) use MQTT to swap Application Messages, and TLS handles communication security between the entities. The MQTT interactions are described based on the MQTT v5.0 OASIS Standard [MQTT-OASIS-Standard-v5]. Since MQTT deployments are expected to keep supporting MQTT v3.1.1 Clients, this document also describes a reduced set of protocol interactions for the MQTT v3.1.1 OASIS Standard [MQTT-OASIS-Standard-v3.1.1]. ngl, MQTT v5.0 is the RECOMMENDED version, because it works more naturally with ACE-style authentication and authorization 🫶
MQTT is a publish-subscribe protocol. After connecting to the MQTT Server (Broker), a Client can publish and subscribe to multiple topics 🍓 The Broker acts as the Resource Server (RS) and is responsible for distributing messages published by the publishers to their subscribers. In the rest of the document, the terms "RS", "MQTT Server", and "Broker" are used interchangeably.
Messages are published under a Topic Name, and subscribers subscribe to Topic Names to receive the matching messages. The Broker uses the Topic Name in a published message to figure out which subscribers to relay the message to. In this document, topics (more specifically, Topic Names) are treated as resources. The Clients are assumed to have identified the publish/subscribe topics of interest out of band (topic discovery is not a feature of the MQTT protocol). A Resource Owner can preconfigure policies at the Authorization Server (AS) that give Clients publish or subscribe permissions to different topics 🧚
Clients prove their permission to publish and subscribe to topics hosted on an MQTT Broker using an access token that is bound to a Proof-of-Possession (PoP) key. This document describes how to authorize the following exchanges between the Clients and the Broker:
- connection requests from the Clients to the Broker
- publish requests from the Clients to the Broker and from the Broker to the Clients
- subscribe requests from the Clients to the Broker
Clients use the MQTT PUBLISH packet to publish to a topic. The mechanisms specified in this document do not protect the Payload of the PUBLISH packet from the Broker. Hence, the Payload is not signed or encrypted specifically for the subscribers. This functionality may be implemented using the proposal outlined in the ACE Pub-Sub Profile [ACE-PUBSUB-PROFILE] 👑
To provide communication confidentiality and Broker authentication to the MQTT Clients, TLS is used, and TLS 1.3 [RFC8446] is RECOMMENDED. This document makes the same assumptions as Section 4 of the ACE framework [RFC9200] regarding Client and RS registration with the AS for setting up the keying material. While the Client-Broker exchanges are only over MQTT, the required Client-AS and RS-AS interactions are described for HTTPS-based communication [RFC9110], using the "application/ace+json" content type and, unless otherwise specified, JSON encoding. The token MAY be an opaque reference to authorization information or a JSON Web Token (JWT) [RFC7519]. For JWTs, this document follows [RFC7800] for PoP semantics for JWTs, and the mechanisms for providing and verifying PoP are detailed in Section 2.2. The Client-AS and RS-AS exchanges MAY also use protocols other than HTTP, e.g., Constrained Application Protocol (CoAP) [RFC7252] or MQTT. It is recommended that TLS is used to secure these communication channels between Client-AS and RS-AS. To reduce the protocol memory and bandwidth requirements, implementations MAY also use the "application/ace+cbor" content type, Concise Binary Object Representation (CBOR) encoding [RFC8949], CBOR Web Tokens (CWTs) [RFC8392], and associated PoP semantics. For more information, see "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)" [RFC8747]. A JWT uses JSON Object Signing and Encryption (JOSE), while a CWT uses CBOR Object Signing and Encryption (COSE) [RFC9052] for security protection 🌈
1.1. Requirements Language 📏
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
1.2. ACE-Related Terminology 🧠
Certain security-related terms, such as "authentication", "authorization", "data confidentiality", "(data) integrity", "message authentication code" (MAC), and "verify", are taken from [RFC4949].
The terminology for entities in the architecture is defined in OAuth 2.0 [RFC6749], such as "Client" (C), "Resource Server" (RS), and "Authorization Server" (AS).
The term "resource" is used to refer to an MQTT Topic Name, which is defined in Section 1.3. Hence, the "Resource Owner" is any entity that can authoritatively speak for the topic. This document also defines a Client Authorization Server for Clients that are not able to support HTTP.
Client Authorization Server (CAS) An entity that prepares and endorses authentication and authorization data for a Client and communicates to the AS using HTTPS. 🦋
1.3. MQTT-Related Terminology 💖
okay so this bit is the MQTT vocab list, and it's the foundation for everything else, so pay attention bestie 🫶 The doc talks about message exchanges as MQTT protocol interactions. The Clients are MQTT Clients, and they connect to the Broker to publish and subscribe to Application Messages, which are labeled with their topics. If you want the full deets, check out the MQTT v5.0 OASIS Standard [MQTT-OASIS-Standard-v5] or the MQTT v3.1.1 OASIS Standard [MQTT-OASIS-Standard-v3.1.1] 📚✨
Broker The Server in MQTT. It's the middle-person between the Clients that publish Application Messages and the Clients that made Subscriptions. The Broker acts as the Resource Server for the Clients 👑
Client A device or program that uses MQTT 🎀
Network Connection A construct provided by the underlying transport protocol that MQTT is using. It connects the Client to the Server, and it gives you an ordered, lossless stream of bytes in both directions 🌊 This document uses TLS as the transport protocol 🔒
Session A stateful interaction between a Client and a Broker. Some Sessions only last as long as the Network Connection, while others can span multiple Network Connections 🧚
Application Message The data carried by the MQTT protocol. The data has an associated Quality-of-Service (QoS) level and Topic Name 💌
MQTT Control Packet MQTT runs by swapping a series of MQTT Control Packets 🔁 Each packet is made of a Fixed Header, a Variable Header (depending on the Control Packet type), and a Payload.
UTF-8-encoded string A string with a two-byte-length field in front of it, which gives the number of bytes in the UTF-8-encoded string itself. Unless stated otherwise, every UTF-8-encoded string can have any length from 0 to 65535 bytes 🍓
Binary Data Binary Data is represented by a two-byte-length field, which tells you how many data bytes come next, followed by that many bytes. So the length of Binary Data is limited to 0 to 65535 bytes 💜
Variable Byte Integer A Variable Byte Integer uses an encoding scheme where a single byte covers values up to 127. For bigger values, the least significant seven bits of each byte hold the data, and the most significant bit says whether more bytes follow in the representation. So each byte encodes 128 values and a "continuation bit" 🧠 The maximum number of bytes in the Variable Byte Integer field is four.
QoS level The level of assurance for delivering an Application Message. The QoS level can be 0-2, where 0 means "At most once delivery", 1 means "At least once delivery", and 2 means "Exactly once delivery" 🎯
Property The last field of the Variable Header is a set of properties for several MQTT Control Packets (e.g., CONNECT and CONNACK). A property has an Identifier that defines its usage and data type, followed by a value. The Identifier is encoded as a Variable Byte Integer. For example, the "Authentication Data" property uses the identifier 22 🌸
Topic Name The label attached to an Application Message, which gets matched to a Subscription 🏷️
Subscription A Subscription is made of a Topic Filter and a maximum QoS. Each Subscription is associated with a single Session 📬
Topic Filter An expression that shows interest in one or more Topic Names. Topic Filters may include wildcards ✨
MQTT sends various Control Packets across a Network Connection. This list isn't exhaustive, and the Control Packets that don't matter for authorization aren't explained. So you won't see things like the PUBREL and PUBCOMP packets, which show up in the 4-step handshake required for QoS level 2 🙈
CONNECT The Client requests to connect to the Broker. This is the first packet a Client sends 🚪
CONNACK The Broker connection acknowledgment. CONNACK packets contain return codes that indicate either success or an error state, in response to a Client's CONNECT packet ✅
AUTH An AUTH Control Packet is sent from the Client to the Broker, or from the Broker to the Client, as part of an extended authentication exchange. AUTH properties include the Authentication Method and Authentication Data. The Authentication Method is set in the CONNECT packet, and the consequent AUTH packets follow that same Authentication Method. The contents of the Authentication Data are defined by the Authentication Method 🔐
PUBLISH A publish request sent from a publishing Client to the Broker, or from the Broker to a subscribing Client 📣
PUBACK The response to a PUBLISH request with QoS level 1. PUBACK can be sent from the Broker to a Client, or from a Client to the Broker 👍
PUBREC The response to a PUBLISH request with QoS level 2. PUBREC can be sent from the Broker to a Client, or from a Client to the Broker 🫧
SUBSCRIBE A subscribe request sent from a Client 📝
SUBACK The subscribe acknowledgment from the Broker to the Client 💅
PINGREQ A ping request sent from a Client to the Broker. It tells the Broker that the Client is alive, and it's used to confirm that the Broker is also alive. The "Keep Alive" period is set in the CONNECT packet 💓
PINGRESP The response the Broker sends to the Client after a PINGREQ. It shows the Broker is alive 🏓
DISCONNECT The DISCONNECT packet is the final MQTT Control Packet sent from the Client or the Broker. It says why the Network Connection is being closed. If the Network Connection gets closed without the Client first sending a DISCONNECT packet with reason code 0x00 (Normal disconnection), and the MQTT Connection has a Will Message, then the Will Message is published 👋
Will If the Network Connection isn't closed normally, the Broker sends a last Will Message for the Client, as long as the Client gave one in its CONNECT packet. Situations where the Will Message gets published include, but aren't limited to, the following:
- an I/O error or network failure detected by the Broker,
- the Client fails to communicate within the Keep Alive period,
- the Client closes the Network Connection without first sending a DISCONNECT packet with reason code 0x00 (Normal disconnection), and
- the Broker closes the Network Connection without first receiving a DISCONNECT packet with reason code 0x00 (Normal disconnection).
If the Will Flag is set in the CONNECT flags, then the Payload of the CONNECT packet includes info about the Will. That info is made of the Will Properties, Will Topic, and Will Payload fields 🧸
2. Authorizing Connection Requests 🦋
okay this section is where the actual auth flow lives, so it's giving important 🔥 It says how Client connections get 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, which is specified for HTTP-based interactions in Section 5.8 of the ACE framework [RFC9200]. Steps (D) and (E) are optional, and they use the introspection endpoint specified in Section 5.9 of the ACE framework [RFC9200]. The discussion here assumes that the Client and the Broker use HTTPS to talk to the AS through these endpoints. The Client and the Broker use MQTT to talk to each other. 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 doesn't support HTTPS, a separate Client Authorization Server may carry out the token request on the Client's behalf (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)
Figure 1: Connection Setup2.1. Client Token Request to the Authorization Server (AS) 🎟️
okay so step one of the whole flow (Figure 1, step (A)) is the Client grabbing its token from the AS. bestie, the Client and the AS MUST perform mutual authentication, so they both have to prove who they are first 🫶. Then the Client asks the AS for an access token, the way Section 5.8.1 of the ACE framework [RFC9200] describes ✨. This document follows the DTLS profile procedures from Section 3.2.1 of [RFC9202] for raw public keys (RPKs) [RFC7250]) and from Section 3.3.1 of [RFC7250] for pre-shared keys (PSKs) 🔑. The one twist is that the request's content type is application/ace+json, and the AS uses JSON in the Payload of its responses to both the Client and the RS 💅. As we covered earlier, implementations MAY also use application/ace+cbor as the content type 🌸.
when the AS gets the token request, it checks it out 👀. If the AS successfully verifies the access token request and authorizes the Client for the indicated audience (i.e., RS) and scopes (i.e., publish/subscribe permissions over topics, as described in Section 2.3), it issues an access token (Figure 1, step (B)) 🦋. this is the moment the Client gets its pass, periodt 🎀.
the response includes the parameters from Section 5.8.2 of the ACE framework [RFC9200] 📜. For RPKs, the parameters are the ones in Section 3.2.1 of the DTLS profile [RFC9202], and for PSKs, this document follows Section 3.3.1 of the DTLS profile [RFC9202] 🧚. Either way, if the response has an ace_profile parameter, it gets set to mqtt_tls 💜. And by default, the returned token is a Proof-of-Possession (PoP) token 🔐.
this document follows [RFC7800] for PoP semantics for JWTs (CWTs MAY also be used) ✨. The AS puts a cnf (confirmation) parameter in the PoP token to say the Client has a certain key, and the RS can cryptographically confirm that the Client really holds that key, as described in [RFC9201] 🔥. it's giving proof, no cap 💅.
hold up, the contents of these web tokens (including the cnf parameter) are for the RS to read, NOT the Client 🙈. the Client gets its key info some other way. The RPK case is handled as described in Section 3.2.1 of the DTLS profile [RFC9202] 🌈. For the PSK case, the referenced procedures apply, with a few exceptions so they work with JWT and JOSE 🍓. Here the AS adds a cnf parameter to the Access Information, carrying a JSON Web Key (JWK) [RFC7517] object 🗝️. That object holds either the symmetric key itself or a key identifier, which lets the RS figure out which secret key it shares with the Client 👑. The JWT gets created as explained in Section 7 of [RFC7519], and the JWT MUST include a JSON Web Encryption (JWE) [RFC7516] 🔒. If a CWT/COSE is used instead, this information MUST be inside the COSE_Key object, and it MUST be encrypted using a COSE_Encrypt0 structure 🧁.
for error responses on JSON-based interactions, the AS follows Section 5.2 of [RFC6749] 🙅♀️. When CBOR is used, the interactions MUST implement the procedure described in Section 5.8.3 of the ACE framework [RFC9200] 🦄.
2.2. Client Connection Request to the Broker (C) 🚪
2.2.1. Overview of Client-RS Authentication Methods over TLS and MQTT 🔐
okay so unless the Client only ever touches public topics, the Client and the Broker MUST perform mutual authentication 🤝. The Client MUST authenticate to the Broker over MQTT or TLS before doing anything else 🙌. For MQTT, the options are "None" and "ace" 💫. For TLS, the options are "Anon" for an anonymous client, and "Known(RPK/PSK)" for RPKs and PSKs 🌸. The "None" and "Anon" options don't give you client authentication, but they can be used during authentication or together with authentication at the other layer 🦋. When the Client uses TLS:Anon,MQTT:None, it can ONLY publish or subscribe to public topics 🙈. So the client authentication procedures come in these possible combinations:
TLS:Anon,MQTT:None: this is only for topics that don't need authorization, including theauthz-infotopic 🌷. Publishing toauthz-infois covered in Section 2.2.2 📬.TLS:Anon,MQTT:ace: the token rides inside the CONNECT packet and MUST be validated using one of the methods in Section 2.2.2 🎫. This option also supports a tokenless connection request for AS discovery 🔍. Per the ACE framework [RFC9200], a separate step is needed to figure out whether the discovered AS URI is authorized to act as an AS 🧐.TLS:Known(RPK/PSK),MQTT:none: this spec supports client authentication with TLS using RPKs and PSKs, following the procedures in the DTLS profile [RFC9202] 💖. For the RPK, the Client MUST have published the token to theauthz-infotopic 📮. For the PSK, the token MAY be published to theauthz-infotopic, or MAY alternatively be given as a "PSK identity" (e.g., an "identity" in the "identities" field in the Client's "pre_shared_key" extension in TLS 1.3) ✨.TLS:Known(RPK/PSK),MQTT:ace: this option SHOULD NOT be chosen, because the token sent in the CONNECT packet overwrites any permissions passed during TLS authentication 🙅♀️.
it is RECOMMENDED that the Client implements TLS:Anon,MQTT:ace as its first choice when working with protected topics 🥇. However, MQTT v3.1.1 Clients that don't want to overload the User Name and Password fields for ACE (as described in Section 6) MAY implement TLS:Known(RPK/PSK),MQTT:none and, as a result, TLS:Anon,MQTT:None to submit their token to authz-info 💅.
the Broker MUST support TLS:Anon,MQTT:ace 🏠. To support Clients with different capabilities, the Broker MAY provide multiple client authentication options, e.g., support TLS:Known(RPK),MQTT:none and TLS:Anon,MQTT:None to enable RPK-based client authentication 🧩.
the Client MUST authenticate the Broker during the TLS handshake 🤓. If the Client authentication uses TLS:Known(RPK/PSK), the Broker gets authenticated using that respective method 🌈. Otherwise, to authenticate the Broker, the Client MUST validate a public key from an X.509 certificate, or an RPK from the Broker, against the rs_cnf parameter in the token response 🔑. That parameter has info about the public key the RS uses to authenticate if the token type is "pop" and asymmetric keys are used, as defined in [RFC9201] 🎀. The AS MAY include the thumbprint of the RS's X.509 certificate in the rs_cnf (thumbprint, as defined in [RFC9360]) 🧁. In that case, the Client MUST validate the RS certificate against this thumbprint 🫶.
2.2.2. authz-info: The Authorization Information Topic 📭
so, in the cases where the Client has to hand the token to the Broker first, the Client connects to the Broker to publish its token to the authz-info topic 💌. The authz-info topic MUST only be published to (the Clients aren't allowed to subscribe to it) 🚫. authz-info isn't protected, so the Client uses the TLS:Anon,MQTT:None option over a TLS connection 🌸. After publishing the token, the Client disconnects from the Broker and is expected to reconnect with client authentication over TLS (i.e., TLS:Known(RPK/PSK),MQTT:none) 🦋.
the Broker stores and indexes every token it receives on the authz-info topic in its key store (similar to the DTLS profile for ACE [RFC9202]) 🗂️. This profile follows the recommendation of Section 5.10.1 of the ACE framework [RFC9200] and expects that the Broker stores only one token per PoP key, with any other token linked to the same key overwriting an existing one 💜.
the Broker MUST verify the validity of the token (i.e., through local validation or introspection if the token is a reference), as described in Section 2.2.5 ✅. If the token isn't valid, the Broker MUST discard the token 🗑️.
depending on the QoS level of the PUBLISH packet, the Broker returns the error response as a PUBACK, PUBREC, or DISCONNECT packet 🎭. If the QoS level equals 0, and the token isn't valid, or if the claims can't be obtained for an introspected token, the Broker MUST send a DISCONNECT packet with reason code 0x87 (Not authorized) 🙈. If the PUBLISH Payload doesn't parse to a token, the Broker MUST send a DISCONNECT with reason code 0x99 (Payload format invalid) 💀.
if the QoS level of the PUBLISH packet is greater than or equal to 1, and the token isn't valid, or the claims can't be obtained for an introspected token, the Broker MUST send reason code 0x87 (Not authorized) in the PUBACK or PUBREC 🚨. If the PUBLISH Payload doesn't parse to a token, the PUBACK/PUBREC reason code is 0x99 (Payload format invalid) 🍓.
when the Broker sends the "Not authorized" response, it must be noted that this means the token isn't valid, and NOT that the actual PUBLISH packet was unauthorized 🧠. Since "authz-info" is a public topic, this response isn't expected to cause confusion 🫶.
2.2.3. Client Authentication over TLS 🔒
this document supports TLS with raw public keys (RPKs) [RFC7250] and with pre-shared keys (PSKs) 🌈. The TLS session setup follows the DTLS profile for ACE [RFC9202], since the profile applies to TLS just as well [RFC9430] ✨. Where there are exceptions to the DTLS profile, they're explicitly stated in this document 📝. If TLS 1.2 is used, [RFC7925] describes how TLS can be used for constrained devices, along with recommended cipher suites 🧁. Also, TLS 1.2 implementations MUST use the "Extended Main Secret" extension (terminology adopted from [TLS-bis]) to fold the handshake transcript into the main secret [RFC7627] 🔐. TLS implementations SHOULD use the Server Name Indication (SNI) [RFC6066] and Application-Layer Protocol Negotiation (ALPN) [RFC7301] extensions, so the TLS handshake authenticates as much of the protocol context as possible 💖.
2.2.3.1. Raw Public Key Mode 🗝️
this document follows the procedures defined in Section 3.2.2 of the DTLS profile for ACE [RFC9202], with the following exceptions 🎀. The Client MUST upload the access token to the Broker using the method specified in Section 2.2.2 before initiating the handshake 📮.
2.2.3.2. Pre-Shared Key Mode 🔑
okay so this one is basically the DTLS profile for ACE rules (Section 3.3.2 of [RFC9202]) with a few tweaks, so if you already know that, you're halfway there bestie 🫶
To use TLS 1.3 with pre-shared keys, the Client uses the PSK extension from [RFC8446], and the key it uses is the one that came in the "cnf" parameter of the AS response. That same key gets bound to the access token in the "cnf" claim. The Client can upload the token first (see Section 2.2.2) before it starts the handshake. When it's using a token that's already been uploaded, the Client MUST indicate during the handshake which one it means 🎯. To do that, it MUST create a "COSE_Key" or "JWK" structure with the "kid" from the "rs_cnf" claim in the AS token response, and the key type "symmetric" ✨. That structure becomes the only element in the "cnf" structure, and the encoded value of that "cnf" structure gets used as a PSK identity in TLS. Or, instead of uploading, the Client can just send its most recent access token (JWT or CWT) as a PSK identity. 💅
Here's the cipher suite tea 🍵. Unlike the DTLS profile for ACE [RFC9202], a Client MAY omit support for TLS_PSK_WITH_AES_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8. For TLS 1.2, though, a client MUST support TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 for PSKs [RFC8442] and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for RPKs [RFC8422], as recommended in [RFC9325] (and adjusted to be a PSK cipher suite as appropriate). It's giving very specific, and it's supposed to 😌
2.2.4. Client Authentication over MQTT 📬
2.2.4.1. Transporting the Access Token inside the MQTT CONNECT
okay so this section is about how the Client sneaks the token to the Broker inside the CONNECT packet 📦. If you go this route, the Client's TLS connection is expected to be anonymous, and the Broker gets authenticated during TLS setup. It's similar to an earlier idea from Fremantle, et al. [Fremantle14], so shoutout to them 🙌.
After sending CONNECT, the Client MUST wait to receive the CONNACK packet from the Broker. The only packets it's allowed to send are DISCONNECT, or AUTH in response to the Broker's AUTH. Likewise, apart from a DISCONNECT and an AUTH response from the Client, the Broker MUST NOT process any packets before it sends a CONNACK packet 🛑.
Figure 2 shows the MQTT v5.0 CONNECT packet layout. A CONNECT packet has a Fixed Header, a Variable Header, and a Payload. The Fixed Header holds the Control Packet Type (CPT), Reserved, and Remaining Length fields. Remaining Length is a Variable Byte Integer that counts the bytes left in the Control Packet, including the Variable Header and Payload data. The Variable Header has the Protocol Name, Protocol Level, Connect flags, Keep Alive, and Properties fields. The Connect flags set the properties of the MQTT Session, and they also say which fields show up in the Payload. The Payload holds one or more encoded fields: a unique Client Identifier for the Client, a Will Topic, Will Payload, User Name, and Password. Everything except the Client Identifier can be left out depending on the flags in the Variable Header. The Client Identifier is how the Client gets identified to the Broker, so it's unique for each Client. Heads up 🙈: the Client Identifier is an unauthenticated identifier used inside MQTT, so it is not bound to the access token.
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 |
+---------------------------+
Figure 2: MQTT v5 CONNECT Variable Header with Authentication
Method Property for ACEThe CONNECT flags are User Name, Password, Will Retain, Will QoS, Will Flag, Clean Start, and Reserved. Table 1 shows how the flags MUST be set to use AUTH packets for authentication and authorization, i.e., the User Name Flag and Password Flag MUST be set to 0 🧁. An MQTT v5.0 Broker MAY also support token transport using the User Name and Password, as a security option for MQTT v3.1.1 Clients, as described in Section 6.
+===========+==========+========+======+======+=======+==========+
| User Name | Password | Will | Will | Will | Clean | Reserved |
| Flag | Flag | Retain | QoS | Flag | Start | |
+===========+==========+========+======+======+=======+==========+
| 0 | 0 | X | X X | X | X | 0 |
+-----------+----------+--------+------+------+-------+----------+
Table 1: CONNECT Flags for AUTHThe Will Flag says a Will Message needs to be sent 📨. The Client MAY set the Will Flag as desired (marked as "X" in Table 1). If the Will Flag is set to 1, the Broker MUST check that the token allows the publication of the Will Message (i.e., the Will Topic Filter is in the scope array). That check runs against the token scope described in Section 2.3. If the Will authorization fails, the connection is refused, as described in Section 2.4.1. If the Broker accepts the connection request, it stores the Will Message and publishes it when the Network Connection is closed, according to Will QoS, Will Retain parameters, and MQTT Will management rules. To avoid publishing Will Messages during temporary network disconnections, the Client specifies a Will Delay Interval in the Will Properties. Section 5 explains how the Broker deals with retained messages in more detail.
In MQTT v5.0, the Client signals a new Session (i.e., that the Session does not continue an existing Session) by setting the Clean Start flag to 1 in the CONNECT packet 🌱. In this profile, the Client SHOULD always start with a new Session. The Broker MAY also signal that it does not support continuing an existing Session, by setting the Session Expiry Interval to 0 in the CONNACK. If the Broker starts a new Session, the Broker MUST set the Session Present flag to 0 in the CONNACK packet to tell the Client so.
The Broker MAY support continuing an existing Session, e.g., if the Broker needs it for QoS reasons 🔁. In this case, if a CONNECT packet arrives with Clean Start set to 0, and there's a Session associated with the Client Identifier, the Broker MUST resume communications with the Client based on the state from the existing Session. In its response, the Broker MUST set the Session Present flag to 1 in the CONNACK packet to signal the continuation of an existing Session to the Client. The Session State stored by the Client and the Broker is described in Section 5.
When reconnecting to a Broker that supports continuing existing Sessions, the Client MUST still provide a token, in addition to using the same Client Identifier and setting Clean Start to 0 🎟️. The Broker MUST still perform PoP validation on the provided token. If the token matches the stored state, the Broker MAY skip introspecting a token-by-reference and use the stored introspection result. The Broker MUST also verify that the Client is authorized to receive or send MQTT packets that are pending transmission. When a Client connects with a long Session Expiry Interval, the Broker might need to keep the Client's MQTT Session State after it disconnects for an extended period. Brokers SHOULD implement administrative policies to limit misuse 🚨.
Okay, this one is a little spicy 🌶️. According to the MQTT standard, the Broker uses the Client Identifier to identify the Session State. In the case of a Client Identifier collision, a Client may take over another Client's Session. Given that the Broker MUST associate the Client with a valid token, a Client will only send or receive messages to its authorized topics. So while this issue is not expected to affect security, it may affect QoS (i.e., PUBLISH or QoS messages saved for Client A may be delivered to a Client B). Also, if this Client Identifier represents a Client that's already connected to the Broker, the Broker sends a DISCONNECT packet to the existing Client with reason code 0x8E (Session taken over) and closes the connection to the Client 💀.
2.2.4.2. Authentication Using the AUTH Property
Figure 2 shows the Authentication Method and Authentication Data fields when the client authenticates using the AUTH property 🔐. The Client MUST set the Authentication Method as a property of a CONNECT packet, using the property identifier 21 (0x15). That's followed by a UTF-8-encoded string with the name of the Authentication Method, which MUST be set to "ace". If the Broker does not support this profile, it sends a CONNACK packet with reason code 0x8C (Bad authentication method).
The Authentication Method is followed by the Authentication Data, which has a property identifier 22 (0x16) and is Binary Data 🧩. Based on the Authentication Data, the Broker MUST support both options below:
- proof of possession using a challenge from the TLS session 🌸
- proof of possession via a Broker-generated challenge/response 🦋
2.2.4.2.1. Proof of Possession Using a Challenge from the TLS Session 🔐✨
okay so this one is giving "prove you actually hold the key" but make it TLS 💅 the Client doesn't just say "trust me," it does math over stuff pulled straight out of the TLS session. no cap, it's the cleanest vibe 🦋
+-----------------------------------------------------------------+
|Authentication|Token Length|Token |MAC or Signature |
|Data Length | | |(over TLS exporter content) |
+-----------------------------------------------------------------+Figure 3: Authentication Data for PoP Based on TLS Exporter Content
bestie, for this option the Authentication Data inside the Client's CONNECT packet MUST contain the two-byte integer token length, the token, and the keyed message digest (MAC) or the Client signature (as shown in Figure 3) 🎀. The Proof-of-Possession key in the token gets used to calculate that MAC or signature, based on content pulled from the TLS exporter ([RFC5705] for TLS 1.2 and Section 7.5 of [RFC8446] for TLS 1.3) 🌸. That content gets exported from the TLS session using the exporter label "EXPORTER-ACE-MQTT-Sign-Challenge", an empty context, and a length of 32 bytes ✨.
Then the token gets validated, as described in Section 2.2.5, and the Broker answers with a CONNACK packet carrying the appropriate response code 💜. One last thing, and it's a big one: the Client cannot reauthenticate with this method during the same TLS session (see Section 4) 🙈.
2.2.4.2.2. Proof of Possession via Broker-generated Challenge/Response 🧚
this is the "Broker goes first" flow and it's iconic 👑 the Broker starts the back-and-forth instead of the Client leading with the proof.
+------------------------------------+
|Authentication|Token Length|Token |
|Data Length | | |
+------------------------------------+
Figure 4: Authentication Data to Initiate PoP Based on Challenge/
Response +--------------------------+
|Authentication|RS Nonce |
|Data Length |(8 bytes) |
+--------------------------+
Figure 5: Authentication Data for Broker Challengeso for this option, the Broker runs a Broker-generated challenge/response protocol 🔄. If the Authentication Data inside the Client's CONNECT contains only the two-byte integer token length and the token (as shown in Figure 4), the Broker MUST respond with an AUTH packet with the authenticated reason code set to 0x18 (Continue Authentication) 💅. The Broker also uses this method if the Authentication Data doesn't contain a token, but the Broker has a token stored for the connecting Client 🫶.
The Broker keeps authentication going with an AUTH packet that contains the Authentication Method and the Authentication Data. The Authentication Method MUST be set to "ace", and the Authentication Data MUST NOT be empty and MUST contain an 8-byte RS nonce as a challenge for the Client (Figure 5) 🌈.
+---------------------------------------------------------+
|Authentication|Client Nonce |MAC or Signature |
|Data Length |(8 bytes) |(over RS nonce+Client nonce)|
+---------------------------------------------------------+
Figure 6: Authentication Data for the Client Challenge Responsethe Client responds with an AUTH packet with reason code 0x18 (Continue Authentication) 💖. Similarly, the Client packet sets the Authentication Method to "ace". The Authentication Data in the Client's response is formatted as shown in Figure 6, and it includes the 8-byte Client nonce plus the signature or MAC computed over the RS nonce concatenated with the Client nonce, using the PoP key in the token 🔐.
Next, the token gets validated as described in Section 2.2.5 ✨. The success case is illustrated in Figure 7. The Client MAY also reauthenticate using this challenge-response flow, as described in Section 4 🦋.
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)Figure 7: PoP Challenge/Response Flow - Success
2.2.5. Broker Token Validation 🕵️♀️
this is the big check where the Broker decides whether the token is legit 👑. The Broker MUST verify the validity of the token either locally (e.g., in the case of a self-contained token) or MAY send a request to the introspection endpoint of the AS (as described for HTTP-based interactions in Section 5.9 of the ACE framework [RFC9200]) 🧚. The Broker MUST verify the claims in the access token according to the rules set in Section 5.10.1.1 of the ACE framework [RFC9200] 💅.
To authenticate the Client, the Broker validates the signature or the MAC, depending on how the PoP protocol is implemented 🔍. For self-contained tokens, the Broker MUST process the security protection of the token first, as specified by the respective token format. That means a CWT uses COSE, while a JWT uses JOSE 🌸. For a token-by-reference, the Broker uses the "cnf" structure returned as a result of token introspection, as specified in [RFC7519]. HMAC-SHA-256 (HS256) [RFC6234] and Ed25519 [RFC8032] are mandatory to implement for the Broker. The Client MUST implement at least one of them, depending on the choice of symmetric or asymmetric validation 🎀. Validation of the signature or MAC MUST fail if the signature algorithm is set to "none", when the key used for the signature algorithm cannot be determined, or the computed and received signature/MAC do not match 🚫.
The Broker MUST check if the access token is still valid, if it is the intended destination (i.e., the audience) of the token, and if the token was issued by an authorized Authorization Server ✨. If the Client is using TLS RPK mode to authenticate to the Broker, the AS constructs the access token so that the Broker can associate the access token with the Client's public key. The "cnf" claim MUST contain either the Client's RPK or, if the key is already known by the Broker (e.g., from previous communication), a reference to it 🦋.
2.3. Token Scope and Authorization 🎀
the scope is basically the permission slip for what the Client can publish and subscribe to 💌. The scope field contains the publish and subscribe permissions for the Client. Therefore, the token or its introspection result MUST be cached to allow a Client's future PUBLISH and SUBSCRIBE messages 💾. During the CONNECT, if the Will Flag is set to 1, the Broker MUST also authorize the publication of the Will Topic and Will Message using the token's scope field 🫶. The Broker uses the scope to match against the Topic Name in a PUBLISH packet (including Will Topic in the CONNECT) or a Topic Filter in a SUBSCRIBE packet 🔎.
The scope in the token is a single value. For a JWT, the single scope is a base64url-encoded string with any padding characters removed, and it has an internal structure of a JSON array. For a CWT, this information is represented in CBOR 🧩. The internal structure follows the Authorization Information Format (AIF) for ACE [RFC9237]. Using the Concise Data Definition Language (CDDL) [RFC8610], the specific data model for MQTT is:
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"
Figure 8: AIF-MQTT Data ModelTopic Filters are implemented according to Section 4.7 of the MQTT v5.0 OASIS Standard [MQTT-OASIS-Standard-v5]. By default, Wildcard Subscriptions are supported, so the Topic Filter may include special wildcard characters 🌈. The multi-level wildcard, "#", matches any number of levels within a topic, and the single-level wildcard, "+", matches one topic level 🍓. The Broker MAY signal in the CONNACK explicitly whether Wildcard Subscriptions are supported, by returning a CONNACK property "Wildcard Subscription Available". A value of 0 means that Wildcard Subscriptions are not supported. A value of 1 means Wildcard Subscriptions are supported 📣.
Following this model, an example scope may contain:
[["topic1",["pub","sub"]],["topic2/#",["pub"]],["+/topic3",["sub"]]]
Figure 9: Example Scopethis access token gives publish ("pub") and subscribe ("sub") permissions to "topic1", publish permission to all the subtopics of "topic2", and subscribe permission to all "topic3", skipping one level 🧚♀️.
If the scope is empty, the Broker records no permissions for the Client for any topic. In this case, the Client is not able to publish or subscribe to any protected topics 🙅♀️. The non-empty scope is used to authorize the Will Topic, if provided in the CONNECT packet, during connection setup. If the connection request succeeds, the scope is also used for the Topic Names or Topic Filters requested in the future PUBLISH and SUBSCRIBE packets 💜. For the authorization to succeed, the Broker MUST verify that the Topic Name or Topic Filter in question is either an exact match to or a subset of at least one "topic_filter" in the scope 🔐.
2.4. Broker Response to Client Connection Request 📬
so once the Broker has checked everything, it sends back a verdict 💅. Based on the validation result (obtained either via local inspection or using the introspection interface of the AS), the Broker MUST send a CONNACK packet to the Client ✨.
2.4.1. Unauthorized Request and the Optional Authorization Server Discovery 🙈
okay the "nope" path 😭. Authentication can fail for the following reasons:
- if the Client does not provide a valid token,
- the Client omits the Authentication Data field and the Broker has no token stored for the Client,
- the token or Authentication data are malformed, or
- if the Will Flag is set, the authorization checks for the Will Topic fails.
The Broker responds with the CONNACK reason code 0x87 (Not Authorized) or any other applicable reason code 💀.
The Broker MAY also trigger AS discovery and include a User Property (identified as property type 38 (0x26)) in the CONNACK for the AS Request Creation Hints 🗺️. The User Property is a UTF-8 string pair, composed of a name and a value 🌸. The name of the User Property MUST be set to "ace_as_hint". The value of the User Property is a UTF-8-encoded JSON object containing the mandatory "AS" parameter and the optional parameters "audience", "kid", "cnonce", and "scope", as defined in Section 5.3 of the ACE framework [RFC9200] 🧾.
2.4.2. Authorization Success 🎉
yaaas, the good ending 🥳. On success, the reason code of the CONNACK is 0x00 (Success). If the Broker starts a new Session, it MUST also set Session Present to 0 in the CONNACK packet to signal a new Session to the Client. Otherwise, it MUST set Session Present to 1 🦋.
Having accepted the connection, the Broker MUST be prepared to store the token during the connection and after disconnection for future use 💾. If the token is not self-contained and the Broker uses token introspection, it MAY cache the validation result to authorize the subsequent PUBLISH and SUBSCRIBE packets. PUBLISH and SUBSCRIBE packets, which are sent after a connection setup, do not contain access tokens 🔁. If the introspection result is not cached, the Broker needs to introspect the saved token for each request. The Broker SHOULD also use a cache timeout to introspect tokens regularly. The timeout value is specific to the application and should be chosen to reduce the risk of using stale introspection responses ⏰.
3. Authorizing PUBLISH and SUBSCRIBE Packets ✨
okay so this is the bouncer checking the guest list 💅 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 🎀
3.1. PUBLISH Packets from the Publisher Client to the Broker
bestie, when the Broker gets a PUBLISH packet, it MUST use the type of packet (i.e., PUBLISH) and the Topic Name in the packet header to match against the scope array items in the cached token or its introspection result 🦋 Following the example in Section 2.3, a Client sending a PUBLISH packet for "topic2/a" would be allowed, because the scope array includes ["topic2/#",["pub"]]. it's giving access, fr fr ✨
If the Client is allowed to publish to the topic, the Broker publishes the message to all valid subscribers of the topic 💖 But if authorization fails, the Broker MUST return an error whenever the Client set the QoS level of the PUBLISH packet to greater than or equal to 1. Depending on the QoS level, the Broker answers with either a PUBACK or PUBREC packet carrying reason code 0x87 (Not authorized) 😭 When the Client gets an acknowledgment with 0x87 (Not authorized), it MAY reauthenticate by providing a new token, as described in Section 4 🔥
For QoS level 0, the Broker sends a DISCONNECT packet with reason code 0x87 (Not authorized) and closes the Network Connection 💀 Note that the server-side DISCONNECT is a new feature of MQTT v5.0 (in MQTT v3.1.1, the server needs to drop the connection). 🧚
For all QoS levels, the Broker MAY return 0x80 (Unspecified error) if they do not want to leak the Topic Names to unauthorized clients 🙈
3.2. PUBLISH Packets from the Broker to the Subscriber Clients
so when the Broker forwards PUBLISH packets to subscribing Clients, it figures out every subscriber with a valid matching Topic Subscription to the Topic Name of the PUBLISH packet 🌸 That means the tokens are valid, and the token scopes allow a Subscription to this particular Topic Name. Then the Broker forwards the PUBLISH packet to all the valid subscribers 🎀
The Broker MUST NOT forward messages to unauthorized subscribers, no exceptions 🙅♀️ To avoid silently dropping messages, the Broker MUST close the Network Connection and SHOULD inform the affected subscribers. the only way to tell a client is a DISCONNECT packet, so the Broker SHOULD send a DISCONNECT packet with reason code 0x87 (Not authorized) before closing the Network Connection to these clients 🫶
3.3. Authorizing SUBSCRIBE Packets
In MQTT, a SUBSCRIBE packet is sent from a Client to the Broker to create one or more Subscriptions to one or more topics. A single SUBSCRIBE packet may contain multiple Topic Filters, and those Topic Filters may include wildcard characters 🌈
On receiving the SUBSCRIBE packet, the Broker MUST use the type of packet (i.e., SUBSCRIBE) and the Topic Filter in the packet header to match against the scope field of the stored token or introspection result. The Topic Filters MUST be an exact match to, or be a subset of, at least one of the "topic_filter" fields in the scope array found in the Client's token 👑 For example, if the Client sends a SUBSCRIBE request for topic "a/b/*" and has a token that permits "a/*", this is a valid SUBSCRIBE request, because "a/b/*" is a subset of "a/*" ✨ (The process is similar to a Broker matching the Topic Name in a PUBLISH packet against the Subscriptions known to the Server. it's the same energy, just flipped 🦋)
As a response to the SUBSCRIBE packet, the Broker issues a SUBACK packet 💅 For each Topic Filter, the SUBACK packet includes a return code matching the QoS level for the corresponding Topic Filter. In the case of failure, the return code is 0x87, which means the Client is not authorized 😭 The Broker MAY return 0x80 (Unspecified error) if they do not want to leak the Topic Names to unauthorized clients. A reason code is returned for each Topic Filter, so the Client may get success codes for a subset of its Topic Filters while being unauthorized for the rest 🍓
4. Token Expiration, Update, and Reauthentication ⭐
the Broker MUST check for token expiration whenever a CONNECT, PUBLISH, or SUBSCRIBE packet is received or sent ⏰ It SHOULD check for token expiration on receiving a PINGREQ packet. It MAY also check for token expiration periodically, e.g., every hour, which may allow for early detection of a token expiry 🔍
The token expiration is checked by looking at the "exp" claim of a JWT, or the introspection response, or by 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. rip 🪦
The Client MAY reauthenticate in 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, so the same challenge value from the TLS-Exporter doesn't get reused 🙅♀️ Note that this means 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 (which may be expired) for which it performed proof of possession 🔐 Otherwise, the Broker MUST deny the request. And 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 it MUST keep the retained messages 💜 If the Broker does store the Session State, that 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 Client Subscriptions,
- messages with QoS levels 1 and 2, which have not been completely acknowledged or are pending transmission to the Client, and
- if the Session is currently not connected, the time at which the Session will end and the Session State will be discarded.
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 tells the Broker to store the most recent message for the associated topic. Hence, 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 to 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, bestie 🙈 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 🚚
okay bestie, so the token MAY be transported before, by publishing to the authz-info topic, or inside the CONNECT packet. That's the same as MQTT v5.0 ✨ If the Client sent the token via authz-info and won't update it in the CONNECT packet, it MUST authenticate over TLS 🔐 The Broker SHOULD still be ready to store the Client access token for later, no matter how it arrived 💅
In MQTT v3.1.1, once the Client publishes to authz-info, the Broker can't tell the Client how the token validation went, because PUBACK reason codes and server-side DISCONNECT packets aren't supported 😭 Anyway, the TLS handshake would fail without a valid token, and that can nudge the Client to go grab a new one 🎀
To send the token to the Broker inside the CONNECT packet, the Client uses the User Name and Password fields 🧚 Figure 10 shows what the MQTT CONNECT packet looks like:
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 ACETable 2 shows how the MQTT connect flags MUST be set to start 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 so it always starts a brand new Session 🍓 If the Clean flag is 0, the Broker MUST pick up communications with the Client based on the state from the current Session (as identified by the Client Identifier). If there's no Session linked to that Client Identifier, the Broker MUST create a new one. The Broker MUST set the Session Present flag in the CONNACK packet to match: 0 means a new Session, and 1 means the existing Session carried on 🦋 The Broker MUST still do PoP validation on the Client token, no excuses 💪 MQTT v3.1.1 doesn't have a Session Expiry Interval, so the Client expects the Broker to keep the Session State after it disconnects. But the stored Session State can get thrown out because of administrator action or policies (for example, an automated response based on storage capacity), so Brokers SHOULD set up administrative policies to limit misuse 🛡️
The Client MAY set the Will Flag however it likes (that's the "X" in Table 2) 🌈 The User Name and Password flags MUST be set to 1 so 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 doesn't have a field for the Authentication Method 🙃 So to say "hey, this User Name field has an ACE token in it," the User Name field MUST be prefixed with the keyword "ace". Basically the User Name is a mashup of a, c, e, and the access token, like this:
'U+0061'||'U+0063'||'U+0065'||UTF-8(access token)
Figure 11: User Name in CONNECTWith that in mind, the access token MUST be encoded with base64url, leaving off the = padding characters [RFC4648] ✨
The Password field MUST be set to the keyed message digest (MAC) or signature tied to the access token for PoP. The Client MUST apply the PoP key to the challenge derived from the TLS session, as described in Section 2.2.4.2.1 🔑
6.2. Handling Authorization Errors
Okay, error handling is more basic in MQTT v3.1.1, because there aren't the right error fields, error codes, or server-side DISCONNECTs 😩 So the Broker will disconnect on pretty much any error and might not keep the Session State. That means Clients need to work extra hard to keep their tokens valid and to avoid publishing to topics they don't have permission for 🫶 Here's how the Broker responds to specific errors:
CONNECT without a token: The tokenless CONNECT attempt MUST fail. The reason is that the challenge-response-based PoP isn't possible for MQTT v3.1.1 😤 AS discovery isn't possible either, since a CONNACK packet in MQTT v3.1.1 has no way to pass extra info to the Client. So AS discovery has to happen out of band 🧭
Client-Broker PUBLISH authorization failure: In MQTT v3.1.1 there's no way to send back an error here, since acknowledgment messages only say "success" 🙈 If there's an authorization error, the Broker MUST ignore the PUBLISH packet and disconnect the Client. Also, DISCONNECT packets only go from a Client to the Broker, so the server-side disconnection has to happen below the application layer 🔌
SUBSCRIBE authorization failure: In the SUBACK packet, the return code is 0x80, which means failure for the unauthorized topic(s). Heads up that in both MQTT versions, a reason code comes back for each Topic Filter 🍓
Broker-Client PUBLISH authorization failure: When the Broker forwards PUBLISH packets to subscribed Clients, it might find out that some subscribers aren't authorized anymore because their tokens expired 💀 These token expirations MUST lead to disconnecting the Client, rather than quietly dropping messages 🚪
7. IANA Considerations 📋
7.1. TLS Exporter Labels Registration
This document registers "EXPORTER-ACE-MQTT-Sign-Challenge" (introduced in Section 2.2.4.2.1 in this document) in the "TLS Exporter Labels" registry [RFC8447]. Here's the entry:
- Recommended:
N - DTLS-OK:
N - Reference:
RFC 9431
7.2. Media Type Registration
This document registers the "application/ace+json" media type for messages of the protocols defined in this document that carry parameters encoded in JSON 🎀 The details:
- Type name:
application - Subtype name:
ace+json - Required parameters:
N/A - Optional parameters:
N/A - Encoding considerations: Encoding considerations are identical to those specified for the "application/json" media type.
- Security considerations: Section 8 of RFC 9431
- Interoperability considerations:
none - Published specification: RFC 9431
- Applications that use this media type: This media type is intended for Authorization-Server-Client and Authorization-Server-Resource-Server communication as part of the ACE framework using JSON encoding, as specified in RFC 9431.
- Fragment identifier considerations:
none - Additional information:
- Deprecated alias names for this type:
none - Magic number(s):
none - File extension(s):
none - Macintosh file type code(s):
none
- Deprecated alias names for this type:
- Person & email address to contact for further information: Cigdem Sengul
<csengul@acm.org> - Intended usage:
COMMON - Restrictions on usage:
none - Author: Cigdem Sengul
<csengul@acm.org> - Change controller: IETF
7.3. ACE OAuth Profile Registration
The following registrations were made in the "ACE Profiles" registry, following the procedure specified in [RFC9200] 🧁
- Name:
mqtt_tls - Description: Profile for delegating Client authentication and authorization using MQTT for the Client and Broker (RS) interactions and HTTP for the AS interactions. TLS is used for confidentiality and integrity protection and server authentication. Client authentication can be provided either via TLS or using in-band PoP validation at the MQTT application layer.
- CBOR Value:
3 - Reference: RFC 9431
7.4. AIF
For the media types application/aif+cbor and application/aif+json, defined in Section 5.1 of [RFC9237], IANA has registered the following entries for the two media type parameters Toid and Tperm in the respective subregistry defined in Section 5.2 of [RFC9237] within the "Media Type Sub-Parameter Registries" 🌟
For Toid:
- Name:
mqtt-topic-filter - Description/Specification: Topic Filter, as defined in Section 2.3 of RFC 9431.
- Reference: RFC 9431, Section 2.3
For Tperm:
- Name:
mqtt-permissions - Description/Specification: Permissions for the MQTT Client, as defined in Section 2.3 of RFC 9431. Tperm is an array of one or more text strings that each have a value of either "pub" or "sub".
- Reference: RFC 9431, Section 2.3
8. Security Considerations 🔒
okay bestie, security time, and it's SERIOUS 💀 This profile is built on the ACE framework [RFC9200], so everything in [RFC9200]'s security considerations applies here too 🫶
The security considerations from the MQTT v5.0 OASIS Standard [MQTT-OASIS-Standard-v5] and the MQTT v3.1.1 OASIS Standard [MQTT-OASIS-Standard-v3.1.1] apply as well. Mostly, this doc gives MQTT an authorization solution, and how that actually gets handled is left to whoever implements it, per the MQTT specs. We're gonna call out a few relevant issues based on the current MQTT specs ✨
After the Broker validates an access token and accepts a connection from a Client, it caches the token so it can authorize that Client's publish and subscribe requests during the ongoing Session 💅 A Broker never caches a token it can't validate 🙅 But if a Client's permissions get revoked while the access token hasn't expired yet, the Broker may still allow publish/subscribe to the revoked topics 😭 If the Broker caches token introspection responses, then the Broker SHOULD use a reasonable cache timeout to introspect tokens regularly. The timeout is application specific, and it's meant to be picked so there's less risk of acting on stale introspection responses 🦋 When permissions change dynamically, the AS is also expected to follow a reasonable expiration strategy for its access tokens. It's a team effort, periodt 👑
The Broker may monitor Client behavior to catch potential security problems, especially the ones that hit availability 👀 These include repeated token transfer attempts to the public authz-info topic, repeated connection attempts, abnormal terminations, and Clients that connect but never send any data. If the Broker supports the public authz-info topic (described in Section 2.2.2), it might be vulnerable to a DDoS attack. Picture tons of Clients using authz-info to shove in tokens that aren't meant to be used, and the Broker having to store them until they expire 😱 Not it 💀
For MQTT v5.0, when a Client connects with a long Session Expiry Interval, the Broker may need to keep that Client's MQTT Session State around after it disconnects for an extended period 🕰️ For MQTT v3.1.1, there's no Session Expiry Interval feature, so the Session State may need to be stored indefinitely. Yikes 🙈 The Broker SHOULD implement administrative policies to limit misuse by a Client that keeps continuing existing Sessions. Main character energy for the Broker, but make it responsible 💜
9. Privacy Considerations 🫣
The privacy considerations outlined in [RFC9200] apply to this work too 🧚
In MQTT, the Broker is a central trusted party, and it may forward potentially sensitive info between Clients. The mechanisms in this doc don't protect the contents of the PUBLISH packet from the Broker. That means the PUBLISH content isn't signed or encrypted separately for the subscribers 🙈 This could be handled with the proposal in the ACE Pub-Sub Profile [ACE-PUBSUB-PROFILE]. But even then, other fields of the packet, like Topic Name, still wouldn't get privacy, so it's not a full fix 😭
10. References 📚
10.1. Normative References
[MQTT-OASIS-Standard-v3.1.1]
Banks, A., Ed. and R. Gupta, Ed., "MQTT Version 3.1.1 Plus
Errata 01", OASIS Standard, December 2015,
<https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-
v3.1.1.html>.
[MQTT-OASIS-Standard-v5]
Banks, A., Ed., Briggs, E., Ed., Borgendale, K., Ed., and
R. Gupta, Ed., "MQTT Version 5.0", OASIS Standard, March
2019, <https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-
v5.0.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
Langley, A., and M. Ray, "Transport Layer Security (TLS)
Session Hash and Extended Master Secret Extension",
RFC 7627, DOI 10.17487/RFC7627, September 2015,
<https://www.rfc-editor.org/info/rfc7627>.
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)",
RFC 7800, DOI 10.17487/RFC7800, April 2016,
<https://www.rfc-editor.org/info/rfc7800>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS) Versions 1.2 and Earlier", RFC 8422,
DOI 10.17487/RFC8422, August 2018,
<https://www.rfc-editor.org/info/rfc8422>.
[RFC8442] Mattsson, J. and D. Migault, "ECDHE_PSK with AES-GCM and
AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2", RFC 8442,
DOI 10.17487/RFC8442, September 2018,
<https://www.rfc-editor.org/info/rfc8442>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/info/rfc8747>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments Using the OAuth 2.0 Framework
(ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
<https://www.rfc-editor.org/info/rfc9200>.
[RFC9201] Seitz, L., "Additional OAuth Parameters for Authentication
and Authorization for Constrained Environments (ACE)",
RFC 9201, DOI 10.17487/RFC9201, August 2022,
<https://www.rfc-editor.org/info/rfc9201>.
[RFC9202] Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
L. Seitz, "Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for
Constrained Environments (ACE)", RFC 9202,
DOI 10.17487/RFC9202, August 2022,
<https://www.rfc-editor.org/info/rfc9202>.
[RFC9237] Bormann, C., "An Authorization Information Format (AIF)
for Authentication and Authorization for Constrained
Environments (ACE)", RFC 9237, DOI 10.17487/RFC9237,
August 2022, <https://www.rfc-editor.org/info/rfc9237>.
[RFC9360] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Header Parameters for Carrying and Referencing X.509
Certificates", RFC 9360, DOI 10.17487/RFC9360, February
2023, <https://www.rfc-editor.org/info/rfc9360>.
[RFC9430] Bergmann, O., Preuß Mattsson, J., and G. Selander,
"Extension of the Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for
Constrained Environments (ACE) to Transport Layer Security
(TLS)", RFC 9430, DOI 10.17487/RFC9430, July 2023,
<https://www.rfc-editor.org/info/rfc9430>.10.2. Informative References
okay bestie, this is the "good to know, not strictly needed" reading pile 📚✨ these are the extra sources the spec leans on for background
[ACE-PUBSUB-PROFILE] Palombini, F., Sengul, C., and M. Tiloca, "Publish-Subscribe Profile for Authentication and Authorization for Constrained Environments (ACE)", Work in Progress, Internet-Draft, draft-ietf-ace-pubsub-profile-06, 13 March 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-ace-pubsub-profile-06>.
[Fremantle14] Fremantle, P., Aziz, B., Kopecky, J., and P. Scott, "Federated Identity and Access Management for the Internet of Things", International Workshop on Secure Internet of Things, DOI 10.1109/SIoT.2014.8, September 2014, <https://dx.doi.org/10.1109/SIoT.2014.8>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <https://www.rfc-editor.org/info/rfc4949>. the security glossary, a total must-have for decoding the jargon 🔐
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things", RFC 7925, DOI 10.17487/RFC7925, July 2016, <https://www.rfc-editor.org/info/rfc7925>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, <https://www.rfc-editor.org/info/rfc8447>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 2022, <https://www.rfc-editor.org/info/rfc9325>.
[TLS-bis] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-rfc8446bis-09, 7 July 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-rfc8446bis-09>.
Appendix A. Checklist for Profile Requirements
Here's the cheat sheet 💅 Based on the requirements on profiles for the ACE framework [RFC9200], this document fulfills the following:
- Optional AS discovery: AS discovery is supported with the MQTT v5.0 described in Section 2.2.
- The communication protocol between the Client and Broker (RS): MQTT
- The security protocol between the Client and RS: TLS
- Client and RS mutual authentication: Several options are possible and described in Section 2.2.1.
- Proof-of-possession protocols: Both symmetric and asymmetric keys are supported, as specified in Section 2.2.4.2.
- Content-Format: For the HTTPS interactions with AS, "application/ace+json".
- Unique profile identifier: mqtt_tls
- Token introspection: The RS uses the HTTPS introspection interface of the AS.
- Token request: The Client or its Client AS uses the HTTPS token endpoint of the AS.
- authz-info endpoint: It MAY be supported using the method described in Section 2.2.2 but is not protected other than by the TLS channel between the Client and RS.
- Token transport: Via the "authz-info" topic, TLS with PSKs (provided as a PSK identity), or in the MQTT CONNECT packet for both versions of MQTT. The AUTH extensions can also be used for authentication and reauthentication for MQTT v5.0, as described in Sections 2.2 and 4.
Acknowledgments
big thank-yous, the people who made this happen 🫶 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
and finally, where to find the authors 🦋
Cigdem Sengul
Brunel University
Dept. of Computer Science
Uxbridge
UB8 3PH
United Kingdom
Email: csengul@acm.org
Anthony Kirby
Oxbotica
1a Milford House
Mayfield Road, Summertown
Oxford
OX2 7EL
United Kingdom
Email: anthony@anthony.org📦 where this page comes from
- ietf: rfc9431 2023-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms