draft-ietf-ace-mqtt-tls-profile-05.txt   draft-ietf-ace-mqtt-tls-profile-06.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: November 29, 2020 Oxbotica Expires: January 14, 2021 Oxbotica
P. Fremantle P. Fremantle
University of Portsmouth University of Portsmouth
May 28, 2020 July 13, 2020
MQTT-TLS profile of ACE MQTT-TLS profile of ACE
draft-ietf-ace-mqtt-tls-profile-05 draft-ietf-ace-mqtt-tls-profile-06
Abstract Abstract
This document specifies a profile for the ACE (Authentication and This document specifies a profile for the ACE (Authentication and
Authorization for Constrained Environments) framework to enable Authorization for Constrained Environments) framework to enable
authorization in an MQTT-based publish-subscribe messaging system. authorization in an Message Queuing Telemetry Transport (MQTT)-based
Proof-of-possession keys, bound to OAuth2.0 access tokens, are used publish-subscribe messaging system. Proof-of-possession keys, bound
to authenticate and authorize MQTT Clients. The protocol relies on to OAuth2.0 access tokens, are used to authenticate and authorize
TLS for confidentiality and MQTT server (broker) authentication. MQTT Clients. The protocol relies on TLS for confidentiality and
MQTT server (broker) authentication.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 29, 2020. This Internet-Draft will expire on January 14, 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 36 skipping to change at page 2, line 37
2.2.5. Token Validation . . . . . . . . . . . . . . . . . . 14 2.2.5. Token Validation . . . . . . . . . . . . . . . . . . 14
2.2.6. The Broker's Response to Client Connection Request . 15 2.2.6. The Broker's Response to Client Connection Request . 15
2.2.6.1. Unauthorised Request: Authorisation Server 2.2.6.1. Unauthorised Request: Authorisation Server
Discovery . . . . . . . . . . . . . . . . . . . . 15 Discovery . . . . . . . . . . . . . . . . . . . . 15
2.2.6.2. Authorisation Success . . . . . . . . . . . . . . 15 2.2.6.2. Authorisation Success . . . . . . . . . . . . . . 15
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 16
3.2. PUBLISH Messages from the Broker to the Subscriber 3.2. PUBLISH Messages from the Broker to the Subscriber
Clients . . . . . . . . . . . . . . . . . . . . . . . . . 17 Clients . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3. Authorizing SUBSCRIBE Messages . . . . . . . . . . . . . 17 3.3. Authorizing SUBSCRIBE Messages . . . . . . . . . . . . . 17
4. Token Expiration and Reauthentication . . . . . . . . . . . . 17 4. Token Expiration and Reauthentication . . . . . . . . . . . . 18
5. Handling Disconnections and Retained Messages . . . . . . . . 18 5. Handling Disconnections and Retained Messages . . . . . . . . 18
6. Reduced Protocol Interactions for MQTT v3.1.1 . . . . . . . . 18 6. Reduced Protocol Interactions for MQTT v3.1.1 . . . . . . . . 19
6.1. Token Transport . . . . . . . . . . . . . . . . . . . . . 19 6.1. Token Transport . . . . . . . . . . . . . . . . . . . . . 19
6.2. Handling Authorization Errors . . . . . . . . . . . . . . 20 6.2. Handling Authorization Errors . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Checklist for profile requirements . . . . . . . . . 25 Appendix A. Checklist for profile requirements . . . . . . . . . 25
Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 25 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
This document specifies a profile for the ACE framework This document specifies a profile for the ACE framework
[I-D.ietf-ace-oauth-authz]. In this profile, Clients and Server [I-D.ietf-ace-oauth-authz]. In this profile, Clients and Servers
(Broker) 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
document also describes a reduced set of protocol interactions for document also describes a reduced set of protocol interactions for
MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard]. However, MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard]. However,
MQTT v5.0 is the RECOMMENDED version as it works more naturally with MQTT v5.0 is the RECOMMENDED version as it works more naturally with
ACE-style authentication and authorization. ACE-style authentication and authorization.
MQTT is a publish-subscribe protocol and after connecting to the MQTT MQTT is a publish-subscribe protocol and after connecting to the MQTT
skipping to change at page 4, line 18 skipping to change at page 4, line 18
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,
using JSON encoding. The token may be a reference or JSON Web Token using JSON encoding. The token may be a reference or JSON Web Token
(JWT). For JWTs, this document follows RFC 7800 [RFC7800] for PoP (JWT). For JWTs, this document follows RFC 7800 [RFC7800] for PoP
semantics for JWTs. The Client-AS and RS-AS MAY also use protocols semantics for JWTs. The Client-AS and RS-AS MAY also use protocols
other than HTTP, e.g. CoAP or MQTT. Implementations MAY also use other than HTTP, e.g. Constrained Application Protocol (CoAP) or
'application/ace+cbor' content type, and CBOR encoding, and CBOR Web MQTT. Implementations MAY also use 'application/ace+cbor' content
Token (CWT) and associated PoP semantics to reduce the protocol type, and CBOR encoding, and CBOR Web Token (CWT) and associated PoP
memory and bandwidth requirements. For more information, see Proof- semantics to reduce the protocol memory and bandwidth requirements.
of-Possession Key Semantics for CBOR Web Tokens (CWTs) [RFC8747]. For more information, see Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs) [RFC8747].
1.1. Requirements Language 1.1. Requirements Language
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174], when, and only when, they appear in all 14 [RFC2119] [RFC8174], when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. ACE-Related Terminology 1.2. ACE-Related Terminology
skipping to change at page 5, line 12 skipping to change at page 5, line 13
Broker to publish and subscribe to Application Messages, labelled Broker to publish and subscribe to Application Messages, labelled
with their topics. For additional information, please refer to the with their topics. For additional information, please refer to the
MQTT v5.0 - the OASIS Standard [MQTT-OASIS-Standard-v5] or the MQTT MQTT v5.0 - the OASIS Standard [MQTT-OASIS-Standard-v5] or the MQTT
v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard]. v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard].
MQTTS MQTTS
Secured transport profile of MQTT. MQTTS runs over TLS. Secured transport profile of MQTT. MQTTS runs over TLS.
Broker Broker
The Server in MQTT. It acts as an intermediary between the The Server in MQTT. It acts as an intermediary between the
Clients that publishes Application Messages, and the Clients Clients that publish Application Messages, and the Clients
that made Subscriptions. The Broker acts as the Resource that made Subscriptions. The Broker acts as the Resource
Server for the Clients. Server for the Clients.
Client Client
A device or program that uses MQTT. A device or program that uses MQTT.
Session
A stateful interaction between a Client and a Broker. Some
Sessions last only as long as the network connection, others
can span multiple network connections.
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 Quality-of-Service (QoS) level and a Topic Name.
QoS level QoS level
The level of assurance for the delivery of an Application The level of assurance for the delivery of an Application
Message. The QoS level can be 0-2, where "0" indicates "At Message. The QoS level can be 0-2, where "0" indicates "At
most once delivery", "1" "At least once delivery", and "2" most once delivery", "1" "At least once delivery", and "2"
"Exactly once delivery". "Exactly once delivery".
Topic Name Topic Name
The label attached to an Application Message, which is The label attached to an Application Message, which is
matched to a Subscription. matched to a Subscription.
Subscription Subscription
A Subscription comprises a Topic Filter and a maximum Quality A Subscription comprises a Topic Filter and a maximum QoS. A
of Service (QoS). A Subscription is associated with a single Subscription is associated with a single session.
session.
Topic Filter Topic Filter
An expression that indicates interest in one or more Topic An expression that indicates interest in one or more Topic
Names. Topic Filters may include wildcards. Names. Topic Filters may include wildcards.
MQTT sends various control messages across a network connection. The MQTT sends various control messages across a network connection. The
following is not an exhaustive list and the control packets that are following is not an exhaustive list and the control packets that are
not relevant for authorization are not explained. These include, for not relevant for authorization are not explained. These include, for
instance, the PUBREL and PUBCOMP packets used in the 4-step handshake instance, the PUBREL and PUBCOMP packets used in the 4-step handshake
required for QoS level 2. required for QoS level 2.
CONNECT CONNECT
Client request to connect to the Broker. This is the first Client request to connect to the Broker. This is the first
packet sent by a Client. packet sent by a Client.
CONNACK CONNACK
The Broker connection acknowledgment. The first packet sent The Broker connection acknowledgment. CONNACK packets
from the Broker to a Client is a CONNACK packet. CONNACK contain return codes indicating either a success or an error
packets contain return codes indicating either a success or state to in response to a Client's CONNECT packet.
an error state to a Client.
AUTH AUTH
Authentication Exchange. An AUTH packet is sent from the Authentication Exchange. An AUTH packet is sent from the
Client to the Broker or from the Broker to the Client as part Client to the Broker or from the Broker to the Client as part
of an extended authentication exchange. AUTH Properties of an extended authentication exchange. AUTH Properties
include Authentication Method and Authentication Data. The include Authentication Method and Authentication Data. The
Authentication Method is set in the CONNECT packet, and Authentication Method is set in the CONNECT packet, and
consequent AUTH packets follow the same Authentication consequent AUTH packets follow the same Authentication
Method. The contents of the Authentication Data are defined Method. The contents of the Authentication Data are defined
by the Authentication Method. by the Authentication Method.
skipping to change at page 9, line 8 skipping to change at page 9, line 8
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 assumed to be
Proof-of-Possession (PoP) token by default. This document follows Proof-of-Possession (PoP) token by default. This document follows
RFC 7800 [RFC7800] for PoP semantics for JWTs. The PoP token RFC 7800 [RFC7800] for PoP semantics for JWTs. The PoP token
includes a 'cnf' parameter with a symmetric or asymmetric PoP key. includes a 'cnf' parameter with a symmetric or asymmetric PoP key.
Note that the 'cnf' parameter in the web tokens are to be consumed by Note that the 'cnf' parameter in the web tokens are to be consumed by
the RS and not the Client. For the asymmetric case, the PoP token the RS and not the Client. For the asymmetric case, the PoP token
may include the 'rs_cnf' parameter containing the information about may include the 'rs_cnf' parameter containing the information about
the public key 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 19 skipping to change at page 10, line 19
2.2.2. authz-info: The Authorization Information Topic 2.2.2. authz-info: The Authorization Information Topic
In the cases when the Client MUST transport the token to the Broker In the cases when the Client MUST transport the token to the Broker
first, the Client connects to the Broker to publish its token to the first, the Client connects to the Broker to publish its token to the
"authz-info" topic. The "authz-info" topic MUST be publish-only "authz-info" topic. The "authz-info" topic MUST be publish-only
(i.e. the Clients are not allowed to subscribe to it). "authz-info" (i.e. the Clients are not allowed to subscribe to it). "authz-info"
is not protected, and hence, the Client uses the "TLS:Anon-MQTT:None" is not protected, and hence, the Client uses the "TLS:Anon-MQTT:None"
option over a TLS connection. After publishing the token, the Client option over a TLS connection. After publishing the token, the Client
disconnects from the Broker and is expected to reconnect using client disconnects from the Broker and is expected to reconnect using client
authentication over TLS. authentication over TLS (i.e. TLS:Known(RPK/PSK)-MQTT:none).
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
skipping to change at page 11, line 49 skipping to change at page 11, line 49
| Auth. Data (0x16) | token or | | Auth. Data (0x16) | token or |
| token + PoP data | | token + PoP data |
+------------------------------------------------------+ +------------------------------------------------------+
| Payload | | Payload |
+------------------------------------------------------+ +------------------------------------------------------+
Figure 2: MQTT v5 CONNECT control message with ACE authentication. Figure 2: MQTT v5 CONNECT control message with ACE authentication.
(CPT=Control Packet Type) (CPT=Control Packet Type)
The CONNECT message flags are Username, Password, Will retain, Will The CONNECT message flags are Username, Password, Will retain, Will
QoS, Will Flag, Clean Start, and Reserved. Figure 6 shows how the QoS, Will Flag, Clean Start, and Reserved. Figure 8 shows how the
flags MUST be set to use AUTH packets for authentication and flags MUST be set to use AUTH packets for authentication and
authorisation, i.e. the username and password flags MUST be set to 0. authorisation, i.e. the username and password flags MUST be set to 0.
An MQTT v5.0 RS MAY also support token transport using Username and An MQTT v5.0 RS MAY also support token transport using Username and
Password to provide a security option for MQTT v3.1.1 clients, as Password to provide a security option for MQTT v3.1.1 clients, as
described in Section 6. described in Section 6.
+-----------------------------------------------------------+ +-----------------------------------------------------------+
|User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.| |User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.|
| Flag |Flag | | | |Start| | | Flag |Flag | | | |Start| |
skipping to change at page 16, line 10 skipping to change at page 16, line 10
messages, which are sent after a connection set-up, do not contain messages, which are sent after a connection set-up, do not contain
access tokens. If the introspection result is not cached, then the access tokens. If the introspection result is not cached, then the
RS needs to introspect the saved token for each request. The Broker RS needs to introspect the saved token for each request. The Broker
SHOULD also use a cache time out to introspect tokens regularly. SHOULD also use a cache time out to introspect tokens regularly.
3. Authorizing PUBLISH and SUBSCRIBE Messages 3. Authorizing PUBLISH and SUBSCRIBE Messages
To authorize a Client's PUBLISH and SUBSCRIBE messages, the Broker To authorize a Client's PUBLISH and SUBSCRIBE messages, the Broker
uses the scope field in the token (or in the introspection result). uses the scope field in the token (or in the introspection result).
The scope field contains the publish and subscribe permissions for The scope field contains the publish and subscribe permissions for
the Client and is made up of space-delimited strings. Scope strings the Client. The scope is a JSON array, each item following the
SHOULD be encoded as permission, followed by an underscore, followed Authorization Information Format (AIF) for ACE
by a topic filter. Two permissions apply to topic filters: 'publish' [I-D.bormann-core-ace-aif]. The specific data model for MQTT is:
and 'subscribe'. Topic filters are implemented according to
Section 4.7 of MQTT v5.0 - the OASIS Standard
[MQTT-OASIS-Standard-v5] and includes special wildcard characters.
The multi-level wildcard, '#', matches any number of levels within a
topic, and the single-level wildcard, '+', matches one topic level.
An example scope field may contain 'publish_topic1 subscribe_topic2/# AIF-MQTT = AIF-Generic<topic_filter, permissions>
publish_+/topic3'. This access token gives 'publish' permission to AIF-Generic<topic_filter, permissions> = [* [topic_filter,permissions]]
the 'topic1', 'subscribe' permission to all the subtopics of topic_filter = tstr
'topic2', and 'publish' permission to all topic3, skipping one level. permissions = [+permission]
If the Will Flag is set, then the Broker MUST check that the token permission = "pub"/"sub"
allows the publication of the Will message (i.e. the scope is
"publish_" followed by the Will Topic). Figure 5: AIF-MQTT data model
Topic filters are implemented according to Section 4.7 of MQTT v5.0 -
the OASIS Standard [MQTT-OASIS-Standard-v5] and includes special
wildcard characters. The multi-level wildcard, '#', matches any
number of levels within a topic, and the single-level wildcard, '+',
matches one topic level.
An example scope field may contain:
[["topic1", ["pub","sub"]], ["topic2/#",["pub"]], ["+/topic3",["sub"]]]
Figure 6: Example scope
This access token gives publish ("pub") and subscribe ("sub")
permissions to the 'topic1', publish permission to all the subtopics
of 'topic2', and subscribe permission to all topic3, skipping one
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
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 string 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 'a/topic3' would be allowed to
publish, as the scope includes the string 'publish_+/topic3'. publish, as the scope includes the string 'publish_+/topic3'.
skipping to change at page 19, line 17 skipping to change at page 19, line 29
As in MQTT v5.0, The Token MAY either be transported before by As in MQTT v5.0, The Token MAY either be transported before by
publishing to the "authz-info" topic, or inside the CONNECT message. publishing to the "authz-info" topic, or inside the CONNECT message.
In MQTT v3.1.1, after the Client published to the "authz-info" topic, In MQTT v3.1.1, after the Client published to the "authz-info" topic,
the Broker cannot communicate the result of the token validation as the Broker cannot communicate the result of the token validation as
PUBACK reason codes or server-side DISCONNECT messages are not PUBACK reason codes or server-side DISCONNECT messages are not
supported. In any case, an invalid token would fail the subsequent supported. In any case, an invalid token would fail the subsequent
TLS handshake, which can prompt the Client to obtain a valid token. TLS handshake, which can prompt the Client to obtain a valid token.
To transport the token to the Broker inside the CONNECT message, the To transport the token to the Broker inside the CONNECT message, the
Client uses the username and password fields. Figure 5 shows the Client uses the username and password fields. Figure 7 shows the
structure of the MQTT CONNECT message. structure of the MQTT CONNECT message.
0 8 16 24 32 0 8 16 24 32
+------------------------------------------------------+ +------------------------------------------------------+
|CPT=1 | Rsvd.|Remaining len.| Protocol name len. = 4 | |CPT=1 | Rsvd.|Remaining len.| Protocol name len. = 4 |
+------------------------------------------------------+ +------------------------------------------------------+
| 'M' 'Q' 'T' 'T' | | 'M' 'Q' 'T' 'T' |
+------------------------------------------------------+ +------------------------------------------------------+
| Proto.level=4|Connect flags| Keep alive | | Proto.level=4|Connect flags| Keep alive |
+------------------------------------------------------+ +------------------------------------------------------+
| Payload | | Payload |
| 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 7: 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 8 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 | X | 0 | | 1 | 1 | X | X X | X | X | 0 |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
Figure 6: MQTT CONNECT flags. (Rsvd=Reserved) Figure 8: MQTT CONNECT flags. (Rsvd=Reserved)
The Broker SHOULD NOT accept session continuation. To this end, the The Broker SHOULD NOT accept session continuation. To this end, the
Broker ignores how the Clean Session Flag is set, and on connection Broker ignores how the Clean Session Flag is set, and on connection
success, the Broker MUST set the Session Present flag to 0 in the success, the Broker MUST set the Session Present flag to 0 in the
CONNACK packet to indicate a clean session to the Client. If the CONNACK packet to indicate a clean session to the Client. If the
Broker wishes to support session continuation, it MUST still perform Broker wishes to support session continuation, it MUST still perform
proof-of-possession validation on the provided Client token. MQTT proof-of-possession validation on the provided Client token. MQTT
v3.1.1 does not use a Session Expiry Interval, and the Client expects v3.1.1 does not use a Session Expiry Interval, and the Client expects
that the Broker maintains the session state after it disconnects. that the Broker maintains the session state after it disconnects.
However, stored Session state can be discarded as a result of However, stored Session state can be discarded as a result of
administrator policies, and Brokers SHOULD implement the necessary administrator policies, and Brokers SHOULD implement the necessary
policies to limit misuse. policies to limit misuse.
The Client may set the Will Flag as desired (marked as 'X' in The Client may set the Will Flag as desired (marked as 'X' in
Figure 6). Username and Password flags MUST be set to 1 to ensure Figure 8). Username and Password flags MUST be set to 1 to ensure
that the Payload of the CONNECT message includes both Username and that the Payload of the CONNECT message includes both Username and
Password fields. Password fields.
The CONNECT in MQTT v3.1.1 does not have a field to indicate the The CONNECT in MQTT v3.1.1 does not have a field to indicate the
authentication method. To signal that the Username field contains an authentication method. To signal that the Username field contains an
ACE token, this field MUST be prefixed with 'ace' keyword, which is ACE token, this field MUST be prefixed with 'ace' keyword, which is
followed by the access token. The Password field MUST be set to the followed by the access token. The Password field MUST be set to the
keyed message digest (MAC) or signature associated with the access keyed message digest (MAC) or signature associated with the access
token for proof-of-possession. The Client MUST apply the PoP key on token for proof-of-possession. The Client MUST apply the PoP key on
the challenge derived from the TLS session as described in the challenge derived from the TLS session as described in
skipping to change at page 20, line 37 skipping to change at page 20, line 50
In MQTT v3.1.1, the MQTT Username as a UTF-8 encoded string (i.e. is In MQTT v3.1.1, the MQTT Username as a UTF-8 encoded string (i.e. is
prefixed by a 2-byte length field followed by UTF-8 encoded character prefixed by a 2-byte length field followed by UTF-8 encoded character
data) and may be up to 65535 bytes. Therefore, an access token that data) and may be up to 65535 bytes. Therefore, an access token that
is not a valid UTF-8 MUST be Base64 [RFC4648] encoded. (The MQTT is not a valid UTF-8 MUST be Base64 [RFC4648] encoded. (The MQTT
Password allows binary data up to 65535 bytes.) Password allows binary data up to 65535 bytes.)
6.2. Handling Authorization Errors 6.2. Handling Authorization Errors
Handling errors are more primitive in MQTT v3.1.1 due to not having Handling errors are more primitive in MQTT v3.1.1 due to not having
appropriate error fields, error codes, and server-side DISCONNECTs. appropriate error fields, error codes, and server-side DISCONNECTs.
In the following, we list how errors are handled without such Therefore, the broker will disconnect on almost any error and may not
protocol support. keep session state, necessitating clients to make a greater effort to
ensure that tokens remain valid and not attempt to publish to topics
that they do not have permissions for. The following lists how the
broker responds to specific errors.
o CONNECT without a token: It is not possible to support AS o CONNECT without a token: It is not possible to support AS
discovery via sending a tokenless CONNECT message to the Broker. discovery via sending a tokenless CONNECT message to the Broker.
This is because a CONNACK packet in MQTT v3.1.1 does not include a This is because a CONNACK packet in MQTT v3.1.1 does not include a
means to provide additional information to the Client. Therefore, means to provide additional information to the Client. Therefore,
AS discovery needs to take place out-of-band. CONNECT attempt AS discovery needs to take place out-of-band. CONNECT attempt
MUST fail. MUST fail.
o Client-RS PUBLISH authorization failure: In the case of a failure, o Client-RS PUBLISH authorization failure: In the case of a failure,
it is not possible to return an error in MQTT v3.1.1. it is not possible to return an error in MQTT v3.1.1.
skipping to change at page 22, line 10 skipping to change at page 22, line 27
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 the MQTT standards. In the left to the specific implementation in the MQTT standards. 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.
To authorize a Client's publish and subscribe requests in an ongoing After the RS validates an access token and accepts a connection from
session, the RS caches the access token after accepting the a client, it caches the token to authorize a Client's publish and
connection from the Client. However, if some permissions are revoked subscribe requests in an ongoing session. RS does not cache any
in the meantime, the RS may still grant publish/subscribe to revoked invalid tokens. If a client's permissions get revoked but the access
topics. If the RS caches the token introspection responses, then the token has not expired, the RS may still grant publish/subscribe to
RS should use a reasonable cache timeout to introspect tokens revoked topics. If the RS caches the token introspection responses,
regularly. When permissions change dynamically, it is expected that then the RS should use a reasonable cache timeout to introspect
AS also follows a reasonable expiration strategy for the access tokens regularly. When permissions change dynamically, it is
tokens. expected that AS also follows a reasonable expiration strategy for
the access 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 Section 2.2.2, then this may be "authz-info" topic, described in Section 2.2.2, then this may be
vulnerable to a DDoS attack, where many Clients use the "authz-info" vulnerable to a DDoS attack, where many Clients use the "authz-info"
public topic to transport fictitious tokens, which RS may need to public topic to transport fictitious tokens, which RS may need to
store indefinitely. store indefinitely.
skipping to change at page 23, line 9 skipping to change at page 23, line 27
encrypted separately for the subscribers. This functionality may be encrypted separately for the subscribers. This functionality may be
implemented using the proposal outlined in the CoAP Pub-Sub Profile implemented using the proposal outlined in the CoAP Pub-Sub Profile
[I-D.ietf-ace-pubsub-profile]. However, this solution would still [I-D.ietf-ace-pubsub-profile]. However, this solution would still
not provide privacy for other properties of the message such as Topic not provide privacy for other properties of the message such as Topic
Name. Name.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-ace-dtls-authorize] [I-D.bormann-core-ace-aif]
Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and Bormann, C., "An Authorization Information Format (AIF)
L. Seitz, "Datagram Transport Layer Security (DTLS) for ACE", draft-bormann-core-ace-aif-09 (work in
Profile for Authentication and Authorization for progress), June 2020.
Constrained Environments (ACE)", draft-ietf-ace-dtls-
authorize-10 (work in progress), May 2020.
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35
(work in progress), February 2020. (work in progress), June 2020.
[I-D.ietf-ace-oauth-params] [I-D.ietf-ace-oauth-params]
Seitz, L., "Additional OAuth Parameters for Authorization Seitz, L., "Additional OAuth Parameters for Authorization
in Constrained Environments (ACE)", draft-ietf-ace-oauth- in Constrained Environments (ACE)", draft-ietf-ace-oauth-
params-13 (work in progress), April 2020. params-13 (work in progress), April 2020.
[I-D.ietf-cose-x509] [I-D.ietf-cose-x509]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Header parameters for carrying and referencing X.509 Header parameters for carrying and referencing X.509
certificates", draft-ietf-cose-x509-06 (work in progress), certificates", draft-ietf-cose-x509-06 (work in progress),
skipping to change at page 25, line 5 skipping to change at page 25, line 23
10.2. Informative References 10.2. Informative References
[fremantle14] [fremantle14]
Fremantle, P., Aziz, B., Kopecky, J., and P. Scott, Fremantle, P., Aziz, B., Kopecky, J., and P. Scott,
"Federated Identity and Access Management for the Internet "Federated Identity and Access Management for the Internet
of Things", research International Workshop on Secure of Things", research International Workshop on Secure
Internet of Things, September 2014, Internet of Things, September 2014,
<http://dx.doi.org/10.1109/SIoT.2014.8>. <http://dx.doi.org/10.1109/SIoT.2014.8>.
[I-D.ietf-ace-dtls-authorize]
Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
L. Seitz, "Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for
Constrained Environments (ACE)", draft-ietf-ace-dtls-
authorize-12 (work in progress), July 2020.
[I-D.ietf-ace-pubsub-profile] [I-D.ietf-ace-pubsub-profile]
Palombini, F., "Pub-Sub Profile for Authentication and Palombini, F., "Pub-Sub Profile for Authentication and
Authorization for Constrained Environments (ACE)", draft- Authorization for Constrained Environments (ACE)", draft-
ietf-ace-pubsub-profile-00 (work in progress), January ietf-ace-pubsub-profile-01 (work in progress), July 2020.
2020.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
Appendix A. Checklist for profile requirements Appendix A. Checklist for profile requirements
o AS discovery: AS discovery is possible with the MQTT v5.0 o AS discovery: AS discovery is possible with the MQTT v5.0
described in Section 2.2. described in Section 2.2.
skipping to change at page 25, line 50 skipping to change at page 26, 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 05 to 06:
o Replace the orignally proposed scope format with AIF model.
Defined the AIF-MQTT, gave an example with a JSON array. Added a
normative reference to the AIF draft.
o Clarified client connection after submitting token via "authz-
info" topic as TLS:Known(RPK/PSK)-MQTT:none.
o Expanded acronyms on their first use including the ones in the
title.
o Added a definition for "Session".
o Corrected "CONNACK" definition, which earlier said it's the first
packet sent by the broker.
o Added a statement that the the broker will disconnect on almost
any error and may not keep session state.
o Clarified that the broker does not cache invalid tokens.
Version 04 to 05: Version 04 to 05:
o Reorganised Section 2 such that "Unauthorised Request: o Reorganised Section 2 such that "Unauthorised Request:
Authorisation Server Discovery" is presented under Section 2. Authorisation Server Discovery" is presented under Section 2.
o Fixed Figure 2 to remove the "empty" word. o Fixed Figure 2 to remove the "empty" word.
o Clarified that MQTT v5.0 Brokers may implement username/password o Clarified that MQTT v5.0 Brokers may implement username/password
option for transporting the ACE token only for MQTT v.3.1.1 option for transporting the ACE token only for MQTT v.3.1.1
clients. This option is not recommended for MQTT v.5.0 clients. clients. This option is not recommended for MQTT v.5.0 clients.
 End of changes. 34 change blocks. 
75 lines changed or deleted 124 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/