idnits 2.17.1 draft-ietf-ace-key-groupcomm-00.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 (December 20, 2018) is 1953 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 (-46) exists of draft-ietf-ace-oauth-authz-17 == Outdated reference: A later version (-16) exists of draft-ietf-ace-oauth-params-01 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-05 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-05 Summary: 1 error (**), 0 flaws (~~), 5 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 AB 4 Intended status: Standards Track M. Tiloca 5 Expires: June 23, 2019 RISE AB 6 December 20, 2018 8 Key Provisioning for Group Communication using ACE 9 draft-ietf-ace-key-groupcomm-00 11 Abstract 13 This document defines message formats and procedures for requesting 14 and distributing group keying material using the ACE framework, to 15 protect communications between group members. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 23, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Authorization to Join a Group . . . . . . . . . . . . . . . . 5 55 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 6 56 3.2. Authorization Response . . . . . . . . . . . . . . . . . 7 57 3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 8 58 4. Key Distribution . . . . . . . . . . . . . . . . . . . . . . 8 59 4.1. Key Distribution Request . . . . . . . . . . . . . . . . 9 60 4.2. Key Distribution Response . . . . . . . . . . . . . . . . 10 61 5. Removal of a Node from the Group . . . . . . . . . . . . . . 12 62 5.1. Expired Authorization . . . . . . . . . . . . . . . . . . 12 63 5.2. Request to Leave the Group . . . . . . . . . . . . . . . 12 64 6. Retrieval of Updated Keying Material . . . . . . . . . . . . 13 65 6.1. Key Re-Distribution Request . . . . . . . . . . . . . . . 13 66 6.2. Key Re-Distribution Response . . . . . . . . . . . . . . 13 67 7. Retrieval of Public Keys for Group Members . . . . . . . . . 13 68 7.1. Public Key Request . . . . . . . . . . . . . . . . . . . 14 69 7.2. Public Key Response . . . . . . . . . . . . . . . . . . . 14 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 74 10.2. Informative References . . . . . . . . . . . . . . . . . 16 75 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 78 1. Introduction 80 This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to 81 define the format of messages used to request, distribute and renew 82 the keying material in a group communication scenario, e.g. based on 83 multicast [RFC7390] or on publishing-subscribing 84 [I-D.ietf-core-coap-pubsub]. 86 Profiles that use group communication can build on this document to 87 specify the selection of the message parameters defined in this 88 document to use and their values. Known applications that can 89 benefit from this document would be, for example, profiles addressing 90 group communication based on multicast [RFC7390] or publishing/ 91 subscribing [I-D.ietf-core-coap-pubsub] in ACE. 93 If the application requires backward and forward security, updated 94 keying material is generated and distributed to the group members 95 (rekeying), when membership changes. A key management scheme 96 performs the actual distribution of the updated keying material to 97 the group. In particular, the key management scheme rekeys the 98 current group members when a new node joins the group, and the 99 remaining group members when a node leaves the group. This document 100 provides a message format for group rekeying that allows to fulfill 101 these requirements. Rekeying mechanisms can be based on [RFC2093], 102 [RFC2094] and [RFC2627]. 104 1.1. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. These 109 words may also appear in this document in lowercase, absent their 110 normative meanings. 112 Readers are expected to be familiar with the terms and concepts 113 described in [I-D.ietf-ace-oauth-authz] and [RFC8152], such as 114 Authorization Server (AS) and Resource Server (RS). 116 2. Overview 118 +------------+ +-----------+ 119 | AS | | KDC | 120 | | .-------->| | 121 +------------+ / +-----------+ 122 ^ / 123 | / 124 v / +-----------+ 125 +------------+ / +------------+ |+-----------+ 126 | Client |<-' | Dispatcher | ||+-----------+ 127 | |<-------->| (RS) |<------->|| Group | 128 +------------+ +------------+ +| members | 129 +-----------+ 131 Figure 1: Key Distribution Participants 133 The following participants (see Figure 1) take part in the 134 authorization and key distribution. 136 o Client (C): node that wants to join the group communication. It 137 can request write and/or read rights. 139 o Authorization Server (AS): same as AS in the ACE Framework; it 140 enforces access policies, and knows if a node is allowed to join 141 the group with write and/or read rights. 143 o Key Distribution Center (KDC): maintains the keying material to 144 protect group communications, and provides it to Clients 145 authorized to join the group. During the first part of the 146 exchange (Section 3), it takes the role of the RS in the ACE 147 Framework. During the second part (Section 4), which is not based 148 on the ACE Framework, it distributes the keying material. In 149 addition, it provides the latest keying material to group members 150 when requested. If required by the application, the KDC renews 151 and re-distributes the keying material in the group when 152 membership changes. 154 o Dispatcher: entity through which the Clients communicate with the 155 group and which distributes messages to the group members. 156 Examples of dispatchers are: the Broker node in a pub-sub setting; 157 a relayer node for group communication that delivers group 158 messages as multiple unicast messages to all group members; an 159 implicit entity as in a multicast communication setting, where 160 messages are transmitted to a multicast IP address and delivered 161 on the transport channel. 163 This document specifies the message flows and formats for: 165 o Authorizing a new node to join the group (Section 3), and 166 providing it with the group keying material to communicate with 167 the other group members (Section 4). 169 o Removing of a current member from the group (Section 5). 171 o Retrieving keying material as a current group member (Section 6 172 and Section 7). 174 o Renewing and re-distributing the group keying material (rekeying) 175 upon a membership change in the group (Section 4.2 and Section 5). 177 Figure 2 provides a high level overview of the message flow for a 178 node joining a group communication setting. 180 C AS KDC Dispatcher Group 181 | | | | Member 182 | | | | \ | 183 | Authorization Request | | | | Defined | 184 |----------------------------->| | | | in the ACE | 185 | | | | | framework | 186 | Authorization Response | | | | | 187 |<-----------------------------| | | | | 188 | | | | | | 189 |--------- Token Post ---------------->| | / | 190 | | | | 191 |---- Key Distribution Request ------->| | | 192 | | | | 193 |<--- Key Distribution Response ------ | --- Group Rekeying ----->| 194 | | | 195 |<================== Protected communication ===|================>| 196 | | | 198 Figure 2: Message Flow Upon New Node's Joining 200 The exchange of Authorization Request and Authorization Response 201 between Client and AS MUST be secured, as specified by the ACE 202 profile used between Client and KDC. 204 The exchange of Key Distribution Request and Key Distribution 205 Response between Client and KDC MUST be secured, as a result of the 206 ACE profile used between Client and KDC. 208 All further communications between the Client and the KDC MUST be 209 secured, for instance with the same security mechanism used for the 210 Key Distribution exchange. 212 All further communications between a Client and the other group 213 members MUST be secured using the keying material provided in 214 Section 4. 216 3. Authorization to Join a Group 218 This section describes in detail the format of messages exchanged by 219 the participants when a node requests access to a group. The first 220 part of the exchange is based on ACE [I-D.ietf-ace-oauth-authz]. 222 As defined in [I-D.ietf-ace-oauth-authz], the Client requests from 223 the AS an authorization to join the group through the KDC (see 224 Section 3.1). If the request is approved and authorization is 225 granted, the AS provides the Client with a proof-of-possession access 226 token and parameters to securely communicate with the KDC (see 227 Section 3.2). Communications between the Client and the AS MUST be 228 secured, and depends on the profile of ACE used. 230 Figure 3 gives an overview of the exchange described above. 232 Client AS KDC 233 | | | 234 |---- Authorization Request: POST /token ------>| | 235 | | | 236 |<--- Authorization Response: 2.01 (Created) ---| | 237 | | | 238 |----- POST Token: POST /authz-info --------------->| 239 | | 241 Figure 3: Message Flow of Join Authorization 243 3.1. Authorization Request 245 The Authorization Request sent from the Client to the AS is as 246 defined in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MUST 247 contain the following parameters: 249 o 'grant_type', with value "client_credentials". 251 Additionally, the Authorization Request MAY contain the following 252 parameters, which, if included, MUST have the corresponding values: 254 o 'scope', with value the identifier of the specific group or topic 255 the Client wishes to access, and optionally the role(s) the Client 256 wishes to take. This value is a CBOR array encoded as a byte 257 string, which contains: 259 * As first element, the identifier of the specific group or 260 topic. 262 * Optionally, as second element, the role (or CBOR array of 263 roles) the Client wishes to take in the group. 265 The encoding of the group or topic identifier and of the role 266 identifiers is application specific. 268 o 'req_aud', as defined in Section 3.1 of 269 [I-D.ietf-ace-oauth-params], with value an identifier of the KDC. 271 o 'req_cnf', as defined in Section 3.1 of 272 [I-D.ietf-ace-oauth-params], optionally containing the public key 273 or the certificate of the Client, if it wishes to communicate that 274 to the AS. 276 o Other additional parameters as defined in 277 [I-D.ietf-ace-oauth-authz], if necessary. 279 3.2. Authorization Response 281 The Authorization Response sent from the AS to the Client is as 282 defined in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST 283 contain the following parameters: 285 o 'access_token', containing the proof-of-possession access token. 287 o 'cnf' if symmetric keys are used, not present if asymmetric keys 288 are used. This parameter is defined in Section 3.2 of 289 [I-D.ietf-ace-oauth-params] and contains the symmetric proof-of- 290 possession key that the Client is supposed to use with the KDC. 292 o 'rs_cnf' if asymmetric keys are used, not present if symmetric 293 keys are used. This parameter is as defined in Section 3.2 of 294 [I-D.ietf-ace-oauth-params] and contains information about the 295 public key of the KDC. 297 o 'exp', contains the lifetime in seconds of the access token. This 298 parameter MAY be omitted if the application defines how the 299 expiration time is communicated to the Client via other means, or 300 if it establishes a default value. 302 Additionally, the Authorization Response MAY contain the following 303 parameters, which, if included, MUST have the corresponding values: 305 o 'scope', which mirrors the 'scope' parameter in the Authorization 306 Request (see Section 3.1). Its value is a CBOR array encoded as a 307 byte string, containing: 309 * As first element, the identifier of the specific group or topic 310 the Client is authorized to access. 312 * Optionally, as second element, the role (or CBOR array of 313 roles) the Client is authorized to take in the group. 315 The encoding of the group or topic identifier and of the role 316 identifiers is application specific. 318 o Other additional parameters as defined in 319 [I-D.ietf-ace-oauth-authz], if necessary. 321 The access token MUST contain all the parameters defined above 322 (including the same 'scope' as in this message, if present, or the 323 'scope' of the Authorization Request otherwise), and additionally 324 other optional parameters the profile requires. 326 When receiving an Authorization Request from a Client that was 327 previously authorized, and which still owns a valid non expired 328 access token, the AS can simply reply with an Authorization Response 329 including a new access token. 331 3.3. Token Post 333 The Client sends a CoAP POST request including the access token to 334 the KDC, as specified in section 5.8.1 of [I-D.ietf-ace-oauth-authz]. 335 If the specific ACE profile defines it, the Client MAY use a 336 different endpoint than /authz-info at the KDC to post the access 337 token to. After successful verification, the Client is authorized to 338 receive the group keying material from the KDC and join the group. 340 Note that this step could be merged with the following message from 341 the Client to the KDC, namely Key Distribution Request. 343 4. Key Distribution 345 This section defines how the keying material used for group 346 communication is distributed from the KDC to the Client, when joining 347 the group as a new member. 349 If not previously established, the Client and the KDC MUST first 350 establish a pairwise secure communication channel using ACE. The 351 exchange of Key Distribution Request-Response MUST occur over that 352 secure channel. The Client and the KDC MAY use that same secure 353 channel to protect further pairwise communications, that MUST be 354 secured. 356 During this exchange, the Client sends a request to the AS, 357 specifying the group it wishes to join (see Section 4.1). Then, the 358 KDC verifies the access token and that the Client is authorized to 359 join that group; if so, it provides the Client with the keying 360 material to securely communicate with the member of the group (see 361 Section 4.2). 363 Figure 4 gives an overview of the exchange described above. 365 Client KDC 366 | | 367 |---- Key Distribution Request: POST /group-id --->| 368 | | 369 |<--- Key Distribution Response: 2.01 (Created) ---| 370 | | 372 Figure 4: Message Flow of Key Distribution to a New Group Member 374 The same set of message can also be used for the following cases, 375 when the Client is already a group member: 377 o The Client wishes to (re-)get the current keying material, for 378 cases such as expiration, loss or suspected mismatch, due to e.g. 379 reboot or missed group rekeying. This is further discussed in 380 Section 6. 382 o The Client wishes to (re-)get the public keys of other group 383 members, e.g. if it is aware of new nodes joining the group after 384 itself. This is further discussed in Section 7. 386 Additionally, the format of the payload of the Key Distribution 387 Response (Section 4.2) can be reused for messages sent by the KDC to 388 distribute updated group keying material, in case of a new node 389 joining the group or of a current member leaving the group. The key 390 management scheme used to send such messages could rely on, e.g., 391 multicast in case of a new node joining or unicast in case of a node 392 leaving the group. 394 Note that proof-of-possession to bind the access token to the Client 395 is performed by using the proof-of-possession key bound to the access 396 token for establishing secure communication between the Client and 397 the KDC. 399 4.1. Key Distribution Request 401 The Client sends a Key Distribution request to the KDC. This 402 corresponds to a CoAP POST request to the endpoint in the KDC 403 associated to the group to join. The endpoint in the KDC is 404 associated to the 'scope' value of the Authorization Request/ 405 Response. The payload of this request is a CBOR Map which MAY 406 contain the following fields, which, if included, MUST have the 407 corresponding values: 409 o 'scope', with value the specific resource that the Client is 410 authorized to access (i.e. group or topic identifier) and role(s), 411 encoded as in Section 3.1. 413 o 'get_pub_keys', if the Client wishes to receive the public keys of 414 the other nodes in the group from the KDC. The value is an empty 415 CBOR Array. This parameter may be present if the KDC stores the 416 public keys of the nodes in the group and distributes them to the 417 Client; it is useless to have here if the set of public keys of 418 the members of the group is known in another way, e.g. it was 419 provided by the AS. 421 o 'client_cred', with value the public key or certificate of the 422 Client. If the KDC is managing (collecting from/distributing to 423 the Client) the public keys of the group members, this field 424 contains the public key of the Client. 426 o 'pub_keys_repos', can be present if a certificate is present in 427 the 'client_cred' field, with value a list of public key 428 repositories storing the certificate of the Client. 430 4.2. Key Distribution Response 432 The KDC verifies the access token and, if verification succeeds, 433 sends a Key Distribution success Response to the Client. This 434 corresponds to a 2.01 Created message. The payload of this response 435 is a CBOR Map which MUST contain the following fields: 437 o 'key', used to send the keying material to the Client, as a 438 COSE_Key ([RFC8152]) containing the following parameters: 440 * 'kty', as defined in [RFC8152]. 442 * 'k', as defined in [RFC8152]. 444 * 'exp' (optionally), as defined below. This parameter is 445 RECOMMENDED to be included in the COSE_Key. If omitted, the 446 authorization server SHOULD provide the expiration time via 447 other means or document the default value. 449 * 'alg' (optionally), as defined in [RFC8152]. 451 * 'kid' (optionally), as defined in [RFC8152]. 453 * 'base iv' (optionally), as defined in [RFC8152]. 455 * 'clientID' (optionally), as defined in 456 [I-D.ietf-ace-oscore-profile]. 458 * 'serverID' (optionally), as defined in 459 [I-D.ietf-ace-oscore-profile]. 461 * 'kdf' (optionally), as defined in 462 [I-D.ietf-ace-oscore-profile]. 464 * 'slt' (optionally), as defined in 465 [I-D.ietf-ace-oscore-profile]. 467 * 'cs_alg' (optionally), containing the algorithm value to 468 countersign the message, taken from Table 5 and 6 of [RFC8152]. 470 The parameter 'exp' identifies the expiration time in seconds after 471 which the COSE_Key is not valid anymore for secure communication in 472 the group. A summary of 'exp' can be found in Figure 5. 474 +------+-------+----------------+------------+-----------------+ 475 | Name | Label | CBOR Type | Value | Description | 476 | | | | Registry | | 477 +------+-------+----------------+------------+-----------------+ 478 | exp | TBD | Integer or | COSE Key | Expiration time | 479 | | | floating-point | Common | in seconds | 480 | | | number | Parameters | | 481 +------+-------+----------------+------------+-----------------+ 483 Figure 5: COSE Key Common Header Parameter 'exp' 485 Optionally, the Key Distribution Response MAY contain the following 486 parameters, which, if included, MUST have the corresponding values: 488 o 'pub_keys', may only be present if 'get_pub_keys' was present in 489 the Key Distribution Request; this parameter is a COSE_KeySet (see 490 [RFC8152]), which contains the public keys of all the members of 491 the group. 493 o 'group_policies', with value a list of parameters indicating how 494 the group handles specific management aspects. This includes, for 495 instance, approaches to achieve synchronization of sequence 496 numbers among group members. The exact format of this parameter 497 is specific to the profile. 499 o 'mgt_key_material', with value the administrative keying material 500 to participate in the group rekeying performed by the KDC. The 501 exact format and content depend on the specific rekeying scheme 502 used in the group, which may be specified in the profile. 504 Specific profiles need to specify how exactly the keying material is 505 used to protect the group communication. 507 If the application requires backward security, the KDC SHALL generate 508 new group keying material and securely distribute it to all the 509 current group members, using the message format defined in this 510 section. Application profiles may define alternative message 511 formats. 513 TBD: define for verification failure 515 5. Removal of a Node from the Group 517 This section describes at a high level how a node can be removed from 518 the group. 520 If the application requires forward security, the KDC SHALL generate 521 new group keying material and securely distribute it to all the 522 current group members but the leaving node, using the message format 523 defined in Section 4.2. Application profiles may define alternative 524 message formats. 526 5.1. Expired Authorization 528 If the node is not authorized anymore, the AS can directly 529 communicate that to the KDC. Alternatively, the access token might 530 have expired. If Token introspection is provided by the AS, the KDC 531 can use it as per Section 5.7 of [I-D.ietf-ace-oauth-authz], in order 532 to verify that the access token is still valid. 534 Either case, once aware that a node is not authorized anymore, the 535 KDC has to remove the unauthorized node from the list of group 536 members, if the KDC keeps track of that. 538 5.2. Request to Leave the Group 540 A node can actively request to leave the group. In this case, the 541 Client can send a request formatted as follows to the KDC, to abandon 542 the group. 544 TBD: Format of the message to leave the group 546 The KDC should then remove the leaving node from the list of group 547 members, if the KDC keeps track of that. 549 Note that, after having left the group, a node may wish to join it 550 again. Then, as long as the node is still authorized to join the 551 group, i.e. it has a still valid access token, it can re-request to 552 join the group directly to the KDC without needing to retrieve a new 553 access token from the AS. This means that the KDC needs to keep 554 track of nodes with valid access tokens, before deleting all 555 information about the leaving node. 557 6. Retrieval of Updated Keying Material 559 A node stops using the group keying material upon its expiration, 560 according to the 'exp' parameter specified in the retained COSE Key. 561 Then, if it wants to continue participating in the group 562 communication, the node has to request new updated keying material to 563 the KDC. 565 The Client may perform the same request to the KDC also upon 566 receiving messages from other group members without being able to 567 correctly decrypt them. This may be due to a previous update of the 568 group keying material (rekeying) triggered by the KDC, that the 569 Client was not able to receive or decrypt. 571 Note that policies can be set up so that the Client sends a request 572 to the KDC only after a given number of unsuccessfully decrypted 573 incoming messages. 575 6.1. Key Re-Distribution Request 577 To request a re-distribution of keying material, the Client sends a 578 shortened Key Distribution Request to the KDC (Section 4.1), 579 formatted as follows. The payload MUST contain only the following 580 field: 582 o 'scope', which contains only the identifier of the specific group 583 or topic, encoded as in Section 3.1. That is, the role field is 584 not present. 586 6.2. Key Re-Distribution Response 588 The KDC receiving a Key Re-Distribution Request MUST check that it is 589 storing a valid access token from that client for that scope. 591 TODO: defines error response if it does not have it / is not valid. 593 The KDC replies to the Client with a Key Distribution Response 594 containing the 'key' parameter, and optionally 'group_policies' and 595 'mgt_key_material', as specified in Section 4.2. Note that this 596 response might simply re-provide the same keying material currently 597 owned by the Client, if it has not been renewed. 599 7. Retrieval of Public Keys for Group Members 601 In case the KDC maintains the public keys of group members, a node in 602 the group can contact the KDC to request public keys of either all 603 group members or a specified subset, using the messages defined 604 below. 606 Figure 6 gives an overview of the exchange described above. 608 Client KDC 609 | | 610 |---- Public Key Request: POST /group-id --->| 611 | | 612 |<--- Public Key Response: 2.01 (Created) ---| 613 | | 615 Figure 6: Message Flow of Public Key Request-Response 617 Note that these messages can be combined with the Key Re-Distribution 618 messages in Section 6, to request at the same time the keying 619 material and the public keys. In this case, either a new endpoint at 620 the KDC may be used, or additional information needs to be sent in 621 the request payload, to distinguish these combined messages from the 622 Public Key messages described below, since they would be identical 623 otherwise. 625 7.1. Public Key Request 627 To request public keys, the Client sends a shortened Key Distribution 628 Request to the KDC (Section 4.1), formatted as follows. The payload 629 of this request MUST contain the following fields: 631 o 'get_pub_keys', which has as value a CBOR array including either: 633 * no elements, i.e. an empty array, in order to request the 634 public key of all current group members; or 636 * N elements, each of which is the identifier of a group member, 637 in order to request the public key of the specified nodes. 639 o 'scope', which contains only the identifier of the specific group 640 or topic, encoded as in Section 3.1. That is, the role field is 641 not present. 643 7.2. Public Key Response 645 The KDC replies to the Client with a Key Distribution Response 646 containing only the 'pub_keys' parameter, as specified in 647 Section 4.2. The payload of this response contains the following 648 field: 650 o 'pub_keys', which contains either: 652 * the public keys of all the members of the group, if the 653 'get_pub_keys' parameter of the Public Key request was an empty 654 array; or 656 * the public keys of the group members with the identifiers 657 specified in the 'get_pub_keys' parameter of the Public Key 658 request. 660 The KDC ignores possible identifiers included in the 'get_pub_keys' 661 parameter of the Public Key request if they are not associated to any 662 current group member. 664 8. Security Considerations 666 The KDC must renew the group keying material upon its expiration. 668 The KDC should renew the keying material upon group membership 669 change, and should provide it to the current group members through 670 the rekeying scheme used in the group. 672 9. IANA Considerations 674 The following registration is required for the COSE Key Common 675 Parameter Registry specified in Section 16.5 of [RFC8152]: 677 o Name: exp 679 o Label: TBD 681 o CBOR Type: Integer or floating-point number 683 o Value Registry: COSE Key Common Parameters 685 o Description: Identifies the expiration time in seconds of the COSE 686 Key 688 o Reference: [[this specification]] 690 10. References 692 10.1. Normative References 694 [I-D.ietf-ace-oauth-authz] 695 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 696 H. Tschofenig, "Authentication and Authorization for 697 Constrained Environments (ACE) using the OAuth 2.0 698 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-17 699 (work in progress), November 2018. 701 [I-D.ietf-ace-oauth-params] 702 Seitz, L., "Additional OAuth Parameters for Authorization 703 in Constrained Environments (ACE)", draft-ietf-ace-oauth- 704 params-01 (work in progress), November 2018. 706 [I-D.ietf-ace-oscore-profile] 707 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 708 "OSCORE profile of the Authentication and Authorization 709 for Constrained Environments Framework", draft-ietf-ace- 710 oscore-profile-05 (work in progress), November 2018. 712 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 713 Requirement Levels", BCP 14, RFC 2119, 714 DOI 10.17487/RFC2119, March 1997, 715 . 717 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 718 RFC 8152, DOI 10.17487/RFC8152, July 2017, 719 . 721 10.2. Informative References 723 [I-D.ietf-core-coap-pubsub] 724 Koster, M., Keranen, A., and J. Jimenez, "Publish- 725 Subscribe Broker for the Constrained Application Protocol 726 (CoAP)", draft-ietf-core-coap-pubsub-05 (work in 727 progress), July 2018. 729 [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management 730 Protocol (GKMP) Specification", RFC 2093, 731 DOI 10.17487/RFC2093, July 1997, 732 . 734 [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management 735 Protocol (GKMP) Architecture", RFC 2094, 736 DOI 10.17487/RFC2094, July 1997, 737 . 739 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 740 Multicast: Issues and Architectures", RFC 2627, 741 DOI 10.17487/RFC2627, June 1999, 742 . 744 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 745 the Constrained Application Protocol (CoAP)", RFC 7390, 746 DOI 10.17487/RFC7390, October 2014, 747 . 749 Acknowledgments 751 The following individuals were helpful in shaping this document: Ben 752 Kaduk, John Mattsson, Jim Schaad, Ludwig Seitz, Goeran Selander and 753 Peter van der Stok. 755 The work on this document has been partly supported by the EIT- 756 Digital High Impact Initiative ACTIVE. 758 Authors' Addresses 760 Francesca Palombini 761 Ericsson AB 762 Torshamnsgatan 23 763 Kista SE-16440 Stockholm 764 Sweden 766 Email: francesca.palombini@ericsson.com 768 Marco Tiloca 769 RISE AB 770 Isafjordsgatan 22 771 Kista SE-16440 Stockholm 772 Sweden 774 Email: marco.tiloca@ri.se