draft-ietf-ace-mqtt-tls-profile-06.txt   draft-ietf-ace-mqtt-tls-profile-07.txt 
ACE Working Group C. Sengul ACE Working Group C. Sengul
Internet-Draft Brunel University Internet-Draft Brunel University
Intended status: Standards Track A. Kirby Intended status: Standards Track A. Kirby
Expires: January 14, 2021 Oxbotica Expires: February 26, 2021 Oxbotica
P. Fremantle P. Fremantle
University of Portsmouth University of Portsmouth
July 13, 2020 August 25, 2020
MQTT-TLS profile of ACE Message Queuing Telemetry Transport (MQTT)-TLS profile of Authentication
draft-ietf-ace-mqtt-tls-profile-06 and Authorization for Constrained Environments (ACE) Framework
draft-ietf-ace-mqtt-tls-profile-07
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 Message Queuing Telemetry Transport (MQTT)-based authorization in an Message Queuing Telemetry Transport (MQTT)-based
publish-subscribe messaging system. Proof-of-possession keys, bound publish-subscribe messaging system. Proof-of-possession keys, bound
to OAuth2.0 access tokens, are used to authenticate and authorize to OAuth2.0 access tokens, are used to authenticate and authorize
MQTT Clients. The protocol relies on TLS for confidentiality and MQTT Clients. The protocol relies on TLS for confidentiality and
MQTT server (broker) authentication. MQTT server (broker) authentication.
skipping to change at page 1, line 39 skipping to change at page 1, line 40
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 January 14, 2021. This Internet-Draft will expire on February 26, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 16
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. ACE-Related Terminology . . . . . . . . . . . . . . . . . 4 1.2. ACE-Related Terminology . . . . . . . . . . . . . . . . . 4
1.3. MQTT-Related Terminology . . . . . . . . . . . . . . . . 4 1.3. MQTT-Related Terminology . . . . . . . . . . . . . . . . 5
2. Authorizing Connection Requests . . . . . . . . . . . . . . . 7 2. Authorizing Connection Requests . . . . . . . . . . . . . . . 7
2.1. Client Token Request to the Authorization Server (AS) . . 8 2.1. Client Token Request to the Authorization Server (AS) . . 8
2.2. Client Connection Request to the Broker (C) . . . . . . . 9 2.2. Client Connection Request to the Broker (C) . . . . . . . 9
2.2.1. Client-Server Authentication over TLS and MQTT . . . 9 2.2.1. Client-Server Authentication over TLS and MQTT . . . 9
2.2.2. authz-info: The Authorization Information Topic . . . 10 2.2.2. authz-info: The Authorization Information Topic . . . 10
2.2.3. Transporting Access Token Inside the MQTT CONNECT . . 11 2.2.3. Transporting Access Token Inside the MQTT CONNECT . . 11
2.2.4. Authentication Using AUTH Property . . . . . . . . . 13 2.2.4. Authentication Using AUTH Property . . . . . . . . . 14
2.2.4.1. Proof-of-Possession Using a Challenge from the 2.2.4.1. Proof-of-Possession Using a Challenge from the
TLS session . . . . . . . . . . . . . . . . . . . 13 TLS session . . . . . . . . . . . . . . . . . . . 14
2.2.4.2. Proof-of-Possession via Broker-generated 2.2.4.2. Proof-of-Possession via Broker-generated
Challenge/Response . . . . . . . . . . . . . . . 13 Challenge/Response . . . . . . . . . . . . . . . 14
2.2.5. Token Validation . . . . . . . . . . . . . . . . . . 14 2.2.5. Token Validation . . . . . . . . . . . . . . . . . . 15
2.2.6. The Broker's Response to Client Connection Request . 15 2.2.6. The Broker's Response to Client Connection Request . 16
2.2.6.1. Unauthorised Request: Authorisation Server 2.2.6.1. Unauthorised Request: Authorisation Server
Discovery . . . . . . . . . . . . . . . . . . . . 15 Discovery . . . . . . . . . . . . . . . . . . . . 16
2.2.6.2. Authorisation Success . . . . . . . . . . . . . . 15 2.2.6.2. Authorisation Success . . . . . . . . . . . . . . 16
3. Authorizing PUBLISH and SUBSCRIBE Messages . . . . . . . . . 16 3. Authorizing PUBLISH and SUBSCRIBE Messages . . . . . . . . . 16
3.1. PUBLISH Messages from the Publisher Client to the Broker 16 3.1. PUBLISH Messages from the Publisher Client to the Broker 17
3.2. PUBLISH Messages from the Broker to the Subscriber 3.2. PUBLISH Messages from the Broker to the Subscriber
Clients . . . . . . . . . . . . . . . . . . . . . . . . . 17 Clients . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3. Authorizing SUBSCRIBE Messages . . . . . . . . . . . . . 17 3.3. Authorizing SUBSCRIBE Messages . . . . . . . . . . . . . 18
4. Token Expiration and Reauthentication . . . . . . . . . . . . 18 4. Token Expiration and Reauthentication . . . . . . . . . . . . 18
5. Handling Disconnections and Retained Messages . . . . . . . . 18 5. Handling Disconnections and Retained Messages . . . . . . . . 19
6. Reduced Protocol Interactions for MQTT v3.1.1 . . . . . . . . 19 6. Reduced Protocol Interactions for MQTT v3.1.1 . . . . . . . . 19
6.1. Token Transport . . . . . . . . . . . . . . . . . . . . . 19 6.1. Token Transport . . . . . . . . . . . . . . . . . . . . . 20
6.2. Handling Authorization Errors . . . . . . . . . . . . . . 20 6.2. Handling Authorization Errors . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Checklist for profile requirements . . . . . . . . . 25 Appendix A. Checklist for profile requirements . . . . . . . . . 26
Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 26 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 27
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 29 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
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 Servers [I-D.ietf-ace-oauth-authz]. In this profile, Clients and Servers
(Brokers) use MQTT to exchange Application Messages. The protocol (Brokers) use MQTT to exchange Application Messages. The protocol
relies on TLS for communication security between entities. The MQTT relies on TLS for communication security between entities. The MQTT
protocol interactions are described based on the MQTT v5.0 - the protocol interactions are described based on the MQTT v5.0 - the
OASIS Standard [MQTT-OASIS-Standard-v5]. Since it is expected that OASIS Standard [MQTT-OASIS-Standard-v5]. Since it is expected that
MQTT deployments will continue to support MQTT v3.1.1 clients, this MQTT deployments will continue to support MQTT v3.1.1 clients, this
skipping to change at page 3, line 37 skipping to change at page 3, line 38
subscribe to the Topic Names to receive the corresponding messages. subscribe to the Topic Names to receive the corresponding messages.
The Broker uses the Topic Name in a published message to determine The Broker uses the Topic Name in a published message to determine
which subscribers to relay the messages. In this document, topics, which subscribers to relay the messages. In this document, topics,
more specifically, Topic Names, are treated as resources. The more specifically, Topic Names, are treated as resources. The
Clients are assumed to have identified the publish/subscribe topics Clients are assumed to have identified the publish/subscribe topics
of interest out-of-band (topic discovery is not a feature of the MQTT of interest out-of-band (topic discovery is not a feature of the MQTT
protocol). A Resource Owner can pre-configure policies at the protocol). A Resource Owner can pre-configure policies at the
Authorisation Server (AS) that give Clients publish or subscribe Authorisation Server (AS) that give Clients publish or subscribe
permissions to different topics. permissions to different topics.
Clients prove their permission to publish/subscribe to topics hosted Clients prove their permission to publish and subscribe to topics
on an MQTT broker using an access token, bound to a proof-of- hosted on an MQTT broker using an access token, bound to a proof-of-
possession (PoP) key. This document describes how to authorize the possession (PoP) key. This document describes how to authorize the
following exchanges between the Clients and the Broker. 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
Clients use MQTT PUBLISH message to publish to a topic. This Clients use MQTT PUBLISH message to publish to a topic. This
document does not protect the payload of the PUBLISH message from the document does not protect the payload of the PUBLISH message from the
Broker. Hence, the payload is not signed or encrypted specifically Broker. Hence, the payload is not signed or encrypted specifically
for the subscribers. This functionality may be implemented using the for the subscribers. This functionality may be implemented using the
proposal outlined in the CoAP Pub-Sub Profile proposal outlined in the ACE Pub-Sub Profile
[I-D.ietf-ace-pubsub-profile]. [I-D.ietf-ace-pubsub-profile].
To provide communication confidentiality and RS authentication, TLS To provide communication confidentiality and RS authentication, TLS
is used, and TLS 1.3 is RECOMMENDED. This document makes the same is used, and TLS 1.3 is RECOMMENDED. This document makes the same
assumptions as Section 4 of the ACE framework assumptions as Section 4 of the ACE framework
[I-D.ietf-ace-oauth-authz] regarding Client and RS registration with [I-D.ietf-ace-oauth-authz] regarding Client and RS registration with
the AS and setting up keying material. While the Client-Broker the AS and setting up keying material. While the Client-Broker
exchanges are only over MQTT, the required Client-AS and RS-AS exchanges are only over MQTT, the required Client-AS and RS-AS
interactions are described for HTTPS-based communication, using interactions are described for HTTPS-based communication, using
'application/ace+json' content type, and unless otherwise specified, 'application/ace+json' content type, and unless otherwise specified,
skipping to change at page 6, line 12 skipping to change at page 6, line 18
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 QoS level 2. required for QoS level 2.
CONNECT CONNECT
Client request to connect to the Broker. This is the first Client request to connect to the Broker. This is the first
packet sent by a Client. packet sent by a Client.
CONNACK CONNACK
The Broker connection acknowledgment. CONNACK packets The Broker connection acknowledgment. CONNACK packets
contain return codes indicating either a success or an error contain return codes indicating either a success or an error
state to in response to a Client's CONNECT packet. state in response to a Client's CONNECT packet.
AUTH AUTH
Authentication Exchange. An AUTH packet is sent from the Authentication Exchange. An AUTH control packet is sent from
Client to the Broker or from the Broker to the Client as part the Client to the Broker or from the Broker to the Client as
of an extended authentication exchange. AUTH Properties part of an extended authentication exchange. AUTH Properties
include Authentication Method and Authentication Data. The include Authentication Method and Authentication Data. The
Authentication Method is set in the CONNECT packet, and Authentication Method is set in the CONNECT packet, and
consequent AUTH packets follow the same Authentication consequent AUTH packets follow the same Authentication
Method. The contents of the Authentication Data are defined Method. The contents of the Authentication Data are defined
by the Authentication Method. by the Authentication Method.
PUBLISH PUBLISH
Publish request sent from a publishing Client to the Broker, Publish request sent from a publishing Client to the Broker,
or from the Broker to a subscribing Client. or from the Broker to a subscribing Client.
PUBACK PUBACK
Response to PUBLISH request with QoS level 1. PUBACK can be Response to a PUBLISH request with QoS level 1. A PUBACK can
sent from the Broker to a Client or a Client to the Broker. be sent from the Broker to a Client or from 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 from a Client to the
Broker.
SUBSCRIBE SUBSCRIBE
Subscribe request sent from a Client. 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
skipping to change at page 8, line 49 skipping to change at page 8, line 49
[I-D.ietf-ace-oauth-authz], however, it MUST set the profile [I-D.ietf-ace-oauth-authz], however, it MUST set the profile
parameter to 'mqtt_tls'. The media format is 'application/ace+json'. parameter to 'mqtt_tls'. The media format is 'application/ace+json'.
The AS uses JSON in the payload of its responses to both to the The AS uses JSON in the payload of its responses to both to the
Client and the RS. Client and the RS.
If the AS successfully verifies the access token request and If the AS successfully verifies the access token request and
authorizes the Client for the indicated audience (i.e. RS) and authorizes the Client for the indicated audience (i.e. RS) and
scopes (i.e. publish/subscribe permissions over topics), the AS scopes (i.e. publish/subscribe permissions over topics), the AS
issues an access token (Figure 1 (B)). The response includes the issues an access token (Figure 1 (B)). The response includes the
parameters described in Section 5.6.2 of the ACE framework parameters described in Section 5.6.2 of the ACE framework
[I-D.ietf-ace-oauth-authz]. The returned token is assumed to be [I-D.ietf-ace-oauth-authz]. The returned token is a Proof-of-
Proof-of-Possession (PoP) token by default. This document follows Possession (PoP) token by default. This document follows RFC 7800
RFC 7800 [RFC7800] for PoP semantics for JWTs. The PoP token [RFC7800] for PoP semantics for JWTs. The PoP token includes a 'cnf'
includes a 'cnf' parameter with a symmetric or asymmetric PoP key. parameter with a symmetric or asymmetric PoP key. Note that the
'cnf' parameter in the web tokens are to be consumed by the RS and
Note that the 'cnf' parameter in the web tokens are to be consumed by not the Client. For the asymmetric case, the PoP token may include
the RS and not the Client. For the asymmetric case, the PoP token the 'rs_cnf' parameter containing the information about the public
may include the 'rs_cnf' parameter containing the information about key to be used by the RS to authenticate as described in
the public key to be used by the RS to authenticate as described in
[I-D.ietf-ace-oauth-params]. [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
Section 5.2 of RFC 6749 [RFC6749]. When CBOR is used, the Section 5.2 of RFC 6749 [RFC6749]. When CBOR is used, the
interactions must implement Section 5.6.3 of the ACE framework interactions must implement Section 5.6.3 of the ACE framework
[I-D.ietf-ace-oauth-authz]. [I-D.ietf-ace-oauth-authz].
2.2. Client Connection Request to the Broker (C) 2.2. Client Connection Request to the Broker (C)
2.2.1. Client-Server Authentication over TLS and MQTT 2.2.1. Client-Server Authentication over TLS and MQTT
skipping to change at page 10, line 30 skipping to change at page 10, line 30
The Broker stores and indexes all tokens received to the "authz-info" The Broker stores and indexes all tokens received to the "authz-info"
topic in its key store (similar to DTLS profile for ACE topic in its key store (similar to DTLS profile for ACE
[I-D.ietf-ace-dtls-authorize]). This profile follows the [I-D.ietf-ace-dtls-authorize]). This profile follows the
recommendation of Section 5.8.1 of the ACE framework recommendation of Section 5.8.1 of the ACE framework
[I-D.ietf-ace-oauth-authz], and expects that the Broker stores only [I-D.ietf-ace-oauth-authz], and expects that the Broker stores only
one token per proof-of-possession key, and any other token linked to one token per proof-of-possession key, and any other token linked to
the same key overwrites an existing token. the same key overwrites an existing token.
The Broker MUST verify the validity of the token (i.e. through local The Broker MUST verify the validity of the token (i.e. through local
validation or introspection) as described in Section 2.2.5. To validation or introspection, if the token is a reference) as
validate the token, RS MAY need to introspect the token with the AS, described in Section 2.2.5. If the token is not valid, the Broker
e.g. if the token is a reference. If the token is not valid, the MUST discard the token. Depending on the QoS level of the PUBLISH
Broker MUST discard the token. Depending on the QoS level of the message, the Broker returns the error response as a PUBACK or a
PUBLISH message, the Broker may return the error response as a PUBACK DISCONNECT message as explained below.
or a DISCONNECT message.
If the QoS level is equal to 0, and the token is invalid or the If the QoS level is equal to 0, and the token is invalid or the
claims cannot be obtained in the case of an introspected token, the claims cannot be obtained in the case of an introspected token, the
Broker MUST send a DISCONNECT message with the reason code '0x87 (Not Broker MUST send a DISCONNECT message with the reason code '0x87 (Not
authorized)'. If the PUBLISH payload does not parse to a token, the authorized)'. If the PUBLISH payload does not parse to a token, the
RS MUST send a DISCONNECT with the reason code '0x99 (Payload format RS MUST send a DISCONNECT with the reason code '0x99 (Payload format
invalid)'. invalid)'.
If the QoS level of the PUBLISH message is greater than or equal to If the QoS level of the PUBLISH message is greater than or equal to
1, the Broker MUST return 'Not authorized' in PUBACK. If the PUBLISH 1, the Broker MUST return 'Not authorized' in PUBACK. If the PUBLISH
skipping to change at page 11, line 16 skipping to change at page 11, line 16
2.2.3. Transporting Access Token Inside the MQTT CONNECT 2.2.3. Transporting Access Token Inside the MQTT CONNECT
This section describes how the Client transports the token to the This section describes how the Client transports the token to the
Broker (RS) inside the CONNECT message. If this method is used, the Broker (RS) inside the CONNECT message. If this method is used, the
Client TLS connection is expected to be anonymous, and the Broker is Client TLS connection is expected to be anonymous, and the Broker is
authenticated during the TLS connection set-up. The approach authenticated during the TLS connection set-up. The approach
described in this section is similar to an earlier proposal by described in this section is similar to an earlier proposal by
Fremantle et al [fremantle14]. Fremantle et al [fremantle14].
After sending the CONNECT, the client MUST NOT send any packets other
than DISCONNECT or AUTH that is in response to the broker AUTH until
it has received a CONNACK. Similarly, the server MUST NOT process
any packets other than DISCONNECT or an AUTH that is sent in response
to its AUTH before it has sent a CONNACK.
Figure 2 shows the structure of the MQTT CONNECT message used in MQTT Figure 2 shows the structure of the MQTT CONNECT message used in MQTT
v5.0. A CONNECT message is composed of a fixed header, a variable v5.0. A CONNECT message is composed of a fixed header, a variable
header and a payload. The fixed header contains the Control Packet header and a payload. The fixed header contains the Control Packet
Type (CPT), Reserved, and Remaining Length fields. The Variable Type (CPT), Reserved, and Remaining Length fields. The Variable
Header contains the Protocol Name, Protocol Level, Connect Flags, Header contains the Protocol Name, Protocol Level, Connect Flags,
Keep Alive, and Properties fields. The Connect Flags in the variable Keep Alive, and Properties fields. The Connect Flags in the variable
header specify the properties of the MQTT session. It also indicates header specify the properties of the MQTT session. It also indicates
the presence or absence of some fields in the Payload. The payload the presence or absence of some fields in the Payload. The payload
contains one or more encoded fields, namely a unique Client contains one or more encoded fields, namely a unique Client
identifier for the Client, a Will Topic, Will Payload, User Name and identifier for the Client, a Will Topic, Will Payload, User Name and
Password. All but the Client identifier can be omitted depending on Password. All but the Client identifier can be omitted depending on
flags in the Variable Header. the 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 |
skipping to change at page 12, line 43 skipping to change at page 13, line 18
does not continue an existing session), by setting the Clean Start does not continue an existing session), by setting the Clean Start
Flag to 1 and, the Session Expiry Interval to 0 in the CONNECT Flag to 1 and, the Session Expiry Interval to 0 in the CONNECT
message. In this profile, the Broker SHOULD always start with a message. In this profile, the Broker SHOULD always start with a
clean session regardless of how these parameters are set. Starting a clean session regardless of how these parameters are set. Starting a
clean session helps the Broker avoid keeping unnecessary session clean session helps the Broker avoid keeping unnecessary session
state for unauthorised clients. If the Broker starts a clean state for unauthorised clients. If the Broker starts a clean
session, the Broker MUST set the Session Present flag to 0 in the session, the Broker MUST set the Session Present flag to 0 in the
CONNACK packet to signal this to the Client. CONNACK packet to signal this to the Client.
If necessary, the Broker MAY support session continuation, and hence, If necessary, the Broker MAY support session continuation, and hence,
maintain and use client state from the existing session. The client maintain and use client state from the existing session. The session
state MAY include token and its introspection result (for reference state kept at the server MAY include token and its introspection
tokens) in addition to the MQTT session state. When reconnecting to result (for reference tokens) in addition to the MQTT session state.
the Broker, the Client MUST still provide a token, as well as setting The MQTT session state is identified by the Client identifier and
the Clean Start to 0 and supplying a Session Expiry interval in the includes state on client subscriptions, QoS 1 and QoS 2 messages
CONNECT message. The Broker MUST perform proof-of-possession which have have not been completely acknowledged or pending
validation on the provided token. If the token matches the stored transmission to the Client, and if the Session is currently not
state, the Broker MAY skip introspecting a token by reference, and connected, the time at which the Session will end and Session State
use the stored introspection result. Continuing, both the Client and will be discarded.
the Broker MUST resend any unacknowledged PUBLISH packets (where QoS
> 0) and PUBREL packets. The Broker MUST still verify the Client is When reconnecting to a Broker that supports session continuation, the
authorized to receive or send these packets. When a Client connects Client MUST still provide a token, in addition to using the same
with a long Session Expiry Interval, the Broker may need to maintain Client identifier, setting the Clean Start to 0 and supplying a
Session Expiry interval in the CONNECT message. The Broker MUST
perform proof-of-possession validation on the provided token. If the
token matches the stored state, the Broker MAY skip introspecting a
token by reference, and use the stored introspection result. The
Broker MUST also verify the Client is authorized to receive or send
packets that are pending transmission. When a Client connects with a
long Session Expiry Interval, the Broker may need to maintain
Client's MQTT session state after it disconnects for an extended Client's MQTT session state after it disconnects for an extended
period. Brokers SHOULD implement administrative policies to limit period. Brokers SHOULD implement administrative policies to limit
misuse. misuse.
Note that, according to the MQTT standard, the Broker must use the
Client identifier to identify the session state. In the case of a
Client identifier collision, a client may take over another client's
session. Given that clients provide a token at each connection,
clients will only send or receive messages to their authorized
topics. Therefore, while this issue is not expected to affect
security, it may affect QoS (i.e. PUBLISH or QoS messages saved for
Client A may be delivered to a Client B). In addition, if this
Client identifier represents a Client already connected to the
Broker, the Broker sends a DISCONNECT packet to the existing Client
with Reason Code of '0x8E (Session taken over)', and closes the
connection to the client.
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,
skipping to change at page 14, line 14 skipping to change at page 15, line 10
'ace' and Authentication Data. The Authentication Data MUST NOT be 'ace' and Authentication Data. The Authentication Data MUST NOT be
empty and contains an 8-byte nonce as a challenge for the Client. empty and contains an 8-byte nonce as a challenge for the Client.
The Client responds to this with an AUTH packet with a reason code The Client responds to this with an AUTH packet with a reason code
'0x18 (Continue Authentication)'. Similarly, the Client packet sets '0x18 (Continue Authentication)'. Similarly, the Client packet sets
the Authentication Method to 'ace'. The Authentication Data in the the Authentication Method to 'ace'. The Authentication Data in the
Client's response is formatted as the client nonce length, the client Client's response is formatted as the client nonce length, the client
nonce, and the signature or MAC computed over the RS nonce nonce, and the signature or MAC computed over the RS nonce
concatenated with the client nonce. Next, the token is validated as concatenated with the client nonce. Next, the token is validated as
described in Section 2.2.5. described in Section 2.2.5.
The client MAY also re-authenticate using this flow. The client MAY also re-authenticate using this challenge-response
flow, as described in Section 4.
Resource Resource
Client Server Client Server
| | | |
|<===========>| TLS connection set-up |<===========>| TLS connection set-up
| | | |
| | | |
+------------>| CONNECT with Authentication Data +------------>| CONNECT with Authentication Data
| | contains only token | | contains only token
| | | |
skipping to change at page 15, line 17 skipping to change at page 16, line 15
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. send a CONNACK message to the Client.
2.2.6.1. Unauthorised Request: Authorisation Server Discovery 2.2.6.1. Unauthorised Request: Authorisation Server Discovery
If the Client does not provide a valid token or omits the If the Client does not provide a valid token or omits the
Authentication Data field, the Broker triggers AS discovery. The Authentication Data field, the Broker triggers AS discovery. The
Broker MUST NOT process any data sent by the Client after the CONNECT Broker responds with the CONNACK reason code '0x87 (Not Authorized)'
packet including AUTH packets (Note that this is different in MQTT and includes a User Property (identified by 38 (0x26)) for the AS
v5.0, the Broker is allowed to process AUTH packets even if the Request Creation Hints. The User Property is a UTF-8 string pair,
Broker rejects the CONNECT). composed of a name and a value. The name of the User Property MUST
be set to "ace_as_hint". The value of the user property is a UTF-8
The Broker responds with the CONNACK reason code '0x87 (Not encoded JSON string containing the mandatory "AS" parameter, and the
Authorized)' and includes a User Property (identified by 38 (0x26)) optional parameters "audience", "kid", "cnonce", and "scope" as
for the AS Request Creation Hints. The User Property is a UTF-8 defined in Section 5.1.2 of the ACE framework
string pair, composed of a name and a value. The name of the User
Property MUST be set to "ace_as_hint". The value of the user
property is a UTF-8 encoded JSON string containing the mandatory "AS"
parameter, and the optional parameters "audience", "kid", "cnonce",
and "scope" as defined in Section 5.1.2 of the ACE framework
[I-D.ietf-ace-oauth-authz]. [I-D.ietf-ace-oauth-authz].
2.2.6.2. Authorisation Success 2.2.6.2. Authorisation Success
On success, the reason code of the CONNACK is '0x00 (Success)'. If On success, the reason code of the CONNACK is '0x00 (Success)'. If
the Broker starts a new session, it MUST also set Session Present to the Broker starts a new session, it MUST also set Session Present to
0 in the CONNACK packet to signal a clean session to the Client. 0 in the CONNACK packet to signal a clean session to the Client.
Otherwise, it MUST set Session Present to 1. In case of an invalid Otherwise, it MUST set Session Present to 1. In case of an invalid
PoP token, the CONNACK reason code is '0x87 (Not Authorized)'. PoP token, the CONNACK reason code is '0x87 (Not Authorized)'.
skipping to change at page 16, line 45 skipping to change at page 17, line 38
permissions to the 'topic1', publish permission to all the subtopics permissions to the 'topic1', publish permission to all the subtopics
of 'topic2', and subscribe permission to all topic3, skipping one of 'topic2', and subscribe permission to all topic3, skipping one
level. If the Will Flag is set, then the Broker MUST check that the level. If the Will Flag is set, then the Broker MUST check that the
token allows the publication of the Will message (i.e. the Will Topic token allows the publication of the Will message (i.e. the Will Topic
filter is found in the scope). filter is found in the scope).
3.1. PUBLISH Messages from the Publisher Client to the Broker 3.1. PUBLISH Messages from the Publisher Client to the Broker
On receiving the PUBLISH message, the Broker MUST use the type of On receiving the PUBLISH message, the Broker MUST use the type of
message (i.e. PUBLISH) and the Topic name in the message header to message (i.e. PUBLISH) and the Topic name in the message header to
match against the scope string in the cached token or its match against the scope array items in the cached token or its
introspection result. Following the example in the previous section, introspection result. Following the example in the previous section,
a client sending a PUBLISH message to 'a/topic3' would be allowed to a client sending a PUBLISH message to 'topic2/a' would be allowed, as
publish, as the scope includes the string 'publish_+/topic3'. the scope array includes the '["topic2/#",["pub"]]'.
If the Client is allowed to publish to the topic, the Broker must If the Client is allowed to publish to the topic, the Broker must
publish the message to all valid subscribers of the topic. In the publish the message to all valid subscribers of the topic. In the
case of an authorization failure, the Broker MUST return an error, if case of an authorization failure, the Broker MUST return an error, if
the Client has set the QoS level of the PUBLISH message to greater the Client has set the QoS level of the PUBLISH message to greater
than or equal to 1. Depending on the QoS level, the Broker responds than or equal to 1. Depending on the QoS level, the Broker responds
with either a PUBACK or PUBREC packet with reason code '0x87 (Not with either a PUBACK or PUBREC packet with reason code '0x87 (Not
authorized)'. On receiving a PUBACK with '0x87 (Not authorized)', authorized)'. On receiving an acknowledgement with '0x87 (Not
the Client MAY reauthenticate by providing a new token as described authorized)', the Client MAY reauthenticate by providing a new token
in Section 4. as described in Section 4.
For QoS level 0, the Broker sends a DISCONNECT with reason code '0x87 For QoS level 0, the Broker sends a DISCONNECT with reason code '0x87
(Not authorized)' and closes the network connection. Note that the (Not authorized)' and closes the network connection. Note that the
server-side DISCONNECT is a new feature of MQTT v5.0 (in MQTT v3.1.1, server-side DISCONNECT is a new feature of MQTT v5.0 (in MQTT v3.1.1,
the server needs to drop the connection). the server needs to drop the connection).
3.2. PUBLISH Messages from the Broker to the Subscriber Clients 3.2. PUBLISH Messages from the Broker to the Subscriber Clients
To forward PUBLISH messages to the subscribing Clients, the Broker To forward PUBLISH messages to the subscribing Clients, the Broker
identifies all the subscribers that have valid matching topic identifies all the subscribers that have valid matching topic
skipping to change at page 17, line 39 skipping to change at page 18, line 33
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 the scope field of the stored token or introspection
result. The Topic Filters MUST be equal or a subset of the scopes result. The Topic Filters MUST be equal or a subset of at least one
associated with the Client's token. of the 'topic_filter' fields in the scope array found in 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 18 skipping to change at page 19, line 10
PUBLISH or SUBSCRIBE message is received or sent. The Broker SHOULD PUBLISH or SUBSCRIBE message is received or sent. The Broker SHOULD
check for token expiration on receiving a PINGREQUEST message. The check for token expiration on receiving a PINGREQUEST message. The
Broker MAY also check for token expiration periodically, e.g. every Broker MAY also check for token expiration periodically, e.g. every
hour. This may allow for early detection of a token expiry. hour. This may allow for early detection of a token expiry.
The token expiration is checked by checking the 'exp' claim of a JWT The token expiration is checked by checking the 'exp' claim of a JWT
or introspection response, or via performing an introspection request or introspection response, or via performing an introspection request
with the AS as described in Section 5.7 of the ACE framework with the AS as described in Section 5.7 of the ACE framework
[I-D.ietf-ace-oauth-authz]. Token expirations may trigger the RS to [I-D.ietf-ace-oauth-authz]. Token expirations may trigger the RS to
send PUBACK, SUBACK and DISCONNECT messages with return code set to send PUBACK, SUBACK and DISCONNECT messages with return code set to
'Not authorised'. After sending a DISCONNECT message, the network 'Not authorized'. After sending a DISCONNECT message, the network
connection is closed, and no more messages can be sent. However, as connection is closed, and no more messages can be sent. However, as
a response to the PUBACK and SUBACK, the Client MAY reauthenticate. a response to the PUBACK and SUBACK, the Client MAY reauthenticate.
The Clients MAY also proactively update their tokens, i.e. before The Clients MAY also proactively update their tokens, i.e. before
they receive a message with 'Not authorized' return code. they receive a message with a 'Not authorized' return code.
To start reauthentication, the Client MUST send an AUTH packet with To start reauthentication, the Client MUST send an AUTH packet with
reason code '0x19 (Re-authentication)'. The Client MUST set the the reason code '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 Broker accepts reauthentication requests if Authentication Data. The Broker accepts reauthentication requests if
the Client has already submitted a token (may be expired) and the Client has already submitted a token (may be expired) and
validated via the challenge-response PoP as defined in validated via the challenge-response PoP as defined in
Section 2.2.4.2. The Client MUST use the challenge-response PoP. Section 2.2.4.2. The Client MUST use the challenge-response PoP.
Otherwise, the Broker MUST deny the request. If the reauthentication Otherwise, the Broker MUST deny the request. If the reauthentication
fails, the Broker MUST send a DISCONNECT with the reason code '0x87 fails, the Broker MUST send a DISCONNECT with the reason code '0x87
(Not Authorized)'. (Not Authorized)'.
5. Handling Disconnections and Retained Messages 5. Handling Disconnections and Retained Messages
In the case of a Client DISCONNECT, the Broker deletes all the In the case of a Client DISCONNECT, the Broker deletes all the
session state but MUST keep the retained messages. By setting a session state but MUST keep the retained messages. By setting a
RETAIN flag in a PUBLISH message, the publisher indicates to the RETAIN flag in a PUBLISH message, the publisher indicates to the
Broker that it should store the most recent message for the Broker that it should store the most recent message for the
associated topic. Hence, the new subscribers can receive the last associated topic. Hence, the new subscribers can receive the last
sent message from the publisher of that particular topic without sent message from the publisher for that particular topic without
waiting for the next PUBLISH message. The Broker MUST continue waiting for the next PUBLISH message. The Broker MUST continue
publishing the retained messages as long as the associated tokens are publishing the retained messages as long as the associated tokens are
valid. 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 scope array MUST include
Will Topic. The Will message MUST be published to the Will Topic the 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 Clients. An MQTT v5.0 Broker MAY implement these MQTT v3.1.1 Clients. An MQTT v5.0 Broker MAY implement these
interactions for the MQTT v3.1.1 clients; MQTT v5.0 clients are NOT interactions for the MQTT v3.1.1 clients; MQTT v5.0 clients are NOT
RECOMMENDED to use the flows described in this section. Brokers that RECOMMENDED to use the flows described in this section. Brokers that
skipping to change at page 23, line 18 skipping to change at page 24, line 18
9. Privacy Considerations 9. Privacy Considerations
The privacy considerations outlined in [I-D.ietf-ace-oauth-authz] The privacy considerations outlined in [I-D.ietf-ace-oauth-authz]
apply to this work. apply to this work.
In MQTT, the RS is a central trusted party and may forward In MQTT, the RS is a central trusted party and may forward
potentially sensitive information between Clients. This document potentially sensitive information between Clients. This document
does not protect the contents of the PUBLISH message from the Broker, does not protect the contents of the PUBLISH message from the Broker,
and hence, the content of the PUBLISH message is not signed or and hence, the content of the PUBLISH message is not signed or
encrypted separately for the subscribers. This functionality may be encrypted separately for the subscribers. This functionality may be
implemented using the proposal outlined in the CoAP Pub-Sub Profile implemented using the proposal outlined in the ACE Pub-Sub Profile
[I-D.ietf-ace-pubsub-profile]. However, this solution would still [I-D.ietf-ace-pubsub-profile]. However, this solution would still
not provide privacy for other properties of the message such as Topic not provide privacy for other properties of the message such as Topic
Name. Name.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.bormann-core-ace-aif] [I-D.bormann-core-ace-aif]
Bormann, C., "An Authorization Information Format (AIF) Bormann, C., "An Authorization Information Format (AIF)
skipping to change at page 26, line 25 skipping to change at page 27, line 25
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 06 to 07:
o Corrected the title.
o In Section 2.2.3, added the constraint on which packets the Client
can send, and the server can process after CONNECT before CONNACK.
o In Section 2.2.3, clarified that session state is identified by
Client Identifier, and listed its content.
o In Section 2.2.3, clarified the issue of Client Identifier
collision, when the broker supports session continuation.
o Corrected the buggy scope example in Section 3.1.
Version 05 to 06: Version 05 to 06:
o Replace the orignally proposed scope format with AIF model. o Replace the originally proposed scope format with AIF model.
Defined the AIF-MQTT, gave an example with a JSON array. Added a Defined the AIF-MQTT, gave an example with a JSON array. Added a
normative reference to the AIF draft. normative reference to the AIF draft.
o Clarified client connection after submitting token via "authz- o Clarified client connection after submitting token via "authz-
info" topic as TLS:Known(RPK/PSK)-MQTT:none. info" topic as TLS:Known(RPK/PSK)-MQTT:none.
o Expanded acronyms on their first use including the ones in the o Expanded acronyms on their first use including the ones in the
title. title.
o Added a definition for "Session". o Added a definition for "Session".
 End of changes. 39 change blocks. 
99 lines changed or deleted 138 lines changed or added

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