idnits 2.17.1 draft-ietf-ace-key-groupcomm-01.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 (March 08, 2019) is 1868 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-22 == Outdated reference: A later version (-16) exists of draft-ietf-ace-oauth-params-04 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-13) exists of draft-ietf-core-coap-pubsub-06 Summary: 1 error (**), 0 flaws (~~), 4 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: September 9, 2019 RISE AB 6 March 08, 2019 8 Key Provisioning for Group Communication using ACE 9 draft-ietf-ace-key-groupcomm-01 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 September 9, 2019. 34 Copyright Notice 36 Copyright (c) 2019 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 . . . . . . . . . . . . . . . 14 66 6.2. Key Re-Distribution Response . . . . . . . . . . . . . . 14 67 7. Retrieval of Public Keys for Group Members . . . . . . . . . 15 68 7.1. Public Key Request . . . . . . . . . . . . . . . . . . . 15 69 7.2. Public Key Response . . . . . . . . . . . . . . . . . . . 16 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 72 9.1. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 16 73 9.2. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 17 74 9.3. Expert Review Instructions . . . . . . . . . . . . . . . 18 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 77 10.2. Informative References . . . . . . . . . . . . . . . . . 19 78 Appendix A. Document Updates . . . . . . . . . . . . . . . . . . 20 79 A.1. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 20 80 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 83 1. Introduction 85 This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to 86 define the format of messages used to request, distribute and renew 87 the keying material in a group communication scenario, e.g. based on 88 multicast [RFC7390] or on publishing-subscribing 89 [I-D.ietf-core-coap-pubsub]. 91 Profiles that use group communication can build on this document to 92 specify the selection of the message parameters defined in this 93 document to use and their values. Known applications that can 94 benefit from this document would be, for example, profiles addressing 95 group communication based on multicast [RFC7390] or publishing/ 96 subscribing [I-D.ietf-core-coap-pubsub] in ACE. 98 If the application requires backward and forward security, updated 99 keying material is generated and distributed to the group members 100 (rekeying), when membership changes. A key management scheme 101 performs the actual distribution of the updated keying material to 102 the group. In particular, the key management scheme rekeys the 103 current group members when a new node joins the group, and the 104 remaining group members when a node leaves the group. This document 105 provides a message format for group rekeying that allows to fulfill 106 these requirements. Rekeying mechanisms can be based on [RFC2093], 107 [RFC2094] and [RFC2627]. 109 1.1. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. These 114 words may also appear in this document in lowercase, absent their 115 normative meanings. 117 Readers are expected to be familiar with the terms and concepts 118 described in [I-D.ietf-ace-oauth-authz] and [RFC8152], such as 119 Authorization Server (AS) and Resource Server (RS). 121 2. Overview 123 +------------+ +-----------+ 124 | AS | | KDC | 125 | | .-------->| | 126 +------------+ / +-----------+ 127 ^ / 128 | / 129 v / +-----------+ 130 +------------+ / +------------+ |+-----------+ 131 | Client |<-' | Dispatcher | ||+-----------+ 132 | |<-------->| (RS) |<------->|| Group | 133 +------------+ +------------+ +| members | 134 +-----------+ 136 Figure 1: Key Distribution Participants 138 The following participants (see Figure 1) take part in the 139 authorization and key distribution. 141 o Client (C): node that wants to join the group communication. It 142 can request write and/or read rights. 144 o Authorization Server (AS): same as AS in the ACE Framework; it 145 enforces access policies, and knows if a node is allowed to join 146 the group with write and/or read rights. 148 o Key Distribution Center (KDC): maintains the keying material to 149 protect group communications, and provides it to Clients 150 authorized to join the group. During the first part of the 151 exchange (Section 3), it takes the role of the RS in the ACE 152 Framework. During the second part (Section 4), which is not based 153 on the ACE Framework, it distributes the keying material. In 154 addition, it provides the latest keying material to group members 155 when requested. If required by the application, the KDC renews 156 and re-distributes the keying material in the group when 157 membership changes. 159 o Dispatcher: entity through which the Clients communicate with the 160 group and which distributes messages to the group members. 161 Examples of dispatchers are: the Broker node in a pub-sub setting; 162 a relayer node for group communication that delivers group 163 messages as multiple unicast messages to all group members; an 164 implicit entity as in a multicast communication setting, where 165 messages are transmitted to a multicast IP address and delivered 166 on the transport channel. 168 This document specifies the message flows and formats for: 170 o Authorizing a new node to join the group (Section 3), and 171 providing it with the group keying material to communicate with 172 the other group members (Section 4). 174 o Removing of a current member from the group (Section 5). 176 o Retrieving keying material as a current group member (Section 6 177 and Section 7). 179 o Renewing and re-distributing the group keying material (rekeying) 180 upon a membership change in the group (Section 4.2 and Section 5). 182 Figure 2 provides a high level overview of the message flow for a 183 node joining a group communication setting. 185 C AS KDC Dispatcher Group 186 | | | | Member 187 | | | | \ | 188 | Authorization Request | | | | Defined | 189 |----------------------------->| | | | in the ACE | 190 | | | | | framework | 191 | Authorization Response | | | | | 192 |<-----------------------------| | | | | 193 | | | | | | 194 |--------- Token Post ---------------->| | / | 195 | | | | 196 |---- Key Distribution Request ------->| | | 197 | | | | 198 |<--- Key Distribution Response ------ | --- Group Rekeying ----->| 199 | | | 200 |<================== Protected communication ===|================>| 201 | | | 203 Figure 2: Message Flow Upon New Node's Joining 205 The exchange of Authorization Request and Authorization Response 206 between Client and AS MUST be secured, as specified by the ACE 207 profile used between Client and KDC. 209 The exchange of Key Distribution Request and Key Distribution 210 Response between Client and KDC MUST be secured, as a result of the 211 ACE profile used between Client and KDC. 213 All further communications between the Client and the KDC MUST be 214 secured, for instance with the same security mechanism used for the 215 Key Distribution exchange. 217 All further communications between a Client and the other group 218 members MUST be secured using the keying material provided in 219 Section 4. 221 3. Authorization to Join a Group 223 This section describes in detail the format of messages exchanged by 224 the participants when a node requests access to a group. The first 225 part of the exchange is based on ACE [I-D.ietf-ace-oauth-authz]. 227 As defined in [I-D.ietf-ace-oauth-authz], the Client requests from 228 the AS an authorization to join the group through the KDC (see 229 Section 3.1). If the request is approved and authorization is 230 granted, the AS provides the Client with a proof-of-possession access 231 token and parameters to securely communicate with the KDC (see 232 Section 3.2). Communications between the Client and the AS MUST be 233 secured, and depends on the profile of ACE used. 235 Figure 3 gives an overview of the exchange described above. 237 Client AS KDC 238 | | | 239 |---- Authorization Request: POST /token ------>| | 240 | | | 241 |<--- Authorization Response: 2.01 (Created) ---| | 242 | | | 243 |----- POST Token: POST /authz-info --------------->| 244 | | 246 Figure 3: Message Flow of Join Authorization 248 3.1. Authorization Request 250 The Authorization Request sent from the Client to the AS is as 251 defined in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MUST 252 contain the following parameters: 254 o 'grant_type', with value "client_credentials". 256 Additionally, the Authorization Request MAY contain the following 257 parameters, which, if included, MUST have the corresponding values: 259 o 'scope', containing the identifier of the specific group (or topic 260 in the case of pub-sub) that the Client wishes to access, and 261 optionally the role(s) that the Client wishes to take. This value 262 is a CBOR array encoded as a byte string, which contains: 264 * As first element, the identifier of the specific group or 265 topic. 267 * Optionally, as second element, the role (or CBOR array of 268 roles) the Client wishes to take in the group. 270 The encoding of the group or topic identifier and of the role 271 identifiers is application specific. 273 o 'audience', with an identifier of a KDC. 275 o 'req_cnf', as defined in Section 3.1 of 276 [I-D.ietf-ace-oauth-params], optionally containing the public key 277 or a reference to the public key of the Client, if it wishes to 278 communicate that to the AS. 280 o Other additional parameters as defined in 281 [I-D.ietf-ace-oauth-authz], if necessary. 283 3.2. Authorization Response 285 The Authorization Response sent from the AS to the Client is as 286 defined in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST 287 contain the following parameters: 289 o 'access_token', containing the proof-of-possession access token. 291 o 'cnf' if symmetric keys are used, not present if asymmetric keys 292 are used. This parameter is defined in Section 3.2 of 293 [I-D.ietf-ace-oauth-params] and contains the symmetric proof-of- 294 possession key that the Client is supposed to use with the KDC. 296 o 'rs_cnf' if asymmetric keys are used, not present if symmetric 297 keys are used. This parameter is as defined in Section 3.2 of 298 [I-D.ietf-ace-oauth-params] and contains information about the 299 public key of the KDC. 301 o 'exp', contains the lifetime in seconds of the access token. This 302 parameter MAY be omitted if the application defines how the 303 expiration time is communicated to the Client via other means, or 304 if it establishes a default value. 306 Additionally, the Authorization Response MAY contain the following 307 parameters, which, if included, MUST have the corresponding values: 309 o 'scope', which mirrors the 'scope' parameter in the Authorization 310 Request (see Section 3.1). Its value is a CBOR array encoded as a 311 byte string, containing: 313 * As first element, the identifier of the specific group or topic 314 the Client is authorized to access. 316 * Optionally, as second element, the role (or CBOR array of 317 roles) the Client is authorized to take in the group. 319 The encoding of the group or topic identifier and of the role 320 identifiers is application specific. 322 o Other additional parameters as defined in 323 [I-D.ietf-ace-oauth-authz], if necessary. 325 The access token MUST contain all the parameters defined above 326 (including the same 'scope' as in this message, if present, or the 327 'scope' of the Authorization Request otherwise), and additionally 328 other optional parameters the profile requires. 330 When receiving an Authorization Request from a Client that was 331 previously authorized, and which still owns a valid non expired 332 access token, the AS can simply reply with an Authorization Response 333 including a new access token. 335 3.3. Token Post 337 The Client sends a CoAP POST request including the access token to 338 the KDC, as specified in section 5.8.1 of [I-D.ietf-ace-oauth-authz]. 339 If the specific ACE profile defines it, the Client MAY use a 340 different endpoint than /authz-info at the KDC to post the access 341 token to. After successful verification, the Client is authorized to 342 receive the group keying material from the KDC and join the group. 344 Note that this step could be merged with the following message from 345 the Client to the KDC, namely Key Distribution Request. 347 4. Key Distribution 349 This section defines how the keying material used for group 350 communication is distributed from the KDC to the Client, when joining 351 the group as a new member. 353 If not previously established, the Client and the KDC MUST first 354 establish a pairwise secure communication channel using ACE. The 355 exchange of Key Distribution Request-Response MUST occur over that 356 secure channel. The Client and the KDC MAY use that same secure 357 channel to protect further pairwise communications, that MUST be 358 secured. 360 During this exchange, the Client sends a request to the AS, 361 specifying the group it wishes to join (see Section 4.1). Then, the 362 KDC verifies the access token and that the Client is authorized to 363 join that group; if so, it provides the Client with the keying 364 material to securely communicate with the member of the group (see 365 Section 4.2). 367 Figure 4 gives an overview of the exchange described above. 369 Client KDC 370 | | 371 |---- Key Distribution Request: POST /group-id --->| 372 | | 373 |<--- Key Distribution Response: 2.01 (Created) ---| 374 | | 376 Figure 4: Message Flow of Key Distribution to a New Group Member 378 The same set of message can also be used for the following cases, 379 when the Client is already a group member: 381 o The Client wishes to (re-)get the current keying material, for 382 cases such as expiration, loss or suspected mismatch, due to e.g. 383 reboot or missed group rekeying. This is further discussed in 384 Section 6. 386 o The Client wishes to (re-)get the public keys of other group 387 members, e.g. if it is aware of new nodes joining the group after 388 itself. This is further discussed in Section 7. 390 Additionally, the format of the payload of the Key Distribution 391 Response (Section 4.2) can be reused for messages sent by the KDC to 392 distribute updated group keying material, in case of a new node 393 joining the group or of a current member leaving the group. The key 394 management scheme used to send such messages could rely on, e.g., 395 multicast in case of a new node joining or unicast in case of a node 396 leaving the group. 398 Note that proof-of-possession to bind the access token to the Client 399 is performed by using the proof-of-possession key bound to the access 400 token for establishing secure communication between the Client and 401 the KDC. 403 4.1. Key Distribution Request 405 The Client sends a Key Distribution Request to the KDC. This 406 corresponds to a CoAP POST request to the endpoint in the KDC 407 associated to the group to join. The endpoint in the KDC is 408 associated to the 'scope' value of the Authorization Request/ 409 Response. The payload of this request is a CBOR Map which MAY 410 contain the following fields, which, if included, MUST have the 411 corresponding values: 413 o 'scope', with value the specific resource that the Client is 414 authorized to access (i.e. group or topic identifier) and role(s), 415 encoded as in Section 3.1. 417 o 'get_pub_keys', if the Client wishes to receive the public keys of 418 the other nodes in the group from the KDC. The value is an empty 419 CBOR Array. This parameter may be present if the KDC stores the 420 public keys of the nodes in the group and distributes them to the 421 Client; it is useless to have here if the set of public keys of 422 the members of the group is known in another way, e.g. it was 423 provided by the AS. 425 o 'client_cred', with value the public key or certificate of the 426 Client. If the KDC is managing (collecting from/distributing to 427 the Client) the public keys of the group members, this field 428 contains the public key of the Client. 430 o 'pub_keys_repos', can be present if a certificate is present in 431 the 'client_cred' field, with value a list of public key 432 repositories storing the certificate of the Client. 434 4.2. Key Distribution Response 436 The KDC verifies the 'scope' received in the Key Distribution 437 Request, if present, against the 'scope' stored in the access token 438 associated to this client. If verification fails, the KDC MUST 439 respond with a 4.01 (Unauthorized) error message. If the Key 440 Distribution Request is not formatted correctly (e.g. no 'scope' 441 field present while expected, or unknown fields present), the KDC 442 MUST respond with 4.00 (Bad Request) error message. 444 If verification succeeds, the KDC sends a Key Distribution success 445 Response to the Client. The Key Distribution success Response 446 corresponds to a 2.01 Created message. The payload of this response 447 is a CBOR map, which MUST contain: 449 o 'kty', identifying the key type of the 'key' parameter. The set 450 of values can be found in the "Key Type" column of the "ACE 451 Groupcomm Key" Registry. Implementations MUST verify that the key 452 type matches the profile being used, if present, as registered in 453 the "ACE Groupcomm Key" registry. 455 o 'key', containing the keying material for the group communication, 456 or information required to derive it. 458 The exact format of the 'key' value MUST be defined in applications 459 of this specification. Additionally, documents specifying the key 460 format MUST register it in the "ACE Groupcomm Key" registry, 461 including its name, type and profile to be used with, as defined in 462 the "ACE Groupcomm Key" registry, defined in Section 9.1. 464 +----------+----------------+---------+-------------------------+ 465 | Name | Key Type Value | Profile | Description | 466 +----------+----------------+---------+-------------------------+ 467 | Reserved | 0 | | This value is reserved | 468 +----------+----------------+---------+-------------------------+ 470 Figure 5: Key Type Values 472 Optionally, the Key Distribution Response MAY contain the following 473 parameters, which, if included, MUST have the corresponding values: 475 o 'profile', with value an identifier that MUST be used to uniquely 476 identify itself. The identifier MUST be registered in the "ACE 477 Groupcomm Profile" Registry. 479 o 'exp', with value the expiration time of the keying material for 480 the group communication, encoded as a CBOR unsigned integer or 481 floating-point number. 483 o 'pub_keys', may only be present if 'get_pub_keys' was present in 484 the Key Distribution Request. This parameter is a CBOR Byte 485 String, which encodes the public keys of all the group members 486 paired with the respective member identifiers. In case public 487 keys in the group are represented as COSE Keys, the CBOR Byte 488 String encodes a COSE_KeySet (see [RFC8152]), which contains the 489 public keys of all the members of the group. In particular, each 490 COSE Key in the COSE_KeySet includes the identifier of the 491 corresponding group member as value of its 'kid' key parameter. 492 Alternative specific encodings of this parameter MUST be defined 493 in applications of this specification. 495 o 'group_policies', with value a list of parameters indicating how 496 the group handles specific management aspects. This includes, for 497 instance, approaches to achieve synchronization of sequence 498 numbers among group members. The exact format of this parameter 499 is specific to the profile. 501 o 'mgt_key_material', with value the administrative keying material 502 to participate in the group rekeying performed by the KDC. The 503 exact format and content depend on the specific rekeying scheme 504 used in the group, which may be specified in the profile. 506 Specific profiles need to specify how exactly the keying material is 507 used to protect the group communication. 509 If the application requires backward security, the KDC SHALL generate 510 new group keying material and securely distribute it to all the 511 current group members, using the message format defined in this 512 section. Application profiles may define alternative message 513 formats. 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. The client MUST use the protected channel established 543 with ACE, mentioned in Section 4. 545 To request to leave a group, the client MUST send a CoAP POST request 546 to the endpoint in the KDC associated to the group to leave (same 547 endpoint used in Section 4.1 for Key Distribution requests). The 548 payload of this Leave Request is a CBOR Map which MUST contain: 550 o 'leave', with value an empty CBOR array. 552 o 'scope', with value the specific resource that the Client is 553 authorized to access (i.e. group or topic identifier) and wants to 554 leave, encoded as in Section 3.1. The 'role' field is omitted. 556 Additionally, the Leave request MAY contain the following parameters, 557 which, if included, MUST have the corresponding values: 559 o 'client_cred', with value the identifier of the public key or 560 certificate of the Client. This field is used if the KDC is 561 managing (collecting from/distributing to the Client) the public 562 keys of the group members. 564 Note that the 'role' field is omitted since such a request should 565 only be used to leave a group altogether. If the leaving node wants 566 to be part of a group with fewer roles, it does not need to 567 communicate that to the KDC, and can simply stop acting according to 568 such roles. 570 If the Leave Request is not formatted correctly (e.g. no 'scope' 571 field present, or unknown fields present), the KDC MUST respond with 572 a 4.00 (Bad Request) error message. Otherwise, the KDC MUST remove 573 the leaving node from the list of group members, if the KDC keeps 574 track of that. 576 Note that, after having left the group, a node may wish to join it 577 again. Then, as long as the node is still authorized to join the 578 group, i.e. it has a still valid access token, it can re-request to 579 join the group directly to the KDC without needing to retrieve a new 580 access token from the AS. This means that the KDC needs to keep 581 track of nodes with valid access tokens, before deleting all 582 information about the leaving node. 584 6. Retrieval of Updated Keying Material 586 A node stops using the group keying material upon its expiration, 587 according to the 'exp' parameter specified in the retained COSE Key. 588 Then, if it wants to continue participating in the group 589 communication, the node has to request new updated keying material to 590 the KDC. 592 The Client may perform the same request to the KDC also upon 593 receiving messages from other group members without being able to 594 correctly decrypt them. This may be due to a previous update of the 595 group keying material (rekeying) triggered by the KDC, that the 596 Client was not able to receive or decrypt. 598 Note that policies can be set up so that the Client sends a request 599 to the KDC only after a given number of unsuccessfully decrypted 600 incoming messages. 602 Alternatively, the re-distribution of keying material can be 603 initiated by the KDC, which e.g.: 605 o Can maintain an Observable resource to send notifications to 606 Clients when the keying material is updated. Such a notification 607 would have the same payload as the Key Re-Distribution Response 608 defined in Section 6.2. 610 o Can send the payload of the Key Re-Distribution Response in a 611 multicast request to the members of the group. 613 o Can send unicast requests to each Client over a secure channel, 614 with the Key Re-Distribution Response as payload. 616 o Can act as a publisher in a pub-sub scenario, and update the 617 keying material by publishing on a specific topic on a broker, 618 which all the members of the group are subscribed to. 620 Note that these methods of KDC-initiated key re-distribution have 621 different security properties and require different security 622 associations. 624 6.1. Key Re-Distribution Request 626 To request a re-distribution of keying material, the Client sends a 627 shortened Key Distribution Request to the KDC (Section 4.1), 628 formatted as follows. The payload MUST contain only the following 629 field: 631 o 'scope', which contains only the identifier of the specific group 632 or topic, encoded as in Section 3.1. That is, the role field is 633 not present. 635 6.2. Key Re-Distribution Response 637 The KDC receiving a Key Re-Distribution Request MUST check that it is 638 storing a valid access token from that client for that scope. 640 If that is not the case, i.e. it does not store the token or the 641 token is not valid for that client for the scope requested, the KDC 642 MUST respond with a 4.01 (Unauthorized) error message. Analogously 643 to Section 4.2, if the Key Re-Distribution Request is not formatted 644 correctly (e.g. no 'scope' field present, or unknown fields present), 645 the KDC MUST respond with a 4.00 (Bad Request) error message. 647 Otherwise, the KDC replies to the Client with a Key Distribution 648 Response, which MUST include the 'kty' and 'key' parameters specified 649 in Section 4.2. The Key Distribution Response MAY also include the 650 'profile', 'exp', 'group_policies' and 'mgt_key_material' parameters 651 specified in Section 4.2. 653 Note that this response might simply re-provide the same keying 654 material currently owned by the Client, if it has not been renewed. 656 7. Retrieval of Public Keys for Group Members 658 In case the KDC maintains the public keys of group members, a node in 659 the group can contact the KDC to request public keys of either all 660 group members or a specified subset, using the messages defined 661 below. 663 Figure 6 gives an overview of the exchange described above. 665 Client KDC 666 | | 667 |---- Public Key Request: POST /group-id --->| 668 | | 669 |<--- Public Key Response: 2.01 (Created) ---| 670 | | 672 Figure 6: Message Flow of Public Key Request-Response 674 Note that these messages can be combined with the Key Re-Distribution 675 messages in Section 6, to request at the same time the keying 676 material and the public keys. In this case, either a new endpoint at 677 the KDC may be used, or additional information needs to be sent in 678 the request payload, to distinguish these combined messages from the 679 Public Key messages described below, since they would be identical 680 otherwise. 682 7.1. Public Key Request 684 To request public keys, the Client sends a shortened Key Distribution 685 Request to the KDC (Section 4.1), formatted as follows. The payload 686 of this request MUST contain the following fields: 688 o 'get_pub_keys', which has as value a CBOR array including either: 690 * no elements, i.e. an empty array, in order to request the 691 public key of all current group members; or 693 * N elements, each of which is the identifier of a group member, 694 in order to request the public key of the specified nodes. 696 o 'scope', which contains only the identifier of the specific group 697 or topic, encoded as in Section 3.1. That is, the role field is 698 not present. 700 7.2. Public Key Response 702 The KDC replies to the Client with a Key Distribution Response 703 containing only the 'pub_keys' parameter, as specified in 704 Section 4.2. The payload of this response contains the following 705 field: 707 o 'pub_keys', which contains either: 709 * the public keys of all the members of the group, if the 710 'get_pub_keys' parameter of the Public Key request was an empty 711 array; or 713 * the public keys of the group members with the identifiers 714 specified in the 'get_pub_keys' parameter of the Public Key 715 request. 717 The KDC ignores possible identifiers included in the 'get_pub_keys' 718 parameter of the Public Key request if they are not associated to any 719 current group member. 721 8. Security Considerations 723 The KDC must renew the group keying material upon its expiration. 725 The KDC should renew the keying material upon group membership 726 change, and should provide it to the current group members through 727 the rekeying scheme used in the group. 729 When a Client receives a message from a sender for the first time, it 730 needs to have a mechanism in place to avoid replay, e.g. 731 Appendix B.2 of [I-D.ietf-core-object-security]. 733 9. IANA Considerations 735 This document has the following actions for IANA. 737 9.1. ACE Groupcomm Key Registry 739 This specification establishes the IANA "ACE Groupcomm Key" Registry. 740 The Registry has been created to use the "Expert Review Required" 741 registration procedure [RFC8126]. Expert review guidelines are 742 provided in Section 9.3. 744 The columns of this Registry are: 746 o Name: This is a descriptive name that enables easier reference to 747 the item. The name MUST be unique. It is not used in the 748 encoding. 750 o Key Type Value: This is the value used to identify the keying 751 material. These values MUST be unique. The value can be a 752 positive integer, a negative integer, or a string. 754 o Profile: This field may contain a descriptive string of a profile 755 to be used with this item. This should be a value that is in the 756 Name column of the "ACE Groupcomm Profile" Registry. 758 o Description: This field contains a brief description of the keying 759 material. 761 o References: This contains a pointer to the public specification 762 for the format of the keying material, if one exists. 764 This Registry has been initially populated by the values in Figure 5. 765 The specification column for all of these entries will be this 766 document. 768 9.2. ACE Groupcomm Profile Registry 770 This specification establishes the IANA "ACE Groupcomm Profile" 771 Registry. The Registry has been created to use the "Expert Review 772 Required" registration procedure [RFC8126]. Expert review guidelines 773 are provided in Section 9.3. It should be noted that, in addition to 774 the expert review, some portions of the Registry require a 775 specification, potentially a Standards Track RFC, be supplied as 776 well. 778 The columns of this Registry are: 780 o Name: The name of the profile, to be used as value of the profile 781 attribute. 783 o Description: Text giving an overview of the profile and the 784 context it is developed for. 786 o CBOR Value: CBOR abbreviation for this profile name. Different 787 ranges of values use different registration policies [RFC8126]. 788 Integer values from -256 to 255 are designated as Standards 789 Action. Integer values from -65536 to -257 and from 256 to 65535 790 are designated as Specification Required. Integer values greater 791 than 65535 are designated as Expert Review. Integer values less 792 than -65536 are marked as Private Use. 794 o Reference: This contains a pointer to the public specification of 795 the profile abbreviation, if one exists. 797 9.3. Expert Review Instructions 799 The IANA Registries established in this document are defined as 800 expert review. This section gives some general guidelines for what 801 the experts should be looking for, but they are being designated as 802 experts for a reason so they should be given substantial latitude. 804 Expert reviewers should take into consideration the following points: 806 o Point squatting should be discouraged. Reviewers are encouraged 807 to get sufficient information for registration requests to ensure 808 that the usage is not going to duplicate one that is already 809 registered and that the point is likely to be used in deployments. 810 The zones tagged as private use are intended for testing purposes 811 and closed environments, code points in other ranges should not be 812 assigned for testing. 814 o Specifications are required for the standards track range of point 815 assignment. Specifications should exist for specification 816 required ranges, but early assignment before a specification is 817 available is considered to be permissible. Specifications are 818 needed for the first-come, first-serve range if they are expected 819 to be used outside of closed environments in an interoperable way. 820 When specifications are not provided, the description provided 821 needs to have sufficient information to identify what the point is 822 being used for. 824 o Experts should take into account the expected usage of fields when 825 approving point assignment. The fact that there is a range for 826 standards track documents does not mean that a standards track 827 document cannot have points assigned outside of that range. The 828 length of the encoded value should be weighed against how many 829 code points of that length are left, the size of device it will be 830 used on, and the number of code points left that encode to that 831 size. 833 10. References 835 10.1. Normative References 837 [I-D.ietf-ace-oauth-authz] 838 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 839 H. Tschofenig, "Authentication and Authorization for 840 Constrained Environments (ACE) using the OAuth 2.0 841 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-22 842 (work in progress), March 2019. 844 [I-D.ietf-ace-oauth-params] 845 Seitz, L., "Additional OAuth Parameters for Authorization 846 in Constrained Environments (ACE)", draft-ietf-ace-oauth- 847 params-04 (work in progress), February 2019. 849 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 850 Requirement Levels", BCP 14, RFC 2119, 851 DOI 10.17487/RFC2119, March 1997, 852 . 854 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 855 Writing an IANA Considerations Section in RFCs", BCP 26, 856 RFC 8126, DOI 10.17487/RFC8126, June 2017, 857 . 859 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 860 RFC 8152, DOI 10.17487/RFC8152, July 2017, 861 . 863 10.2. Informative References 865 [I-D.ietf-core-coap-pubsub] 866 Koster, M., Keranen, A., and J. Jimenez, "Publish- 867 Subscribe Broker for the Constrained Application Protocol 868 (CoAP)", draft-ietf-core-coap-pubsub-06 (work in 869 progress), January 2019. 871 [I-D.ietf-core-object-security] 872 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 873 "Object Security for Constrained RESTful Environments 874 (OSCORE)", draft-ietf-core-object-security-16 (work in 875 progress), March 2019. 877 [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management 878 Protocol (GKMP) Specification", RFC 2093, 879 DOI 10.17487/RFC2093, July 1997, 880 . 882 [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management 883 Protocol (GKMP) Architecture", RFC 2094, 884 DOI 10.17487/RFC2094, July 1997, 885 . 887 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 888 Multicast: Issues and Architectures", RFC 2627, 889 DOI 10.17487/RFC2627, June 1999, 890 . 892 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 893 the Constrained Application Protocol (CoAP)", RFC 7390, 894 DOI 10.17487/RFC7390, October 2014, 895 . 897 Appendix A. Document Updates 899 RFC EDITOR: PLEASE REMOVE THIS SECTION. 901 A.1. Version -00 to -01 903 o Changed name of 'req_aud' to 'audience' in the Authorization 904 Request (Section 3.1). 906 o Defined error handling on the KDC (Sections 4.2 and 6.2). 908 o Updated format of the Key Distribution Response as a whole 909 (Section 4.2). 911 o Generalized format of 'pub_keys' in the Key Distribution Response 912 (Section 4.2). 914 o Defined format for the message to request leaving the group 915 (Section 5.2). 917 o Mentioned methods for group rekeying initiated by the KDC 918 (Section 6). 920 o Added security consideration on replay protection (Section 8). 922 o New IANA registries "ACE Groupcomm Key Registry" and "ACE 923 Groupcomm Profile Registry" (Section 9). 925 Acknowledgments 927 The following individuals were helpful in shaping this document: Ben 928 Kaduk, John Mattsson, Jim Schaad, Ludwig Seitz, Goeran Selander and 929 Peter van der Stok. 931 The work on this document has been partly supported by VINNOVA and 932 the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact 933 Initiative ACTIVE. 935 Authors' Addresses 937 Francesca Palombini 938 Ericsson AB 939 Torshamnsgatan 23 940 Kista SE-16440 Stockholm 941 Sweden 943 Email: francesca.palombini@ericsson.com 945 Marco Tiloca 946 RISE AB 947 Isafjordsgatan 22 948 Kista SE-16440 Stockholm 949 Sweden 951 Email: marco.tiloca@ri.se