idnits 2.17.1 draft-ietf-ace-key-groupcomm-03.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 : ---------------------------------------------------------------------------- == There are 15 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 1634 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-25 == Outdated reference: A later version (-16) exists of draft-ietf-ace-oauth-params-05 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-05 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-03) exists of draft-dijk-core-groupcomm-bis-01 == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-08 == Outdated reference: A later version (-17) exists of draft-ietf-ace-mqtt-tls-profile-01 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-08 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 Summary: 2 errors (**), 0 flaws (~~), 10 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: May 7, 2020 RISE AB 6 November 04, 2019 8 Key Provisioning for Group Communication using ACE 9 draft-ietf-ace-key-groupcomm-03 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 May 7, 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Authorization to Join a Group . . . . . . . . . . . . . . . . 6 55 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 6 56 3.2. Authorization Response . . . . . . . . . . . . . . . . . 7 57 3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 8 58 4. Keying Material Provisioning and Group Membership Management 11 59 4.1. Interface at KDC . . . . . . . . . . . . . . . . . . . . 12 60 4.2. Joining Exchange . . . . . . . . . . . . . . . . . . . . 21 61 4.3. Retrieval of Updated Keying Material . . . . . . . . . . 22 62 4.4. Retrieval of New Keying Material . . . . . . . . . . . . 24 63 4.5. Retrieval of Public Keys for Group Members . . . . . . . 24 64 4.6. Retrieval of Group Policies . . . . . . . . . . . . . . . 25 65 4.7. Retrieval of Keying Material Version . . . . . . . . . . 25 66 4.8. Group Leaving Request . . . . . . . . . . . . . . . . . . 26 67 5. Removal of a Node from the Group . . . . . . . . . . . . . . 26 68 6. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 27 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 70 7.1. Update of Keying Material . . . . . . . . . . . . . . . . 29 71 7.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 29 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 73 8.1. ACE Authorization Server Request Creation Hints Registry 30 74 8.2. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 30 75 8.3. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 31 76 8.4. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 32 77 8.5. ACE Groupcomm Policy Registry . . . . . . . . . . . . . . 32 78 8.6. Sequence Number Synchronization Method Registry . . . . . 33 79 8.7. Expert Review Instructions . . . . . . . . . . . . . . . 34 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 34 82 9.2. Informative References . . . . . . . . . . . . . . . . . 35 83 Appendix A. Requirements on Application Profiles . . . . . . . . 37 84 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 39 85 B.1. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 39 86 B.2. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 39 87 B.3. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 40 88 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 91 1. Introduction 93 This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to 94 define the message exchanges used to request, distribute and renew 95 the keying material in a group communication scenario, e.g. based on 96 multicast [RFC7390][I-D.dijk-core-groupcomm-bis] or on publishing- 97 subscribing [I-D.ietf-core-coap-pubsub]. The ACE framework is based 98 on CBOR [RFC7049], so CBOR is the format used in this specification. 99 However, using JSON [RFC8259] instead of CBOR is possible, using the 100 conversion method specified in Sections 4.1 and 4.2 of [RFC7049]. 102 Profiles that use group communication can build on this document, by 103 defining a number of details such as the exact group communication 104 protocol and security protocols used. The specific list of details a 105 profile needs to define is in Appendix A. 107 If the application requires backward and forward security, updated 108 keying material is generated and distributed to the group members 109 (rekeying), when membership changes. A key management scheme 110 performs the actual distribution of the updated keying material to 111 the group. In particular, the key management scheme rekeys the 112 current group members when a new node joins the group, and the 113 remaining group members when a node leaves the group. Rekeying 114 mechanisms can be based on [RFC2093], [RFC2094] and [RFC2627]. 116 1.1. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in BCP 121 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 Readers are expected to be familiar with the terms and concepts 125 described in [I-D.ietf-ace-oauth-authz] and [RFC8152], such as 126 Authorization Server (AS) and Resource Server (RS). 128 This document additionally uses the following terminology: 130 o Transport profile, to indicate a profile of ACE as per 131 Section 5.6.4.3 of [I-D.ietf-ace-oauth-authz]. A transport 132 profile specifies the communication protocol and communication 133 security protocol between an ACE Client and Resource Server, as 134 well as proof-of-possession methods, if it supports proof-of- 135 possession access tokens, etc. Tranport profiles of ACE include, 136 for instance, [I-D.ietf-ace-oscore-profile], 137 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-mqtt-tls-profile]. 139 o Application profile, that defines how applications enforce and use 140 supporting security services they require. These services may 141 include, for instance, provisioning, revocation and 142 (re-)distribution of keying material. An application profile may 143 define specific procedures and message formats. 145 2. Overview 147 +------------+ +-----------+ 148 | AS | | KDC | 149 | | .-------->| | 150 +------------+ / +-----------+ 151 ^ / 152 | / 153 v / +-----------+ 154 +------------+ / +------------+ |+-----------+ 155 | Client |<-' | Dispatcher | ||+-----------+ 156 | |<-------->| (RS) |<------->|| Group | 157 +------------+ +------------+ +| members | 158 +-----------+ 160 Figure 1: Key Distribution Participants 162 The following participants (see Figure 1) take part in the 163 authorization and key distribution. 165 o Client (C): node that wants to join the group communication. It 166 can request write and/or read rights. 168 o Authorization Server (AS): same as AS in the ACE Framework; it 169 enforces access policies, and knows if a node is allowed to join 170 the group with write and/or read rights. 172 o Key Distribution Center (KDC): maintains the keying material to 173 protect group communications, and provides it to Clients 174 authorized to join the group. During the first part of the 175 exchange (Section 3), it takes the role of the RS in the ACE 176 Framework. During the second part (Section 4), which is not based 177 on the ACE Framework, it distributes the keying material. In 178 addition, it provides the latest keying material to group members 179 when requested. If required by the application, the KDC renews 180 and re-distributes the keying material in the group when 181 membership changes. 183 o Dispatcher: entity through which the Clients communicate with the 184 group and which distributes messages to the group members. 185 Examples of dispatchers are: the Broker node in a pub-sub setting; 186 a relayer node for group communication that delivers group 187 messages as multiple unicast messages to all group members; an 188 implicit entity as in a multicast communication setting, where 189 messages are transmitted to a multicast IP address and delivered 190 on the transport channel. 192 This document specifies a mechanism for: 194 o Authorizing a new node to join the group (Section 3), and 195 providing it with the group keying material to communicate with 196 the other group members (Section 4). 198 o A node to leave the group of for the KDC to remove a current 199 member of the group (Section 5). 201 o Retrieving keying material as a current group member (Section 4.3 202 and Section 4.4). 204 o Renewing and re-distributing the group keying material (rekeying) 205 upon a membership change in the group (Section 4.8 and Section 5). 207 Figure 2 provides a high level overview of the message flow for a 208 node joining a group communication setting. 210 C AS KDC Group 211 | | | Member 212 / | | | | 213 | | Authorization Request | | | 214 Defined | |---------------------------->| | | 215 in the | | | | | 216 ACE | | Authorization Response | | | 217 framework | |<----------------------------| | | 218 | | | | 219 \ |----------- Token Post ---------->| | 220 | | | 221 |-------- Joining Request -------->| | 222 | | | 223 |<------- Joining Response --------|-- Group Rekeying -->| 224 | | | 225 | Dispatcher | 226 | | | 227 |<====== Secure group communication ========|===========>| 228 | | | 230 Figure 2: Message Flow Upon New Node's Joining 232 The exchange of Authorization Request and Authorization Response 233 between Client and AS MUST be secured, as specified by the transport 234 profile of ACE used between Client and KDC. 236 The exchange of Joining Request and Joining Response between Client 237 and KDC MUST be secured, as a result of the transport profile of ACE 238 used between Client and KDC. 240 All further communications between the Client and the KDC MUST be 241 secured, for instance with the same security mechanism used for the 242 Key Distribution exchange. 244 All communications between a Client and the other group members MUST 245 be secured using the keying material provided in Section 4. 247 3. Authorization to Join a Group 249 This section describes in detail the format of messages exchanged by 250 the participants when a node requests access to a group. This 251 exchange is based on ACE [I-D.ietf-ace-oauth-authz]. 253 As defined in [I-D.ietf-ace-oauth-authz], the Client requests from 254 the AS an authorization to join the group through the KDC (see 255 Section 3.1). If the request is approved and authorization is 256 granted, the AS provides the Client with a proof-of-possession access 257 token and parameters to securely communicate with the KDC (see 258 Section 3.2). 260 Communications between the Client and the AS MUST be secured, as 261 defined by the transport profile of ACE used. The Content-Format 262 used in the messages is the one specified by the used transport 263 profile of ACE (e.g. application/ace+cbor for the first two messages 264 and application/cwt for the third message, depending on the format of 265 the access token). The transport profile of ACE also defines a 266 number of details such as the communication and security protocols 267 used with the KDC (see Appendix C of [I-D.ietf-ace-oauth-authz]). 269 Figure 3 gives an overview of the exchange described above. 271 Client AS KDC 272 | | | 273 |---- Authorization Request: POST /token ------>| | 274 | | | 275 |<--- Authorization Response: 2.01 (Created) ---| | 276 | | | 277 |----- POST Token: POST /authz-info --------------->| 278 | | 280 Figure 3: Message Flow of Join Authorization 282 3.1. Authorization Request 284 The Authorization Request sent from the Client to the AS is as 285 defined in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MAY 286 contain the following parameters, which, if included, MUST have the 287 corresponding values: 289 o 'scope', containing the identifier of the specific group (or topic 290 in the case of pub-sub) that the Client wishes to access, and 291 optionally the role(s) that the Client wishes to take. This value 292 is a CBOR array encoded as a byte string, which contains: 294 * As first element, the identifier of the specific group or 295 topic. 297 * Optionally, as second element, the role (or CBOR array of 298 roles) the Client wishes to take in the group. 300 The encoding of the group or topic identifier (REQ1) and of the 301 role identifiers (REQ2) is application specific, and part of the 302 requirements for the application profile. 304 o 'audience', with an identifier of a KDC. 306 o 'req_cnf', as defined in Section 3.1 of 307 [I-D.ietf-ace-oauth-params], optionally containing the public key 308 or a reference to the public key of the Client, if it wishes to 309 communicate that to the AS. 311 o Other additional parameters as defined in 312 [I-D.ietf-ace-oauth-authz], if necessary. 314 As in [I-D.ietf-ace-oauth-authz], these parameters are included in 315 the payload, which is formatted as a CBOR map. The Content-Format 316 "application/ace+cbor" defined in Section 8.14 of 317 [I-D.ietf-ace-oauth-authz] is used. 319 3.2. Authorization Response 321 The Authorization Response sent from the AS to the Client is as 322 defined in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST 323 contain the following parameters: 325 o 'access_token', containing the proof-of-possession access token. 327 o 'cnf' if symmetric keys are used, not present if asymmetric keys 328 are used. This parameter is defined in Section 3.2 of 329 [I-D.ietf-ace-oauth-params] and contains the symmetric proof-of- 330 possession key that the Client is supposed to use with the KDC. 332 o 'rs_cnf' if asymmetric keys are used, not present if symmetric 333 keys are used. This parameter is as defined in Section 3.2 of 334 [I-D.ietf-ace-oauth-params] and contains information about the 335 public key of the KDC. 337 o 'exp', contains the lifetime in seconds of the access token. This 338 parameter MAY be omitted if the application defines how the 339 expiration time is communicated to the Client via other means, or 340 if it establishes a default value. 342 Additionally, the Authorization Response MAY contain the following 343 parameters, which, if included, MUST have the corresponding values: 345 o 'scope', which mirrors the 'scope' parameter in the Authorization 346 Request (see Section 3.1). Its value is a CBOR array encoded as a 347 byte string, containing: 349 * As first element, the identifier of the specific group or topic 350 the Client is authorized to access. 352 * Optionally, as second element, the role (or CBOR array of 353 roles) the Client is authorized to take in the group. 355 The encoding of the group or topic identifier and of the role 356 identifiers is the same as in Section 3.1. 358 o Other additional parameters as defined in 359 [I-D.ietf-ace-oauth-authz], if necessary. 361 The access token MUST contain all the parameters defined above 362 (including the same 'scope' as in this message, if present, or the 363 'scope' of the Authorization Request otherwise), and additionally 364 other optional parameters that the transport profile of ACE requires. 366 As in [I-D.ietf-ace-oauth-authz], these parameters are included in 367 the payload, which is formatted as a CBOR map. The Content-Format 368 "application/ace+cbor" is used. 370 When receiving an Authorization Request from a Client that was 371 previously authorized, and which still owns a valid non expired 372 access token, the AS replies with an Authorization Response with a 373 new access token. 375 3.3. Token Post 377 The Client sends a CoAP POST request including the access token to 378 the KDC, as specified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. 379 If the specific transport profile of ACE defines it, the Client MAY 380 use a different endpoint than /authz-info at the KDC to post the 381 access token to. 383 Optionally, the Client might want to request necessary information 384 concerning the public keys in the group, as well as concerning the 385 algorithm and related parameters for computing signatures in the 386 group. In such a case, the joining node MAY ask for that information 387 to the KDC in this same request. To this end, it sends the CoAP POST 388 request to the /authz-info endpoint using the Content-Format 389 "application/ace+cbor". The payload of the message MUST be formatted 390 as a CBOR map, including the access token and the following 391 parameters: 393 o 'sign_info' defined in Section 3.3.1, encoding the CBOR simple 394 value Null, to require information and parameters on the signature 395 algorithm and on the public keys used in the group. 397 o 'pub_key_enc' defined in Section 3.3.2, encoding the CBOR simple 398 value Null, to require information on the exact encoding of public 399 keys used in the group. 401 The CDDL notation of the 'sign_info' and 'pub_key_enc' parameters 402 formatted as in the request is given below. 404 sign_info_req = nil 406 pub_key_enc_req = nil 408 Alternatively, the joining node may retrieve this information by 409 other means. 411 After successful verification, the Client is authorized to receive 412 the group keying material from the KDC and join the group. In 413 particular, the KDC replies to the Client with a 2.01 (Created) 414 response, using Content-Format "application/ace+cbor" defined in 415 Section 8.14 of [I-D.ietf-ace-oauth-authz]. 417 The payload of the 2.01 response is a CBOR map, which MUST include 418 the parameter 'rsnonce' defined in Section Section 3.3.3, specifying 419 a dedicated nonce N_S generated by the KDC. The Client may use this 420 nonce for proving possession of its own private key (see the 421 'client_cred_verify' parameter in Section 4). 423 Optionally, if they were included in the request, the AS MAY include 424 the 'sign_info' parameter as well as the 'pub_key_enc' parameter 425 defined in Section 3.3.1 and Section 3.3.2 of this specification, 426 respectively. 428 The 'sign_info' parameter MUST be present if the POST request 429 included the 'sign_info' parameter with value Null. If present, the 430 'sign_info' parameter of the 2.01 (Created) response is a CBOR array 431 formatted as follows. 433 o The first element 'sign_alg' is an integer or a text string, 434 indicating the signature algorithm used in the group. It is 435 REQUIRED of the application profiles to define specific values for 436 this parameter (REQ3). 438 o The second element 'sign_parameters' indicates the parameters of 439 the signature algorithm. Its structure depends on the value of 440 'sign_alg'. It is REQUIRED of the application profiles to define 441 specific values for this parameter (REQ4). If no parameters of 442 the signature algorithm are specified, 'sign_parameters' MUST be 443 encoded as the CBOR simple value Null. 445 o The third element 'sign_key_parameters' indicates the parameters 446 of the key used with the signature algorithm. Its structure 447 depends on the value of 'sign_alg'. It is REQUIRED of the 448 application profiles to define specific values for this parameter 449 (REQ5). If no parameters of the key used with the signature 450 algorithm are specified, 'sign_key_parameters' MUST be encoded as 451 the CBOR simple value Null. 453 The 'pub_key_enc' parameter MUST be present if the POST request 454 included the 'pub_key_enc' parameter with value Null. If present, 455 the 'pub_key_enc' parameter of the 2.01 (Created) response is a CBOR 456 integer, indicating the encoding of public keys used in the group. 457 Its acceptable values are taken from the "CWT Confirmation Method" 458 Registry defined in [I-D.ietf-ace-cwt-proof-of-possession]. It is 459 REQUIRED of the application profiles to define specific values to use 460 for this parameter (REQ6). 462 The CDDL notation of the 'sign_info' and 'pub_key_enc' parameters 463 formatted as in the response is given below. 465 sign_info_res = [ 466 sign_alg : int / tstr, 467 sign_parameters : any / nil, 468 sign_key_parameters : any / nil 469 ] 471 pub_key_enc_res = int 473 Note that the CBOR map specified as payload of the 2.01 (Created) 474 response may include further parameters, e.g. according to the 475 signalled transport profile of ACE. 477 3.3.1. 'sign_info' Parameter 479 The 'sign_info' parameter is an OPTIONAL parameter of the AS Request 480 Creation Hints message defined in Section 5.1.2. of 481 [I-D.ietf-ace-oauth-authz]. This parameter contains information and 482 parameters about the signature algorithm and the public keys to be 483 used between the Client and the RS. Its exact content is application 484 specific. 486 In this specification and in application profiles building on it, 487 this parameter is used to ask and retrieve from the KDC information 488 about the signature algorithm and related parameters used in the 489 group. 491 3.3.2. 'pub_key_enc' Parameter 493 The 'pub_key_enc' parameter is an OPTIONAL parameter of the AS 494 Request Creation Hints message defined in Section 5.1.2. of 495 [I-D.ietf-ace-oauth-authz]. This parameter contains information 496 about the exact encoding of public keys to be used between the Client 497 and the RS. Its exact content is application specific. 499 In this specification and in application profiles building on it, 500 this parameter is used to ask and retrieve from the KDC information 501 about the encoding of public keys used in the group. 503 3.3.3. 'rsnonce' Parameter 505 The 'rsnonce' parameter is an OPTIONAL parameter of the AS Request 506 Creation Hints message defined in Section 5.1.2. of 507 [I-D.ietf-ace-oauth-authz]. This parameter contains a nonce 508 generated by the RS and provided to the Client. Its exact content is 509 application specific. 511 In this specification and in application profiles building on it, 512 this parameter is used to provide a nonce that the Client may use to 513 prove possession of its own private key in the Joining Request ((see 514 the 'client_cred_verify' parameter in Section 4). 516 4. Keying Material Provisioning and Group Membership Management 518 This section defines the interface available at the KDC. Moreover, 519 this section specifies how the clients can use this interface to join 520 a group, leave a group, retrieve new keying material or policies. 522 During the first exchange with the KDC ("Joining"), the Client sends 523 a request to the KDC, specifying the group it wishes to join (see 524 Section 4.2). Then, the KDC verifies the access token and that the 525 Client is authorized to join that group. If so, it provides the 526 Client with the keying material to securely communicate with the 527 other members of the group. Whenever used, the Content-Format in 528 messages containing a payload is set to application/cbor. 530 TODO: Do we need to define a new Content-Format cbor+ace-groupcomm? 532 When the Client is already a group member, the Client can use the 533 interface at the KDC to perform the following actions: 535 o The Client can (re-)get the current keying material, for cases 536 such as expiration, loss or suspected mismatch, due to e.g. reboot 537 or missed group rekeying. This is described in Section 4.3. 539 o The Client can retrieve a new individual key, or new input 540 material to derive it. This is described in Section 4.4. 542 o The Client can (re-)get the public keys of other group members, 543 e.g. if it is aware of new nodes joining the group after itself. 544 This is described in Section 4.5. 546 o The Client can (re-)get the policies currently enforced in the 547 group. This is described in Section 4.6. 549 o The Client can (re-)get the version number of the keying material 550 currently used in the group. This is described in Section 4.7. 552 o The Client can request to leave the group. This is further 553 discussed in Section 4.8. 555 Upon receiving a request from a Client, the KDC MUST check that it is 556 storing a valid access token from that Client for the group 557 identifier assiciated to the endpoint. If that is not the case, i.e. 558 the KDC does not store a valid access token or this is not valid for 559 that Client for the group identifier at hand, the KDC MUST respond to 560 the Client with a 4.01 (Unauthorized) error message. 562 4.1. Interface at KDC 564 The KDC is configured with the following resources: 566 o /ace-group : this resource is fixed and indicates that this 567 specification is used. Other applications that run on a KDC 568 implementing this specification MUST NOT use this same resource. 570 o /ace-group/gid : one sub-resource to /ace-group is implemented for 571 each group the KDC manages. These resources are identified by the 572 group identifiers of the groups the KDC manages (in this example, 573 the group identifier has value "gid"). These resources support 574 GET and POST method. 576 o /ace-group/gid/pub-key : this sub-resource is fixed and supports 577 GET and POST methods. 579 o /ace-group/gid/policies: this sub-resource is fixed and supports 580 the GET method. 582 o /ace-group/gid/ctx-num: this sub-resource is fixed and supports 583 the GET method. 585 o /ace-group/gid/node: this sub-resource is fixed and supports GET 586 and POST methods. 588 The details for the handlers of each resource are given in the 589 following sections. These endpoints are used to perform the 590 operations introduced in Section 4. Note that the url-path given 591 here are default names: implementations are not required to use these 592 names, and can define their own instead. 594 4.1.1. ace-group 596 No handlers are implemented for this resource. 598 4.1.2. ace-group/gid 600 This resource implements GET and POST handlers. 602 4.1.2.1. POST Handler 604 The POST handler adds the public key of the client to the list of the 605 group members' public keys and returns the symmetric group keying 606 material for the group identified by "gid". 608 The handler expects a request with payload formatted as a CBOR map 609 which MAY contain the following fields, which, if included, MUST have 610 the corresponding values: 612 o 'scope', with value the specific resource that the Client is 613 authorized to access (i.e. group or topic identifier) and role(s), 614 encoded as in Section 3.1. 616 o 'get_pub_keys', if the Client wishes to receive the public keys of 617 the other nodes in the group from the KDC. The value is an empty 618 CBOR array. This parameter may be present if the KDC stores the 619 public keys of the nodes in the group and distributes them to the 620 Client; it is useless to have here if the set of public keys of 621 the members of the group is known in another way, e.g. it was 622 provided by the AS. 624 o 'client_cred', with value the public key or certificate of the 625 Client, encoded as a CBOR byte string. If the KDC is managing 626 (collecting from/distributing to the Client) the public keys of 627 the group members, this field contains the public key of the 628 Client. The default encoding for public keys is COSE Keys. 629 Alternative specific encodings of this parameter MAY be defined in 630 applications of this specification (OPT1). 632 o 'cnonce', as defined in Section 5.1.2 of 633 [I-D.ietf-ace-oauth-authz], and including a dedicated nonce N_C 634 generated by the Client. This parameter MUST be present if the 635 'client_cred' parameter is present. 637 o 'client_cred_verify', encoded as a CBOR byte string. This 638 parameter MUST be present if the 'client_cred' parameter is 639 present. This parameter contains a signature computed by the 640 Client over N_S concatenated with N_C, where N_S is the nonce 641 received from the KDC in the 'rsnonce' parameter of the 2.01 642 (Created) response to the token POST request (see Section 3.3), 643 while N_C is the nonce generated by the Client and specified in 644 the 'cnonce' parameter above. The Client computes the signature 645 by using its own private key, whose corresponding public key is 646 either directly specified in the 'client_cred' parameter or 647 included in the certificate specified in the 'client_cred' 648 parameter. 650 o 'pub_keys_repos', can be present if a certificate is present in 651 the 'client_cred' field, with value a list of public key 652 repositories storing the certificate of the Client. This 653 parameter is encoded as a CBOR array of CBOR text strings, each of 654 which specifies the URI of a key repository. 656 The handler verifies that the group identifier of the /ace-group/gid 657 path is a subset of the 'scope' stored in the access token associated 658 to this client. If verification fails, the KDC MUST respond with a 659 4.01 (Unauthorized) error message. 661 If the request is not formatted correctly (e.g. unknown fields 662 present), the handler MUST respond with 4.00 (Bad Request) error 663 message. 665 If verification succeeds, the handler adds the public key indicated 666 in "client_cred" to the list of public keys stored for the group 667 identified by "gid". The handler returns a 2.01 (Created) message 668 containing the symmetric group keying material, the group policies 669 and all the public keys of the current members of the group, if the 670 KDC manages those and the Client requested them. The payload of the 671 response is formatted as a CBOR map which MAY contain the following 672 fields, which, if included, MUST have the corresponding values: 674 o 'kty', identifying the key type of the 'key' parameter. The set 675 of values can be found in the "Key Type" column of the "ACE 676 Groupcomm Key" Registry. Implementations MUST verify that the key 677 type matches the application profile being used, if present, as 678 registered in the "ACE Groupcomm Key" registry. 680 o 'key', containing the keying material for the group communication, 681 or information required to derive it. 683 o 'num', containing the version number of the keying material for 684 the group communication, formatted as an integer. The initial 685 version MUST be set to 0 at the KDC. 687 The exact format of the 'key' value MUST be defined in applications 688 of this specification (REQ7), as well as accepted values of 'kty' by 689 the application (REQ8). Additionally, documents specifying the key 690 format MUST register it in the "ACE Groupcomm Key" registry defined 691 in Section 8.3, including its name, type and application profile to 692 be used with. 694 +----------+----------------+---------+-------------------------+ 695 | Name | Key Type Value | Profile | Description | 696 +----------+----------------+---------+-------------------------+ 697 | Reserved | 0 | | This value is reserved | 698 +----------+----------------+---------+-------------------------+ 700 Figure 4: Key Type Values 702 Optionally, the response MAY contain the following parameters, which, 703 if included, MUST have the corresponding values: 705 o 'profile', with value a CBOR integer that MUST be used to uniquely 706 identify the application profile for group communication. The 707 value MUST be registered in the "ACE Groupcomm Profile" Registry. 709 o 'exp', with value the expiration time of the keying material for 710 the group communication, encoded as a CBOR unsigned integer or 711 floating-point number. This field contains a numeric value 712 representing the number of seconds from 1970-01-01T00:00:00Z UTC 713 until the specified UTC date/time, ignoring leap seconds, 714 analogous to what specified in Section 2 of [RFC7519]. 716 o 'pub_keys', may only be present if 'get_pub_keys' was present in 717 the request. This parameter is a CBOR byte string, which encodes 718 the public keys of all the group members paired with the 719 respective member identifiers. The default encoding for public 720 keys is COSE Keys, so the default encoding for 'pub_keys' is a 721 CBOR byte string wrapping a COSE_KeySet (see [RFC8152]), which 722 contains the public keys of all the members of the group. In 723 particular, each COSE Key in the COSE_KeySet includes the 724 identifier of the corresponding group member as value of its 'kid' 725 key parameter. Alternative specific encodings of this parameter 726 MAY be defined in applications of this specification (OPT2). The 727 specific format of the identifiers of group members MUST be 728 specified in the application profile (REQ8). 730 o 'group_policies', with value a CBOR map, whose entries specify how 731 the group handles specific management aspects. These include, for 732 instance, approaches to achieve synchronization of sequence 733 numbers among group members. The elements of this field are 734 registered in the "ACE Groupcomm Policy" Registry. This 735 specification defines the two elements "Sequence Number 736 Synchronization Method" and "Key Update Check Interval", which are 737 summarized in Figure 5. Application profiles that build on this 738 document MUST specify the exact content format of included map 739 entries (REQ9). 741 +-----------------+-------+----------|--------------------|------------+ 742 | Name | CBOR | CBOR | Description | Reference | 743 | | label | type | | | 744 |-----------------+-------+----------|--------------------|------------| 745 | Sequence Number | TBD1 | tstr/int | Method for a re- | [[this | 746 | Synchronization | | | cipient node to | document]] | 747 | Method | | | synchronize with | | 748 | | | | sequence numbers | | 749 | | | | of a sender node. | | 750 | | | | Its value is taken | | 751 | | | | from the 'Value' | | 752 | | | | column of the | | 753 | | | | Sequence Number | | 754 | | | | Synchronization | | 755 | | | | Method registry | | 756 | | | | | | 757 | Key Update | TBD2 | int | Polling interval | [[this | 758 | Check Interval | | | in seconds, to | document]] | 759 | | | | check for new | | 760 | | | | keying material at | | 761 | | | | the KDC | | 762 +-----------------+-------+----------|--------------------|------------+ 764 Figure 5: ACE Groupcomm Policies 766 o 'mgt_key_material', encoded as a CBOR byte string and containing 767 the administrative keying material to participate in the group 768 rekeying performed by the KDC. The exact format and content 769 depend on the specific rekeying scheme used in the group, which 770 MAY be specified in the application profile (OPT3). 772 Specific application profiles that build on this document MUST 773 specify how exactly the keying material is used to protect the group 774 communication (REQ10). 776 CBOR labels for these fields are defined in Section 6. 778 4.1.2.2. GET Handler 780 The GET handler returns the symmetric group keying material for the 781 group identified by "gid". 783 The handler expects a GET request. 785 The handler verifies that the group identifier of the /ace-group/gid 786 path is a subset of the 'scope' stored in the access token associated 787 to this client. If verification fails, the KDC MUST respond with a 788 4.01 (Unauthorized) error message. 790 If verification succeeds, the handler returns a 2.05 (Content) 791 message containing the symmetric group keying material, the group 792 policies and all the public keys of the current members of the group. 793 The payload of the response is formatted as a CBOR map which MUST 794 contain the parameters 'kty','key' and 'num' specified in 795 Section 4.1.2.1. 797 The payload MAY also include the parameters 'profile', 'exp' and 798 'mgt_key_material' parameters specified in Section 4.1.2.1. 800 4.1.3. ace-group/gid/pub-key 802 This resource implements GET and POST handlers. 804 4.1.3.1. POST Handler 806 The POST handler receives identifiers of group members for the group 807 identified by "gid" and returns the public keys of such group 808 members. 810 The handler expects a request with payload formatted as a CBOR map. 811 The payload of this request is a CBOR Map that MUST contain the 812 following fields: 814 o 'get_pub_keys', whose value is a non-empty CBOR array. Each 815 element of the array is the identifier of a group member for the 816 group identified by "gid". The specific format of public keys as 817 well as identifiers of group members MUST be specified by the 818 application profile (REQ11, REQ8). 820 The handler verifies that the group identifier of the /ace-group/gid 821 path is a subset of the 'scope' stored in the access token associated 822 to this client. If verification fails, the KDC MUST respond with a 823 4.01 (Unauthorized) error message. 825 The handler verifies that the 'get_pub_keys' parameter is not an 826 empty CBOR Array. If verification fails, the KDC MUST treat the 827 request as malformed and respond with a 4.00 (Bad Request) error 828 message. 830 If verification succeeds, the handler identifies the public keys of 831 the current group members for which the identifier matches with one 832 of those indicated in the request. Then, the handler returns a 2.05 833 (Content) message response with payload formatted as a CBOR map 834 containing only the 'pub_keys' parameter from Section 4.1.2.1, which 835 encodes the list of public keys of those group members including the 836 respective member identifiers. If the KDC does not store any public 837 key associated with the specified member identifiers, the handler 838 returns a response with payload formatted as a CBOR byte string of 839 zero length. The specific format of public keys as well as of 840 identifiers of group members is specified by the application profile 841 (REQ11, REQ8). 843 The handler MAY enforce one of the following policies, in order to 844 handle possible identifiers that are included in the 'get_pub_keys' 845 parameter of the request but are not associated to any current group 846 member. Such a policy MUST be specified by the application profile 847 (REQ12) 849 o The KDC silently ignores those identifiers. 851 o The KDC retains public keys of group members for a given amount of 852 time after their leaving, before discarding them. As long as such 853 public keys are retained, the KDC provides them to a requesting 854 Client. 856 4.1.3.2. GET Handler 858 The handler expects a GET request. 860 The handler verifies that the group identifier of the /ace-group/gid 861 path is a subset of the 'scope' stored in the access token associated 862 to this client. If verification fails, the KDC MUST respond with a 863 4.01 (Unauthorized) error message. 865 If verification succeeds, the handler returns a 2.05 (Content) 866 message containing the public keys of all the current group members, 867 for the group identified by "gid". The payload of the response is 868 formatted as a CBOR map containing only the 'pub_keys' parameter from 869 Section 4.1.2.1, which encodes the list of public keys of all the 870 group members including the respective member identifiers. If the 871 KDC does not store any public key for the group, the handler returns 872 a response with payload formatted as a CBOR byte string of zero 873 length. The specific format of public keys as well as of identifiers 874 of group members is specified by the application profile (REQ11, 875 REQ8). 877 4.1.4. ace-group/gid/policies 879 This resource implements a GET handler. 881 4.1.4.1. GET Handler 883 The handler expects a GET request. 885 The handler verifies that the group identifier of the /ace-group/gid 886 path is a subset of the 'scope' stored in the access token associated 887 to this client. If verification fails, the KDC MUST respond with a 888 4.01 (Unauthorized) error message. 890 If verification succeeds, the handler returns a 2.05 (Content) 891 message containing the list of policies for the group identified by 892 "gid". The payload of the response is formatted as a CBOR map 893 including only the parameter 'group_policies' defined in 894 Section 4.1.2.1 and specifying the current policies in the group. If 895 the KDC does not store any policy, the payload is formatted as a 896 zero-length CBOR byte string. 898 The specific format and meaning of group policies MUST be specified 899 in the application profile (REQ13). 901 4.1.5. ace-group/gid/ctx-num 903 This resource implements a GET handler. 905 4.1.5.1. GET Handler 907 The handler expects a GET request. 909 The handler verifies that the group identifier of the /ace-group/gid 910 path is a subset of the 'scope' stored in the access token associated 911 to this client. If verification fails, the KDC MUST respond with a 912 4.01 (Unauthorized) error message. 914 If verification succeeds, the handler returns a 2.05 (Content) 915 message containing an integer that represents the version number of 916 the symmetric group keying material. This number is incremented on 917 the KDC every time the KDC updates the symmetric group keying 918 material. The payload of the response is formatted as a CBOR 919 integer. 921 4.1.6. ace-group/gid/node 923 This resource implements GET and POST handlers. 925 4.1.6.1. POST Handler 927 The POST handler removes the node from the group, for the group 928 identified by "gid". 930 The handler expects a request with payload formatted as a CBOR map. 931 The payload of this request is a CBOR Map that MAY contain only the 932 'scope' field as specified in Section 4.1.2.1. 934 The handler verifies that the group identifier of the /ace-group/gid 935 path is a subset of the 'scope' stored in the access token associated 936 to this client. If verification fails, the KDC MUST respond with a 937 4.01 (Unauthorized) error message. 939 If the request contained a 'scope' field, the handler MUST extract 940 the roles for that client. If the value is such that the KDC cannot 941 extract all the necessary information to understand and process it 942 correctly (e.g. unrecognized roles), the KDC MUST respond with a 4.00 943 (Bad Request) error message. 945 If verification succeeds, the handler removes the client from the 946 group identified by "gid", for specific roles if roles were specified 947 in the 'scope' field, or for all roles. That includes removing the 948 public key of the client if the KDC keep tracks of that. Then, the 949 handler returns a 2.05 (Content) message with empty payload. 951 4.1.6.2. GET Handler 953 The handler expects a GET request. 955 The handler verifies that the group identifier of the /ace-group/gid 956 path is a subset of the 'scope' stored in the access token associated 957 to this client. If verification fails, the KDC MUST respond with a 958 4.01 (Unauthorized) error message. 960 If verification succeeds, the handler returns a 2.05 (Content) 961 message containing newly-generated individual keying material for the 962 Client, or information enabling the Client to derive it. The payload 963 of the response is formatted as a CBOR map. The specific format of 964 newly-generated individual keying material for group members, or of 965 the information to derive it, and corresponding CBOR label, MUST be 966 specified in the application profile (REQ14) and registered in 967 Section 8.2. 969 4.2. Joining Exchange 971 Figure 6 gives an overview of the Joining exchange between Client and 972 KDC, when the Client first joins a group. 974 Client KDC 975 | | 976 |-------- Joining Request: POST /ace-group/gid --------->| 977 | | 978 |<--------- Joining Response: 2.01 (Created) ----------- | 979 | | 981 Figure 6: Message Flow of First Exchange for Group Joining 983 If not previously established, the Client and the KDC MUST first 984 establish a pairwise secure communication channel (REQ15). This can 985 be achieved, for instance, by using a transport profile of ACE. The 986 Joining exchange MUST occur over that secure channel. The Client and 987 the KDC MAY use that same secure channel to protect further pairwise 988 communications that must be secured. 990 The secure communication protocol is REQUIRED to establish the secure 991 channel by using the proof-of-possession key bound to the access 992 token. As a result, the proof-of-possession to bind the access token 993 to the Client is performed by using the proof-of-possession key bound 994 to the access token for establishing secure communication between the 995 Client and the KDC. 997 To join the group, the Client sends a CoAP POST request to the /ace- 998 group/gid endpoint at the KDC, where gid is the group identifier of 999 the group to join, formatted as specified in Section 4.1.2.1. This 1000 group identifier is the same as the 'scope' value of the 1001 Authorization Request/Response, or it can be retrieved from it. 1003 If the application requires backward security, the KDC MUST generate 1004 new group keying material and securely distribute it to all the 1005 current group members, upon a new node's joining the group. To this 1006 end, the KDC uses the message format of the Joining Response (see 1007 Section 4.1.2.1). Application profiles may define alternative ways 1008 of retrieving the keying material, such as sending separate requests 1009 to different resources at the KDC (Section 4.1.2.2, Section 4.1.3.2, 1010 Section 4.1.4.1). After distributing the new group keying material, 1011 the KDC MUST increment the version number of the keying material. 1013 4.3. Retrieval of Updated Keying Material 1015 A node stops using the group keying material upon its expiration, 1016 according to what indicated by the KDC with the 'exp' parameter in a 1017 Joining response, or to a pre-configured value. Then, if it wants to 1018 continue participating in the group communication, the node has to 1019 request new updated keying material from the KDC. 1021 The Client may need to request the latest group keying material also 1022 upon receiving messages from other group members without being able 1023 to retrieve the material to correctly decrypt them. This may be due 1024 to a previous update of the group keying material (rekeying) 1025 triggered by the KDC, that the Client was not able to receive or 1026 decrypt. To this end, the Client sends a CoAP GET request to the 1027 /ace-group/gid endpoint at the KDC, formatted as specified in 1028 Section 4.1.2.2. 1030 Note that policies can be set up so that the Client sends a Key Re- 1031 Distribution Request to the KDC only after a given number of 1032 unsuccessfully decrypted incoming messages. It is application 1033 dependent and pertaining to the particular message exchange (e.g. 1034 [I-D.ietf-core-oscore-groupcomm]) to set up policies that instruct 1035 clients to retain unsuccessfully decrypted messages and for how long, 1036 so that they can be decrypted after getting updated keying material, 1037 rather than just considered non valid messages to discard right away 1038 (OPT4). 1040 The same Key Distribution Request could also be sent by the Client 1041 without being triggered by a failed decryption of a message, if the 1042 Client wants to be sure that it has the latest group keying material. 1043 If that is the case, the Client will receive from the KDC the same 1044 group keying material it already has in memory. 1046 Figure 7 gives an overview of the exchange described above. 1048 Client KDC 1049 | | 1050 |----- Key Distribution Request: GET ace-group/gid ----->| 1051 | | 1052 |<----- Key Distribution Response: 2.05 (Content) -------| 1053 | | 1055 Figure 7: Message Flow of Key Distribution Request-Response 1057 Alternatively, the re-distribution of keying material can be 1058 initiated by the KDC, which e.g.: 1060 o Can make the ace-group/gid resource Observable, and send 1061 notifications to Clients when the keying material is updated. 1063 o Can send the Key Distribution Response as one or multiple 1064 multicast requests to the members of the group, using secure 1065 rekeying schemes such as [RFC2093][RFC2094][RFC2627]. 1067 o Can send unicast requests to each Client over a secure channel, 1068 with the same payload as the Key Distribution Response. 1070 o Can act as a publisher in a pub-sub scenario, and update the 1071 keying material by publishing on a specific topic on a broker, 1072 which all the members of the group are subscribed to. 1074 Note that these methods of KDC-initiated key distribution have 1075 different security properties and require different security 1076 associations. 1078 4.4. Retrieval of New Keying Material 1080 Beside possible expiration and depending on what part of the keying 1081 material is no longer eligible to be used, the client may need to 1082 communicate to the KDC its need for that part to be renewed. For 1083 example, if the Client uses an individual key to protect outgoing 1084 traffic and has to renew it, the node may request a new one, or new 1085 input material to derive it, without renewing the whole group keying 1086 material. To this end, the client performs a Key Renewal Request/ 1087 Response exchange with the KDC, that is a CoAP GET request to the 1088 /ace-group/gid/node endpoint at the KDC, where gid is the group 1089 identifier, and formatted as defined in Section 4.1.6.2. 1091 Figure 8 gives an overview of the exchange described above. 1093 Client KDC 1094 | | 1095 |---- Key Renewal Request: GET ace-group/gid/node --->| 1096 | | 1097 |<----- Key Renewal Response: 2.05 (Content) ---------| 1098 | | 1100 Figure 8: Message Flow of Key Renewal Request-Response 1102 Note the difference between the Key Distribution Request and the Key 1103 Renewal Request: while the first one only triggers distribution (the 1104 renewal might have happened independently, e.g. because of 1105 expiration), the second one triggers the KDC to produce new 1106 individual keying material for the requesting node. 1108 4.5. Retrieval of Public Keys for Group Members 1110 In case the KDC maintains the public keys of group members, a node in 1111 the group can contact the KDC to request public keys of either all 1112 group members or a specified subset, by sending a CoAP GET or POST 1113 request to the /ace-group/gid/pub-key endpoint at the KDC, where gid 1114 is the group identifier, and formatted as defined in Section 4.1.3.2 1115 and Section 4.1.3.1. 1117 Figure 9 and Figure 10 give an overview of the exchanges described 1118 above. 1120 Client KDC 1121 | | 1122 |---- Public Key Request: GET /ace-group/gid/pub-key --->| 1123 | | 1124 |<--------- Public Key Response: 2.05 (Content) ---------| 1125 | | 1127 Figure 9: Message Flow of Public Key Exchange to Request All Members 1128 Public Keys 1130 Client KDC 1131 | | 1132 |--- Public Key Request: POST /ace-group/gid/pub-key --->| 1133 | | 1134 |<--------- Public Key Response: 2.01 (Created) ---------| 1135 | | 1137 Figure 10: Message Flow of Public Key Exchange to Request Specific 1138 Members Public Keys 1140 4.6. Retrieval of Group Policies 1142 A node in the group can contact the KDC to retrieve the current group 1143 policies, by sending a CoAP GET request to the /ace-group/gid/ 1144 policies endpoint at the KDC, where gid is the group identifier, and 1145 formatted as defined in Section 4.1.4.1 1147 Figure 11 gives an overview of the exchange described above. 1149 Client KDC 1150 | | 1151 |--- Policies Request: GET ace-group/gid/policies ---->| 1152 | | 1153 |<--------- Policies Response: 2.05 (Content) ---------| 1154 | | 1156 Figure 11: Message Flow of Policies Request-Response 1158 4.7. Retrieval of Keying Material Version 1160 A node in the group can contact the KDC to request information about 1161 the version number of the symmetric group keying material, by sending 1162 a CoAP GET request to the /ace-group/gid/ctx-num endpoint at the KDC, 1163 where gid is the group identifier, formatted as defined in 1164 Section 4.1.5.1. In particular, the version is incremented by the 1165 KDC every time the group keying material is renewed. 1167 Figure 12 gives an overview of the exchange described above. 1169 Client KDC 1170 | | 1171 |----- Version Request: GET ace-group/gid/ctx-num ----->| 1172 | | 1173 |<--------- Version Response: 2.05 (Content) -----------| 1174 | | 1176 Figure 12: Message Flow of Version Request-Response 1178 4.8. Group Leaving Request 1180 A node can actively request to leave the group. In this case, the 1181 Client sends a CoAP POST request to the endpoint /ace-group/gid/node 1182 at the KDC, where gid is the group identifier, formatted as defined 1183 in Section 4.1.6.1 1185 Alternatively, a node may be removed by the KDC, without having 1186 explicitly asked for it. This is further discussed in Section 5. 1188 5. Removal of a Node from the Group 1190 This section describes the different scenarios according to which a 1191 node ends up being removed from the group. 1193 If the application requires forward security, the KDC MUST generate 1194 new group keying material and securely distribute it to all the 1195 current group members but the leaving node, using the message format 1196 of the Key Distribution Response (see Section 4.3). Application 1197 profiles may define alternative message formats. Once distributed 1198 the new group keying material, the KDC MUST increment the version 1199 number of the keying material. 1201 Note that, after having left the group, a node may wish to join it 1202 again. Then, as long as the node is still authorized to join the 1203 group, i.e. it still has a valid access token, it can re-request to 1204 join the group directly to the KDC without needing to retrieve a new 1205 access token from the AS. This means that the KDC might decide to 1206 keep track of nodes with valid access tokens, before deleting all 1207 information about the leaving node. 1209 A node may be evicted from the group in the following cases. 1211 1. The node explicitly asks to leave the group, as defined in 1212 Section 4.8. 1214 2. The node has been found compromised or is suspected so. 1216 3. The node's authorization to be a group member is expired. If the 1217 AS provides Token introspection (see Section 5.7 of 1218 [I-D.ietf-ace-oauth-authz]), the KDC can optionally use and check 1219 whether: 1221 * the node is not authorized anymore; 1223 * the access token is still valid, upon its expiration. 1225 Either case, once aware that a node is not authorized anymore, 1226 the KDC has to remove the unauthorized node from the list of 1227 group members, if the KDC keeps track of that. 1229 6. ACE Groupcomm Parameters 1231 This specification defines a number of fields used during the second 1232 part of the message exchange, after the ACE Token POST exchange. The 1233 table below summarizes them, and specifies the CBOR key to use 1234 instead of the full descriptive name. 1236 +--------------------+--------+-----------------------+-------------+ 1237 | Name | CBOR | CBOR Type | Reference | 1238 | | Key | | | 1239 +--------------------+--------+-----------------------+-------------+ 1240 | scope | TBD | array | Section | 1241 | | | | 4.1.2.1 | 1242 | | | | | 1243 | get_pub_keys | TBD | array | Section | 1244 | | | | 4.1.2.1 | 1245 | | | | | 1246 | client_cred | TBD | byte string | Section | 1247 | | | | 4.1.2.1 | 1248 | | | | | 1249 | cnonce | TBD | byte string | Section | 1250 | | | | 4.1.2.1 | 1251 | | | | | 1252 | client_cred_verify | TBD | byte string | Section | 1253 | | | | 4.1.2.1 | 1254 | | | | | 1255 | pub_keys_repos | TBD | array | Section | 1256 | | | | 4.1.2.1 | 1257 | | | | | 1258 | kty | TBD | int / byte string | Section | 1259 | | | | 4.1.2.1 | 1260 | | | | | 1261 | key | TBD | see "ACE Groupcomm | Section | 1262 | | | Key" Registry | 4.1.2.1 | 1263 | | | | | 1264 | num | TBD | int | Section | 1265 | | | | 4.1.2.1 | 1266 | | | | | 1267 | profile | TBD | int | Section | 1268 | | | | 4.1.2.1 | 1269 | | | | | 1270 | exp | TBD | int / float | Section | 1271 | | | | 4.1.2.1 | 1272 | | | | | 1273 | pub_keys | TBD | byte string | Section | 1274 | | | | 4.1.2.1 | 1275 | | | | | 1276 | group_policies | TBD | map | Section | 1277 | | | | 4.1.2.1 | 1278 | | | | | 1279 | mgt_key_material | TBD | byte string | Section | 1280 | | | | 4.1.2.1 | 1281 | | | | | 1282 | get_pub_keys | TBD | array | Section | 1283 | | | | 4.1.3.1 | 1284 +--------------------+--------+-----------------------+-------------+ 1286 7. Security Considerations 1288 When a Client receives a message from a sender for the first time, it 1289 needs to have a mechanism in place to avoid replay, e.g. 1290 Appendix B.2 of [RFC8613]. 1292 The KDC must renew the group keying material upon its expiration. 1294 The KDC should renew the keying material upon group membership 1295 change, and should provide it to the current group members through 1296 the rekeying scheme used in the group. 1298 The KDC may enforce a rekeying policy that takes into account the 1299 overall time required to rekey the group, as well as the expected 1300 rate of changes in the group membership. 1302 That is, the KDC may not rekey the group at every membership change, 1303 for instance if members' joining and leaving occur frequently and 1304 performing a group rekeying takes too long. Instead, the KDC may 1305 rekey the group after a minum number of group members have joined or 1306 left within a given time interval, or during predictable network 1307 inactivity periods. 1309 However, this would result in the KDC not constantly preserving 1310 backward and forward security. In fact, newly joining group members 1311 could be able to access the keying material used before their 1312 joining, and thus could access past group communications. Also, 1313 until the KDC performs a group rekeying, the newly leaving nodes 1314 would still be able to access upcoming group communications that are 1315 protected with the keying material that has not yet been updated. 1317 7.1. Update of Keying Material 1319 A group member can receive a message shortly after the group has been 1320 rekeyed, and new keying material has been distributed by the KDC. In 1321 the following two cases, this may result in misaligned keying 1322 material between the group members. 1324 In the first case, the sender protects a message using the old keying 1325 material. However, the recipient receives the message after having 1326 received the new keying material, hence not being able to correctly 1327 process it. A possible way to ameliorate this issue is to preserve 1328 the old, recent, keying material for a maximum amount of time defined 1329 by the application. By doing so, the recipient can still try to 1330 process the received message using the old retained keying material 1331 as second attempt. Note that a former (compromised) group member can 1332 take advantage of this by sending messages protected with the old 1333 retained keying material. Therefore, a conservative application 1334 policy should not admit the storage of old keying material. 1336 In the second case, the sender protects a message using the new 1337 keying material, but the recipient receives that request before 1338 having received the new keying material. Therefore, the recipient 1339 would not be able to correctly process the request and hence discards 1340 it. If the recipient receives the new keying material shortly after 1341 that and the sender endpoint uses CoAP retransmissions, the former 1342 will still be able to receive and correctly process the message. In 1343 any case, the recipient should actively ask the KDC for an updated 1344 keying material according to an application-defined policy, for 1345 instance after a given number of unsuccessfully decrypted incoming 1346 messages. 1348 A node that has left the group should not expect any of its outgoing 1349 messages to be successfully processed, if received after its leaving, 1350 due to a possible group rekeying occurred before the message 1351 reception. 1353 7.2. Block-Wise Considerations 1355 If the block-wise options [RFC7959] are used, and the keying material 1356 is updated in the middle of a block-wise transfer, the sender of the 1357 blocks just changes the keying material to the updated one and 1358 continues the transfer. As long as both sides get the new keying 1359 material, updating the keying material in the middle of a transfer 1360 will not cause any issue. Otherwise, the sender will have to 1361 transmit the message again, when receiving an error message from the 1362 recipient. 1364 Compared to a scenario where the transfer does not use block-wise, 1365 depending on how fast the keying material is changed, the nodes might 1366 consume a larger amount of the network bandwidth resending the blocks 1367 again and again, which might be problematic. 1369 8. IANA Considerations 1371 This document has the following actions for IANA. 1373 8.1. ACE Authorization Server Request Creation Hints Registry 1375 IANA is asked to register the following entries in the "ACE 1376 Authorization Server Request Creation Hints" Registry defined in 1377 Section 8.1 of [I-D.ietf-ace-oauth-authz]. 1379 o Name: sign_info 1381 o CBOR Key: TBD (range -256 to 255) 1383 o Value Type: any 1385 o Reference: [[This specification]] 1387 o Name: pub_key_enc 1389 o CBOR Key: TBD (range -256 to 255) 1391 o Value Type: integer 1393 o Reference: [[This specification]] 1395 o Name: rsnonce 1397 o CBOR Key: TBD (range -256 to 255) 1399 o Value Type: byte string 1401 o Reference: [[This specification]] 1403 8.2. ACE Groupcomm Parameters Registry 1405 This specification establishes the "ACE Groupcomm Parameters" IANA 1406 Registry. The Registry has been created to use the "Expert Review 1407 Required" registration procedure [RFC8126]. Expert review guidelines 1408 are provided in Section 8.7. 1410 The columns of this Registry are: 1412 o Name: This is a descriptive name that enables easier reference to 1413 the item. The name MUST be unique. It is not used in the 1414 encoding. 1416 o CBOR Key: This is the value used as CBOR key of the item. These 1417 values MUST be unique. The value can be a positive integer, a 1418 negative integer, or a string. 1420 o CBOR Type: This contains the CBOR type of the item, or a pointer 1421 to the registry that defines its type, when that depends on 1422 another item. 1424 o Reference: This contains a pointer to the public specification for 1425 the item. 1427 This Registry has been initially populated by the values in 1428 Section 6. The Reference column for all of these entries refers to 1429 sections of this document. 1431 8.3. ACE Groupcomm Key Registry 1433 This specification establishes the "ACE Groupcomm Key" IANA Registry. 1434 The Registry has been created to use the "Expert Review Required" 1435 registration procedure [RFC8126]. Expert review guidelines are 1436 provided in Section 8.7. 1438 The columns of this Registry are: 1440 o Name: This is a descriptive name that enables easier reference to 1441 the item. The name MUST be unique. It is not used in the 1442 encoding. 1444 o Key Type Value: This is the value used to identify the keying 1445 material. These values MUST be unique. The value can be a 1446 positive integer, a negative integer, or a string. 1448 o Profile: This field may contain one or more descriptive strings of 1449 application profiles to be used with this item. The values should 1450 be taken from the Name column of the "ACE Groupcomm Profile" 1451 Registry. 1453 o Description: This field contains a brief description of the keying 1454 material. 1456 o References: This contains a pointer to the public specification 1457 for the format of the keying material, if one exists. 1459 This Registry has been initially populated by the values in Figure 4. 1460 The specification column for all of these entries will be this 1461 document. 1463 8.4. ACE Groupcomm Profile Registry 1465 This specification establishes the "ACE Groupcomm Profile" IANA 1466 Registry. The Registry has been created to use the "Expert Review 1467 Required" registration procedure [RFC8126]. Expert review guidelines 1468 are provided in Section 8.7. It should be noted that, in addition to 1469 the expert review, some portions of the Registry require a 1470 specification, potentially a Standards Track RFC, be supplied as 1471 well. 1473 The columns of this Registry are: 1475 o Name: The name of the application profile, to be used as value of 1476 the profile attribute. 1478 o Description: Text giving an overview of the application profile 1479 and the context it is developed for. 1481 o CBOR Value: CBOR abbreviation for the name of this application 1482 profile. Different ranges of values use different registration 1483 policies [RFC8126]. Integer values from -256 to 255 are 1484 designated as Standards Action. Integer values from -65536 to 1485 -257 and from 256 to 65535 are designated as Specification 1486 Required. Integer values greater than 65535 are designated as 1487 Expert Review. Integer values less than -65536 are marked as 1488 Private Use. 1490 o Reference: This contains a pointer to the public specification of 1491 the abbreviation for this application profile, if one exists. 1493 8.5. ACE Groupcomm Policy Registry 1495 This specification establishes the "ACE Groupcomm Policy" IANA 1496 Registry. The Registry has been created to use the "Expert Review 1497 Required" registration procedure [RFC8126]. Expert review guidelines 1498 are provided in Section 8.7. It should be noted that, in addition to 1499 the expert review, some portions of the Registry require a 1500 specification, potentially a Standards Track RFC, be supplied as 1501 well. 1503 The columns of this Registry are: 1505 o Name: The name of the group communication policy. 1507 o CBOR label: The value to be used to identify this group 1508 communication policy. Key map labels MUST be unique. The label 1509 can be a positive integer, a negative integer or a string. 1510 Integer values between 0 and 255 and strings of length 1 are 1511 designated as Standards Track Document required. Integer values 1512 from 256 to 65535 and strings of length 2 are designated as 1513 Specification Required. Integer values of greater than 65535 and 1514 strings of length greater than 2 are designated as expert review. 1515 Integer values less than -65536 are marked as private use. 1517 o CBOR type: the CBOR type used to encode the value of this group 1518 communication policy. 1520 o Description: This field contains a brief description for this 1521 group communication policy. 1523 o Reference: This field contains a pointer to the public 1524 specification providing the format of the group communication 1525 policy, if one exists. 1527 This registry will be initially populated by the values in Figure 5. 1529 8.6. Sequence Number Synchronization Method Registry 1531 This specification establishes the "Sequence Number Synchronization 1532 Method" IANA Registry. The Registry has been created to use the 1533 "Expert Review Required" registration procedure [RFC8126]. Expert 1534 review guidelines are provided in Section 8.7. It should be noted 1535 that, in addition to the expert review, some portions of the Registry 1536 require a specification, potentially a Standards Track RFC, be 1537 supplied as well. 1539 The columns of this Registry are: 1541 o Name: The name of the sequence number synchronization method. 1543 o Value: The value to be used to identify this sequence number 1544 synchronization method. 1546 o Description: This field contains a brief description for this 1547 sequence number synchronization method. 1549 o Reference: This field contains a pointer to the public 1550 specification describing the sequence number synchronization 1551 method. 1553 8.7. Expert Review Instructions 1555 The IANA Registries established in this document are defined as 1556 expert review. This section gives some general guidelines for what 1557 the experts should be looking for, but they are being designated as 1558 experts for a reason so they should be given substantial latitude. 1560 Expert reviewers should take into consideration the following points: 1562 o Point squatting should be discouraged. Reviewers are encouraged 1563 to get sufficient information for registration requests to ensure 1564 that the usage is not going to duplicate one that is already 1565 registered and that the point is likely to be used in deployments. 1566 The zones tagged as private use are intended for testing purposes 1567 and closed environments, code points in other ranges should not be 1568 assigned for testing. 1570 o Specifications are required for the standards track range of point 1571 assignment. Specifications should exist for specification 1572 required ranges, but early assignment before a specification is 1573 available is considered to be permissible. Specifications are 1574 needed for the first-come, first-serve range if they are expected 1575 to be used outside of closed environments in an interoperable way. 1576 When specifications are not provided, the description provided 1577 needs to have sufficient information to identify what the point is 1578 being used for. 1580 o Experts should take into account the expected usage of fields when 1581 approving point assignment. The fact that there is a range for 1582 standards track documents does not mean that a standards track 1583 document cannot have points assigned outside of that range. The 1584 length of the encoded value should be weighed against how many 1585 code points of that length are left, the size of device it will be 1586 used on, and the number of code points left that encode to that 1587 size. 1589 9. References 1591 9.1. Normative References 1593 [I-D.ietf-ace-cwt-proof-of-possession] 1594 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 1595 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 1596 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 1597 possession-11 (work in progress), October 2019. 1599 [I-D.ietf-ace-oauth-authz] 1600 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1601 H. Tschofenig, "Authentication and Authorization for 1602 Constrained Environments (ACE) using the OAuth 2.0 1603 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-25 1604 (work in progress), October 2019. 1606 [I-D.ietf-ace-oauth-params] 1607 Seitz, L., "Additional OAuth Parameters for Authorization 1608 in Constrained Environments (ACE)", draft-ietf-ace-oauth- 1609 params-05 (work in progress), March 2019. 1611 [I-D.ietf-core-oscore-groupcomm] 1612 Tiloca, M., Selander, G., Palombini, F., and J. Park, 1613 "Group OSCORE - Secure Group Communication for CoAP", 1614 draft-ietf-core-oscore-groupcomm-05 (work in progress), 1615 July 2019. 1617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1618 Requirement Levels", BCP 14, RFC 2119, 1619 DOI 10.17487/RFC2119, March 1997, 1620 . 1622 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1623 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1624 October 2013, . 1626 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1627 Writing an IANA Considerations Section in RFCs", BCP 26, 1628 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1629 . 1631 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1632 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1633 . 1635 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1636 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1637 May 2017, . 1639 9.2. Informative References 1641 [I-D.dijk-core-groupcomm-bis] 1642 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1643 for the Constrained Application Protocol (CoAP)", draft- 1644 dijk-core-groupcomm-bis-01 (work in progress), July 2019. 1646 [I-D.ietf-ace-dtls-authorize] 1647 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 1648 L. Seitz, "Datagram Transport Layer Security (DTLS) 1649 Profile for Authentication and Authorization for 1650 Constrained Environments (ACE)", draft-ietf-ace-dtls- 1651 authorize-08 (work in progress), April 2019. 1653 [I-D.ietf-ace-mqtt-tls-profile] 1654 Sengul, C., Kirby, A., and P. Fremantle, "MQTT-TLS profile 1655 of ACE", draft-ietf-ace-mqtt-tls-profile-01 (work in 1656 progress), October 2019. 1658 [I-D.ietf-ace-oscore-profile] 1659 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 1660 "OSCORE profile of the Authentication and Authorization 1661 for Constrained Environments Framework", draft-ietf-ace- 1662 oscore-profile-08 (work in progress), July 2019. 1664 [I-D.ietf-core-coap-pubsub] 1665 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1666 Subscribe Broker for the Constrained Application Protocol 1667 (CoAP)", draft-ietf-core-coap-pubsub-09 (work in 1668 progress), September 2019. 1670 [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management 1671 Protocol (GKMP) Specification", RFC 2093, 1672 DOI 10.17487/RFC2093, July 1997, 1673 . 1675 [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management 1676 Protocol (GKMP) Architecture", RFC 2094, 1677 DOI 10.17487/RFC2094, July 1997, 1678 . 1680 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 1681 Multicast: Issues and Architectures", RFC 2627, 1682 DOI 10.17487/RFC2627, June 1999, 1683 . 1685 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 1686 the Constrained Application Protocol (CoAP)", RFC 7390, 1687 DOI 10.17487/RFC7390, October 2014, 1688 . 1690 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1691 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1692 . 1694 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1695 the Constrained Application Protocol (CoAP)", RFC 7959, 1696 DOI 10.17487/RFC7959, August 2016, 1697 . 1699 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1700 Interchange Format", STD 90, RFC 8259, 1701 DOI 10.17487/RFC8259, December 2017, 1702 . 1704 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1705 "Object Security for Constrained RESTful Environments 1706 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1707 . 1709 Appendix A. Requirements on Application Profiles 1711 TODO: fix req numbers in the text. 1713 This section lists the requirements on application profiles of this 1714 specification,for the convenience of application profile designers. 1716 o REQ1: Specify the encoding and value of the identifier of group or 1717 topic of 'scope' (see Section 3.1). 1719 o REQ2: Specify the encoding and value of roles of 'scope' (see 1720 Section 3.1). 1722 o REQ3: Optionally, specify the acceptable values for 'sign_alg' 1723 (see Section 3.3). 1725 o REQ4: Optionally, specify the acceptable values for 1726 'sign_parameters' (see Section 3.3). 1728 o REQ5: Optionally, specify the acceptable values for 1729 'sign_key_parameters' (see Section 3.3). 1731 o REQ6: Optionally, specify the acceptable values for 'pub_key_enc' 1732 (see Section 3.3). 1734 o REQ7: Specify the exact format of the 'key' value (see 1735 Section 4.1.2.1). 1737 o REQ8: Specify the acceptable values of 'kty' (see 1738 Section 4.1.2.1). 1740 o REQ9: Specity the format of the identifiers of group members (see 1741 Section 4.1.2.1). 1743 o REQ10: Optionally, specify the format and content of 1744 'group_policies' entries (see Section 4.1.2.1). 1746 o REQ11: Specify the communication protocol the members of the group 1747 must use (e.g., multicast CoAP). 1749 o REQ12: Specify the security protocol the group members must use to 1750 protect their communication (e.g., group OSCORE). This must 1751 provide encryption, integrity and replay protection. 1753 o REQ13: Specify and register the application profile identifier 1754 (see Section 4.1.2.1). 1756 o REQ14: Optionally, specify the encoding of public keys, of 1757 'client_cred', and of 'pub_keys' if COSE_Keys are not used (see 1758 Section 4.1.2.1). 1760 o REQ15: Specify policies at the KDC to handle id that are not 1761 included in get_pub_keys (see Section 4.1.3.1). 1763 o REQ16: Specify the format and content of 'group_policies' (see 1764 Section 4.1.2.1). 1766 o REQ17: Specify the format of newly-generated individual keying 1767 material for group members, or of the information to derive it, 1768 and corresponding CBOR label (see Section 4.1.6.2). 1770 o REQ18: Specify how the communication is secured between Client and 1771 KDC. Optionally, specify tranport profile of ACE 1772 [I-D.ietf-ace-oauth-authz] to use between Client and KDC (see 1773 Section 4.2. 1775 o OPT1: Optionally, specify the encoding of public keys, of 1776 'client_cred', and of 'pub_keys' if COSE_Keys are not used (see 1777 Section 4.1.2.1). 1779 o OPT2: Optionally, specify the negotiation of parameter values for 1780 signature algorithm and signature keys, if 'sign_info' and 1781 'pub_key_enc' are not used (see Section 3.3). 1783 o OPT3: Optionally, specify the format and content of 1784 'mgt_key_material' (see Section 4.1.2.1). 1786 o OPT4: Optionally, specify policies that instruct clients to retain 1787 unsuccessfully decrypted messages and for how long, so that they 1788 can be decrypted after getting updated keying material (OPT4). 1790 Appendix B. Document Updates 1792 RFC EDITOR: PLEASE REMOVE THIS SECTION. 1794 B.1. Version -02 to -03 1796 o Exchange of information on the countersignature algorithm and 1797 related parameters, during the Token POST (Section 3.3). 1799 o Restructured KDC interface, with new possible operations 1800 (Section 4). 1802 o Client PoP signature for the Joining Request upon joining 1803 (Section 4.1.2.1). 1805 o Revised text on group member removal (Section 5). 1807 o Added more profile requirements (Appendix A). 1809 B.2. Version -01 to -02 1811 o Editorial fixes. 1813 o Distinction between transport profile and application profile 1814 (Section 1.1). 1816 o New parameters 'sign_info' and 'pub_key_enc' to negotiate 1817 parameter values for signature algorithm and signature keys 1818 (Section 3.3). 1820 o New parameter 'type' to distinguish different Key Distribution 1821 Request messages (Section 4.1). 1823 o New parameter 'client_cred_verify' in the Key Distribution Request 1824 to convey a Client signature (Section 4.1). 1826 o Encoding of 'pub_keys_repos' (Section 4.1). 1828 o Encoding of 'mgt_key_material' (Section 4.1). 1830 o Improved description on retrieval of new or updated keying 1831 material (Section 6). 1833 o Encoding of 'get_pub_keys' in Public Key Request (Section 7.1). 1835 o Extended security considerations (Sections 10.1 and 10.2). 1837 o New "ACE Public Key Encoding" IANA Registry (Section 11.2). 1839 o New "ACE Groupcomm Parameters" IANA Registry (Section 11.3), 1840 populated with the entries in Section 8. 1842 o New "Ace Groupcomm Request Type" IANA Registry (Section 11.4), 1843 populated with the values in Section 9. 1845 o New "ACE Groupcomm Policy" IANA Registry (Section 11.7) populated 1846 with two entries "Sequence Number Synchronization Method" and "Key 1847 Update Check Interval" (Section 4.2). 1849 o Improved list of requirements for application profiles 1850 (Appendix A). 1852 B.3. Version -00 to -01 1854 o Changed name of 'req_aud' to 'audience' in the Authorization 1855 Request (Section 3.1). 1857 o Defined error handling on the KDC (Sections 4.2 and 6.2). 1859 o Updated format of the Key Distribution Response as a whole 1860 (Section 4.2). 1862 o Generalized format of 'pub_keys' in the Key Distribution Response 1863 (Section 4.2). 1865 o Defined format for the message to request leaving the group 1866 (Section 5.2). 1868 o Renewal of individual keying material and methods for group 1869 rekeying initiated by the KDC (Section 6). 1871 o CBOR type for node identifiers in 'get_pub_keys' (Section 7.1). 1873 o Added section on parameter identifiers and their CBOR keys 1874 (Section 8). 1876 o Added request types for requests to a Join Response (Section 9). 1878 o Extended security considerations (Section 10). 1880 o New IANA registries "ACE Groupcomm Key Registry", "ACE Groupcomm 1881 Profile Registry", "ACE Groupcomm Policy Registry" and "Sequence 1882 Number Synchronization Method Registry" (Section 11). 1884 o Added appendix about requirements for application profiles of ACE 1885 on group communication (Appendix A). 1887 Acknowledgments 1889 The following individuals were helpful in shaping this document: 1890 Carsten Bormann, Rikard Hoeglund, Ben Kaduk, John Mattsson, Daniel 1891 Migault, Jim Schaad, Ludwig Seitz, Goeran Selander and Peter van der 1892 Stok. 1894 The work on this document has been partly supported by VINNOVA and 1895 the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact 1896 Initiative ACTIVE. 1898 Authors' Addresses 1900 Francesca Palombini 1901 Ericsson AB 1902 Torshamnsgatan 23 1903 Kista SE-16440 Stockholm 1904 Sweden 1906 Email: francesca.palombini@ericsson.com 1908 Marco Tiloca 1909 RISE AB 1910 Isafjordsgatan 22 1911 Kista SE-16440 Stockholm 1912 Sweden 1914 Email: marco.tiloca@ri.se