idnits 2.17.1 draft-ietf-ace-key-groupcomm-14.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 == Line 1700 has weird spacing: '...ds, for group...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: If 'sign_info' is included in the Token Transfer Request, the KDC SHOULD include the 'sign_info' parameter in the Token Transfer Response, as per the format defined in Section 3.3.1. Note that the field 'id' of each 'sign_info_entry' specifies the name, or array of group names, for which that 'sign_info_entry' applies to. As an exception, the KDC MAY NOT include the 'sign_info' parameter in the Token Transfer Response even if 'sign_info' is included in the Token Transfer Request, in case none of the groups that the Client is authorized to join uses signatures to achieve source authentication. -- The document date (25 October 2021) is 913 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 1263 -- Looks like a reference, but probably isn't: '02' on line 1263 == Unused Reference: 'I-D.ietf-cose-rfc8152bis-struct' is defined on line 4234, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-ace-aif-03 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-45 == 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 (-11) 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 (~~), 12 warnings (==), 6 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: 28 April 2022 RISE AB 6 25 October 2021 8 Key Provisioning for Group Communication using ACE 9 draft-ietf-ace-key-groupcomm-14 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 28 April 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 -13 to -14 . . . . . . . . . . . . . . . . . . . 101 153 C.2. Version -05 to -13 . . . . . . . . . . . . . . . . . . . 102 154 C.3. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 102 155 C.4. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 103 156 C.5. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 103 157 C.6. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 104 158 C.7. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 105 159 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 105 160 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 106 162 1. Introduction 164 This document builds on the Authentication and Authorization for 165 Constrained Environments (ACE) framework and defines how to request, 166 distribute and renew keying material and configuration parameters to 167 protect message exchanges in a group communication environment. 169 Candidate group members acting as Clients and authorized to join a 170 group can interact with the Key Distribution Center (KDC) acting as 171 Resource Server and responsible for that group, in order to obtain 172 the necessary keying material and parameters to communicate with 173 other group members. 175 In particular, this document defines the operations and interface 176 available at the KDC, as well as general message formats for the 177 interactions between Clients and KDC. At the same time, 178 communications in the group can rely on different approaches, e.g., 179 based on multicast [I-D.ietf-core-groupcomm-bis] or on publish- 180 subscribe messaging [I-D.ietf-core-coap-pubsub], and can be protected 181 in different ways. 183 Therefore, this document delegates details on the communication and 184 security approaches used in a group to separate application profiles. 185 These are specialized instances of this document, targeting a 186 particular group communication approach and defining how 187 communications in the group are protected, as well as the specific 188 keying material and configuration parameters provided to group 189 members. In order to ensure consistency and aid the development of 190 such application profiles, this document defines a number of related 191 compliance requirements (see Appendix A). 193 If the application requires backward and forward security, new keying 194 material is generated and distributed to the group upon membership 195 changes (rekeying). A group rekeying scheme performs the actual 196 distribution of the new keying material, by rekeying the current 197 group members when a new Client joins the group, and the remaining 198 group members when a Client leaves the group. This can rely on 199 different approaches, including efficient group rekeying schemes such 200 as [RFC2093], [RFC2094] and [RFC2627]. 202 Consistently with what is recommeded in the ACE framework, this 203 document uses CBOR [RFC8949] for data encoding. However, using JSON 204 [RFC8259] instead of CBOR is possible, by relying on the conversion 205 method specified in Sections 6.1 and 6.2 of [RFC8949]. 207 1.1. Terminology 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 211 "OPTIONAL" in this document are to be interpreted as described in BCP 212 14 [RFC2119] [RFC8174] when, and only when, they appear in all 213 capitals, as shown here. 215 Readers are expected to be familiar with: 217 * The terms and concepts described in the ACE framework 218 [I-D.ietf-ace-oauth-authz] and in the Authorization Information 219 Format (AIF) [I-D.ietf-ace-aif] to express authorization 220 information. The terminology for entities in the considered 221 architecture is defined in OAuth 2.0 [RFC6749]. In particular, 222 this includes Client (C), Resource Server (RS), and Authorization 223 Server (AS). 225 * The terms and concepts described in CoAP [RFC7252]. Unless 226 otherwise indicated, the term "endpoint" is used here following 227 its OAuth definition, aimed at denoting resources such as /token 228 and /introspect at the AS, and /authz-info at the RS. This 229 document does not use the CoAP definition of "endpoint", which is 230 "An entity participating in the CoAP protocol". 232 * The terms and concepts described in CBOR [RFC8949] and COSE [I-D.i 233 etf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs][I-D.iet 234 f-cose-countersign]. 236 A principal interested to participate in group communication as well 237 as already participating as a group member is interchangeably denoted 238 as "Client" or "node". 240 Furthermore, this document uses "names" or "identifiers" for groups 241 and nodes. Their different meanings are summarized below. 243 * Group: a set of nodes that share common keying material and 244 security parameters used to protect their communications with one 245 another. That is, the term refers to a "security group". 247 This is not to be confused with an "application group", which has 248 relevance at the application level and whose members share a 249 common pool of resources or content. Examples of application 250 groups are the set of all nodes deployed in a same physical room, 251 or the set of nodes registered to a pub-sub topic. 253 The same security group might be associated to multiple 254 application groups. Also, the same application group can be 255 associated to multiple security groups. Further details and 256 considerations on the mapping between the two types of group are 257 out of the scope of this document. 259 * Key Distribution Center (KDC): the entity responsible for managing 260 one or multiple groups, with particular reference to the group 261 membership and the keying material to use for protecting group 262 communications. 264 * Group name: the invariant once established identifier of a group. 265 It is used in the interactions between Client, AS and RS to 266 identify a group. A group name is always unique among the group 267 names of the existing groups under the same KDC. 269 * GROUPNAME: the invariant once established text string used in 270 URIs. GROUPNAME uniquely maps to the group name of a group, 271 although they do not necessarily coincide. 273 * Group identifier: the identifier of the group keying material used 274 in a group. Unlike group name and GROUPNAME, this identifier 275 changes over time, when the group keying material is updated. 277 * Node name: the invariant once established identifier of a node. 278 It is used in the interactions between Client and RS and to 279 identify a member of a group. Within the same group, a node name 280 is always unique among the node names of all the current members 281 of that group. 283 * NODENAME: the invariant once established text string used in URIs 284 to identify a member a group. Its value coincides with the node 285 name of the associated group member. 287 This document additionally uses the following terminology: 289 * Transport profile, to indicate a profile of ACE as per 290 Section 5.8.4.3 of [I-D.ietf-ace-oauth-authz]. A transport 291 profile specifies the communication protocol and communication 292 security protocol between an ACE Client and Resource Server, as 293 well as proof-of-possession methods, if it supports proof-of- 294 possession access tokens, etc. Transport profiles of ACE include, 295 for instance, [I-D.ietf-ace-oscore-profile], 296 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-mqtt-tls-profile]. 298 * Application profile, that defines how applications enforce and use 299 supporting security services they require. These services may 300 include, for instance, provisioning, revocation and distribution 301 of keying material. An application profile may define specific 302 procedures and message formats. 304 2. Overview 306 The full procedure can be separated in two phases: the first one 307 follows the ACE Framework, between Client, AS and KDC; the second one 308 is the key distribution between Client and KDC. After the two phases 309 are completed, the Client is able to participate in the group 310 communication, via a Dispatcher entity. 312 +------------+ +-----------+ 313 | AS | | KDC | 314 | | .----->| | 315 +------------+ / +-----------+ 316 ^ / 317 | / 318 v / +-----------+ 319 +------------+ / +------------+ |+-----------+ 320 | Client |<-' | Dispatcher | ||+-----------+ 321 | |<------------->| |<------->||| Group | 322 +------------+ +------------+ ||| members | 323 +++-----------+ 325 Figure 1: Key Distribution Participants 327 The following participants (see Figure 1) take part in the 328 authorization and key distribution. 330 * Client (C): node that wants to join a group and take part in group 331 communication with other group memebrs. Within the group, the 332 Client can have different roles. 334 * Authorization Server (AS): as per the AS defined in the ACE 335 Framework, it enforces access policies, and knows if a node is 336 allowed to join a given group with write and/or read rights. 338 * Key Distribution Center (KDC): maintains the keying material to 339 protect group communications, and provides it to Clients 340 authorized to join a given group. During the first part of the 341 exchange (Section 3), it takes the role of the RS in the ACE 342 Framework. During the second part (Section 4), which is not based 343 on the ACE Framework, it distributes the keying material. In 344 addition, it provides the latest keying material to group members 345 when requested or, if required by the application, when membership 346 changes. 348 * Dispatcher: entity through which the Clients communicate with the 349 group, when sending a message intended to multiple group members. 350 That is, the Dispatcher distributes such a one-to-many message to 351 the group members as intended recipients. A single-recipient 352 message intended to only one group member may be delivered by 353 alternative means, with no assistance from the Dispatcher. 355 Examples of a Dispatcher are: the Broker in a pub-sub setting; a 356 relayer for group communication that delivers group messages as 357 multiple unicast messages to all group members; an implicit entity 358 as in a multicast communication setting, where messages are 359 transmitted to a multicast IP address and delivered on the 360 transport channel. 362 This document specifies a mechanism for: 364 * Authorizing a Client to join the group (Section 3), and providing 365 it with the group keying material to communicate with the other 366 group members (Section 4). 368 * Allowing a group member to retrieve group keying material 369 (Section 4.8.1.1 and Section 4.8.2.1). 371 * Allowing a group member to retrieve public keys of other group 372 members (Section 4.4.1.1) and to provide an updated public key 373 (Section 4.9.1.1). 375 * Allowing a group member to leave the group (Section 5). 377 * Evicting a group member from the group (Section 5). 379 * Renewing and re-distributing the group keying material (rekeying) 380 upon a membership change in the group (Section 4.8.3.1 and 381 Section 5). 383 Figure 2 provides a high level overview of the message flow for a 384 node joining a group. The message flow can be expanded as follows. 386 1. The joining node requests an access token from the AS, in order 387 to access one or more group-membership resources at the KDC and 388 hence join the associated groups. 390 This exchange between Client and AS MUST be secured, as specified 391 by the transport profile of ACE used between Client and KDC. 392 Based on the response from the AS, the joining node will 393 establish or continue using a secure communication association 394 with the KDC. 396 2. The joining node transfers authentication and authorization 397 information to the KDC, by transferring the obtained access 398 token. This is typically achieved by including the access token 399 in a request sent to the /authz-info endpoint at the KDC. 401 Once this exchange is completed, the joining node MUST have a 402 secure communication association established with the KDC, before 403 joining a group under that KDC. 405 This exchange and the following secure communications between the 406 Client and the KDC MUST occur in accordance with the transport 407 profile of ACE used between Client and KDC, such as the DTLS 408 transport profile [I-D.ietf-ace-dtls-authorize] and OSCORE 409 transport profile [I-D.ietf-ace-oscore-profile] of ACE. 411 3. The joining node starts the joining process to become a member of 412 the group, by sending a request to the related group-membership 413 resource at the KDC. Based on the application requirements and 414 policies, the KDC may perform a group rekeying, by generating new 415 group keying material and distributing it to the current group 416 members through the rekeying scheme used in the group. 418 At the end of the joining process, the joining node has received 419 from the KDC the parameters and group keying material to securely 420 communicate with the other group members. Also, the KDC has 421 stored the association between the authorization information from 422 the access token and the secure session with the joining node. 424 4. The joining node and the KDC maintain the secure association, to 425 support possible future communications. These especially include 426 key management operations, such as retrieval of updated keying 427 material or participation to a group rekeying process. 429 5. The joining node can communicate securely with the other group 430 members, using the keying material provided in step 3. 432 C AS KDC Group 433 | | | Members 434 / | | | | 435 | |--- Authorization Request -->| | | 436 | | | | | 437 | |<-- Authorization Response --| | | 438 (*) < | | | | 439 | | | | | 440 | |--- Token Transfer Request ---->| | 441 | | | | 442 | |<--- Token Transfer Response-----| | 443 \ | | | | 444 | | | | 445 |------ Joining Request --------->| | 446 | | | | 447 | | | -- Group rekeying -->| 448 | | | (optional) | 449 |<----- Joining Response ---------| | 450 | | | | 451 | | | | 452 | | | Dispatcher | 453 | | | 454 |<======= Secure group communication =========|=========>| 455 | | | 457 (*) Defined in the ACE framework 459 Figure 2: Message Flow Upon New Node's Joining 461 3. Authorization to Join a Group 463 This section describes in detail the format of messages exchanged by 464 the participants when a node requests access to a given group. This 465 exchange is based on ACE [I-D.ietf-ace-oauth-authz]. 467 As defined in [I-D.ietf-ace-oauth-authz], the Client requests the AS 468 for the authorization to join the group through the KDC (see 469 Section 3.1). If the request is approved and authorization is 470 granted, the AS provides the Client with a proof-of-possession access 471 token and parameters to securely communicate with the KDC (see 472 Section 3.2). 474 Communications between the Client and the AS MUST be secured, 475 according to what is defined by the used transport profile of ACE. 476 The Content-Format used in the message also depends on the used 477 transport profile of ACE. For example, it can be application/ 478 ace+cbor for the first two messages and application/cwt for the third 479 message, which are defined in the ACE framework. 481 The transport profile of ACE also defines a number of details such as 482 the communication and security protocols used with the KDC (see 483 Appendix C of [I-D.ietf-ace-oauth-authz]). 485 Figure 3 gives an overview of the exchange described above. 487 Client AS KDC 488 | | | 489 |---- Authorization Request: POST /token ------->| | 490 | | | 491 |<--- Authorization Response: 2.01 (Created) ----| | 492 | | | 493 |---- Token Transfer Request: POST /authz-info ------->| 494 | | | 495 |<--- Token Transfer Response: 2.01 (Created) -------->| 496 | | | 498 Figure 3: Message Flow of Join Authorization 500 3.1. Authorization Request 502 The Authorization Request sent from the Client to the AS is defined 503 in Section 5.8.1 of [I-D.ietf-ace-oauth-authz] and MAY contain the 504 following parameters, which, if included, MUST have format and value 505 as specified below. 507 * 'scope', specifying the name of the groups that the Client 508 requests to access, and optionally the roles that the Client 509 requests to have in those groups. 511 This parameter is encoded as a CBOR byte string, which wraps a 512 CBOR array of one or more scope entries. All the scope entries 513 are specified according to a same format, i.e. either the AIF 514 format or the textual format defined below. 516 - If the AIF format is used, each scope entry is encoded as 517 specified in [I-D.ietf-ace-aif]. The object identifier "Toid" 518 corresponds to the group name and MUST be encoded as a CBOR 519 text string. The permission set "Tperm" indicates the roles 520 that the Client wishes to take in the group. 522 The AIF format is the default format for application profiles 523 of this specification, and is preferable for those that aim to 524 a compact encoding of scope. This is desirable especially for 525 application profiles defining several roles, with the Client 526 possibly requesting for multiple roles combined. 528 Figure 4 shows an example in CDDL notation [RFC8610] where 529 scope uses the AIF format. 531 - If the textual format is used, each scope entry is a CBOR array 532 formatted as follows. 534 o As first element, the group name, encoded as a CBOR text 535 string. 537 o Optionally, as second element, the role or CBOR array of 538 roles that the Client wishes to take in the group. This 539 element is optional since roles may have been pre-assigned 540 to the Client, as associated to its verifiable identity 541 credentials. Alternatively, the application may have 542 defined a single, well-known role for the target resource(s) 543 and audience(s). 545 Figure 5 shows an example in CDDL notation where scope uses the 546 textual format, with group name and role identifiers encoded as 547 CBOR text strings. 549 It is REQUIRED of application profiles of this specificaton to 550 specify the exact format and encoding of scope (REQ1). This 551 includes defining the set of possible roles and their identifiers, 552 as well as the corresponding encoding to use in the scope entries 553 according to the used scope format. 555 If the application profile uses the AIF format, it is also 556 REQUIRED to register its specific instance of "Toid" and "Tperm", 557 as well as the corresponding Media Type and Content-Format, as per 558 the guidelines in [I-D.ietf-ace-aif] (REQ2). 560 If the application profile uses the textual format, it MAY 561 additionally specify CBOR values to use for abbreviating the role 562 identifiers (OPT1). 564 * 'audience', with an identifier of the KDC. 566 As defined in [I-D.ietf-ace-oauth-authz], other additional parameters 567 can be included if necessary. 569 gname = tstr 571 permissions = uint . bits roles 573 roles = &( 574 Requester: 1, 575 Responder: 2, 576 Monitor: 3, 577 Verifier: 4 578 ) 580 scope_entry = AIF_Generic 582 scope = << [ + scope_entry ] >> 584 Figure 4: Example of scope using the AIF format 586 gname = tstr 588 role = tstr 590 scope_entry = [ gname , ? ( role / [ 2*role ] ) ] 592 scope = << [ + scope_entry ] >> 594 Figure 5: Example of scope using the textual format, with the 595 group name and role identifiers encoded as text strings 597 3.2. Authorization Response 599 The AS processes the Authorization Request as defined in 600 Section 5.8.2 of [I-D.ietf-ace-oauth-authz], especially verifying 601 that the Client is authorized to access the specified groups with the 602 requested roles, or possibly a subset of those. 604 In case of successful verification, the Authorization Response sent 605 from the AS to the Client is also defined in Section 5.8.2 of 606 [I-D.ietf-ace-oauth-authz]. Note that the parameter 'expires_in' MAY 607 be omitted if the application defines how the expiration time is 608 communicated to the Client via other means, or if it establishes a 609 default value. 611 Additionally, when included, the following parameter MUST have the 612 corresponding values: 614 * 'scope' has the same format and encoding of 'scope' in the 615 Authorization Request, defined in Section 3.1. If this parameter 616 is not present, the granted scope is equal to the one requested in 617 Section 3.1. 619 The proof-of-possession access token (in 'access_token' above) MUST 620 contain the following parameters: 622 * a confirmation claim (see for example 'cnf' defined in Section 3.1 623 of [RFC8747] for CWT); 625 * an expiration time claim (see for example 'exp' defined in 626 Section 3.1.4 of [RFC8392] for CWT); 628 * a scope claim (see for example 'scope' registered in Section 8.14 629 of [I-D.ietf-ace-oauth-authz] for CWT). 631 This claim specifies the same access control information as in the 632 'scope' parameter of the Authorization Response, if the parameter 633 is present in the message, or as in the 'scope' parameter of the 634 Authorization Request otherwise. 636 By default, this claim has the same encoding as the 'scope' 637 parameter in the Authorization Request, defined in Section 3.1. 639 Optionally, an alternative extended format of scope defined in 640 Section 7 can be used. This format explicitly signals the 641 semantics used to express the actual access control information, 642 and according to which this has to be parsed. This enables a 643 Resource Server to correctly process a received access token, also 644 in case: 646 - The Resource Server implements a KDC that supports multiple 647 application profiles of this specification, using different 648 scope semantics; and/or 650 - The Resource Server implements further services beyond a KDC 651 for group communication, using different scope semantics. 653 If the Authorization Server is aware that this applies to the 654 Resource Server for which the access token is issued, the 655 Authorization Server SHOULD use the extended format of scope 656 defined in Section 7. 658 The access token MAY additionally contain other claims that the 659 transport profile of ACE requires, or other optional parameters. 661 When receiving an Authorization Request from a Client that was 662 previously authorized, and for which the AS still owns a valid non- 663 expired access token, the AS MAY reply with that token. Note that it 664 is up to application profiles of ACE to make sure that re-posting the 665 same token does not cause re-use of keying material between nodes 666 (for example, that is done with the use of random nonces in 667 [I-D.ietf-ace-oscore-profile]). 669 3.3. Token Transferring 671 The Client sends a Token Transfer Request to the KDC, i.e., a CoAP 672 POST request including the access token and targeting the authz-info 673 endpoint (see Section 5.10.1 of [I-D.ietf-ace-oauth-authz]). 675 Note that this request deviates from the one defined in 676 [I-D.ietf-ace-oauth-authz], since it allows to ask the KDC for 677 additional information concerning the public keys used in the group 678 to ensure source authentication, as well as for possible additional 679 group parameters. 681 The joining node MAY ask for this information from the KDC through 682 the same Token Transfer Request. In this case, the message MUST have 683 Content-Format set to application/ace+cbor defined in Section 8.16 of 684 [I-D.ietf-ace-oauth-authz], and the message payload MUST be formatted 685 as a CBOR map, which MUST include the access token. The CBOR map MAY 686 additionally include the following parameter, which, if included, 687 MUST have format and value as specified below. 689 * 'sign_info' defined in Section 3.3.1, specifying the CBOR simple 690 value 'null' (0xf6) to request information about the signature 691 algorithm, signature algorithm parameters, signature key 692 parameters and about the exact encoding of public keys used in the 693 groups that the Client has been authorized to join. 695 Alternatively, such information may be pre-configured on the joining 696 node, or may be retrieved by alternative means. For example, the 697 joining node may have performed an early group discovery process and 698 obtained the link to the associated group-membership resource at the 699 KDC, together with attributes descriptive of the group configuration 700 (see, e.g., [I-D.tiloca-core-oscore-discovery]). 702 After successful verification, the Client is authorized to receive 703 the group keying material from the KDC and join the group. Hence, 704 the KDC replies to the Client with a Token Transfer Response, i.e., a 705 CoAP 2.01 (Created) response. 707 The Token Transfer Response MUST have Content-Format "application/ 708 ace+cbor", and its payload is a CBOR map. Note that this deviates 709 from what is defined in the ACE framework, where the response from 710 the authz-info endpoint is defined as conveying no payload (see 711 Section 5.10.1 of [I-D.ietf-ace-oauth-authz]). 713 If the access token contains a role that requires the Client to send 714 its own public key to the KDC when joining the group, the CBOR map 715 MUST include the parameter 'kdcchallenge' defined in Section 3.3.2, 716 specifying a dedicated challenge N_S generated by the KDC. 718 Later, when joining the group (see Section 4.3.1.1), the Client uses 719 the 'kdcchallenge' value and additional information to build a proof- 720 of-possession (PoP) input. This is in turn used to compute a PoP 721 evidence, which the Client also provides to the Group Manager in 722 order to prove possession of its own private key (see the 723 'client_cred_verify' parameter in Section 4.3.1). 725 The KDC MUST store the 'kdcchallenge' value associated to the Client 726 at least until it receives a Joining Request from it (see 727 Section 4.3.1.1), to be able to verify the PoP evidence provided 728 during the join process, and thus that the Client possesses its own 729 private key. 731 The same 'kdcchallenge' value MAY be reused several times by the 732 Client, to generate a new PoP evidence, e.g., in case the Client 733 provides the Group Manager with a new public key while being a group 734 member (see Section 4.9.1.1), or joins a different group where it 735 intends to use a different public key. Therefore, it is RECOMMENDED 736 that the KDC keeps storing the 'kdcchallenge' value after the first 737 join is processed as well. If the KDC has already discarded the 738 'kdcchallenge' value, that will trigger an error response with a 739 newly generated 'kdcchallenge' value that the Client can use to 740 restart the join process, as specified in Section 4.3.1.1. 742 If 'sign_info' is included in the Token Transfer Request, the KDC 743 SHOULD include the 'sign_info' parameter in the Token Transfer 744 Response, as per the format defined in Section 3.3.1. Note that the 745 field 'id' of each 'sign_info_entry' specifies the name, or array of 746 group names, for which that 'sign_info_entry' applies to. As an 747 exception, the KDC MAY NOT include the 'sign_info' parameter in the 748 Token Transfer Response even if 'sign_info' is included in the Token 749 Transfer Request, in case none of the groups that the Client is 750 authorized to join uses signatures to achieve source authentication. 752 Note that the CBOR map specified as payload of the 2.01 (Created) 753 response may include further parameters, e.g., according to the used 754 transport profile of ACE. Application profiles of this specification 755 MAY define additional parameters to use within this exchange (OPT2). 757 Application profiles of this specification MAY define alternative 758 specific negotiations of parameter values for the signature algorithm 759 and signature keys, if 'sign_info' is not used (OPT3). 761 If allowed by the used transport profile of ACE, the Client may 762 provide the Access Token to the KDC by other means than the Token 763 Transfer Request. An example is the DTLS transport profile of ACE, 764 where the Client can provide the access token to the KDC during the 765 secure session establishment (see Section 3.3.2 of 766 [I-D.ietf-ace-dtls-authorize]). 768 3.3.1. 'sign_info' Parameter 770 The 'sign_info' parameter is an OPTIONAL parameter of the request and 771 response messages exchanged between the Client and the authz-info 772 endpoint at the RS (see Section 5.10.1. of 773 [I-D.ietf-ace-oauth-authz]). 775 This parameter allows the Client and the RS to exchange information 776 about a signature algorithm and about public keys to accordingly use 777 for signature verification. Its exact semantics and content are 778 application specific. 780 In this specification and in application profiles building on it, 781 this parameter is used to exchange information about the signature 782 algorithm and about public keys to be used with it, in the groups 783 indicated by the transferred acces token as per its 'scope' claim 784 (see Section 3.2). 786 When used in the Token Transfer Request sent to the KDC (see 787 Section 3.3), the 'sign_info' parameter specifies the CBOR simple 788 value 'null' (0xf6). This is done to ask for information about the 789 signature algorithm and about the public keys used in the groups that 790 the Client has been authorized to join - or to have a more restricted 791 interaction as per its granted roles (e.g., the Client is an external 792 signature verifier). 794 When used in the following Token Transfer Response from the KDC (see 795 Section 3.3), the 'sign_info' parameter is a CBOR array of one or 796 more elements. The number of elements is at most the number of 797 groups that the Client has been authorized to join - or to have a 798 more restricted interaction (see above). Each element contains 799 information about signing parameters and about public keys for one or 800 more groups, and is formatted as follows. 802 * The first element 'id' is a group name or an array of group names, 803 associated to groups for which the next four elements apply. In 804 the following, each specified group name is referred to as 805 'gname'. 807 * The second element 'sign_alg' is an integer or a text string if 808 the POST request included the 'sign_info' parameter with value the 809 CBOR simple value 'null' (0xf6), and indicates the signature 810 algorithm used in the groups identified by the 'gname' values. It 811 is REQUIRED of the application profiles to define specific values 812 that this parameter can take (REQ3), selected from the set of 813 signing algorithms of the COSE Algorithms registry 814 [COSE.Algorithms]. 816 * The third element 'sign_parameters' is a CBOR array indicating the 817 parameters of the signature algorithm used in the groups 818 identified by the 'gname' values. Its content depends on the 819 value of 'sign_alg'. It is REQUIRED of the application profiles 820 to define the possible values and structure for the elements of 821 this parameter (REQ4). 823 * The fourth element 'sign_key_parameters' is a CBOR array 824 indicating the parameters of the key used with the signature 825 algorithm, in the groups identified by the 'gname' values. Its 826 content depends on the value of 'sign_alg'. It is REQUIRED of the 827 application profiles to define the possible values and structure 828 for the elements of this parameter (REQ5). 830 * The fifth element 'pub_key_enc' parameter is either a CBOR integer 831 indicating the encoding of public keys used in the groups 832 identified by the 'gname' values, or has value the CBOR simple 833 value 'null' (0xf6) indicating that the KDC does not act as 834 repository of public keys for group members. Its acceptable 835 integer values are taken from the 'Label' column of the "COSE 836 Header Parameters" registry [COSE.Header.Parameters]. It is 837 REQUIRED of the application profiles to define specific values to 838 use for this parameter, consistently with the acceptable formats 839 of public keys (REQ6). 841 The CDDL notation [RFC8610] of the 'sign_info' parameter is given 842 below. 844 sign_info = sign_info_req / sign_info_resp 846 sign_info_req = nil ; in the Token Transfer 847 ; Request to the KDC 849 sign_info_resp = [ + sign_info_entry ] ; in the Token Transfer 850 ; Response from the KDC 852 sign_info_entry = 853 [ 854 id : gname / [ + gname ], 855 sign_alg : int / tstr, 856 sign_parameters : [ any ], 857 sign_key_parameters : [ any ], 858 pub_key_enc = int / nil 859 ] 861 gname = tstr 863 This format is consistent with every signature algorithm currently 864 defined in [I-D.ietf-cose-rfc8152bis-algs], i.e., with algorithms 865 that have only the COSE key type as their COSE capability. 866 Appendix B describes how the format of each 'sign_info_entry' can be 867 generalized for possible future registered algorithms having a 868 different set of COSE capabilities. 870 3.3.2. 'kdcchallenge' Parameter 872 The 'kdcchallenge' parameter is an OPTIONAL parameter of response 873 message returned from the authz-info endpoint at the RS, as defined 874 in Section 5.10.1 of [I-D.ietf-ace-oauth-authz]. This parameter 875 contains a challenge generated by the RS and provided to the Client. 877 In this specification and in application profiles building on it, the 878 Client may use this challenge to prove possession of its own private 879 key in the Joining Request (see the 'client_cred_verify' parameter in 880 Section 4.3.1). 882 4. KDC Functionalities 884 This section describes the functionalities provided by the KDC, as 885 related to the provisioning of the keying material as well as to the 886 group membership management. 888 In particular, this section defines the interface available at the 889 KDC; specifies the handlers of each resource provided by the KDC 890 interface; and describes how Clients interact with those resources to 891 join a group and to perform additional operations as group members. 893 As most important operation after trasferring the access token to the 894 KDC, the Client can perform a "Joining" exchange with the KDC, by 895 specifying the group it requests to join (see Section 4.3.1.1). 896 Then, the KDC verifies the access token and that the Client is 897 authorized to join the specified group. If so, the KDC provides the 898 Client with the keying material to securely communicate with the 899 other members of the group. 901 Later on as a group member, the Client can also rely on the interface 902 at the KDC to perform additional operations, consistently with the 903 roles it has in the group. 905 4.1. Interface at the KDC 907 The KDC provides its interface by hosting the following resources. 908 Note that the root url-path "ace-group" used hereafter is a default 909 name; implementations are not required to use this name, and can 910 define their own instead. The Interface Description (if=) Link 911 Target Attribute value "ace.group" is registered in Section 11.5 and 912 can be used to describe this interface. 914 If request messages sent to the KDC as well as success response 915 messages from the KDC include a payload and specify a Content-Format, 916 those messages MUST have Content-Format set to application/ace- 917 groupcomm+cbor, defined in Section 11.2. CBOR labels for the message 918 parameters are defined in Section 8. 920 * /ace-group : this resource is invariant once established, and 921 indicates that this specification is used. If other applications 922 run on a KDC implementing this specification and use this same 923 resource, those applications will collide, and a mechanism will be 924 needed to differentiate the endpoints. 926 A Client can access this resource in order to retrieve a set of 927 group names, each corresponding to one of the specified group 928 identifiers. This operation is described in Section 4.2.1.1. 930 * /ace-group/GROUPNAME : one such sub-resource to /ace-group is 931 hosted for each group with name GROUPNAME that the KDC manages, 932 and contains the symmetric group keying material for that group. 934 A Client can access this resource in order to join the group with 935 name GROUPNAME, or later as a group member to retrieve the current 936 group keying material. These operations are described in 937 Section 4.3.1.1 and Section 4.3.2.1, respectively. 939 If the value of the GROUPNAME URI path and the group name in the 940 access token scope ('gname' in Section 3.2) are not required to 941 coincide, the KDC MUST implement a mechanism to map the GROUPNAME 942 value in the URI to the group name, in order to refer to the 943 correct group (REQ7). 945 * /ace-group/GROUPNAME/pub-key : this resource is invariant once 946 established, and contains the public keys of all the members of 947 the group with name GROUPNAME. 949 This resource is created only in case the KDC acts as repository 950 of public keys for group members. 952 A Client can access this resource in order to retrieve the public 953 keys of other group members, in addition to when joining the 954 group. That is, the Client can retrieve the public keys of all 955 the current group members, or a subset of them by specifying 956 filter criteria. These operations are described in 957 Section 4.4.2.1 and Section 4.4.1.1, respectively. 959 Clients may be authorized to access this resource even without 960 being group members, e.g., if authorized to be external signature 961 verifiers for the group. 963 * ace-group/GROUPNAME/kdc-pub-key : this resource is invariant once 964 established, and contains the public key of the KDC for the group 965 with name GROUPNAME. 967 This resource is created only in case the KDC has an associated 968 public key and this is required for the correct group operation. 969 It is REQUIRED of application profiles to define whether the KDC 970 has such an associated public key (REQ8). 972 A Client can interact with this resource in order to retrieve the 973 current public key of the KDC, in addition to when joining the 974 group. 976 Clients may be authorized to access this resource even without 977 being group members, e.g., if authorized to be external signature 978 verifiers for the group. 980 * /ace-group/GROUPNAME/policies : this resource is invariant once 981 established, and contains the group policies of the group with 982 name GROUPNAME. 984 A Client can access this resource as a group member in order to 985 retrieve the group policies. This operation is described in 986 Section 4.6.1.1. 988 * /ace-group/GROUPNAME/num : this resource is invariant once 989 established, and contains the current version number for the 990 symmetric group keying material of the group with name GROUPNAME. 992 A Client can access this resource as a group member in order to 993 retrieve the version number of the keying material currently used 994 in the group. This operation is described in Section 4.7.1.1. 996 * /ace-group/GROUPNAME/nodes/NODENAME : one such sub-resource of 997 /ace-group/GROUPNAME is hosted for each group member of the group 998 with name GROUPNAME. Each of such resources is identified by the 999 node name NODENAME of the associated group member, and contains 1000 the group keying material and the individual keying material for 1001 that group member. 1003 A Client as a group member can access this resource in order to 1004 retrieve the current group keying material together with its the 1005 individual keying material; request new individual keying material 1006 to use in the group; and leave the group. These operations are 1007 described in Section 4.8.1.1, Section 4.8.2.1, and 1008 Section 4.8.3.1, respectively. 1010 * /ace-group/GROUPNAME/nodes/NODENAME/pub-key : this resource is 1011 invariant once established, and contains the individual public 1012 keying material for the node with name NODENAME, as group member 1013 of the group with name GROUPNAME. 1015 A Client can access this resource in order to upload at the KDC a 1016 new public key to use in the group. This operation is described 1017 in Section 4.9.1.1. 1019 This resource is not created if the group member does not have 1020 individual public keying material to use in the group, or if the 1021 KDC does not store the public keys of group members. 1023 The KDC is expected to fully provide the interface defined above. It 1024 is otherwise REQUIRED of the application profiles of this 1025 specification to indicate which resources are not hosted, i.e., which 1026 parts of the interface defined in this section are not supported by 1027 the KDC (REQ9). Application profiles of this specification MAY 1028 extend the KDC interface, by defining additional resources and their 1029 handlers. 1031 It is REQUIRED of the application profiles of this specification to 1032 register a Resource Type for the root url-path (REQ10). This 1033 Resource Type can be used to discover the correct url to access at 1034 the KDC. This Resource Type can also be used at the GROUPNAME sub- 1035 resource, to indicate different application profiles for different 1036 groups. 1038 It is REQUIRED of the application profiles of this specification to 1039 define what specific actions (e.g., CoAP methods) are allowed on each 1040 resource provided by the KDC interface, depending on whether the 1041 Client is a current group member; the roles that a Client is 1042 authorized to take as per the obtained access token (see 1043 Section 3.1); and the roles that the Client has as current group 1044 member (REQ11). 1046 4.1.1. Operations Supported by Clients 1048 It is expected that a Client minimally supports the following set of 1049 primary operations and corresponding interactions with the KDC. 1051 * FETCH request to ace-group/ , in order to retrieve group names 1052 associated to group identifiers. 1054 * POST and GET requests to ace-group/GROUPNAME/ , in order to join a 1055 group (POST) and later retrieve the current group key material as 1056 a group member (GET). 1058 * GET and FETCH requests to ace-group/GROUPNAME/pub-key , in order 1059 to retrieve the public keys of all the other group members (GET) 1060 or only some of them by filtering (FETCH). While retrieving 1061 public keys remains possible by using GET requests, retrieval by 1062 filtering allows to greatly limit the size of exchanged messages. 1064 * GET request to ace-group/GROUPNAME/num , in order to retrieve the 1065 current version of the group key material as a group member. 1067 * DELETE request to ace-group/GROUPNAME/nodes/NODENAME , in order to 1068 leave the group. 1070 In addition, some Clients may rather not support the following set of 1071 secondary operations and corresponding interactions with the KDC. 1072 This can be specified, for instance, in compliance documents defining 1073 minimalistic Clients and their capabilities in specific deployments. 1074 In turn, these might also have to consider the used application 1075 profile of this specification. 1077 * GET request to ace-group/GROUPNAME/kdc-pub-key , in order to 1078 retrieve the current public key of the KDC, in addition to when 1079 joining the group. This is relevant only if the KDC has an 1080 associated public key and this is required for the correct group 1081 operation. 1083 * GET request to ace-group/GROUPNAME/policies , in order to retrieve 1084 the current group policies as a group member, in addition to when 1085 joining the group. 1087 * GET request to ace-group/GROUPNAME/nodes/NODENAME, in order to 1088 retrieve the current group keying material and individual keying 1089 material. The former can also be retrieved through a GET request 1090 to ace-group/GROUPNAME/ (see above). The latter would not be 1091 possible to re-obtain as a group member. 1093 * PUT request to ace-group/GROUPNAME/nodes/NODENAME , in order to 1094 ask for new individual keying material. The Client would have to 1095 alternatively re-join the group through a POST request to ace- 1096 group/GROUPNAME/ (see above). Furthermore, depending on its roles 1097 in the group or on the application profile of this specification, 1098 the Client might simply not be associated to any individual keying 1099 material. 1101 * POST request to ace-group/GROUPNAME/nodes/NODENAME/pub-key , in 1102 order to provide the KDC with a new public key. The Client would 1103 have to alternatively re-join the group through a POST request to 1104 ace-group/GROUPNAME/ (see above). Furthermore, depending on its 1105 roles in the group, the Client might simply not have an associated 1106 public key to provide. 1108 It is REQUIRED of application profiles of this specification to 1109 categorize possible newly defined operations for Clients into primary 1110 operations and secondary operations, and to provide accompanying 1111 considerations (REQ12). 1113 4.1.2. Error Handling 1115 Upon receiving a request from a Client, the KDC MUST check that it is 1116 storing a valid access token from that Client. If this is not the 1117 case, the KDC MUST reply with a 4.01 (Unauthorized) error response. 1119 Unless the request targets the /ace-group resource, the KDC MUST 1120 check that it is storing a valid access token from that Client such 1121 that: 1123 * The scope specified in the access token includes a scope entry 1124 related to the group name GROUPNAME associated to targeted 1125 resource; and 1127 * The set of roles specified in that scope entry allows the Client 1128 to perform the requested operation on the targeted resource 1129 (REQ11). 1131 In case the KDC stores a valid access token but the verifications 1132 above fail, the KDC MUST reply with a 4.03 (Forbidden) error 1133 response. This response MAY be an AS Request Creation Hints, as 1134 defined in Section 5.3 of [I-D.ietf-ace-oauth-authz], in which case 1135 the Content-Format MUST be set to application/ace+cbor. 1137 If the request is not formatted correctly (e.g., required fields are 1138 not present or are not encoded as expected), the handler MUST reply 1139 with a 4.00 (Bad Request) error response. 1141 If the request includes unknown or non-expected fields, the handler 1142 MUST silently ignore them and continue processing the request. 1143 Application profiles of this specification MAY define optional or 1144 mandatory payload formats for specific error cases (OPT4). 1146 Some error responses from the KDC can have Content-Format set to 1147 application/ace-groupcomm+cbor. In such a case, the paylod of the 1148 response MUST be a CBOR map, which includes the following fields. 1150 * 'error', with value a CBOR integer specifying the error occurred 1151 at the KDC. The value is taken from the "Value" column of the 1152 "ACE Groupcomm Errors" registry defined in Section 11.13 of this 1153 specification. This field MUST be present. 1155 * 'error_description', with value a CBOR text string specifying a 1156 human-readable diagnostic description of the error occurred at the 1157 KDC, written in English. The diagnostic text is intended for 1158 software engineers as well as for device and network operators, in 1159 order to aid debugging and provide context for possible 1160 intervention. The diagnostic message SHOULD be logged by the KDC. 1161 This field MAY be present, and it is unlikely relevant in an 1162 unattended setup where human intervention is not expected. 1164 The 'error' and 'error_description' fields are defined as OPTIONAL to 1165 support for Clients (see Section 8). A Client supporting the 'error' 1166 parameter and able to understand the specified error may use that 1167 information to determine what actions to take next. 1169 Section 9 of this specification defines an initial set of error 1170 identifiers, as possible values for the 'error' field. Application 1171 profiles of this specification inherit this initial set or error 1172 identifiers and MAY define additional value (OPT5). 1174 4.2. /ace-group 1176 This resource implements the FETCH handler. 1178 4.2.1. FETCH Handler 1180 The FETCH handler receives group identifiers and returns the 1181 corresponding group names and GROUPNAME URIs. 1183 The handler expects a request with payload formatted as a CBOR map, 1184 which MUST contain the following fields: 1186 * 'gid', whose value is encoded as a CBOR array, containing one or 1187 more group identifiers. The exact encoding of group identifier 1188 MUST be specified by the application profile (REQ13). The Client 1189 indicates that it wishes to receive the group names and GROUPNAMEs 1190 of all groups having these identifiers. 1192 The handler identifies the groups that are secured by the keying 1193 material identified by those group identifiers. 1195 If all verifications succeed, the handler replies with a 2.05 1196 (Content) response, whose payload is formatted as a CBOR map that 1197 MUST contain the following fields: 1199 * 'gid', whose value is encoded as a CBOR array, containing zero or 1200 more group identifiers. The handler indicates that those are the 1201 identifiers it is sending group names and GROUPNAMEs for. This 1202 CBOR array is a subset of the 'gid' array in the FETCH request. 1204 * 'gname', whose value is encoded as a CBOR array, containing zero 1205 or more group names. The elements of this array are encoded as 1206 text strings. Each element of index i of this CBOR array 1207 corresponds to the element of group identifier i in the 'gid' 1208 array. 1210 * 'guri', whose value is encoded as a CBOR array, containing zero or 1211 more URIs, each indicating a GROUPNAME resource. The elements of 1212 this array are encoded as text strings. Each element of index i 1213 of this CBOR array corresponds to the element of group identifier 1214 i in the 'gid' array. 1216 If the KDC does not find any group associated to the specified group 1217 identifiers, the handler returns a response with payload formatted as 1218 a CBOR byte string of zero length. 1220 Note that the KDC only verifies that the node is authorized by the AS 1221 to access this resource. Nodes that are not members of the group but 1222 are authorized to do signature verification on the group messages may 1223 be allowed to access this resource, if the application needs it. 1225 4.2.1.1. Retrieve Group Names 1227 In case the joining node only knows the group identifier of the group 1228 it wishes to join or about which it wishes to get update information 1229 from the KDC, the node can contact the KDC to request the 1230 corresponding group name and joining resource URI. The node can 1231 request several group identifiers at once. It does so by sending a 1232 CoAP FETCH request to the /ace-group endpoint at the KDC formatted as 1233 defined in Section 4.2.1. 1235 Figure 6 gives an overview of the exchanges described above, and 1236 Figure 7 shows an example. 1238 Client KDC 1239 | | 1240 |-------- Group Name and URI Retrieval Request: -------->| 1241 | FETCH /ace-group | 1242 | | 1243 |<-Group Name and URI Retrieval Response: 2.05 (Content)-| 1244 | | 1246 Figure 6: Message Flow of Group Name and URI Retrieval Request- 1247 Response 1249 Request: 1251 Header: FETCH (Code=0.05) 1252 Uri-Host: "kdc.example.com" 1253 Uri-Path: "ace-group" 1254 Content-Format: "application/ace-groupcomm+cbor" 1255 Payload (in CBOR diagnostic notation): 1256 { "gid": [01, 02] } 1258 Response: 1260 Header: Content (Code=2.05) 1261 Content-Format: "application/ace-groupcomm+cbor" 1262 Payload (in CBOR diagnostic notation): 1263 { "gid": [01, 02], "gname": ["group1", "group2"], 1264 "guri": ["ace-group/g1", "ace-group/g2"] } 1266 Figure 7: Example of Group Name and URI Retrieval Request-Response 1268 4.3. /ace-group/GROUPNAME 1270 This resource implements the POST and GET and handlers. 1272 4.3.1. POST Handler 1274 The POST handler processes the Joining Request sent by a Client to 1275 join a group, and returns a Joining Response as successful result of 1276 the joining process (see Section 4.3.1.1). At a high level, the POST 1277 handler adds the Client to the list of current group members, adds 1278 the public key of the Client to the list of the group members' public 1279 keys, and returns the symmetric group keying material for the group 1280 identified by GROUPNAME. 1282 The handler expects a request with payload formatted as a CBOR map, 1283 which MAY contain the following fields, which, if included, MUST have 1284 format and value as specified below. 1286 * 'scope', with value the specific group that the Client is 1287 attempting to join, i.e., the group name, and the roles it wishes 1288 to have in the group. This value is a CBOR byte string wrapping 1289 one scope entry, as defined in Section 3.1. 1291 * 'get_pub_keys', if the Client wishes to receive the public keys of 1292 the current group members from the KDC. This parameter may be 1293 included in the Joining Request if the KDC stores the public keys 1294 of the group members, while it is not useful to include it if the 1295 Client obtains those public keys through alternative means, e.g., 1296 from the AS. Note that including this parameter might result in a 1297 following Joining Response of large size, which can be 1298 inconvenient for resource-constrained devices. 1300 If the Client wishes to retrieve the public keys of all the 1301 current group members, the 'get_pub_keys' parameter MUST encode 1302 the CBOR simple value 'null' (0xf6). Otherwise, the 1303 'get_pub_keys' parameter MUST encode a non-empty CBOR array, 1304 containing the following three elements formatted as defined 1305 below. 1307 - The first element, namely 'inclusion_flag', encodes the CBOR 1308 simple value True. That is, the Client indicates that it 1309 wishes to receive the public keys of all group members having 1310 their node identifier specified in the third element of the 1311 'get_pub_keys' array, namely 'id_filter' (see below). 1313 - The second element, namely 'role_filter', is a non-empty CBOR 1314 array. Each element of the array contains one role or a 1315 combination of roles for the group identified by GROUPNAME. 1316 That is, when the Joining Request includes a non-Null 1317 'get_pub_keys' parameter, the Client filters public keys based 1318 on node identifiers. 1320 In particular, the Client indicates that it wishes to retrieve 1321 the public keys of all the group members having any of the 1322 single roles, or at least all of the roles indicated in any 1323 combination of roles. For example, the array ["role1", 1324 "role2+role3"] indicates that the Client wishes to receive the 1325 public keys of all group members that have at least "role1" or 1326 at least both "role2" and "role3". 1328 - The third element, namely 'id_filter', is an empty CBOR array. 1329 That is, when the Joining Request includes a non-Null 1330 'get_pub_keys' parameter, the Client does not filter public 1331 keys based on node identifiers. 1333 In fact, when first joining the group, the Client is not 1334 expected or capable to express a filter based on node 1335 identifiers of other group members. Instead, when already a 1336 group member and sending a Joining Request to re-join, the 1337 Client is not expected to include the 'get_pub_keys' parameter 1338 in the Joining Request altogether, since it can rather retrieve 1339 public keys associated to specific group identifiers as defined 1340 in Section 4.4.1.1. 1342 The CDDL definition [RFC8610] of 'get_pub_keys' is given in 1343 Figure 8, using as example encoding: node identifier encoded as a 1344 CBOR byte string; role identifier encoded as a CBOR text string, 1345 and combination of roles encoded as a CBOR array of roles. 1347 Note that, for this handler, 'inclusion_flag' is always set to 1348 true, the array of roles 'role_filter' is always non-empty, while 1349 the array of node identifiers 'id_filter' is always empty. 1350 However, this is not necessarily the case for other handlers using 1351 the 'get_pub_keys' parameter. 1353 inclusion_flag = bool 1355 role = tstr 1356 comb_role = [ 2*role ] 1357 role_filter = [ *(role / comb_role) ] 1359 id = bstr 1360 id_filter = [ *id ] 1362 get_pub_keys = null / [ inclusion_flag, role_filter, id_filter] 1364 Figure 8: CDLL definition of get_pub_keys, using as example node 1365 identifier encoded as bstr and role as tstr 1367 * 'client_cred', encoded as a CBOR byte string, with value the 1368 original binary representation of the Client's public key. This 1369 parameter is used if the KDC is managing (collecting from/ 1370 distributing to the Client) the public keys of the group members, 1371 and if the Client's role in the group will require for it to send 1372 messages to one or more group members. It is REQUIRED of the 1373 application profiles to define the specific formats that are 1374 acceptable to use for encoding public keys in the group (REQ6). 1376 * 'cnonce', encoded as a CBOR byte string, and including a dedicated 1377 nonce N_C generated by the Client. This parameter MUST be present 1378 if the 'client_cred' parameter is present. 1380 * 'client_cred_verify', encoded as a CBOR byte string. This 1381 parameter MUST be present if the 'client_cred' parameter is 1382 present and no public key associated to the Client's token can be 1383 retrieved for that group. 1385 This parameter contains a proof-of-possession (PoP) evidence 1386 computed by the Client over the following PoP input: the scope 1387 (encoded as CBOR byte string), concatenated with N_S (encoded as 1388 CBOR byte string) concatenated with N_C (encoded as CBOR byte 1389 string), where: 1391 - scope is the CBOR byte string either specified in the 'scope' 1392 parameter above, if present, or as a default scope that the 1393 handler is expected to understand, if omitted. 1395 - N_S is the challenge received from the KDC in the 1396 'kdcchallenge' parameter of the 2.01 (Created) response to the 1397 Token Transfer Request (see Section 3.3), encoded as a CBOR 1398 byte string. 1400 - N_C is the nonce generated by the Client and specified in the 1401 'cnonce' parameter above, encoded as a CBOR byte string. 1403 An example of PoP input to compute 'client_cred_verify' using CBOR 1404 encoding is given in Figure 9. 1406 A possible type of PoP evidence is a signature, that the Client 1407 computes by using its own private key, whose corresponding public 1408 key is specified in the 'client_cred' parameter. Application 1409 profiles of this specification MUST specify the exact approaches 1410 used to compute the PoP evidence to include in 1411 'client_cred_verify', and MUST specify which of those approaches 1412 is used in which case (REQ14). 1414 If the token was not provided to the KDC through a Token Transfer 1415 Request (e.g., it is used directly to validate TLS instead), it is 1416 REQUIRED of the specific application profile to define how the 1417 challenge N_S is generated (REQ15). 1419 * 'pub_keys_repos', which can be present if the format of the 1420 Client's public key in the 'client_cred' parameter is a 1421 certificate. In such a case, this parameter has as value the URI 1422 of the certificate. This parameter is encoded as a CBOR text 1423 string. Alternative specific encodings of this parameter MAY be 1424 defined in applications of this specification (OPT6). 1426 * 'control_uri', with value a full URI, encoded as a CBOR text 1427 string. A default url-path is /ace-group/GROUPNAME/node, although 1428 implementations can use different ones instead. The URI MUST NOT 1429 have url-path ace-group/GROUPNAME. 1431 If 'control_uri' is specified in the Joining Request, the Client 1432 acts as a CoAP server and hosts a resource at this specific URI. 1433 The KDC MAY use this URI to send CoAP requests to the Client 1434 (acting as CoAP server in this exchange), for example for one-to- 1435 one provisioning of new group keying material when performing a 1436 group rekeying (see Section 4.8.1.1), or to inform the Client of 1437 its removal from the group Section 5. 1439 In particular, this resource is intended for communications 1440 concerning exclusively the group whose group name GROUPNAME is 1441 specified in the 'scope' parameter. If the KDC does not implement 1442 mechanisms using this resource for that group, it can ignore this 1443 parameter. Other additional functionalities of this resource MAY 1444 be defined in application profiles of this specifications (OPT7). 1446 scope, N_S, and N_C expressed in CBOR diagnostic notation: 1447 scope = h'826667726F7570316673656E646572' 1448 N_S = h'018a278f7faab55a' 1449 N_C = h'25a8991cd700ac01' 1451 scope, N_S, and N_C as CBOR encoded byte strings: 1452 scope = 0x4f826667726F7570316673656E646572 1453 N_S = 0x48018a278f7faab55a 1454 N_C = 0x4825a8991cd700ac01 1456 PoP input: 1457 0x4f 826667726F7570316673656E646572 1458 48 018a278f7faab55a 48 25a8991cd700ac01 1460 Figure 9: Example of PoP input to compute 'client_cred_verify' 1461 using CBOR encoding 1463 If the request does not include a 'scope' field, the KDC is expected 1464 to understand with what roles the Client is requesting to join the 1465 group. For example, as per the access token, the Client might have 1466 been granted access to the group with only one role. If the KDC 1467 cannot determine which exact scope should be considered for the 1468 Client, it MUST reply with a 4.00 (Bad Request) error response. 1470 The handler considers the scope specified in the access token 1471 associated to the Client, and checks the scope entry related to the 1472 group with name GROUPNAME associated to the endpoint. In particular, 1473 the handler checks whether the set of roles specified in that scope 1474 entry includes all the roles that the Client wishes to have in the 1475 group as per the Joining Request. If this is not the case, the KDC 1476 MUST reply with a 4.03 (Forbidden) error response. 1478 If the KDC manages the group members' public keys, the handler checks 1479 if one is included in the 'client_cred' field. If so, the KDC 1480 retrieves the public key and performs the following actions. 1482 * If the access token was provided through a Token Transfer Request 1483 (see Section 3.3) but the KDC cannot retrieve the 'kdcchallenge' 1484 associated to this Client (see Section 3.3), the KDC MUST reply 1485 with a 4.00 Bad Request error response, which MUST also have 1486 Content-Format application/ace-groupcomm+cbor. The payload of the 1487 error response is a CBOR map including a newly generated 1488 'kdcchallenge' value. This is specified in the 'kdcchallenge' 1489 parameter. 1491 * The KDC checks the public key to be valid for the group identified 1492 by GROUPNAME. That is, it checks that the public key is encoded 1493 according to the format used in the group, is intended for the 1494 public key algorithm used in the group, and is aligned with the 1495 possible associated parameters used in the group. 1497 If this verification fails, the handler MUST reply with a 4.00 1498 (Bad Request) error response. The response MUST have Content- 1499 Format set to application/ace-groupcomm+cbor and is formatted as 1500 defined in Section 4. The value of the 'error' field MUST be set 1501 to 2 ("Public key incompatible with the group configuration"). 1503 * The KDC verifies the PoP evidence contained in the 1504 'client_cred_verify' field. Application profiles of this 1505 specification MUST specify the exact approaches used to verify the 1506 PoP evidence, and MUST specify which of those approaches is used 1507 in which case (REQ14). 1509 If the PoP evidence does not pass verification, the handler MUST 1510 reply with a 4.00 (Bad Request) error response. The response MUST 1511 have Content-Format set to application/ace-groupcomm+cbor and is 1512 formatted as defined in Section 4. The value of the 'error' field 1513 MUST be set to 3 ("Invalid Proof-of-Possession evidence"). 1515 If no public key is included in the 'client_cred' field, the handler 1516 checks if a public key is already associated to the received access 1517 token and to the group identified by GROUPNAME (see also 1518 Section 4.3.1.1). Note that the same joining node may use different 1519 public keys in different groups, and all those public keys would be 1520 associate to the same access token. 1522 If an eligible public key for the Client is neither present in the 1523 'client_cred' field nor retrieved from the stored ones at the KDC, it 1524 is RECOMMENDED that the handler stops the processing and replies with 1525 a 4.00 (Bad Request) error response. Applications profiles MAY 1526 define alternatives (OPT8). 1528 If, regardless the reason, the KDC replies with a 4.00 (Bad Request) 1529 error response, this response MAY have Content-Format set to 1530 application/ace-groupcomm+cbor and have a CBOR map as payload. For 1531 instance, the CBOR map can include a 'sign_info' parameter formatted 1532 as 'sign_info_res' defined in Section 3.3.1, with the 'pub_key_enc' 1533 element set to the CBOR simple value 'null' (0xf6) if the Client sent 1534 its own public key and the KDC is not set to store public keys of the 1535 group members. 1537 If all the verifications above succeed, the KDC proceeds as follows. 1539 First, only in case the Client is not already a group member, the 1540 handler performs the following actions: 1542 * The handler adds the Client to the list of current members of the 1543 group. 1545 * The handler assigns a name NODENAME to the Client, and creates a 1546 sub-resource to /ace-group/GROUPNAME at the KDC, i.e., "/ace- 1547 group/GROUPNAME/nodes/NODENAME". 1549 * The handler associates the node identifier NODENAME to the access 1550 token and the secure session for the Client. 1552 Then, the handler performs the following actions. 1554 * If the KDC manages the group members' public keys: 1556 - The handler associates the retrieved Client's public key to the 1557 tuple composed of the node name NODENAME, the group name 1558 GROUPNAME and the received access token. 1560 - The handler adds the retrieved Client's public key to the 1561 stored list of public keys stored for the group identified by 1562 GROUPNAME. If such list already includes a public key for the 1563 Client, but a different public key is specified in the 1564 'client_cred' field, then the handler MUST replace the old 1565 public key in the list with the one specified in the 1566 'client_cred' field. 1568 * If the application requires backward security or if the used 1569 application profile prescribes so, the KDC MUST generate new group 1570 keying material and securely distribute it to the current group 1571 members (see Section 6). 1573 * The handler returns a successful Joining Response as defined 1574 below, containing the symmetric group keying material; the group 1575 policies; and the public keys of the current members of the group, 1576 if the KDC manages those and the Client requested them. 1578 The Joining Response MUST have response code 2.01 (Created) if the 1579 Client has been added to the list of group members in this joining 1580 exchange (see above), or 2.04 (Changed) otherwise, i.e., if the 1581 Client is re-joining the group without having left it. 1583 The Joining Response message MUST include the Location-Path CoAP 1584 option, specifying the URI path to the sub-resource associated to the 1585 Client, i.e. "/ace-group/GROUPNAME/nodes/NODENAME". 1587 The Joining Response message MUST have Content-Format application/ 1588 ace-groupcomm+cbor. The payload of the response is formatted as a 1589 CBOR map, which MUST contain the following fields and values. 1591 * 'gkty', identifying the key type of the 'key' parameter. The set 1592 of values can be found in the "Key Type" column of the "ACE 1593 Groupcomm Key Types" registry. Implementations MUST verify that 1594 the key type matches the application profile being used, if 1595 present, as registered in the "ACE Groupcomm Key Types" registry. 1597 * 'key', containing the keying material for the group communication, 1598 or information required to derive it. 1600 * 'num', containing the version number of the keying material for 1601 the group communication, formatted as an integer. This is a 1602 strictly monotonic increasing field. The application profile MUST 1603 define the initial version number (REQ16). 1605 The exact format of the 'key' value MUST be defined in applications 1606 of this specification (REQ17), as well as values of 'gkty' accepted 1607 by the application (REQ18). Additionally, documents specifying the 1608 key format MUST register it in the "ACE Groupcomm Key Types" registry 1609 defined in Section 11.8, including its name, type and application 1610 profile to be used with. 1612 +----------+----------------+---------+-------------------------+ 1613 | Name | Key Type Value | Profile | Description | 1614 +----------+----------------+---------+-------------------------+ 1615 | Reserved | 0 | | This value is reserved | 1616 +----------+----------------+---------+-------------------------+ 1618 Figure 10: Key Type Values 1620 The response SHOULD contain the following parameter: 1622 * 'exp', with value the expiration time of the keying material for 1623 the group communication, encoded as a CBOR unsigned integer. This 1624 field contains a numeric value representing the number of seconds 1625 from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, 1626 ignoring leap seconds, analogous to what specified for NumericDate 1627 in Section 2 of [RFC7519]. Group members MUST stop using the 1628 keying material to protect outgoing messages and retrieve new 1629 keying material at the time indicated in this field. 1631 Optionally, the response MAY contain the following parameters, which, 1632 if included, MUST have format and value as specified below. 1634 * 'ace-groupcomm-profile', with value a CBOR integer that MUST be 1635 used to uniquely identify the application profile for group 1636 communication. Applications of this specification MUST register 1637 an application profile identifier and the related value for this 1638 parameter in the "ACE Groupcomm Profiles" registry (REQ19). 1640 * 'pub_keys', MUST be present if 'get_pub_keys' was present in the 1641 request, otherwise it MUST NOT be present. This parameter is a 1642 CBOR array specifying the public keys of the group members, i.e., 1643 of all of them or of the ones selected according to the 1644 'get_pub_keys' parameter in the request. In particular, each 1645 element of the array is a CBOR byte string, with value the 1646 original binary representation of a group member's public key. It 1647 is REQUIRED of the application profiles to define the specific 1648 formats of public keys that are acceptable to use in the group 1649 (REQ6). 1651 * 'peer_roles', MUST be present if 'pub_keys' is also present, 1652 otherwise it MUST NOT be present. This parameter is a CBOR array 1653 of n elements, with n the number of public keys included in the 1654 'pub_keys' parameter (at most the number of members in the group). 1655 The i-th element of the array specifies the role (or CBOR array of 1656 roles) that the group member associated to the i-th public key in 1657 'pub_keys' has in the group. In particular, each array element is 1658 encoded as the role element of a scope entry, as defined in 1659 Section 3.1. 1661 * 'peer_identifiers', MUST be present if 'pub_keys' is also present, 1662 otherwise it MUST NOT be present. This parameter is a CBOR array 1663 of n elements, with n the number of public keys included in the 1664 'pub_keys' parameter (at most the number of members in the group). 1665 The i-th element of the array specifies the node identifier that 1666 the group member associated to the i-th public key in 'pub_keys' 1667 has in the group. In particular, the i-th array element is 1668 encoded as a CBOR byte string, with value the node identifier of 1669 the group member. 1671 * 'group_policies', with value a CBOR map, whose entries specify how 1672 the group handles specific management aspects. These include, for 1673 instance, approaches to achieve synchronization of sequence 1674 numbers among group members. The elements of this field are 1675 registered in the "ACE Groupcomm Policies" registry. This 1676 specification defines the three elements "Sequence Number 1677 Synchronization Methods", "Key Update Check Interval" and 1678 "Expiration Delta", which are summarized in Figure 11. 1679 Application profiles that build on this document MUST specify the 1680 exact content format and default value of included map entries 1681 (REQ20). 1683 +--------------+-------+----------+----------------------+------------+ 1684 | Name | CBOR | CBOR | Description | Reference | 1685 | | label | type | | | 1686 +--------------+-------+----------+----------------------+------------+ 1687 | Sequence | TBD | tstr/int | Method for recipient | [[this | 1688 | Number | | | group members to | document]] | 1689 | Synchroniza- | | | synchronize with | | 1690 | tion Method | | | sequence numbers of | | 1691 | | | | of sender group | | 1692 | | | | members. Its value | | 1693 | | | | is taken from the | | 1694 | | | | 'Value' column of | | 1695 | | | | the Sequence Number | | 1696 | | | | Synchronization | | 1697 | | | | Method registry | | 1698 +--------------+-------+----------+----------------------+------------+ 1699 | Key Update | TBD | int | Polling interval in | [[this | 1700 | Check | | | seconds, for group | document]] | 1701 | Interval | | | members to check at | | 1702 | | | | the KDC if the | | 1703 | | | | latest group keying | | 1704 | | | | material is the one | | 1705 | | | | that they own | | 1706 +--------------+-------+----------+----------------------+------------+ 1707 | Expiration | TBD | uint | Number of seconds | [[this | 1708 | Delta | | | from 'exp' until the | document]] | 1709 | | | | specified UTC | | 1710 | | | | date/time after | | 1711 | | | | which group members | | 1712 | | | | MUST stop using the | | 1713 | | | | group keying | | 1714 | | | | material they own to | | 1715 | | | | verify incoming | | 1716 | | | | messages | | 1717 +--------------+-------+----------|----------------------|------------+ 1719 Figure 11: ACE Groupcomm Policies 1721 * 'kdc_cred', encoded as a CBOR byte string, with value the original 1722 binary representation of the KDC's public key. This parameter is 1723 used if the KDC has an associated public key and this is required 1724 for the correct group operation. It is REQUIRED of application 1725 profiles to define whether the KDC has a public key and if this 1726 has to be provided through the 'kdc_cred' parameter (REQ8). 1728 In such a case, the KDC's public key MUST have the same format 1729 used for the public keys of the group members. It is REQUIRED of 1730 the application profiles to define the specific formats that are 1731 acceptable to use for encoding public keys in the group (REQ6). 1733 * 'kdc_nonce', encoded as a CBOR byte string, and including a 1734 dedicated nonce N_KDC generated by the KDC. This parameter MUST 1735 be present if the 'kdc_cred' parameter is present. 1737 * 'kdc_cred_verify' parameter, encoded as a CBOR byte string. This 1738 parameter MUST be present if the 'kdc_cred' parameter is present. 1740 This parameter contains a proof-of-possession (PoP) evidence 1741 computed by the KDC over the nonce N_KDC, which is specified in 1742 the 'kdc_nonce' parameter and taken as PoP input. 1744 A possible type of PoP evidence is a signature, that the KDC 1745 computes by using its own private key, whose corresponding public 1746 key is specified in the 'kdc_cred' parameter. Application 1747 profiles of this specification MUST specify the exact approaches 1748 used by the KDC to compute the PoP evidence to include in 1749 'kdc_cred_verify', and MUST specify which of those approaches is 1750 used in which case (REQ21). 1752 * 'rekeying_scheme', identifying the rekeying scheme that the KDC 1753 uses to provide new group keying meterial to the group members. 1754 This parameter is encoded as a CBOR integer, whose value is taken 1755 from the "Value" column of the "ACE Groupcomm Rekeying Schemes" 1756 registry defined in Section 11.14 of this specification. 1758 +-------+----------------+-------------------------------+-----------+ 1759 | Value | Name | Description | Reference | 1760 +-------+----------------+-------------------------------+-----------+ 1761 | 0 | Point-to-Point | The KDC individually targets | [this | 1762 | | | each node to rekey, using the | document] | 1763 | | | pairwise secure communication | | 1764 | | | association with that node | | 1765 +-------+----------------+-------------------------------+-----------+ 1767 Figure 12: ACE Groupcomm Rekeying Schemes 1769 Application profiles of this specification MAY define a default group 1770 rekeying scheme, to refer to in case the 'rekeying_scheme' parameter 1771 is not included in the Joining Response (OPT9). 1773 * 'mgt_key_material', encoded as a CBOR byte string and containing 1774 the specific administrative keying material that the joining node 1775 requires in order to participate in the group rekeying process 1776 performed by the KDC. This parameter MUST NOT be present if the 1777 'rekeying_scheme' parameter is not present and the application 1778 profile does not specify a default group rekeying scheme to use in 1779 the group. Some simple rekeying scheme may not require specific 1780 administrative keying material to be provided, e.g., the basic 1781 "Point-to-Point" group rekeying scheme (see Section 6.1). 1783 In more advanced group rekeying schemes, the administrative keying 1784 material can be composed of multiple keys organized, for instance, 1785 into a logical tree hierarchy, whose root key is the only 1786 administrative key shared by all the group members. In such a 1787 case, each group member is exclusively associated to one leaf key 1788 in the hierarchy, and owns only the administrative keys from the 1789 associated leaf key all the way up along the path to the root key. 1790 That is, different group members can be provided with a different 1791 subset of the overall administrative keying material. 1793 It is expected from separate documents to define how the advanced 1794 group rekeying scheme possibly indicated in the 'rekeying_scheme' 1795 parameter is used by an application profile of this specification. 1796 This includes defining the format of the administrative keying 1797 material to specify in 'mgt_key_material', consistently with the 1798 group rekeying scheme and the application profile in question. 1800 * 'control_group_uri', with value a full URI, encoded as a CBOR text 1801 string. The URI MUST specify addressing information intended to 1802 reach all the members in the group. For example, this can be a 1803 multicast IP address, optionally together with a port number 1804 (which defaults to 5683 if omitted). The URI MUST include 1805 GROUPNAME in the url-path. A default url-path is /ace-group/ 1806 GROUPNAME, although implementations can use different ones 1807 instead. The URI MUST NOT have url-path ace-group/GROUPNAME/node. 1809 If 'control_group_uri' is included in the Joining Response, the 1810 Clients supporting this parameter act as CoAP servers, host a 1811 resource at this specific URI, and listen to the specified 1812 addressing information. 1814 The KDC MAY use this URI to send one-to-many CoAP requests to the 1815 Client group members (acting as CoAP servers in this exchange), 1816 for example for one-to-many provisioning of new group keying 1817 material when performing a group rekeying (see Section 4.8.1.1), 1818 or to inform the Clients of their removal from the group 1819 Section 5. 1821 In particular, this resource is intended for communications 1822 concerning exclusively the group whose group name GROUPNAME is 1823 specified in the 'scope' parameter. If the KDC does not implement 1824 mechanisms using this resource for that group, it can ignore this 1825 parameter. Other additional functionalities of this resource MAY 1826 be defined in application profiles of this specifications (OPT10). 1828 If the Joining Response includes the 'kdc_cred_verify' parameter, the 1829 Client verifies the conveyed PoP evidence and considers the group 1830 joining unsuccessful in case of failed verification. Application 1831 profiles of this specification MUST specify the exact approaches used 1832 by the Client to verify the PoP evidence in 'kdc_cred_verify', and 1833 MUST specify which of those approaches is used in which case (REQ21). 1835 Specific application profiles that build on this document MUST 1836 specify the communication protocol that members of the group use to 1837 communicate with each other (REQ22) and how exactly the keying 1838 material is used to protect the group communication (REQ23). 1840 4.3.1.1. Join the Group 1842 Figure 13 gives an overview of the Joining exchange between Client 1843 and KDC, when the Client first joins a group, while Figure 14 shows 1844 an example. 1846 Client KDC 1847 | | 1848 |----- Joining Request: POST /ace-group/GROUPNAME ------>| 1849 | | 1850 |<--------- Joining Response: 2.01 (Created) ----------- | 1851 | Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME" | 1853 Figure 13: Message Flow of the Joining Exchange 1855 Request: 1857 Header: POST (Code=0.02) 1858 Uri-Host: "kdc.example.com" 1859 Uri-Path: "ace-group" 1860 Uri-Path: "g1" 1861 Content-Format: "application/ace-groupcomm+cbor" 1862 Payload (in CBOR diagnostic notation, 1863 with PUB_KEY and POP_EVIDENCE being CBOR byte strings): 1864 { "scope": << [ "group1", ["sender", "receiver"] ] >> , 1865 "get_pub_keys": [true, ["sender"], []], "client_cred": PUB_KEY, 1866 "cnonce": h'6df49c495409a9b5', "client_cred_verify": POP_EVIDENCE } 1868 Response: 1870 Header: Created (Code=2.01) 1871 Content-Format: "application/ace-groupcomm+cbor" 1872 Location-Path: "kdc.example.com" 1873 Location-Path: "g1" 1874 Location-Path: "nodes" 1875 Location-Path: "c101" 1876 Payload (in CBOR diagnostic notation, 1877 with KEY being a CBOR byte strings): 1878 { "gkty": 13, "key": KEY, "num": 12, "exp": 1609459200, 1879 "pub_keys": [ PUB_KEY1, PUB_KEY2 ], 1880 "peer_roles": ["sender", ["sender", "receiver"]], 1881 "peer_identifiers": [ ID1, ID2 ] } 1883 Figure 14: Example of First Exchange for Group Joining 1885 If not previously established, the Client and the KDC MUST first 1886 establish a pairwise secure communication channel (REQ24). This can 1887 be achieved, for instance, by using a transport profile of ACE. The 1888 Joining exchange MUST occur over that secure channel. The Client and 1889 the KDC MAY use that same secure channel to protect further pairwise 1890 communications that must be secured. 1892 The secure communication protocol is REQUIRED to establish the secure 1893 channel between Client and KDC by using the proof-of-possession key 1894 bound to the access token. As a result, the proof-of-possession to 1895 bind the access token to the Client is performed by using the proof- 1896 of-possession key bound to the access token for establishing secure 1897 communication between the Client and the KDC. 1899 To join the group, the Client sends a CoAP POST request to the /ace- 1900 group/GROUPNAME endpoint at the KDC, where GROUPNAME is the group 1901 name of the group to join, formatted as specified in Section 4.3.1. 1902 This group name is the same as in the scope entry corresponding to 1903 that group, specified in the 'scope' parameter of the Authorization 1904 Request/Response, or it can be retrieved from it. Note that, in case 1905 of successful joining, the Client will receive the URI to retrieve 1906 individual keying material and to leave the group in the Location- 1907 Path option of the response. 1909 If the node is joining a group for the first time, and the KDC 1910 maintains the public keys of the group members, the Client is 1911 REQUIRED to send its own public key and proof-of-possession (PoP) 1912 evidence in the Joining Request (see the 'client_cred' and 1913 'client_cred_verify' parameters in Section 4.3.1). The request is 1914 accepted only if both public key is provided and the PoP evidence is 1915 successfully verified. 1917 If a node re-joins a group as authorized by the same access token and 1918 using the same public key, it can omit the public key and the PoP 1919 evidence, or just the PoP evidence, from the Joining Request. Then, 1920 the KDC will be able to retrieve the node's public key associated to 1921 the access token for that group. If the public key has been 1922 discarded, the KDC replies with 4.00 (Bad Request) error response, as 1923 specified in Section 4.3.1. If a node re-joins a group but wants to 1924 update its own public key, it needs to include both its public key 1925 and the PoP evidence in the Joining Request like when it joined the 1926 group for the first time. 1928 4.3.2. GET Handler 1930 The GET handler returns the symmetric group keying material for the 1931 group identified by GROUPNAME. 1933 The handler expects a GET request. 1935 In addition to what is defined in Section 4.1.2, the handler verifies 1936 that the Client is a current member of the group. If the 1937 verification fails, the KDC MUST reply with a 4.03 (Forbidden) error 1938 response. The response MUST have Content-Format set to application/ 1939 ace-groupcomm+cbor and is formatted as defined in Section 4. The 1940 value of the 'error' field MUST be set to 0 ("Operation permitted 1941 only to group members"). 1943 If all verifications succeed, the handler replies with a 2.05 1944 (Content) response containing the symmetric group keying material. 1945 The payload of the response is formatted as a CBOR map which MUST 1946 contain the parameters 'gkty', 'key' and 'num' specified in 1947 Section 4.3.1. 1949 Each of the following parameters specified in Section 4.3.1 MUST also 1950 be included in the payload of the response, if they are included in 1951 the payload of the Joining Responses sent for the group: 1952 'rekeying_scheme', 'mgt_key_material'. 1954 The payload MAY also include the parameters 'ace-groupcomm-profile' 1955 and 'exp' parameters specified in Section 4.3.1. 1957 4.3.2.1. Retrieve Group Keying Material 1959 A node in the group can contact the KDC to retrieve the current group 1960 keying material, by sending a CoAP GET request to the /ace-group/ 1961 GROUPNAME endpoint at the KDC, where GROUPNAME is the group name. 1963 Figure 15 gives an overview of the Joining exchange between Client 1964 and KDC, when the Client first joins a group, while Figure 16 shows 1965 an example. 1967 Client KDC 1968 | | 1969 |----- Key Distribution Request: POST /ace-group/GROUPNAME ------>| 1970 | | 1971 |<----------- Key Distribution Response: 2.05 (Content) --------- | 1972 | | 1974 Figure 15: Message Flow of Key Distribution Request-Response 1976 Request: 1978 Header: GET (Code=0.01) 1979 Uri-Host: "kdc.example.com" 1980 Uri-Path: "ace-group" 1981 Uri-Path: "g1" 1982 Payload: - 1984 Response: 1986 Header: Content (Code=2.05) 1987 Content-Format: "application/ace-groupcomm+cbor" 1988 Payload (in CBOR diagnostic notation, 1989 with KEY being a CBOR byte strings): 1990 { "gkty": 13, "key": KEY, "num": 12 } 1992 Figure 16: Example of Key Distribution Request-Response 1994 4.4. /ace-group/GROUPNAME/pub-key 1996 This resource implements the GET and FETCH handlers. 1998 4.4.1. FETCH Handler 2000 The FETCH handler receives identifiers of group members for the group 2001 identified by GROUPNAME and returns the public keys of such group 2002 members. 2004 The handler expects a request with payload formatted as a CBOR map, 2005 that MUST contain the following field. 2007 * 'get_pub_keys', whose value is encoded as in Section 4.3.1 with 2008 the following modifications. 2010 - The arrays 'role_filter' and 'id_filter' MUST NOT both be 2011 empty, i.e., in CBOR diagnostic notation: [ bool, [ ], [ ] ]. 2012 If the 'get_pub_keys' parameter has such a format, the request 2013 MUST be considered malformed, and the KDC MUST reply with a 2014 4.00 (Bad Request) error response. 2016 Note that a group member can retrieve the public keys of all 2017 the current group members by sending a GET request to the same 2018 KDC resource instead (see Section 4.4.2.1). 2020 - The element 'inclusion_flag' encodes the CBOR simple value True 2021 if the third element 'id_filter' specifies an empty CBOR array, 2022 or if the Client wishes to receive the public keys of the nodes 2023 having their node identifier specified in 'id_filter' (i.e, 2024 selection by inclusive filtering). Instead, this element 2025 encodes the CBOR simple value False if the Client wishes to 2026 receive the public keys of the nodes not having the node 2027 identifiers specified in the third element 'id_filter' (i.e., 2028 selection by exclusive filtering). 2030 - The array 'role_filter' can be empty, if the Client does not 2031 wish to filter the requested public keys based on the roles of 2032 the group members. 2034 - The array 'id_filter' contains zero or more node identifiers of 2035 group members, for the group identified by GROUPNAME. The 2036 Client indicates that it wishes to receive the public keys of 2037 the nodes having or not having these node identifiers, in case 2038 the 'inclusion_flag' element encodes the CBOR simple value True 2039 or False, respectively. The array 'id_filter' may be empty, if 2040 the Client does not wish to filter the requested public keys 2041 based on the node identifiers of the group members. 2043 Note that, in case the 'role_filter' array and the 'id_filter' array 2044 are both non-empty: 2046 * If the 'inclusion_flag' encodes the CBOR simple value True, the 2047 handler returns the public keys of group members whose roles match 2048 with 'role_filter' and/or having their node identifier specified 2049 in 'id_filter'. 2051 * If the 'inclusion_flag' encodes the CBOR simple value False, the 2052 handler returns the public keys of group members whose roles match 2053 with 'role_filter' and, at the same time, not having their node 2054 identifier specified in 'id_filter'. 2056 The specific format of public keys as well as identifiers, roles and 2057 combination of roles of group members MUST be specified by It is 2058 REQUIRED of application profiles of this specification (REQ1, REQ6, 2059 REQ25). 2061 The handler identifies the public keys of the current group members 2062 for which either: 2064 * the role identifier matches with one of those indicated in the 2065 request; note that the request can contain a "combination of 2066 roles", where the handler select all group members who have all 2067 roles included in the combination. 2069 * the node identifier matches with one of those indicated in the 2070 request. 2072 If all verifications succeed, the handler returns a 2.05 (Content) 2073 message response with payload formatted as a CBOR map, containing 2074 only the following parameters from Section 4.3.1. 2076 * 'num', which encodes the version number of the current group 2077 keying material. 2079 * 'pub_keys', which encodes the list of public keys of the selected 2080 group members. 2082 * 'peer_roles', which encodes the role (or CBOR array of roles) that 2083 each of the selected group members has in the group. 2085 * 'peer_identifiers', which encodes the node identifier that each of 2086 the selected group members has in the group. 2088 The specific format of public keys as well as of node identifiers of 2089 group members is specified by the application profile (REQ6, REQ25). 2091 If the KDC does not store any public key associated to the specified 2092 node identifiers, the handler returns a response with payload 2093 formatted as a CBOR byte string of zero length. 2095 The handler MAY enforce one of the following policies, in order to 2096 handle possible node identifiers that are included in the 'id_filter' 2097 element of the 'get_pub_keys' parameter of the request but are not 2098 associated to any current group member. Such a policy MUST be 2099 specified by the application profile (REQ26). 2101 * The KDC silently ignores those node identifiers. 2103 * The KDC retains public keys of group members for a given amount of 2104 time after their leaving, before discarding them. As long as such 2105 public keys are retained, the KDC provides them to a requesting 2106 Client. 2108 If the KDC adopts this policy, the application profile MUST also 2109 specify the amount of time during which the KDC retains the public 2110 key of a former group member after its leaving, possibly on a per- 2111 member basis. 2113 Note that this resource handler only verifies that the node is 2114 authorized by the AS to access this resource. Nodes that are not 2115 members of the group but are authorized to do signature verifications 2116 on the group messages may be allowed to access this resource, if the 2117 application needs it. 2119 4.4.1.1. Retrieve a Subset of Public Keys in the Group 2121 In case the KDC maintains the public keys of group members, a node in 2122 the group can contact the KDC to request the public keys, roles and 2123 node identifiers of a specified subset of group members, by sending a 2124 CoAP FETCH request to the /ace-group/GROUPNAME/pub-key endpoint at 2125 the KDC, where GROUPNAME is the group name, and formatted as defined 2126 in Section 4.4.1. 2128 Figure 17 gives an overview of the exchange mentioned above, while 2129 Figure 18 shows an example of such an exchange. 2131 Client KDC 2132 | | 2133 |-Public Key Request: FETCH /ace-group/GROUPNAME/pub-key->| 2134 | | 2135 |<--------- Public Key Response: 2.05 (Created) ----------| 2136 | | 2138 Figure 17: Message Flow of Public Key Exchange to Request the 2139 Public Keys of Specific Group Members 2141 Request: 2143 Header: FETCH (Code=0.05) 2144 Uri-Host: "kdc.example.com" 2145 Uri-Path: "ace-group" 2146 Uri-Path: "g1" 2147 Uri-Path: "pub-key" 2148 Content-Format: "application/ace-groupcomm+cbor" 2149 Payload: 2150 { "get_pub_keys": [true, [], [ ID3 ]] } 2152 Response: 2154 Header: Content (Code=2.05) 2155 Content-Format: "application/ace-groupcomm+cbor" 2156 Payload (in CBOR diagnostic notation): 2157 { "pub_keys": [ PUB_KEY3 ], 2158 "peer_roles": [ "receiver" ], 2159 "peer_identifiers": [ ID3 ] } 2161 Figure 18: Example of Public Key Exchange to Request the Public 2162 Keys of Specific Group Members 2164 4.4.2. GET Handler 2166 The handler expects a GET request. 2168 If all verifications succeed, the KDC replies with a 2.05 (Content) 2169 response as in the FETCH handler in Section 4.4.1, but specifying in 2170 the payload the public keys of all the group members, together with 2171 their roles and node identifiers. 2173 4.4.2.1. Retrieve All Public Keys in the Group 2175 In case the KDC maintains the public keys of group members, a group 2176 or an external signature verifier can contact the KDC to request the 2177 public keys, roles and node identifiers of all the current group 2178 members, by sending a CoAP GET request to the /ace-group/GROUPNAME/ 2179 pub-key endpoint at the KDC, where GROUPNAME is the group name. 2181 Figure 19 gives an overview of the message exchange, while Figure 20 2182 shows an example of such an exchange. 2184 Client KDC 2185 | | 2186 |--Public Key Request: GET /ace-group/GROUPNAME/pub-key->| 2187 | | 2188 |<--------- Public Key Response: 2.05 (Content) ---------| 2189 | | 2191 Figure 19: Message Flow of Public Key Exchange to Request the 2192 Public Keys of all the Group Members 2194 Request: 2196 Header: GET (Code=0.01) 2197 Uri-Host: "kdc.example.com" 2198 Uri-Path: "ace-group" 2199 Uri-Path: "g1" 2200 Uri-Path: "pub-key" 2201 Payload: - 2203 Response: 2205 Header: Content (Code=2.05) 2206 Content-Format: "application/ace-groupcomm+cbor" 2207 Payload (in CBOR diagnostic notation): 2208 { "num": 5, 2209 "pub_keys": [ PUB_KEY1, PUB_KEY2, PUB_KEY3 ], 2210 "peer_roles": ["sender", ["sender", "receiver"], "receiver"], 2211 "peer_identifiers": [ ID1, ID2, ID3 ] } 2213 Figure 20: Example of Public Key Exchange to Request the Public 2214 Keys of all the Group Members 2216 4.5. ace-group/GROUPNAME/kdc-pub-key 2218 This resource implements a GET handler. 2220 4.5.1. GET Handler 2222 The handler expects a GET request. 2224 If all verifications succeed, the handler returns a 2.05 (Content) 2225 message containing the KDC's public key together with a proof-of- 2226 possession (PoP) evidence. The response MUST have Content-Format set 2227 to application/ace-groupcomm+cbor. The payload of the response is a 2228 CBOR map, which includes the following fields. 2230 * The 'kdc_cred' parameter, specifying the KDC's public key. This 2231 parameter is encoded like the 'kdc_cred' parameter in the Joining 2232 Response (see Section 4.3.1). 2234 * The 'kdc_nonce' parameter, specifying a nonce generated by the 2235 KDC. This parameter is encoded like the 'kdc_nonce' parameter in 2236 the Joining Response (see Section 4.3.1). 2238 * The 'kdc_cred_verify' parameter, specifying a PoP evidence 2239 computed by the KDC. This parameter is encoded like the 2240 'kdc_cred_verify' parameter in the Joining Response (see 2241 Section 4.3.1). 2243 The PoP evidence is computed over the nonce specified in the 2244 'kdc_nonce' parameter and taken as PoP input, by means of the same 2245 method used when preparing the Joining Response (see 2246 Section 4.3.1). Application profiles of this specification MUST 2247 specify the exact approaches used by the KDC to compute the PoP 2248 evidence to include in 'kdc_cred_verify', and MUST specify which 2249 of those approaches is used in which case (REQ21). 2251 4.5.1.1. Retrieve the KDC's Public Key 2253 In case the KDC has an associated public key as required for the 2254 correct group operation, a group member or an external signature 2255 verifier can contact the KDC to request the KDC's public key, by 2256 sending a CoAP GET request to the /ace-group/GROUPNAME/kdc-pub-key 2257 endpoint at the KDC, where GROUPNAME is the group name. 2259 Upon receiving the 2.05 (Content) response, the Client retrieves the 2260 KDC's public key from the 'kdc_cred' parameter, and MUST verify the 2261 proof-of-possession (PoP) evidence specified in the 'kdc_cred_verify' 2262 parameter. In case of successful verification of the PoP evidence, 2263 the Client MUST store the obtained KDC's public key and replace the 2264 currently stored one. 2266 The PoP evidence is verified by means of the same method used when 2267 processing the Joining Response (see Section 4.3.1). Application 2268 profiles of this specification MUST specify the exact approaches used 2269 by the Client to verify the PoP evidence in 'kdc_cred_verify', and 2270 MUST specify which of those approaches is used in which case (REQ21). 2272 Figure 21 gives an overview of the exchange described above, while 2273 Figure 22 shows an example. 2275 Group 2276 Member KDC 2277 | | 2278 | KDC Public Key Request | 2279 |------------------------------------------------------------>| 2280 | GET ace-group/GROUPNAME/gm-pub-key | 2281 | | 2282 |<--------- KDC Public Key Response: 2.05 (Content) ----------| 2283 | | 2285 Figure 21: Message Flow of KDC Public Key Request-Response 2287 Request: 2289 Header: GET (Code=0.01) 2290 Uri-Host: "kdc.example.com" 2291 Uri-Path: "ace-group" 2292 Uri-Path: "g1" 2293 Uri-Path: "kdc-pub-key" 2294 Payload: - 2296 Response: 2298 Header: Content (Code=2.05) 2299 Content-Format: "application/ace-groupcomm+cbor" 2300 Payload (in CBOR diagnostic notation, with PUB_KEY_KDC 2301 and POP_EVIDENCE being CBOR byte strings): 2302 { 2303 "kdc_nonce": h'25a8991cd700ac01', 2304 "kdc_cred": PUB_KEY_KDC, 2305 "kdc_cred_verify": POP_EVIDENCE 2306 } 2308 Figure 22: Example of KDC Public Key Request-Response 2310 4.6. /ace-group/GROUPNAME/policies 2312 This resource implements the GET handler. 2314 4.6.1. GET Handler 2316 The handler expects a GET request. 2318 In addition to what is defined in Section 4.1.2, the handler verifies 2319 that the Client is a current member of the group. If the 2320 verification fails, the KDC MUST reply with a 4.03 (Forbidden) error 2321 response. The response MUST have Content-Format set to application/ 2322 ace-groupcomm+cbor and is formatted as defined in Section 4. The 2323 value of the 'error' field MUST be set to 0 ("Operation permitted 2324 only to group members"). 2326 If all verifications succeed, the handler replies with a 2.05 2327 (Content) response containing the list of policies for the group 2328 identified by GROUPNAME. The payload of the response is formatted as 2329 a CBOR map including only the parameter 'group_policies' defined in 2330 Section 4.3.1 and specifying the current policies in the group. If 2331 the KDC does not store any policy, the payload is formatted as a 2332 zero-length CBOR byte string. 2334 The specific format and meaning of group policies MUST be specified 2335 in the application profile (REQ20). 2337 4.6.1.1. Retrieve the Group Policies 2339 A node in the group can contact the KDC to retrieve the current group 2340 policies, by sending a CoAP GET request to the /ace-group/GROUPNAME/ 2341 policies endpoint at the KDC, where GROUPNAME is the group name, and 2342 formatted as defined in Section 4.6.1 2344 Figure 23 gives an overview of the exchange described above, while 2345 Figure 24 shows an example. 2347 Client KDC 2348 | | 2349 |-Policies Request: GET ace-group/GROUPNAME/policies ->| 2350 | | 2351 |<--------- Policies Response: 2.05 (Content) ---------| 2352 | | 2354 Figure 23: Message Flow of Policies Request-Response 2356 Request: 2358 Header: GET (Code=0.01) 2359 Uri-Host: "kdc.example.com" 2360 Uri-Path: "ace-group" 2361 Uri-Path: "g1" 2362 Uri-Path: "policies" 2363 Payload: - 2365 Response: 2367 Header: Content (Code=2.05) 2368 Content-Format: "application/ace-groupcomm+cbor" 2369 Payload(in CBOR diagnostic notation): 2370 { "group_policies": {"exp-delta": 120} } 2372 Figure 24: Example of Policies Request-Response 2374 4.7. /ace-group/GROUPNAME/num 2376 This resource implements the GET handler. 2378 4.7.1. GET Handler 2380 The handler expects a GET request. 2382 In addition to what is defined in Section 4.1.2, the handler verifies 2383 that the Client is a current member of the group. If the 2384 verification fails, the KDC MUST reply with a 4.03 (Forbidden) error 2385 response. The response MUST have Content-Format set to application/ 2386 ace-groupcomm+cbor and is formatted as defined in Section 4. The 2387 value of the 'error' field MUST be set to 0 ("Operation permitted 2388 only to group members"). 2390 If all verifications succeed, the handler returns a 2.05 (Content) 2391 message containing an integer that represents the version number of 2392 the symmetric group keying material. This number is incremented on 2393 the KDC every time the KDC updates the symmetric group keying 2394 material, before the new keying material is distributed. This number 2395 is stored in persistent storage. 2397 The payload of the response is formatted as a CBOR integer. 2399 4.7.1.1. Retrieve the Keying Material Version 2401 A node in the group can contact the KDC to request information about 2402 the version number of the symmetric group keying material, by sending 2403 a CoAP GET request to the /ace-group/GROUPNAME/num endpoint at the 2404 KDC, where GROUPNAME is the group name, formatted as defined in 2405 Section 4.7.1. In particular, the version is incremented by the KDC 2406 every time the group keying material is renewed, before it's 2407 distributed to the group members. 2409 Figure 25 gives an overview of the exchange described above, while 2410 Figure 26 shows an example. 2412 Client KDC 2413 | | 2414 |---- Version Request: GET ace-group/GROUPNAME/num ---->| 2415 | | 2416 |<--------- Version Response: 2.05 (Content) -----------| 2417 | | 2419 Figure 25: Message Flow of Version Request-Response 2421 Request: 2423 Header: GET (Code=0.01) 2424 Uri-Host: "kdc.example.com" 2425 Uri-Path: "ace-group" 2426 Uri-Path: "g1" 2427 Uri-Path: "num" 2428 Payload: - 2430 Response: 2432 Header: Content (Code=2.05) 2433 Content-Format: "application/ace-groupcomm+cbor" 2434 Payload(in CBOR diagnostic notation): 2435 13 2437 Figure 26: Example of Version Request-Response 2439 4.8. /ace-group/GROUPNAME/nodes/NODENAME 2441 This resource implements the GET, PUT and DELETE handlers. 2443 In addition to what is defined in Section 4.1.2, each of the handlers 2444 performs the following two verifications. 2446 * The handler verifies that the Client is a current member of the 2447 group. If the verification fails, the KDC MUST reply with a 4.03 2448 (Forbidden) error response. The response MUST have Content-Format 2449 set to application/ace-groupcomm+cbor and is formatted as defined 2450 in Section 4. The value of the 'error' field MUST be set to 0 2451 ("Operation permitted only to group members"). 2453 * The handler verifies that the node name of the Client is equal to 2454 NODENAME used in the url-path. If the verification fails, the 2455 handler replies with a 4.03 (Forbidden) error response. 2457 4.8.1. GET Handler 2459 The handler expects a GET request. 2461 If all verifications succeed, the handler replies with a 2.05 2462 (Content) response containing both the group keying material and the 2463 individual keying material for the Client, or information enabling 2464 the Client to derive it. The payload of the response is formatted as 2465 a CBOR map. The format for the group keying material is the same as 2466 defined in the response of Section 4.3.2. The specific format of 2467 individual keying material for group members, or of the information 2468 to derive it, and corresponding CBOR label, MUST be specified in the 2469 application profile (REQ27) and registered in Section 11.7. 2471 Optionally, the KDC can make the sub-resource at ace- 2472 group/GROUPNAME/nodes/NODENAME also Observable [RFC7641] for the 2473 associated node. In case the KDC removes that node from the group 2474 without having been explicitly asked for it, this allows the KDC to 2475 send an unsolicited 4.04 (Not Found) response to the node as a 2476 notification of eviction from the group (see Section 5). 2478 Note that the node could have been observing also the resource at 2479 ace-group/GROUPNAME, in order to be informed of changes in the keying 2480 material. In such a case, this method would result in largely 2481 overlapping notifications received for the resource at ace-group/ 2482 GROUPNAME and the sub-resource at ace-group/GROUPNAME/nodes/NODENAME. 2484 In order to mitigate this, a node that supports the No-Response 2485 option [RFC7967] can use it when starting the observation of the sub- 2486 resource at ace-group/GROUPNAME/nodes/NODENAME. In particular, the 2487 GET observation request can also include the No-Response option, with 2488 value set to 2 (Not interested in 2.xx responses). 2490 4.8.1.1. Retrieve Group and Individual Keying Material 2492 When any of the following happens, a node MUST stop using the owned 2493 group keying material to protect outgoing messages, and SHOULD stop 2494 using it to decrypt and verify incoming messages. 2496 * Upon expiration of the keying material, according to what 2497 indicated by the KDC with the 'exp' parameter in a Joining 2498 Response, or to a pre-configured value. 2500 * Upon receiving a notification of revoked/renewed keying material 2501 from the KDC, possibly as part of an update of the keying material 2502 (rekeying) triggered by the KDC. 2504 * Upon receiving messages from other group members without being 2505 able to retrieve the keying material to correctly decrypt them. 2506 This may be due to rekeying messages previously sent by the KDC, 2507 that the Client was not able to receive or decrypt. 2509 In either case, if it wants to continue participating in the group 2510 communication, the node has to request the latest keying material 2511 from the KDC. To this end, the Client sends a CoAP GET request to 2512 the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, 2513 formatted as specified in Section 4.8.1. 2515 Note that policies can be set up, so that the Client sends a Key Re- 2516 Distribution request to the KDC only after a given number of received 2517 messages could not be decrypted (because of failed decryption 2518 processing or inability to retrieve the necessary keying material). 2520 It is application dependent and pertaining to the particular message 2521 exchange (e.g., [I-D.ietf-core-oscore-groupcomm]) to set up these 2522 policies for instructing Clients to retain incoming messages and for 2523 how long (OPT11). This allows Clients to possibly decrypt such 2524 messages after getting updated keying material, rather than just 2525 consider them non valid messages to discard right away. 2527 The same Key Distribution Request could also be sent by the Client 2528 without being triggered by a failed decryption of a message, if the 2529 Client wants to be sure that it has the latest group keying material. 2530 If that is the case, the Client will receive from the KDC the same 2531 group keying material it already has in memory. 2533 Figure 27 gives an overview of the exchange described above, while 2534 Figure 28 shows an example. 2536 Client KDC 2537 | | 2538 |------------------ Key Distribution Request: --------------->| 2539 | GET ace-group/GROUPNAME/nodes/NODENAME | 2540 | | 2541 |<-------- Key Distribution Response: 2.05 (Content) ---------| 2542 | | 2544 Figure 27: Message Flow of Key Distribution Request-Response 2546 Request: 2548 Header: GET (Code=0.01) 2549 Uri-Host: "kdc.example.com" 2550 Uri-Path: "ace-group" 2551 Uri-Path: "g1" 2552 Uri-Path: "nodes" 2553 Uri-Path: "c101" 2554 Payload: - 2556 Response: 2558 Header: Content (Code=2.05) 2559 Content-Format: "application/ace-groupcomm+cbor" 2560 Payload (in CBOR diagnostic notation, 2561 with KEY and IND_KEY being CBOR byte strings, 2562 and "ind-key" the profile-specified label 2563 for individual keying material): 2564 { "gkty": 13, "key": KEY, "num": 12, "ind-key": IND_KEY } 2566 Figure 28: Example of Key Distribution Request-Response 2568 4.8.2. PUT Handler 2570 The PUT handler processes requests from a Client that asks for new 2571 individual keying material, as required to process messages exchanged 2572 in the group. 2574 The handler expects a PUT request with empty payload. 2576 In addition to what is defined in Section 4.1.2 and at the beginning 2577 of Section 4.8, the handler verifies that this operation is 2578 consistent with the set of roles that the Client has in the group 2579 (REQ11). If the verification fails, the KDC MUST reply with a 4.00 2580 (Bad Request) error response. The response MUST have Content-Format 2581 set to application/ace-groupcomm+cbor and is formatted as defined in 2582 Section 4. The value of the 'error' field MUST be set to 1 ("Request 2583 inconsistent with the current roles"). 2585 If the KDC is currently not able to serve this request, i.e., to 2586 generate new individual keying material for the requesting Client, 2587 the KDC MUST reply with a 5.03 (Service Unavailable) error response. 2588 The response MUST have Content-Format set to application/ace- 2589 groupcomm+cbor and is formatted as defined in Section 4. The value 2590 of the 'error' field MUST be set to 4 ("No available node 2591 identifiers"). 2593 If all verifications succeed, the handler reply with a 2.05 (Content) 2594 response containing newly generated, individual keying material for 2595 the Client. The payload of the response is formatted as a CBOR map. 2596 The specific format of newly-generated individual keying material for 2597 group members, or of the information to derive it, and corresponding 2598 CBOR label, MUST be specified in the application profile (REQ27) and 2599 registered in Section 11.7. 2601 The typical successful outcome consists in replying with newly 2602 generated, individual keying material for the Client, as defined 2603 above. However, application profiles of this specification MAY also 2604 extend this handler in order to achieve different akin outcomes 2605 (OPT12), for instance: 2607 * Not providing the Client with newly generated, individual keying 2608 material, but rather rekeying the whole group, i.e., providing all 2609 the current group members with newly generated group keying 2610 material. 2612 * Both providing the Client with newly generated, individual keying 2613 material, as well as rekeying the whole group, i.e., providing all 2614 the current group members with newly generated group keying 2615 material. 2617 In either case, the handler may specify the new group keying material 2618 as part of the 2.05 (Content) response. 2620 Note that this handler is not intended to accommodate requests from a 2621 group member to trigger a group rekeying, whose scheduling and 2622 execution is an exclusive prerogative of the KDC. 2624 4.8.2.1. Request to Change Individual Keying Material 2626 A Client may ask the KDC for new, individual keying material. For 2627 instance, this can be due to the expiration of such individual keying 2628 material, or to the exhaustion of AEAD nonces, if an AEAD encryption 2629 algorithm is used for protecting communications in the group. An 2630 example of individual keying material can simply be an individual 2631 encryption key associated to the Client. Hence, the Client may ask 2632 for a new individual encryption key, or for new input material to 2633 derive it. 2635 To this end, the Client performs a Key Renewal Request/Response 2636 exchange with the KDC, i.e., it sends a CoAP PUT request to the /ace- 2637 group/GROUPNAME/nodes/NODENAME endpoint at the KDC, where GROUPNAME 2638 is the group name and NODENAME is its node name, and formatted as 2639 defined in Section 4.8.1. 2641 Figure 29 gives an overview of the exchange described above, while 2642 Figure 30 shows an example. 2644 Client KDC 2645 | | 2646 |------------------ Key Renewal Request: -------------->| 2647 | PUT ace-group/GROUPNAME/nodes/NODENAME | 2648 | | 2649 |<-------- Key Renewal Response: 2.05 (Content) --------| 2650 | | 2652 Figure 29: Message Flow of Key Renewal Request-Response 2654 Request: 2656 Header: PUT (Code=0.03) 2657 Uri-Host: "kdc.example.com" 2658 Uri-Path: "ace-group" 2659 Uri-Path: "g1" 2660 Uri-Path: "nodes" 2661 Uri-Path: "c101" 2662 Payload: - 2664 Response: 2666 Header: Content (Code=2.05) 2667 Content-Format: "application/ace-groupcomm+cbor" 2668 Payload (in CBOR diagnostic notation, with IND_KEY being 2669 a CBOR byte string, and "ind-key" the profile-specified 2670 label for individual keying material): 2671 { "ind-key": IND_KEY } 2672 Figure 30: Example of Key Renewal Request-Response 2674 Note the difference between the Key Renewal Request in this section 2675 and the Key Distribution Request in Section 4.8.1.1. The former asks 2676 the KDC for new individual keying material, while the latters asks 2677 the KDC for the current group keying material together with the 2678 current individual keying material. 2680 As discussed in Section 4.8.2, application profiles of this 2681 specification may define alternative outcomes for the Key Renewal 2682 Request-Response exchange (OPT12), where the provisioning of new 2683 individual keying material is replaced by or combined with the 2684 execution of a whole group rekeying. 2686 4.8.3. DELETE Handler 2688 The DELETE handler removes the node identified by NODENAME from the 2689 group identified by GROUPNAME. 2691 The handler expects a DELETE request with empty payload. 2693 In addition to what is defined in Section 4.1.2, the handler verifies 2694 that the Client is a current member of the group. If the 2695 verification fails, the KDC MUST reply with a 4.03 (Forbidden) error 2696 response. The response MUST have Content-Format set to application/ 2697 ace-groupcomm+cbor and is formatted as defined in Section 4. The 2698 value of the 'error' field MUST be set to 0 ("Operation permitted 2699 only to group members"). 2701 If all verification succeeds, the handler performs the actions 2702 defined in Section 5 and replies with a 2.02 (Deleted) response with 2703 empty payload. 2705 4.8.3.1. Leave the Group 2707 A Client can actively request to leave the group. In this case, the 2708 Client sends a CoAP DELETE request to the endpoint /ace- 2709 group/GROUPNAME/nodes/NODENAME at the KDC, where GROUPNAME is the 2710 group name and NODENAME is its node name, formatted as defined in 2711 Section 4.8.3 2713 Note that, after having left the group, the Client may wish to join 2714 it again. Then, as long as the Client is still authorized to join 2715 the group, i.e., the associated access token is still valid, the 2716 Client can request to re-join the group directly to the KDC (see 2717 Section 4.3.1.1), without having to retrieve a new access token from 2718 the AS. 2720 4.9. /ace-group/GROUPNAME/nodes/NODENAME/pub-key 2722 This resource implements the POST handler. 2724 4.9.1. POST Handler 2726 The POST handler is used to replace the stored public key of this 2727 Client (identified by NODENAME) with the one specified in the request 2728 at the KDC, for the group identified by GROUPNAME. 2730 The handler expects a POST request with payload as specified in 2731 Section 4.3.1, with the difference that it includes only the 2732 parameters 'client_cred', 'cnonce' and 'client_cred_verify'. In 2733 particular, the PoP evidence included in 'client_cred_verify' is 2734 computed in the same way considered in Section 4.3.1 and defined by 2735 the specific application profile (REQ14), with a newly generated N_C 2736 nonce and the previously received N_S. It is REQUIRED of the 2737 application profiles to define the specific formats of public keys 2738 that are acceptable to use in the group (REQ6). 2740 In addition to what is defined in Section 4.1.2 and at the beginning 2741 of Section 4.8, the handler verifies that this operation is 2742 consistent with the set of roles that the node has in the group. If 2743 the verification fails, the KDC MUST reply with a 4.00 (Bad Request) 2744 error response. The response MUST have Content-Format set to 2745 application/ace-groupcomm+cbor and is formatted as defined in 2746 Section 4. The value of the 'error' field MUST be set to 1 ("Request 2747 inconsistent with the current roles"). 2749 If the KDC cannot retrieve the 'kdcchallenge' associated to this 2750 Client (see Section 3.3), the KDC MUST reply with a 4.00 (Bad 2751 Request) error response, which MUST also have Content-Format 2752 application/ace-groupcomm+cbor. The payload of the error response is 2753 a CBOR map including a newly generated 'kdcchallenge' value. This is 2754 specified in the 'kdcchallenge' parameter. In such a case the KDC 2755 MUST store the newly generated value as the 'kdcchallenge' value 2756 associated to this Client, possibly replacing the currently stored 2757 value. 2759 Otherwise, the handler checks that the public key specified in the 2760 'client_cred' field is valid for the group identified by GROUPNAME. 2761 That is, the handler checks that the public key is encoded according 2762 to the format used in the group, is intended for the public key 2763 algorithm used in the group, and is aligned with the possible 2764 associated parameters used in the group. If that cannot be 2765 successfully verified, the handler MUST reply with a 4.00 (Bad 2766 Request) error response. The response MUST have Content-Format set 2767 to application/ace-groupcomm+cbor and is formatted as defined in 2768 Section 4. The value of the 'error' field MUST be set to 2 ("Public 2769 key incompatible with the group configuration"). 2771 Otherwise, the handler verifies the PoP evidence contained in the 2772 'client_cred_verify' field of the request, by using the public key 2773 specified in the 'client_cred' field, as well as the same way 2774 considered in Section 4.3.1 and defined by the specific application 2775 profile (REQ14). If the PoP evidence does not pass verification, the 2776 handler MUST reply with a 4.00 (Bad Request) error response. The 2777 response MUST have Content-Format set to application/ace- 2778 groupcomm+cbor and is formatted as defined in Section 4. The value 2779 of the 'error' field MUST be set to 3 ("Invalid Proof-of-Possession 2780 evidence"). 2782 If all verifications succeed, the handler performs the following 2783 actions. 2785 * The handler associates the public key from the 'client_cred' field 2786 of the request to the node identifier NODENAME and to the access 2787 token associated to the node identified by NODENAME. 2789 * In the stored list of group members' public keys for the group 2790 identified by GROUPNAME, the handler replaces the public key of 2791 the node identified by NODENAME with the public key specified in 2792 the 'client_cred' field of the request. 2794 Then, the handler replies with a 2.04 (Changed) response, which does 2795 not include a payload. 2797 4.9.1.1. Uploading a New Public Key 2799 In case the KDC maintains the public keys of group members, a node in 2800 the group can contact the KDC to upload a new public key to use in 2801 the group, and replace the currently stored one. 2803 To this end, the Client performs a Public Key Update Request/Response 2804 exchange with the KDC, i.e., it sends a CoAP POST request to the 2805 /ace-group/GROUPNAME/nodes/NODENAME/pub-key endpoint at the KDC, 2806 where GROUPNAME is the group name and NODENAME is its node name. 2808 The request is formatted as specified in Section 4.9.1. 2810 Figure Figure 31 gives an overview of the exchange described above, 2811 while Figure 32 shows an example. 2813 Client KDC 2814 | | 2815 |-------------- Public Key Update Request: ---------------------->| 2816 | POST ace-group/GROUPNAME/nodes/NODENAME/pub-key | 2817 | | 2818 |<------- Public Key Update Response: 2.04 (Changed) -------------| 2819 | | 2821 Figure 31: Message Flow of Public Key Update Request-Response 2823 Request: 2825 Header: POST (Code=0.02) 2826 Uri-Host: "kdc.example.com" 2827 Uri-Path: "ace-group" 2828 Uri-Path: "g1" 2829 Uri-Path: "nodes" 2830 Uri-Path: "c101" 2831 Uri-Path: "pub-key" 2832 Content-Format: "application/ace-groupcomm+cbor" 2833 Payload (in CBOR diagnostic notation, with PUB_KEY 2834 and POP_EVIDENCE being CBOR byte strings): 2835 { "client_cred": PUB_KEY, "cnonce": h'9ff7684414affcc8', 2836 "client_cred_verify": POP_EVIDENCE } 2838 Response: 2840 Header: Changed (Code=2.04) 2841 Payload: - 2843 Figure 32: Example of Public Key Update Request-Response 2845 Additionally, after updating its own public key, a group member MAY 2846 send a number of requests including an identifier of the updated 2847 public key, to notify other group members that they have to retrieve 2848 it. How this is done depends on the group communication protocol 2849 used, and therefore is application profile specific (OPT13). 2851 5. Removal of a Group Member 2853 A Client identified by NODENAME may be removed from a group 2854 identified by GROUPNAME where it is a member, due to the following 2855 reasons. 2857 1. The Client explicitly asks to leave the group, as defined in 2858 Section 4.8.3.1. 2860 2. The node has been found compromised or is suspected so. 2862 3. The Client's authorization to be a group member with the current 2863 roles is not valid anymore, i.e., the access token has expired or 2864 has been revoked. If the AS provides token introspection (see 2865 Section 5.9 of [I-D.ietf-ace-oauth-authz]), the KDC can 2866 optionally use it and check whether the Client is still 2867 authorized. 2869 In either case, the KDC performs the following actions. 2871 * The KDC removes the Client from the list of current members or the 2872 group. 2874 * In case of forced eviction, i.e., for cases 2 and 3 above, the KDC 2875 deletes the public key of the removed Client, if it acts as 2876 repository of public keys for group members. 2878 * If the removed Client is registered as an observer of the group- 2879 membership resource at ace-group/GROUPNAME, the KDC removes the 2880 Client from the list of observers of that resource. 2882 * If the sub-resource nodes/NODENAME was created for the removed 2883 Client, the KDC deletes that sub-resource. 2885 In case of forced eviction, i.e., for cases 2 and 3 above, the KDC 2886 MAY explicitly inform the removed Client, by means of the 2887 following methods. 2889 - If the evicted Client implements the 'control_uri' resource 2890 specified in Section 4.3.1, the KDC sends a DELETE request, 2891 targeting the URI specified in the 'control_uri' parameter of 2892 the Joining Request (see Section 4.3.1). 2894 - If the evicted Client is observing its associated sub-resource 2895 at ace-group/GROUPNAME/nodes/NODENAME (see Section 4.8.1), the 2896 KDC sends an unsolicited 4.04 (Not Found) error response, which 2897 does not include the Observe option and indicates that the 2898 observed resource has been deleted (see Section 3.2 of 2899 [RFC7641]). 2901 The response MUST have Content-Format set to application/ace- 2902 groupcomm+cbor and is formatted as defined in Section 4. The 2903 value of the 'error' field MUST be set to 5 ("Group membership 2904 terminated"). 2906 * If the application requires forward security or the used 2907 application profile requires so, the KDC MUST generate new group 2908 keying material and securely distribute it to all the current 2909 group members except the leaving node (see Section 6). 2911 6. Group Rekeying Process 2913 A group rekeying is started and driven by the KDC. The KDC is not 2914 intended to accommodate explicit requests from group members to 2915 trigger a group rekeying. That is, the scheduling and execution of a 2916 group rekeying is an exclusive prerogative of the KDC. Reasons that 2917 can trigger a group rekeying are a change in the group membership, 2918 the current group keying material approaching its expiration time, or 2919 a regularly scheduled update of the group keying material. 2921 The KDC MUST increment the version number NUM of the current keying 2922 material, before distributing the newly generated keying material 2923 with version number NUM+1 to the group. Once completed the group 2924 rekeying, the KDC MUST delete the old keying material and SHOULD 2925 store the newly distributed keying material in persistent storage. 2927 Distributing the new group keying material requires the KDC to send 2928 multiple rekeying messages to the group members. Depending on the 2929 rekeying scheme used in the group and the reason that has triggered 2930 the rekeying process, each rekeying message can be intended to one or 2931 multiple group members, hereafter referred to as target group 2932 members. The KDC MUST support at least the "Point-to-Point" group 2933 rekeying scheme in Section 6.1 and MAY support additional ones. 2935 Each rekeying message MUST have Content-Format set to application/ 2936 ace-groupcomm+cbor and its payload formatted as a CBOR map, which 2937 MUST include at least the information specified in the Key 2938 Distribution Response message (see Section 4.3.2), i.e., the 2939 parameters 'gkty', 'key' and 'num' defined in Section 4.3.1. The 2940 CBOR map MAY include the parameter 'exp', as well as the parameter 2941 'mgt_key_material' specifying new administrative keying material for 2942 the target group members, if relevant for the used rekeying scheme. 2944 A rekeying message may include additional information, depending on 2945 the rekeying scheme used in the group, the reason that has triggered 2946 the rekeying process and the specific target group members. In 2947 particular, if the group rekeying is performed due to one or multiple 2948 Clients that have joined the group and the KDC acts as repository of 2949 public keys of the group members, then a rekeying message MAY also 2950 include the public keys that those Clients use in the group, together 2951 with the roles and node identifier that the corresponding Client has 2952 in the group. It is RECOMMENDED to specify this information by means 2953 of the parameters 'pub_keys', 'peer_roles' and 'peer_identifiers', 2954 like done in the Joining Response message (see Section 4.3.1). 2956 The complete format of a rekeying message, including the encoding and 2957 content of the 'mgt_key_material' parameter, has to be defined in 2958 separate specifications aimed at profiling the used rekeying scheme 2959 in the context of the used application profile of this specification. 2960 As a particular case, an application profile of this specification 2961 MAY define additional information to include in rekeying messages for 2962 the "Point-to-Point" group rekeying scheme in Section 6.1 (OPT14). 2964 Consistently with the used group rekeying scheme, the actual delivery 2965 of rekeying messages can occur through different approaches, as 2966 discussed in the following. 2968 6.1. Point-to-Point Group Rekeying 2970 This approach consists in the KDC sending one individual rekeying 2971 message to each target group member. In particular, the rekeying 2972 message is protected by means of the security association between the 2973 KDC and the target group member in question, as per the used 2974 application profile of this specification and the used transport 2975 profile of ACE. 2977 This is the approach taken by the basic "Point-to-Point" group 2978 rekeying scheme, that the KDC can explicitly signal in the Joining 2979 Response (see Section 4.3.1), through the 'rekeying_scheme' parameter 2980 specifying the value 0. 2982 When taking this approach in the group identified by GROUPNAME, the 2983 KDC can practically deliver the rekeying messages to the target group 2984 members in different, co-existing ways. 2986 * The KDC SHOULD make the ace-group/GROUPNAME resource Observable 2987 [RFC7641]. Thus, upon performing a group rekeying, the KDC can 2988 distribute the new group keying material through individual 2989 notification responses sent to the target group members that are 2990 also observing that resource. 2992 In case the KDC deletes the group, this also allows the KDC to 2993 send an unsolicited 4.04 (Not Found) response to each observer 2994 group member, as a notification of group termination. The 2995 response MUST have Content-Format set to application/ace- 2996 groupcomm+cbor and is formatted as defined in Section 4. The 2997 value of the 'error' field MUST be set to 6 ("Group deleted"). 2999 * If a target group member specified a URI in the 'control_uri' 3000 parameter of the Joining Request upon joining the group (see 3001 Section 4.3.1), the KDC can provide that group member with the new 3002 group keying material by sending a unicast POST request to that 3003 URI. 3005 A Client that does not plan to observe the ace-group/GROUPNAME 3006 resource at the KDC SHOULD provide a URI in the 'control_uri' 3007 parameter of the Joining Request upon joining the group. 3009 If the KDC has to send a rekeying message to a target group member, 3010 but this did not include the 'control_uri' parameter in the Joining 3011 Request and is not a registered observer for the ace-group/GROUPNAME 3012 resource, then that target group member would not be able to 3013 participate to the group rekeying. Later on, after having repeatedly 3014 failed to successfully exchange secure messages in the group, that 3015 group member can retrieve the current group keying material from the 3016 KDC, by sending a GET request to ace-group/GROUPNAME or ace- 3017 group/GROUPNAME/nodes/NODENAME (see Section 4.3.2 and Section 4.8.1, 3018 respectively). 3020 6.2. One-to-Many Group Rekeying 3022 This section provides high-level recommendations on how the KDC can 3023 rekey a group by means of a more efficient and scalable group 3024 rekeying scheme, e.g., [RFC2093][RFC2094][RFC2627]. That is, each 3025 rekeying message might be, and likely is, intended to multiple target 3026 group members, and thus can be delivered to the whole group, although 3027 possible to decrypt only for the actual target group members. 3029 This yields an overall lower number of rekeying messages, thus 3030 potentially reducing the overall time required to rekey the group. 3031 On the other hand, it requires the KDC to provide and use additional 3032 administrative keying material to protect the rekeying messages, and 3033 to additionally sign them to ensure source authentication (see 3034 Section 6.2.1). Typically, this pays off in large-scale groups, 3035 where the introduced performance overhead is less than what 3036 experienced by rekeying the group in a point-to-point fashion (see 3037 Section 6.1). 3039 The exact set of rekeying messages to send, their content and format, 3040 the administrative keying material to use to protect them, as well as 3041 the set of target group members depend on the specific group rekeying 3042 scheme, and are typically affected by the reason that has triggered 3043 the group rekeying. Details about the data content and format of 3044 rekeying messages have to be defined by separate documents profiling 3045 the use of the group rekeying scheme, in the context of the used 3046 application profile of this specification. 3048 When one of these group rekeying schemes is used, the KDC provides a 3049 number of related information to a Client joining the group in the 3050 Joining Response message (see Section 4.3.1). In particular, 3051 'rekeying_scheme' identifies the rekeying scheme used in the group 3052 (if no default can be assumed); 'control_group_uri', if present, 3053 specifies a URI with a multicast address where the KDC will send the 3054 rekeying messages for that group; 'mgt_key_material' specifies a 3055 subset of the administrative keying material intended for that 3056 particular joining Client to have, as used to protect the rekeying 3057 messages sent to the group when intended also to that joining Client. 3059 Rekeying messages can be protected at the application layer, by using 3060 COSE and the administrative keying material as prescribed by the 3061 specific group rekeying scheme (see Section 6.2.1). After that, the 3062 delivery of protected rekeying messages to the intended target group 3063 members can occur in different ways, such as the following ones. 3065 * Over multicast - In this case, the KDC simply sends a rekeying 3066 message as a CoAP request addressed to the multicast URI specified 3067 in the 'control_group_uri' parameter of the Joining Response (see 3068 Section 4.3.1). 3070 If a particular rekeying message is intended to a single target 3071 group member, the KDC may alternatively protect the message using 3072 the security association with that group member, and deliver the 3073 message like when using the "Point-to-Point" group rekeying scheme 3074 (see Section 6.1). 3076 * Through a pub-sub communication model - In this case, the KDC acts 3077 as publisher and publishes each rekeying message to a specific 3078 "rekeying topic", which is associated to the group and is hosted 3079 at a broker server. Following their group joining, the group 3080 members subscribe to the rekeying topic at the broker, thus 3081 receiving the group rekeying messages as they are published by the 3082 KDC. 3084 In order to make such message delivery more efficient, the 3085 rekeying topic associated to a group can be further organized into 3086 subtopics. For instance, the KDC can use a particular subtopic to 3087 address a particular set of target group members during the 3088 rekeying process, as possibly aligned to a similar organization of 3089 the administrative keying material (e.g., a key hierarchy). 3091 The setup of rekeying topics at the broker as well as the 3092 discovery of the topics at the broker for group members are 3093 application specific. A possible way is for the KDC to provide 3094 such information in the Joining Response message (see 3095 Section 4.3.1), by means of a new parameter analogous to 3096 'control_group_uri' and specifying the URI(s) of the rekeying 3097 topic(s) that a group member has to subscribe to at the broker. 3099 Regardless the specifically used delivery method, the group rekeying 3100 scheme can perform a possible roll-over of the administrative keying 3101 material through the same sent rekeying messages. Actually, such a 3102 roll-over occurs every time a group rekeying is performed upon the 3103 leaving of group members, which have to be excluded from future 3104 communications in the group. 3106 From a high level point of view, each group member owns only a subset 3107 of the overall administrative keying material, obtained upon joining 3108 the group. Then, when a group rekeying occurs: 3110 * Each rekeying message is protected by using a (most convenient) 3111 key from the administrative keying material such that: i) the used 3112 key is not owned by any node leaving the group, i.e. the key is 3113 safe to use and does not have to be renewed; and ii) the used key 3114 is owned by all the target group members, that indeed have to be 3115 provided with new group keying material to protect communications 3116 in the group. 3118 * Each rekeying message includes not only the new group keying 3119 material intended to all the rekeyed group members, but also any 3120 new administrative keys that: i) are pertaining to and supposed to 3121 be owned by the target group members; and ii) had to be updated 3122 since leaving group members own the previous version. 3124 Further details depend on the specific rekeying scheme used in the 3125 group. 3127 6.2.1. Protection of Rekeying Messages 3129 When using a group rekeying scheme relying on one-to-many rekeying 3130 messages, the actual data content of each rekeying message is 3131 prepared according to what the rekeying scheme prescribes. 3133 Then, the KDC can protect the rekeying message as defined below. The 3134 used encryption algorithm which SHOULD be the same one used to 3135 protect communications in the group. The method defined below 3136 assumes that the following holds for the management keying material 3137 specified in the 'mgt_key_material' parameter of the Joining Response 3138 (see Section 4.3.1). 3140 * The included symmetric encryption keys are accompanied by a 3141 corresponding and unique key identifier assigned by the KDC. 3143 * A Base IV is also included, with the same size of the AEAD nonce 3144 considered by the encryption algorithm to use. 3146 First, the KDC computes a COSE_Encrypt0 object as follows. 3148 * The encryption key to use is selected from the administrative 3149 keying material, as defined by the rekeying scheme used in the 3150 group. 3152 * The plaintext is the actual data content of the rekeying message. 3154 * The Additional Authenticated Data (AAD) is empty, unless otherwise 3155 specified by separate documents profiling the use of the group 3156 rekeying scheme. 3158 * Since the KDC is the only sender of rekeying messages, the AEAD 3159 nonce can be computed as follows, where NONCE_SIZE is the size in 3160 bytes of the AEAD nonce. Separate documents profiling the use of 3161 the group rekeying scheme may define alternative ways to compute 3162 the AEAD nonce. 3164 The KDC considers the following values. 3166 - COUNT, as a 1-byte unsigned integer associated to the used 3167 encryption key. Its value is set to 0 when starting to perform 3168 a new group rekeying instance, and is incremented after each 3169 use of the encryption key. 3171 - NEW_NUM, as the version number of the new group keying material 3172 to distribute in this rekeying instance, left-padded with 3173 zeroes to exactly NONCE_SIZE - 1. 3175 Then, the KDC computes a Partial IV as the byte string 3176 concatenation of COUNT and NEW_NUM, in this order. Finally, the 3177 AEAD nonce is computed as the XOR between the Base IV and the 3178 Partial IV. 3180 * The protected header of the COSE_Encrypt0 object MUST include the 3181 following parameters. 3183 - 'alg', specifying the used encryption algorithm. 3185 - 'kid', specifying the identifier of the encryption key from the 3186 administrative keying material used to protect this rekeying 3187 message. 3189 * The unprotected header of the COSE_Encrypt0 object MUST include 3190 the 'Partial IV' parameter, with value the Partial IV computed 3191 above. 3193 In order to ensure source authentication, each rekeying message 3194 protected with the administrative keying material MUST be signed by 3195 the KDC. To this end, the KDC computes a countersignature of the 3196 COSE_Encrypt0 object, as described in Sections 3.2 and 3.3 of 3197 [I-D.ietf-cose-countersign]. In particular, the following applies 3198 when computing the countersignature. 3200 * The Countersign_structure contains the context text string 3201 "CounterSignature0". 3203 * The private key of the KDC is used as signing key. 3205 * The payload is the ciphertext of the COSE_Encrypt0 object. 3207 * The Additional Authenticated Data (AAD) is empty, unless otherwise 3208 specified by separate documents profiling the use of a group 3209 rekeying scheme. 3211 * The protected header of the signing object MUST include the 3212 parameter 'alg', specifying the used signature algorithm. 3214 If source authentication of messages exchanged in the group is also 3215 ensured by means of signatures, then rekeying messages MUST be signed 3216 using the same signature algorithm and related parameters. Also, the 3217 KDC's public key used for signature verification MUST me provided in 3218 the Joining Response through the 'kdc_cred' parameter, together with 3219 the corresponding proof-of-possession (PoP) evidence in the 3220 'kdc_cred_verify' parameter. 3222 If source authentication of messages exchanged in the group is not 3223 ensured by means of signatures, then the KDC MUST provide its public 3224 key together with a corresponding PoP evidence as part of the 3225 management keying material specified in the 'mgt_key_material' 3226 parameter of the Joining Response (see Section 4.3.1). It is 3227 RECOMMENDED to specify this information by using the same format and 3228 encoding used for the parameters 'kdc_cred', 'kdc_nonce' and 3229 'kdc_cred_verify' in the Joining Response. It is up to separate 3230 documents profiling the use of the group rekeying scheme to specify 3231 such details. 3233 After that, the KDC specifies the computed countersignature in the 3234 'COSE_Countersignature0' header parameter of the COSE_Encrypt0 3235 object. 3237 Finally, the KDC specifies the COSE_Encrypt0 object as payload of a 3238 CoAP request, which is sent to the target group members as per the 3239 used message delivery method. 3241 7. Extended Scope Format 3243 This section defines an extended format of binary encoded scope, 3244 which additionally specifies the semantics used to express the same 3245 access control information from the corresponding original scope. 3247 As also discussed in Section 3.2, this enables a Resource Server to 3248 unambiguously process a received access token, also in case the 3249 Resource Server runs multiple applications or application profiles 3250 that involve different scope semantics. 3252 The extended format is intended only for the 'scope' claim of access 3253 tokens, for the cases where the claim takes as value a CBOR byte 3254 string. That is, the extended format does not apply to the 'scope' 3255 parameter included in ACE messages, i.e., the Authorization Request 3256 and Authorization Response exchanged between the Client and the 3257 Authorization Server (see Sections 5.8.1 and 5.8.2 of 3258 [I-D.ietf-ace-oauth-authz]), the AS Request Creation Hints message 3259 from the Resource Server (see Section 5.3 of 3260 [I-D.ietf-ace-oauth-authz]), and the Introspection Response from the 3261 Authorization Server (see Section 5.9.2 of 3262 [I-D.ietf-ace-oauth-authz]). 3264 The value of the 'scope' claim following the extended format is 3265 composed as follows. Given the original scope using a semantics SEM 3266 and encoded as a CBOR byte string, the corresponding extended scope 3267 is encoded as a tagged CBOR byte string, wrapping a CBOR sequence 3268 [RFC8742] of two elements. In particular: 3270 * The first element of the sequence is a CBOR integer, and 3271 identifies the semantics SEM used for this scope. The value of 3272 this element has to be taken from the "Value" column of the "ACE 3273 Scope Semantics" registry defined in Section 11.12 of this 3274 specification. 3276 When defining a new semantics for a binary scope, it is up to the 3277 applications and application profiles to define and register the 3278 corresponding integer identifier (REQ28). 3280 * The second element of the sequence is the original scope using the 3281 semantics SEM, encoded as a CBOR byte string. 3283 Finally, the CBOR byte string wrapping the CBOR sequence is tagged, 3284 and identified by the CBOR tag TBD_TAG "ACE Extended Scope Format", 3285 defined in Section 11.6 of this specification. 3287 The resulting tagged CBOR byte string is used as value of the 'scope' 3288 claim of the access token. 3290 The usage of the extended scope format is not limited to application 3291 profiles of this specification or to applications based on group 3292 communication. Rather, it is generally applicable to any application 3293 and application profile where access control information in the 3294 access token is expressed as a binary encoded scope. 3296 Figure 33 and Figure 34 build on the examples in Section 3.2, and 3297 show the corresponding extended scopes. 3299 gname = tstr 3301 permissions = uint . bits roles 3303 roles = &( 3304 Requester: 1, 3305 Responder: 2, 3306 Monitor: 3, 3307 Verifier: 4 3308 ) 3310 scope_entry = AIF_Generic 3312 scope = << [ + scope_entry ] >> 3314 semantics = int 3316 ; This defines an array, the elements 3317 ; of which are to be used in a CBOR Sequence: 3318 sequence = [semantics, scope] 3320 extended_scope = #6.TBD_TAG(<< sequence >>) 3322 Figure 33: Example CDLL definition of scope, using the default 3323 Authorization Information Format 3325 gname = tstr 3327 role = tstr 3329 scope_entry = [ gname , ? ( role / [ 2*role ] ) ] 3331 scope = << [ + scope_entry ] >> 3333 semantics = int 3335 ; This defines an array, the elements 3336 ; of which are to be used in a CBOR Sequence: 3337 sequence = [semantics, scope] 3339 extended_scope = #6.TBD_TAG(<< sequence >>) 3341 Figure 34: CDLL definition of scope, using as example group name 3342 encoded as tstr and role as tstr 3344 8. ACE Groupcomm Parameters 3346 This specification defines a number of parameters used during the 3347 second part of the message exchange, after the exchange of Token 3348 Transfer Request and Response. The table below summarizes them, and 3349 specifies the CBOR key to use instead of the full descriptive name. 3351 Note that the media type application/ace-groupcomm+cbor MUST be used 3352 when these parameters are transported in the respective message 3353 fields. 3355 +-----------------------+------+-----------------+-----------------+ 3356 | Name | CBOR | CBOR Type | Reference | 3357 | | Key | | | 3358 +-----------------------+------+-----------------+-----------------+ 3359 | error | TBD | int | [this document] | 3360 +-----------------------+------+-----------------+-----------------+ 3361 | error_description | TBD | tstr | [this document] | 3362 +-----------------------+------+-----------------+-----------------+ 3363 | gid | TBD | array | [this document] | 3364 +-----------------------+------+-----------------+-----------------+ 3365 | gname | TBD | array of tstr | [this document] | 3366 +-----------------------+------+-----------------+-----------------+ 3367 | guri | TBD | array of tstr | [this document] | 3368 +-----------------------+------+-----------------+-----------------+ 3369 | scope | TBD | bstr | [this document] | 3370 +-----------------------+------+-----------------+-----------------+ 3371 | get_pub_keys | TBD | array / nil | [this document] | 3372 +-----------------------+------+-----------------+-----------------+ 3373 | client_cred | TBD | bstr | [this document] | 3374 +-----------------------+------+-----------------+-----------------+ 3375 | cnonce | TBD | bstr | [this document] | 3376 +-----------------------+------+-----------------+-----------------+ 3377 | client_cred_verify | TBD | bstr | [this document] | 3378 +-----------------------+------+-----------------+-----------------+ 3379 | pub_keys_repos | TBD | tstr | [this document] | 3380 +-----------------------+------+-----------------+-----------------+ 3381 | control_uri | TBD | tstr | [this document] | 3382 +-----------------------+------+-----------------+-----------------+ 3383 | gkty | TBD | int / tstr | [this document] | 3384 +-----------------------+------+-----------------+-----------------+ 3385 | key | TBD | See the "ACE | [this document] | 3386 | | | Groupcomm Key | | 3387 | | | Types" registry | | 3388 +-----------------------+------+-----------------+-----------------+ 3389 | num | TBD | int | [this document] | 3390 +-----------------------+------+-----------------+-----------------+ 3391 | ace-groupcomm-profile | TBD | int | [this document] | 3392 +-----------------------+------+-----------------+-----------------+ 3393 | exp | TBD | int | [this document] | 3394 +-----------------------+------+-----------------+-----------------+ 3395 | pub_keys | TBD | array | [this document] | 3396 +-----------------------+------+-----------------+-----------------+ 3397 | peer_roles | TBD | array | [this document] | 3398 +-----------------------+------+-----------------+-----------------+ 3399 | peer_identifiers | TBD | array | [this document] | 3400 +-----------------------+------+-----------------+-----------------+ 3401 | group_policies | TBD | map | [this document] | 3402 +-----------------------+------+-----------------+-----------------+ 3403 | kdc_cred | TBD | bstr | [this document] | 3404 +-----------------------+------+-----------------+-----------------+ 3405 | kdc_nonce | TBD | bstr | [this document] | 3406 +-----------------------+------+-----------------+-----------------+ 3407 | kdc_cred_verify | TBD | bstr | [this document] | 3408 +-----------------------+------+-----------------+-----------------+ 3409 | rekeying_scheme | TBD | int | [this document] | 3410 +-----------------------+------+-----------------+-----------------+ 3411 | mgt_key_material | TBD | bstr | [this document] | 3412 +-----------------------+------+-----------------+-----------------+ 3413 | control_group_uri | TBD | tstr | [this document] | 3414 +-----------------------+------+-----------------+-----------------+ 3415 | sign_info | TBD | array | [this document] | 3416 +-----------------------+------+-----------------+-----------------+ 3417 | kdcchallenge | TBD | bstr | [this document] | 3418 +-----------------------+------+-----------------+-----------------+ 3420 Figure 35: ACE Groupcomm Parameters 3422 The KDC is expected to support and understand all the parameters 3423 above. Instead, a Client can support and understand only a subset of 3424 such parameters, depending on the roles it expects to take in the 3425 joined groups or on other conditions defined in application profiles 3426 of this specification. 3428 In the following, the parameters are categorized according to the 3429 support expected by Clients. That is, a Client that supports a 3430 parameter is able to: i) use and specify it in a request message to 3431 the KDC; and ii) understand and process it if specified in a response 3432 message from the KDC. It is REQUIRED of application profiles of this 3433 specification to sort their newly defined parameters according to the 3434 same categorization (REQ29). 3436 Note that the actual use of a parameter and its inclusion in a 3437 message depends on the specific exchange, the specific Client and 3438 group involved, as well as what is defined in the used application 3439 profile of this specification. 3441 A Client MUST support the following parameters. 3443 * 'scope', 'gkty', 'key', 'num', 'exp', 'gid', 'gname', 'guri', 3444 'pub_keys', 'peer_identifiers', 'ace_groupcomm_profile', 3445 'control_uri', 'rekeying_scheme'. 3447 A Client SHOULD support the following parameter. 3449 * 'get_pub_keys'. That is, not supporting this parameter would 3450 yield the inconvenient and undesirable behavior where: i) the 3451 Client does not ask for the other group members' public keys upon 3452 joining the group (see Section 4.3.1.1); and ii) later on as a 3453 group member, the Client only retrieves the public keys of all 3454 group members (see Section 4.4.2.1). 3456 A Client MAY support the following optional parameters. Application 3457 profiles of this specification MAY define that Clients must or should 3458 support these parameters instead (OPT15). 3460 * 'error', 'error_description'. 3462 The following conditional parameters are relevant only if specific 3463 conditions hold. It is REQUIRED of application profiles of this 3464 specification to define whether Clients must, should or may support 3465 these parameters, and under which circumstances (REQ30). 3467 * 'client_cred', 'cnonce', 'client_cred_verify'. These parameters 3468 are relevant for a Client that has a public key to use in a joined 3469 group. 3471 * 'kdcchallenge'. This parameter is relevant for a Client that has 3472 a public key to use in a joined group and that provides the access 3473 token to the KDC through a Token Transfer Request (see 3474 Section 3.3). 3476 * 'pub_keys'repo'. This parameter is relevant for a Client that has 3477 a public key to use in a joined group and that makes it available 3478 from a key repository different than the KDC. 3480 * 'group_policies'. This parameter is relevant for a Client that is 3481 interested in the specific policies used in a group, but it does 3482 not know them or cannot become aware of them before joining that 3483 group. 3485 * 'peer_roles'. This parameter is relevant for a Client that has to 3486 know about the roles of other group members, especially when 3487 retrieving and handling their corresponding public keys. 3489 * 'kdc_nonce', 'kdc_cred', 'kdc_cred_verify'. These parameters are 3490 relevant for a Client that joins a group for which, as per the 3491 used application profile of this specification, the KDC has an 3492 associated public key and this is required for the correct group 3493 operation. 3495 * 'mgt_key_material'. This parameter is relevant for a Client that 3496 supports an advanced rekeying scheme possibly used in the group, 3497 such as based on one-to-many rekeying messages sent over IP 3498 multicast. 3500 * 'control_group_uri'. This parameter is relevant for a Client that 3501 supports the hosting of local resources each associated to a group 3502 (hence acting as CoAP server) and the reception of one-to-many 3503 requests sent to those resources by the KDC (e.g., over IP 3504 multicast), targeting multiple members of the corresponding group. 3505 Examples of related management operations that the KDC can perform 3506 by this means are the eviction of group members and the execution 3507 of a group rekeying process through an advanced rekeying scheme, 3508 such as based on one-to-many rekeying messages. 3510 9. ACE Groupcomm Error Identifiers 3512 This specification defines a number of values that the KDC can 3513 include as error identifiers, in the 'error' field of an error 3514 response with Content-Format application/ace-groupcomm+cbor. 3516 +-------+------------------------------------------------------+ 3517 | Value | Description | 3518 +-------+------------------------------------------------------+ 3519 | 0 | Operation permitted only to group members | 3520 +-------+------------------------------------------------------+ 3521 | 1 | Request inconsistent with the current roles | 3522 +-------+------------------------------------------------------+ 3523 | 2 | Public key incompatible with the group configuration | 3524 +-------+------------------------------------------------------+ 3525 | 3 | Invalid proof-of-possession evidence | 3526 +-------+------------------------------------------------------+ 3527 | 4 | No available node identifiers | 3528 +-------+------------------------------------------------------+ 3529 | 5 | Group membership terminated | 3530 +-------+------------------------------------------------------+ 3531 | 6 | Group deleted | 3532 +-------+------------------------------------------------------+ 3534 Figure 36: ACE Groupcomm Error Identifiers 3536 A Client supporting the 'error' parameter (see Section 4.1.2 and 3537 Section 8) and able to understand the specified error may use that 3538 information to determine what actions to take next. If it is 3539 included in the error response and supported by the Client, the 3540 'error_description' parameter may provide additional context. 3542 In particular, the following guidelines apply, and application 3543 profiles of this specification can define more detailed actions for 3544 the Client to take when learning that a specific error has occurred. 3546 * In case of error 0, the Client should stop sending the request in 3547 question to the KDC. Rather, the Client should first join the 3548 targeted group. If it has not happened already, this first 3549 requires the Client to obtain an appropriate access token 3550 authorizing access to the group and provide it to the KDC. 3552 * In case of error 1, the Client as a group member should re-join 3553 the group with all the roles needed to perform the operation in 3554 question. This might require the Client to first obtain a new 3555 access token and provide it to the KDC, if the current access 3556 token does not authorize to take those roles in the group. For 3557 operations admitted to a Client which is not a group member (e.g., 3558 an external signature verifier), the Client should first obtain a 3559 new access token authorizing to also have the missing roles. 3561 * In case of error 2, the Client has to obtain or self-generate a 3562 different asymmetric key pair, as aligned to the publick key 3563 algorithms, parameters and encoding used in the targeted group. 3564 After that, the Client should provide its new consistent public 3565 key to the KDC. 3567 * In case of error 3, the Client should ensure to be computing its 3568 proof-of-possession evidence by correctly using the parameters and 3569 procedures defined in the used application profile of this 3570 specification. In an unattended setup, it might be not possible 3571 for a Client to autonomously diagnose the error and take an 3572 effective next action to address it. 3574 * In case of error 4, the Client should wait for a certain (pre- 3575 configured) amount of time, before trying re-sending its request 3576 to the KDC. 3578 * In case of error 5, the Client may try joining the group again. 3579 This might require the Client to first obtain a new access token 3580 and provide it to the KDC, e.g., if the current access token has 3581 expired. 3583 * In case of error 6, the Client should clean up its state regarding 3584 the group, just like if it has left the group with no intention to 3585 re-join it. 3587 10. Security Considerations 3589 Security considerations are inherited from the ACE framework 3590 [I-D.ietf-ace-oauth-authz], and from the specific transport profile 3591 of ACE used between the Clients and the KDC, e.g., 3592 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile]. 3594 Furthermore, the following security considerations apply. 3596 10.1. Secure Communication in the Group 3598 When a group member receives a message from a certain sender for the 3599 first time since joining the group, it needs to have a mechanism in 3600 place to avoid replayed messages, e.g., Appendix B.2 of [RFC8613] or 3601 Appendix E of [I-D.ietf-core-oscore-groupcomm]. Such a mechanism 3602 aids the recipient group member also in case it has rebooted and lost 3603 the security state used to protect previous group communications with 3604 that sender. 3606 By its nature, the KDC is invested with a large amount of trust, 3607 since it acts as generator and provider of the symmetric keying 3608 material used to protect communications in each of its groups. While 3609 details depend on the specific communication and security protocols 3610 used in the group, the KDC is in the position to decrypt messages 3611 exchanged in the group as if it was also a group member, as long as 3612 those are protected through commonly shared group keying material. 3614 A compromised KDC would thus put the attacker in the same position, 3615 which also means that: 3617 * The attacker can generate and control new group keying material, 3618 hence possibly rekeying the group and evicting certain group 3619 members as part of a broader attack. 3621 * The attacker can actively participate to communications in a group 3622 even without been authorized to join it, and can allow further 3623 unauthorized entities to do so. 3625 * The attacker can build erroneous associations between node 3626 identifiers and group members' public keys. 3628 On the other hand, as long as the security protocol used in the group 3629 ensures source authentication of messages (e.g., by means of 3630 signatures), the KDC is not able to impersonate group members since 3631 it does now own their private keys. 3633 Further security considerations are specific of the communication and 3634 security protocols used in the group, and thus have to be provided by 3635 those protocols and complemented by the application profiles of this 3636 specification using them. 3638 10.2. Update of Group Keying Material 3640 Due to different reasons, the KDC can generate new group keying 3641 material and provide it to the group members (rekeying) through the 3642 rekeying scheme used in the group, as discussed in Section 6. 3644 In particular, the KDC must renew the group keying material latest 3645 upon its expiration. Before then, the KDC may also renew the group 3646 keying material on a regular or periodical fashion. 3648 The KDC should renew the group keying material upon a group 3649 membership change. Since the minimum number of group members is one, 3650 the KDC should provide also a Client joining an empty group with new 3651 keying material never used before in that group. Similarly, the KDC 3652 should provide new group keying material also to a Client that 3653 remains the only member in the group after the leaving of other group 3654 members. 3656 Note that the considerations in Section 10.1 about dealing with 3657 replayed messages still hold, even in case the KDC rekeys the group 3658 upon every single joining of a new group member. However, if the KDC 3659 has renewed the group keying material upon a group member's joining, 3660 and the time interval between the end of the rekeying process and 3661 that member's joining is sufficiently small, then that group member 3662 is also on the safe side, since it would not accept replayed messages 3663 protected with the old group keying material previous to its joining. 3665 The KDC may enforce a rekeying policy that takes into account the 3666 overall time required to rekey the group, as well as the expected 3667 rate of changes in the group membership. That is, the KDC may not 3668 rekey the group at each and every group membership change, for 3669 instance if members' joining and leaving occur frequently and 3670 performing a group rekeying takes too long. Instead, the KDC might 3671 rekey the group after a minimum number of group members have joined 3672 or left within a given time interval, or after a maximum amount of 3673 time since the last group rekeying was completed, or yet during 3674 predictable network inactivity periods. 3676 However, this would result in the KDC not constantly preserving 3677 backward and forward security in the group. That is: 3679 * Newly joining group members would be able to access the keying 3680 material used before their joining, and thus they could access 3681 past group communications if they have recorded old exchanged 3682 messages. This might still be acceptable for some applications 3683 and in situations where the new group members are freshly deployed 3684 through strictly controlled procedures. 3686 * The leaving group members would remain able to access upcoming 3687 group communications, as protected with the current keying 3688 material that has not been updated. This is typically 3689 undesirable, especially if the leaving group member is compromised 3690 or suspected to be, and it might have an impact or compromise the 3691 security properties of the protocols used in the group to protect 3692 messages exchanged among the group member. 3694 The KDC should renew the group keying material in case it has 3695 rebooted, even in case it stores the whole group keying material in 3696 persistent storage. This assumes that the secure associations with 3697 the current group members as well as any administrative keying 3698 material required to rekey the group are also stored in persistent 3699 storage. 3701 However, if the KDC relies on Observe notifications to distribute the 3702 new group keying material, the KDC would have lost all the current 3703 ongoing Observations with the group members after rebooting, and the 3704 group members would continue using the old group keying material. 3705 Therefore, the KDC will rather rely on each group member asking for 3706 the new group keying material (see Section 4.3.2.1 and 3707 Section 4.8.1.1), or rather perform a group rekeying by actively 3708 sending rekeying messages to group members as discussed in Section 6. 3710 The KDC needs to have a mechanism in place to detect DoS attacks from 3711 nodes repeatedly performing actions that might trigger a group 3712 rekeying. Such actions can include leaving and/or re-joining the 3713 group at high rates, or often asking the KDC for new indidivual 3714 keying material. Ultimately, the KDC can resort to removing these 3715 nodes from the group and (temperorarily) preventing them from joining 3716 the group again. 3718 The KDC also needs to have a congestion control mechanism in place, 3719 in order to avoid network congestion upon distributing new group 3720 keying material. For example, CoAP and Observe give guidance on such 3721 mechanisms, see Section 4.7 of [RFC7252] and Section 4.5.1 of 3722 [RFC7641]. 3724 A node that has left the group should not expect any of its outgoing 3725 messages to be successfully processed, if received by other nodes 3726 after its leaving, due to a possible group rekeying occurred before 3727 the message reception. 3729 10.2.1. Misalignment of Group Keying Material 3731 A group member can receive a message shortly after the group has been 3732 rekeyed, and new keying material has been distributed by the KDC (see 3733 Section 6). In the following two cases, this may result in 3734 misaligned keying material between the group members. 3736 In the first case, the sender protects a message using the old group 3737 keying material. However, the recipient receives the message after 3738 having received the new group keying material, hence not being able 3739 to correctly process it. A possible way to ameliorate this issue is 3740 to preserve the old, recent group keying material for a maximum 3741 amount of time defined by the application, during which it is used 3742 solely for processing incoming messages. By doing so, the recipient 3743 can still temporarily process received messages also by using the 3744 old, retained group keying material. Note that a former 3745 (compromised) group member can take advantage of this by sending 3746 messages protected with the old, retained group keying material. 3747 Therefore, a conservative application policy should not admit the 3748 storage of old group keying material. Eventually, the sender will 3749 have obtained the new group keying material too, and can possibly re- 3750 send the message protected with such keying material. 3752 In the second case, the sender protects a message using the new group 3753 keying material, but the recipient receives that message before 3754 having received the new group keying material. Therefore, the 3755 recipient would not be able to correctly process the message and 3756 hence discards it. If the recipient receives the new group keying 3757 material shortly after that and the application at the sender 3758 endpoint performs retransmissions, the former will still be able to 3759 receive and correctly process the message. In any case, the 3760 recipient should actively ask the KDC for the latest group keying 3761 material according to an application-defined policy, for instance 3762 after a given number of unsuccessfully decrypted incoming messages. 3764 10.3. Block-Wise Considerations 3766 If the Block-Wise CoAP options [RFC7959] are used, and the keying 3767 material is updated in the middle of a Block-Wise transfer, the 3768 sender of the blocks just changes the group keying material to the 3769 updated one and continues the transfer. As long as both sides get 3770 the new group keying material, updating group the keying material in 3771 the middle of a transfer will not cause any issue. Otherwise, the 3772 sender will have to transmit the message again, when receiving an 3773 error message from the recipient. 3775 Compared to a scenario where the transfer does not use Block-Wise, 3776 depending on how fast the group keying material is changed, the group 3777 members might consume a larger amount of the network bandwidth by 3778 repeatedly resending the same blocks, which might be problematic. 3780 11. IANA Considerations 3782 This document has the following actions for IANA. 3784 11.1. Media Type Registrations 3786 This specification registers the 'application/ace-groupcomm+cbor' 3787 media type for messages of the protocols defined in this document 3788 following the ACE exchange and carrying parameters encoded in CBOR. 3789 This registration follows the procedures specified in [RFC6838]. 3791 Type name: application 3793 Subtype name: ace-groupcomm+cbor 3795 Required parameters: N/A 3797 Optional parameters: N/A 3798 Encoding considerations: Must be encoded as CBOR map containing the 3799 protocol parameters defined in [this document]. 3801 Security considerations: See Section 10 of this document. 3803 Interoperability considerations: n/a 3805 Published specification: [this document] 3807 Applications that use this media type: The type is used by 3808 Authorization Servers, Clients and Resource Servers that support the 3809 ACE groupcomm framework as specified in [this document]. 3811 Fragment identifier considerations: N/A 3813 Additional information: N/A 3815 Person & email address to contact for further information: 3816 iesg@ietf.org (mailto:iesg@ietf.org) 3818 Intended usage: COMMON 3820 Restrictions on usage: None 3822 Author: Francesca Palombini francesca.palombini@ericsson.com 3823 (mailto:francesca.palombini@ericsson.com) 3825 Change controller: IESG 3827 11.2. CoAP Content-Formats 3829 IANA is asked to register the following entry to the "CoAP Content- 3830 Formats" registry within the "CoRE Parameters" registry group. 3832 Media Type: application/ace-groupcomm+cbor 3834 Encoding: - 3836 ID: TBD 3838 Reference: [this document] 3840 11.3. OAuth Parameters 3842 IANA is asked to register the following entries in the "OAuth 3843 Parameters" registry following the procedure specified in 3844 Section 11.2 of [RFC6749]. 3846 * Parameter name: sign_info 3848 * Parameter usage location: client-rs request, rs-client response 3850 * Change Controller: IESG 3852 * Specification Document(s): [[This specification]] 3854 * Parameter name: kdcchallenge 3856 * Parameter usage location: rs-client response 3858 * Change Controller: IESG 3860 * Specification Document(s): [[This specification]] 3862 11.4. OAuth Parameters CBOR Mappings 3864 IANA is asked to register the following entries in the "OAuth 3865 Parameters CBOR Mappings" registry following the procedure specified 3866 in Section 8.10 of [I-D.ietf-ace-oauth-authz]. 3868 * Name: sign_info 3870 * CBOR Key: TBD (range -256 to 255) 3872 * Value Type: Simple value null / array 3874 * Reference: [[This specification]] 3876 * Name: kdcchallenge 3878 * CBOR Key: TBD (range -256 to 255) 3880 * Value Type: Byte string 3882 * Reference: [[This specification]] 3884 11.5. Interface Description (if=) Link Target Attribute Values 3886 IANA is asked to register the following entry in the "Interface 3887 Description (if=) Link Target Attribute Values" registry within the 3888 "CoRE Parameters" registry group. 3890 * Attribute Value: ace.group 3891 * Description: The 'ace group' interface is used to provision keying 3892 material and related information and policies to members of a 3893 group using the Ace framework. 3895 * Reference: [This Document] 3897 11.6. CBOR Tags 3899 IANA is asked to register the following entry in the "CBOR Tags" 3900 registry. 3902 * Tag : TBD_TAG 3904 * Data Item: byte string 3906 * Semantics: Extended ACE scope format, including the identifier of 3907 the used scope semantics. 3909 * Reference: [This Document] 3911 11.7. ACE Groupcomm Parameters 3913 This specification establishes the "ACE Groupcomm Parameters" IANA 3914 registry. The registry has been created to use the "Expert Review" 3915 registration procedure [RFC8126]. Expert review guidelines are 3916 provided in Section 11.15. 3918 The columns of this registry are: 3920 * Name: This is a descriptive name that enables easier reference to 3921 the item. The name MUST be unique. It is not used in the 3922 encoding. 3924 * CBOR Key: This is the value used as CBOR key of the item. These 3925 values MUST be unique. The value can be a positive integer, a 3926 negative integer, or a string. 3928 * CBOR Type: This contains the CBOR type of the item, or a pointer 3929 to the registry that defines its type, when that depends on 3930 another item. 3932 * Reference: This contains a pointer to the public specification for 3933 the item. 3935 This registry has been initially populated by the values in 3936 Section 8. The Reference column for all of these entries refers to 3937 sections of this document. 3939 11.8. ACE Groupcomm Key Types 3941 This specification establishes the "ACE Groupcomm Key Types" IANA 3942 registry. The registry has been created to use the "Expert Review" 3943 registration procedure [RFC8126]. Expert review guidelines are 3944 provided in Section 11.15. 3946 The columns of this registry are: 3948 * Name: This is a descriptive name that enables easier reference to 3949 the item. The name MUST be unique. It is not used in the 3950 encoding. 3952 * Key Type Value: This is the value used to identify the keying 3953 material. These values MUST be unique. The value can be a 3954 positive integer, a negative integer, or a text string. 3956 * Profile: This field may contain one or more descriptive strings of 3957 application profiles to be used with this item. The values should 3958 be taken from the Name column of the "ACE Groupcomm Profiles" 3959 registry. 3961 * Description: This field contains a brief description of the keying 3962 material. 3964 * References: This contains a pointer to the public specification 3965 for the format of the keying material, if one exists. 3967 This registry has been initially populated by the values in 3968 Figure 10. The specification column for all of these entries will be 3969 this document. 3971 11.9. ACE Groupcomm Profiles 3973 This specification establishes the "ACE Groupcomm Profiles" IANA 3974 registry. The registry has been created to use the "Expert Review" 3975 registration procedure [RFC8126]. Expert review guidelines are 3976 provided in Section 11.15. It should be noted that, in addition to 3977 the expert review, some portions of the registry require a 3978 specification, potentially a Standards Track RFC, to be supplied as 3979 well. 3981 The columns of this registry are: 3983 * Name: The name of the application profile, to be used as value of 3984 the profile attribute. 3986 * Description: Text giving an overview of the application profile 3987 and the context it is developed for. 3989 * CBOR Value: CBOR abbreviation for the name of this application 3990 profile. Different ranges of values use different registration 3991 policies [RFC8126]. Integer values from -256 to 255 are 3992 designated as Standards Action. Integer values from -65536 to 3993 -257 and from 256 to 65535 are designated as Specification 3994 Required. Integer values greater than 65535 are designated as 3995 Expert Review. Integer values less than -65536 are marked as 3996 Private Use. 3998 * Reference: This contains a pointer to the public specification of 3999 the abbreviation for this application profile, if one exists. 4001 11.10. ACE Groupcomm Policies 4003 This specification establishes the "ACE Groupcomm Policies" IANA 4004 registry. The registry has been created to use the "Expert Review" 4005 registration procedure [RFC8126]. Expert review guidelines are 4006 provided in Section 11.15. It should be noted that, in addition to 4007 the expert review, some portions of the registry require a 4008 specification, potentially a Standards Track RFC, to be supplied as 4009 well. 4011 The columns of this registry are: 4013 * Name: The name of the group communication policy. 4015 * CBOR label: The value to be used to identify this group 4016 communication policy. Key map labels MUST be unique. The label 4017 can be a positive integer, a negative integer or a string. 4018 Integer values between 0 and 255 and strings of length 1 are 4019 designated as Standards Track Document required. Integer values 4020 from 256 to 65535 and strings of length 2 are designated as 4021 Specification Required. Integer values greater than 65535 and 4022 strings of length greater than 2 are designated as expert review. 4023 Integer values less than -65536 are marked as private use. 4025 * CBOR type: the CBOR type used to encode the value of this group 4026 communication policy. 4028 * Description: This field contains a brief description for this 4029 group communication policy. 4031 * Reference: This field contains a pointer to the public 4032 specification providing the format of the group communication 4033 policy, if one exists. 4035 This registry will be initially populated by the values in Figure 11. 4037 11.11. Sequence Number Synchronization Methods 4039 This specification establishes the "Sequence Number Synchronization 4040 Methods" IANA registry. The registry has been created to use the 4041 "Expert Review" registration procedure [RFC8126]. Expert review 4042 guidelines are provided in Section 11.15. It should be noted that, 4043 in addition to the expert review, some portions of the registry 4044 require a specification, potentially a Standards Track RFC, to be 4045 supplied as well. 4047 The columns of this registry are: 4049 * Name: The name of the sequence number synchronization method. 4051 * Value: The value to be used to identify this sequence number 4052 synchronization method. 4054 * Description: This field contains a brief description for this 4055 sequence number synchronization method. 4057 * Reference: This field contains a pointer to the public 4058 specification describing the sequence number synchronization 4059 method. 4061 11.12. ACE Scope Semantics 4063 This specification establishes the "ACE Scope Semantics" IANA 4064 registry. The registry has been created to use the "Expert Review" 4065 registration procedure [RFC8126]. Expert review guidelines are 4066 provided in Section 11.15. It should be noted that, in addition to 4067 the expert review, some portions of the registry require a 4068 specification, potentially a Standards Track RFC, to be supplied as 4069 well. 4071 The columns of this registry are: 4073 * Value: The value to be used to identify this scope semantics. The 4074 value MUST be unique. The value can be a positive integer or a 4075 negative integer. Integer values between 0 and 255 are designated 4076 as Standards Track Document required. Integer values from 256 to 4077 65535 are designated as Specification Required. Integer values 4078 greater than 65535 are designated as expert review. Integer 4079 values less than -65536 are marked as private use. 4081 * Description: This field contains a brief description of the scope 4082 semantics. 4084 * Reference: This field contains a pointer to the public 4085 specification defining the scope semantics, if one exists. 4087 11.13. ACE Groupcomm Errors 4089 This specification establishes the "ACE Groupcomm Errors" IANA 4090 registry. The registry has been created to use the "Expert Review" 4091 registration procedure [RFC8126]. Expert review guidelines are 4092 provided in Section 11.15. It should be noted that, in addition to 4093 the expert review, some portions of the registry require a 4094 specification, potentially a Standards Track RFC, to be supplied as 4095 well. 4097 The columns of this registry are: 4099 * Value: The value to be used to identify the error. The value MUST 4100 be unique. The value can be a positive integer or a negative 4101 integer. Integer values between 0 and 255 are designated as 4102 Standards Track Document required. Integer values from 256 to 4103 65535 are designated as Specification Required. Integer values 4104 greater than 65535 are designated as expert review. Integer 4105 values less than -65536 are marked as private use. 4107 * Description: This field contains a brief description of the error. 4109 * Reference: This field contains a pointer to the public 4110 specification defining the error, if one exists. 4112 This registry has been initially populated by the values in 4113 Section 9. The Reference column for all of these entries refers to 4114 this document. 4116 11.14. ACE Groupcomm Rekeying Schemes 4118 This specification establishes the "ACE Groupcomm Rekeying Schemes" 4119 IANA registry. The registry has been created to use the "Expert 4120 Review" registration procedure [RFC8126]. Expert review guidelines 4121 are provided in Section 11.15. It should be noted that, in addition 4122 to the expert review, some portions of the registry require a 4123 specification, potentially a Standards Track RFC, to be supplied as 4124 well. 4126 The columns of this registry are: 4128 * Value: The value to be used to identify the group rekeying scheme. 4129 The value MUST be unique. The value can be a positive integer or 4130 a negative integer. Integer values between 0 and 255 are 4131 designated as Standards Track Document required. Integer values 4132 from 256 to 65535 are designated as Specification Required. 4133 Integer values greater than 65535 are designated as expert review. 4134 Integer values less than -65536 are marked as private use. 4136 * Name: The name of the group rekeying scheme. 4138 * Description: This field contains a brief description of the group 4139 rekeying scheme. 4141 * Reference: This field contains a pointer to the public 4142 specification defining the group rekeying scheme, if one exists. 4144 This registry has been initially populated by the value in Figure 12. 4146 11.15. Expert Review Instructions 4148 The IANA Registries established in this document are defined as 4149 expert review. This section gives some general guidelines for what 4150 the experts should be looking for, but they are being designated as 4151 experts for a reason so they should be given substantial latitude. 4153 Expert reviewers should take into consideration the following points: 4155 * Point squatting should be discouraged. Reviewers are encouraged 4156 to get sufficient information for registration requests to ensure 4157 that the usage is not going to duplicate one that is already 4158 registered and that the point is likely to be used in deployments. 4159 The zones tagged as private use are intended for testing purposes 4160 and closed environments, code points in other ranges should not be 4161 assigned for testing. 4163 * Specifications are required for the standards track range of point 4164 assignment. Specifications should exist for specification 4165 required ranges, but early assignment before a specification is 4166 available is considered to be permissible. Specifications are 4167 needed for the first-come, first-serve range if they are expected 4168 to be used outside of closed environments in an interoperable way. 4169 When specifications are not provided, the description provided 4170 needs to have sufficient information to identify what the point is 4171 being used for. 4173 * Experts should take into account the expected usage of fields when 4174 approving point assignment. The fact that there is a range for 4175 standards track documents does not mean that a standards track 4176 document cannot have points assigned outside of that range. The 4177 length of the encoded value should be weighed against how many 4178 code points of that length are left, the size of device it will be 4179 used on, and the number of code points left that encode to that 4180 size. 4182 12. References 4184 12.1. Normative References 4186 [COSE.Algorithms] 4187 IANA, "COSE Algorithms", 4188 . 4191 [COSE.Header.Parameters] 4192 IANA, "COSE Header Parameters", 4193 . 4196 [I-D.ietf-ace-aif] 4197 Bormann, C., "An Authorization Information Format (AIF) 4198 for ACE", Work in Progress, Internet-Draft, draft-ietf- 4199 ace-aif-03, 24 June 2021, 4200 . 4203 [I-D.ietf-ace-oauth-authz] 4204 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 4205 H. Tschofenig, "Authentication and Authorization for 4206 Constrained Environments (ACE) using the OAuth 2.0 4207 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 4208 draft-ietf-ace-oauth-authz-45, 29 August 2021, 4209 . 4212 [I-D.ietf-core-oscore-groupcomm] 4213 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 4214 and J. Park, "Group OSCORE - Secure Group Communication 4215 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 4216 core-oscore-groupcomm-13, 25 October 2021, 4217 . 4220 [I-D.ietf-cose-countersign] 4221 Schaad, J. and R. Housley, "CBOR Object Signing and 4222 Encryption (COSE): Countersignatures", Work in Progress, 4223 Internet-Draft, draft-ietf-cose-countersign-05, 23 June 4224 2021, . 4227 [I-D.ietf-cose-rfc8152bis-algs] 4228 Schaad, J., "CBOR Object Signing and Encryption (COSE): 4229 Initial Algorithms", Work in Progress, Internet-Draft, 4230 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 4231 . 4234 [I-D.ietf-cose-rfc8152bis-struct] 4235 Schaad, J., "CBOR Object Signing and Encryption (COSE): 4236 Structures and Process", Work in Progress, Internet-Draft, 4237 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 4238 . 4241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4242 Requirement Levels", BCP 14, RFC 2119, 4243 DOI 10.17487/RFC2119, March 1997, 4244 . 4246 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 4247 RFC 6749, DOI 10.17487/RFC6749, October 2012, 4248 . 4250 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 4251 Specifications and Registration Procedures", BCP 13, 4252 RFC 6838, DOI 10.17487/RFC6838, January 2013, 4253 . 4255 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 4256 Application Protocol (CoAP)", RFC 7252, 4257 DOI 10.17487/RFC7252, June 2014, 4258 . 4260 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 4261 Bose, "Constrained Application Protocol (CoAP) Option for 4262 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 4263 August 2016, . 4265 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 4266 Writing an IANA Considerations Section in RFCs", BCP 26, 4267 RFC 8126, DOI 10.17487/RFC8126, June 2017, 4268 . 4270 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4271 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4272 May 2017, . 4274 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 4275 Definition Language (CDDL): A Notational Convention to 4276 Express Concise Binary Object Representation (CBOR) and 4277 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 4278 June 2019, . 4280 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 4281 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 4282 . 4284 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 4285 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 4286 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 4287 2020, . 4289 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 4290 Representation (CBOR)", STD 94, RFC 8949, 4291 DOI 10.17487/RFC8949, December 2020, 4292 . 4294 12.2. Informative References 4296 [I-D.ietf-ace-dtls-authorize] 4297 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 4298 L. Seitz, "Datagram Transport Layer Security (DTLS) 4299 Profile for Authentication and Authorization for 4300 Constrained Environments (ACE)", Work in Progress, 4301 Internet-Draft, draft-ietf-ace-dtls-authorize-18, 4 June 4302 2021, . 4305 [I-D.ietf-ace-mqtt-tls-profile] 4306 Sengul, C. and A. Kirby, "Message Queuing Telemetry 4307 Transport (MQTT)-TLS profile of Authentication and 4308 Authorization for Constrained Environments (ACE) 4309 Framework", Work in Progress, Internet-Draft, draft-ietf- 4310 ace-mqtt-tls-profile-13, 23 October 2021, 4311 . 4314 [I-D.ietf-ace-oscore-profile] 4315 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 4316 "OSCORE Profile of the Authentication and Authorization 4317 for Constrained Environments Framework", Work in Progress, 4318 Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May 4319 2021, . 4322 [I-D.ietf-core-coap-pubsub] 4323 Koster, M., Keranen, A., and J. Jimenez, "Publish- 4324 Subscribe Broker for the Constrained Application Protocol 4325 (CoAP)", Work in Progress, Internet-Draft, draft-ietf- 4326 core-coap-pubsub-09, 30 September 2019, 4327 . 4330 [I-D.ietf-core-groupcomm-bis] 4331 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 4332 for the Constrained Application Protocol (CoAP)", Work in 4333 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 4334 05, 25 October 2021, . 4337 [I-D.tiloca-core-oscore-discovery] 4338 Tiloca, M., Amsuess, C., and P. V. D. Stok, "Discovery of 4339 OSCORE Groups with the CoRE Resource Directory", Work in 4340 Progress, Internet-Draft, draft-tiloca-core-oscore- 4341 discovery-10, 25 October 2021, 4342 . 4345 [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management 4346 Protocol (GKMP) Specification", RFC 2093, 4347 DOI 10.17487/RFC2093, July 1997, 4348 . 4350 [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management 4351 Protocol (GKMP) Architecture", RFC 2094, 4352 DOI 10.17487/RFC2094, July 1997, 4353 . 4355 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 4356 Multicast: Issues and Architectures", RFC 2627, 4357 DOI 10.17487/RFC2627, June 1999, 4358 . 4360 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 4361 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 4362 . 4364 [RFC7641] Hartke, K., "Observing Resources in the Constrained 4365 Application Protocol (CoAP)", RFC 7641, 4366 DOI 10.17487/RFC7641, September 2015, 4367 . 4369 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 4370 the Constrained Application Protocol (CoAP)", RFC 7959, 4371 DOI 10.17487/RFC7959, August 2016, 4372 . 4374 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 4375 Interchange Format", STD 90, RFC 8259, 4376 DOI 10.17487/RFC8259, December 2017, 4377 . 4379 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 4380 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 4381 May 2018, . 4383 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 4384 "Object Security for Constrained RESTful Environments 4385 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 4386 . 4388 Appendix A. Requirements on Application Profiles 4390 This section lists the requirements on application profiles of this 4391 specification, for the convenience of application profile designers. 4393 A.1. Mandatory-to-Address Requirements 4395 * REQ1: Specify the format and encoding of 'scope'. This includes 4396 defining the set of possible roles and their identifiers, as well 4397 as the corresponding encoding to use in the scope entries 4398 according to the used scope format (see Section 3.1). 4400 * REQ2: If the AIF format of 'scope' is used, register its specific 4401 instance of "Toid" and "Tperm", as well as the corresponding Media 4402 Type and Content-Format, as per the guidelines in 4403 [I-D.ietf-ace-aif]. 4405 * REQ3: If used, specify the acceptable values for 'sign_alg' (see 4406 Section 3.3). 4408 * REQ4: If used, specify the acceptable values for 'sign_parameters' 4409 (see Section 3.3). 4411 * REQ5: If used, specify the acceptable values for 4412 'sign_key_parameters' (see Section 3.3). 4414 * REQ6: Specify the acceptable formats for encoding public keys and, 4415 if used, the acceptable values for 'pub_key_enc' (see 4416 Section 3.3). 4418 * REQ7: If the value of the GROUPNAME URI path and the group name in 4419 the access token scope (gname in Section 3.2) are not required to 4420 coincide, specify the mechanism to map the GROUPNAME value in the 4421 URI to the group name (see Section 4.1). 4423 * REQ8: Define whether the KDC has a public key and if this has to 4424 be provided through the 'kdc_cred' parameter, see Section 4.3.1. 4426 * REQ9: Specify if any part of the KDC interface as defined in this 4427 document is not supported by the KDC (see Section 4.1). 4429 * REQ10: Register a Resource Type for the root url-path, which is 4430 used to discover the correct url to access at the KDC (see 4431 Section 4.1). 4433 * REQ11: Define what specific actions (e.g., CoAP methods) are 4434 allowed on each resource provided by the KDC interface, depending 4435 on whether the Client is a current group member; the roles that a 4436 Client is authorized to take as per the obtained access token (see 4437 Section 3.1); and the roles that the Client has as current group 4438 member. 4440 * REQ12: Categorize possible newly defined operations for Clients 4441 into primary operations expected to be minimally supported and 4442 secondary operations, and provide accompanying considerations (see 4443 Section 4.1.1). 4445 * REQ13: Specify the encoding of group identifier (see 4446 Section 4.2.1). 4448 * REQ14: Specify the approaches used to compute and verify the PoP 4449 evidence to include in 'client_cred_verify', and which of those 4450 approaches is used in which case (see Section 4.3.1). 4452 * REQ15: Specify how the nonce N_S is generated, if the token is not 4453 provided to the KDC through the Token Transfer Request to the 4454 authz-info endpoint (e.g., if it is used directly to validate TLS 4455 instead). 4457 * REQ16 Define the initial value of the 'num' parameter (see 4458 Section 4.3.1). 4460 * REQ17: Specify the format of the 'key' parameter (see 4461 Section 4.3.1). 4463 * REQ18: Specify the acceptable values of the 'gkty' parameter (see 4464 Section 4.3.1). 4466 * REQ19: Specify and register the application profile identifier 4467 (see Section 4.3.1). 4469 * REQ20: If used, specify the format and content of 'group_policies' 4470 and its entries. Specify the policies default values (see 4471 Section 4.3.1). 4473 * REQ21: Specify the approaches used to compute and verify the PoP 4474 evidence to include in 'kdc_cred_verify', and which of those 4475 approaches is used in which case (see Section 4.3.1). 4477 * REQ22: Specify the communication protocol the members of the group 4478 must use (e.g., multicast CoAP). 4480 * REQ23: Specify the security protocol the group members must use to 4481 protect their communication (e.g., group OSCORE). This must 4482 provide encryption, integrity and replay protection. 4484 * REQ24: Specify how the communication is secured between Client and 4485 KDC. Optionally, specify transport profile of ACE 4486 [I-D.ietf-ace-oauth-authz] to use between Client and KDC (see 4487 Section 4.3.1.1. 4489 * REQ25: Specify the format of the identifiers of group members (see 4490 Section 4.3.1). 4492 * REQ26: Specify policies at the KDC to handle ids that are not 4493 included in 'get_pub_keys' (see Section 4.4.1). 4495 * REQ27: Specify the format of newly-generated individual keying 4496 material for group members, or of the information to derive it, 4497 and corresponding CBOR label (see Section 4.8.1). 4499 * REQ28: Specify and register the identifier of newly defined 4500 semantics for binary scopes (see Section 7). 4502 * REQ29: Categorize newly defined parameters according to the same 4503 criteria of Section 8. 4505 * REQ30: Define whether Clients must, should or may support the 4506 conditional parameters defined in Section 8, and under which 4507 circumstances. 4509 A.2. Optional-to-Address Requirements 4511 * OPT1: Optionally, if the textual format of 'scope' is used, 4512 specify CBOR values to use for abbreviating the role identifiers 4513 in the group (see Section 3.1). 4515 * OPT2: Optionally, specify the additional parameters used in the 4516 exchange of Token Transfer Request and Response (see Section 3.3). 4518 * OPT3: Optionally, specify the negotiation of parameter values for 4519 signature algorithm and signature keys, if 'sign_info' is not used 4520 (see Section 3.3). 4522 * OPT4: Optionally, specify possible or required payload formats for 4523 specific error cases. 4525 * OPT5: Optionally, specify additional identifiers of error types, 4526 as values of the 'error' field in an error response from the KDC. 4528 * OPT6: Optionally, specify the encoding of 'pub_keys_repos' if the 4529 default is not used (see Section 4.3.1). 4531 * OPT7: Optionally, specify the functionalities implemented at the 4532 'control_uri' resource hosted at the Client, including message 4533 exchange encoding and other details (see Section 4.3.1). 4535 * OPT8: Optionally, specify the behavior of the handler in case of 4536 failure to retrieve a public key for the specific node (see 4537 Section 4.3.1). 4539 * OPT9: Optionally, define a default group rekeying scheme, to refer 4540 to in case the 'rekeying_scheme' parameter is not included in the 4541 Joining Response (see Section 4.3.1). 4543 * OPT10: Optionally, specify the functionalities implemented at the 4544 'control_group_uri' resource hosted at the Client, including 4545 message exchange encoding and other details (see Section 4.3.1). 4547 * OPT11: Optionally, specify policies that instruct Clients to 4548 retain messages and for how long, if they are unsuccessfully 4549 decrypted (see Section 4.8.1.1). This makes it possible to 4550 decrypt such messages after getting updated keying material. 4552 * OPT12: Optionally, specify for the KDC to perform group rekeying 4553 (together or instead of renewing individual keying material) when 4554 receiving a Key Renewal Request (see Section 4.8.2.1). 4556 * OPT13: Optionally, specify how the identifier of a group members's 4557 public key is included in requests sent to other group members 4558 (see Section 4.9.1.1). 4560 * OPT14: Optionally, specify additional information to include in 4561 rekeying messages for the "Point-to-Point" group rekeying scheme 4562 (see Section 6). 4564 * OPT15: Optionally, specify if Clients must or should support any 4565 of the parameters defined as optional in this specification (see 4566 Section 8). 4568 Appendix B. Extensibility for Future COSE Algorithms 4570 As defined in Section 8.1 of [I-D.ietf-cose-rfc8152bis-algs], future 4571 algorithms can be registered in the "COSE Algorithms" registry 4572 [COSE.Algorithms] as specifying none or multiple COSE capabilities. 4574 To enable the seamless use of such future registered algorithms, this 4575 section defines a general, agile format for each 'sign_info_entry' of 4576 the 'sign_info' parameter in the Token Transfer Response, see 4577 Section 3.3.1. 4579 If any of the currently registered COSE algorithms is considered, 4580 using this general format yields the same structure of 4581 'sign_info_entry' defined in this document, thus ensuring retro- 4582 compatibility. 4584 B.1. Format of 'sign_info_entry' 4586 The format of each 'sign_info_entry' (see Section 3.3.1) is 4587 generalized as follows. Given N the number of elements of the 4588 'sign_parameters' array, i.e., the number of COSE capabilities of the 4589 signature algorithm, then: 4591 * 'sign_key_parameters' is replaced by N elements 'sign_capab_i', 4592 each of which is a CBOR array. 4594 * The i-th array following 'sign_parameters', i.e., 'sign_capab_i' 4595 (i = 0, ..., N-1), is the array of COSE capabilities for the 4596 algorithm capability specified in 'sign_parameters'[i]. 4598 sign_info_entry = 4599 [ 4600 id : gname / [ + gname ], 4601 sign_alg : int / tstr, 4602 sign_parameters : [ alg_capab_1 : any, 4603 alg_capab_2 : any, 4604 ..., 4605 alg_capab_N : any], 4606 sign_capab_1 : [ any ], 4607 sign_capab_2 : [ any ], 4608 ..., 4609 sign_capab_N : [ any ], 4610 pub_key_enc = int / nil 4611 ] 4613 gname = tstr 4615 Figure 37: 'sign_info_entry' with general format 4617 Appendix C. Document Updates 4619 RFC EDITOR: PLEASE REMOVE THIS SECTION. 4621 C.1. Version -13 to -14 4623 * Clarified scope and goal of the document in abstract and 4624 introduction. 4626 * Overall clarifications on semantics of operations and parameters. 4628 * Major restructuring in the presentation of the KDC interface. 4630 * Revised error handling, also removing redundant text. 4632 * Imported parameters and KDC resource about the KDC's public key 4633 from draft-ietf-ace-key-groupcomm-oscore. 4635 * New parameters 'group_rekeying_scheme' and 'control_group_uri'. 4637 * Provided example of administrative keying material transported in 4638 'mgt_key_material'. 4640 * Reasoned categorization of parameters, as expected support by ACE 4641 Clients. 4643 * Reasoned categorization of KDC functionalities, as minimally/ 4644 optional to support for ACE Clients. 4646 * Guidelines on enhanced error responses using 'error' and 4647 'error_description'. 4649 * New section on group rekeying, discussing at a high-level a basic 4650 one-to-one approach and possible one-to-many approaches. 4652 * Revised and expanded security considerations, also about the KDC. 4654 * Updated list of requirements for application profiles. 4656 * Several further clarifications and editorial improvements. 4658 C.2. Version -05 to -13 4660 * Incremental revision of the KDC interface. 4662 * Removed redundancy in parameters about signature algorithm and 4663 signature keys. 4665 * Node identifiers always indicated with 'peer_identifiers'. 4667 * Format of public keys changed from raw COSE Keys to be 4668 certificates, CWTs or CWT Claims Set (CCS). Adapted parameter 4669 'pub_key_enc'. 4671 * Parameters and functionalities imported from draft-ietf-key- 4672 groupcomm-oscore where early defined. 4674 * Possible provisioning of the KDC's Diffie-Hellman public key in 4675 response to the Token transferring to /authz-info. 4677 * Generalized proof-of-possession evidence, to be not necessarily a 4678 signature. 4680 * Public keys of group members may be retrieved filtering by role 4681 and/or node identifier. 4683 * Enhanced error handling with error code and error description. 4685 * Extended "typed" format for the 'scope' claim, optional to use. 4687 * Editorial improvements. 4689 C.3. Version -04 to -05 4691 * Updated uppercase/lowercase URI segments for KDC resources. 4693 * Supporting single Access Token for multiple groups/topics. 4695 * Added 'control_uri' parameter in the Joining Request. 4697 * Added 'peer_roles' parameter to support legal requesters/ 4698 responders. 4700 * Clarification on stopping using owned keying material. 4702 * Clarification on different reasons for processing failures, 4703 related policies, and requirement OPT11. 4705 * Added a KDC sub-resource for group members to upload a new public 4706 key. 4708 * Possible group rekeying following an individual Key Renewal 4709 Request. 4711 * Clarified meaning of requirement REQ3; added requirement OPT12. 4713 * Editorial improvements. 4715 C.4. Version -03 to -04 4717 * Revised RESTful interface, as to methods and parameters. 4719 * Extended processing of joining request, as to check/retrieval of 4720 public keys. 4722 * Revised and extended profile requirements. 4724 * Clarified specific usage of parameters related to signature 4725 algorithms/keys. 4727 * Included general content previously in draft-ietf-ace-key- 4728 groupcomm-oscore 4730 * Registration of media type and content format application/ace- 4731 group+cbor 4733 * Editorial improvements. 4735 C.5. Version -02 to -03 4737 * Exchange of information on the signature algorithm and related 4738 parameters, during the Token POST (Section 3.3). 4740 * Restructured KDC interface, with new possible operations 4741 (Section 4). 4743 * Client PoP signature for the Joining Request upon joining 4744 (Section 4.1.2.1). 4746 * Revised text on group member removal (Section 5). 4748 * Added more profile requirements (Appendix A). 4750 C.6. Version -01 to -02 4752 * Editorial fixes. 4754 * Distinction between transport profile and application profile 4755 (Section 1.1). 4757 * New parameters 'sign_info' and 'pub_key_enc' to negotiate 4758 parameter values for signature algorithm and signature keys 4759 (Section 3.3). 4761 * New parameter 'type' to distinguish different Key Distribution 4762 Request messages (Section 4.1). 4764 * New parameter 'client_cred_verify' in the Key Distribution Request 4765 to convey a Client signature (Section 4.1). 4767 * Encoding of 'pub_keys_repos' (Section 4.1). 4769 * Encoding of 'mgt_key_material' (Section 4.1). 4771 * Improved description on retrieval of new or updated keying 4772 material (Section 6). 4774 * Encoding of 'get_pub_keys' in Public Key Request (Section 7.1). 4776 * Extended security considerations (Sections 10.1 and 10.2). 4778 * New "ACE Public Key Encoding" IANA registry (Section 11.2). 4780 * New "ACE Groupcomm Parameters" IANA registry (Section 11.3), 4781 populated with the entries in Section 8. 4783 * New "Ace Groupcomm Request Type" IANA registry (Section 11.4), 4784 populated with the values in Section 9. 4786 * New "ACE Groupcomm Policy" IANA registry (Section 11.7) populated 4787 with two entries "Sequence Number Synchronization Method" and "Key 4788 Update Check Interval" (Section 4.2). 4790 * Improved list of requirements for application profiles 4791 (Appendix A). 4793 C.7. Version -00 to -01 4795 * Changed name of 'req_aud' to 'audience' in the Authorization 4796 Request (Section 3.1). 4798 * Defined error handling on the KDC (Sections 4.2 and 6.2). 4800 * Updated format of the Key Distribution Response as a whole 4801 (Section 4.2). 4803 * Generalized format of 'pub_keys' in the Key Distribution Response 4804 (Section 4.2). 4806 * Defined format for the message to request leaving the group 4807 (Section 5.2). 4809 * Renewal of individual keying material and methods for group 4810 rekeying initiated by the KDC (Section 6). 4812 * CBOR type for node identifiers in 'get_pub_keys' (Section 7.1). 4814 * Added section on parameter identifiers and their CBOR keys 4815 (Section 8). 4817 * Added request types for requests to a Join Response (Section 9). 4819 * Extended security considerations (Section 10). 4821 * New IANA registries "ACE Groupcomm Key registry", "ACE Groupcomm 4822 Profile registry", "ACE Groupcomm Policy registry" and "Sequence 4823 Number Synchronization Method registry" (Section 11). 4825 * Added appendix about requirements for application profiles of ACE 4826 on group communication (Appendix A). 4828 Acknowledgments 4830 The following individuals were helpful in shaping this document: 4831 Christian Amsuess, Carsten Bormann, Rikard Hoeglund, Ben Kaduk, 4832 Watson Ladd, John Mattsson, Daniel Migault, Jim Schaad, Ludwig Seitz, 4833 Goeran Selander, Cigdem Sengul and Peter van der Stok. 4835 The work on this document has been partly supported by VINNOVA and 4836 the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home 4837 (Grant agreement 952652); and by the EIT-Digital High Impact 4838 Initiative ACTIVE. 4840 Authors' Addresses 4842 Francesca Palombini 4843 Ericsson AB 4844 Torshamnsgatan 23 4845 SE-16440 Stockholm Kista 4846 Sweden 4848 Email: francesca.palombini@ericsson.com 4850 Marco Tiloca 4851 RISE AB 4852 Isafjordsgatan 22 4853 SE-16440 Stockholm Kista 4854 Sweden 4856 Email: marco.tiloca@ri.se