rfc9431.original   rfc9431.txt 
ACE Working Group C.S. Sengul Internet Engineering Task Force (IETF) C. Sengul
Internet-Draft Brunel University Request for Comments: 9431 Brunel University
Intended status: Standards Track A.K. Kirby Category: Standards Track A. Kirby
Expires: 24 September 2022 Oxbotica ISSN: 2070-1721 Oxbotica
23 March 2022 July 2023
Message Queuing Telemetry Transport (MQTT)-TLS profile of Authentication Message Queuing Telemetry Transport (MQTT) and Transport Layer Security
and Authorization for Constrained Environments (ACE) Framework (TLS) Profile of Authentication and Authorization for Constrained
draft-ietf-ace-mqtt-tls-profile-17 Environments (ACE) Framework
Abstract Abstract
This document specifies a profile for the ACE (Authentication and This document specifies a profile for the Authentication and
Authorization for Constrained Environments) framework to enable Authorization for Constrained Environments (ACE) framework to enable
authorization in a Message Queuing Telemetry Transport (MQTT)-based authorization in a publish-subscribe messaging system based on
publish-subscribe messaging system. Proof-of-possession keys, bound Message Queuing Telemetry Transport (MQTT). Proof-of-Possession
to OAuth2.0 access tokens, are used to authenticate and authorize keys, bound to OAuth 2.0 access tokens, are used to authenticate and
MQTT Clients. The protocol relies on TLS for confidentiality and authorize MQTT Clients. The protocol relies on TLS for
MQTT server (Broker) authentication. confidentiality and MQTT server (Broker) authentication.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 24 September 2022. 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 Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language
1.2. ACE-Related Terminology . . . . . . . . . . . . . . . . . 4 1.2. ACE-Related Terminology
1.3. MQTT-Related Terminology . . . . . . . . . . . . . . . . 5 1.3. MQTT-Related Terminology
2. Authorizing Connection Requests . . . . . . . . . . . . . . . 9 2. Authorizing Connection Requests
2.1. Client Token Request to the Authorization Server (AS) . . 10 2.1. Client Token Request to the Authorization Server (AS)
2.2. Client Connection Request to the Broker (C) . . . . . . . 11 2.2. Client Connection Request to the Broker (C)
2.2.1. Overview of Client-RS Authentication Methods over TLS 2.2.1. Overview of Client-RS Authentication Methods over TLS
and MQTT . . . . . . . . . . . . . . . . . . . . . . 12 and MQTT
2.2.2. authz-info: The Authorization Information Topic . . . 13 2.2.2. authz-info: The Authorization Information Topic
2.2.3. Client Authentication over TLS . . . . . . . . . . . 14 2.2.3. Client Authentication over TLS
2.2.3.1. Raw Public Key Mode . . . . . . . . . . . . . . . 14 2.2.3.1. Raw Public Key Mode
2.2.3.2. Pre-Shared Key Mode . . . . . . . . . . . . . . . 15 2.2.3.2. Pre-Shared Key Mode
2.2.4. Client Authentication over MQTT . . . . . . . . . . . 15 2.2.4. Client Authentication over MQTT
2.2.4.1. Transporting the Access Token Inside the MQTT 2.2.4.1. Transporting the Access Token inside the MQTT
CONNECT . . . . . . . . . . . . . . . . . . . . . . 15 CONNECT
2.2.4.2. Authentication Using AUTH Property . . . . . . . 18 2.2.4.2. Authentication Using the AUTH Property
2.2.5. Broker Token Validation . . . . . . . . . . . . . . . 21 2.2.5. Broker Token Validation
2.3. Token Scope and Authorization . . . . . . . . . . . . . . 22 2.3. Token Scope and Authorization
2.4. Broker Response to Client Connection Request . . . . . . 23 2.4. Broker Response to Client Connection Request
2.4.1. Unauthorized Request and the Optional Authorization 2.4.1. Unauthorized Request and the Optional Authorization
Server Discovery . . . . . . . . . . . . . . . . . . 23 Server Discovery
2.4.2. Authorization Success . . . . . . . . . . . . . . . . 24 2.4.2. Authorization Success
3. Authorizing PUBLISH and SUBSCRIBE Packets . . . . . . . . . . 24 3. Authorizing PUBLISH and SUBSCRIBE Packets
3.1. PUBLISH Packets from the Publisher Client to the 3.1. PUBLISH Packets from the Publisher Client to the Broker
Broker . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2. PUBLISH Packets from the Broker to the Subscriber Clients
3.2. PUBLISH Packets from the Broker to the Subscriber 3.3. Authorizing SUBSCRIBE Packets
Clients . . . . . . . . . . . . . . . . . . . . . . . . . 25 4. Token Expiration, Update, and Reauthentication
3.3. Authorizing SUBSCRIBE Packets . . . . . . . . . . . . . . 25 5. Handling Disconnections and Retained Messages
4. Token Expiration, Update, and Reauthentication . . . . . . . 26 6. Reduced Protocol Interactions for MQTT v3.1.1
5. Handling Disconnections and Retained Messages . . . . . . . . 27 6.1. Token Transport
6. Reduced Protocol Interactions for MQTT v3.1.1 . . . . . . . . 28 6.2. Handling Authorization Errors
6.1. Token Transport . . . . . . . . . . . . . . . . . . . . . 28 7. IANA Considerations
6.2. Handling Authorization Errors . . . . . . . . . . . . . . 30 7.1. TLS Exporter Labels Registration
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 7.2. Media Type Registration
7.1. TLS Exporter Label Registration . . . . . . . . . . . . . 31 7.3. ACE OAuth Profile Registration
7.2. Media Type Registration . . . . . . . . . . . . . . . . . 31 7.4. AIF
7.3. ACE OAuth Profile Registration . . . . . . . . . . . . . 32 8. Security Considerations
7.4. AIF . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 9. Privacy Considerations
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 10. References
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 34 10.1. Normative References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.2. Informative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 35 Appendix A. Checklist for Profile Requirements
10.2. Informative References . . . . . . . . . . . . . . . . . 38 Acknowledgments
Appendix A. Checklist for profile requirements . . . . . . . . . 40 Authors' Addresses
Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 40
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
This document specifies a profile for the ACE framework This document specifies a profile for the ACE framework [RFC9200].
[I-D.ietf-ace-oauth-authz]. In this profile, Clients and Servers In this profile, Clients and Servers (Brokers) use MQTT to exchange
(Brokers) use MQTT to exchange Application Messages. The protocol Application Messages. The protocol relies on TLS for communication
relies on TLS for communication security between entities. The MQTT security between entities. The MQTT protocol interactions are
protocol interactions are described based on the MQTT v5.0 - the described based on the MQTT v5.0 OASIS Standard
OASIS Standard [MQTT-OASIS-Standard-v5]. Since it is expected that [MQTT-OASIS-Standard-v5]. Since it is expected that MQTT deployments
MQTT deployments will continue to support MQTT v3.1.1 Clients, this will continue to support MQTT v3.1.1 Clients, this document also
document also describes a reduced set of protocol interactions for describes a reduced set of protocol interactions for the MQTT v3.1.1
MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard-v3.1.1]. OASIS Standard [MQTT-OASIS-Standard-v3.1.1]. However, MQTT v5.0 is
However, MQTT v5.0 is the RECOMMENDED version as it works more the RECOMMENDED version, as it works more naturally with ACE-style
naturally with ACE-style authentication and authorization. authentication and authorization.
MQTT is a publish-subscribe protocol, and after connecting to the MQTT is a publish-subscribe protocol, and after connecting to the
MQTT Server (Broker), a Client can publish and subscribe to multiple MQTT Server (Broker), a Client can publish and subscribe to multiple
topics. The Broker, which acts as the Resource Server (RS), is topics. The Broker, which acts as the Resource Server (RS), is
responsible for distributing messages published by the publishers to responsible for distributing messages published by the publishers to
their subscribers. In the rest of the document, the terms "RS", their subscribers. In the rest of the document, the terms "RS",
"MQTT Server" and "Broker" are used interchangeably. "MQTT Server", and "Broker" are used interchangeably.
Messages are published under a Topic Name, and subscribers subscribe Messages are published under a Topic Name, and subscribers subscribe
to the Topic Names to receive the corresponding messages. The Broker to the Topic Names to receive the corresponding messages. The Broker
uses the Topic Name in a published message to determine which uses the Topic Name in a published message to determine which
subscribers to relay the messages to. In this document, topics, more subscribers to relay the messages to. In this document, topics (more
specifically, Topic Names, are treated as resources. The Clients are specifically, Topic Names) are treated as resources. The Clients are
assumed to have identified the publish/subscribe topics of interest assumed to have identified the publish/subscribe topics of interest
out-of-band (topic discovery is not a feature of the MQTT protocol). out of band (topic discovery is not a feature of the MQTT protocol).
A Resource Owner can pre-configure policies at the Authorization A Resource Owner can preconfigure policies at the Authorization
Server (AS) that give Clients publish or subscribe permissions to Server (AS) that give Clients publish or subscribe permissions to
different topics. different topics.
Clients prove their permission to publish and subscribe to topics Clients prove their permission to publish and subscribe to topics
hosted on an MQTT Broker using an access token, bound to a proof-of- hosted on an MQTT Broker using an access token that is bound to a
possession (PoP) key. This document describes how to authorize the Proof-of-Possession (PoP) key. This document describes how to
following exchanges between the Clients and the Broker. authorize the following exchanges between the Clients and the Broker.
* Connection requests from the Clients to the Broker * connection requests from the Clients to the Broker
* Publish requests from the Clients to the Broker and from the * publish requests from the Clients to the Broker and from the
Broker to the Clients Broker to the Clients
* Subscribe requests from the Clients to the Broker * subscribe requests from the Clients to the Broker
Clients use the MQTT PUBLISH packet to publish to a topic. The Clients use the MQTT PUBLISH packet to publish to a topic. The
mechanisms specified in this document do not protect the payload of mechanisms specified in this document do not protect the Payload of
the PUBLISH packet from the Broker. Hence, the payload is not signed the PUBLISH packet from the Broker. Hence, the Payload is not signed
or encrypted specifically for the subscribers. This functionality or encrypted specifically for the subscribers. This functionality
may be implemented using the proposal outlined in the ACE Pub-Sub may be implemented using the proposal outlined in the ACE Pub-Sub
Profile [I-D.ietf-ace-pubsub-profile]. Profile [ACE-PUBSUB-PROFILE].
To provide communication confidentiality and Broker authentication to To provide communication confidentiality and Broker authentication to
the MQTT Clients, TLS is used, and TLS 1.3 [RFC8446] is RECOMMENDED. 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 This document makes the same assumptions as Section 4 of the ACE
framework [I-D.ietf-ace-oauth-authz] regarding Client and RS framework [RFC9200] regarding Client and RS registration with the AS
registration with the AS and setting up the keying material. While for setting up the keying material. While the Client-Broker
the Client-Broker exchanges are only over MQTT, the required Client- exchanges are only over MQTT, the required Client-AS and RS-AS
AS and RS-AS interactions are described for HTTPS-based communication interactions are described for HTTPS-based communication [RFC9110],
[I-D.ietf-httpbis-semantics], using "application/ace+json" content using the "application/ace+json" content type and, unless otherwise
type, and unless otherwise specified, using JSON encoding. The token specified, JSON encoding. The token MAY be an opaque reference to
MAY be an opaque reference to authorization information or JSON Web authorization information or a JSON Web Token (JWT) [RFC7519]. For
Token (JWT) [RFC7519]. For JWTs, this document follows [RFC7800] for JWTs, this document follows [RFC7800] for PoP semantics for JWTs, and
PoP semantics for JWTs, and the mechanisms for providing and the mechanisms for providing and verifying PoP are detailed in
verifying PoP are detailed in Section 2.2. The Client-AS and RS-AS Section 2.2. The Client-AS and RS-AS exchanges MAY also use
exchanges MAY also use protocols other than HTTP, e.g., Constrained protocols other than HTTP, e.g., Constrained Application Protocol
Application Protocol (CoAP) [RFC7252] or MQTT. It is recommended (CoAP) [RFC7252] or MQTT. It is recommended that TLS is used to
that TLS is used to secure these communication channels between secure these communication channels between Client-AS and RS-AS. To
Client-AS and RS-AS. To reduce the protocol memory and bandwidth reduce the protocol memory and bandwidth requirements,
requirements, implementations MAY also use "application/ace+cbor" implementations MAY also use the "application/ace+cbor" content type,
content type, and CBOR encoding [RFC8949], and CBOR Web Token (CWT) Concise Binary Object Representation (CBOR) encoding [RFC8949], CBOR
[RFC8392] and associated PoP semantics. For more information, see Web Tokens (CWTs) [RFC8392], and associated PoP semantics. For more
Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) information, see "Proof-of-Possession Key Semantics for CBOR Web
[RFC8747]. A JWT token uses JOSE, while a CWT token uses COSE Tokens (CWTs)" [RFC8747]. A JWT uses JSON Object Signing and
[RFC8152] for security protection. Encryption (JOSE), while a CWT uses CBOR Object Signing and
Encryption (COSE) [RFC9052] for security protection.
1.1. Requirements Language 1.1. Requirements Language
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174], when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. ACE-Related Terminology 1.2. ACE-Related Terminology
Certain security-related terms such as "authentication", Certain security-related terms, such as "authentication",
"authorization", "confidentiality", "(data) integrity", "message "authorization", "data confidentiality", "(data) integrity", "message
authentication code", and "verify" are taken from [RFC4949]. authentication code" (MAC), and "verify", are taken from [RFC4949].
The terminology for entities in the architecture is defined in OAuth The terminology for entities in the architecture is defined in OAuth
2.0 [RFC6749] such as "Client" (C), "Resource Server" (RS) and 2.0 [RFC6749], such as "Client" (C), "Resource Server" (RS), and
"Authorization Server" (AS). "Authorization Server" (AS).
The term "resource" is used to refer to an MQTT Topic Name, which is 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 defined in Section 1.3. Hence, the "Resource Owner" is any entity
that can authoritatively speak for the topic. This document also that can authoritatively speak for the topic. This document also
defines a Client Authorization Server for Clients that are not able defines a Client Authorization Server for Clients that are not able
to support HTTP. to support HTTP.
Client Authorization Server (CAS) Client Authorization Server (CAS)
An entity that prepares and endorses authentication and An entity that prepares and endorses authentication and
authorization data for a Client, and communicates to the AS authorization data for a Client and communicates to the AS
using HTTPS. using HTTPS.
1.3. MQTT-Related Terminology 1.3. MQTT-Related Terminology
The document describes message exchanges as MQTT protocol The document describes message exchanges as MQTT protocol
interactions. The Clients are MQTT Clients, which connect to the interactions. The Clients are MQTT Clients, which connect to the
Broker to publish and subscribe to Application Messages, labelled Broker to publish and subscribe to Application Messages (which are
with their topics. For additional information, please refer to the labeled with their topics). For additional information, please refer
MQTT v5.0 - the OASIS Standard [MQTT-OASIS-Standard-v5] or the MQTT to the MQTT v5.0 OASIS Standard [MQTT-OASIS-Standard-v5] or MQTT
v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard-v3.1.1]. v3.1.1 OASIS Standard [MQTT-OASIS-Standard-v3.1.1].
Broker Broker
The Server in MQTT. It acts as an intermediary between the The Server in MQTT. It acts as an intermediary between the
Clients that publish Application Messages and the Clients Clients that publish Application Messages and the Clients
that made Subscriptions. The Broker acts as the Resource that made Subscriptions. The Broker acts as the Resource
Server for the Clients. Server for the Clients.
Client Client
A device or program that uses MQTT. A device or program that uses MQTT.
Network Connection Network Connection
A construct provided by the underlying transport protocol A construct provided by the underlying transport protocol
that is being used by MQTT. It connects the Client to the that is being used by MQTT. It connects the Client to the
Server. It provides the means to send an ordered, lossless, Server. It provides the means to send an ordered, lossless
stream of bytes in both directions. This document uses TLS stream of bytes in both directions. This document uses TLS
as tranport protocol. as the transport protocol.
Session Session
A stateful interaction between a Client and a Broker. Some A stateful interaction between a Client and a Broker. Some
Sessions last only as long as the Network Connection; others Sessions last only as long as the Network Connection; others
can span multiple Network Connections. can span multiple Network Connections.
Application Message Application Message
The data carried by the MQTT protocol. The data has an The data carried by the MQTT protocol. The data has an
associated Quality-of-Service (QoS) level and Topic Name. associated Quality-of-Service (QoS) level and Topic Name.
MQTT Control Packet MQTT Control Packet
The MQTT protocol operates by exchanging a series of MQTT The MQTT protocol operates by exchanging a series of MQTT
Control packets. Each packet is composed of a Fixed Header, Control Packets. Each packet is composed of a Fixed Header,
a Variable Header (depending on the control packet type), and a Variable Header (depending on the Control Packet type), and
a Payload. a Payload.
UTF-8 encoded string UTF-8-encoded string
A string prefixed with a two-byte length field that gives the A string prefixed with a two-byte-length field that gives the
number of bytes in a UTF-8 encoded string itself. Unless number of bytes in a UTF-8-encoded string itself. Unless
stated otherwise, all UTF-8 encoded strings can have any stated otherwise, all UTF-8-encoded strings can have any
length in the range 0 to 65535 bytes. length in the range 0 to 65535 bytes.
Binary Data Binary Data
Binary Data is represented by a two-byte length field which Binary Data is represented by a two-byte-length field, which
indicates the number of data bytes, followed by that number indicates the number of data bytes, followed by that number
of bytes. Thus, the length of Binary Data is limited to the of bytes. Thus, the length of Binary Data is limited to the
range of 0 to 65535 Bytes. range of 0 to 65535 bytes.
Variable Byte Integer Variable Byte Integer
Variable Byte Integer is encoded using an encoding scheme A Variable Byte Integer is encoded using an encoding scheme
that uses a single byte for values up to 127. For larger that uses a single byte for values up to 127. For larger
values, the least significant seven bits of each byte encode values, the least significant seven bits of each byte encode
the data, and the most significant bit is used to indicate the data, and the most significant bit is used to indicate
whether there are bytes following in the representation. whether there are bytes following in the representation.
Thus, each byte encodes 128 values and a "continuation bit". Thus, each byte encodes 128 values and a "continuation bit".
The maximum number of bytes in the Variable Byte Integer The maximum number of bytes in the Variable Byte Integer
field is four. field is four.
QoS level QoS level
The level of assurance for the delivery of an Application The level of assurance for the delivery of an Application
Message. The QoS level can be 0-2, where 0 indicates "At Message. The QoS level can be 0-2, where 0 indicates "At
most once delivery", 1 "At least once delivery", and 2 most once delivery", 1 indicates "At least once delivery",
"Exactly once delivery". and 2 indicates "Exactly once delivery".
Property Property
The last field of the Variable Header is a set of properties The last field of the Variable Header is a set of properties
for several MQTT control packets (e.g. CONNECT, CONNACK). A for several MQTT Control Packets (e.g., CONNECT and CONNACK).
Property consists of an Identifier that defines its usage and A property consists of an Identifier that defines its usage
data type, followed by a value. The Identifier is encoded as and data type, followed by a value. The Identifier is
a Variable Byte Integer. For example, the "Authentication encoded as a Variable Byte Integer. For example, the
Data" property uses the Identifier 22. "Authentication Data" property uses the identifier 22.
Topic Name Topic Name
The label attached to an Application Message, which is The label attached to an Application Message, which is
matched to a Subscription. matched to a Subscription.
Subscription Subscription
A Subscription comprises a Topic Filter and a maximum QoS. A A Subscription comprises a Topic Filter and a maximum QoS. A
Subscription is associated with a single session. Subscription is associated with a single Session.
Topic Filter Topic Filter
An expression that indicates interest in one or more Topic An expression that indicates interest in one or more Topic
Names. Topic Filters may include wildcards. Names. Topic Filters may include wildcards.
MQTT sends various control packets across a Network Connection. The MQTT sends various Control Packets across a Network Connection. The
following is not an exhaustive list, and the control packets that are following is not an exhaustive list, and the Control Packets that are
not relevant for authorization are not explained. These include, for not relevant for authorization are not explained. For instance,
instance, the PUBREL and PUBCOMP packets used in the 4-step handshake these include the PUBREL and PUBCOMP packets used in the 4-step
required for QoS level 2. handshake required for QoS level 2.
CONNECT CONNECT
Client request to connect to the Broker. This is the first The Client requests to connect to the Broker. This is the
packet sent by a Client. first packet sent by a Client.
CONNACK CONNACK
The Broker connection acknowledgment. CONNACK packets The Broker connection acknowledgment. CONNACK packets
contain return codes indicating either a success or an error contain return codes that indicate either a success or an
state in response to a Client's CONNECT packet. error state in response to a Client's CONNECT packet.
AUTH AUTH
Authentication Exchange. An AUTH control packet is sent from An AUTH Control Packet is sent from the Client to the Broker
the Client to the Broker or from the Broker to the Client as or from the Broker to the Client as part of an extended
part of an extended authentication exchange. AUTH Properties authentication exchange. AUTH properties include the
include Authentication Method and Authentication Data. The Authentication Method and Authentication Data. The
Authentication Method is set in the CONNECT packet, and Authentication Method is set in the CONNECT packet, and
consequent AUTH packets follow the same Authentication consequent AUTH packets follow the same Authentication
Method. The contents of the Authentication Data are defined Method. The contents of the Authentication Data are defined
by the Authentication Method. by the Authentication Method.
PUBLISH PUBLISH
Publish request sent from a publishing Client to the Broker, Publish request sent from a publishing Client to the Broker
or from the Broker to a subscribing Client. or from the Broker to a subscribing Client.
PUBACK PUBACK
Response to a PUBLISH request with QoS level 1. A PUBACK can 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 be sent from the Broker to a Client or from a Client to the
Broker. Broker.
PUBREC PUBREC
Response to PUBLISH request with QoS level 2. PUBREC can be Response to a PUBLISH request with QoS level 2. PUBREC can
sent from the Broker to a Client or from a Client to the be sent from the Broker to a Client or from a Client to the
Broker. Broker.
SUBSCRIBE SUBSCRIBE
Subscribe request sent from a Client. Subscribe request sent from a Client.
SUBACK SUBACK
Subscribe acknowledgment from the Broker to the Client. Subscribe acknowledgment from the Broker to the Client.
PINGREQ PINGREQ
A ping request sent from a Client to the Broker. It signals A ping request sent from a Client to the Broker. It signals
skipping to change at page 8, line 26 skipping to change at line 352
PINGRESP PINGRESP
Response sent by the Broker to the Client in response to Response sent by the Broker to the Client in response to
PINGREQ. It indicates the Broker is alive. PINGREQ. It indicates the Broker is alive.
DISCONNECT DISCONNECT
The DISCONNECT packet is the final MQTT Control Packet sent The DISCONNECT packet is the final MQTT Control Packet sent
from the Client or the Broker. It indicates the reason why from the Client or the Broker. It indicates the reason why
the Network Connection is being closed. If the Network the Network Connection is being closed. If the Network
Connection is closed without the Client first sending a Connection is closed without the Client first sending a
DISCONNECT packet with Reason Code 0x00 (Normal DISCONNECT packet with reason code 0x00 (Normal
disconnection) and the Connection has a Will Message, the disconnection) and the MQTT Connection has a Will Message,
Will Message is published. the Will Message is published.
Will Will
If the Network Connection is not closed normally, the Broker If the Network Connection is not closed normally, the Broker
sends a last Will message for the Client if the Client sends a last Will Message for the Client if the Client
provided one in its CONNECT packet. Situations in which the provided one in its CONNECT packet. Situations in which the
Will Message is published include, but are not limited to: Will Message is published include, but are not limited to,
the following:
* An I/O error or network failure detected by the Broker. * an I/O error or network failure detected by the Broker,
* The Client fails to communicate within the Keep Alive * the Client fails to communicate within the Keep Alive
period. period,
* The Client closes the Network Connection without first * the Client closes the Network Connection without first
sending a DISCONNECT packet with a Reason Code 0x00 sending a DISCONNECT packet with reason code 0x00 (Normal
(Normal disconnection). disconnection), and
* The Broker closes the Network Connection without first * the Broker closes the Network Connection without first
receiving a DISCONNECT packet with a Reason Code 0x00 receiving a DISCONNECT packet with reason code 0x00
(Normal disconnection). (Normal disconnection).
If the Will Flag is set in the CONNECT flags, then the If the Will Flag is set in the CONNECT flags, then the
payload of the CONNECT packet includes information about the Payload of the CONNECT packet includes information about the
Will. The information consists of the Will Properties, Will Will. The information consists of the Will Properties, Will
Topic, and Will Payload fields. Topic, and Will Payload fields.
2. Authorizing Connection Requests 2. Authorizing Connection Requests
This section specifies how Client connections are authorized by the This section specifies how Client connections are authorized by the
AS and verified by the MQTT Broker. Figure 1 shows the basic AS and verified by the MQTT Broker. Figure 1 shows the basic
protocol flow during connection setup. The token request and protocol flows during connection setup. The token request and
response use the token endpoint at the AS, specified for HTTP-based response use the token endpoint at the AS, specified for HTTP-based
interactions in Section 5.8 of the ACE framework interactions in Section 5.8 of the ACE framework [RFC9200]. Steps
[I-D.ietf-ace-oauth-authz]. Steps (D) and (E) are optional and use (D) and (E) are optional and use the introspection endpoint specified
the introspection endpoint specified in Section 5.9 of the ACE in Section 5.9 of the ACE framework [RFC9200]. The discussion in
framework. The discussion in this document assumes that the Client this document assumes that the Client and the Broker use HTTPS to
and the Broker use HTTPS to communicate with the AS via these communicate with the AS via these endpoints. The Client and the
endpoints. The Client and the Broker use MQTT to communicate between Broker use MQTT to communicate between them. The C-AS and Broker-AS
them. The C-AS and Broker-AS communication MAY be implemented using communications MAY be implemented using protocols other than HTTPS,
protocols other than HTTPS, e.g. CoAP or MQTT. Whatever protocol is e.g., CoAP or MQTT. Whatever protocol is used for the C-AS and
used for C-AS and Broker-AS communications MUST provide mutual Broker-AS communications MUST provide mutual authentication,
authentication, confidentiality protection, and integrity protection. confidentiality protection, and integrity protection.
If the Client is resource-constrained or does not support HTTPS, a If the Client is resource constrained or does not support HTTPS, a
separate Client Authorization Server may carry out the token request separate Client Authorization Server may carry out the token request
on behalf of the Client (Figure 1 (A) and (B)), and later, onboard on behalf of the Client (Figure 1, steps (A) and (B)) and, later,
the Client with the token. The interactions between a Client and its onboard the Client with the token. The interactions between a Client
Client Authorization Server for token onboarding and support for and its Client Authorization Server for token onboarding and support
MQTT-based token requests at the AS are out of the scope of this for MQTT-based token requests at the AS are out of the scope of this
document. document.
+---------------------+ +---------------------+
| Client | | Client |
| | | |
+---(A) Token request--| Client - | +---(A) Token request------| Client - |
| | Authorization | | | Authorization |
| +-(B) Access token-> Server Interface | | +-(B) Access token-----> Server Interface |
| | | (HTTPS) | | | | (HTTPS) |
| | |_____________________| | | |_____________________|
| | | | | | | |
+--v-------------+ | Pub/Sub Interface | +--v-------------+ | Pub/Sub Interface |
| Authorization | | (MQTT over TLS) | | Authorization | | (MQTT over TLS) |
| Server | +-----------^---------+ | Server | +----------------^----+
|________________| | | |________________| | |
| ^ (C)Connection (F)Connection | ^ (C) Connection (F) Connection
| | request + response | | request + response
| | access token | | | access token |
| | | | | | | |
| | +---v--------------+ | | +---v--------------+
| | | Broker | | | | Broker |
| | | (MQTT over TLS) | | | | (MQTT over TLS) |
| | |__________________| | | |__________________|
| +(D)Introspection-| | | +(D) Introspection-----| |
| request (optional) | RS-AS interface | | request (optional)| RS-AS interface |
| | (HTTPS) | | | (HTTPS) |
+-(E)Introspection---->|__________________| +-(E) Introspection-------->|__________________|
response (optional) response (optional)
Figure 1: Connection Setup Figure 1: Connection Setup
2.1. Client Token Request to the Authorization Server (AS) 2.1. Client Token Request to the Authorization Server (AS)
The first step in the protocol flow (Figure 1 (A)) is the token The first step in the protocol flow (Figure 1, step (A)) is the token
acquisition by the Client from the AS. The Client and the AS MUST acquisition by the Client from the AS. The Client and the AS MUST
perform mutual authentication. The Client requests an access token perform mutual authentication. The Client requests an access token
from the AS as described in Section 5.8.1 of the ACE framework from the AS, as described in Section 5.8.1 of the ACE framework
[I-D.ietf-ace-oauth-authz]. The document follows the procedures [RFC9200]. The document follows the procedures defined in
defined in Section 3.2.1 of the DTLS profile Section 3.2.1 of the DTLS profile [RFC9202] for raw public keys
[I-D.ietf-ace-dtls-authorize] for RPK (Raw Public Keys [RFC7250]), (RPKs) [RFC7250]) and in Section 3.3.1 of [RFC7250] for pre-shared
and in Section 3.3.1 of the same document for PSK (Pre-Shared Keys). keys (PSKs). However, the content type of the request is set to
However, the content type of the request is set to "application/ "application/ace+json", and the AS uses JSON in the Payload of its
ace+json", and the AS uses JSON in the payload of its responses to responses to the Client and the RS. As explained earlier,
the Client and the RS. As explained earlier, implementations MAY implementations MAY also use the "application/ace+cbor" content type.
also use "application/ace+cbor" content type.
On receipt of the token request, the AS verifies the request. If the On receipt of the token request, the AS verifies the request. If the
AS successfully verifies the access token request and authorizes the AS successfully verifies the access token request and authorizes the
Client for the indicated audience (i.e., RS) and scopes (i.e., Client for the indicated audience (i.e., RS) and scopes (i.e.,
publish/subscribe permissions over topics as described in publish/subscribe permissions over topics, as described in
Section 2.3), the AS issues an access token (Figure 1 (B)). Section 2.3), the AS issues an access token (Figure 1, step (B)).
The response includes the parameters described in Section 5.8.2 of The response includes the parameters described in Section 5.8.2 of
the ACE framework [I-D.ietf-ace-oauth-authz]. For RPK, the the ACE framework [RFC9200]. For RPKs, the parameters are as
parameters are as described in Section 3.2.1 of the DTLS profile described in Section 3.2.1 of the DTLS profile [RFC9202]. For PSKs,
[I-D.ietf-ace-dtls-authorize]. For PSK, the document follows the document follows Section 3.3.1 of the DTLS profile [RFC9202]. In
Section 3.3.1 of the DTLS profile [I-D.ietf-ace-dtls-authorize]. In
both cases, if the response contains an "ace_profile" parameter, this both cases, if the response contains an "ace_profile" parameter, this
parameter is set to "mqtt_tls". The returned token is a Proof-of- parameter is set to "mqtt_tls". The returned token is a Proof-of-
Possession (PoP) token by default. Possession (PoP) token by default.
This document follows [RFC7800] for PoP semantics for JWTs (CWTs MAY This document follows [RFC7800] for PoP semantics for JWTs (CWTs MAY
also be used). The AS includes a "cnf" (confirmation) parameter in also be used). The AS includes a "cnf" (confirmation) parameter in
the PoP token, to declare that the Client possesses a particular key the PoP token to declare that the Client possesses a particular key
and RS can cryptographically confirm that the Client has possession and the RS can cryptographically confirm that the Client has
of that key, as described in [I-D.ietf-ace-oauth-params]. possession of that key, as described in [RFC9201].
Note that the contents of the web tokens (including the "cnf" Note that the contents of the web tokens (including the "cnf"
parameter) are to be consumed by the RS and not the Client (the parameter) are to be consumed by the RS and not the Client (the
Client obtains the key information in a different manner). The RPK Client obtains the key information in a different manner). The RPK
case is handled as described in Section 3.2.1 of the DTLS profile case is handled as described in Section 3.2.1 of the DTLS profile
[I-D.ietf-ace-dtls-authorize]. For the PSK case, the referenced [RFC9202]. For the PSK case, the referenced procedures apply, with
procedures apply, with the following exceptions to accommodate JWT the following exceptions to accommodate JWT and JOSE use. In this
and JOSE use. In this case, the AS adds a "cnf" parameter to the case, the AS adds a "cnf" parameter to the Access Information
access information carrying a JWK (JSON Web Key) [RFC7517] object carrying a JSON Web Key (JWK) [RFC7517] object that contains either
that contains either the symmetric key itself or a key identifier the symmetric key itself or a key identifier that can be used by the
that can be used by the RS to determine the secret key it shares with RS to determine the secret key it shares with the Client. The JWT is
the Client. The JWT is created as explained in Section 7 of created as explained in Section 7 of [RFC7519], and the JWT MUST
[RFC7519], and the JWT MUST include JWE [RFC7516]. If CWT/COSE is include a JSON Web Encryption (JWE) [RFC7516]. If a CWT/COSE is
used this information MUST be inside the "COSE_Key" object, and MUST used, this information MUST be inside the "COSE_Key" object and MUST
be encrypted using a "COSE_Encrypt0" structure. be encrypted using a "COSE_Encrypt0" structure.
The AS returns error responses for JSON-based interactions following The AS returns error responses for JSON-based interactions following
Section 5.2 of [RFC6749]. When CBOR is used, the interactions MUST Section 5.2 of [RFC6749]. When CBOR is used, the interactions MUST
implement Section 5.8.3 of the ACE framework implement the procedure described in Section 5.8.3 of the ACE
[I-D.ietf-ace-oauth-authz]. framework [RFC9200].
2.2. Client Connection Request to the Broker (C) 2.2. Client Connection Request to the Broker (C)
2.2.1. Overview of Client-RS Authentication Methods over TLS and MQTT 2.2.1. Overview of Client-RS Authentication Methods over TLS and MQTT
Unless the Client publishes and subscribes to only public topics, the Unless the Client publishes and subscribes to only public topics, the
Client and the Broker MUST perform mutual authentication. The Client Client and the Broker MUST perform mutual authentication. The Client
MUST authenticate to the Broker either over MQTT or TLS before MUST authenticate to the Broker either over MQTT or TLS before
performing any other action. For MQTT, the options are "None" and performing any other action. For MQTT, the options are "None" and
"ace". For TLS, the options are "Anon" for an anonymous client, and "ace". For TLS, the options are "Anon" for an anonymous client, and
"Known(RPK/PSK)" for RPK and PSK, respectively. The "None" and "Known(RPK/PSK)" for RPKs and PSKs, respectively. The "None" and
"Anon" options do not provide client authentication but can be used "Anon" options do not provide client authentication but can be used
either during authentication or in combination with authentication at either during authentication or in combination with authentication at
the other layer. When the Client uses TLS:Anon,MQTT:None, the Client the other layer. When the Client uses TLS:Anon,MQTT:None, the Client
can only publish or subscribe to public topics. Thus, the client can only publish or subscribe to public topics. Thus, the client
authentication procedures involve the following possible authentication procedures involve the following possible
combinations: combinations:
* TLS:Anon,MQTT:None: This option is used only for the topics that TLS:Anon,MQTT:None:
do not require authorization, including the "authz-info" topic. This option is used only for the topics that do not require
Publishing to the "authz-info" topic is described in authorization, including the "authz-info" topic. Publishing
Section 2.2.2. to the "authz-info" topic is described in Section 2.2.2.
* TLS:Anon,MQTT:ace: The token is transported inside the CONNECT TLS:Anon,MQTT:ace:
packet and MUST be validated using one of the methods described in The token is transported inside the CONNECT packet and MUST
Section 2.2.2. This option also supports a tokenless connection be validated using one of the methods described in
request for AS discovery. As per the ACE framework Section 2.2.2. This option also supports a tokenless
[I-D.ietf-ace-oauth-authz], a separate step is needed to determine connection request for AS discovery. As per the ACE
whether the discovered AS URI is authorized to act as an AS. framework [RFC9200], a separate step is needed to determine
whether the discovered AS URI is authorized to act as an AS.
* TLS:Known(RPK/PSK),MQTT:none: This specification supports client TLS:Known(RPK/PSK),MQTT:none:
authentication with TLS with RPK and PSK following the procedures This specification supports client authentication with TLS
described in DTLS profile [I-D.ietf-ace-dtls-authorize]. For the with RPKs and PSKs, following the procedures described in the
RPK, the Client MUST have published the token to the "authz-info" DTLS profile [RFC9202]. For the RPK, the Client MUST have
topic. For the PSK, the token MAY be published to the "authz- published the token to the "authz-info" topic. For the PSK,
info" topic, or MAY be, alternatively, provided as a "PSK the token MAY be published to the "authz-info" topic or MAY
identity" (e.g. an "identity" in the "identities" field in the be, alternatively, provided as a "PSK identity" (e.g., an
Client's "pre_shared_key" extension in TLS 1.3). "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 as TLS:Known(RPK/PSK),MQTT:ace:
the token transported in the CONNECT overwrites any permissions This option SHOULD NOT be chosen as the token transported in
passed during the TLS authentication. the CONNECT packet and overwrites any permissions passed
during the TLS authentication.
It is RECOMMENDED that the Client implements TLS:Anon,MQTT:ace as the It is RECOMMENDED that the Client implements TLS:Anon,MQTT:ace as the
first choice when working with protected topics. However, MQTT first choice when working with protected topics. However, MQTT
v3.1.1 Clients that do not prefer to overload username and password v3.1.1 Clients that do not prefer to overload the User Name and
fields for ACE (as described in Section 6) MAY implement Password fields for ACE (as described in Section 6) MAY implement
TLS:Known(RPK/PSK),MQTT:none, and consequently TLS:Anon,MQTT:None to TLS:Known(RPK/PSK),MQTT:none and, consequently, TLS:Anon,MQTT:None to
submit their token to "authz-info". submit their token to "authz-info".
The Broker MUST support TLS:Anon,MQTT:ace. To support Clients with The Broker MUST support TLS:Anon,MQTT:ace. To support Clients with
different capabilities, the Broker MAY provide multiple client different capabilities, the Broker MAY provide multiple client
authentication options, e.g. support TLS:Known(RPK),MQTT:none and authentication options, e.g., support TLS:Known(RPK),MQTT:none and
TLS:Anon,MQTT:None, to enable RPK-based client authentication. TLS:Anon,MQTT:None, to enable RPK-based client authentication.
The Client MUST authenticate the Broker during the TLS handshake. If The Client MUST authenticate the Broker during the TLS handshake. If
the Client authentication uses TLS:Known(RPK/PSK), then the Broker is the Client authentication uses TLS:Known(RPK/PSK), then the Broker is
authenticated using the respective method. Otherwise, to authenticated using the respective method. Otherwise, to
authenticate the Broker, the Client MUST validate a public key from 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" an X.509 certificate or an RPK from the Broker against the "rs_cnf"
parameter in the token response, which contains information about the parameter in the token response, which contains information about the
public key used by the RS to authenticate if the token type is "pop" public key used by the RS to authenticate if the token type is "pop"
and asymmetric keys are used as defined in and asymmetric keys are used as defined in [RFC9201]. The AS MAY
[I-D.ietf-ace-oauth-params]. The AS MAY include the thumbprint of include the thumbprint of the RS's X.509 certificate in the "rs_cnf"
the RS's X.509 certificate in the "rs_cnf" (thumbprint as defined in (thumbprint, as defined in [RFC9360]). In this case, the Client MUST
[I-D.ietf-cose-x509]). In this case, the Client MUST validate the RS validate the RS certificate against this thumbprint.
certificate against this thumbprint.
2.2.2. authz-info: The Authorization Information Topic 2.2.2. authz-info: The Authorization Information Topic
In the cases when the Client must transport the token to the Broker In the cases when the Client must transport the token to the Broker
first, the Client connects to the Broker to publish its token to the first, the Client connects to the Broker to publish its token to the
"authz-info" topic. The "authz-info" topic MUST be publish-only "authz-info" topic. The "authz-info" topic MUST only be published
(i.e., the Clients are not allowed to subscribe to it). "authz-info" (i.e., the Clients are not allowed to subscribe to it). "authz-info"
is not protected, and hence, the Client uses the TLS:Anon,MQTT:None is not protected, and hence, the Client uses the TLS:Anon,MQTT:None
option over a TLS connection. After publishing the token, the Client option over a TLS connection. After publishing the token, the Client
disconnects from the Broker and is expected to reconnect using client disconnects from the Broker and is expected to reconnect using client
authentication over TLS (i.e., TLS:Known(RPK/PSK),MQTT:none). authentication over TLS (i.e., TLS:Known(RPK/PSK),MQTT:none).
The Broker stores and indexes all tokens received to the "authz-info" The Broker stores and indexes all tokens received to the "authz-info"
topic in its key store (similar to the DTLS profile for ACE topic in its key store (similar to the DTLS profile for ACE
[I-D.ietf-ace-dtls-authorize]). This profile follows the [RFC9202]). This profile follows the recommendation of
recommendation of Section 5.10.1 of the ACE framework Section 5.10.1 of the ACE framework [RFC9200] and expects that the
[I-D.ietf-ace-oauth-authz] and expects that the Broker stores only Broker stores only one token per PoP key, and any other token linked
one token per PoP key, and any other token linked to the same key to the same key overwrites an existing token.
overwrites an existing token.
The Broker MUST verify the validity of the token (i.e., through local The Broker MUST verify the validity of the token (i.e., through local
validation or introspection, if the token is a reference) as validation or introspection if the token is a reference), as
described in Section 2.2.5. If the token is not valid, the Broker described in Section 2.2.5. If the token is not valid, the Broker
MUST discard the token. MUST discard the token.
Depending on the QoS level of the PUBLISH packet, the Broker returns Depending on the QoS level of the PUBLISH packet, the Broker returns
the error response as a PUBACK, PUBREC, or DISCONNECT packet. If the the error response as a PUBACK, PUBREC, or DISCONNECT packet. If the
QoS level is equal to 0, and the token is not valid, or the claims QoS level is equal to 0, and the token is not valid, or if the claims
cannot be obtained in the case of an introspected token, the Broker cannot be obtained in the case of an introspected token, the Broker
MUST send a DISCONNECT packet with the reason code 0x87 (Not MUST send a DISCONNECT packet with reason code 0x87 (Not authorized).
authorized). If the PUBLISH payload does not parse to a token, the If the PUBLISH Payload does not parse to a token, the Broker MUST
Broker MUST send a DISCONNECT with the reason code 0x99 (Payload send a DISCONNECT with reason code 0x99 (Payload format invalid).
format invalid).
If the QoS level of the PUBLISH packet is greater than or equal to 1, If the QoS level of the PUBLISH packet is greater than or equal to 1,
and the token is not valid, or the claims cannot be obtained in the and the token is not valid, or the claims cannot be obtained in the
case of an introspected token, the Broker MUST send the reason code case of an introspected token, the Broker MUST send reason code 0x87
0x87 (Not authorized) in the PUBACK or PUBREC. If the PUBLISH (Not authorized) in the PUBACK or PUBREC. If the PUBLISH Payload
payload does not parse to a token, the PUBACK/PUBREC reason code is does not parse to a token, the PUBACK/PUBREC reason code is 0x99
0x99 (Payload format invalid). (Payload format invalid).
It must be noted that when the Broker sends the "Not authorized" When the Broker sends the "Not authorized" response, it must be noted
response, this corresponds to the token being not valid, and not that that this corresponds to the token being not valid and not that the
the actual PUBLISH packet was not authorized. Given that the "authz- actual PUBLISH packet was not authorized. Given that the "authz-
info" is a public topic, this response is not expected to cause info" is a public topic, this response is not expected to cause
confusion. confusion.
2.2.3. Client Authentication over TLS 2.2.3. Client Authentication over TLS
This document supports TLS with Raw Public Keys (RPK) [RFC7250] and This document supports TLS with raw public keys (RPKs) [RFC7250] and
with Pre-Shared Keys (PSK). The TLS session setup follows the DTLS with pre-shared keys (PSKs). The TLS session setup follows the DTLS
profile for ACE [I-D.ietf-ace-dtls-authorize], as the profile applies profile for ACE [RFC9202], as the profile applies to TLS equally well
to TLS equally well [I-D.ietf-ace-extend-dtls-authorize]. When there [RFC9430]. When there are exceptions to the DTLS profile, these are
are exceptions to the DTLS profile, these are explicitly stated in explicitly stated in the document. If TLS 1.2 is used, [RFC7925]
the document. If TLS 1.2 is used, [RFC7925] describes how TLS can be describes how TLS can be used for constrained devices, alongside
used for constrained devices, alongside recommended cipher suites. recommended cipher suites. Additionally, TLS 1.2 implementations
Additionally, TLS 1.2 implementations MUST use the "Extended Main MUST use the "Extended Main Secret" extension (terminology adopted
Secret" extension (terminology adopted from from [TLS-bis]) to incorporate the handshake transcript into the main
[I-D.ietf-tls-rfc8446bis]) to incorporate the handshake transcript secret [RFC7627]. TLS implementations SHOULD use the Server Name
into the main secret [RFC7627]. TLS implementations SHOULD use the Indication (SNI) [RFC6066] and Application-Layer Protocol Negotiation
SNI (Server Name Indication) [RFC6066] and APLN (Application-Layer (ALPN) [RFC7301] extensions so the TLS handshake authenticates as
Protocol Negotiation) [RFC7301] extensions so the TLS handshake much of the protocol context as possible.
authenticates as much of the protocol context as possible.
2.2.3.1. Raw Public Key Mode 2.2.3.1. Raw Public Key Mode
This document follows the procedures defined in Section 3.2.2 of the This document follows the procedures defined in Section 3.2.2 of the
DTLS profile for ACE [I-D.ietf-ace-dtls-authorize] with the following DTLS profile for ACE [RFC9202] with the following exceptions. The
exceptions. The Client MUST upload the access token to the Broker Client MUST upload the access token to the Broker using the method
using the method specified in Section 2.2.2 before initiating the specified in Section 2.2.2 before initiating the handshake.
handshake.
2.2.3.2. Pre-Shared Key Mode 2.2.3.2. Pre-Shared Key Mode
This document follows the procedures defined in Section 3.3.2 of DTLS This document follows the procedures defined in Section 3.3.2 of the
profile for ACE [I-D.ietf-ace-dtls-authorize] with the following DTLS profile for ACE [RFC9202] with the following exceptions.
exceptions.
To use TLS 1.3 with pre-shared keys, the Client utilizes the PSK key To use TLS 1.3 with pre-shared keys, the Client utilizes the PSK
extension specified in [RFC8446] using the key conveyed in the "cnf" extension specified in [RFC8446] using the key conveyed in the "cnf"
parameter of the AS response. The same key is bound to the access parameter of the AS response. The same key is bound to the access
token in the "cnf" claim. The Client can upload the token as token in the "cnf" claim. The Client can upload the token, as
specified in Section 2.2.2 before initiating the handshake. When specified in Section 2.2.2, before initiating the handshake. When
using a previously uploaded token, the Client MUST indicate during using a previously uploaded token, the Client MUST indicate during
the handshake which previously uploaded access token it intends to the handshake which previously uploaded access token it intends to
use. To do so, it MUST create a "COSE_Key" or "JWK" structure with use. To do so, it MUST create a "COSE_Key" or "JWK" structure with
the "kid" that was conveyed in the "rs_cnf" claim in the token the "kid" that was conveyed in the "rs_cnf" claim in the token
response from the AS and the key type "symmetric". This structure is response from the AS and the key type "symmetric". This structure is
then included as the only element in the "cnf" structure and the then included as the only element in the "cnf" structure and the
encoded value of that "cnf" structure used as a PSK identity in TLS. encoded value of that "cnf" structure used as a PSK identity in TLS.
As an alternative to the access token upload, the Client can provide As an alternative to the access token upload, the Client can provide
the most recent access token, JWT or CWT, as a PSK identity. the most recent access token, JWT or CWT, as a PSK identity.
In contrast to DTLS profile for ACE [I-D.ietf-ace-dtls-authorize], a In contrast to the DTLS profile for ACE [RFC9202], a Client MAY omit
Client MAY omit support for the cipher suites support for the cipher suites TLS_PSK_WITH_AES_128_CCM_8 and
TLS_PSK_WITH_AES_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8. TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8. For TLS 1.2, however, a client
For TLS 1.2, however, a client MUST support MUST support TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 for PSKs [RFC8442]
TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 for PSK ([RFC8442]) and and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for RPKs [RFC8422], as
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for RPK ([RFC8422]), as recommended in [RFC9325] (and adjusted to be a PSK cipher suite as
recommended in [RFC7525] (and adjusted to be a PSK cipher suite as
appropriate). appropriate).
2.2.4. Client Authentication over MQTT 2.2.4. Client Authentication over MQTT
2.2.4.1. Transporting the Access Token Inside the MQTT CONNECT 2.2.4.1. Transporting the Access Token inside the MQTT CONNECT
This section describes how the Client transports the token to the This section describes how the Client transports the token to the
Broker inside the CONNECT packet. If this method is used, the Client Broker inside the CONNECT packet. If this method is used, the Client
TLS connection is expected to be anonymous, and the Broker is TLS connection is expected to be anonymous, and the Broker is
authenticated during the TLS connection setup. The approach authenticated during the TLS connection setup. The approach
described in this section is similar to an earlier proposal by described in this section is similar to an earlier proposal by
Fremantle, et al. [fremantle14]. Fremantle, et al. [Fremantle14].
After sending the CONNECT, the Client MUST wait to receive the After sending the CONNECT packet, the Client MUST wait to receive the
CONNACK from the Broker. The only packets it is allowed to send are CONNACK packet from the Broker. The only packets it is allowed to
DISCONNECT or AUTH that is in response to the Broker AUTH. send are DISCONNECT or AUTH that are in response to the Broker AUTH.
Similarly, except for a DISCONNECT and AUTH response from the Client, Similarly, except for a DISCONNECT and AUTH response from the Client,
the Broker MUST NOT process any packets before sending a CONNACK. the Broker MUST NOT process any packets before sending a CONNACK
packet.
Figure 2 shows the structure of the MQTT CONNECT packet used in MQTT Figure 2 shows the structure of the MQTT CONNECT packet used in MQTT
v5.0. A CONNECT packet is composed of a fixed header, a variable v5.0. A CONNECT packet is composed of a Fixed Header, a Variable
header, and a payload. The fixed header contains the Control Packet Header, and a Payload The Fixed Header contains the Control Packet
Type (CPT), Reserved, and Remaining Length fields. Remaining Length Type (CPT), Reserved, and Remaining Length fields. The Remaining
is a Variable Byte Integer that represents the number of bytes Length is a Variable Byte Integer that represents the number of bytes
remaining within the current Control Packet, including data in the remaining within the current Control Packet, including data in the
Variable Header and the Payload. The Variable Header contains the Variable Header and the Payload. The Variable Header contains the
Protocol Name, Protocol Level, Connect Flags, Keep Alive, and Protocol Name, Protocol Level, Connect flags, Keep Alive, and
Properties fields. The Connect Flags in the variable header specify Properties fields. The Connect flags in the Variable Header specify
the properties of the MQTT session. It also indicates the presence the properties of the MQTT Session. It also indicates the presence
or absence of some fields in the Payload. The payload contains one or absence of some fields in the Payload. The Payload contains one
or more encoded fields, namely a unique Client Identifier for the or more encoded fields, namely a unique Client Identifier for the
Client, a Will Topic, Will Payload, User Name, and Password. All but Client, a Will Topic, Will Payload, User Name, and Password. All but
the Client Identifier can be omitted depending on the flags in the the Client Identifier can be omitted depending on the flags in the
Variable Header. The Client Identifier identifies the Client to the Variable Header. The Client Identifier identifies the Client to the
Broker, and therefore, is unique for each Client. It must be noted Broker and, therefore, is unique for each Client. It must be noted
that the Client Identifier is an unauthenticated identifier used that the Client Identifier is an unauthenticated identifier used
within the MQTT protocol and so is not bound to the access token. within the MQTT protocol and so is not bound to the access token.
0 8 16 0 8 16
+---------------------------+ +---------------------------+
|Protocol name length = 4 | |Protocol name length = 4 |
+---------------------------+ +---------------------------+
| 'M' 'Q' | | 'M' 'Q' |
+---------------------------+ +---------------------------+
| 'T' 'T' | | 'T' 'T' |
+---------------------------+ +---------------------------+
|Proto.level=5|Connect flags| |Proto.level=5|Connect flags|
+---------------------------+ +---------------------------+
| Keep alive | | Keep alive |
+---------------------------+ +---------------------------+
| CONNECT Properties Length | | CONNECT Properties Length |
| (Upto 4 bytes) | | (up to 4 bytes) |
+---------------------------+ +---------------------------+
| ( ..Other properties..) | | ( ..Other properties..) |
+---------------------------+ +---------------------------+
| Authentication Method | | Authentication Method |
| (0x15) | Len. | | (0x15) | Len |
| Len | 'a' | | Len | 'a' |
| 'c' | 'e' | | 'c' | 'e' |
+---------------------------+ +---------------------------+
| Authentication Data | | Authentication Data |
| (0x16) | Len | | (0x16) | Len |
| Len | token | | Len | token |
| or token + PoP data | | or token + PoP data |
+---------------------------+ +---------------------------+
Figure 2: MQTT v5 CONNECT Variable Header with Authentication Figure 2: MQTT v5 CONNECT Variable Header with Authentication
Method Property for ACE Method Property for ACE
The CONNECT flags are Username, Password, Will retain, Will QoS, Will The CONNECT flags are User Name, Password, Will Retain, Will QoS,
Flag, Clean Start, and Reserved. Figure 3 shows how the flags MUST Will Flag, Clean Start, and Reserved. Table 1 shows how the flags
be set to use AUTH packets for authentication and authorization, MUST be set to use AUTH packets for authentication and authorization,
i.e., the username and password flags MUST be set to 0. An MQTT v5.0 i.e., the User Name Flag and Password Flag MUST be set to 0. An MQTT
Broker MAY also support token transport using Username and Password v5.0 Broker MAY also support token transport using the User Name and
to provide a security option for MQTT v3.1.1 Clients, as described in Password to provide a security option for MQTT v3.1.1 Clients, as
Section 6. described in Section 6.
+-----------------------------------------------------------+ +===========+==========+========+======+======+=======+==========+
|User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.| | User Name | Password | Will | Will | Will | Clean | Reserved |
| Flag |Flag | | | |Start| | | Flag | Flag | Retain | QoS | Flag | Start | |
+-----------------------------------------------------------+ +===========+==========+========+======+======+=======+==========+
| 0 | 0 | X | X X | X | X | 0 | | 0 | 0 | X | X X | X | X | 0 |
+-----------------------------------------------------------+ +-----------+----------+--------+------+------+-------+----------+
Figure 3: CONNECT Flags for AUTH Table 1: CONNECT Flags for AUTH
The Will Flag indicates that a Will message needs to be sent. The The Will Flag indicates that a Will Message needs to be sent. The
Client MAY set the Will Flag as desired (marked as "X" in Figure 3). 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 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 allows the publication of the Will Message (i.e., the Will Topic
filter is in the scope array). The check is performed against the Filter is in the scope array). The check is performed against the
token scope described in Section 2.3. If the Will authorization token scope described in Section 2.3. If the Will authorization
fails, the connection is refused as described in Section 2.4.1. If fails, the connection is refused, as described in Section 2.4.1. If
the Broker accepts the connection request, the Broker stores the Will the Broker accepts the connection request, the Broker stores the Will
message and publishes it when the Network Connection is closed Message and publishes it when the Network Connection is closed
according to Will QoS, and Will retain parameters and MQTT Will according to Will QoS, Will Retain parameters, and MQTT Will
management rules. To avoid publishing the Will Messages in the case management rules. To avoid publishing the Will Messages in the case
of temporary network disconnections, the Client specifies a Will of temporary network disconnections, the Client specifies a Will
Delay Interval in the Will Properties. Section 5 explains how the Delay Interval in the Will Properties. Section 5 explains how the
Broker deals with the retained messages in further detail. Broker deals with the retained messages in further detail.
In MQTT v5.0, the Client signals a clean session (i.e., that the 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 Session does not continue an existing Session) by setting the Clean
Start Flag to 1 in the CONNECT packet. In this profile, the Client Start flag to 1 in the CONNECT packet. In this profile, the Client
SHOULD always start with a clean session. The Broker MAY also signal SHOULD always start with a new Session. The Broker MAY also signal
that it does not support session continuation by setting Session that it does not support the continuation of an existing Session by
Expiry Interval to 0 in the CONNACK. If the Broker starts a clean setting the Session Expiry Interval to 0 in the CONNACK. If the
session, the Broker MUST set the Session Present flag to 0 in the Broker starts a new Session, the Broker MUST set the Session Present
CONNACK packet to signal this to the Client. flag to 0 in the CONNACK packet to signal this to the Client.
The Broker MAY support session continuation, e.g., if the Broker The Broker MAY support continuing an existing Session, e.g., if the
requires it for QoS reasons. In this case, if a CONNECT packet is Broker requires it for QoS reasons. In this case, if a CONNECT
received with Clean Start set to 0 and there is a Session associated packet is received with Clean Start set to 0, and there is a Session
with the Client Identifier, the Broker MUST resume communications associated with the Client Identifier, the Broker MUST resume
with the Client based on the state from the existing Session. In its communications with the Client based on the state from the existing
response, the Broker MUST set the Session Present flag to 1 in the Session. In its response, the Broker MUST set the Session Present
CONNACK packet to signal session continuation to the Client. The flag to 1 in the CONNACK packet to signal the continuation of an
session state stored by the Client and the Broker is described in existing Session to the Client. The Session State stored by the
Section 5. Client and the Broker is described in Section 5.
When reconnecting to a Broker that supports session continuation, the When reconnecting to a Broker that supports continuing existing
Client MUST still provide a token, in addition to using the same Sessions, the Client MUST still provide a token in addition to using
Client Identifier and setting the Clean Start to 0. The Broker MUST the same Client Identifier and setting the Clean Start to 0. The
still perform PoP validation on the provided token. If the token Broker MUST still perform PoP validation on the provided token. If
matches the stored state, the Broker MAY skip introspecting a token- the token matches the stored state, the Broker MAY skip introspecting
by-reference and use the stored introspection result. The Broker a token-by-reference and use the stored introspection result. The
MUST also verify the Client is authorized to receive or send MQTT Broker MUST also verify the Client is authorized to receive or send
packets that are pending transmission. When a Client connects with a MQTT packets that are pending transmission. When a Client connects
long Session Expiry Interval, the Broker may need to maintain the with a long Session Expiry Interval, the Broker may need to maintain
Client's MQTT session state after it disconnects for an extended the Client's MQTT Session State after it disconnects for an extended
period. Brokers SHOULD implement administrative policies to limit period. Brokers SHOULD implement administrative policies to limit
misuse. misuse.
Note that, according to the MQTT standard, the Broker uses the Client Note that, according to the MQTT standard, the Broker uses the Client
Identifier to identify the session state. In the case of a Client Identifier to identify the Session State. In the case of a Client
Identifier collision, a Client may take over another Client's Identifier collision, a Client may take over another Client's
session. Given that the Broker MUST associate the Client with a Session. Given that the Broker MUST associate the Client with a
valid token, a Client will only send or receive messages to its valid token, a Client will only send or receive messages to its
authorized topics. Therefore, while this issue is not expected to authorized topics. Therefore, while this issue is not expected to
affect security, it may affect QoS (i.e., PUBLISH or QoS messages affect security, it may affect QoS (i.e., PUBLISH or QoS messages
saved for Client A may be delivered to a Client B). In addition, if saved for Client A may be delivered to a Client B). In addition, if
this Client Identifier represents a Client already connected to the this Client Identifier represents a Client already connected to the
Broker, the Broker sends a DISCONNECT packet to the existing Client Broker, the Broker sends a DISCONNECT packet to the existing Client
with Reason Code of 0x8E (Session taken over) and closes the with reason code 0x8E (Session taken over) and closes the connection
connection to the Client. to the Client.
2.2.4.2. Authentication Using AUTH Property 2.2.4.2. Authentication Using the AUTH Property
To use AUTH, the Client MUST set the Authentication Method as a Figure 2 shows the Authentication Method and Authentication Data
property of a CONNECT packet by using the property identifier 21 fields when the client authenticates using the AUTH property. The
(0x15). This is followed by a UTF-8 Encoded String containing the Client MUST set the Authentication Method as a property of a CONNECT
name of the Authentication Method, which MUST be set to "ace". If packet by using the property identifier 21 (0x15). This is followed
the Broker does not support this profile, it sends a CONNACK with a by a UTF-8-encoded string containing the name of the Authentication
Reason Code of 0x8C (Bad authentication method). 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, The Authentication Method is followed by the Authentication Data,
which has a property identifier 22 (0x16) and is Binary Data. Based which has a property identifier 22 (0x16) and is Binary Data. Based
on the Authentication Data, the Broker MUST support both options on the Authentication Data, the Broker MUST support both options
below: below:
* Proof-of-Possession using a challenge from the TLS session * proof of possession using a challenge from the TLS session
* Proof-of-Possession via Broker-generated challenge/response
2.2.4.2.1. 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
+-----------------------------------------------------------------+ +-----------------------------------------------------------------+
|Authentication|Token Length|Token |MAC or Signature | |Authentication|Token Length|Token |MAC or Signature |
|Data Length | | |(over TLS exporter content) | |Data Length | | |(over TLS exporter content) |
+-----------------------------------------------------------------+ +-----------------------------------------------------------------+
Figure 4: Authentication Data for PoP Based on TLS Exporter Content Figure 3: Authentication Data for PoP Based on TLS Exporter Content
For this option, the Authentication Data inside the Client's CONNECT For this option, the Authentication Data inside the Client's CONNECT
MUST contain the two-byte integer token length, the token, and the packet MUST contain the two-byte integer token length, the token, and
keyed message digest (MAC) or the Client signature (as shown in the keyed message digest (MAC) or the Client signature (as shown in
Figure 4). The Proof-of-Possession key in the token is used to Figure 3). The Proof-of-Possession key in the token is used to
calculate the keyed message digest (MAC) or the Client signature calculate the keyed message digest (MAC) or the Client signature
based on the content obtained from the TLS exporter ([RFC5705] for based on the content obtained from the TLS exporter ([RFC5705] for
TLS 1.2, and Section 7.5 of [RFC8446]) for TLS 1.3. This content is TLS 1.2 and Section 7.5 of [RFC8446] for TLS 1.3). This content is
exported from the TLS session using the exporter label "EXPORTER-ACE- exported from the TLS session using the exporter label "EXPORTER-ACE-
MQTT-Sign-Challenge", an empty context, and length of 32 bytes. The MQTT-Sign-Challenge", an empty context, and a length of 32 bytes.
token is also validated as described in Section 2.2.5, and the Broker The token is also validated, as described in Section 2.2.5, and the
responds with a CONNACK with the appropriate response code. The Broker responds with a CONNACK packet with the appropriate response
Client cannot reauthenticate using this method during the same TLS code. The Client cannot reauthenticate using this method during the
session (see Section 4). same TLS session (see Section 4).
2.2.4.2.2. Proof-of-Possession via Broker-generated Challenge/Response 2.2.4.2.2. Proof of Possession via Broker-generated Challenge/Response
+------------------------------------+ +------------------------------------+
|Authentication|Token Length|Token | |Authentication|Token Length|Token |
|Data Length | | | |Data Length | | |
+------------------------------------+ +------------------------------------+
Figure 5: Authentication Data to Initiate PoP Based on Challenge/ Figure 4: Authentication Data to Initiate PoP Based on Challenge/
Response Response
+--------------------------+ +--------------------------+
|Authentication|RS Nonce | |Authentication|RS Nonce |
|Data Length |(8 bytes) | |Data Length |(8 bytes) |
+--------------------------+ +--------------------------+
Figure 6: Authentication Data for Broker Challenge Figure 5: Authentication Data for Broker Challenge
For this option, the Broker follows a Broker-generated challenge/ For this option, the Broker follows a Broker-generated challenge/
response protocol. If the Authentication Data inside the Client's response protocol. If the Authentication Data inside the Client's
CONNECT contains only the two-byte integer token length and the token CONNECT contains only the two-byte integer token length and the token
(as shown in Figure 5), the Broker MUST respond with an AUTH packet, (as shown in Figure 4), the Broker MUST respond with an AUTH packet
with the Authenticate Reason Code set to 0x18 (Continue with the authenticated reason code set to 0x18 (Continue
Authentication). The Broker also uses this method if the Authentication). The Broker also uses this method if the
Authentication Data does not contain a token, but the Broker has a Authentication Data does not contain a token, but the Broker has a
token stored for the connecting Client. token stored for the connecting Client.
The Broker continues authentication using an AUTH packet that The Broker continues authentication using an AUTH packet that
contains the Authentication Method and the Authentication Data. The contains the Authentication Method and the Authentication Data. The
Authentication Method MUST be set to "ace", and the Authentication 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 Data MUST NOT be empty and MUST contain an 8-byte RS nonce as a
challenge for the Client (Figure 6). challenge for the Client (Figure 5).
+---------------------------------------------------------+ +---------------------------------------------------------+
|Authentication|Client Nonce |MAC or Signature | |Authentication|Client Nonce |MAC or Signature |
|Data Length |(8 bytes) |(over RS nonce+Client nonce)| |Data Length |(8 bytes) |(over RS nonce+Client nonce)|
+---------------------------------------------------------+ +---------------------------------------------------------+
Figure 7: Authentication Data for Client Challenge Response Figure 6: Authentication Data for the Client Challenge Response
The Client responds to this with an AUTH packet with a reason code The Client responds to this with an AUTH packet with reason code 0x18
0x18 (Continue Authentication). Similarly, the Client packet sets (Continue Authentication). Similarly, the Client packet sets the
the Authentication Method to "ace". The Authentication Data in the Authentication Method to "ace". The Authentication Data in the
Client's response is formatted as shown in Figure 7 and includes the Client's response is formatted as shown in Figure 6 and includes the
8-byte Client nonce, and the signature or MAC computed over the RS 8-byte Client nonce and the signature or MAC computed over the RS
nonce concatenated with the Client nonce using PoP key in the token. nonce concatenated with the Client nonce using PoP key in the token.
Next, the token is validated as described in Section 2.2.5. The Next, the token is validated as described in Section 2.2.5. The
success case is illustrated in Figure 8. The Client MAY also re- success case is illustrated in Figure 7. The Client MAY also
authenticate using this challenge-response flow, as described in reauthenticate using this challenge-response flow, as described in
Section 4. Section 4.
Client Broker Client Broker
| | | |
|<===========>| TLS connection setup |<===========>| TLS connection setup
| | | |
| | | |
+------------>| CONNECT with Authentication Data +------------>| CONNECT with Authentication Data
| | contains only token | | contains only token
| | | |
<-------------+ AUTH 0x18 (Cont. Authentication) <-------------+ AUTH 0x18 (Cont. Authentication)
| | 8-byte RS nonce as challenge | | 8-byte RS nonce as challenge
| | | |
|------------>| AUTH 0x18 (Cont. Authentication) |------------>| AUTH 0x18 (Cont. Authentication)
| | 8-byte Client nonce + signature/MAC | | 8-byte Client nonce + signature/MAC
| | | |
| |---+ Token validation | |---+ Token validation
| | | (may involve introspection) | | | (may involve introspection)
| |<--+ | |<--+
| | | |
|<------------+ CONNACK 0x00 (Success) |<------------+ CONNACK 0x00 (Success)
Figure 8: PoP Challenge/Response Flow - Success Figure 7: PoP Challenge/Response Flow - Success
2.2.5. Broker Token Validation 2.2.5. Broker Token Validation
The Broker MUST verify the validity of the token either locally 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 (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 to the introspection endpoint of the AS (as described for HTTP-based
interactions in Section 5.9 of the ACE framework interactions in Section 5.9 of the ACE framework [RFC9200]). The
[I-D.ietf-ace-oauth-authz]). The Broker MUST verify the claims in Broker MUST verify the claims in the access token according to the
the access token according to the rules set in Section 5.10.1.1 of rules set in Section 5.10.1.1 of the ACE framework [RFC9200].
the ACE framework [I-D.ietf-ace-oauth-authz].
To authenticate the Client, the Broker validates the signature or the To authenticate the Client, the Broker validates the signature or the
MAC, depending on how the PoP protocol is implemented. For self- MAC, depending on how the PoP protocol is implemented. For self-
contained tokens, the Broker MUST process the security protection of contained tokens, the Broker MUST process the security protection of
the token first, as specified by the respective token format, i.e. a the token first, as specified by the respective token format, i.e., a
CWT token uses COSE, while a JWT token uses JOSE. For a token-by- CWT uses COSE, while a JWT uses JOSE. For a token-by-reference, the
reference, the Broker uses the "cnf" structure returned as a result Broker uses the "cnf" structure returned as a result of token
of token introspection as specified in [RFC7519]. HS256 (HMAC-SHA- introspection, as specified in [RFC7519]. HMAC-SHA-256 (HS256)
256) [RFC6234] and Ed25519 [RFC8032] are mandatory to implement for [RFC6234] and Ed25519 [RFC8032] are mandatory to implement for the
the Broker. The Client MUST implement at least one of them depending Broker. The Client MUST implement at least one of them depending on
on the choice of symmetric or asymmetric validation. Validation of the choice of symmetric or asymmetric validation. Validation of the
the signature or MAC MUST fail if the signature algorithm is set to signature or MAC MUST fail if the signature algorithm is set to
"none", when the key used for the signature algorithm cannot be "none" when the key used for the signature algorithm cannot be
determined, or the computed and received signature/MAC do not match. 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 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 intended destination (i.e., the audience) of the token, and if
the token was issued by an authorized authorization server. If the the token was issued by an authorized Authorization Server. If the
Client is using TLS RPK mode to authenticate to the Broker, the AS Client is using TLS RPK mode to authenticate to the Broker, the AS
constructs the access token so that the Broker can associate the constructs the access token so that the Broker can associate the
access token with the Client's public key. The "cnf" claim MUST 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 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. the Broker (e.g., from previous communication), a reference to it.
2.3. Token Scope and Authorization 2.3. Token Scope and Authorization
The scope field contains the publish and subscribe permissions for The scope field contains the publish and subscribe permissions for
the Client. Therefore, the token or its introspection result MUST be the Client. Therefore, the token or its introspection result MUST be
cached to allow a Client's future PUBLISH and SUBSCRIBE messages. 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 During the CONNECT, if the Will Flag is set to 1, the Broker MUST
also authorize the publication of the Will Topic and message using also authorize the publication of the Will Topic and Will Message
the token's scope field. The Broker uses the scope to match against using the token's scope field. The Broker uses the scope to match
the Topic Name in a PUBLISH packet (including Will Topic in the against the Topic Name in a PUBLISH packet (including Will Topic in
CONNECT) or a Topic Filter in a SUBSCRIBE packet. the CONNECT) or a Topic Filter in a SUBSCRIBE packet.
The scope in the token is a single value. For a JWT, the single The scope in the token is a single value. For a JWT, the single
scope is base64url encoded string with any padding characters scope is a base64url-encoded string with any padding characters
removed, which has an internal structure of a JSON array. For a CWT, removed, which has an internal structure of a JSON array. For a CWT,
this information is represented in CBOR. The internal structure this information is represented in CBOR. The internal structure
follows the Authorization Information Format (AIF) for ACE follows the Authorization Information Format (AIF) for ACE [RFC9237].
[I-D.ietf-ace-aif]. Using the Concise Data Definition Language Using the Concise Data Definition Language (CDDL) [RFC8610], the
(CDDL) [RFC8610], the specific data model for MQTT is: specific data model for MQTT is:
AIF-MQTT = AIF-Generic<mqtt-topic-filter, mqtt-permissions> AIF-MQTT = AIF-Generic<mqtt-topic-filter, mqtt-permissions>
AIF-Generic<Toid, Tperm> = [* [Toid, Tperm]] AIF-Generic<Toid, Tperm> = [* [Toid, Tperm]]
mqtt-topic-filter = tstr ; as per Section 4.7 of MQTT v5.0 mqtt-topic-filter = tstr ; as per Section 4.7 of MQTT v5.0
mqtt-permissions = [+permission] mqtt-permissions = [+permission]
permission = "pub"/"sub" permission = "pub"/"sub"
Figure 9: AIF-MQTT data model Figure 8: AIF-MQTT Data Model
Topic filters are implemented according to Section 4.7 of MQTT v5.0 - Topic Filters are implemented according to Section 4.7 of the MQTT
the OASIS Standard [MQTT-OASIS-Standard-v5]. By default, Wildcard v5.0 OASIS Standard [MQTT-OASIS-Standard-v5]. By default, Wildcard
Subscriptions are supported, and so, the topic filter may include Subscriptions are supported, and so, the Topic Filter may include
special wildcard characters. The multi-level wildcard, "#", matches special wildcard characters. The multi-level wildcard, "#", matches
any number of levels within a topic, and the single-level wildcard, any number of levels within a topic, and the single-level wildcard,
"+", matches one topic level. The Broker MAY signal in the CONNACK "+", matches one topic level. The Broker MAY signal in the CONNACK
explicitly whether wildcard subscriptions are supported by returning explicitly whether Wildcard Subscriptions are supported by returning
a CONNACK property "Wildcard Subscription Available". A value of 0 a CONNACK property "Wildcard Subscription Available". A value of 0
means that Wildcard Subscriptions are not supported. A value of 1 means that Wildcard Subscriptions are not supported. A value of 1
means Wildcard Subscriptions are supported. means Wildcard Subscriptions are supported.
Following this model, an example scope may contain: Following this model, an example scope may contain:
[["topic1",["pub","sub"]],["topic2/#",["pub"]],["+/topic3",["sub"]]] [["topic1",["pub","sub"]],["topic2/#",["pub"]],["+/topic3",["sub"]]]
Figure 10: Example scope Figure 9: Example Scope
This access token gives publish ("pub") and subscribe ("sub") This access token gives publish ("pub") and subscribe ("sub")
permissions to the "topic1", publish permission to all the subtopics permissions to the "topic1", publish permission to all the subtopics
of "topic2", and subscribe permission to all "topic3", skipping one of "topic2", and subscribe permission to all "topic3", skipping one
level. level.
If the scope is empty, the Broker records no permissions for the 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 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 publish or subscribe to any protected topics. The non-empty scope is
used to authorize the Will Topic, if provided, in the CONNECT packet, used to authorize the Will Topic, if provided, in the CONNECT packet,
during connection setup, and if the connection request succeeds, the during connection setup and, if the connection request succeeds, the
Topic Names or Topic Filters requested in the future PUBLISH and Topic Names or Topic Filters requested in the future PUBLISH and
SUBSCRIBE packets. For the authorization to succeed, the Broker MUST SUBSCRIBE packets. For the authorization to succeed, the Broker MUST
verify that the topic name or filter in question is either an exact verify that the Topic Name or Topic Filter in question is either an
match to or a subset of at least one "topic_filter" in the scope. exact match to or a subset of at least one "topic_filter" in the
scope.
2.4. Broker Response to Client Connection Request 2.4. Broker Response to Client Connection Request
Based on the validation result (obtained either via local inspection Based on the validation result (obtained either via local inspection
or using the introspection interface of the AS), the Broker MUST send or using the introspection interface of the AS), the Broker MUST send
a CONNACK packet to the Client. a CONNACK packet to the Client.
2.4.1. Unauthorized Request and the Optional Authorization Server 2.4.1. Unauthorized Request and the Optional Authorization Server
Discovery Discovery
Authentication can fail for the following reasons: Authentication can fail for the following reasons:
* If the Client does not provide a valid token, * if the Client does not provide a valid token,
* the Client omits the Authentication Data field and the Broker has * the Client omits the Authentication Data field and the Broker has
no token stored for the Client, no token stored for the Client,
* the token or Authentication data are malformed, or * the token or Authentication data are malformed, or
* if the Will flag is set, the authorization checks for the Will * if the Will Flag is set, the authorization checks for the Will
topic fails. Topic fails.
The Broker responds with the CONNACK reason code 0x87 (Not The Broker responds with the CONNACK reason code 0x87 (Not
Authorized) or any other applicable reason code. Authorized) or any other applicable reason code.
The Broker MAY also trigger AS discovery and include a User Property The Broker MAY also trigger AS discovery and include a User Property
(identified as property type 38 (0x26)) in the CONNACK for the AS (identified as property type 38 (0x26)) in the CONNACK for the AS
Request Creation Hints. The User Property is a UTF-8 string pair, 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 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 be set to "ace_as_hint". The value of the User Property is a UTF-
encoded JSON object containing the mandatory "AS" parameter, and the 8-encoded JSON object containing the mandatory "AS" parameter and the
optional parameters "audience", "kid", "cnonce", and "scope" as optional parameters "audience", "kid", "cnonce", and "scope", as
defined in Section 5.3 of the ACE framework defined in Section 5.3 of the ACE framework [RFC9200].
[I-D.ietf-ace-oauth-authz].
2.4.2. Authorization Success 2.4.2. Authorization Success
On success, the reason code of the CONNACK is 0x00 (Success). If the 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 Broker starts a new Session, it MUST also set Session Present to 0 in
the CONNACK packet to signal a clean session to the Client. the CONNACK packet to signal a new Session to the Client. Otherwise,
Otherwise, it MUST set Session Present to 1. it MUST set Session Present to 1.
Having accepted the connection, the Broker MUST be prepared to store Having accepted the connection, the Broker MUST be prepared to store
the token during the connection and after disconnection for future the token during the connection and after disconnection for future
use. If the token is not self-contained and the Broker uses token use. If the token is not self-contained and the Broker uses token
introspection, it MAY cache the validation result to authorize the introspection, it MAY cache the validation result to authorize the
subsequent PUBLISH and SUBSCRIBE packets. PUBLISH and SUBSCRIBE subsequent PUBLISH and SUBSCRIBE packets. PUBLISH and SUBSCRIBE
packets, which are sent after a connection setup, do not contain packets, which are sent after a connection setup, do not contain
access tokens. If the introspection result is not cached, the Broker access tokens. If the introspection result is not cached, the Broker
needs to introspect the saved token for each request. The Broker needs to introspect the saved token for each request. The Broker
SHOULD also use a cache timeout to introspect tokens regularly. The SHOULD also use a cache timeout to introspect tokens regularly. The
timeout value is application-specific and should be chosen to reduce timeout value is specific to the application and should be chosen to
the risk of using stale introspection responses. reduce the risk of using stale introspection responses.
3. Authorizing PUBLISH and SUBSCRIBE Packets 3. Authorizing PUBLISH and SUBSCRIBE Packets
Using the cached token or its introspection result, the Broker uses Using the cached token or its introspection result, the Broker uses
the scope field to match against the Topic Name in a PUBLISH packet, the scope field to match against the Topic Name in a PUBLISH packet
or a Topic Filter in a SUBSCRIBE packet. or a Topic Filter in a SUBSCRIBE packet.
3.1. PUBLISH Packets from the Publisher Client to the Broker 3.1. PUBLISH Packets from the Publisher Client to the Broker
On receiving the PUBLISH packet, the Broker MUST use the type of On receiving the PUBLISH packet, the Broker MUST use the type of
packet (i.e., PUBLISH) and the Topic name in the packet header to 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 match against the scope array items in the cached token or its
introspection result. Following the example in Section 2.3, the introspection result. Following the example in Section 2.3, the
Client sending a PUBLISH for "topic2/a" would be allowed, as the Client sending a PUBLISH packet for "topic2/a" would be allowed, as
scope array includes the ["topic2/#",["pub"]]. the scope array includes the ["topic2/#",["pub"]].
If the Client is allowed to publish to the topic, the Broker If the Client is allowed to publish to the topic, the Broker
publishes the message to all valid subscribers of the topic. In the publishes the message to all valid subscribers of the topic. In the
case of an authorization failure, the Broker MUST return an error if case of an authorization failure, the Broker MUST return an error if
the Client has set the QoS level of the PUBLISH packet to greater the Client has set the QoS level of the PUBLISH packet to greater
than or equal to 1. Depending on the QoS level, the Broker responds than or equal to 1. Depending on the QoS level, the Broker responds
with either a PUBACK or PUBREC packet with reason code 0x87 (Not with either a PUBACK or PUBREC packet with reason code 0x87 (Not
authorized). On receiving an acknowledgment with 0x87 (Not authorized). On receiving an acknowledgment with 0x87 (Not
authorized), the Client MAY reauthenticate by providing a new token authorized), the Client MAY reauthenticate by providing a new token,
as described in Section 4. as described in Section 4.
For QoS level 0, the Broker sends a DISCONNECT with reason code 0x87 For QoS level 0, the Broker sends a DISCONNECT packet with reason
(Not authorized) and closes the Network Connection. Note that the code 0x87 (Not authorized) and closes the Network Connection. Note
server-side DISCONNECT is a new feature of MQTT v5.0 (in MQTT v3.1.1, that the server-side DISCONNECT is a new feature of MQTT v5.0 (in
the server needs to drop the connection). MQTT v3.1.1, the server needs to drop the connection).
For all QoS levels, the Broker MAY return 0x80 Unspecified error if For all QoS levels, the Broker MAY return 0x80 (Unspecified error) if
they do not want to leak the topic names to unauthorized clients. they do not want to leak the Topic Names to unauthorized clients.
3.2. PUBLISH Packets from the Broker to the Subscriber Clients 3.2. PUBLISH Packets from the Broker to the Subscriber Clients
To forward PUBLISH packets to the subscribing Clients, the Broker To forward PUBLISH packets to the subscribing Clients, the Broker
identifies all the subscribers that have valid matching topic identifies all the subscribers that have valid matching Topic
subscriptions to the Topic name of the PUBLISH packet (i.e., the Subscriptions to the Topic Name of the PUBLISH packet (i.e., the
tokens are valid, and token scopes allow a subscription to this tokens are valid, and token scopes allow a Subscription to this
particular Topic name). The Broker forwards the PUBLISH packet to particular Topic Name). The Broker forwards the PUBLISH packet to
all the valid subscribers. all the valid subscribers.
The Broker MUST NOT forward messages to unauthorized subscribers. To The Broker MUST NOT forward messages to unauthorized subscribers. To
avoid silently dropping messages, the Broker MUST close the network avoid silently dropping messages, the Broker MUST close the Network
connection and SHOULD inform the affected subscribers. The only way Connection and SHOULD inform the affected subscribers. In this case,
to inform a client, in this case, would be sending a DISCONNECT the only way to inform a client would be sending a DISCONNECT packet.
packet. Therefore, the Broker SHOULD send a DISCONNECT packet with Therefore, the Broker SHOULD send a DISCONNECT packet with reason
the reason code 0x87 (Not authorized) before closing the network code 0x87 (Not authorized) before closing the Network Connection to
connection to these clients. these clients.
3.3. Authorizing SUBSCRIBE Packets 3.3. Authorizing SUBSCRIBE Packets
In MQTT, a SUBSCRIBE packet is sent from a Client to the Broker to In MQTT, a SUBSCRIBE packet is sent from a Client to the Broker to
create one or more subscriptions to one or more topics. The create one or more Subscriptions to one or more topics. The
SUBSCRIBE packet may contain multiple Topic Filters. The Topic SUBSCRIBE packet may contain multiple Topic Filters. The Topic
Filters may include wildcard characters. Filters may include wildcard characters.
On receiving the SUBSCRIBE packet, the Broker MUST use the type of 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 packet (i.e., SUBSCRIBE) and the Topic Filter in the packet header to
match against the scope field of the stored token or introspection 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 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 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 in the Client's token. For example, if the Client sends a SUBSCRIBE
subscription request for topic "a/b/*", and has a token that permits request for topic "a/b/*" and has a token that permits "a/*", this is
"a/*", this is a valid subscription request, as "a/b/*" is a subset a valid SUBSCRIBE request, as "a/b/*" is a subset of "a/*". (The
of "a/*". (The process is similar to a Broker matching the Topic process is similar to a Broker matching the Topic Name in a PUBLISH
Name in a PUBLISH packet against the Subscriptions known to the packet against the Subscriptions known to the Server.)
Server.)
As a response to the SUBSCRIBE packet, the Broker issues a SUBACK. As a response to the SUBSCRIBE packet, the Broker issues a SUBACK
For each Topic Filter, the SUBACK packet includes a return code packet. For each Topic Filter, the SUBACK packet includes a return
matching the QoS level for the corresponding Topic Filter. In the code matching the QoS level for the corresponding Topic Filter. In
case of failure, the return code is 0x87, indicating that the Client the case of failure, the return code is 0x87, indicating that the
is not authorized. The Broker MAY return 0x80 Unspecified error if Client is not authorized. The Broker MAY return 0x80 (Unspecified
they do not want to leak the topic names to unauthorized clients. A error) if they do not want to leak the Topic Names to unauthorized
reason code is returned for each Topic Filter. Therefore, the Client clients. A reason code is returned for each Topic Filter.
may receive success codes for a subset of its Topic Filters while Therefore, the Client may receive success codes for a subset of its
being unauthorized for the rest. Topic Filters while being unauthorized for the rest.
4. Token Expiration, Update, and Reauthentication 4. Token Expiration, Update, and Reauthentication
The Broker MUST check for token expiration whenever a CONNECT, The Broker MUST check for token expiration whenever a CONNECT,
PUBLISH, or SUBSCRIBE is received or sent. The Broker SHOULD check PUBLISH, or SUBSCRIBE packet is received or sent. The Broker SHOULD
for token expiration on receiving a PINGREQUEST. The Broker MAY also check for token expiration on receiving a PINGREQ packet. The Broker
check for token expiration periodically, e.g., every hour. This may MAY also check for token expiration periodically, e.g., every hour.
allow for early detection of a token expiry. This may allow for early detection of a token expiry.
The token expiration is checked by checking the "exp" claim of a JWT The token expiration is checked by checking the "exp" claim of a JWT
or introspection response or via performing an introspection request or introspection response or via performing an introspection request
with the AS as described in Section 5.9 of the ACE framework with the AS, as described in Section 5.9 of the ACE framework
[I-D.ietf-ace-oauth-authz]. Token expirations may trigger the Broker [RFC9200]. Token expirations may trigger the Broker to send PUBACK,
to send PUBACK, SUBACK and DISCONNECT packets with return code set to SUBACK, and DISCONNECT packets with the return code set to "Not
"Not authorized". After sending a DISCONNECT, the Network Connection authorized". After sending a DISCONNECT packet, the Network
is closed, and no more messages can be sent. Connection is closed, and no more messages can be sent.
The Client MAY reauthenticate as a response to the PUBACK and SUBACK The Client MAY reauthenticate a response to PUBACK and SUBACK, which
that signal loss of authorization. The Clients MAY also proactively signal loss of authorization. The Clients MAY also proactively
update their tokens, i.e., before they receive a packet with a "Not update their tokens, i.e., before they receive a packet with a "Not
authorized" return code. To start reauthentication, the Client MUST authorized" return code. To start reauthentication, the Client MUST
send an AUTH packet with the reason code 0x19 (Re-authentication). send an AUTH packet with reason code 0x19 (Reauthentication). The
The Client MUST set the Authentication Method as "ace" and transport Client MUST set the Authentication Method as "ace" and transport the
the new token in the Authentication Data. If re-authenticating new token in the Authentication Data. If reauthenticating during the
during the current TLS session, the Client MUST NOT use the method current TLS session, the Client MUST NOT use the method described in
described in Section 2.2.4.2.1, Proof-of-Possession using a challenge Section 2.2.4.2.1, i.e., proof of possession using a challenge from
from the TLS session, to avoid re-using the same challenge value from the TLS session, to avoid reusing the same challenge value from the
the TLS-Exporter. Note that this means that servers will either need TLS-Exporter. Note that this means that servers will either need to
to record in the session ticket or database entry whether the TLS- 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 was used or always deny use of the TLS-
Exporter-derived challenge for resumed sessions. In TLS 1.3, the Exporter-derived challenge for resumed sessions. In TLS 1.3, the
resumed connection would have a new exporter value, but the resumed connection would have a new exporter value, but the
requirement is phrased this way for simplicity. For re- requirement is phrased this way for simplicity. For
authentications in the same TLS-session, the Client MUST use the 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 challenge-response PoP, as defined in Section 2.2.4.2.2. The Broker
accepts reauthentication requests if the Client has already submitted accepts reauthentication requests if the Client has already submitted
a token (may be expired), for which it performed proof-of-possession. a token (may be expired), for which it performed proof of possession.
Otherwise, the Broker MUST deny the request. If the reauthentication Otherwise, the Broker MUST deny the request. If the reauthentication
fails, the Broker MUST send a DISCONNECT with the reason code 0x87 fails, the Broker MUST send a DISCONNECT packet with reason code 0x87
(Not Authorized). (Not Authorized).
5. Handling Disconnections and Retained Messages 5. Handling Disconnections and Retained Messages
In the case of a Client DISCONNECT, if the Session Expiry Interval is In the case of a Client DISCONNECT, if the Session Expiry Interval is
set to 0, the Broker doesn't maintain session state but MUST keep the set to 0, the Broker doesn't store the Session State but MUST keep
retained messages. If the Broker maintains session state, the state the retained messages. If the Broker stores the Session State, the
MAY include the token and its introspection result (for reference state MAY include the token and its introspection result (for
tokens) in addition to the MQTT session state. The MQTT session reference tokens) in addition to the MQTT Session State. The MQTT
state is identified by the Client Identifier and includes the Session State is identified by the Client Identifier and includes the
following: following:
* Client subscription state, * the Client Subscriptions,
* messages with QoS levels 1 and 2, and which have not been * messages with QoS levels 1 and 2, which have not been completely
completely acknowledged or are pending transmission to the Client, acknowledged or are pending transmission to the Client, and
and
* if the Session is currently not connected, the time at which the * if the Session is currently not connected, the time at which the
Session will end and Session State will be discarded. Session will end and the Session State will be discarded.
The token/introspection state is not part of the MQTT session state, The token/introspection state is not part of the MQTT Session State,
and PoP validation is required for each new connection, regardless of and PoP validation is required for each new connection, regardless of
whether MQTT session continuation is used. whether existing MQTT Sessions are continued.
The messages to be retained are indicated to the Broker by setting a The messages to be retained are indicated to the Broker by setting a
RETAIN flag in a PUBLISH packet. This way, the publisher signals to RETAIN flag in a PUBLISH packet. This way, the publisher signals to
the Broker to store the most recent message for the associated topic. the Broker to store the most recent message for the associated topic.
Hence, the new subscribers can receive the last sent message from the Hence, the new subscribers can receive the last sent message from the
publisher for that particular topic without waiting for the next publisher for that particular topic without waiting for the next
PUBLISH packet. The Broker MUST continue publishing the retained PUBLISH packet. The Broker MUST continue publishing the retained
messages as long as the associated tokens are valid. In the MQTT 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 standard, if QoS is 0 for the PUBLISH packet, the Broker may discard
the retained message any time. For QoS>1, the message expiry the retained message any time. For QoS > 1, the message expiry
interval dictates how long the retained message is kept. However, it interval dictates how long the retained message is kept. However, it
is important that the Broker avoids sending messages indefinitely for is important that the Broker avoids sending messages indefinitely for
the Clients that never update their tokens (i.e., the Client connects the Clients that never update their tokens (i.e., the Client connects
briefly with a valid token, sends a PUBLISH packet with RETAIN flag briefly with a valid token, sends a PUBLISH packet with the RETAIN
set to 1 and QoS>1, disconnects, and never connects again). flag set to 1 and QoS > 1, disconnects, and never connects again).
Therefore, the Broker MUST use the minimum of token expiry and Therefore, the Broker MUST use the minimum of the token expiry and
message expiry interval to discard a retained message. message expiry interval to discard a retained message.
In case of disconnections due to network errors or server In case of disconnections due to network errors or server
disconnection due to a protocol error (which includes authorization disconnection due to a protocol error (which includes authorization
errors), the Will message is sent if the Client supplied a Will in 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 the CONNECT packet. The Client's token scope array MUST include the
Will Topic. The Will message MUST be published to the Will Topic Will Topic. The Will Message MUST be published to the Will Topic,
regardless of whether the corresponding token has expired (as it has regardless of whether the corresponding token has expired (as it has
been validated and accepted during CONNECT). been validated and accepted during CONNECT).
6. Reduced Protocol Interactions for MQTT v3.1.1 6. Reduced Protocol Interactions for MQTT v3.1.1
This section describes a reduced set of protocol interactions for the This section describes a reduced set of protocol interactions for the
MQTT v3.1.1 Clients. An MQTT v5.0 Broker MAY implement these 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 interactions for the MQTT v3.1.1 Clients; the flows described in this
section are NOT RECOMMENDED for use by MQTT v5.0 Clients. Brokers section are NOT RECOMMENDED for use by MQTT v5.0 Clients. Brokers
that do not support MQTT v3.1.1 Clients return a CONNACK packet with that do not support MQTT v3.1.1 Clients return a CONNACK packet with
Reason Code 0x84 (Unsupported Protocol Version) in response to the reason code 0x84 (Unsupported Protocol Version) in response to the
connection requests. connection requests.
6.1. Token Transport 6.1. Token Transport
As in MQTT v5.0, the token MAY either be transported before, by As in MQTT v5.0, the token MAY either be transported before, by
publishing to the "authz-info" topic, or inside the CONNECT packet. publishing to the "authz-info" topic, or inside the CONNECT packet.
If the Client provided the token via the "authz-info" topic and will If the Client provided the token via the "authz-info" topic and will
not update the token in the CONNECT packet, it MUST authenticate over not update the token in the CONNECT packet, it MUST authenticate over
TLS. The Broker SHOULD still be prepared to store the Client access TLS. The Broker SHOULD still be prepared to store the Client access
token for future use (regardless of the method of transport). token for future use (regardless of the method of transport).
In MQTT v3.1.1, after the Client has published to the "authz-info" In MQTT v3.1.1, after the Client has published to the "authz-info"
topic, the Broker cannot communicate the result of the token topic, the Broker cannot communicate the result of the token
validation because PUBACK reason codes or server-side DISCONNECT validation because PUBACK reason codes or server-side DISCONNECT
packets are not supported. In any case, the subsequent TLS handshake packets are not supported. In any case, the subsequent TLS handshake
would fail without a valid token, which can prompt the Client to would fail without a valid token, which can prompt the Client to
obtain a valid token. obtain a valid token.
To transport the token to the Broker inside the CONNECT packet, the To transport the token to the Broker inside the CONNECT packet, the
Client uses the username and password fields. Figure 11 shows the Client uses the User Name and Password fields. Figure 10 shows the
structure of the MQTT CONNECT packet. structure of the MQTT CONNECT packet.
0 8 16 0 8 16
+---------------------------+ +---------------------------+
|Protocol name length = 4 | |Protocol name length = 4 |
+---------------------------+ +---------------------------+
| 'M' 'Q' | | 'M' 'Q' |
+---------------------------+ +---------------------------+
| 'T' 'T' | | 'T' 'T' |
+---------------------------+ +---------------------------+
|Proto.level=5|Connect flags| |Proto.level=5|Connect flags|
+---------------------------+ +---------------------------+
| Keep alive | | Keep alive |
+---------------------------+ +---------------------------+
| Payload | | Payload |
| Client Identifier | | Client Identifier |
| (UTF-8 encoded string) | | (UTF-8-encoded string) |
| Username as access token | | User Name as access token |
| (UTF-8 encoded string) | | (UTF-8-encoded string) |
| Password for signature/MAC| | Password for signature/MAC|
| (Binary Data) | | (Binary Data) |
+---------------------------+ +---------------------------+
Figure 11: MQTT CONNECT Variable Header Using Username and Figure 10: MQTT CONNECT Variable Header Using a User Name and
Password for ACE Password for ACE
Figure 12 shows how the MQTT connect flags MUST be set to initiate a Table 2 shows how the MQTT connect flags MUST be set to initiate a
connection with the Broker. connection with the Broker.
+-----------------------------------------------------------+ +================+==========+========+======+======+=======+=======+
|User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.| | User Name Flag | Password | Will | Will | Will | Clean | Rsvd. |
| flag |flag | | | | | | | | Flag | Retain | QoS | Flag | | |
+-----------------------------------------------------------+ +================+==========+========+======+======+=======+=======+
| 1 | 1 | X | X X | X | X | 0 | | 1 | 1 | X | X X | X | X | 0 |
+-----------------------------------------------------------+ +----------------+----------+--------+------+------+-------+-------+
Figure 12: MQTT CONNECT Flags (Rsvd=Reserved) Table 2: MQTT CONNECT Flags (Rsvd. = Reserved)
The Client SHOULD set the Clean flag to 1 to always start a new The Client SHOULD set the Clean flag to 1 to always start a new
session. If the Clean flag is set to 0, the Broker MUST resume Session. If the Clean flag is set to 0, the Broker MUST resume
communications with the Client based on the state from the current communications with the Client based on the state from the current
Session (as identified by the Client Identifier). If there is no Session (as identified by the Client Identifier). If there is no
Session associated with the Client Identifier, the Broker MUST create Session associated with the Client Identifier, the Broker MUST create
a new session. The Broker MUST set the Session Present flag in the a new Session. The Broker MUST set the Session Present flag in the
CONNACK packet accordingly, i.e., 0 to indicate a clean session to CONNACK packet accordingly, i.e., 0 to indicate a new Session to the
the Client and 1 to indicate session continuation. The Broker MUST Client and 1 to indicate that the existing Session is continued. The
still perform PoP validation on the provided Client token. MQTT Broker MUST still perform PoP validation on the provided Client
v3.1.1 does not use a Session Expiry Interval, and the Client expects token. MQTT v3.1.1 does not use a Session Expiry Interval, and the
that the Broker maintains the session state after it disconnects. Client expects that the Broker maintains the Session State after it
However, stored Session state can be discarded as a result of disconnects. However, the stored Session State can be discarded as a
administrator action or policies (e.g. defining an automated response result of administrator action or policies (e.g., defining an
based on storage capabilities), and Brokers SHOULD implement automated response based on storage capabilities), and Brokers SHOULD
administrative policies to limit misuse. implement administrative policies to limit misuse.
The Client MAY set the Will Flag as desired (marked as "X" in The Client MAY set the Will Flag as desired (marked as "X" in
Figure 12). Username and Password flags MUST be set to 1 to ensure Table 2). User Name and Password flags MUST be set to 1 to ensure
that the Payload of the CONNECT packet includes both Username and that the Payload of the CONNECT packet includes both the User Name
Password fields. The MQTT Username is a UTF-8 encoded string, and and Password fields. The MQTT User Name is a UTF-8-encoded string,
the MQTT Password is Binary Data. and the MQTT Password is Binary Data.
The CONNECT in MQTT v3.1.1 does not have a field to indicate the The CONNECT in MQTT v3.1.1 does not have a field to indicate the
authentication method. To signal that the Username field contains an Authentication Method. To signal that the User Name field contains
ACE token, this field MUST be prefixed with "ace" keyword, i.e., the an ACE token, this field MUST be prefixed with the keyword "ace",
Username field is a concatenation of 'a', 'c', 'e' and the access i.e., the User Name field is a concatenation of 'a', 'c', 'e', and
token represented as: the access token represented as:
'U+0061'||'U+0063'||'U+0065'||UTF-8(access token) 'U+0061'||'U+0063'||'U+0065'||UTF-8(access token)
Figure 13: Username in CONNECT Figure 11: User Name in CONNECT
To this end, the access token MUST be base64url encoded, omitting the To this end, the access token MUST be encoded with base64url,
'=' padding characters [RFC4648]. omitting the "=" padding characters [RFC4648].
The password field MUST be set to the keyed message digest (MAC) or The Password field MUST be set to the keyed message digest (MAC) or
signature associated with the access token for PoP. The Client MUST signature associated with the access token for PoP. The Client MUST
apply the PoP key on the challenge derived from the TLS session as apply the PoP key on the challenge derived from the TLS session, as
described in Section 2.2.4.2.1. described in Section 2.2.4.2.1.
6.2. Handling Authorization Errors 6.2. Handling Authorization Errors
Error handling is more primitive in MQTT v3.1.1 due to not having Error handling is more primitive in MQTT v3.1.1 due to not having
appropriate error fields, error codes, and server-side DISCONNECTs. appropriate error fields, error codes, and server-side DISCONNECTs.
Therefore, the Broker will disconnect on almost any error and may not Therefore, the Broker will disconnect on almost any error and may not
keep the session state, necessitating that clients make a greater keep the Session State, necessitating that clients make a greater
effort to ensure that tokens remain valid and do not attempt to effort to ensure that tokens remain valid and do not attempt to
publish to topics that they do not have permissions for. The publish to topics that they do not have permissions for. The
following lists how the Broker responds to specific errors. following lists how the Broker responds to specific errors.
* CONNECT without a token: The tokenless CONNECT attempt MUST fail. CONNECT without a token:
This is because the challenge-response based PoP is not possible The tokenless CONNECT attempt MUST fail. This is because the
for MQTT v3.1.1. It is also not possible to support AS discovery challenge-response-based PoP is not possible for MQTT v3.1.1.
since a CONNACK packet in MQTT v3.1.1 does not include a means to It is also not possible to support AS discovery since a
provide additional information to the Client. Therefore, AS CONNACK packet in MQTT v3.1.1 does not include a means to
discovery needs to take place out-of-band. provide additional information to the Client. Therefore, AS
discovery needs to take place out of band.
* Client-Broker PUBLISH authorization failure: In the case of a Client-Broker PUBLISH authorization failure:
failure, it is not possible to return an error in MQTT v3.1.1. In the case of a failure, it is not possible to return an
Acknowledgment messages only indicate success. In the case of an error in MQTT v3.1.1. Acknowledgment messages only indicate
authorization error, the Broker MUST ignore the PUBLISH packet and success. In the case of an authorization error, the Broker
disconnect the Client. Also, as DISCONNECT packets are only sent MUST ignore the PUBLISH packet and disconnect the Client.
from a Client to the Broker, the server disconnection needs to Also, as DISCONNECT packets are only sent from a Client to
take place below the application layer. the Broker, the server disconnection needs to take place
below the application layer.
* SUBSCRIBE authorization failure: In the SUBACK packet, the return SUBSCRIBE authorization failure:
code is 0x80 indicating failure for the unauthorized topic(s). In the SUBACK packet, the return code is 0x80, indicating
Note that, in both MQTT versions, a reason code is returned for failure for the unauthorized topic(s). Note that, in both
each Topic Filter. MQTT versions, a reason code is returned for each Topic
Filter.
* Broker-Client PUBLISH authorization failure: When the Broker is Broker-Client PUBLISH authorization failure:
forwarding PUBLISH packets to the subscribed Clients, it may When the Broker is forwarding PUBLISH packets to the
discover that some of the subscribers are no longer authorized due subscribed Clients, it may discover that some of the
to expired tokens. These token expirations MUST lead to subscribers are no longer authorized due to expired tokens.
disconnecting the Client rather than silently dropping messages. These token expirations MUST lead to disconnecting the Client
rather than silently dropping messages.
7. IANA Considerations 7. IANA Considerations
Note to RFC Editor: Please replace all occurrences of "[this 7.1. TLS Exporter Labels Registration
document]" with the RFC number of this specification and delete this
paragraph.
7.1. TLS Exporter Label Registration
This document registers "EXPORTER-ACE-MQTT-Sign-Challenge" This document registers "EXPORTER-ACE-MQTT-Sign-Challenge"
(introduced in Section 2.2.4.2.1 in this document) in the TLS (introduced in Section 2.2.4.2.1 in this document) in the "TLS
Exporter Label Registry [RFC8447]. Exporter Labels" registry [RFC8447].
* Recommended: No Recommended: N
* DTLS-OK: No DTLS-OK: N
* Reference: [This document] Reference: RFC 9431
7.2. Media Type Registration 7.2. Media Type Registration
This document registers the "application/ace+json" media type for This document registers the "application/ace+json" media type for
messages of the protocols defined in this document carrying messages of the protocols defined in this document carrying
parameters encoded in JSON. parameters encoded in JSON.
* Type name: application Type name: application
* Subtype name: ace+json Subtype name: ace+json
* Required parameters: N/A Required parameters: N/A
* Optional 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 [this document] Encoding considerations: Encoding considerations are identical to
those specified for the "application/json" media type.
* Interoperability considerations: none Security considerations: Section 8 of RFC 9431
* Published specification: [this document] Interoperability considerations: none
* Applications that use this media type: This media type is intended Published specification: RFC 9431
for authorization server-client and authorization server-resource
server communication as part of the ACE framework using JSON
encoding as specified in [this document].
* Fragment identifier considerations: none 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.
* Additional information: Fragment identifier considerations: none
- Deprecated alias names for this type: none Additional information:
- Magic number(s): none Deprecated alias names for this type: none
- File extension(s): none Magic number(s): none
- Macintosh file type code(s): none File extension(s): none
* Person & email address to contact for further information: Cigdem Macintosh file type code(s): none
Sengul (csengul@acm.org)
* Intended usage: COMMON Person & email address to contact for further information:
Cigdem Sengul <csengul@acm.org>
* Restrictions on usage: none Intended usage: COMMON
* Author: Cigdem Sengul (csengul@acm.org) Restrictions on usage: none
* Change controller: IETF Author: Cigdem Sengul <csengul@acm.org>
* Provisional registration? (standards tree only): no Change controller: IETF
7.3. ACE OAuth Profile Registration 7.3. ACE OAuth Profile Registration
The following registrations are done for the ACE OAuth Profile The following registrations have been made in the "ACE Profiles"
Registry following the procedure specified in registry, following the procedure specified in [RFC9200].
[I-D.ietf-ace-oauth-authz].
* Name: mqtt_tls Name: mqtt_tls
* Description: Profile for delegating Client authentication and
Description: Profile for delegating Client authentication and
authorization using MQTT for the Client and Broker (RS) authorization using MQTT for the Client and Broker (RS)
interactions, and HTTP for the AS interactions. TLS is used for interactions and HTTP for the AS interactions. TLS is used for
confidentiality and integrity protection and server confidentiality and integrity protection and server
authentication. Client authentication can be provided either via authentication. Client authentication can be provided either via
TLS or using in-band PoP validation at the MQTT application layer. TLS or using in-band PoP validation at the MQTT application layer.
* CBOR Value: To be assigned by IANA in the (-256, 255) range CBOR Value: 3
* Reference: [this document] Reference: RFC 9431
7.4. AIF 7.4. AIF
For the media-types application/aif+cbor and application/aif+json For the media types "application/aif+cbor" and "application/
defined in Section 5.1 of [I-D.ietf-ace-aif], IANA is requested to aif+json", defined in Section 5.1 of [RFC9237], IANA has registered
register the following entries for the two media-type parameters Toid the following entries for the two media type parameters Toid and
and Tperm, in the respective sub-registry defined in Section 5.2 of Tperm in the respective subregistry defined in Section 5.2 of
[I-D.ietf-ace-aif] within the "MIME Media Type Sub-Parameter" [RFC9237] within the "Media Type Sub-Parameter Registries".
registry group.
For Toid: For Toid:
Name: mqtt-topic-filter
* Name: mqtt-topic-filter Description/Specification: Topic Filter, as defined in
Section 2.3 of RFC 9431.
* Description/Specification: Topic Filter as defined in Section 2.3.
* Reference: [[This document]] (Section 2.3) Reference: RFC 9431, Section 2.3
For Tperm: For Tperm:
Name: mqtt-permissions
* 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
* Description/Specification: Permissions for MQTT client as defined or more text strings that each have a value of either "pub" or
in Section 2.3. Tperm is an array of one or more text strings "sub".
that each have a value of either "pub" or "sub".
* Reference: [[This document]] (Section 2.3) Reference: RFC 9431, Section 2.3
8. Security Considerations 8. Security Considerations
This document specifies a profile for the Authentication and This document specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework Authorization for Constrained Environments (ACE) framework [RFC9200].
[I-D.ietf-ace-oauth-authz]. Therefore, the security considerations Therefore, the security considerations outlined in [RFC9200] apply to
outlined in [I-D.ietf-ace-oauth-authz] apply to this work. this work.
In addition, the security considerations outlined in MQTT v5.0 - the In addition, the security considerations outlined in the MQTT v5.0
OASIS Standard [MQTT-OASIS-Standard-v5] and MQTT v3.1.1 - the OASIS OASIS Standard [MQTT-OASIS-Standard-v5] and MQTT v3.1.1 OASIS
Standard [MQTT-OASIS-Standard-v3.1.1] apply. Mainly, this document Standard [MQTT-OASIS-Standard-v3.1.1] apply. Mainly, this document
provides an authorization solution for MQTT, the responsibility of provides an authorization solution for MQTT, the responsibility of
which is left to the specific implementation in the MQTT standards. which is left to the specific implementation in the MQTT standards.
In the following, we comment on a few relevant issues based on the In the following, we comment on a few relevant issues based on the
current MQTT specifications. current MQTT specifications.
After the Broker validates an access token and accepts a connection After the Broker validates an access token and accepts a connection
from a client, it caches the token to authorize a Client's publish from a client, it caches the token to authorize a Client's publish
and subscribe requests in an ongoing session. The Broker does not and subscribe requests in an ongoing Session. The Broker does not
cache any tokens that cannot be validated. If a Client's permissions cache any tokens that cannot be validated. If a Client's permissions
get revoked, but the access token has not expired, the Broker may get revoked, but the access token has not expired, the Broker may
still grant publish/subscribe to revoked topics. If the Broker still grant publish/subscribe to revoked topics. If the Broker
caches the token introspection responses, then the Broker SHOULD use caches the token introspection responses, then the Broker SHOULD use
a reasonable cache timeout to introspect tokens regularly. The a reasonable cache timeout to introspect tokens regularly. The
timeout value is application-specific and should be chosen to reduce timeout value is application specific and should be chosen to reduce
the risk of using stale introspection responses. When permissions the risk of using stale introspection responses. When permissions
change dynamically, it is expected that AS also follows a reasonable change dynamically, it is expected that the AS also follows a
expiration strategy for the access tokens. reasonable expiration strategy for the access tokens.
The Broker may monitor Client behaviour to detect potential security The Broker may monitor Client behavior to detect potential security
problems, especially those affecting availability. These include problems, especially those affecting availability. These include
repeated token transfer attempts to the public "authz-info" topic, repeated token transfer attempts to the public "authz-info" topic,
repeated connection attempts, abnormal terminations, and Clients that repeated connection attempts, abnormal terminations, and Clients that
connect but do not send any data. If the Broker supports the public connect but do not send any data. If the Broker supports the public
"authz-info" topic, described in Section 2.2.2, then this may be "authz-info" topic, described in Section 2.2.2, then this may be
vulnerable to a DDoS attack, where many Clients use the "authz-info" vulnerable to a DDoS attack, where many Clients use the "authz-info"
public topic to transport tokens that are not meant to be used, and public topic to transport tokens that are not meant to be used and
which the Broker may need to store until the tokens expire. that the Broker may need to store until they expire.
For MQTT v5.0, when a Client connects with a long Session Expiry For MQTT v5.0, when a Client connects with a long Session Expiry
Interval, the Broker may need to maintain the Client's MQTT session Interval, the Broker may need to maintain the Client's MQTT Session
state after it disconnects for an extended period. For MQTT v3.1.1, State after it disconnects for an extended period. For MQTT v3.1.1,
the session state may need to be stored indefinitely, as it does not the Session State may need to be stored indefinitely, as it does not
have a Session Expiry Interval feature. The Broker SHOULD implement have a Session Expiry Interval feature. The Broker SHOULD implement
administrative policies to limit misuse of the session continuation administrative policies to limit misuse by the Client resulting from
by the Client. continuing existing Sessions.
9. Privacy Considerations 9. Privacy Considerations
The privacy considerations outlined in [I-D.ietf-ace-oauth-authz] The privacy considerations outlined in [RFC9200] apply to this work.
apply to this work.
In MQTT, the Broker is a central trusted party and may forward In MQTT, the Broker is a central trusted party and may forward
potentially sensitive information between Clients. The mechanisms potentially sensitive information between Clients. The mechanisms
defined in this document do not protect the contents of the PUBLISH defined in this document do not protect the contents of the PUBLISH
packet from the Broker, and hence, the content of the PUBLISH packet packet from the Broker, and hence, the content of the PUBLISH packet
is not signed or encrypted separately for the subscribers. This is not signed or encrypted separately for the subscribers. This
functionality may be implemented using the proposal outlined in the functionality may be implemented using the proposal outlined in the
ACE Pub-Sub Profile [I-D.ietf-ace-pubsub-profile]. However, this ACE Pub-Sub Profile [ACE-PUBSUB-PROFILE]. However, this solution
solution would still not provide privacy for other fields of the would still not provide privacy for other fields of the packet, such
packet, such as Topic Name. as Topic Name.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-ace-aif]
Bormann, C., "An Authorization Information Format (AIF)
for ACE", Work in Progress, Internet-Draft, draft-ietf-
ace-aif-07, 15 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-ace-aif-
07.txt>.
[I-D.ietf-ace-dtls-authorize]
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)", Work in Progress,
Internet-Draft, draft-ietf-ace-dtls-authorize-18, 4 June
2021, <https://www.ietf.org/archive/id/draft-ietf-ace-
dtls-authorize-18.txt>.
[I-D.ietf-ace-extend-dtls-authorize]
Bergmann, O., Mattsson, J. P., and G. Selander, "Extension
of the CoAP-DTLS Profile for ACE to TLS", Work in
Progress, Internet-Draft, draft-ietf-ace-extend-dtls-
authorize-02, 7 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-ace-extend-
dtls-authorize-02.txt>.
[I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", Work in Progress, Internet-Draft,
draft-ietf-ace-oauth-authz-46, 8 November 2021,
<https://www.ietf.org/archive/id/draft-ietf-ace-oauth-
authz-46.txt>.
[I-D.ietf-ace-oauth-params]
Seitz, L., "Additional OAuth Parameters for Authorization
in Constrained Environments (ACE)", Work in Progress,
Internet-Draft, draft-ietf-ace-oauth-params-16, 7
September 2021, <https://www.ietf.org/archive/id/draft-
ietf-ace-oauth-params-16.txt>.
[I-D.ietf-cose-x509]
Schaad, J., "CBOR Object Signing and Encryption (COSE):
Header parameters for carrying and referencing X.509
certificates", Work in Progress, Internet-Draft, draft-
ietf-cose-x509-08, 14 December 2020,
<https://www.ietf.org/internet-drafts/draft-ietf-cose-
x509-08.txt>.
[I-D.ietf-httpbis-semantics]
Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
Semantics", Work in Progress, Internet-Draft, draft-ietf-
httpbis-semantics-19, 12 September 2021,
<https://www.ietf.org/archive/id/draft-ietf-httpbis-
semantics-19.txt>.
[MQTT-OASIS-Standard-v3.1.1] [MQTT-OASIS-Standard-v3.1.1]
Banks, A., Ed. and R. Gupta, Ed., "OASIS Standard MQTT Banks, A., Ed. and R. Gupta, Ed., "MQTT Version 3.1.1 Plus
Version 3.1.1 Plus Errata 01", 2015, <https://docs.oasis- Errata 01", OASIS Standard, December 2015,
open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html>. <https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-
v3.1.1.html>.
[MQTT-OASIS-Standard-v5] [MQTT-OASIS-Standard-v5]
Banks, A., Ed., Briggs, E., Ed., Borgendale, K., Ed., and Banks, A., Ed., Briggs, E., Ed., Borgendale, K., Ed., and
R. Gupta, Ed., "OASIS Standard MQTT Version 5.0", 2017, R. Gupta, Ed., "MQTT Version 5.0", OASIS Standard, March
<https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt- 2019, <https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-
v5.0-os.html>. v5.0.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
skipping to change at page 38, line 10 skipping to change at line 1620
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)", Possession Key Semantics for JSON Web Tokens (JWTs)",
RFC 7800, DOI 10.17487/RFC7800, April 2016, RFC 7800, DOI 10.17487/RFC7800, April 2016,
<https://www.rfc-editor.org/info/rfc7800>. <https://www.rfc-editor.org/info/rfc7800>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
Curve Cryptography (ECC) Cipher Suites for Transport Layer Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS) Versions 1.2 and Earlier", RFC 8422, Security (TLS) Versions 1.2 and Earlier", RFC 8422,
DOI 10.17487/RFC8422, August 2018, DOI 10.17487/RFC8422, August 2018,
<https://www.rfc-editor.org/info/rfc8422>. <https://www.rfc-editor.org/info/rfc8422>.
skipping to change at page 38, line 44 skipping to change at line 1650
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/info/rfc8747>. 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 10.2. Informative References
[fremantle14] [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, Fremantle, P., Aziz, B., Kopecky, J., and P. Scott,
"Federated Identity and Access Management for the Internet "Federated Identity and Access Management for the Internet
of Things", research International Workshop on Secure of Things", International Workshop on Secure Internet of
Internet of Things, September 2014, Things, DOI 10.1109/SIoT.2014.8, September 2014,
<https://dx.doi.org/10.1109/SIoT.2014.8>. <https://dx.doi.org/10.1109/SIoT.2014.8>.
[I-D.ietf-ace-pubsub-profile]
Palombini, F. and C. Sengul, "Pub-Sub Profile for
Authentication and Authorization for Constrained
Environments (ACE)", Work in Progress, Internet-Draft,
draft-ietf-ace-pubsub-profile-04, 29 December 2021,
<https://www.ietf.org/archive/id/draft-ietf-ace-pubsub-
profile-04.txt>.
[I-D.ietf-tls-rfc8446bis]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", Work in Progress, Internet-Draft, draft-
ietf-tls-rfc8446bis-04, 7 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-tls-
rfc8446bis-04.txt>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
Security (TLS) / Datagram Transport Layer Security (DTLS) Security (TLS) / Datagram Transport Layer Security (DTLS)
Profiles for the Internet of Things", RFC 7925, Profiles for the Internet of Things", RFC 7925,
DOI 10.17487/RFC7925, July 2016, DOI 10.17487/RFC7925, July 2016,
<https://www.rfc-editor.org/info/rfc7925>. <https://www.rfc-editor.org/info/rfc7925>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>. May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/info/rfc8447>. <https://www.rfc-editor.org/info/rfc8447>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
Appendix A. Checklist for profile requirements [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
Based on the requirements on profiles for the ACE framework Based on the requirements on profiles for the ACE framework
[I-D.ietf-ace-oauth-authz], this document fulfills the following: [RFC9200], this document fulfills the following:
* Optional AS discovery: AS discovery is supported with the MQTT * Optional AS discovery: AS discovery is supported with the MQTT
v5.0 described in Section 2.2. v5.0 described in Section 2.2.
* The communication protocol between the Client and Broker (RS): * The communication protocol between the Client and Broker (RS):
MQTT MQTT
* The security protocol between the Client and RS: TLS * The security protocol between the Client and RS: TLS
* Client and RS mutual authentication: Several options are possible * Client and RS mutual authentication: Several options are possible
and described in Section 2.2.1. and described in Section 2.2.1.
* Proof-of-possession protocols: Specified in Section 2.2.4.2; both * Proof-of-possession protocols: Both symmetric and asymmetric keys
symmetric and asymmetric keys supported. are supported, as specified in Section 2.2.4.2.
* Content format: For the HTTPS interactions with AS, "application/ * Content-Format: For the HTTPS interactions with AS, "application/
ace+json". ace+json".
* Unique profile identifier: mqtt_tls * Unique profile identifier: mqtt_tls
* Token introspection: RS uses HTTPS introspect interface of AS. * Token introspection: The RS uses the HTTPS introspection interface
of the AS.
* Token request: Client or its Client AS uses the HTTPS token * Token request: The Client or its Client AS uses the HTTPS token
endpoint of the AS. endpoint of the AS.
* authz-info endpoint: It MAY be supported using the method * authz-info endpoint: It MAY be supported using the method
described in Section 2.2.2, but is not protected other than by the described in Section 2.2.2 but is not protected other than by the
TLS channel between Client and RS. TLS channel between the Client and RS.
* Token transport: Via "authz-info" topic, or TLS with PSK, provided
as a PSK identity, or in MQTT CONNECT packet for both versions of
MQTT. The AUTH extensions can also be used for authentication and
re-authentication for MQTT v5.0, as described in Section 2.2 and
Section 4.
Appendix B. Document Updates
Version 15: Addressing GENART review comments.
Version 11 to 15: Addressing AD review comments.
Version 10 to 11: Clarified the TLS use between RS-AS and Client-AS.
Version 09 to 10: Fixed version issues for references.
Version 08 to 09: Fixed spacing issues and references.
Version 07 to 08:
* Fixed several nits, typos based on WG reviews.
* Added missing references.
* Added the definition for Property defined by MQTT, and Client
Authorization Server.
* Added artwork to show Authorization Data format for various PoP-
related message exchange.
* Removed all MQTT-related must/should/may.
* Made AS discovery optional.
* Clarified what the client and server must implement for client
authentication; cleaned up TLS 1.3 related language.
Version 06 to 07:
* Corrected the title.
* In Section 2.2.3, added the constraint on which packets the Client
can send, and the server can process after CONNECT before CONNACK.
* In Section 2.2.3, clarified that session state is identified by
Client Identifier, and listed its content.
* In Section 2.2.3, clarified the issue of Client Identifier
collision, when the Broker supports session continuation.
* Corrected the buggy scope example in Section 3.1.
Version 05 to 06:
* Replace the originally proposed scope format with AIF model.
Defined the AIF-MQTT, gave an example with a JSON array. Added a
normative reference to the AIF draft.
* Clarified client connection after submitting token via "authz-
info" topic as TLS:Known(RPK/PSK),MQTT:none.
* Expanded acronyms on their first use including the ones in the
title.
* Added a definition for "Session".
* Corrected "CONNACK" definition, which earlier said it's the first
packet sent by the Broker.
* Added a statement that the Broker will disconnect on almost any
error and may not keep session state.
* Clarified that the Broker does not cache tokens that cannot be
validated.
Version 04 to 05:
* Reorganised Section 2 such that "Unauthorized Request:
Authorization Server Discovery" is presented under Section 2.
* Fixed Figure 2 to remove the "empty" word.
* Clarified that MQTT v5.0 Brokers may implement username/password
option for transporting the ACE token only for MQTT v.3.1.1
clients. This option is not recommended for MQTT v.5.0 clients.
* Changed Clean Session requirement both for MQTT v.5.0 and v.3.1.1.
The Broker SHOULD NOT, instead of MUST NOT, continue sessions.
Clarified expected behaviour if session continuation is supported.
Added to the Security Considerations the potential misuse of
session continuation.
* Fixed the Authentication Data to include token length for the
Challenge/Response PoP.
* Added that Authorization Server Discovery is triggered if a token
is not valid and not only missing.
* Clarified that the Broker should not accept any other packets from
Client after CONNECT and before sending CONNACK.
* Added that client reauthentication is accepted only for the
challenge/response PoP.
* Added Ed25519 as mandatory to implement.
* Fixed typos.
Version 03 to 04:
* Linked the terms Broker and MQTT server more at the introduction
of the document.
* Clarified support for MQTTv3.1.1 and removed phrases that might be
considered as MQTTv5 is backwards compatible with MQTTv3.1.1
* Corrected the Informative and Normative references.
* For AS discovery, clarified the CONNECT message omits the
Authentication Data field. Specified the User Property MUST be
set to "ace_as_hint" for AS Request Creation Hints.
* Added that MQTT v5 brokers MAY also implement reduced interactions
described for MQTTv3.1.1.
* Added to Section 3.1, in case of an authorization failure and QoS
level 0, the RS sends a DISCONNECT with reason code 0x87 (Not
authorized).
* Added a pointer to section 4.7 of MQTTv5 spec for more information
on topic names and filters.
* Added HS256 and RSA256 are mandatory to implement depending on the
choice of symmetric or asymmetric validation.
* Added MQTT to the TLS exporter label to make it application
specific: 'EXPORTER-ACE-MQTT-Sign-Challenge'.
* Added a format for Authentication Data so that length values
prefix the token (or client nonce) when Authentication Data
contains more than one piece of information.
* Clarified clients still connect over TLS (server-side) for the
authz-info flow.
Version 02 to 03:
* Added the option of Broker certificate thumbprint in the 'rs_cnf'
sent to the Client.
* Clarified the use of a random nonce from the TLS Exporter for PoP,
added to the IANA requirements that the label should be
registered.
* Added a client nonce, when Challenge/Response Authentication is
used between Client and Broker.
* Clarified the use of the "authz-info" topic and the error response
if token validation fails.
* Added clarification on wildcard use in scopes for publish/
subscribe permissions
* Reorganised sections so that token authorization for publish/
subscribe messages are better placed.
Version 01 to 02:
* Clarified protection of Application Message payload as out of
scope, and cited draft-palombini-ace-coap-pubsub-profile for a
potential solution
* Expanded Client connection authorization to capture different
options for Client and Broker authentication over TLS and MQTT
* Removed Payload (and specifically Client Identifier) from proof-
of-possession in favor of using tls-exporter for a TLS-session
based challenge.
* Moved token transport via "authz-info" topic from the Appendix to
the main text.
* Clarified Will scope.
* Added MQTT AUTH to terminology.
* Typo fixes, and simplification of figures.
Version 00 to 01:
* Present the MQTTv5 as the RECOMMENDED version, and MQTT v3.1.1 for
backward compatibility.
* Clarified Will message.
* Improved consistency in the use of terminology and upper/lower
case.
* Defined Broker and MQTTS.
* Clarified HTTPS use for C-AS and RS-AS communication. Removed
reference to actors document, and clarified the use of client
authorization server.
* Clarified the Connect message payload and Client Identifier.
* Presented different methods for passing the token and PoP.
* Added new figures to explain AUTH packets exchange, updated * Token transport: Via the "authz-info" topic, TLS with PSKs
CONNECT message figure. (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 Acknowledgments
The authors would like to thank Ludwig Seitz for his review and his The authors would like to thank Ludwig Seitz for his review and his
input on the authorization information endpoint; Benjamin Kaduk for input on the authorization information endpoint; Benjamin Kaduk for
his review, insightful comments, and contributions to resolving his review, insightful comments, and contributions to resolving
issues; and Carsten Bormann for his review and revisions to the AIF- issues; and Carsten Bormann for his review and revisions to the AIF-
MQTT data model. The authors would like to thank Paul Fremantle for MQTT data model. The authors would like to thank Paul Fremantle for
the initial discussions on MQTT v5.0 support. the initial discussions on MQTT v5.0 support.
skipping to change at page 45, line 29 skipping to change at line 1813
Cigdem Sengul Cigdem Sengul
Brunel University Brunel University
Dept. of Computer Science Dept. of Computer Science
Uxbridge Uxbridge
UB8 3PH UB8 3PH
United Kingdom United Kingdom
Email: csengul@acm.org Email: csengul@acm.org
Anthony Kirby Anthony Kirby
Oxbotica Oxbotica
1a Milford House, Mayfield Road, Summertown 1a Milford House
Mayfield Road, Summertown
Oxford Oxford
OX2 7EL OX2 7EL
United Kingdom United Kingdom
Email: anthony@anthony.org Email: anthony@anthony.org
 End of changes. 259 change blocks. 
1085 lines changed or deleted 858 lines changed or added

This html diff was produced by rfcdiff 1.48.