Skip to main content

Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework


(Benjamin Kaduk)

No Objection

Erik Kline
John Scudder
Warren Kumari
Zaheduzzaman Sarker
(Alvaro Retana)
(Martin Vigoureux)
(Robert Wilton)

Note: This ballot was opened for revision 15 and is now closed.

Francesca Palombini
(was Discuss, No Objection) Yes
Comment (2022-03-22 for -16) Sent
Thank you for the work on this document

Many thanks to Jean Mahoney for her ART ART review:, and to the authors for addressing it.

Thanks to Carsten Bormann for his review and text improvement to the IANA registrations for AIF (in the editor copy, to be included in v-17).

Erik Kline
No Objection
John Scudder
No Objection
Murray Kucherawy
(was Discuss) No Objection
Comment (2022-03-22 for -16) Sent
Thanks to Jean Mahoney for her ARTART review.  I encourage the authors to respond at least to what she identified as minor issues.

Thanks for resolving my DISCUSS issue.

The final SHOULD in Section 2.4.2 seems weak to me.  I recommend using a non-BCP 14 "should" instead.
Roman Danyliw
No Objection
Comment (2022-03-08 for -15) Sent
** Section 2.

   If the Client is resource-constrained or does not support HTTPS, a
   separate Client Authorization Server may carry out the token request
   on behalf of the Client, and later, onboard the Client with the

Appreciating that the CAS is out of scope, I’m trying to understand which of the (A) – (F) interactions are handled by the Client and which would be handled by the CAS.  Figure 1 is a ambiguous.  (A) and (B) seem like they would be covered by the CAS, but I’m assuming (C) and (D) are the Client after being provisioned with the access token (from A and B).  Is that correct?  If so, it would be helpful to clarify that in the text and/or diagram.

** Section 3.3.
   As a response to the SUBSCRIBE packet, the Broker issues a SUBACK.
   For each Topic Filter, the SUBACK packet includes a return code
   matching the QoS level for the corresponding Topic Filter.  In the
   case of failure, the return code is 0x87, indicating that the Client
   is 'Not authorized'.  A reason code is returned for each Topic

This may be a detail of MQTT.  Does the explicit use of “not authorized” vs. “not authorized/not found” leak the existence of a topic name to an off-path attacker?  It seems that with “not authorized” semantics, one could try to guess topic name with enumeration, say, try 1: “/topic/is-the-sensitive-project-called-A”, try 2: “/topic/is-the-sensitive-project-called-B”, etc.

Editorial Nits 

** Section 1. Editorial. s/The Client-AS and RS-AS/The Client-AS and RS-AS communication/

** Section 1.3.  Editorial.  Chose either the “65535” or “65,535” convention (comma or no comma).  “UTF-8 string” uses the former and “binary data” uses the latter

** Section 1.2. Editorial.  SUBACK.  Describe the who is the sender and receiver like in the other message types.

Subscribe acknowledgement.

Subscribe acknowledgement from the Broker to the Client.

** Section 2.  Editorial.
   The token request and
   response use the token endpoint at the AS, specified for HTTP-based
   interactions in Section 5.8 of the ACE framework

This reference should likely read Section 4 of [I-D.ietf-ace-oauth-authz] as this section included the bullet protocol flow from (A) – (E).

** Section 2.3.  Should it be MQTT messages vs. MQTT packets?  For example, in “… to allow a Client’s future PUBLISH and SUBSCRIBE packets”.

** Section 3.3.  Editorial.  s/token token/token scope which/
Warren Kumari
No Objection
Zaheduzzaman Sarker
No Objection
Benjamin Kaduk Former IESG member
Yes (for -15) Unknown

Alvaro Retana Former IESG member
No Objection
No Objection (for -15) Not sent

Lars Eggert Former IESG member
No Objection
No Objection (2022-03-07 for -15) Sent
Found terminology that should be reviewed for inclusivity; see for background and more

 * Term "master"; alternatives might be "active", "central", "initiator",
   "leader", "main", "orchestrator", "parent", "primary", "server".

 * Term "his"; alternatives might be "they", "them", "their".

 * Term "invalid"; alternatives might be "not valid", "unenforceable", "not
   binding", "inoperative", "illegitimate", "incorrect", "improper",
   "unacceptable", "inapplicable", "revoked", "rescinded".

Thanks to Theresa Enghardt for their General Area Review Team (Gen-ART) review

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via, so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2.1. , paragraph 5, nit:
>    This document follows [RFC7800] for PoP semantics for JWTs (CWTs can
>    also be used).  The PoP token includes a 'cnf' parameter with a

s/can/MAY/ ?

Section 2.2.2. , paragraph 4, nit:
-    DISCONNECT packet as explained below.
+    DISCONNECT packet, as explained below.
+                     +

Section 2. , paragraph 4, nit:
> e RPK case is handled as described in in Section 3.2.1 of the DTLS profile [
>                                    ^^^^^
Possible typo: you repeated a word.

Section 2.2.1. , paragraph 2, nit:
> lient MUST validate a public key from a X.509 certificate or an RPK from the
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 2.2.1. , paragraph 7, nit:
>  equal to 0, and the token is invalid or the claims cannot be obtained in the
>                                      ^^^
Use a comma before "or" if it connects two independent clauses (unless they are
closely connected and short).

Section 2.2.3. , paragraph 2, nit:
> to an earlier proposal by Fremantle et al [fremantle14]. After sending the C
>                                     ^^^^^
A period is misplaced or missing.

Section , paragraph 3, nit:
>  as shown in Figure 7 and includes the the 8-byte Client nonce, and the signa
>                                    ^^^^^^^
Possible typo: you repeated a word.

Section 2.2.5. , paragraph 3, nit:
> ame or filter in question is either an an exact match to or a subset of at le
>                                     ^^^^^
Possible typo: you repeated a word.

Section 2.4.1. , paragraph 3, nit:
> est for topic "a/b/*", and has a token token permits "a/*", this is a valid s
>                                  ^^^^^^^^^^^
Possible typo: you repeated a word.

Section 10.1. , paragraph 23, nit:
>  broker. * Added a statement that the the broker will disconnect on almost an
>                                   ^^^^^^^
Possible typo: you repeated a word.

Uncited references:
     [I-D.ietf-ace-oauth-params], [RFC8422], [RFC7251], and [RFC8705].

Document references draft-ietf-ace-aif-05, but -06 is the latest available

Document references draft-ietf-ace-pubsub-profile-01, but -04 is the latest
available revision.

These URLs in the document did not return content:

These URLs in the document can probably be converted to HTTPS:
Martin Vigoureux Former IESG member
No Objection
No Objection (for -15) Not sent

Robert Wilton Former IESG member
No Objection
No Objection (for -15) Not sent