Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework
Extracted elements (29)
MQTT v5.0 is the RECOMMENDED version for this profile because it works more naturally with ACE-style authentication and authorization, while v3.1.1 support is retained given expected continued deployments.
MQTT v3.1.1 lacks PUBACK reason codes and server-side DISCONNECT packets, so authorization errors in that version result in silent disconnection at the network layer rather than application-layer error reporting; token management is therefore more demanding for v3.1.1 clients.
During reauthentication within the same TLS session, the Client MUST NOT use TLS-exporter-based PoP (Section 2.2.4.2.1) to avoid reusing the same challenge; it MUST instead use the challenge-response PoP method.
For MQTT v3.1.1, a tokenless CONNECT MUST fail because challenge-response PoP is not possible, and AS discovery via CONNACK is also not supported in that protocol version.
HMAC-SHA-256 (HS256) and Ed25519 are mandatory to implement for the Broker. The Client MUST implement at least one of them. Signature validation MUST fail if the algorithm is set to "none" or if the signature/MAC does not match.
If the Will Flag is set to 1 in CONNECT, the Broker MUST check that the token scope allows publication of the Will Topic; if Will authorization fails, the connection MUST be refused.
The Broker MUST check for token expiration on receiving a CONNECT, PUBLISH, or SUBSCRIBE packet. The Broker SHOULD also check on receiving a PINGREQ and MAY check periodically to enable early detection.
The Broker MUST NOT forward PUBLISH messages to unauthorized subscribers. To avoid silently dropping messages, the Broker MUST close the Network Connection and SHOULD send a DISCONNECT with reason code 0x87 (Not authorized) to affected subscribers.
The Broker MUST use the minimum of the token expiry interval and the message expiry interval when deciding how long to retain a retained message, to prevent indefinite publication by clients that never update their tokens.
The Broker MUST verify the validity of an access token (either locally or via introspection) and MUST verify claims per ACE framework Section 5.10.1.1. For self-contained tokens the Broker MUST process the token's security protection (COSE for CWT, JOSE for JWT) before any other processing.
The token or its introspection result MUST be cached by the Broker to authorize a Client's future PUBLISH and SUBSCRIBE messages, since those packets do not carry access tokens. The Broker SHOULD use a cache timeout to introspect tokens regularly.
TLS 1.2 implementations MUST use the Extended Master Secret extension to incorporate the handshake transcript into the master secret; implementations SHOULD use SNI and ALPN extensions.
Unless a Client publishes/subscribes only to public topics, the Client and Broker MUST perform mutual authentication. The Client MUST authenticate to the Broker (over MQTT or TLS) before performing any other action.
The Broker is a central trusted party that can read all PUBLISH payloads; the mechanisms in this document do not protect PUBLISH packet contents or Topic Names from the Broker. End-to-end payload confidentiality requires additional mechanisms such as the ACE Pub-Sub Profile.
AS discovery is optionally triggered by the Broker on connection failure by including a User Property (type 0x26) named "ace_as_hint" in the CONNACK packet; its value is a UTF-8-encoded JSON object with the mandatory "AS" parameter and optional "audience", "kid", "cnonce", and "scope" parameters.
Client authentication over MQTT uses the Authentication Method property set to the string "ace" (property identifier 0x15) and Authentication Data (property identifier 0x16) carrying the token and PoP material. The Broker MUST support both TLS-exporter-based PoP and Broker-generated challenge/response.
Five client authentication combinations are defined: TLS:Anon,MQTT:None (public topics only); TLS:Anon,MQTT:ace (token in CONNECT); TLS:Known(RPK/PSK),MQTT:none (token pre-uploaded or in PSK identity); and TLS:Known(RPK/PSK),MQTT:ace (SHOULD NOT be used as it overwrites TLS permissions).
The AIF-MQTT data model defines the token scope as an array of [mqtt-topic-filter, mqtt-permissions] pairs, where mqtt-permissions is an array of "pub" and/or "sub" strings. For JWTs the scope is a base64url-encoded JSON array; for CWTs it is CBOR.
The "authz-info" topic is a public, unprotected MQTT topic used to pre-upload access tokens to the Broker before TLS client authentication. Clients MUST only publish to it (subscribing is not allowed), using TLS:Anon,MQTT:None.
The CONNECT packet flags for MQTT v5.0 ACE authentication MUST have User Name Flag and Password Flag set to 0; the AUTH property carries the token. For MQTT v3.1.1, both User Name Flag and Password Flag MUST be set to 1.
This document registers AIF sub-parameter entries: "mqtt-topic-filter" for Toid (MQTT Topic Filters per Section 4.7 of MQTT v5.0) and "mqtt-permissions" for Tperm (array of "pub" and/or "sub" strings), in the Media Type Sub-Parameter Registries for application/aif+cbor and application/aif+json.
This document registers the ACE OAuth profile "mqtt_tls" (CBOR value 3) in the "ACE Profiles" registry, describing the profile for MQTT Client/Broker interactions secured with TLS and ACE PoP.
This document registers the media type "application/ace+json" for ACE framework messages using JSON encoding, intended for AS-Client and AS-RS communication.
This document registers the TLS Exporter Label "EXPORTER-ACE-MQTT-Sign-Challenge" in the IANA "TLS Exporter Labels" registry (RFC 8447). Recommended: N, DTLS-OK: N.
If a Client's permissions are revoked before the access token expires, the Broker may still grant publish/subscribe access to revoked topics when using cached tokens or introspection results. The Broker SHOULD use a reasonable cache timeout; the AS should follow a reasonable token expiration strategy when permissions change dynamically.
The public "authz-info" topic is vulnerable to DDoS attack: many clients can upload tokens not intended to be used, forcing the Broker to store them until expiry. The Broker SHOULD monitor for repeated token-transfer attempts and other anomalous patterns.
For Broker challenge/response PoP: the Client's initial CONNECT Authentication Data contains a two-byte token length and token; the Broker AUTH challenge contains an 8-byte RS nonce; the Client AUTH response contains an 8-byte Client nonce followed by a MAC or signature over RS nonce concatenated with Client nonce.
For MQTT v3.1.1 token transport, the CONNECT User Name field MUST be prefixed with ASCII characters 'a','c','e' followed by the base64url-encoded (no padding) access token; the Password field MUST contain the MAC or signature for PoP over the TLS-exporter challenge.
For TLS-exporter-based PoP, the CONNECT Authentication Data field contains: a two-byte token length, the token bytes, and a MAC or signature computed over 32 bytes exported from the TLS session using label "EXPORTER-ACE-MQTT-Sign-Challenge" with an empty context.