idnits 2.17.1 draft-palombini-ace-coap-pubsub-profile-05.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 08, 2019) is 1752 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-02 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-24 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-08 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-08 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-07 Summary: 1 error (**), 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 08, 2019 5 Expires: January 9, 2020 7 CoAP Pub-Sub Profile for Authentication and Authorization for 8 Constrained Environments (ACE) 9 draft-palombini-ace-coap-pubsub-profile-05 11 Abstract 13 This specification defines a profile for authentication and 14 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 9, 2020. 38 Copyright Notice 40 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Profile Overview . . . . . . . . . . . . . . . . . . . . . . 3 58 3. coap_pubsub_app Profile . . . . . . . . . . . . . . . . . . . 5 59 3.1. Retrieval of COSE Key for protection of content . . . . . 5 60 4. Publisher . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 5. Subscriber . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 6. Pub-Sub Protected Communication . . . . . . . . . . . . . . . 12 63 6.1. Using COSE Objects To Protect The Resource Representation 13 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 66 8.1. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 16 67 8.2. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 16 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 70 9.2. Informative References . . . . . . . . . . . . . . . . . 17 71 Appendix A. Requirements on Application Profiles . . . . . . . . 18 72 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 75 1. Introduction 77 The publisher-subscriber setting allows for devices with limited 78 reachability to communicate via a broker that enables store-and- 79 forward messaging between the devices. The pub-sub scenario using 80 the Constrained Application Protocol (CoAP) is specified in 81 [I-D.ietf-core-coap-pubsub]. This document defines a way to 82 authorize nodes in a CoAP pub-sub type of setting, using the ACE 83 framework [I-D.ietf-ace-oauth-authz], and to provide the keys for 84 protecting the communication between these nodes. 86 1.1. Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 Readers are expected to be familiar with the terms and concepts 93 described in [I-D.ietf-ace-oauth-authz], [I-D.ietf-ace-key-groupcomm] 94 and [I-D.ietf-core-coap-pubsub]. In particular, analogously to 95 [I-D.ietf-ace-oauth-authz], terminology for entities in the 96 architecture such as Client (C), Resource Server (RS), and 97 Authorization Server (AS) is defined in OAuth 2.0 [RFC6749] and 98 [I-D.ietf-ace-actors], and terminology for entities such as the Key 99 Distribution Center (KDC) and Dispatcher in 100 [I-D.ietf-ace-key-groupcomm]. 102 2. Profile Overview 104 The objective of this document is to specify how to authorize nodes, 105 provide keys, and protect a CoAP pub-sub communication, as described 106 in [I-D.ietf-core-coap-pubsub], using [I-D.ietf-ace-key-groupcomm], 107 which itself expands the Ace framework ([I-D.ietf-ace-oauth-authz]), 108 and profiles ([I-D.ietf-ace-dtls-authorize], 109 [I-D.ietf-ace-oscore-profile]). 111 The architecture of the scenario is shown in Figure 1. 113 +----------------+ +----------------+ 114 | | | | 115 | Authorization | | Authorization | 116 | Server 1 | | Server 2 | 117 | | | | 118 +----------------+ +----------------+ 119 ^ ^ ^ 120 | | | 121 +---------(A)----+ | +-----(D)------+ 122 | +--------------------(B)--------+ | 123 v v v 124 +------------+ +------------+ +------------+ 125 | CoAP | ----(C)---> | CoAP | | CoAP | 126 | Client - | ----(E)---> | Server - | | Client - | 127 | | | | <----(F)---- | | 128 | Publisher | | Broker | -----(G)---> | Subscriber | 129 +------------+ +------------+ +------------+ 131 Figure 1: Architecture CoAP pubsub with Authorization Servers 133 The RS is the broker, which contains the topic. This node 134 corresponds to the Dispatcher, in [I-D.ietf-ace-key-groupcomm]. The 135 AS1 hosts the policies about the Broker: what endpoints are allowed 136 to Publish on the Broker. The Clients access this node to get write 137 access to the Broker. The AS2 hosts the policies about the topic: 138 what endpoints are allowed to access what topic. This node 139 represents both the AS and Key Distribution Center roles from 140 [I-D.ietf-ace-key-groupcomm]. 142 There are four phases, the first three can be done in parallel. 144 1. The Publisher requests publishing access to the Broker at the 145 AS1, and communicates with the Broker to set up security. 147 2. The Publisher requests access to a specific topic at the AS2 149 3. The Subscriber requests access to a specific topic at the AS2. 151 4. The Publisher and the Subscriber securely post to and get 152 publications from the Broker. 154 This exchange aims at setting up 2 different security associations: 155 on the one hand, the Publisher has a security association with the 156 Broker, to protect the communication and securely authorize the 157 Publisher to publish on a topic (Security Association 1). On the 158 other hand, the Publisher has a security association with the 159 Subscriber, to protect the publication content itself (Security 160 Association 2). The Security Association 1 is set up using AS1 and a 161 profile of [I-D.ietf-ace-oauth-authz], the Security Association 2 is 162 set up using AS2 and [I-D.ietf-ace-key-groupcomm]. 164 Note that, analogously to the Publisher, the Subscriber can also set 165 up an additional security association with the Broker, using an AS, 166 in the same way the Publisher does with AS1. In this case, only 167 authorized Subscribers would be able to get notifications from the 168 Broker. The overhead would be that each Subscriber should access the 169 AS and get all the information to start a secure exchange with the 170 Broker. 172 +------------+ +------------+ +------------+ 173 | CoAP | | CoAP | | CoAP | 174 | Client - | | Server - | | Client - | 175 | | | | | | 176 | Publisher | | Broker | | Subscriber | 177 +------------+ +------------+ +------------+ 178 : : : : 179 : '------ Security -------' : 180 : Association 1 : 181 '------------------------------- Security --------------' 182 Association 2 184 Note that AS1 and AS2 might either be co-resident or be 2 separate 185 physical entities, in which case access control policies must be 186 exchanged between AS1 and AS2, so that they agree on rights for 187 joining nodes about specific topics. How the policies are exchanged 188 is out of scope for this profile. 190 3. coap_pubsub_app Profile 192 This profile uses [I-D.ietf-ace-key-groupcomm], which expands the ACE 193 framework. This document specifies which exact parameters from 194 [I-D.ietf-ace-key-groupcomm] have to be used, and the values for each 195 parameter. 197 The Publisher and the Subscriber map to the Client in 198 [I-D.ietf-ace-key-groupcomm], the AS2 maps to the AS and to the KDC, 199 the Broker maps to the Dispatcher. 201 Note that both publishers and subscribers use the same profile, 202 called "coap_pubsub_app". 204 3.1. Retrieval of COSE Key for protection of content 206 This phase is common to both Publisher and Subscriber. To maintain 207 the generality, the Publisher or Subscriber is referred as Client in 208 this section. 210 Client Broker AS2 211 | [----- Resource Request ---->] | | 212 | | | 213 | [<-- AS1, AS2 Information ---] | | 214 | | 215 | [------ Pub Key Format Negociation Request --->] | 216 | | 217 | [<---- Pub Key Format Negociation Response ----] | 218 | | 219 | -- Authorization + Key Distribution Request ---> | 220 | | 221 | <-- Authorization + Key Distribution Response -- | 222 | | 224 Figure 2: B: Access request - response 226 Complementary to what is defined in [I-D.ietf-ace-oauth-authz] 227 (Section 5.1.1), to determine the AS2 in charge of a topic hosted at 228 the Broker, the Broker MAY send the address of both the AS in charge 229 of the topic back to the Client in the 'AS' parameter in the AS 230 Information, as a response to an Unauthorized Resource Request 231 (Section 5.1.2). An example using CBOR diagnostic notation is given 232 below: 234 4.01 Unauthorized 235 Content-Format: application/ace+cbor 236 {"AS": "coaps://as1.example.com/token, 237 coaps://as2.example.com/pubsubkey"} 239 Figure 3: AS1, AS2 Information example 241 After retrieving the AS2 address, the Client MAY send a Pub Key 242 Format Negociation Request to the AS, in order to request necessary 243 information concerning the public keys in the group, as well as 244 concerning the algorithm and related parameters for computing 245 signatures in the group. This request is a subset of the Token Post 246 request defined in Section 3.3 of [I-D.ietf-ace-key-groupcomm], 247 specifically including the parameters 'sign_info' and 'pub_key_enc'. 248 The AS MUST respond with the response defined in Section 3.3 of 249 [I-D.ietf-ace-key-groupcomm], specifically including the same 250 parameters 'sign_info' and 'pub_key_enc'. 252 After that, the Client sends an Authorization + Key Distribution 253 Request, which is an Authorization Request merged with a Key 254 Distribution Request, as described in [I-D.ietf-ace-key-groupcomm], 255 Sections 3.1 and 4.1. The reason for merging these two messages is 256 that the AS2 is both the AS and the KDC, in this setting, so the 257 Authorization Response and the Post Token message are not necessary. 259 More specifically, the Client sends a POST request to the /token 260 endpoint on AS2, with Content-Format = "application/ace+cbor" that 261 MUST contain in the payload (formatted as a CBOR map): 263 o the following fields from the Authorization Request (Section 3.1 264 of [I-D.ietf-ace-key-groupcomm]): 266 * 'grant_type' set to "client_credentials", 268 * OPTIONALLY, if needed, other additional parameters such as 269 'client_id' 271 o the following fields from the Key Distribution Request 272 (Section 4.1 of [I-D.ietf-ace-key-groupcomm]): 274 * 'type' set to 1 ("key distribution") 276 * 'client_cred' parameter containing the Client's public key 277 formatted as a COSE_Key, if the Client needs to directly send 278 that to the AS2, 280 * 'scope' parameter set to a CBOR array containing: 282 + the broker's topic as first element, and 284 + the string "publisher" if the client request to be a 285 publisher, "subscriber" if the client request to be a 286 subscriber, or a CBOR array containing both, if the client 287 request to be both. 289 * 'get_pub_keys' parameter set to the empty array if the Client 290 needs to retrieve the public keys of the other pubsub members 292 * OPTIONALLY, if needed, the 'pub_keys_repos' parameter 294 Note that the alg parameter in the 'client_cred' COSE_Key MUST be a 295 signing algorithm, as defined in section 8 of [RFC8152]. 297 Examples of the payload of a Authorization + Key Distribution Request 298 are specified in Figure 5 and Figure 8. 300 The AS2 verifies that the Client is authorized to access the topic 301 and, if the 'client_cred' parameter is present, stores the public key 302 of the Client. 304 The AS2 response is an Authorization + Key Distribution Response, see 305 Section 4.2 of [I-D.ietf-ace-key-groupcomm], with Content-Format = 306 "application/ace+cbor". The payload (formatted as a CBOR map) MUST 307 contain: 309 o the following fields from the Authorization Response (Section 3.2 310 of [I-D.ietf-ace-key-groupcomm]): 312 * 'profile' set to "coap_pubsub_app", as specified in Section 8.1 314 * OPTIONALLY 'scope', set to a CBOR array containing: 316 + the broker's topic as first element, and 318 + the string "publisher" if the client is an authorized 319 publisher, "subscriber" if the client is an authorized 320 subscriber, or a CBOR array containing both, if the client 321 is authorized to be both. 323 o the following fields from the Key Distribution Response 324 (Section 4.2 of [I-D.ietf-ace-key-groupcomm]): 326 * 'kty' identifies a key type "COSE_Key", as defined in 327 Section 8.2. 329 * 'key', which contains a "COSE_Key" object (defined in 330 [RFC8152], containing: 332 + 'kty' with value 4 (symmetric) 334 + 'alg' with value defined by the AS2 (Content Encryption 335 Algorithm) 337 + 'Base IV' with value defined by the AS2 339 + 'k' with value the symmetric key value 341 + OPTIONALLY, 'kid' with an identifier for the key value 343 * OPTIONALLY, exp with the expiration time of the key 345 * 'pub_keys', containing the public keys of all authorized 346 signing members formatted as COSE_Keys, if the 'get_pub_keys' 347 parameter was present and set to the empty array in the 348 Authorization + Key Distribution Request 350 Examples for the response payload are detailed in Figure 6 and 351 Figure 9. 353 4. Publisher 355 In this section, it is specified how the Publisher requests, obtains 356 and communicates to the Broker the access token, as well as the 357 retrieval of the keying material to protect the publication. 359 +----------------+ +----------------+ 360 | | | | 361 | Authorization | | Authorization | 362 | Server 1 | | Server 2 | 363 | | | | 364 +----------------+ +----------------+ 365 ^ ^ 366 | | 367 +---------(A)----+ | 368 | +--------------------(B)--------+ 369 v v 370 +------------+ +------------+ 371 | CoAP | ----(C)---> | CoAP | 372 | Client - | | Server - | 373 | | | | 374 | Publisher | | Broker | 375 +------------+ +------------+ 377 Figure 4: Phase 1: Publisher side 379 This is a combination of two independent phases: 381 o one is the establishment of a secure connection between Publisher 382 and Broker, using an ACE profile such as DTLS 383 [I-D.ietf-ace-dtls-authorize] or OSCORE 384 [I-D.ietf-ace-oscore-profile]. (A)(C) 386 o the other is the Publisher's retrieval of keying material to 387 protect the publication. (B) 389 In detail: 391 (A) corresponds to the Access Token Request and Response between 392 Publisher and Authorization Server to retrieve the Access Token and 393 RS (Broker) Information. As specified, the Publisher has the role of 394 a CoAP client, the Broker has the role of the CoAP server. 396 (C) corresponds to the exchange between Publisher and Broker, where 397 the Publisher sends its access token to the Broker and establishes a 398 secure connection with the Broker. Depending on the Information 399 received in (A), this can be for example DTLS handshake, or other 400 protocols. Depending on the application, there may not be the need 401 for this set up phase: for example, if OSCORE is used directly. 403 (A) and (C) details are specified in the profile used. 405 (B) corresponds to the retrieval of the keying material to protect 406 the publication end-to-end with the subscribers (see Section 6.1), 407 and uses [I-D.ietf-ace-key-groupcomm]. The details are defined in 408 Section 3.1. 410 An example of the payload of an Authorization + Key Distribution 411 Request and corresponding Response for a Publisher is specified in 412 Figure 5 and Figure 6. 414 { 415 "grant_type" : "client_credentials", 416 "scope" : ["Broker1/Temp", "publisher"], 417 "type" = 1, 418 "client_id" : "publisher1", 419 "client_cred" : 420 { / COSE_Key / 421 / type / 1 : 2, / EC2 / 422 / kid / 2 : h'11', 423 / alg / 3 : -7, / ECDSA with SHA-256 / 424 / crv / -1 : 1 , / P-256 / 425 / x / -2 : h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de1 426 08de439c08551d', 427 / y /-3 : h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e 428 9eecd0084d19c' 429 } 430 } 432 Figure 5: Authorization + Key Distribution Request payload for a 433 Publisher 435 { 436 "profile" : "coap_pubsub_app", 437 "kty" : "COSE_Key", 438 "key" : {1: 4, 2: h'1234', 3: 12, 5: h'1f389d14d17dc7', 439 -1: h'02e2cc3a9b92855220f255fff1c615bc'} 440 } 442 Figure 6: Authorization + Key Distribution Response payload for a 443 Publisher 445 5. Subscriber 447 In this section, it is specified how the Subscriber retrieves the 448 keying material to protect the publication. 450 +----------------+ 451 | | 452 | Authorization | 453 | Server 2 | 454 | | 455 +----------------+ 456 ^ 457 | 458 +-----(D)------+ 459 | 460 v 461 +------------+ 462 | CoAP | 463 | Client - | 464 | | 465 | Subscriber | 466 | | 467 +------------+ 469 Figure 7: Phase 2: Subscriber side 471 Step (D) between Subscriber and AS2 corresponds to the retrieval of 472 the keying material to verify the publication end-to-end with the 473 publishers (see Section 6.1). The details are defined in Section 3.1 475 This step is the same as (B) between Publisher and AS2 (Section 3.1), 476 with the following differences: 478 o The Authorization + Key Distribution Request MUST NOT contain the 479 'client_cred parameter', the role element in the 'scope' parameter 480 MUST be set to "subscriber". The Subscriber MUST have access to 481 the public keys of all the Publishers; this MAY be achieved in the 482 Authorization + Key Distribution Request by using the parameter 483 'get_pub_keys' set to empty array. 485 o The Authorization + Key Distribution Response MUST contain the 486 'pub_keys' parameter. 488 An example of the payload of an Authorization + Key Distribution 489 Request and corresponding Response for a Subscriber is specified in 490 Figure 8 and Figure 9. 492 { 493 "grant_type" : "client_credentials", 494 "type" = 1, 495 "scope" : ["Broker1/Temp", "subscriber"], 496 "get_pub_keys" : [ ] 497 } 499 Figure 8: Authorization + Key Distribution Request payload for a 500 Subscriber 502 { 503 "profile" : "coap_pubsub_app", 504 "scope" : ["Broker1/Temp", "subscriber"], 505 "kty" : "COSE_Key" 506 "key" : {1: 4, 2: h'1234', 3: 12, 5: h'1f389d14d17dc7', 507 -1: h'02e2cc3a9b92855220f255fff1c615bc'}, 508 "pub_keys" : [ 509 { 510 1 : 2, / type EC2 / 511 2 : h'11', / kid / 512 3 : -7, / alg ECDSA with SHA-256 / 513 -1 : 1 , / crv P-256 / 514 -2 : h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de43 515 9c08551d', / x / 516 -3 : h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd 517 0084d19c' / y / 518 } 519 ] 520 } 522 Figure 9: Authorization + Key Distribution Response payload for a 523 Subscriber 525 6. Pub-Sub Protected Communication 527 This section specifies the communication Publisher-Broker and 528 Subscriber-Broker, after the previous phases have taken place. The 529 operations of publishing and subscribing are defined in 530 [I-D.ietf-core-coap-pubsub]. 532 +------------+ +------------+ +------------+ 533 | CoAP | | CoAP | | CoAP | 534 | Client - | | Server - | | Client - | 535 | | ----(E)---> | | | | 536 | Publisher | | Broker | <----(F)---- | Subscriber | 537 | | | | -----(G)---> | | 538 +------------+ +------------+ +------------+ 540 Figure 10: Phase 3: Secure communication between Publisher and 541 Subscriber 543 The (E) message corresponds to the publication of a topic on the 544 Broker. The publication (the resource representation) is protected 545 with COSE ([RFC8152]). The (F) message is the subscription of the 546 Subscriber, which is unprotected, unless a profile of ACE 547 [I-D.ietf-ace-oauth-authz] is used between Subscriber and Broker. 548 The (G) message is the response from the Broker, where the 549 publication is protected with COSE. 551 The flow graph is presented below. 553 Publisher Broker Subscriber 554 | --- PUT /topic ----> | | 555 | protected with COSE | | 556 | | <--- GET /topic ----- | 557 | | | 558 | | ---- response ------> | 559 | | protected with COSE | 561 Figure 11: (E), (F), (G): Example of protected communication 563 6.1. Using COSE Objects To Protect The Resource Representation 565 The Publisher uses the symmetric COSE Key received from AS2 in 566 exchange B (Section 3.1) to protect the payload of the PUBLISH 567 operation (Section 4.3 of [I-D.ietf-core-coap-pubsub]). 568 Specifically, the COSE Key is used to create a COSE_Encrypt0 with 569 algorithm specified by AS2. The Publisher uses the private key 570 corresponding to the public key sent to the AS2 in exchange B 571 (Section 3.1) to countersign the COSE Object as specified in 572 Section 4.5 of [RFC8152]. The CoAP payload is replaced by the COSE 573 object before the publication is sent to the Broker. 575 The Subscriber uses the kid in the countersignature field in the COSE 576 object to retrieve the right public key to verify the 577 countersignature. It then uses the symmetric key received from AS2 578 to verify and decrypt the publication received in the payload of the 579 CoAP Notification from the Broker. 581 The COSE object is constructed in the following way: 583 o The protected Headers (as described in Section 3 of [RFC8152]) MAY 584 contain the kid parameter, with value the kid of the symmetric 585 COSE Key received in Section 3.1 and MUST contain the content 586 encryption algorithm. 588 o The unprotected Headers MUST contain the Partial IV, with value a 589 sequence number that is incremented for every message sent, and 590 the counter signature that includes: 592 * the algorithm (same value as in the asymmetric COSE Key 593 received in (B)) in the protected header; 595 * the kid (same value as the kid of the asymmetric COSE Key 596 received in (B)) in the unprotected header; 598 * the signature computed as specified in Section 4.5 of 599 [RFC8152]. 601 o The ciphertext, computed over the plaintext that MUST contain the 602 CoAP payload. 604 The external_aad is an empty string. 606 An example is given in Figure 12 607 16( 608 [ 609 / protected / h'a2010c04421234' / { 610 \ alg \ 1:12, \ AES-CCM-64-64-128 \ 611 \ kid \ 4: h'1234' 612 } / , 613 / unprotected / { 614 / iv / 5:h'89f52f65a1c580', 615 / countersign / 7:[ 616 / protected / h'a10126' / { 617 \ alg \ 1:-7 618 } / , 619 / unprotected / { 620 / kid / 4:h'11' 621 }, 622 / signature / SIG / 64 bytes signature / 623 ] 624 }, 625 / ciphertext / h'8df0a3b62fccff37aa313c8020e971f8aC8d' 626 ] 627 ) 629 Figure 12: Example of COSE Object sent in the payload of a PUBLISH 630 operation 632 The encryption and decryption operations are described in sections 633 5.3 and 5.4 of [RFC8152]. 635 7. Security Considerations 637 In the profile described above, the Publisher and Subscriber use 638 asymmetric crypto, which would make the message exchange quite heavy 639 for small constrained devices. Moreover, all Subscribers must be 640 able to access the public keys of all the Publishers to a specific 641 topic to be able to verify the publications. Such a database could 642 be set up and managed by the same entity having control of the topic, 643 i.e. AS2. 645 An application where it is not critical that only authorized 646 Publishers can publish on a topic may decide not to make use of the 647 asymmetric crypto and only use symmetric encryption/MAC to 648 confidentiality and integrity protect the publication, but this is 649 not recommended since, as a result, any authorized Subscribers with 650 access to the Broker may forge unauthorized publications without 651 being detected. In this symmetric case the Subscribers would only 652 need one symmetric key per topic, and would not need to know any 653 information about the Publishers, that can be anonymous to it and the 654 Broker. 656 Subscribers can be excluded from future publications through re- 657 keying for a certain topic. This could be set up to happen on a 658 regular basis, for certain applications. How this could be done is 659 out of scope for this work. 661 The Broker is only trusted with verifying that the Publisher is 662 authorized to publish, but is not trusted with the publications 663 itself, which it cannot read nor modify. In this setting, caching of 664 publications on the Broker is still allowed. 666 TODO: expand on security and privacy considerations 668 8. IANA Considerations 670 8.1. ACE Groupcomm Profile Registry 672 The following registrations are done for the "ACE Groupcomm Profile" 673 Registry following the procedure specified in 674 [I-D.ietf-ace-key-groupcomm]. 676 Note to RFC Editor: Please replace all occurrences of "[[This 677 document]]" with the RFC number of this specification and delete this 678 paragraph. 680 Name: coap_pubsub_app 682 Description: Profile for delegating client authentication and 683 authorization for publishers and subscribers in a pub-sub setting 684 scenario in a constrained environment. 686 CBOR Key: TBD 688 Reference: [[This document]] 690 8.2. ACE Groupcomm Key Registry 692 The following registrations are done for the ACE Groupcomm Key 693 Registry following the procedure specified in 694 [I-D.ietf-ace-key-groupcomm]. 696 Note to RFC Editor: Please replace all occurrences of "[[This 697 document]]" with the RFC number of this specification and delete this 698 paragraph. 700 Name: COSE_Key 702 Key Type Value: TBD 703 Profile: coap_pubsub_app 705 Description: COSE_Key object 707 References: [RFC8152], [[This document]] 709 9. References 711 9.1. Normative References 713 [I-D.ietf-ace-key-groupcomm] 714 Palombini, F. and M. Tiloca, "Key Provisioning for Group 715 Communication using ACE", draft-ietf-ace-key-groupcomm-02 716 (work in progress), July 2019. 718 [I-D.ietf-ace-oauth-authz] 719 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 720 H. Tschofenig, "Authentication and Authorization for 721 Constrained Environments (ACE) using the OAuth 2.0 722 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24 723 (work in progress), March 2019. 725 [I-D.ietf-core-coap-pubsub] 726 Koster, M., Keranen, A., and J. Jimenez, "Publish- 727 Subscribe Broker for the Constrained Application Protocol 728 (CoAP)", draft-ietf-core-coap-pubsub-08 (work in 729 progress), March 2019. 731 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 732 Requirement Levels", BCP 14, RFC 2119, 733 DOI 10.17487/RFC2119, March 1997, 734 . 736 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 737 RFC 6749, DOI 10.17487/RFC6749, October 2012, 738 . 740 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 741 RFC 8152, DOI 10.17487/RFC8152, July 2017, 742 . 744 9.2. Informative References 746 [I-D.ietf-ace-actors] 747 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 748 architecture for authorization in constrained 749 environments", draft-ietf-ace-actors-07 (work in 750 progress), October 2018. 752 [I-D.ietf-ace-dtls-authorize] 753 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 754 L. Seitz, "Datagram Transport Layer Security (DTLS) 755 Profile for Authentication and Authorization for 756 Constrained Environments (ACE)", draft-ietf-ace-dtls- 757 authorize-08 (work in progress), April 2019. 759 [I-D.ietf-ace-oscore-profile] 760 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 761 "OSCORE profile of the Authentication and Authorization 762 for Constrained Environments Framework", draft-ietf-ace- 763 oscore-profile-07 (work in progress), February 2019. 765 Appendix A. Requirements on Application Profiles 767 This section lists the specifications on this profile based on the 768 requirements defined in Appendix A of [I-D.ietf-ace-key-groupcomm] 770 o Specify the communication protocol the members of the group must 771 use: CoAP pub/sub. 773 o Specify the security protocol the group members must use to 774 protect their communication: Object Security of Content using 775 COSE. 777 o Specify the encoding and value of the identifier of group or topic 778 and role of 'scope': see Section 3.1). 780 o Specify and register the application profile identifier: 781 "coap_pubsub_app", see Section 8.1. 783 o Specify the acceptable values of 'kty': "COSE_Key", see 784 Section 3.1. 786 o Specify the format and content of 'group_policies' entries 788 o Optionally, specify the format and content of 'mgt_key_material': 789 not defined 791 o Optionally, specify tranport profile of ACE 792 [I-D.ietf-ace-oauth-authz] to use between Client and KDC: up to 793 the application. 795 o Optionally, specify the encoding of public keys, of 'client_cred', 796 and of 'pub_keys' if COSE_Keys are not used: COSE_Keys are used. 798 o Optionally, specify the acceptable values for parameters related 799 to signature algorithm and signature keys: 'sign_alg', 800 'sign_parameters', 'sign_key_parameters', 'pub_key_enc': not 801 defined 803 o Optionally, specify the negotiation of parameter values for 804 signature algorithm and signature keys, if 'sign_info' and 805 'pub_key_enc' are not used: not defined. 807 Acknowledgments 809 The author wishes to thank Ari Keraenen, John Mattsson, Ludwig Seitz, 810 Goeran Selander, Jim Schaad and Marco Tiloca for the useful 811 discussion and reviews that helped shape this document. 813 Author's Address 815 Francesca Palombini 816 Ericsson 818 Email: francesca.palombini@ericsson.com