Section 1. Introduction

This document specifies a profile for the ACE framework [RFC9200].
   In this profile, Clients and Servers (Brokers) use MQTT to exchange
   Application Messages.  The protocol relies on TLS for communication
   security between entities.  The MQTT protocol interactions are
   described based on the MQTT v5.0 OASIS Standard
   [MQTT-OASIS-Standard-v5].  Since it is expected that MQTT deployments
   will continue to support 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].  However, MQTT v5.0 is
   the RECOMMENDED version, as it works more naturally with ACE-style
   authentication and authorization.
   MQTT is a publish-subscribe protocol, and after connecting to the
   MQTT Server (Broker), a Client can publish and subscribe to multiple
   topics.  The Broker, which acts as the Resource Server (RS), 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 the Topic Names to receive the corresponding messages.  The Broker
   uses the Topic Name in a published message to determine which
   subscribers to relay the messages 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
   The document describes message exchanges as MQTT protocol
   interactions.  The Clients are MQTT Clients, which connect to the
   Broker to publish and subscribe to Application Messages (which are
   labeled with their topics).  For additional information, please refer
   to the MQTT v5.0 OASIS Standard [MQTT-OASIS-Standard-v5] or MQTT
   v3.1.1 OASIS Standard [MQTT-OASIS-Standard-v3.1.1].
   Broker 
           The Server in MQTT.  It acts as an intermediary 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 is being used by MQTT.  It connects the Client to the
           Server.  It provides the means to send 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 last only as long as the Network Connection; 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
           The MQTT protocol operates by exchanging a series of MQTT
           Control Packets.  Each packet is composed of a Fixed Header,
           a Variable Header (depending on the Control Packet type), and
           a Payload.
   UTF-8-encoded string
           A string prefixed with a two-byte-length field that gives the
           number of bytes in a UTF-8-encoded string itself.  Unless
           stated otherwise, all UTF-8-encoded strings can have any
           length in the range 0 to 65535 bytes.
   Binary Data
           Binary Data is represented by a two-byte-length field, which
           indicates the number of data bytes, followed by that number
           of bytes.  Thus, the length of Binary Data is limited to the
           range of 0 to 65535 bytes.
   Variable Byte Integer
           A Variable Byte Integer is encoded using an encoding scheme
           that uses a single byte for values up to 127.  For larger
           values, the least significant seven bits of each byte encode
           the data, and the most significant bit is used to indicate
           whether there are bytes following in the representation.
           Thus, 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 the delivery of an Application
           Message.  The QoS level can be 0-2, where 0 indicates "At
           most once delivery", 1 indicates "At least once delivery",
           and 2 indicates "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 consists of 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 is
           matched to a Subscription.
   Subscription
           A Subscription comprises a Topic Filter and a maximum QoS.  A
           Subscription is associated with a single Session.
   Topic Filter
           An expression that indicates interest in one or more Topic
           Names.  Topic Filters may include wildcards.
   MQTT sends various Control Packets across a Network Connection.  The
   following is not an exhaustive list, and the Control Packets that are
   not relevant for authorization are not explained.  For instance,
   these include the PUBREL and PUBCOMP packets used in the 4-step
   handshake required for QoS level 2.
   CONNECT
           The Client requests to connect to the Broker.  This is the
           first packet sent by a Client.
   CONNACK
           The Broker connection acknowledgment.  CONNACK packets
           contain return codes that indicate either a 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
           consequent AUTH packets follow the same Authentication
           Method.  The contents of the Authentication Data are defined
           by the Authentication Method.
   PUBLISH
           Publish request sent from a publishing Client to the Broker
           or from the Broker to a subscribing Client.
   PUBACK 
           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 
           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
           Subscribe request sent from a Client.
   SUBACK 
           Subscribe acknowledgment from the Broker to the Client.
   PINGREQ
           A ping request sent from a Client to the Broker.  It signals
           to the Broker that the Client is alive and is used to confirm
           that the Broker is also alive.  The "Keep Alive" period is
           set in the CONNECT packet.
   PINGRESP
           Response sent by the Broker to the Client in response to
           PINGREQ.  It indicates the Broker is alive.
   DISCONNECT
           The DISCONNECT packet is the final MQTT Control Packet sent
           from the Client or the Broker.  It indicates the reason why
           the Network Connection is being closed.  If the Network
           Connection is closed without the Client first sending a
           DISCONNECT packet with reason code 0x00 (Normal
           disconnection) and the MQTT Connection has a Will Message,
           the Will Message is published.
   Will   
           If the Network Connection is not closed normally, the Broker
           sends a last Will Message for the Client if the Client
           provided one in its CONNECT packet.  Situations in which the
           Will Message is published include, but are not 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 information about the
           Will.  The information consists of the Will Properties, Will
           Topic, and Will Payload fields.