idnits 2.17.1 draft-ietf-ace-pubsub-profile-01.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 03, 2020) is 1393 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 (-18) exists of draft-ietf-ace-key-groupcomm-07 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-35 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-11 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-11 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). 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 July 03, 2020 5 Expires: January 4, 2021 7 Pub-Sub Profile for Authentication and Authorization for Constrained 8 Environments (ACE) 9 draft-ietf-ace-pubsub-profile-01 11 Abstract 13 This specification defines an application profile for authentication 14 and authorization for publishers and subscribers in a pub-sub setting 15 scenario in a constrained environment, using the ACE framework. This 16 profile relies on transport layer or application layer security to 17 authorize the publisher to the broker. Moreover, it relies on 18 application layer security for publisher-broker and subscriber-broker 19 communication. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 4, 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Application Profile Overview . . . . . . . . . . . . . . . . 3 58 3. PubSub Application Profiles . . . . . . . . . . . . . . . . . 5 59 3.1. Retrieval of COSE Key for protection of content . . . . . 6 60 3.2. coap_pubsub_app Application Profile . . . . . . . . . . . 9 61 3.3. mqtt_pubsub_app Application Profile . . . . . . . . . . . 9 62 4. Publisher . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.1. CoAP Publisher . . . . . . . . . . . . . . . . . . . . . 11 64 4.2. MQTT Publisher . . . . . . . . . . . . . . . . . . . . . 12 65 5. Subscriber . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 5.1. CoAP Subscriber . . . . . . . . . . . . . . . . . . . . . 13 67 5.2. MQTT Subscriber . . . . . . . . . . . . . . . . . . . . . 13 68 6. Pub-Sub Protected Communication . . . . . . . . . . . . . . . 13 69 6.1. Using COSE Objects To Protect The Resource Representation 14 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 72 8.1. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 17 73 8.1.1. CoAP Profile Registration . . . . . . . . . . . . . . 17 74 8.1.2. CoAP Profile Registration . . . . . . . . . . . . . . 17 75 8.2. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 18 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 78 9.2. Informative References . . . . . . . . . . . . . . . . . 19 79 Appendix A. Requirements on Application Profiles . . . . . . . . 19 80 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 83 1. Introduction 85 The publisher-subscriber setting allows for devices with limited 86 reachability to communicate via a broker that enables store-and- 87 forward messaging between the devices. The pub-sub scenario using 88 the Constrained Application Protocol (CoAP) is specified in 89 [I-D.ietf-core-coap-pubsub], while the one using MQTT is specified in 90 REF MQTT. This document defines a way to authorize nodes in a CoAP 91 pub-sub type of setting, using the ACE framework 92 [I-D.ietf-ace-oauth-authz], and to provide the keys for protecting 93 the communication between these nodes. This document gives detailed 94 specifications for MQTT and CoAP pub-sub, but can easily be adapted 95 for other transport protocol as well. 97 1.1. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 Readers are expected to be familiar with the terms and concepts 104 described in [I-D.ietf-ace-oauth-authz], 105 [I-D.ietf-ace-key-groupcomm]. In particular, analogously to 106 [I-D.ietf-ace-oauth-authz], terminology for entities in the 107 architecture such as Client (C), Resource Server (RS), and 108 Authorization Server (AS) is defined in OAuth 2.0 [RFC6749] and 109 [I-D.ietf-ace-actors], and terminology for entities such as the Key 110 Distribution Center (KDC) and Dispatcher in 111 [I-D.ietf-ace-key-groupcomm]. 113 Readers are expected to be familiar with terms and concepts of pub- 114 sub group communication, as described in [I-D.ietf-core-coap-pubsub], 115 or MQTT (REF MQTT pubsub). 117 2. Application Profile Overview 119 The objective of this document is to specify how to authorize nodes, 120 provide keys, and protect a pub-sub communication, using 121 [I-D.ietf-ace-key-groupcomm], which itself expands the Ace framework 122 ([I-D.ietf-ace-oauth-authz]), and transport profiles 123 ([I-D.ietf-ace-dtls-authorize], [I-D.ietf-ace-oscore-profile], REF 124 MQTT profile). The pub-sub communication protocol can be based on 125 CoAP, as described in [I-D.ietf-core-coap-pubsub], MQTT (see REF MQTT 126 comm), or other transport. 128 The architecture of the scenario is shown in Figure 1. 130 +----------------+ +----------------+ 131 | | | | 132 | Authorization | | Authorization | 133 | Server 1 | | Server 2 | 134 | | | | 135 +----------------+ +----------------+ 136 ^ ^ ^ 137 | | | 138 +---------(A)----+ | +-----(D)------+ 139 | +--------------------(B)--------+ | 140 v v v 141 +------------+ +------------+ +------------+ 142 | | | | | | 143 | Publisher | ----(E)---> | Broker | | Subscriber | 144 | | | | <----(F)---- | | 145 | | | | -----(G)---> | | 146 +------------+ +------------+ +------------+ 148 Figure 1: Architecture CoAP pubsub with Authorization Servers 150 The RS is the broker, which contains the topic. This node 151 corresponds to the Dispatcher, in [I-D.ietf-ace-key-groupcomm]. The 152 AS1 hosts the policies about the Broker: what endpoints are allowed 153 to Publish on the Broker. The Clients access this node to get write 154 access to the Broker. The AS2 hosts the policies about the topic: 155 what endpoints are allowed to access what topic. This node 156 represents both the AS and Key Distribution Center roles from 157 [I-D.ietf-ace-key-groupcomm]. 159 There are four phases, the first three can be done in parallel. 161 1. The Publisher requests publishing access to the Broker at the 162 AS1, and communicates with the Broker to set up security. 164 2. The Publisher requests access to a specific topic at the AS2 166 3. The Subscriber requests access to a specific topic at the AS2. 168 4. The Publisher and the Subscriber securely post to and get 169 publications from the Broker. 171 This exchange aims at setting up 2 different security associations: 172 on the one hand, the Publisher has a security association with the 173 Broker, to protect the communication and securely authorize the 174 Publisher to publish on a topic (Security Association 1). On the 175 other hand, the Publisher has a security association with the 176 Subscriber, to protect the publication content itself (Security 177 Association 2). The Security Association 1 is set up using AS1 and a 178 transport profile of [I-D.ietf-ace-oauth-authz], the Security 179 Association 2 is set up using AS2 and [I-D.ietf-ace-key-groupcomm]. 181 Note that, analogously to the Publisher, the Subscriber can also set 182 up an additional security association with the Broker, using an AS, 183 in the same way the Publisher does with AS1. In this case, only 184 authorized Subscribers would be able to get notifications from the 185 Broker. The overhead would be that each Subscriber should access the 186 AS and get all the information to start a secure exchange with the 187 Broker. 189 +------------+ +------------+ +------------+ 190 | | | | | | 191 | Publisher | | Broker | | Subscriber | 192 | | | | | | 193 | | | | | | 194 +------------+ +------------+ +------------+ 195 : : : : 196 : '------ Security -------' : 197 : Association 1 : 198 '------------------------------- Security --------------' 199 Association 2 201 Note that AS1 and AS2 might either be co-resident or be 2 separate 202 physical entities, in which case access control policies must be 203 exchanged between AS1 and AS2, so that they agree on rights for 204 joining nodes about specific topics. How the policies are exchanged 205 is out of scope for this specification. 207 3. PubSub Application Profiles 209 Each profile defined in this document uses 210 [I-D.ietf-ace-key-groupcomm], which expands the ACE framework. This 211 section defines which exact parameters from 212 [I-D.ietf-ace-key-groupcomm] have to be used, and the values for each 213 parameter. Since [I-D.ietf-ace-oauth-authz] recommends the use of 214 CoAP anc CBOR, this document describes the exchanges assuming CoAP 215 and CBOR are used. However, using HTTP instead of CoAP is possible, 216 using the corresponding parameters and methods. Analogously, JSON 217 [RFC8259] can be used instead of CBOR, using the conversion method 218 specified in Sections 4.1 and 4.2 of [RFC7049]. In case JSON is 219 used, the Content Format or Media Type of the message has to be 220 changed accordingly. 222 The Publisher and the Subscriber map to the Client in 223 [I-D.ietf-ace-key-groupcomm], the AS2 maps to the AS and to the KDC, 224 the Broker maps to the Dispatcher. 226 Note that both publishers and subscribers use the same profile. 228 3.1. Retrieval of COSE Key for protection of content 230 This phase is common to both Publisher and Subscriber. To maintain 231 the generality, the Publisher or Subscriber is referred as Client in 232 this section. 234 Client Broker AS2 235 | [----- Resource Request ---->] | | 236 | | | 237 | [<-- AS1, AS2 Information ---] | | 238 | | 239 | [------ Pub Key Format Negociation Request --->] | 240 | | 241 | [<---- Pub Key Format Negociation Response ----] | 242 | | 243 | -- Authorization + Key Distribution Request ---> | 244 | | 245 | <-- Authorization + Key Distribution Response -- | 246 | | 248 Figure 2: B: Access request - response 250 Complementary to what is defined in [I-D.ietf-ace-oauth-authz] 251 (Section 5.1.1), to determine the AS2 in charge of a topic hosted at 252 the Broker, the Broker MAY send the address of both the AS in charge 253 of the topic back to the Client in the 'AS' parameter in the AS 254 Information, as a response to an Unauthorized Resource Request 255 (Section 5.1.2). The uri of AS2 is concatenated to the uri of AS1, 256 and separated by a comma. An example using CBOR diagnostic notation 257 and CoAP is given below: 259 4.01 Unauthorized 260 Content-Format: application/ace+cbor 261 {"AS": "coaps://as1.example.com/token, 262 coaps://as2.example.com/pubsubkey"} 264 Figure 3: AS1, AS2 Information example 266 After retrieving the AS2 address, the Client MAY send a request to 267 the AS, in order to retrieve necessary information concerning the 268 public keys in the group, as well as concerning the algorithm and 269 related parameters for computing signatures in the group. This 270 request is a subset of the Token POST request defined in Section 3.3 271 of [I-D.ietf-ace-key-groupcomm], specifically a CoAP POST request to 272 a specific resource at the AS, including only the parameters 273 'sign_info' and 'pub_key_enc' in the CBOR map in the payload. The 274 default url-path for this resource is /ace-group/gid/cs-info, where 275 "gid" is the topic identifier, but implementations are not required 276 to use this name, and can use their own instead. The AS MUST respond 277 with the response defined in Section 3.3 of 278 [I-D.ietf-ace-key-groupcomm], specifically including the parameters 279 'sign_info', 'pub_key_enc', and 'rsnonce' (8 bytes pseudo-random 280 nonce generated by the AS). 282 After that, the Client sends an Authorization + Joining Request, 283 which is an Authorization Request merged with a Joining Request, as 284 described in [I-D.ietf-ace-key-groupcomm], Sections 3.1 and 4.2. The 285 reason for merging these two messages is that the AS2 is both the AS 286 and the KDC, in this setting, so the Authorization Response and the 287 Post Token message are not necessary. 289 More specifically, the Client sends a POST request to the /ace-group/ 290 gid endpoint on AS2, with Content-Format = "application/ace+cbor" 291 that MUST contain in the payload (formatted as a CBOR map): 293 o the following fields from the Joining Request (Section 4.2 of 294 [I-D.ietf-ace-key-groupcomm]): 296 * 'scope' parameter set to a CBOR array containing: 298 + the broker's topic as first element, and 300 + the text string "publisher" if the client request to be a 301 publisher, "subscriber" if the client request to be a 302 subscriber, or a CBOR array containing both, if the client 303 request to be both. 305 * 'get_pub_keys' parameter set to the empty array if the Client 306 needs to retrieve the public keys of the other pubsub members, 308 * 'client_cred' parameter containing the Client's public key 309 formatted as a COSE_Key, if the Client needs to directly send 310 that to the AS2, 312 * 'cnonce', set to a 8 bytes long pseudo-random nonce, if 313 'client_cred' is present, 315 * 'client_cred_verify', set to a singature computed over the 316 rsnonce concatenated with cnonce, if 'client_cred' is present, 318 * OPTIONALLY, if needed, the 'pub_keys_repos' parameter 320 o the following fields from the Authorization Request (Section 3.1 321 of [I-D.ietf-ace-key-groupcomm]): 323 * OPTIONALLY, if needed, additional parameters such as 324 'client_id' 326 TODO: 'cnonce' might change name. TODO: register media type ace+json 327 for HTTP? 329 Note that the alg parameter in the 'client_cred' COSE_Key MUST be a 330 signing algorithm, as defined in section 8 of [RFC8152], and that it 331 is the same algorithm used to compute the signature sent in 332 'client_cred_verify'. 334 Examples of the payload of a Authorization + Joining Request are 335 specified in Figure 5 and Figure 8. 337 The AS2 verifies that the Client is authorized to access the topic 338 and, if the 'client_cred' parameter is present, stores the public key 339 of the Client. 341 The AS2 response is an Authorization + Joining Response, with 342 Content-Format = "application/ace+cbor". The payload (formatted as a 343 CBOR map) MUST contain: 345 o the following fields from the Joining Response (Section 4.2 of 346 [I-D.ietf-ace-key-groupcomm]): 348 * 'kty' identifies a key type "COSE_Key", as defined in 349 Section 8.2. 351 * 'key', which contains a "COSE_Key" object (defined in 352 [RFC8152], containing: 354 + 'kty' with value 4 (symmetric) 356 + 'alg' with value defined by the AS2 (Content Encryption 357 Algorithm) 359 + 'Base IV' with value defined by the AS2 361 + 'k' with value the symmetric key value 363 + OPTIONALLY, 'kid' with an identifier for the key value 365 * OPTIONALLY, 'exp' with the expiration time of the key 367 * 'pub_keys', containing the public keys of all authorized 368 signing members formatted as COSE_Keys, if the 'get_pub_keys' 369 parameter was present and set to the empty array in the 370 Authorization + Key Distribution Request 372 o the following fields from the Authorization Response (Section 3.2 373 of [I-D.ietf-ace-key-groupcomm]): 375 * 'profile' set to the corresponding value, see Section 3.2 or 376 Section 3.3 378 * OPTIONALLY 'scope', set to a CBOR array containing: 380 + the broker's topic as first element, and 382 + the string "publisher" if the client is an authorized 383 publisher, "subscriber" if the client is an authorized 384 subscriber, or a CBOR array containing both, if the client 385 is authorized to be both. 387 Examples for the response payload are detailed in Figure 6 and 388 Figure 9. 390 3.2. coap_pubsub_app Application Profile 392 In case CoAP PubSub is used as communication protocol: 394 o 'profile' set to "coap_pubsub_app", as specified in Section 8.1.1. 396 3.3. mqtt_pubsub_app Application Profile 398 In case mQTT PubSub is used as communication protocol: 400 o 'profile' set to "mqtt_pubsub_app", as specified in Section 8.1.2. 402 4. Publisher 404 In this section, it is specified how the Publisher requests, obtains 405 and communicates to the Broker the access token, as well as the 406 retrieval of the keying material to protect the publication. 408 +----------------+ +----------------+ 409 | | | | 410 | Authorization | | Authorization | 411 | Server 1 | | Server 2 | 412 | | | | 413 +----------------+ +----------------+ 414 ^ ^ 415 | | 416 +---------(A)----+ | 417 | +--------------------(B)--------+ 418 v v 419 +------------+ +------------+ 420 | | ----(C)---> | | 421 | Publisher | | Broker | 422 | | | | 423 | | | | 424 +------------+ +------------+ 426 Figure 4: Phase 1: Publisher side 428 This is a combination of two independent phases: 430 o one is the establishment of a secure connection between Publisher 431 and Broker, using an ACE transport profile such as DTLS 432 [I-D.ietf-ace-dtls-authorize], OSCORE 433 [I-D.ietf-ace-oscore-profile] or REF MQTT Profile. (A)(C) 435 o the other is the Publisher's retrieval of keying material to 436 protect the publication. (B) 438 In detail: 440 (A) corresponds to the Access Token Request and Response between 441 Publisher and Authorization Server to retrieve the Access Token and 442 RS (Broker) Information. As specified, the Publisher has the role of 443 a CoAP client, the Broker has the role of the CoAP server. 445 (C) corresponds to the exchange between Publisher and Broker, where 446 the Publisher sends its access token to the Broker and establishes a 447 secure connection with the Broker. Depending on the Information 448 received in (A), this can be for example DTLS handshake, or other 449 protocols. Depending on the application, there may not be the need 450 for this set up phase: for example, if OSCORE is used directly. Note 451 that, in line with what defined in the ACE transport profile used, 452 the access token includes the scope (i.e. pubsub topics on the 453 Broker) the Publisher is allowed to publish to. For implementation 454 semplicity, it is RECOMMENDED that the ACE transport profile used and 455 this specification use the same format of "scope". 457 (A) and (C) details are specified in the profile used. 459 (B) corresponds to the retrieval of the keying material to protect 460 the publication end-to-end with the subscribers (see Section 6.1), 461 and uses [I-D.ietf-ace-key-groupcomm]. The details are defined in 462 Section 3.1. 464 4.1. CoAP Publisher 466 An example of the payload of an Authorization + Joining Request and 467 corresponding Response for a CoAP Publisher using CoAP and CBOR is 468 specified in Figure 5 and Figure 6, where SIG is a signature computed 469 using the private key associated to the public key and the algorithm 470 in "client_cred". 472 { 473 "scope" : ["Broker1/Temp", "publisher"], 474 "client_id" : "publisher1", 475 "client_cred" : 476 { / COSE_Key / 477 / type / 1 : 2, / EC2 / 478 / kid / 2 : h'11', 479 / alg / 3 : -7, / ECDSA with SHA-256 / 480 / crv / -1 : 1 , / P-256 / 481 / x / -2 : h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de1 482 08de439c08551d', 483 / y /-3 : h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e 484 9eecd0084d19c', 485 "cnonce" : h'd36b581d1eef9c7c, 486 "client_cred_verify" : SIG 487 } 488 } 490 Figure 5: Authorization + Joining Request payload for a Publisher 492 { 493 "profile" : "coap_pubsub_app", 494 "kty" : "COSE_Key", 495 "key" : {1: 4, 2: h'1234', 3: 12, 5: h'1f389d14d17dc7', 496 -1: h'02e2cc3a9b92855220f255fff1c615bc'} 497 } 499 Figure 6: Authorization + Joining Response payload for a Publisher 501 4.2. MQTT Publisher 503 TODO 505 5. Subscriber 507 In this section, it is specified how the Subscriber retrieves the 508 keying material to protect the publication. 510 +----------------+ 511 | | 512 | Authorization | 513 | Server 2 | 514 | | 515 +----------------+ 516 ^ 517 | 518 +-----(D)------+ 519 | 520 v 521 +------------+ 522 | | 523 | Subscriber | 524 | | 525 | | 526 +------------+ 528 Figure 7: Phase 2: Subscriber side 530 Step (D) between Subscriber and AS2 corresponds to the retrieval of 531 the keying material to verify the publication end-to-end with the 532 publishers (see Section 6.1). The details are defined in Section 3.1 534 This step is the same as (B) between Publisher and AS2 (Section 3.1), 535 with the following differences: 537 o The Authorization + Joining Request MUST NOT contain the 538 'client_cred parameter', the role element in the 'scope' parameter 539 MUST be set to "subscriber". The Subscriber MUST have access to 540 the public keys of all the Publishers; this MAY be achieved in the 541 Authorization + Joining Request by using the parameter 542 'get_pub_keys' set to empty array. 544 o The Authorization + Key Distribution Response MUST contain the 545 'pub_keys' parameter. 547 5.1. CoAP Subscriber 549 An example of the payload of an Authorization + Joining Request and 550 corresponding Response for a CoAP Subscriber using CoAP and CBOR is 551 specified in Figure 8 and Figure 9. 553 { 554 "scope" : ["Broker1/Temp", "subscriber"], 555 "get_pub_keys" : [ ] 556 } 558 Figure 8: Authorization + Joining Request payload for a Subscriber 560 { 561 "profile" : "coap_pubsub_app", 562 "scope" : ["Broker1/Temp", "subscriber"], 563 "kty" : "COSE_Key" 564 "key" : {1: 4, 2: h'1234', 3: 12, 5: h'1f389d14d17dc7', 565 -1: h'02e2cc3a9b92855220f255fff1c615bc'}, 566 "pub_keys" : [ 567 { 568 1 : 2, / type EC2 / 569 2 : h'11', / kid / 570 3 : -7, / alg ECDSA with SHA-256 / 571 -1 : 1 , / crv P-256 / 572 -2 : h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de43 573 9c08551d', / x / 574 -3 : h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd 575 0084d19c' / y / 576 } 577 ] 578 } 580 Figure 9: Authorization + Joining Response payload for a Subscriber 582 5.2. MQTT Subscriber 584 TODO 586 6. Pub-Sub Protected Communication 588 This section specifies the communication Publisher-Broker and 589 Subscriber-Broker, after the previous phases have taken place. The 590 operations of publishing and subscribing are defined in 591 [I-D.ietf-core-coap-pubsub]. 593 +------------+ +------------+ +------------+ 594 | | | | | | 595 | Publisher | ----(E)---> | Broker | | Subscriber | 596 | | | | <----(F)---- | | 597 | | | | -----(G)---> | | 598 +------------+ +------------+ +------------+ 600 Figure 10: Phase 3: Secure communication between Publisher and 601 Subscriber 603 The (E) message corresponds to the publication of a topic on the 604 Broker. The publication (the resource representation) is protected 605 with COSE ([RFC8152]). The (F) message is the subscription of the 606 Subscriber, which is unprotected, unless a profile of ACE 607 [I-D.ietf-ace-oauth-authz] is used between Subscriber and Broker. 608 The (G) message is the response from the Broker, where the 609 publication is protected with COSE. 611 The flow graph is presented below. 613 Publisher Broker Subscriber 614 | --- PUT /topic ----> | | 615 | protected with COSE | | 616 | | <--- GET /topic ----- | 617 | | | 618 | | ---- response ------> | 619 | | protected with COSE | 621 Figure 11: (E), (F), (G): Example of protected communication 623 6.1. Using COSE Objects To Protect The Resource Representation 625 The Publisher uses the symmetric COSE Key received from AS2 in 626 exchange B (Section 3.1) to protect the payload of the PUBLISH 627 operation (Section 4.3 of [I-D.ietf-core-coap-pubsub] and REF MQTT). 628 Specifically, the COSE Key is used to create a COSE_Encrypt0 with 629 algorithm specified by AS2. The Publisher uses the private key 630 corresponding to the public key sent to the AS2 in exchange B 631 (Section 3.1) to countersign the COSE Object as specified in 632 Section 4.5 of [RFC8152]. The CoAP payload is replaced by the COSE 633 object before the publication is sent to the Broker. 635 The Subscriber uses the kid in the countersignature field in the COSE 636 object to retrieve the right public key to verify the 637 countersignature. It then uses the symmetric key received from AS2 638 to verify and decrypt the publication received in the payload of the 639 CoAP Notification from the Broker. 641 The COSE object is constructed in the following way: 643 o The protected Headers (as described in Section 3 of [RFC8152]) MAY 644 contain the kid parameter, with value the kid of the symmetric 645 COSE Key received in Section 3.1 and MUST contain the content 646 encryption algorithm. 648 o The unprotected Headers MUST contain the Partial IV, with value a 649 sequence number that is incremented for every message sent, and 650 the counter signature that includes: 652 * the algorithm (same value as in the asymmetric COSE Key 653 received in (B)) in the protected header; 655 * the kid (same value as the kid of the asymmetric COSE Key 656 received in (B)) in the unprotected header; 658 * the signature computed as specified in Section 4.5 of 659 [RFC8152]. 661 o The ciphertext, computed over the plaintext that MUST contain the 662 CoAP payload. 664 The external_aad is an empty string. 666 An example is given in Figure 12 667 16( 668 [ 669 / protected / h'a2010c04421234' / { 670 \ alg \ 1:12, \ AES-CCM-64-64-128 \ 671 \ kid \ 4: h'1234' 672 } / , 673 / unprotected / { 674 / iv / 5:h'89f52f65a1c580', 675 / countersign / 7:[ 676 / protected / h'a10126' / { 677 \ alg \ 1:-7 678 } / , 679 / unprotected / { 680 / kid / 4:h'11' 681 }, 682 / signature / SIG / 64 bytes signature / 683 ] 684 }, 685 / ciphertext / h'8df0a3b62fccff37aa313c8020e971f8aC8d' 686 ] 687 ) 689 Figure 12: Example of COSE Object sent in the payload of a PUBLISH 690 operation 692 The encryption and decryption operations are described in sections 693 5.3 and 5.4 of [RFC8152]. 695 7. Security Considerations 697 In the profile described above, the Publisher and Subscriber use 698 asymmetric crypto, which would make the message exchange quite heavy 699 for small constrained devices. Moreover, all Subscribers must be 700 able to access the public keys of all the Publishers to a specific 701 topic to be able to verify the publications. Such a database could 702 be set up and managed by the same entity having control of the topic, 703 i.e. AS2. 705 An application where it is not critical that only authorized 706 Publishers can publish on a topic may decide not to make use of the 707 asymmetric crypto and only use symmetric encryption/MAC to 708 confidentiality and integrity protect the publication, but this is 709 not recommended since, as a result, any authorized Subscribers with 710 access to the Broker may forge unauthorized publications without 711 being detected. In this symmetric case the Subscribers would only 712 need one symmetric key per topic, and would not need to know any 713 information about the Publishers, that can be anonymous to it and the 714 Broker. 716 Subscribers can be excluded from future publications through re- 717 keying for a certain topic. This could be set up to happen on a 718 regular basis, for certain applications. How this could be done is 719 out of scope for this work. 721 The Broker is only trusted with verifying that the Publisher is 722 authorized to publish, but is not trusted with the publications 723 itself, which it cannot read nor modify. In this setting, caching of 724 publications on the Broker is still allowed. 726 TODO: expand on security and privacy considerations 728 8. IANA Considerations 730 8.1. ACE Groupcomm Profile Registry 732 The following registrations are done for the "ACE Groupcomm Profile" 733 Registry following the procedure specified in 734 [I-D.ietf-ace-key-groupcomm]. 736 Note to RFC Editor: Please replace all occurrences of "[[This 737 document]]" with the RFC number of this specification and delete this 738 paragraph. 740 8.1.1. CoAP Profile Registration 742 Name: coap_pubsub_app 744 Description: Profile for delegating client authentication and 745 authorization for publishers and subscribers in a CoAP pub-sub 746 setting scenario in a constrained environment. 748 CBOR Key: TBD 750 Reference: [[This document]] 752 8.1.2. CoAP Profile Registration 754 Name: mqtt_pubsub_app 756 Description: Profile for delegating client authentication and 757 authorization for publishers and subscribers in a MQTT pub-sub 758 setting scenario in a constrained environment. 760 CBOR Key: TBD 762 Reference: [[This document]] 764 8.2. ACE Groupcomm Key Registry 766 The following registrations are done for the ACE Groupcomm Key 767 Registry following the procedure specified in 768 [I-D.ietf-ace-key-groupcomm]. 770 Note to RFC Editor: Please replace all occurrences of "[[This 771 document]]" with the RFC number of this specification and delete this 772 paragraph. 774 Name: COSE_Key 776 Key Type Value: TBD 778 Profile: coap_pubsub_app 780 Description: COSE_Key object 782 References: [RFC8152], [[This document]] 784 9. References 786 9.1. Normative References 788 [I-D.ietf-ace-key-groupcomm] 789 Palombini, F. and M. Tiloca, "Key Provisioning for Group 790 Communication using ACE", draft-ietf-ace-key-groupcomm-07 791 (work in progress), June 2020. 793 [I-D.ietf-ace-oauth-authz] 794 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 795 H. Tschofenig, "Authentication and Authorization for 796 Constrained Environments (ACE) using the OAuth 2.0 797 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35 798 (work in progress), June 2020. 800 [I-D.ietf-core-coap-pubsub] 801 Koster, M., Keranen, A., and J. Jimenez, "Publish- 802 Subscribe Broker for the Constrained Application Protocol 803 (CoAP)", draft-ietf-core-coap-pubsub-09 (work in 804 progress), September 2019. 806 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 807 Requirement Levels", BCP 14, RFC 2119, 808 DOI 10.17487/RFC2119, March 1997, 809 . 811 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 812 RFC 6749, DOI 10.17487/RFC6749, October 2012, 813 . 815 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 816 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 817 October 2013, . 819 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 820 RFC 8152, DOI 10.17487/RFC8152, July 2017, 821 . 823 9.2. Informative References 825 [I-D.ietf-ace-actors] 826 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 827 architecture for authorization in constrained 828 environments", draft-ietf-ace-actors-07 (work in 829 progress), October 2018. 831 [I-D.ietf-ace-dtls-authorize] 832 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 833 L. Seitz, "Datagram Transport Layer Security (DTLS) 834 Profile for Authentication and Authorization for 835 Constrained Environments (ACE)", draft-ietf-ace-dtls- 836 authorize-11 (work in progress), June 2020. 838 [I-D.ietf-ace-oscore-profile] 839 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 840 "OSCORE profile of the Authentication and Authorization 841 for Constrained Environments Framework", draft-ietf-ace- 842 oscore-profile-11 (work in progress), June 2020. 844 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 845 Interchange Format", STD 90, RFC 8259, 846 DOI 10.17487/RFC8259, December 2017, 847 . 849 Appendix A. Requirements on Application Profiles 851 This section lists the specifications on this profile based on the 852 requirements defined in Appendix A of [I-D.ietf-ace-key-groupcomm] 854 o REQ1: Specify the encoding and value of the identifier of group or 855 topic of 'scope': see Section 3.1). 857 o REQ2: Specify the encoding and value of roles of 'scope': see 858 Section 3.1). 860 o REQ3: Optionally, specify the acceptable values for 'sign_alg': 861 TODO 863 o REQ4: Optionally, specify the acceptable values for 864 'sign_parameters': TODO 866 o REQ5: Optionally, specify the acceptable values for 867 'sign_key_parameters': TODO 869 o REQ6: Optionally, specify the acceptable values for 'pub_key_enc': 870 TODO 872 o REQ7: Specify the exact format of the 'key' value: COSE_Key, see 873 Section 3.1. 875 o REQ8: Specify the acceptable values of 'kty' : "COSE_Key", see 876 Section 3.1. 878 o REQ9: Specity the format of the identifiers of group members: TODO 880 o REQ10: Optionally, specify the format and content of 881 'group_policies' entries: not defined 883 o REQ11: Specify the communication protocol the members of the group 884 must use: CoAP pub/sub. 886 o REQ12: Specify the security protocol the group members must use to 887 protect their communication. This must provide encryption, 888 integrity and replay protection: Object Security of Content using 889 COSE, see Section 6.1. 891 o REQ13: Specify and register the application profile identifier : 892 "coap_pubsub_app", see Section 8.1. 894 o REQ14: Optionally, specify the encoding of public keys, of 895 'client_cred', and of 'pub_keys' if COSE_Keys are not used: NA. 897 o REQ15: Specify policies at the KDC to handle id that are not 898 included in get_pub_keys: TODO 900 o REQ16: Specify the format and content of 'group_policies': TODO 902 o REQ17: Specify the format of newly-generated individual keying 903 material for group members, or of the information to derive it, 904 and corresponding CBOR label : not defined 906 o REQ18: Specify how the communication is secured between Client and 907 KDC. Optionally, specify tranport profile of ACE 909 [I-D.ietf-ace-oauth-authz] to use between Client and KDC: pre-set, 910 as KDC is AS. 912 o OPT1: Optionally, specify the encoding of public keys, of 913 'client_cred', and of 'pub_keys' if COSE_Keys are not used: NA 915 o OPT2: Optionally, specify the negotiation of parameter values for 916 signature algorithm and signature keys, if 'sign_info' and 917 'pub_key_enc' are not used: NA 919 o OPT3: Optionally, specify the format and content of 920 'mgt_key_material': not defined 922 o OPT4: Optionally, specify policies that instruct clients to retain 923 unsuccessfully decrypted messages and for how long, so that they 924 can be decrypted after getting updated keying material: not 925 defined 927 Acknowledgments 929 The author wishes to thank Ari Keraenen, John Mattsson, Ludwig Seitz, 930 Goeran Selander, Cigdem Sengul, Jim Schaad and Marco Tiloca for the 931 useful discussion and reviews that helped shape this document. 933 Author's Address 935 Francesca Palombini 936 Ericsson 938 Email: francesca.palombini@ericsson.com