idnits 2.17.1 draft-ietf-ace-key-groupcomm-15.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 (23 December 2021) is 853 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) -- Looks like a reference, but probably isn't: '01' on line 1264 -- Looks like a reference, but probably isn't: '02' on line 1264 == Outdated reference: A later version (-07) exists of draft-ietf-ace-aif-03 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-13 == Outdated reference: A later version (-10) exists of draft-ietf-cose-countersign-05 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-countersign' ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' ** Downref: Normative reference to an Informational RFC: RFC 7967 == Outdated reference: A later version (-17) exists of draft-ietf-ace-mqtt-tls-profile-13 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-10) exists of draft-ietf-core-groupcomm-bis-05 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-10 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). 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: 26 June 2022 RISE AB 6 23 December 2021 8 Key Provisioning for Group Communication using ACE 9 draft-ietf-ace-key-groupcomm-15 11 Abstract 13 This document defines how to use the Authentication and Authorization 14 for Constrained Environments (ACE) framework to distribute keying 15 material and configuration parameters for secure group communication. 16 Candidate group members acting as Clients and authorized to join a 17 group can do so by interacting with a Key Distribution Center (KDC) 18 acting as Resource Server, from which they obtain the keying material 19 to communicate with other group members. While defining general 20 message formats as well as the interface and operations available at 21 the KDC, this document supports different approaches and protocols 22 for secure group communication. Therefore, details are delegated to 23 separate application profiles of this document, as specialized 24 instances that target a particular group communication approach and 25 define how communications in the group are protected. Compliance 26 requirements for such application profiles are also specified. 28 Discussion Venues 30 This note is to be removed before publishing as an RFC. 32 Source for this draft and an issue tracker can be found at 33 https://github.com/ace-wg/ace-key-groupcomm. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 26 June 2022. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Simplified BSD License text 62 as described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 69 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3. Authorization to Join a Group . . . . . . . . . . . . . . . . 10 71 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 11 72 3.2. Authorization Response . . . . . . . . . . . . . . . . . 13 73 3.3. Token Transferring . . . . . . . . . . . . . . . . . . . 15 74 3.3.1. 'sign_info' Parameter . . . . . . . . . . . . . . . . 17 75 3.3.2. 'kdcchallenge' Parameter . . . . . . . . . . . . . . 19 76 4. KDC Functionalities . . . . . . . . . . . . . . . . . . . . . 19 77 4.1. Interface at the KDC . . . . . . . . . . . . . . . . . . 20 78 4.1.1. Operations Supported by Clients . . . . . . . . . . . 23 79 4.1.2. Error Handling . . . . . . . . . . . . . . . . . . . 24 80 4.2. /ace-group . . . . . . . . . . . . . . . . . . . . . . . 26 81 4.2.1. FETCH Handler . . . . . . . . . . . . . . . . . . . . 26 82 4.2.1.1. Retrieve Group Names . . . . . . . . . . . . . . 27 83 4.3. /ace-group/GROUPNAME . . . . . . . . . . . . . . . . . . 28 84 4.3.1. POST Handler . . . . . . . . . . . . . . . . . . . . 28 85 4.3.1.1. Join the Group . . . . . . . . . . . . . . . . . 41 86 4.3.2. GET Handler . . . . . . . . . . . . . . . . . . . . . 43 87 4.3.2.1. Retrieve Group Keying Material . . . . . . . . . 44 88 4.4. /ace-group/GROUPNAME/pub-key . . . . . . . . . . . . . . 45 89 4.4.1. FETCH Handler . . . . . . . . . . . . . . . . . . . . 45 90 4.4.1.1. Retrieve a Subset of Public Keys in the Group . . 47 91 4.4.2. GET Handler . . . . . . . . . . . . . . . . . . . . . 48 92 4.4.2.1. Retrieve All Public Keys in the Group . . . . . . 48 93 4.5. ace-group/GROUPNAME/kdc-pub-key . . . . . . . . . . . . . 49 94 4.5.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 49 95 4.5.1.1. Retrieve the KDC's Public Key . . . . . . . . . . 50 96 4.6. /ace-group/GROUPNAME/policies . . . . . . . . . . . . . . 51 97 4.6.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 51 98 4.6.1.1. Retrieve the Group Policies . . . . . . . . . . . 52 99 4.7. /ace-group/GROUPNAME/num . . . . . . . . . . . . . . . . 53 100 4.7.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 53 101 4.7.1.1. Retrieve the Keying Material Version . . . . . . 54 102 4.8. /ace-group/GROUPNAME/nodes/NODENAME . . . . . . . . . . . 54 103 4.8.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 55 104 4.8.1.1. Retrieve Group and Individual Keying Material . . 56 105 4.8.2. PUT Handler . . . . . . . . . . . . . . . . . . . . . 57 106 4.8.2.1. Request to Change Individual Keying Material . . 59 107 4.8.3. DELETE Handler . . . . . . . . . . . . . . . . . . . 60 108 4.8.3.1. Leave the Group . . . . . . . . . . . . . . . . . 60 109 4.9. /ace-group/GROUPNAME/nodes/NODENAME/pub-key . . . . . . . 61 110 4.9.1. POST Handler . . . . . . . . . . . . . . . . . . . . 61 111 4.9.1.1. Uploading a New Public Key . . . . . . . . . . . 62 112 5. Removal of a Group Member . . . . . . . . . . . . . . . . . . 63 113 6. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 65 114 6.1. Point-to-Point Group Rekeying . . . . . . . . . . . . . . 66 115 6.2. One-to-Many Group Rekeying . . . . . . . . . . . . . . . 67 116 6.2.1. Protection of Rekeying Messages . . . . . . . . . . . 69 117 7. Extended Scope Format . . . . . . . . . . . . . . . . . . . . 72 118 8. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 74 119 9. ACE Groupcomm Error Identifiers . . . . . . . . . . . . . . . 77 120 10. Security Considerations . . . . . . . . . . . . . . . . . . . 79 121 10.1. Secure Communication in the Group . . . . . . . . . . . 79 122 10.2. Update of Group Keying Material . . . . . . . . . . . . 80 123 10.2.1. Misalignment of Group Keying Material . . . . . . . 82 124 10.3. Block-Wise Considerations . . . . . . . . . . . . . . . 83 125 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83 126 11.1. Media Type Registrations . . . . . . . . . . . . . . . . 83 127 11.2. CoAP Content-Formats . . . . . . . . . . . . . . . . . . 84 128 11.3. OAuth Parameters . . . . . . . . . . . . . . . . . . . . 84 129 11.4. OAuth Parameters CBOR Mappings . . . . . . . . . . . . . 85 130 11.5. Interface Description (if=) Link Target Attribute 131 Values . . . . . . . . . . . . . . . . . . . . . . . . 85 132 11.6. CBOR Tags . . . . . . . . . . . . . . . . . . . . . . . 86 133 11.7. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . 86 134 11.8. ACE Groupcomm Key Types . . . . . . . . . . . . . . . . 87 135 11.9. ACE Groupcomm Profiles . . . . . . . . . . . . . . . . . 87 136 11.10. ACE Groupcomm Policies . . . . . . . . . . . . . . . . . 88 137 11.11. Sequence Number Synchronization Methods . . . . . . . . 89 138 11.12. ACE Scope Semantics . . . . . . . . . . . . . . . . . . 89 139 11.13. ACE Groupcomm Errors . . . . . . . . . . . . . . . . . . 90 140 11.14. ACE Groupcomm Rekeying Schemes . . . . . . . . . . . . . 90 141 11.15. Expert Review Instructions . . . . . . . . . . . . . . . 91 142 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 92 143 12.1. Normative References . . . . . . . . . . . . . . . . . . 92 144 12.2. Informative References . . . . . . . . . . . . . . . . . 94 146 Appendix A. Requirements on Application Profiles . . . . . . . . 96 147 A.1. Mandatory-to-Address Requirements . . . . . . . . . . . . 96 148 A.2. Optional-to-Address Requirements . . . . . . . . . . . . 99 149 Appendix B. Extensibility for Future COSE Algorithms . . . . . . 100 150 B.1. Format of 'sign_info_entry' . . . . . . . . . . . . . . . 100 151 Appendix C. Document Updates . . . . . . . . . . . . . . . . . . 101 152 C.1. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 101 153 C.2. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 101 154 C.3. Version -05 to -13 . . . . . . . . . . . . . . . . . . . 102 155 C.4. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 102 156 C.5. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 103 157 C.6. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 103 158 C.7. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 104 159 C.8. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 105 160 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 105 161 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 106 163 1. Introduction 165 This document builds on the Authentication and Authorization for 166 Constrained Environments (ACE) framework and defines how to request, 167 distribute and renew keying material and configuration parameters to 168 protect message exchanges in a group communication environment. 170 Candidate group members acting as Clients and authorized to join a 171 group can interact with the Key Distribution Center (KDC) acting as 172 Resource Server and responsible for that group, in order to obtain 173 the necessary keying material and parameters to communicate with 174 other group members. 176 In particular, this document defines the operations and interface 177 available at the KDC, as well as general message formats for the 178 interactions between Clients and KDC. At the same time, 179 communications in the group can rely on different approaches, e.g., 180 based on multicast [I-D.ietf-core-groupcomm-bis] or on publish- 181 subscribe messaging [I-D.ietf-core-coap-pubsub], and can be protected 182 in different ways. 184 Therefore, this document delegates details on the communication and 185 security approaches used in a group to separate application profiles. 186 These are specialized instances of this document, targeting a 187 particular group communication approach and defining how 188 communications in the group are protected, as well as the specific 189 keying material and configuration parameters provided to group 190 members. In order to ensure consistency and aid the development of 191 such application profiles, this document defines a number of related 192 compliance requirements (see Appendix A). 194 If the application requires backward and forward security, new keying 195 material is generated and distributed to the group upon membership 196 changes (rekeying). A group rekeying scheme performs the actual 197 distribution of the new keying material, by rekeying the current 198 group members when a new Client joins the group, and the remaining 199 group members when a Client leaves the group. This can rely on 200 different approaches, including efficient group rekeying schemes such 201 as [RFC2093], [RFC2094] and [RFC2627]. 203 Consistently with what is recommeded in the ACE framework, this 204 document uses CBOR [RFC8949] for data encoding. However, using JSON 205 [RFC8259] instead of CBOR is possible, by relying on the conversion 206 method specified in Sections 6.1 and 6.2 of [RFC8949]. 208 1.1. Terminology 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 212 "OPTIONAL" in this document are to be interpreted as described in BCP 213 14 [RFC2119] [RFC8174] when, and only when, they appear in all 214 capitals, as shown here. 216 Readers are expected to be familiar with: 218 * The terms and concepts described in the ACE framework 219 [I-D.ietf-ace-oauth-authz] and in the Authorization Information 220 Format (AIF) [I-D.ietf-ace-aif] to express authorization 221 information. The terminology for entities in the considered 222 architecture is defined in OAuth 2.0 [RFC6749]. In particular, 223 this includes Client (C), Resource Server (RS), and Authorization 224 Server (AS). 226 * The terms and concepts described in CoAP [RFC7252]. Unless 227 otherwise indicated, the term "endpoint" is used here following 228 its OAuth definition, aimed at denoting resources such as /token 229 and /introspect at the AS, and /authz-info at the RS. This 230 document does not use the CoAP definition of "endpoint", which is 231 "An entity participating in the CoAP protocol". 233 * The terms and concepts described in CBOR [RFC8949] and COSE 234 [I-D.ietf-cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-algs] 235 [I-D.ietf-cose-countersign]. 237 A principal interested to participate in group communication as well 238 as already participating as a group member is interchangeably denoted 239 as "Client" or "node". 241 Furthermore, this document uses "names" or "identifiers" for groups 242 and nodes. Their different meanings are summarized below. 244 * Group: a set of nodes that share common keying material and 245 security parameters used to protect their communications with one 246 another. That is, the term refers to a "security group". 248 This is not to be confused with an "application group", which has 249 relevance at the application level and whose members share a 250 common pool of resources or content. Examples of application 251 groups are the set of all nodes deployed in a same physical room, 252 or the set of nodes registered to a pub-sub topic. 254 The same security group might be associated to multiple 255 application groups. Also, the same application group can be 256 associated to multiple security groups. Further details and 257 considerations on the mapping between the two types of group are 258 out of the scope of this document. 260 * Key Distribution Center (KDC): the entity responsible for managing 261 one or multiple groups, with particular reference to the group 262 membership and the keying material to use for protecting group 263 communications. 265 * Group name: the invariant once established identifier of a group. 266 It is used in the interactions between Client, AS and RS to 267 identify a group. A group name is always unique among the group 268 names of the existing groups under the same KDC. 270 * GROUPNAME: the invariant once established text string used in 271 URIs. GROUPNAME uniquely maps to the group name of a group, 272 although they do not necessarily coincide. 274 * Group identifier: the identifier of the group keying material used 275 in a group. Unlike group name and GROUPNAME, this identifier 276 changes over time, when the group keying material is updated. 278 * Node name: the invariant once established identifier of a node. 279 It is used in the interactions between Client and RS and to 280 identify a member of a group. Within the same group, a node name 281 is always unique among the node names of all the current members 282 of that group. 284 * NODENAME: the invariant once established text string used in URIs 285 to identify a member a group. Its value coincides with the node 286 name of the associated group member. 288 This document additionally uses the following terminology: 290 * Transport profile, to indicate a profile of ACE as per 291 Section 5.8.4.3 of [I-D.ietf-ace-oauth-authz]. A transport 292 profile specifies the communication protocol and communication 293 security protocol between an ACE Client and Resource Server, as 294 well as proof-of-possession methods, if it supports proof-of- 295 possession access tokens, etc. Transport profiles of ACE include, 296 for instance, [I-D.ietf-ace-oscore-profile], 297 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-mqtt-tls-profile]. 299 * Application profile, that defines how applications enforce and use 300 supporting security services they require. These services may 301 include, for instance, provisioning, revocation and distribution 302 of keying material. An application profile may define specific 303 procedures and message formats. 305 2. Overview 307 The full procedure can be separated in two phases: the first one 308 follows the ACE Framework, between Client, AS and KDC; the second one 309 is the key distribution between Client and KDC. After the two phases 310 are completed, the Client is able to participate in the group 311 communication, via a Dispatcher entity. 313 +------------+ +-----------+ 314 | AS | | KDC | 315 | | .----->| | 316 +------------+ / +-----------+ 317 ^ / 318 | / 319 v / +-----------+ 320 +------------+ / +------------+ |+-----------+ 321 | Client |<-' | Dispatcher | ||+-----------+ 322 | |<------------->| |<------->||| Group | 323 +------------+ +------------+ ||| members | 324 +++-----------+ 326 Figure 1: Key Distribution Participants 328 The following participants (see Figure 1) take part in the 329 authorization and key distribution. 331 * Client (C): node that wants to join a group and take part in group 332 communication with other group memebrs. Within the group, the 333 Client can have different roles. 335 * Authorization Server (AS): as per the AS defined in the ACE 336 Framework, it enforces access policies, and knows if a node is 337 allowed to join a given group with write and/or read rights. 339 * Key Distribution Center (KDC): maintains the keying material to 340 protect group communications, and provides it to Clients 341 authorized to join a given group. During the first part of the 342 exchange (Section 3), it takes the role of the RS in the ACE 343 Framework. During the second part (Section 4), which is not based 344 on the ACE Framework, it distributes the keying material. In 345 addition, it provides the latest keying material to group members 346 when requested or, if required by the application, when membership 347 changes. 349 * Dispatcher: entity through which the Clients communicate with the 350 group, when sending a message intended to multiple group members. 351 That is, the Dispatcher distributes such a one-to-many message to 352 the group members as intended recipients. A single-recipient 353 message intended to only one group member may be delivered by 354 alternative means, with no assistance from the Dispatcher. 356 Examples of a Dispatcher are: the Broker in a pub-sub setting; a 357 relayer for group communication that delivers group messages as 358 multiple unicast messages to all group members; an implicit entity 359 as in a multicast communication setting, where messages are 360 transmitted to a multicast IP address and delivered on the 361 transport channel. 363 This document specifies a mechanism for: 365 * Authorizing a Client to join the group (Section 3), and providing 366 it with the group keying material to communicate with the other 367 group members (Section 4). 369 * Allowing a group member to retrieve group keying material 370 (Section 4.8.1.1 and Section 4.8.2.1). 372 * Allowing a group member to retrieve public keys of other group 373 members (Section 4.4.1.1) and to provide an updated public key 374 (Section 4.9.1.1). 376 * Allowing a group member to leave the group (Section 5). 378 * Evicting a group member from the group (Section 5). 380 * Renewing and re-distributing the group keying material (rekeying) 381 upon a membership change in the group (Section 4.8.3.1 and 382 Section 5). 384 Figure 2 provides a high level overview of the message flow for a 385 node joining a group. The message flow can be expanded as follows. 387 1. The joining node requests an access token from the AS, in order 388 to access one or more group-membership resources at the KDC and 389 hence join the associated groups. 391 This exchange between Client and AS MUST be secured, as specified 392 by the transport profile of ACE used between Client and KDC. 393 Based on the response from the AS, the joining node will 394 establish or continue using a secure communication association 395 with the KDC. 397 2. The joining node transfers authentication and authorization 398 information to the KDC, by transferring the obtained access 399 token. This is typically achieved by including the access token 400 in a request sent to the /authz-info endpoint at the KDC. 402 Once this exchange is completed, the joining node MUST have a 403 secure communication association established with the KDC, before 404 joining a group under that KDC. 406 This exchange and the following secure communications between the 407 Client and the KDC MUST occur in accordance with the transport 408 profile of ACE used between Client and KDC, such as the DTLS 409 transport profile [I-D.ietf-ace-dtls-authorize] and OSCORE 410 transport profile [I-D.ietf-ace-oscore-profile] of ACE. 412 3. The joining node starts the joining process to become a member of 413 the group, by sending a request to the related group-membership 414 resource at the KDC. Based on the application requirements and 415 policies, the KDC may perform a group rekeying, by generating new 416 group keying material and distributing it to the current group 417 members through the rekeying scheme used in the group. 419 At the end of the joining process, the joining node has received 420 from the KDC the parameters and group keying material to securely 421 communicate with the other group members. Also, the KDC has 422 stored the association between the authorization information from 423 the access token and the secure session with the joining node. 425 4. The joining node and the KDC maintain the secure association, to 426 support possible future communications. These especially include 427 key management operations, such as retrieval of updated keying 428 material or participation to a group rekeying process. 430 5. The joining node can communicate securely with the other group 431 members, using the keying material provided in step 3. 433 C AS KDC Group 434 | | | Members 435 / | | | | 436 | |--- Authorization Request -->| | | 437 | | | | | 438 | |<-- Authorization Response --| | | 439 (*) < | | | | 440 | | | | | 441 | |--- Token Transfer Request ---->| | 442 | | | | 443 | |<--- Token Transfer Response-----| | 444 \ | | | | 445 | | | | 446 |------ Joining Request --------->| | 447 | | | | 448 | | | -- Group rekeying -->| 449 | | | (optional) | 450 |<----- Joining Response ---------| | 451 | | | | 452 | | | | 453 | | | Dispatcher | 454 | | | 455 |<======= Secure group communication =========|=========>| 456 | | | 458 (*) Defined in the ACE framework 460 Figure 2: Message Flow Upon New Node's Joining 462 3. Authorization to Join a Group 464 This section describes in detail the format of messages exchanged by 465 the participants when a node requests access to a given group. This 466 exchange is based on ACE [I-D.ietf-ace-oauth-authz]. 468 As defined in [I-D.ietf-ace-oauth-authz], the Client requests the AS 469 for the authorization to join the group through the KDC (see 470 Section 3.1). If the request is approved and authorization is 471 granted, the AS provides the Client with a proof-of-possession access 472 token and parameters to securely communicate with the KDC (see 473 Section 3.2). 475 Communications between the Client and the AS MUST be secured, 476 according to what is defined by the used transport profile of ACE. 477 The Content-Format used in the message also depends on the used 478 transport profile of ACE. For example, it can be application/ 479 ace+cbor for the first two messages and application/cwt for the third 480 message, which are defined in the ACE framework. 482 The transport profile of ACE also defines a number of details such as 483 the communication and security protocols used with the KDC (see 484 Appendix C of [I-D.ietf-ace-oauth-authz]). 486 Figure 3 gives an overview of the exchange described above. 488 Client AS KDC 489 | | | 490 |---- Authorization Request: POST /token ------->| | 491 | | | 492 |<--- Authorization Response: 2.01 (Created) ----| | 493 | | | 494 |---- Token Transfer Request: POST /authz-info ------->| 495 | | | 496 |<--- Token Transfer Response: 2.01 (Created) -------->| 497 | | | 499 Figure 3: Message Flow of Join Authorization 501 3.1. Authorization Request 503 The Authorization Request sent from the Client to the AS is defined 504 in Section 5.8.1 of [I-D.ietf-ace-oauth-authz] and MAY contain the 505 following parameters, which, if included, MUST have format and value 506 as specified below. 508 * 'scope', specifying the name of the groups that the Client 509 requests to access, and optionally the roles that the Client 510 requests to have in those groups. 512 This parameter is encoded as a CBOR byte string, which wraps a 513 CBOR array of one or more scope entries. All the scope entries 514 are specified according to a same format, i.e. either the AIF 515 format or the textual format defined below. 517 - If the AIF format is used, each scope entry is encoded as 518 specified in [I-D.ietf-ace-aif]. The object identifier "Toid" 519 corresponds to the group name and MUST be encoded as a CBOR 520 text string. The permission set "Tperm" indicates the roles 521 that the Client wishes to take in the group. 523 The AIF format is the default format for application profiles 524 of this specification, and is preferable for those that aim to 525 a compact encoding of scope. This is desirable especially for 526 application profiles defining several roles, with the Client 527 possibly requesting for multiple roles combined. 529 Figure 4 shows an example in CDDL notation [RFC8610] where 530 scope uses the AIF format. 532 - If the textual format is used, each scope entry is a CBOR array 533 formatted as follows. 535 o As first element, the group name, encoded as a CBOR text 536 string. 538 o Optionally, as second element, the role or CBOR array of 539 roles that the Client wishes to take in the group. This 540 element is optional since roles may have been pre-assigned 541 to the Client, as associated to its verifiable identity 542 credentials. Alternatively, the application may have 543 defined a single, well-known role for the target resource(s) 544 and audience(s). 546 Figure 5 shows an example in CDDL notation where scope uses the 547 textual format, with group name and role identifiers encoded as 548 CBOR text strings. 550 It is REQUIRED of application profiles of this specificaton to 551 specify the exact format and encoding of scope (REQ1). This 552 includes defining the set of possible roles and their identifiers, 553 as well as the corresponding encoding to use in the scope entries 554 according to the used scope format. 556 If the application profile uses the AIF format, it is also 557 REQUIRED to register its specific instance of "Toid" and "Tperm", 558 as well as the corresponding Media Type and Content-Format, as per 559 the guidelines in [I-D.ietf-ace-aif] (REQ2). 561 If the application profile uses the textual format, it MAY 562 additionally specify CBOR values to use for abbreviating the role 563 identifiers (OPT1). 565 * 'audience', with an identifier of the KDC. 567 As defined in [I-D.ietf-ace-oauth-authz], other additional parameters 568 can be included if necessary. 570 gname = tstr 572 permissions = uint . bits roles 574 roles = &( 575 Requester: 1, 576 Responder: 2, 577 Monitor: 3, 578 Verifier: 4 579 ) 581 scope_entry = AIF_Generic 583 scope = << [ + scope_entry ] >> 585 Figure 4: Example of scope using the AIF format 587 gname = tstr 589 role = tstr 591 scope_entry = [ gname , ? ( role / [ 2*role ] ) ] 593 scope = << [ + scope_entry ] >> 595 Figure 5: Example of scope using the textual format, with the 596 group name and role identifiers encoded as text strings 598 3.2. Authorization Response 600 The AS processes the Authorization Request as defined in 601 Section 5.8.2 of [I-D.ietf-ace-oauth-authz], especially verifying 602 that the Client is authorized to access the specified groups with the 603 requested roles, or possibly a subset of those. 605 In case of successful verification, the Authorization Response sent 606 from the AS to the Client is also defined in Section 5.8.2 of 607 [I-D.ietf-ace-oauth-authz]. Note that the parameter 'expires_in' MAY 608 be omitted if the application defines how the expiration time is 609 communicated to the Client via other means, or if it establishes a 610 default value. 612 Additionally, when included, the following parameter MUST have the 613 corresponding values: 615 * 'scope' has the same format and encoding of 'scope' in the 616 Authorization Request, defined in Section 3.1. If this parameter 617 is not present, the granted scope is equal to the one requested in 618 Section 3.1. 620 The proof-of-possession access token (in 'access_token' above) MUST 621 contain the following parameters: 623 * a confirmation claim (see for example 'cnf' defined in Section 3.1 624 of [RFC8747] for CWT); 626 * an expiration time claim (see for example 'exp' defined in 627 Section 3.1.4 of [RFC8392] for CWT); 629 * a scope claim (see for example 'scope' registered in Section 8.14 630 of [I-D.ietf-ace-oauth-authz] for CWT). 632 This claim specifies the same access control information as in the 633 'scope' parameter of the Authorization Response, if the parameter 634 is present in the message, or as in the 'scope' parameter of the 635 Authorization Request otherwise. 637 By default, this claim has the same encoding as the 'scope' 638 parameter in the Authorization Request, defined in Section 3.1. 640 Optionally, an alternative extended format of scope defined in 641 Section 7 can be used. This format explicitly signals the 642 semantics used to express the actual access control information, 643 and according to which this has to be parsed. This enables a 644 Resource Server to correctly process a received access token, also 645 in case: 647 - The Resource Server implements a KDC that supports multiple 648 application profiles of this specification, using different 649 scope semantics; and/or 651 - The Resource Server implements further services beyond a KDC 652 for group communication, using different scope semantics. 654 If the Authorization Server is aware that this applies to the 655 Resource Server for which the access token is issued, the 656 Authorization Server SHOULD use the extended format of scope 657 defined in Section 7. 659 The access token MAY additionally contain other claims that the 660 transport profile of ACE requires, or other optional parameters. 662 When receiving an Authorization Request from a Client that was 663 previously authorized, and for which the AS still owns a valid non- 664 expired access token, the AS MAY reply with that token. Note that it 665 is up to application profiles of ACE to make sure that re-posting the 666 same token does not cause re-use of keying material between nodes 667 (for example, that is done with the use of random nonces in 668 [I-D.ietf-ace-oscore-profile]). 670 3.3. Token Transferring 672 The Client sends a Token Transfer Request to the KDC, i.e., a CoAP 673 POST request including the access token and targeting the authz-info 674 endpoint (see Section 5.10.1 of [I-D.ietf-ace-oauth-authz]). 676 Note that this request deviates from the one defined in 677 [I-D.ietf-ace-oauth-authz], since it allows to ask the KDC for 678 additional information concerning the public keys used in the group 679 to ensure source authentication, as well as for possible additional 680 group parameters. 682 The joining node MAY ask for this information from the KDC through 683 the same Token Transfer Request. In this case, the message MUST have 684 Content-Format set to application/ace+cbor defined in Section 8.16 of 685 [I-D.ietf-ace-oauth-authz], and the message payload MUST be formatted 686 as a CBOR map, which MUST include the access token. The CBOR map MAY 687 additionally include the following parameter, which, if included, 688 MUST have format and value as specified below. 690 * 'sign_info' defined in Section 3.3.1, specifying the CBOR simple 691 value 'null' (0xf6) to request information about the signature 692 algorithm, signature algorithm parameters, signature key 693 parameters and about the exact encoding of public keys used in the 694 groups that the Client has been authorized to join. 696 Alternatively, such information may be pre-configured on the joining 697 node, or may be retrieved by alternative means. For example, the 698 joining node may have performed an early group discovery process and 699 obtained the link to the associated group-membership resource at the 700 KDC, together with attributes descriptive of the group configuration 701 (see, e.g., [I-D.tiloca-core-oscore-discovery]). 703 After successful verification, the Client is authorized to receive 704 the group keying material from the KDC and join the group. Hence, 705 the KDC replies to the Client with a Token Transfer Response, i.e., a 706 CoAP 2.01 (Created) response. 708 The Token Transfer Response MUST have Content-Format "application/ 709 ace+cbor", and its payload is a CBOR map. Note that this deviates 710 from what is defined in the ACE framework, where the response from 711 the authz-info endpoint is defined as conveying no payload (see 712 Section 5.10.1 of [I-D.ietf-ace-oauth-authz]). 714 If the access token contains a role that requires the Client to send 715 its own public key to the KDC when joining the group, the CBOR map 716 MUST include the parameter 'kdcchallenge' defined in Section 3.3.2, 717 specifying a dedicated challenge N_S generated by the KDC. 719 Later, when joining the group (see Section 4.3.1.1), the Client uses 720 the 'kdcchallenge' value and additional information to build a proof- 721 of-possession (PoP) input. This is in turn used to compute a PoP 722 evidence, which the Client also provides to the Group Manager in 723 order to prove possession of its own private key (see the 724 'client_cred_verify' parameter in Section 4.3.1). 726 The KDC MUST store the 'kdcchallenge' value associated to the Client 727 at least until it receives a Joining Request from it (see 728 Section 4.3.1.1), to be able to verify the PoP evidence provided 729 during the join process, and thus that the Client possesses its own 730 private key. 732 The same 'kdcchallenge' value MAY be reused several times by the 733 Client, to generate a new PoP evidence, e.g., in case the Client 734 provides the Group Manager with a new public key while being a group 735 member (see Section 4.9.1.1), or joins a different group where it 736 intends to use a different public key. Therefore, it is RECOMMENDED 737 that the KDC keeps storing the 'kdcchallenge' value after the first 738 join is processed as well. If the KDC has already discarded the 739 'kdcchallenge' value, that will trigger an error response with a 740 newly generated 'kdcchallenge' value that the Client can use to 741 restart the join process, as specified in Section 4.3.1.1. 743 If 'sign_info' is included in the Token Transfer Request, the KDC 744 SHOULD include the 'sign_info' parameter in the Token Transfer 745 Response, as per the format defined in Section 3.3.1. Note that the 746 field 'id' of each 'sign_info_entry' specifies the name, or array of 747 group names, for which that 'sign_info_entry' applies to. As an 748 exception, the KDC MAY omit the 'sign_info' parameter in the Token 749 Transfer Response even if 'sign_info' is included in the Token 750 Transfer Request, in case none of the groups that the Client is 751 authorized to join uses signatures to achieve source authentication. 753 Note that the CBOR map specified as payload of the 2.01 (Created) 754 response may include further parameters, e.g., according to the used 755 transport profile of ACE. Application profiles of this specification 756 MAY define additional parameters to use within this exchange (OPT2). 758 Application profiles of this specification MAY define alternative 759 specific negotiations of parameter values for the signature algorithm 760 and signature keys, if 'sign_info' is not used (OPT3). 762 If allowed by the used transport profile of ACE, the Client may 763 provide the Access Token to the KDC by other means than the Token 764 Transfer Request. An example is the DTLS transport profile of ACE, 765 where the Client can provide the access token to the KDC during the 766 secure session establishment (see Section 3.3.2 of 767 [I-D.ietf-ace-dtls-authorize]). 769 3.3.1. 'sign_info' Parameter 771 The 'sign_info' parameter is an OPTIONAL parameter of the request and 772 response messages exchanged between the Client and the authz-info 773 endpoint at the RS (see Section 5.10.1. of 774 [I-D.ietf-ace-oauth-authz]). 776 This parameter allows the Client and the RS to exchange information 777 about a signature algorithm and about public keys to accordingly use 778 for signature verification. Its exact semantics and content are 779 application specific. 781 In this specification and in application profiles building on it, 782 this parameter is used to exchange information about the signature 783 algorithm and about public keys to be used with it, in the groups 784 indicated by the transferred acces token as per its 'scope' claim 785 (see Section 3.2). 787 When used in the Token Transfer Request sent to the KDC (see 788 Section 3.3), the 'sign_info' parameter specifies the CBOR simple 789 value 'null' (0xf6). This is done to ask for information about the 790 signature algorithm and about the public keys used in the groups that 791 the Client has been authorized to join - or to have a more restricted 792 interaction as per its granted roles (e.g., the Client is an external 793 signature verifier). 795 When used in the following Token Transfer Response from the KDC (see 796 Section 3.3), the 'sign_info' parameter is a CBOR array of one or 797 more elements. The number of elements is at most the number of 798 groups that the Client has been authorized to join - or to have a 799 more restricted interaction (see above). Each element contains 800 information about signing parameters and about public keys for one or 801 more groups, and is formatted as follows. 803 * The first element 'id' is a group name or an array of group names, 804 associated to groups for which the next four elements apply. In 805 the following, each specified group name is referred to as 806 'gname'. 808 * The second element 'sign_alg' is an integer or a text string if 809 the POST request included the 'sign_info' parameter with value the 810 CBOR simple value 'null' (0xf6), and indicates the signature 811 algorithm used in the groups identified by the 'gname' values. It 812 is REQUIRED of the application profiles to define specific values 813 that this parameter can take (REQ3), selected from the set of 814 signing algorithms of the COSE Algorithms registry 815 [COSE.Algorithms]. 817 * The third element 'sign_parameters' is a CBOR array indicating the 818 parameters of the signature algorithm used in the groups 819 identified by the 'gname' values. Its content depends on the 820 value of 'sign_alg'. It is REQUIRED of the application profiles 821 to define the possible values and structure for the elements of 822 this parameter (REQ4). 824 * The fourth element 'sign_key_parameters' is a CBOR array 825 indicating the parameters of the key used with the signature 826 algorithm, in the groups identified by the 'gname' values. Its 827 content depends on the value of 'sign_alg'. It is REQUIRED of the 828 application profiles to define the possible values and structure 829 for the elements of this parameter (REQ5). 831 * The fifth element 'pub_key_enc' parameter is either a CBOR integer 832 indicating the encoding of public keys used in the groups 833 identified by the 'gname' values, or has value the CBOR simple 834 value 'null' (0xf6) indicating that the KDC does not act as 835 repository of public keys for group members. Its acceptable 836 integer values are taken from the 'Label' column of the "COSE 837 Header Parameters" registry [COSE.Header.Parameters]. It is 838 REQUIRED of the application profiles to define specific values to 839 use for this parameter, consistently with the acceptable formats 840 of public keys (REQ6). 842 The CDDL notation [RFC8610] of the 'sign_info' parameter is given 843 below. 845 sign_info = sign_info_req / sign_info_resp 847 sign_info_req = nil ; in the Token Transfer 848 ; Request to the KDC 850 sign_info_resp = [ + sign_info_entry ] ; in the Token Transfer 851 ; Response from the KDC 853 sign_info_entry = 854 [ 855 id : gname / [ + gname ], 856 sign_alg : int / tstr, 857 sign_parameters : [ any ], 858 sign_key_parameters : [ any ], 859 pub_key_enc = int / nil 860 ] 862 gname = tstr 864 This format is consistent with every signature algorithm currently 865 defined in [I-D.ietf-cose-rfc8152bis-algs], i.e., with algorithms 866 that have only the COSE key type as their COSE capability. 867 Appendix B describes how the format of each 'sign_info_entry' can be 868 generalized for possible future registered algorithms having a 869 different set of COSE capabilities. 871 3.3.2. 'kdcchallenge' Parameter 873 The 'kdcchallenge' parameter is an OPTIONAL parameter of response 874 message returned from the authz-info endpoint at the RS, as defined 875 in Section 5.10.1 of [I-D.ietf-ace-oauth-authz]. This parameter 876 contains a challenge generated by the RS and provided to the Client. 878 In this specification and in application profiles building on it, the 879 Client may use this challenge to prove possession of its own private 880 key in the Joining Request (see the 'client_cred_verify' parameter in 881 Section 4.3.1). 883 4. KDC Functionalities 885 This section describes the functionalities provided by the KDC, as 886 related to the provisioning of the keying material as well as to the 887 group membership management. 889 In particular, this section defines the interface available at the 890 KDC; specifies the handlers of each resource provided by the KDC 891 interface; and describes how Clients interact with those resources to 892 join a group and to perform additional operations as group members. 894 As most important operation after trasferring the access token to the 895 KDC, the Client can perform a "Joining" exchange with the KDC, by 896 specifying the group it requests to join (see Section 4.3.1.1). 897 Then, the KDC verifies the access token and that the Client is 898 authorized to join the specified group. If so, the KDC provides the 899 Client with the keying material to securely communicate with the 900 other members of the group. 902 Later on as a group member, the Client can also rely on the interface 903 at the KDC to perform additional operations, consistently with the 904 roles it has in the group. 906 4.1. Interface at the KDC 908 The KDC provides its interface by hosting the following resources. 909 Note that the root url-path "ace-group" used hereafter is a default 910 name; implementations are not required to use this name, and can 911 define their own instead. The Interface Description (if=) Link 912 Target Attribute value "ace.group" is registered in Section 11.5 and 913 can be used to describe this interface. 915 If request messages sent to the KDC as well as success response 916 messages from the KDC include a payload and specify a Content-Format, 917 those messages MUST have Content-Format set to application/ace- 918 groupcomm+cbor, defined in Section 11.2. CBOR labels for the message 919 parameters are defined in Section 8. 921 * /ace-group : this resource is invariant once established, and 922 indicates that this specification is used. If other applications 923 run on a KDC implementing this specification and use this same 924 resource, those applications will collide, and a mechanism will be 925 needed to differentiate the endpoints. 927 A Client can access this resource in order to retrieve a set of 928 group names, each corresponding to one of the specified group 929 identifiers. This operation is described in Section 4.2.1.1. 931 * /ace-group/GROUPNAME : one such sub-resource to /ace-group is 932 hosted for each group with name GROUPNAME that the KDC manages, 933 and contains the symmetric group keying material for that group. 935 A Client can access this resource in order to join the group with 936 name GROUPNAME, or later as a group member to retrieve the current 937 group keying material. These operations are described in 938 Section 4.3.1.1 and Section 4.3.2.1, respectively. 940 If the value of the GROUPNAME URI path and the group name in the 941 access token scope ('gname' in Section 3.2) are not required to 942 coincide, the KDC MUST implement a mechanism to map the GROUPNAME 943 value in the URI to the group name, in order to refer to the 944 correct group (REQ7). 946 * /ace-group/GROUPNAME/pub-key : this resource is invariant once 947 established, and contains the public keys of all the members of 948 the group with name GROUPNAME. 950 This resource is created only in case the KDC acts as repository 951 of public keys for group members. 953 A Client can access this resource in order to retrieve the public 954 keys of other group members, in addition to when joining the 955 group. That is, the Client can retrieve the public keys of all 956 the current group members, or a subset of them by specifying 957 filter criteria. These operations are described in 958 Section 4.4.2.1 and Section 4.4.1.1, respectively. 960 Clients may be authorized to access this resource even without 961 being group members, e.g., if authorized to be external signature 962 verifiers for the group. 964 * ace-group/GROUPNAME/kdc-pub-key : this resource is invariant once 965 established, and contains the public key of the KDC for the group 966 with name GROUPNAME. 968 This resource is created only in case the KDC has an associated 969 public key and this is required for the correct group operation. 970 It is REQUIRED of application profiles to define whether the KDC 971 has such an associated public key (REQ8). 973 A Client can interact with this resource in order to retrieve the 974 current public key of the KDC, in addition to when joining the 975 group. 977 Clients may be authorized to access this resource even without 978 being group members, e.g., if authorized to be external signature 979 verifiers for the group. 981 * /ace-group/GROUPNAME/policies : this resource is invariant once 982 established, and contains the group policies of the group with 983 name GROUPNAME. 985 A Client can access this resource as a group member in order to 986 retrieve the group policies. This operation is described in 987 Section 4.6.1.1. 989 * /ace-group/GROUPNAME/num : this resource is invariant once 990 established, and contains the current version number for the 991 symmetric group keying material of the group with name GROUPNAME. 993 A Client can access this resource as a group member in order to 994 retrieve the version number of the keying material currently used 995 in the group. This operation is described in Section 4.7.1.1. 997 * /ace-group/GROUPNAME/nodes/NODENAME : one such sub-resource of 998 /ace-group/GROUPNAME is hosted for each group member of the group 999 with name GROUPNAME. Each of such resources is identified by the 1000 node name NODENAME of the associated group member, and contains 1001 the group keying material and the individual keying material for 1002 that group member. 1004 A Client as a group member can access this resource in order to 1005 retrieve the current group keying material together with its the 1006 individual keying material; request new individual keying material 1007 to use in the group; and leave the group. These operations are 1008 described in Section 4.8.1.1, Section 4.8.2.1, and 1009 Section 4.8.3.1, respectively. 1011 * /ace-group/GROUPNAME/nodes/NODENAME/pub-key : this resource is 1012 invariant once established, and contains the individual public 1013 keying material for the node with name NODENAME, as group member 1014 of the group with name GROUPNAME. 1016 A Client can access this resource in order to upload at the KDC a 1017 new public key to use in the group. This operation is described 1018 in Section 4.9.1.1. 1020 This resource is not created if the group member does not have 1021 individual public keying material to use in the group, or if the 1022 KDC does not store the public keys of group members. 1024 The KDC is expected to fully provide the interface defined above. It 1025 is otherwise REQUIRED of the application profiles of this 1026 specification to indicate which resources are not hosted, i.e., which 1027 parts of the interface defined in this section are not supported by 1028 the KDC (REQ9). Application profiles of this specification MAY 1029 extend the KDC interface, by defining additional resources and their 1030 handlers. 1032 It is REQUIRED of the application profiles of this specification to 1033 register a Resource Type for the root url-path (REQ10). This 1034 Resource Type can be used to discover the correct url to access at 1035 the KDC. This Resource Type can also be used at the GROUPNAME sub- 1036 resource, to indicate different application profiles for different 1037 groups. 1039 It is REQUIRED of the application profiles of this specification to 1040 define what specific actions (e.g., CoAP methods) are allowed on each 1041 resource provided by the KDC interface, depending on whether the 1042 Client is a current group member; the roles that a Client is 1043 authorized to take as per the obtained access token (see 1044 Section 3.1); and the roles that the Client has as current group 1045 member (REQ11). 1047 4.1.1. Operations Supported by Clients 1049 It is expected that a Client minimally supports the following set of 1050 primary operations and corresponding interactions with the KDC. 1052 * FETCH request to ace-group/ , in order to retrieve group names 1053 associated to group identifiers. 1055 * POST and GET requests to ace-group/GROUPNAME/ , in order to join a 1056 group (POST) and later retrieve the current group key material as 1057 a group member (GET). 1059 * GET and FETCH requests to ace-group/GROUPNAME/pub-key , in order 1060 to retrieve the public keys of all the other group members (GET) 1061 or only some of them by filtering (FETCH). While retrieving 1062 public keys remains possible by using GET requests, retrieval by 1063 filtering allows to greatly limit the size of exchanged messages. 1065 * GET request to ace-group/GROUPNAME/num , in order to retrieve the 1066 current version of the group key material as a group member. 1068 * DELETE request to ace-group/GROUPNAME/nodes/NODENAME , in order to 1069 leave the group. 1071 In addition, some Clients may rather not support the following set of 1072 secondary operations and corresponding interactions with the KDC. 1073 This can be specified, for instance, in compliance documents defining 1074 minimalistic Clients and their capabilities in specific deployments. 1075 In turn, these might also have to consider the used application 1076 profile of this specification. 1078 * GET request to ace-group/GROUPNAME/kdc-pub-key , in order to 1079 retrieve the current public key of the KDC, in addition to when 1080 joining the group. This is relevant only if the KDC has an 1081 associated public key and this is required for the correct group 1082 operation. 1084 * GET request to ace-group/GROUPNAME/policies , in order to retrieve 1085 the current group policies as a group member, in addition to when 1086 joining the group. 1088 * GET request to ace-group/GROUPNAME/nodes/NODENAME, in order to 1089 retrieve the current group keying material and individual keying 1090 material. The former can also be retrieved through a GET request 1091 to ace-group/GROUPNAME/ (see above). The latter would not be 1092 possible to re-obtain as a group member. 1094 * PUT request to ace-group/GROUPNAME/nodes/NODENAME , in order to 1095 ask for new individual keying material. The Client would have to 1096 alternatively re-join the group through a POST request to ace- 1097 group/GROUPNAME/ (see above). Furthermore, depending on its roles 1098 in the group or on the application profile of this specification, 1099 the Client might simply not be associated to any individual keying 1100 material. 1102 * POST request to ace-group/GROUPNAME/nodes/NODENAME/pub-key , in 1103 order to provide the KDC with a new public key. The Client would 1104 have to alternatively re-join the group through a POST request to 1105 ace-group/GROUPNAME/ (see above). Furthermore, depending on its 1106 roles in the group, the Client might simply not have an associated 1107 public key to provide. 1109 It is REQUIRED of application profiles of this specification to 1110 categorize possible newly defined operations for Clients into primary 1111 operations and secondary operations, and to provide accompanying 1112 considerations (REQ12). 1114 4.1.2. Error Handling 1116 Upon receiving a request from a Client, the KDC MUST check that it is 1117 storing a valid access token from that Client. If this is not the 1118 case, the KDC MUST reply with a 4.01 (Unauthorized) error response. 1120 Unless the request targets the /ace-group resource, the KDC MUST 1121 check that it is storing a valid access token from that Client such 1122 that: 1124 * The scope specified in the access token includes a scope entry 1125 related to the group name GROUPNAME associated to targeted 1126 resource; and 1128 * The set of roles specified in that scope entry allows the Client 1129 to perform the requested operation on the targeted resource 1130 (REQ11). 1132 In case the KDC stores a valid access token but the verifications 1133 above fail, the KDC MUST reply with a 4.03 (Forbidden) error 1134 response. This response MAY be an AS Request Creation Hints, as 1135 defined in Section 5.3 of [I-D.ietf-ace-oauth-authz], in which case 1136 the Content-Format MUST be set to application/ace+cbor. 1138 If the request is not formatted correctly (e.g., required fields are 1139 not present or are not encoded as expected), the handler MUST reply 1140 with a 4.00 (Bad Request) error response. 1142 If the request includes unknown or non-expected fields, the handler 1143 MUST silently ignore them and continue processing the request. 1144 Application profiles of this specification MAY define optional or 1145 mandatory payload formats for specific error cases (OPT4). 1147 Some error responses from the KDC can have Content-Format set to 1148 application/ace-groupcomm+cbor. In such a case, the paylod of the 1149 response MUST be a CBOR map, which includes the following fields. 1151 * 'error', with value a CBOR integer specifying the error occurred 1152 at the KDC. The value is taken from the "Value" column of the 1153 "ACE Groupcomm Errors" registry defined in Section 11.13 of this 1154 specification. This field MUST be present. 1156 * 'error_description', with value a CBOR text string specifying a 1157 human-readable diagnostic description of the error occurred at the 1158 KDC, written in English. The diagnostic text is intended for 1159 software engineers as well as for device and network operators, in 1160 order to aid debugging and provide context for possible 1161 intervention. The diagnostic message SHOULD be logged by the KDC. 1162 This field MAY be present, and it is unlikely relevant in an 1163 unattended setup where human intervention is not expected. 1165 The 'error' and 'error_description' fields are defined as OPTIONAL to 1166 support for Clients (see Section 8). A Client supporting the 'error' 1167 parameter and able to understand the specified error may use that 1168 information to determine what actions to take next. 1170 Section 9 of this specification defines an initial set of error 1171 identifiers, as possible values for the 'error' field. Application 1172 profiles of this specification inherit this initial set or error 1173 identifiers and MAY define additional value (OPT5). 1175 4.2. /ace-group 1177 This resource implements the FETCH handler. 1179 4.2.1. FETCH Handler 1181 The FETCH handler receives group identifiers and returns the 1182 corresponding group names and GROUPNAME URIs. 1184 The handler expects a request with payload formatted as a CBOR map, 1185 which MUST contain the following fields: 1187 * 'gid', whose value is encoded as a CBOR array, containing one or 1188 more group identifiers. The exact encoding of group identifier 1189 MUST be specified by the application profile (REQ13). The Client 1190 indicates that it wishes to receive the group names and GROUPNAMEs 1191 of all groups having these identifiers. 1193 The handler identifies the groups that are secured by the keying 1194 material identified by those group identifiers. 1196 If all verifications succeed, the handler replies with a 2.05 1197 (Content) response, whose payload is formatted as a CBOR map that 1198 MUST contain the following fields: 1200 * 'gid', whose value is encoded as a CBOR array, containing zero or 1201 more group identifiers. The handler indicates that those are the 1202 identifiers it is sending group names and GROUPNAMEs for. This 1203 CBOR array is a subset of the 'gid' array in the FETCH request. 1205 * 'gname', whose value is encoded as a CBOR array, containing zero 1206 or more group names. The elements of this array are encoded as 1207 text strings. Each element of index i of this CBOR array 1208 corresponds to the element of group identifier i in the 'gid' 1209 array. 1211 * 'guri', whose value is encoded as a CBOR array, containing zero or 1212 more URIs, each indicating a GROUPNAME resource. The elements of 1213 this array are encoded as text strings. Each element of index i 1214 of this CBOR array corresponds to the element of group identifier 1215 i in the 'gid' array. 1217 If the KDC does not find any group associated to the specified group 1218 identifiers, the handler returns a response with payload formatted as 1219 a CBOR byte string of zero length. 1221 Note that the KDC only verifies that the node is authorized by the AS 1222 to access this resource. Nodes that are not members of the group but 1223 are authorized to do signature verification on the group messages may 1224 be allowed to access this resource, if the application needs it. 1226 4.2.1.1. Retrieve Group Names 1228 In case the joining node only knows the group identifier of the group 1229 it wishes to join or about which it wishes to get update information 1230 from the KDC, the node can contact the KDC to request the 1231 corresponding group name and joining resource URI. The node can 1232 request several group identifiers at once. It does so by sending a 1233 CoAP FETCH request to the /ace-group endpoint at the KDC formatted as 1234 defined in Section 4.2.1. 1236 Figure 6 gives an overview of the exchanges described above, and 1237 Figure 7 shows an example. 1239 Client KDC 1240 | | 1241 |-------- Group Name and URI Retrieval Request: -------->| 1242 | FETCH /ace-group | 1243 | | 1244 |<-Group Name and URI Retrieval Response: 2.05 (Content)-| 1245 | | 1247 Figure 6: Message Flow of Group Name and URI Retrieval Request- 1248 Response 1250 Request: 1252 Header: FETCH (Code=0.05) 1253 Uri-Host: "kdc.example.com" 1254 Uri-Path: "ace-group" 1255 Content-Format: "application/ace-groupcomm+cbor" 1256 Payload (in CBOR diagnostic notation): 1257 { "gid": [01, 02] } 1259 Response: 1261 Header: Content (Code=2.05) 1262 Content-Format: "application/ace-groupcomm+cbor" 1263 Payload (in CBOR diagnostic notation): 1264 { "gid": [01, 02], "gname": ["group1", "group2"], 1265 "guri": ["ace-group/g1", "ace-group/g2"] } 1267 Figure 7: Example of Group Name and URI Retrieval Request-Response 1269 4.3. /ace-group/GROUPNAME 1271 This resource implements the POST and GET and handlers. 1273 4.3.1. POST Handler 1275 The POST handler processes the Joining Request sent by a Client to 1276 join a group, and returns a Joining Response as successful result of 1277 the joining process (see Section 4.3.1.1). At a high level, the POST 1278 handler adds the Client to the list of current group members, adds 1279 the public key of the Client to the list of the group members' public 1280 keys, and returns the symmetric group keying material for the group 1281 identified by GROUPNAME. 1283 The handler expects a request with payload formatted as a CBOR map, 1284 which MAY contain the following fields, which, if included, MUST have 1285 format and value as specified below. 1287 * 'scope', with value the specific group that the Client is 1288 attempting to join, i.e., the group name, and the roles it wishes 1289 to have in the group. This value is a CBOR byte string wrapping 1290 one scope entry, as defined in Section 3.1. 1292 * 'get_pub_keys', if the Client wishes to receive the public keys of 1293 the current group members from the KDC. This parameter may be 1294 included in the Joining Request if the KDC stores the public keys 1295 of the group members, while it is not useful to include it if the 1296 Client obtains those public keys through alternative means, e.g., 1297 from the AS. Note that including this parameter might result in a 1298 following Joining Response of large size, which can be 1299 inconvenient for resource-constrained devices. 1301 If the Client wishes to retrieve the public keys of all the 1302 current group members, the 'get_pub_keys' parameter MUST encode 1303 the CBOR simple value 'null' (0xf6). Otherwise, the 1304 'get_pub_keys' parameter MUST encode a non-empty CBOR array, 1305 containing the following three elements formatted as defined 1306 below. 1308 - The first element, namely 'inclusion_flag', encodes the CBOR 1309 simple value True. That is, the Client indicates that it 1310 wishes to receive the public keys of all group members having 1311 their node identifier specified in the third element of the 1312 'get_pub_keys' array, namely 'id_filter' (see below). 1314 - The second element, namely 'role_filter', is a non-empty CBOR 1315 array. Each element of the array contains one role or a 1316 combination of roles for the group identified by GROUPNAME. 1317 That is, when the Joining Request includes a non-Null 1318 'get_pub_keys' parameter, the Client filters public keys based 1319 on node identifiers. 1321 In particular, the Client indicates that it wishes to retrieve 1322 the public keys of all the group members having any of the 1323 single roles, or at least all of the roles indicated in any 1324 combination of roles. For example, the array ["role1", 1325 "role2+role3"] indicates that the Client wishes to receive the 1326 public keys of all group members that have at least "role1" or 1327 at least both "role2" and "role3". 1329 - The third element, namely 'id_filter', is an empty CBOR array. 1330 That is, when the Joining Request includes a non-Null 1331 'get_pub_keys' parameter, the Client does not filter public 1332 keys based on node identifiers. 1334 In fact, when first joining the group, the Client is not 1335 expected or capable to express a filter based on node 1336 identifiers of other group members. Instead, when already a 1337 group member and sending a Joining Request to re-join, the 1338 Client is not expected to include the 'get_pub_keys' parameter 1339 in the Joining Request altogether, since it can rather retrieve 1340 public keys associated to specific group identifiers as defined 1341 in Section 4.4.1.1. 1343 The CDDL definition [RFC8610] of 'get_pub_keys' is given in 1344 Figure 8, using as example encoding: node identifier encoded as a 1345 CBOR byte string; role identifier encoded as a CBOR text string, 1346 and combination of roles encoded as a CBOR array of roles. 1348 Note that, for this handler, 'inclusion_flag' is always set to 1349 true, the array of roles 'role_filter' is always non-empty, while 1350 the array of node identifiers 'id_filter' is always empty. 1351 However, this is not necessarily the case for other handlers using 1352 the 'get_pub_keys' parameter. 1354 inclusion_flag = bool 1356 role = tstr 1357 comb_role = [ 2*role ] 1358 role_filter = [ *(role / comb_role) ] 1360 id = bstr 1361 id_filter = [ *id ] 1363 get_pub_keys = null / [ inclusion_flag, role_filter, id_filter] 1365 Figure 8: CDLL definition of get_pub_keys, using as example node 1366 identifier encoded as bstr and role as tstr 1368 * 'client_cred', encoded as a CBOR byte string, with value the 1369 original binary representation of the Client's public key. This 1370 parameter is used if the KDC is managing (collecting from/ 1371 distributing to the Client) the public keys of the group members, 1372 and if the Client's role in the group will require for it to send 1373 messages to one or more group members. It is REQUIRED of the 1374 application profiles to define the specific formats that are 1375 acceptable to use for encoding public keys in the group (REQ6). 1377 * 'cnonce', encoded as a CBOR byte string, and including a dedicated 1378 nonce N_C generated by the Client. This parameter MUST be present 1379 if the 'client_cred' parameter is present. 1381 * 'client_cred_verify', encoded as a CBOR byte string. This 1382 parameter MUST be present if the 'client_cred' parameter is 1383 present and no public key associated to the Client's token can be 1384 retrieved for that group. 1386 This parameter contains a proof-of-possession (PoP) evidence 1387 computed by the Client over the following PoP input: the scope 1388 (encoded as CBOR byte string), concatenated with N_S (encoded as 1389 CBOR byte string) concatenated with N_C (encoded as CBOR byte 1390 string), where: 1392 - scope is the CBOR byte string either specified in the 'scope' 1393 parameter above, if present, or as a default scope that the 1394 handler is expected to understand, if omitted. 1396 - N_S is the challenge received from the KDC in the 1397 'kdcchallenge' parameter of the 2.01 (Created) response to the 1398 Token Transfer Request (see Section 3.3), encoded as a CBOR 1399 byte string. 1401 - N_C is the nonce generated by the Client and specified in the 1402 'cnonce' parameter above, encoded as a CBOR byte string. 1404 An example of PoP input to compute 'client_cred_verify' using CBOR 1405 encoding is given in Figure 9. 1407 A possible type of PoP evidence is a signature, that the Client 1408 computes by using its own private key, whose corresponding public 1409 key is specified in the 'client_cred' parameter. Application 1410 profiles of this specification MUST specify the exact approaches 1411 used to compute the PoP evidence to include in 1412 'client_cred_verify', and MUST specify which of those approaches 1413 is used in which case (REQ14). 1415 If the token was not provided to the KDC through a Token Transfer 1416 Request (e.g., it is used directly to validate TLS instead), it is 1417 REQUIRED of the specific application profile to define how the 1418 challenge N_S is generated (REQ15). 1420 * 'pub_keys_repos', which can be present if the format of the 1421 Client's public key in the 'client_cred' parameter is a 1422 certificate. In such a case, this parameter has as value the URI 1423 of the certificate. This parameter is encoded as a CBOR text 1424 string. Alternative specific encodings of this parameter MAY be 1425 defined in applications of this specification (OPT6). 1427 * 'control_uri', with value a full URI, encoded as a CBOR text 1428 string. A default url-path is /ace-group/GROUPNAME/node, although 1429 implementations can use different ones instead. The URI MUST NOT 1430 have url-path ace-group/GROUPNAME. 1432 If 'control_uri' is specified in the Joining Request, the Client 1433 acts as a CoAP server and hosts a resource at this specific URI. 1434 The KDC MAY use this URI to send CoAP requests to the Client 1435 (acting as CoAP server in this exchange), for example for one-to- 1436 one provisioning of new group keying material when performing a 1437 group rekeying (see Section 4.8.1.1), or to inform the Client of 1438 its removal from the group Section 5. 1440 In particular, this resource is intended for communications 1441 concerning exclusively the group whose group name GROUPNAME is 1442 specified in the 'scope' parameter. If the KDC does not implement 1443 mechanisms using this resource for that group, it can ignore this 1444 parameter. Other additional functionalities of this resource MAY 1445 be defined in application profiles of this specifications (OPT7). 1447 scope, N_S, and N_C expressed in CBOR diagnostic notation: 1448 scope = h'826667726F7570316673656E646572' 1449 N_S = h'018a278f7faab55a' 1450 N_C = h'25a8991cd700ac01' 1452 scope, N_S, and N_C as CBOR encoded byte strings: 1453 scope = 0x4f826667726F7570316673656E646572 1454 N_S = 0x48018a278f7faab55a 1455 N_C = 0x4825a8991cd700ac01 1457 PoP input: 1458 0x4f 826667726F7570316673656E646572 1459 48 018a278f7faab55a 48 25a8991cd700ac01 1461 Figure 9: Example of PoP input to compute 'client_cred_verify' 1462 using CBOR encoding 1464 If the request does not include a 'scope' field, the KDC is expected 1465 to understand with what roles the Client is requesting to join the 1466 group. For example, as per the access token, the Client might have 1467 been granted access to the group with only one role. If the KDC 1468 cannot determine which exact scope should be considered for the 1469 Client, it MUST reply with a 4.00 (Bad Request) error response. 1471 The handler considers the scope specified in the access token 1472 associated to the Client, and checks the scope entry related to the 1473 group with name GROUPNAME associated to the endpoint. In particular, 1474 the handler checks whether the set of roles specified in that scope 1475 entry includes all the roles that the Client wishes to have in the 1476 group as per the Joining Request. If this is not the case, the KDC 1477 MUST reply with a 4.03 (Forbidden) error response. 1479 If the KDC manages the group members' public keys, the handler checks 1480 if one is included in the 'client_cred' field. If so, the KDC 1481 retrieves the public key and performs the following actions. 1483 * If the access token was provided through a Token Transfer Request 1484 (see Section 3.3) but the KDC cannot retrieve the 'kdcchallenge' 1485 associated to this Client (see Section 3.3), the KDC MUST reply 1486 with a 4.00 Bad Request error response, which MUST also have 1487 Content-Format application/ace-groupcomm+cbor. The payload of the 1488 error response is a CBOR map including a newly generated 1489 'kdcchallenge' value. This is specified in the 'kdcchallenge' 1490 parameter. 1492 * The KDC checks the public key to be valid for the group identified 1493 by GROUPNAME. That is, it checks that the public key is encoded 1494 according to the format used in the group, is intended for the 1495 public key algorithm used in the group, and is aligned with the 1496 possible associated parameters used in the group. 1498 If this verification fails, the handler MUST reply with a 4.00 1499 (Bad Request) error response. The response MUST have Content- 1500 Format set to application/ace-groupcomm+cbor and is formatted as 1501 defined in Section 4. The value of the 'error' field MUST be set 1502 to 2 ("Public key incompatible with the group configuration"). 1504 * The KDC verifies the PoP evidence contained in the 1505 'client_cred_verify' field. Application profiles of this 1506 specification MUST specify the exact approaches used to verify the 1507 PoP evidence, and MUST specify which of those approaches is used 1508 in which case (REQ14). 1510 If the PoP evidence does not pass verification, the handler MUST 1511 reply with a 4.00 (Bad Request) error response. The response MUST 1512 have Content-Format set to application/ace-groupcomm+cbor and is 1513 formatted as defined in Section 4. The value of the 'error' field 1514 MUST be set to 3 ("Invalid Proof-of-Possession evidence"). 1516 If no public key is included in the 'client_cred' field, the handler 1517 checks if a public key is already associated to the received access 1518 token and to the group identified by GROUPNAME (see also 1519 Section 4.3.1.1). Note that the same joining node may use different 1520 public keys in different groups, and all those public keys would be 1521 associate to the same access token. 1523 If an eligible public key for the Client is neither present in the 1524 'client_cred' field nor retrieved from the stored ones at the KDC, it 1525 is RECOMMENDED that the handler stops the processing and replies with 1526 a 4.00 (Bad Request) error response. Applications profiles MAY 1527 define alternatives (OPT8). 1529 If, regardless the reason, the KDC replies with a 4.00 (Bad Request) 1530 error response, this response MAY have Content-Format set to 1531 application/ace-groupcomm+cbor and have a CBOR map as payload. For 1532 instance, the CBOR map can include a 'sign_info' parameter formatted 1533 as 'sign_info_res' defined in Section 3.3.1, with the 'pub_key_enc' 1534 element set to the CBOR simple value 'null' (0xf6) if the Client sent 1535 its own public key and the KDC is not set to store public keys of the 1536 group members. 1538 If all the verifications above succeed, the KDC proceeds as follows. 1540 First, only in case the Client is not already a group member, the 1541 handler performs the following actions: 1543 * The handler adds the Client to the list of current members of the 1544 group. 1546 * The handler assigns a name NODENAME to the Client, and creates a 1547 sub-resource to /ace-group/GROUPNAME at the KDC, i.e., "/ace- 1548 group/GROUPNAME/nodes/NODENAME". 1550 * The handler associates the node identifier NODENAME to the access 1551 token and the secure session for the Client. 1553 Then, the handler performs the following actions. 1555 * If the KDC manages the group members' public keys: 1557 - The handler associates the retrieved Client's public key to the 1558 tuple composed of the node name NODENAME, the group name 1559 GROUPNAME and the received access token. 1561 - The handler adds the retrieved Client's public key to the 1562 stored list of public keys stored for the group identified by 1563 GROUPNAME. If such list already includes a public key for the 1564 Client, but a different public key is specified in the 1565 'client_cred' field, then the handler MUST replace the old 1566 public key in the list with the one specified in the 1567 'client_cred' field. 1569 * If the application requires backward security or if the used 1570 application profile prescribes so, the KDC MUST generate new group 1571 keying material and securely distribute it to the current group 1572 members (see Section 6). 1574 * The handler returns a successful Joining Response as defined 1575 below, containing the symmetric group keying material; the group 1576 policies; and the public keys of the current members of the group, 1577 if the KDC manages those and the Client requested them. 1579 The Joining Response MUST have response code 2.01 (Created) if the 1580 Client has been added to the list of group members in this joining 1581 exchange (see above), or 2.04 (Changed) otherwise, i.e., if the 1582 Client is re-joining the group without having left it. 1584 The Joining Response message MUST include the Location-Path CoAP 1585 option, specifying the URI path to the sub-resource associated to the 1586 Client, i.e. "/ace-group/GROUPNAME/nodes/NODENAME". 1588 The Joining Response message MUST have Content-Format application/ 1589 ace-groupcomm+cbor. The payload of the response is formatted as a 1590 CBOR map, which MUST contain the following fields and values. 1592 * 'gkty', identifying the key type of the 'key' parameter. The set 1593 of values can be found in the "Key Type" column of the "ACE 1594 Groupcomm Key Types" registry. Implementations MUST verify that 1595 the key type matches the application profile being used, if 1596 present, as registered in the "ACE Groupcomm Key Types" registry. 1598 * 'key', containing the keying material for the group communication, 1599 or information required to derive it. 1601 * 'num', containing the version number of the keying material for 1602 the group communication, formatted as an integer. This is a 1603 strictly monotonic increasing field. The application profile MUST 1604 define the initial version number (REQ16). 1606 The exact format of the 'key' value MUST be defined in applications 1607 of this specification (REQ17), as well as values of 'gkty' accepted 1608 by the application (REQ18). Additionally, documents specifying the 1609 key format MUST register it in the "ACE Groupcomm Key Types" registry 1610 defined in Section 11.8, including its name, type and application 1611 profile to be used with. 1613 +----------+----------------+---------+-------------------------+ 1614 | Name | Key Type Value | Profile | Description | 1615 +----------+----------------+---------+-------------------------+ 1616 | Reserved | 0 | | This value is reserved | 1617 +----------+----------------+---------+-------------------------+ 1619 Figure 10: Key Type Values 1621 The response SHOULD contain the following parameter: 1623 * 'exp', with value the expiration time of the keying material for 1624 the group communication, encoded as a CBOR unsigned integer. This 1625 field contains a numeric value representing the number of seconds 1626 from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, 1627 ignoring leap seconds, analogous to what specified for NumericDate 1628 in Section 2 of [RFC7519]. Group members MUST stop using the 1629 keying material to protect outgoing messages and retrieve new 1630 keying material at the time indicated in this field. 1632 Optionally, the response MAY contain the following parameters, which, 1633 if included, MUST have format and value as specified below. 1635 * 'ace-groupcomm-profile', with value a CBOR integer that MUST be 1636 used to uniquely identify the application profile for group 1637 communication. Applications of this specification MUST register 1638 an application profile identifier and the related value for this 1639 parameter in the "ACE Groupcomm Profiles" registry (REQ19). 1641 * 'pub_keys', MUST be present if 'get_pub_keys' was present in the 1642 request, otherwise it MUST NOT be present. This parameter is a 1643 CBOR array specifying the public keys of the group members, i.e., 1644 of all of them or of the ones selected according to the 1645 'get_pub_keys' parameter in the request. In particular, each 1646 element of the array is a CBOR byte string, with value the 1647 original binary representation of a group member's public key. It 1648 is REQUIRED of the application profiles to define the specific 1649 formats of public keys that are acceptable to use in the group 1650 (REQ6). 1652 * 'peer_roles', MUST be present if 'pub_keys' is also present, 1653 otherwise it MUST NOT be present. This parameter is a CBOR array 1654 of n elements, with n the number of public keys included in the 1655 'pub_keys' parameter (at most the number of members in the group). 1656 The i-th element of the array specifies the role (or CBOR array of 1657 roles) that the group member associated to the i-th public key in 1658 'pub_keys' has in the group. In particular, each array element is 1659 encoded as the role element of a scope entry, as defined in 1660 Section 3.1. 1662 * 'peer_identifiers', MUST be present if 'pub_keys' is also present, 1663 otherwise it MUST NOT be present. This parameter is a CBOR array 1664 of n elements, with n the number of public keys included in the 1665 'pub_keys' parameter (at most the number of members in the group). 1666 The i-th element of the array specifies the node identifier that 1667 the group member associated to the i-th public key in 'pub_keys' 1668 has in the group. In particular, the i-th array element is 1669 encoded as a CBOR byte string, with value the node identifier of 1670 the group member. 1672 * 'group_policies', with value a CBOR map, whose entries specify how 1673 the group handles specific management aspects. These include, for 1674 instance, approaches to achieve synchronization of sequence 1675 numbers among group members. The elements of this field are 1676 registered in the "ACE Groupcomm Policies" registry. This 1677 specification defines the three elements "Sequence Number 1678 Synchronization Methods", "Key Update Check Interval" and 1679 "Expiration Delta", which are summarized in Figure 11. 1680 Application profiles that build on this document MUST specify the 1681 exact content format and default value of included map entries 1682 (REQ20). 1684 +--------------+-------+----------+----------------------+------------+ 1685 | Name | CBOR | CBOR | Description | Reference | 1686 | | label | type | | | 1687 +--------------+-------+----------+----------------------+------------+ 1688 | Sequence | TBD | tstr/int | Method for recipient | [[this | 1689 | Number | | | group members to | document]] | 1690 | Synchroniza- | | | synchronize with | | 1691 | tion Method | | | sequence numbers of | | 1692 | | | | of sender group | | 1693 | | | | members. Its value | | 1694 | | | | is taken from the | | 1695 | | | | 'Value' column of | | 1696 | | | | the Sequence Number | | 1697 | | | | Synchronization | | 1698 | | | | Method registry | | 1699 +--------------+-------+----------+----------------------+------------+ 1700 | Key Update | TBD | int | Polling interval in | [[this | 1701 | Check | | | seconds, for group | document]] | 1702 | Interval | | | members to check at | | 1703 | | | | the KDC if the | | 1704 | | | | latest group keying | | 1705 | | | | material is the one | | 1706 | | | | that they own | | 1707 +--------------+-------+----------+----------------------+------------+ 1708 | Expiration | TBD | uint | Number of seconds | [[this | 1709 | Delta | | | from 'exp' until the | document]] | 1710 | | | | specified UTC | | 1711 | | | | date/time after | | 1712 | | | | which group members | | 1713 | | | | MUST stop using the | | 1714 | | | | group keying | | 1715 | | | | material they own to | | 1716 | | | | verify incoming | | 1717 | | | | messages | | 1718 +--------------+-------+----------|----------------------|------------+ 1720 Figure 11: ACE Groupcomm Policies 1722 * 'kdc_cred', encoded as a CBOR byte string, with value the original 1723 binary representation of the KDC's public key. This parameter is 1724 used if the KDC has an associated public key and this is required 1725 for the correct group operation. It is REQUIRED of application 1726 profiles to define whether the KDC has a public key and if this 1727 has to be provided through the 'kdc_cred' parameter (REQ8). 1729 In such a case, the KDC's public key MUST have the same format 1730 used for the public keys of the group members. It is REQUIRED of 1731 the application profiles to define the specific formats that are 1732 acceptable to use for encoding public keys in the group (REQ6). 1734 * 'kdc_nonce', encoded as a CBOR byte string, and including a 1735 dedicated nonce N_KDC generated by the KDC. This parameter MUST 1736 be present if the 'kdc_cred' parameter is present. 1738 * 'kdc_cred_verify' parameter, encoded as a CBOR byte string. This 1739 parameter MUST be present if the 'kdc_cred' parameter is present. 1741 This parameter contains a proof-of-possession (PoP) evidence 1742 computed by the KDC over the nonce N_KDC, which is specified in 1743 the 'kdc_nonce' parameter and taken as PoP input. 1745 A possible type of PoP evidence is a signature, that the KDC 1746 computes by using its own private key, whose corresponding public 1747 key is specified in the 'kdc_cred' parameter. Application 1748 profiles of this specification MUST specify the exact approaches 1749 used by the KDC to compute the PoP evidence to include in 1750 'kdc_cred_verify', and MUST specify which of those approaches is 1751 used in which case (REQ21). 1753 * 'rekeying_scheme', identifying the rekeying scheme that the KDC 1754 uses to provide new group keying meterial to the group members. 1755 This parameter is encoded as a CBOR integer, whose value is taken 1756 from the "Value" column of the "ACE Groupcomm Rekeying Schemes" 1757 registry defined in Section 11.14 of this specification. 1759 +-------+----------------+-------------------------------+-----------+ 1760 | Value | Name | Description | Reference | 1761 +-------+----------------+-------------------------------+-----------+ 1762 | 0 | Point-to-Point | The KDC individually targets | [this | 1763 | | | each node to rekey, using the | document] | 1764 | | | pairwise secure communication | | 1765 | | | association with that node | | 1766 +-------+----------------+-------------------------------+-----------+ 1768 Figure 12: ACE Groupcomm Rekeying Schemes 1770 Application profiles of this specification MAY define a default group 1771 rekeying scheme, to refer to in case the 'rekeying_scheme' parameter 1772 is not included in the Joining Response (OPT9). 1774 * 'mgt_key_material', encoded as a CBOR byte string and containing 1775 the specific administrative keying material that the joining node 1776 requires in order to participate in the group rekeying process 1777 performed by the KDC. This parameter MUST NOT be present if the 1778 'rekeying_scheme' parameter is not present and the application 1779 profile does not specify a default group rekeying scheme to use in 1780 the group. Some simple rekeying scheme may not require specific 1781 administrative keying material to be provided, e.g., the basic 1782 "Point-to-Point" group rekeying scheme (see Section 6.1). 1784 In more advanced group rekeying schemes, the administrative keying 1785 material can be composed of multiple keys organized, for instance, 1786 into a logical tree hierarchy, whose root key is the only 1787 administrative key shared by all the group members. In such a 1788 case, each group member is exclusively associated to one leaf key 1789 in the hierarchy, and owns only the administrative keys from the 1790 associated leaf key all the way up along the path to the root key. 1791 That is, different group members can be provided with a different 1792 subset of the overall administrative keying material. 1794 It is expected from separate documents to define how the advanced 1795 group rekeying scheme possibly indicated in the 'rekeying_scheme' 1796 parameter is used by an application profile of this specification. 1797 This includes defining the format of the administrative keying 1798 material to specify in 'mgt_key_material', consistently with the 1799 group rekeying scheme and the application profile in question. 1801 * 'control_group_uri', with value a full URI, encoded as a CBOR text 1802 string. The URI MUST specify addressing information intended to 1803 reach all the members in the group. For example, this can be a 1804 multicast IP address, optionally together with a port number 1805 (which defaults to 5683 if omitted). The URI MUST include 1806 GROUPNAME in the url-path. A default url-path is /ace-group/ 1807 GROUPNAME, although implementations can use different ones 1808 instead. The URI MUST NOT have url-path ace-group/GROUPNAME/node. 1810 If 'control_group_uri' is included in the Joining Response, the 1811 Clients supporting this parameter act as CoAP servers, host a 1812 resource at this specific URI, and listen to the specified 1813 addressing information. 1815 The KDC MAY use this URI to send one-to-many CoAP requests to the 1816 Client group members (acting as CoAP servers in this exchange), 1817 for example for one-to-many provisioning of new group keying 1818 material when performing a group rekeying (see Section 4.8.1.1), 1819 or to inform the Clients of their removal from the group 1820 Section 5. 1822 In particular, this resource is intended for communications 1823 concerning exclusively the group whose group name GROUPNAME is 1824 specified in the 'scope' parameter. If the KDC does not implement 1825 mechanisms using this resource for that group, it can ignore this 1826 parameter. Other additional functionalities of this resource MAY 1827 be defined in application profiles of this specifications (OPT10). 1829 If the Joining Response includes the 'kdc_cred_verify' parameter, the 1830 Client verifies the conveyed PoP evidence and considers the group 1831 joining unsuccessful in case of failed verification. Application 1832 profiles of this specification MUST specify the exact approaches used 1833 by the Client to verify the PoP evidence in 'kdc_cred_verify', and 1834 MUST specify which of those approaches is used in which case (REQ21). 1836 Specific application profiles that build on this document MUST 1837 specify the communication protocol that members of the group use to 1838 communicate with each other (REQ22) and how exactly the keying 1839 material is used to protect the group communication (REQ23). 1841 4.3.1.1. Join the Group 1843 Figure 13 gives an overview of the Joining exchange between Client 1844 and KDC, when the Client first joins a group, while Figure 14 shows 1845 an example. 1847 Client KDC 1848 | | 1849 |----- Joining Request: POST /ace-group/GROUPNAME ------>| 1850 | | 1851 |<--------- Joining Response: 2.01 (Created) ----------- | 1852 | Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME" | 1854 Figure 13: Message Flow of the Joining Exchange 1856 Request: 1858 Header: POST (Code=0.02) 1859 Uri-Host: "kdc.example.com" 1860 Uri-Path: "ace-group" 1861 Uri-Path: "g1" 1862 Content-Format: "application/ace-groupcomm+cbor" 1863 Payload (in CBOR diagnostic notation, 1864 with PUB_KEY and POP_EVIDENCE being CBOR byte strings): 1865 { "scope": << [ "group1", ["sender", "receiver"] ] >> , 1866 "get_pub_keys": [true, ["sender"], []], "client_cred": PUB_KEY, 1867 "cnonce": h'6df49c495409a9b5', "client_cred_verify": POP_EVIDENCE } 1869 Response: 1871 Header: Created (Code=2.01) 1872 Content-Format: "application/ace-groupcomm+cbor" 1873 Location-Path: "kdc.example.com" 1874 Location-Path: "g1" 1875 Location-Path: "nodes" 1876 Location-Path: "c101" 1877 Payload (in CBOR diagnostic notation, 1878 with KEY being a CBOR byte strings): 1879 { "gkty": 13, "key": KEY, "num": 12, "exp": 1609459200, 1880 "pub_keys": [ PUB_KEY1, PUB_KEY2 ], 1881 "peer_roles": ["sender", ["sender", "receiver"]], 1882 "peer_identifiers": [ ID1, ID2 ] } 1884 Figure 14: Example of First Exchange for Group Joining 1886 If not previously established, the Client and the KDC MUST first 1887 establish a pairwise secure communication channel (REQ24). This can 1888 be achieved, for instance, by using a transport profile of ACE. The 1889 Joining exchange MUST occur over that secure channel. The Client and 1890 the KDC MAY use that same secure channel to protect further pairwise 1891 communications that must be secured. 1893 The secure communication protocol is REQUIRED to establish the secure 1894 channel between Client and KDC by using the proof-of-possession key 1895 bound to the access token. As a result, the proof-of-possession to 1896 bind the access token to the Client is performed by using the proof- 1897 of-possession key bound to the access token for establishing secure 1898 communication between the Client and the KDC. 1900 To join the group, the Client sends a CoAP POST request to the /ace- 1901 group/GROUPNAME endpoint at the KDC, where GROUPNAME is the group 1902 name of the group to join, formatted as specified in Section 4.3.1. 1903 This group name is the same as in the scope entry corresponding to 1904 that group, specified in the 'scope' parameter of the Authorization 1905 Request/Response, or it can be retrieved from it. Note that, in case 1906 of successful joining, the Client will receive the URI to retrieve 1907 individual keying material and to leave the group in the Location- 1908 Path option of the response. 1910 If the node is joining a group for the first time, and the KDC 1911 maintains the public keys of the group members, the Client is 1912 REQUIRED to send its own public key and proof-of-possession (PoP) 1913 evidence in the Joining Request (see the 'client_cred' and 1914 'client_cred_verify' parameters in Section 4.3.1). The request is 1915 accepted only if both public key is provided and the PoP evidence is 1916 successfully verified. 1918 If a node re-joins a group as authorized by the same access token and 1919 using the same public key, it can omit the public key and the PoP 1920 evidence, or just the PoP evidence, from the Joining Request. Then, 1921 the KDC will be able to retrieve the node's public key associated to 1922 the access token for that group. If the public key has been 1923 discarded, the KDC replies with 4.00 (Bad Request) error response, as 1924 specified in Section 4.3.1. If a node re-joins a group but wants to 1925 update its own public key, it needs to include both its public key 1926 and the PoP evidence in the Joining Request like when it joined the 1927 group for the first time. 1929 4.3.2. GET Handler 1931 The GET handler returns the symmetric group keying material for the 1932 group identified by GROUPNAME. 1934 The handler expects a GET request. 1936 In addition to what is defined in Section 4.1.2, the handler verifies 1937 that the Client is a current member of the group. If the 1938 verification fails, the KDC MUST reply with a 4.03 (Forbidden) error 1939 response. The response MUST have Content-Format set to application/ 1940 ace-groupcomm+cbor and is formatted as defined in Section 4. The 1941 value of the 'error' field MUST be set to 0 ("Operation permitted 1942 only to group members"). 1944 If all verifications succeed, the handler replies with a 2.05 1945 (Content) response containing the symmetric group keying material. 1946 The payload of the response is formatted as a CBOR map which MUST 1947 contain the parameters 'gkty', 'key' and 'num' specified in 1948 Section 4.3.1. 1950 Each of the following parameters specified in Section 4.3.1 MUST also 1951 be included in the payload of the response, if they are included in 1952 the payload of the Joining Responses sent for the group: 1953 'rekeying_scheme', 'mgt_key_material'. 1955 The payload MAY also include the parameters 'ace-groupcomm-profile' 1956 and 'exp' parameters specified in Section 4.3.1. 1958 4.3.2.1. Retrieve Group Keying Material 1960 A node in the group can contact the KDC to retrieve the current group 1961 keying material, by sending a CoAP GET request to the /ace-group/ 1962 GROUPNAME endpoint at the KDC, where GROUPNAME is the group name. 1964 Figure 15 gives an overview of the Joining exchange between Client 1965 and KDC, when the Client first joins a group, while Figure 16 shows 1966 an example. 1968 Client KDC 1969 | | 1970 |----- Key Distribution Request: POST /ace-group/GROUPNAME ------>| 1971 | | 1972 |<----------- Key Distribution Response: 2.05 (Content) --------- | 1973 | | 1975 Figure 15: Message Flow of Key Distribution Request-Response 1977 Request: 1979 Header: GET (Code=0.01) 1980 Uri-Host: "kdc.example.com" 1981 Uri-Path: "ace-group" 1982 Uri-Path: "g1" 1983 Payload: - 1985 Response: 1987 Header: Content (Code=2.05) 1988 Content-Format: "application/ace-groupcomm+cbor" 1989 Payload (in CBOR diagnostic notation, 1990 with KEY being a CBOR byte strings): 1991 { "gkty": 13, "key": KEY, "num": 12 } 1993 Figure 16: Example of Key Distribution Request-Response 1995 4.4. /ace-group/GROUPNAME/pub-key 1997 This resource implements the GET and FETCH handlers. 1999 4.4.1. FETCH Handler 2001 The FETCH handler receives identifiers of group members for the group 2002 identified by GROUPNAME and returns the public keys of such group 2003 members. 2005 The handler expects a request with payload formatted as a CBOR map, 2006 that MUST contain the following field. 2008 * 'get_pub_keys', whose value is encoded as in Section 4.3.1 with 2009 the following modifications. 2011 - The arrays 'role_filter' and 'id_filter' MUST NOT both be 2012 empty, i.e., in CBOR diagnostic notation: [ bool, [ ], [ ] ]. 2013 If the 'get_pub_keys' parameter has such a format, the request 2014 MUST be considered malformed, and the KDC MUST reply with a 2015 4.00 (Bad Request) error response. 2017 Note that a group member can retrieve the public keys of all 2018 the current group members by sending a GET request to the same 2019 KDC resource instead (see Section 4.4.2.1). 2021 - The element 'inclusion_flag' encodes the CBOR simple value True 2022 if the third element 'id_filter' specifies an empty CBOR array, 2023 or if the Client wishes to receive the public keys of the nodes 2024 having their node identifier specified in 'id_filter' (i.e, 2025 selection by inclusive filtering). Instead, this element 2026 encodes the CBOR simple value False if the Client wishes to 2027 receive the public keys of the nodes not having the node 2028 identifiers specified in the third element 'id_filter' (i.e., 2029 selection by exclusive filtering). 2031 - The array 'role_filter' can be empty, if the Client does not 2032 wish to filter the requested public keys based on the roles of 2033 the group members. 2035 - The array 'id_filter' contains zero or more node identifiers of 2036 group members, for the group identified by GROUPNAME. The 2037 Client indicates that it wishes to receive the public keys of 2038 the nodes having or not having these node identifiers, in case 2039 the 'inclusion_flag' element encodes the CBOR simple value True 2040 or False, respectively. The array 'id_filter' may be empty, if 2041 the Client does not wish to filter the requested public keys 2042 based on the node identifiers of the group members. 2044 Note that, in case the 'role_filter' array and the 'id_filter' array 2045 are both non-empty: 2047 * If the 'inclusion_flag' encodes the CBOR simple value True, the 2048 handler returns the public keys of group members whose roles match 2049 with 'role_filter' and/or having their node identifier specified 2050 in 'id_filter'. 2052 * If the 'inclusion_flag' encodes the CBOR simple value False, the 2053 handler returns the public keys of group members whose roles match 2054 with 'role_filter' and, at the same time, not having their node 2055 identifier specified in 'id_filter'. 2057 The specific format of public keys as well as identifiers, roles and 2058 combination of roles of group members MUST be specified by It is 2059 REQUIRED of application profiles of this specification (REQ1, REQ6, 2060 REQ25). 2062 The handler identifies the public keys of the current group members 2063 for which either: 2065 * the role identifier matches with one of those indicated in the 2066 request; note that the request can contain a "combination of 2067 roles", where the handler select all group members who have all 2068 roles included in the combination. 2070 * the node identifier matches with one of those indicated in the 2071 request. 2073 If all verifications succeed, the handler returns a 2.05 (Content) 2074 message response with payload formatted as a CBOR map, containing 2075 only the following parameters from Section 4.3.1. 2077 * 'num', which encodes the version number of the current group 2078 keying material. 2080 * 'pub_keys', which encodes the list of public keys of the selected 2081 group members. 2083 * 'peer_roles', which encodes the role (or CBOR array of roles) that 2084 each of the selected group members has in the group. 2086 * 'peer_identifiers', which encodes the node identifier that each of 2087 the selected group members has in the group. 2089 The specific format of public keys as well as of node identifiers of 2090 group members is specified by the application profile (REQ6, REQ25). 2092 If the KDC does not store any public key associated to the specified 2093 node identifiers, the handler returns a response with payload 2094 formatted as a CBOR byte string of zero length. 2096 The handler MAY enforce one of the following policies, in order to 2097 handle possible node identifiers that are included in the 'id_filter' 2098 element of the 'get_pub_keys' parameter of the request but are not 2099 associated to any current group member. Such a policy MUST be 2100 specified by the application profile (REQ26). 2102 * The KDC silently ignores those node identifiers. 2104 * The KDC retains public keys of group members for a given amount of 2105 time after their leaving, before discarding them. As long as such 2106 public keys are retained, the KDC provides them to a requesting 2107 Client. 2109 If the KDC adopts this policy, the application profile MUST also 2110 specify the amount of time during which the KDC retains the public 2111 key of a former group member after its leaving, possibly on a per- 2112 member basis. 2114 Note that this resource handler only verifies that the node is 2115 authorized by the AS to access this resource. Nodes that are not 2116 members of the group but are authorized to do signature verifications 2117 on the group messages may be allowed to access this resource, if the 2118 application needs it. 2120 4.4.1.1. Retrieve a Subset of Public Keys in the Group 2122 In case the KDC maintains the public keys of group members, a node in 2123 the group can contact the KDC to request the public keys, roles and 2124 node identifiers of a specified subset of group members, by sending a 2125 CoAP FETCH request to the /ace-group/GROUPNAME/pub-key endpoint at 2126 the KDC, where GROUPNAME is the group name, and formatted as defined 2127 in Section 4.4.1. 2129 Figure 17 gives an overview of the exchange mentioned above, while 2130 Figure 18 shows an example of such an exchange. 2132 Client KDC 2133 | | 2134 |-Public Key Request: FETCH /ace-group/GROUPNAME/pub-key->| 2135 | | 2136 |<--------- Public Key Response: 2.05 (Created) ----------| 2137 | | 2139 Figure 17: Message Flow of Public Key Exchange to Request the 2140 Public Keys of Specific Group Members 2142 Request: 2144 Header: FETCH (Code=0.05) 2145 Uri-Host: "kdc.example.com" 2146 Uri-Path: "ace-group" 2147 Uri-Path: "g1" 2148 Uri-Path: "pub-key" 2149 Content-Format: "application/ace-groupcomm+cbor" 2150 Payload: 2151 { "get_pub_keys": [true, [], [ ID3 ]] } 2153 Response: 2155 Header: Content (Code=2.05) 2156 Content-Format: "application/ace-groupcomm+cbor" 2157 Payload (in CBOR diagnostic notation): 2158 { "pub_keys": [ PUB_KEY3 ], 2159 "peer_roles": [ "receiver" ], 2160 "peer_identifiers": [ ID3 ] } 2162 Figure 18: Example of Public Key Exchange to Request the Public 2163 Keys of Specific Group Members 2165 4.4.2. GET Handler 2167 The handler expects a GET request. 2169 If all verifications succeed, the KDC replies with a 2.05 (Content) 2170 response as in the FETCH handler in Section 4.4.1, but specifying in 2171 the payload the public keys of all the group members, together with 2172 their roles and node identifiers. 2174 4.4.2.1. Retrieve All Public Keys in the Group 2176 In case the KDC maintains the public keys of group members, a group 2177 or an external signature verifier can contact the KDC to request the 2178 public keys, roles and node identifiers of all the current group 2179 members, by sending a CoAP GET request to the /ace-group/GROUPNAME/ 2180 pub-key endpoint at the KDC, where GROUPNAME is the group name. 2182 Figure 19 gives an overview of the message exchange, while Figure 20 2183 shows an example of such an exchange. 2185 Client KDC 2186 | | 2187 |--Public Key Request: GET /ace-group/GROUPNAME/pub-key->| 2188 | | 2189 |<--------- Public Key Response: 2.05 (Content) ---------| 2190 | | 2192 Figure 19: Message Flow of Public Key Exchange to Request the 2193 Public Keys of all the Group Members 2195 Request: 2197 Header: GET (Code=0.01) 2198 Uri-Host: "kdc.example.com" 2199 Uri-Path: "ace-group" 2200 Uri-Path: "g1" 2201 Uri-Path: "pub-key" 2202 Payload: - 2204 Response: 2206 Header: Content (Code=2.05) 2207 Content-Format: "application/ace-groupcomm+cbor" 2208 Payload (in CBOR diagnostic notation): 2209 { "num": 5, 2210 "pub_keys": [ PUB_KEY1, PUB_KEY2, PUB_KEY3 ], 2211 "peer_roles": ["sender", ["sender", "receiver"], "receiver"], 2212 "peer_identifiers": [ ID1, ID2, ID3 ] } 2214 Figure 20: Example of Public Key Exchange to Request the Public 2215 Keys of all the Group Members 2217 4.5. ace-group/GROUPNAME/kdc-pub-key 2219 This resource implements a GET handler. 2221 4.5.1. GET Handler 2223 The handler expects a GET request. 2225 If all verifications succeed, the handler returns a 2.05 (Content) 2226 message containing the KDC's public key together with a proof-of- 2227 possession (PoP) evidence. The response MUST have Content-Format set 2228 to application/ace-groupcomm+cbor. The payload of the response is a 2229 CBOR map, which includes the following fields. 2231 * The 'kdc_cred' parameter, specifying the KDC's public key. This 2232 parameter is encoded like the 'kdc_cred' parameter in the Joining 2233 Response (see Section 4.3.1). 2235 * The 'kdc_nonce' parameter, specifying a nonce generated by the 2236 KDC. This parameter is encoded like the 'kdc_nonce' parameter in 2237 the Joining Response (see Section 4.3.1). 2239 * The 'kdc_cred_verify' parameter, specifying a PoP evidence 2240 computed by the KDC. This parameter is encoded like the 2241 'kdc_cred_verify' parameter in the Joining Response (see 2242 Section 4.3.1). 2244 The PoP evidence is computed over the nonce specified in the 2245 'kdc_nonce' parameter and taken as PoP input, by means of the same 2246 method used when preparing the Joining Response (see 2247 Section 4.3.1). Application profiles of this specification MUST 2248 specify the exact approaches used by the KDC to compute the PoP 2249 evidence to include in 'kdc_cred_verify', and MUST specify which 2250 of those approaches is used in which case (REQ21). 2252 4.5.1.1. Retrieve the KDC's Public Key 2254 In case the KDC has an associated public key as required for the 2255 correct group operation, a group member or an external signature 2256 verifier can contact the KDC to request the KDC's public key, by 2257 sending a CoAP GET request to the /ace-group/GROUPNAME/kdc-pub-key 2258 endpoint at the KDC, where GROUPNAME is the group name. 2260 Upon receiving the 2.05 (Content) response, the Client retrieves the 2261 KDC's public key from the 'kdc_cred' parameter, and MUST verify the 2262 proof-of-possession (PoP) evidence specified in the 'kdc_cred_verify' 2263 parameter. In case of successful verification of the PoP evidence, 2264 the Client MUST store the obtained KDC's public key and replace the 2265 currently stored one. 2267 The PoP evidence is verified by means of the same method used when 2268 processing the Joining Response (see Section 4.3.1). Application 2269 profiles of this specification MUST specify the exact approaches used 2270 by the Client to verify the PoP evidence in 'kdc_cred_verify', and 2271 MUST specify which of those approaches is used in which case (REQ21). 2273 Figure 21 gives an overview of the exchange described above, while 2274 Figure 22 shows an example. 2276 Group 2277 Member KDC 2278 | | 2279 | KDC Public Key Request | 2280 |------------------------------------------------------------>| 2281 | GET ace-group/GROUPNAME/gm-pub-key | 2282 | | 2283 |<--------- KDC Public Key Response: 2.05 (Content) ----------| 2284 | | 2286 Figure 21: Message Flow of KDC Public Key Request-Response 2288 Request: 2290 Header: GET (Code=0.01) 2291 Uri-Host: "kdc.example.com" 2292 Uri-Path: "ace-group" 2293 Uri-Path: "g1" 2294 Uri-Path: "kdc-pub-key" 2295 Payload: - 2297 Response: 2299 Header: Content (Code=2.05) 2300 Content-Format: "application/ace-groupcomm+cbor" 2301 Payload (in CBOR diagnostic notation, with PUB_KEY_KDC 2302 and POP_EVIDENCE being CBOR byte strings): 2303 { 2304 "kdc_nonce": h'25a8991cd700ac01', 2305 "kdc_cred": PUB_KEY_KDC, 2306 "kdc_cred_verify": POP_EVIDENCE 2307 } 2309 Figure 22: Example of KDC Public Key Request-Response 2311 4.6. /ace-group/GROUPNAME/policies 2313 This resource implements the GET handler. 2315 4.6.1. GET Handler 2317 The handler expects a GET request. 2319 In addition to what is defined in Section 4.1.2, the handler verifies 2320 that the Client is a current member of the group. If the 2321 verification fails, the KDC MUST reply with a 4.03 (Forbidden) error 2322 response. The response MUST have Content-Format set to application/ 2323 ace-groupcomm+cbor and is formatted as defined in Section 4. The 2324 value of the 'error' field MUST be set to 0 ("Operation permitted 2325 only to group members"). 2327 If all verifications succeed, the handler replies with a 2.05 2328 (Content) response containing the list of policies for the group 2329 identified by GROUPNAME. The payload of the response is formatted as 2330 a CBOR map including only the parameter 'group_policies' defined in 2331 Section 4.3.1 and specifying the current policies in the group. If 2332 the KDC does not store any policy, the payload is formatted as a 2333 zero-length CBOR byte string. 2335 The specific format and meaning of group policies MUST be specified 2336 in the application profile (REQ20). 2338 4.6.1.1. Retrieve the Group Policies 2340 A node in the group can contact the KDC to retrieve the current group 2341 policies, by sending a CoAP GET request to the /ace-group/GROUPNAME/ 2342 policies endpoint at the KDC, where GROUPNAME is the group name, and 2343 formatted as defined in Section 4.6.1 2345 Figure 23 gives an overview of the exchange described above, while 2346 Figure 24 shows an example. 2348 Client KDC 2349 | | 2350 |-Policies Request: GET ace-group/GROUPNAME/policies ->| 2351 | | 2352 |<--------- Policies Response: 2.05 (Content) ---------| 2353 | | 2355 Figure 23: Message Flow of Policies Request-Response 2357 Request: 2359 Header: GET (Code=0.01) 2360 Uri-Host: "kdc.example.com" 2361 Uri-Path: "ace-group" 2362 Uri-Path: "g1" 2363 Uri-Path: "policies" 2364 Payload: - 2366 Response: 2368 Header: Content (Code=2.05) 2369 Content-Format: "application/ace-groupcomm+cbor" 2370 Payload(in CBOR diagnostic notation): 2371 { "group_policies": {"exp-delta": 120} } 2373 Figure 24: Example of Policies Request-Response 2375 4.7. /ace-group/GROUPNAME/num 2377 This resource implements the GET handler. 2379 4.7.1. GET Handler 2381 The handler expects a GET request. 2383 In addition to what is defined in Section 4.1.2, the handler verifies 2384 that the Client is a current member of the group. If the 2385 verification fails, the KDC MUST reply with a 4.03 (Forbidden) error 2386 response. The response MUST have Content-Format set to application/ 2387 ace-groupcomm+cbor and is formatted as defined in Section 4. The 2388 value of the 'error' field MUST be set to 0 ("Operation permitted 2389 only to group members"). 2391 If all verifications succeed, the handler returns a 2.05 (Content) 2392 message containing an integer that represents the version number of 2393 the symmetric group keying material. This number is incremented on 2394 the KDC every time the KDC updates the symmetric group keying 2395 material, before the new keying material is distributed. This number 2396 is stored in persistent storage. 2398 The payload of the response is formatted as a CBOR integer. 2400 4.7.1.1. Retrieve the Keying Material Version 2402 A node in the group can contact the KDC to request information about 2403 the version number of the symmetric group keying material, by sending 2404 a CoAP GET request to the /ace-group/GROUPNAME/num endpoint at the 2405 KDC, where GROUPNAME is the group name, formatted as defined in 2406 Section 4.7.1. In particular, the version is incremented by the KDC 2407 every time the group keying material is renewed, before it's 2408 distributed to the group members. 2410 Figure 25 gives an overview of the exchange described above, while 2411 Figure 26 shows an example. 2413 Client KDC 2414 | | 2415 |---- Version Request: GET ace-group/GROUPNAME/num ---->| 2416 | | 2417 |<--------- Version Response: 2.05 (Content) -----------| 2418 | | 2420 Figure 25: Message Flow of Version Request-Response 2422 Request: 2424 Header: GET (Code=0.01) 2425 Uri-Host: "kdc.example.com" 2426 Uri-Path: "ace-group" 2427 Uri-Path: "g1" 2428 Uri-Path: "num" 2429 Payload: - 2431 Response: 2433 Header: Content (Code=2.05) 2434 Content-Format: "application/ace-groupcomm+cbor" 2435 Payload(in CBOR diagnostic notation): 2436 13 2438 Figure 26: Example of Version Request-Response 2440 4.8. /ace-group/GROUPNAME/nodes/NODENAME 2442 This resource implements the GET, PUT and DELETE handlers. 2444 In addition to what is defined in Section 4.1.2, each of the handlers 2445 performs the following two verifications. 2447 * The handler verifies that the Client is a current member of the 2448 group. If the verification fails, the KDC MUST reply with a 4.03 2449 (Forbidden) error response. The response MUST have Content-Format 2450 set to application/ace-groupcomm+cbor and is formatted as defined 2451 in Section 4. The value of the 'error' field MUST be set to 0 2452 ("Operation permitted only to group members"). 2454 * The handler verifies that the node name of the Client is equal to 2455 NODENAME used in the url-path. If the verification fails, the 2456 handler replies with a 4.03 (Forbidden) error response. 2458 4.8.1. GET Handler 2460 The handler expects a GET request. 2462 If all verifications succeed, the handler replies with a 2.05 2463 (Content) response containing both the group keying material and the 2464 individual keying material for the Client, or information enabling 2465 the Client to derive it. The payload of the response is formatted as 2466 a CBOR map. The format for the group keying material is the same as 2467 defined in the response of Section 4.3.2. The specific format of 2468 individual keying material for group members, or of the information 2469 to derive it, and corresponding CBOR label, MUST be specified in the 2470 application profile (REQ27) and registered in Section 11.7. 2472 Optionally, the KDC can make the sub-resource at ace- 2473 group/GROUPNAME/nodes/NODENAME also Observable [RFC7641] for the 2474 associated node. In case the KDC removes that node from the group 2475 without having been explicitly asked for it, this allows the KDC to 2476 send an unsolicited 4.04 (Not Found) response to the node as a 2477 notification of eviction from the group (see Section 5). 2479 Note that the node could have been observing also the resource at 2480 ace-group/GROUPNAME, in order to be informed of changes in the keying 2481 material. In such a case, this method would result in largely 2482 overlapping notifications received for the resource at ace-group/ 2483 GROUPNAME and the sub-resource at ace-group/GROUPNAME/nodes/NODENAME. 2485 In order to mitigate this, a node that supports the No-Response 2486 option [RFC7967] can use it when starting the observation of the sub- 2487 resource at ace-group/GROUPNAME/nodes/NODENAME. In particular, the 2488 GET observation request can also include the No-Response option, with 2489 value set to 2 (Not interested in 2.xx responses). 2491 4.8.1.1. Retrieve Group and Individual Keying Material 2493 When any of the following happens, a node MUST stop using the owned 2494 group keying material to protect outgoing messages, and SHOULD stop 2495 using it to decrypt and verify incoming messages. 2497 * Upon expiration of the keying material, according to what 2498 indicated by the KDC with the 'exp' parameter in a Joining 2499 Response, or to a pre-configured value. 2501 * Upon receiving a notification of revoked/renewed keying material 2502 from the KDC, possibly as part of an update of the keying material 2503 (rekeying) triggered by the KDC. 2505 * Upon receiving messages from other group members without being 2506 able to retrieve the keying material to correctly decrypt them. 2507 This may be due to rekeying messages previously sent by the KDC, 2508 that the Client was not able to receive or decrypt. 2510 In either case, if it wants to continue participating in the group 2511 communication, the node has to request the latest keying material 2512 from the KDC. To this end, the Client sends a CoAP GET request to 2513 the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, 2514 formatted as specified in Section 4.8.1. 2516 Note that policies can be set up, so that the Client sends a Key Re- 2517 Distribution request to the KDC only after a given number of received 2518 messages could not be decrypted (because of failed decryption 2519 processing or inability to retrieve the necessary keying material). 2521 It is application dependent and pertaining to the particular message 2522 exchange (e.g., [I-D.ietf-core-oscore-groupcomm]) to set up these 2523 policies for instructing Clients to retain incoming messages and for 2524 how long (OPT11). This allows Clients to possibly decrypt such 2525 messages after getting updated keying material, rather than just 2526 consider them non valid messages to discard right away. 2528 The same Key Distribution Request could also be sent by the Client 2529 without being triggered by a failed decryption of a message, if the 2530 Client wants to be sure that it has the latest group keying material. 2531 If that is the case, the Client will receive from the KDC the same 2532 group keying material it already has in memory. 2534 Figure 27 gives an overview of the exchange described above, while 2535 Figure 28 shows an example. 2537 Client KDC 2538 | | 2539 |------------------ Key Distribution Request: --------------->| 2540 | GET ace-group/GROUPNAME/nodes/NODENAME | 2541 | | 2542 |<-------- Key Distribution Response: 2.05 (Content) ---------| 2543 | | 2545 Figure 27: Message Flow of Key Distribution Request-Response 2547 Request: 2549 Header: GET (Code=0.01) 2550 Uri-Host: "kdc.example.com" 2551 Uri-Path: "ace-group" 2552 Uri-Path: "g1" 2553 Uri-Path: "nodes" 2554 Uri-Path: "c101" 2555 Payload: - 2557 Response: 2559 Header: Content (Code=2.05) 2560 Content-Format: "application/ace-groupcomm+cbor" 2561 Payload (in CBOR diagnostic notation, 2562 with KEY and IND_KEY being CBOR byte strings, 2563 and "ind-key" the profile-specified label 2564 for individual keying material): 2565 { "gkty": 13, "key": KEY, "num": 12, "ind-key": IND_KEY } 2567 Figure 28: Example of Key Distribution Request-Response 2569 4.8.2. PUT Handler 2571 The PUT handler processes requests from a Client that asks for new 2572 individual keying material, as required to process messages exchanged 2573 in the group. 2575 The handler expects a PUT request with empty payload. 2577 In addition to what is defined in Section 4.1.2 and at the beginning 2578 of Section 4.8, the handler verifies that this operation is 2579 consistent with the set of roles that the Client has in the group 2580 (REQ11). If the verification fails, the KDC MUST reply with a 4.00 2581 (Bad Request) error response. The response MUST have Content-Format 2582 set to application/ace-groupcomm+cbor and is formatted as defined in 2583 Section 4. The value of the 'error' field MUST be set to 1 ("Request 2584 inconsistent with the current roles"). 2586 If the KDC is currently not able to serve this request, i.e., to 2587 generate new individual keying material for the requesting Client, 2588 the KDC MUST reply with a 5.03 (Service Unavailable) error response. 2589 The response MUST have Content-Format set to application/ace- 2590 groupcomm+cbor and is formatted as defined in Section 4. The value 2591 of the 'error' field MUST be set to 4 ("No available node 2592 identifiers"). 2594 If all verifications succeed, the handler reply with a 2.05 (Content) 2595 response containing newly generated, individual keying material for 2596 the Client. The payload of the response is formatted as a CBOR map. 2597 The specific format of newly-generated individual keying material for 2598 group members, or of the information to derive it, and corresponding 2599 CBOR label, MUST be specified in the application profile (REQ27) and 2600 registered in Section 11.7. 2602 The typical successful outcome consists in replying with newly 2603 generated, individual keying material for the Client, as defined 2604 above. However, application profiles of this specification MAY also 2605 extend this handler in order to achieve different akin outcomes 2606 (OPT12), for instance: 2608 * Not providing the Client with newly generated, individual keying 2609 material, but rather rekeying the whole group, i.e., providing all 2610 the current group members with newly generated group keying 2611 material. 2613 * Both providing the Client with newly generated, individual keying 2614 material, as well as rekeying the whole group, i.e., providing all 2615 the current group members with newly generated group keying 2616 material. 2618 In either case, the handler may specify the new group keying material 2619 as part of the 2.05 (Content) response. 2621 Note that this handler is not intended to accommodate requests from a 2622 group member to trigger a group rekeying, whose scheduling and 2623 execution is an exclusive prerogative of the KDC. 2625 4.8.2.1. Request to Change Individual Keying Material 2627 A Client may ask the KDC for new, individual keying material. For 2628 instance, this can be due to the expiration of such individual keying 2629 material, or to the exhaustion of AEAD nonces, if an AEAD encryption 2630 algorithm is used for protecting communications in the group. An 2631 example of individual keying material can simply be an individual 2632 encryption key associated to the Client. Hence, the Client may ask 2633 for a new individual encryption key, or for new input material to 2634 derive it. 2636 To this end, the Client performs a Key Renewal Request/Response 2637 exchange with the KDC, i.e., it sends a CoAP PUT request to the /ace- 2638 group/GROUPNAME/nodes/NODENAME endpoint at the KDC, where GROUPNAME 2639 is the group name and NODENAME is its node name, and formatted as 2640 defined in Section 4.8.1. 2642 Figure 29 gives an overview of the exchange described above, while 2643 Figure 30 shows an example. 2645 Client KDC 2646 | | 2647 |------------------ Key Renewal Request: -------------->| 2648 | PUT ace-group/GROUPNAME/nodes/NODENAME | 2649 | | 2650 |<-------- Key Renewal Response: 2.05 (Content) --------| 2651 | | 2653 Figure 29: Message Flow of Key Renewal Request-Response 2655 Request: 2657 Header: PUT (Code=0.03) 2658 Uri-Host: "kdc.example.com" 2659 Uri-Path: "ace-group" 2660 Uri-Path: "g1" 2661 Uri-Path: "nodes" 2662 Uri-Path: "c101" 2663 Payload: - 2665 Response: 2667 Header: Content (Code=2.05) 2668 Content-Format: "application/ace-groupcomm+cbor" 2669 Payload (in CBOR diagnostic notation, with IND_KEY being 2670 a CBOR byte string, and "ind-key" the profile-specified 2671 label for individual keying material): 2672 { "ind-key": IND_KEY } 2673 Figure 30: Example of Key Renewal Request-Response 2675 Note the difference between the Key Renewal Request in this section 2676 and the Key Distribution Request in Section 4.8.1.1. The former asks 2677 the KDC for new individual keying material, while the latters asks 2678 the KDC for the current group keying material together with the 2679 current individual keying material. 2681 As discussed in Section 4.8.2, application profiles of this 2682 specification may define alternative outcomes for the Key Renewal 2683 Request-Response exchange (OPT12), where the provisioning of new 2684 individual keying material is replaced by or combined with the 2685 execution of a whole group rekeying. 2687 4.8.3. DELETE Handler 2689 The DELETE handler removes the node identified by NODENAME from the 2690 group identified by GROUPNAME. 2692 The handler expects a DELETE request with empty payload. 2694 In addition to what is defined in Section 4.1.2, the handler verifies 2695 that the Client is a current member of the group. If the 2696 verification fails, the KDC MUST reply with a 4.03 (Forbidden) error 2697 response. The response MUST have Content-Format set to application/ 2698 ace-groupcomm+cbor and is formatted as defined in Section 4. The 2699 value of the 'error' field MUST be set to 0 ("Operation permitted 2700 only to group members"). 2702 If all verification succeeds, the handler performs the actions 2703 defined in Section 5 and replies with a 2.02 (Deleted) response with 2704 empty payload. 2706 4.8.3.1. Leave the Group 2708 A Client can actively request to leave the group. In this case, the 2709 Client sends a CoAP DELETE request to the endpoint /ace- 2710 group/GROUPNAME/nodes/NODENAME at the KDC, where GROUPNAME is the 2711 group name and NODENAME is its node name, formatted as defined in 2712 Section 4.8.3 2714 Note that, after having left the group, the Client may wish to join 2715 it again. Then, as long as the Client is still authorized to join 2716 the group, i.e., the associated access token is still valid, the 2717 Client can request to re-join the group directly to the KDC (see 2718 Section 4.3.1.1), without having to retrieve a new access token from 2719 the AS. 2721 4.9. /ace-group/GROUPNAME/nodes/NODENAME/pub-key 2723 This resource implements the POST handler. 2725 4.9.1. POST Handler 2727 The POST handler is used to replace the stored public key of this 2728 Client (identified by NODENAME) with the one specified in the request 2729 at the KDC, for the group identified by GROUPNAME. 2731 The handler expects a POST request with payload as specified in 2732 Section 4.3.1, with the difference that it includes only the 2733 parameters 'client_cred', 'cnonce' and 'client_cred_verify'. In 2734 particular, the PoP evidence included in 'client_cred_verify' is 2735 computed in the same way considered in Section 4.3.1 and defined by 2736 the specific application profile (REQ14), with a newly generated N_C 2737 nonce and the previously received N_S. It is REQUIRED of the 2738 application profiles to define the specific formats of public keys 2739 that are acceptable to use in the group (REQ6). 2741 In addition to what is defined in Section 4.1.2 and at the beginning 2742 of Section 4.8, the handler verifies that this operation is 2743 consistent with the set of roles that the node has in the group. If 2744 the verification fails, the KDC MUST reply with a 4.00 (Bad Request) 2745 error response. The response MUST have Content-Format set to 2746 application/ace-groupcomm+cbor and is formatted as defined in 2747 Section 4. The value of the 'error' field MUST be set to 1 ("Request 2748 inconsistent with the current roles"). 2750 If the KDC cannot retrieve the 'kdcchallenge' associated to this 2751 Client (see Section 3.3), the KDC MUST reply with a 4.00 (Bad 2752 Request) error response, which MUST also have Content-Format 2753 application/ace-groupcomm+cbor. The payload of the error response is 2754 a CBOR map including a newly generated 'kdcchallenge' value. This is 2755 specified in the 'kdcchallenge' parameter. In such a case the KDC 2756 MUST store the newly generated value as the 'kdcchallenge' value 2757 associated to this Client, possibly replacing the currently stored 2758 value. 2760 Otherwise, the handler checks that the public key specified in the 2761 'client_cred' field is valid for the group identified by GROUPNAME. 2762 That is, the handler checks that the public key is encoded according 2763 to the format used in the group, is intended for the public key 2764 algorithm used in the group, and is aligned with the possible 2765 associated parameters used in the group. If that cannot be 2766 successfully verified, the handler MUST reply with a 4.00 (Bad 2767 Request) error response. The response MUST have Content-Format set 2768 to application/ace-groupcomm+cbor and is formatted as defined in 2769 Section 4. The value of the 'error' field MUST be set to 2 ("Public 2770 key incompatible with the group configuration"). 2772 Otherwise, the handler verifies the PoP evidence contained in the 2773 'client_cred_verify' field of the request, by using the public key 2774 specified in the 'client_cred' field, as well as the same way 2775 considered in Section 4.3.1 and defined by the specific application 2776 profile (REQ14). If the PoP evidence does not pass verification, the 2777 handler MUST reply with a 4.00 (Bad Request) error response. The 2778 response MUST have Content-Format set to application/ace- 2779 groupcomm+cbor and is formatted as defined in Section 4. The value 2780 of the 'error' field MUST be set to 3 ("Invalid Proof-of-Possession 2781 evidence"). 2783 If all verifications succeed, the handler performs the following 2784 actions. 2786 * The handler associates the public key from the 'client_cred' field 2787 of the request to the node identifier NODENAME and to the access 2788 token associated to the node identified by NODENAME. 2790 * In the stored list of group members' public keys for the group 2791 identified by GROUPNAME, the handler replaces the public key of 2792 the node identified by NODENAME with the public key specified in 2793 the 'client_cred' field of the request. 2795 Then, the handler replies with a 2.04 (Changed) response, which does 2796 not include a payload. 2798 4.9.1.1. Uploading a New Public Key 2800 In case the KDC maintains the public keys of group members, a node in 2801 the group can contact the KDC to upload a new public key to use in 2802 the group, and replace the currently stored one. 2804 To this end, the Client performs a Public Key Update Request/Response 2805 exchange with the KDC, i.e., it sends a CoAP POST request to the 2806 /ace-group/GROUPNAME/nodes/NODENAME/pub-key endpoint at the KDC, 2807 where GROUPNAME is the group name and NODENAME is its node name. 2809 The request is formatted as specified in Section 4.9.1. 2811 Figure Figure 31 gives an overview of the exchange described above, 2812 while Figure 32 shows an example. 2814 Client KDC 2815 | | 2816 |-------------- Public Key Update Request: ---------------------->| 2817 | POST ace-group/GROUPNAME/nodes/NODENAME/pub-key | 2818 | | 2819 |<------- Public Key Update Response: 2.04 (Changed) -------------| 2820 | | 2822 Figure 31: Message Flow of Public Key Update Request-Response 2824 Request: 2826 Header: POST (Code=0.02) 2827 Uri-Host: "kdc.example.com" 2828 Uri-Path: "ace-group" 2829 Uri-Path: "g1" 2830 Uri-Path: "nodes" 2831 Uri-Path: "c101" 2832 Uri-Path: "pub-key" 2833 Content-Format: "application/ace-groupcomm+cbor" 2834 Payload (in CBOR diagnostic notation, with PUB_KEY 2835 and POP_EVIDENCE being CBOR byte strings): 2836 { "client_cred": PUB_KEY, "cnonce": h'9ff7684414affcc8', 2837 "client_cred_verify": POP_EVIDENCE } 2839 Response: 2841 Header: Changed (Code=2.04) 2842 Payload: - 2844 Figure 32: Example of Public Key Update Request-Response 2846 Additionally, after updating its own public key, a group member MAY 2847 send a number of requests including an identifier of the updated 2848 public key, to notify other group members that they have to retrieve 2849 it. How this is done depends on the group communication protocol 2850 used, and therefore is application profile specific (OPT13). 2852 5. Removal of a Group Member 2854 A Client identified by NODENAME may be removed from a group 2855 identified by GROUPNAME where it is a member, due to the following 2856 reasons. 2858 1. The Client explicitly asks to leave the group, as defined in 2859 Section 4.8.3.1. 2861 2. The node has been found compromised or is suspected so. 2863 3. The Client's authorization to be a group member with the current 2864 roles is not valid anymore, i.e., the access token has expired or 2865 has been revoked. If the AS provides token introspection (see 2866 Section 5.9 of [I-D.ietf-ace-oauth-authz]), the KDC can 2867 optionally use it and check whether the Client is still 2868 authorized. 2870 In either case, the KDC performs the following actions. 2872 * The KDC removes the Client from the list of current members or the 2873 group. 2875 * In case of forced eviction, i.e., for cases 2 and 3 above, the KDC 2876 deletes the public key of the removed Client, if it acts as 2877 repository of public keys for group members. 2879 * If the removed Client is registered as an observer of the group- 2880 membership resource at ace-group/GROUPNAME, the KDC removes the 2881 Client from the list of observers of that resource. 2883 * If the sub-resource nodes/NODENAME was created for the removed 2884 Client, the KDC deletes that sub-resource. 2886 In case of forced eviction, i.e., for cases 2 and 3 above, the KDC 2887 MAY explicitly inform the removed Client, by means of the 2888 following methods. 2890 - If the evicted Client implements the 'control_uri' resource 2891 specified in Section 4.3.1, the KDC sends a DELETE request, 2892 targeting the URI specified in the 'control_uri' parameter of 2893 the Joining Request (see Section 4.3.1). 2895 - If the evicted Client is observing its associated sub-resource 2896 at ace-group/GROUPNAME/nodes/NODENAME (see Section 4.8.1), the 2897 KDC sends an unsolicited 4.04 (Not Found) error response, which 2898 does not include the Observe option and indicates that the 2899 observed resource has been deleted (see Section 3.2 of 2900 [RFC7641]). 2902 The response MUST have Content-Format set to application/ace- 2903 groupcomm+cbor and is formatted as defined in Section 4. The 2904 value of the 'error' field MUST be set to 5 ("Group membership 2905 terminated"). 2907 * If the application requires forward security or the used 2908 application profile requires so, the KDC MUST generate new group 2909 keying material and securely distribute it to all the current 2910 group members except the leaving node (see Section 6). 2912 6. Group Rekeying Process 2914 A group rekeying is started and driven by the KDC. The KDC is not 2915 intended to accommodate explicit requests from group members to 2916 trigger a group rekeying. That is, the scheduling and execution of a 2917 group rekeying is an exclusive prerogative of the KDC. Reasons that 2918 can trigger a group rekeying are a change in the group membership, 2919 the current group keying material approaching its expiration time, or 2920 a regularly scheduled update of the group keying material. 2922 The KDC MUST increment the version number NUM of the current keying 2923 material, before distributing the newly generated keying material 2924 with version number NUM+1 to the group. Once completed the group 2925 rekeying, the KDC MUST delete the old keying material and SHOULD 2926 store the newly distributed keying material in persistent storage. 2928 Distributing the new group keying material requires the KDC to send 2929 multiple rekeying messages to the group members. Depending on the 2930 rekeying scheme used in the group and the reason that has triggered 2931 the rekeying process, each rekeying message can be intended to one or 2932 multiple group members, hereafter referred to as target group 2933 members. The KDC MUST support at least the "Point-to-Point" group 2934 rekeying scheme in Section 6.1 and MAY support additional ones. 2936 Each rekeying message MUST have Content-Format set to application/ 2937 ace-groupcomm+cbor and its payload formatted as a CBOR map, which 2938 MUST include at least the information specified in the Key 2939 Distribution Response message (see Section 4.3.2), i.e., the 2940 parameters 'gkty', 'key' and 'num' defined in Section 4.3.1. The 2941 CBOR map MAY include the parameter 'exp', as well as the parameter 2942 'mgt_key_material' specifying new administrative keying material for 2943 the target group members, if relevant for the used rekeying scheme. 2945 A rekeying message may include additional information, depending on 2946 the rekeying scheme used in the group, the reason that has triggered 2947 the rekeying process and the specific target group members. In 2948 particular, if the group rekeying is performed due to one or multiple 2949 Clients that have joined the group and the KDC acts as repository of 2950 public keys of the group members, then a rekeying message MAY also 2951 include the public keys that those Clients use in the group, together 2952 with the roles and node identifier that the corresponding Client has 2953 in the group. It is RECOMMENDED to specify this information by means 2954 of the parameters 'pub_keys', 'peer_roles' and 'peer_identifiers', 2955 like done in the Joining Response message (see Section 4.3.1). 2957 The complete format of a rekeying message, including the encoding and 2958 content of the 'mgt_key_material' parameter, has to be defined in 2959 separate specifications aimed at profiling the used rekeying scheme 2960 in the context of the used application profile of this specification. 2961 As a particular case, an application profile of this specification 2962 MAY define additional information to include in rekeying messages for 2963 the "Point-to-Point" group rekeying scheme in Section 6.1 (OPT14). 2965 Consistently with the used group rekeying scheme, the actual delivery 2966 of rekeying messages can occur through different approaches, as 2967 discussed in the following. 2969 6.1. Point-to-Point Group Rekeying 2971 This approach consists in the KDC sending one individual rekeying 2972 message to each target group member. In particular, the rekeying 2973 message is protected by means of the security association between the 2974 KDC and the target group member in question, as per the used 2975 application profile of this specification and the used transport 2976 profile of ACE. 2978 This is the approach taken by the basic "Point-to-Point" group 2979 rekeying scheme, that the KDC can explicitly signal in the Joining 2980 Response (see Section 4.3.1), through the 'rekeying_scheme' parameter 2981 specifying the value 0. 2983 When taking this approach in the group identified by GROUPNAME, the 2984 KDC can practically deliver the rekeying messages to the target group 2985 members in different, co-existing ways. 2987 * The KDC SHOULD make the ace-group/GROUPNAME resource Observable 2988 [RFC7641]. Thus, upon performing a group rekeying, the KDC can 2989 distribute the new group keying material through individual 2990 notification responses sent to the target group members that are 2991 also observing that resource. 2993 In case the KDC deletes the group, this also allows the KDC to 2994 send an unsolicited 4.04 (Not Found) response to each observer 2995 group member, as a notification of group termination. The 2996 response MUST have Content-Format set to application/ace- 2997 groupcomm+cbor and is formatted as defined in Section 4. The 2998 value of the 'error' field MUST be set to 6 ("Group deleted"). 3000 * If a target group member specified a URI in the 'control_uri' 3001 parameter of the Joining Request upon joining the group (see 3002 Section 4.3.1), the KDC can provide that group member with the new 3003 group keying material by sending a unicast POST request to that 3004 URI. 3006 A Client that does not plan to observe the ace-group/GROUPNAME 3007 resource at the KDC SHOULD provide a URI in the 'control_uri' 3008 parameter of the Joining Request upon joining the group. 3010 If the KDC has to send a rekeying message to a target group member, 3011 but this did not include the 'control_uri' parameter in the Joining 3012 Request and is not a registered observer for the ace-group/GROUPNAME 3013 resource, then that target group member would not be able to 3014 participate to the group rekeying. Later on, after having repeatedly 3015 failed to successfully exchange secure messages in the group, that 3016 group member can retrieve the current group keying material from the 3017 KDC, by sending a GET request to ace-group/GROUPNAME or ace- 3018 group/GROUPNAME/nodes/NODENAME (see Section 4.3.2 and Section 4.8.1, 3019 respectively). 3021 6.2. One-to-Many Group Rekeying 3023 This section provides high-level recommendations on how the KDC can 3024 rekey a group by means of a more efficient and scalable group 3025 rekeying scheme, e.g., [RFC2093][RFC2094][RFC2627]. That is, each 3026 rekeying message might be, and likely is, intended to multiple target 3027 group members, and thus can be delivered to the whole group, although 3028 possible to decrypt only for the actual target group members. 3030 This yields an overall lower number of rekeying messages, thus 3031 potentially reducing the overall time required to rekey the group. 3032 On the other hand, it requires the KDC to provide and use additional 3033 administrative keying material to protect the rekeying messages, and 3034 to additionally sign them to ensure source authentication (see 3035 Section 6.2.1). Typically, this pays off in large-scale groups, 3036 where the introduced performance overhead is less than what 3037 experienced by rekeying the group in a point-to-point fashion (see 3038 Section 6.1). 3040 The exact set of rekeying messages to send, their content and format, 3041 the administrative keying material to use to protect them, as well as 3042 the set of target group members depend on the specific group rekeying 3043 scheme, and are typically affected by the reason that has triggered 3044 the group rekeying. Details about the data content and format of 3045 rekeying messages have to be defined by separate documents profiling 3046 the use of the group rekeying scheme, in the context of the used 3047 application profile of this specification. 3049 When one of these group rekeying schemes is used, the KDC provides a 3050 number of related information to a Client joining the group in the 3051 Joining Response message (see Section 4.3.1). In particular, 3052 'rekeying_scheme' identifies the rekeying scheme used in the group 3053 (if no default can be assumed); 'control_group_uri', if present, 3054 specifies a URI with a multicast address where the KDC will send the 3055 rekeying messages for that group; 'mgt_key_material' specifies a 3056 subset of the administrative keying material intended for that 3057 particular joining Client to have, as used to protect the rekeying 3058 messages sent to the group when intended also to that joining Client. 3060 Rekeying messages can be protected at the application layer, by using 3061 COSE and the administrative keying material as prescribed by the 3062 specific group rekeying scheme (see Section 6.2.1). After that, the 3063 delivery of protected rekeying messages to the intended target group 3064 members can occur in different ways, such as the following ones. 3066 * Over multicast - In this case, the KDC simply sends a rekeying 3067 message as a CoAP request addressed to the multicast URI specified 3068 in the 'control_group_uri' parameter of the Joining Response (see 3069 Section 4.3.1). 3071 If a particular rekeying message is intended to a single target 3072 group member, the KDC may alternatively protect the message using 3073 the security association with that group member, and deliver the 3074 message like when using the "Point-to-Point" group rekeying scheme 3075 (see Section 6.1). 3077 * Through a pub-sub communication model - In this case, the KDC acts 3078 as publisher and publishes each rekeying message to a specific 3079 "rekeying topic", which is associated to the group and is hosted 3080 at a broker server. Following their group joining, the group 3081 members subscribe to the rekeying topic at the broker, thus 3082 receiving the group rekeying messages as they are published by the 3083 KDC. 3085 In order to make such message delivery more efficient, the 3086 rekeying topic associated to a group can be further organized into 3087 subtopics. For instance, the KDC can use a particular subtopic to 3088 address a particular set of target group members during the 3089 rekeying process, as possibly aligned to a similar organization of 3090 the administrative keying material (e.g., a key hierarchy). 3092 The setup of rekeying topics at the broker as well as the 3093 discovery of the topics at the broker for group members are 3094 application specific. A possible way is for the KDC to provide 3095 such information in the Joining Response message (see 3096 Section 4.3.1), by means of a new parameter analogous to 3097 'control_group_uri' and specifying the URI(s) of the rekeying 3098 topic(s) that a group member has to subscribe to at the broker. 3100 Regardless the specifically used delivery method, the group rekeying 3101 scheme can perform a possible roll-over of the administrative keying 3102 material through the same sent rekeying messages. Actually, such a 3103 roll-over occurs every time a group rekeying is performed upon the 3104 leaving of group members, which have to be excluded from future 3105 communications in the group. 3107 From a high level point of view, each group member owns only a subset 3108 of the overall administrative keying material, obtained upon joining 3109 the group. Then, when a group rekeying occurs: 3111 * Each rekeying message is protected by using a (most convenient) 3112 key from the administrative keying material such that: i) the used 3113 key is not owned by any node leaving the group, i.e. the key is 3114 safe to use and does not have to be renewed; and ii) the used key 3115 is owned by all the target group members, that indeed have to be 3116 provided with new group keying material to protect communications 3117 in the group. 3119 * Each rekeying message includes not only the new group keying 3120 material intended to all the rekeyed group members, but also any 3121 new administrative keys that: i) are pertaining to and supposed to 3122 be owned by the target group members; and ii) had to be updated 3123 since leaving group members own the previous version. 3125 Further details depend on the specific rekeying scheme used in the 3126 group. 3128 6.2.1. Protection of Rekeying Messages 3130 When using a group rekeying scheme relying on one-to-many rekeying 3131 messages, the actual data content of each rekeying message is 3132 prepared according to what the rekeying scheme prescribes. 3134 Then, the KDC can protect the rekeying message as defined below. The 3135 used encryption algorithm which SHOULD be the same one used to 3136 protect communications in the group. The method defined below 3137 assumes that the following holds for the management keying material 3138 specified in the 'mgt_key_material' parameter of the Joining Response 3139 (see Section 4.3.1). 3141 * The included symmetric encryption keys are accompanied by a 3142 corresponding and unique key identifier assigned by the KDC. 3144 * A Base IV is also included, with the same size of the AEAD nonce 3145 considered by the encryption algorithm to use. 3147 First, the KDC computes a COSE_Encrypt0 object as follows. 3149 * The encryption key to use is selected from the administrative 3150 keying material, as defined by the rekeying scheme used in the 3151 group. 3153 * The plaintext is the actual data content of the rekeying message. 3155 * The Additional Authenticated Data (AAD) is empty, unless otherwise 3156 specified by separate documents profiling the use of the group 3157 rekeying scheme. 3159 * Since the KDC is the only sender of rekeying messages, the AEAD 3160 nonce can be computed as follows, where NONCE_SIZE is the size in 3161 bytes of the AEAD nonce. Separate documents profiling the use of 3162 the group rekeying scheme may define alternative ways to compute 3163 the AEAD nonce. 3165 The KDC considers the following values. 3167 - COUNT, as a 1-byte unsigned integer associated to the used 3168 encryption key. Its value is set to 0 when starting to perform 3169 a new group rekeying instance, and is incremented after each 3170 use of the encryption key. 3172 - NEW_NUM, as the version number of the new group keying material 3173 to distribute in this rekeying instance, left-padded with 3174 zeroes to exactly NONCE_SIZE - 1. 3176 Then, the KDC computes a Partial IV as the byte string 3177 concatenation of COUNT and NEW_NUM, in this order. Finally, the 3178 AEAD nonce is computed as the XOR between the Base IV and the 3179 Partial IV. 3181 * The protected header of the COSE_Encrypt0 object MUST include the 3182 following parameters. 3184 - 'alg', specifying the used encryption algorithm. 3186 - 'kid', specifying the identifier of the encryption key from the 3187 administrative keying material used to protect this rekeying 3188 message. 3190 * The unprotected header of the COSE_Encrypt0 object MUST include 3191 the 'Partial IV' parameter, with value the Partial IV computed 3192 above. 3194 In order to ensure source authentication, each rekeying message 3195 protected with the administrative keying material MUST be signed by 3196 the KDC. To this end, the KDC computes a countersignature of the 3197 COSE_Encrypt0 object, as described in Sections 3.2 and 3.3 of 3198 [I-D.ietf-cose-countersign]. In particular, the following applies 3199 when computing the countersignature. 3201 * The Countersign_structure contains the context text string 3202 "CounterSignature0". 3204 * The private key of the KDC is used as signing key. 3206 * The payload is the ciphertext of the COSE_Encrypt0 object. 3208 * The Additional Authenticated Data (AAD) is empty, unless otherwise 3209 specified by separate documents profiling the use of a group 3210 rekeying scheme. 3212 * The protected header of the signing object MUST include the 3213 parameter 'alg', specifying the used signature algorithm. 3215 If source authentication of messages exchanged in the group is also 3216 ensured by means of signatures, then rekeying messages MUST be signed 3217 using the same signature algorithm and related parameters. Also, the 3218 KDC's public key used for signature verification MUST me provided in 3219 the Joining Response through the 'kdc_cred' parameter, together with 3220 the corresponding proof-of-possession (PoP) evidence in the 3221 'kdc_cred_verify' parameter. 3223 If source authentication of messages exchanged in the group is not 3224 ensured by means of signatures, then the KDC MUST provide its public 3225 key together with a corresponding PoP evidence as part of the 3226 management keying material specified in the 'mgt_key_material' 3227 parameter of the Joining Response (see Section 4.3.1). It is 3228 RECOMMENDED to specify this information by using the same format and 3229 encoding used for the parameters 'kdc_cred', 'kdc_nonce' and 3230 'kdc_cred_verify' in the Joining Response. It is up to separate 3231 documents profiling the use of the group rekeying scheme to specify 3232 such details. 3234 After that, the KDC specifies the computed countersignature in the 3235 'COSE_Countersignature0' header parameter of the COSE_Encrypt0 3236 object. 3238 Finally, the KDC specifies the COSE_Encrypt0 object as payload of a 3239 CoAP request, which is sent to the target group members as per the 3240 used message delivery method. 3242 7. Extended Scope Format 3244 This section defines an extended format of binary encoded scope, 3245 which additionally specifies the semantics used to express the same 3246 access control information from the corresponding original scope. 3248 As also discussed in Section 3.2, this enables a Resource Server to 3249 unambiguously process a received access token, also in case the 3250 Resource Server runs multiple applications or application profiles 3251 that involve different scope semantics. 3253 The extended format is intended only for the 'scope' claim of access 3254 tokens, for the cases where the claim takes as value a CBOR byte 3255 string. That is, the extended format does not apply to the 'scope' 3256 parameter included in ACE messages, i.e., the Authorization Request 3257 and Authorization Response exchanged between the Client and the 3258 Authorization Server (see Sections 5.8.1 and 5.8.2 of 3259 [I-D.ietf-ace-oauth-authz]), the AS Request Creation Hints message 3260 from the Resource Server (see Section 5.3 of 3261 [I-D.ietf-ace-oauth-authz]), and the Introspection Response from the 3262 Authorization Server (see Section 5.9.2 of 3263 [I-D.ietf-ace-oauth-authz]). 3265 The value of the 'scope' claim following the extended format is 3266 composed as follows. Given the original scope using a semantics SEM 3267 and encoded as a CBOR byte string, the corresponding extended scope 3268 is encoded as a tagged CBOR byte string, wrapping a CBOR sequence 3269 [RFC8742] of two elements. In particular: 3271 * The first element of the sequence is a CBOR integer, and 3272 identifies the semantics SEM used for this scope. The value of 3273 this element has to be taken from the "Value" column of the "ACE 3274 Scope Semantics" registry defined in Section 11.12 of this 3275 specification. 3277 When defining a new semantics for a binary scope, it is up to the 3278 applications and application profiles to define and register the 3279 corresponding integer identifier (REQ28). 3281 * The second element of the sequence is the original scope using the 3282 semantics SEM, encoded as a CBOR byte string. 3284 Finally, the CBOR byte string wrapping the CBOR sequence is tagged, 3285 and identified by the CBOR tag TBD_TAG "ACE Extended Scope Format", 3286 defined in Section 11.6 of this specification. 3288 The resulting tagged CBOR byte string is used as value of the 'scope' 3289 claim of the access token. 3291 The usage of the extended scope format is not limited to application 3292 profiles of this specification or to applications based on group 3293 communication. Rather, it is generally applicable to any application 3294 and application profile where access control information in the 3295 access token is expressed as a binary encoded scope. 3297 Figure 33 and Figure 34 build on the examples in Section 3.2, and 3298 show the corresponding extended scopes. 3300 gname = tstr 3302 permissions = uint . bits roles 3304 roles = &( 3305 Requester: 1, 3306 Responder: 2, 3307 Monitor: 3, 3308 Verifier: 4 3309 ) 3311 scope_entry = AIF_Generic 3313 scope = << [ + scope_entry ] >> 3315 semantics = int 3317 ; This defines an array, the elements 3318 ; of which are to be used in a CBOR Sequence: 3319 sequence = [semantics, scope] 3321 extended_scope = #6.TBD_TAG(<< sequence >>) 3323 Figure 33: Example CDLL definition of scope, using the default 3324 Authorization Information Format 3326 gname = tstr 3328 role = tstr 3330 scope_entry = [ gname , ? ( role / [ 2*role ] ) ] 3332 scope = << [ + scope_entry ] >> 3334 semantics = int 3336 ; This defines an array, the elements 3337 ; of which are to be used in a CBOR Sequence: 3338 sequence = [semantics, scope] 3340 extended_scope = #6.TBD_TAG(<< sequence >>) 3342 Figure 34: CDLL definition of scope, using as example group name 3343 encoded as tstr and role as tstr 3345 8. ACE Groupcomm Parameters 3347 This specification defines a number of parameters used during the 3348 second part of the message exchange, after the exchange of Token 3349 Transfer Request and Response. The table below summarizes them, and 3350 specifies the CBOR key to use instead of the full descriptive name. 3352 Note that the media type application/ace-groupcomm+cbor MUST be used 3353 when these parameters are transported in the respective message 3354 fields. 3356 +-----------------------+------+-----------------+-----------------+ 3357 | Name | CBOR | CBOR Type | Reference | 3358 | | Key | | | 3359 +-----------------------+------+-----------------+-----------------+ 3360 | error | TBD | int | [this document] | 3361 +-----------------------+------+-----------------+-----------------+ 3362 | error_description | TBD | tstr | [this document] | 3363 +-----------------------+------+-----------------+-----------------+ 3364 | gid | TBD | array | [this document] | 3365 +-----------------------+------+-----------------+-----------------+ 3366 | gname | TBD | array of tstr | [this document] | 3367 +-----------------------+------+-----------------+-----------------+ 3368 | guri | TBD | array of tstr | [this document] | 3369 +-----------------------+------+-----------------+-----------------+ 3370 | scope | TBD | bstr | [this document] | 3371 +-----------------------+------+-----------------+-----------------+ 3372 | get_pub_keys | TBD | array / nil | [this document] | 3373 +-----------------------+------+-----------------+-----------------+ 3374 | client_cred | TBD | bstr | [this document] | 3375 +-----------------------+------+-----------------+-----------------+ 3376 | cnonce | TBD | bstr | [this document] | 3377 +-----------------------+------+-----------------+-----------------+ 3378 | client_cred_verify | TBD | bstr | [this document] | 3379 +-----------------------+------+-----------------+-----------------+ 3380 | pub_keys_repos | TBD | tstr | [this document] | 3381 +-----------------------+------+-----------------+-----------------+ 3382 | control_uri | TBD | tstr | [this document] | 3383 +-----------------------+------+-----------------+-----------------+ 3384 | gkty | TBD | int / tstr | [this document] | 3385 +-----------------------+------+-----------------+-----------------+ 3386 | key | TBD | See the "ACE | [this document] | 3387 | | | Groupcomm Key | | 3388 | | | Types" registry | | 3389 +-----------------------+------+-----------------+-----------------+ 3390 | num | TBD | int | [this document] | 3391 +-----------------------+------+-----------------+-----------------+ 3392 | ace-groupcomm-profile | TBD | int | [this document] | 3393 +-----------------------+------+-----------------+-----------------+ 3394 | exp | TBD | int | [this document] | 3395 +-----------------------+------+-----------------+-----------------+ 3396 | pub_keys | TBD | array | [this document] | 3397 +-----------------------+------+-----------------+-----------------+ 3398 | peer_roles | TBD | array | [this document] | 3399 +-----------------------+------+-----------------+-----------------+ 3400 | peer_identifiers | TBD | array | [this document] | 3401 +-----------------------+------+-----------------+-----------------+ 3402 | group_policies | TBD | map | [this document] | 3403 +-----------------------+------+-----------------+-----------------+ 3404 | kdc_cred | TBD | bstr | [this document] | 3405 +-----------------------+------+-----------------+-----------------+ 3406 | kdc_nonce | TBD | bstr | [this document] | 3407 +-----------------------+------+-----------------+-----------------+ 3408 | kdc_cred_verify | TBD | bstr | [this document] | 3409 +-----------------------+------+-----------------+-----------------+ 3410 | rekeying_scheme | TBD | int | [this document] | 3411 +-----------------------+------+-----------------+-----------------+ 3412 | mgt_key_material | TBD | bstr | [this document] | 3413 +-----------------------+------+-----------------+-----------------+ 3414 | control_group_uri | TBD | tstr | [this document] | 3415 +-----------------------+------+-----------------+-----------------+ 3416 | sign_info | TBD | array | [this document] | 3417 +-----------------------+------+-----------------+-----------------+ 3418 | kdcchallenge | TBD | bstr | [this document] | 3419 +-----------------------+------+-----------------+-----------------+ 3421 Figure 35: ACE Groupcomm Parameters 3423 The KDC is expected to support and understand all the parameters 3424 above. Instead, a Client can support and understand only a subset of 3425 such parameters, depending on the roles it expects to take in the 3426 joined groups or on other conditions defined in application profiles 3427 of this specification. 3429 In the following, the parameters are categorized according to the 3430 support expected by Clients. That is, a Client that supports a 3431 parameter is able to: i) use and specify it in a request message to 3432 the KDC; and ii) understand and process it if specified in a response 3433 message from the KDC. It is REQUIRED of application profiles of this 3434 specification to sort their newly defined parameters according to the 3435 same categorization (REQ29). 3437 Note that the actual use of a parameter and its inclusion in a 3438 message depends on the specific exchange, the specific Client and 3439 group involved, as well as what is defined in the used application 3440 profile of this specification. 3442 A Client MUST support the following parameters. 3444 * 'scope', 'gkty', 'key', 'num', 'exp', 'gid', 'gname', 'guri', 3445 'pub_keys', 'peer_identifiers', 'ace_groupcomm_profile', 3446 'control_uri', 'rekeying_scheme'. 3448 A Client SHOULD support the following parameter. 3450 * 'get_pub_keys'. That is, not supporting this parameter would 3451 yield the inconvenient and undesirable behavior where: i) the 3452 Client does not ask for the other group members' public keys upon 3453 joining the group (see Section 4.3.1.1); and ii) later on as a 3454 group member, the Client only retrieves the public keys of all 3455 group members (see Section 4.4.2.1). 3457 A Client MAY support the following optional parameters. Application 3458 profiles of this specification MAY define that Clients must or should 3459 support these parameters instead (OPT15). 3461 * 'error', 'error_description'. 3463 The following conditional parameters are relevant only if specific 3464 conditions hold. It is REQUIRED of application profiles of this 3465 specification to define whether Clients must, should or may support 3466 these parameters, and under which circumstances (REQ30). 3468 * 'client_cred', 'cnonce', 'client_cred_verify'. These parameters 3469 are relevant for a Client that has a public key to use in a joined 3470 group. 3472 * 'kdcchallenge'. This parameter is relevant for a Client that has 3473 a public key to use in a joined group and that provides the access 3474 token to the KDC through a Token Transfer Request (see 3475 Section 3.3). 3477 * 'pub_keys'repo'. This parameter is relevant for a Client that has 3478 a public key to use in a joined group and that makes it available 3479 from a key repository different than the KDC. 3481 * 'group_policies'. This parameter is relevant for a Client that is 3482 interested in the specific policies used in a group, but it does 3483 not know them or cannot become aware of them before joining that 3484 group. 3486 * 'peer_roles'. This parameter is relevant for a Client that has to 3487 know about the roles of other group members, especially when 3488 retrieving and handling their corresponding public keys. 3490 * 'kdc_nonce', 'kdc_cred', 'kdc_cred_verify'. These parameters are 3491 relevant for a Client that joins a group for which, as per the 3492 used application profile of this specification, the KDC has an 3493 associated public key and this is required for the correct group 3494 operation. 3496 * 'mgt_key_material'. This parameter is relevant for a Client that 3497 supports an advanced rekeying scheme possibly used in the group, 3498 such as based on one-to-many rekeying messages sent over IP 3499 multicast. 3501 * 'control_group_uri'. This parameter is relevant for a Client that 3502 supports the hosting of local resources each associated to a group 3503 (hence acting as CoAP server) and the reception of one-to-many 3504 requests sent to those resources by the KDC (e.g., over IP 3505 multicast), targeting multiple members of the corresponding group. 3506 Examples of related management operations that the KDC can perform 3507 by this means are the eviction of group members and the execution 3508 of a group rekeying process through an advanced rekeying scheme, 3509 such as based on one-to-many rekeying messages. 3511 9. ACE Groupcomm Error Identifiers 3513 This specification defines a number of values that the KDC can 3514 include as error identifiers, in the 'error' field of an error 3515 response with Content-Format application/ace-groupcomm+cbor. 3517 +-------+------------------------------------------------------+ 3518 | Value | Description | 3519 +-------+------------------------------------------------------+ 3520 | 0 | Operation permitted only to group members | 3521 +-------+------------------------------------------------------+ 3522 | 1 | Request inconsistent with the current roles | 3523 +-------+------------------------------------------------------+ 3524 | 2 | Public key incompatible with the group configuration | 3525 +-------+------------------------------------------------------+ 3526 | 3 | Invalid proof-of-possession evidence | 3527 +-------+------------------------------------------------------+ 3528 | 4 | No available node identifiers | 3529 +-------+------------------------------------------------------+ 3530 | 5 | Group membership terminated | 3531 +-------+------------------------------------------------------+ 3532 | 6 | Group deleted | 3533 +-------+------------------------------------------------------+ 3535 Figure 36: ACE Groupcomm Error Identifiers 3537 A Client supporting the 'error' parameter (see Section 4.1.2 and 3538 Section 8) and able to understand the specified error may use that 3539 information to determine what actions to take next. If it is 3540 included in the error response and supported by the Client, the 3541 'error_description' parameter may provide additional context. 3543 In particular, the following guidelines apply, and application 3544 profiles of this specification can define more detailed actions for 3545 the Client to take when learning that a specific error has occurred. 3547 * In case of error 0, the Client should stop sending the request in 3548 question to the KDC. Rather, the Client should first join the 3549 targeted group. If it has not happened already, this first 3550 requires the Client to obtain an appropriate access token 3551 authorizing access to the group and provide it to the KDC. 3553 * In case of error 1, the Client as a group member should re-join 3554 the group with all the roles needed to perform the operation in 3555 question. This might require the Client to first obtain a new 3556 access token and provide it to the KDC, if the current access 3557 token does not authorize to take those roles in the group. For 3558 operations admitted to a Client which is not a group member (e.g., 3559 an external signature verifier), the Client should first obtain a 3560 new access token authorizing to also have the missing roles. 3562 * In case of error 2, the Client has to obtain or self-generate a 3563 different asymmetric key pair, as aligned to the publick key 3564 algorithms, parameters and encoding used in the targeted group. 3565 After that, the Client should provide its new consistent public 3566 key to the KDC. 3568 * In case of error 3, the Client should ensure to be computing its 3569 proof-of-possession evidence by correctly using the parameters and 3570 procedures defined in the used application profile of this 3571 specification. In an unattended setup, it might be not possible 3572 for a Client to autonomously diagnose the error and take an 3573 effective next action to address it. 3575 * In case of error 4, the Client should wait for a certain (pre- 3576 configured) amount of time, before trying re-sending its request 3577 to the KDC. 3579 * In case of error 5, the Client may try joining the group again. 3580 This might require the Client to first obtain a new access token 3581 and provide it to the KDC, e.g., if the current access token has 3582 expired. 3584 * In case of error 6, the Client should clean up its state regarding 3585 the group, just like if it has left the group with no intention to 3586 re-join it. 3588 10. Security Considerations 3590 Security considerations are inherited from the ACE framework 3591 [I-D.ietf-ace-oauth-authz], and from the specific transport profile 3592 of ACE used between the Clients and the KDC, e.g., 3593 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile]. 3595 Furthermore, the following security considerations apply. 3597 10.1. Secure Communication in the Group 3599 When a group member receives a message from a certain sender for the 3600 first time since joining the group, it needs to have a mechanism in 3601 place to avoid replayed messages, e.g., Appendix B.2 of [RFC8613] or 3602 Appendix E of [I-D.ietf-core-oscore-groupcomm]. Such a mechanism 3603 aids the recipient group member also in case it has rebooted and lost 3604 the security state used to protect previous group communications with 3605 that sender. 3607 By its nature, the KDC is invested with a large amount of trust, 3608 since it acts as generator and provider of the symmetric keying 3609 material used to protect communications in each of its groups. While 3610 details depend on the specific communication and security protocols 3611 used in the group, the KDC is in the position to decrypt messages 3612 exchanged in the group as if it was also a group member, as long as 3613 those are protected through commonly shared group keying material. 3615 A compromised KDC would thus put the attacker in the same position, 3616 which also means that: 3618 * The attacker can generate and control new group keying material, 3619 hence possibly rekeying the group and evicting certain group 3620 members as part of a broader attack. 3622 * The attacker can actively participate to communications in a group 3623 even without been authorized to join it, and can allow further 3624 unauthorized entities to do so. 3626 * The attacker can build erroneous associations between node 3627 identifiers and group members' public keys. 3629 On the other hand, as long as the security protocol used in the group 3630 ensures source authentication of messages (e.g., by means of 3631 signatures), the KDC is not able to impersonate group members since 3632 it does now own their private keys. 3634 Further security considerations are specific of the communication and 3635 security protocols used in the group, and thus have to be provided by 3636 those protocols and complemented by the application profiles of this 3637 specification using them. 3639 10.2. Update of Group Keying Material 3641 Due to different reasons, the KDC can generate new group keying 3642 material and provide it to the group members (rekeying) through the 3643 rekeying scheme used in the group, as discussed in Section 6. 3645 In particular, the KDC must renew the group keying material latest 3646 upon its expiration. Before then, the KDC may also renew the group 3647 keying material on a regular or periodical fashion. 3649 The KDC should renew the group keying material upon a group 3650 membership change. Since the minimum number of group members is one, 3651 the KDC should provide also a Client joining an empty group with new 3652 keying material never used before in that group. Similarly, the KDC 3653 should provide new group keying material also to a Client that 3654 remains the only member in the group after the leaving of other group 3655 members. 3657 Note that the considerations in Section 10.1 about dealing with 3658 replayed messages still hold, even in case the KDC rekeys the group 3659 upon every single joining of a new group member. However, if the KDC 3660 has renewed the group keying material upon a group member's joining, 3661 and the time interval between the end of the rekeying process and 3662 that member's joining is sufficiently small, then that group member 3663 is also on the safe side, since it would not accept replayed messages 3664 protected with the old group keying material previous to its joining. 3666 The KDC may enforce a rekeying policy that takes into account the 3667 overall time required to rekey the group, as well as the expected 3668 rate of changes in the group membership. That is, the KDC may not 3669 rekey the group at each and every group membership change, for 3670 instance if members' joining and leaving occur frequently and 3671 performing a group rekeying takes too long. Instead, the KDC might 3672 rekey the group after a minimum number of group members have joined 3673 or left within a given time interval, or after a maximum amount of 3674 time since the last group rekeying was completed, or yet during 3675 predictable network inactivity periods. 3677 However, this would result in the KDC not constantly preserving 3678 backward and forward security in the group. That is: 3680 * Newly joining group members would be able to access the keying 3681 material used before their joining, and thus they could access 3682 past group communications if they have recorded old exchanged 3683 messages. This might still be acceptable for some applications 3684 and in situations where the new group members are freshly deployed 3685 through strictly controlled procedures. 3687 * The leaving group members would remain able to access upcoming 3688 group communications, as protected with the current keying 3689 material that has not been updated. This is typically 3690 undesirable, especially if the leaving group member is compromised 3691 or suspected to be, and it might have an impact or compromise the 3692 security properties of the protocols used in the group to protect 3693 messages exchanged among the group member. 3695 The KDC should renew the group keying material in case it has 3696 rebooted, even in case it stores the whole group keying material in 3697 persistent storage. This assumes that the secure associations with 3698 the current group members as well as any administrative keying 3699 material required to rekey the group are also stored in persistent 3700 storage. 3702 However, if the KDC relies on Observe notifications to distribute the 3703 new group keying material, the KDC would have lost all the current 3704 ongoing Observations with the group members after rebooting, and the 3705 group members would continue using the old group keying material. 3706 Therefore, the KDC will rather rely on each group member asking for 3707 the new group keying material (see Section 4.3.2.1 and 3708 Section 4.8.1.1), or rather perform a group rekeying by actively 3709 sending rekeying messages to group members as discussed in Section 6. 3711 The KDC needs to have a mechanism in place to detect DoS attacks from 3712 nodes repeatedly performing actions that might trigger a group 3713 rekeying. Such actions can include leaving and/or re-joining the 3714 group at high rates, or often asking the KDC for new indidivual 3715 keying material. Ultimately, the KDC can resort to removing these 3716 nodes from the group and (temperorarily) preventing them from joining 3717 the group again. 3719 The KDC also needs to have a congestion control mechanism in place, 3720 in order to avoid network congestion upon distributing new group 3721 keying material. For example, CoAP and Observe give guidance on such 3722 mechanisms, see Section 4.7 of [RFC7252] and Section 4.5.1 of 3723 [RFC7641]. 3725 A node that has left the group should not expect any of its outgoing 3726 messages to be successfully processed, if received by other nodes 3727 after its leaving, due to a possible group rekeying occurred before 3728 the message reception. 3730 10.2.1. Misalignment of Group Keying Material 3732 A group member can receive a message shortly after the group has been 3733 rekeyed, and new keying material has been distributed by the KDC (see 3734 Section 6). In the following two cases, this may result in 3735 misaligned keying material between the group members. 3737 In the first case, the sender protects a message using the old group 3738 keying material. However, the recipient receives the message after 3739 having received the new group keying material, hence not being able 3740 to correctly process it. A possible way to ameliorate this issue is 3741 to preserve the old, recent group keying material for a maximum 3742 amount of time defined by the application, during which it is used 3743 solely for processing incoming messages. By doing so, the recipient 3744 can still temporarily process received messages also by using the 3745 old, retained group keying material. Note that a former 3746 (compromised) group member can take advantage of this by sending 3747 messages protected with the old, retained group keying material. 3748 Therefore, a conservative application policy should not admit the 3749 storage of old group keying material. Eventually, the sender will 3750 have obtained the new group keying material too, and can possibly re- 3751 send the message protected with such keying material. 3753 In the second case, the sender protects a message using the new group 3754 keying material, but the recipient receives that message before 3755 having received the new group keying material. Therefore, the 3756 recipient would not be able to correctly process the message and 3757 hence discards it. If the recipient receives the new group keying 3758 material shortly after that and the application at the sender 3759 endpoint performs retransmissions, the former will still be able to 3760 receive and correctly process the message. In any case, the 3761 recipient should actively ask the KDC for the latest group keying 3762 material according to an application-defined policy, for instance 3763 after a given number of unsuccessfully decrypted incoming messages. 3765 10.3. Block-Wise Considerations 3767 If the Block-Wise CoAP options [RFC7959] are used, and the keying 3768 material is updated in the middle of a Block-Wise transfer, the 3769 sender of the blocks just changes the group keying material to the 3770 updated one and continues the transfer. As long as both sides get 3771 the new group keying material, updating group the keying material in 3772 the middle of a transfer will not cause any issue. Otherwise, the 3773 sender will have to transmit the message again, when receiving an 3774 error message from the recipient. 3776 Compared to a scenario where the transfer does not use Block-Wise, 3777 depending on how fast the group keying material is changed, the group 3778 members might consume a larger amount of the network bandwidth by 3779 repeatedly resending the same blocks, which might be problematic. 3781 11. IANA Considerations 3783 This document has the following actions for IANA. 3785 11.1. Media Type Registrations 3787 This specification registers the 'application/ace-groupcomm+cbor' 3788 media type for messages of the protocols defined in this document 3789 following the ACE exchange and carrying parameters encoded in CBOR. 3790 This registration follows the procedures specified in [RFC6838]. 3792 Type name: application 3794 Subtype name: ace-groupcomm+cbor 3796 Required parameters: N/A 3798 Optional parameters: N/A 3799 Encoding considerations: Must be encoded as CBOR map containing the 3800 protocol parameters defined in [this document]. 3802 Security considerations: See Section 10 of this document. 3804 Interoperability considerations: n/a 3806 Published specification: [this document] 3808 Applications that use this media type: The type is used by 3809 Authorization Servers, Clients and Resource Servers that support the 3810 ACE groupcomm framework as specified in [this document]. 3812 Fragment identifier considerations: N/A 3814 Additional information: N/A 3816 Person & email address to contact for further information: 3817 iesg@ietf.org (mailto:iesg@ietf.org) 3819 Intended usage: COMMON 3821 Restrictions on usage: None 3823 Author: Francesca Palombini francesca.palombini@ericsson.com 3824 (mailto:francesca.palombini@ericsson.com) 3826 Change controller: IESG 3828 11.2. CoAP Content-Formats 3830 IANA is asked to register the following entry to the "CoAP Content- 3831 Formats" registry within the "CoRE Parameters" registry group. 3833 Media Type: application/ace-groupcomm+cbor 3835 Encoding: - 3837 ID: TBD 3839 Reference: [this document] 3841 11.3. OAuth Parameters 3843 IANA is asked to register the following entries in the "OAuth 3844 Parameters" registry following the procedure specified in 3845 Section 11.2 of [RFC6749]. 3847 * Parameter name: sign_info 3849 * Parameter usage location: client-rs request, rs-client response 3851 * Change Controller: IESG 3853 * Specification Document(s): [[This specification]] 3855 * Parameter name: kdcchallenge 3857 * Parameter usage location: rs-client response 3859 * Change Controller: IESG 3861 * Specification Document(s): [[This specification]] 3863 11.4. OAuth Parameters CBOR Mappings 3865 IANA is asked to register the following entries in the "OAuth 3866 Parameters CBOR Mappings" registry following the procedure specified 3867 in Section 8.10 of [I-D.ietf-ace-oauth-authz]. 3869 * Name: sign_info 3871 * CBOR Key: TBD (range -256 to 255) 3873 * Value Type: Simple value null / array 3875 * Reference: [[This specification]] 3877 * Name: kdcchallenge 3879 * CBOR Key: TBD (range -256 to 255) 3881 * Value Type: Byte string 3883 * Reference: [[This specification]] 3885 11.5. Interface Description (if=) Link Target Attribute Values 3887 IANA is asked to register the following entry in the "Interface 3888 Description (if=) Link Target Attribute Values" registry within the 3889 "CoRE Parameters" registry group. 3891 * Attribute Value: ace.group 3892 * Description: The 'ace group' interface is used to provision keying 3893 material and related information and policies to members of a 3894 group using the Ace framework. 3896 * Reference: [This Document] 3898 11.6. CBOR Tags 3900 IANA is asked to register the following entry in the "CBOR Tags" 3901 registry. 3903 * Tag : TBD_TAG 3905 * Data Item: byte string 3907 * Semantics: Extended ACE scope format, including the identifier of 3908 the used scope semantics. 3910 * Reference: [This Document] 3912 11.7. ACE Groupcomm Parameters 3914 This specification establishes the "ACE Groupcomm Parameters" IANA 3915 registry. The registry has been created to use the "Expert Review" 3916 registration procedure [RFC8126]. Expert review guidelines are 3917 provided in Section 11.15. 3919 The columns of this registry are: 3921 * Name: This is a descriptive name that enables easier reference to 3922 the item. The name MUST be unique. It is not used in the 3923 encoding. 3925 * CBOR Key: This is the value used as CBOR key of the item. These 3926 values MUST be unique. The value can be a positive integer, a 3927 negative integer, or a string. 3929 * CBOR Type: This contains the CBOR type of the item, or a pointer 3930 to the registry that defines its type, when that depends on 3931 another item. 3933 * Reference: This contains a pointer to the public specification for 3934 the item. 3936 This registry has been initially populated by the values in 3937 Section 8. The Reference column for all of these entries refers to 3938 sections of this document. 3940 11.8. ACE Groupcomm Key Types 3942 This specification establishes the "ACE Groupcomm Key Types" IANA 3943 registry. The registry has been created to use the "Expert Review" 3944 registration procedure [RFC8126]. Expert review guidelines are 3945 provided in Section 11.15. 3947 The columns of this registry are: 3949 * Name: This is a descriptive name that enables easier reference to 3950 the item. The name MUST be unique. It is not used in the 3951 encoding. 3953 * Key Type Value: This is the value used to identify the keying 3954 material. These values MUST be unique. The value can be a 3955 positive integer, a negative integer, or a text string. 3957 * Profile: This field may contain one or more descriptive strings of 3958 application profiles to be used with this item. The values should 3959 be taken from the Name column of the "ACE Groupcomm Profiles" 3960 registry. 3962 * Description: This field contains a brief description of the keying 3963 material. 3965 * References: This contains a pointer to the public specification 3966 for the format of the keying material, if one exists. 3968 This registry has been initially populated by the values in 3969 Figure 10. The specification column for all of these entries will be 3970 this document. 3972 11.9. ACE Groupcomm Profiles 3974 This specification establishes the "ACE Groupcomm Profiles" IANA 3975 registry. The registry has been created to use the "Expert Review" 3976 registration procedure [RFC8126]. Expert review guidelines are 3977 provided in Section 11.15. It should be noted that, in addition to 3978 the expert review, some portions of the registry require a 3979 specification, potentially a Standards Track RFC, to be supplied as 3980 well. 3982 The columns of this registry are: 3984 * Name: The name of the application profile, to be used as value of 3985 the profile attribute. 3987 * Description: Text giving an overview of the application profile 3988 and the context it is developed for. 3990 * CBOR Value: CBOR abbreviation for the name of this application 3991 profile. Different ranges of values use different registration 3992 policies [RFC8126]. Integer values from -256 to 255 are 3993 designated as Standards Action. Integer values from -65536 to 3994 -257 and from 256 to 65535 are designated as Specification 3995 Required. Integer values greater than 65535 are designated as 3996 Expert Review. Integer values less than -65536 are marked as 3997 Private Use. 3999 * Reference: This contains a pointer to the public specification of 4000 the abbreviation for this application profile, if one exists. 4002 11.10. ACE Groupcomm Policies 4004 This specification establishes the "ACE Groupcomm Policies" IANA 4005 registry. The registry has been created to use the "Expert Review" 4006 registration procedure [RFC8126]. Expert review guidelines are 4007 provided in Section 11.15. It should be noted that, in addition to 4008 the expert review, some portions of the registry require a 4009 specification, potentially a Standards Track RFC, to be supplied as 4010 well. 4012 The columns of this registry are: 4014 * Name: The name of the group communication policy. 4016 * CBOR label: The value to be used to identify this group 4017 communication policy. Key map labels MUST be unique. The label 4018 can be a positive integer, a negative integer or a string. 4019 Integer values between 0 and 255 and strings of length 1 are 4020 designated as Standards Track Document required. Integer values 4021 from 256 to 65535 and strings of length 2 are designated as 4022 Specification Required. Integer values greater than 65535 and 4023 strings of length greater than 2 are designated as expert review. 4024 Integer values less than -65536 are marked as private use. 4026 * CBOR type: the CBOR type used to encode the value of this group 4027 communication policy. 4029 * Description: This field contains a brief description for this 4030 group communication policy. 4032 * Reference: This field contains a pointer to the public 4033 specification providing the format of the group communication 4034 policy, if one exists. 4036 This registry will be initially populated by the values in Figure 11. 4038 11.11. Sequence Number Synchronization Methods 4040 This specification establishes the "Sequence Number Synchronization 4041 Methods" IANA registry. The registry has been created to use the 4042 "Expert Review" registration procedure [RFC8126]. Expert review 4043 guidelines are provided in Section 11.15. It should be noted that, 4044 in addition to the expert review, some portions of the registry 4045 require a specification, potentially a Standards Track RFC, to be 4046 supplied as well. 4048 The columns of this registry are: 4050 * Name: The name of the sequence number synchronization method. 4052 * Value: The value to be used to identify this sequence number 4053 synchronization method. 4055 * Description: This field contains a brief description for this 4056 sequence number synchronization method. 4058 * Reference: This field contains a pointer to the public 4059 specification describing the sequence number synchronization 4060 method. 4062 11.12. ACE Scope Semantics 4064 This specification establishes the "ACE Scope Semantics" IANA 4065 registry. The registry has been created to use the "Expert Review" 4066 registration procedure [RFC8126]. Expert review guidelines are 4067 provided in Section 11.15. It should be noted that, in addition to 4068 the expert review, some portions of the registry require a 4069 specification, potentially a Standards Track RFC, to be supplied as 4070 well. 4072 The columns of this registry are: 4074 * Value: The value to be used to identify this scope semantics. The 4075 value MUST be unique. The value can be a positive integer or a 4076 negative integer. Integer values between 0 and 255 are designated 4077 as Standards Track Document required. Integer values from 256 to 4078 65535 are designated as Specification Required. Integer values 4079 greater than 65535 are designated as expert review. Integer 4080 values less than -65536 are marked as private use. 4082 * Description: This field contains a brief description of the scope 4083 semantics. 4085 * Reference: This field contains a pointer to the public 4086 specification defining the scope semantics, if one exists. 4088 11.13. ACE Groupcomm Errors 4090 This specification establishes the "ACE Groupcomm Errors" IANA 4091 registry. The registry has been created to use the "Expert Review" 4092 registration procedure [RFC8126]. Expert review guidelines are 4093 provided in Section 11.15. It should be noted that, in addition to 4094 the expert review, some portions of the registry require a 4095 specification, potentially a Standards Track RFC, to be supplied as 4096 well. 4098 The columns of this registry are: 4100 * Value: The value to be used to identify the error. The value MUST 4101 be unique. The value can be a positive integer or a negative 4102 integer. Integer values between 0 and 255 are designated as 4103 Standards Track Document required. Integer values from 256 to 4104 65535 are designated as Specification Required. Integer values 4105 greater than 65535 are designated as expert review. Integer 4106 values less than -65536 are marked as private use. 4108 * Description: This field contains a brief description of the error. 4110 * Reference: This field contains a pointer to the public 4111 specification defining the error, if one exists. 4113 This registry has been initially populated by the values in 4114 Section 9. The Reference column for all of these entries refers to 4115 this document. 4117 11.14. ACE Groupcomm Rekeying Schemes 4119 This specification establishes the "ACE Groupcomm Rekeying Schemes" 4120 IANA registry. The registry has been created to use the "Expert 4121 Review" registration procedure [RFC8126]. Expert review guidelines 4122 are provided in Section 11.15. It should be noted that, in addition 4123 to the expert review, some portions of the registry require a 4124 specification, potentially a Standards Track RFC, to be supplied as 4125 well. 4127 The columns of this registry are: 4129 * Value: The value to be used to identify the group rekeying scheme. 4130 The value MUST be unique. The value can be a positive integer or 4131 a negative integer. Integer values between 0 and 255 are 4132 designated as Standards Track Document required. Integer values 4133 from 256 to 65535 are designated as Specification Required. 4134 Integer values greater than 65535 are designated as expert review. 4135 Integer values less than -65536 are marked as private use. 4137 * Name: The name of the group rekeying scheme. 4139 * Description: This field contains a brief description of the group 4140 rekeying scheme. 4142 * Reference: This field contains a pointer to the public 4143 specification defining the group rekeying scheme, if one exists. 4145 This registry has been initially populated by the value in Figure 12. 4147 11.15. Expert Review Instructions 4149 The IANA Registries established in this document are defined as 4150 expert review. This section gives some general guidelines for what 4151 the experts should be looking for, but they are being designated as 4152 experts for a reason so they should be given substantial latitude. 4154 Expert reviewers should take into consideration the following points: 4156 * Point squatting should be discouraged. Reviewers are encouraged 4157 to get sufficient information for registration requests to ensure 4158 that the usage is not going to duplicate one that is already 4159 registered and that the point is likely to be used in deployments. 4160 The zones tagged as private use are intended for testing purposes 4161 and closed environments, code points in other ranges should not be 4162 assigned for testing. 4164 * Specifications are required for the standards track range of point 4165 assignment. Specifications should exist for specification 4166 required ranges, but early assignment before a specification is 4167 available is considered to be permissible. Specifications are 4168 needed for the first-come, first-serve range if they are expected 4169 to be used outside of closed environments in an interoperable way. 4170 When specifications are not provided, the description provided 4171 needs to have sufficient information to identify what the point is 4172 being used for. 4174 * Experts should take into account the expected usage of fields when 4175 approving point assignment. The fact that there is a range for 4176 standards track documents does not mean that a standards track 4177 document cannot have points assigned outside of that range. The 4178 length of the encoded value should be weighed against how many 4179 code points of that length are left, the size of device it will be 4180 used on, and the number of code points left that encode to that 4181 size. 4183 12. References 4185 12.1. Normative References 4187 [COSE.Algorithms] 4188 IANA, "COSE Algorithms", 4189 . 4192 [COSE.Header.Parameters] 4193 IANA, "COSE Header Parameters", 4194 . 4197 [I-D.ietf-ace-aif] 4198 Bormann, C., "An Authorization Information Format (AIF) 4199 for ACE", Work in Progress, Internet-Draft, draft-ietf- 4200 ace-aif-03, 24 June 2021, 4201 . 4204 [I-D.ietf-ace-oauth-authz] 4205 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 4206 H. Tschofenig, "Authentication and Authorization for 4207 Constrained Environments (ACE) using the OAuth 2.0 4208 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 4209 draft-ietf-ace-oauth-authz-46, 8 November 2021, 4210 . 4213 [I-D.ietf-core-oscore-groupcomm] 4214 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 4215 and J. Park, "Group OSCORE - Secure Group Communication 4216 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 4217 core-oscore-groupcomm-13, 25 October 2021, 4218 . 4221 [I-D.ietf-cose-countersign] 4222 Schaad, J. and R. Housley, "CBOR Object Signing and 4223 Encryption (COSE): Countersignatures", Work in Progress, 4224 Internet-Draft, draft-ietf-cose-countersign-05, 23 June 4225 2021, . 4228 [I-D.ietf-cose-rfc8152bis-algs] 4229 Schaad, J., "CBOR Object Signing and Encryption (COSE): 4230 Initial Algorithms", Work in Progress, Internet-Draft, 4231 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 4232 . 4235 [I-D.ietf-cose-rfc8152bis-struct] 4236 Schaad, J., "CBOR Object Signing and Encryption (COSE): 4237 Structures and Process", Work in Progress, Internet-Draft, 4238 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 4239 . 4242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4243 Requirement Levels", BCP 14, RFC 2119, 4244 DOI 10.17487/RFC2119, March 1997, 4245 . 4247 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 4248 RFC 6749, DOI 10.17487/RFC6749, October 2012, 4249 . 4251 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 4252 Specifications and Registration Procedures", BCP 13, 4253 RFC 6838, DOI 10.17487/RFC6838, January 2013, 4254 . 4256 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 4257 Application Protocol (CoAP)", RFC 7252, 4258 DOI 10.17487/RFC7252, June 2014, 4259 . 4261 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 4262 Bose, "Constrained Application Protocol (CoAP) Option for 4263 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 4264 August 2016, . 4266 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 4267 Writing an IANA Considerations Section in RFCs", BCP 26, 4268 RFC 8126, DOI 10.17487/RFC8126, June 2017, 4269 . 4271 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4272 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4273 May 2017, . 4275 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 4276 Definition Language (CDDL): A Notational Convention to 4277 Express Concise Binary Object Representation (CBOR) and 4278 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 4279 June 2019, . 4281 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 4282 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 4283 . 4285 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 4286 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 4287 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 4288 2020, . 4290 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 4291 Representation (CBOR)", STD 94, RFC 8949, 4292 DOI 10.17487/RFC8949, December 2020, 4293 . 4295 12.2. Informative References 4297 [I-D.ietf-ace-dtls-authorize] 4298 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 4299 L. Seitz, "Datagram Transport Layer Security (DTLS) 4300 Profile for Authentication and Authorization for 4301 Constrained Environments (ACE)", Work in Progress, 4302 Internet-Draft, draft-ietf-ace-dtls-authorize-18, 4 June 4303 2021, . 4306 [I-D.ietf-ace-mqtt-tls-profile] 4307 Sengul, C. and A. Kirby, "Message Queuing Telemetry 4308 Transport (MQTT)-TLS profile of Authentication and 4309 Authorization for Constrained Environments (ACE) 4310 Framework", Work in Progress, Internet-Draft, draft-ietf- 4311 ace-mqtt-tls-profile-13, 23 October 2021, 4312 . 4315 [I-D.ietf-ace-oscore-profile] 4316 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 4317 "OSCORE Profile of the Authentication and Authorization 4318 for Constrained Environments Framework", Work in Progress, 4319 Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May 4320 2021, . 4323 [I-D.ietf-core-coap-pubsub] 4324 Koster, M., Keranen, A., and J. Jimenez, "Publish- 4325 Subscribe Broker for the Constrained Application Protocol 4326 (CoAP)", Work in Progress, Internet-Draft, draft-ietf- 4327 core-coap-pubsub-09, 30 September 2019, 4328 . 4331 [I-D.ietf-core-groupcomm-bis] 4332 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 4333 for the Constrained Application Protocol (CoAP)", Work in 4334 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 4335 05, 25 October 2021, . 4338 [I-D.tiloca-core-oscore-discovery] 4339 Tiloca, M., Amsuess, C., and P. V. D. Stok, "Discovery of 4340 OSCORE Groups with the CoRE Resource Directory", Work in 4341 Progress, Internet-Draft, draft-tiloca-core-oscore- 4342 discovery-10, 25 October 2021, 4343 . 4346 [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management 4347 Protocol (GKMP) Specification", RFC 2093, 4348 DOI 10.17487/RFC2093, July 1997, 4349 . 4351 [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management 4352 Protocol (GKMP) Architecture", RFC 2094, 4353 DOI 10.17487/RFC2094, July 1997, 4354 . 4356 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 4357 Multicast: Issues and Architectures", RFC 2627, 4358 DOI 10.17487/RFC2627, June 1999, 4359 . 4361 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 4362 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 4363 . 4365 [RFC7641] Hartke, K., "Observing Resources in the Constrained 4366 Application Protocol (CoAP)", RFC 7641, 4367 DOI 10.17487/RFC7641, September 2015, 4368 . 4370 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 4371 the Constrained Application Protocol (CoAP)", RFC 7959, 4372 DOI 10.17487/RFC7959, August 2016, 4373 . 4375 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 4376 Interchange Format", STD 90, RFC 8259, 4377 DOI 10.17487/RFC8259, December 2017, 4378 . 4380 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 4381 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 4382 May 2018, . 4384 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 4385 "Object Security for Constrained RESTful Environments 4386 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 4387 . 4389 Appendix A. Requirements on Application Profiles 4391 This section lists the requirements on application profiles of this 4392 specification, for the convenience of application profile designers. 4394 A.1. Mandatory-to-Address Requirements 4396 * REQ1: Specify the format and encoding of 'scope'. This includes 4397 defining the set of possible roles and their identifiers, as well 4398 as the corresponding encoding to use in the scope entries 4399 according to the used scope format (see Section 3.1). 4401 * REQ2: If the AIF format of 'scope' is used, register its specific 4402 instance of "Toid" and "Tperm", as well as the corresponding Media 4403 Type and Content-Format, as per the guidelines in 4404 [I-D.ietf-ace-aif]. 4406 * REQ3: If used, specify the acceptable values for 'sign_alg' (see 4407 Section 3.3). 4409 * REQ4: If used, specify the acceptable values for 'sign_parameters' 4410 (see Section 3.3). 4412 * REQ5: If used, specify the acceptable values for 4413 'sign_key_parameters' (see Section 3.3). 4415 * REQ6: Specify the acceptable formats for encoding public keys and, 4416 if used, the acceptable values for 'pub_key_enc' (see 4417 Section 3.3). 4419 * REQ7: If the value of the GROUPNAME URI path and the group name in 4420 the access token scope (gname in Section 3.2) are not required to 4421 coincide, specify the mechanism to map the GROUPNAME value in the 4422 URI to the group name (see Section 4.1). 4424 * REQ8: Define whether the KDC has a public key and if this has to 4425 be provided through the 'kdc_cred' parameter, see Section 4.3.1. 4427 * REQ9: Specify if any part of the KDC interface as defined in this 4428 document is not supported by the KDC (see Section 4.1). 4430 * REQ10: Register a Resource Type for the root url-path, which is 4431 used to discover the correct url to access at the KDC (see 4432 Section 4.1). 4434 * REQ11: Define what specific actions (e.g., CoAP methods) are 4435 allowed on each resource provided by the KDC interface, depending 4436 on whether the Client is a current group member; the roles that a 4437 Client is authorized to take as per the obtained access token (see 4438 Section 3.1); and the roles that the Client has as current group 4439 member. 4441 * REQ12: Categorize possible newly defined operations for Clients 4442 into primary operations expected to be minimally supported and 4443 secondary operations, and provide accompanying considerations (see 4444 Section 4.1.1). 4446 * REQ13: Specify the encoding of group identifier (see 4447 Section 4.2.1). 4449 * REQ14: Specify the approaches used to compute and verify the PoP 4450 evidence to include in 'client_cred_verify', and which of those 4451 approaches is used in which case (see Section 4.3.1). 4453 * REQ15: Specify how the nonce N_S is generated, if the token is not 4454 provided to the KDC through the Token Transfer Request to the 4455 authz-info endpoint (e.g., if it is used directly to validate TLS 4456 instead). 4458 * REQ16 Define the initial value of the 'num' parameter (see 4459 Section 4.3.1). 4461 * REQ17: Specify the format of the 'key' parameter (see 4462 Section 4.3.1). 4464 * REQ18: Specify the acceptable values of the 'gkty' parameter (see 4465 Section 4.3.1). 4467 * REQ19: Specify and register the application profile identifier 4468 (see Section 4.3.1). 4470 * REQ20: If used, specify the format and content of 'group_policies' 4471 and its entries. Specify the policies default values (see 4472 Section 4.3.1). 4474 * REQ21: Specify the approaches used to compute and verify the PoP 4475 evidence to include in 'kdc_cred_verify', and which of those 4476 approaches is used in which case (see Section 4.3.1). 4478 * REQ22: Specify the communication protocol the members of the group 4479 must use (e.g., multicast CoAP). 4481 * REQ23: Specify the security protocol the group members must use to 4482 protect their communication (e.g., group OSCORE). This must 4483 provide encryption, integrity and replay protection. 4485 * REQ24: Specify how the communication is secured between Client and 4486 KDC. Optionally, specify transport profile of ACE 4487 [I-D.ietf-ace-oauth-authz] to use between Client and KDC (see 4488 Section 4.3.1.1. 4490 * REQ25: Specify the format of the identifiers of group members (see 4491 Section 4.3.1). 4493 * REQ26: Specify policies at the KDC to handle ids that are not 4494 included in 'get_pub_keys' (see Section 4.4.1). 4496 * REQ27: Specify the format of newly-generated individual keying 4497 material for group members, or of the information to derive it, 4498 and corresponding CBOR label (see Section 4.8.1). 4500 * REQ28: Specify and register the identifier of newly defined 4501 semantics for binary scopes (see Section 7). 4503 * REQ29: Categorize newly defined parameters according to the same 4504 criteria of Section 8. 4506 * REQ30: Define whether Clients must, should or may support the 4507 conditional parameters defined in Section 8, and under which 4508 circumstances. 4510 A.2. Optional-to-Address Requirements 4512 * OPT1: Optionally, if the textual format of 'scope' is used, 4513 specify CBOR values to use for abbreviating the role identifiers 4514 in the group (see Section 3.1). 4516 * OPT2: Optionally, specify the additional parameters used in the 4517 exchange of Token Transfer Request and Response (see Section 3.3). 4519 * OPT3: Optionally, specify the negotiation of parameter values for 4520 signature algorithm and signature keys, if 'sign_info' is not used 4521 (see Section 3.3). 4523 * OPT4: Optionally, specify possible or required payload formats for 4524 specific error cases. 4526 * OPT5: Optionally, specify additional identifiers of error types, 4527 as values of the 'error' field in an error response from the KDC. 4529 * OPT6: Optionally, specify the encoding of 'pub_keys_repos' if the 4530 default is not used (see Section 4.3.1). 4532 * OPT7: Optionally, specify the functionalities implemented at the 4533 'control_uri' resource hosted at the Client, including message 4534 exchange encoding and other details (see Section 4.3.1). 4536 * OPT8: Optionally, specify the behavior of the handler in case of 4537 failure to retrieve a public key for the specific node (see 4538 Section 4.3.1). 4540 * OPT9: Optionally, define a default group rekeying scheme, to refer 4541 to in case the 'rekeying_scheme' parameter is not included in the 4542 Joining Response (see Section 4.3.1). 4544 * OPT10: Optionally, specify the functionalities implemented at the 4545 'control_group_uri' resource hosted at the Client, including 4546 message exchange encoding and other details (see Section 4.3.1). 4548 * OPT11: Optionally, specify policies that instruct Clients to 4549 retain messages and for how long, if they are unsuccessfully 4550 decrypted (see Section 4.8.1.1). This makes it possible to 4551 decrypt such messages after getting updated keying material. 4553 * OPT12: Optionally, specify for the KDC to perform group rekeying 4554 (together or instead of renewing individual keying material) when 4555 receiving a Key Renewal Request (see Section 4.8.2.1). 4557 * OPT13: Optionally, specify how the identifier of a group members's 4558 public key is included in requests sent to other group members 4559 (see Section 4.9.1.1). 4561 * OPT14: Optionally, specify additional information to include in 4562 rekeying messages for the "Point-to-Point" group rekeying scheme 4563 (see Section 6). 4565 * OPT15: Optionally, specify if Clients must or should support any 4566 of the parameters defined as optional in this specification (see 4567 Section 8). 4569 Appendix B. Extensibility for Future COSE Algorithms 4571 As defined in Section 8.1 of [I-D.ietf-cose-rfc8152bis-algs], future 4572 algorithms can be registered in the "COSE Algorithms" registry 4573 [COSE.Algorithms] as specifying none or multiple COSE capabilities. 4575 To enable the seamless use of such future registered algorithms, this 4576 section defines a general, agile format for each 'sign_info_entry' of 4577 the 'sign_info' parameter in the Token Transfer Response, see 4578 Section 3.3.1. 4580 If any of the currently registered COSE algorithms is considered, 4581 using this general format yields the same structure of 4582 'sign_info_entry' defined in this document, thus ensuring retro- 4583 compatibility. 4585 B.1. Format of 'sign_info_entry' 4587 The format of each 'sign_info_entry' (see Section 3.3.1) is 4588 generalized as follows. Given N the number of elements of the 4589 'sign_parameters' array, i.e., the number of COSE capabilities of the 4590 signature algorithm, then: 4592 * 'sign_key_parameters' is replaced by N elements 'sign_capab_i', 4593 each of which is a CBOR array. 4595 * The i-th array following 'sign_parameters', i.e., 'sign_capab_i' 4596 (i = 0, ..., N-1), is the array of COSE capabilities for the 4597 algorithm capability specified in 'sign_parameters'[i]. 4599 sign_info_entry = 4600 [ 4601 id : gname / [ + gname ], 4602 sign_alg : int / tstr, 4603 sign_parameters : [ alg_capab_1 : any, 4604 alg_capab_2 : any, 4605 ..., 4606 alg_capab_N : any], 4607 sign_capab_1 : [ any ], 4608 sign_capab_2 : [ any ], 4609 ..., 4610 sign_capab_N : [ any ], 4611 pub_key_enc = int / nil 4612 ] 4614 gname = tstr 4616 Figure 37: 'sign_info_entry' with general format 4618 Appendix C. Document Updates 4620 RFC EDITOR: PLEASE REMOVE THIS SECTION. 4622 C.1. Version -14 to -15 4624 * Fixed nits. 4626 C.2. Version -13 to -14 4628 * Clarified scope and goal of the document in abstract and 4629 introduction. 4631 * Overall clarifications on semantics of operations and parameters. 4633 * Major restructuring in the presentation of the KDC interface. 4635 * Revised error handling, also removing redundant text. 4637 * Imported parameters and KDC resource about the KDC's public key 4638 from draft-ietf-ace-key-groupcomm-oscore. 4640 * New parameters 'group_rekeying_scheme' and 'control_group_uri'. 4642 * Provided example of administrative keying material transported in 4643 'mgt_key_material'. 4645 * Reasoned categorization of parameters, as expected support by ACE 4646 Clients. 4648 * Reasoned categorization of KDC functionalities, as minimally/ 4649 optional to support for ACE Clients. 4651 * Guidelines on enhanced error responses using 'error' and 4652 'error_description'. 4654 * New section on group rekeying, discussing at a high-level a basic 4655 one-to-one approach and possible one-to-many approaches. 4657 * Revised and expanded security considerations, also about the KDC. 4659 * Updated list of requirements for application profiles. 4661 * Several further clarifications and editorial improvements. 4663 C.3. Version -05 to -13 4665 * Incremental revision of the KDC interface. 4667 * Removed redundancy in parameters about signature algorithm and 4668 signature keys. 4670 * Node identifiers always indicated with 'peer_identifiers'. 4672 * Format of public keys changed from raw COSE Keys to be 4673 certificates, CWTs or CWT Claims Set (CCS). Adapted parameter 4674 'pub_key_enc'. 4676 * Parameters and functionalities imported from draft-ietf-key- 4677 groupcomm-oscore where early defined. 4679 * Possible provisioning of the KDC's Diffie-Hellman public key in 4680 response to the Token transferring to /authz-info. 4682 * Generalized proof-of-possession evidence, to be not necessarily a 4683 signature. 4685 * Public keys of group members may be retrieved filtering by role 4686 and/or node identifier. 4688 * Enhanced error handling with error code and error description. 4690 * Extended "typed" format for the 'scope' claim, optional to use. 4692 * Editorial improvements. 4694 C.4. Version -04 to -05 4695 * Updated uppercase/lowercase URI segments for KDC resources. 4697 * Supporting single Access Token for multiple groups/topics. 4699 * Added 'control_uri' parameter in the Joining Request. 4701 * Added 'peer_roles' parameter to support legal requesters/ 4702 responders. 4704 * Clarification on stopping using owned keying material. 4706 * Clarification on different reasons for processing failures, 4707 related policies, and requirement OPT11. 4709 * Added a KDC sub-resource for group members to upload a new public 4710 key. 4712 * Possible group rekeying following an individual Key Renewal 4713 Request. 4715 * Clarified meaning of requirement REQ3; added requirement OPT12. 4717 * Editorial improvements. 4719 C.5. Version -03 to -04 4721 * Revised RESTful interface, as to methods and parameters. 4723 * Extended processing of joining request, as to check/retrieval of 4724 public keys. 4726 * Revised and extended profile requirements. 4728 * Clarified specific usage of parameters related to signature 4729 algorithms/keys. 4731 * Included general content previously in draft-ietf-ace-key- 4732 groupcomm-oscore 4734 * Registration of media type and content format application/ace- 4735 group+cbor 4737 * Editorial improvements. 4739 C.6. Version -02 to -03 4741 * Exchange of information on the signature algorithm and related 4742 parameters, during the Token POST (Section 3.3). 4744 * Restructured KDC interface, with new possible operations 4745 (Section 4). 4747 * Client PoP signature for the Joining Request upon joining 4748 (Section 4.1.2.1). 4750 * Revised text on group member removal (Section 5). 4752 * Added more profile requirements (Appendix A). 4754 C.7. Version -01 to -02 4756 * Editorial fixes. 4758 * Distinction between transport profile and application profile 4759 (Section 1.1). 4761 * New parameters 'sign_info' and 'pub_key_enc' to negotiate 4762 parameter values for signature algorithm and signature keys 4763 (Section 3.3). 4765 * New parameter 'type' to distinguish different Key Distribution 4766 Request messages (Section 4.1). 4768 * New parameter 'client_cred_verify' in the Key Distribution Request 4769 to convey a Client signature (Section 4.1). 4771 * Encoding of 'pub_keys_repos' (Section 4.1). 4773 * Encoding of 'mgt_key_material' (Section 4.1). 4775 * Improved description on retrieval of new or updated keying 4776 material (Section 6). 4778 * Encoding of 'get_pub_keys' in Public Key Request (Section 7.1). 4780 * Extended security considerations (Sections 10.1 and 10.2). 4782 * New "ACE Public Key Encoding" IANA registry (Section 11.2). 4784 * New "ACE Groupcomm Parameters" IANA registry (Section 11.3), 4785 populated with the entries in Section 8. 4787 * New "Ace Groupcomm Request Type" IANA registry (Section 11.4), 4788 populated with the values in Section 9. 4790 * New "ACE Groupcomm Policy" IANA registry (Section 11.7) populated 4791 with two entries "Sequence Number Synchronization Method" and "Key 4792 Update Check Interval" (Section 4.2). 4794 * Improved list of requirements for application profiles 4795 (Appendix A). 4797 C.8. Version -00 to -01 4799 * Changed name of 'req_aud' to 'audience' in the Authorization 4800 Request (Section 3.1). 4802 * Defined error handling on the KDC (Sections 4.2 and 6.2). 4804 * Updated format of the Key Distribution Response as a whole 4805 (Section 4.2). 4807 * Generalized format of 'pub_keys' in the Key Distribution Response 4808 (Section 4.2). 4810 * Defined format for the message to request leaving the group 4811 (Section 5.2). 4813 * Renewal of individual keying material and methods for group 4814 rekeying initiated by the KDC (Section 6). 4816 * CBOR type for node identifiers in 'get_pub_keys' (Section 7.1). 4818 * Added section on parameter identifiers and their CBOR keys 4819 (Section 8). 4821 * Added request types for requests to a Join Response (Section 9). 4823 * Extended security considerations (Section 10). 4825 * New IANA registries "ACE Groupcomm Key registry", "ACE Groupcomm 4826 Profile registry", "ACE Groupcomm Policy registry" and "Sequence 4827 Number Synchronization Method registry" (Section 11). 4829 * Added appendix about requirements for application profiles of ACE 4830 on group communication (Appendix A). 4832 Acknowledgments 4834 The following individuals were helpful in shaping this document: 4835 Christian Amsuess, Carsten Bormann, Rikard Hoeglund, Ben Kaduk, 4836 Watson Ladd, John Mattsson, Daniel Migault, Jim Schaad, Ludwig Seitz, 4837 Goeran Selander, Cigdem Sengul and Peter van der Stok. 4839 The work on this document has been partly supported by VINNOVA and 4840 the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home 4841 (Grant agreement 952652); and by the EIT-Digital High Impact 4842 Initiative ACTIVE. 4844 Authors' Addresses 4846 Francesca Palombini 4847 Ericsson AB 4848 Torshamnsgatan 23 4849 SE-16440 Stockholm Kista 4850 Sweden 4852 Email: francesca.palombini@ericsson.com 4854 Marco Tiloca 4855 RISE AB 4856 Isafjordsgatan 22 4857 SE-16440 Stockholm Kista 4858 Sweden 4860 Email: marco.tiloca@ri.se