idnits 2.17.1 draft-palombini-ace-coap-pubsub-profile-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- 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 (April 03, 2019) is 1848 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-01 == 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-07 == 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 April 03, 2019 5 Expires: October 5, 2019 7 CoAP Pub-Sub Profile for Authentication and Authorization for 8 Constrained Environments (ACE) 9 draft-palombini-ace-coap-pubsub-profile-04 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 October 5, 2019. 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 Profile . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Retrieval of COSE Key for protection of content . . . . . 5 60 4. Publisher . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5. Subscriber . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 6. Pub-Sub Protected Communication . . . . . . . . . . . . . . . 11 63 6.1. Using COSE Objects to protect the resource representation 12 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 66 8.1. ACE OAuth Profile Registry . . . . . . . . . . . . . . . 14 67 8.2. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 15 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 70 9.2. Informative References . . . . . . . . . . . . . . . . . 16 71 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 74 1. Introduction 76 The publisher-subscriber setting allows for devices with limited 77 reachability to communicate via a broker that enables store-and- 78 forward messaging between the devices. The pub-sub scenario using 79 the Constrained Application Protocol (CoAP) is specified in 80 [I-D.ietf-core-coap-pubsub]. This document defines a way to 81 authorize nodes in a CoAP pub-sub type of setting, using the ACE 82 framework [I-D.ietf-ace-oauth-authz]. 84 1.1. Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [RFC2119]. 90 Readers are expected to be familiar with the terms and concepts 91 described in [I-D.ietf-ace-oauth-authz], [I-D.ietf-ace-key-groupcomm] 92 and [I-D.ietf-core-coap-pubsub]. In particular, analogously to 93 [I-D.ietf-ace-oauth-authz], terminology for entities in the 94 architecture such as Client (C), Resource Server (RS), and 95 Authorization Server (AS) is defined in OAuth 2.0 [RFC6749] and 96 [I-D.ietf-ace-actors], and terminology for entities such as the Key 97 Distribution Center (KDC) and Dispatcher in 98 [I-D.ietf-ace-key-groupcomm]. 100 2. Profile Overview 102 The objective of this document is to specify how to protect a CoAP 103 pub-sub communication, as described in [I-D.ietf-core-coap-pubsub], 104 using [I-D.ietf-ace-key-groupcomm], which itself expands the Ace 105 framework ([I-D.ietf-ace-oauth-authz]), and profiles 106 ([I-D.ietf-ace-dtls-authorize], [I-D.ietf-ace-oscore-profile]). 108 The architecture of the scenario is shown in Figure 1. 110 +----------------+ +----------------+ 111 | | | | 112 | Authorization | | Authorization | 113 | Server 1 | | Server 2 | 114 | | | | 115 +----------------+ +----------------+ 116 ^ ^ ^ 117 | | | 118 +---------(A)----+ | +-----(D)------+ 119 | +--------------------(B)--------+ | 120 v v v 121 +------------+ +------------+ +------------+ 122 | CoAP | ----(C)---> | CoAP | | CoAP | 123 | Client - | ----(E)---> | Server - | | Client - | 124 | | | | <----(F)---- | | 125 | Publisher | | Broker | -----(G)---> | Subscriber | 126 +------------+ +------------+ +------------+ 128 Figure 1: Architecture CoAP pubsub with Authorization Servers 130 The RS is the broker, which contains the topic. This node 131 corresponds to the Dispatcher, in [I-D.ietf-ace-key-groupcomm]. The 132 AS1 hosts the policies about the Broker: what endpoints are allowed 133 to Publish on the Broker. The Clients access this node to get write 134 access to the Broker. The AS2 hosts the policies about the topic: 135 what endpoints are allowed to access what topic. This node 136 represents both the AS and Key Distribution Center roles from 137 [I-D.ietf-ace-key-groupcomm]. 139 There are four phases, the first three can be done in parallel. 141 1. The Publisher requests publishing access to the Broker at the 142 AS1, and communicates with the Broker to set up security. 144 2. The Publisher requests access to a specific topic at the AS2 145 3. The Subscriber requests access to a specific topic at the AS2. 147 4. The Publisher and the Subscriber securely post to and get 148 publications from the Broker. 150 This exchange aims at setting up 2 different security associations: 151 on the one hand, the Publisher has a security association with the 152 Broker, to protect the communication and securely authorize the 153 Publisher to publish on a topic (Security Association 1). On the 154 other hand, the Publisher has a security association with the 155 Subscriber, to protect the publication content itself (Security 156 Association 2). The Security Association 1 is set up using AS1 and a 157 profile of [I-D.ietf-ace-oauth-authz], the Security Association 2 is 158 set up using AS2 and [I-D.ietf-ace-key-groupcomm]. 160 Note that, analogously to the Publisher, the Subscriber can also set 161 up an additional security association with the Broker, using an AS, 162 in the same way the Publisher does with AS1. In this case, only 163 authorized Subscribers would be able to get notifications from the 164 Broker. The overhead would be that each Subscriber should access the 165 AS and get all the information to start a secure exchange with the 166 Broker. 168 +------------+ +------------+ +------------+ 169 | CoAP | | CoAP | | CoAP | 170 | Client - | | Server - | | Client - | 171 | | | | | | 172 | Publisher | | Broker | | Subscriber | 173 +------------+ +------------+ +------------+ 174 : : : : 175 : '------ Security -------' : 176 : Association 1 : 177 '------------------------------- Security --------------' 178 Association 2 180 Note that AS1 and AS2 might either be co-resident or be 2 separate 181 physical entities, in which case access control policies must be 182 exchanged between AS1 and AS2, so that they agree on rights for 183 joining nodes about specific topics. How the policies are exchanged 184 is out of scope for this profile. 186 3. coap_pubsub Profile 188 This profile uses [I-D.ietf-ace-key-groupcomm], which expands the ACE 189 framework. This document specifies which exact parameters from 190 [I-D.ietf-ace-key-groupcomm] have to be used, and the values for each 191 parameter. 193 The Publisher and the Subscriber map to the Client in 194 [I-D.ietf-ace-key-groupcomm], the AS2 maps to the AS and to the KDC, 195 the Broker maps to the Dispatcher. 197 Note that both publishers and subscribers use the same profile, 198 called "coap_pubsub". 200 3.1. Retrieval of COSE Key for protection of content 202 This phase is common to both Publisher and Subscriber. To maintain 203 the generality, the Publisher or Subscriber is referred as Client in 204 this section. 206 Client Broker AS2 207 | [----- Resource Request ---->] | | 208 | | | 209 | [<-- AS1, AS2 Information ---] | | 210 | | 211 | -- Authorization + Key Distribution Request ---> | 212 | | 213 | <-- Authorization + Key Distribution Response -- | 214 | | 216 Figure 2: B: Access request - response 218 Complementary to what is defined in [I-D.ietf-ace-oauth-authz] 219 (Section 5.1.1), to determine the AS2 in charge of a topic hosted at 220 the Broker, the Broker MAY send the address of both the AS in charge 221 of the topic back to the Client in the 'AS' parameter in the AS 222 Information, as a response to an Unauthorized Resource Request 223 (Section 5.1.2). An example using CBOR diagnostic notation is given 224 below: 226 4.01 Unauthorized 227 Content-Format: application/ace+cbor 228 {"AS": "coaps://as1.example.com/token, 229 coaps://as2.example.com/pubsubkey"} 231 Figure 3: AS1, AS2 Information example 233 After retrieving the AS2 address, the Client sends an Authorization + 234 Key Distribution Request, which is an Authorization Request merged 235 with a Key Distribution Request, as described in 236 [I-D.ietf-ace-key-groupcomm], Sections 3.1 and 4.1. The reason for 237 merging these two messages is that the AS2 is both the AS and the 238 KDC, in this setting, so the Authorization Response and the Post 239 Token message are not necessary. 241 More specifically, the Client sends a POST request to the /token 242 endpoint on AS2, that MUST contain in the payload (formatted as a 243 CBOR map): 245 o the following fields from the Authorization Request (Section 3.1 246 of [I-D.ietf-ace-key-groupcomm]): 248 * the grant type set to "client_credentials", 250 * OPTIONALLY, if needed, other additional parameters such as 251 "client_id" 253 o the following fields from the Key Distribution Request 254 (Section 4.1 of [I-D.ietf-ace-key-groupcomm]): 256 * the client_cred parameter containing the Client's public key, 257 if the Client needs to directly send that to the AS2, 259 * the scope parameter set to a CBOR array containing the broker's 260 topic as first element and the string "publisher" for 261 publishers and "subscriber" for subscribers as second element 263 * the get_pub_keys parameter set to the empty array if the Client 264 needs to retrieve the public keys of the other pubsub members 266 * OPTIONALLY, if needed, the pub_keys_repos parameter 268 Note that the alg parameter in the client_cred COSE_Key MUST be a 269 signing algorithm, as defined in section 8 of [RFC8152]. 271 Examples of the payload of a Authorization + Key Distribution Request 272 are specified in Figure 5 and Figure 8. 274 The AS2 verifies that the Client is authorized to access the topic 275 and, if the 'client_cred' parameter is present, stores the public key 276 of the Client. 278 The AS2 response is an Authorization + Key Distribution Response, see 279 Section 4.2 of [I-D.ietf-ace-key-groupcomm]. The payload (formatted 280 as a CBOR map) MUST contain: 282 o the following fields from the Authorization Response (Section 3.2 283 of [I-D.ietf-ace-key-groupcomm]): 285 * profile set to "coap_pubsub" 287 * scope parameter (optionally), set to a CBOR array containing 288 the broker's topic as first element and the string "publisher" 289 for publishers and "subscriber" for subscribers as second 290 element 292 o the following fields from the Key Distribution Response 293 (Section 4.2 of [I-D.ietf-ace-key-groupcomm]): 295 * kty parameter identifies a key type "COSE_Key", as defined in 296 Section 8.2. 298 * key parameter, which contains a "COSE_Key" object (defined in 299 [RFC8152], containing: 301 + kty with value 4 (symmetric) 303 + alg with value defined by the AS2 (Content Encryption 304 Algorithm) 306 + Base IV with value defined by the AS2 308 + k with value the symmetric key value 310 + OPTIONALLY, kid with an identifier for the key value 312 * "pub_keys", containing the public keys of all authorized 313 signing members, if the "get_pub_keys" parameter was present 314 and set to the empty array in the Authorization + Key 315 Distribution Request 317 Examples for the response payload are detailed in Figure 6 and 318 Figure 9. 320 4. Publisher 322 In this section, it is specified how the Publisher requests, obtains 323 and communicates to the Broker the access token, as well as the 324 retrieval of the keying material to protect the publication. 326 +----------------+ +----------------+ 327 | | | | 328 | Authorization | | Authorization | 329 | Server 1 | | Server 2 | 330 | | | | 331 +----------------+ +----------------+ 332 ^ ^ 333 | | 334 +---------(A)----+ | 335 | +--------------------(B)--------+ 336 v v 337 +------------+ +------------+ 338 | CoAP | ----(C)---> | CoAP | 339 | Client - | | Server - | 340 | | | | 341 | Publisher | | Broker | 342 +------------+ +------------+ 344 Figure 4: Phase 1: Publisher side 346 This is a combination of two independent phases: 348 o one is the establishment of a secure connection between Publisher 349 and Broker, using an ACE profile such as DTLS 350 [I-D.ietf-ace-dtls-authorize] or OSCORE 351 [I-D.ietf-ace-oscore-profile]. (A)(C) 353 o the other is the Publisher's retrieval of keying material to 354 protect the publication. (B) 356 In detail: 358 (A) corresponds to the Access Token Request and Response between 359 Publisher and Authorization Server to retrieve the Access Token and 360 RS (Broker) Information. As specified, the Publisher has the role of 361 a CoAP client, the Broker has the role of the CoAP server. 363 (C) corresponds to the exchange between Publisher and Broker, where 364 the Publisher sends its access token to the Broker and establishes a 365 secure connection with the Broker. Depending on the Information 366 received in (A), this can be for example DTLS handshake, or other 367 protocols. Depending on the application, there may not be the need 368 for this set up phase: for example, if OSCORE is used directly. 370 (A) and (C) details are specified in the profile used. 372 (B) corresponds to the retrieval of the keying material to protect 373 the publication, and uses [I-D.ietf-ace-key-groupcomm]. The details 374 are defined in Section 3.1. 376 An example of the payload of an Authorization + Key Distribution 377 Request and corresponding Response for a Publisher is specified in 378 Figure 5 and Figure 6. 380 { 381 "grant_type" : "client_credentials", 382 "scope" : ["Broker1/Temp", "publisher"], 383 "client_id" : "publisher1", 384 "client_cred" : 385 { / COSE_Key / 386 / type / 1 : 2, / EC2 / 387 / kid / 2 : h'11', 388 / alg / 3 : -7, / ECDSA with SHA-256 / 389 / crv / -1 : 1 , / P-256 / 390 / x / -2 : h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de1 391 08de439c08551d', 392 / y /-3 : h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e 393 9eecd0084d19c' 394 } 395 } 397 Figure 5: Authorization + Key Distribution Request payload for a 398 Publisher 400 { 401 "profile" : "coap_pubsub", 402 "kty" : "COSE_Key", 403 "key" : {1: 4, 2: h'1234', 3: 12, 5: h'1f389d14d17dc7', 404 -1: h'02e2cc3a9b92855220f255fff1c615bc'} 405 } 407 Figure 6: Authorization + Key Distribution Response payload for a 408 Publisher 410 5. Subscriber 412 In this section, it is specified how the Subscriber retrieves the 413 keying material to protect the publication. 415 +----------------+ 416 | | 417 | Authorization | 418 | Server 2 | 419 | | 420 +----------------+ 421 ^ 422 | 423 +-----(D)------+ 424 | 425 v 426 +------------+ 427 | CoAP | 428 | Client - | 429 | | 430 | Subscriber | 431 | | 432 +------------+ 434 Figure 7: Phase 2: Subscriber side 436 Step (D) between Subscriber and AS2 corresponds to the retrieval of 437 the keying material to verify the publication. The details are 438 defined in Section 3.1 440 This step is the same as (B) between Publisher and AS2 (Section 3.1), 441 with the following differences: 443 o The Authorization + Key Distribution Request MUST NOT contain the 444 client_cred parameter, the role element in the 'scope' parameter 445 MUST be set to "subscriber". The Subscriber MUST have access to 446 the public keys of all the Publishers; this MAY be achieved in the 447 Authorization + Key Distribution Request by using the parameter 448 get_pub_keys set to empty array. 450 o The Authorization + Key Distribution Response MUST contain the 451 pub_keys parameter. 453 An example of the payload of an Authorization + Key Distribution 454 Request and corresponding Response for a Subscriber is specified in 455 Figure 8 and Figure 9. 457 { 458 "grant_type" : "client_credentials", 459 "scope" : ["Broker1/Temp", "subscriber"], 460 "get_pub_keys" : [ ] 461 } 463 Figure 8: Authorization + Key Distribution Request payload for a 464 Subscriber 466 { 467 "profile" : "coap_pubsub", 468 "scope" : ["Broker1/Temp", "subscriber"], 469 "kty" : "COSE_Key" 470 "key" : {1: 4, 2: h'1234', 3: 12, 5: h'1f389d14d17dc7', 471 -1: h'02e2cc3a9b92855220f255fff1c615bc'}, 472 "pub_keys" : [ 473 { 474 1 : 2, / type EC2 / 475 2 : h'11', / kid / 476 3 : -7, / alg ECDSA with SHA-256 / 477 -1 : 1 , / crv P-256 / 478 -2 : h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de43 479 9c08551d', / x / 480 -3 : h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd 481 0084d19c' / y / 482 } 483 ] 484 } 486 Figure 9: Authorization + Key Distribution Response payload for a 487 Subscriber 489 6. Pub-Sub Protected Communication 491 This section specifies the communication Publisher-Broker and 492 Subscriber-Broker, after the previous phases have taken place. 494 +------------+ +------------+ +------------+ 495 | CoAP | | CoAP | | CoAP | 496 | Client - | | Server - | | Client - | 497 | | ----(E)---> | | | | 498 | Publisher | | Broker | <----(F)---- | Subscriber | 499 | | | | -----(G)---> | | 500 +------------+ +------------+ +------------+ 502 Figure 10: Phase 3: Secure communication between Publisher and 503 Subscriber 505 The (E) message corresponds to the publication of a topic on the 506 Broker. The publication (the resource representation) is protected 507 with COSE ([RFC8152]). The (F) message is the subscription of the 508 Subscriber, which is unprotected. The (G) message is the response 509 from the Broker, where the publication is protected with COSE. 511 The flow graph is presented below. 513 Publisher Broker Subscriber 514 | --- PUT /topic ----> | | 515 | protected with COSE | | 516 | | <--- GET /topic ----- | 517 | | | 518 | | ---- response ------> | 519 | | protected with COSE | 521 Figure 11: (E), (F), (G): Example of protected communication 523 6.1. Using COSE Objects to protect the resource representation 525 The Publisher uses the symmetric COSE Key received from AS2 in 526 exchange B (Section 3.1) to protect the payload of the PUBLISH 527 operation (Section 4.3 of [I-D.ietf-core-coap-pubsub]). 528 Specifically, the COSE Key is used to create a COSE_Encrypt0 with 529 algorithm specified by AS2. The Publisher uses the private key 530 corresponding to the public key sent to the AS2 in exchange B 531 (Section 3.1) to countersign the COSE Object as specified in 532 Section 4.5 of [RFC8152]. The CoAP payload is replaced by the COSE 533 object before the publication is sent to the Broker. 535 The Subscriber uses the kid in the countersignature field in the COSE 536 object to retrieve the right public key to verify the 537 countersignature. It then uses the symmetric key received from AS2 538 to verify and decrypt the publication received in the payload of the 539 CoAP Notification from the Broker. 541 The COSE object is constructed in the following way: 543 o The protected Headers (as described in Section 3 of [RFC8152]) MAY 544 contain the kid parameter, with value the kid of the symmetric 545 COSE Key received in Section 3.1 and MUST contain the content 546 encryption algorithm 548 o The unprotected Headers MUST contain the Partial IV and the 549 counter signature that includes: 551 * the algorithm (same value as in the asymmetric COSE Key 552 received in (B)) in the protected header 554 * the kid (same value as the kid of the asymmetric COSE Key 555 received in (B)) in the unprotected header 557 * the signature computed as specified in Section 4.5 of [RFC8152] 559 o The ciphertext, computed over the plaintext that MUST contain the 560 CoAP payload. 562 The external_aad is an empty string. 564 An example is given in Figure 12 566 16( 567 [ 568 / protected / h'a2010c04421234' / { 569 \ alg \ 1:12, \ AES-CCM-64-64-128 \ 570 \ kid \ 4: h'1234' 571 } / , 572 / unprotected / { 573 / iv / 5:h'89f52f65a1c580', 574 / countersign / 7:[ 575 / protected / h'a10126' / { 576 \ alg \ 1:-7 577 } / , 578 / unprotected / { 579 / kid / 4:h'11' 580 }, 581 / signature / SIG / 64 bytes signature / 582 ] 583 }, 584 / ciphertext / h'8df0a3b62fccff37aa313c8020e971f8aC8d' 585 ] 586 ) 588 Figure 12: Example of COSE Object sent in the payload of a PUBLISH 589 operation 591 The encryption and decryption operations are described in sections 592 5.3 and 5.4 of [RFC8152]. 594 7. Security Considerations 596 In the profile described above, the Publisher and Subscriber use 597 asymmetric crypto, which would make the message exchange quite heavy 598 for small constrained devices. Moreover, all Subscribers must be 599 able to access the public keys of all the Publishers to a specific 600 topic to be able to verify the publications. Such a database could 601 be set up and managed by the same entity having control of the topic, 602 i.e. AS2. 604 An application where it is not critical that only authorized 605 Publishers can publish on a topic may decide not to make use of the 606 asymmetric crypto and only use symmetric encryption/MAC to 607 confidentiality and integrity protect the publication, but this is 608 not recommended since, as a result, any authorized Subscribers with 609 access to the Broker may forge unauthorized publications without 610 being detected. In this symmetric case the Subscribers would only 611 need one symmetric key per topic, and would not need to know any 612 information about the Publishers, that can be anonymous to it and the 613 Broker. 615 Subscribers can be excluded from future publications through re- 616 keying for a certain topic. This could be set up to happen on a 617 regular basis, for certain applications. How this could be done is 618 out of scope for this work. 620 The Broker is only trusted with verifying that the Publisher is 621 authorized to publish, but is not trusted with the publications 622 itself, which it cannot read nor modify. In this setting, caching of 623 publications on the Broker is still allowed. 625 TODO: expand on security and privacy considerations 627 8. IANA Considerations 629 8.1. ACE OAuth Profile Registry 631 The following registrations are done for the ACE OAuth Profile 632 Registry following the procedure specified in 633 [I-D.ietf-ace-oauth-authz]. 635 Note to RFC Editor: Please replace all occurrences of "[[This 636 document]]" with the RFC number of this specification and delete this 637 paragraph. 639 Name: coap_pubsub 641 Description: Profile for delegating client authentication and 642 authorization for publishers and subscribers in a pub-sub setting 643 scenario in a constrained environment. 645 CBOR Key: TBD 647 Reference: [[This document]] 649 8.2. ACE Groupcomm Key Registry 651 The following registrations are done for the ACE Groupcomm Key 652 Registry following the procedure specified in 653 [I-D.ietf-ace-key-groupcomm]. 655 Note to RFC Editor: Please replace all occurrences of "[[This 656 document]]" with the RFC number of this specification and delete this 657 paragraph. 659 Name: COSE_Key 661 Key Type Value: TBD 663 Profile: 665 Description: COSE_Key object 667 References: [RFC8152] 669 9. References 671 9.1. Normative References 673 [I-D.ietf-ace-key-groupcomm] 674 Palombini, F. and M. Tiloca, "Key Provisioning for Group 675 Communication using ACE", draft-ietf-ace-key-groupcomm-01 676 (work in progress), March 2019. 678 [I-D.ietf-ace-oauth-authz] 679 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 680 H. Tschofenig, "Authentication and Authorization for 681 Constrained Environments (ACE) using the OAuth 2.0 682 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24 683 (work in progress), March 2019. 685 [I-D.ietf-core-coap-pubsub] 686 Koster, M., Keranen, A., and J. Jimenez, "Publish- 687 Subscribe Broker for the Constrained Application Protocol 688 (CoAP)", draft-ietf-core-coap-pubsub-08 (work in 689 progress), March 2019. 691 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 692 Requirement Levels", BCP 14, RFC 2119, 693 DOI 10.17487/RFC2119, March 1997, 694 . 696 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 697 RFC 6749, DOI 10.17487/RFC6749, October 2012, 698 . 700 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 701 RFC 8152, DOI 10.17487/RFC8152, July 2017, 702 . 704 9.2. Informative References 706 [I-D.ietf-ace-actors] 707 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 708 architecture for authorization in constrained 709 environments", draft-ietf-ace-actors-07 (work in 710 progress), October 2018. 712 [I-D.ietf-ace-dtls-authorize] 713 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 714 L. Seitz, "Datagram Transport Layer Security (DTLS) 715 Profile for Authentication and Authorization for 716 Constrained Environments (ACE)", draft-ietf-ace-dtls- 717 authorize-07 (work in progress), March 2019. 719 [I-D.ietf-ace-oscore-profile] 720 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 721 "OSCORE profile of the Authentication and Authorization 722 for Constrained Environments Framework", draft-ietf-ace- 723 oscore-profile-07 (work in progress), February 2019. 725 Acknowledgments 727 The author wishes to thank Ari Keraenen, John Mattsson, Ludwig Seitz, 728 Goeran Selander, Jim Schaad and Marco Tiloca for the useful 729 discussion and reviews that helped shape this document. 731 Author's Address 733 Francesca Palombini 734 Ericsson 736 Email: francesca.palombini@ericsson.com