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