< draft-ietf-ace-mqtt-tls-profile-16.txt   draft-ietf-ace-mqtt-tls-profile-17.txt >
ACE Working Group C.S. Sengul ACE Working Group C.S. Sengul
Internet-Draft Brunel University Internet-Draft Brunel University
Intended status: Standards Track A.K. Kirby Intended status: Standards Track A.K. Kirby
Expires: 22 September 2022 Oxbotica Expires: 24 September 2022 Oxbotica
21 March 2022 23 March 2022
Message Queuing Telemetry Transport (MQTT)-TLS profile of Authentication Message Queuing Telemetry Transport (MQTT)-TLS profile of Authentication
and Authorization for Constrained Environments (ACE) Framework and Authorization for Constrained Environments (ACE) Framework
draft-ietf-ace-mqtt-tls-profile-16 draft-ietf-ace-mqtt-tls-profile-17
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 a Message Queuing Telemetry Transport (MQTT)-based authorization in a 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 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 22 September 2022. This Internet-Draft will expire on 24 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 11, line 21 skipping to change at page 11, line 21
The response includes the parameters described in Section 5.8.2 of The response includes the parameters described in Section 5.8.2 of
the ACE framework [I-D.ietf-ace-oauth-authz]. For RPK, the the ACE framework [I-D.ietf-ace-oauth-authz]. For RPK, the
parameters are as described in Section 3.2.1 of the DTLS profile parameters are as described in Section 3.2.1 of the DTLS profile
[I-D.ietf-ace-dtls-authorize]. For PSK, the document follows [I-D.ietf-ace-dtls-authorize]. For PSK, the document follows
Section 3.3.1 of the DTLS profile [I-D.ietf-ace-dtls-authorize]. In Section 3.3.1 of the DTLS profile [I-D.ietf-ace-dtls-authorize]. In
both cases, if the response contains an "ace_profile" parameter, this both cases, if the response contains an "ace_profile" parameter, this
parameter is set to "mqtt_tls". The returned token is a Proof-of- parameter is set to "mqtt_tls". The returned token is a Proof-of-
Possession (PoP) token by default. Possession (PoP) token by default.
This document follows [RFC7800] for PoP semantics for JWTs (CWTs MAY This document follows [RFC7800] for PoP semantics for JWTs (CWTs MAY
also be used). The AS includes a "cnf" (confirmation) parameter to also be used). The AS includes a "cnf" (confirmation) parameter in
the PoP token, to declare that the Client possesses a particular key the PoP token, to declare that the Client possesses a particular key
and RS can cryptographically confirm that the Client has possession and RS can cryptographically confirm that the Client has possession
of that key. The "cnf" parameter is REQUIRED if a symmetric key is of that key, as described in [I-D.ietf-ace-oauth-params].
used, and MAY be present for asymmetric PoP keys, as described in
[I-D.ietf-ace-oauth-params].
Note that the contents of the web tokens (including the "cnf" Note that the contents of the web tokens (including the "cnf"
parameter) are to be consumed by the RS and not the Client (the parameter) are to be consumed by the RS and not the Client (the
Client obtains the key information in a different manner). The RPK Client obtains the key information in a different manner). The RPK
case is handled as described in Section 3.2.1 of the DTLS profile case is handled as described in Section 3.2.1 of the DTLS profile
[I-D.ietf-ace-dtls-authorize]. For the PSK case, the referenced [I-D.ietf-ace-dtls-authorize]. For the PSK case, the referenced
procedures apply, with the following exceptions to accommodate JWT procedures apply, with the following exceptions to accommodate JWT
and JOSE use. In this case, the AS adds a "cnf" parameter to the and JOSE use. In this case, the AS adds a "cnf" parameter to the
access information carrying a JWK (JSON Web Key) [RFC7517] object access information carrying a JWK (JSON Web Key) [RFC7517] object
that contains either the symmetric key itself or a key identifier that contains either the symmetric key itself or a key identifier
skipping to change at page 22, line 33 skipping to change at page 22, line 33
CONNECT) or a Topic Filter in a SUBSCRIBE packet. CONNECT) or a Topic Filter in a SUBSCRIBE packet.
The scope in the token is a single value. For a JWT, the single The scope in the token is a single value. For a JWT, the single
scope is base64url encoded string with any padding characters scope is base64url encoded string with any padding characters
removed, which has an internal structure of a JSON array. For a CWT, removed, which has an internal structure of a JSON array. For a CWT,
this information is represented in CBOR. The internal structure this information is represented in CBOR. The internal structure
follows the Authorization Information Format (AIF) for ACE follows the Authorization Information Format (AIF) for ACE
[I-D.ietf-ace-aif]. Using the Concise Data Definition Language [I-D.ietf-ace-aif]. Using the Concise Data Definition Language
(CDDL) [RFC8610], the specific data model for MQTT is: (CDDL) [RFC8610], the specific data model for MQTT is:
AIF-MQTT = AIF-Generic<topic_filter, permissions> AIF-MQTT = AIF-Generic<mqtt-topic-filter, mqtt-permissions>
AIF-Generic<topic_filter, permissions> = [* [topic_filter, permissions]] AIF-Generic<Toid, Tperm> = [* [Toid, Tperm]]
topic_filter = tstr mqtt-topic-filter = tstr ; as per Section 4.7 of MQTT v5.0
permissions = [+permission] mqtt-permissions = [+permission]
permission = "pub"/"sub" permission = "pub"/"sub"
Figure 9: AIF-MQTT data model Figure 9: AIF-MQTT data model
Topic filters are implemented according to Section 4.7 of MQTT v5.0 - Topic filters are implemented according to Section 4.7 of MQTT v5.0 -
the OASIS Standard [MQTT-OASIS-Standard-v5]. By default, Wildcard the OASIS Standard [MQTT-OASIS-Standard-v5]. By default, Wildcard
Subscriptions are supported, and so, the topic filter may include Subscriptions are supported, and so, the topic filter may include
special wildcard characters. The multi-level wildcard, "#", matches special wildcard characters. The multi-level wildcard, "#", matches
any number of levels within a topic, and the single-level wildcard, any number of levels within a topic, and the single-level wildcard,
"+", matches one topic level. The Broker MAY signal in the CONNACK "+", matches one topic level. The Broker MAY signal in the CONNACK
explicitly whether wildcard subscriptions are supported by returning explicitly whether wildcard subscriptions are supported by returning
a CONNACK property "Wildcard Subscription Available". A value of 0 a CONNACK property "Wildcard Subscription Available". A value of 0
means that Wildcard Subscriptions are not supported. A value of 1 means that Wildcard Subscriptions are not supported. A value of 1
skipping to change at page 24, line 25 skipping to change at page 24, line 25
Having accepted the connection, the Broker MUST be prepared to store Having accepted the connection, the Broker MUST be prepared to store
the token during the connection and after disconnection for future the token during the connection and after disconnection for future
use. If the token is not self-contained and the Broker uses token use. If the token is not self-contained and the Broker uses token
introspection, it MAY cache the validation result to authorize the introspection, it MAY cache the validation result to authorize the
subsequent PUBLISH and SUBSCRIBE packets. PUBLISH and SUBSCRIBE subsequent PUBLISH and SUBSCRIBE packets. PUBLISH and SUBSCRIBE
packets, which are sent after a connection setup, do not contain packets, which are sent after a connection setup, do not contain
access tokens. If the introspection result is not cached, the Broker access tokens. If the introspection result is not cached, the Broker
needs to introspect the saved token for each request. The Broker needs to introspect the saved token for each request. The Broker
SHOULD also use a cache timeout to introspect tokens regularly. The SHOULD also use a cache timeout to introspect tokens regularly. The
timeout value is application-specific and SHOULD be chosen to reduce timeout value is application-specific and should be chosen to reduce
the risk of using stale introspection responses. the risk of using stale introspection responses.
3. Authorizing PUBLISH and SUBSCRIBE Packets 3. Authorizing PUBLISH and SUBSCRIBE Packets
Using the cached token or its introspection result, the Broker uses Using the cached token or its introspection result, the Broker uses
the scope field to match against the Topic Name in a PUBLISH packet, the scope field to match against the Topic Name in a PUBLISH packet,
or a Topic Filter in a SUBSCRIBE packet. or a Topic Filter in a SUBSCRIBE packet.
3.1. PUBLISH Packets from the Publisher Client to the Broker 3.1. PUBLISH Packets from the Publisher Client to the Broker
skipping to change at page 33, line 28 skipping to change at page 33, line 28
defined in Section 5.1 of [I-D.ietf-ace-aif], IANA is requested to defined in Section 5.1 of [I-D.ietf-ace-aif], IANA is requested to
register the following entries for the two media-type parameters Toid register the following entries for the two media-type parameters Toid
and Tperm, in the respective sub-registry defined in Section 5.2 of and Tperm, in the respective sub-registry defined in Section 5.2 of
[I-D.ietf-ace-aif] within the "MIME Media Type Sub-Parameter" [I-D.ietf-ace-aif] within the "MIME Media Type Sub-Parameter"
registry group. registry group.
For Toid: For Toid:
* Name: mqtt-topic-filter * Name: mqtt-topic-filter
* Description/Specification: Topic Filter as defined in Section 1.3. * Description/Specification: Topic Filter as defined in Section 2.3.
* Reference: [[This document]] (Section 2.3) * Reference: [[This document]] (Section 2.3)
For Tperm: For Tperm:
* Name: mqtt-permissions * Name: mqtt-permissions
* Description/Specification: Permissions for MQTT client. Tperm is * Description/Specification: Permissions for MQTT client as defined
a string with a value either "pub" or "sub". in Section 2.3. Tperm is an array of one or more text strings
that each have a value of either "pub" or "sub".
* Reference: [[This document]] (Section 2.3 ) * Reference: [[This document]] (Section 2.3)
8. Security Considerations 8. Security Considerations
This document specifies a profile for the Authentication and This document specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework Authorization for Constrained Environments (ACE) framework
[I-D.ietf-ace-oauth-authz]. Therefore, the security considerations [I-D.ietf-ace-oauth-authz]. Therefore, the security considerations
outlined in [I-D.ietf-ace-oauth-authz] apply to this work. outlined in [I-D.ietf-ace-oauth-authz] apply to this work.
In addition, the security considerations outlined in MQTT v5.0 - the In addition, the security considerations outlined in MQTT v5.0 - the
OASIS Standard [MQTT-OASIS-Standard-v5] and MQTT v3.1.1 - the OASIS OASIS Standard [MQTT-OASIS-Standard-v5] and MQTT v3.1.1 - the OASIS
skipping to change at page 45, line 11 skipping to change at page 45, line 11
* Clarified the Connect message payload and Client Identifier. * Clarified the Connect message payload and Client Identifier.
* Presented different methods for passing the token and PoP. * Presented different methods for passing the token and PoP.
* Added new figures to explain AUTH packets exchange, updated * Added new figures to explain AUTH packets exchange, updated
CONNECT message figure. CONNECT message figure.
Acknowledgments Acknowledgments
The authors would like to thank Ludwig Seitz for his review and his The authors would like to thank Ludwig Seitz for his review and his
input on the authorization information endpoint, and Benjamin Kaduk input on the authorization information endpoint; Benjamin Kaduk for
for his review, insightful comments, and contributions to resolving his review, insightful comments, and contributions to resolving
issues. The authors would like to thank Paul Fremantle for the issues; and Carsten Bormann for his review and revisions to the AIF-
initial discussions on MQTT v5.0 support. MQTT data model. The authors would like to thank Paul Fremantle for
the initial discussions on MQTT v5.0 support.
Authors' Addresses Authors' Addresses
Cigdem Sengul Cigdem Sengul
Brunel University Brunel University
Dept. of Computer Science Dept. of Computer Science
Uxbridge Uxbridge
UB8 3PH UB8 3PH
United Kingdom United Kingdom
Email: csengul@acm.org Email: csengul@acm.org
 End of changes. 12 change blocks. 
23 lines changed or deleted 23 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/