idnits 2.17.1 draft-ietf-ace-pubsub-profile-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([MQTT-OASIS-Standard-v5], [I-D.ietf-core-coap-pubsub]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (29 December 2021) is 849 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-ietf-rats-uccs-01 == Outdated reference: A later version (-18) exists of draft-ietf-ace-key-groupcomm-15 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-11) exists of draft-ietf-core-groupcomm-bis-05 == Outdated reference: A later version (-09) exists of draft-ietf-cose-cbor-encoded-cert-02 ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' -- Possible downref: Non-RFC (?) normative reference: ref. 'MQTT-OASIS-Standard-v5' == Outdated reference: A later version (-17) exists of draft-ietf-ace-mqtt-tls-profile-13 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group F. Palombini 3 Internet-Draft Ericsson 4 Intended status: Standards Track C. Sengul 5 Expires: 2 July 2022 Brunel University 6 29 December 2021 8 Pub-Sub Profile for Authentication and Authorization for Constrained 9 Environments (ACE) 10 draft-ietf-ace-pubsub-profile-04 12 Abstract 14 This specification defines an application profile for authentication 15 and authorization for Publishers and Subscribers in a constrained 16 pub-sub scenario, using the ACE framework. This profile relies on 17 transport layer or application layer security to authorize the pub- 18 sub clients to the broker. Moreover, it describes the use of 19 application layer security to protect the content of the pub-sub 20 client message exchange through the broker. The profile covers pub- 21 sub scenarios using either the Constrained Application Protocol 22 (CoAP) [I-D.ietf-core-coap-pubsub] or the Message Queue Telemetry 23 Transport (MQTT) [MQTT-OASIS-Standard-v5] protocol. 25 Note to Readers 27 Source for this draft and an issue tracker can be found at 28 https://github.com/ace-wg/pubsub-profile (https://github.com/ace-wg/ 29 pubsub-profile). 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 2 July 2022. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Revised BSD License text as 59 described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Revised BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Application Profile Overview . . . . . . . . . . . . . . . . 3 67 3. PubSub Authorisation . . . . . . . . . . . . . . . . . . . . 5 68 3.1. AS Discovery (Optional) . . . . . . . . . . . . . . . . . 6 69 3.2. Authorising to the KDC and the Broker . . . . . . . . . . 6 70 4. Key Distribution for PubSub Content Protection . . . . . . . 8 71 4.1. Token POST . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.2. Join Request and Join Response . . . . . . . . . . . . . 8 73 5. PubSub Protected Communication . . . . . . . . . . . . . . . 12 74 5.1. Using COSE Objects To Protect The Resource 75 Representation . . . . . . . . . . . . . . . . . . . . . 13 76 6. Profile-specific Considerations . . . . . . . . . . . . . . . 15 77 6.1. CoAP PubSub Application Profile . . . . . . . . . . . . . 15 78 6.2. MQTT PubSub Application Profile . . . . . . . . . . . . . 15 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 81 8.1. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 17 82 8.1.1. CoAP Profile Registration . . . . . . . . . . . . . . 17 83 8.1.2. MQTT Profile Registration . . . . . . . . . . . . . . 17 84 8.2. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 18 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 87 9.2. Informative References . . . . . . . . . . . . . . . . . 20 88 Appendix A. Requirements on Application Profiles . . . . . . . . 21 89 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 92 1. Introduction 94 In the publish-subscribe (pub-sub) scenario, devices with limited 95 reachability communicate via a broker, which enables store-and- 96 forward messaging between the devices. This document defines a way 97 to authorize pub-sub clients using the ACE framework 98 [I-D.ietf-ace-oauth-authz] to obtain the keys for protecting the 99 content of their pub-sub messages when communicating through the 100 broker. The pub-sub communication using the Constrained Application 101 Protocol (CoAP) [RFC7252] is specified in 102 [I-D.ietf-core-coap-pubsub], while the one using MQTT is specified in 103 [MQTT-OASIS-Standard-v5]. This document gives detailed 104 specifications for MQTT and CoAP pub-sub, but can easily be adapted 105 for other transport protocols as well. 107 1.1. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 Readers are expected to be familiar with the terms and concepts 114 described in [I-D.ietf-ace-oauth-authz], 115 [I-D.ietf-ace-key-groupcomm]. In particular, analogously to 116 [I-D.ietf-ace-oauth-authz], terminology for entities in the 117 architecture such as Client (C), Resource Server (RS), and 118 Authorization Server (AS) is defined in OAuth 2.0 [RFC6749] and 119 [I-D.ietf-ace-actors], and terminology for entities such as the Key 120 Distribution Center (KDC) and Dispatcher in 121 [I-D.ietf-ace-key-groupcomm]. 123 Readers are expected to be familiar with terms and concepts of pub- 124 sub group communication, as described in [I-D.ietf-core-coap-pubsub], 125 or MQTT [MQTT-OASIS-Standard-v5]. 127 2. Application Profile Overview 129 The objective of this document is to specify how to authorize nodes, 130 provide keys, and protect a pub-sub communication, using 131 [I-D.ietf-ace-key-groupcomm], which expands from the ACE framework 132 ([I-D.ietf-ace-oauth-authz]), and transport profiles 133 ([I-D.ietf-ace-dtls-authorize], [I-D.ietf-ace-oscore-profile], 134 [I-D.ietf-ace-mqtt-tls-profile]). The pub-sub communication protocol 135 can be based on CoAP, as described in [I-D.ietf-core-coap-pubsub], 136 MQTT [MQTT-OASIS-Standard-v5] , or other transport. Note that both 137 Publishers and Subscribers use the same pub-sub communication 138 protocol and the same transport profile of ACE in their interaction 139 with the broker. However, all clients need to use CoAP when 140 communicating to the KDC. 142 The architecture of the scenario is shown in Figure 1. 144 +----------------+ +----------------+ 145 | | | Key | 146 | Authorization | | Distribution | 147 | Server | | Center | 148 | (AS) | | (KDC) | 149 +----------------+ +----------------+ 150 ^ ^ 151 | | 152 +---------(A)----+ | 153 | +--------------------(B)--------+ 154 v v 155 +------------+ +------------+ 156 | | | | 157 | Pub-Sub | <-- (C)---> | Broker | 158 | Client | | | 159 | | | | 160 +------------+ +------------+ 162 Figure 1: Architecture for Pub-Sub with Authorization Server and Key 163 Distribution Center 165 Publisher or Subscriber Clients is referred to as Client in short. A 166 Client can act both as a publisher and a subscriber, publishing to 167 some topics, and subscribing to others. However, for the simplicity 168 of presentation, this profile describes Publisher and Subscriber 169 clients separately. The Broker acts as the ACE RS, and also 170 corresponds to the Dispatcher in [I-D.ietf-ace-key-groupcomm]). 172 This profile specifies: 174 1. The establishment of a secure connection between a Client and 175 Broker, using an ACE transport profile such as DTLS 176 [I-D.ietf-ace-dtls-authorize], OSCORE 177 [I-D.ietf-ace-oscore-profile], or MQTT-TLS 178 [I-D.ietf-ace-mqtt-tls-profile] (A and C). 180 2. The Clients retrieval of keying material for the Publisher Client 181 to publish protected publications to the Broker, and for the 182 Subscriber Client to read protected publications (B). 184 These exchanges aim at setting up two different security 185 associations. On the one hand, the Publisher and the Subscriber 186 clients have a security association with the Broker, so that, as the 187 ACE RS, it can verify that the Clients are authorized (Security 188 Association 1). On the other hand, the Publisher has a security 189 association with the Subscriber, to protect the publication content 190 (Security Association 2) while sending it through the broker. The 191 Security Association 1 is set up using AS and a transport profile of 192 [I-D.ietf-ace-oauth-authz], the Security Association 2 is set up 193 using AS, KDC and [I-D.ietf-ace-key-groupcomm]. Note that, given 194 that the publication content is protected, the Broker MAY accept 195 unauthorised Subscribers. In this case, the Subscriber client can 196 skip setting up Security Association 1 with the Broker and connect to 197 it as an anonymous client to subscribe to topics of interest at the 198 Broker. 200 +------------+ +------------+ +------------+ 201 | | | | | | 202 | Publisher | | Broker | | Subscriber | 203 | | | | | | 204 | | | | | | 205 +------------+ +------------+ +------------+ 206 : : : : : : 207 : '------ Security -------' '-----------------------' : 208 : Association 1 : 209 '------------------------------- Security --------------' 210 Association 2 212 Figure 2: Security Associations between Publisher, Broker, 213 Subscriber pairs. 215 3. PubSub Authorisation 217 Since [I-D.ietf-ace-oauth-authz] recommends the use of CoAP and CBOR, 218 this document describes the exchanges assuming CoAP and CBOR are 219 used. However, using HTTP instead of CoAP is possible, using the 220 corresponding parameters and methods. Analogously, JSON [RFC8259] 221 can be used instead of CBOR, using the conversion method specified in 222 Sections 6.1 and 6.2 of [RFC8949]. In case JSON is used, the Content 223 Format or Media Type of the message has to be changed accordingly. 224 Exact definition of these exchanges are considered out of scope for 225 this document. 227 Figure 3 shows the message flow for authorisation purposes. 229 Client Broker AS KDC 230 | [--Resource Request (CoAP/MQTT/other)-->] | | | 231 | | | | 232 | [<----AS Information (CoAP/MQTT/other)--] | | | 233 | | | 234 | ----- Authorisation Request (CoAP/HTTP/other)---->| | 235 | | | 236 | <------Authorisation Response (CoAP/HTTP/other) --| | 237 | | 238 |----------------------Token Post (CoAP)------------------->| 239 | | 240 |------------------- Joining Request (CoAP) --------------->| 241 | | 242 |------------------ Joining Response (CoAP) --------------->| 244 Figure 3: Authorisation Flow 246 3.1. AS Discovery (Optional) 248 Complementary to what is defined in [I-D.ietf-ace-oauth-authz] 249 (Section 5.1) for AS discovery, the Broker MAY send the address of 250 the AS to the Client in the 'AS' parameter in the AS Information as a 251 response to an Unauthorized Resource Request (Section 5.2). An 252 example using CBOR diagnostic notation and CoAP is given below: 254 4.01 Unauthorized 255 Content-Format: application/ace-groupcomm+cbor 256 {"AS": "coaps://as.example.com/token"} 258 Figure 4: AS Information example 260 Authorisation Server (AS) Discovery is also defined in 261 Section 2.2.6.1 of [I-D.ietf-ace-mqtt-tls-profile] for MQTT v5 262 clients (and not supported for MQTT v3 clients). 264 3.2. Authorising to the KDC and the Broker 266 After retrieving the AS address, the Client sends two Authorisation 267 Requests to the AS for the KDC and the Broker, respectively. 269 Note that the AS authorises what topics a Client is allowed to 270 Publish or Subscribe to the Broker, which means authorising which 271 application and security groups a Client can join. This is because 272 being able to publish or subscribe to a topic at the Broker is 273 considered as being part of an application group. As this profile 274 secures the message contents, an application group may be a part of a 275 security group, or can be associated to multiple security groups. 276 Therefore, a Client MUST send Authorization Requests for both. 278 Both requests include the following fields from the Authorization 279 Request (Section 3.1 of [I-D.ietf-ace-key-groupcomm]): 281 * 'scope', containing the group identifiers, that the Client wishes 282 to access 284 * 'audience', an identifier, corresponding to either the KDC or the 285 Broker. Other additional parameters can be included if necessary, 286 as defined in [I-D.ietf-ace-oauth-authz]. 288 It must be noted that for pub-sub brokers, the scope represents pub- 289 sub topics i.e., the application group. On the other hand, for the 290 KDC, the scope represents the security group. If there is a one-to- 291 one mapping between the application group and the security group, the 292 client uses the same scope for both requests. If there is not a one- 293 to-one mapping, the correct policies regarding both sets of scopes 294 MUST be available to the AS. To be able to join the right security 295 group associated with requested application groups (i.e., pub-sub 296 topics), the client The client MUST ask for the correct scopes in its 297 Authorization Requests. How the client discovers the (application 298 group, security group) association is out of scope of this document. 299 ToDo: Check OSCORE Groups with the CoRE Resource Directory to see if 300 it applies. 302 The 'scope' parameter is encoded as follows, where 'gname' is treated 303 as topic identifier or filter. 305 gname = tstr 307 role = tstr 309 scope_entry = [ gname , ? ( role / [ 2*role ] ) ] 311 scope = << [ + scope_entry ] >> 313 Figure 5: CDLL definition of scope, using as example group name 314 encoded as tstr and role as tstr. 316 Other scope representations are also possible and are described in 317 (Section 3.1 of [I-D.ietf-ace-key-groupcomm]). Note that in the AIF- 318 MQTT data model described in Section 3 of the 319 [I-D.ietf-ace-mqtt-tls-profile], the role values have been further 320 constrained to "pub" and "sub". 322 The AS responds with an Authorization Response to each request as 323 defined in Section 5.8.2 of [I-D.ietf-ace-oauth-authz] and 324 Section 3.2 of [I-D.ietf-ace-key-groupcomm]. The client needs to 325 keep track of which response corresponds to which entity to use the 326 right token for the right audience, i.e., the KDC or the Broker. In 327 case CoAP PubSub is used as communication protocol, 'profile' claim 328 is set to "coap_pubsub_app" as defined in Section 8.1.1. In case 329 MQTT PubSub is used as communication protocol, 'profile' claim is set 330 to "mqtt_pubsub_app" as defined in Section 8.1.2. 332 4. Key Distribution for PubSub Content Protection 334 4.1. Token POST 336 After receiving a token from the AS, the Client posts the token to 337 the KDC (Section 3.3 [I-D.ietf-ace-key-groupcomm]). In addition to 338 the token post, a Subscriber Client MAY ask for the format of the 339 public keys in the group, used for source authentication, as well as 340 any other group parameters. In this case, the message MUST have 341 Content-Format set to "application/ace+cbor" defined in Section 8.16 342 of [I-D.ietf-ace-oauth-authz]. The message payload MUST be formatted 343 as a CBOR map, which MUST include the access token and the 344 'sign_info' parameter. The details for the 'sign_info' parameter can 345 be found in Section 3.3 of [I-D.ietf-ace-key-groupcomm]. 346 Alternatively, the joining node may retrieve this information by 347 other means as described in [I-D.ietf-ace-key-groupcomm]. 349 The KDC verifies the token to check of the Client is authorized to 350 access the topic with the requested role. After successful 351 verification, the Client is authorized to receive the group keying 352 material from the KDC and join the group. The KDC replies to the 353 Client with a 2.01 (Created) response, using Content-Format 354 "application/ace+cbor". The payload of the 2.01 response is a CBOR 355 map. 357 A Publisher Client MUST send its own public key to the KDC when 358 joining the group. Since the access token from a Publisher Client 359 will have "pub" role, the KDC MUST include 'kdcchallenge' in the CBOR 360 map, specifying a dedicated challenge N_S generated by the KDC. The 361 Client uses this challenge to prove possession of its own private key 362 (see [I-D.ietf-ace-key-groupcomm] for details). 364 4.2. Join Request and Join Response 366 In the next step, a joining node MUST have a secure communication 367 association established with the KDC, before starting to join a group 368 under that KDC. Possible ways to provide a secure communication 369 association are described in the DTLS transport profile 370 [I-D.ietf-ace-dtls-authorize] and OSCORE transport profile 371 [I-D.ietf-ace-oscore-profile] of ACE. 373 After establishing a secure communication, the Client sends a Joining 374 Request to the KDC as described in Section 4.3 of 375 [I-D.ietf-ace-key-groupcomm]. More specifically, the Client sends a 376 POST request to the /ace-group/GROUPNAME endpoint on KDC, with 377 Content-Format "application/ace-groupcomm+cbor" that MUST contain in 378 the payload (formatted as a CBOR map, Section 4.1.2.1 of 379 [I-D.ietf-ace-key-groupcomm]): 381 * 'scope' parameter set to the specific group that the Client is 382 attempting to join, i.e., the group name, and the roles it wishes 383 to have in the group. This value corresponds to one scope entry, 384 as defined in Section 3.2. 386 * 'get_pub_keys' parameter set to the empty array if the Client 387 needs to retrieve the public keys of the other pubsub members, 389 * 'client_cred' parameter containing the Client's public key 390 formatted according to the encoding of the public keys used in the 391 group, if the Client is a Publisher, 393 * 'cnonce', encoded as a CBOR byte string, and including a dedicated 394 nonce N_C generated by the Client, if 'client_cred' is present, 396 * 'client_cred_verify', set to a signature computed over the 397 'rsnonce' concatenated with cnonce, if 'client_cred' is present, 399 * OPTIONALLY, if needed, the 'pub_keys_repos' parameter 401 TODO: Check 'cnonce' 403 Note that for a Subscriber-only Client, the Joining Request MUST NOT 404 contain the 'client_cred parameter', the role element in the 'scope' 405 parameter MUST be set to "sub". The Subscriber MUST have access to 406 the public keys of all the Publishers; this MAY be achieved in the 407 Joining Request by using the parameter 'get_pub_keys' encoding the 408 CBOR simple value 'null' (0xf6) (as described in Section 4.3.1 of 409 [I-D.ietf-ace-key-groupcomm]) to retrieve the public keys of all the 410 Publishers. 412 If the 'client_cred' parameter is present, KDC stores the public key 413 of the Client. Note that the alg parameter in the 'client_cred' 414 COSE_Key MUST be a signing algorithm, as defined in 415 [I-D.ietf-cose-rfc8152bis-algs] [I-D.ietf-cose-rfc8152bis-struct], 416 and that it is the same algorithm used to compute the signature sent 417 in 'client_cred_verify'. 419 The KDC responds with a Joining Response, which has the Content- 420 Format "application/ace-groupcomm+cbor". The payload (formatted as a 421 CBOR map) MUST contain the following fields from the Joining Response 422 (Section 4.3.1 of [I-D.ietf-ace-key-groupcomm]): 424 * 'gkty' identifies a key type for the 'key' parameter. 426 * 'key', which contains a "COSE_Key" object (defined in 427 [I-D.ietf-cose-rfc8152bis-algs][I-D.ietf-cose-rfc8152bis-struct], 428 containing: 430 - 'kty' with value 4 (symmetric) 432 - 'alg' with value defined by the AS (Content Encryption 433 Algorithm) 435 - 'Base IV' with value defined by the AS 437 - 'k' with value the symmetric key value 439 - OPTIONALLY, 'kid' with an identifier for the key value 441 * OPTIONALLY, 'exp' with the expiration time of the key 443 * 'pub_keys', containing the public keys of all Publisher Clients, 444 formatted according to the public key encoding for the group, if 445 the 'get_pub_keys' parameter was present and set to the empty 446 array in the Key Distribution Request. For Subscriber Clients, 447 the Joining Response MUST contain the 'pub_keys' parameter. The 448 encoding accepted for this document is UCCS (Unprotectec CWT 449 Claims Set) [I-D.draft-ietf-rats-uccs-01]. ToDo: Consider 450 allowing other public key formats with the following text. If 451 CBOR Web Tokens (CWTs) or CWT Claims Sets (CCSs) [RFC8392] are 452 used as public key format, the public key algorithm is fully 453 described by a COSE key type and its "kty" and "crv" parameters. 454 If X.509 certificates [RFC7925] or C509 certificates 455 [I-D.ietf-cose-cbor-encoded-cert] are used as public key format, 456 the public key algorithm is fully described by the "algorithm" 457 field of the "SubjectPublicKeyInfo" structure, and by the 458 "subjectPublicKeyAlgorithm" element, respectively. 460 An example of the Joining Request and corresponding Response for a 461 CoAP Publisher using CoAP and CBOR is specified in Figure 6 and 462 Figure 7, where SIG is a signature computed using the private key 463 associated to the public key and the algorithm in 'client_cred'. 465 { 466 "scope" : ["Broker1/Temp", "pub"], 467 "client_cred" : 468 { / COSE_Key / 469 / type / 1 : 2, / EC2 / 470 / kid / 2 : h'11', 471 / alg / 3 : -7, / ECDSA with SHA-256 / 472 / crv / -1 : 1 , / P-256 / 473 / x / -2 : h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de1 474 08de439c08551d', 475 / y /-3 : h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e 476 9eecd0084d19c', 477 "cnonce" : h'd36b581d1eef9c7c, 478 "client_cred_verify" : SIG 479 } 480 } 482 Figure 6: Joining Request payload for a Publisher 484 { 485 "gkty" : "COSE_Key", 486 "key" : {1: 4, 2: h'1234', 3: 12, 5: h'1f389d14d17dc7', 487 -1: h'02e2cc3a9b92855220f255fff1c615bc'} 488 } 490 Figure 7: Joining Response payload for a Publisher 492 An example of the payload of a Joining Request and corresponding 493 Response for a Subscriber using CoAP and CBOR is specified in 494 Figure 8 and Figure 9. 496 { 497 "scope" : ["Broker1/Temp", "sub"], 498 "get_pub_keys" : null 499 } 501 Figure 8: Joining Request payload for a Subscriber 503 { 504 "scope" : ["Broker1/Temp", "sub"], 505 "gkty" : "COSE_Key" 506 "key" : {1: 4, 2: h'1234', 3: 12, 5: h'1f389d14d17dc7', 507 -1: h'02e2cc3a9b92855220f255fff1c615bc'}, 508 "pub_keys" : [ 509 {/UCCS/ 510 2: "42-50-31-FF-EF-37-32-39", /sub/ 511 8: {/cnf/ 512 1: {/COSE_Key/ 513 1 : 1, /alg/ 514 3 : -8 /kty/ 515 -1 : 6 , /crv/ 516 -2 : h'C6EC665E817BD064340E7C24BB93A11E /x/ 517 8EC0735CE48790F9C458F7FA340B8CA3', / x / 518 } 519 } 520 } 521 ] 522 } 524 Figure 9: Joining Response payload for a Subscriber 526 ToDO: Fix Example for COSE_Key for public key 528 5. PubSub Protected Communication 530 +------------+ +------------+ +------------+ 531 | | | | | | 532 | Publisher | ----(D)---> | Broker | | Subscriber | 533 | | | | <----(E)---- | | 534 | | | | -----(F)---> | | 535 +------------+ +------------+ +------------+ 537 Figure 10: Secure communication between Publisher and Subscriber 539 (D) corresponds to the publication of a topic on the Broker. The 540 publication (the resource representation) is protected with COSE 541 ([I-D.ietf-cose-rfc8152bis-algs] [I-D.ietf-cose-rfc8152bis-struct]) 542 by the Publisher. The (E) message is the subscription of the 543 Subscriber. The subscription MAY be unprotected. The (F) message is 544 the response from the Broker, where the publication is protected with 545 COSE by the Publisher. 547 Publisher Broker Subscriber 548 | --- PUT /topic ----> | | 549 | protected with COSE | | 550 | | <--- GET /topic ----- | 551 | | | 552 | | ---- response ------> | 553 | | protected with COSE | 555 Figure 11: (E), (F), (G): Example of protected communication for CoAP 557 The flow graph is presented below for CoAP. The message flow is 558 similar for MQTT, where PUT corresponds to a PUBLISH message, and GET 559 corresponds to a SUBSCRIBE message. Whenever a Client publishes a 560 new message, the Broker sends this message to all valid subscribers. 562 5.1. Using COSE Objects To Protect The Resource Representation 564 The Publisher uses the symmetric COSE Key received from the KDC 565 (Section 4) to protect the payload of the PUBLISH operation 566 (Section 4.3 of [I-D.ietf-core-coap-pubsub] and 567 [MQTT-OASIS-Standard-v5]). Specifically, the COSE Key is used to 568 create a COSE_Encrypt0 object with algorithm specified by KDC. The 569 Publisher uses the private key corresponding to the public key sent 570 to the KDC in exchange B (Section 4) to countersign the COSE Object 571 as specified in [I-D.ietf-cose-rfc8152bis-algs] 572 [I-D.ietf-cose-rfc8152bis-struct]. The payload is replaced by the 573 COSE object before the publication is sent to the Broker. 575 The Subscriber uses the 'kid' in the 'countersignature' field in the 576 COSE object to retrieve the right public key to verify the 577 countersignature. It then uses the symmetric key received from KDC 578 to verify and decrypt the publication received in the payload from 579 the Broker (in the case of CoAP the publication is received by the 580 CoAP Notification and for MQTT, it is received as a PUBLISH message 581 from the Broker to the subscribing client). 583 The COSE object is constructed in the following way: 585 * The protected Headers (as described in 586 [I-D.ietf-cose-rfc8152bis-algs] [I-D.ietf-cose-rfc8152bis-struct]) 587 MUST contain the kid parameter if it was provided in the Joining 588 Response, with value the kid of the symmetric COSE Key received in 589 Section 4 and MUST contain the content encryption algorithm. 591 * The unprotected Headers MUST contain the Partial IV, with value a 592 sequence number that is incremented for every message sent, and 593 the counter signature that includes: 595 - the algorithm (same value as in the asymmetric COSE Key 596 received in (B)) in the protected header; 598 - the kid (same value as the kid of the asymmetric COSE Key 599 received in (B)) in the unprotected header; 601 - the signature computed as specified in 602 [I-D.ietf-cose-rfc8152bis-algs] 603 [I-D.ietf-cose-rfc8152bis-struct]. 605 * The ciphertext, computed over the plaintext that MUST contain the 606 message payload. 608 The 'external_aad' is an empty string. 610 An example is given in Figure 12: 612 16( 613 [ 614 / protected / h'a2010c04421234' / { 615 \ alg \ 1:12, \ AES-CCM-64-64-128 \ 616 \ kid \ 4: h'1234' 617 } / , 618 / unprotected / { 619 / iv / 5:h'89f52f65a1c580', 620 / countersign / 7:[ 621 / protected / h'a10126' / { 622 \ alg \ 1:-7 623 } / , 624 / unprotected / { 625 / kid / 4:h'11' 626 }, 627 / signature / SIG / 64 bytes signature / 628 ] 629 }, 630 / ciphertext / h'8df0a3b62fccff37aa313c8020e971f8aC8d' 631 ] 632 ) 634 Figure 12: Example of COSE Object sent in the payload of a 635 PUBLISH operation 637 The encryption and decryption operations are described in 638 [I-D.ietf-cose-rfc8152bis-algs] [I-D.ietf-cose-rfc8152bis-struct]. 640 6. Profile-specific Considerations 642 This section summarises the CoAP and MQTT specific pub-sub 643 communications, and considerations respectively. 645 6.1. CoAP PubSub Application Profile 647 A CoAP Pub-Sub Client and Broker use an ACE transport profile such as 648 DTLS [I-D.ietf-ace-dtls-authorize], OSCORE 649 [I-D.ietf-ace-oscore-profile]. 651 As shown in Figure 1, (A) is an Access Token Request and Response 652 exchange between Publisher and Authorization Server to retrieve the 653 Access Token and RS (Broker) Information. As specified, the Client 654 has the role of a CoAP client, the Broker has the role of the CoAP 655 server. 657 (B) corresponds to the retrieval of the keying material to protect 658 the publication end-to-end (see Section 5.1), and uses 659 [I-D.ietf-ace-key-groupcomm]. The details are defined in Section 4. 661 (C) corresponds to the exchange between the Client and the Broker, 662 where the Client sends its access token to the Broker and establishes 663 a secure connection with the Broker. Depending on the Information 664 received in (A), this can be for example DTLS handshake, or other 665 protocols. Depending on the application, there may not be the need 666 for this set up phase: for example, if OSCORE is used directly. Note 667 that, in line with what defined in the ACE transport profile used, 668 the access token includes the scope (i.e. pubsub topics on the 669 Broker) the Publisher is allowed to publish to. For implementation 670 simplicity, it is RECOMMENDED that the ACE transport profile used. 672 After the previous phases have taken place, the pub-sub communication 673 can commence. The operations of publishing and subscribing are 674 defined in [I-D.ietf-core-coap-pubsub]. 676 6.2. MQTT PubSub Application Profile 678 The steps MQTT clients go through are similar to the CoAP clients as 679 described in Section 6.1. The payload that is carried in MQTT 680 messages will be protected using COSE. 682 In MQTT, topics are organised as a tree, and in the 683 [I-D.ietf-ace-mqtt-tls-profile] 'scope' captures permissions for not 684 a single topic but a topic filter. Therefore, topic names (i.e., 685 group names) may include wildcards spanning several levels of the 686 topic tree. Hence, it is important to distinguish application groups 687 and security groups defined in [I-D.ietf-core-groupcomm-bis]. An 688 application group has relevance at the application level - for 689 example, in MQTT an application group could denote all topics stored 690 under ""home/lights/". On the other hand, a security group is a 691 group of endpoints that each store group security material to 692 exchange secure communication within the group. The group 693 communication in [I-D.ietf-ace-key-groupcomm] refers to security 694 groups. ToDo: Give a more complete example 696 For an MQTT client we envision the following steps to take place: 698 1. Client sends a token request to AS for the requested topics 699 (application groups) using the broker as the audience. 701 2. Client sends a token request to AS for the corresponding security 702 groups for its application groups using the KDC as the audience. 704 3. Client sends join requests to KDC to gets the keys for these 705 security groups. 707 4. Client authorises to the Broker with the token (described in 708 [I-D.ietf-ace-mqtt-tls-profile]). 710 5. A Publisher Client sends PUBLISH messages for a given topic and 711 protects the payload with the corresponding key for the 712 associated security group. RS validates the PUBLISH message by 713 checking the topic stored token. 715 6. A Subscriber Client may send SUBSCRIBE messages with one or 716 multiple topic filters. A topic filter may correspond to 717 multiple topics. RS validates the SUBSCRIBE message by checking 718 the stored token for the Client. 720 7. Security Considerations 722 In the profile described above, the Publisher and Subscriber use 723 asymmetric crypto, which would make the message exchange quite heavy 724 for small constrained devices. Moreover, all Subscribers must be 725 able to access the public keys of all the Publishers to a specific 726 topic to be able to verify the publications. Such a database could 727 be set up and managed by the same entity having control of the key 728 material for that topic, i.e. KDC. 730 An application where it is not critical that only authorized 731 Publishers can publish on a topic may decide not to make use of the 732 asymmetric crypto and only use symmetric encryption/MAC to 733 confidentiality and integrity protection of the publication. 734 However, this is not recommended since, as a result, any authorized 735 Subscribers with access to the Broker may forge unauthorized 736 publications without being detected. In this symmetric case the 737 Subscribers would only need one symmetric key per topic, and would 738 not need to know any information about the Publishers, that can be 739 anonymous to it and the Broker. 741 Subscribers can be excluded from future publications through re- 742 keying for a certain topic. This could be set up to happen on a 743 regular basis, for certain applications. How this could be done is 744 out of scope for this work. 746 The Broker is only trusted with verifying that the Publisher is 747 authorized to publish, but is not trusted with the publications 748 itself, which it cannot read nor modify. In this setting, caching of 749 publications on the Broker is still allowed. 751 TODO: expand on security and privacy considerations 753 8. IANA Considerations 755 8.1. ACE Groupcomm Profile Registry 757 The following registrations are done for the "ACE Groupcomm Profile" 758 Registry following the procedure specified in 759 [I-D.ietf-ace-key-groupcomm]. 761 Note to RFC Editor: Please replace all occurrences of "[[This 762 document]]" with the RFC number of this specification and delete this 763 paragraph. 765 8.1.1. CoAP Profile Registration 767 Name: coap_pubsub_app 769 Description: Profile for delegating client authentication and 770 authorization for publishers and subscribers in a CoAP pub-sub 771 setting scenario in a constrained environment. 773 CBOR Key: TBD 775 Reference: [[This document]] 777 8.1.2. MQTT Profile Registration 779 Name: mqtt_pubsub_app 781 Description: Profile for delegating client authentication and 782 authorization for publishers and subscribers in a MQTT pub-sub 783 setting scenario in a constrained environment. 785 CBOR Key: TBD 787 Reference: [[This document]] 789 8.2. ACE Groupcomm Key Registry 791 The following registrations are done for the ACE Groupcomm Key 792 Registry following the procedure specified in 793 [I-D.ietf-ace-key-groupcomm]. 795 Note to RFC Editor: Please replace all occurrences of "[[This 796 document]]" with the RFC number of this specification and delete this 797 paragraph. 799 Name: COSE_Key 801 Key Type Value: TBD 803 Profile: coap_pubsub_app, mqtt_pubsub_app 805 Description: COSE_Key object 807 References: [I-D.ietf-cose-rfc8152bis-algs] 808 [I-D.ietf-cose-rfc8152bis-struct], [[This document]] 810 9. References 812 9.1. Normative References 814 [I-D.draft-ietf-rats-uccs-01] 815 Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C. 816 Bormann, "A CBOR Tag for Unprotected CWT Claims Sets", 817 Work in Progress, Internet-Draft, draft-ietf-rats-uccs-01, 818 12 July 2021, . 821 [I-D.ietf-ace-key-groupcomm] 822 Palombini, F. and M. Tiloca, "Key Provisioning for Group 823 Communication using ACE", Work in Progress, Internet- 824 Draft, draft-ietf-ace-key-groupcomm-15, 23 December 2021, 825 . 828 [I-D.ietf-ace-oauth-authz] 829 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 830 H. Tschofenig, "Authentication and Authorization for 831 Constrained Environments (ACE) using the OAuth 2.0 832 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 833 draft-ietf-ace-oauth-authz-46, 8 November 2021, 834 . 837 [I-D.ietf-core-coap-pubsub] 838 Koster, M., Keranen, A., and J. Jimenez, "Publish- 839 Subscribe Broker for the Constrained Application Protocol 840 (CoAP)", Work in Progress, Internet-Draft, draft-ietf- 841 core-coap-pubsub-09, 30 September 2019, 842 . 845 [I-D.ietf-core-groupcomm-bis] 846 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 847 for the Constrained Application Protocol (CoAP)", Work in 848 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 849 05, 25 October 2021, . 852 [I-D.ietf-cose-cbor-encoded-cert] 853 Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and 854 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 855 Certificates)", Work in Progress, Internet-Draft, draft- 856 ietf-cose-cbor-encoded-cert-02, 12 July 2021, 857 . 860 [I-D.ietf-cose-rfc8152bis-algs] 861 Schaad, J., "CBOR Object Signing and Encryption (COSE): 862 Initial Algorithms", Work in Progress, Internet-Draft, 863 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 864 . 867 [I-D.ietf-cose-rfc8152bis-struct] 868 Schaad, J., "CBOR Object Signing and Encryption (COSE): 869 Structures and Process", Work in Progress, Internet-Draft, 870 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 871 . 874 [MQTT-OASIS-Standard-v5] 875 Banks, A., Briggs, E., Borgendale, K., and R. Gupta, 876 "OASIS Standard MQTT Version 5.0", 2017, 877 . 880 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 881 Requirement Levels", BCP 14, RFC 2119, 882 DOI 10.17487/RFC2119, March 1997, 883 . 885 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 886 RFC 6749, DOI 10.17487/RFC6749, October 2012, 887 . 889 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 890 Application Protocol (CoAP)", RFC 7252, 891 DOI 10.17487/RFC7252, June 2014, 892 . 894 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 895 Security (TLS) / Datagram Transport Layer Security (DTLS) 896 Profiles for the Internet of Things", RFC 7925, 897 DOI 10.17487/RFC7925, July 2016, 898 . 900 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 901 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 902 May 2018, . 904 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 905 Representation (CBOR)", STD 94, RFC 8949, 906 DOI 10.17487/RFC8949, December 2020, 907 . 909 9.2. Informative References 911 [I-D.ietf-ace-actors] 912 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 913 architecture for authorization in constrained 914 environments", Work in Progress, Internet-Draft, draft- 915 ietf-ace-actors-07, 22 October 2018, 916 . 919 [I-D.ietf-ace-dtls-authorize] 920 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 921 L. Seitz, "Datagram Transport Layer Security (DTLS) 922 Profile for Authentication and Authorization for 923 Constrained Environments (ACE)", Work in Progress, 924 Internet-Draft, draft-ietf-ace-dtls-authorize-18, 4 June 925 2021, . 928 [I-D.ietf-ace-mqtt-tls-profile] 929 Sengul, C. and A. Kirby, "Message Queuing Telemetry 930 Transport (MQTT)-TLS profile of Authentication and 931 Authorization for Constrained Environments (ACE) 932 Framework", Work in Progress, Internet-Draft, draft-ietf- 933 ace-mqtt-tls-profile-13, 23 October 2021, 934 . 937 [I-D.ietf-ace-oscore-profile] 938 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 939 "OSCORE Profile of the Authentication and Authorization 940 for Constrained Environments Framework", Work in Progress, 941 Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May 942 2021, . 945 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 946 Interchange Format", STD 90, RFC 8259, 947 DOI 10.17487/RFC8259, December 2017, 948 . 950 Appendix A. Requirements on Application Profiles 952 This section lists the specifications on this profile based on the 953 requirements defined in Appendix A of [I-D.ietf-ace-key-groupcomm] 955 * REQ1: Specify the encoding and value of the identifier of group or 956 topic of 'scope': see Section 4). 958 * REQ2: Specify the encoding and value of roles of 'scope': see 959 Section 4). 961 * REQ3: Optionally, specify the acceptable values for 'sign_alg': 962 TODO 964 * REQ4: Optionally, specify the acceptable values for 965 'sign_parameters': TODO 967 * REQ5: Optionally, specify the acceptable values for 968 'sign_key_parameters': TODO 970 * REQ6: Optionally, specify the acceptable values for 'pub_key_enc': 971 TODO 973 * REQ7: Specify the exact format of the 'key' value: COSE_Key, see 974 Section 4. 976 * REQ8: Specify the acceptable values of 'kty' : "COSE_Key", see 977 Section 4. 979 * REQ9: Specify the format of the identifiers of group members: TODO 981 * REQ10: Optionally, specify the format and content of 982 'group_policies' entries: not defined 984 * REQ11: Specify the communication protocol the members of the group 985 must use: CoAP pub/sub. 987 * REQ12: Specify the security protocol the group members must use to 988 protect their communication. This must provide encryption, 989 integrity and replay protection: Object Security of Content using 990 COSE, see Section 5.1. 992 * REQ13: Specify and register the application profile identifier : 993 "coap_pubsub_app", see Section 8.1. 995 * REQ14: Optionally, specify the encoding of public keys, of 996 'client_cred', and of 'pub_keys' if COSE_Keys are not used: NA. 998 * REQ15: Specify policies at the KDC to handle id that are not 999 included in get_pub_keys: TODO 1001 * REQ16: Specify the format and content of 'group_policies': TODO 1003 * REQ17: Specify the format of newly-generated individual keying 1004 material for group members, or of the information to derive it, 1005 and corresponding CBOR label : not defined 1007 * REQ18: Specify how the communication is secured between Client and 1008 KDC. Optionally, specify transport profile of ACE 1009 [I-D.ietf-ace-oauth-authz] to use between Client and KDC: pre-set, 1010 as KDC is AS. 1012 * OPT1: Optionally, specify the encoding of public keys, of 1013 'client_cred', and of 'pub_keys' if COSE_Keys are not used: NA 1015 * OPT2: Optionally, specify the negotiation of parameter values for 1016 signature algorithm and signature keys, if 'sign_info' and 1017 'pub_key_enc' are not used: NA 1019 * OPT3: Optionally, specify the format and content of 1020 'mgt_key_material': not defined 1022 * OPT4: Optionally, specify policies that instruct clients to retain 1023 unsuccessfully decrypted messages and for how long, so that they 1024 can be decrypted after getting updated keying material: not 1025 defined 1027 Acknowledgments 1029 The author wishes to thank Ari Keraenen, John Mattsson, Ludwig Seitz, 1030 Goeran Selander, Jim Schaad and Marco Tiloca for the useful 1031 discussion and reviews that helped shape this document. 1033 Authors' Addresses 1035 Francesca Palombini 1036 Ericsson 1038 Email: francesca.palombini@ericsson.com 1040 Cigdem Sengul 1041 Brunel University 1043 Email: csengul@acm.org