rfc9431xml2.original.xml   rfc9431.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc, <!DOCTYPE rfc [
which is available here: http://xml.resource.org. --> <!ENTITY nbsp "&#160;">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY zwsp "&#8203;">
<!-- One method to get references from the online citation libraries. <!ENTITY nbhy "&#8209;">
There has to be one entity for each item to be referenced. <!ENTITY wj "&#8288;">
An alternate method (rfc include) is described in the references. -- ]>
>
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
nce.RFC.8174.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.2629.xml">
<!ENTITY RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.4648.xml">
<!ENTITY RFC4949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.4949.xml">
<!ENTITY RFC6066 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.6066.xml">
<!ENTITY RFC6234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.6234.xml">
<!ENTITY RFC6749 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.6749.xml">
<!ENTITY RFC7800 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.7800.xml">
<!ENTITY RFC8949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.8949.xml">
<!ENTITY RFC7250 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.7250.xml">
<!ENTITY RFC7252 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.7252.xml">
<!ENTITY RFC7301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.7301.xml">
<!ENTITY RFC7516 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.7516.xml">
<!ENTITY RFC7517 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.7517.xml">
<!ENTITY RFC7519 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.7519.xml">
<!ENTITY RFC7525 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.7525.xml">
<!ENTITY RFC7627 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.7627.xml">
<!ENTITY RFC8422 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.8422.xml">
<!ENTITY RFC8442 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.8442.xml">
<!ENTITY RFC7925 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.7925.xml">
<!ENTITY RFC8446 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.8446.xml">
<!ENTITY RFC5705 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.5705.xml">
<!ENTITY RFC8032 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.8032.xml">
<!ENTITY RFC8152 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.8152.xml">
<!ENTITY RFC8392 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.8392.xml">
<!ENTITY RFC8447 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.8447.xml">
<!ENTITY RFC8610 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.8610.xml">
<!ENTITY RFC8747 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.8747.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-ace-mqtt-tls-profile-17" ipr="trust20090
2">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200
902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only neces
sary if the
full title is longer than 39 characters -->
<title abbrev="MQTT-TLS profile of ACE">Message Queuing Telemetry Transp
ort (MQTT)-TLS profile of Authentication and Authorization for Constrained Envir
onments (ACE) Framework</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Author 1-->
<author fullname="Cigdem Sengul" initials="C.S."
surname="Sengul">
<organization>Brunel University</organization>
<address>
<postal>
<!-- Reorder these if your country does things differently -
->
<street>Dept. of Computer Science</street>
<city>Uxbridge</city>
<code>UB8 3PH</code>
<country>UK</country>
</postal>
<email>csengul@acm.org</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<!-- Author 2-->
<author fullname="Anthony Kirby" initials="A.K"
surname="Kirby">
<organization>Oxbotica</organization>
<address>
<postal>
<street>1a Milford House, Mayfield Road, Summertown</street>
<!-- Reorder these if your country does things differently -
->
<city>Oxford</city>
<code>OX2 7EL</code>
<country>UK</country>
</postal>
<email>anthony@anthony.org</email>
</address>
</author>
<date year="2022"/> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<!-- If the month and year are both specified and are the current ones, std" consensus="true" docName="draft-ietf-ace-mqtt-tls-profile-17" number="9431"
xml2rfc will fill ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDe
in the current day for you. If only the current year is specified, pth="4" symRefs="true" sortRefs="true" version="3">
xml2rfc will fill
in the current day and month for you. If the year is not the current o
ne, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not
specified for the
purpose of calculating the expiry date). With drafts it is normally s
ufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Security</area>
<workgroup>ACE Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc, <!-- xml2rfc v2v3 conversion 3.12.2 -->
IETF is fine for individual submissions. <front>
If this element is not present, the default is "Network Working Group" <title abbrev="MQTT-TLS Profile of ACE">Message Queuing Telemetry Transp
, ort (MQTT) and Transport Layer Security (TLS) Profile of Authentication
which is used by the RFC Editor as a nod to the history of the IETF and Authorization for Constrained Environments (ACE) Framework</title>
. --> <seriesInfo name="RFC" value="9431"/>
<keyword>Internet-Draft</keyword> <author fullname="Cigdem Sengul" initials="C." surname="Sengul">
<!-- Keywords will be incorporated into HTML output <organization>Brunel University</organization>
files in a meta tag but they have no effect on text or nroff <address>
output. If you submit your draft to the RFC Editor, the <postal>
keywords will be used for the search engine. --> <street>Dept. of Computer Science</street>
<city>Uxbridge</city>
<code>UB8 3PH</code>
<country>United Kingdom</country>
</postal>
<email>csengul@acm.org</email>
</address>
</author>
<author fullname="Anthony Kirby" initials="A." surname="Kirby">
<organization>Oxbotica</organization>
<address>
<postal>
<extaddr>1a Milford House</extaddr>
<street>Mayfield Road, Summertown</street>
<city>Oxford</city>
<code>OX2 7EL</code>
<country>United Kingdom</country>
</postal>
<email>anthony@anthony.org</email>
</address>
</author>
<date month="July" year="2023"/>
<area>sec</area>
<workgroup>ace</workgroup>
<keyword>publish-subscribe</keyword>
<keyword>authorization information format</keyword>
<abstract> <abstract>
<t> <t>
This document specifies a profile for the ACE (Authentication an This document specifies a profile for the Authentication and Aut
d Authorization for Constrained horization for Constrained
Environments) framework to enable authorization in a Message Que Environments (ACE) framework to enable authorization in a publis
uing Telemetry Transport h-subscribe messaging system based on Message Queuing Telemetry Transport
(MQTT)-based publish-subscribe messaging system. (MQTT).
Proof-of-possession keys, bound to OAuth2.0 access tokens, are u Proof-of-Possession keys, bound to OAuth 2.0 access tokens, are
sed to authenticate and authorize used to authenticate and authorize
MQTT Clients. The protocol relies on TLS for confidentiality and MQTT server (Broker) authentication. MQTT Clients. The protocol relies on TLS for confidentiality and MQTT server (Broker) authentication.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section numbered="true" toc="default">
<section title="Introduction"> <name>Introduction</name>
<t> <t>
This document specifies a profile for the ACE framework <xref ta This document specifies a profile for the ACE framework <xref ta
rget="I-D.ietf-ace-oauth-authz"></xref>. rget="RFC9200" format="default"/>.
In this profile, Clients and Servers (Brokers) use MQTT to excha nge Application Messages. In this profile, Clients and Servers (Brokers) use MQTT to excha nge Application Messages.
The protocol relies on TLS for communication security between en tities. The MQTT protocol interactions The protocol relies on TLS for communication security between en tities. The MQTT protocol interactions
are described based on the <xref target="MQTT-OASIS-Standard-v5" >MQTT v5.0 - the OASIS Standard</xref>. are described based on the <xref target="MQTT-OASIS-Standard-v5" format="default">MQTT v5.0 OASIS Standard</xref>.
Since it is expected that MQTT deployments will continue to supp ort MQTT v3.1.1 Clients, Since it is expected that MQTT deployments will continue to supp ort MQTT v3.1.1 Clients,
this document also describes a reduced set of protocol in this document also describes a reduced set of protocol in
teractions for teractions for the
<xref target="MQTT-OASIS-Standard-v3.1.1">MQTT v3.1.1 - the OASI <xref target="MQTT-OASIS-Standard-v3.1.1" format="default">MQTT
S Standard</xref>. v3.1.1 OASIS Standard</xref>.
However, MQTT v5.0 is the RECOMMENDED version as it works However, MQTT v5.0 is the <bcp14>RECOMMENDED</bcp14> vers
more naturally ion, as it works more naturally
with ACE-style authentication and authorization. with ACE-style authentication and authorization.
</t> </t>
<t> <t>
MQTT is a publish-subscribe protocol, and MQTT is a publish-subscribe protocol, and
after connecting to the MQTT Server (Broker), a Client can publi sh and subscribe to multiple topics. after connecting to the MQTT Server (Broker), a Client can publi sh and subscribe to multiple topics.
The Broker, which acts as the Resource Server (RS), is responsib le for distributing messages published The Broker, which acts as the Resource Server (RS), is responsib le for distributing messages published
by the publishers to their subscribers. In the rest of the by the publishers to their subscribers. In the rest of the
document, the terms "RS", "MQTT Server" and "Broker" are used in document, the terms "RS", "MQTT Server", and "Broker" are used i
terchangeably. nterchangeably.
</t> </t>
<t>
<t>
Messages are published under a Topic Name, Messages are published under a Topic Name,
and subscribers subscribe to the Topic Names to receive the corr esponding messages. and subscribers subscribe to the Topic Names to receive the corr esponding messages.
The Broker uses the Topic Name in a published message to determi ne which The Broker uses the Topic Name in a published message to determi ne which
subscribers to relay the messages to. subscribers to relay the messages to.
In this document, topics, more specifically, Topic Names, are tr In this document, topics (more specifically, Topic Names) are tr
eated as resources. eated as resources.
The Clients are assumed to have identified the publish/subscribe The Clients are assumed to have identified the publish/subscribe
topics of interest out-of-band topics of interest out of band
(topic discovery is not a feature of the MQTT protocol). (topic discovery is not a feature of the MQTT protocol).
A Resource Owner can pre-configure policies at the Authorization Server (AS) A Resource Owner can preconfigure policies at the Authorization Server (AS)
that give Clients publish or subscribe permissions to different topics. that give Clients publish or subscribe permissions to different topics.
</t> </t>
<t> <t>
Clients prove their permission to publish and subscribe to topic s hosted on an MQTT Broker Clients prove their permission to publish and subscribe to topic s hosted on an MQTT Broker
using an access token, bound to a proof-of-possession (PoP) key. using an access token that is bound to a Proof-of-Possession (Po P) key.
This document describes how to authorize the following exchanges between the This document describes how to authorize the following exchanges between the
Clients and the Broker. Clients and the Broker.
<list style="symbols"> </t>
<t>Connection requests from the Clients to the Broker</t> <ul spacing="normal">
<t>Publish requests from the Clients to the Broker and from <li>connection requests from the Clients to the Broker</li>
the Broker to the Clients</t> <li>publish requests from the Clients to the Broker and from the Broker
<t>Subscribe requests from the Clients to the Broker</t> to the Clients</li>
</list> <li>subscribe requests from the Clients to the Broker</li>
</ul>
<t>
Clients use the MQTT PUBLISH packet to publish to a topic. Clients use the MQTT PUBLISH packet to publish to a topic.
The mechanisms specified in this document do not protect the pay The mechanisms specified in this document do not protect the Pay
load of the PUBLISH packet from the Broker. Hence, load of the PUBLISH packet from the Broker. Hence,
the payload is not signed or encrypted specifically for the subs the Payload is not signed or encrypted specifically for the subs
cribers. This functionality may cribers. This functionality may
be implemented using the proposal outlined in the be implemented using the proposal outlined in the
<xref target="I-D.ietf-ace-pubsub-profile">ACE Pub-Sub Profile</ <xref target="I-D.ietf-ace-pubsub-profile" format="default">ACE
xref>. Pub-Sub Profile</xref>.
</t> </t>
<t> <t>
To provide communication confidentiality and Broker authenticati on to the MQTT Clients, TLS is used, and To provide communication confidentiality and Broker authenticati on to the MQTT Clients, TLS is used, and
TLS 1.3 <xref target="RFC8446"></xref> is RECOMMENDED. This docu TLS 1.3 <xref target="RFC8446" format="default"/> is <bcp14>RECO
ment makes the same assumptions as Section 4 of the MMENDED</bcp14>.
<xref target="I-D.ietf-ace-oauth-authz">ACE framework</xr This document makes the same assumptions as
ef> regarding Client and RS <xref target="RFC9200" format="default" sectionFormat="of
registration with the AS and setting up the keying material. " section="4">the ACE framework</xref> regarding Client and RS
registration with the AS for setting up the keying material.
While the Client-Broker exchanges are only over MQTT, the requir ed Client-AS and While the Client-Broker exchanges are only over MQTT, the requir ed Client-AS and
RS-AS interactions are described for HTTPS-based communication < RS-AS interactions are described for HTTPS-based communication <
xref target="I-D.ietf-httpbis-semantics"></xref>, xref target="RFC9110" format="default"/>,
using "application/ace+json" using the "application/ace+json"
content type, and unless otherwise specified, using JSON encodin content type and, unless otherwise specified, JSON encoding. The
g. The token MAY be an token <bcp14>MAY</bcp14> be an
opaque reference to authorization information or JSON Web Token opaque reference to authorization information or a JSON Web Tok
(JWT) <xref target="RFC7519"></xref>. en (JWT) <xref target="RFC7519" format="default"/>.
For JWTs, this document follows <xref target="RFC7800"></xref> For JWTs, this document follows <xref target="RFC7800" format="d
efault"/>
for PoP semantics for JWTs, and the mechanisms for providing and verifying PoP for PoP semantics for JWTs, and the mechanisms for providing and verifying PoP
are detailed in <xref target="connect_v5"></xref>. The Client-A are detailed in <xref target="connect_v5" format="default"/>. T
S and RS-AS exchanges MAY also use protocols other than HTTP, he Client-AS and RS-AS exchanges <bcp14>MAY</bcp14> also use protocols other tha
e.g., Constrained Application Protocol (CoAP) <xref target="RFC7 n HTTP,
252"></xref> or MQTT. It is recommended e.g., Constrained Application Protocol (CoAP) <xref target="RFC7
252" format="default"/> or MQTT. It is recommended
that TLS is used to secure these communication channels between Client-AS and RS-AS. that TLS is used to secure these communication channels between Client-AS and RS-AS.
To reduce the protocol memory and bandwidth To reduce the protocol memory and bandwidth
requirements, implementations MAY also use "application/ace+cbor requirements, implementations <bcp14>MAY</bcp14> also use the "a
" content type, and CBOR encoding <xref target="RFC8949"></xref>, and pplication/ace+cbor" content type, Concise Binary Object Representation (CBOR) e
CBOR Web Token (CWT) <xref target="RFC8392"></xref> and associat ncoding <xref target="RFC8949" format="default"/>,
ed PoP semantics. For more information, see <xref target="RFC8747">Proof-of-Pos CBOR Web Tokens (CWTs) <xref target="RFC8392" format="default"/>
session Key , and associated PoP semantics. For more information, see <xref target="RFC8747
Semantics for CBOR Web Tokens (CWTs)</xref>. " format="default">"Proof-of-Possession Key
A JWT token uses JOSE, while a CWT token uses COSE <xref target= Semantics for CBOR Web Tokens (CWTs)"</xref>.
"RFC8152"></xref> for security protection. A JWT uses JSON Object Signing and Encryption (JOSE), while a CW
</t> T uses CBOR Object Signing and Encryption (COSE) <xref target="RFC9052" format="
default"/> for security protection.
<section title="Requirements Language"> </t>
<t> <section numbered="true" toc="default">
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <name>Requirements Language</name>
NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", " The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
MAY", and "OPTIONAL" in this IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
document are to be interpreted as described in BCP 14 <xref NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
target="RFC2119"></xref> <xref target="RFC8174"></xref>, RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, and only when, they appear in all capitals, as shown "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
here. be interpreted as
</t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
</section> when, and only when, they appear in all capitals, as shown here.
</t>
<section title="ACE-Related Terminology"> </section>
<t> <section numbered="true" toc="default">
Certain security-related terms such as "authentication", "au <name>ACE-Related Terminology</name>
thorization", "confidentiality", "(data) <t>
integrity", "message authentication code", and "verify" are Certain security-related terms, such as "authentication",
taken from <xref target="RFC4949"></xref>. "authorization", "data confidentiality", "(data) integrity", "message
</t> authentication code" (MAC), and "verify", are taken from <xref target="RFC494
<t> 9" format="default"/>.
The terminology for entities in the architecture is defined </t>
in OAuth 2.0 <xref target="RFC6749"></xref> such as "Client" (C), <t>
"Resource Server" (RS) and "Authorization Server" (AS). The terminology for entities in the architecture is defined
</t> in OAuth 2.0 <xref target="RFC6749" format="default"/>, such as "Client" (C),
<t> "Resource Server" (RS), and "Authorization Server" (AS).
The term "resource" is used to refer to an MQTT Topic Name, </t>
which is defined in <xref target="mqtt-defs"></xref>. <t>
The term "resource" is used to refer to an MQTT Topic Name,
which is defined in <xref target="mqtt-defs" format="default"/>.
Hence, the "Resource Owner" is any entity that can authorita tively speak for the topic. Hence, the "Resource Owner" is any entity that can authorita tively speak for the topic.
This document also defines a Client Authorization Server for Clients that are not This document also defines a Client Authorization Server for Clients that are not
able to support HTTP. able to support HTTP.
</t> </t>
<t> <dl newline="true" spacing="normal" indent="8">
<list hangIndent="8" style="hanging"> <dt>Client Authorization Server (CAS)</dt>
<t hangText="Client Authorization Server (CAS)"> <dd>
<vspace blankLines="0"/> An entity that prepares and endorses authentication and author
An entity that prepares and endorses authentication and author ization data for a Client
ization data for a Client,
and communicates to the AS using HTTPS. and communicates to the AS using HTTPS.
</t> </dd>
</list> </dl>
</t> </section>
</section> <section anchor="mqtt-defs" numbered="true" toc="default">
<name>MQTT-Related Terminology</name>
<section title="MQTT-Related Terminology" anchor="mqtt-defs"> <t>
<t> The document describes message exchanges as MQTT protocol in
The document describes message exchanges as MQTT protocol in teractions. The Clients are MQTT Clients, which connect to the
teractions. The Clients are MQTT Clients, Broker to publish and subscribe to Application Messages (which are
which connect to the Broker to publish and subscribe to Appl labeled with their topics). For additional information,
ication Messages, labelled please refer to the <xref target="MQTT-OASIS-Standard-v5" fo
with their topics. For additional information, rmat="default">MQTT v5.0 OASIS Standard
please refer to the <xref target="MQTT-OASIS-Standard-v5">MQ </xref> or <xref target="MQTT-OASIS-Standard-v3.1.1" format
TT v5.0 ="default">MQTT v3.1.1 OASIS Standard
- the OASIS Standard</xref> or the <xref target="MQTT-OASIS </xref>.
-Standard-v3.1.1">MQTT v3.1.1 </t>
- the OASIS Standard</xref>. <dl newline="true" spacing="normal" indent="8">
</t> <dt>Broker</dt>
<t> <dd>
<list hangIndent="8" style="hanging">
<t hangText="Broker">
<vspace blankLines="0"/>
The Server in MQTT. It acts as an intermediary betwe en the Clients that publish Application Messages The Server in MQTT. It acts as an intermediary betwe en the Clients that publish Application Messages
and the Clients that made Subscriptions. The Broker acts as the Resource Server for the Clients. and the Clients that made Subscriptions. The Broker acts as the Resource Server for the Clients.
</t> </dd>
<t hangText="Client"> <dt>Client</dt>
<vspace blankLines="0"/> <dd>
A device or program that uses MQTT. A device or program that uses MQTT.
</t> </dd>
<t hangText = "Network Connection"> <dt>Network Connection</dt>
<vspace blankLines="0"/> <dd>
A construct provided by the underlying transport pro tocol that is being used by MQTT. A construct provided by the underlying transport pro tocol that is being used by MQTT.
It connects the Client to the Server. It provides th It connects the Client to the Server. It provides th
e means to send an ordered, lossless, e means to send an ordered, lossless
stream of bytes in both directions. This document us stream of bytes in both directions. This document us
es TLS as tranport protocol. es TLS as the transport protocol.
</t> </dd>
<t hangText = "Session"> <dt>Session</dt>
<vspace blankLines="0"/> <dd>
A stateful interaction between a Client and a Broker . A stateful interaction between a Client and a Broker .
Some Sessions last only as long as the Network Conne ction; Some Sessions last only as long as the Network Conne ction;
others can span multiple Network Connections. others can span multiple Network Connections.
</t> </dd>
<t hangText="Application Message"> <dt>Application Message</dt>
<vspace blankLines="0"/> <dd>
The data carried by the MQTT protocol. The data has an associated Quality-of-Service (QoS) level and Topic The data carried by the MQTT protocol. The data has an associated Quality-of-Service (QoS) level and Topic
Name. Name.
</t> </dd>
<t hangText="MQTT Control Packet"> <dt>MQTT Control Packet</dt>
<vspace blankLines="0"/> <dd>
The MQTT protocol operates by exchanging a series of The MQTT protocol operates by exchanging a series of
MQTT Control packets. MQTT Control Packets.
Each packet is composed of a Fixed Header, a Variable Header (depending Each packet is composed of a Fixed Header, a Variable Header (depending
on the control packet type), and a Payload. on the Control Packet type), and a Payload.
</t> </dd>
<t hangText="UTF-8 encoded string"> <dt>UTF-8-encoded string</dt>
<vspace blankLines="0"/> <dd>
A string prefixed with a two-byte length field that A string prefixed with a two-byte-length field that
gives the number of bytes in a UTF-8 encoded string itself. gives the number of bytes in a UTF-8-encoded string itself.
Unless stated otherwise, all UTF-8 encoded strings c Unless stated otherwise, all UTF-8-encoded strings c
an have any length in the range 0 to 65535 bytes. an have any length in the range 0 to 65535 bytes.
</t> </dd>
<t hangText="Binary Data"> <dt>Binary Data</dt>
<vspace blankLines="0"/> <dd>
Binary Data is represented by a two-byte length fiel Binary Data is represented by a two-byte-length fiel
d which indicates the number of data bytes, followed by that number of bytes. d, which indicates the number of data bytes, followed by that number of bytes.
Thus, the length of Binary Data is limited to the ra Thus, the length of Binary Data is limited to the ra
nge of 0 to 65535 Bytes. nge of 0 to 65535 bytes.
</t> </dd>
<t hangText="Variable Byte Integer"> <dt>Variable Byte Integer</dt>
<vspace blankLines="0"/> <dd>
Variable Byte Integer is encoded using an encoding s A Variable Byte Integer is encoded using an encoding
cheme that uses a single byte for values up to 127. scheme that uses a single byte for values up to 127.
For larger values, the least significant seven bits of each byte encode the data, For larger values, the least significant seven bits of each byte encode the data,
and the most significant bit is used to indicate whe ther there are bytes following in and the most significant bit is used to indicate whe ther there are bytes following in
the representation. Thus, each byte encodes 128 valu es and a "continuation bit". the representation. Thus, each byte encodes 128 valu es and a "continuation bit".
The maximum number of bytes in the Variable Byte Int eger field is four. The maximum number of bytes in the Variable Byte Int eger field is four.
</t> </dd>
<t hangText="QoS level"> <dt>QoS level</dt>
<vspace blankLines="0"/> <dd>
The level of assurance for the delivery of an Applic ation Message. The QoS level can be 0-2, The level of assurance for the delivery of an Applic ation Message. The QoS level can be 0-2,
where 0 indicates "At most once delivery", 1 "At lea where 0 indicates "At most once delivery", 1 indicat
st once delivery", and 2 "Exactly once delivery". es "At least once delivery", and 2 indicates "Exactly once delivery".
</t> </dd>
<t hangText="Property"> <dt>Property</dt>
<vspace blankLines="0"/> <dd>
The last field of the Variable Header is a set of pr operties The last field of the Variable Header is a set of pr operties
for several MQTT control packets (e.g. CONNECT, CONN for several MQTT Control Packets (e.g., CONNECT and
ACK). CONNACK).
A Property consists of an Identifier that defines it A property consists of an Identifier that defines it
s usage and data type, followed by a value. s usage and data type, followed by a value.
The Identifier is encoded as a Variable Byte Integer . For example, the "Authentication Data" property The Identifier is encoded as a Variable Byte Integer . For example, the "Authentication Data" property
uses the Identifier 22. uses the identifier 22.
</t> </dd>
<t hangText="Topic Name"> <dt>Topic Name</dt>
<vspace blankLines="0"/> <dd>
The label attached to an Application Message, which is matched to a Subscription. The label attached to an Application Message, which is matched to a Subscription.
</t> </dd>
<t hangText="Subscription"> <dt>Subscription</dt>
<vspace blankLines="0"/> <dd>
A Subscription comprises a Topic Filter and a maximu A Subscription comprises a Topic Filter and a maximu
m QoS. A Subscription is associated with a single session. m QoS. A Subscription is associated with a single Session.
</t> </dd>
<t hangText="Topic Filter"> <dt>Topic Filter</dt>
<vspace blankLines="0"/> <dd>
An expression that indicates interest in one or more Topic Names. Topic Filters may include An expression that indicates interest in one or more Topic Names. Topic Filters may include
wildcards. wildcards.
</t> </dd>
</list> </dl>
</t> <t>
<t> MQTT sends various Control Packets across a Network Connecti
MQTT sends various control packets across a Network Connecti on.
on. The following is not an exhaustive list, and the Control Pac
The following is not an exhaustive list, and the control pac kets that are not relevant for
kets that are not relevant for
authorization are not explained. authorization are not explained.
These include, for instance, the PUBREL and PUBCOMP packets used in the 4-step handshake required For instance, these include the PUBREL and PUBCOMP packets u sed in the 4-step handshake required
for QoS level 2. for QoS level 2.
<list hangIndent="8" style="hanging"> </t>
<t hangText="CONNECT"> <dl newline="true" spacing="normal" indent="8">
<vspace blankLines="0"/> <dt>CONNECT</dt>
Client request to connect to the Broker. This is <dd>
The Client requests to connect to the Broker. This i
s
the first packet sent by a Client. the first packet sent by a Client.
</t> </dd>
<t hangText="CONNACK"> <dt>CONNACK</dt>
<vspace blankLines="0"/> <dd>
The Broker connection acknowledgment. CONNACK packet s The Broker connection acknowledgment. CONNACK packet s
contain return codes indicating either a success or an error state contain return codes that indicate either a success or an error state
in response to a Client's CONNECT packet. in response to a Client's CONNECT packet.
</t> </dd>
<t hangText="AUTH"> <dt>AUTH</dt>
<vspace blankLines="0"/> <dd>
Authentication Exchange. An AUTH control packet is s An AUTH Control Packet is sent from the Client to th
ent from the Client to the Broker or e Broker or
from the Broker to the Client as part of an extended authentication exchange. from the Broker to the Client as part of an extended authentication exchange.
AUTH Properties include Authentication Method and Au thentication Data. AUTH properties include the Authentication Method an d Authentication Data.
The Authentication Method is set in the CONNECT pack et, and consequent The Authentication Method is set in the CONNECT pack et, and consequent
AUTH packets follow the same Authentication Method. AUTH packets follow the same Authentication Method.
The contents of the Authentication Data are defined by the Authentication Method. The contents of the Authentication Data are defined by the Authentication Method.
</t> </dd>
<t hangText="PUBLISH"> <dt>PUBLISH</dt>
<vspace blankLines="0"/> <dd>
Publish request sent from a publishing Client to the Publish request sent from a publishing Client to the
Broker, or from the Broker to a Broker or from the Broker to a
subscribing Client. subscribing Client.
</t> </dd>
<t hangText="PUBACK"> <dt>PUBACK</dt>
<vspace blankLines="0"/> <dd>
Response to a PUBLISH request with QoS level 1. A PU Response to a PUBLISH request with QoS level 1. PUBA
BACK can be sent from the Broker to a CK can be sent from the Broker to a
Client or from a Client to the Broker. Client or from a Client to the Broker.
</t> </dd>
<t hangText="PUBREC"> <dt>PUBREC</dt>
<vspace blankLines="0"/> <dd>
Response to PUBLISH request with QoS level 2. PUBREC Response to a PUBLISH request with QoS level 2. PUBR
can be sent from the Broker to a EC can be sent from the Broker to a
Client or from a Client to the Broker. Client or from a Client to the Broker.
</t> </dd>
<t hangText="SUBSCRIBE"> <dt>SUBSCRIBE</dt>
<vspace blankLines="0"/> <dd>
Subscribe request sent from a Client. Subscribe request sent from a Client.
</t> </dd>
<t hangText="SUBACK"> <dt>SUBACK</dt>
<vspace blankLines="0"/> <dd>
Subscribe acknowledgment from the Broker to the Clie nt. Subscribe acknowledgment from the Broker to the Clie nt.
</t> </dd>
<t hangText="PINGREQ"> <dt>PINGREQ</dt>
<vspace blankLines="0"/> <dd>
A ping request sent from a Client to the Broker. It signals to the Broker that the Client is alive and A ping request sent from a Client to the Broker. It signals to the Broker that the Client is alive and
is used to confirm that the Broker is als o alive. The "Keep Alive" period is set in the CONNECT packet. is used to confirm that the Broker is als o alive. The "Keep Alive" period is set in the CONNECT packet.
</t> </dd>
<t hangText="PINGRESP"> <dt>PINGRESP</dt>
<vspace blankLines="0"/> <dd>
Response sent by the Broker to the Client in response to PINGREQ. It indicates the Broker is alive. Response sent by the Broker to the Client in response to PINGREQ. It indicates the Broker is alive.
</t> </dd>
<t hangText="DISCONNECT"> <dt>DISCONNECT</dt>
<vspace blankLines="0"/> <dd>
The DISCONNECT packet is the final MQTT Control Pack et The DISCONNECT packet is the final MQTT Control Pack et
sent from the Client or the Broker. sent from the Client or the Broker.
It indicates the reason why the Network Connection i s being closed. It indicates the reason why the Network Connection i s being closed.
If the Network Connection is closed without the Clie nt first sending a If the Network Connection is closed without the Clie nt first sending a
DISCONNECT packet with Reason Code 0x00 (Normal disc DISCONNECT packet with reason code 0x00 (Normal disc
onnection) and onnection) and
the Connection has a Will Message, the Will Message the MQTT Connection has a Will Message, the Will Mes
is published. sage is published.
</t> </dd>
<t hangText="Will"> <dt>Will</dt>
<vspace blankLines="0"/> <dd>
If the Network Connection is not closed normally, th <t>
e Broker sends a last Will message If the Network Connection is not closed normally, th
e Broker sends a last Will Message
for the Client if the Client provided one in its CON NECT packet. for the Client if the Client provided one in its CON NECT packet.
Situations in which the Will Message is published in Situations in which the Will Message is published in
clude, but are not limited to: clude, but are not limited to, the following:
<list style="symbols"> </t>
<t>An I/O error or network failure detected by the <ul spacing="normal">
Broker.</t> <li>an I/O error or network failure detected by the Broker,</li>
<t>The Client fails to communicate within the Keep <li>the Client fails to communicate within the Keep Alive period,<
Alive period.</t> /li>
<t>The Client closes the Network Connection without <li>the Client closes the Network Connection without first sending
first sending a DISCONNECT packet with a Reason Code 0x00 (Normal disconnection a DISCONNECT packet with reason code 0x00 (Normal disconnection), and</li>
).</t> <li>the Broker closes the Network Connection without first receivi
<t>The Broker closes the Network Connection without ng a DISCONNECT packet with reason code 0x00 (Normal disconnection).</li>
first receiving a DISCONNECT packet with a Reason Code 0x00 (Normal disconnecti </ul>
on).</t> <t>
</list> If the Will Flag is set in the CONNECT flags, then t
If the Will Flag is set in the CONNECT flags, then t he Payload of the CONNECT packet includes information
he payload of the CONNECT packet includes information
about the Will. The information consists of the Will Properties, Will Topic, about the Will. The information consists of the Will Properties, Will Topic,
and Will Payload fields. and Will Payload fields.
</t> </t>
</list> </dd>
</t> </dl>
</section> </section>
</section> </section>
<section title="Authorizing Connection Requests" anchor="token_acquisiti <section anchor="token_acquisition" numbered="true" toc="default">
on"> <name>Authorizing Connection Requests</name>
<t> <t>
This section specifies how Client connections are authorized by the AS This section specifies how Client connections are authorized by the AS
and verified by the MQTT Broker. <xref target="protocol_flow"></xref > shows the basic protocol flow and verified by the MQTT Broker. <xref target="protocol_flow" format ="default"/> shows the basic protocol flows
during connection setup. The token request and response use the toke n endpoint during connection setup. The token request and response use the toke n endpoint
at the AS, specified for HTTP-based interactions in Section 5.8 of t at the AS, specified for HTTP-based interactions in <xref target="RF
he <xref target="I-D.ietf-ace-oauth-authz">ACE framework</xref>. C9200" format="default" sectionFormat="of" section="5.8">the ACE framework</xref
Steps (D) and (E) are optional and use the introspection endpoint sp >.
ecified in Section 5.9 of the ACE framework. Steps (D) and (E) are optional and use the introspection endpoint sp
ecified in <xref target="RFC9200" format="default" sectionFormat="of" section="5
.9"> the ACE framework</xref>.
The discussion in this document assumes that the Client and the Brok er use HTTPS to communicate The discussion in this document assumes that the Client and the Brok er use HTTPS to communicate
with the AS via these endpoints. The Client and the Broker use MQTT to communicate between them. with the AS via these endpoints. The Client and the Broker use MQTT to communicate between them.
The C-AS and Broker-AS communication MAY be implemented using protoc The C-AS and Broker-AS communications <bcp14>MAY</bcp14> be implemen
ols other than HTTPS, ted using protocols other than HTTPS,
e.g. CoAP or MQTT. Whatever protocol is used for C-AS and Broker-AS e.g., CoAP or MQTT. Whatever protocol is used for the C-AS and Brok
communications MUST provide mutual er-AS communications <bcp14>MUST</bcp14> provide mutual
authentication, confidentiality protection, and integrity protection . authentication, confidentiality protection, and integrity protection .
</t> </t>
<t> <t>
If the Client is resource-constrained or does not support HTTPS, a s If the Client is resource constrained or does not support HTTPS, a s
eparate Client Authorization Server eparate Client Authorization Server
may carry out the token request on behalf of the Client (Figure 1 (A may carry out the token request on behalf of the Client (<xref targe
) and (B)), and later, onboard the Client with the token. t="protocol_flow"/>, steps (A) and (B)) and, later, onboard the Client with the
token.
The interactions between a Client and its Client Authorization Serve r for token The interactions between a Client and its Client Authorization Serve r for token
onboarding and support for MQTT-based token requests at the AS are o ut of the scope of this document. onboarding and support for MQTT-based token requests at the AS are o ut of the scope of this document.
</t> </t>
<figure align="center" anchor="protocol_flow" title="Connection Setu <figure anchor="protocol_flow">
p"> <name>Connection Setup</name>
<artwork align="left"><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
+---------------------+ +---------------------+
| 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)
]]></artwork> ]]></artwork>
</figure> </figure>
<section numbered="true" toc="default">
<section title="Client Token Request to the Authorization Server (AS)"> <name>Client Token Request to the Authorization Server (AS)</name>
<t> <t>
The first step in the protocol flow (Figure 1 (A)) is the token The first step in the protocol flow (<xref target="protocol_flow
acquisition by the Client "/>, step (A)) is the token acquisition by the Client
from the AS. The Client and the AS MUST perform mutual authentic from the AS. The Client and the AS <bcp14>MUST</bcp14> perform m
ation. utual authentication.
The Client requests an access token from the AS as The Client requests an access token from the AS, as
described in Section 5.8.1 of the <xref target="I-D.ietf-ace-oau described in <xref target="RFC9200" format="default" sectionForm
th-authz">ACE framework</xref>. at="of" section="5.8.1">the ACE framework</xref>.
The document follows the procedures defined in Section 3.2.1 of The document follows the procedures defined in <xref target="RFC
the <xref target="I-D.ietf-ace-dtls-authorize">DTLS profile</xref> 9202" format="default" sectionFormat="of" section="3.2.1">the DTLS profile</xref
for RPK (Raw Public Keys <xref target="RFC7250"></xref>), and in >
Section 3.3.1 of the same document for PSK (Pre-Shared Keys). for raw public keys (RPKs) <xref target="RFC7250" format="defaul
t"/>) and in <xref target="RFC7250" section="3.3.1" sectionFormat="of" format="d
efault"/> for pre-shared keys (PSKs).
However, the content type of the request is set to "application/ ace+json", However, the content type of the request is set to "application/ ace+json",
and the AS uses JSON in the payload of its responses to the Clie and the AS uses JSON in the Payload of its responses to the Clie
nt and the RS. nt and the RS.
As explained earlier, implementations MAY also use "application/ As explained earlier, implementations <bcp14>MAY</bcp14> also us
ace+cbor" content type. e the "application/ace+cbor" content type.
</t> </t>
<t> On receipt of the token request, the AS verifies the request. <t> On receipt of the token request, the AS verifies the request.
If the AS successfully verifies the access token request and aut horizes the Client for the If the AS successfully verifies the access token request and aut horizes the Client for the
indicated audience (i.e., RS) and scopes (i.e., publish/subscrib indicated audience (i.e., RS) and scopes (i.e., publish/subscrib
e permissions over topics as described e permissions over topics, as described
in <xref target="scope"></xref>), in <xref target="scope" format="default"/>),
the AS issues an access token (Figure 1 (B)). the AS issues an access token (<xref target="protocol_flow"/>, s
</t> tep (B)).
<t>The response includes the parameters described </t>
in Section 5.8.2 of <xref target="I-D.ietf-ace-oauth-authz">the <t>The response includes the parameters described
ACE framework</xref>. in <xref target="RFC9200" section="5.8.2" sectionFormat="of" for
For RPK, the parameters are as described mat="default">the ACE framework</xref>.
in Section 3.2.1 of the <xref target="I-D.ietf-ace-dtls-authoriz For RPKs, the parameters are as described
e">DTLS profile</xref>. in <xref target="RFC9202" section="3.2.1" sectionFormat="of" for
For PSK, the document follows Section 3.3.1 of the <xref target= mat="default">the DTLS profile</xref>.
"I-D.ietf-ace-dtls-authorize">DTLS profile</xref>. For PSKs, the document follows <xref target="RFC9202" format="de
fault" sectionFormat="of" section="3.3.1">the DTLS profile</xref>.
In both cases, if the response contains an "ace_profile" parame ter, this parameter is set In both cases, if the response contains an "ace_profile" parame ter, this parameter is set
to "mqtt_tls". to "mqtt_tls".
The returned token is a Proof-of-Possession (PoP) token by defau lt. The returned token is a Proof-of-Possession (PoP) token by defau lt.
</t> </t>
<t> <t>
This document follows <xref target="RFC7800"></xref> for PoP sem This document follows <xref target="RFC7800" format="default"/>
antics for JWTs for PoP semantics for JWTs
(CWTs MAY also be used). The AS includes a "cnf" (confirmation) (CWTs <bcp14>MAY</bcp14> also be used). The AS includes a "cnf"
parameter in the PoP token, (confirmation) parameter in the PoP token
to declare that the Client to declare that the Client
possesses a particular key and RS can cryptographically confirm possesses a particular key and the RS can cryptographically conf
that irm that
the Client has possession of that key, as described in <xref tar the Client has possession of that key, as described in <xref tar
get="I-D.ietf-ace-oauth-params"></xref>. get="RFC9201" format="default"/>.
</t> </t>
<t> <t>
Note that the contents of the web tokens (including the "cnf" pa rameter) are to be consumed by the RS Note that the contents of the web tokens (including the "cnf" pa rameter) are to be consumed by the RS
and not the Client (the Client obtains the key information in a different manner). and not the Client (the Client obtains the key information in a different manner).
The RPK case is handled as described in Section 3.2.1 of the <xr ef target="I-D.ietf-ace-dtls-authorize">DTLS profile</xref>. The RPK case is handled as described in <xref target="RFC9202" f ormat="default" sectionFormat="of" section="3.2.1">the DTLS profile</xref>.
For the PSK case, the referenced procedures apply, with the foll owing exceptions to accommodate For the PSK case, the referenced procedures apply, with the foll owing exceptions to accommodate
JWT and JOSE use. JWT and JOSE use.
In this case, the AS adds a "cnf" parameter to the access inform In this case, the AS adds a "cnf" parameter to the Access Inform
ation ation
carrying <xref target="RFC7517">a JWK (JSON Web Key)</xref> obj carrying <xref target="RFC7517" format="default">a JSON Web Key
ect that contains (JWK)</xref> object that contains
either the symmetric key itself or a key identifier that can be used by the RS to either the symmetric key itself or a key identifier that can be used by the RS to
determine the secret key it shares with the Client. determine the secret key it shares with the Client.
The JWT is created as explained in Section 7 of <xref target="RF The JWT is created as explained in <xref target="RFC7519" sectio
C7519"></xref>, n="7" sectionFormat="of" format="default"/>,
and the JWT MUST include <xref target="RFC7516">JWE</xref>. and the JWT <bcp14>MUST</bcp14> include <xref target="RFC7516"
If CWT/COSE is used this information MUST be inside the "COSE_Ke format="default"> a JSON Web Encryption (JWE)</xref>.
y" object, If a CWT/COSE is used, this information <bcp14>MUST</bcp14> be i
and MUST be encrypted using a "COSE_Encrypt0" structure. nside the "COSE_Key" object
</t> and <bcp14>MUST</bcp14> be encrypted using a "COSE_Encrypt0" str
<t> The AS returns error responses for JSON-based interactions ucture.
following Section 5.2 of <xref target="RFC6749"></xref>. </t>
When CBOR is used, the interactions MUST implement <t> The AS returns error responses for JSON-based interactions
Section 5.8.3 of the <xref following <xref target="RFC6749" section="5.2" sectionFormat="of
target="I-D.ietf-ace-oauth-authz">ACE framework</xref>. " format="default"/>.
</t> When CBOR is used, the interactions <bcp14>MUST</bcp14> implemen
</section> t the procedure described in
<section title="Client Connection Request to the Broker (C)" anchor="con <xref target="RFC9200" format="default" section="5.8.3" sectionF
nect_v5"> ormat="of">the ACE framework</xref>.
<section title="Overview of Client-RS Authentication Methods over TL </t>
S and MQTT" anchor="auth_options"> </section>
<t> <section anchor="connect_v5" numbered="true" toc="default">
Unless the Client publishes and subscribes to only public to <name>Client Connection Request to the Broker (C)</name>
pics, the Client and the Broker MUST perform mutual authentication. <section anchor="auth_options" numbered="true" toc="default">
The Client MUST authenticate to the Broker either over MQTT <name>Overview of Client-RS Authentication Methods over TLS and MQTT</
or TLS before performing any other action. name>
<t>
Unless the Client publishes and subscribes to only public to
pics, the Client and the Broker <bcp14>MUST</bcp14> perform mutual authenticatio
n.
The Client <bcp14>MUST</bcp14> authenticate to the Broker ei
ther over MQTT or TLS before performing any other action.
For MQTT, the options are "None" and "ace". For MQTT, the options are "None" and "ace".
For TLS, the options are "Anon" for an anonymous client, For TLS, the options are "Anon" for an anonymous client,
and "Known(RPK/PSK)" for RPK and PSK, respectively. and "Known(RPK/PSK)" for RPKs and PSKs, respectively.
The "None" and "Anon" options do not provide client authenti cation but can be used either The "None" and "Anon" options do not provide client authenti cation but can be used either
during authentication or in combination with authentication at the other layer. during authentication or in combination with authentication at the other layer.
When the Client uses TLS:Anon,MQTT:None, the Client can only publish or subscribe to public topics. When the Client uses TLS:Anon,MQTT:None, the Client can only publish or subscribe to public topics.
Thus, the client authentication procedures involve the follo wing possible combinations: Thus, the client authentication procedures involve the follo wing possible combinations:
<list style="symbols"> </t>
<t>TLS:Anon,MQTT:None: This option is used only for the <dl newline="true" spacing="normal" indent="8">
topics that do not require authorization, <dt>TLS:Anon,MQTT:None:</dt> <dd>This option is used only for the to
including the "authz-info" topic. Publishing to the pics that do not require authorization,
"authz-info" topic is described in <xref target="app-authzinfo"></xref>.</t> including the "authz-info" topic. Publishing to the
<t>TLS:Anon,MQTT:ace: The token is transported inside th "authz-info" topic is described in <xref target="app-authzinfo" format="default"
e CONNECT packet and MUST be />.</dd>
validated using one of the methods described in <xre <dt>TLS:Anon,MQTT:ace:</dt> <dd>The token is transported inside the
f target="app-authzinfo"></xref>. This option also supports CONNECT packet and <bcp14>MUST</bcp14> be
a tokenless connection request for AS discovery. As validated using one of the methods described in <xre
per the <xref target="I-D.ietf-ace-oauth-authz">ACE framework</xref>, f target="app-authzinfo" format="default"/>. This option also supports
a separate step is needed to determine whether the d a tokenless connection request for AS discovery. As
iscovered AS URI is authorized to act as an AS.</t> per the <xref target="RFC9200" format="default">ACE framework</xref>,
<t>TLS:Known(RPK/PSK),MQTT:none: This specification supp a separate step is needed to determine whether the d
orts client authentication with TLS with RPK and PSK following the procedures iscovered AS URI is authorized to act as an AS.</dd>
described in <xref target="I-D.ietf-ace-dtls-authori <dt>TLS:Known(RPK/PSK),MQTT:none:</dt> <dd>This specification suppor
ze">DTLS profile</xref>. ts client authentication with TLS with RPKs and PSKs, following the procedures
described in the <xref target="RFC9202" format="defa
ult">DTLS profile</xref>.
For the RPK, the Client For the RPK, the Client
MUST have published the token to the "authz-info" to <bcp14>MUST</bcp14> have published the token to the
pic. For the PSK, the token MAY be published to the "authz-info" topic, "authz-info" topic. For the PSK, the token <bcp14>MAY</bcp14> be published to th
or MAY be, alternatively, e "authz-info" topic
provided as a "PSK identity" (e.g. an "identity" in or <bcp14>MAY</bcp14> be, alternatively,
the "identities" field in the Client's "pre_shared_key" extension in TLS 1.3). provided as a "PSK identity" (e.g., an "identity" i
</t> n the "identities" field in the Client's "pre_shared_key" extension in TLS 1.3).
<t>TLS:Known(RPK/PSK),MQTT:ace: This option SHOULD NOT b </dd>
e chosen as the token transported in the CONNECT <dt>TLS:Known(RPK/PSK),MQTT:ace:</dt> <dd>This option <bcp14>SHOULD
overwrites any permissions passed during the TLS aut NOT</bcp14> be chosen as the token transported in the CONNECT packet and
hentication.</t> overwrites any permissions passed during the TLS aut
</list> hentication.</dd>
It is RECOMMENDED that the Client implements TLS:Anon,MQTT: </dl>
ace as the first choice when working with protected topics. <t>
However, MQTT v3.1.1 Clients that do not prefer to overload It is <bcp14>RECOMMENDED</bcp14> that the Client implements
username and password fields TLS:Anon,MQTT:ace as the first choice when working with protected topics.
for ACE (as described in <xref target="MQTTv311"></xref>) M However, MQTT v3.1.1 Clients that do not prefer to overload
AY implement TLS:Known(RPK/PSK),MQTT:none, and the User Name and Password fields
consequently TLS:Anon,MQTT:None to submit their token to "a for ACE (as described in <xref target="MQTTv311" format="de
uthz-info". fault"/>) <bcp14>MAY</bcp14> implement TLS:Known(RPK/PSK),MQTT:none and,
</t> consequently, TLS:Anon,MQTT:None to submit their token to "
<t> authz-info".
The Broker MUST support TLS:Anon,MQTT:ace. </t>
To support Clients with different capabilities, the Broker <t>
MAY provide multiple client authentication options, The Broker <bcp14>MUST</bcp14> support TLS:Anon,MQTT:ace.
e.g. support TLS:Known(RPK),MQTT:none and TLS:Anon,MQTT:Non To support Clients with different capabilities, the Broker
e, <bcp14>MAY</bcp14> provide multiple client authentication options,
e.g., support TLS:Known(RPK),MQTT:none and TLS:Anon,MQTT:No
ne,
to enable RPK-based client authentication. to enable RPK-based client authentication.
</t> </t>
<t> <t>
The Client MUST authenticate the Broker during the TLS hands The Client <bcp14>MUST</bcp14> authenticate the Broker durin
hake. g the TLS handshake.
If the Client authentication uses TLS:Known(RPK/PSK), If the Client authentication uses TLS:Known(RPK/PSK),
then the Broker is authenticated using the respective method . then the Broker is authenticated using the respective method .
Otherwise, to authenticate the Broker, the Client MUST valid ate a Otherwise, to authenticate the Broker, the Client <bcp14>MUS T</bcp14> validate a
public key from an X.509 certificate or an RPK from the Brok er against the public key from an X.509 certificate or an RPK from the Brok er against the
"rs_cnf" parameter in the token response, which contains inf ormation "rs_cnf" parameter in the token response, which contains inf ormation
about the public key used by the RS to authenticate if the t oken type is "pop" about the public key used by the RS to authenticate if the t oken type is "pop"
and asymmetric keys are used as defined in <xref target="I-D and asymmetric keys are used as defined in <xref target="RFC
.ietf-ace-oauth-params"></xref>. 9201" format="default"/>.
The AS MAY include the thumbprint of the RS's X.509 certific The AS <bcp14>MAY</bcp14> include the thumbprint of the RS's
ate in the "rs_cnf" X.509 certificate in the "rs_cnf"
(thumbprint as defined in <xref target="I-D.ietf-cose-x509"> (thumbprint, as defined in <xref target="RFC9360" format="de
</xref>). In this case, fault"/>). In this case,
the Client MUST validate the RS certificate against this thu the Client <bcp14>MUST</bcp14> validate the RS certificate a
mbprint. gainst this thumbprint.
</t> </t>
</section> </section>
<section anchor="app-authzinfo" title="authz-info: The Authorization <section anchor="app-authzinfo" numbered="true" toc="default">
Information Topic"> <name>authz-info: The Authorization Information Topic</name>
<t> <t>
In the cases when the Client must transport the token to the Broker first, 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 th e "authz-info" topic. the Client connects to the Broker to publish its token to th e "authz-info" topic.
The "authz-info" topic MUST be publish-only (i.e., the Clien ts are not allowed to subscribe to it). The "authz-info" topic <bcp14>MUST</bcp14> only be published (i.e., the Clients are not allowed to subscribe to it).
"authz-info" is not protected, and hence, the Client uses th e TLS:Anon,MQTT:None option over a TLS connection. "authz-info" is not protected, and hence, the Client uses th e TLS:Anon,MQTT:None option over a TLS connection.
After publishing the token, the Client disconnects from the Broker and is expected to reconnect After publishing the token, the Client disconnects from the Broker and is expected to reconnect
using client authentication over TLS (i.e., TLS:Known(RPK/PS K),MQTT:none). using client authentication over TLS (i.e., TLS:Known(RPK/PS K),MQTT:none).
</t> </t>
<t> <t>
The Broker stores and indexes all tokens received to the "au thz-info" topic in its key store The Broker stores and indexes all tokens received to the "au thz-info" topic in its key store
(similar to the <xref target="I-D.ietf-ace-dtls-authorize">D TLS profile for ACE</xref>). (similar to the <xref target="RFC9202" format="default">DTLS profile for ACE</xref>).
This profile follows the recommendation of This profile follows the recommendation of
Section 5.10.1 of the <xref target="I-D.ietf-ace-oauth-authz ">ACE framework</xref> <xref target="RFC9200" format="default" sectionFormat="of" s ection="5.10.1">the ACE framework</xref>
and expects that the Broker stores only one token per PoP ke y, and any other and expects that the Broker stores only one token per PoP ke y, and any other
token linked to the same key overwrites an existing token. token linked to the same key overwrites an existing token.
</t> </t>
<t> <t>
The Broker MUST verify the validity of the token The Broker <bcp14>MUST</bcp14> verify the validity of the to
(i.e., through local validation or introspection, if the tok ken
en is a reference) (i.e., through local validation or introspection if the toke
as described in <xref target="token_validation"></xref>. n is a reference),
If the token is not valid, the Broker MUST discard the token as described in <xref target="token_validation" format="defa
. ult"/>.
</t> If the token is not valid, the Broker <bcp14>MUST</bcp14> di
<t> scard the token.
</t>
<t>
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 . the error response as a PUBACK, PUBREC, or DISCONNECT packet .
If the QoS level is equal to 0, and the token is not valid, If the QoS level is equal to 0, and the token is not valid,
or the claims or if the claims
cannot be obtained in the case of an introspected token, the cannot be obtained in the case of an introspected token, the
Broker MUST Broker <bcp14>MUST</bcp14>
send a DISCONNECT packet with the reason code 0x87 (Not auth send a DISCONNECT packet with reason code 0x87 (Not authoriz
orized). ed).
If the PUBLISH payload does not parse to a token, the Broker If the PUBLISH Payload does not parse to a token, the Broker
MUST send a DISCONNECT with <bcp14>MUST</bcp14> send a DISCONNECT with
the reason code 0x99 (Payload format invalid). reason code 0x99 (Payload format invalid).
</t> </t>
<t> <t>
If the QoS level of the PUBLISH packet is greater than or eq ual to 1, and the token is not valid, or If the QoS level of the PUBLISH packet is greater than or eq ual to 1, and the token is not valid, or
the claims cannot be obtained in the case of an introspected token, the claims cannot be obtained in the case of an introspected token,
the Broker MUST send the reason code 0x87 (Not authorized) i n the PUBACK or PUBREC. If the PUBLISH payload does not parse to a token, the Broker <bcp14>MUST</bcp14> send reason code 0x87 (Not au thorized) in the PUBACK or PUBREC. If the PUBLISH Payload does not parse to a t oken,
the PUBACK/PUBREC reason code is 0x99 (Payload format invali d). the PUBACK/PUBREC reason code is 0x99 (Payload format invali d).
</t> </t>
<t> <t>
It must be noted that when the Broker sends the "Not authori When the Broker sends the "Not authorized" response, it must
zed" response, this corresponds be noted that this corresponds
to the token being not valid, and not that the actual PUBLIS to the token being not valid and not that the actual PUBLISH
H packet was not authorized. packet was not authorized.
Given that the "authz-info" is a public topic, this response is not Given that the "authz-info" is a public topic, this response is not
expected to cause confusion. expected to cause confusion.
</t> </t>
</section> </section>
<section anchor="auth-TLS" title="Client Authentication over TLS"> <section anchor="auth-TLS" numbered="true" toc="default">
<t> <name>Client Authentication over TLS</name>
This document supports TLS with Raw Public Keys (RPK) <t>
<xref target="RFC7250"></xref> and with Pre-Shared Keys (PSK). This document supports TLS with raw public keys (RPKs)
<xref target="RFC7250" format="default"/> and with pre-shared ke
ys (PSKs).
The TLS session setup follows the The TLS session setup follows the
<xref target="I-D.ietf-ace-dtls-authorize">DTLS profile for ACE< /xref>, <xref target="RFC9202" format="default">DTLS profile for ACE</xr ef>,
as the profile applies to TLS equally well as the profile applies to TLS equally well
<xref target="I-D.ietf-ace-extend-dtls-authorize"></xref>. <xref target="RFC9430" format="default"/>.
When there are exceptions to the DTLS profile, these are explici tly When there are exceptions to the DTLS profile, these are explici tly
stated in the document. stated in the document.
If TLS 1.2 is used, <xref target="RFC7925"></xref> describes If TLS 1.2 is used, <xref target="RFC7925" format="default"/> de scribes
how TLS can be used for constrained devices, alongside recommend ed cipher suites. how TLS can be used for constrained devices, alongside recommend ed cipher suites.
Additionally, TLS 1.2 implementations MUST use the "Extended Mai Additionally, TLS 1.2 implementations <bcp14>MUST</bcp14> use th
n Secret" extension (terminology adopted e "Extended Main Secret" extension (terminology adopted
from <xref target="I-D.ietf-tls-rfc8446bis"></xref>) from <xref target="I-D.ietf-tls-rfc8446bis" format="default"/>)
to incorporate the handshake transcript into the main secret <x to incorporate the handshake transcript into the main secret <x
ref target="RFC7627"></xref>. TLS implementations SHOULD use the ref target="RFC7627" format="default"/>. TLS implementations <bcp14>SHOULD</bcp
14> use the
SNI (Server Name Indication) <xref target="RFC6066"></xref> and Server Name Indication (SNI) <xref target="RFC6066" format="defa
APLN (Application-Layer Protocol Negotiation) ult"/> and Application-Layer Protocol Negotiation (ALPN)
<xref target="RFC7301"></xref> extensions so the TLS handshake a <xref target="RFC7301" format="default"/> extensions so the TLS
uthenticates as much of the protocol context as possible. handshake authenticates as much of the protocol context as possible.
</t> </t>
<section anchor="TLS-RPK" title="Raw Public Key Mode"> <section anchor="TLS-RPK" numbered="true" toc="default">
<t> <name>Raw Public Key Mode</name>
This document follows the procedures defined in Section 3.2.2 o <t>
f the This document follows the procedures defined in
<xref target="I-D.ietf-ace-dtls-authorize">DTLS profile for ACE <xref target="RFC9202" format="default" sectionFormat="of" sect
</xref> with ion="3.2.2">the DTLS profile for ACE</xref> with
the following exceptions. the following exceptions.
The Client MUST upload the access token to the Broker using the The Client <bcp14>MUST</bcp14> upload the access token to the B
method specified in roker using the method specified in
<xref target="app-authzinfo"></xref> before initiating the hand <xref target="app-authzinfo" format="default"/> before initiati
shake. ng the handshake.
</t> </t>
</section> </section>
<section anchor="TLS-PSK" title="Pre-Shared Key Mode"> <section anchor="TLS-PSK" numbered="true" toc="default">
<t> <name>Pre-Shared Key Mode</name>
This document follows the procedures defined in Section 3.3.2 o <t>
f This document follows the procedures defined in <xref target="R
<xref target="I-D.ietf-ace-dtls-authorize">DTLS profile for ACE FC9202" section="3.3.2" sectionFormat="of" format="default">the DTLS profile for
</xref> with ACE</xref> with
the following exceptions. the following exceptions.
</t> </t>
<t> <t>
To use TLS 1.3 with pre-shared keys, the Client utilizes the PSK To use TLS 1.3 with pre-shared keys, the Client utilizes the PSK
key extension extension specified in <xref target="RFC8446" format="default"/> using the ke
specified in <xref target="RFC8446"></xref> using the key convey y conveyed in the "cnf"
ed in the "cnf" parameter parameter of the AS response.
of the AS response. The same key is bound to the access token The same key is bound to the access token
in the "cnf" claim. The Client can upload the token as specified in the "cnf" claim. The Client can upload the token, as specifie
in d in
<xref target="app-authzinfo"></xref> before initiating the hand <xref target="app-authzinfo" format="default"/>, before initiat
shake. ing the handshake.
When using a previously uploaded token, the Client MUST indicat When using a previously uploaded token, the Client <bcp14>MUST<
e during the handshake which previously uploaded access token /bcp14> indicate during the handshake which previously uploaded access token
it intends to use. To do so, it MUST create a "COSE_Key" or "J it intends to use. To do so, it <bcp14>MUST</bcp14> create a "
WK" structure with the "kid" COSE_Key" or "JWK" structure with the "kid"
that was conveyed in the "rs_cnf" claim in the token response f rom that was conveyed in the "rs_cnf" claim in the token response f rom
the AS and the key type "symmetric". This structure is then inc luded as the only element the AS and the key type "symmetric". This structure is then inc luded as the only element
in the "cnf" structure and the encoded value of that "cnf" stru cture used as a PSK identity in TLS. in the "cnf" structure and the encoded value of that "cnf" stru cture used as a PSK identity in TLS.
As an alternative to the access token upload, the Client can pr ovide the most recent access token, As an alternative to the access token upload, the Client can pr ovide the most recent access token,
JWT or CWT, as a PSK identity. JWT or CWT, as a PSK identity.
</t> </t>
<t> <t>
In contrast to <xref target="I-D.ietf-ace-dtls-authorize">DTLS p In contrast to the <xref target="RFC9202" format="default">DTLS
rofile for ACE</xref>, profile for ACE</xref>,
a Client MAY omit support for the cipher suites TLS_PSK_WITH_AES a Client <bcp14>MAY</bcp14> omit support for the cipher suites T
_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8. LS_PSK_WITH_AES_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8.
For TLS 1.2, however, a client MUST support TLS_ECDHE_PSK_WITH_A For TLS 1.2, however, a client <bcp14>MUST</bcp14> support TLS_E
ES_128_GCM_SHA256 for PSK (<xref target="RFC8442"></xref>) and TLS_ECDHE_ECDSA_W CDHE_PSK_WITH_AES_128_GCM_SHA256 for PSKs <xref target="RFC8442" format="default
ITH_AES_128_GCM_SHA256 for RPK (<xref target="RFC8422"></xref>), "/> and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for RPKs <xref target="RFC8422"
as recommended in <xref target="RFC7525"></xref> (and adjusted t format="default"/>,
o be a PSK cipher suite as appropriate). as recommended in <xref target="RFC9325" format="default"/> (and
</t> adjusted to be a PSK cipher suite as appropriate).
</section> </t>
</section> </section>
<section anchor="auth-ACE" title="Client Authentication over MQTT"> </section>
<section anchor="token-CONNECT" title="Transporting the Access Token <section anchor="auth-ACE" numbered="true" toc="default">
Inside the MQTT CONNECT"> <name>Client Authentication over MQTT</name>
<t> <section anchor="token-CONNECT" numbered="true" toc="default">
<name>Transporting the Access Token inside the MQTT CONNECT</name>
<t>
This section describes how the Client transports the token t o the Broker This section describes how the Client transports the token t o the Broker
inside the CONNECT packet. If this method is used, inside the CONNECT packet. If this method is used,
the Client TLS connection is expected to be anonymous, and t he Broker is the Client TLS connection is expected to be anonymous, and t he Broker is
authenticated during the TLS connection setup. authenticated during the TLS connection setup.
The approach described in this section is similar to an earl ier proposal The approach described in this section is similar to an earl ier proposal
by Fremantle, et al. <xref target="fremantle14"></xref>. by Fremantle, et al. <xref target="Fremantle14" format="def
</t> ault"/>.
<t> </t>
After sending the CONNECT, the Client MUST wait to receive t <t>
he CONNACK from After sending the CONNECT packet, the Client <bcp14>MUST</bc
p14> wait to receive the CONNACK packet from
the Broker. The only packets it is allowed to send are DISCO NNECT the Broker. The only packets it is allowed to send are DISCO NNECT
or AUTH that is in response to the Broker AUTH. or AUTH that are in response to the Broker AUTH.
Similarly, except for a DISCONNECT and AUTH response from th e Client, Similarly, except for a DISCONNECT and AUTH response from th e Client,
the Broker MUST NOT process any packets before sending a CON the Broker <bcp14>MUST NOT</bcp14> process any packets befor
NACK. e sending a CONNACK packet.
</t> </t>
<t> <t>
<xref target="mqtt5_connect_message"></xref> shows th <xref target="mqtt5_connect_message" format="default"
e structure of the /> shows the structure of the
MQTT CONNECT packet used in MQTT v5.0. MQTT CONNECT packet used in MQTT v5.0.
A CONNECT packet is composed of a fixed header, a variable h A CONNECT packet is composed of a Fixed Header, a Variable H
eader, and a payload. eader, and a Payload
The fixed header contains the Control Packet Type (CPT), Res The Fixed Header contains the Control Packet Type (CPT), Res
erved, and Remaining Length fields. erved, and Remaining Length fields.
Remaining Length is a Variable Byte Integer that represents The Remaining Length is a Variable Byte Integer that represe
the number of bytes nts the number of bytes
remaining within the current Control Packet, including data in the Variable Header and the Payload. remaining within the current Control Packet, including data in the Variable Header and the Payload.
The Variable Header contains the Protocol Name, Protocol Lev el, The Variable Header contains the Protocol Name, Protocol Lev el,
Connect Flags, Keep Alive, and Properties fields. Connect flags, Keep Alive, and Properties fields.
The Connect Flags in the variable header specify the propert The Connect flags in the Variable Header specify the propert
ies of the MQTT session. ies of the MQTT Session.
It also indicates the presence or absence of some fields in the Payload. It also indicates the presence or absence of some fields in the Payload.
The payload contains one or more encoded fields, namely a un ique Client The Payload contains one or more encoded fields, namely a un ique Client
Identifier for the Client, a Will Topic, Will Payload, User Name, and Password. Identifier for the Client, a Will Topic, Will Payload, User Name, and Password.
All but the Client Identifier can be omitted depending on th e flags in the Variable Header. All but the Client Identifier can be omitted depending on th e flags in the Variable Header.
The Client Identifier identifies the Client to the Broker, a nd therefore, The Client Identifier identifies the Client to the Broker an d, therefore,
is unique for each Client. It must be noted that the Client Identifier is an unauthenticated identifier is unique for each Client. It must be noted that the Client Identifier is an unauthenticated identifier
used within the MQTT protocol and so is not bound to the acc ess token. used within the MQTT protocol and so is not bound to the acc ess token.
</t> </t>
<figure align="center" anchor="mqtt5_connect_message" <figure anchor="mqtt5_connect_message">
title="MQTT v5 CONNECT Variable Header with Authenti <name>MQTT v5 CONNECT Variable Header with Authentication Method P
cation Method Property for ACE"> roperty for ACE</name>
<artwork align="left"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
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 | | (up to 4 bytes) |
| (Upto 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 | +---------------------------+
+---------------------------+ ]]></artwork>
]]></artwork> </figure>
</figure>
<t> <t>
The CONNECT flags are Username, Password, Will retain, Will QoS, Will Flag, The CONNECT flags are User Name, Password, Will Retain, Will QoS , Will Flag,
Clean Start, and Reserved. Clean Start, and Reserved.
<xref target="mqttv5_connect_flags"></xref> shows how the <xref target="mqttv5_connect_flags" format="default"/> shows how
flags MUST be set to use AUTH packets for authentication and aut the
horization, flags <bcp14>MUST</bcp14> be set to use AUTH packets for authent
i.e., the username and password flags MUST be set to 0. ication and authorization,
An MQTT v5.0 Broker MAY also support token transport using Usern i.e., the User Name Flag and Password Flag <bcp14>MUST</bcp14> b
ame and Password to provide e set to 0.
An MQTT v5.0 Broker <bcp14>MAY</bcp14> also support token transp
ort using the User Name and Password to provide
a security option for MQTT v3.1.1 Clients, as a security option for MQTT v3.1.1 Clients, as
described in <xref target="MQTTv311"></xref>. described in <xref target="MQTTv311" format="default"/>.
</t> </t>
<figure align="center" anchor="mqttv5_connect_flags" title="CONNECT <table anchor="mqttv5_connect_flags" align="center">
Flags for AUTH"> <name>CONNECT Flags for AUTH</name>
<artwork align="left"><![CDATA[ <thead>
+-----------------------------------------------------------+ <tr>
|User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.| <th>User Name Flag</th>
| Flag |Flag | | | |Start| | <th>Password Flag</th>
+-----------------------------------------------------------+ <th>Will Retain</th>
| 0 | 0 | X | X X | X | X | 0 | <th>Will QoS</th>
+-----------------------------------------------------------+ <th>Will Flag</th>
]]></artwork> <th>Clean Start</th>
</figure> <th>Reserved</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">0</td>
<td align="center">0</td>
<td align="center">X</td>
<td align="center">X X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">0</td>
</tr>
</tbody>
</table>
<t> <t>
The Will Flag indicates that a Will message needs to be sent. 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 <x The Client <bcp14>MAY</bcp14> set the Will Flag as desired (mark
ref target="mqttv5_connect_flags"></xref>). ed as "X" in <xref target="mqttv5_connect_flags" format="default"/>).
If the Will Flag is set to 1, the Broker MUST check that the to If the Will Flag is set to 1, the Broker <bcp14>MUST</bcp14> ch
ken eck 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). Filter is in the scope array).
The check is performed against the token scope The check is performed against the token scope
described in <xref target="scope"></xref>. If the Will authoriza described in <xref target="scope" format="default"/>. If the Wil
tion fails, the connection l authorization fails, the connection
is refused as described in <xref target="as_discovery"></xref>. is refused, as described in <xref target="as_discovery" format=
"default"/>.
If the Broker accepts the connection request, the Broker If the Broker accepts the connection request, the Broker
stores the Will message and publishes it when the Network Conne stores the Will Message and publishes it when the Network Conne
ction is closed according to Will QoS, and ction is closed according to Will QoS,
Will retain parameters and MQTT Will management rules. To av Will Retain parameters, and MQTT Will management rules. To a
oid publishing the Will Messages void publishing the Will Messages
in the case of temporary network disconnections, in the case of temporary network disconnections,
the Client specifies a Will Delay Interval in the Will Propertie s. the Client specifies a Will Delay Interval in the Will Propertie s.
<xref target="disconnections"></xref> explains how the Broker de als with the retained messages in further detail. <xref target="disconnections" format="default"/> explains how th e Broker deals with the retained messages in further detail.
</t> </t>
<t> <t>
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 Sess
session does not continue an existing session) ion does not continue an existing Session) by setting the Clean Start flag to 1
by setting the Clean Start Flag to 1 in the CONNECT in the CONNECT packet. In this profile, the Client <bcp14>SHOULD</bcp14> always
packet. In this profile, the Client SHOULD always start with a new Session. The Broker <bcp14>MAY</bcp14> also signal that it does
start with a clean session. The Broker MAY also signal that it d not support the continuation of an existing Session by setting the Session Expi
oes not support ry Interval to 0 in the CONNACK. If the Broker starts a new Session, the Broker
session continuation by setting Session Expiry Interval to 0 in <bcp14>MUST</bcp14> set the Session Present flag to 0 in the CONNACK packet to s
the CONNACK. ignal this to the Client.
If the Broker starts a clean session, the Broker MUST set the Se
ssion Present flag to 0 in the CONNACK packet to signal
this to the Client.
</t> </t>
<t> <t>
The Broker MAY support session continuation, e.g., if the Broker The Broker <bcp14>MAY</bcp14> support continuing an existing Sessi
requires it for QoS reasons. on, e.g., if the Broker requires it for QoS reasons. In this case, if a CONNECT
In this case, if a CONNECT packet is received with Clean Start s packet is received with Clean Start set to 0, and there is a Session associated
et to 0 and there is a Session associated with the Client Identifier, the Broker <bcp14>MUST</bcp14> resume communications
with the Client Identifier, the Broker MUST resume communication with the Client based on the state from the existing Session. In its response,
s with the Client based on the state from the the Broker <bcp14>MUST</bcp14> set the Session Present flag to 1 in the CONNACK
existing Session. In its response, the Broker MUST set the Sessi packet to signal the continuation of an existing Session to the Client. The Sess
on Present flag to 1 ion State stored by the Client and the Broker is described in <xref target="disc
in the CONNACK packet to signal session continuation to the Clie onnections" format="default"/>.
nt.
The session state stored by the Client and the Broker is describ
ed in <xref target="disconnections"></xref>.
</t> </t>
<t> <t>
When reconnecting to a Broker that supports session continuation When reconnecting to a Broker that supports continuing existing Ses
, sions, the Client <bcp14>MUST</bcp14> still provide a token in addition to using
the Client MUST still provide a token, in addition to the same Client Identifier and setting the Clean Start to 0. The Broker <bcp14>
using the same Client Identifier and MUST</bcp14> still perform PoP validation on the provided token. If the token ma
setting the Clean Start to 0. tches the stored state, the Broker <bcp14>MAY</bcp14> skip introspecting a token
The Broker MUST still perform PoP validation on the provided tok -by-reference and use the stored introspection result. The Broker <bcp14>MUST</b
en. cp14> also verify the Client is authorized to receive or send MQTT packets that
If the token matches the stored state, are pending transmission. When a Client connects with a long Session Expiry Inte
the Broker MAY skip introspecting a token-by-reference and use t rval, the Broker may need to maintain the Client's MQTT Session State after it d
he stored introspection result. isconnects for an extended period. Brokers <bcp14>SHOULD</bcp14> implement admin
The Broker MUST also verify the Client is authorized to receive istrative policies to limit misuse.
or send </t>
MQTT packets that are pending transmission. When a Client connec
ts with a long Session Expiry Interval, the
Broker may need to maintain the Client's MQTT session state aft
er it disconnects for an extended period.
Brokers SHOULD implement administrative policies to limit misuse
.
</t>
<t> <t>
Note that, according to the MQTT standard, the Broker uses the C Note that, according to the MQTT standard, the Broker uses the Clie
lient Identifier to identify the session state. nt Identifier to identify the Session State. In the case of a Client Identifier
In the case of a Client Identifier collision, collision, a Client may take over another Client's Session.
a Client may take over another Client's session. Given that the Broker <bcp14>MUST</bcp14> associate the Client with
Given that the Broker MUST associate the Client with a valid tok a valid token, a Client will only send or receive messages to its authorized to
en, a Client will only send or receive messages to its authorized topics. pics.
Therefore, while this issue is not expected to affect security, Therefore, while this issue is not expected to affect security,
it may affect QoS (i.e., PUBLISH or QoS messages saved for Clien t A may be delivered to a Client B). it may affect QoS (i.e., PUBLISH or QoS messages saved for Clien t A may be delivered to a Client B).
In addition, if this Client Identifier represents a Client alrea dy connected to the Broker, In addition, if this Client Identifier represents a Client alrea dy connected to the Broker,
the Broker sends a DISCONNECT packet to the existing Client with Reason Code of 0x8E (Session taken over) the Broker sends a DISCONNECT packet to the existing Client with reason code 0x8E (Session taken over)
and closes the connection to the Client. and closes the connection to the Client.
</t> </t>
</section> </section>
<section anchor="AUTH-method" title="Authentication Using AUTH Property" <section anchor="AUTH-method" numbered="true" toc="default">
> <name>Authentication Using the AUTH Property</name>
<t> <t><xref target="mqtt5_connect_message"/> shows the Authentication M
To use AUTH, ethod and Authentication Data fields when the client authenticates using the AUT
the Client MUST set the Authentication Method H property. The Client <bcp14>MUST</bcp14> set the Authentication Method as a pr
as a property of a CONNECT packet by using the property identifi operty of a CONNECT packet by using the property identifier 21 (0x15). This is f
er 21 (0x15). ollowed by a UTF-8-encoded string containing the name of the Authentication Meth
This is followed by a UTF-8 Encoded String containing the name o od, which <bcp14>MUST</bcp14> be set to "ace". If the Broker does not support th
f the is profile, it sends a CONNACK packet with reason code 0x8C (Bad authentication
Authentication Method, which MUST be set to "ace". If the Broker method).
does not support this profile, </t>
it sends a CONNACK with a Reason Code of 0x8C (Bad authenticatio
n method).
</t>
<t> <t>
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. which has a property identifier 22 (0x16) and is Binary Data.
Based on the Authentication Data, the Broker MUST support both o Based on the Authentication Data, the Broker <bcp14>MUST</bcp14>
ptions below: support both options below:
<list style="symbols">
<t>Proof-of-Possession using a challenge from the TLS sessio
n</t>
<t>Proof-of-Possession via Broker-generated challenge/respon
se</t>
</list>
</t> </t>
<section title="Proof-of-Possession Using a Challenge from the TLS sessi <ul spacing="normal">
on" anchor="pop_nonce"> <li>proof of possession using a challenge from the TLS session</li
<figure align="center" anchor="authdata_tlsexporter" title="Authenti >
cation Data for PoP Based on TLS Exporter Content"> <li>proof of possession via a Broker-generated challenge/response<
<artwork align="left"><![CDATA[ /li>
</ul>
<section anchor="pop_nonce" numbered="true" toc="default">
<name>Proof of Possession Using a Challenge from the TLS Session</
name>
<figure anchor="authdata_tlsexporter">
<name>Authentication Data for PoP Based on TLS Exporter Content<
/name>
<artwork align="left" name="" type="" alt=""><![CDATA[
+-----------------------------------------------------------------+ +-----------------------------------------------------------------+
|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) |
+-----------------------------------------------------------------+ +-----------------------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
For this option, the Authentication Data inside the Client's CON For this option, the Authentication Data inside the Client's CON
NECT MUST contain the two-byte integer token length, NECT packet <bcp14>MUST</bcp14> contain the two-byte integer token length,
the token, and the keyed message digest (MAC) or the Client sign ature (as shown in the token, and the keyed message digest (MAC) or the Client sign ature (as shown in
<xref target="authdata_tlsexporter"></xref>). <xref target="authdata_tlsexporter" format="default"/>).
The Proof-of-Possession key in the token is used to calculate The Proof-of-Possession key in the token is used to calculate
the keyed message digest (MAC) or the Client signature the keyed message digest (MAC) or the Client signature
based on the content obtained from the TLS exporter (<xref targe based on the content obtained from the TLS exporter (<xref targe
t="RFC5705"></xref> t="RFC5705" format="default"/>
for TLS 1.2, and Section 7.5 of <xref target="RFC8446"></xref>) for TLS 1.2 and <xref target="RFC8446" section="7.5" sectionForm
for TLS 1.3. at="of" format="default"/> for TLS 1.3).
This content is exported from the TLS session using the exporter label "EXPORTER-ACE-MQTT-Sign-Challenge", This content is exported from the TLS session using the exporter label "EXPORTER-ACE-MQTT-Sign-Challenge",
an empty context, and length of 32 bytes. an empty context, and a length of 32 bytes.
The token is also validated as described in <xref target="token The token is also validated, as described in <xref target="toke
_validation"></xref>, n_validation" format="default"/>,
and the Broker responds with a CONNACK with the appropriate resp and the Broker responds with a CONNACK packet with the appropria
onse code. te response code.
The Client cannot reauthenticate using this method during the sa The Client cannot reauthenticate using this method during the sa
me TLS session (see <xref target="reauthentication"></xref>). me TLS session (see <xref target="reauthentication" format="default"/>).
</t> </t>
</section> </section>
<section title="Proof-of-Possession via Broker-generated Challenge/Respo <section anchor="pop_challenge" numbered="true" toc="default">
nse" anchor="pop_challenge"> <name>Proof of Possession via Broker-generated Challenge/Response<
<figure align="center" anchor="authdata_challenge_client" title="Aut /name>
hentication Data to Initiate PoP Based on Challenge/Response"> <figure anchor="authdata_challenge_client">
<artwork align="left"><![CDATA[ <name>Authentication Data to Initiate PoP Based on Challenge/Res
ponse</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
+------------------------------------+ +------------------------------------+
|Authentication|Token Length|Token | |Authentication|Token Length|Token |
|Data Length | | | |Data Length | | |
+------------------------------------+ +------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<figure align="center" anchor="authdata_challenge_broker_challenge" tit <figure anchor="authdata_challenge_broker_challenge">
le="Authentication Data for Broker Challenge"> <name>Authentication Data for Broker Challenge</name>
<artwork align="left"><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
+--------------------------+ +--------------------------+
|Authentication|RS Nonce | |Authentication|RS Nonce |
|Data Length |(8 bytes) | |Data Length |(8 bytes) |
+--------------------------+ +--------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
For this option, the Broker follows a Broker-generated challe nge/response protocol. For this option, the Broker follows a Broker-generated challe nge/response protocol.
If the Authentication Data inside the Client's CONNECT contains only the two-byte integer token length and If the Authentication Data inside the Client's CONNECT contains only the two-byte integer token length and
the token (as shown in <xref target="authdata_challenge_client"> the token (as shown in <xref target="authdata_challenge_client"
</xref>), format="default"/>),
the Broker MUST respond with an AUTH packet, the Broker <bcp14>MUST</bcp14> respond with an AUTH packet
with the Authenticate Reason Code set to 0x18 (Continue Authenti with the authenticated reason code set to 0x18 (Continue Authent
cation). ication).
The Broker also uses this method if the Authentication Data does not The Broker also uses this method if the Authentication Data does not
contain a token, but the Broker has a token stored for the conne cting Client. contain a token, but the Broker has a token stored for the conne cting Client.
</t> </t>
<t> <t>
The Broker continues authentication using an AUTH packet that co ntains the Authentication Method The Broker continues authentication using an AUTH packet that co ntains the Authentication Method
and the Authentication Data. The Authentication Method MUST be s and the Authentication Data. The Authentication Method <bcp14>MU
et to "ace", and the Authentication Data MUST NOT be empty and ST</bcp14> be set to "ace", and the Authentication Data <bcp14>MUST NOT</bcp14>
MUST contain an 8-byte RS nonce as a challenge for the Client (< be empty and
xref target="authdata_challenge_broker_challenge"></xref>). <bcp14>MUST</bcp14> contain an 8-byte RS nonce as a challenge fo
</t> r the Client (<xref target="authdata_challenge_broker_challenge" format="default
<figure align="center" anchor="authdata_challenge_client_response" title="Authen "/>).
tication Data for Client Challenge Response"> </t>
<artwork align="left"><![CDATA[ <figure anchor="authdata_challenge_client_response">
<name>Authentication Data for the Client Challenge Response</nam
e>
<artwork align="left" name="" type="" alt=""><![CDATA[
+---------------------------------------------------------+ +---------------------------------------------------------+
|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)|
+---------------------------------------------------------+ +---------------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
The Client responds to this with an AUTH packet The Client responds to this with an AUTH packet
with a reason code 0x18 (Continue Authentication). with reason code 0x18 (Continue Authentication).
Similarly, the Client packet sets the Authentication Method to " ace". Similarly, the Client packet sets the Authentication Method to " ace".
The Authentication Data in the Client's response is formatted as shown The Authentication Data in the Client's response is formatted as shown
in <xref target="authdata_challenge_client_response"></xref> and includes the 8-byte Client nonce, and in <xref target="authdata_challenge_client_response" format="def ault"/> and includes the 8-byte Client nonce and
the signature or MAC computed over the RS nonce concatenated wit h the Client nonce the signature or MAC computed over the RS nonce concatenated wit h the Client nonce
using PoP key in the token. using PoP key in the token.
</t> </t>
<t> <t>
Next, the token is validated as described in <xref target="toke Next, the token is validated as described in <xref target="toke
n_validation"></xref>. n_validation" format="default"/>.
The success case is illustrated in <xref target="pop_challenge_r The success case is illustrated in <xref target="pop_challenge_r
esponse"></xref>. esponse" format="default"/>.
The Client MAY also re-authenticate using this challenge-respons The Client <bcp14>MAY</bcp14> also reauthenticate using this cha
e flow, llenge-response flow,
as described in <xref target="reauthentication"></xref>. as described in <xref target="reauthentication" format="default"
</t> />.
<figure align="center" anchor="pop_challenge_response" title="Po </t>
P Challenge/Response Flow - Success"> <figure anchor="pop_challenge_response">
<artwork align="left"><![CDATA[ <name>PoP Challenge/Response Flow - Success</name>
Client Broker <artwork align="center" name="" type="" alt=""><![CDATA[
| | Client Broker
|<===========>| TLS connection setup | |
| | |<===========>| TLS connection setup
| | | |
+------------>| CONNECT with Authentication Data | |
| | contains only token +------------>| CONNECT with Authentication Data
| | | | contains only token
<-------------+ AUTH 0x18 (Cont. Authentication) | |
| | 8-byte RS nonce as challenge <-------------+ AUTH 0x18 (Cont. Authentication)
| | | | 8-byte RS nonce as challenge
|------------>| AUTH 0x18 (Cont. Authentication) | |
| | 8-byte Client nonce + signature/MAC |------------>| AUTH 0x18 (Cont. Authentication)
| | | | 8-byte Client nonce + signature/MAC
| |---+ Token validation | |
| | | (may involve introspection) | |---+ Token validation
| |<--+ | | | (may involve introspection)
| | | |<--+
|<------------+ CONNACK 0x00 (Success) | |
|<------------+ CONNACK 0x00 (Success)
]]></artwork> ]]></artwork>
</figure> </figure>
</section>
</section>
</section> </section>
<section title="Broker Token Validation" anchor="token_validation"> </section>
<t> </section>
The Broker MUST verify the validity of the token either loca <section anchor="token_validation" numbered="true" toc="default">
lly <name>Broker Token Validation</name>
(e.g., in the case of a self-contained token) or MAY send a <t>
request to the The Broker <bcp14>MUST</bcp14> verify the validity of the to
introspection endpoint of the AS (as described for HTTP-base ken either locally
d interactions in Section 5.9 of (e.g., in the case of a self-contained token) or <bcp14>MAY<
the <xref target="I-D.ietf-ace-oauth-authz">ACE framework</x /bcp14> send a request to the
ref>). introspection endpoint of the AS (as described for HTTP-base
The Broker MUST verify the claims in the access token accord d interactions in
ing to the rules set in <xref target="RFC9200" format="default" sectionFormat="of" s
Section 5.10.1.1 of the <xref target="I-D.ietf-ace-oauth-aut ection="5.9">the ACE framework</xref>).
hz">ACE framework</xref>. The Broker <bcp14>MUST</bcp14> verify the claims in the acce
</t> ss token according to the rules set in
<t> <xref target="RFC9200" format="default" sectionFormat="of" s
ection="5.10.1.1">the ACE framework</xref>.
</t>
<t>
To authenticate the Client, the Broker validates the signatu re or the MAC, depending on how the PoP protocol is implemented. To authenticate the Client, the Broker validates the signatu re or the MAC, depending on how the PoP protocol is implemented.
For self-contained tokens, the Broker MUST process the secur For self-contained tokens, the Broker <bcp14>MUST</bcp14> pr
ity protection of the token first, as specified by the respective token format, ocess the security protection of the token first, as specified by the respective
i.e. a CWT token uses COSE, while a JWT token uses JOSE. Fo token format,
r a token-by-reference, the i.e., a CWT uses COSE, while a JWT uses JOSE. For a token-b
Broker uses the "cnf" structure returned as a result of toke y-reference, the
n introspection as specified in <xref target="RFC7519"></xref>. Broker uses the "cnf" structure returned as a result of toke
HS256 (HMAC-SHA-256) <xref target="RFC6234"></xref> and Ed25 n introspection, as specified in <xref target="RFC7519" format="default"/>.
519 <xref target="RFC8032"></xref> are mandatory to implement HMAC-SHA-256 (HS256) <xref target="RFC6234" format="default"
for the Broker. The Client MUST implement at least one of th /> and Ed25519 <xref target="RFC8032" format="default"/> are mandatory to implem
em depending on the choice of symmetric or asymmetric validation. ent
Validation of the signature or MAC MUST fail if the signatur for the Broker. The Client <bcp14>MUST</bcp14> implement at
e algorithm is set to "none", least one of them depending on the choice of symmetric or asymmetric validation.
when the key used for the signature algorithm cannot be dete Validation of the signature or MAC <bcp14>MUST</bcp14> fail
rmined, or if the signature algorithm is set to "none"
when the key used for the signature algorithm cannot be dete
rmined or
the computed and received signature/MAC do not match. the computed and received signature/MAC do not match.
</t> </t>
<t> <t>
The Broker MUST check if the access token is still valid, The Broker <bcp14>MUST</bcp14> check if the access token is sti
ll valid,
if it is the intended destination (i.e., the audience) if it is the intended destination (i.e., the audience)
of the token, and if the token was issued by an authorized of the token, and if the token was issued by an authorized
authorization server. If the Client is using TLS RPK mode Authorization Server. If the Client is using TLS RPK mode
to authenticate to the Broker, the AS constructs the access to ken to authenticate to the Broker, the AS constructs the access to ken
so that the Broker can associate the access token with the so that the Broker can associate the access token with the
Client's public key. The "cnf" claim MUST contain either the C lient's RPK or, Client's public key. The "cnf" claim <bcp14>MUST</bcp14> conta in either the Client's RPK or,
if the key is already known by the Broker (e.g., from previous communication), if the key is already known by the Broker (e.g., from previous communication),
a reference to it. a reference to it.
</t> </t>
</section> </section>
</section> </section>
<section title="Token Scope and Authorization" anchor="scope"> <section anchor="scope" numbered="true" toc="default">
<t> <name>Token Scope and Authorization</name>
<t>
The scope field contains the publish and subscribe permissions for t he Client. The scope field contains the publish and subscribe permissions for t he Client.
Therefore, the token or its introspection result MUST be cached Therefore, the token or its introspection result <bcp14>MUST</bcp14> be cached
to allow a Client's future PUBLISH and SUBSCRIBE messages. to allow a Client's future PUBLISH and SUBSCRIBE messages.
During the CONNECT, if the Will Flag is set to 1, the Broker MU During the CONNECT, if the Will Flag is set to 1, the Broker <b
ST also authorize cp14>MUST</bcp14> also authorize
the publication of the Will Topic and message using the token's the publication of the Will Topic and Will Message using the tok
scope field. en's scope field.
The Broker uses the scope to match against the Topic Name in a PUBLI SH packet The Broker uses the scope to match against the Topic Name in a PUBLI SH packet
(including Will Topic in the CONNECT) or a Topic Filter in a SUBSCRI BE packet. (including Will Topic in the CONNECT) or a Topic Filter in a SUBSCRI BE packet.
</t> </t>
<t> <t>
The scope in the token is a single value. For a JWT, the single scop e The scope in the token is a single value. For a JWT, the single scop e
is base64url encoded string with any padding characters removed, whi ch has an internal structure of a JSON array. is a base64url-encoded string with any padding characters removed, w hich has an internal structure of a JSON array.
For a CWT, this information is represented in CBOR. For a CWT, this information is represented in CBOR.
The internal structure follows the <xref target="I-D.ietf-ace-aif">A uthorization Information The internal structure follows the <xref target="RFC9237" format="de fault">Authorization Information
Format (AIF) for ACE</xref>. Format (AIF) for ACE</xref>.
Using the Concise Data Definition Language (CDDL) <xref target="RFC8 610"></xref>, Using the Concise Data Definition Language (CDDL) <xref target="RFC8 610" format="default"/>,
the specific data model for MQTT is: the specific data model for MQTT is:
<figure anchor="MQTTaif" align="left" title="AIF-MQTT data model"> </t>
<artwork type="CDDL" name="" align="left" alt=""><![CDATA[ <figure anchor="MQTTaif">
<name>AIF-MQTT Data Model</name>
<sourcecode type="cddl"><![CDATA[
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"
]]></artwork> ]]></sourcecode>
</figure> </figure>
Topic filters are implemented according to <t>
Section 4.7 of <xref target="MQTT-OASIS-Standard-v5">MQTT v5.0 Topic Filters are implemented according to Section 4.7 of the
- the OASIS Standard</xref>. <xref target="MQTT-OASIS-Standard-v5" format="default">MQTT v5.0 OAS
IS Standard</xref>.
By default, Wildcard Subscriptions are supported, and so, By default, Wildcard Subscriptions are supported, and so,
the topic filter may include special wildcard characters. the Topic Filter may include special wildcard characters.
The multi-level wildcard, "#", matches any number of levels within a topic, and the single-level wildcard, "+", The multi-level wildcard, "#", matches any number of levels within a topic, and the single-level wildcard, "+",
matches one topic level. matches one topic level.
The Broker MAY signal in the CONNACK explicitly whether wildcard sub scriptions are supported The Broker <bcp14>MAY</bcp14> signal in the CONNACK explicitly wheth er Wildcard Subscriptions are supported
by returning a CONNACK property "Wildcard Subscription Available". by returning a CONNACK property "Wildcard Subscription Available".
A value of 0 means that Wildcard Subscriptions are not supported. A value of 0 means that Wildcard Subscriptions are not supported.
A value of 1 means Wildcard Subscriptions are supported. A value of 1 means Wildcard Subscriptions are supported.
</t> </t>
<t> Following this model, an example scope may contain: <t> Following this model, an example scope may contain:
<figure anchor="MQTTaifex" align="left" title="Example scope"> </t>
<artwork type="" name="" align="left" alt=""><![CDATA[ <figure anchor="MQTTaifex">
<name>Example Scope</name>
<sourcecode type="json"><![CDATA[
[["topic1",["pub","sub"]],["topic2/#",["pub"]],["+/topic3",["sub"]]] [["topic1",["pub","sub"]],["topic2/#",["pub"]],["+/topic3",["sub"]]]
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>
This access token gives publish ("pub") and subscribe ("sub") permis sions to the "topic1", This access token gives publish ("pub") and subscribe ("sub") permis sions to the "topic1",
publish permission to all the subtopics of "topic2", publish permission to all the subtopics of "topic2",
and subscribe permission to all "topic3", skipping one level. and subscribe permission to all "topic3", skipping one level.
</t> </t>
<t> <t>
If the scope is empty, the Broker records If the scope is empty, the Broker records
no permissions for the Client for any topic. In this case, the Clien t no permissions for the Client for any topic. In this case, the Clien t
is not able to publish or subscribe to any protected topics. is not able to publish or subscribe to any protected topics.
The non-empty scope is used to authorize the Will Topic, if provided , in the CONNECT packet, The non-empty scope is used to authorize the Will Topic, if provided , in the CONNECT packet,
during connection setup, and if the connection request during connection setup and, if the connection request
succeeds, the Topic Names or Topic Filters requested in the future P UBLISH and SUBSCRIBE packets. succeeds, the Topic Names or Topic Filters requested in the future P UBLISH and SUBSCRIBE packets.
For the authorization to succeed, the Broker MUST verify that the to pic name or filter in question is either For the authorization to succeed, the Broker <bcp14>MUST</bcp14> ver ify that the Topic Name or Topic Filter in question is either
an exact match to or a subset of at least one "topic_filter" in the scope. an exact match to or a subset of at least one "topic_filter" in the scope.
</t> </t>
</section> </section>
<section title="Broker Response to Client Connection Request"> <section numbered="true" toc="default">
<t> <name>Broker Response to Client Connection Request</name>
<t>
Based on the validation result (obtained either via local inspe ction or using the introspection Based on the validation result (obtained either via local inspe ction or using the introspection
interface of the AS), the Broker MUST send a CONNACK packet to t interface of the AS), the Broker <bcp14>MUST</bcp14> send a CONN
he Client. ACK packet to the Client.
</t> </t>
<section title="Unauthorized Request and the Optional Authoriz <section anchor="as_discovery" numbered="true" toc="default">
ation Server Discovery" anchor="as_discovery"> <name>Unauthorized Request and the Optional Authorization Server Disco
<t> Authentication can fail for the following reasons: very</name>
<list style="symbols"> <t> Authentication can fail for the following reasons:
<t> If the Client does not provide a valid token,</t> </t>
<t> the Client omits the Authentication Data field and th <ul spacing="normal">
e Broker <li>if the Client does not provide a valid token,</li>
has no token stored for the Client,</t> <li>the Client omits the Authentication Data field and the Broker
<t> the token or Authentication data are malformed, or </ has no token stored for the Client,</li>
t> <li>the token or Authentication data are malformed, or </li>
<t> if the Will flag is set, the authorization checks for <li>if the Will Flag is set, the authorization checks for
the Will topic fails.</t> the Will Topic fails.</li>
</list> </ul>
<t>
The Broker responds with the CONNACK reason code 0x87 (Not A uthorized) or any other applicable The Broker responds with the CONNACK reason code 0x87 (Not A uthorized) or any other applicable
reason code. reason code.
</t> </t>
<t> <t>
The Broker MAY also trigger AS discovery and include a U The Broker <bcp14>MAY</bcp14> also trigger AS discovery
ser Property (identified as property type 38 (0x26)) and include a User Property (identified as property type 38 (0x26))
in the CONNACK for the AS Request Creation Hints. in the CONNACK for the AS Request Creation Hints.
The User Property is a UTF-8 string pair, composed of a name and a value. The name The User Property is a UTF-8 string pair, composed of a name and a value. The name
of the User Property MUST be set to "ace_as_hint". The v of the User Property <bcp14>MUST</bcp14> be set to "ace_
alue of the user property as_hint". The value of the User Property
is a UTF-8 encoded JSON object containing the mandatory is a UTF-8-encoded JSON object containing the mandatory
"AS" parameter, "AS" parameter
and the optional parameters "audience", "kid", "cnonce" and the optional parameters "audience", "kid", "cnonce"
, and "scope" as defined , and "scope", as defined
in Section 5.3 in <xref target="RFC9200" format="default" sectionForma
of the <xref target="I-D.ietf-ace-oauth-authz">ACE frame t="of" section="5.3">the ACE framework</xref>.
work</xref>. </t>
</t> </section>
</section> <section anchor="auth_success" numbered="true" toc="default">
<section title="Authorization Success" anchor="auth_success"> <name>Authorization Success</name>
<t> <t>
On success, the reason code of the CONNACK is 0x00 (Success) On success, the reason code of the CONNACK is 0x00 (Success).
. If the Broker starts a new Session, it <bcp14>MUST</bcp14> also set S
If the Broker starts a new session, it MUST also set Session ession Present to 0 in the CONNACK packet to signal a new Session to the Client.
Present to 0 Otherwise, it <bcp14>MUST</bcp14> set Session Present to 1.
in the CONNACK packet to signal a clean session to the Clien </t>
t. Otherwise, <t>
it MUST set Session Present to 1. Having accepted the connection, the Broker <bcp14>MUST</bcp1
</t> 4> be prepared to store the token
<t>
Having accepted the connection, the Broker MUST be prepared
to store the token
during the connection and after disconnection for future use . during the connection and after disconnection for future use .
If the token is not self-contained and the Broker uses token If the token is not self-contained and the Broker uses token
introspection, it MAY cache the validation result to authori ze introspection, it <bcp14>MAY</bcp14> cache the validation re sult to authorize
the subsequent PUBLISH and SUBSCRIBE packets. the subsequent PUBLISH and SUBSCRIBE packets.
PUBLISH and SUBSCRIBE packets, which are sent after a connec tion PUBLISH and SUBSCRIBE packets, which are sent after a connec tion
setup, do not contain access tokens. If the introspection re sult setup, do not contain access tokens. If the introspection re sult
is not cached, the Broker needs to introspect the saved toke n for is not cached, the Broker needs to introspect the saved toke n for
each request. The Broker SHOULD also use a cache timeout to each request. The Broker <bcp14>SHOULD</bcp14> also use a ca
introspect che timeout to introspect
tokens regularly. The timeout value is application-specific tokens regularly. The timeout value is specific to the appli
and should be chosen cation and should be chosen
to reduce the risk of using stale introspection responses. to reduce the risk of using stale introspection responses.
</t> </t>
</section>
</section>
</section> </section>
<section title="Authorizing PUBLISH and SUBSCRIBE Packets" anchor="pubsub_au </section>
thorisation"> </section>
<section anchor="pubsub_authorization" numbered="true" toc="default">
<t> <name>Authorizing PUBLISH and SUBSCRIBE Packets</name>
<t>
Using the cached token or its introspection result, the Broker uses the scope field Using the cached token or its introspection result, the Broker uses the scope field
to match against the Topic Name in a PUBLISH packet, or a Topic Filter i to match against the Topic Name in a PUBLISH packet or a Topic Filter in
n a SUBSCRIBE packet. a SUBSCRIBE packet.
</t> </t>
<section anchor="publish-packets" numbered="true" toc="default">
<section title="PUBLISH Packets from the Publisher Client to the Broker" <name>PUBLISH Packets from the Publisher Client to the Broker</name>
> <t>
<t> On receiving the PUBLISH packet, the Broker <bcp14>MUST</bcp14>
On receiving the PUBLISH packet, the Broker MUST use the type of use the type of
packet (i.e., PUBLISH) and the Topic name in the packet header t packet (i.e., PUBLISH) and the Topic Name in the packet header t
o match against the o match against the
scope array items in the cached token or its introspection resul t. scope array items in the cached token or its introspection resul t.
Following the example in <xref target="scope"></xref>, the Clien t sending a PUBLISH for "topic2/a" would be Following the example in <xref target="scope" format="default"/> , the Client sending a PUBLISH packet for "topic2/a" would be
allowed, as the scope array includes the ["topic2/#",["pub"]]. allowed, as the scope array includes the ["topic2/#",["pub"]].
</t> </t>
<t> <t>
If the Client is allowed to publish to the topic, If the Client is allowed to publish to the topic,
the Broker publishes the message to all valid subscribers of the topic. the Broker publishes the message to all valid subscribers of the topic.
In the case of an authorization failure, the Broker MUST r eturn an error if In the case of an authorization failure, the Broker <bcp14 >MUST</bcp14> return an error if
the Client has set the QoS level of the PUBLISH packet to greate r than or equal to 1. the Client has set the QoS level of the PUBLISH packet to greate r than or equal to 1.
Depending on the QoS level, the Broker responds with either a PU BACK or PUBREC packet with reason code Depending on the QoS level, the Broker responds with either a PU BACK or PUBREC packet with reason code
0x87 (Not authorized). 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 as descri the Client <bcp14>MAY</bcp14> reauthenticate by providing a new
bed in <xref target="reauthentication"></xref>. token, as described in <xref target="reauthentication" format="default"/>.
</t> </t>
<t> <t>
For QoS level 0, the Broker sends a DISCONNECT with reason code For QoS level 0, the Broker sends a DISCONNECT packet with reaso
0x87 (Not authorized) n code 0x87 (Not authorized)
and closes the Network Connection. Note that the server-side DI SCONNECT is a new feature of MQTT v5.0 (in MQTT v3.1.1, and closes the Network Connection. Note that the server-side DI SCONNECT is a new feature of MQTT v5.0 (in MQTT v3.1.1,
the server needs to drop the connection). the server needs to drop the connection).
</t> </t>
<t> For all QoS levels, the Broker MAY return 0x80 Unspecified error <t> For all QoS levels, the Broker <bcp14>MAY</bcp14> return 0x80 (Unspe
if they do not want to leak the topic names to unauthorized clients. cified error) if they do not want to leak the Topic Names to unauthorized client
</t> s.
</section> </t>
<section title="PUBLISH Packets from the Broker to the Subscriber Client </section>
s"> <section numbered="true" toc="default">
<t> <name>PUBLISH Packets from the Broker to the Subscriber Clients</name>
To forward PUBLISH packets to the subscribing Clients, th <t>
e Broker identifies all the To forward PUBLISH packets to the subscribing Clients, the Broker ident
subscribers that have valid matching topic subscriptions to the ifies all the subscribers that have valid matching Topic Subscriptions to the To
Topic name of the PUBLISH pic Name of the PUBLISH packet (i.e., the tokens are valid, and token scopes all
packet (i.e., the tokens are valid, and ow a Subscription to this particular Topic Name).
token scopes allow a subscription to this particular Topic name)
.
The Broker forwards the PUBLISH packet to all the valid The Broker forwards the PUBLISH packet to all the valid
subscribers. subscribers.
</t> </t>
<t> <t>
The Broker MUST NOT forward messages to unauthorized subscribers The Broker <bcp14>MUST NOT</bcp14> forward messages to unauthori
. zed subscribers.
To avoid silently dropping messages, the Broker MUST close the n To avoid silently dropping messages, the Broker <bcp14>MUST</bcp
etwork connection and 14> close the Network Connection and
SHOULD inform the affected subscribers. <bcp14>SHOULD</bcp14> inform the affected subscribers.
The only way to inform a client, in this case, would be sending In this case, the only way to inform a client would be sending a
a DISCONNECT packet. DISCONNECT packet.
Therefore, the Broker SHOULD send a DISCONNECT packet with the r Therefore, the Broker <bcp14>SHOULD</bcp14> send a DISCONNECT pa
eason code 0x87 (Not authorized) cket with reason code 0x87 (Not authorized)
before closing the network connection to these clients. before closing the Network Connection to these clients.
</t> </t>
</section> </section>
<section title="Authorizing SUBSCRIBE Packets"> <section numbered="true" toc="default">
<name>Authorizing SUBSCRIBE Packets</name>
<t> <t>
In MQTT, a SUBSCRIBE packet is sent from a Client to the Broker In MQTT, a SUBSCRIBE packet is sent from a Client to the Broker
to create one or more subscriptions to create one or more Subscriptions
to one or more topics. to one or more topics.
The SUBSCRIBE packet may contain multiple Topic Filters. The SUBSCRIBE packet may contain multiple Topic Filters.
The Topic Filters may include wildcard characters. The Topic Filters may include wildcard characters.
</t> </t>
<t> <t>
On receiving the SUBSCRIBE packet, the Broker MUST use the type of p acket (i.e., On receiving the SUBSCRIBE packet, the Broker <bcp14>MUST</bcp14> us e the type of packet (i.e.,
SUBSCRIBE) and the Topic Filter in the packet header to match SUBSCRIBE) and the Topic Filter in the packet header to match
against the scope field of the stored token or introspection result. against the scope field of the stored token or introspection result.
The Topic Filters MUST be an exact match to or be a subset of at lea The Topic Filters <bcp14>MUST</bcp14> be an exact match to or be a s
st one of the "topic_filter" fields ubset of at least one of the "topic_filter" fields
in the scope array found in the Client's token. For example, in the scope array found in the Client's token. For example, if the
if the Client sends a subscription request for topic "a/b/*", Client sends a SUBSCRIBE request for topic "a/b/*" and has a token that permits
and has a token that permits "a/*", this is a valid subscription re "a/*", this is a valid SUBSCRIBE request, as "a/b/*" is a subset of "a/*". (The
quest, as "a/b/*" is process is similar to a Broker matching the Topic Name in a PUBLISH packet again
a subset of "a/*". (The process is similar to a Broker matching the st the Subscriptions known to the Server.)
Topic Name
in a PUBLISH packet against the Subscriptions known to the Server.)
</t> </t>
<t> <t>
As a response to the SUBSCRIBE packet, the Broker issues a SUBACK. As a response to the SUBSCRIBE packet, the Broker issues a SUBACK pa cket.
For each Topic Filter, For each Topic Filter,
the SUBACK packet includes a return code matching the QoS level the SUBACK packet includes a return code matching the QoS level
for the corresponding Topic Filter. In the case of failure, the retu rn code is 0x87, for the corresponding Topic Filter. In the case of failure, the retu rn code is 0x87,
indicating that the Client is not authorized. The Broker MAY return indicating that the Client is not authorized. The Broker <bcp14>MAY<
0x80 Unspecified error /bcp14> return 0x80 (Unspecified error)
if they do not want to leak the topic names to unauthorized clients. if they do not want to leak the Topic Names to unauthorized clients.
A reason code is returned for each Topic Filter. A reason code is returned for each Topic Filter.
Therefore, the Client may receive success codes for a subset of its Topic Filters while being Therefore, the Client may receive success codes for a subset of its Topic Filters while being
unauthorized for the rest. unauthorized for the rest.
</t> </t>
</section>
</section> </section>
</section> <section anchor="reauthentication" numbered="true" toc="default">
<section anchor="reauthentication" title="Token Expiration, Update, and Reau <name>Token Expiration, Update, and Reauthentication</name>
thentication"> <t>
<t> The Broker <bcp14>MUST</bcp14> check for token expiration whenever a
The Broker MUST check for token expiration whenever a CONNECT, PUBLI CONNECT, PUBLISH, or SUBSCRIBE packet is received
SH, or SUBSCRIBE is received or sent.
or sent. The Broker SHOULD check for token expiration on receiving a The Broker <bcp14>SHOULD</bcp14> check for token expiration on receiv
PINGREQUEST. ing a PINGREQ packet.
The Broker MAY also check for token expiration periodically, e.g., e The Broker <bcp14>MAY</bcp14> also check for token expiration period
very hour. This may allow ically, e.g., every hour. This may allow
for early detection of a token expiry. for early detection of a token expiry.
</t> </t>
<t> <t>
The token expiration is checked by checking the "exp" claim of a JWT or introspection response The token expiration is checked by checking the "exp" claim of a JWT or introspection response
or via performing an or via performing an
introspection request with the AS as described in Section 5.9 of the introspection request with the AS, as described in <xref target="RFC
<xref 9200" format="default" sectionFormat="of" section="5.9">the ACE framework</xref>
target="I-D.ietf-ace-oauth-authz">ACE framework</xref>. .
Token expirations may trigger the Broker to send PUBACK, SUBACK and Token expirations may trigger the Broker to send PUBACK, SUBACK, and
DISCONNECT packets with return code DISCONNECT packets with the return code
set to "Not authorized". After sending a DISCONNECT, the Network Con set to "Not authorized". After sending a DISCONNECT packet, the Netw
nection is closed, and ork Connection is closed, and
no more messages can be sent. no more messages can be sent.
</t> </t>
<t> <t>
The Client MAY reauthenticate as a response to the The Client <bcp14>MAY</bcp14> reauthenticate a response to
PUBACK and SUBACK that signal loss of authorization. PUBACK and SUBACK, which signal loss of authorization.
The Clients MAY also proactively update their tokens, i.e., before The Clients <bcp14>MAY</bcp14> also proactively update their tokens,
i.e., before
they receive a packet with a "Not authorized" return code. they receive a packet with a "Not authorized" return code.
To start reauthentication, the Client MUST send an AUTH packet with To start reauthentication, the Client <bcp14>MUST</bcp14> send an AU
the reason code TH packet with reason code
0x19 (Re-authentication). The Client MUST 0x19 (Reauthentication). The Client <bcp14>MUST</bcp14>
set the Authentication Method as "ace" and transport the new token in the Authentication Data. set the Authentication Method as "ace" and transport the new token in the Authentication Data.
If re-authenticating during the current TLS session, If reauthenticating during the current TLS session,
the Client MUST NOT use the method described in <xref target ="pop_n the Client <bcp14>MUST NOT</bcp14> use the method described in <xref
once"></xref>, target="pop_nonce" format="default"/>, i.e.,
Proof-of-Possession using a challenge from the TLS session, to avoid proof of possession using a challenge from the TLS session, to avoid
re-using the same challenge value from the TLS-Exporter. reusing the same challenge value from the TLS-Exporter.
Note that this means that servers will either need to record in the session ticket or database entry whether Note that this means that servers will either need to record in the session ticket or database entry whether
the TLS-Exporter-derived challenge was used, or always deny use of the TLS-Exporter-derived challenge the TLS-Exporter-derived challenge was used or always deny use of t he TLS-Exporter-derived challenge
for resumed sessions. In TLS 1.3, the resumed connection would ha ve a new exporter value, for resumed sessions. In TLS 1.3, the resumed connection would ha ve a new exporter value,
but the requirement is phrased this way for simplicity. but the requirement is phrased this way for simplicity.
For re-authentications in the same TLS-session, the Client MUST use For reauthentications in the same TLS-session, the Client <bcp14>MU
the challenge-response PoP as defined ST</bcp14> use the challenge-response PoP, as defined
in <xref target="pop_challenge"></xref>. in <xref target="pop_challenge" format="default"/>.
The Broker accepts reauthentication requests if the Client has alrea dy submitted The Broker accepts reauthentication requests if the Client has alrea dy 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. Otherwise, the Broker <bcp14>MUST</bcp14> deny the request.
If the reauthentication fails, the Broker If the reauthentication fails, the Broker
MUST send a DISCONNECT with the reason code 0x87 (Not Authori <bcp14>MUST</bcp14> send a DISCONNECT packet with reason code
zed). 0x87 (Not Authorized).
</t> </t>
</section> </section>
<section title="Handling Disconnections and Retained Messages" anchor="disco <section anchor="disconnections" numbered="true" toc="default">
nnections"> <name>Handling Disconnections and Retained Messages</name>
<t> <t>
In the case of a Client DISCONNECT, if the Session Expiry Interval i In the case of a Client DISCONNECT, if the Session Expiry Interval is set
s set to 0, the Broker to 0, the Broker doesn't store the Session State but <bcp14>MUST</bcp14> keep t
doesn't maintain session state but MUST keep the retained messages. he retained messages. If the Broker stores the Session State, the state <bcp14>M
If the Broker maintains session state, the state MAY include the to AY</bcp14> include the token and its introspection result (for reference tokens)
ken and its in addition to the MQTT Session State. The MQTT Session State is identified by
introspection result (for reference tokens) in addition to the MQTT the Client Identifier and includes the following:
session state. </t>
The MQTT session state is identified by the Client Identifier and in <ul spacing="normal">
cludes the following: <li>the Client Subscriptions, </li>
<list style="symbols"> <li>messages with QoS levels 1 and 2, which have
<t>Client subscription state, </t> not been completely acknowledged or are pending transmission to the
<t> messages with QoS levels 1 and 2, and which have Client, and </li>
not been completely acknowledged or are pending transmission to the <li>if the Session is currently not connected, the time at which the Ses
Client, and </t> sion will end and the Session State will be discarded.</li>
<t> if the Session is currently not connected, </ul>
the time at which the Session will end and Session State will be dis <t>
carded.</t> The token/introspection state is not part of the MQTT Session State, and
</list> PoP validation is required for each new connection, regardless of whether existi
The token/introspection state is not part of the MQTT session state, ng MQTT Sessions are continued.
and PoP validation is required </t>
for each new connection, regardless of whether MQTT session continua <t>
tion is used.
</t>
<t>
The messages to be retained are indicated to the Broker by setting a RETAIN flag in a PUBLISH packet. The messages to be retained are indicated to the Broker by setting a RETAIN flag in a PUBLISH packet.
This way, the publisher signals to the Broker to store the most This way, the publisher signals to the Broker to store the most
recent message for the associated topic. Hence, the new subscribers can receive recent message for the associated topic. Hence, the new subscribers can receive
the last sent message from the publisher for that particular topic w ithout waiting the last sent message from the publisher for that particular topic w ithout waiting
for the next PUBLISH packet. for the next PUBLISH packet.
The Broker MUST continue publishing The Broker <bcp14>MUST</bcp14> continue publishing
the retained messages as long as the associated tokens are valid. the retained messages as long as the associated tokens are valid.
In the MQTT standard, if QoS is 0 for the PUBLISH packet, the Broker may discard the In the MQTT standard, if QoS is 0 for the PUBLISH packet, the Broker may discard the
retained message any time. For QoS>1, the message expiry interval di ctates how long the retained message is kept. retained message any time. For QoS &gt; 1, the message expiry interv al dictates how long the retained message is kept.
However, it is important that the Broker avoids sending messages ind efinitely for the Clients that never update their tokens (i.e., However, it is important that the Broker avoids sending messages ind efinitely for the Clients that never update their tokens (i.e.,
the Client connects briefly with a valid token, sends a PUBLISH pack the Client connects briefly with a valid token, sends a PUBLISH pack
et with RETAIN flag set to 1 et with the RETAIN flag set to 1
and QoS>1, disconnects, and never connects again). and QoS &gt; 1, disconnects, and never connects again).
Therefore, the Broker MUST use the minimum of token expiry and messa Therefore, the Broker <bcp14>MUST</bcp14> use the minimum of the tok
ge expiry interval to discard en expiry and message expiry interval to discard
a retained message. a retained message.
</t> </t>
<t> <t>
In case of disconnections due to network errors or server disconnect ion due to a protocol error In case of disconnections due to network errors or server disconnect ion due to a protocol error
(which includes authorization errors), the Will message is sent if t (which includes authorization errors), the Will Message is sent if t
he Client supplied he Client supplied
a Will in the CONNECT packet. The Client's token scope array MUST i a Will in the CONNECT packet. The Client's token scope array <bcp14
nclude the Will Topic. >MUST</bcp14> include the Will Topic.
The Will message MUST be published to the Will Topic regardless of w The Will Message <bcp14>MUST</bcp14> be published to the Will Topic,
hether the corresponding regardless of whether the corresponding
token has expired (as it has been validated and accepted duri ng CONNECT). token has expired (as it has been validated and accepted duri ng CONNECT).
</t> </t>
</section> </section>
<section anchor="MQTTv311" title="Reduced Protocol Interactions for MQTT <section anchor="MQTTv311" numbered="true" toc="default">
v3.1.1"> <name>Reduced Protocol Interactions for MQTT v3.1.1</name>
<t> <t>
This section describes a reduced set of protocol interactions for the MQ TT v3.1.1 Clients. This section describes a reduced set of protocol interactions for the MQ TT v3.1.1 Clients.
An MQTT v5.0 Broker MAY implement these interactions for the MQTT v3.1.1 An MQTT v5.0 Broker <bcp14>MAY</bcp14> implement these interactions for
Clients; the MQTT v3.1.1 Clients;
The flows described in this section are NOT RECOMMENDED for use by MQTT the flows described in this section are <bcp14>NOT RECOMMENDED</bcp14> f
v5.0 Clients. or use by MQTT v5.0 Clients.
Brokers that do not support MQTT v3.1.1 Clients return a CONNACK packet Brokers that do not support MQTT v3.1.1 Clients return a CONNACK packet
with Reason Code 0x84 (Unsupported Protocol Version) in response to the with reason code 0x84 (Unsupported Protocol Version) in response to the
connection requests. connection requests.
</t> </t>
<section anchor="token_311" title="Token Transport"> <section anchor="token_311" numbered="true" toc="default">
<t> As in MQTT v5.0, the token MAY either be transported before, by <name>Token Transport</name>
publishing <t> As in MQTT v5.0, the token <bcp14>MAY</bcp14> either be transported
before, by publishing
to the "authz-info" topic, or inside the CONNECT packet. If the Cli ent provided to the "authz-info" topic, or inside the CONNECT packet. If the Cli ent provided
the token via the "authz-info" topic and will not update the token in the CONNECT packet, the token via the "authz-info" topic and will not update the token in the CONNECT packet,
it MUST authenticate over TLS. The Broker SHOULD still be prepared to store the Client access it <bcp14>MUST</bcp14> authenticate over TLS. The Broker <bcp14>SHO ULD</bcp14> 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).
</t> </t>
<t>In MQTT v3.1.1, after the Client has published to the "authz-info <t>In MQTT v3.1.1, after the Client has published to the "authz-info" to
" topic, pic,
the Broker cannot communicate the Broker cannot communicate
the result of the token validation because PUBACK reason codes o r server-side DISCONNECT the result of the token validation because PUBACK reason codes o r server-side DISCONNECT
packets are not supported. packets are not supported.
In any case, the subsequent TLS handshake would fail without a v alid token, In any case, the subsequent TLS handshake would fail without a v alid token,
which can prompt the Client to which can prompt the Client to
obtain a valid token. obtain a valid token.
</t> </t>
<t> <t>
To transport the token to the Broker inside the CONNECT packet, To transport the token to the Broker inside the CONNECT packet,
the Client uses the username and password fields. the Client uses the User Name and Password fields.
<xref target="mqtt_connect_message"></xref> shows the structure <xref target="mqtt_connect_message" format="default"/> shows the
of the MQTT CONNECT packet. structure of the MQTT CONNECT packet.
</t> </t>
<figure align="center" anchor="mqtt_connect_message" title="MQTT CONNE <figure anchor="mqtt_connect_message">
CT Variable Header Using Username and Password for ACE"> <name>MQTT CONNECT Variable Header Using a User Name and Password for
<artwork align="left"><![CDATA[ ACE</name>
0 8 16 <artwork align="center" name="" type="" alt=""><![CDATA[
+---------------------------+ 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 | +---------------------------+
| Client Identifier | | Payload |
| (UTF-8 encoded string) | | Client Identifier |
| Username as access token | | (UTF-8-encoded string) |
| (UTF-8 encoded string) | | User Name as access token |
| Password for signature/MAC| | (UTF-8-encoded string) |
| (Binary Data) | | Password for signature/MAC|
+---------------------------+ | (Binary Data) |
]]></artwork> +---------------------------+
</figure> ]]></artwork>
<t> </figure>
<xref target="mqtt_connect_flags"></xref> shows how the MQTT connect <t>
flags MUST be set to initiate <xref target="mqtt_connect_flags" format="default"/> shows how the M
QTT connect flags <bcp14>MUST</bcp14> be set to initiate
a connection with the Broker. a connection with the Broker.
</t> </t>
<figure align="center" anchor="mqtt_connect_flags" title="MQTT CONNECT F <table anchor="mqtt_connect_flags">
lags (Rsvd=Reserved)"> <name>MQTT CONNECT Flags (Rsvd. = Reserved)</name>
<artwork align="left"><![CDATA[ <thead>
+-----------------------------------------------------------+ <tr>
|User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.| <th>User Name Flag</th>
| flag |flag | | | | | | <th>Password Flag</th>
+-----------------------------------------------------------+ <th>Will Retain</th>
| 1 | 1 | X | X X | X | X | 0 | <th>Will QoS</th>
+-----------------------------------------------------------+ <th>Will Flag</th>
]]></artwork> <th>Clean</th>
</figure> <th>Rsvd.</th>
<t> </tr>
The Client SHOULD set the Clean flag to 1 to always start a </thead>
new session. <tbody>
If the Clean flag is set to 0, the Broker MUST resume commun <tr>
ications <td align="center">1</td>
with the Client based on the state from the current Session <td align="center">1</td>
(as identified by the Client Identifier). <td align="center">X</td>
If there is no Session associated with the Client Identifier <td align="center">X X</td>
, the Broker MUST create a new session. <td align="center">X</td>
The Broker MUST set the Session Present flag in the CONNACK <td align="center">X</td>
packet accordingly, i.e., 0 to indicate a clean session to the <td align="center">0</td>
Client and 1 to indicate session continuation. </tr>
The Broker MUST still perform PoP validation on the provided </tbody>
Client token. MQTT v3.1.1 does not use a </table>
Session Expiry Interval, and the Client expects that the Bro <t>
ker maintains the session The Client <bcp14>SHOULD</bcp14> set the Clean flag to 1 to always star
state after it disconnects. However, stored Session state ca t a new Session. If the Clean flag is set to 0, the Broker <bcp14>MUST</bcp14> r
n be discarded as a result esume communications with the Client based on the state from the current Session
of administrator action or policies (e.g. defining an automa (as identified by the Client Identifier). If there is no Session associated wit
ted h the Client Identifier, the Broker <bcp14>MUST</bcp14> create a new Session. Th
response based on storage capabilities), and Brokers SHOULD e Broker <bcp14>MUST</bcp14> set the Session Present flag in the CONNACK packet
implement administrative policies to limit accordingly, i.e., 0 to indicate a new Session to the Client and 1 to indicate t
misuse. hat the existing Session is continued. The Broker <bcp14>MUST</bcp14> still perf
</t> orm PoP validation on the provided Client token. MQTT v3.1.1 does not use a Sess
<t> ion Expiry Interval, and the Client expects that the Broker maintains the Sessio
The Client MAY set the Will Flag as desired (marked as "X" i n State after it disconnects. However, the stored Session State can be discarded
n as a result of administrator action or policies (e.g., defining an automated re
<xref target="mqtt_connect_flags"></xref>). Username and Pa sponse based on storage capabilities), and Brokers <bcp14>SHOULD</bcp14> impleme
ssword flags MUST be nt administrative policies to limit misuse.
set to 1 to ensure that the Payload of the CONNECT packet </t>
includes both Username <t>
and Password fields. The MQTT Username is a UTF-8 encoded The Client <bcp14>MAY</bcp14> set the Will Flag as desired (
string, and the MQTT Password is Binary Data. marked as "X" in
</t> <xref target="mqtt_connect_flags" format="default"/>). User
<t> Name and Password flags <bcp14>MUST</bcp14> be
The CONNECT in MQTT v3.1.1 does not have a field to indicate set to 1 to ensure that the Payload of the CONNECT packet
the authentication includes both the User Name
method. To signal that the Username field contains an ACE to and Password fields. The MQTT User Name is a UTF-8-encoded
ken, string, and the MQTT Password is Binary Data.
this field MUST be prefixed with "ace" keyword, </t>
i.e., the Username field is a concatenation of 'a', 'c', 'e' <t>
and the access token The CONNECT in MQTT v3.1.1 does not have a field to indicate
the Authentication
Method. To signal that the User Name field contains an ACE t
oken,
this field <bcp14>MUST</bcp14> be prefixed with the keyword
"ace",
i.e., the User Name field is a concatenation of 'a', 'c', 'e
', and the access token
represented as: represented as:
<figure anchor="v31username" align="left" title="Username i </t>
n CONNECT"> <figure anchor="v31username">
<artwork type="" name="" align="left" alt=""><![CDATA[ <name>User Name in CONNECT</name>
'U+0061'||'U+0063'||'U+0065'||UTF-8(access token) <artwork type="" name="" align="center" alt=""><![CDATA[
'U+0061'||'U+0063'||'U+0065'||UTF-8(access token)
]]></artwork> ]]></artwork>
</figure> </figure>
To this end, the access token MUST be base64url encoded, <t>
omitting the '=' padding characters <xref target="RFC4648">< To this end, the access token <bcp14>MUST</bcp14> be encoded
/xref>. with base64url,
</t> omitting the "=" padding characters <xref target="RFC4648" f
<t> ormat="default"/>.
The password field MUST be set to the keyed message digest ( </t>
MAC) <t>
The Password field <bcp14>MUST</bcp14> be set to the keyed m
essage digest (MAC)
or signature associated with the access token for PoP. or signature associated with the access token for PoP.
The Client MUST apply the PoP key on the challenge derived f The Client <bcp14>MUST</bcp14> apply the PoP key on the chal
rom the TLS lenge derived from the TLS
session as described in <xref target="pop_nonce"></xref>. session, as described in <xref target="pop_nonce" format="de
</t> fault"/>.
</section> </t>
<section anchor="errors_311" title="Handling Authorization Erro </section>
rs"> <section anchor="errors_311" numbered="true" toc="default">
<t> <name>Handling Authorization Errors</name>
<t>
Error handling is more primitive in MQTT v3.1.1 due to not havin g appropriate error fields, Error handling is more primitive in MQTT v3.1.1 due to not havin g appropriate error fields,
error codes, and server-side DISCONNECTs. error codes, and server-side DISCONNECTs.
Therefore, the Broker will disconnect on almost any error and ma Therefore, the Broker will disconnect on almost any error and may
y not keep the not keep the Session State, necessitating that clients make a greater effort to
session state, necessitating that clients make a greater ensure that tokens remain valid and do not attempt to publish to topics that th
effort to ensure that tokens remain valid and do not attempt to ey do not have permissions for.
publish
to topics that they do not have permissions for.
The following lists how the Broker responds to specific errors. The following lists how the Broker responds to specific errors.
</t> </t>
<t> <dl newline="true" spacing="normal" indent="8">
<list style="symbols"> <dt>
<t> CONNECT without a token:</dt> <dd>The tokenless CONNECT attempt
CONNECT without a token: The tokenless CONNECT attempt MUST fail <bcp14>MUST</bcp14> fail. This is
. This is because the challenge-response-based PoP is not possible for MQT
because the challenge-response based PoP is not possible for MQT T v3.1.1.
T v3.1.1.
It is also not possible to support AS discovery since a CONNACK packet in MQTT v3.1.1 It is also not possible to support AS discovery since a CONNACK packet in MQTT v3.1.1
does not include a means to provide additional information to the Client. does not include a means to provide additional information to the Client.
Therefore, AS discovery needs to take place out-of-ba Therefore, AS discovery needs to take place out of ba
nd. nd.
</t> </dd>
<t> <dt>
Client-Broker PUBLISH authorization failure: In the case of a fa Client-Broker PUBLISH authorization failure:</dt> <dd>In the cas
ilure, e of a failure,
it is not possible to return an error in MQTT v3.1.1. it is not possible to return an error in MQTT v3.1.1.
Acknowledgment messages only indicate success. In the case of an authorization error, Acknowledgment messages only indicate success. In the case of an authorization error,
the Broker MUST ignore the PUBLISH packet and disconnect the Cli ent. the Broker <bcp14>MUST</bcp14> ignore the PUBLISH packet and dis connect the Client.
Also, as DISCONNECT packets are only sent Also, as DISCONNECT packets are only sent
from a Client to the Broker, the server disconnection needs to t ake place below the application layer. from a Client to the Broker, the server disconnection needs to t ake place below the application layer.
</t> </dd>
<t> SUBSCRIBE authorization failure: In the SUBACK packet <dt> SUBSCRIBE authorization failure:</dt> <dd>In the SUBACK packet,
, the return code is 0x80 indicating the return code is 0x80, indicating
failure for the unauthorized topic(s). Note that, in both MQTT v ersions, a reason code is failure for the unauthorized topic(s). Note that, in both MQTT v ersions, a reason code is
returned for each Topic Filter. returned for each Topic Filter.
</t> </dd>
<t>Broker-Client PUBLISH authorization failure: When the B <dt>Broker-Client PUBLISH authorization failure:</dt> <dd>When the Br
roker is forwarding PUBLISH packets to the subscribed Clients, oker is forwarding PUBLISH packets to the subscribed Clients,
it may discover that some of the subscribers are no longer authorized due to expired tokens. it may discover that some of the subscribers are no longer authorized due to expired tokens.
These token expirations MUST lead to disconnecting the Client rat These token expirations <bcp14>MUST</bcp14> lead to disconnecting
her than silently dropping messages. the Client rather than silently dropping messages.
</t> </dd>
</list> </dl>
</t> </section>
</section> </section>
</section> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<!-- This PI places the pagebreak correctly (before the section title) in <section numbered="true" toc="default">
the text output. --> <name>TLS Exporter Labels Registration</name>
<t>
<!--<?rfc needLines="8" ?>--> This document registers "EXPORTER-ACE-MQTT-Sign-Challenge" (introduc
ed in <xref target="pop_nonce" format="default"/>
<!-- Possibly a 'Acknowledgments'/ 'Contributors' section ... --> in this document) in the "TLS Exporter Labels" registry <xref target=
<section anchor="IANA" title="IANA Considerations"> "RFC8447" format="default"/>.
</t>
<t> Note to RFC Editor: Please replace all occurrences of "[this documen <dl newline="false" spacing="normal">
t]" <dt>Recommended:</dt> <dd>N</dd>
with the RFC number of this specification and delete this paragraph.</t> <dt>DTLS-OK:</dt> <dd>N</dd>
<dt>Reference:</dt> <dd>RFC 9431</dd>
<section title="TLS Exporter Label Registration"> </dl>
<t> </section>
This document registers "EXPORTER-ACE-MQTT-Sign-Challenge" (introduc <section numbered="true" toc="default">
ed in <xref target="pop_nonce"></xref> <name>Media Type Registration</name>
in this document) in the TLS Exporter Label Registry <xref target="RF
C8447"></xref>.
<list style="symbols">
<t>Recommended: No</t>
<t>DTLS-OK: No</t>
<t>Reference: [This document]</t>
</list>
</t>
</section>
<section title="Media Type Registration">
<t>This document registers the "application/ace+json" media type <t>This document registers the "application/ace+json" media type
for messages of the protocols defined in this document carrying for messages of the protocols defined in this document carrying
parameters encoded in JSON.</t> parameters encoded in JSON.</t>
<t> <dl newline="false" spacing="normal">
<list style="symbols"> <dt>Type name:</dt> <dd>application </dd>
<t>Type name: application </t> <dt>Subtype name:</dt> <dd>ace+json </dd>
<t>Subtype name: ace+json </t> <dt>Required parameters:</dt> <dd>N/A </dd>
<t>Required parameters: N/A </t> <dt>Optional parameters:</dt> <dd>N/A </dd>
<t>Optional parameters: N/A </t> <dt>Encoding considerations:</dt> <dd>Encoding considerations are iden
<t>Encoding considerations: Encoding considerations are identical to tical to
those specified for the "application/json" media type.</t> those specified for the "application/json" media type.</dd>
<t>Security considerations: Section 8 of [this document]</t> <dt>Security considerations:</dt> <dd><xref target="Security" format="
<t>Interoperability considerations: none </t> default"/> of RFC 9431</dd>
<t>Published specification: [this document]</t> <dt>Interoperability considerations:</dt> <dd>none </dd>
<t>Applications that use this media type: This media type is intended <dt>Published specification:</dt> <dd>RFC 9431</dd>
for <dt>Applications that use this media type:</dt> <dd>This media type is
authorization server-client and authorization server-resource server intended for
communication as part of the ACE framework using JSON encoding as sp Authorization-Server-Client and Authorization-Server-Resource-Server
ecified in [this document].</t> communication as part of the ACE framework using JSON encoding, as s
<t>Fragment identifier considerations: none </t> pecified in RFC 9431.</dd>
<t>Additional information: <dt>Fragment identifier considerations:</dt> <dd>none </dd>
<list style="symbols"> <dt>Additional information:</dt>
<t>Deprecated alias names for this type: none</t> <dd><t><br/></t>
<t>Magic number(s): none</t> <dl newline="false" spacing="normal">
<t>File extension(s): none</t> <dt>Deprecated alias names for this type:</dt> <dd>none</dd>
<t>Macintosh file type code(s): none</t> <dt>Magic number(s):</dt> <dd>none</dd>
</list> <dt>File extension(s):</dt> <dd>none</dd>
</t> <dt>Macintosh file type code(s):</dt> <dd>none</dd>
<t>Person &amp; email address to contact for further information: Cigd </dl>
em Sengul (csengul@acm.org) </t> </dd>
<t>Intended usage: COMMON</t> <dt>Person &amp; email address to contact for further information:</dt
<t>Restrictions on usage: none</t> >
<t>Author: Cigdem Sengul (csengul@acm.org)</t> <dd><t><br/>Cigdem Sengul &lt;csengul@acm.org&gt;</t></dd>
<t>Change controller: IETF </t> <dt>Intended usage:</dt> <dd>COMMON</dd>
<t>Provisional registration? (standards tree only): no </t> <dt>Restrictions on usage:</dt> <dd>none</dd>
</list></t> <dt>Author:</dt> <dd>Cigdem Sengul &lt;csengul@acm.org&gt;</dd>
</section> <dt>Change controller:</dt> <dd>IETF </dd>
<section title="ACE OAuth Profile Registration"> </dl>
<t>The following registrations are done for the ACE OAuth Profile Regis </section>
try following the procedure specified in <section numbered="true" toc="default">
<xref target="I-D.ietf-ace-oauth-authz"></xref>. <name>ACE OAuth Profile Registration</name>
</t> <t>The following registrations have been made in the "ACE Profiles" regi
<t> stry, following the procedure specified in
<list style="symbols"> <xref target="RFC9200" format="default"/>.
<t>Name: mqtt_tls</t> </t>
<t>Description: Profile for delegating Client authentication and <dl newline="false" spacing="normal">
authorization using MQTT for the <dt>Name:</dt> <dd>mqtt_tls</dd>
Client and Broker (RS) interactions, and HTTP for the AS interaction <dt>Description:</dt> <dd>Profile for delegating Client authentication
s. and authorization using MQTT for the
Client and Broker (RS) interactions and HTTP for the AS interactions
.
TLS is used for confidentiality and integrity protection and serv er authentication. TLS is used for confidentiality and integrity protection and serv er authentication.
Client authentication can be provided either via TLS or using in-ban d PoP validation at the MQTT Client authentication can be provided either via TLS or using in-ban d PoP validation at the MQTT
application layer. application layer.
</t> </dd>
<t>CBOR Value: To be assigned by IANA in the (-256, 255) range</t <dt>CBOR Value:</dt> <dd>3</dd>
> <dt>Reference:</dt> <dd>RFC 9431</dd>
<t>Reference: [this document]</t> </dl>
</list> </section>
</t> <section numbered="true" toc="default">
</section> <name>AIF</name>
<section title="AIF"> <t>For the media types "application/aif+cbor" and "application/aif+json"
<t>For the media-types application/aif+cbor and application/aif+json ,
defined in Section 5.1 of <xref target="I-D.ietf-ace-aif"></xref>, IANA defined in <xref target="RFC9237" section="5.1" sectionFormat="of" forma
is requested to t="default"/>, IANA has
register the following entries for the two media-type parameters Toid registered the following entries for the two media type parameters Toid
and Tperm, in the respective sub-registry defined in Section 5.2 of and Tperm in the respective subregistry defined in <xref target="RFC9237
<xref target="I-D.ietf-ace-aif"></xref> within the "MIME Media Type Sub- " section="5.2" sectionFormat="of" format="default"/> within the "Media Type Sub
Parameter" -Parameter Registries".
registry group.
</t>
<t> For Toid:
<list style="symbols">
<t>Name: mqtt-topic-filter</t>
<t>Description/Specification: Topic Filter as defined in <xref t
arget="scope"></xref>.</t>
<t>Reference: [[This document]] (<xref target="scope"></xref>)</
t>
</list>
</t> </t>
<t> For Tperm: <dl newline="true" spacing="normal">
<list style="symbols"> <dt>For Toid:</dt>
<t>Name: mqtt-permissions</t> <dd>
<t>Description/Specification: Permissions for MQTT <dl newline="false" spacing="normal">
client as defined in <xref target="scope"></xref>. <dt>Name:</dt> <dd>mqtt-topic-filter</dd>
<dt>Description/Specification:</dt> <dd>Topic Filter, as defined in <x
ref target="scope" format="default"/> of RFC 9431.</dd>
<dt>Reference:</dt> <dd>RFC 9431, <xref target="scope" format="default
"/></dd>
</dl>
</dd>
<dt> For Tperm:</dt>
<dd>
<dl newline="false" spacing="normal">
<dt>Name:</dt> <dd>mqtt-permissions</dd>
<dt>Description/Specification:</dt> <dd>Permissions for the MQTT
Client, as defined in <xref target="scope" format="default"/> of
RFC 9431.
Tperm is an array of one or more text strings that each have Tperm is an array of one or more text strings that each have
a value of either "pub" or "sub".</t> a value of either "pub" or "sub".</dd>
<t>Reference: [[This document]] (<xref target="scope"></xref>)< <dt>Reference:</dt> <dd>RFC 9431, <xref target="scope" format="default
/t> "/></dd>
</list> </dl>
</t> </dd></dl>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t> This document specifies a profile for the Authentication and Author <t> This document specifies a profile for the Authentication and Authoriza
ization for Constrained Environments (ACE) framework tion for Constrained Environments (ACE) framework
<xref target="I-D.ietf-ace-oauth-authz"></xref>. Therefore, the securit <xref target="RFC9200" format="default"/>. Therefore, the security cons
y considerations outlined iderations outlined
in <xref target="I-D.ietf-ace-oauth-authz"></xref> apply to this work. in <xref target="RFC9200" format="default"/> apply to this work.
</t> </t>
<t> In addition, the security considerations outlined in <xref target=" <t> In addition, the security considerations outlined in the <xref target=
MQTT-OASIS-Standard-v5">MQTT v5.0 - the OASIS Standard</xref> "MQTT-OASIS-Standard-v5" format="default">MQTT v5.0 OASIS Standard</xref>
and <xref target="MQTT-OASIS-Standard-v3.1.1">MQTT v3.1.1 - the OASIS S and <xref target="MQTT-OASIS-Standard-v3.1.1" format="default">MQTT v3.
tandard</xref> 1.1 OASIS Standard</xref>
apply. Mainly, this document provides an authorization solution for M QTT, apply. Mainly, this document provides an authorization solution for M QTT,
the responsibility of which is left to the specific implementation in the MQTT standards. the responsibility of which is left to the specific implementation in the MQTT standards.
In the following, we comment on a few relevant issues based on the curre nt MQTT specifications. In the following, we comment on a few relevant issues based on the curre nt MQTT specifications.
</t> </t>
<t>After the Broker validates an access token and accepts a connection fro
<t>After the Broker validates an access token and accepts a connection m a client, it caches the token to authorize a Client's publish and subscribe re
from a client, it caches the token quests in an ongoing Session.
to authorize a Client's publish and subscribe requests in an ongoing sessi
on.
The Broker does not cache any tokens that cannot be validated. The Broker does not cache any tokens that cannot be validated.
If a Client's permissions get revoked, but the access token has not expire d, If a Client's permissions get revoked, but the access token has not expire d,
the Broker may still grant publish/subscribe to revoked topics. the Broker may still grant publish/subscribe to revoked topics.
If the Broker caches the token introspection responses, then the Broker SH If the Broker caches the token introspection responses, then the Broker <b
OULD use a reasonable cache timeout cp14>SHOULD</bcp14> use a reasonable cache timeout
to introspect tokens regularly. The timeout value is application-specific to introspect tokens regularly. The timeout value is application specific
and should be chosen and should be chosen
to reduce the risk of using stale introspection responses. to reduce the risk of using stale introspection responses.
When permissions change dynamically, it is expected that AS also When permissions change dynamically, it is expected that the AS also
follows a reasonable expiration strategy for the access tokens. follows a reasonable expiration strategy for the access tokens.
</t> </t>
<t> The Broker may monitor Client behavior to detect potential security pr
<t> The Broker may monitor Client behaviour to detect potential securit oblems, especially those affecting availability.
y problems, especially those affecting availability.
These include repeated token transfer attempts to the public "authz-inf o" topic, repeated connection attempts, These include repeated token transfer attempts to the public "authz-inf o" topic, repeated connection attempts,
abnormal terminations, and Clients that connect but do not send any dat a. abnormal terminations, and Clients that connect but do not send any dat a.
If the Broker supports the public "authz-info" topic, described in <xre If the Broker supports the public
f target="app-authzinfo"></xref>, "authz-info" topic, described in <xref target="app-authzinfo" format="default
then this may be vulnerable to a DDoS attack, where many Clients use th "/>, then this may be
e "authz-info" public topic vulnerable to a DDoS attack, where many Clients use the "authz-info"
to transport tokens that are not meant to be used, and which the Broker ma public topic to transport tokens that are not meant to be used
y need to store until the and that the Broker may need to store until they expire.</t>
tokens expire.</t> <t>For MQTT v5.0, when a Client connects with a long Session Expiry Interval,
the Broker may need to maintain the Client's MQTT Session State after it discon
<t>For MQTT v5.0, when a Client connects with a long Session Expiry Interv nects for an extended period. For MQTT v3.1.1, the Session State may need to be
al, the Broker may need to maintain stored indefinitely, as it does not have a Session Expiry Interval feature. The
the Client's MQTT session state after it disconnects for an extended perio Broker <bcp14>SHOULD</bcp14> implement administrative policies to limit misuse b
d. For MQTT v3.1.1, y the Client resulting from continuing existing Sessions.
the session state may need to be stored indefinitely, as it does not have
a Session Expiry Interval feature.
The Broker SHOULD implement administrative policies to limit misuse of the
session continuation by the Client.
</t> </t>
</section> </section>
<section anchor="Privacy" numbered="true" toc="default">
<section anchor="Privacy" title="Privacy Considerations"> <name>Privacy Considerations</name>
<t>The privacy considerations outlined in <xref target="I-D.ietf-ace <t>The privacy considerations outlined in <xref target="RFC9200" format="d
-oauth-authz"></xref> apply to this work. efault"/> apply to this work.
</t> </t>
<t>In MQTT, the Broker is a central trusted party and may forward <t>In MQTT, the Broker is a central trusted party and may forward potentia
potentially sensitive information lly sensitive information
between Clients. The mechanisms defined in this document do not p rotect the contents of the PUBLISH packet from the Broker, and hence, between Clients. The mechanisms defined in this document do not p rotect the contents of the PUBLISH packet from the Broker, and hence,
the content of the PUBLISH packet is not signed or encrypted sep arately for the subscribers. the content of the PUBLISH packet is not signed or encrypted sep arately for the subscribers.
This functionality may be implemented using the proposal outline d in <xref target="I-D.ietf-ace-pubsub-profile"> This functionality may be implemented using the proposal outline d in <xref target="I-D.ietf-ace-pubsub-profile" format="default">
the ACE Pub-Sub Profile</xref>. the ACE Pub-Sub Profile</xref>.
However, this solution would still not provide privacy for other fields of the packet, such as Topic Name. However, this solution would still not provide privacy for other fields of the packet, such as Topic Name.
</t> </t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libr <displayreference target="I-D.ietf-tls-rfc8446bis" to="TLS-bis"/>
aries: <displayreference target="I-D.ietf-ace-pubsub-profile" to="ACE-PUBSUB-PROFILE"/>
1. define an ENTITY at the top, and use "ampersand character"RFC2629; h <references>
ere (as shown) <name>References</name>
2. simply use a PI "less than character"?rfc include="reference.RFC.211 <references>
9.xml"?> here <name>Normative References</name>
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
bis.xml") 119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
648.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
250.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
422.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
442.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
705.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
749.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
800.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
747.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
610.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
519.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
516.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
517.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
052.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
627.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
066.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
301.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
032.xml"/>
Both are cited textually in the same manner: by using xref elements. <reference anchor="MQTT-OASIS-Standard-v3.1.1" target="https://docs.oasi
If you use the PI option, xml2rfc will, by default, try to find include s-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html">
d files in the same <front>
directory as the including file. You can also define the XML_LIBRARY en <title>MQTT Version 3.1.1 Plus Errata 01</title>
vironment variable <author initials="A." surname="Banks" role="editor">
with a value containing a set of directories to search. These can be e <organization>IBM</organization>
ither in the local </author>
filing system or remote ones accessed by http (http://domain/dir/... ). <author initials="R." surname="Gupta" role="editor">
--> <organization>IBM</organization>
</author>
<date year="2015" month="December"/>
</front>
<refcontent>OASIS Standard</refcontent>
</reference>
<references title="Normative References"> <reference anchor="MQTT-OASIS-Standard-v5" target="https://docs.oasis-op
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/referenc en.org/mqtt/mqtt/v5.0/mqtt-v5.0.html">
e.RFC.2119.xml"?--> <front>
&RFC2119; <title>MQTT Version 5.0</title>
&RFC4648; <author initials="A." surname="Banks" role="editor">
&RFC8174; <organization>IBM</organization>
&RFC7250; </author>
&RFC8422; <author initials="E." surname="Briggs" role="editor">
&RFC8442; <organization>Microsoft</organization>
&RFC8446; </author>
&RFC5705; <author initials="K." surname="Borgendale" role="editor">
&RFC6234; <organization>IBM</organization>
&RFC6749; </author>
&RFC7800; <author initials="R." surname="Gupta" role="editor">
&RFC8747; <organization>IBM</organization>
&RFC8610; </author>
&RFC7519; <date year="2019" month="March"/>
&RFC7516; </front>
&RFC7517; <refcontent>OASIS Standard</refcontent>
&RFC8152; </reference>
&RFC7627;
&RFC6066;
&RFC7301;
&RFC8032;
<reference anchor="MQTT-OASIS-Standard-v3.1.1"
target="https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt
-v3.1.1.html">
<front>
<title>
OASIS Standard MQTT Version 3.1.1 Plus Errata 01
</title>
<author initials="A." surname="Banks" role="editor">
<organization>IBM</organization>
</author>
<author initials="R." surname="Gupta" role="editor">
<organization>IBM</organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="MQTT-OASIS-Standard-v5" <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92
target="https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt 00.xml"/>
-v5.0-os.html"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<front> 201.xml"/>
<title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
OASIS Standard MQTT Version 5.0 360.xml"/>
</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author initials="A." surname="Banks" role="editor"> 237.xml"/>
<organization>IBM</organization> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</author> 202.xml"/>
<author initials="E." surname="Briggs" role="editor">
<organization>Microsoft</organization>
</author>
<author initials="K." surname="Borgendale" role="editor">
<organization>IBM</organization>
</author>
<author initials="R." surname="Gupta" role="editor">
<organization>IBM</organization>
</author>
<date year="2017"/>
</front>
</reference>
<?rfc include="reference.I-D.ietf-ace-oauth-authz.xml"?>
<?rfc include="reference.I-D.ietf-ace-oauth-params.xml"?>
<?rfc include="reference.I-D.draft-ietf-cose-x509-08.xml"?>
<?rfc include="reference.I-D.ietf-ace-aif-07.xml"?>
<?rfc include="reference.I-D.ietf-ace-dtls-authorize.xml"?>
<?rfc include="reference.I-D.ietf-ace-extend-dtls-authorize-02.xml"?
>
<?rfc include="reference.I-D.ietf-httpbis-semantics-19.xml"?>
</references>
<references title="Informative References"> <reference anchor="RFC9430" target="https://www.rfc-editor.org/info/rfc9430">
<!-- Here we use entities that we defined at the beginning. --> <front>
<!-- A reference written by by an organization not a person. --> <title>
&RFC4949; Extension of the Datagram Transport Layer Security (DTLS) Profile for Authentica
&RFC7252; tion and Authorization for Constrained Environments (ACE) to Transport Layer Sec
&RFC8949; urity (TLS)
&RFC8392; </title>
&RFC8447; <author initials="O." surname="Bergmann" fullname="Olaf Bergmann">
&RFC7925; <organization>Universität Bremen TZI</organization>
&RFC7525; </author>
<reference anchor="fremantle14" target="https://dx.doi.org/10.1109/SI <author initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattsson">
oT.2014.8"> <organization>Ericsson AB</organization>
<front> </author>
<title> <author initials="G." surname="Selander" fullname="Göran Selander">
Federated Identity and Access Management for the <organization>Ericsson AB</organization>
Internet of Things </author>
</title> <date month="July" year="2023"/>
<author initials="P." surname="Fremantle"></author> </front>
<author initials="B." surname="Aziz"></author> <seriesInfo name="RFC" value="9430"/>
<author initials="J." surname="Kopecky"></author> <seriesInfo name="DOI" value="10.17487/RFC9430"/>
<author initials="P." surname="Scott"></author> </reference>
<date month="September" year="2014"></date>
</front>
<seriesInfo name="research" value="International Workshop on Secu
re Internet of Things"></seriesInfo>
</reference>
<?rfc include="reference.I-D.draft-ietf-tls-rfc8446bis-04.xml"?>
<?rfc include="reference.I-D.draft-ietf-ace-pubsub-profile-04.xml"?>
</references>
<section anchor="app-profile-requirements" title="Checklist for profile <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
requirements"> 10.xml"/>
<t>
Based on the requirements on profiles for the ACE framework <xref t
arget="I-D.ietf-ace-oauth-authz"></xref>,
this document fulfills the following:
<list style="symbols">
<t>Optional AS discovery: AS discovery is supported with the M
QTT v5.0 described in <xref target="connect_v5"></xref>.</t>
<t>The communication protocol between the Client and Broker (R
S): MQTT</t>
<t>The security protocol between the Client and RS: TLS</t>
<t>Client and RS mutual authentication: Several options are po
ssible and described in <xref target="auth_options"></xref>.
</t>
<t> Proof-of-possession protocols: Specified in <xref target="
AUTH-method"></xref>; both symmetric and asymmetric keys supported.
</t>
<t>Content format: For the HTTPS interactions with AS, "applic
ation/ace+json".
</t>
<t>Unique profile identifier: mqtt_tls</t>
<t>Token introspection: RS uses HTTPS introspect interface o
f AS.</t>
<t>Token request: Client or its Client AS uses the HTTPS tok
en endpoint of the AS.</t>
<t>authz-info endpoint: It MAY be supported using the method
described in <xref
target="app-authzinfo"></xref>, but is
not protected other than by the TLS channel between Clie
nt and RS.
</t>
<t>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 an
d re-authentication for
MQTT v5.0, as described in <xref target="connect_v5">
</xref> and <xref target="reauthentication"></xref>.</t>
</list>
</t>
</section>
<!-- Change Log </references>
--> <references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
949.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
252.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
949.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
392.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
447.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
925.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
325.xml"/>
<section anchor="document_updates" title="Document Updates"> <reference anchor="Fremantle14" target="https://dx.doi.org/10.1109/SIoT.
<t>Version 15: Addressing GENART review comments. 2014.8">
</t> <front>
<t>Version 11 to 15: Addressing AD review comments. <title>Federated Identity and Access Management for the Internet of
</t> Things</title>
<t> Version 10 to 11: Clarified the TLS use between RS-AS and Client-AS. <author initials="P." surname="Fremantle"/>
</t> <author initials="B." surname="Aziz"/>
<t> Version 09 to 10: Fixed version issues for references. <author initials="J." surname="Kopecky"/>
</t> <author initials="P." surname="Scott"/>
<t> Version 08 to 09: Fixed spacing issues and references. <date month="September" year="2014"/>
</t> </front>
<t> Version 07 to 08: <seriesInfo name="DOI" value="10.1109/SIoT.2014.8"/>
<list style="symbols"> <refcontent>International Workshop on Secure Internet of Things</refcon
<t>Fixed several nits, typos based on WG reviews.</t> tent>
<t>Added missing references.</t> </reference>
<t>Added the definition for Property defined by MQTT, and Client Aut
horization Server.</t>
<t>Added artwork to show Authorization Data format for various PoP-r
elated message exchange.</t>
<t>Removed all MQTT-related must/should/may.</t>
<t>Made AS discovery optional.</t>
<t>Clarified what the client and server must implement for client au
thentication; cleaned
up TLS 1.3 related language.</t>
</list>
</t>
<t> Version 06 to 07:
<list style="symbols">
<t>Corrected the title.</t>
<t>In Section 2.2.3, added the constraint on which packets the Clien
t can send, and the server
can process after CONNECT before CONNACK.</t>
<t>In Section 2.2.3, clarified that session state is identified by C
lient Identifier,
and listed its content.</t>
<t>In Section 2.2.3, clarified the issue of Client Identifier collis
ion, when the Broker supports
session continuation.</t>
<t>Corrected the buggy scope example in Section 3.1.</t>
</list>
</t>
<t> Version 05 to 06:
<list style="symbols">
<t>Replace the originally proposed scope format with AIF model. Defi
ned the AIF-MQTT,
gave an example with a JSON array. Added a normative reference to
the AIF draft.</t>
<t>Clarified client connection after submitting token via "authz-inf
o" topic as
TLS:Known(RPK/PSK),MQTT:none. </t>
<t>Expanded acronyms on their first use including the ones in the ti
tle.</t>
<t>Added a definition for "Session".</t>
<t>Corrected "CONNACK" definition, which earlier said it's the first
packet sent by the Broker.</t>
<t>Added a statement that the Broker will disconnect on almost any e
rror and may not keep session state.</t>
<t>Clarified that the Broker does not cache tokens that cannot be va
lidated.</t>
</list>
</t>
<t> Version 04 to 05:
<list style="symbols">
<t>Reorganised Section 2 such that "Unauthorized Request: Authorizatio
n Server Discovery"
is presented under Section 2.</t>
<t>Fixed Figure 2 to remove the "empty" word.</t>
<t>Clarified that MQTT v5.0 Brokers may implement username/password o
ption for
transporting the ACE token only for MQTT v.3.1.1 clients. This opt
ion is not recommended
for MQTT v.5.0 clients.</t>
<t>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.</t>
<t>Fixed the Authentication Data to include token length for the Cha
llenge/Response PoP.</t>
<t>Added that Authorization Server Discovery is triggered if a token
is not valid and not only missing.</t>
<t>Clarified that the Broker should not accept any other packets fro
m Client after CONNECT and
before sending CONNACK.</t>
<t> Added that client reauthentication is accepted only for the chal
lenge/response PoP.</t>
<t> Added Ed25519 as mandatory to implement.</t>
<t>Fixed typos.</t>
</list>
</t>
<t>
Version 03 to 04:
<list style="symbols">
<t>Linked the terms Broker and MQTT server more at the introduction
of the document.</t>
<t>Clarified support for MQTTv3.1.1 and removed phrases that might b
e considered as MQTTv5 is backwards compatible with MQTTv3.1.1</t>
<t>Corrected the Informative and Normative references.</t>
<t>For AS discovery, clarified the CONNECT message omits the Authent
ication Data field.
Specified the User Property MUST be set to "ace_as_hint" for AS Requ
est Creation Hints.</t>
<t>Added that MQTT v5 brokers MAY also implement reduced interaction
s described for MQTTv3.1.1.</t>
<t>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).</t
>
<t>Added a pointer to section 4.7 of MQTTv5 spec for more informatio
n on topic names and filters.</t>
<t>Added HS256 and RSA256 are mandatory to implement depending on th
e choice
of symmetric or asymmetric validation.</t>
<t>Added MQTT to the TLS exporter label to make it application speci
fic: 'EXPORTER-ACE-MQTT-Sign-Challenge'.</t>
<t>Added a format for Authentication Data so that length values pref
ix the token (or client nonce)
when Authentication Data contains more than one piece of information
.</t>
<t> Clarified clients still connect over TLS (server-side) for the a
uthz-info flow. </t>
</list>
</t>
<t>
Version 02 to 03:
<list style="symbols">
<t>Added the option of Broker certificate thumbprint in the 'rs_cnf'
sent to the Client.</t>
<t>Clarified the use of a random nonce from the TLS Exporter for PoP
, added to the IANA requirements that
the label should be registered.</t>
<t>Added a client nonce, when Challenge/Response Authentication is u
sed between Client and Broker.</t>
<t>Clarified the use of the "authz-info" topic and the error respons
e if token validation fails.</t>
<t>Added clarification on wildcard use in scopes for publish/subscri
be permissions</t>
<t>Reorganised sections so that token authorization for publish/subs
cribe messages are better placed.</t>
</list>
</t>
<t>
Version 01 to 02:
<list style="symbols">
<t> Clarified protection of Application Message payload as out of sc
ope, and cited draft-palombini-ace-coap-pubsub-profile
for a potential solution </t>
<t> Expanded Client connection authorization to capture different op
tions for Client and Broker
authentication over TLS and MQTT</t>
<t> Removed Payload (and specifically Client Identifier) from proof-
of-possession
in favor of using tls-exporter for a TLS-session based challenge
.</t>
<t> Moved token transport via "authz-info" topic from the Appendix t
o the main text.</t>
<t> Clarified Will scope. </t>
<t> Added MQTT AUTH to terminology.</t>
<t> Typo fixes, and simplification of figures.</t>
</list>
</t>
<t>
Version 00 to 01:
<list style="symbols">
<t> Present the MQTTv5 as the RECOMMENDED version, and MQTT v3.1.1 f
or backward compatibility. </t>
<t> Clarified Will message. </t>
<t> Improved consistency in the use of terminology and upper/lower c
ase. </t>
<t> Defined Broker and MQTTS. </t>
<t> Clarified HTTPS use for C-AS and RS-AS communication. Removed re
ference to actors document, and clarified the use of client authorization server
.</t>
<t> Clarified the Connect message payload and Client Identifier. </t
>
<t> Presented different methods for passing the token and PoP. </t>
<t> Added new figures to explain AUTH packets exchange, updated CONN
ECT message figure. </t>
</list>
</t>
</section>
<section anchor="Acknowledgments" title="Acknowledgments" numbered="no" t <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
oc="default"> ietf-tls-rfc8446bis.xml"/>
<t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
The authors would like to thank Ludwig Seitz for his review and ietf-ace-pubsub-profile.xml"/>
his input on the authorization information endpoint; </references>
Benjamin Kaduk for his review, insightful comments, and contribu </references>
tions to resolving issues; and Carsten Bormann for his review and <section anchor="app-profile-requirements" numbered="true" toc="default">
<name>Checklist for Profile Requirements</name>
<t>
Based on the requirements on profiles for the ACE framework <xref t
arget="RFC9200" format="default"/>,
this document fulfills the following:
</t>
<ul spacing="normal">
<li>Optional AS discovery: AS discovery is supported with the MQTT v5.0
described in <xref target="connect_v5" format="default"/>.</li>
<li>The communication protocol between the Client and Broker (RS): MQTT<
/li>
<li>The security protocol between the Client and RS: TLS</li>
<li>Client and RS mutual authentication: Several options are possible an
d described in <xref target="auth_options" format="default"/>.
</li>
<li> Proof-of-possession protocols: Both symmetric and asymmetric keys a
re supported, as specified in <xref target="AUTH-method" format="default"/>.
</li>
<li>Content-Format: For the HTTPS interactions with AS, "application/ace
+json".
</li>
<li>Unique profile identifier: mqtt_tls</li>
<li>Token introspection: The RS uses the HTTPS introspection interface o
f the AS.</li>
<li>Token request: The Client or its Client AS uses the HTTPS token endp
oint of the AS.</li>
<li>authz-info endpoint: It <bcp14>MAY</bcp14> be supported using the me
thod described in <xref target="app-authzinfo" format="default"/> but is
not protected other than by the TLS channel between the
Client and RS.
</li>
<li>Token transport: Via the "authz-info" topic, TLS with PSKs (provided
as a PSK identity), or in the
MQTT CONNECT packet for both versions of MQTT.
The AUTH extensions can also be used for authentication an
d reauthentication for
MQTT v5.0, as described in Sections <xref target="con
nect_v5" format="counter"/> and <xref target="reauthentication" format="counter"
/>.</li>
</ul>
</section>
<section anchor="Acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>
The authors would like to thank <contact fullname="Ludwig Seitz"
/> for his review and his input on the authorization information endpoint;
<contact fullname="Benjamin Kaduk"/> for his review, insightful
comments, and contributions to resolving issues; and <contact fullname="Carsten
Bormann"/> for his review and
revisions to the AIF-MQTT data model. revisions to the AIF-MQTT data model.
The authors would like to thank Paul Fremantle for the initial d The authors would like to thank <contact fullname="Paul Fremantl
iscussions on MQTT v5.0 support. e"/> for the initial discussions on MQTT v5.0 support.
</t> </t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 226 change blocks. 
1958 lines changed or deleted 1716 lines changed or added

This html diff was produced by rfcdiff 1.48.