draft-ietf-ace-mqtt-tls-profile-03.txt   draft-ietf-ace-mqtt-tls-profile-04.txt 
ACE Working Group C. Sengul ACE Working Group C. Sengul
Internet-Draft Nominet Internet-Draft Brunel University
Intended status: Standards Track A. Kirby Intended status: Standards Track A. Kirby
Expires: June 22, 2020 Oxbotica Expires: September 10, 2020 Oxbotica
P. Fremantle P. Fremantle
University of Portsmouth University of Portsmouth
December 20, 2019 March 9, 2020
MQTT-TLS profile of ACE MQTT-TLS profile of ACE
draft-ietf-ace-mqtt-tls-profile-03 draft-ietf-ace-mqtt-tls-profile-04
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 server authentication. TLS for confidentiality and MQTT server (broker) authentication.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 June 22, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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
skipping to change at page 2, line 36 skipping to change at page 2, line 36
2.2.4.3. Unauthorised Request: Authorisation Server 2.2.4.3. Unauthorised Request: Authorisation Server
Discovery . . . . . . . . . . . . . . . . . . . . 14 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 3. Authorizing PUBLISH and SUBSCRIBE Messages . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3. Authorizing SUBSCRIBE Messages . . . . . . . . . . . . . 16 3.3. Authorizing SUBSCRIBE Messages . . . . . . . . . . . . . 16
4. Token Expiration and Reauthentication . . . . . . . . . . . . 17 4. Token Expiration and Reauthentication . . . . . . . . . . . . 17
5. Handling Disconnections and Retained Messages . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . . 18
6.2. Handling Authorization Errors . . . . . . . . . . . . . . 20 6.2. Handling Authorization Errors . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Checklist for profile requirements . . . . . . . . . 24 Appendix A. Checklist for profile requirements . . . . . . . . . 24
Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 25 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 25
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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 a Broker [I-D.ietf-ace-oauth-authz]. In this profile, Clients and Server
use MQTT to exchange Application Messages. The protocol relies on (Broker) use MQTT to exchange Application Messages. The protocol
TLS for communication security between entities. The MQTT protocol relies on TLS for communication security between entities. The MQTT
interactions are described based on the MQTT v5.0 - the OASIS protocol interactions are described based on the MQTT v5.0 - the
Standard [MQTT-OASIS-Standard-v5]. It is expected that MQTT OASIS Standard [MQTT-OASIS-Standard-v5]. Since it is expected that
deployments will retain backward compatibility for MQTT v3.1.1 MQTT deployments will continue to support MQTT v3.1.1 clients, this
clients, and therefore, this document also describes a reduced set of document also describes a reduced set of protocol interactions for
protocol interactions for MQTT v3.1.1 - the OASIS Standard MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard]. However,
[MQTT-OASIS-Standard]. However, MQTT v5.0 is the RECOMMENDED version MQTT v5.0 is the RECOMMENDED version as it works more naturally with
as it works more naturally with ACE-style authentication and ACE-style authentication and authorization.
authorization.
MQTT is a publish-subscribe protocol and after connecting to the MQTT MQTT is a publish-subscribe protocol and after connecting to the MQTT
Broker, a Client can publish and subscribe to multiple topics. The Server (Broker), a Client can publish and subscribe to multiple
MQTT Broker is responsible for distributing messages published by the topics. The Broker, which acts as the Resource Server (RS), is
publishers to their subscribers. Messages are published under a responsible for distributing messages published by the publishers to
Topic Name, and subscribers must subscribe to the Topic Names to their subscribers. In the rest of the document the terms "RS", "MQTT
receive the corresponding messages. The Broker uses the Topic Name Server" and "Broker" are used interchangeably.
in a published message to determine which subscribers to relay the
messages.
In this document, topics, more specifically, Topic Names, are treated Messages are published under a Topic Name, and subscribers must
as resources. The Clients are assumed to have identified the subscribe to the Topic Names to receive the corresponding messages.
publish/subscribe topics of interest out-of-band (topic discovery is The Broker uses the Topic Name in a published message to determine
not a feature of the MQTT protocol). A resource owner can pre- which subscribers to relay the messages. In this document, topics,
configure policies at the AS that give Clients publish or subscribe more specifically, Topic Names, are treated as resources. The
Clients are assumed to have identified the publish/subscribe topics
of interest out-of-band (topic discovery is not a feature of the MQTT
protocol). A Resource Owner can pre-configure policies at the
Authorisation Server (AS) that give Clients publish or subscribe
permissions to different topics. permissions to different topics.
Clients use an access token, bound to a proof-of-possession (PoP) key Clients prove their permission to publish/subscribe to topics hosted
to authorize with the MQTT Broker their connection and publish/ on an MQTT broker using an access token, bound to a proof-of-
subscribe permissions to topics. In the context of this ACE profile, possession (PoP) key. This document describes how to authorize the
the Broker acts as the Resource Server (RS). In the rest of the following exchanges between the Clients and the Broker.
document the terms "RS" and "Broker" are used interchangeably. This
document describes how to authorise the following exchanges between
the Clients and the Broker.
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
This document does not protect the contents of the PUBLISH message Clients use MQTT PUBLISH message to publish to a topic. This
from the Broker, and hence, the content of the the PUBLISH message is document does not protect the payload of the PUBLISH message from the
not signed or encrypted separately for the subscribers. This Broker, and hence, the payload is not signed or encrypted specificaly
functionality may be implemented using the proposal outlined in the for the subscribers. This functionality may be implemented using the
CoAP Pub-Sub Profile [I-D.palombini-ace-coap-pubsub-profile]. proposal outlined in the CoAP Pub-Sub 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 the 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 JWT tokens, this document follows RFC 7800 [RFC7800] for
PoP semantics for JWTs. The Client-AS and RS-AS may also be other PoP semantics for JWTs. The Client-AS and RS-AS MAY also use
than HTTPS e.g., CoAP or MQTT. Implementations MAY also use protocols other than HTTP e.g., CoAP or MQTT. Implementations MAY
'application/ace+cbor' content type, and CBOR encoding, and CBOR Web also use 'application/ace+cbor' content type, and CBOR encoding, and
Token (CWT) and associated PoP semantics to reduce the protocol CBOR Web Token (CWT) and associated PoP semantics to reduce the
memory and bandwidth requirements. For more information on Proof of protocol memory and bandwidth requirements. For more information on
Possession semantics for CWTs, see Proof-of-Possession Key Semantics Proof of Possession semantics for CWTs, see Proof-of-Possession Key
for CBOR Web Tokens (CWTs) [I-D.ietf-ace-cwt-proof-of-possession]. 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 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in 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).
The term "Resource" is used to refer to an MQTT Topic Name, which is The term "resource" is used to refer to an MQTT Topic Name, which is
defined in Section 1.3. Hence, the "Resource Owner" is any entity defined in Section 1.3. Hence, the "Resource Owner" is any entity
that can authoritatively speak for the topic. 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
skipping to change at page 5, line 23 skipping to change at page 5, line 23
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.
Client
A device or program that uses MQTT.
Application Message Application Message
The data carried by the MQTT protocol. The data has an The data carried by the MQTT protocol. The data has an
associated QoS level and a Topic Name. associated QoS level and a Topic Name.
QoS level QoS level
The level of assurance for the delivery of an Application The level of assurance for the delivery of an Application
Message. The QoS level can be 0-2, where "0" indicates "At Message. The QoS level can be 0-2, where "0" indicates "At
most once delivery", "1" "At least once delivery", and "2" most once delivery", "1" "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). of Service (QoS).A Subscription is associated with a single
session.
Topic Filter Topic Filter
An expression that indicates interest in one or more Topic An expression that indicates interest in one or more Topic
Names. Topic Filters may include wildcards. Names. Topic Filters may include wildcards.
MQTT sends various control 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 the QoS level 2.
CONNECT CONNECT
Client request to connect to the Broker. After a network Client request to connect to the Broker. This is the first
connection is established, this is the first packet sent by a packet sent by a Client.
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 to the Broker to the Client as part
skipping to change at page 6, line 37 skipping to change at page 6, line 40
PUBACK PUBACK
Response to PUBLISH request with QoS level 1. PUBACK can be Response to PUBLISH request with QoS level 1. PUBACK can be
sent from the Broker to a Client or a Client to the Broker. sent from the Broker to a Client or a Client to the Broker.
PUBREC PUBREC
Response to PUBLISH request with QoS level 2. PUBREC can be Response to PUBLISH request with QoS level 2. PUBREC can be
sent from the Broker to a Client or a Client to the Broker. sent from the Broker to a Client or a Client to the Broker.
SUBSCRIBE SUBSCRIBE
The Client subscribe request. Subscribe request sent from a Client.
SUBACK SUBACK
Subscribe acknowledgment. Subscribe acknowledgment.
PINGREQ PINGREQ
A ping request sent from a Client to the Broker. It signals A ping request sent from a Client to the Broker. It signals
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.
skipping to change at page 7, line 16 skipping to change at page 7, line 18
If the network connection is not closed normally, the Server If the network connection is not closed normally, the Server
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 connection MQTT Broker. Figure 1 shows the basic protocol flow during
set-up.The token request and response use the /token endpoint at the connection set-up.The token request and response use the token
AS, specified in the Section 5.6 of the ACE framework endpoint at the AS, specified in the 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 the Section 5.7 of the ACE
framework. The Client and Broker use HTTPS to communicate to AS via framework. The Client and Broker use HTTPS to communicate to AS via
these endpoints. The Client and Broker use only MQTT to communicate these endpoints. The Client and Broker use only MQTT to communicate
between them. 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.,
skipping to change at page 8, line 36 skipping to change at page 8, line 36
| request (optional) | RS-AS interface | | request (optional) | RS-AS interface |
| | (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. When requesting an access acquisition by the Client from the AS. The Client and the AS MUST
token from the AS, the Client follows the token request as described perform mutual authentication. When requesting an access token from
in Section 5.6.1 of the ACE framework [I-D.ietf-ace-oauth-authz], the AS, the Client follows the token request as described in
Section 5.6.1 of the ACE framework [I-D.ietf-ace-oauth-authz],
howevever, it MUST set the profile parameter to 'mqtt_tls'. The howevever, it MUST set the profile parameter to 'mqtt_tls'. The
media format is 'application/ace+json'. The AS uses JSON in the media format is 'application/ace+json'. The AS uses JSON in the
payload of its responses to both to the Client and the RS. payload of its responses to both to the 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 included 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.
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' parameter Note that the 'cnf' parameter in the web tokens are to be consumed by
containing the information about the public key used by the RS to the RS and not the Client. The PoP token may include a 'rs_cnf'
authenticate as described in [I-D.ietf-ace-oauth-params]. parameter containing the information about 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 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 the Section 5.6.3 of 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 MAY authenticate to the Broker over MQTT or TLS. For MQTT, Client MUST authenticate to the Broker either over MQTT or TLS. For
the options are "None" and "ace". For TLS, the options are "Anon" MQTT, the options are "None" and "ace". For TLS, the options are
for anonynous client, and "Known(RPK/PSK)" for Raw Public Keys (RPK) "Anon" for anonynous client, and "Known(RPK/PSK)" for Raw Public Keys
and Pre-Shared Keys (PSK), respectively. Combined, the Client (RPK) and Pre-Shared Keys (PSK), respectively. Combined, the Client
authentication takes the following options: authentication takes 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
skipping to change at page 10, line 4 skipping to change at page 10, line 5
permissions passed during the TLS authentication. permissions passed during the TLS authentication.
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' (thumbrint 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]), then the client MUST validate the RS
certificate against this thumbprint. certificate against this thumbprint.
2.2.2. authz-info: The Authorization Information Topic 2.2.2. authz-info: The Authorization Information Topic
In the cases when the Client MUST transport the token to the Broker In the cases when the Client MUST transport the token to the Broker
before the TLS handshake, the Client connects to the Broker and first, the Client connects to the Broker to publish its token to the
publishes its token to the "authz-info" topic. The "authz-info" "authz-info" topic. The "authz-info" topic MUST be publish-only
topic MUST be publish-only (i.e., the Clients are not allowed to (i.e., the Clients are not allowed to subscribe to it). "authz-info"
subscribe to it). "authz-info" is not protected, and hence, the is not protected, and hence, the Client uses the "TLS:Anon-MQTT:None"
Client authenticates with the RS using the "TLS:Anon-MQTT:None" option over a TLS connection. After publishing the token, the Client
option. After publishing the token, the Client disconnects from the disconnects from the Broker and is expected to reconnect, potentially
Broker and is expected to try reconnecting over TLS. using client authentication with TLS.
The Broker stores and indexes all tokens received to this topic in The Broker stores and indexes all tokens received to this topic in
its key store similar to DTLS profile for ACE 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 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 RS stores only one token
per proof-of-possession key, and any other token linked to the same per proof-of-possession key, and any other token linked to the same
key overwrites existing token at the RS. key overwrites existing token at the RS.
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
skipping to change at page 10, line 47 skipping to change at page 10, line 48
MUST send a DISCONNECT message with the reason code '0x87 (Not 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 token does not parse to a token, the RS MUST
send a DISCONNECT with the reason code '0x99 (Payload format 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 For 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 MAY return 'Not authorized' in PUBACK. If the token
does not parse to a token, the PUBACK reason code is '0x99 (Payload does not parse to a token, the PUBACK reason code is '0x99 (Payload
format invalid)'. format invalid)'.
It must be noted that when the AS 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 a 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
skipping to change at page 12, line 34 skipping to change at page 12, line 36
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, to achieve a clean session (i.e., the session does not
continue an existing session), the Client sets the Clean Start Flag continue an existing session), the Client sets the Clean Start Flag
to 1 and, the Session Expiry Interval to 0 in the CONNECT message. to 1 and, the Session Expiry Interval to 0 in the CONNECT message.
However, in this profile, the Broker MUST always start with a clean However, in this profile, the Broker MUST always start with a clean
session regardless of how these parameters are set. The Broker MUST session regardless of how these parameters are set. The clean
session requirement is for avoiding the Broker to keep unnecessary
session state for unauthorised clients. Therefore, the Broker MUST
set the Session Present flag to 0 in the CONNACK packet to signal the set the Session Present flag to 0 in the CONNACK packet to signal the
Client that the Broker started a clean session. Client that the Broker started a clean session.
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. Based which has a property identifier 22 (0x16) and is binary data. The
on the Authentication Data, this profile allows: binary data in MQTT is represented by a two-byte integer length,
which indicates the number of data bytes, followed by that number of
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 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 token and For this option, the Authentication Data MUST contain the two-byte
the keyed message digest (MAC) or the Client signature. The secret integer token length, the token, and the keyed message digest (MAC)
that is used for the proof-of-possession calculation, i.e., to or the Client signature. The content to calculate the keyed message
calculate the keyed message digest (MAC) or the Client signature, 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 secret is exported from TLS using the Section 7.5 of [RFC8446]). The content is exported from TLS using
exporter label 'EXPORTER-ACE-Sign-Challenge', an empty context, and the exporter label 'EXPORTER-ACE-MQTT-Sign-Challenge', an empty
length of 32 bytes. The token is also validated as described in context, and length of 32 bytes. The token is also validated as
Section 2.2.5 and the server responds with a CONNACK with the described in Section 2.2.5 and the server responds with a CONNACK
appropriate response code. with the appropriate response code.
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 only includes the token, the RS MUST respond with
an AUTH packet, with the Authenticate Reason Code set to '0x18 an AUTH packet, with the Authenticate Reason Code set to '0x18
(Continue Authentication)'. This packet includes the Authentication (Continue Authentication)'. This packet includes the Authentication
Method, which MUST be set to 'ace' and Authentication Data. The Method, which MUST be set to 'ace' and Authentication Data. The
Authentication Data MUST NOT be empty and contains an 8-byte nonce as Authentication Data MUST NOT be empty and contains an 8-byte nonce as
a challenge for the Client. The Client responds to this with an AUTH a challenge for the Client. The Client responds to this with an AUTH
packet with a reason code '0x18 (Continue Authentication)'. packet with a reason code '0x18 (Continue Authentication)'.
Similarly, the Client packet sets the Authentication Method to 'ace'. Similarly, the Client packet sets the Authentication Method to 'ace'.
The Authentication Data in the Client's response contains a client- The Authentication Data in the Client's response is formatted as
generated 8-byte nonce, and the signature or MAC computed over the RS client nonce length, the client nonce, and the signature or MAC
nonce concatenated with the client nonce. Next, the token is computed over the RS nonce concatenated with the client nonce. Next,
validated as described in Section 2.2.5. the token is validated as described in Section 2.2.5.
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
| | | |
<-------------+ AUTH '0x18 (Continue Authentication)' <-------------+ AUTH '0x18 (Cont. Authentication)'
| | 8-byte nonce as RS challenge | | 8-byte nonce as RS challenge
| | | |
|------------>| AUTH '0x18 (Continue Authentication)' |------------>| AUTH '0x18 (Cont. Authentication)'
| | 8-byte client nonce + signature/MAC | | 8-byte client nonce + signature/MAC
| | | |
| |-----+ Token validation (may involve introspection) | |---+ Token validation
| | | | | | (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 2.2.4.3. Unauthorised Request: Authorisation Server Discovery
Finally, this document allows the CONNECT message to have the Finally, this document allows the CONNECT message to have the
Authentication Method set to 'ace' followed by an empty Authentication Method set to 'ace' omitting the Authentication Data
Authentication Data field. This is the AS discovery option and the field. This is the AS discovery option and the RS responds with the
RS responds with the CONNACK reason code '0x87 (Not Authorized)' and CONNACK reason code '0x87 (Not Authorized)' and includes a User
includes a User Property (identified by 38 (0x26)) for the AS Property (identified by 38 (0x26)) for the AS Request Creation Hints.
creation hints as defined in the Section 5.1.2 of the ACE framework The User Property is a UTF-8 string pair, composed of a name and a
[I-D.ietf-ace-oauth-authz]. 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. Validation of MAC, depending on how the PoP protocol is implemented. HS256 and
the signature or MAC MUST fail if the signature algorithm is set to RS256 are mandatory to implement depending on the choice of symmetric
"none", when the key used for the signature algorithm cannot be or asymmetric validation. Validation of the signature or MAC MUST
determined, or the computed and received signature/MAC do not match. fail if the signature algorithm is set to "none", when the key used
for the signature algorithm cannot be determined, or the 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. The reason code of the CONNACK
is '0x00 (Success)' if the token validation is successful. The is '0x00 (Success)' if the token validation is successful. The
Broker MUST also set Session Present to 0 in the CONNACK packet to Broker MUST also set Session Present to 0 in the CONNACK packet to
signal a clean session to the Client. In case of an invalid PoP signal a clean session to the Client. In case of an invalid PoP
token, the CONNACK reason code is '0x87 (Not Authorized)'. token, the CONNACK reason code is '0x87 (Not Authorized)'.
skipping to change at page 15, line 36 skipping to change at page 15, line 40
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 needs to use the scope field in the token (or in the introspection
result). The scope field contains the publish and subscribe result). The scope field contains the publish and subscribe
permissions for the Client. Scope strings SHOULD be encoded as a permissions for the Client. Scope strings SHOULD be encoded as a
permission, followed by an underscore, followed by a topic filter. permission, followed by an underscore, followed by a topic filter.
Two permissions apply to topic filters: 'publish' and 'subscribe'. Two permissions apply to topic filters: 'publish' and 'subscribe'.
Topic filters are implemented as described in MQTT specification and Topic filters are implemented as described in the Section 4.7 of MQTT
includes special wildcard characters. The multi-level wildcard, '#', v5.0 - the OASIS Standard [MQTT-OASIS-Standard-v5] and includes
matches any number of levels within a topic, and the single-level special wildcard characters. The multi-level wildcard, '#', matches
wildcard, '+', matches one topic level. any number of levels within a 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 multiple such strings, space
delimited, e.g., '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).
skipping to change at page 16, line 17 skipping to change at page 16, line 19
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 above, a client sending
a PUBLISH message to 'a/topic3' would be allowed to publish, as the a PUBLISH message to 'a/topic3' would be allowed to publish, as the
scope includes the string 'publish_+/topic3'. 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 RS must publish
the message to all valid subscribers of the topic. In the case of an the message to all valid subscribers of the topic. In the case of an
authorization failure, an error MAY be returned to the Client. For authorization failure, an error MAY be returned to the Client. For
this the QoS level of the PUBLISH message MUST be set to greater than this, the QoS level of the PUBLISH message MUST be set to greater
or equal to 1. This guarantees that RS responds with either a PUBACK than or equal to 1. This guarantees that RS responds with either a
or PUBREC packet with reason code '0x87 (Not authorized)'. PUBACK or PUBREC packet with reason code '0x87 (Not authorized)'. On
receiving a PUBACK with '0x87 (Not authorized)', the Client MAY
On receiving a PUBACK with '0x87 (Not authorized)', the Client MAY
reauthenticate as described in Section 4, and pass a new token reauthenticate as described in Section 4, and pass a new token
following the same PoP methods as described in Figure 2. following the same PoP methods as described in Figure 2.
For QoS level 0, the RS sends a DISCONNECT with reason code '0x87
(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,
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 stop forwarding messages to the unauthorized subscribers. RS MUST NOT forward messages to the unauthorized subscribers. There
There is no way to inform the Clients with invalid tokens that an 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 RS SHOULD send a DISCONNECT message with the reason
code '0x87 (Not authorized)'. Note that the server-side DISCONNECT code '0x87 (Not authorized)'.
is a new feature of MQTT v5.0 (in MQTT v3.1.1, the server needs to
drop the connection).
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. result. The Topic Filters MUST be equal or a subset of the scopes
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
skipping to change at page 18, line 19 skipping to change at page 18, line 29
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 v3.1.1 Client. MQTT v.5 brokers MAY also implement this method.
Brokers that do not support MQTT v3.1.1 clients return a CONNACK
packet with Reason Code '0x84 (Unsupported Protocol Version)' in
response to the clients' CONNECT packet.
6.1. Token Transport 6.1. Token Transport
As in MQTT v5, The Token MAY either be transported before the TLS As in MQTT v5, The Token MAY either be transported before by
session publishing to the "authz-info" topic, or inside the CONNECT publishing to the "authz-info" topic, or inside the CONNECT message.
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 it is not possible for the Broker to communicate the result of the
token validation as PUBACK reason codes or server-side DISCONNECT token validation as PUBACK reason codes or server-side DISCONNECT
messages are not supported. In any case, an invalid token would fail messages are not supported. In any case, an invalid token would fail
the subsequent TLS handshake, which can prompt the Client to obtain a the subsequent 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 of the CONNECT message.
skipping to change at page 22, line 20 skipping to change at page 22, line 20
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 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.palombini-ace-coap-pubsub-profile]. However, this solution [I-D.ietf-ace-pubsub-profile]. However, this solution would still
would still not provide privacy for other properties of the message not provide privacy for other properties of the message such as Topic
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-09 (work in progress), December 2019.
[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-29 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33
(work in progress), December 2019. (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-07 (work in progress), December 2019. params-12 (work in progress), February 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", Headers for carrying and referencing X.509 certificates",
draft-ietf-cose-x509-05 (work in progress), November 2019. draft-ietf-cose-x509-05 (work in progress), November 2019.
[I-D.palombini-ace-coap-pubsub-profile]
Palombini, F., "CoAP Pub-Sub Profile for Authentication
and Authorization for Constrained Environments (ACE)",
draft-palombini-ace-coap-pubsub-profile-06 (work in
progress), November 2019.
[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-
v5.0-os.html>. v5.0-os.html>.
skipping to change at page 23, line 35 skipping to change at page 23, line 34
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>. March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>. June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)",
RFC 7800, DOI 10.17487/RFC7800, April 2016,
<https://www.rfc-editor.org/info/rfc7800>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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,
skipping to change at page 24, line 14 skipping to change at page 24, line 22
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-cwt-proof-of-possession] [I-D.ietf-ace-pubsub-profile]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Palombini, F., "Pub-Sub Profile for Authentication and
Tschofenig, "Proof-of-Possession Key Semantics for CBOR Authorization for Constrained Environments (ACE)", draft-
Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- ietf-ace-pubsub-profile-00 (work in progress), January
possession-11 (work in progress), October 2019. 2020.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)",
RFC 7800, DOI 10.17487/RFC7800, April 2016,
<https://www.rfc-editor.org/info/rfc7800>.
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
skipping to change at page 25, line 19 skipping to change at page 25, line 18
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 03 to 04:
o Linked the terms Broker and MQTT server more at the introduction
of the document.
o Clarified support for MQTTv3.1.1 and removed phrases that might be
considered as MQTTv5 is backward compatible with MQTTv3.1.1
o Corrected the Informative and Normative references.
o For AS discovery, clarified the CONNECT message omits the
Authentication Data field. Specified the User Property MUST be
set to "ace_as_hint" for AS Request Creation Hints.
o Added that MQTT v5 brokers MAY also implement reduced interactions
described for MQTTv3.1.1.
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
authorized)'.
o Added a pointer to section 4.7 of MQTTv5 spec for more information
on topic names and filters.
o Added HS256 and RS256 are mandatory to implement depending on the
choice of symmetric or asymmetric validation.
o Added MQTT to the TLS exporter label to make it application
specific: 'EXPORTER-ACE-MQTT-Sign-Challenge'.
o Added a format for Authentication Data so that length values
prefix the token (or client nonce) when Authentication Data
contains more than one piece of information.
o Clarified clients still connect over TLS (server-side) for the
authz-info flow.
Version 02 to 03: Version 02 to 03:
o Added the option of Broker certificate thumbprint in the 'rs_cnf' o Added the option of Broker certificate thumbprint in the 'rs_cnf'
sent to the Client. sent to the Client.
o Clarified the use of a random nonce from the TLS Exporter for PoP, o Clarified the use of a random nonce from the TLS Exporter for PoP,
added to the IANA requirements that the label should be added to the IANA requirements that the label should be
registered. registered.
o Added a client nonce, when Challenge/Response Authentication is o Added a client nonce, when Challenge/Response Authentication is
skipping to change at page 26, line 46 skipping to change at page 27, line 35
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
Nominet Brunel University
4 Kingdom Street Dept. of Computer Science
London W2 6BD Uxbridge UB8 3PH
UK UK
Email: csengul@acm.org Email: csengul@acm.org
Anthony Kirby Anthony Kirby
Oxbotica Oxbotica
1a Milford House, Mayfield Road, Summertown 1a Milford House, Mayfield Road, Summertown
Oxford OX2 7EL Oxford OX2 7EL
UK UK
Email: anthony@anthony.org Email: anthony@anthony.org
Paul Fremantle Paul Fremantle
University of Portsmouth University of Portsmouth
School of Computing, Buckingham House School of Computing, Buckingham House
Portsmouth PO1 3HE Portsmouth PO1 3HE
UK UK
Email: paul.fremantle@port.ac.uk Email: paul.fremantle@port.ac.uk
 End of changes. 59 change blocks. 
162 lines changed or deleted 221 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/