draft-ietf-ace-mqtt-tls-profile-01.txt   draft-ietf-ace-mqtt-tls-profile-02.txt 
ACE Working Group C. Sengul ACE Working Group C. Sengul
Internet-Draft Nominet Internet-Draft Nominet
Intended status: Standards Track A. Kirby Intended status: Standards Track A. Kirby
Expires: April 7, 2020 Oxbotica Expires: May 5, 2020 Oxbotica
P. Fremantle P. Fremantle
University of Portsmouth University of Portsmouth
October 5, 2019 November 2, 2019
MQTT-TLS profile of ACE MQTT-TLS profile of ACE
draft-ietf-ace-mqtt-tls-profile-01 draft-ietf-ace-mqtt-tls-profile-02
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) to enable authorization Authorization for Constrained Environments) framework to enable
in an MQTT-based publish-subscribe messaging system. Proof-of- authorization in an MQTT-based publish-subscribe messaging system.
possession keys, bound to OAuth2.0 access tokens, are used to Proof-of-possession keys, bound to OAuth2.0 access tokens, are used
authenticate and authorize MQTT Clients. The protocol relies on TLS to authenticate and authorize MQTT Clients. The protocol relies on
for confidentiality and server authentication. TLS for confidentiality and server 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 April 7, 2020. This Internet-Draft will expire on May 5, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 15 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . . . . 4 1.3. MQTT-Related Terminology . . . . . . . . . . . . . . . . 4
2. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 6 2. Authorizing Connection Requests . . . . . . . . . . . . . . . 7
2.1. Authorizing Connection Establishment . . . . . . . . . . 7 2.1. Client Token Request to the Authorization Server (AS) . . 8
2.1.1. Client Token Request to the Authorization Server (AS) 8 2.2. Client Connection Request to the Broker (C) . . . . . . . 8
2.1.2. Client Connection Request to the Broker (C) . . . . . 8 2.2.1. Client-Server Authentication over TLS and MQTT . . . 8
2.1.2.1. Proof-of-Possession over Predefined Field . . . . 10 2.2.2. authz-info: The Authorization Information Topic . . . 9
2.1.2.2. Proof-of-Possession via challenge/response . . . 11 2.2.3. Transporting Access Token Inside the MQTT CONNECT . . 9
2.1.2.3. Unauthorised Request: Authorisation Server 2.2.4. Authentication Using AUTH Property . . . . . . . . . 11
2.2.4.1. Proof-of-Possession Using a Challenge from the
TLS session . . . . . . . . . . . . . . . . . . . 11
2.2.4.2. Proof-of-Possession via Broker-generated
Challenge/Response . . . . . . . . . . . . . . . 12
2.2.4.3. Unauthorised Request: Authorisation Server
Discovery . . . . . . . . . . . . . . . . . . . . 12 Discovery . . . . . . . . . . . . . . . . . . . . 12
2.1.3. Token Validation . . . . . . . . . . . . . . . . . . 12 2.2.5. Token Validation . . . . . . . . . . . . . . . . . . 13
2.1.4. The Broker's Response to Client Connection Request . 13 2.2.6. The Broker's Response to Client Connection Request . 13
2.2. Authorizing PUBLISH Messages . . . . . . . . . . . . . . 13 3. Authorizing PUBLISH Messages . . . . . . . . . . . . . . . . 14
2.2.1. PUBLISH Messages from the Publisher Client to the 3.1. PUBLISH Messages from the Publisher Client to the Broker 14
Broker . . . . . . . . . . . . . . . . . . . . . . . 13 3.2. PUBLISH Messages from the Broker to the Subscriber
2.2.2. PUBLISH Messages from the Broker to the Subscriber Clients . . . . . . . . . . . . . . . . . . . . . . . . . 14
Clients . . . . . . . . . . . . . . . . . . . . . . . 14 4. Authorizing SUBSCRIBE Messages . . . . . . . . . . . . . . . 15
2.3. Authorizing SUBSCRIBE Messages . . . . . . . . . . . . . 14 5. Token Expiration and Reauthentication . . . . . . . . . . . . 15
2.4. Token Expiration and Reauthentication . . . . . . . . . . 15 6. Handling Disconnections and Retained Messages . . . . . . . . 16
2.5. Handling Disconnections and Retained Messages . . . . . . 15 7. Reduced Protocol Interactions for MQTT v3.1.1 . . . . . . . . 16
3. Reduced Protocol Interactions for MQTT v3.1.1 . . . . . . . . 16 7.1. Token Transport . . . . . . . . . . . . . . . . . . . . . 16
3.1. Token Transport . . . . . . . . . . . . . . . . . . . . . 16 7.2. Handling Authorization Errors . . . . . . . . . . . . . . 18
3.2. Handling Authorization Errors . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. Checklist for profile requirements . . . . . . . . . 22
Appendix A. Checklist for profile requirements . . . . . . . . . 21 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 22
Appendix B. The Authorization Information Endpoint . . . . . . . 21 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix C. Document Updates . . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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 a Broker
use MQTT to exchange Application messages. The protocol relies on use MQTT to exchange Application Messages. The protocol relies on
TLS for communication security between entities. The MQTT protocol TLS for communication security between entities. The MQTT protocol
interactions are described based on the MQTT v5.0 - the OASIS interactions are described based on the MQTT v5.0 - the OASIS
Standard [MQTT-OASIS-Standard-v5]. It is expected that MQTT Standard [MQTT-OASIS-Standard-v5]. It is expected that MQTT
deployments will retain backward compatibility for MQTT v3.1.1 deployments will retain backward compatibility for MQTT v3.1.1
clients, and therefore, this document describes a reduced set of clients, and therefore, this document also describes a reduced set of
protocol interactions suited to MQTT v3.1.1 - the OASIS Standard protocol interactions suited to MQTT v3.1.1 - the OASIS Standard
[MQTT-OASIS-Standard]. However, it is RECOMMENDED to use MQTT v5.0 [MQTT-OASIS-Standard]. However, it is RECOMMENDED to use MQTT v5.0
as it works more naturally with ACE-style authentication and as it works more naturally with ACE-style authentication and
authorization. authorization.
MQTT is a publish-subscribe protocol and supports two main types of MQTT is a publish-subscribe protocol and after connecting to the MQTT
Client operation: publish and subscribe. Once connected, a Client Broker, a Client can publish and subscribe to multiple topics. The
can publish to multiple topics, and subscribe to multiple topics. MQTT Broker is responsible for distributing messages published by the
The MQTT Broker is responsible for distributing messages published by publishers to the appropriate subscribers. Publisher messages
the publishers to the appropriate subscribers. Each publish message
contains a Topic Name, which is used by the Broker to filter the contains a Topic Name, which is used by the Broker to filter the
subscribers for the message. Subscribers must subscribe to the subscribers for the message. Subscribers must subscribe to the
topics to receive the corresponding messages. topics to receive the corresponding messages.
In this document, message topics are treated as resources. Clients In this document, message topics are treated as resources. The
use an access token, bound to a key (the proof-of-possession key) to Clients are assumed to have identified the publish/subscribe topics
authorize with the MQTT Broker their connection and publish/subscribe of interest out-of-band (topic discovery is not a feature of the MQTT
permissions to topics. In the context of this ACE profile, the MQTT protocol). A resource owner can pre-configure policies at the AS
Broker acts as the Resource Server (RS). In the rest of the document that give Clients publish or subscribe permissions to different
RS and Broker are used interchangeably. To provide communication topics.
confidentiality and Resource Server authentication, TLS is used.
This document makes the same assumptions as the Section 4 of the ACE
framework [I-D.ietf-ace-oauth-authz] regarding Client and RS
registration with the AS and establishing of keying material.
This document describes the authorization of the following exchanges Clients use an access token, bound to a proof-of-possession (PoP) key
between Clients and the Broker. to authorize with the MQTT Broker their connection and publish/
subscribe permissions to topics. In the context of this ACE profile,
the MQTT Broker acts as the Resource Server (RS). In the rest of the
document RS and Broker are used interchangeably. This document
describes the following exchanges between Clients and the Broker.
o Connection establishment between the Clients and the Broker o Authorizing connection requests from the Clients to the Broker
o Publish messages from the Clients to the Broker, and from the o Authorizing publish messages from the Clients to the Broker, and
Broker to the Clients from the Broker to the Clients
o Subscribe messages from the Clients to the Broker o Authorizing subscribe messages from Clients to the Broker
While the Client-Broker exchanges are over MQTT, the required Client- To provide communication confidentiality and Resource Server
AS and RS-AS interactions are described for HTTPS-based authentication, TLS is used, and TLS 1.3 is RECOMMENDED. This
communication, using 'application/ace+json' content type, and unless document makes the same assumptions as the Section 4 of the ACE
otherwise specified, using JSON encoding. The token may be a framework [I-D.ietf-ace-oauth-authz] regarding Client and RS
reference, or JWT. For JWT tokens, this document follows RFC 7800 registration with the Authorization Server (AS) and setting up keying
[RFC7800] for PoP semantics for JWTs. The Client-AS and RS-AS may material. While the Client-Broker exchanges are only over MQTT, the
also be based on CoAP. It is also possible to use 'application/ required Client-AS and RS-AS interactions are described for HTTPS-
ace+cbor' content type, and CBOR encoding, and CWT and associated PoP based communication, using 'application/ace+json' content type, and
semantics to reduce the protocol memory and bandwidth requirements. unless otherwise specified, using JSON encoding. The token may be a
For more information on Proof of Possession semantics for CWTs, see reference, or JSON Web Token (JWT). For JWT tokens, this document
Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) follows RFC 7800 [RFC7800] for PoP semantics for JWTs. The Client-AS
and RS-AS may also be other than HTTPS e.g., CoAP or MQTT. It may
also be possible to use 'application/ace+cbor' content type, and CBOR
encoding, and CBOR Web Token (CWT) and associated PoP semantics to
reduce the protocol memory and bandwidth requirements. For more
information on Proof of Possession semantics for CWTs, see Proof-of-
Possession Key Semantics for CBOR Web Tokens (CWTs)
[I-D.ietf-ace-cwt-proof-of-possession]. [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.
skipping to change at page 5, line 4 skipping to change at page 5, line 9
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. For Broker to publish and subscribe to Application Messages. For
additional information, please refer to the MQTT v5.0 - the OASIS additional information, please refer to the MQTT v5.0 - the OASIS
Standard [MQTT-OASIS-Standard-v5] or the MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard-v5] or the MQTT v3.1.1 - the OASIS
Standard [MQTT-OASIS-Standard]. 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 and acts as an intermediary between The Server in MQTT. It acts as an intermediary between
Clients that publish 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.
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
The level of assurance for the delivery of an Application
Message. The QoS level can be 0-2, where "0" indicates "At
most once delivery", "1" "At least once delivery", and "2"
"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).
Topic Filter Topic Filter
An expression that indicates interest in one or more Topic An expression that indicates interest in one or more Topic
skipping to change at page 5, line 42 skipping to change at page 6, line 5
Client request to connect to the Broker. After a network Client request to connect to the Broker. After a network
connection is established, this is the first packet sent by a connection is established, this is the first 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
Authentication Exchange. An AUTH packet is sent from the
Client to the Broker or to the Broker to the Client as part
of an extended authentication exchange. AUTH Properties
include Authentication Method and Authentication Data. The
Authentication Method is set in the CONNECT packet, and
consequent AUTH packets follow the same Authentication
Method. The contents of the Authentication Data are defined
by the Authentication Method.
PUBLISH PUBLISH
Publish packet that can be sent from a Client to the Broker, Publish packet that can be sent from a Client to the Broker,
or from the Broker to a Client. or from the Broker to a Client.
PUBACK PUBACK
Response to PUBLISH packet with QoS level 1. PUBACK can be Response to PUBLISH packet 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 packet with QoS level 2. PUBREC can be Response to PUBLISH packet with QoS level 2. PUBREC can be
skipping to change at page 6, line 16 skipping to change at page 6, line 36
SUBSCRIBE SUBSCRIBE
The Client subscribe request. The Client subscribe request.
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 still alive. confirm that the Broker is still alive. The "Keep Alive"
period is set in the CONNECT message.
Will
An application message published by the Server after the
network connection is closed in cases where the network
connection is not closed normally. If the Will Flag is set,
then the payload of the CONNECT message has information about
the Will. The Will consists of the Will Properties, Will
Topic, and Will Payload fields in the CONNECT message.
2. Protocol Interactions
This section describes the following exchanges between Clients, the
Broker, and the Authorization Server according to the MQTT v5.0.
o Authorizing connection establishment between the Clients and the
Broker
o Authorizing publish messages from the Clients to the Broker, and
from the Broker to the Clients
o Authorizing subscribe messages from Clients to the Broker PINGRESP
Response sent by the Broker to the Client in response to
PINGREQ. It indicates the Broker is alive.
Section 3 describes how these exchanges can also be supported using Will
the MQTT v3.1.1. MQTT v5.0 brokers MAY also only support the basic If the network connection is not closed normally, the Server
operation; however, this is NOT RECOMMENDED. sends a last Will message for the Client, if the Client
provided one in its CONNECT message. If the Will Flag is
set, then the payload of the CONNECT message includes
information about the Will. The information consists of the
Will Properties, Will Topic, and Will Payload fields.
In this profile document, message topics are treated as resources. 2. Authorizing Connection Requests
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 AS that give Clients publish or subscribe permissions to
different topics.
2.1. Authorizing Connection Establishment This section specifies how Client connections can be authorized by an
MQTT Broker.Figure 1 shows the basic protocol flow during connection
set-up.The token request and response use the /token endpoint of the
authorization server, specified in the Section 5.6 of the ACE
framework [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 framework. The Client and Broker use HTTPS to
communicate to AS via these endpoints. The Client and Broker use
only MQTT to communicate between them.
This section specifies how Clients establish an authorized connection If the Client is resource-constrained, the Client's Authorisation
to an MQTT Broker. Figure 1 shows the basic protocol flow during Server may carry out the token request on behalf of the Client, and
connection establishment.The token request and response use the later, onboard the Client with the token. Also, the C-AS and Broker-
/token endpoint of the authorization server, specified in the AS interfaces may be implemented using protocols other than HTTPS,
Section 5.6 of the ACE framework [I-D.ietf-ace-oauth-authz]. Steps e.g., CoAP or MQTT. The interactions between a Client and its Client
(D) and (E) are optional, and use the introspection endpoint, Authorization Server for token onboarding, and the MQTTS support for
specified in the Section 5.7 of the ACE framework. The Client and token requests are out of scope of this document.
Broker use HTTPS to communicate to AS via these endpoints. If the
Client is resource-constrained, a Client Authorisation Server may
carry out the token request on behalf of the Client, and later,
onboard the Client with the token. Also, these interfaces may be
implemented using other protocols, e.g., CoAP or MQTT. The
interactions between a Client and its Client Authorization Server for
token onboarding, and the MQTTS support for token requests 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 7, line 49 skipping to change at page 7, line 51
| | | | | | | |
| | +---v--------------+ | | +---v--------------+
| | | Broker (MQTTS) | | | | Broker (MQTTS) |
| | |__________________| | | |__________________|
| +(D)Introspection-| | | +(D)Introspection-| |
| request (optional) | RS-AS interface | | request (optional) | RS-AS interface |
| | (HTTPS) | | | (HTTPS) |
+-(E)Introspection---->|__________________| +-(E)Introspection---->|__________________|
response (optional) response (optional)
Figure 1: Connection establishment Figure 1: Connection set-up
2.1.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. When requesting an access
token from the AS, the Client MAY include parameters in its request token from the AS, the Client follows the token request as is
as defined in Section 5.6.1 of the ACE framework described in Section 5.6.1 of the ACE framework
[I-D.ietf-ace-oauth-authz]. The media format is 'application/ [I-D.ietf-ace-oauth-authz], howevever, it MUST set the profile
ace+json'. The profile parameter MUST be set to 'mqtt_tls'. The parameter to 'mqtt_tls'. The media format is 'application/ace+json'.
OAuth 2.0 AS uses a JSON structure in the payload of its responses The AS uses a JSON structure in the payload of its responses both to
both to client and RS. 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 (e.g., RS) and authorizes the Client for the indicated audience (i.e., RS) and
scopes (e.g., 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.
Note that the 'cnf' parameter in the web tokens are to be consumed by The 'cnf' parameter in the web tokens are to be consumed by the
the resource server and not the Client. resource server and not the Client. The PoP token may include a
'rs_cnf' parameter containing the information about the public key
used by the RS to authenticate as described in
[I-D.ietf-ace-oauth-params].
In the case of an error, the AS returns error responses for HTTP- In the case of an error, the AS returns error responses for HTTP-
based interactions as ASCII codes in JSON content, as defined in based interactions as ASCII codes in JSON content, as defined in
Section 5.2 of RFC 6749 [RFC6749]. Section 5.2 of RFC 6749 [RFC6749].
2.1.2. Client Connection Request to the Broker (C) 2.2. Client Connection Request to the Broker (C)
This section describes how the Client transports the token to the 2.2.1. Client-Server Authentication over TLS and MQTT
Broker (RS) via the CONNECT control message after the TLS handshake.
This is similar to an earlier proposal by Fremantle et al.
[fremantle14]. Alternatively, the token may be used for the TLS
session establishment as described in the DTLS profile for ACE
[I-D.gerdes-ace-dtls-authorize]. In this case, both the TLS PSK and
RPK handshakes MAY be supported. This may additionally require that
the Client transports the token to the Broker before the connection
establishment. To this end, the Broker MAY support /authz-info
endpoint via the "authz-info" topic. Then, to transport the token,
Clients publish to "authz-info" topic unauthorized. The topic
"authz-info" MUST be publish-only for Clients (i.e., the Clients are
not allowed to subscribe to it). This option is described in more
detail in Appendix B.
After the token acquisition, the Client connects to the RS (Broker) The Client and the Broker MUST perform mutual authentication. The
using the CONNECT message of MQTT over TLS. For server Client MAY authenticate to the Broker over MQTT or TLS. For MQTT,
authentication, the client MAY either have the ability to receive and the options are "None" and "ace". For TLS, the options are "Anon"
validate a certificate or a raw public key from the Broker. The for anonynous client, and "Known(RPK/PSK)" for Raw Public Keys (RPK)
client needs to use this raw public key in the TLS handshake together and Pre-Shared Keys (PSK), respectively. Combined, the Client
with an out-of-band validation technique (see RFC 7250 [RFC7250] for authentication takes the following options:
details).
Figure 2 shows the structure of the MQTT CONNECT control message used o "TLS:Anon-MQTT:None": This option is used only for the topics that
in MQTT v5.0. A CONNECT message is composed of a fixed header, a do not require authorization, including the "authz-info" topic.
variable header and a payload. The fixed header contains Control Publishing to the "authz-info" topic is described in
Packet Type (CPT), Reserved, and Remaining Length. The Variable Section 2.2.2.
Header contains the Protocol Name, Protocol Level, Connect Flags,
Keep Alive, and Properties. The Connect Flags in the variable header o "TLS:Anon-MQTT:ace": The token is transported inside the CONNECT
specify the behavior of the MQTT connection. It also indicates the message, and MUST be validated using one of the methods described
presence or absence of fields in the Payload. The payload contains in Section 2.2.2. This also supports a tokenless connection
one or more encoded fields, namely a unique Client identifier for the request for AS discovery.
Client, a Will Topic, Will Payload, User Name and Password. All but
the Client identifier can be omitted depending on flags in the o "TLS:Known(RPK/PSK)-MQTT:none": For the RPK, the token MUST have
Variable Header. been published to the "authz-info" topic. For the PSK, the token
MAY have be provided in the "psk_identity". The TLS session set-
up is as described in DTLS profile for ACE
[I-D.ietf-ace-dtls-authorize].
o "TLS:Known(RPK/PSK)-MQTT:ace": This option SHOULD NOT be chosen.
In any case, the token transported in the CONNECT overwrites any
permissions passed during the TLS authentication.
It is RECOMMENDED that the Client follows TLS:Anon-MQTT:ace.
The Broker MUST be authenticated during TLS handshake. If the Client
authentication included TLS:Known(RPK/PSK), then the Broker is
authenticated using the respective method. For the other Client
Authentication cases, to authenticate the Broker, the client MAY
either have the ability to receive and validate a server-side
certificate or an RPK from the Broker against the 'rs_cnf' parameter
in the token.
2.2.2. authz-info: The Authorization Information Topic
In the cases when the Client MUST transport the token to the Broker
before the TLS handshake, the Client connects to the Broker and
publishes its token to the "authz-info" topic. The "authz-info"
topic MUST be publish-only for Clients (i.e., the Clients are not
allowed to subscribe to it). The Broker stores and indexes all
tokens received to this topic in its key store similar to DTLS
profile for ACE [I-D.ietf-ace-dtls-authorize].
The Broker must verify the validity of the token (i.e., through local
validation or introspection) as described in Section 2.2.5. The
Broker returns 'Not authorized' error to a PUBLISH request if the QoS
level of this PUBLISH message is greater or equal to 1. After
publishing the token, the Client disconnects from the Broker and is
expected to try reconnecting over TLS.
2.2.3. Transporting Access Token Inside the MQTT CONNECT
This section describes how the Client transports the token to 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
authenticated during the TLS connection set-up. The approach
described in this section is similar to an earlier proposal by
Fremantle et al. [fremantle14].
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
header and a payload. The fixed header contains Control Packet Type
(CPT), Reserved, and Remaining Length. The Variable Header contains
the Protocol Name, Protocol Level, Connect Flags, Keep Alive, and
Properties. The Connect Flags in the variable header specify the
behavior of the MQTT connection. It also indicates the presence or
absence of fields in the Payload. The payload contains one or more
encoded fields, namely a unique Client identifier for the Client, a
Will Topic, Will Payload, User Name and Password. All but the Client
identifier can be omitted depending on flags in the Variable Header.
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) | empty or token or |
| token + PoP data | | token + PoP data |
+------------------------------------------------------+ +------------------------------------------------------+
| Payload: Client Identifier | | Payload |
+------------------------------------------------------+ +------------------------------------------------------+
Figure 2: MQTT CONNECT control message. (CPT=Control Packet Type, Figure 2: MQTT v5 CONNECT control message with ACE authentication.
Rsvd=Reserved, len.=length, Proto.=Protocol) (CPT=Control Packet Type)
Connect Flags include Clean Start, Will, Will QoS, Will Retain, The CONNECT message flags include Username, Password, Will retain,
Password and Username flags. Figure 6 shows how the MQTT connect Will QoS, Will Flag, Clean Start, and Reserved. Figure 6 shows how
flags MUST be set to initiate a connection with the Broker. the MQTT connect flags MUST be set to use AUTH packets for
authentication and authorisation. For AUTH, the username and
password flags MUST be set to 0. The RS MAY support token transport
using username and password (the CONNECT message for that option is
described in Section 7 for MQTT v3.1.1).
+-----------------------------------------------------------+ +-----------------------------------------------------------+
|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 | | | | | |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| 0 | 0 | X | X X | X | 1 | 0 | | 0 | 0 | X | X X | X | X | 0 |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
Figure 3: MQTT CONNECT flags. (Rsvd=Reserved) Figure 3: CONNECT flags for AUTH
To achieve a clean session (i.e., the session starts without an
existing session), the Clean Start Flag MUST be set to 1. In
addition, if the Session Expiry Interval is present in the CONNECT
message, it MUST be set to 0.
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
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 my specify a Will Delay temporary network disconnections, the Client may specify a Will Delay
Interval in Will Properties. Section 2.5 explains how the Broker Interval in Will Properties. Section 6 explains how the Broker deals
deals with the retained messages in further detail. with the retained messages in further detail.
For token transport, the RS SHOULD support AUTH (Authentication In MQTT v5, to achieve a clean session (i.e., the session starts
Exchange) method. The RS MAY support token transport via username without an existing session), the Client sets the Clean Start Flag to
and password, which is described in Section 3 for MQTT v3.1.1. The 1 and, the Session Expiry Interval to 0 in the CONNECT message.
rest of this section describes the AUTH method, for which the However, in this profile, the Broker MUST always start with a clean
username and password flags MUST be set to 0. session regardless of how these parameters are set. The Broker MUST
set the Session Present flag to 0 in the CONNACK packet as a
response.
To implement the AUTH (Authentication Exchange) method, the Client 2.2.4. Authentication Using AUTH Property
MUST set the Authentication Method as a property of a CONNECT packet
by using the property identifier 21 (0x15). This is followed by a To use AUTH, the Client MUST set the Authentication Method as a
UTF-8 Encoded String containing the name of the authentication property of a CONNECT packet by using the property identifier 21
method, which MUST be set to 'ace'. If the RS does not support this (0x15). This is followed by a UTF-8 Encoded String containing the
profile, it sends a CONNACK with a Reason Code of '0x8C (Bad name of the Authentication Method, which MUST be set to 'ace'. If
authentication method)'. the RS does not support this profile, it sends a CONNACK with a
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. Based
on the Authentication Data, this profile allows: on the Authentication Data, this profile allows:
o Proof-of-Possession over predefined field o Proof-of-Possession using a challenge from the TLS session
o Proof-of-Possession via challenge/response o Proof-of-Possession via Broker generated challenge/response
o Unauthorised request: Authorisation Server discovery o Unauthorised request: Authorisation Server discovery
2.1.2.1. Proof-of-Possession over Predefined Field 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 token and
the keyed message digest (MAC) or the Client signature. To calculate the keyed message digest (MAC) or the Client signature. The
the keyed message digest (MAC) or the Client signature, the Client challenge that is used as part of the proof-of-possession, i.e., to
SHOULD apply the PoP key to the CONNECT payload. The CONNECT payload calculate the keyed message digest (MAC) or the Client signature, is
has at least a Client Identifier, and if the Will Flag is set to 1, obtained using using a TLS exporter ([RFC5705] for TLS 1.2 and for
may contain Will-related information. The Client Identifier is a TLS 1.3, Section 7.5 of [RFC8446]). The token is also validated as
MUST be a UTF-8 Encoded String (i.e., is prefixed with a two-byte described in Section 2.2.5 and the server responds with a CONNACK
integer length field that gives the number of bytes in a UTF-8 with the appropriate response code.
encoded string itself). The Client Identifier may be 1-23 UTF-8
encoded bytes, and contain only the characters
"0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ".
However, according to MQTTv5 standard, the Broker may except longer
Client Identifiers, and characters not included in the list given
above. Clients MUST change their Client Identifier for each session,
if the Client Identifier is the only source of randomness in the
payload to defend against a replay attack. If the Client reuses its
Client Identifier across different sessions, the Authentication Data
MUST also contain a nonce, and the keyed message digest (MAC) or the
Client signature MUST be computed over this nonce. Finally, the
token is validated as described in Section 2.1.3 and the server
responds with a CONNACK.
2.1.2.2. Proof-of-Possession via challenge/response 2.2.4.2. Proof-of-Possession via Broker-generated Challenge/Response
For this option, the RS follows a challenge/response protocol. The For this option, the RS follows a Broker-generated challenge/response
success case is illustrated in Figure 4. If the Authentication Data protocol. The success case is illustrated in Figure 4. If the
only includes the token, the RS MUST respond with an AUTH packet, Authentication Data only includes the token, the RS MUST respond with
with the Authenticate Reason Code set to '0x18 (Continue an AUTH packet, with the Authenticate Reason Code set to '0x18
Authentication)'. This packet includes the Authentication Method, (Continue Authentication)'. This packet includes the Authentication
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 a challenge for Authentication Data MUST NOT be empty and contains a challenge for
the Client. The Client responds to this with an AUTH packet with a the Client. The Client responds to this with an AUTH packet with a
reason code '0x18 (Continue Authentication)'. Similarly, the Client reason code '0x18 (Continue Authentication)'. Similarly, the Client
packet sets the Authentication Method to 'ace'. The Authentication packet sets the Authentication Method to 'ace'. The Authentication
Data in the Client's response contains the signature or MAC computed Data in the Client's response contains the signature or MAC computed
over the RS's challenge. Next, the token is validated as described over the RS's challenge. Next, the token is validated as described
in Section 2.1.3. in Section 2.2.5.
Resource Resource
Client Server Client Server
| | | |
|<===========>| TLS connection establishment |<===========>| TLS connection set-up
| | | |
| | | |
+------------>| CONNECT with Authentication Data +------------>| CONNECT with Authentication Data
| | contains only token | | contains only token
| | | |
<-------------+ AUTH '0x18 (Continue Authentication)' <-------------+ AUTH '0x18 (Continue Authentication)'
| | challenge | | challenge
| | | |
|------------>| AUTH '0x18 (Continue Authentication)' |------------>| AUTH '0x18 (Continue Authentication)'
| | signature | | signature
| | | |
| |-----+ 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.1.2.3. Unauthorised Request: Authorisation Server Discovery 2.2.4.3. Unauthorised Request: Authorisation Server Discovery
Finally, this document allows the CONNECT message to have an empty Finally, this document allows the CONNECT message to have the
Authentication Method set to 'ace' followed by an empty
Authentication Data field. This is the AS discovery option and the Authentication Data field. This is the AS discovery option and the
RS responds with the CONNACK reason code '0x87 (Not Authorized)' and RS responds with the CONNACK reason code '0x87 (Not Authorized)' and
includes a User Property (identified by 38 (0x26)) for the AS includes a User Property (identified by 38 (0x26)) for the AS
creation hints as dedined in the Section 5.1.2 of the ACE framework creation hints as defined in the Section 5.1.2 of the ACE framework
[I-D.ietf-ace-oauth-authz]. [I-D.ietf-ace-oauth-authz].
2.1.3. Token Validation 2.2.5. Token Validation
The RS MUST verify the validity of the token. This validation MAY be
done locally (e.g., in the case of a self-contained token) or the RS
MAY send an introspection request to the AS. If introspection is
used, this section follows similar steps to those described in
Sections 5.7 of the ACE framework [I-D.ietf-ace-oauth-authz]. The
communication between AS and RS MUST be confidential, mutually
authenticated and integrity protected.
The Broker MUST check if the token is active either using 'exp' claim The RS MUST verify the validity of the token either locally (e.g., in
of the token or 'active' parameter of the introspection response. the case of a self-contained token) or the RS MAY send an
Also, if present in the access token, RS must check that the 'iss' introspection request to the AS. RS MUST verify the claims according
corresponds to AS, the 'aud' field corresponds to RS. It also has to to the rules set in the Section 5.8.1.1 of the ACE framework
check whether the 'nbf' and the 'iat' claims are present and valid. [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. To authorize MAC, depending on how the PoP protocol is implemented. Validation of
the Client, the Broker uses the scope field in the token (or in the the signature or MAC MUST fail if the signature algorithm is set to
introspection result). The scope field contains the publish and "none", when the key used for the signature algorithm cannot be
subscribe permissions for the Client. If the Will Flag is set,then determined, or the computed and received signature/MAC do not match.
the Broker MUST check that the token allows the publication of the To authorize the Client, the Broker uses the scope field in the token
Will message. (or in the introspection result). The scope field contains the
publish and subscribe permissions for the Client.
Scope strings SHOULD be encoded as a permission, followed by an Scope strings SHOULD be encoded as a permission, followed by an
underscore, followed by a topic filter. Two permissions apply to underscore, followed by a topic filter. Two permissions apply to
topics: 'publish' and 'subscribe'. An example scope field may topics: 'publish' and 'subscribe'. An example scope field may
contain multiple such strings, space delimited, e.g., 'publish_topic1 contain multiple such strings, space delimited, e.g., 'publish_topic1
subscribe_topic2/#'. Hence, this access token would give 'publish' subscribe_topic2/#'. Hence, this access token would give 'publish'
permission to the 'topic1', 'subscribe' permission to all the permission to the 'topic1', 'subscribe' permission to all the
subtopics of 'topic2'. subtopics of 'topic2'. 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 "publish_" followed by the Will Topic).
2.1.4. 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 authentication is successful. In case of is '0x00 (Success)' if the authentication is successful. The Broker
an invalid PoP token, the CONNACK reason code is '0x87 (Not MUST also set Session Present to 0 in the CONNACK packet to signal a
Authorized)'. clean session to the Client. In case of an invalid PoP token, the
CONNACK reason code is '0x87 (Not Authorized)'.
If the RS accepts the connection, it MUST store the token until the If the Broker accepts the connection, it MUST store the token until
end of connection. On Client or RS disconnection, the token is the end of connection. On Client or Broker disconnection, the Client
discarded, and the Client MUST provide a token inside each CONNECT is expected to provide a token again inside the next CONNECT message.
message.
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 use a cache time out to introspect tokens regularly. SHOULD use a cache time out to introspect tokens regularly.
2.2. Authorizing PUBLISH Messages 3. Authorizing PUBLISH Messages
2.2.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
compare against the cached token or its introspection result. compare against the cached token or its introspection result.
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. The Broker may the message to all valid subscribers of the topic. The Broker may
also return an acknowledgment message if the QoS level is greater also return an acknowledgment message if the QoS level is greater
than or equal to 1. than or equal to 1.
In case of an authorization failure, an error MAY be returned to the In case of an authorization failure, an error MAY be returned to the
Client. For this the QoS level of the PUBLISH message, should be set Client. For this the QoS level of the PUBLISH message, should be set
to greater than or equal to 1. This guarantees that RS responds with to greater than or equal to 1. This guarantees that RS responds with
either a PUBACK or PUBREC packet with reason code '0x87 (Not either a PUBACK or PUBREC packet with reason code '0x87 (Not
authorized)'. 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 2.4, and pass a new token reauthenticate as described in Section 5, 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.
2.2.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 stop forwarding messages to the unauthorized subscribers.
For Clients with invalid tokens, there is no way to inform the Client There is no way to inform the Clients with invalid tokens that an
that an authorization error has occurred other than sending a authorization error has occurred other than sending a DISCONNECT
DISCONNECT message. The RS SHOULD send a DISCONNECT message with the message. The RS SHOULD send a DISCONNECT message with the reason
reason code '0x87 (Not authorized)'. Note that the server-side code '0x87 (Not authorized)'. Note that the server-side DISCONNECT
DISCONNECT is a new feature of MQTT v5.0 (in MQTT v3.1.1, the server is a new feature of MQTT v5.0 (in MQTT v3.1.1, the server needs to
needs to drop the connection). drop the connection).
2.3. Authorizing SUBSCRIBE Messages 4. 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 compare against the stored token or introspection result. to compare against the stored token or introspection result.
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.
2.4. Token Expiration and Reauthentication 5. 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. This check for token expiration on receiving a PINGREQUEST message. The
may allow for early detection of a token expiry. Broker MAY also check for token expiration periodically e.g., every
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 Authorization server as described in Section 5.7 of the ACE with the AS as described in Section 5.7 of the ACE framework
framework [I-D.ietf-ace-oauth-authz]. Token expirations may trigger [I-D.ietf-ace-oauth-authz]. Token expirations may trigger the RS to
the RS to send PUBACK, SUBACK and DISCONNECT messages with return send PUBACK, SUBACK and DISCONNECT messages with return code set to
code set to 'Not authorised'. As a response, the Client MAY re- 'Not authorised'. After sending a DISCONNECT message, the network
authenticate by sending an AUTH packet with a Reason Code of 0x19 connection is closed, and no more messages can be sent. However, as
(Re-authentication) a response to the PUBACK and SUBACK, the Client MAY re-authenticate
by sending an AUTH packet with a Reason Code of 0x19 (Re-
authentication).
To re-authenticate, the Client sends an AUTH packet with reason code To re-authenticate, the Client sends an AUTH packet with reason code
'0x19 (Re-authentication)'. The Client MUST set the authentication '0x19 (Re-authentication)'. The Client MUST set the Authentication
method as 'ace' and transport the new token in the Authentication Method as 'ace' and transport the new token in the Authentication
Data. The Client and the RS go through the same steps for proof of Data. The Client and the RS go through the same steps for proof of
possession validation as described in Section 2.1.2. If the re- possession validation as described in Section 2.2. If the re-
authentication fails, the server MUST send a DISCONNECT with the authentication fails, the server MUST send a DISCONNECT with the
reason code '0x87 (Not Authorized)'. The Clients can also reason code '0x87 (Not Authorized)'. The Clients can also
proactively update their tokens before they receive a message with proactively update their tokens i.e., before they receive a message
'Not authorized' return code. with 'Not authorized' return code.
2.5. Handling Disconnections and Retained Messages 6. Handling Disconnections and Retained Messages
In the case of a Client DISCONNECT, due to the Clean Session flag, In the case of a Client DISCONNECT, the Broker deletes all session
the Broker deletes all session state but MUST keep the retained state but MUST keep the retained messages. By setting a RETAIN flag
messages. By setting a RETAIN flag in a PUBLISH message, the in a PUBLISH message, the publisher indicates to the Broker that it
publisher indicates to the Broker that it should store the most should store the most recent message for the associated topic.
recent message for the associated topic. Hence, the new subscribers Hence, the new subscribers can receive the last sent message from the
can receive the last sent message from the publisher of that publisher of that particular topic without waiting for the next
particular topic without waiting for the next PUBLISH message. The PUBLISH message. The Broker MUST continue publishing the retained
Broker MUST continue publishing the retained messages as long as the messages as long as the associated tokens are valid.
associated tokens are valid.
In case of disconnections due to network errors or server In case of disconnections due to network errors or server
disconnection due to a protocol error (which includes authorization disconnection due to a protocol error (which includes authorization
errors), the Will message 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
when the network connection is closed regardless of whether the regardless of whether the corresponding token has expired. In the
corresponding token has expired. In the case of a server-side case of a server-side DISCONNECT, the server returns the '0x87 Not
DISCONNECT, the server returns the '0x87 Not Authorized' return code Authorized' return code to the Client.
to the Client.
3. Reduced Protocol Interactions for MQTT v3.1.1 7. 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.
3.1. Token Transport 7.1. Token Transport
To transport the token to the Broker, the Clients use the username As in MQTT v5, The Token MAY either be transported before the TLS
and password fields of the CONNECT control message after the TLS session publishing to the "authz-info" topic, or inside the CONNECT
handshake. Figure 5 shows the structure of the MQTT CONNECT message. message.
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
token verification. In any case, any token authorization failure
affect the subsequent TLS handshake, which can prompt the Client to
obtain a valid token.
To transport the token to the Broker inside the CONNECT message, the
Client uses the username and password fields of the CONNECT message.
Figure 5 shows the 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 |
| Client Identifier | | Client Identifier |
| Username as access token (UTF-8) | | Username as access token (UTF-8) |
| Password length (2 Bytes) | | Password length (2 Bytes) |
| Password data as signature/MAC (binary) | | Password data as signature/MAC (binary) |
+------------------------------------------------------+ +------------------------------------------------------+
Figure 5: MQTT CONNECT control message. (CPT=Control Packet Type, Figure 5: MQTT CONNECT control message. (CPT=Control Packet Type,
Rsvd=Reserved, len.=length, Proto.=Protocol) Rsvd=Reserved, len.=length, Proto.=Protocol)
Figure 6 shows how the MQTT connect flags MUST be set to initiate a Figure 6 shows how the MQTT connect flags MUST be set to initiate a
connection with the Broker. connection with the Broker.
+-----------------------------------------------------------+ +-----------------------------------------------------------+
|User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.| |User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.|
| flag |flag | | | | | | | flag |flag | | | | | |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| 1 | 1 | X | X X | X | 1 | 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 MUST be set to 1. The Client may set the Will The Clean Session Flag is ignored, and the Broker always sets up a
Flag as desired (marked as 'X' in Figure 6). Username and Password clean session. On connection success, the Broker MUST set the
flags MUST be set to 1 to ensure that the Payload of the CONNECT Session Present flag to 0 in the CONNACK packet.
message includes both Username and Password fields.
The CONNECT message defaults to ACE for authentication and The Client may set the Will Flag as desired (marked as 'X' in
authorization. The Username field MUST be set to the access token. Figure 6). Username and Password flags MUST be set to 1 to ensure
that the Payload of the CONNECT message includes both Username and
Password fields.
The Password field MUST be set to the keyed message digest (MAC) or The CONNECT message defaults to 'ace' for authentication and
signature associated with the access token for proof-of-possession. authorization as the header does not have a field to indicate the
The Client MUST apply the PoP key to the payload as described in authentication method. The Username field MUST be set to the access
Section 2.1.2.1. token. The Password field MUST be set to the keyed message digest
(MAC) or signature associated with the access token for proof-of-
possession. The Client MUST apply the PoP key on the challenge
derived from the TLS session as described in 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.)
3.2. Handling Authorization Errors 7.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
MUSY fail. MUST fail.
o Client-RS PUBLISH authorization failure: In case of a failure, it o Client-RS PUBLISH authorization failure: In case of a failure, it
is not possible to return an error in MQTT v3.1.1. is not possible to return an error in MQTT v3.1.1.
Acknowledgement messages only indicate success. In the case of an Acknowledgement messages only indicate success. In the case of an
authorization error, the Broker SHOULD disconnect the Client. authorization error, the Broker SHOULD disconnect the Client.
Otherwise, it MUST ignore the PUBLISH message. Also, DISCONNECT Otherwise, it MUST ignore the PUBLISH message. Also, DISCONNECT
messages are only sent from a Client to the Broker. So, server messages are only sent from a Client to the Broker. So, server
disconnection needs to take place below the application layer. disconnection needs to take place below the application layer.
o SUBSCRIBE authorization failure: In the SUBACK packet, the return o SUBSCRIBE authorization failure: In the SUBACK packet, the return
code must be 0x80 indicating 'Failure' for the unauthorized code must be 0x80 indicating 'Failure' for the unauthorized
topic(s). Note that, in both MQTT versions, a reason code is topic(s). Note that, in both MQTT versions, a reason code is
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.
4. IANA Considerations 8. IANA Considerations
The following registrations are done for the ACE OAuth Profile The following registrations are done for the ACE OAuth Profile
Registry following the procedure specified in 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.
Profile name: mqtt_tls Profile name: mqtt_tls
skipping to change at page 18, line 27 skipping to change at page 19, line 17
Profile description: Profile for delegating Client authentication and Profile description: Profile for delegating Client authentication and
authorization using MQTT as the application protocol and TLS For authorization using MQTT as the application protocol and TLS For
transport layer security. transport layer security.
Profile ID: Profile ID:
Change controller: IESG Change controller: IESG
Reference: [RFC-XXXX] Reference: [RFC-XXXX]
5. Security Considerations 9. Security Considerations
This document specifies a profile for the Authentication and This document specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework Authorization for Constrained Environments (ACE) framework
[I-D.ietf-ace-oauth-authz]. Therefore, the security considerations [I-D.ietf-ace-oauth-authz]. Therefore, the security considerations
outlined in [I-D.ietf-ace-oauth-authz] apply to this work. outlined in [I-D.ietf-ace-oauth-authz] apply to this work.
In addition, the security considerations outlined in MQTT v5.0 - the In addition, the security considerations outlined in MQTT v5.0 - the
OASIS Standard [MQTT-OASIS-Standard-v5] and MQTT v3.1.1 - the OASIS OASIS Standard [MQTT-OASIS-Standard-v5] and MQTT v3.1.1 - the OASIS
Standard [MQTT-OASIS-Standard] apply. Mainly, this document provides Standard [MQTT-OASIS-Standard] apply. Mainly, this document provides
an authorization solution for MQTT, the responsibility of which is an authorization solution for MQTT, the responsibility of which is
left to the specific implementation in MQTT v5.0 standard. In the left to the specific implementation in MQTT v5.0 standard. In the
following, we comment on a few relevant issues based on the current following, we comment on a few relevant issues based on the current
MQTT specifications. MQTT specifications.
In this document, RS uses the PoP access token to authenticate the
Client. If the Client is able, TLS certificates sent from the Client
can be used by the RS to authenticate the Client. The Client may
authenticate the RS either using a server cerficate or the RPK
method. In the case of RPK, client needs to use this raw public key
in the TLS handshake together with an out-of-band validation
technique (see [RFC7250] for details).
To authorize a Client's publish and subscribe requests in an ongoing To authorize a Client's publish and subscribe requests in an ongoing
session, the RS caches the access token after accepting the session, the RS caches the access token after accepting the
connection from the Client. However, if some permissions are revoked connection from the Client. However, if some permissions are revoked
in the meantime, the RS may still grant publish/subscribe to revoked in the meantime, the RS may still grant publish/subscribe to revoked
topics. If the RS caches the token introspection responses, then the topics. If the RS caches the token introspection responses, then the
RS should use a reasonable cache timeout to introspect tokens RS should use a reasonable cache timeout to introspect tokens
regularly. When permissions change dynamically, it is expected that regularly. When permissions change dynamically, it is expected that
AS also follows a reasonable expiration strategy for the access AS also follows a reasonable expiration strategy for the access
tokens. tokens.
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 Appendix B, 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.
6. Privacy Considerations 10. 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. Clients may potentially sensitive information between Clients. Clients may
choose to encrypt the payload of their messages. However, this would choose to encrypt the payload of their messages. However, this would
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.
7. References 11. References
7.1. Normative References 11.1. Normative References
[I-D.gerdes-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-gerdes-ace-dtls- Constrained Environments (ACE)", draft-ietf-ace-dtls-
authorize-01 (work in progress), March 2017. authorize-08 (work in progress), April 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-24 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-25
(work in progress), March 2019. (work in progress), October 2019.
[I-D.ietf-ace-oauth-params]
Seitz, L., "Additional OAuth Parameters for Authorization
in Constrained Environments (ACE)", draft-ietf-ace-oauth-
params-05 (work in progress), March 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-
skipping to change at page 20, line 25 skipping to change at page 21, line 14
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[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>.
[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>.
7.2. Informative References [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
11.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-cwt-proof-of-possession]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
possession-08 (work in progress), October 2019. possession-11 (work in progress), October 2019.
[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", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)", Possession Key Semantics for JSON Web Tokens (JWTs)",
RFC 7800, DOI 10.17487/RFC7800, April 2016, RFC 7800, DOI 10.17487/RFC7800, April 2016,
<https://www.rfc-editor.org/info/rfc7800>. <https://www.rfc-editor.org/info/rfc7800>.
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.1.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: RS provides a server o Client and RS mutual authentication: Several options are possible
certificate or RPK during TLS handshake. Client transports token and descibed in Section 2.2.1.
and MAC via the MQTT CONNECT message.
o Content format: For the HTTPS interactions with AS, "application/ o Content format: For the HTTPS interactions with AS, "application/
ace+json". The MQTT payloads may be formatted in 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.
o Token request: CAS uses HTTPS /token interface of AS. o Token request: Client or its Client AS uses HTTPS /token interface
of AS.
o /authz-info endpoint: It MAY be supported using the method o /authz-info endpoint: It MAY be supported using the method
described in Appendix B, but is not protected. described in Section 2.2.2, but is not protected.
o Token transport: In MQTT CONNECT message for both versions of o Token transport: Via "authz-info topic", or in MQTT CONNECT
MQTT. AUTH extensions also used for authentication and re- message for both versions of MQTT. AUTH extensions also used for
authentication for MQTT v5.0 as described in Section 2.1.2. authentication and re-authentication for MQTT v5.0 as described in
Section 2.2.
Appendix B. The Authorization Information Endpoint Appendix B. Document Updates
The main document described a method for transporting tokens inside Version 01 to 02:
MQTT CONNECT messages. In this section, we describe an alternative
method to transport an access token.
The method consists of the MQTT Broker accepting PUBLISH messages to o Expanded Client connection authorization to capture different
a public "authz-info" topic. A Client using this method MUST first options for Client and Broker authentication over TLS and MQTT
connect to the Broker, and publish the access token using the "authz-
info" topic. The Broker must verify the validity of the token (i.e.,
through local validation or introspection). After publishing the
token, the Client disconnects from the Broker and is expected to try
reconnecting over TLS.
In MQTT v5.0, the Broker can return 'Not authorized' error to a o Removed Payload (and specifically Client Identifier) from proof-
PUBLISH request for QoS greater or equal to 1. In MQTT v3.1.1, after of-possesion in favor of using tls-exporter for a TLS-session
the Client published to the "authz-info" topic, it is not possible based challenge.
for the Broker to communicate the result of the token verification.
In any case, any token authorization failure affect the subsequent
TLS handshake, which can prompt the Client to obtain a valid token.
Appendix C. Document Updates o Moved token transport via "authz-info" topic from the Appendix to
the main text.
o Clarified Will scope.
o Added MQTT AUTH to terminology.
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.
skipping to change at page 22, line 42 skipping to change at page 23, line 38
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 for AUTH methods, updated CONNECT message o Added new figures to explain AUTH packets exchang, updated CONNECT
figure. 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
Nominet Nominet
4 Kingdom Street 4 Kingdom Street
London W2 6BD London W2 6BD
UK UK
Email: Cigdem.Sengul@nominet.uk Email: Cigdem.Sengul@nominet.uk
Anthony Kirby Anthony Kirby
Oxbotica Oxbotica
 End of changes. 112 change blocks. 
370 lines changed or deleted 423 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/