idnits 2.17.1 draft-palombini-ace-coap-pubsub-profile-06.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 (November 04, 2019) is 1628 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-03 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-25 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 ** 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-08 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 November 04, 2019 5 Expires: May 7, 2020 7 CoAP Pub-Sub Profile for Authentication and Authorization for 8 Constrained Environments (ACE) 9 draft-palombini-ace-coap-pubsub-profile-06 11 Abstract 13 This specification defines an application profile for authentication 14 and authorization for publishers and subscribers in a pub-sub setting 15 scenario in a constrained environment, using the ACE framework. This 16 profile relies on transport layer or application layer security to 17 authorize the publisher to the broker. Moreover, it relies on 18 application layer security for publisher-broker and subscriber-broker 19 communication. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 7, 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. Application Profile Overview . . . . . . . . . . . . . . . . 3 58 3. coap_pubsub_app Application 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 . . . . . . . . . . . . . . . . . . . 14 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 66 8.1. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 15 67 8.2. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 16 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 70 9.2. Informative References . . . . . . . . . . . . . . . . . 17 71 Appendix A. Requirements on Application Profiles . . . . . . . . 17 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. Application 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 transport 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 transport profile of [I-D.ietf-ace-oauth-authz], the Security 162 Association 2 is 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 specification. 190 3. coap_pubsub_app Application 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). The uri of AS2 is concatenated to the uri of AS1, 232 and separated by a comma. An example using CBOR diagnostic notation 233 is given below: 235 4.01 Unauthorized 236 Content-Format: application/ace+cbor 237 {"AS": "coaps://as1.example.com/token, 238 coaps://as2.example.com/pubsubkey"} 240 Figure 3: AS1, AS2 Information example 242 After retrieving the AS2 address, the Client MAY send a request to 243 the AS, in order to retrieve necessary information concerning the 244 public keys in the group, as well as concerning the algorithm and 245 related parameters for computing signatures in the group. This 246 request is a subset of the Token POST request defined in Section 3.3 247 of [I-D.ietf-ace-key-groupcomm], specifically a CoAP POST request to 248 a specific resource at the AS, including only the parameters 249 'sign_info' and 'pub_key_enc' in the CBOR map in the payload. The 250 default url-path for this resource is /ace-group/gid/cs-info, where 251 "gid" is the topic identifier, but implementations are not required 252 to use this name, and can use their own instead. The AS MUST respond 253 with the response defined in Section 3.3 of 254 [I-D.ietf-ace-key-groupcomm], specifically including the parameters 255 'sign_info', 'pub_key_enc', and 'rsnonce' (8 bytes pseudo-random 256 nonce generated by the AS). 258 After that, the Client sends an Authorization + Joining Request, 259 which is an Authorization Request merged with a Joining Request, as 260 described in [I-D.ietf-ace-key-groupcomm], Sections 3.1 and 4.2. The 261 reason for merging these two messages is that the AS2 is both the AS 262 and the KDC, in this setting, so the Authorization Response and the 263 Post Token message are not necessary. 265 More specifically, the Client sends a POST request to the /ace-group/ 266 gid endpoint on AS2, with Content-Format = "application/ace+cbor" 267 that MUST contain in the payload (formatted as a CBOR map): 269 o the following fields from the Joining Request (Section 4.2 of 270 [I-D.ietf-ace-key-groupcomm]): 272 * 'scope' parameter set to a CBOR array containing: 274 + the broker's topic as first element, and 276 + the text string "publisher" if the client request to be a 277 publisher, "subscriber" if the client request to be a 278 subscriber, or a CBOR array containing both, if the client 279 request to be both. 281 * 'get_pub_keys' parameter set to the empty array if the Client 282 needs to retrieve the public keys of the other pubsub members, 284 * 'client_cred' parameter containing the Client's public key 285 formatted as a COSE_Key, if the Client needs to directly send 286 that to the AS2, 288 * 'cnonce', set to a 8 bytes long pseudo-random nonce, if 289 'client_cred' is present, 291 * 'client_cred_verify', set to a singature computed over the 292 rsnonce concatenated with cnonce, if 'client_cred' is present, 294 * OPTIONALLY, if needed, the 'pub_keys_repos' parameter 296 o the following fields from the Authorization Request (Section 3.1 297 of [I-D.ietf-ace-key-groupcomm]): 299 * OPTIONALLY, if needed, additional parameters such as 300 'client_id' 302 Note that the alg parameter in the 'client_cred' COSE_Key MUST be a 303 signing algorithm, as defined in section 8 of [RFC8152], and that it 304 is the same algorithm used to compute the signature sent in 305 'client_cred_verify'. 307 Examples of the payload of a Authorization + Joining Request are 308 specified in Figure 5 and Figure 8. 310 The AS2 verifies that the Client is authorized to access the topic 311 and, if the 'client_cred' parameter is present, stores the public key 312 of the Client. 314 The AS2 response is an Authorization + Joining Response, with 315 Content-Format = "application/ace+cbor". The payload (formatted as a 316 CBOR map) MUST contain: 318 o the following fields from the Joining Response (Section 4.1 of 319 [I-D.ietf-ace-key-groupcomm]): 321 * 'kty' identifies a key type "COSE_Key", as defined in 322 Section 8.2. 324 * 'key', which contains a "COSE_Key" object (defined in 325 [RFC8152], containing: 327 + 'kty' with value 4 (symmetric) 329 + 'alg' with value defined by the AS2 (Content Encryption 330 Algorithm) 332 + 'Base IV' with value defined by the AS2 334 + 'k' with value the symmetric key value 336 + OPTIONALLY, 'kid' with an identifier for the key value 338 * OPTIONALLY, 'exp' with the expiration time of the key 340 * 'pub_keys', containing the public keys of all authorized 341 signing members formatted as COSE_Keys, if the 'get_pub_keys' 342 parameter was present and set to the empty array in the 343 Authorization + Key Distribution Request 345 o the following fields from the Authorization Response (Section 3.2 346 of [I-D.ietf-ace-key-groupcomm]): 348 * 'profile' set to "coap_pubsub_app", as specified in Section 8.1 350 * OPTIONALLY 'scope', set to a CBOR array containing: 352 + the broker's topic as first element, and 354 + the string "publisher" if the client is an authorized 355 publisher, "subscriber" if the client is an authorized 356 subscriber, or a CBOR array containing both, if the client 357 is authorized to be both. 359 Examples for the response payload are detailed in Figure 6 and 360 Figure 9. 362 4. Publisher 364 In this section, it is specified how the Publisher requests, obtains 365 and communicates to the Broker the access token, as well as the 366 retrieval of the keying material to protect the publication. 368 +----------------+ +----------------+ 369 | | | | 370 | Authorization | | Authorization | 371 | Server 1 | | Server 2 | 372 | | | | 373 +----------------+ +----------------+ 374 ^ ^ 375 | | 376 +---------(A)----+ | 377 | +--------------------(B)--------+ 378 v v 379 +------------+ +------------+ 380 | CoAP | ----(C)---> | CoAP | 381 | Client - | | Server - | 382 | | | | 383 | Publisher | | Broker | 384 +------------+ +------------+ 386 Figure 4: Phase 1: Publisher side 388 This is a combination of two independent phases: 390 o one is the establishment of a secure connection between Publisher 391 and Broker, using an ACE transport profile such as DTLS 392 [I-D.ietf-ace-dtls-authorize] or OSCORE 393 [I-D.ietf-ace-oscore-profile]. (A)(C) 395 o the other is the Publisher's retrieval of keying material to 396 protect the publication. (B) 398 In detail: 400 (A) corresponds to the Access Token Request and Response between 401 Publisher and Authorization Server to retrieve the Access Token and 402 RS (Broker) Information. As specified, the Publisher has the role of 403 a CoAP client, the Broker has the role of the CoAP server. 405 (C) corresponds to the exchange between Publisher and Broker, where 406 the Publisher sends its access token to the Broker and establishes a 407 secure connection with the Broker. Depending on the Information 408 received in (A), this can be for example DTLS handshake, or other 409 protocols. Depending on the application, there may not be the need 410 for this set up phase: for example, if OSCORE is used directly. 412 (A) and (C) details are specified in the profile used. 414 (B) corresponds to the retrieval of the keying material to protect 415 the publication end-to-end with the subscribers (see Section 6.1), 416 and uses [I-D.ietf-ace-key-groupcomm]. The details are defined in 417 Section 3.1. 419 An example of the payload of an Authorization + Joining Request and 420 corresponding Response for a Publisher is specified in Figure 5 and 421 Figure 6, where SIG is a signature computed using the private key 422 associated to the public key and the algorithm in "client_cred". 424 { 425 "scope" : ["Broker1/Temp", "publisher"], 426 "client_id" : "publisher1", 427 "client_cred" : 428 { / COSE_Key / 429 / type / 1 : 2, / EC2 / 430 / kid / 2 : h'11', 431 / alg / 3 : -7, / ECDSA with SHA-256 / 432 / crv / -1 : 1 , / P-256 / 433 / x / -2 : h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de1 434 08de439c08551d', 435 / y /-3 : h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e 436 9eecd0084d19c', 437 "cnonce" : h'd36b581d1eef9c7c, 438 "client_cred_verify" : SIG 439 } 440 } 442 Figure 5: Authorization + Joining Request payload for a Publisher 444 { 445 "profile" : "coap_pubsub_app", 446 "kty" : "COSE_Key", 447 "key" : {1: 4, 2: h'1234', 3: 12, 5: h'1f389d14d17dc7', 448 -1: h'02e2cc3a9b92855220f255fff1c615bc'} 449 } 451 Figure 6: Authorization + Joining Response payload for a Publisher 453 5. Subscriber 455 In this section, it is specified how the Subscriber retrieves the 456 keying material to protect the publication. 458 +----------------+ 459 | | 460 | Authorization | 461 | Server 2 | 462 | | 463 +----------------+ 464 ^ 465 | 466 +-----(D)------+ 467 | 468 v 469 +------------+ 470 | CoAP | 471 | Client - | 472 | | 473 | Subscriber | 474 | | 475 +------------+ 477 Figure 7: Phase 2: Subscriber side 479 Step (D) between Subscriber and AS2 corresponds to the retrieval of 480 the keying material to verify the publication end-to-end with the 481 publishers (see Section 6.1). The details are defined in Section 3.1 483 This step is the same as (B) between Publisher and AS2 (Section 3.1), 484 with the following differences: 486 o The Authorization + Joining Request MUST NOT contain the 487 'client_cred parameter', the role element in the 'scope' parameter 488 MUST be set to "subscriber". The Subscriber MUST have access to 489 the public keys of all the Publishers; this MAY be achieved in the 490 Authorization + Joining Request by using the parameter 491 'get_pub_keys' set to empty array. 493 o The Authorization + Key Distribution Response MUST contain the 494 'pub_keys' parameter. 496 An example of the payload of an Authorization + Joining Request and 497 corresponding Response for a Subscriber is specified in Figure 8 and 498 Figure 9. 500 { 501 "scope" : ["Broker1/Temp", "subscriber"], 502 "get_pub_keys" : [ ] 503 } 505 Figure 8: Authorization + Joining Request payload for a Subscriber 507 { 508 "profile" : "coap_pubsub_app", 509 "scope" : ["Broker1/Temp", "subscriber"], 510 "kty" : "COSE_Key" 511 "key" : {1: 4, 2: h'1234', 3: 12, 5: h'1f389d14d17dc7', 512 -1: h'02e2cc3a9b92855220f255fff1c615bc'}, 513 "pub_keys" : [ 514 { 515 1 : 2, / type EC2 / 516 2 : h'11', / kid / 517 3 : -7, / alg ECDSA with SHA-256 / 518 -1 : 1 , / crv P-256 / 519 -2 : h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de43 520 9c08551d', / x / 521 -3 : h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd 522 0084d19c' / y / 523 } 524 ] 525 } 527 Figure 9: Authorization + Joining Response payload for a Subscriber 529 6. Pub-Sub Protected Communication 531 This section specifies the communication Publisher-Broker and 532 Subscriber-Broker, after the previous phases have taken place. The 533 operations of publishing and subscribing are defined in 534 [I-D.ietf-core-coap-pubsub]. 536 +------------+ +------------+ +------------+ 537 | CoAP | | CoAP | | CoAP | 538 | Client - | | Server - | | Client - | 539 | | ----(E)---> | | | | 540 | Publisher | | Broker | <----(F)---- | Subscriber | 541 | | | | -----(G)---> | | 542 +------------+ +------------+ +------------+ 544 Figure 10: Phase 3: Secure communication between Publisher and 545 Subscriber 547 The (E) message corresponds to the publication of a topic on the 548 Broker. The publication (the resource representation) is protected 549 with COSE ([RFC8152]). The (F) message is the subscription of the 550 Subscriber, which is unprotected, unless a profile of ACE 551 [I-D.ietf-ace-oauth-authz] is used between Subscriber and Broker. 552 The (G) message is the response from the Broker, where the 553 publication is protected with COSE. 555 The flow graph is presented below. 557 Publisher Broker Subscriber 558 | --- PUT /topic ----> | | 559 | protected with COSE | | 560 | | <--- GET /topic ----- | 561 | | | 562 | | ---- response ------> | 563 | | protected with COSE | 565 Figure 11: (E), (F), (G): Example of protected communication 567 6.1. Using COSE Objects To Protect The Resource Representation 569 The Publisher uses the symmetric COSE Key received from AS2 in 570 exchange B (Section 3.1) to protect the payload of the PUBLISH 571 operation (Section 4.3 of [I-D.ietf-core-coap-pubsub]). 572 Specifically, the COSE Key is used to create a COSE_Encrypt0 with 573 algorithm specified by AS2. The Publisher uses the private key 574 corresponding to the public key sent to the AS2 in exchange B 575 (Section 3.1) to countersign the COSE Object as specified in 576 Section 4.5 of [RFC8152]. The CoAP payload is replaced by the COSE 577 object before the publication is sent to the Broker. 579 The Subscriber uses the kid in the countersignature field in the COSE 580 object to retrieve the right public key to verify the 581 countersignature. It then uses the symmetric key received from AS2 582 to verify and decrypt the publication received in the payload of the 583 CoAP Notification from the Broker. 585 The COSE object is constructed in the following way: 587 o The protected Headers (as described in Section 3 of [RFC8152]) MAY 588 contain the kid parameter, with value the kid of the symmetric 589 COSE Key received in Section 3.1 and MUST contain the content 590 encryption algorithm. 592 o The unprotected Headers MUST contain the Partial IV, with value a 593 sequence number that is incremented for every message sent, and 594 the counter signature that includes: 596 * the algorithm (same value as in the asymmetric COSE Key 597 received in (B)) in the protected header; 599 * the kid (same value as the kid of the asymmetric COSE Key 600 received in (B)) in the unprotected header; 602 * the signature computed as specified in Section 4.5 of 603 [RFC8152]. 605 o The ciphertext, computed over the plaintext that MUST contain the 606 CoAP payload. 608 The external_aad is an empty string. 610 An example is given in Figure 12 612 16( 613 [ 614 / protected / h'a2010c04421234' / { 615 \ alg \ 1:12, \ AES-CCM-64-64-128 \ 616 \ kid \ 4: h'1234' 617 } / , 618 / unprotected / { 619 / iv / 5:h'89f52f65a1c580', 620 / countersign / 7:[ 621 / protected / h'a10126' / { 622 \ alg \ 1:-7 623 } / , 624 / unprotected / { 625 / kid / 4:h'11' 626 }, 627 / signature / SIG / 64 bytes signature / 628 ] 629 }, 630 / ciphertext / h'8df0a3b62fccff37aa313c8020e971f8aC8d' 631 ] 632 ) 634 Figure 12: Example of COSE Object sent in the payload of a PUBLISH 635 operation 637 The encryption and decryption operations are described in sections 638 5.3 and 5.4 of [RFC8152]. 640 7. Security Considerations 642 In the profile described above, the Publisher and Subscriber use 643 asymmetric crypto, which would make the message exchange quite heavy 644 for small constrained devices. Moreover, all Subscribers must be 645 able to access the public keys of all the Publishers to a specific 646 topic to be able to verify the publications. Such a database could 647 be set up and managed by the same entity having control of the topic, 648 i.e. AS2. 650 An application where it is not critical that only authorized 651 Publishers can publish on a topic may decide not to make use of the 652 asymmetric crypto and only use symmetric encryption/MAC to 653 confidentiality and integrity protect the publication, but this is 654 not recommended since, as a result, any authorized Subscribers with 655 access to the Broker may forge unauthorized publications without 656 being detected. In this symmetric case the Subscribers would only 657 need one symmetric key per topic, and would not need to know any 658 information about the Publishers, that can be anonymous to it and the 659 Broker. 661 Subscribers can be excluded from future publications through re- 662 keying for a certain topic. This could be set up to happen on a 663 regular basis, for certain applications. How this could be done is 664 out of scope for this work. 666 The Broker is only trusted with verifying that the Publisher is 667 authorized to publish, but is not trusted with the publications 668 itself, which it cannot read nor modify. In this setting, caching of 669 publications on the Broker is still allowed. 671 TODO: expand on security and privacy considerations 673 8. IANA Considerations 675 8.1. ACE Groupcomm Profile Registry 677 The following registrations are done for the "ACE Groupcomm Profile" 678 Registry following the procedure specified in 679 [I-D.ietf-ace-key-groupcomm]. 681 Note to RFC Editor: Please replace all occurrences of "[[This 682 document]]" with the RFC number of this specification and delete this 683 paragraph. 685 Name: coap_pubsub_app 687 Description: Profile for delegating client authentication and 688 authorization for publishers and subscribers in a pub-sub setting 689 scenario in a constrained environment. 691 CBOR Key: TBD 693 Reference: [[This document]] 695 8.2. ACE Groupcomm Key Registry 697 The following registrations are done for the ACE Groupcomm Key 698 Registry following the procedure specified in 699 [I-D.ietf-ace-key-groupcomm]. 701 Note to RFC Editor: Please replace all occurrences of "[[This 702 document]]" with the RFC number of this specification and delete this 703 paragraph. 705 Name: COSE_Key 707 Key Type Value: TBD 709 Profile: coap_pubsub_app 711 Description: COSE_Key object 713 References: [RFC8152], [[This document]] 715 9. References 717 9.1. Normative References 719 [I-D.ietf-ace-key-groupcomm] 720 Palombini, F. and M. Tiloca, "Key Provisioning for Group 721 Communication using ACE", draft-ietf-ace-key-groupcomm-03 722 (work in progress), November 2019. 724 [I-D.ietf-ace-oauth-authz] 725 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 726 H. Tschofenig, "Authentication and Authorization for 727 Constrained Environments (ACE) using the OAuth 2.0 728 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-25 729 (work in progress), October 2019. 731 [I-D.ietf-core-coap-pubsub] 732 Koster, M., Keranen, A., and J. Jimenez, "Publish- 733 Subscribe Broker for the Constrained Application Protocol 734 (CoAP)", draft-ietf-core-coap-pubsub-09 (work in 735 progress), September 2019. 737 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 738 Requirement Levels", BCP 14, RFC 2119, 739 DOI 10.17487/RFC2119, March 1997, 740 . 742 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 743 RFC 6749, DOI 10.17487/RFC6749, October 2012, 744 . 746 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 747 RFC 8152, DOI 10.17487/RFC8152, July 2017, 748 . 750 9.2. Informative References 752 [I-D.ietf-ace-actors] 753 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 754 architecture for authorization in constrained 755 environments", draft-ietf-ace-actors-07 (work in 756 progress), October 2018. 758 [I-D.ietf-ace-dtls-authorize] 759 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 760 L. Seitz, "Datagram Transport Layer Security (DTLS) 761 Profile for Authentication and Authorization for 762 Constrained Environments (ACE)", draft-ietf-ace-dtls- 763 authorize-08 (work in progress), April 2019. 765 [I-D.ietf-ace-oscore-profile] 766 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 767 "OSCORE profile of the Authentication and Authorization 768 for Constrained Environments Framework", draft-ietf-ace- 769 oscore-profile-08 (work in progress), July 2019. 771 Appendix A. Requirements on Application Profiles 773 This section lists the specifications on this profile based on the 774 requirements defined in Appendix A of [I-D.ietf-ace-key-groupcomm] 776 o REQ1: Specify the encoding and value of the identifier of group or 777 topic of 'scope': see Section 3.1). 779 o REQ2: Specify the encoding and value of roles of 'scope': see 780 Section 3.1). 782 o REQ3: Optionally, specify the acceptable values for 'sign_alg': 783 TODO 785 o REQ4: Optionally, specify the acceptable values for 786 'sign_parameters': TODO 788 o REQ5: Optionally, specify the acceptable values for 789 'sign_key_parameters': TODO 791 o REQ6: Optionally, specify the acceptable values for 'pub_key_enc': 792 TODO 794 o REQ7: Specify the exact format of the 'key' value: COSE_Key, see 795 Section 3.1. 797 o REQ8: Specify the acceptable values of 'kty' : "COSE_Key", see 798 Section 3.1. 800 o REQ9: Specity the format of the identifiers of group members: TODO 802 o REQ10: Optionally, specify the format and content of 803 'group_policies' entries: not defined 805 o REQ11: Specify the communication protocol the members of the group 806 must use: CoAP pub/sub. 808 o REQ12: Specify the security protocol the group members must use to 809 protect their communication. This must provide encryption, 810 integrity and replay protection: Object Security of Content using 811 COSE, see Section 6.1. 813 o REQ13: Specify and register the application profile identifier : 814 "coap_pubsub_app", see Section 8.1. 816 o REQ14: Optionally, specify the encoding of public keys, of 817 'client_cred', and of 'pub_keys' if COSE_Keys are not used: NA. 819 o REQ15: Specify policies at the KDC to handle id that are not 820 included in get_pub_keys: TODO 822 o REQ16: Specify the format and content of 'group_policies': TODO 824 o REQ17: Specify the format of newly-generated individual keying 825 material for group members, or of the information to derive it, 826 and corresponding CBOR label : not defined 828 o REQ18: Specify how the communication is secured between Client and 829 KDC. Optionally, specify tranport profile of ACE 830 [I-D.ietf-ace-oauth-authz] to use between Client and KDC: pre-set, 831 as KDC is AS. 833 o OPT1: Optionally, specify the encoding of public keys, of 834 'client_cred', and of 'pub_keys' if COSE_Keys are not used: NA 836 o OPT2: Optionally, specify the negotiation of parameter values for 837 signature algorithm and signature keys, if 'sign_info' and 838 'pub_key_enc' are not used: NA 840 o OPT3: Optionally, specify the format and content of 841 'mgt_key_material': not defined 843 o OPT4: Optionally, specify policies that instruct clients to retain 844 unsuccessfully decrypted messages and for how long, so that they 845 can be decrypted after getting updated keying material: not 846 defined 848 Acknowledgments 850 The author wishes to thank Ari Keraenen, John Mattsson, Ludwig Seitz, 851 Goeran Selander, Jim Schaad and Marco Tiloca for the useful 852 discussion and reviews that helped shape this document. 854 Author's Address 856 Francesca Palombini 857 Ericsson 859 Email: francesca.palombini@ericsson.com