| < 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/ | ||||