draft-ietf-ace-mqtt-tls-profile-04.txt   draft-ietf-ace-mqtt-tls-profile-05.txt 
ACE Working Group C. Sengul ACE Working Group C. Sengul
Internet-Draft Brunel University Internet-Draft Brunel University
Intended status: Standards Track A. Kirby Intended status: Standards Track A. Kirby
Expires: September 10, 2020 Oxbotica Expires: November 29, 2020 Oxbotica
P. Fremantle P. Fremantle
University of Portsmouth University of Portsmouth
March 9, 2020 May 28, 2020
MQTT-TLS profile of ACE MQTT-TLS profile of ACE
draft-ietf-ace-mqtt-tls-profile-04 draft-ietf-ace-mqtt-tls-profile-05
Abstract Abstract
This document specifies a profile for the ACE (Authentication and This document specifies a profile for the ACE (Authentication and
Authorization for Constrained Environments) framework to enable Authorization for Constrained Environments) framework to enable
authorization in an MQTT-based publish-subscribe messaging system. authorization in an MQTT-based publish-subscribe messaging system.
Proof-of-possession keys, bound to OAuth2.0 access tokens, are used Proof-of-possession keys, bound to OAuth2.0 access tokens, are used
to authenticate and authorize MQTT Clients. The protocol relies on to authenticate and authorize MQTT Clients. The protocol relies on
TLS for confidentiality and MQTT server (broker) authentication. TLS for confidentiality and MQTT server (broker) authentication.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2020. This Internet-Draft will expire on November 29, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 14
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. ACE-Related Terminology . . . . . . . . . . . . . . . . . 4 1.2. ACE-Related Terminology . . . . . . . . . . . . . . . . . 4
1.3. MQTT-Related Terminology . . . . . . . . . . . . . . . . 5 1.3. MQTT-Related Terminology . . . . . . . . . . . . . . . . 4
2. Authorizing Connection Requests . . . . . . . . . . . . . . . 7 2. Authorizing Connection Requests . . . . . . . . . . . . . . . 7
2.1. Client Token Request to the Authorization Server (AS) . . 8 2.1. Client Token Request to the Authorization Server (AS) . . 8
2.2. Client Connection Request to the Broker (C) . . . . . . . 9 2.2. Client Connection Request to the Broker (C) . . . . . . . 9
2.2.1. Client-Server Authentication over TLS and MQTT . . . 9 2.2.1. Client-Server Authentication over TLS and MQTT . . . 9
2.2.2. authz-info: The Authorization Information Topic . . . 10 2.2.2. authz-info: The Authorization Information Topic . . . 10
2.2.3. Transporting Access Token Inside the MQTT CONNECT . . 11 2.2.3. Transporting Access Token Inside the MQTT CONNECT . . 11
2.2.4. Authentication Using AUTH Property . . . . . . . . . 12 2.2.4. Authentication Using AUTH Property . . . . . . . . . 13
2.2.4.1. Proof-of-Possession Using a Challenge from the 2.2.4.1. Proof-of-Possession Using a Challenge from the
TLS session . . . . . . . . . . . . . . . . . . . 13 TLS session . . . . . . . . . . . . . . . . . . . 13
2.2.4.2. Proof-of-Possession via Broker-generated 2.2.4.2. Proof-of-Possession via Broker-generated
Challenge/Response . . . . . . . . . . . . . . . 13 Challenge/Response . . . . . . . . . . . . . . . 13
2.2.4.3. Unauthorised Request: Authorisation Server
Discovery . . . . . . . . . . . . . . . . . . . . 14
2.2.5. Token Validation . . . . . . . . . . . . . . . . . . 14 2.2.5. Token Validation . . . . . . . . . . . . . . . . . . 14
2.2.6. The Broker's Response to Client Connection Request . 15 2.2.6. The Broker's Response to Client Connection Request . 15
3. Authorizing PUBLISH and SUBSCRIBE Messages . . . . . . . . . 15 2.2.6.1. Unauthorised Request: Authorisation Server
Discovery . . . . . . . . . . . . . . . . . . . . 15
2.2.6.2. Authorisation Success . . . . . . . . . . . . . . 15
3. Authorizing PUBLISH and SUBSCRIBE Messages . . . . . . . . . 16
3.1. PUBLISH Messages from the Publisher Client to the Broker 16 3.1. PUBLISH Messages from the Publisher Client to the Broker 16
3.2. PUBLISH Messages from the Broker to the Subscriber 3.2. PUBLISH Messages from the Broker to the Subscriber
Clients . . . . . . . . . . . . . . . . . . . . . . . . . 16 Clients . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3. Authorizing SUBSCRIBE Messages . . . . . . . . . . . . . 16 3.3. Authorizing SUBSCRIBE Messages . . . . . . . . . . . . . 17
4. Token Expiration and Reauthentication . . . . . . . . . . . . 17 4. Token Expiration and Reauthentication . . . . . . . . . . . . 17
5. Handling Disconnections and Retained Messages . . . . . . . . 18 5. Handling Disconnections and Retained Messages . . . . . . . . 18
6. Reduced Protocol Interactions for MQTT v3.1.1 . . . . . . . . 18 6. Reduced Protocol Interactions for MQTT v3.1.1 . . . . . . . . 18
6.1. Token Transport . . . . . . . . . . . . . . . . . . . . . 18 6.1. Token Transport . . . . . . . . . . . . . . . . . . . . . 19
6.2. Handling Authorization Errors . . . . . . . . . . . . . . 20 6.2. Handling Authorization Errors . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Checklist for profile requirements . . . . . . . . . 24 Appendix A. Checklist for profile requirements . . . . . . . . . 25
Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 25 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 25
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
This document specifies a profile for the ACE framework This document specifies a profile for the ACE framework
[I-D.ietf-ace-oauth-authz]. In this profile, Clients and Server [I-D.ietf-ace-oauth-authz]. In this profile, Clients and Server
(Broker) use MQTT to exchange Application Messages. The protocol (Broker) use MQTT to exchange Application Messages. The protocol
relies on TLS for communication security between entities. The MQTT relies on TLS for communication security between entities. The MQTT
protocol interactions are described based on the MQTT v5.0 - the protocol interactions are described based on the MQTT v5.0 - the
OASIS Standard [MQTT-OASIS-Standard-v5]. Since it is expected that OASIS Standard [MQTT-OASIS-Standard-v5]. Since it is expected that
MQTT deployments will continue to support MQTT v3.1.1 clients, this MQTT deployments will continue to support MQTT v3.1.1 clients, this
skipping to change at page 3, line 51 skipping to change at page 3, line 51
o Connection requests from the Clients to the Broker o Connection requests from the Clients to the Broker
o Publish requests from the Clients to the Broker, and from the o Publish requests from the Clients to the Broker, and from the
Broker to the Clients Broker to the Clients
o Subscribe requests from Clients to the Broker o Subscribe requests from Clients to the Broker
Clients use MQTT PUBLISH message to publish to a topic. This Clients use MQTT PUBLISH message to publish to a topic. This
document does not protect the payload of the PUBLISH message from the document does not protect the payload of the PUBLISH message from the
Broker, and hence, the payload is not signed or encrypted specificaly Broker. Hence, the payload is not signed or encrypted specifically
for the subscribers. This functionality may be implemented using the for the subscribers. This functionality may be implemented using the
proposal outlined in the CoAP Pub-Sub Profile proposal outlined in the CoAP Pub-Sub Profile
[I-D.ietf-ace-pubsub-profile]. [I-D.ietf-ace-pubsub-profile].
To provide communication confidentiality and RS authentication, TLS To provide communication confidentiality and RS authentication, TLS
is used and TLS 1.3 is RECOMMENDED. This document makes the same is used, and TLS 1.3 is RECOMMENDED. This document makes the same
assumptions as the Section 4 of the ACE framework assumptions as Section 4 of the ACE framework
[I-D.ietf-ace-oauth-authz] regarding Client and RS registration with [I-D.ietf-ace-oauth-authz] regarding Client and RS registration with
the AS and setting up keying material. While the Client-Broker the AS and setting up keying material. While the Client-Broker
exchanges are only over MQTT, the required Client-AS and RS-AS exchanges are only over MQTT, the required Client-AS and RS-AS
interactions are described for HTTPS-based communication, using interactions are described for HTTPS-based communication, using
'application/ace+json' content type, and unless otherwise specified, 'application/ace+json' content type, and unless otherwise specified,
using JSON encoding. The token may be a reference, or JSON Web Token using JSON encoding. The token may be a reference or JSON Web Token
(JWT). For JWT tokens, this document follows RFC 7800 [RFC7800] for (JWT). For JWTs, this document follows RFC 7800 [RFC7800] for PoP
PoP semantics for JWTs. The Client-AS and RS-AS MAY also use semantics for JWTs. The Client-AS and RS-AS MAY also use protocols
protocols other than HTTP e.g., CoAP or MQTT. Implementations MAY other than HTTP, e.g. CoAP or MQTT. Implementations MAY also use
also use 'application/ace+cbor' content type, and CBOR encoding, and 'application/ace+cbor' content type, and CBOR encoding, and CBOR Web
CBOR Web Token (CWT) and associated PoP semantics to reduce the Token (CWT) and associated PoP semantics to reduce the protocol
protocol memory and bandwidth requirements. For more information on memory and bandwidth requirements. For more information, see Proof-
Proof of Possession semantics for CWTs, see Proof-of-Possession Key of-Possession Key Semantics for CBOR Web Tokens (CWTs) [RFC8747].
Semantics for CBOR Web Tokens (CWTs)
[I-D.ietf-ace-cwt-proof-of-possession].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174], when, and only when, they appear in all 14 [RFC2119] [RFC8174], when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. ACE-Related Terminology 1.2. ACE-Related Terminology
The terminology for entities in the architecture is defined in OAuth The terminology for entities in the architecture is defined in OAuth
2.0 RFC 6749 [RFC6749] such as "Client" (C), "Resource Server" (RS) 2.0 RFC 6749 [RFC6749] such as "Client" (C), "Resource Server" (RS)
and "Authorization Server" (AS). and "Authorization Server" (AS).
skipping to change at page 5, line 9 skipping to change at page 4, line 50
that can authoritatively speak for the topic. that can authoritatively speak for the topic.
Certain security-related terms such as "authentication", Certain security-related terms such as "authentication",
"authorization", "confidentiality", "(data) integrity", "message "authorization", "confidentiality", "(data) integrity", "message
authentication code", and "verify" are taken from RFC 4949 [RFC4949]. authentication code", and "verify" are taken from RFC 4949 [RFC4949].
1.3. MQTT-Related Terminology 1.3. MQTT-Related Terminology
The document describes message exchanges as MQTT protocol The document describes message exchanges as MQTT protocol
interactions. The Clients are MQTT Clients, which connect to the interactions. The Clients are MQTT Clients, which connect to the
Broker to publish and subscribe to Application Messages, labeled with Broker to publish and subscribe to Application Messages, labelled
their topics. For additional information, please refer to the MQTT with their topics. For additional information, please refer to the
v5.0 - the OASIS Standard [MQTT-OASIS-Standard-v5] or the MQTT v3.1.1 MQTT v5.0 - the OASIS Standard [MQTT-OASIS-Standard-v5] or the MQTT
- the OASIS Standard [MQTT-OASIS-Standard]. v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard].
MQTTS MQTTS
Secured transport profile of MQTT. MQTTS runs over TLS. Secured transport profile of MQTT. MQTTS runs over TLS.
Broker Broker
The Server in MQTT. It acts as an intermediary between the The Server in MQTT. It acts as an intermediary between the
Clients that publishes Application Messages, and the Clients Clients that publishes Application Messages, and the Clients
that made Subscriptions. The Broker acts as the Resource that made Subscriptions. The Broker acts as the Resource
Server for the Clients. Server for the Clients.
skipping to change at page 5, line 42 skipping to change at page 5, line 35
Message. The QoS level can be 0-2, where "0" indicates "At Message. The QoS level can be 0-2, where "0" indicates "At
most once delivery", "1" "At least once delivery", and "2" most once delivery", "1" "At least once delivery", and "2"
"Exactly once delivery". "Exactly once delivery".
Topic Name Topic Name
The label attached to an Application Message, which is The label attached to an Application Message, which is
matched to a Subscription. matched to a Subscription.
Subscription Subscription
A Subscription comprises a Topic Filter and a maximum Quality A Subscription comprises a Topic Filter and a maximum Quality
of Service (QoS).A Subscription is associated with a single of Service (QoS). A Subscription is associated with a single
session. session.
Topic Filter Topic Filter
An expression that indicates interest in one or more Topic An expression that indicates interest in one or more Topic
Names. Topic Filters may include wildcards. Names. Topic Filters may include wildcards.
MQTT sends various control messages across a network connection. The MQTT sends various control messages across a network connection. The
following is not an exhaustive list and the control packets that are following is not an exhaustive list and the control packets that are
not relevant for authorization are not explained. These include, for not relevant for authorization are not explained. These include, for
instance, the PUBREL and PUBCOMP packets used in the 4-step handshake instance, the PUBREL and PUBCOMP packets used in the 4-step handshake
required for the QoS level 2. required for QoS level 2.
CONNECT CONNECT
Client request to connect to the Broker. This is the first Client request to connect to the Broker. This is the first
packet sent by a Client. packet sent by a Client.
CONNACK CONNACK
The Broker connection acknowledgment. The first packet sent The Broker connection acknowledgment. The first packet sent
from the Broker to a Client is a CONNACK packet. CONNACK from the Broker to a Client is a CONNACK packet. CONNACK
packets contain return codes indicating either a success or packets contain return codes indicating either a success or
an error state to a Client. an error state to a Client.
AUTH AUTH
Authentication Exchange. An AUTH packet is sent from the Authentication Exchange. An AUTH packet is sent from the
Client to the Broker or to the Broker to the Client as part Client to the Broker or from the Broker to the Client as part
of an extended authentication exchange. AUTH Properties of an extended authentication exchange. AUTH Properties
include Authentication Method and Authentication Data. The include Authentication Method and Authentication Data. The
Authentication Method is set in the CONNECT packet, and Authentication Method is set in the CONNECT packet, and
consequent AUTH packets follow the same Authentication consequent AUTH packets follow the same Authentication
Method. The contents of the Authentication Data are defined Method. The contents of the Authentication Data are defined
by the Authentication Method. by the Authentication Method.
PUBLISH PUBLISH
Publish request sent from a publishing Client to the Broker, Publish request sent from a publishing Client to the Broker,
or from the Broker to a subscribing Client. or from the Broker to a subscribing Client.
skipping to change at page 7, line 8 skipping to change at page 6, line 50
A ping request sent from a Client to the Broker. It signals A ping request sent from a Client to the Broker. It signals
to the Broker that the Client is alive, and is used to to the Broker that the Client is alive, and is used to
confirm that the Broker is also alive. The "Keep Alive" confirm that the Broker is also alive. The "Keep Alive"
period is set in the CONNECT message. period is set in the CONNECT message.
PINGRESP PINGRESP
Response sent by the Broker to the Client in response to Response sent by the Broker to the Client in response to
PINGREQ. It indicates the Broker is alive. PINGREQ. It indicates the Broker is alive.
Will Will
If the network connection is not closed normally, the Server If the network connection is not closed normally, the Broker
sends a last Will message for the Client, if the Client sends a last Will message for the Client, if the Client
provided one in its CONNECT message. If the Will Flag is provided one in its CONNECT message. If the Will Flag is
set, then the payload of the CONNECT message includes set, then the payload of the CONNECT message includes
information about the Will. The information consists of the information about the Will. The information consists of the
Will Properties, Will Topic, and Will Payload fields. Will Properties, Will Topic, and Will Payload fields.
2. Authorizing Connection Requests 2. Authorizing Connection Requests
This section specifies how Client connections are authorized by the This section specifies how Client connections are authorized by the
MQTT Broker. Figure 1 shows the basic protocol flow during MQTT Broker. Figure 1 shows the basic protocol flow during
connection set-up.The token request and response use the token connection set-up. The token request and response use the token
endpoint at the AS, specified in the Section 5.6 of the ACE framework endpoint at the AS, specified in Section 5.6 of the ACE framework
[I-D.ietf-ace-oauth-authz]. Steps (D) and (E) are optional, and use [I-D.ietf-ace-oauth-authz]. Steps (D) and (E) are optional and use
the introspection endpoint, specified in the Section 5.7 of the ACE the introspection endpoint, specified in Section 5.7 of the ACE
framework. The Client and Broker use HTTPS to communicate to AS via framework. The Client and the Broker use HTTPS to communicate to AS
these endpoints. The Client and Broker use only MQTT to communicate via these endpoints. The Client and the Broker use MQTT to
between them. communicate between them.
If the Client is resource-constrained, a Client Authorisation Server If the Client is resource-constrained, a Client Authorisation Server
may carry out the token request on behalf of the Client, and later, may carry out the token request on behalf of the Client, and later,
onboard the Client with the token. Also, the C-AS and Broker-AS onboard the Client with the token. Also, the C-AS and Broker-AS
interfaces may be implemented using protocols other than HTTPS, e.g., interfaces may be implemented using protocols other than HTTPS, e.g.
CoAP or MQTT. The interactions between a Client and its Client CoAP or MQTT. The interactions between a Client and its Client
Authorization Server for token onboarding, and the MQTTS support for Authorization Server for token onboarding, and support for MQTTS-
token requests are out of scope of this document. based token requests at the AS are out of scope of this document.
+---------------------+ +---------------------+
| Client | | Client |
| | | |
+---(A) Token request--| Client - | +---(A) Token request--| Client - |
| | Authorization | | | Authorization |
| +-(B) Access token-> Server Interface | | +-(B) Access token-> Server Interface |
| | | (HTTPS) | | | | (HTTPS) |
| | |_____________________| | | |_____________________|
| | | | | | | |
skipping to change at page 8, line 37 skipping to change at page 8, line 37
| | (HTTPS) | | | (HTTPS) |
+-(E)Introspection---->|__________________| +-(E)Introspection---->|__________________|
response (optional) response (optional)
Figure 1: Connection set-up Figure 1: Connection set-up
2.1. Client Token Request to the Authorization Server (AS) 2.1. Client Token Request to the Authorization Server (AS)
The first step in the protocol flow (Figure 1 (A)) is the token The first step in the protocol flow (Figure 1 (A)) is the token
acquisition by the Client from the AS. The Client and the AS MUST acquisition by the Client from the AS. The Client and the AS MUST
perform mutual authentication. When requesting an access token from perform mutual authentication. The Client requests an access token
the AS, the Client follows the token request as described in from the AS as described in Section 5.6.1 of the ACE framework
Section 5.6.1 of the ACE framework [I-D.ietf-ace-oauth-authz], [I-D.ietf-ace-oauth-authz], however, it MUST set the profile
howevever, it MUST set the profile parameter to 'mqtt_tls'. The parameter to 'mqtt_tls'. The media format is 'application/ace+json'.
media format is 'application/ace+json'. The AS uses JSON in the The AS uses JSON in the payload of its responses to both to the
payload of its responses to both to the Client and the RS. Client and the RS.
If the AS successfully verifies the access token request and If the AS successfully verifies the access token request and
authorizes the Client for the indicated audience (i.e., RS) and authorizes the Client for the indicated audience (i.e. RS) and
scopes (i.e., publish/subscribe permissions over topics), the AS scopes (i.e. publish/subscribe permissions over topics), the AS
issues an access token (Figure 1 (B)). The response includes the issues an access token (Figure 1 (B)). The response includes the
parameters described in Section 5.6.2 of the ACE framework parameters described in Section 5.6.2 of the ACE framework
[I-D.ietf-ace-oauth-authz]. The included token is assumed to be [I-D.ietf-ace-oauth-authz]. The returned token is assumed to be
Proof-of-Possession (PoP) token by default. This document follows Proof-of-Possession (PoP) token by default. This document follows
RFC 7800 [RFC7800] for PoP semantics for JWTs. The PoP token RFC 7800 [RFC7800] for PoP semantics for JWTs. The PoP token
includes a 'cnf' parameter with a symmetric or asymmetric PoP key. includes a 'cnf' parameter with a symmetric or asymmetric PoP key.
Note that the 'cnf' parameter in the web tokens are to be consumed by Note that the 'cnf' parameter in the web tokens are to be consumed by
the RS and not the Client. The PoP token may include a 'rs_cnf' the RS and not the Client. For the asymmetric case, the PoP token
parameter containing the information about the public key used by the may include the 'rs_cnf' parameter containing the information about
RS to authenticate as described in [I-D.ietf-ace-oauth-params]. the public key used by the RS to authenticate as described in
[I-D.ietf-ace-oauth-params].
The AS returns error responses for JSON-based interactions following The AS returns error responses for JSON-based interactions following
the Section 5.2 of RFC 6749 [RFC6749]. When CBOR is used, the Section 5.2 of RFC 6749 [RFC6749]. When CBOR is used, the
interactions must implement the Section 5.6.3 of ACE framework interactions must implement Section 5.6.3 of the ACE framework
[I-D.ietf-ace-oauth-authz]. [I-D.ietf-ace-oauth-authz].
2.2. Client Connection Request to the Broker (C) 2.2. Client Connection Request to the Broker (C)
2.2.1. Client-Server Authentication over TLS and MQTT 2.2.1. Client-Server Authentication over TLS and MQTT
The Client and the Broker MUST perform mutual authentication. The The Client and the Broker MUST perform mutual authentication. The
Client MUST authenticate to the Broker either over MQTT or TLS. For Client MUST authenticate to the Broker either over MQTT or TLS. For
MQTT, the options are "None" and "ace". For TLS, the options are MQTT, the options are "None" and "ace". For TLS, the options are
"Anon" for anonynous client, and "Known(RPK/PSK)" for Raw Public Keys "Anon" for an anonymous client, and "Known(RPK/PSK)" for Raw Public
(RPK) and Pre-Shared Keys (PSK), respectively. Combined, the Client Keys (RPK) and Pre-Shared Keys (PSK), respectively. Combined, client
authentication takes the following options: authentication has the following options:
o "TLS:Anon-MQTT:None": This option is used only for the topics that o "TLS:Anon-MQTT:None": This option is used only for the topics that
do not require authorization, including the "authz-info" topic. do not require authorization, including the "authz-info" topic.
Publishing to the "authz-info" topic is described in Publishing to the "authz-info" topic is described in
Section 2.2.2. Section 2.2.2.
o "TLS:Anon-MQTT:ace": The token is transported inside the CONNECT o "TLS:Anon-MQTT:ace": The token is transported inside the CONNECT
message, and MUST be validated using one of the methods described message, and MUST be validated using one of the methods described
in Section 2.2.2. This option also supports a tokenless in Section 2.2.2. This option also supports a tokenless
connection request for AS discovery. connection request for AS discovery.
skipping to change at page 10, line 6 skipping to change at page 10, line 7
It is RECOMMENDED that the Client follows TLS:Anon-MQTT:ace. It is RECOMMENDED that the Client follows TLS:Anon-MQTT:ace.
The Broker MUST be authenticated during the TLS handshake. If the The Broker MUST be authenticated during the TLS handshake. If the
Client authentication uses TLS:Known(RPK/PSK), then the Broker is Client authentication uses TLS:Known(RPK/PSK), then the Broker is
authenticated using the respective method. Otherwise, to authenticated using the respective method. Otherwise, to
authenticate the Broker, the client MUST validate a public key from a authenticate the Broker, the client MUST validate a public key from a
X.509 certificate or an RPK from the Broker against the 'rs_cnf' X.509 certificate or an RPK from the Broker against the 'rs_cnf'
parameter in the token response. The AS MAY include the thumbprint parameter in the token response. The AS MAY include the thumbprint
of the RS's X.509 certificate in the 'rs_cnf' (thumbprint as defined of the RS's X.509 certificate in the 'rs_cnf' (thumbprint as defined
in [I-D.ietf-cose-x509]), then the client MUST validate the RS in [I-D.ietf-cose-x509]). In this case, the client MUST validate the
certificate against this thumbprint. RS certificate against this thumbprint.
2.2.2. authz-info: The Authorization Information Topic 2.2.2. authz-info: The Authorization Information Topic
In the cases when the Client MUST transport the token to the Broker In the cases when the Client MUST transport the token to the Broker
first, the Client connects to the Broker to publish its token to the first, the Client connects to the Broker to publish its token to the
"authz-info" topic. The "authz-info" topic MUST be publish-only "authz-info" topic. The "authz-info" topic MUST be publish-only
(i.e., the Clients are not allowed to subscribe to it). "authz-info" (i.e. the Clients are not allowed to subscribe to it). "authz-info"
is not protected, and hence, the Client uses the "TLS:Anon-MQTT:None" is not protected, and hence, the Client uses the "TLS:Anon-MQTT:None"
option over a TLS connection. After publishing the token, the Client option over a TLS connection. After publishing the token, the Client
disconnects from the Broker and is expected to reconnect, potentially disconnects from the Broker and is expected to reconnect using client
using client authentication with TLS. authentication over TLS.
The Broker stores and indexes all tokens received to this topic in The Broker stores and indexes all tokens received to the "authz-info"
its key store similar to DTLS profile for ACE topic in its key store (similar to DTLS profile for ACE
[I-D.ietf-ace-dtls-authorize]. This profile follows the [I-D.ietf-ace-dtls-authorize]). This profile follows the
recommendation of Section 5.8.1 of ACE framework recommendation of Section 5.8.1 of the ACE framework
[I-D.ietf-ace-oauth-authz], and expects that RS stores only one token [I-D.ietf-ace-oauth-authz], and expects that the Broker stores only
per proof-of-possession key, and any other token linked to the same one token per proof-of-possession key, and any other token linked to
key overwrites existing token at the RS. the same key overwrites an existing token.
The Broker MUST verify the validity of the token (i.e., through local The Broker MUST verify the validity of the token (i.e. through local
validation or introspection) as described in Section 2.2.5. To validation or introspection) as described in Section 2.2.5. To
validate the token, RS MAY need to introspect the token with the AS validate the token, RS MAY need to introspect the token with the AS,
e.g., if the token is a reference. If the token is not valid, the e.g. if the token is a reference. If the token is not valid, the
Broker MUST discard the token. Depending on the QoS level of the Broker MUST discard the token. Depending on the QoS level of the
PUBLISH message, the Broker may return the error response as a PUBACK PUBLISH message, the Broker may return the error response as a PUBACK
or a DISCONNECT message. or a DISCONNECT message.
If the QoS level is equal to 0, and token is invalid or the claims If the QoS level is equal to 0, and the token is invalid or the
cannot be obtained in the case of an introspected token, the Broker claims cannot be obtained in the case of an introspected token, the
MUST send a DISCONNECT message with the reason code '0x87 (Not Broker MUST send a DISCONNECT message with the reason code '0x87 (Not
authorized)'. If the token does not parse to a token, the RS MUST authorized)'. If the PUBLISH payload does not parse to a token, the
send a DISCONNECT with the reason code '0x99 (Payload format RS MUST send a DISCONNECT with the reason code '0x99 (Payload format
invalid)'. invalid)'.
For the QoS level of the PUBLISH message is greater than or equal to If the QoS level of the PUBLISH message is greater than or equal to
1, the Broker MAY return 'Not authorized' in PUBACK. If the token 1, the Broker MUST return 'Not authorized' in PUBACK. If the PUBLISH
does not parse to a token, the PUBACK reason code is '0x99 (Payload payload does not parse to a token, the PUBACK reason code is '0x99
format invalid)'. (Payload format invalid)'.
It must be noted that when the RS sends the 'Not authorized' It must be noted that when the RS sends the 'Not authorized'
response, this corresponds to the token being invalid, and not that response, this corresponds to the token being invalid, and not that
the actual PUBLISH message was not authorized. Given that the the actual PUBLISH message was not authorized. Given that the
"authz-info" is a public topic, this response is not expected to "authz-info" is a public topic, this response is not expected to
cause a confusion. cause confusion.
2.2.3. Transporting Access Token Inside the MQTT CONNECT 2.2.3. Transporting Access Token Inside the MQTT CONNECT
This section describes how the Client transports the token to the This section describes how the Client transports the token to the
Broker (RS) inside the CONNECT message. If this method is used, the Broker (RS) inside the CONNECT message. If this method is used, the
Client TLS connection is expected to be anonymous, and the Broker is Client TLS connection is expected to be anonymous, and the Broker is
authenticated during the TLS connection set-up. The approach authenticated during the TLS connection set-up. The approach
described in this section is similar to an earlier proposal by described in this section is similar to an earlier proposal by
Fremantle et al. [fremantle14]. Fremantle et al [fremantle14].
Figure 2 shows the structure of the MQTT CONNECT message used in MQTT Figure 2 shows the structure of the MQTT CONNECT message used in MQTT
v5.0. A CONNECT message is composed of a fixed header, a variable v5.0. A CONNECT message is composed of a fixed header, a variable
header and a payload. The fixed header contains the Control Packet header and a payload. The fixed header contains the Control Packet
Type (CPT), Reserved, and Remaining Length fields. The Variable Type (CPT), Reserved, and Remaining Length fields. The Variable
Header contains the Protocol Name, Protocol Level, Connect Flags, Header contains the Protocol Name, Protocol Level, Connect Flags,
Keep Alive, and Properties fields. The Connect Flags in the variable Keep Alive, and Properties fields. The Connect Flags in the variable
header specify the properties of the MQTT session. It also indicates header specify the properties of the MQTT session. It also indicates
the presence or absence of some fields in the Payload. The payload the presence or absence of some fields in the Payload. The payload
contains one or more encoded fields, namely a unique Client contains one or more encoded fields, namely a unique Client
skipping to change at page 11, line 39 skipping to change at page 11, line 39
0 8 16 24 32 0 8 16 24 32
+------------------------------------------------------+ +------------------------------------------------------+
|CPT=1 | Rsvd.|Remaining len.| Protocol name len. = 4 | |CPT=1 | Rsvd.|Remaining len.| Protocol name len. = 4 |
+------------------------------------------------------+ +------------------------------------------------------+
| 'M' 'Q' 'T' 'T' | | 'M' 'Q' 'T' 'T' |
+------------------------------------------------------+ +------------------------------------------------------+
| Proto.level=5|Connect flags| Keep alive | | Proto.level=5|Connect flags| Keep alive |
+------------------------------------------------------+ +------------------------------------------------------+
| Property length | | Property length |
| Auth. Method (0x15) | 'ace' | | Auth. Method (0x15) | 'ace' |
| Auth. Data (0x16) | empty or token or | | Auth. Data (0x16) | token or |
| token + PoP data | | token + PoP data |
+------------------------------------------------------+ +------------------------------------------------------+
| Payload | | Payload |
+------------------------------------------------------+ +------------------------------------------------------+
Figure 2: MQTT v5 CONNECT control message with ACE authentication. Figure 2: MQTT v5 CONNECT control message with ACE authentication.
(CPT=Control Packet Type) (CPT=Control Packet Type)
The CONNECT message flags are Username, Password, Will retain, Will The CONNECT message flags are Username, Password, Will retain, Will
QoS, Will Flag, Clean Start, and Reserved. Figure 6 shows how the QoS, Will Flag, Clean Start, and Reserved. Figure 6 shows how the
MQTT connect flags MUST be set to use AUTH packets for authentication flags MUST be set to use AUTH packets for authentication and
and authorisation. To use AUTH, the username and password flags MUST authorisation, i.e. the username and password flags MUST be set to 0.
be set to 0. The RS MAY support token transport using username and
password and the CONNECT message for that option is described in An MQTT v5.0 RS MAY also support token transport using Username and
Section 6 for MQTT v3.1.1, which is the only option available to MQTT Password to provide a security option for MQTT v3.1.1 clients, as
v3.1.1. described in Section 6.
+-----------------------------------------------------------+ +-----------------------------------------------------------+
|User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.| |User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.|
| Flag |Flag | | | |Start| | | Flag |Flag | | | |Start| |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| 0 | 0 | X | X X | X | X | 0 | | 0 | 0 | X | X X | X | X | 0 |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
Figure 3: CONNECT flags for AUTH Figure 3: CONNECT flags for AUTH
The Will Flag indicates that a Will message needs to be sent if The Will Flag indicates that a Will message needs to be sent if the
network connection is not closed normally. The situations in which network connection is not closed normally. The situations in which
the Will message is published include disconnections due to I/O or the Will message is published include disconnections due to I/O or
network failures, and the server closing the network connection due network failures, and the server closing the network connection due
to a protocol error. The Client may set the Will Flag as desired to a protocol error. The Client may set the Will Flag as desired
(marked as 'X' in Figure 3). If the Will Flag is set to 1 and the (marked as 'X' in Figure 3). If the Will Flag is set to 1 and the
Broker accepts the connection request, the Broker must store the Will Broker accepts the connection request, the Broker must store the Will
message, and publish it when the network connection is closed message and publish it when the network connection is closed
according to Will QoS and Will retain parameters, and MQTT Will according to Will QoS and Will retain parameters and MQTT Will
management rules. To avoid publishing Will Messages in the case of management rules. To avoid publishing Will Messages in the case of
temporary network disconnections, the Client may specify a Will Delay temporary network disconnections, the Client may specify a Will Delay
Interval in the Will Properties. Section 5 explains how the Broker Interval in the Will Properties. Section 5 explains how the Broker
deals with the retained messages in further detail. deals with the retained messages in further detail.
In MQTT v5, to achieve a clean session (i.e., the session does not In MQTT v5.0, the Client signals a clean session (i.e. the session
continue an existing session), the Client sets the Clean Start Flag does not continue an existing session), by setting the Clean Start
to 1 and, the Session Expiry Interval to 0 in the CONNECT message. Flag to 1 and, the Session Expiry Interval to 0 in the CONNECT
However, in this profile, the Broker MUST always start with a clean message. In this profile, the Broker SHOULD always start with a
session regardless of how these parameters are set. The clean clean session regardless of how these parameters are set. Starting a
session requirement is for avoiding the Broker to keep unnecessary clean session helps the Broker avoid keeping unnecessary session
session state for unauthorised clients. Therefore, the Broker MUST state for unauthorised clients. If the Broker starts a clean
set the Session Present flag to 0 in the CONNACK packet to signal the session, the Broker MUST set the Session Present flag to 0 in the
Client that the Broker started a clean session. CONNACK packet to signal this to the Client.
If necessary, the Broker MAY support session continuation, and hence,
maintain and use client state from the existing session. The client
state MAY include token and its introspection result (for reference
tokens) in addition to the MQTT session state. When reconnecting to
the Broker, the Client MUST still provide a token, as well as setting
the Clean Start to 0 and supplying a Session Expiry interval in the
CONNECT message. The Broker MUST perform proof-of-possession
validation on the provided token. If the token matches the stored
state, the Broker MAY skip introspecting a token by reference, and
use the stored introspection result. Continuing, both the Client and
the Broker MUST resend any unacknowledged PUBLISH packets (where QoS
> 0) and PUBREL packets. The Broker MUST still verify the Client is
authorized to receive or send these packets. When a Client connects
with a long Session Expiry Interval, the Broker may need to maintain
Client's MQTT session state after it disconnects for an extended
period. Brokers SHOULD implement administrative policies to limit
misuse.
2.2.4. Authentication Using AUTH Property 2.2.4. Authentication Using AUTH Property
To use AUTH, the Client MUST set the Authentication Method as a To use AUTH, the Client MUST set the Authentication Method as a
property of a CONNECT packet by using the property identifier 21 property of a CONNECT packet by using the property identifier 21
(0x15). This is followed by a UTF-8 Encoded String containing the (0x15). This is followed by a UTF-8 Encoded String containing the
name of the Authentication Method, which MUST be set to 'ace'. If name of the Authentication Method, which MUST be set to 'ace'. If
the RS does not support this profile, it sends a CONNACK with a the RS does not support this profile, it sends a CONNACK with a
Reason Code of '0x8C (Bad authentication method)'. Reason Code of '0x8C (Bad authentication method)'.
The Authentication Method is followed by the Authentication Data, The Authentication Method is followed by the Authentication Data,
which has a property identifier 22 (0x16) and is binary data. The which has a property identifier 22 (0x16) and is binary data. The
binary data in MQTT is represented by a two-byte integer length, binary data in MQTT is represented by a two-byte integer length,
which indicates the number of data bytes, followed by that number of which indicates the number of data bytes, followed by that number of
bytes. Based on the Authentication Data, this profile allows: bytes. Based on the Authentication Data, this profile allows:
o Proof-of-Possession using a challenge from the TLS session o Proof-of-Possession using a challenge from the TLS session
o Proof-of-Possession via Broker generated challenge/response o Proof-of-Possession via Broker generated challenge/response
o Unauthorised request and Authorisation Server discovery
2.2.4.1. Proof-of-Possession Using a Challenge from the TLS session 2.2.4.1. Proof-of-Possession Using a Challenge from the TLS session
For this option, the Authentication Data MUST contain the two-byte For this option, the Authentication Data MUST contain the two-byte
integer token length, the token, and the keyed message digest (MAC) integer token length, the token, and the keyed message digest (MAC)
or the Client signature. The content to calculate the keyed message or the Client signature. The content to calculate the keyed message
digest (MAC) or the Client signature (for the proof-of-possession) is digest (MAC) or the Client signature (for the proof-of-possession) is
obtained using a TLS exporter ([RFC5705] for TLS 1.2 and for TLS 1.3, obtained using a TLS exporter ([RFC5705] for TLS 1.2 and for TLS 1.3,
Section 7.5 of [RFC8446]). The content is exported from TLS using Section 7.5 of [RFC8446]). The content is exported from TLS using
the exporter label 'EXPORTER-ACE-MQTT-Sign-Challenge', an empty the exporter label 'EXPORTER-ACE-MQTT-Sign-Challenge', an empty
context, and length of 32 bytes. The token is also validated as context, and length of 32 bytes. The token is also validated as
described in Section 2.2.5 and the server responds with a CONNACK described in Section 2.2.5 and, the server responds with a CONNACK
with the appropriate response code. with the appropriate response code. The client cannot reauthenticate
using this method during the same session ( see Section 4). )
2.2.4.2. Proof-of-Possession via Broker-generated Challenge/Response 2.2.4.2. Proof-of-Possession via Broker-generated Challenge/Response
For this option, the RS follows a Broker-generated challenge/response For this option, the RS follows a Broker-generated challenge/response
protocol. The success case is illustrated in Figure 4. If the protocol. The success case is illustrated in Figure 4. If the
Authentication Data only includes the token, the RS MUST respond with Authentication Data contains only the two-byte integer token length
an AUTH packet, with the Authenticate Reason Code set to '0x18 and the token, the RS MUST respond with an AUTH packet, with the
(Continue Authentication)'. This packet includes the Authentication Authenticate Reason Code set to '0x18 (Continue Authentication)'.
Method, which MUST be set to 'ace' and Authentication Data. The This packet includes the Authentication Method, which MUST be set to
Authentication Data MUST NOT be empty and contains an 8-byte nonce as 'ace' and Authentication Data. The Authentication Data MUST NOT be
a challenge for the Client. The Client responds to this with an AUTH empty and contains an 8-byte nonce as a challenge for the Client.
packet with a reason code '0x18 (Continue Authentication)'. The Client responds to this with an AUTH packet with a reason code
Similarly, the Client packet sets the Authentication Method to 'ace'. '0x18 (Continue Authentication)'. Similarly, the Client packet sets
The Authentication Data in the Client's response is formatted as the Authentication Method to 'ace'. The Authentication Data in the
client nonce length, the client nonce, and the signature or MAC Client's response is formatted as the client nonce length, the client
computed over the RS nonce concatenated with the client nonce. Next, nonce, and the signature or MAC computed over the RS nonce
the token is validated as described in Section 2.2.5. concatenated with the client nonce. Next, the token is validated as
described in Section 2.2.5.
The client MAY also re-authenticate using this flow.
Resource Resource
Client Server Client Server
| | | |
|<===========>| TLS connection set-up |<===========>| TLS connection set-up
| | | |
| | | |
+------------>| CONNECT with Authentication Data +------------>| CONNECT with Authentication Data
| | contains only token | | contains only token
| | | |
skipping to change at page 14, line 28 skipping to change at page 14, line 39
| | 8-byte client nonce + signature/MAC | | 8-byte client nonce + signature/MAC
| | | |
| |---+ Token validation | |---+ Token validation
| | | (may involve introspection) | | | (may involve introspection)
| |<--+ | |<--+
| | | |
|<------------+ CONNACK '0x00 (Success)' |<------------+ CONNACK '0x00 (Success)'
Figure 4: PoP Challenge/Response Protocol Flow - Success Figure 4: PoP Challenge/Response Protocol Flow - Success
2.2.4.3. Unauthorised Request: Authorisation Server Discovery
Finally, this document allows the CONNECT message to have the
Authentication Method set to 'ace' omitting the Authentication Data
field. This is the AS discovery option and the RS responds with the
CONNACK reason code '0x87 (Not Authorized)' and includes a User
Property (identified by 38 (0x26)) for the AS Request Creation Hints.
The User Property is a UTF-8 string pair, composed of a name and a
value. The name of the User Property MUST be set to "ace_as_hint".
The value of the user property is a UTF-8 encoded JSON string
containing the mandatory "AS" parameter, and the optional parameters
"audience", "kid", "cnonce", and "scope" as defined in the
Section 5.1.2 of the ACE framework [I-D.ietf-ace-oauth-authz].
2.2.5. Token Validation 2.2.5. Token Validation
The RS MUST verify the validity of the token either locally (e.g., in The RS MUST verify the validity of the token either locally (e.g. in
the case of a self-contained token) or the RS MAY send an the case of a self-contained token) or the RS MAY send an
introspection request to the AS. RS MUST verify the claims according introspection request to the AS. RS MUST verify the claims according
to the rules set in the Section 5.8.1.1 of the ACE framework to the rules set in the Section 5.8.1.1 of the ACE framework
[I-D.ietf-ace-oauth-authz]. [I-D.ietf-ace-oauth-authz].
To authenticate the Client, the RS validates the signature or the To authenticate the Client, the RS validates the signature or the
MAC, depending on how the PoP protocol is implemented. HS256 and MAC, depending on how the PoP protocol is implemented. HS256 and
RS256 are mandatory to implement depending on the choice of symmetric Ed25519 are mandatory to implement depending on the choice of
or asymmetric validation. Validation of the signature or MAC MUST symmetric or asymmetric validation. Validation of the signature or
fail if the signature algorithm is set to "none", when the key used MAC MUST fail if the signature algorithm is set to "none", when the
for the signature algorithm cannot be determined, or the computed and key used for the signature algorithm cannot be determined, or the
received signature/MAC do not match. computed and received signature/MAC do not match.
2.2.6. The Broker's Response to Client Connection Request 2.2.6. The Broker's Response to Client Connection Request
Based on the validation result (obtained either via local inspection Based on the validation result (obtained either via local inspection
or using the /introspection interface of the AS), the Broker MUST or using the /introspection interface of the AS), the Broker MUST
send a CONNACK message to the Client. The reason code of the CONNACK send a CONNACK message to the Client.
is '0x00 (Success)' if the token validation is successful. The
Broker MUST also set Session Present to 0 in the CONNACK packet to 2.2.6.1. Unauthorised Request: Authorisation Server Discovery
signal a clean session to the Client. In case of an invalid PoP
token, the CONNACK reason code is '0x87 (Not Authorized)'. If the Client does not provide a valid token or omits the
Authentication Data field, the Broker triggers AS discovery. The
Broker MUST NOT process any data sent by the Client after the CONNECT
packet including AUTH packets (Note that this is different in MQTT
v5.0, the Broker is allowed to process AUTH packets even if the
Broker rejects the CONNECT).
The Broker responds with the CONNACK reason code '0x87 (Not
Authorized)' and includes a User Property (identified by 38 (0x26))
for the AS Request Creation Hints. The User Property is a UTF-8
string pair, composed of a name and a value. The name of the User
Property MUST be set to "ace_as_hint". The value of the user
property is a UTF-8 encoded JSON string containing the mandatory "AS"
parameter, and the optional parameters "audience", "kid", "cnonce",
and "scope" as defined in Section 5.1.2 of the ACE framework
[I-D.ietf-ace-oauth-authz].
2.2.6.2. Authorisation Success
On success, the reason code of the CONNACK is '0x00 (Success)'. If
the Broker starts a new session, it MUST also set Session Present to
0 in the CONNACK packet to signal a clean session to the Client.
Otherwise, it MUST set Session Present to 1. In case of an invalid
PoP token, the CONNACK reason code is '0x87 (Not Authorized)'.
If the Broker accepts the connection, it MUST store the token until If the Broker accepts the connection, it MUST store the token until
the end of the connection. On Client or Broker disconnection, the the end of the connection. On Client or Broker disconnection, the
Client is expected to provide a token again inside the next CONNECT Client is expected to transport a token again on the next connection
message. attempt.
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 authorize the introspection, it MAY cache the validation result to authorize the
subsequent PUBLISH and SUBSCRIBE messages. PUBLISH and SUBSCRIBE subsequent PUBLISH and SUBSCRIBE messages. PUBLISH and SUBSCRIBE
messages, which are sent after a connection set-up, do not contain messages, which are sent after a connection set-up, do not contain
access tokens. If the introspection result is not cached, then the access tokens. If the introspection result is not cached, then the
RS needs to introspect the saved token for each request. The Broker RS needs to introspect the saved token for each request. The Broker
SHOULD also use a cache time out to introspect tokens regularly. SHOULD also use a cache time out to introspect tokens regularly.
3. Authorizing PUBLISH and SUBSCRIBE Messages 3. Authorizing PUBLISH and SUBSCRIBE Messages
To authorize a Client's PUBLISH and SUBSCRIBE messages, the Broker To authorize a Client's PUBLISH and SUBSCRIBE messages, the Broker
needs to use the scope field in the token (or in the introspection uses the scope field in the token (or in the introspection result).
result). The scope field contains the publish and subscribe The scope field contains the publish and subscribe permissions for
permissions for the Client. Scope strings SHOULD be encoded as a the Client and is made up of space-delimited strings. Scope strings
permission, followed by an underscore, followed by a topic filter. SHOULD be encoded as permission, followed by an underscore, followed
Two permissions apply to topic filters: 'publish' and 'subscribe'. by a topic filter. Two permissions apply to topic filters: 'publish'
Topic filters are implemented as described in the Section 4.7 of MQTT and 'subscribe'. Topic filters are implemented according to
v5.0 - the OASIS Standard [MQTT-OASIS-Standard-v5] and includes Section 4.7 of MQTT v5.0 - the OASIS Standard
special wildcard characters. The multi-level wildcard, '#', matches [MQTT-OASIS-Standard-v5] and includes special wildcard characters.
any number of levels within a topic, and the single-level wildcard, The multi-level wildcard, '#', matches any number of levels within a
'+', matches one topic level. topic, and the single-level wildcard, '+', matches one topic level.
An example scope field may contain multiple such strings, space An example scope field may contain 'publish_topic1 subscribe_topic2/#
delimited, e.g., 'publish_topic1 subscribe_topic2/#' publish_+/topic3'. This access token gives 'publish' permission to
publish_+/topic3. This access token gives 'publish' permission to
the 'topic1', 'subscribe' permission to all the subtopics of the 'topic1', 'subscribe' permission to all the subtopics of
'topic2', and 'publish' permission to all topic3, skipping one level. 'topic2', and 'publish' permission to all topic3, skipping one level.
If the Will Flag is set,then the Broker MUST check that the token If the Will Flag is set, then the Broker MUST check that the token
allows the publication of the Will message (i.e., the scope is allows the publication of the Will message (i.e. the scope is
"publish_" followed by the Will Topic). "publish_" followed by the Will Topic).
3.1. PUBLISH Messages from the Publisher Client to the Broker 3.1. PUBLISH Messages from the Publisher Client to the Broker
On receiving the PUBLISH message, the Broker MUST use the type of On receiving the PUBLISH message, the Broker MUST use the type of
message (i.e., PUBLISH) and the Topic name in the message header to message (i.e. PUBLISH) and the Topic name in the message header to
match against the scope string in the cached token or its match against the scope string in the cached token or its
introspection result. Following the example above, a client sending introspection result. Following the example in the previous section,
a PUBLISH message to 'a/topic3' would be allowed to publish, as the a client sending a PUBLISH message to 'a/topic3' would be allowed to
scope includes the string 'publish_+/topic3'. publish, as the scope includes the string 'publish_+/topic3'.
If the Client is allowed to publish to the topic, the RS must publish If the Client is allowed to publish to the topic, the Broker must
the message to all valid subscribers of the topic. In the case of an publish the message to all valid subscribers of the topic. In the
authorization failure, an error MAY be returned to the Client. For case of an authorization failure, the Broker MUST return an error, if
this, the QoS level of the PUBLISH message MUST be set to greater the Client has set the QoS level of the PUBLISH message to greater
than or equal to 1. This guarantees that RS responds with either a than or equal to 1. Depending on the QoS level, the Broker responds
PUBACK or PUBREC packet with reason code '0x87 (Not authorized)'. On with either a PUBACK or PUBREC packet with reason code '0x87 (Not
receiving a PUBACK with '0x87 (Not authorized)', the Client MAY authorized)'. On receiving a PUBACK with '0x87 (Not authorized)',
reauthenticate as described in Section 4, and pass a new token the Client MAY reauthenticate by providing a new token as described
following the same PoP methods as described in Figure 2. in Section 4.
For QoS level 0, the RS sends a DISCONNECT with reason code '0x87 For QoS level 0, the Broker sends a DISCONNECT with reason code '0x87
(Not authorized)' and closes the network connection. Note that the (Not authorized)' and closes the network connection. Note that the
server-side DISCONNECT is a new feature of MQTT v5.0 (in MQTT v3.1.1, server-side DISCONNECT 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).
3.2. PUBLISH Messages from the Broker to the Subscriber Clients 3.2. PUBLISH Messages from the Broker to the Subscriber Clients
To forward PUBLISH messages to the subscribing Clients, the Broker To forward PUBLISH messages to the subscribing Clients, the Broker
identifies all the subscribers that have valid matching topic identifies all the subscribers that have valid matching topic
subscriptions (i.e., the tokens are valid, and token scopes allow a subscriptions (i.e. the tokens are valid, and token scopes allow a
subscription to the particular topic). The Broker sends a PUBLISH subscription to the particular topic). The Broker sends a PUBLISH
message with the Topic name to all the valid subscribers. message with the Topic name to all the valid subscribers.
RS MUST NOT forward messages to the unauthorized subscribers. There The Broker MUST NOT forward messages to the unauthorized subscribers.
is no way to inform the Clients with invalid tokens that an There is no way to inform the Clients with invalid tokens that an
authorization error has occurred other than sending a DISCONNECT authorization error has occurred other than sending a DISCONNECT
message. The RS SHOULD send a DISCONNECT message with the reason message. The Broker SHOULD send a DISCONNECT message with the reason
code '0x87 (Not authorized)'. code '0x87 (Not authorized)'.
3.3. Authorizing SUBSCRIBE Messages 3.3. Authorizing SUBSCRIBE Messages
In MQTT, a SUBSCRIBE message is sent from a Client to the Broker to In MQTT, a SUBSCRIBE message is sent from a Client to the Broker to
create one or more subscriptions to one or more topics. The create one or more subscriptions to one or more topics. The
SUBSCRIBE message may contain multiple Topic Filters. The Topic SUBSCRIBE message may contain multiple Topic Filters. The Topic
Filters may include wildcard characters. Filters may include wildcard characters.
On receiving the SUBSCRIBE message, the Broker MUST use the type of On receiving the SUBSCRIBE message, the Broker MUST use the type of
message (i.e., SUBSCRIBE) and the Topic Filter in the message header message (i.e. SUBSCRIBE) and the Topic Filter in the message header
to match against a scope string of the stored token or introspection to match against a scope string of the stored token or introspection
result. The Topic Filters MUST be equal or a subset of the scopes result. The Topic Filters MUST be equal or a subset of the scopes
associated with the Client's token. associated with the Client's token.
As a response to the SUBSCRIBE message, the Broker issues a SUBACK As a response to the SUBSCRIBE message, the Broker issues a SUBACK
message. For each Topic Filter, the SUBACK packet includes a return message. For each Topic Filter, the SUBACK packet includes a return
code matching the QoS level for the corresponding Topic Filter. In code matching the QoS level for the corresponding Topic Filter. In
the case of failure, the return code is 0x87, indicating that the the case of failure, the return code is 0x87, indicating that the
Client is 'Not authorized'. A reason code is returned for each Topic Client is 'Not authorized'. A reason code is returned for each Topic
Filter. Therefore, the Client may receive success codes for a subset Filter. Therefore, the Client may receive success codes for a subset
of its Topic Filters while being unauthorized for the rest. of its Topic Filters while being unauthorized for the rest.
4. Token Expiration and Reauthentication 4. Token Expiration and Reauthentication
The Broker MUST check for token expiration whenever a CONNECT, The Broker MUST check for token expiration whenever a CONNECT,
PUBLISH or SUBSCRIBE message is received or sent. The Broker SHOULD PUBLISH or SUBSCRIBE message is received or sent. The Broker SHOULD
check for token expiration on receiving a PINGREQUEST message. The check for token expiration on receiving a PINGREQUEST message. The
Broker MAY also check for token expiration periodically e.g., every Broker MAY also check for token expiration periodically, e.g. every
hour. This may allow for early detection of a token expiry. hour. This may allow for early detection of a token expiry.
The token expiration is checked by checking the 'exp' claim of a JWT The token expiration is checked by checking the 'exp' claim of a JWT
or introspection response, or via performing an introspection request or introspection response, or via performing an introspection request
with the AS as described in Section 5.7 of the ACE framework with the AS as described in Section 5.7 of the ACE framework
[I-D.ietf-ace-oauth-authz]. Token expirations may trigger the RS to [I-D.ietf-ace-oauth-authz]. Token expirations may trigger the RS to
send PUBACK, SUBACK and DISCONNECT messages with return code set to send PUBACK, SUBACK and DISCONNECT messages with return code set to
'Not authorised'. After sending a DISCONNECT message, the network 'Not authorised'. After sending a DISCONNECT message, the network
connection is closed, and no more messages can be sent. However, as connection is closed, and no more messages can be sent. However, as
a response to the PUBACK and SUBACK, the Client MAY re-authenticate a response to the PUBACK and SUBACK, the Client MAY reauthenticate.
by sending an AUTH packet with a Reason Code of '0x19 (Re- The Clients MAY also proactively update their tokens, i.e. before
authentication)'. they receive a message with 'Not authorized' return code.
To re-authenticate, the Client sends an AUTH packet with reason code To start reauthentication, the Client MUST send an AUTH packet with
'0x19 (Re-authentication)'. The Client MUST set the Authentication reason code '0x19 (Re-authentication)'. The Client MUST set the
Method as 'ace' and transport the new token in the Authentication Authentication Method as 'ace' and transport the new token in the
Data. The Client and the RS go through the same steps for proof of Authentication Data. The Broker accepts reauthentication requests if
possession validation as described in Section 2.2. The Client SHOULD the Client has already submitted a token (may be expired) and
use the same method used for the first connection request. If the validated via the challenge-response PoP as defined in
re-authentication fails, the server MUST send a DISCONNECT with the Section 2.2.4.2. The Client MUST use the challenge-response PoP.
reason code '0x87 (Not Authorized)'. The Clients can also Otherwise, the Broker MUST deny the request. If the reauthentication
proactively update their tokens i.e., before they receive a message fails, the Broker MUST send a DISCONNECT with the reason code '0x87
with 'Not authorized' return code. (Not Authorized)'.
5. Handling Disconnections and Retained Messages 5. Handling Disconnections and Retained Messages
In the case of a Client DISCONNECT, the Broker deletes all the In the case of a Client DISCONNECT, the Broker deletes all the
session state but MUST keep the retained messages. By setting a session state but MUST keep the retained messages. By setting a
RETAIN flag in a PUBLISH message, the publisher indicates to the RETAIN flag in a PUBLISH message, the publisher indicates to the
Broker that it should store the most recent message for the Broker that it should store the most recent message for the
associated topic. Hence, the new subscribers can receive the last associated topic. Hence, the new subscribers can receive the last
sent message from the publisher of that particular topic without sent message from the publisher of that particular topic without
waiting for the next PUBLISH message. The Broker MUST continue waiting for the next PUBLISH message. The Broker MUST continue
skipping to change at page 18, line 29 skipping to change at page 18, line 45
errors), the Will message must be sent if the Client supplied a Will errors), the Will message must be sent if the Client supplied a Will
in the CONNECT message. The Client's token scopes MUST include the in the CONNECT message. The Client's token scopes MUST include the
Will Topic. The Will message MUST be published to the Will Topic Will Topic. The Will message MUST be published to the Will Topic
regardless of whether the corresponding token has expired. In the regardless of whether the corresponding token has expired. In the
case of a server-side DISCONNECT, the server returns the '0x87 Not case of a server-side DISCONNECT, the server returns the '0x87 Not
Authorized' return code to the Client. Authorized' return code to the Client.
6. Reduced Protocol Interactions for MQTT v3.1.1 6. Reduced Protocol Interactions for MQTT v3.1.1
This section describes a reduced set of protocol interactions for the This section describes a reduced set of protocol interactions for the
MQTT v3.1.1 Client. MQTT v.5 brokers MAY also implement this method. MQTT v3.1.1 Clients. An MQTT v5.0 Broker MAY implement these
Brokers that do not support MQTT v3.1.1 clients return a CONNACK interactions for the MQTT v3.1.1 clients; MQTT v5.0 clients are NOT
packet with Reason Code '0x84 (Unsupported Protocol Version)' in RECOMMENDED to use the flows described in this section. Brokers that
response to the clients' CONNECT packet. do not support MQTT v3.1.1 clients return a CONNACK packet with
Reason Code '0x84 (Unsupported Protocol Version)' in response to the
connection requests.
6.1. Token Transport 6.1. Token Transport
As in MQTT v5, The Token MAY either be transported before by As in MQTT v5.0, The Token MAY either be transported before by
publishing to the "authz-info" topic, or inside the CONNECT message. publishing to the "authz-info" topic, or inside the CONNECT message.
In MQTT v3.1.1, after the Client published to the "authz-info" topic, In MQTT v3.1.1, after the Client published to the "authz-info" topic,
it is not possible for the Broker to communicate the result of the the Broker cannot communicate the result of the token validation as
token validation as PUBACK reason codes or server-side DISCONNECT PUBACK reason codes or server-side DISCONNECT messages are not
messages are not supported. In any case, an invalid token would fail supported. In any case, an invalid token would fail the subsequent
the subsequent TLS handshake, which can prompt the Client to obtain a TLS handshake, which can prompt the Client to obtain a valid token.
valid token.
To transport the token to the Broker inside the CONNECT message, the To transport the token to the Broker inside the CONNECT message, the
Client uses the username and password fields of the CONNECT message. Client uses the username and password fields. Figure 5 shows the
Figure 5 shows the structure of the MQTT CONNECT message. structure of the MQTT CONNECT message.
0 8 16 24 32 0 8 16 24 32
+------------------------------------------------------+ +------------------------------------------------------+
|CPT=1 | Rsvd.|Remaining len.| Protocol name len. = 4 | |CPT=1 | Rsvd.|Remaining len.| Protocol name len. = 4 |
+------------------------------------------------------+ +------------------------------------------------------+
| 'M' 'Q' 'T' 'T' | | 'M' 'Q' 'T' 'T' |
+------------------------------------------------------+ +------------------------------------------------------+
| Proto.level=4|Connect flags| Keep alive | | Proto.level=4|Connect flags| Keep alive |
+------------------------------------------------------+ +------------------------------------------------------+
| Payload | | Payload |
skipping to change at page 19, line 35 skipping to change at page 19, line 50
+-----------------------------------------------------------+ +-----------------------------------------------------------+
|User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.| |User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.|
| flag |flag | | | | | | | flag |flag | | | | | |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| 1 | 1 | X | X X | X | X | 0 | | 1 | 1 | X | X X | X | X | 0 |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
Figure 6: MQTT CONNECT flags. (Rsvd=Reserved) Figure 6: MQTT CONNECT flags. (Rsvd=Reserved)
The Clean Session Flag is ignored, and the Broker always sets up a The Broker SHOULD NOT accept session continuation. To this end, the
clean session. On connection success, the Broker MUST set the Broker ignores how the Clean Session Flag is set, and on connection
Session Present flag to 0 in the CONNACK packet. success, the Broker MUST set the Session Present flag to 0 in the
CONNACK packet to indicate a clean session to the Client. If the
Broker wishes to support session continuation, it MUST still perform
proof-of-possession validation on the provided Client token. MQTT
v3.1.1 does not use a Session Expiry Interval, and the Client expects
that the Broker maintains the session state after it disconnects.
However, stored Session state can be discarded as a result of
administrator policies, and Brokers SHOULD implement the necessary
policies to limit misuse.
The Client may set the Will Flag as desired (marked as 'X' in The Client may set the Will Flag as desired (marked as 'X' in
Figure 6). Username and Password flags MUST be set to 1 to ensure Figure 6). Username and Password flags MUST be set to 1 to ensure
that the Payload of the CONNECT message includes both Username and that the Payload of the CONNECT message includes both Username and
Password fields. Password fields.
The CONNECT in MQTT v3.1.1 does not have a field to indicate the The CONNECT in MQTT v3.1.1 does not have a field to indicate the
authentication method. To signal that the Username field contains an authentication method. To signal that the Username field contains an
ACE token, this field MUST be prefixed with 'ace' keyword, which is ACE token, this field MUST be prefixed with 'ace' keyword, which is
followed by the access token. The Password field MUST be set to the followed by the access token. The Password field MUST be set to the
keyed message digest (MAC) or signature associated with the access keyed message digest (MAC) or signature associated with the access
token for proof-of-possession. The Client MUST apply the PoP key on token for proof-of-possession. The Client MUST apply the PoP key on
the challenge derived from the TLS session as described in the challenge derived from the TLS session as described in
Section 2.2.4.1. Section 2.2.4.1.
In MQTT v3.1.1, the MQTT Username as a UTF-8 encoded string (i.e., is In MQTT v3.1.1, the MQTT Username as a UTF-8 encoded string (i.e. is
prefixed by a 2-byte length field followed by UTF-8 encoded character prefixed by a 2-byte length field followed by UTF-8 encoded character
data) and may be up to 65535 bytes. Therefore, an access token that data) and may be up to 65535 bytes. Therefore, an access token that
is not a valid UTF-8 MUST be Base64 [RFC4648] encoded. (The MQTT is not a valid UTF-8 MUST be Base64 [RFC4648] encoded. (The MQTT
Password allows binary data up to 65535 bytes.) Password allows binary data up to 65535 bytes.)
6.2. Handling Authorization Errors 6.2. Handling Authorization Errors
Handling errors are more primitive in MQTT v3.1.1 due to not having Handling errors are more primitive in MQTT v3.1.1 due to not having
appropriate error fields, error codes, and server-side DISCONNECTS. appropriate error fields, error codes, and server-side DISCONNECTs.
In the following, we list how errors are handled without such In the following, we list how errors are handled without such
protocol support. protocol support.
o CONNECT without a token: It is not possible to support AS o CONNECT without a token: It is not possible to support AS
discovery via sending a tokenless CONNECT message to the Broker. discovery via sending a tokenless CONNECT message to the Broker.
This is because a CONNACK packet in MQTT v3.1.1 does not include a This is because a CONNACK packet in MQTT v3.1.1 does not include a
means to provide additional information to the Client. Therefore, means to provide additional information to the Client. Therefore,
AS discovery needs to take place out-of-band. CONNECT attempt AS discovery needs to take place out-of-band. CONNECT attempt
MUST fail. MUST fail.
skipping to change at page 20, line 47 skipping to change at page 21, line 21
returned for each Topic Filter. returned for each Topic Filter.
o RS-Client PUBLISH authorization failure: When RS is forwarding o RS-Client PUBLISH authorization failure: When RS is forwarding
PUBLISH messages to the subscribed Clients, it may discover that PUBLISH messages to the subscribed Clients, it may discover that
some of the subscribers are no more authorized due to expired some of the subscribers are no more authorized due to expired
tokens. These token expirations SHOULD lead to disconnecting the tokens. These token expirations SHOULD lead to disconnecting the
Client rather than silently dropping messages. Client rather than silently dropping messages.
7. IANA Considerations 7. IANA Considerations
This document registers 'EXPORTER-ACE-Sign-Challenge from This document registers 'EXPORTER-ACE-MQTT-Sign-Challenge' from
Section 2.2.4.1 in the TLS Exporter Label Registry TLS-REGISTRIES Section 2.2.4.1 in the TLS Exporter Label Registry TLS-REGISTRIES
[RFC8447]. [RFC8447].
In addition, the following registrations are done for the ACE OAuth In addition, the following registrations are done for the ACE OAuth
Profile Registry following the procedure specified in Profile Registry following the procedure specified in
[I-D.ietf-ace-oauth-authz]. [I-D.ietf-ace-oauth-authz].
Note to the RFC editor: Please replace all occurrences of "[RFC- Note to the RFC editor: Please replace all occurrences of "[RFC-
XXXX]" with the RFC number of this specification and delete this XXXX]" with the RFC number of this specification and delete this
paragraph. paragraph.
skipping to change at page 22, line 9 skipping to change at page 22, line 30
The RS may monitor Client behaviour to detect potential security The RS may monitor Client behaviour to detect potential security
problems, especially those affecting availability. These include problems, especially those affecting availability. These include
repeated token transfer attempts to the public "authz-info" topic, repeated token transfer attempts to the public "authz-info" topic,
repeated connection attempts, abnormal terminations, and Clients that repeated connection attempts, abnormal terminations, and Clients that
connect but do not send any data. If the RS supports the public connect but do not send any data. If the RS supports the public
"authz-info" topic, described in Section 2.2.2, then this may be "authz-info" topic, described in Section 2.2.2, then this may be
vulnerable to a DDoS attack, where many Clients use the "authz-info" vulnerable to a DDoS attack, where many Clients use the "authz-info"
public topic to transport fictitious tokens, which RS may need to public topic to transport fictitious tokens, which RS may need to
store indefinitely. store indefinitely.
For MQTT v5.0, when a Client connects with a long Session Expiry
Interval, the RS may need to maintain Client's MQTT session state
after it disconnects for an extended period. For MQTT v3.1.1, the
session state may need to be stored indefinitely, as it does not have
a Session Expiry Interval feature. The RS SHOULD implement
administrative policies to limit misuse of the session continuation
by the Client.
9. Privacy Considerations 9. Privacy Considerations
The privacy considerations outlined in [I-D.ietf-ace-oauth-authz] The privacy considerations outlined in [I-D.ietf-ace-oauth-authz]
apply to this work. apply to this work.
In MQTT, the RS is a central trusted party and may forward In MQTT, the RS is a central trusted party and may forward
potentially sensitive information between Clients. This document potentially sensitive information between Clients. This document
does not protect the contents of the PUBLISH message from the Broker, does not protect the contents of the PUBLISH message from the Broker,
and hence, the content of the the PUBLISH message is not signed or and hence, the content of the PUBLISH message is not signed or
encrypted separately for the subscribers. This functionality may be encrypted separately for the subscribers. This functionality may be
implemented using the proposal outlined in the CoAP Pub-Sub Profile implemented using the proposal outlined in the CoAP Pub-Sub Profile
[I-D.ietf-ace-pubsub-profile]. However, this solution would still [I-D.ietf-ace-pubsub-profile]. However, this solution would still
not provide privacy for other properties of the message such as Topic not provide privacy for other properties of the message such as Topic
Name. Name.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-ace-cwt-proof-of-possession]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
possession-11 (work in progress), October 2019.
[I-D.ietf-ace-dtls-authorize] [I-D.ietf-ace-dtls-authorize]
Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
L. Seitz, "Datagram Transport Layer Security (DTLS) L. Seitz, "Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for Profile for Authentication and Authorization for
Constrained Environments (ACE)", draft-ietf-ace-dtls- Constrained Environments (ACE)", draft-ietf-ace-dtls-
authorize-09 (work in progress), December 2019. authorize-10 (work in progress), May 2020.
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33
(work in progress), February 2020. (work in progress), February 2020.
[I-D.ietf-ace-oauth-params] [I-D.ietf-ace-oauth-params]
Seitz, L., "Additional OAuth Parameters for Authorization Seitz, L., "Additional OAuth Parameters for Authorization
in Constrained Environments (ACE)", draft-ietf-ace-oauth- in Constrained Environments (ACE)", draft-ietf-ace-oauth-
params-12 (work in progress), February 2020. params-13 (work in progress), April 2020.
[I-D.ietf-cose-x509] [I-D.ietf-cose-x509]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Headers for carrying and referencing X.509 certificates", Header parameters for carrying and referencing X.509
draft-ietf-cose-x509-05 (work in progress), November 2019. certificates", draft-ietf-cose-x509-06 (work in progress),
March 2020.
[MQTT-OASIS-Standard] [MQTT-OASIS-Standard]
Banks, A., Ed. and R. Gupta, Ed., "OASIS Standard MQTT Banks, A., Ed. and R. Gupta, Ed., "OASIS Standard MQTT
Version 3.1.1 Plus Errata 01", 2015, <http://docs.oasis- Version 3.1.1 Plus Errata 01", 2015, <http://docs.oasis-
open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html>. open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html>.
[MQTT-OASIS-Standard-v5] [MQTT-OASIS-Standard-v5]
Banks, A., Ed., Briggs, E., Ed., Borgendale, K., Ed., and Banks, A., Ed., Briggs, E., Ed., Borgendale, K., Ed., and
R. Gupta, Ed., "OASIS Standard MQTT Version 5.0", 2017, R. Gupta, Ed., "OASIS Standard MQTT Version 5.0", 2017,
<http://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt- <http://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-
skipping to change at page 24, line 13 skipping to change at page 24, line 36
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/info/rfc8447>. <https://www.rfc-editor.org/info/rfc8447>.
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/info/rfc8747>.
10.2. Informative References 10.2. Informative References
[fremantle14] [fremantle14]
Fremantle, P., Aziz, B., Kopecky, J., and P. Scott, Fremantle, P., Aziz, B., Kopecky, J., and P. Scott,
"Federated Identity and Access Management for the Internet "Federated Identity and Access Management for the Internet
of Things", research International Workshop on Secure of Things", research International Workshop on Secure
Internet of Things, September 2014, Internet of Things, September 2014,
<http://dx.doi.org/10.1109/SIoT.2014.8>. <http://dx.doi.org/10.1109/SIoT.2014.8>.
[I-D.ietf-ace-pubsub-profile] [I-D.ietf-ace-pubsub-profile]
skipping to change at page 24, line 42 skipping to change at page 25, line 25
Appendix A. Checklist for profile requirements Appendix A. Checklist for profile requirements
o AS discovery: AS discovery is possible with the MQTT v5.0 o AS discovery: AS discovery is possible with the MQTT v5.0
described in Section 2.2. described in Section 2.2.
o The communication protocol between the Client and RS: MQTT o The communication protocol between the Client and RS: MQTT
o The security protocol between the Client and RS: TLS o The security protocol between the Client and RS: TLS
o Client and RS mutual authentication: Several options are possible o Client and RS mutual authentication: Several options are possible
and descibed in Section 2.2.1. and described in Section 2.2.1.
o Content format: For the HTTPS interactions with AS, "application/ o Content format: For the HTTPS interactions with AS, "application/
ace+json". ace+json".
o PoP protocols: Either symmetric or asymmetric keys can be o PoP protocols: Either symmetric or asymmetric keys can be
supported. supported.
o Unique profile identifier: mqtt_tls o Unique profile identifier: mqtt_tls
o Token introspection: RS uses HTTPS /introspect interface of AS. o Token introspection: RS uses HTTPS /introspect interface of AS.
skipping to change at page 25, line 18 skipping to change at page 25, line 50
o /authz-info endpoint: It MAY be supported using the method o /authz-info endpoint: It MAY be supported using the method
described in Section 2.2.2, but is not protected. described in Section 2.2.2, but is not protected.
o Token transport: Via "authz-info" topic, or in MQTT CONNECT o Token transport: Via "authz-info" topic, or in MQTT CONNECT
message for both versions of MQTT. AUTH extensions also used for message for both versions of MQTT. AUTH extensions also used for
authentication and re-authentication for MQTT v5.0 as described in authentication and re-authentication for MQTT v5.0 as described in
Section 2.2 and in Section 4. Section 2.2 and in Section 4.
Appendix B. Document Updates Appendix B. Document Updates
Version 04 to 05:
o Reorganised Section 2 such that "Unauthorised Request:
Authorisation Server Discovery" is presented under Section 2.
o Fixed Figure 2 to remove the "empty" word.
o Clarified that MQTT v5.0 Brokers may implement username/password
option for transporting the ACE token only for MQTT v.3.1.1
clients. This option is not recommended for MQTT v.5.0 clients.
o 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.
o Fixed the Authentication Data to include token length for the
Challenge/Response PoP.
o Added that Authorisation Server Discovery is triggered if a token
is invalid and not only missing.
o Clarified that the Broker should not accept any other packets from
Client after CONNECT and before sending CONNACK.
o Added that client reauthentication is accepted only for the
challenge/response PoP.
o Added Ed25519 as mandatory to implement.
o Fixed typos.
Version 03 to 04: Version 03 to 04:
o Linked the terms Broker and MQTT server more at the introduction o Linked the terms Broker and MQTT server more at the introduction
of the document. of the document.
o Clarified support for MQTTv3.1.1 and removed phrases that might be o Clarified support for MQTTv3.1.1 and removed phrases that might be
considered as MQTTv5 is backward compatible with MQTTv3.1.1 considered as MQTTv5 is backwards compatible with MQTTv3.1.1
o Corrected the Informative and Normative references. o Corrected the Informative and Normative references.
o For AS discovery, clarified the CONNECT message omits the o For AS discovery, clarified the CONNECT message omits the
Authentication Data field. Specified the User Property MUST be Authentication Data field. Specified the User Property MUST be
set to "ace_as_hint" for AS Request Creation Hints. set to "ace_as_hint" for AS Request Creation Hints.
o Added that MQTT v5 brokers MAY also implement reduced interactions o Added that MQTT v5 brokers MAY also implement reduced interactions
described for MQTTv3.1.1. described for MQTTv3.1.1.
o Added to Section 3.1, in case of an authorisation failure and QoS o Added to Section 3.1, in case of an authorisation failure and QoS
level 0, the RS sends a DISCONNECT with reason code '0x87 (Not level 0, the RS sends a DISCONNECT with reason code '0x87 (Not
authorized)'. authorized)'.
o Added a pointer to section 4.7 of MQTTv5 spec for more information o Added a pointer to section 4.7 of MQTTv5 spec for more information
on topic names and filters. on topic names and filters.
o Added HS256 and RS256 are mandatory to implement depending on the o Added HS256 and RSA256 are mandatory to implement depending on the
choice of symmetric or asymmetric validation. choice of symmetric or asymmetric validation.
o Added MQTT to the TLS exporter label to make it application o Added MQTT to the TLS exporter label to make it application
specific: 'EXPORTER-ACE-MQTT-Sign-Challenge'. specific: 'EXPORTER-ACE-MQTT-Sign-Challenge'.
o Added a format for Authentication Data so that length values o Added a format for Authentication Data so that length values
prefix the token (or client nonce) when Authentication Data prefix the token (or client nonce) when Authentication Data
contains more than one piece of information. contains more than one piece of information.
o Clarified clients still connect over TLS (server-side) for the o Clarified clients still connect over TLS (server-side) for the
skipping to change at page 26, line 39 skipping to change at page 28, line 9
Version 01 to 02: Version 01 to 02:
o Clarified protection of Application Message payload as out of o Clarified protection of Application Message payload as out of
scope, and cited draft-palombini-ace-coap-pubsub-profile for a scope, and cited draft-palombini-ace-coap-pubsub-profile for a
potential solution potential solution
o Expanded Client connection authorization to capture different o Expanded Client connection authorization to capture different
options for Client and Broker authentication over TLS and MQTT options for Client and Broker authentication over TLS and MQTT
o Removed Payload (and specifically Client Identifier) from proof- o Removed Payload (and specifically Client Identifier) from proof-
of-possesion in favor of using tls-exporter for a TLS-session of-possession in favor of using tls-exporter for a TLS-session
based challenge. based challenge.
o Moved token transport via "authz-info" topic from the Appendix to o Moved token transport via "authz-info" topic from the Appendix to
the main text. the main text.
o Clarified Will scope. o Clarified Will scope.
o Added MQTT AUTH to terminology. o Added MQTT AUTH to terminology.
o Typo fixes, and simplification of figures. o Typo fixes, and simplification of figures.
Version 00 to 01: Version 00 to 01:
o Present the MQTTv5 as the RECOMMENDED version, and MQTT v3.1.1 for o Present the MQTTv5 as the RECOMMENDED version, and MQTT v3.1.1 for
backward compatibility. backward compatibility.
o Clarified Will message. o Clarified Will message.
o Improved consistency in the use of terminology, and upper/lower o Improved consistency in the use of terminology and upper/lower
case. case.
o Defined Broker and MQTTS. o Defined Broker and MQTTS.
o Clarified HTTPS use for C-AS and RS-AS communication. Removed o Clarified HTTPS use for C-AS and RS-AS communication. Removed
reference to actors document, and clarified the use of client reference to actors document, and clarified the use of client
authorization server. authorization server.
o Clarified the Connect message payload and Client Identifier. o Clarified the Connect message payload and Client Identifier.
o Presented different methods for passing the token, and PoP. o Presented different methods for passing the token and PoP.
o Added new figures to explain AUTH packets exchang, updated CONNECT o Added new figures to explain AUTH packets exchange, updated
message figure. CONNECT message figure.
Acknowledgements Acknowledgements
The authors would like to thank Ludwig Seitz for his review and his The authors would like to thank Ludwig Seitz for his review and his
input on the authorization information endpoint, presented in the input on the authorization information endpoint, presented in the
appendix. appendix.
Authors' Addresses Authors' Addresses
Cigdem Sengul Cigdem Sengul
 End of changes. 92 change blocks. 
240 lines changed or deleted 318 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/