idnits 2.17.1 draft-ietf-ace-key-groupcomm-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (11 May 2020) is 1445 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-33 == Outdated reference: A later version (-16) exists of draft-ietf-ace-oauth-params-13 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-08 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-09 == Outdated reference: A later version (-17) exists of draft-ietf-ace-mqtt-tls-profile-04 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-10 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 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: 12 November 2020 RISE AB 6 11 May 2020 8 Key Provisioning for Group Communication using ACE 9 draft-ietf-ace-key-groupcomm-06 11 Abstract 13 This document defines message formats and procedures for requesting 14 and distributing group keying material using the ACE framework, to 15 protect communications between group members. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 12 November 2020. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Authorization to Join a Group . . . . . . . . . . . . . . . . 7 54 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 7 55 3.2. Authorization Response . . . . . . . . . . . . . . . . . 9 56 3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 10 57 4. Keying Material Provisioning and Group Membership 58 Management . . . . . . . . . . . . . . . . . . . . . . . 14 59 4.1. Interface at the KDC . . . . . . . . . . . . . . . . . . 15 60 4.2. Joining Exchange . . . . . . . . . . . . . . . . . . . . 30 61 4.3. Retrieval of Updated Keying Material . . . . . . . . . . 32 62 4.4. Retrieval of New Keying Material . . . . . . . . . . . . 34 63 4.5. Retrieval of Public Keys and Roles for Group Members . . 34 64 4.6. Update of Public Key . . . . . . . . . . . . . . . . . . 35 65 4.7. Retrieval of Group Policies . . . . . . . . . . . . . . . 36 66 4.8. Retrieval of Keying Material Version . . . . . . . . . . 37 67 4.9. Group Leaving Request . . . . . . . . . . . . . . . . . . 37 68 5. Removal of a Node from the Group . . . . . . . . . . . . . . 37 69 6. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 38 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 40 71 7.1. Update of Keying Material . . . . . . . . . . . . . . . . 40 72 7.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 41 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 74 8.1. Media Type Registrations . . . . . . . . . . . . . . . . 42 75 8.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 43 76 8.3. ACE Authorization Server Request Creation Hints 77 Registry . . . . . . . . . . . . . . . . . . . . . . . . 43 78 8.4. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 44 79 8.5. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 44 80 8.6. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 45 81 8.7. ACE Groupcomm Policy Registry . . . . . . . . . . . . . . 46 82 8.8. Sequence Number Synchronization Method Registry . . . . . 46 83 8.9. Interface Description (if=) Link Target Attribute Values 84 Registry . . . . . . . . . . . . . . . . . . . . . . . . 47 85 8.10. Expert Review Instructions . . . . . . . . . . . . . . . 47 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 48 88 9.2. Informative References . . . . . . . . . . . . . . . . . 49 89 Appendix A. Requirements on Application Profiles . . . . . . . . 51 90 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 53 91 B.1. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 53 92 B.2. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 54 93 B.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 54 94 B.4. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 55 95 B.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 56 97 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 56 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 100 1. Introduction 102 This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to 103 define the message exchanges used to request, distribute and renew 104 the keying material in a group communication scenario, e.g. based on 105 multicast [I-D.dijk-core-groupcomm-bis] or on publishing-subscribing 106 [I-D.ietf-core-coap-pubsub]. The ACE framework is based on CBOR 107 [RFC7049], so CBOR is the format used in this specification. 108 However, using JSON [RFC8259] instead of CBOR is possible, using the 109 conversion method specified in Sections 4.1 and 4.2 of [RFC7049]. 111 Profiles that use group communication can build on this document, by 112 defining a number of details such as the exact group communication 113 protocol and security protocols used. The specific list of details a 114 profile needs to define is shown in Appendix A. 116 If the application requires backward and forward security, new keying 117 material is generated and distributed to the group upon membership 118 changes. A key management scheme performs the actual distribution of 119 the new keying material to the group. In particular, the key 120 management scheme rekeys the current group members when a new node 121 joins the group, and the remaining group members when a node leaves 122 the group. Rekeying mechanisms can be based on [RFC2093], [RFC2094] 123 and [RFC2627]. 125 1.1. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 Readers are expected to be familiar with the terms and concepts 134 described in [I-D.ietf-ace-oauth-authz] and [RFC8152], such as 135 Authorization Server (AS) and Resource Server (RS). 137 This document additionally uses the following terminology: 139 * Transport profile, to indicate a profile of ACE as per 140 Section 5.6.4.3 of [I-D.ietf-ace-oauth-authz]. A transport 141 profile specifies the communication protocol and communication 142 security protocol between an ACE Client and Resource Server, as 143 well as proof-of-possession methods, if it supports proof-of- 144 possession access tokens, etc. Tranport profiles of ACE include, 145 for instance, [I-D.ietf-ace-oscore-profile], 146 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-mqtt-tls-profile]. 148 * Application profile, that defines how applications enforce and use 149 supporting security services they require. These services may 150 include, for instance, provisioning, revocation and 151 (re-)distribution of keying material. An application profile may 152 define specific procedures and message formats. 154 2. Overview 156 +------------+ +-----------+ 157 | AS | | KDC | 158 | | .-------->| | 159 +------------+ / +-----------+ 160 ^ / 161 | / 162 v / +-----------+ 163 +------------+ / +------------+ |+-----------+ 164 | Client |<-' | Dispatcher | ||+-----------+ 165 | |<-------->| (RS) |<------->|| Group | 166 +------------+ +------------+ +| members | 167 +-----------+ 169 Figure 1: Key Distribution Participants 171 The following participants (see Figure 1) take part in the 172 authorization and key distribution. 174 * Client (C): node that wants to join the group communication. It 175 can request write and/or read rights. 177 * Authorization Server (AS): same as AS in the ACE Framework; it 178 enforces access policies, and knows if a node is allowed to join a 179 given group with write and/or read rights. 181 * Key Distribution Center (KDC): maintains the keying material to 182 protect group communications, and provides it to Clients 183 authorized to join a given group. During the first part of the 184 exchange (Section 3), it takes the role of the RS in the ACE 185 Framework. During the second part (Section 4), which is not based 186 on the ACE Framework, it distributes the keying material. In 187 addition, it provides the latest keying material to group members 188 when requested or, if required by the application, when membership 189 changes. 191 * Dispatcher: entity through which the Clients communicate with the 192 group and which distributes messages to the group members. 193 Examples of dispatchers are: the Broker node in a pub-sub setting; 194 a relayer node for group communication that delivers group 195 messages as multiple unicast messages to all group members; an 196 implicit entity as in a multicast communication setting, where 197 messages are transmitted to a multicast IP address and delivered 198 on the transport channel. 200 This document specifies a mechanism for: 202 * Authorizing a new node to join the group (Section 3), and 203 providing it with the group keying material to communicate with 204 the other group members (Section 4). 206 * A node to leave the group of for the KDC to remove a current 207 member of the group (Section 5). 209 * Retrieving keying material as a current group member (Section 4.3 210 and Section 4.4). 212 * Renewing and re-distributing the group keying material (rekeying) 213 upon a membership change in the group (Section 4.9 and Section 5). 215 Figure 2 provides a high level overview of the message flow for a 216 node joining a group communication setting, which can be expanded as 217 follows. 219 1. The joining node requests an Access Token from the AS, in order 220 to access a specific group-membership resource on the KDC and 221 hence join the associated group. The joining node will start or 222 continue using a secure communication association with the KDC, 223 according to the response from the AS. 225 2. The joining node transfers authentication and authorization 226 information to the KDC, by posting the obtained Access Token to 227 the /authz-info endpoint at the KDC. After that, a joining node 228 MUST have a secure communication association established with the 229 KDC, before starting to join a group under that KDC. Possible 230 ways to provide a secure communication association are DTLS 231 [RFC6347] and OSCORE [RFC8613]. 233 3. The joining node starts the joining process to become a member of 234 the group, by accessing the related group-membership resource at 235 the KDC. At the end of the joining process, the joining node has 236 received from the KDC the parameters and keying material to 237 securely communicate with the other members of the group, and the 238 KDC has stored the association between the authorization 239 information from the access token and the secure session with the 240 client. 242 4. The joining node and the KDC maintain the secure association, to 243 support possible future communications. These especially include 244 key management operations, such as retrieval of updated keying 245 material or participation to a group rekeying process. 247 C AS KDC Group 248 | | | Member 249 / | | | | 250 | | Authorization Request | | | 251 Defined | |-------------------------->| | | 252 in the | | | | | 253 ACE | | Authorization Response | | | 254 framework | |<--------------------------| | | 255 | | | | 256 \ |---------- Token Post --------->| | 257 | | | 258 |------- Joining Request ------->| | 259 | | | 260 |<------ Joining Response -------|-- Group Rekeying -->| 261 | | | 262 | Dispatcher | 263 | | | 264 |<===== Secure group communication =======|===========>| 265 | | | 267 Figure 2: Message Flow Upon New Node's Joining 269 The exchange of Authorization Request and Authorization Response 270 between Client and AS MUST be secured, as specified by the transport 271 profile of ACE used between Client and KDC. 273 The exchange of Joining Request and Joining Response between Client 274 and KDC MUST be secured, as a result of the transport profile of ACE 275 used between Client and KDC. 277 All further communications between the Client and the KDC MUST be 278 secured, for instance with the same security mechanism used for the 279 Key Distribution exchange. 281 All communications between a Client and the other group members MUST 282 be secured using the keying material provided in Section 4. 284 3. Authorization to Join a Group 286 This section describes in detail the format of messages exchanged by 287 the participants when a node requests access to a group. This 288 exchange is based on ACE [I-D.ietf-ace-oauth-authz]. 290 As defined in [I-D.ietf-ace-oauth-authz], the Client requests from 291 the AS an authorization to join the group through the KDC (see 292 Section 3.1). If the request is approved and authorization is 293 granted, the AS provides the Client with a proof-of-possession access 294 token and parameters to securely communicate with the KDC (see 295 Section 3.2). 297 Communications between the Client and the AS MUST be secured, as 298 defined by the transport profile of ACE used. The Content-Format 299 used in the messages is the one specified by the used transport 300 profile of ACE (e.g. application/ace+cbor for the first two messages 301 and application/cwt for the third message, depending on the format of 302 the access token). The transport profile of ACE also defines a 303 number of details such as the communication and security protocols 304 used with the KDC (see Appendix C of [I-D.ietf-ace-oauth-authz]). 306 Figure 3 gives an overview of the exchange described above. 308 Client AS KDC 309 | | | 310 |---- Authorization Request: POST /token ------>| | 311 | | | 312 |<--- Authorization Response: 2.01 (Created) ---| | 313 | | | 314 |----- POST Token: POST /authz-info --------------->| 315 | | 317 Figure 3: Message Flow of Join Authorization 319 3.1. Authorization Request 321 The Authorization Request sent from the Client to the AS is as 322 defined in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MAY 323 contain the following parameters, which, if included, MUST have the 324 corresponding values: 326 * 'scope', containing the identifier of the specific group(s), or 327 topic(s) in the case of pub-sub, that the Client wishes to access, 328 and optionally the role(s) that the Client wishes to take. 330 This value is a CBOR byte string, encoding a CBOR array of one or 331 more entries. 333 An entry has as value a CBOR array, which contains: 335 - As first element, the identifier of the specific group or 336 topic. 338 - Optionally, as second element, the role (or CBOR array of 339 roles) that the Client wishes to take in the group. This 340 element is optional since roles may have been pre-assigned to 341 the Client, as associated to its verifiable identity 342 credentials. Alternatively, the application may have defined a 343 single, well-known role for the target resource(s) and 344 audience(s). 346 In each entry, the encoding of the group or topic identifier 347 (REQ1) and of the role identifiers (REQ2) is application specific, 348 and part of the requirements for the application profile. 350 In particular, the application profile may specify CBOR values to 351 use for abbreviating role identifiers (OPT7). 353 The CDDL definition of scope, using as example group identifier 354 encoded as byte string and role identifier as text string, is 355 given in Figure 4. 357 * 'audience', with an identifier of a KDC. 359 * 'req_cnf', as defined in Section 3.1 of 360 [I-D.ietf-ace-oauth-params], optionally containing the public key 361 or a reference to the public key of the Client, if it wishes to 362 communicate that to the AS. 364 * Other additional parameters as defined in 365 [I-D.ietf-ace-oauth-authz], if necessary. 367 As in [I-D.ietf-ace-oauth-authz], these parameters are included in 368 the payload, which is formatted as a CBOR map. The Content-Format 369 "application/ace+cbor" defined in Section 8.14 of 370 [I-D.ietf-ace-oauth-authz] is used. 372 gid = bstr 374 role = tstr 376 scope_entry = [ gid , ? ( role / [ 2*role ] ) ] 378 scope = << [ + scope_entry ] >> 380 Figure 4: CDLL definition of scope, using as example group 381 identifier encoded as bstr and role as tstr 383 3.2. Authorization Response 385 The Authorization Response sent from the AS to the Client is as 386 defined in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST 387 contain the following parameters: 389 * 'access_token', containing the proof-of-possession access token. 391 * 'cnf' if symmetric keys are used, not present if asymmetric keys 392 are used. This parameter is defined in Section 3.2 of 393 [I-D.ietf-ace-oauth-params] and contains the symmetric proof-of- 394 possession key that the Client is supposed to use with the KDC. 396 * 'rs_cnf' if asymmetric keys are used, not present if symmetric 397 keys are used. This parameter is as defined in Section 3.2 of 398 [I-D.ietf-ace-oauth-params] and contains information about the 399 public key of the KDC. 401 * 'expires_in', contains the lifetime in seconds of the access 402 token. This parameter MAY be omitted if the application defines 403 how the expiration time is communicated to the Client via other 404 means, or if it establishes a default value. 406 Additionally, the Authorization Response MAY contain the following 407 parameters, which, if included, MUST have the corresponding values: 409 * 'scope' containing the granted scope, if different from the scope 410 requested by the client. This parameter has the same format and 411 encoding of 'scope' in the Authorization Request, defined in 412 Section 3.1. 414 * Other additional parameters as defined in 415 [I-D.ietf-ace-oauth-authz], if necessary. 417 The proof-of-possession access token (in 'access_token' above) MUST 418 contain the following parameters: 420 * a confirmation claim (see for example 'cnf' defined in Section 3.1 421 of [RFC8747] for CWT); 423 * an expiration time claim (see for example 'exp' defined in 424 Section 3.1.4 of [RFC8392] for CWT); 426 * a scope claim (see for example 'scope' registered in Section 8.13 427 of [I-D.ietf-ace-oauth-authz] for CWT). This claim has the same 428 encoding as 'scope' parameter above. Additionally, this claim has 429 the same value of the 'scope' parameter if the parameter is 430 present in the message, or it takes the value of 'scope' in the 431 Authorization Request otherwise. 433 The access token MAY additionally contain other claims that the 434 transport profile of ACE requires, or other optional parameters. 436 As in [I-D.ietf-ace-oauth-authz], these parameters are included in 437 the payload, which is formatted as a CBOR map. The Content-Format 438 "application/ace+cbor" is used. 440 When receiving an Authorization Request from a Client that was 441 previously authorized, and for which the AS still owns a valid non 442 expired access token, the AS MAY reply with that token. Note that it 443 is up to application profiles of ACE to make sure that re-posting the 444 same token does not cause re-use of keying material between nodes 445 (for example, that is done with the use of random nonces in 446 [I-D.ietf-ace-oscore-profile]). 448 3.3. Token Post 450 The Client sends a CoAP POST request including the access token to 451 the KDC, as specified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. 452 If the specific transport profile of ACE defines it, the Client MAY 453 use a different endpoint than /authz-info at the KDC to post the 454 access token to. 456 Optionally, the Client might want to request necessary information 457 concerning the public keys in the group, as well as concerning the 458 algorithm and related parameters for computing signatures in the 459 group. In such a case, the joining node MAY ask for that information 460 to the KDC in this same request. To this end, it sends the CoAP POST 461 request to the /authz-info endpoint using the Content-Format 462 "application/ace+cbor". The payload of the message MUST be formatted 463 as a CBOR map, including the access token and the following 464 parameters: 466 * 'sign_info' defined in Section 3.3.1. 468 * 'pub_key_enc' defined in Section 3.3.2, encoding the CBOR simple 469 value Null, to require information on the exact encoding of public 470 keys used in the group. 472 Alternatively, the joining node may retrieve this information by 473 other means. 475 After successful verification, the Client is authorized to receive 476 the group keying material from the KDC and join the group. In 477 particular, the KDC replies to the Client with a 2.01 (Created) 478 response, using Content-Format "application/ace+cbor" defined in 479 Section 8.14 of [I-D.ietf-ace-oauth-authz]. 481 The payload of the 2.01 response is a CBOR map. If the access token 482 contains a role that requires the Client to send its own public key 483 to the KDC when joining the group, the CBOR map MUST include the 484 parameter 'kdcchallenge' defined in Section Section 3.3.3, specifying 485 a dedicated challenge N_S generated by the KDC. The Client uses this 486 challenge to prove possession of its own private key (see the 487 'client_cred_verify' parameter in Section 4). Note that the payload 488 format of the response deviates from the default as defined in the 489 ACE framework (see Section 5.8.1 of [I-D.ietf-ace-oauth-authz]). 491 The KDC MUST store the 'kdcchallenge' value associated to the Client 492 at least until it receives a join request from it (see Section 4.2), 493 to be able to verify the proof of possession. The same challenge MAY 494 be reused several times by the Client, to generate new proof of 495 possessions, e.g. in case of update of the public key, or to join a 496 different group with a different key, so it is RECOMMENDED that the 497 KDC keeps storing the 'kdcchallenge' after the first join is 498 processed as well. If the KDC has already discarded the 499 'kdcchallenge', that will trigger an error response with a newly 500 generated 'kdcchallenge' that the client can use to restart the join 501 process, as specified in Section 4.2. 503 If either of 'sign_info' or 'pub_key_enc' were included in the 504 request, the KDC MAY include the 'sign_info' parameter defined in 505 Section 3.3.1, optionally including the 'pub_key_enc' parameter 506 Section 3.3.2. 508 The 'sign_info' parameter MUST be present if the POST request 509 included the 'sign_info' parameter and/or the pub_key_enc with value 510 Null. The encoding of the 'sign_info' parameter in the response is 511 defined in Section 3.3.2. Note that the field 'id' takes the value 512 of the group identifier for which the 'sign_info' applies to, in this 513 specification. 515 Note that the CBOR map specified as payload of the 2.01 (Created) 516 response may include further parameters, e.g. according to the 517 signalled transport profile of ACE. 519 Applications of this specification MAY define alternative specific 520 negotiations of parameter values for signature algorithm and 521 signature keys, if 'sign_info' and 'pub_key_enc' are not used (OPT2). 523 3.3.1. 'sign_info' Parameter 525 The 'sign_info' parameter is an OPTIONAL parameter of the AS Request 526 Creation Hints message defined in Section 5.1.2. of 527 [I-D.ietf-ace-oauth-authz]. This parameter contains information and 528 parameters about the signature algorithm and the public keys to be 529 used between the Client and the RS. Its exact content is application 530 specific. 532 In this specification and in application profiles building on it, 533 this parameter is used to ask and retrieve from the KDC information 534 about the signature algorithm and related parameters used in the 535 group. 537 When used in the request, the 'sign_info' encodes the CBOR simple 538 value Null, to require information and parameters on the signature 539 algorithm and on the public keys used. 541 The CDDL notation of the 'sign_info' parameter formatted as in the 542 request is given below. 544 sign_info_req = nil 546 The 'sign_info' parameter of the 2.01 (Created) response is a CBOR 547 array of one ore more elements. The number of elements is lower or 548 at most equal to the number of groups the client has been authorized 549 to join. Each element contains information about signing parameters 550 and keys for one or more group or topic and is formatted as follows. 552 * The first element 'id' is an identifier of the group or an array 553 of identifiers for the groups for which this information applies. 555 * The second element 'sign_alg' is an integer or a text string if 556 the POST request included the 'sing_info' parameter with value 557 Null, and indicates the signature algorithm used in the group 558 identified by 'gid'. It is REQUIRED of the application profiles 559 to define specific values that this parameter can take (REQ3), 560 selected from the set of signing algorithms of the COSE Algorithms 561 registry defined in [RFC8152]. If the POST request did not 562 include the 'sing_info' parameter, this element is encoded as the 563 CBOR simple value Null. 565 * The third element 'sign_parameters' indicates the parameters of 566 the signature algorithm. Its structure depends on the value of 567 'sign_alg'. It is REQUIRED of the application profiles to define 568 specific values for this parameter (REQ4). If no parameters of 569 the signature algorithm are specified, 'sign_parameters' MUST be 570 encoded as the CBOR simple value Null. If the POST request did 571 not include the 'sing_info' parameter, this element is encoded as 572 the CBOR simple value Null. 574 * The fourth element 'sign_key_parameters' indicates the parameters 575 of the key used with the signature algorithm. Its structure 576 depends on the value of 'sign_alg'. It is REQUIRED of the 577 application profiles to define specific values for this parameter 578 (REQ5). If no parameters of the key used with the signature 579 algorithm are specified, 'sign_key_parameters' MUST be encoded as 580 the CBOR simple value Null. If the POST request did not include 581 the 'sing_info' parameter, this element is encoded as the CBOR 582 simple value Null. 584 * The fifth element 'pub_key_enc' parameter is optional and MUST 585 only be present if the POST request included the 'pub_key_enc' 586 parameter with value Null. If present, it is either a CBOR 587 integer indicating the encoding of public keys used in the group 588 identified by 'gid', or has value Null indicating that the KDC 589 does not act as repository of public keys for group members. Its 590 acceptable values are taken from the "CWT Confirmation Method" 591 Registry defined in [I-D.ietf-ace-cwt-proof-of-possession]. It is 592 REQUIRED of the application profiles to define specific values to 593 use for this parameter (REQ6). 595 The CDDL notation of the 'sign_info' parameter formatted as in the 596 response is given below, with gid formatted as a bstr (note that gid 597 can be encoded differently, see REQ1). 599 sign_info_res = [ + sign_info_entry ] 601 sign_info_entry = 602 [ 603 id : gid / [ + gid ], 604 sign_alg : int / tstr / nil, 605 sign_parameters : any / nil, 606 sign_key_parameters : any / nil, 607 ? pub_key_enc_res = int / nil 608 ] 610 gid = bstr 612 3.3.2. 'pub_key_enc' Parameter 614 The 'pub_key_enc' parameter is an OPTIONAL parameter of the AS 615 Request Creation Hints message defined in Section 5.1.2. of 616 [I-D.ietf-ace-oauth-authz]. This parameter contains information 617 about the exact encoding of public keys to be used between the Client 618 and the RS. Its exact content is application specific. 620 In this specification and in application profiles building on it, 621 this parameter is used to ask the KDC information about the encoding 622 of public keys used in the group. 624 The CDDL notation of the 'pub_key_enc' parameter formatted as in the 625 request is given below. 627 pub_key_enc_req = nil 629 3.3.3. 'kdcchallenge' Parameter 631 The 'kdcchallenge' parameter is an OPTIONAL parameter of the AS 632 Request Creation Hints message defined in Section 5.1.2. of 633 [I-D.ietf-ace-oauth-authz]. This parameter contains a challenge 634 generated by the KDC and provided to the Client. The Client may use 635 this challenge to prove possession of its own private key in the 636 Joining Request ((see the 'client_cred_verify' parameter in 637 Section 4). 639 4. Keying Material Provisioning and Group Membership Management 641 This section defines the interface available at the KDC. Moreover, 642 this section specifies how the clients can use this interface to join 643 a group, leave a group, retrieve new keying material or policies. 645 During the first exchange with the KDC ("Joining"), the Client sends 646 a request to the KDC, specifying the group it wishes to join (see 647 Section 4.2). Then, the KDC verifies the access token and that the 648 Client is authorized to join that group. If so, it provides the 649 Client with the keying material to securely communicate with the 650 other members of the group. Whenever used, the Content-Format in 651 messages containing a payload is set to application/ace- 652 groupcomm+cbor, as defined in Section 8.2. 654 When the Client is already a group member, the Client can use the 655 interface at the KDC to perform the following actions: 657 * The Client can (re-)get the current keying material, for cases 658 such as expiration, loss or suspected mismatch, due to e.g. reboot 659 or missed group rekeying. This is described in Section 4.3. 661 * The Client can retrieve a new individual key, or new input 662 material to derive it. This is described in Section 4.4. 664 * The Client can (re-)get the public keys of other group members, 665 e.g. if it is aware of new nodes joining the group after itself. 666 This is described in Section 4.5. 668 * The Client can (re-)get the policies currently enforced in the 669 group. This is described in Section 4.7. 671 * The Client can (re-)get the version number of the keying material 672 currently used in the group. This is described in Section 4.8. 674 * The Client can request to leave the group. This is further 675 discussed in Section 4.9. 677 Upon receiving a request from a Client, the KDC MUST check that it is 678 storing a valid access token from that Client for the group 679 identifier assiciated to the endpoint. If that is not the case, i.e. 680 the KDC does not store a valid access token or this is not valid for 681 that Client for the group identifier at hand, the KDC MUST respond to 682 the Client with a 4.01 (Unauthorized) error message. 684 4.1. Interface at the KDC 686 The KDC is configured with the following resources. Note that the 687 root url-path "ace-group" given here are default names: 688 implementations are not required to use these names, and can define 689 their own instead. The Interface Description (if=) Link Target 690 Attribute value ace-group is registered (Section 8.9) and can be used 691 to describe this inferface. 693 * /ace-group : this resource is fixed and indicates that this 694 specification is used. Other applications that run on a KDC 695 implementing this specification MUST NOT use this same resource. 697 * /ace-group/GROUPNAME : one sub-resource to /ace-group is 698 implemented for each group the KDC manages. These resources are 699 identified by the group identifiers of the groups the KDC manages 700 (in this example, the group identifier has value "GROUPNAME"). 701 These resources support GET and POST method. 703 * /ace-group/GROUPNAME/pub-key : this sub-resource is fixed and 704 supports GET and FETCH methods. 706 * /ace-group/GROUPNAME/policies: this sub-resource is fixed and 707 supports the GET method. 709 * /ace-group/GROUPNAME/ctx-num: this sub-resource is fixed and 710 supports the GET method. 712 * /ace-group/GROUPNAME/nodes/NODENAME: one sub-resource to /ace- 713 group/GROUPNAME is implemented for each node in the group the KDC 714 manages. These resources are identified by the node name (in this 715 example, the node name has value "NODENAME"). These resources 716 support GET, PUT and DELETE methods. 718 * /ace-group/GROUPNAME/nodes/NODENAME/pub-key: one sub-resource to 719 /ace-group/GROUPNAME/nodes/NODENAME is implemented for each node 720 in the group the KDC manages. These resources are identified by 721 the node name (in this example, the node name has value 722 "NODENAME"). These resources support the POST method. 724 The details for the handlers of each resource are given in the 725 following sections. These endpoints are used to perform the 726 operations introduced in Section 4. 728 4.1.1. ace-group 730 No handlers are implemented for this resource. 732 4.1.2. ace-group/GROUPNAME 734 This resource implements GET and POST handlers. 736 4.1.2.1. POST Handler 738 The POST handler adds the public key of the client to the list of the 739 group members' public keys and returns the symmetric group keying 740 material for the group identified by "GROUPNAME". 742 The handler expects a request with payload formatted as a CBOR map 743 which MAY contain the following fields, which, if included, MUST have 744 the corresponding values: 746 * 'scope', with value the specific resource that the Client is 747 authorized to access, i.e. group or topic identifier, and role(s). 748 This value is a CBOR byte string encoding one scope entry, as 749 defined in Section 3.1. 751 * 'get_pub_keys', if the Client wishes to receive the public keys of 752 the other nodes in the group from the KDC. The value is an empty 753 CBOR array. This parameter may be present if the KDC stores the 754 public keys of the nodes in the group and distributes them to the 755 Client; it is useless to have here if the set of public keys of 756 the members of the group is known in another way, e.g. it was 757 provided by the AS. 759 * 'client_cred', with value the public key or certificate of the 760 Client, encoded as a CBOR byte string. This field contains the 761 public key of the Client. This field is used if the KDC is 762 managing (collecting from/distributing to the Client) the public 763 keys of the group members, and if the Client's role in the group 764 will require for it to send messages to the group. The default 765 encoding for public keys is COSE Keys. Alternative specific 766 encodings of this parameter MAY be defined in applications of this 767 specification (OPT1). 769 * 'cnonce', with the same encoding as defined for the "cnonce" 770 parameter of Ace, in Section 5.1.2 of [I-D.ietf-ace-oauth-authz], 771 and including a dedicated nonce N_C generated by the Client. This 772 parameter MUST be present if the 'client_cred' parameter is 773 present. 775 * 'client_cred_verify', encoded as a CBOR byte string. This 776 parameter MUST be present if the 'client_cred' parameter is 777 present and no public key associated to the client's token can be 778 retrieved for that group. This parameter contains a signature 779 computed by the Client over the scope concatenated with N_S 780 concatenated with N_C, where: 782 - scope is the byte string specified in the 'scope parameter 783 above'. 785 - N_S is the challenge received from the KDC in the 786 'kdcchallenge' parameter of the 2.01 (Created) response to the 787 token POST request (see Section 3.3). 789 - N_C is the nonce generated by the Client and specified in the 790 'cnonce' parameter above. 792 If the token is not being posted (e.g. if it is used directly to 793 validate TLS instead), it is REQUIRED of the specific profile to 794 define how the challenge N_S is generated (REQ17). The Client 795 computes the signature by using its own private key, whose 796 corresponding public key is either directly specified in the 797 'client_cred' parameter or included in the certificate specified in 798 the 'client_cred' parameter. 800 * 'pub_keys_repos', can be present if a certificate is present in 801 the 'client_cred' field, with value the URI of the certificate of 802 the Client. This parameter is encoded as a CBOR text string. 803 Alternative specific encodings of this parameter MAY be defined in 804 applications of this specification (OPT3). 806 * 'control_path', with value a full URI, encoded as a CBOR text 807 string. If 'control_path' is supported by the Client, the Client 808 acts as a CoAP server and hosts a resource at this specific URI. 809 The KDC MAY use this URI to send CoAP requests to the Client 810 (acting as CoAP server in this exchange), for example for 811 individual provisioning of new keying material when performing a 812 group rekeying (see Section 4.3), or to inform the Client of its 813 removal from the group Section 5. If the KDC does not implement 814 mechanisms using this resource, it can just ignore this parameter. 815 Other additional functionalities of this resource MAY be defined 816 in application profiles of this specifications (OPT9). In 817 particular, this resource is intended for communications 818 concerning exclusively the group or topic specified in the 'scope' 819 parameter. 821 The handler verifies that the group identifier of the /ace-group/ 822 GROUPNAME path is a subset of the 'scope' stored in the access token 823 associated to this client. If verification fails, the KDC MUST 824 respond with a 4.01 (Unauthorized) error message. The KDC MAY set 825 the payload with the 'sign_info' and 'pub_key_enc' parameter, 826 formatted as 'sign_info_res' and 'pub_key_enc_res' in the payload of 827 the 2.01 (Created) response to the Token Post as defined in 828 Section 3.3. Note that in this case, the content format MUST be set 829 to application/ace+cbor. 831 If the request is not formatted correctly (e.g. unknown, not-expected 832 fields present, or expected fields with incorrect format), the 833 handler MUST respond with a 4.00 (Bad Request) error message. The 834 response MAY contain a CBOR map in the payload with ace+cbor format, 835 e.g. it could send back "pub_key_enc" set to Null if the Client sent 836 its own public key and the KDC is not set to store public keys of the 837 group members. Application profiles MAY define optional or mandatory 838 payload formats for specific error cases (OPT6). 840 If the KDC stores the group members' public keys, the handler checks 841 if one public key is already associated to the access token received 842 (see Section 4.2 for an example) and to the group identified by 843 "GROUPNAME". If that is not the case, it retrieves it from the 844 'client_cred' field and associates it to the access token received, 845 after verifications succed. In particular, the KDC verifies: 847 * that such public key has an acceptable format for the group 848 identified by "GROUPNAME", i.e. it is encoded as expected and is 849 compatible with the signature algorithm and possible associated 850 parameters. If that cannot be verified, it is RECOMMENDED that 851 the handler stops the process and responds with a 4.00 (Bad 852 Request) error message. Applications profiles MAY define 853 alternatives (OPT5). 855 * that the signature contained in "client_cred_verify" passes 856 verification. If that cannot be verified, the handler MUST 857 respond with a 4.00 (Bad Request) error message, and if the token 858 was posted (see REQ17) including the 'kdcchallenge' associated to 859 this Client (see Section 3.3) if it can be retrieved, or otherwise 860 newly generated, in a CBOR map in the payload. This error 861 response MUST also have Content-Format "application/ace+cbor". 863 If one public key is already associated to the access token and to 864 that group, but the 'client_cred' is populated with a different 865 public key, the handler MUST delete the previous one and replace it 866 with this one, after verifying the points above. 868 If the token was posted but the KDC cannot retrieve the 869 'kdcchallenge' associated to this Client (see Section 3.3), the KDC 870 MUST respond with a 4.00 Bad Request error response, including a 871 newly generated 'kdcchallenge' in a CBOR map in the payload. This 872 error response MUST also have Content-Format "application/ace+cbor". 874 If all verifications succeed, the handler: 876 * Adds the node to the list of current members of the group. 878 * Assigns a name NODENAME to the node, and creates a sub-resource to 879 /ace-group/GROUPNAME/ at the KDC (e.g. "/ace- 880 group/GROUPNAME/nodes/NODENAME"). 882 * Associates the identifier "NODENAME" with the access token and the 883 secure session for that node. 885 * If the KDC manages public keys for group members: 887 - Adds the retrieved public key of the node to the list of public 888 keys stored for the group identified by "GROUPNAME" 890 - Associates the node's public key with its access token and the 891 group identified by "GROUPNAME", if such association did not 892 already exist. 894 * Returns a 2.01 (Created) message containing the symmetric group 895 keying material, the group policies and all the public keys of the 896 current members of the group, if the KDC manages those and the 897 Client requested them. 899 The response message also contains the URI path to the sub-resource 900 created for that node in a Location-Path CoAP option. The payload of 901 the response is formatted as a CBOR map which MUST contain the 902 following fields and values: 904 * 'gkty', identifying the key type of the 'key' parameter. The set 905 of values can be found in the "Key Type" column of the "ACE 906 Groupcomm Key" Registry. Implementations MUST verify that the key 907 type matches the application profile being used, if present, as 908 registered in the "ACE Groupcomm Key" registry. 910 * 'key', containing the keying material for the group communication, 911 or information required to derive it. 913 * 'num', containing the version number of the keying material for 914 the group communication, formatted as an integer. The initial 915 version MUST be set to 0 at the KDC. This is a strictly monotonic 916 increasing field. 918 The exact format of the 'key' value MUST be defined in applications 919 of this specification (REQ7), as well as accepted values of 'gkty' by 920 the application (REQ8). Additionally, documents specifying the key 921 format MUST register it in the "ACE Groupcomm Key" registry defined 922 in Section 8.5, including its name, type and application profile to 923 be used with. 925 +----------+----------------+---------+-------------------------+ 926 | Name | Key Type Value | Profile | Description | 927 +----------+----------------+---------+-------------------------+ 928 | Reserved | 0 | | This value is reserved | 929 +----------+----------------+---------+-------------------------+ 931 Figure 5: Key Type Values 933 Optionally, the response MAY contain the following parameters, which, 934 if included, MUST have the corresponding values: 936 * 'ace-groupcomm-profile', with value a CBOR integer that MUST be 937 used to uniquely identify the application profile for group 938 communication. Applications of this specification MUST register 939 an application profile identifier and the related value for this 940 parameter in the "ACE Groupcomm Profile" Registry (REQ12). 942 * 'exp', with value the expiration time of the keying material for 943 the group communication, encoded as a CBOR unsigned integer. This 944 field contains a numeric value representing the number of seconds 945 from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, 946 ignoring leap seconds, analogous to what specified for NumericDate 947 in Section 2 of [RFC7519]. Group members MUST stop using the 948 keying material to protect outgoing messages and retrieve new 949 keying material at the time indicated in this field. 951 * 'exp_delta', with value the time interval (starting at 'exp') 952 during which the keying material for the group communication can 953 still be used for verifying incoming messages, encoded as a CBOR 954 unsigned integer. This field contains a numeric value 955 representing the number of seconds from 'exp' until the specified 956 UTC date/time after which group members MUST stop using the keying 957 material to verify incoming messages. 959 * 'pub_keys', may only be present if 'get_pub_keys' was present in 960 the request. This parameter is a CBOR byte string, which encodes 961 the public keys of all the group members paired with the 962 respective member identifiers. The default encoding for public 963 keys is COSE Keys, so the default encoding for 'pub_keys' is a 964 CBOR byte string wrapping a COSE_KeySet (see [RFC8152]), which 965 contains the public keys of all the members of the group. In 966 particular, each COSE Key in the COSE_KeySet includes the 967 identifier of the corresponding group member as value of its 'kid' 968 key parameter. Alternative specific encodings of this parameter 969 MAY be defined in applications of this specification (OPT1). The 970 specific format of the identifiers of group members MUST be 971 specified in the application profile (REQ9). 973 * 'peer_roles', MUST be present if 'pub_keys' is present. This 974 parameter is a CBOR array of n elements, with n the number of 975 members in the group (and number of public keys included in the 976 'pub_keys' parameter). The i-th element of the array specifies 977 the role (or CBOR array of roles) that the group member associated 978 to the i-th public key in 'pub_keys' has in the group. In 979 particular, each array element is encoded as the role element of a 980 scope entry, as defined in Section 3.1. 982 * 'group_policies', with value a CBOR map, whose entries specify how 983 the group handles specific management aspects. These include, for 984 instance, approaches to achieve synchronization of sequence 985 numbers among group members. The elements of this field are 986 registered in the "ACE Groupcomm Policy" Registry. This 987 specification defines the two elements "Sequence Number 988 Synchronization Method" and "Key Update Check Interval", which are 989 summarized in Figure 6. Application profiles that build on this 990 document MUST specify the exact content format of included map 991 entries (REQ14). 993 +--------------+-------+----------|--------------------|------------+ 994 | Name | CBOR | CBOR | Description | Reference | 995 | | label | type | | | 996 |--------------+-------+----------|--------------------|------------| 997 | Sequence | TBD1 | tstr/int | Method for a re- | [[this | 998 | Number | | | cipient node to | document]] | 999 | Synchroniza- | | | synchronize with | | 1000 | tion Method | | | sequence numbers | | 1001 | | | | of a sender node. | | 1002 | | | | Its value is taken | | 1003 | | | | from the 'Value' | | 1004 | | | | column of the | | 1005 | | | | Sequence Number | | 1006 | | | | Synchronization | | 1007 | | | | Method registry | | 1008 | | | | | | 1009 | Key Update | TBD2 | int | Polling interval | [[this | 1010 | Check | | | in seconds, to | document]] | 1011 | Interval | | | check for new | | 1012 | | | | keying material at | | 1013 | | | | the KDC | | 1014 +--------------+-------+----------|--------------------|------------+ 1016 Figure 6: ACE Groupcomm Policies 1018 * 'mgt_key_material', encoded as a CBOR byte string and containing 1019 the administrative keying material to participate in the group 1020 rekeying performed by the KDC. The application profile MUST 1021 define if this field is used, and if used then MUST specify the 1022 exact format and content which depend on the specific rekeying 1023 scheme used in the group. If the usage of 'mgt_key_material' is 1024 indicated and its format defined for a specific key management 1025 scheme, that format must explicitly indicate the key management 1026 scheme itself. If a new rekeying scheme is defined to be used for 1027 an existing 'mgt_key_material' in an existing profile, then that 1028 profile will have to be updated accordingly, especially with 1029 respect to the usage of 'mgt_key_material' related format and 1030 content (REQ18). 1032 Specific application profiles that build on this document MUST 1033 specify the communication protocol that members of the group use to 1034 communicate with each other (REQ10) and how exactly the keying 1035 material is used to protect the group communication (REQ11). 1037 CBOR labels for these fields are defined in Section 6. 1039 4.1.2.2. GET Handler 1041 The GET handler returns the symmetric group keying material for the 1042 group identified by "GROUPNAME". 1044 The handler expects a GET request. 1046 The handler verifies that the group identifier of the /ace-group/ 1047 GROUPNAME path is a subset of the 'scope' stored in the access token 1048 associated to this client. If verification fails, the KDC MUST 1049 respond with a 4.01 (Unauthorized) error message. The KDC MAY set 1050 the payload with the 'sign_info' and 'pub_key_enc' parameter, 1051 formatted as 'sign_info_res' and 'pub_key_enc_res' in the payload of 1052 the 2.01 (Created) response to the Token Post as defined in 1053 Section 3.3. Note that in this case, the content format MUST be set 1054 to application/ace+cbor. 1056 Additionally, the handler verifies that the node is a current member 1057 of the group. If verification fails, the KDC MUST respond with a 1058 4.00 (Bad Request) error message. 1060 If verification succeeds, the handler returns a 2.05 (Content) 1061 message containing the symmetric group keying material. The payload 1062 of the response is formatted as a CBOR map which MUST contain the 1063 parameters 'gkty','key' and 'num' specified in Section 4.1.2.1. 1065 The payload MAY also include the parameters 'ace-groupcomm-profile', 1066 'exp', 'exp_delta' and 'mgt_key_material' parameters specified in 1067 Section 4.1.2.1. 1069 4.1.3. ace-group/GROUPNAME/pub-key 1071 This resource implements GET and FETCH handlers. 1073 4.1.3.1. FETCH Handler 1075 The FETCH handler receives identifiers of group members for the group 1076 identified by "GROUPNAME" and returns the public keys of such group 1077 members. 1079 The handler expects a request with payload formatted as a CBOR map. 1080 The payload of this request is a CBOR Map that MUST contain the 1081 following fields: 1083 * 'get_pub_keys', whose value is a non-empty CBOR array containing 1084 two CBOR arrays: 1086 - The first array contains zero or more roles (or combination of 1087 roles) of group members for the group identified by 1088 "GROUPNAME". 1090 - The second array contains zero or more identifiers of group 1091 members for the group identified by "GROUPNAME". 1093 The CDDL definition of 'get_pub_keys' is given in Figure 7 using as 1094 example encoding: node identifier encoded as byte string, role 1095 identifier as text string, and combination of roles encoded as a CBOR 1096 array of roles. Note that the empty array is not valid for this 1097 handler, but is valid for the value of "get_pub_keys" received by the 1098 handler of POST to ace-group/GROUPNAME (see Section 4.1.2.1). 1100 id = bstr 1102 role = tstr 1104 comb_role = [ 2*role ] 1106 get_pub_keys = [ [ *(role / comb_role) ], [ *id ] ] / [ ] 1108 Figure 7: CDLL definition of get_pub_keys, using as example node 1109 identifier encoded as bstr and role as tstr 1111 The specific format of public keys as well as identifiers, roles and 1112 combination of roles of group members MUST be specified by the 1113 application profile (OPT1, REQ2, REQ9). 1115 The handler verifies that the group identifier of the /ace-group/ 1116 GROUPNAME path is a subset of the 'scope' stored in the access token 1117 associated to this client. If verification fails, the KDC MUST 1118 respond with a 4.01 (Unauthorized) error message. 1120 If verification succeeds, the handler identifies the public keys of 1121 the current group members for which either: - the role identifier 1122 matches with one of those indicated in the request (including the 1123 exact combination of roles requested), or - the identifier matches 1124 with one of those indicated in the request. 1126 Then, the handler returns a 2.05 (Content) message response with 1127 payload formatted as a CBOR map, containing only the 'pub_keys' and 1128 'peer_roles' parameters from Section 4.1.2.1. In particular, 1129 'pub_keys' encodes the list of public keys of those group members 1130 including the respective member identifiers, while 'peer_roles' 1131 encodes their respective role (or CBOR array of roles) in the group. 1133 If the KDC does not store any public key associated with the 1134 specified member identifiers, the handler returns a response with 1135 payload formatted as a CBOR byte string of zero length. The specific 1136 format of public keys as well as of identifiers of group members is 1137 specified by the application profile (OPT1, REQ9). 1139 The handler MAY enforce one of the following policies, in order to 1140 handle possible identifiers that are included in the 'get_pub_keys' 1141 parameter of the request but are not associated to any current group 1142 member. Such a policy MUST be specified by the application profile 1143 (REQ13) 1145 * The KDC silently ignores those identifiers. 1147 * The KDC retains public keys of group members for a given amount of 1148 time after their leaving, before discarding them. As long as such 1149 public keys are retained, the KDC provides them to a requesting 1150 Client. 1152 Note that this resource handlers only verify that the node is 1153 authorized by the AS to access this resource. Nodes that are not 1154 members of the group but are authorized to do signature verifications 1155 on the group messages may be allowed to access this resource, if the 1156 application needs it. 1158 4.1.3.2. GET Handler 1160 The handler expects a GET request. 1162 The handler verifies that the group identifier of the /ace-group/ 1163 GROUPNAME path is a subset of the 'scope' stored in the access token 1164 associated to this client. If verification fails, the KDC MUST 1165 respond with a 4.01 (Unauthorized) error message. 1167 If verification succeeds, the handler returns a 2.05 (Content) 1168 message containing the public keys of all the current group members, 1169 for the group identified by "GROUPNAME". The payload of the response 1170 is formatted as a CBOR map, containing only the 'pub_keys' and 1171 'peer_roles' parameters from Section 4.1.2.1. In particular, 1172 'pub_keys' encodes the list of public keys of those group members 1173 including the respective member identifiers, while 'peer_roles' 1174 encodes their respective role (or CBOR array of roles) in the group. 1176 If the KDC does not store any public key for the group, the handler 1177 returns a response with payload formatted as a CBOR byte string of 1178 zero length. The specific format of public keys as well as of 1179 identifiers of group members is specified by the application profile 1180 (OPT1, REQ9). 1182 Note that this resource handlers only verify that the node is 1183 authorized by the AS to access this resource. Nodes that are not 1184 members of the group but are authorized to do signature verifications 1185 on the group messages may be allowed to access this resource, if the 1186 application needs it. 1188 4.1.4. ace-group/GROUPNAME/policies 1190 This resource implements a GET handler. 1192 4.1.4.1. GET Handler 1194 The handler expects a GET request. 1196 The handler verifies that the group identifier of the /ace-group/ 1197 GROUPNAME path is a subset of the 'scope' stored in the access token 1198 associated to this client. If verification fails, the KDC MUST 1199 respond with a 4.01 (Unauthorized) error message. 1201 Additionally, the handler verifies that the node is a current member 1202 of the group. If verification fails, the KDC MUST respond with a 1203 4.00 (Bad Request) error message. 1205 If verification succeeds, the handler returns a 2.05 (Content) 1206 message containing the list of policies for the group identified by 1207 "GROUPNAME". The payload of the response is formatted as a CBOR map 1208 including only the parameter 'group_policies' defined in 1209 Section 4.1.2.1 and specifying the current policies in the group. If 1210 the KDC does not store any policy, the payload is formatted as a 1211 zero-length CBOR byte string. 1213 The specific format and meaning of group policies MUST be specified 1214 in the application profile (REQ14). 1216 4.1.5. ace-group/GROUPNAME/ctx-num 1218 This resource implements a GET handler. 1220 4.1.5.1. GET Handler 1222 The handler expects a GET request. 1224 The handler verifies that the group identifier of the /ace-group/ 1225 GROUPNAME path is a subset of the 'scope' stored in the access token 1226 associated to this client. If verification fails, the KDC MUST 1227 respond with a 4.01 (Unauthorized) error message. 1229 Additionally, the handler verifies that the node is a current member 1230 of the group. If verification fails, the KDC MUST respond with a 1231 4.00 (Bad Request) error message. 1233 If verification succeeds, the handler returns a 2.05 (Content) 1234 message containing an integer that represents the version number of 1235 the symmetric group keying material. This number is incremented on 1236 the KDC every time the KDC updates the symmetric group keying 1237 material. The payload of the response is formatted as a CBOR 1238 integer. 1240 4.1.6. ace-group/GROUPNAME/nodes/NODENAME 1242 This resource implements GET, PUT and DELETE handlers. 1244 4.1.6.1. PUT Handler 1246 The PUT handler is used to get the KDC to produce and return 1247 individual keying material to protect outgoing messages for the node 1248 (identified by "NODENAME") for the group identified by "GROUPNAME". 1250 The handler expects a request with empty payload. 1252 The handler verifies that the group identifier of the /ace-group/ 1253 GROUPNAME path is a subset of the 'scope' stored in the access token 1254 associated to this client, identified by "NODENAME". If verification 1255 fails, the KDC MUST respond with a 4.01 (Unauthorized) error message. 1257 Additionally, the handler verifies that the node is a current member 1258 of the group. If verification fails, the KDC MUST respond with a 1259 4.00 (Bad Request) error message. 1261 If verification succeeds, the handler returns a 2.05 (Content) 1262 message containing newly-generated individual keying material for the 1263 Client, or information enabling the Client to derive it. The payload 1264 of the response is formatted as a CBOR map. The specific format of 1265 newly-generated individual keying material for group members, or of 1266 the information to derive it, and corresponding CBOR label, MUST be 1267 specified in the application profile (REQ15) and registered in 1268 Section 8.4. 1270 4.1.6.2. GET Handler 1272 The handler expects a GET request. 1274 The handler verifies that the group identifier of the /ace-group/ 1275 GROUPNAME path is a subset of the 'scope' stored in the access token 1276 associated to this client, identified by "NODENAME". If verification 1277 fails, the KDC MUST respond with a 4.01 (Unauthorized) error message. 1279 The handler also verifies that the node sending the request and the 1280 node name used in the Uri-Path match. If that is not the case, the 1281 handler responds with a 4.01 (Unauthorized) error response. 1283 Additionally, the handler verifies that the node is a current member 1284 of the group. If verification fails, the KDC MUST respond with a 1285 4.00 (Bad Request) error message. 1287 If verification succeeds, the handler returns a 2.05 (Content) 1288 message containing both the group keying material and the individual 1289 keying material for the Client, or information enabling the Client to 1290 derive it. The payload of the response is formatted as a CBOR map. 1291 The format for the group keying material is the same as defined in 1292 the response of Section 4.1.2.2. The specific format of individual 1293 keying material for group members, or of the information to derive 1294 it, and corresponding CBOR label, MUST be specified in the 1295 application profile (REQ15) and registered in Section 8.4. 1297 4.1.6.3. DELETE Handler 1299 The DELETE handler removes the node identified by "NODENAME" from the 1300 group identified by "GROUPNAME". 1302 The handler expects a request with method DELETE (and empty payload). 1304 The handler only accept a request from the node that matches the 1305 "NODENAME" used in Uri-Path, and that is part of the "GROUPNAME" 1306 group: the handler verifies that the group identifier "GROUPNAME" is 1307 a subset of the 'scope' stored in the access token associated to this 1308 client, and that this client is identified by "NODENAME". If 1309 verification fails, the KDC MUST respond with a 4.01 (Unauthorized) 1310 error message. 1312 The handler also verifies that the node sending the request and the 1313 node name used in the Uri-Path match. If that is not the case, the 1314 handler responds with a 4.01 (Unauthorized) error response. 1316 Additionally, the handler verifies that the node is a current member 1317 of the group. If verification fails, the KDC MUST respond with a 1318 4.00 (Bad Request) error message. 1320 If verification succeeds, the handler removes the client from the 1321 group identified by "GROUPNAME", for specific roles if roles were 1322 specified in the 'scope' field, or for all roles. That includes 1323 removing the public key of the client if the KDC keep tracks of that. 1324 Then, the handler delete the sub-resource nodes/NODENAME and returns 1325 a 2.02 (Deleted) message with empty payload. 1327 4.1.7. ace-group/GROUPNAME/nodes/NODENAME/pub-key 1329 This resource implements a POST handler, if the KDC stores the public 1330 key of group members. If the KDC does not store the public keys of 1331 group members, the handler does not implement any method, and every 1332 request returns a 4.05 Method Not Allowed error. 1334 4.1.7.1. POST Handler 1336 The POST handler is used to replace the stored public key of this 1337 client (identified by "NODENAME") with the one specified in the 1338 request at the KDC, for the group identified by "GROUPNAME". 1340 The handler expects a POST request with payload as specified in 1341 Section 4.1.2.1, with the difference that it includes only the 1342 parameters 'client_cred', 'cnonce' and 'client_cred_verify'. In 1343 particular, the signature included in 'client_cred_verify' is 1344 expected to be computed as defined in Section 4.1.2.1, with a newly 1345 generated N_C nonce and the previously received N_S. The specific 1346 format of public keys is specified by the application profile (OPT1). 1348 The handler verifies that the group identifier GROUPNAME is a subset 1349 of the 'scope' stored in the access token associated to this client. 1350 If verification fails, the KDC MUST respond with a 4.01 1351 (Unauthorized) error message. 1353 If the request is not formatted correctly (e.g. unknown, not-expected 1354 fields present, or expected fields with incorrect format), the 1355 handler MUST respond with a 4.00 (Bad Request) error message. 1356 Application profiles MAY define optional or mandatory payload formats 1357 for specific error cases (OPT6). 1359 Otherwise, the handler checks that the public key specified in the 1360 'client_cred' field has a valid format for the group identified by 1361 "GROUPNAME", i.e. it is encoded as expected and is compatible with 1362 the signature algorithm and possible associated parameters. If that 1363 cannot be verified, the handler MUST respond with a 4.00 (Bad 1364 Request) error message. Applications profiles MAY define 1365 alternatives (OPT5). 1367 Otherwise, the handler verifies the signature contained in the 1368 'client_cred_verify' field of the request, using the public key 1369 specified in the 'client_cred' field. If the signature does not pass 1370 verification, the handler MUST respond with a 4.00 (Bad Request) 1371 error message. If the KDC cannot retrieve the 'kdcchallenge' 1372 associated to this Client (see Section 3.3), the KDC MUST respond 1373 with a 4.00 Bad Request error respons, including a newly generated 1374 'kdcchallenge' in a CBOR map in the payload the payload. This error 1375 response MUST also have Content-Format "application/ace+cbor". 1377 If verification succeeds, the handler replaces the old public key of 1378 the node NODENAME with the one specified in the 'client_cred' field 1379 of the request, and stores it as the new current public key of the 1380 node NODENAME, in the list of group members' public keys for the 1381 group identified by GROUPNAME. Then, the handler replies with a 2.04 1382 (Changed) response, which does not include a payload. 1384 4.2. Joining Exchange 1386 Figure 8 gives an overview of the Joining exchange between Client and 1387 KDC, when the Client first joins a group. 1389 Client KDC 1390 | | 1391 |----- Joining Request: POST /ace-group/GROUPNAME ------>| 1392 | | 1393 |<--------- Joining Response: 2.01 (Created) ----------- | 1394 | Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME" | 1396 Figure 8: Message Flow of First Exchange for Group Joining 1398 If not previously established, the Client and the KDC MUST first 1399 establish a pairwise secure communication channel (REQ16). This can 1400 be achieved, for instance, by using a transport profile of ACE. The 1401 Joining exchange MUST occur over that secure channel. The Client and 1402 the KDC MAY use that same secure channel to protect further pairwise 1403 communications that must be secured. 1405 The secure communication protocol is REQUIRED to establish the secure 1406 channel by using the proof-of-possession key bound to the access 1407 token. As a result, the proof-of-possession to bind the access token 1408 to the Client is performed by using the proof-of-possession key bound 1409 to the access token for establishing secure communication between the 1410 Client and the KDC. 1412 To join the group, the Client sends a CoAP POST request to the /ace- 1413 group/GROUPNAME endpoint at the KDC, where GROUPNAME is the group 1414 identifier of the group to join, formatted as specified in 1415 Section 4.1.2.1. This group identifier is the same as the scope 1416 entry corresponding to that group, specified in the 'scope' parameter 1417 of the Authorization Request/Response, or it can be retrieved from 1418 it. Note that, in case of successful joining, the Client will 1419 receive the URI to retrieve individual or group keying material and 1420 to leave the group in the Location-Path option of the response. 1422 If the node is joining a group for the first time, and the KDC 1423 maintains the public keys of the group members, the Client is 1424 REQUIRED to send its own public key and proof of possession 1425 ("client_cred" and "client_cred_verify" in Section 4.1.2.1). The 1426 request is only accepted if both public key and proof of possession 1427 are provided. If a node re-joins a group with the same access token 1428 and the same public key, it can omit to send the public key and the 1429 proof of possession, or just omit the proof of possession, and the 1430 KDC will be able to retrieve its public key associated to its token 1431 for that group (if the key has been discarded, the KDC will reply 1432 with 4.00 Bad Request, as specified in Section 4.1.2.1). If a node 1433 re-joins a group but wants to update its own public key, it needs to 1434 send both public key and proof of possession. 1436 If the application requires backward security, the KDC MUST generate 1437 new group keying material and securely distribute it to all the 1438 current group members, upon a new node's joining the group. To this 1439 end, the KDC uses the message format of the response defined in 1440 Section 4.1.2.2. Application profiles may define alternative ways of 1441 retrieving the keying material, such as sending separate requests to 1442 different resources at the KDC (Section 4.1.2.2, Section 4.1.3.2, 1443 Section 4.1.4.1). After distributing the new group keying material, 1444 the KDC MUST increment the version number of the keying material. 1446 4.3. Retrieval of Updated Keying Material 1448 When any of the following happens, a node MUST stop using the owned 1449 group keying material to protect outgoing messages, and SHOULD stop 1450 using it to decrypt and verify incoming messages. 1452 * Upon expiration of the keying material, according to what 1453 indicated by the KDC with the 'exp' (and possibly the 'exp_delta') 1454 parameter in a Joining Response, or to a pre-configured value. 1456 * Upon receiving a notification of revoked/renewed keying material 1457 from the KDC, possibly as part of an update of the keying material 1458 (rekeying) triggered by the KDC. 1460 * Upon receiving messages from other group members without being 1461 able to retrieve the keying material to correctly decrypt them. 1462 This may be due to rekeying messages previously sent by the KDC, 1463 that the Client was not able to receive or decrypt. 1465 In either case, if it wants to continue participating in the group 1466 communication, the node has to request the latest keying material 1467 from the KDC. To this end, the Client sends a CoAP GET request to 1468 the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, 1469 formatted as specified in Section 4.1.6.2. 1471 Note that policies can be set up, so that the Client sends a Key Re- 1472 Distribution request to the KDC only after a given number of received 1473 messages could not be decrypted (because of failed decryption 1474 processing or inability to retrieve the necessary keying material). 1476 It is application dependent and pertaining to the particular message 1477 exchange (e.g. [I-D.ietf-core-oscore-groupcomm]) to set up these 1478 policies, to instruct clients to retain incoming messages and for how 1479 long (OPT4). This allows clients to possibly decrypt such messages 1480 after getting updated keying material, rather than just consider them 1481 non valid messages to discard right away. 1483 The same Key Distribution Request could also be sent by the Client 1484 without being triggered by a failed decryption of a message, if the 1485 Client wants to be sure that it has the latest group keying material. 1486 If that is the case, the Client will receive from the KDC the same 1487 group keying material it already has in memory. 1489 Figure 9 gives an overview of the exchange described above. 1491 Client KDC 1492 | | 1493 |------------------ Key Distribution Request: --------------->| 1494 | GET ace-group/GROUPNAME/nodes/NODENAME | 1495 | | 1496 |<-------- Key Distribution Response: 2.05 (Content) ---------| 1497 | | 1499 Figure 9: Message Flow of Key Distribution Request-Response 1501 Alternatively, the re-distribution of keying material can be 1502 initiated by the KDC, which e.g.: 1504 * Can make the ace-group/GROUPNAME/nodes/NODENAME resource 1505 Observable, and send notifications to Clients when the keying 1506 material is updated. 1508 * Can send the payload of the Key Distribution Response in one or 1509 multiple multicast POST requests to the members of the group, 1510 using secure rekeying schemes such as [RFC2093][RFC2094][RFC2627]. 1512 * Can send unicast POST requests to each Client over a secure 1513 channel, with the same payload as the Key Distribution Response. 1514 When sending such requests, the KDC can target the URI path 1515 possibly provided by the intended recipient upon joining the 1516 group, as specified in the 'control_path' parameter of the Joining 1517 Request (see Section 4.1.2.1). 1519 * Can act as a publisher in a pub-sub scenario, and update the 1520 keying material by publishing on a specific topic on a broker, 1521 which all the members of the group are subscribed to. 1523 Note that these methods of KDC-initiated key distribution have 1524 different security properties and require different security 1525 associations. 1527 4.4. Retrieval of New Keying Material 1529 Beside possible expiration and depending on what part of the keying 1530 material is no longer eligible to be used, the client may need to 1531 communicate to the KDC its need for that part to be renewed. For 1532 example, if the Client uses an individual key to protect outgoing 1533 traffic and has to renew it, the node may request a new one, or new 1534 input material to derive it, without renewing the whole group keying 1535 material. 1537 To this end, the client performs a Key Renewal Request/Response 1538 exchange with the KDC, i.e. it sends a CoAP PUT request to the /ace- 1539 group/GROUPNAME/nodes/NODENAME endpoint at the KDC, where GROUPNAME 1540 is the group identifier and NODENAME is the node's name, and 1541 formatted as defined in Section 4.1.6.2. 1543 Figure 10 gives an overview of the exchange described above. 1545 Client KDC 1546 | | 1547 |------------------ Key Renewal Request: -------------->| 1548 | PUT ace-group/GROUPNAME/nodes/NODENAME | 1549 | | 1550 |<-------- Key Renewal Response: 2.05 (Content) --------| 1551 | | 1553 Figure 10: Message Flow of Key Renewal Request-Response 1555 Note the difference between the Key Distribution Request and the Key 1556 Renewal Request: while the first one only triggers distribution (the 1557 renewal might have happened independently, e.g. because of 1558 expiration), the second one triggers the KDC to produce new 1559 individual keying material for the requesting node. 1561 Furthermore, policies can be set up so that, upon receiving a Key 1562 Renewal Request, the KDC replies to the client with an error 1563 response, and then performs a complete group rekeying (OPT8). 1565 4.5. Retrieval of Public Keys and Roles for Group Members 1567 In case the KDC maintains the public keys of group members, a node in 1568 the group can contact the KDC to request public keys and roles of 1569 either all group members or a specified subset, by sending a CoAP GET 1570 or FETCH request to the /ace-group/GROUPNAME/pub-key endpoint at the 1571 KDC, where GROUPNAME is the group identifier, and formatted as 1572 defined in Section 4.1.3.2 and Section 4.1.3.1. 1574 When receiving a Public Key Response, the requesting group member 1575 stores (or updates) the public keys (in the 'pub_keys' parameter) and 1576 roles (in the 'peer_roles' parameter) of the group members. 1578 Figure 11 and Figure 12 give an overview of the exchanges described 1579 above. 1581 Client KDC 1582 | | 1583 |--Public Key Request: GET /ace-group/GROUPNAME/pub-key->| 1584 | | 1585 |<--------- Public Key Response: 2.05 (Content) ---------| 1586 | | 1588 Figure 11: Message Flow of Public Key Exchange to Request All 1589 Members Public Keys 1591 Client KDC 1592 | | 1593 |-Public Key Request: FETCH /ace-group/GROUPNAME/pub-key->| 1594 | | 1595 |<--------- Public Key Response: 2.05 (Created) ----------| 1596 | | 1598 Figure 12: Message Flow of Public Key Exchange to Request 1599 Specific Members Public Keys 1601 4.6. Update of Public Key 1603 In case the KDC maintains the public keys of group members, a node in 1604 the group can contact the KDC to upload a new public key to use in 1605 the group, and replace the currently stored one. 1607 To this end, the Client performs a Public Key Update Request/Response 1608 exchange with the KDC, i.e. it sends a CoAP POST request to the /ace- 1609 group/GROUPNAME/nodes/NODENAME/pub-key endpoint at the KDC, where 1610 GROUPNAME is the group identifier and NODENAME is the node's name. 1612 The request is formatted as specified in Section 4.1.7.1. 1614 Figure Figure 13 gives an overview of the exchange described above. 1616 Client KDC 1617 | | 1618 |-------------- Public Key Update Request: ---------------------->| 1619 | POST ace-group/GROUPNAME/nodes/NODENAME/pub-key | 1620 | | 1621 |<------- Public Key Update Response: 2.04 (Changed) -------------| 1622 | | 1624 Figure 13: Message Flow of Public Key Update Request-Response 1626 If the application requires backward security, the KDC MUST generate 1627 new group keying material and securely distribute it to all the 1628 current group members, upon a group member updating its own public 1629 key. To this end, the KDC uses the message format of the response 1630 defined in Section 4.1.2.2. Application profiles may define 1631 alternative ways of retrieving the keying material, such as sending 1632 separate requests to different resources at the KDC (Section 4.1.2.2, 1633 Section 4.1.3.2, Section 4.1.4.1). After distributing the new group 1634 keying material, the KDC MUST increment the version number of the 1635 keying material. 1637 Additionally, after updating its own public key, a group member MAY 1638 send a number of the later requests including an identifier of the 1639 updated public key, to signal nodes that they need to retrieve it. 1640 How that is done depends on the group communication protocol used, 1641 and therefore is application profile specific (OPT10). 1643 4.7. Retrieval of Group Policies 1645 A node in the group can contact the KDC to retrieve the current group 1646 policies, by sending a CoAP GET request to the /ace-group/GROUPNAME/ 1647 policies endpoint at the KDC, where GROUPNAME is the group 1648 identifier, and formatted as defined in Section 4.1.4.1 1650 Figure 14 gives an overview of the exchange described above. 1652 Client KDC 1653 | | 1654 |-Policies Request: GET ace-group/GROUPNAME/policies ->| 1655 | | 1656 |<--------- Policies Response: 2.05 (Content) ---------| 1657 | | 1659 Figure 14: Message Flow of Policies Request-Response 1661 4.8. Retrieval of Keying Material Version 1663 A node in the group can contact the KDC to request information about 1664 the version number of the symmetric group keying material, by sending 1665 a CoAP GET request to the /ace-group/GROUPNAME/ctx-num endpoint at 1666 the KDC, where GROUPNAME is the group identifier, formatted as 1667 defined in Section 4.1.5.1. In particular, the version is 1668 incremented by the KDC every time the group keying material is 1669 renewed. 1671 Figure 15 gives an overview of the exchange described above. 1673 Client KDC 1674 | | 1675 |-- Version Request: GET ace-group/GROUPNAME/ctx-num -->| 1676 | | 1677 |<--------- Version Response: 2.05 (Content) -----------| 1678 | | 1680 Figure 15: Message Flow of Version Request-Response 1682 4.9. Group Leaving Request 1684 A node can actively request to leave the group. In this case, the 1685 Client sends a CoAP DELETE request to the endpoint /ace- 1686 group/GROUPNAME/nodes/NODENAME at the KDC, where GROUPNAME is the 1687 group identifier and NODENAME is the node's name, formatted as 1688 defined in Section 4.1.6.3 1690 Alternatively, a node may be removed by the KDC, without having 1691 explicitly asked for it. This is further discussed in Section 5. 1693 5. Removal of a Node from the Group 1695 This section describes the different scenarios according to which a 1696 node ends up being removed from the group. 1698 If the application requires forward security, the KDC MUST generate 1699 new group keying material and securely distribute it to all the 1700 current group members but the leaving node, using the message format 1701 of the Key Distribution Response (see Section 4.3). Application 1702 profiles may define alternative message formats. Once distributed 1703 the new group keying material, the KDC MUST increment the version 1704 number of the keying material. 1706 Note that, after having left the group, a node may wish to join it 1707 again. Then, as long as the node is still authorized to join the 1708 group, i.e. it still has a valid access token, it can re-request to 1709 join the group directly to the KDC without needing to retrieve a new 1710 access token from the AS. This means that the KDC might decide to 1711 keep track of nodes with valid access tokens, before deleting all 1712 information about the leaving node. 1714 A node may be evicted from the group in the following cases. 1716 1. The node explicitly asks to leave the group, as defined in 1717 Section 4.9. 1719 2. The node has been found compromised or is suspected so. 1721 3. The node's authorization to be a group member is not valid 1722 anymore, either because the access token has expired, or it has 1723 been revoked. If the AS provides Token introspection (see 1724 Section 5.7 of [I-D.ietf-ace-oauth-authz]), the KDC can 1725 optionally use it and check whether the node is still authorized 1726 for that group in that role. 1728 In either case, once aware that a node is not authorized anymore, the 1729 KDC has to remove the unauthorized node from the list of group 1730 members, if the KDC keeps track of that. 1732 In case of forced eviction, the KDC MAY explicitly inform the leaving 1733 node, if the Client implements the 'control_path' resource specified 1734 in Section 4.1.2.1. To this end, the KDC MAY send a DEL request, 1735 targeting the URI specified in the 'control_path' parameter of the 1736 Joining Request. 1738 6. ACE Groupcomm Parameters 1740 This specification defines a number of fields used during the second 1741 part of the message exchange, after the ACE Token POST exchange. The 1742 table below summarizes them, and specifies the CBOR key to use 1743 instead of the full descriptive name. Note that the media type ace- 1744 groupcomm+cbor MUST be used when these fields are transported. 1746 +-----------------------+------+---------------+------------------+ 1747 | Name | CBOR | CBOR Type | Reference | 1748 | | Key | | | 1749 +=======================+======+===============+==================+ 1750 | scope | TBD | byte string | Section 4.1.2.1 | 1751 +-----------------------+------+---------------+------------------+ 1752 | get_pub_keys | TBD | array | Section 4.1.2.1, | 1753 | | | | Section 4.1.3.1 | 1754 +-----------------------+------+---------------+------------------+ 1755 | client_cred | TBD | byte string | Section 4.1.2.1 | 1756 +-----------------------+------+---------------+------------------+ 1757 | cnonce | TBD | byte string | Section 4.1.2.1 | 1758 +-----------------------+------+---------------+------------------+ 1759 | client_cred_verify | TBD | byte string | Section 4.1.2.1 | 1760 +-----------------------+------+---------------+------------------+ 1761 | pub_keys_repos | TBD | text string | Section 4.1.2.1 | 1762 +-----------------------+------+---------------+------------------+ 1763 | control_path | TBD | text string | Section 4.1.2.1 | 1764 +-----------------------+------+---------------+------------------+ 1765 | gkty | TBD | int / text | Section 4.1.2.1 | 1766 | | | string | | 1767 +-----------------------+------+---------------+------------------+ 1768 | key | TBD | see "ACE | Section 4.1.2.1 | 1769 | | | Groupcomm | | 1770 | | | Key" Registry | | 1771 +-----------------------+------+---------------+------------------+ 1772 | num | TBD | int | Section 4.1.2.1 | 1773 +-----------------------+------+---------------+------------------+ 1774 | ace-groupcomm-profile | TBD | int | Section 4.1.2.1 | 1775 +-----------------------+------+---------------+------------------+ 1776 | exp | TBD | int | Section 4.1.2.1 | 1777 +-----------------------+------+---------------+------------------+ 1778 | exp_delta | TBD | int | Section 4.1.2.1 | 1779 +-----------------------+------+---------------+------------------+ 1780 | pub_keys | TBD | byte string | Section 4.1.2.1 | 1781 +-----------------------+------+---------------+------------------+ 1782 | peer_roles | TBD | array | Section 4.1.2.1 | 1783 +-----------------------+------+---------------+------------------+ 1784 | group_policies | TBD | map | Section 4.1.2.1 | 1785 +-----------------------+------+---------------+------------------+ 1786 | mgt_key_material | TBD | byte string | Section 4.1.2.1 | 1787 +-----------------------+------+---------------+------------------+ 1789 Table 1 1791 7. Security Considerations 1793 When a Client receives a message from a sender for the first time, it 1794 needs to have a mechanism in place to avoid replay, e.g. 1795 Appendix B.2 of [RFC8613]. In case the Client rebooted and lost the 1796 security state used to protect previous communication with that 1797 sender, such a mechanism is useful for the recipient to be on the 1798 safe side. If the group has renewed its group keying material, the 1799 time window between the end of the rekeying process and the next loss 1800 of security state is safe for recipients, as replayed older messages 1801 protected with previous keying material will not be accepted. 1803 The KDC must renew the group keying material upon its expiration. 1805 The KDC should renew the keying material upon group membership 1806 change, and should provide it to the current group members through 1807 the rekeying scheme used in the group. 1809 The KDC may enforce a rekeying policy that takes into account the 1810 overall time required to rekey the group, as well as the expected 1811 rate of changes in the group membership. 1813 That is, the KDC may not rekey the group at every membership change, 1814 for instance if members' joining and leaving occur frequently and 1815 performing a group rekeying takes too long. Instead, the KDC may 1816 rekey the group after a minimum number of group members have joined 1817 or left within a given time interval, or during predictable network 1818 inactivity periods. 1820 However, this would result in the KDC not constantly preserving 1821 backward and forward security. In fact, newly joining group members 1822 could be able to access the keying material used before their 1823 joining, and thus could access past group communications. Also, 1824 until the KDC performs a group rekeying, the newly leaving nodes 1825 would still be able to access upcoming group communications that are 1826 protected with the keying material that has not yet been updated. 1828 The KDC needs to have a mechanism in place to detect DoS attacks from 1829 nodes constantly initiating rekeys (for example by updating their 1830 public key), such as removing these nodes from the group. 1832 7.1. Update of Keying Material 1834 A group member can receive a message shortly after the group has been 1835 rekeyed, and new keying material has been distributed by the KDC. In 1836 the following two cases, this may result in misaligned keying 1837 material between the group members. 1839 In the first case, the sender protects a message using the old keying 1840 material. However, the recipient receives the message after having 1841 received the new keying material, hence not being able to correctly 1842 process it. A possible way to ameliorate this issue is to preserve 1843 the old, recent, keying material for a maximum amount of time defined 1844 by the application. By doing so, the recipient can still try to 1845 process the received message using the old retained keying material 1846 as second attempt. Note that a former (compromised) group member can 1847 take advantage of this by sending messages protected with the old 1848 retained keying material. Therefore, a conservative application 1849 policy should not admit the storage of old keying material. 1851 In the second case, the sender protects a message using the new 1852 keying material, but the recipient receives that request before 1853 having received the new keying material. Therefore, the recipient 1854 would not be able to correctly process the request and hence discards 1855 it. If the recipient receives the new keying material shortly after 1856 that and the application at the sender endpoint performs 1857 retransmissions, the former will still be able to receive and 1858 correctly process the message. In any case, the recipient should 1859 actively ask the KDC for an updated keying material according to an 1860 application-defined policy, for instance after a given number of 1861 unsuccessfully decrypted incoming messages. 1863 A node that has left the group should not expect any of its outgoing 1864 messages to be successfully processed, if received after its leaving, 1865 due to a possible group rekeying occurred before the message 1866 reception. 1868 7.2. Block-Wise Considerations 1870 If the block-wise options [RFC7959] are used, and the keying material 1871 is updated in the middle of a block-wise transfer, the sender of the 1872 blocks just changes the keying material to the updated one and 1873 continues the transfer. As long as both sides get the new keying 1874 material, updating the keying material in the middle of a transfer 1875 will not cause any issue. Otherwise, the sender will have to 1876 transmit the message again, when receiving an error message from the 1877 recipient. 1879 Compared to a scenario where the transfer does not use block-wise, 1880 depending on how fast the keying material is changed, the nodes might 1881 consume a larger amount of the network bandwidth resending the blocks 1882 again and again, which might be problematic. 1884 8. IANA Considerations 1886 This document has the following actions for IANA. 1888 8.1. Media Type Registrations 1890 This specification registers the 'application/ace-groupcomm+cbor' 1891 media type for messages of the protocols defined in this document 1892 following the ACE exchange and carrying parameters encoded in CBOR. 1893 This registration follows the procedures specified in [RFC6838]. 1895 Type name: application 1897 Subtype name: ace-groupcomm+cbor 1899 Required parameters: none 1901 Optional parameters: none 1903 Encoding considerations: Must be encoded as CBOR map containing the 1904 protocol parameters defined in [this document]. 1906 Security considerations: See Section 7 of this document. 1908 Interoperability considerations: n/a 1910 Published specification: [this document] 1912 Applications that use this media type: The type is used by 1913 authorization servers, clients and resource servers that support the 1914 ACE groupcomm framework as specified in [this document]. 1916 Additional information: 1918 Magic number(s): n/a 1920 File extension(s): .ace-groupcomm 1922 Macintosh file type code(s): n/a 1924 Person & email address to contact for further information: 1925 iesg@ietf.org (mailto:iesg@ietf.org) 1927 Intended usage: COMMON 1929 Restrictions on usage: None 1930 Author: Francesca Palombini francesca.palombini@ericsson.com 1931 (mailto:francesca.palombini@ericsson.com) 1933 Change controller: IESG 1935 8.2. CoAP Content-Formats Registry 1937 This specification registers the following entry to the "CoAP 1938 Content-Formats" registry, within the "CoRE Parameters" registry: 1940 Media Type: application/ace-groupcomm+cbor 1942 Encoding: - 1944 ID: TBD 1946 Reference: [this document] 1948 8.3. ACE Authorization Server Request Creation Hints Registry 1950 IANA is asked to register the following entries in the "ACE 1951 Authorization Server Request Creation Hints" Registry defined in 1952 Section 8.1 of [I-D.ietf-ace-oauth-authz]. 1954 * Name: sign_info 1956 * CBOR Key: TBD (range -256 to 255) 1958 * Value Type: any 1960 * Reference: [[This specification]] 1962 * Name: pub_key_enc 1964 * CBOR Key: TBD (range -256 to 255) 1966 * Value Type: integer 1968 * Reference: [[This specification]] 1970 * Name: kdcchallenge 1972 * CBOR Key: TBD (range -256 to 255) 1974 * Value Type: byte string 1976 * Reference: [[This specification]] 1978 8.4. ACE Groupcomm Parameters Registry 1980 This specification establishes the "ACE Groupcomm Parameters" IANA 1981 Registry. The Registry has been created to use the "Expert Review 1982 Required" registration procedure [RFC8126]. Expert review guidelines 1983 are provided in Section 8.10. 1985 The columns of this Registry are: 1987 * Name: This is a descriptive name that enables easier reference to 1988 the item. The name MUST be unique. It is not used in the 1989 encoding. 1991 * CBOR Key: This is the value used as CBOR key of the item. These 1992 values MUST be unique. The value can be a positive integer, a 1993 negative integer, or a string. 1995 * CBOR Type: This contains the CBOR type of the item, or a pointer 1996 to the registry that defines its type, when that depends on 1997 another item. 1999 * Reference: This contains a pointer to the public specification for 2000 the item. 2002 This Registry has been initially populated by the values in 2003 Section 6. The Reference column for all of these entries refers to 2004 sections of this document. 2006 8.5. ACE Groupcomm Key Registry 2008 This specification establishes the "ACE Groupcomm Key" IANA Registry. 2009 The Registry has been created to use the "Expert Review Required" 2010 registration procedure [RFC8126]. Expert review guidelines are 2011 provided in Section 8.10. 2013 The columns of this Registry are: 2015 * Name: This is a descriptive name that enables easier reference to 2016 the item. The name MUST be unique. It is not used in the 2017 encoding. 2019 * Key Type Value: This is the value used to identify the keying 2020 material. These values MUST be unique. The value can be a 2021 positive integer, a negative integer, or a text string. 2023 * Profile: This field may contain one or more descriptive strings of 2024 application profiles to be used with this item. The values should 2025 be taken from the Name column of the "ACE Groupcomm Profile" 2026 Registry. 2028 * Description: This field contains a brief description of the keying 2029 material. 2031 * References: This contains a pointer to the public specification 2032 for the format of the keying material, if one exists. 2034 This Registry has been initially populated by the values in Figure 5. 2035 The specification column for all of these entries will be this 2036 document. 2038 8.6. ACE Groupcomm Profile Registry 2040 This specification establishes the "ACE Groupcomm Profile" IANA 2041 Registry. The Registry has been created to use the "Expert Review 2042 Required" registration procedure [RFC8126]. Expert review guidelines 2043 are provided in Section 8.10. It should be noted that, in addition 2044 to the expert review, some portions of the Registry require a 2045 specification, potentially a Standards Track RFC, be supplied as 2046 well. 2048 The columns of this Registry are: 2050 * Name: The name of the application profile, to be used as value of 2051 the profile attribute. 2053 * Description: Text giving an overview of the application profile 2054 and the context it is developed for. 2056 * CBOR Value: CBOR abbreviation for the name of this application 2057 profile. Different ranges of values use different registration 2058 policies [RFC8126]. Integer values from -256 to 255 are 2059 designated as Standards Action. Integer values from -65536 to 2060 -257 and from 256 to 65535 are designated as Specification 2061 Required. Integer values greater than 65535 are designated as 2062 Expert Review. Integer values less than -65536 are marked as 2063 Private Use. 2065 * Reference: This contains a pointer to the public specification of 2066 the abbreviation for this application profile, if one exists. 2068 8.7. ACE Groupcomm Policy Registry 2070 This specification establishes the "ACE Groupcomm Policy" IANA 2071 Registry. The Registry has been created to use the "Expert Review 2072 Required" registration procedure [RFC8126]. Expert review guidelines 2073 are provided in Section 8.10. It should be noted that, in addition 2074 to the expert review, some portions of the Registry require a 2075 specification, potentially a Standards Track RFC, be supplied as 2076 well. 2078 The columns of this Registry are: 2080 * Name: The name of the group communication policy. 2082 * CBOR label: The value to be used to identify this group 2083 communication policy. Key map labels MUST be unique. The label 2084 can be a positive integer, a negative integer or a string. 2085 Integer values between 0 and 255 and strings of length 1 are 2086 designated as Standards Track Document required. Integer values 2087 from 256 to 65535 and strings of length 2 are designated as 2088 Specification Required. Integer values of greater than 65535 and 2089 strings of length greater than 2 are designated as expert review. 2090 Integer values less than -65536 are marked as private use. 2092 * CBOR type: the CBOR type used to encode the value of this group 2093 communication policy. 2095 * Description: This field contains a brief description for this 2096 group communication policy. 2098 * Reference: This field contains a pointer to the public 2099 specification providing the format of the group communication 2100 policy, if one exists. 2102 This registry will be initially populated by the values in Figure 6. 2104 8.8. Sequence Number Synchronization Method Registry 2106 This specification establishes the "Sequence Number Synchronization 2107 Method" IANA Registry. The Registry has been created to use the 2108 "Expert Review Required" registration procedure [RFC8126]. Expert 2109 review guidelines are provided in Section 8.10. It should be noted 2110 that, in addition to the expert review, some portions of the Registry 2111 require a specification, potentially a Standards Track RFC, be 2112 supplied as well. 2114 The columns of this Registry are: 2116 * Name: The name of the sequence number synchronization method. 2118 * Value: The value to be used to identify this sequence number 2119 synchronization method. 2121 * Description: This field contains a brief description for this 2122 sequence number synchronization method. 2124 * Reference: This field contains a pointer to the public 2125 specification describing the sequence number synchronization 2126 method. 2128 8.9. Interface Description (if=) Link Target Attribute Values Registry 2130 This specification registers the following entry to the "Interface 2131 Description (if=) Link Target Attribute Values Registry" registry, 2132 within the "CoRE Parameters" registry: 2134 * Attribute Value: ace-group 2136 * Description: The 'ace group' interface is used to provision keying 2137 material and related informations and policies to members of a 2138 group using the Ace framework. 2140 * Reference: [This Document] 2142 8.10. Expert Review Instructions 2144 The IANA Registries established in this document are defined as 2145 expert review. This section gives some general guidelines for what 2146 the experts should be looking for, but they are being designated as 2147 experts for a reason so they should be given substantial latitude. 2149 Expert reviewers should take into consideration the following points: 2151 * Point squatting should be discouraged. Reviewers are encouraged 2152 to get sufficient information for registration requests to ensure 2153 that the usage is not going to duplicate one that is already 2154 registered and that the point is likely to be used in deployments. 2155 The zones tagged as private use are intended for testing purposes 2156 and closed environments, code points in other ranges should not be 2157 assigned for testing. 2159 * Specifications are required for the standards track range of point 2160 assignment. Specifications should exist for specification 2161 required ranges, but early assignment before a specification is 2162 available is considered to be permissible. Specifications are 2163 needed for the first-come, first-serve range if they are expected 2164 to be used outside of closed environments in an interoperable way. 2165 When specifications are not provided, the description provided 2166 needs to have sufficient information to identify what the point is 2167 being used for. 2169 * Experts should take into account the expected usage of fields when 2170 approving point assignment. The fact that there is a range for 2171 standards track documents does not mean that a standards track 2172 document cannot have points assigned outside of that range. The 2173 length of the encoded value should be weighed against how many 2174 code points of that length are left, the size of device it will be 2175 used on, and the number of code points left that encode to that 2176 size. 2178 9. References 2180 9.1. Normative References 2182 [I-D.ietf-ace-cwt-proof-of-possession] 2183 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 2184 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 2185 Web Tokens (CWTs)", Work in Progress, Internet-Draft, 2186 draft-ietf-ace-cwt-proof-of-possession-11, 31 October 2187 2019, . 2190 [I-D.ietf-ace-oauth-authz] 2191 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 2192 H. Tschofenig, "Authentication and Authorization for 2193 Constrained Environments (ACE) using the OAuth 2.0 2194 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 2195 draft-ietf-ace-oauth-authz-33, 6 February 2020, 2196 . 2199 [I-D.ietf-ace-oauth-params] 2200 Seitz, L., "Additional OAuth Parameters for Authorization 2201 in Constrained Environments (ACE)", Work in Progress, 2202 Internet-Draft, draft-ietf-ace-oauth-params-13, 28 April 2203 2020, . 2206 [I-D.ietf-core-oscore-groupcomm] 2207 Tiloca, M., Selander, G., Palombini, F., and J. Park, 2208 "Group OSCORE - Secure Group Communication for CoAP", Work 2209 in Progress, Internet-Draft, draft-ietf-core-oscore- 2210 groupcomm-08, 6 April 2020, . 2213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2214 Requirement Levels", BCP 14, RFC 2119, 2215 DOI 10.17487/RFC2119, March 1997, 2216 . 2218 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2219 Specifications and Registration Procedures", BCP 13, 2220 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2221 . 2223 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2224 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2225 October 2013, . 2227 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2228 Writing an IANA Considerations Section in RFCs", BCP 26, 2229 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2230 . 2232 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 2233 RFC 8152, DOI 10.17487/RFC8152, July 2017, 2234 . 2236 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2237 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2238 May 2017, . 2240 9.2. Informative References 2242 [I-D.dijk-core-groupcomm-bis] 2243 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 2244 for the Constrained Application Protocol (CoAP)", Work in 2245 Progress, Internet-Draft, draft-dijk-core-groupcomm-bis- 2246 03, 9 March 2020, . 2249 [I-D.ietf-ace-dtls-authorize] 2250 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 2251 L. Seitz, "Datagram Transport Layer Security (DTLS) 2252 Profile for Authentication and Authorization for 2253 Constrained Environments (ACE)", Work in Progress, 2254 Internet-Draft, draft-ietf-ace-dtls-authorize-09, 18 2255 December 2019, . 2258 [I-D.ietf-ace-mqtt-tls-profile] 2259 Sengul, C., Kirby, A., and P. Fremantle, "MQTT-TLS profile 2260 of ACE", Work in Progress, Internet-Draft, draft-ietf-ace- 2261 mqtt-tls-profile-04, 9 March 2020, . 2264 [I-D.ietf-ace-oscore-profile] 2265 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 2266 "OSCORE profile of the Authentication and Authorization 2267 for Constrained Environments Framework", Work in Progress, 2268 Internet-Draft, draft-ietf-ace-oscore-profile-10, 9 March 2269 2020, . 2272 [I-D.ietf-core-coap-pubsub] 2273 Koster, M., Keranen, A., and J. Jimenez, "Publish- 2274 Subscribe Broker for the Constrained Application Protocol 2275 (CoAP)", Work in Progress, Internet-Draft, draft-ietf- 2276 core-coap-pubsub-09, 30 September 2019, 2277 . 2280 [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management 2281 Protocol (GKMP) Specification", RFC 2093, 2282 DOI 10.17487/RFC2093, July 1997, 2283 . 2285 [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management 2286 Protocol (GKMP) Architecture", RFC 2094, 2287 DOI 10.17487/RFC2094, July 1997, 2288 . 2290 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 2291 Multicast: Issues and Architectures", RFC 2627, 2292 DOI 10.17487/RFC2627, June 1999, 2293 . 2295 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2296 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2297 January 2012, . 2299 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 2300 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 2301 . 2303 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 2304 the Constrained Application Protocol (CoAP)", RFC 7959, 2305 DOI 10.17487/RFC7959, August 2016, 2306 . 2308 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2309 Interchange Format", STD 90, RFC 8259, 2310 DOI 10.17487/RFC8259, December 2017, 2311 . 2313 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 2314 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 2315 May 2018, . 2317 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2318 "Object Security for Constrained RESTful Environments 2319 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2320 . 2322 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 2323 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 2324 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2325 2020, . 2327 Appendix A. Requirements on Application Profiles 2329 This section lists the requirements on application profiles of this 2330 specification,for the convenience of application profile designers. 2332 * REQ1: Specify the encoding and value of the identifier of group or 2333 topic, for scope entries of 'scope' (see Section 3.1). 2335 * REQ2: Specify the encoding and value of roles, for scope entries 2336 of 'scope' (see Section 3.1). 2338 * REQ3: If used, specify the acceptable values for 'sign_alg' (see 2339 Section 3.3). 2341 * REQ4: If used, specify the acceptable values for 'sign_parameters' 2342 (see Section 3.3). 2344 * REQ5: If used, specify the acceptable values for 2345 'sign_key_parameters' (see Section 3.3). 2347 * REQ6: If used, specify the acceptable values for 'pub_key_enc' 2348 (see Section 3.3). 2350 * REQ7: Specify the exact format of the 'key' value (see 2351 Section 4.1.2.1). 2353 * REQ8: Specify the acceptable values of 'gkty' (see 2354 Section 4.1.2.1). 2356 * REQ9: Specify the format of the identifiers of group members (see 2357 Section 4.1.2.1). 2359 * REQ10: Specify the communication protocol the members of the group 2360 must use (e.g., multicast CoAP). 2362 * REQ11: Specify the security protocol the group members must use to 2363 protect their communication (e.g., group OSCORE). This must 2364 provide encryption, integrity and replay protection. 2366 * REQ12: Specify and register the application profile identifier 2367 (see Section 4.1.2.1). 2369 * REQ13: Specify policies at the KDC to handle ids that are not 2370 included in get_pub_keys (see Section 4.1.3.1). 2372 * REQ14: If used, specify the format and content of 'group_policies' 2373 and its entries (see Section 4.1.2.1). 2375 * REQ15: Specify the format of newly-generated individual keying 2376 material for group members, or of the information to derive it, 2377 and corresponding CBOR label (see Section 4.1.6.2). 2379 * REQ16: Specify how the communication is secured between Client and 2380 KDC. Optionally, specify tranport profile of ACE 2381 [I-D.ietf-ace-oauth-authz] to use between Client and KDC (see 2382 Section 4.2. 2384 * REQ17: Specify how the nonce N_S is generated, if the token is not 2385 being posted (e.g. if it is used directly to validate TLS 2386 instead). 2388 * REQ18: Specify if 'mgt_key_material' used, and if yes specify its 2389 format and content (see Section 4.1.2.1). If the usage of 2390 'mgt_key_material' is indicated and its format defined for a 2391 specific key management scheme, that format must explicitly 2392 indicate the key management scheme itself. If a new rekeying 2393 scheme is defined to be used for an existing 'mgt_key_material' in 2394 an existing profile, then that profile will have to be updated 2395 accordingly, especially with respect to the usage of 2396 'mgt_key_material' related format and content. 2398 * OPT1: Optionally, specify the encoding of public keys, of 2399 'client_cred', and of 'pub_keys' if COSE_Keys are not used (see 2400 Section 4.1.2.1). 2402 * OPT2: Optionally, specify the negotiation of parameter values for 2403 signature algorithm and signature keys, if 'sign_info' and 2404 'pub_key_enc' are not used (see Section 3.3). 2406 * OPT3: Optionally, specify the encoding of 'pub_keys_repos' if the 2407 default is not used (see Section 4.1.2.1). 2409 * OPT4: Optionally, specify policies that instruct clients to retain 2410 messages and for how long, if they are unsuccessfully decrypted 2411 (see Section 4.3). This makes it possible to decrypt such 2412 messages after getting updated keying material. 2414 * OPT5: Optionally, specify the behavior of the handler in case of 2415 failure to retrieve a public key for the specific node (see 2416 Section 4.1.2.1). 2418 * OPT6: Optionally, specify possible or required payload formats for 2419 specific error cases. 2421 * OPT7: Optionally, specify CBOR values to use for abbreviating 2422 identifiers of roles in the group or topic (see Section 3.1). 2424 * OPT8: Optionally, specify policies for the KDC to perform group 2425 rekeying after receiving a Key Renewal Request (see Section 4.4). 2427 * OPT9: Optionally, specify the functionalities implemented at the 2428 'control_path' resource hosted at the Client, including message 2429 exchange encoding and other details (see Section 4.1.2.1). 2431 * OPT10: Optionally, specify how the identifier of the sender's 2432 public key is included in the group request (see Section 4.6). 2434 Appendix B. Document Updates 2436 RFC EDITOR: PLEASE REMOVE THIS SECTION. 2438 B.1. Version -04 to -05 2440 * Updated uppercase/lowercase URI segments for KDC resources. 2442 * Supporting single Access Token for multiple groups/topics. 2444 * Added 'control_path' parameter in the Joining Request. 2446 * Added 'peer_roles' parameter to support legal requesters/ 2447 responders. 2449 * Clarification on stopping using owned keying material. 2451 * Clarification on different reasons for processing failures, 2452 related policies, and requirement OPT4. 2454 * Added a KDC sub-resource for group members to upload a new public 2455 key. 2457 * Possible group rekeying following an individual Key Renewal 2458 Request. 2460 * Clarified meaning of requirement REQ3; added requirement OPT8. 2462 * Editorial improvements. 2464 B.2. Version -03 to -04 2466 * Revised RESTful interface, as to methods and parameters. 2468 * Extended processing of joining request, as to check/retrieval of 2469 public keys. 2471 * Revised and extended profile requirements. 2473 * Clarified specific usage of parameters related to signature 2474 algorithms/keys. 2476 * Included general content previously in draft-ietf-ace-key- 2477 groupcomm-oscore 2479 * Registration of media type and content format application/ace- 2480 group+cbor 2482 * Editorial improvements. 2484 B.3. Version -02 to -03 2486 * Exchange of information on the countersignature algorithm and 2487 related parameters, during the Token POST (Section 3.3). 2489 * Restructured KDC interface, with new possible operations 2490 (Section 4). 2492 * Client PoP signature for the Joining Request upon joining 2493 (Section 4.1.2.1). 2495 * Revised text on group member removal (Section 5). 2497 * Added more profile requirements (Appendix A). 2499 B.4. Version -01 to -02 2501 * Editorial fixes. 2503 * Distinction between transport profile and application profile 2504 (Section 1.1). 2506 * New parameters 'sign_info' and 'pub_key_enc' to negotiate 2507 parameter values for signature algorithm and signature keys 2508 (Section 3.3). 2510 * New parameter 'type' to distinguish different Key Distribution 2511 Request messages (Section 4.1). 2513 * New parameter 'client_cred_verify' in the Key Distribution Request 2514 to convey a Client signature (Section 4.1). 2516 * Encoding of 'pub_keys_repos' (Section 4.1). 2518 * Encoding of 'mgt_key_material' (Section 4.1). 2520 * Improved description on retrieval of new or updated keying 2521 material (Section 6). 2523 * Encoding of 'get_pub_keys' in Public Key Request (Section 7.1). 2525 * Extended security considerations (Sections 10.1 and 10.2). 2527 * New "ACE Public Key Encoding" IANA Registry (Section 11.2). 2529 * New "ACE Groupcomm Parameters" IANA Registry (Section 11.3), 2530 populated with the entries in Section 8. 2532 * New "Ace Groupcomm Request Type" IANA Registry (Section 11.4), 2533 populated with the values in Section 9. 2535 * New "ACE Groupcomm Policy" IANA Registry (Section 11.7) populated 2536 with two entries "Sequence Number Synchronization Method" and "Key 2537 Update Check Interval" (Section 4.2). 2539 * Improved list of requirements for application profiles 2540 (Appendix A). 2542 B.5. Version -00 to -01 2544 * Changed name of 'req_aud' to 'audience' in the Authorization 2545 Request (Section 3.1). 2547 * Defined error handling on the KDC (Sections 4.2 and 6.2). 2549 * Updated format of the Key Distribution Response as a whole 2550 (Section 4.2). 2552 * Generalized format of 'pub_keys' in the Key Distribution Response 2553 (Section 4.2). 2555 * Defined format for the message to request leaving the group 2556 (Section 5.2). 2558 * Renewal of individual keying material and methods for group 2559 rekeying initiated by the KDC (Section 6). 2561 * CBOR type for node identifiers in 'get_pub_keys' (Section 7.1). 2563 * Added section on parameter identifiers and their CBOR keys 2564 (Section 8). 2566 * Added request types for requests to a Join Response (Section 9). 2568 * Extended security considerations (Section 10). 2570 * New IANA registries "ACE Groupcomm Key Registry", "ACE Groupcomm 2571 Profile Registry", "ACE Groupcomm Policy Registry" and "Sequence 2572 Number Synchronization Method Registry" (Section 11). 2574 * Added appendix about requirements for application profiles of ACE 2575 on group communication (Appendix A). 2577 Acknowledgments 2579 The following individuals were helpful in shaping this document: 2580 Carsten Bormann, Rikard Hoeglund, Ben Kaduk, John Mattsson, Daniel 2581 Migault, Jim Schaad, Ludwig Seitz, Goeran Selander and Peter van der 2582 Stok. 2584 The work on this document has been partly supported by VINNOVA and 2585 the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact 2586 Initiative ACTIVE. 2588 Authors' Addresses 2589 Francesca Palombini 2590 Ericsson AB 2591 Torshamnsgatan 23 2592 SE-16440 Stockholm Kista 2593 Sweden 2595 Email: francesca.palombini@ericsson.com 2597 Marco Tiloca 2598 RISE AB 2599 Isafjordsgatan 22 2600 SE-16440 Stockholm Kista 2601 Sweden 2603 Email: marco.tiloca@ri.se