idnits 2.17.1 draft-ietf-ace-key-groupcomm-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 15 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 15, 2020) is 1556 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1897 -- Looks like a reference, but probably isn't: '2' on line 1899 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-29 == Outdated reference: A later version (-16) exists of draft-ietf-ace-oauth-params-11 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-06 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-03) exists of draft-dijk-core-groupcomm-bis-02 == 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-03 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-08 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 4 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: July 18, 2020 RISE AB 6 January 15, 2020 8 Key Provisioning for Group Communication using ACE 9 draft-ietf-ace-key-groupcomm-04 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 July 18, 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 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Authorization to Join a Group . . . . . . . . . . . . . . . . 6 55 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 7 56 3.2. Authorization Response . . . . . . . . . . . . . . . . . 8 57 3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 9 58 4. Keying Material Provisioning and Group Membership Management 12 59 4.1. Interface at KDC . . . . . . . . . . . . . . . . . . . . 13 60 4.2. Joining Exchange . . . . . . . . . . . . . . . . . . . . 23 61 4.3. Retrieval of Updated Keying Material . . . . . . . . . . 24 62 4.4. Retrieval of New Keying Material . . . . . . . . . . . . 26 63 4.5. Retrieval of Public Keys for Group Members . . . . . . . 26 64 4.6. Retrieval of Group Policies . . . . . . . . . . . . . . . 27 65 4.7. Retrieval of Keying Material Version . . . . . . . . . . 27 66 4.8. Group Leaving Request . . . . . . . . . . . . . . . . . . 28 67 5. Removal of a Node from the Group . . . . . . . . . . . . . . 28 68 6. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 29 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 70 7.1. Update of Keying Material . . . . . . . . . . . . . . . . 31 71 7.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 31 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 73 8.1. Media Type Registrations . . . . . . . . . . . . . . . . 32 74 8.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 33 75 8.3. ACE Authorization Server Request Creation Hints Registry 33 76 8.4. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 34 77 8.5. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 34 78 8.6. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 35 79 8.7. ACE Groupcomm Policy Registry . . . . . . . . . . . . . . 36 80 8.8. Sequence Number Synchronization Method Registry . . . . . 36 81 8.9. Expert Review Instructions . . . . . . . . . . . . . . . 37 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 38 84 9.2. Informative References . . . . . . . . . . . . . . . . . 39 85 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 40 86 Appendix A. Requirements on Application Profiles . . . . . . . . 41 87 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 43 88 B.1. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 43 89 B.2. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 43 90 B.3. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 43 91 B.4. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 44 92 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 45 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 95 1. Introduction 97 This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to 98 define the message exchanges used to request, distribute and renew 99 the keying material in a group communication scenario, e.g. based on 100 multicast [RFC7390][I-D.dijk-core-groupcomm-bis] or on publishing- 101 subscribing [I-D.ietf-core-coap-pubsub]. The ACE framework is based 102 on CBOR [RFC7049], so CBOR is the format used in this specification. 103 However, using JSON [RFC8259] instead of CBOR is possible, using the 104 conversion method specified in Sections 4.1 and 4.2 of [RFC7049]. 106 Profiles that use group communication can build on this document, by 107 defining a number of details such as the exact group communication 108 protocol and security protocols used. The specific list of details a 109 profile needs to define is shown in Appendix A. 111 If the application requires backward and forward security, updated 112 keying material is generated and distributed to the group members 113 (rekeying), when membership changes. A key management scheme 114 performs the actual distribution of the updated keying material to 115 the group. In particular, the key management scheme rekeys the 116 current group members when a new node joins the group, and the 117 remaining group members when a node leaves the group. Rekeying 118 mechanisms can be based on [RFC2093], [RFC2094] and [RFC2627]. 120 1.1. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in BCP 125 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 Readers are expected to be familiar with the terms and concepts 129 described in [I-D.ietf-ace-oauth-authz] and [RFC8152], such as 130 Authorization Server (AS) and Resource Server (RS). 132 This document additionally uses the following terminology: 134 o Transport profile, to indicate a profile of ACE as per 135 Section 5.6.4.3 of [I-D.ietf-ace-oauth-authz]. A transport 136 profile specifies the communication protocol and communication 137 security protocol between an ACE Client and Resource Server, as 138 well as proof-of-possession methods, if it supports proof-of- 139 possession access tokens, etc. Tranport profiles of ACE include, 140 for instance, [I-D.ietf-ace-oscore-profile], 141 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-mqtt-tls-profile]. 143 o Application profile, that defines how applications enforce and use 144 supporting security services they require. These services may 145 include, for instance, provisioning, revocation and 146 (re-)distribution of keying material. An application profile may 147 define specific procedures and message formats. 149 2. Overview 151 +------------+ +-----------+ 152 | AS | | KDC | 153 | | .-------->| | 154 +------------+ / +-----------+ 155 ^ / 156 | / 157 v / +-----------+ 158 +------------+ / +------------+ |+-----------+ 159 | Client |<-' | Dispatcher | ||+-----------+ 160 | |<-------->| (RS) |<------->|| Group | 161 +------------+ +------------+ +| members | 162 +-----------+ 164 Figure 1: Key Distribution Participants 166 The following participants (see Figure 1) take part in the 167 authorization and key distribution. 169 o Client (C): node that wants to join the group communication. It 170 can request write and/or read rights. 172 o Authorization Server (AS): same as AS in the ACE Framework; it 173 enforces access policies, and knows if a node is allowed to join a 174 given group with write and/or read rights. 176 o Key Distribution Center (KDC): maintains the keying material to 177 protect group communications, and provides it to Clients 178 authorized to join a given group. During the first part of the 179 exchange (Section 3), it takes the role of the RS in the ACE 180 Framework. During the second part (Section 4), which is not based 181 on the ACE Framework, it distributes the keying material. In 182 addition, it provides the latest keying material to group members 183 when requested or, if required by the application, when membership 184 changes. 186 o Dispatcher: entity through which the Clients communicate with the 187 group and which distributes messages to the group members. 188 Examples of dispatchers are: the Broker node in a pub-sub setting; 189 a relayer node for group communication that delivers group 190 messages as multiple unicast messages to all group members; an 191 implicit entity as in a multicast communication setting, where 192 messages are transmitted to a multicast IP address and delivered 193 on the transport channel. 195 This document specifies a mechanism for: 197 o Authorizing a new node to join the group (Section 3), and 198 providing it with the group keying material to communicate with 199 the other group members (Section 4). 201 o A node to leave the group of for the KDC to remove a current 202 member of the group (Section 5). 204 o Retrieving keying material as a current group member (Section 4.3 205 and Section 4.4). 207 o Renewing and re-distributing the group keying material (rekeying) 208 upon a membership change in the group (Section 4.8 and Section 5). 210 Figure 2 provides a high level overview of the message flow for a 211 node joining a group communication setting, which can be expanded as 212 follows. 214 1. The joining node requests an Access Token from the AS, in order 215 to access a specific group-membership resource on the KDC and 216 hence join the associated group. The joining node will start or 217 continue using a secure communication association with the KDC, 218 according to the response from the AS. 220 2. The joining node transfers authentication and authorization 221 information to the KDC, by posting the obtained Access Token to 222 the /authz-info endpoint at the KDC. After that, a joining node 223 MUST have a secure communication association established with the 224 KDC, before starting to join a group under that KDC. Possible 225 ways to provide a secure communication association are DTLS 226 [RFC6347] and OSCORE [RFC8613]. 228 3. The joining node starts the joining process to become a member of 229 the group, by accessing the related group-membership resource at 230 the KDC. At the end of the joining process, the joining node has 231 received from the KDC the parameters and keying material to 232 securely communicate with the other members of the group. 234 4. The joining node and the KDC maintain the secure association, to 235 support possible future communications. These especially include 236 key management operations, such as retrieval of updated keying 237 material or participation to a group rekeying process. 239 C AS KDC Group 240 | | | Member 241 / | | | | 242 | | Authorization Request | | | 243 Defined | |---------------------------->| | | 244 in the | | | | | 245 ACE | | Authorization Response | | | 246 framework | |<----------------------------| | | 247 | | | | 248 \ |----------- Token Post ---------->| | 249 | | | 250 |-------- Joining Request -------->| | 251 | | | 252 |<------- Joining Response --------|-- Group Rekeying -->| 253 | | | 254 | Dispatcher | 255 | | | 256 |<====== Secure group communication ========|===========>| 257 | | | 259 Figure 2: Message Flow Upon New Node's Joining 261 The exchange of Authorization Request and Authorization Response 262 between Client and AS MUST be secured, as specified by the transport 263 profile of ACE used between Client and KDC. 265 The exchange of Joining Request and Joining Response between Client 266 and KDC MUST be secured, as a result of the transport profile of ACE 267 used between Client and KDC. 269 All further communications between the Client and the KDC MUST be 270 secured, for instance with the same security mechanism used for the 271 Key Distribution exchange. 273 All communications between a Client and the other group members MUST 274 be secured using the keying material provided in Section 4. 276 3. Authorization to Join a Group 278 This section describes in detail the format of messages exchanged by 279 the participants when a node requests access to a group. This 280 exchange is based on ACE [I-D.ietf-ace-oauth-authz]. 282 As defined in [I-D.ietf-ace-oauth-authz], the Client requests from 283 the AS an authorization to join the group through the KDC (see 284 Section 3.1). If the request is approved and authorization is 285 granted, the AS provides the Client with a proof-of-possession access 286 token and parameters to securely communicate with the KDC (see 287 Section 3.2). 289 Communications between the Client and the AS MUST be secured, as 290 defined by the transport profile of ACE used. The Content-Format 291 used in the messages is the one specified by the used transport 292 profile of ACE (e.g. application/ace+cbor for the first two messages 293 and application/cwt for the third message, depending on the format of 294 the access token). The transport profile of ACE also defines a 295 number of details such as the communication and security protocols 296 used with the KDC (see Appendix C of [I-D.ietf-ace-oauth-authz]). 298 Figure 3 gives an overview of the exchange described above. 300 Client AS KDC 301 | | | 302 |---- Authorization Request: POST /token ------>| | 303 | | | 304 |<--- Authorization Response: 2.01 (Created) ---| | 305 | | | 306 |----- POST Token: POST /authz-info --------------->| 307 | | 309 Figure 3: Message Flow of Join Authorization 311 3.1. Authorization Request 313 The Authorization Request sent from the Client to the AS is as 314 defined in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MAY 315 contain the following parameters, which, if included, MUST have the 316 corresponding values: 318 o 'scope', containing the identifier of the specific group (or topic 319 in the case of pub-sub) that the Client wishes to access, and 320 optionally the role(s) that the Client wishes to take. This value 321 is a CBOR array encoded as a byte string, which contains: 323 * As first element, the identifier of the specific group or 324 topic. 326 * Optionally, as second element, the role (or CBOR array of 327 roles) the Client wishes to take in the group. 329 The encoding of the group or topic identifier (REQ1) and of the 330 role identifiers (REQ2) is application specific, and part of the 331 requirements for the application profile. 333 o 'audience', with an identifier of a KDC. 335 o 'req_cnf', as defined in Section 3.1 of 336 [I-D.ietf-ace-oauth-params], optionally containing the public key 337 or a reference to the public key of the Client, if it wishes to 338 communicate that to the AS. 340 o Other additional parameters as defined in 341 [I-D.ietf-ace-oauth-authz], if necessary. 343 As in [I-D.ietf-ace-oauth-authz], these parameters are included in 344 the payload, which is formatted as a CBOR map. The Content-Format 345 "application/ace+cbor" defined in Section 8.14 of 346 [I-D.ietf-ace-oauth-authz] is used. 348 3.2. Authorization Response 350 The Authorization Response sent from the AS to the Client is as 351 defined in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST 352 contain the following parameters: 354 o 'access_token', containing the proof-of-possession access token. 356 o 'cnf' if symmetric keys are used, not present if asymmetric keys 357 are used. This parameter is defined in Section 3.2 of 358 [I-D.ietf-ace-oauth-params] and contains the symmetric proof-of- 359 possession key that the Client is supposed to use with the KDC. 361 o 'rs_cnf' if asymmetric keys are used, not present if symmetric 362 keys are used. This parameter is as defined in Section 3.2 of 363 [I-D.ietf-ace-oauth-params] and contains information about the 364 public key of the KDC. 366 o 'exp', contains the lifetime in seconds of the access token. This 367 parameter MAY be omitted if the application defines how the 368 expiration time is communicated to the Client via other means, or 369 if it establishes a default value. 371 Additionally, the Authorization Response MAY contain the following 372 parameters, which, if included, MUST have the corresponding values: 374 o 'scope', which mirrors the 'scope' parameter in the Authorization 375 Request (see Section 3.1). Its value is a CBOR array encoded as a 376 byte string, containing: 378 * As first element, the identifier of the specific group or topic 379 the Client is authorized to access. 381 * Optionally, as second element, the role (or CBOR array of 382 roles) the Client is authorized to take in the group. 384 The encoding of the group or topic identifier and of the role 385 identifiers is the same as in Section 3.1. 387 o Other additional parameters as defined in 388 [I-D.ietf-ace-oauth-authz], if necessary. 390 The access token MUST contain all the parameters defined above 391 (including the same 'scope' as in this message, if present, or the 392 'scope' of the Authorization Request otherwise), and additionally 393 other optional parameters that the transport profile of ACE requires. 395 As in [I-D.ietf-ace-oauth-authz], these parameters are included in 396 the payload, which is formatted as a CBOR map. The Content-Format 397 "application/ace+cbor" is used. 399 When receiving an Authorization Request from a Client that was 400 previously authorized, and which still owns a valid non expired 401 access token, the AS replies with an Authorization Response with a 402 new access token. 404 3.3. Token Post 406 The Client sends a CoAP POST request including the access token to 407 the KDC, as specified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. 408 If the specific transport profile of ACE defines it, the Client MAY 409 use a different endpoint than /authz-info at the KDC to post the 410 access token to. 412 Optionally, the Client might want to request necessary information 413 concerning the public keys in the group, as well as concerning the 414 algorithm and related parameters for computing signatures in the 415 group. In such a case, the joining node MAY ask for that information 416 to the KDC in this same request. To this end, it sends the CoAP POST 417 request to the /authz-info endpoint using the Content-Format 418 "application/ace+cbor". The payload of the message MUST be formatted 419 as a CBOR map, including the access token and the following 420 parameters: 422 o 'sign_info' defined in Section 3.3.1, encoding the CBOR simple 423 value Null, to require information and parameters on the signature 424 algorithm and on the public keys used in the group. 426 o 'pub_key_enc' defined in Section 3.3.2, encoding the CBOR simple 427 value Null, to require information on the exact encoding of public 428 keys used in the group. 430 The CDDL notation of the 'sign_info' and 'pub_key_enc' parameters 431 formatted as in the request is given below. 433 sign_info_req = nil 435 pub_key_enc_req = nil 437 Alternatively, the joining node may retrieve this information by 438 other means. 440 After successful verification, the Client is authorized to receive 441 the group keying material from the KDC and join the group. In 442 particular, the KDC replies to the Client with a 2.01 (Created) 443 response, using Content-Format "application/ace+cbor" defined in 444 Section 8.14 of [I-D.ietf-ace-oauth-authz]. 446 The payload of the 2.01 response is a CBOR map, which MUST include 447 the parameter 'rsnonce' defined in Section Section 3.3.3, specifying 448 a dedicated nonce N_S generated by the KDC. The Client may use this 449 nonce for proving possession of its own private key (see the 450 'client_cred_verify' parameter in Section 4). Note that the payload 451 format of the response deviates from the default as defined in the 452 ACE framework (see Section 5.8.1 of [I-D.ietf-ace-oauth-authz]). 454 Optionally, if they were included in the request, the KDC MAY include 455 the 'sign_info' parameter as well as the 'pub_key_enc' parameter 456 defined in Section 3.3.1 and Section 3.3.2 of this specification, 457 respectively. 459 The 'sign_info' parameter MUST be present if the POST request 460 included the 'sign_info' parameter with value Null. If present, the 461 'sign_info' parameter of the 2.01 (Created) response is a CBOR array 462 formatted as follows. 464 o The first element 'sign_alg' is an integer or a text string, 465 indicating the signature algorithm used in the group. It is 466 REQUIRED of the application profiles to define specific values for 467 this parameter (REQ3). 469 o The second element 'sign_parameters' indicates the parameters of 470 the signature algorithm. Its structure depends on the value of 471 'sign_alg'. It is REQUIRED of the application profiles to define 472 specific values for this parameter (REQ4). If no parameters of 473 the signature algorithm are specified, 'sign_parameters' MUST be 474 encoded as the CBOR simple value Null. 476 o The third element 'sign_key_parameters' indicates the parameters 477 of the key used with the signature algorithm. Its structure 478 depends on the value of 'sign_alg'. It is REQUIRED of the 479 application profiles to define specific values for this parameter 480 (REQ5). If no parameters of the key used with the signature 481 algorithm are specified, 'sign_key_parameters' MUST be encoded as 482 the CBOR simple value Null. 484 The 'pub_key_enc' parameter MUST be present if the POST request 485 included the 'pub_key_enc' parameter with value Null. If present, 486 the 'pub_key_enc' parameter of the 2.01 (Created) response is either 487 a CBOR integer indicating the encoding of public keys used in the 488 group, or has value Null indicating that the KDC does not act as 489 repository of public keys for group members. 491 Its acceptable values are taken from the "CWT Confirmation Method" 492 Registry defined in [I-D.ietf-ace-cwt-proof-of-possession]. It is 493 REQUIRED of the application profiles to define specific values to use 494 for this parameter (REQ6). 496 The CDDL notation of the 'sign_info' and 'pub_key_enc' parameters 497 formatted as in the response is given below. 499 sign_info_res = [ 500 sign_alg : int / tstr, 501 sign_parameters : any / nil, 502 sign_key_parameters : any / nil 503 ] 505 pub_key_enc_res = int / nil 507 Note that the CBOR map specified as payload of the 2.01 (Created) 508 response may include further parameters, e.g. according to the 509 signalled transport profile of ACE. 511 Applications of this specification MAY define alternative specific 512 negotiations of parameter values for signature algorithm and 513 signature keys, if 'sign_info' and 'pub_key_enc' are not used (OPT2). 515 3.3.1. 'sign_info' Parameter 517 The 'sign_info' parameter is an OPTIONAL parameter of the AS Request 518 Creation Hints message defined in Section 5.1.2. of 519 [I-D.ietf-ace-oauth-authz]. This parameter contains information and 520 parameters about the signature algorithm and the public keys to be 521 used between the Client and the RS. Its exact content is application 522 specific. 524 In this specification and in application profiles building on it, 525 this parameter is used to ask and retrieve from the KDC information 526 about the signature algorithm and related parameters used in the 527 group. 529 3.3.2. 'pub_key_enc' Parameter 531 The 'pub_key_enc' parameter is an OPTIONAL parameter of the AS 532 Request Creation Hints message defined in Section 5.1.2. of 533 [I-D.ietf-ace-oauth-authz]. This parameter contains information 534 about the exact encoding of public keys to be used between the Client 535 and the RS. Its exact content is application specific. 537 In this specification and in application profiles building on it, 538 this parameter is used to ask and retrieve from the KDC information 539 about the encoding of public keys used in the group. 541 3.3.3. 'rsnonce' Parameter 543 The 'rsnonce' parameter is an OPTIONAL parameter of the AS Request 544 Creation Hints message defined in Section 5.1.2. of 545 [I-D.ietf-ace-oauth-authz]. This parameter contains a nonce 546 generated by the RS and provided to the Client. Its exact content is 547 application specific. 549 In this specification and in application profiles building on it, 550 this parameter is used to provide a nonce that the Client may use to 551 prove possession of its own private key in the Joining Request ((see 552 the 'client_cred_verify' parameter in Section 4). 554 4. Keying Material Provisioning and Group Membership Management 556 This section defines the interface available at the KDC. Moreover, 557 this section specifies how the clients can use this interface to join 558 a group, leave a group, retrieve new keying material or policies. 560 During the first exchange with the KDC ("Joining"), the Client sends 561 a request to the KDC, specifying the group it wishes to join (see 562 Section 4.2). Then, the KDC verifies the access token and that the 563 Client is authorized to join that group. If so, it provides the 564 Client with the keying material to securely communicate with the 565 other members of the group. Whenever used, the Content-Format in 566 messages containing a payload is set to application/ace- 567 groupcomm+cbor, as defined in Section 8.2. 569 When the Client is already a group member, the Client can use the 570 interface at the KDC to perform the following actions: 572 o The Client can (re-)get the current keying material, for cases 573 such as expiration, loss or suspected mismatch, due to e.g. reboot 574 or missed group rekeying. This is described in Section 4.3. 576 o The Client can retrieve a new individual key, or new input 577 material to derive it. This is described in Section 4.4. 579 o The Client can (re-)get the public keys of other group members, 580 e.g. if it is aware of new nodes joining the group after itself. 581 This is described in Section 4.5. 583 o The Client can (re-)get the policies currently enforced in the 584 group. This is described in Section 4.6. 586 o The Client can (re-)get the version number of the keying material 587 currently used in the group. This is described in Section 4.7. 589 o The Client can request to leave the group. This is further 590 discussed in Section 4.8. 592 Upon receiving a request from a Client, the KDC MUST check that it is 593 storing a valid access token from that Client for the group 594 identifier assiciated to the endpoint. If that is not the case, i.e. 595 the KDC does not store a valid access token or this is not valid for 596 that Client for the group identifier at hand, the KDC MUST respond to 597 the Client with a 4.01 (Unauthorized) error message. 599 4.1. Interface at KDC 601 The KDC is configured with the following resources: 603 o /ace-group : this resource is fixed and indicates that this 604 specification is used. Other applications that run on a KDC 605 implementing this specification MUST NOT use this same resource. 607 o /ace-group/gid : one sub-resource to /ace-group is implemented for 608 each group the KDC manages. These resources are identified by the 609 group identifiers of the groups the KDC manages (in this example, 610 the group identifier has value "gid"). These resources support 611 GET and POST method. 613 o /ace-group/gid/pub-key : this sub-resource is fixed and supports 614 GET and FETCH methods. 616 o /ace-group/gid/policies: this sub-resource is fixed and supports 617 the GET method. 619 o /ace-group/gid/ctx-num: this sub-resource is fixed and supports 620 the GET method. 622 o /ace-group/gid/node: one sub-resource to /ace-group/gid is 623 implemented for each node in the group the KDC manages. These 624 resources are identified by the node name (in this example, the 625 node name has value "node"). These resources support GET, PUT and 626 DELETE methods. 628 The details for the handlers of each resource are given in the 629 following sections. These endpoints are used to perform the 630 operations introduced in Section 4. Note that the url-path given 631 here are default names: implementations are not required to use these 632 names, and can define their own instead. 634 4.1.1. ace-group 636 No handlers are implemented for this resource. 638 4.1.2. ace-group/gid 640 This resource implements GET and POST handlers. 642 4.1.2.1. POST Handler 644 The POST handler adds the public key of the client to the list of the 645 group members' public keys and returns the symmetric group keying 646 material for the group identified by "gid". 648 The handler expects a request with payload formatted as a CBOR map 649 which MAY contain the following fields, which, if included, MUST have 650 the corresponding values: 652 o 'scope', with value the specific resource that the Client is 653 authorized to access (i.e. group or topic identifier) and role(s), 654 encoded as in Section 3.1. 656 o 'get_pub_keys', if the Client wishes to receive the public keys of 657 the other nodes in the group from the KDC. The value is an empty 658 CBOR array. This parameter may be present if the KDC stores the 659 public keys of the nodes in the group and distributes them to the 660 Client; it is useless to have here if the set of public keys of 661 the members of the group is known in another way, e.g. it was 662 provided by the AS. 664 o 'client_cred', with value the public key or certificate of the 665 Client, encoded as a CBOR byte string. This field contains the 666 public key of the Client. This field is used if the KDC is 667 managing (collecting from/distributing to the Client) the public 668 keys of the group members, and if the Client's role in the group 669 will require for it to send messages to the group. The default 670 encoding for public keys is COSE Keys. Alternative specific 671 encodings of this parameter MAY be defined in applications of this 672 specification (OPT1). 674 o 'cnonce', as defined in Section 5.1.2 of 675 [I-D.ietf-ace-oauth-authz], and including a dedicated nonce N_C 676 generated by the Client. This parameter MUST be present if the 677 'client_cred' parameter is present. 679 o 'client_cred_verify', encoded as a CBOR byte string. This 680 parameter MUST be present if the 'client_cred' parameter is 681 present. This parameter contains a signature computed by the 682 Client over N_S concatenated with N_C, where N_S is the nonce 683 received from the KDC in the 'rsnonce' parameter of the 2.01 684 (Created) response to the token POST request (see Section 3.3), 685 while N_C is the nonce generated by the Client and specified in 686 the 'cnonce' parameter above. If the token is not being posted 687 (e.g. if it is used directly to validate TLS instead), it is 688 REQUIRED of the specific profile to define how the nonce N_S is 689 generated (REQ17). The Client computes the signature by using its 690 own private key, whose corresponding public key is either directly 691 specified in the 'client_cred' parameter or included in the 692 certificate specified in the 'client_cred' parameter. 694 o 'pub_keys_repos', can be present if a certificate is present in 695 the 'client_cred' field, with value the URI of the certificate of 696 the Client. This parameter is encoded as a CBOR text string. 697 Alternative specific encodings of this parameter MAY be defined in 698 applications of this specification (OPT3). 700 The handler verifies that the group identifier of the /ace-group/gid 701 path is a subset of the 'scope' stored in the access token associated 702 to this client. If verification fails, the KDC MUST respond with a 703 4.01 (Unauthorized) error message. The KDC MAY set the payload with 704 the 'sign_info' and 'pub_key_enc' parameter, formatted as 705 'sign_info_res' and 'pub_key_enc_res' in the payload of the 2.01 706 (Created) response to the Token Post as defined in Section 3.3. Note 707 that in this case, the content format MUST be set to application/ 708 ace+cbor. 710 If the request is not formatted correctly (e.g. unknown, not-expected 711 fields present, or expected fields with incorrect format), the 712 handler MUST respond with 4.00 (Bad Request) error message. The 713 response MAY contain a CBOR map in the payload with ace- 714 groupcomm+cbor format, e.g. it could send back "pub_key_enc" set to 715 Null if the Client sent its own public key and the KDC is not set to 716 store public keys of the group members. Application profiles MAY 717 define optional or mandatory payload formats for specific error cases 718 (OPT6). 720 If the KDC stores the group members' public keys, the handler 721 verifies that one public key can be retrieved for the joining node, 722 either from the 'client_cred' field, or from the KDC previous 723 knowledge of it. In particular, the KDC checks that such public key 724 has an accepted format for the group identified by "gid", i.e. it is 725 encoded as expected and is compatible with the signature algorithm 726 and possible associated parameters. If that cannot be verified, it 727 is RECOMMENDED that the handler stops the joining process and 728 responds with 4.00 (Bad Request) error message. Applications 729 profiles MAY define alternatives (OPT5). 731 If the signature contained in "client_cred_verify" does not pass 732 verification, the handler MUST respond with 4.00 (Bad Request) error 733 message. 735 If verification succeeds, the handler adds the retrieved public key 736 of the joining node to the list of public keys stored for the group 737 identified by "gid". Moreover, the handler assigns a name to the 738 node (e.g. "node1"), and creates a sub-resource to /ace-group/gid/ at 739 the KDC (e.g. "/ace-group/gid/node1"). The handler returns a 2.01 740 (Created) message containing the symmetric group keying material, the 741 group policies and all the public keys of the current members of the 742 group, if the KDC manages those and the Client requested them. The 743 response message also contains the URI path to the sub-resource 744 created for that node in a Location-Path CoAP option. The payload of 745 the response is formatted as a CBOR map which MAY contain the 746 following fields, which, if included, MUST have the corresponding 747 values: 749 o 'gkty', identifying the key type of the 'key' parameter. The set 750 of values can be found in the "Key Type" column of the "ACE 751 Groupcomm Key" Registry. Implementations MUST verify that the key 752 type matches the application profile being used, if present, as 753 registered in the "ACE Groupcomm Key" registry. 755 o 'key', containing the keying material for the group communication, 756 or information required to derive it. 758 o 'num', containing the version number of the keying material for 759 the group communication, formatted as an integer. The initial 760 version MUST be set to 0 at the KDC. This is a strictly monotonic 761 increasing field. 763 The exact format of the 'key' value MUST be defined in applications 764 of this specification (REQ7), as well as accepted values of 'gkty' by 765 the application (REQ8). Additionally, documents specifying the key 766 format MUST register it in the "ACE Groupcomm Key" registry defined 767 in Section 8.5, including its name, type and application profile to 768 be used with. 770 +----------+----------------+---------+-------------------------+ 771 | Name | Key Type Value | Profile | Description | 772 +----------+----------------+---------+-------------------------+ 773 | Reserved | 0 | | This value is reserved | 774 +----------+----------------+---------+-------------------------+ 776 Figure 4: Key Type Values 778 Optionally, the response MAY contain the following parameters, which, 779 if included, MUST have the corresponding values: 781 o 'ace-groupcomm-profile', with value a CBOR integer that MUST be 782 used to uniquely identify the application profile for group 783 communication. Applications of this specification MUST register 784 an application profile identifier and the related value for this 785 parameter in the "ACE Groupcomm Profile" Registry (REQ12). 787 o 'exp', with value the expiration time of the keying material for 788 the group communication, encoded as a CBOR unsigned integer or 789 floating-point number. This field contains a numeric value 790 representing the number of seconds from 1970-01-01T00:00:00Z UTC 791 until the specified UTC date/time, ignoring leap seconds, 792 analogous to what specified in Section 2 of [RFC7519]. 794 o 'pub_keys', may only be present if 'get_pub_keys' was present in 795 the request. This parameter is a CBOR byte string, which encodes 796 the public keys of all the group members paired with the 797 respective member identifiers. The default encoding for public 798 keys is COSE Keys, so the default encoding for 'pub_keys' is a 799 CBOR byte string wrapping a COSE_KeySet (see [RFC8152]), which 800 contains the public keys of all the members of the group. In 801 particular, each COSE Key in the COSE_KeySet includes the 802 identifier of the corresponding group member as value of its 'kid' 803 key parameter. Alternative specific encodings of this parameter 804 MAY be defined in applications of this specification (OPT1). The 805 specific format of the identifiers of group members MUST be 806 specified in the application profile (REQ9). 808 o 'group_policies', with value a CBOR map, whose entries specify how 809 the group handles specific management aspects. These include, for 810 instance, approaches to achieve synchronization of sequence 811 numbers among group members. The elements of this field are 812 registered in the "ACE Groupcomm Policy" Registry. This 813 specification defines the two elements "Sequence Number 814 Synchronization Method" and "Key Update Check Interval", which are 815 summarized in Figure 5. Application profiles that build on this 816 document MUST specify the exact content format of included map 817 entries (REQ14). 819 +-----------------+-------+----------|--------------------|------------+ 820 | Name | CBOR | CBOR | Description | Reference | 821 | | label | type | | | 822 |-----------------+-------+----------|--------------------|------------| 823 | Sequence Number | TBD1 | tstr/int | Method for a re- | [[this | 824 | Synchronization | | | cipient node to | document]] | 825 | Method | | | synchronize with | | 826 | | | | sequence numbers | | 827 | | | | of a sender node. | | 828 | | | | Its value is taken | | 829 | | | | from the 'Value' | | 830 | | | | column of the | | 831 | | | | Sequence Number | | 832 | | | | Synchronization | | 833 | | | | Method registry | | 834 | | | | | | 835 | Key Update | TBD2 | int | Polling interval | [[this | 836 | Check Interval | | | in seconds, to | document]] | 837 | | | | check for new | | 838 | | | | keying material at | | 839 | | | | the KDC | | 840 +-----------------+-------+----------|--------------------|------------+ 842 Figure 5: ACE Groupcomm Policies 844 o 'mgt_key_material', encoded as a CBOR byte string and containing 845 the administrative keying material to participate in the group 846 rekeying performed by the KDC. The application profile MUST 847 define if this field is used, and if used then MUST specify the 848 exact format and content which depend on the specific rekeying 849 scheme used in the group. If the usage of 'mgt_key_material' is 850 indicated and its format defined for a specific key management 851 scheme, that format must explicitly indicate the key management 852 scheme itself. If a new rekeying scheme is defined to be used for 853 an existing 'mgt_key_material' in an existing profile, then that 854 profile will have to be updated accordingly, especially with 855 respect to the usage of 'mgt_key_material' related format and 856 content (REQ18). 858 Specific application profiles that build on this document MUST 859 specify the communication protocol that members of the group use to 860 communicate with each other (REQ10) and how exactly the keying 861 material is used to protect the group communication (REQ11). 863 CBOR labels for these fields are defined in Section 6. 865 4.1.2.2. GET Handler 867 The GET handler returns the symmetric group keying material for the 868 group identified by "gid". 870 The handler expects a GET request. 872 The handler verifies that the group identifier of the /ace-group/gid 873 path is a subset of the 'scope' stored in the access token associated 874 to this client. If verification fails, the KDC MUST respond with a 875 4.01 (Unauthorized) error message. The KDC MAY set the payload with 876 the 'sign_info' and 'pub_key_enc' parameter, formatted as 877 'sign_info_res' and 'pub_key_enc_res' in the payload of the 2.01 878 (Created) response to the Token Post as defined in Section 3.3. Note 879 that in this case, the content format MUST be set to application/ 880 ace+cbor. 882 If verification succeeds, the handler returns a 2.05 (Content) 883 message containing the symmetric group keying material. The payload 884 of the response is formatted as a CBOR map which MUST contain the 885 parameters 'gkty','key' and 'num' specified in Section 4.1.2.1. 887 The payload MAY also include the parameters 'ace-groupcomm-profile', 888 'exp' and 'mgt_key_material' parameters specified in Section 4.1.2.1. 890 4.1.3. ace-group/gid/pub-key 892 This resource implements GET and FETCH handlers. 894 4.1.3.1. FETCH Handler 896 The FETCH handler receives identifiers of group members for the group 897 identified by "gid" and returns the public keys of such group 898 members. 900 The handler expects a request with payload formatted as a CBOR map. 901 The payload of this request is a CBOR Map that MUST contain the 902 following fields: 904 o 'get_pub_keys', whose value is a non-empty CBOR array. Each 905 element of the array is the identifier of a group member for the 906 group identified by "gid". The specific format of public keys as 907 well as identifiers of group members MUST be specified by the 908 application profile (OPT1, REQ9). 910 The handler verifies that the group identifier of the /ace-group/gid 911 path is a subset of the 'scope' stored in the access token associated 912 to this client. If verification fails, the KDC MUST respond with a 913 4.01 (Unauthorized) error message. 915 If verification succeeds, the handler identifies the public keys of 916 the current group members for which the identifier matches with one 917 of those indicated in the request. Then, the handler returns a 2.05 918 (Content) message response with payload formatted as a CBOR map 919 containing only the 'pub_keys' parameter from Section 4.1.2.1, which 920 encodes the list of public keys of those group members including the 921 respective member identifiers. If the KDC does not store any public 922 key associated with the specified member identifiers, the handler 923 returns a response with payload formatted as a CBOR byte string of 924 zero length. The specific format of public keys as well as of 925 identifiers of group members is specified by the application profile 926 (OPT1, REQ9). 928 The handler MAY enforce one of the following policies, in order to 929 handle possible identifiers that are included in the 'get_pub_keys' 930 parameter of the request but are not associated to any current group 931 member. Such a policy MUST be specified by the application profile 932 (REQ13) 934 o The KDC silently ignores those identifiers. 936 o The KDC retains public keys of group members for a given amount of 937 time after their leaving, before discarding them. As long as such 938 public keys are retained, the KDC provides them to a requesting 939 Client. 941 4.1.3.2. GET Handler 943 The handler expects a GET request. 945 The handler verifies that the group identifier of the /ace-group/gid 946 path is a subset of the 'scope' stored in the access token associated 947 to this client. If verification fails, the KDC MUST respond with a 948 4.01 (Unauthorized) error message. 950 If verification succeeds, the handler returns a 2.05 (Content) 951 message containing the public keys of all the current group members, 952 for the group identified by "gid". The payload of the response is 953 formatted as a CBOR map containing only the 'pub_keys' parameter from 954 Section 4.1.2.1, which encodes the list of public keys of all the 955 group members including the respective member identifiers. If the 956 KDC does not store any public key for the group, the handler returns 957 a response with payload formatted as a CBOR byte string of zero 958 length. The specific format of public keys as well as of identifiers 959 of group members is specified by the application profile (OPT1, 960 REQ9). 962 4.1.4. ace-group/gid/policies 964 This resource implements a GET handler. 966 4.1.4.1. GET Handler 968 The handler expects a GET request. 970 The handler verifies that the group identifier of the /ace-group/gid 971 path is a subset of the 'scope' stored in the access token associated 972 to this client. If verification fails, the KDC MUST respond with a 973 4.01 (Unauthorized) error message. 975 If verification succeeds, the handler returns a 2.05 (Content) 976 message containing the list of policies for the group identified by 977 "gid". The payload of the response is formatted as a CBOR map 978 including only the parameter 'group_policies' defined in 979 Section 4.1.2.1 and specifying the current policies in the group. If 980 the KDC does not store any policy, the payload is formatted as a 981 zero-length CBOR byte string. 983 The specific format and meaning of group policies MUST be specified 984 in the application profile (REQ14). 986 4.1.5. ace-group/gid/ctx-num 988 This resource implements a GET handler. 990 4.1.5.1. GET Handler 992 The handler expects a GET request. 994 The handler verifies that the group identifier of the /ace-group/gid 995 path is a subset of the 'scope' stored in the access token associated 996 to this client. If verification fails, the KDC MUST respond with a 997 4.01 (Unauthorized) error message. 999 If verification succeeds, the handler returns a 2.05 (Content) 1000 message containing an integer that represents the version number of 1001 the symmetric group keying material. This number is incremented on 1002 the KDC every time the KDC updates the symmetric group keying 1003 material. The payload of the response is formatted as a CBOR 1004 integer. 1006 4.1.6. ace-group/gid/node 1008 This resource implements GET, PUT and DELETE handlers. 1010 4.1.6.1. PUT Handler 1012 The PUT handler is used to get the KDC to produce and return 1013 individual keying material to protect outgoing messages for the node 1014 (identified by "node") for the group identified by "gid". 1016 The handler expects a request with empty payload. 1018 The handler verifies that the group identifier of the /ace-group/gid 1019 path is a subset of the 'scope' stored in the access token associated 1020 to this client. If verification fails, the KDC MUST respond with a 1021 4.01 (Unauthorized) error message. 1023 If verification succeeds, the handler returns a 2.05 (Content) 1024 message containing newly-generated individual keying material for the 1025 Client, or information enabling the Client to derive it. The payload 1026 of the response is formatted as a CBOR map. The specific format of 1027 newly-generated individual keying material for group members, or of 1028 the information to derive it, and corresponding CBOR label, MUST be 1029 specified in the application profile (REQ15) and registered in 1030 Section 8.4. 1032 4.1.6.2. GET Handler 1034 The handler expects a GET request. 1036 The handler verifies that the group identifier of the /ace-group/gid 1037 path is a subset of the 'scope' stored in the access token associated 1038 to this client, identified by "node". If verification fails, the KDC 1039 MUST respond with a 4.01 (Unauthorized) error message. 1041 If verification succeeds, the handler returns a 2.05 (Content) 1042 message containing both the group keying material and the individual 1043 keying material for the Client, or information enabling the Client to 1044 derive it. The payload of the response is formatted as a CBOR map. 1045 The format for the group keying material is the same as defined in 1046 the response of Section 4.1.2.2. The specific format of individual 1047 keying material for group members, or of the information to derive 1048 it, and corresponding CBOR label, MUST be specified in the 1049 application profile (REQ15) and registered in Section 8.4. 1051 4.1.6.3. DELETE Handler 1053 The DELETE handler removes the node (identified by "node") from the 1054 group, for the group identified by "gid". If the node sending the 1055 request and the node name used in the Uri-Path do not match, the 1056 handler responds with a 4.01 (Unauthorized) error response. 1058 TODO: Check the previous sentence. 1060 The handler expects a request with payload formatted as a CBOR map. 1061 The payload of this request is a CBOR Map that MAY contain only the 1062 'scope' field as specified in Section 4.1.2.1. 1064 The handler verifies that the group identifier of the /ace-group/gid 1065 path is a subset of the 'scope' stored in the access token associated 1066 to this client. If verification fails, the KDC MUST respond with a 1067 4.01 (Unauthorized) error message. 1069 If the request contained a 'scope' field, the handler MUST extract 1070 the roles for that client. If the value is such that the KDC cannot 1071 extract all the necessary information to understand and process it 1072 correctly (e.g. unrecognized roles), the KDC MUST respond with a 4.00 1073 (Bad Request) error message. 1075 If verification succeeds, the handler removes the client from the 1076 group identified by "gid", for specific roles if roles were specified 1077 in the 'scope' field, or for all roles. That includes removing the 1078 public key of the client if the KDC keep tracks of that. Then, the 1079 handler delete the sub-resource /node and returns a 2.02 (Deleted) 1080 message with empty payload. 1082 4.2. Joining Exchange 1084 Figure 6 gives an overview of the Joining exchange between Client and 1085 KDC, when the Client first joins a group. 1087 Client KDC 1088 | | 1089 |-------- Joining Request: POST /ace-group/gid --------->| 1090 | | 1091 |<--------- Joining Response: 2.01 (Created) ----------- | 1092 | Location-Path = "/ace-group/gid/node" | 1094 Figure 6: Message Flow of First Exchange for Group Joining 1096 If not previously established, the Client and the KDC MUST first 1097 establish a pairwise secure communication channel (REQ16). This can 1098 be achieved, for instance, by using a transport profile of ACE. The 1099 Joining exchange MUST occur over that secure channel. The Client and 1100 the KDC MAY use that same secure channel to protect further pairwise 1101 communications that must be secured. 1103 The secure communication protocol is REQUIRED to establish the secure 1104 channel by using the proof-of-possession key bound to the access 1105 token. As a result, the proof-of-possession to bind the access token 1106 to the Client is performed by using the proof-of-possession key bound 1107 to the access token for establishing secure communication between the 1108 Client and the KDC. 1110 To join the group, the Client sends a CoAP POST request to the /ace- 1111 group/gid endpoint at the KDC, where gid is the group identifier of 1112 the group to join, formatted as specified in Section 4.1.2.1. This 1113 group identifier is the same as the 'scope' value of the 1114 Authorization Request/Response, or it can be retrieved from it. Note 1115 that, in case of successful joining, the Client will receive the URI 1116 to retrieve individual or group keying material and to leave the 1117 group in the Location-Path option of the response. 1119 If the application requires backward security, the KDC MUST generate 1120 new group keying material and securely distribute it to all the 1121 current group members, upon a new node's joining the group. To this 1122 end, the KDC uses the message format of the Joining Response (see 1123 Section 4.1.2.1). Application profiles may define alternative ways 1124 of retrieving the keying material, such as sending separate requests 1125 to different resources at the KDC (Section 4.1.2.2, Section 4.1.3.2, 1126 Section 4.1.4.1). After distributing the new group keying material, 1127 the KDC MUST increment the version number of the keying material. 1129 4.3. Retrieval of Updated Keying Material 1131 A node stops using the group keying material upon its expiration, 1132 according to what indicated by the KDC with the 'exp' parameter in a 1133 Joining response, or to a pre-configured value. Then, if it wants to 1134 continue participating in the group communication, the node has to 1135 request new updated keying material from the KDC. 1137 The Client may need to request the latest group keying material also 1138 upon receiving messages from other group members without being able 1139 to retrieve the material to correctly decrypt them. This may be due 1140 to a previous update of the group keying material (rekeying) 1141 triggered by the KDC, that the Client was not able to receive or 1142 decrypt. To this end, the Client sends a CoAP GET request to the 1143 /ace-group/gid/node endpoint at the KDC, formatted as specified in 1144 Section 4.1.6.2. 1146 Note that policies can be set up so that the Client sends a Key Re- 1147 Distribution Request to the KDC only after a given number of 1148 unsuccessfully decrypted incoming messages. It is application 1149 dependent and pertaining to the particular message exchange (e.g. 1150 [I-D.ietf-core-oscore-groupcomm]) to set up policies that instruct 1151 clients to retain unsuccessfully decrypted messages and for how long, 1152 so that they can be decrypted after getting updated keying material, 1153 rather than just considered non valid messages to discard right away 1154 (OPT4). 1156 The same Key Distribution Request could also be sent by the Client 1157 without being triggered by a failed decryption of a message, if the 1158 Client wants to be sure that it has the latest group keying material. 1159 If that is the case, the Client will receive from the KDC the same 1160 group keying material it already has in memory. 1162 Figure 7 gives an overview of the exchange described above. 1164 Client KDC 1165 | | 1166 |--- Key Distribution Request: GET ace-group/gid/node -->| 1167 | | 1168 |<----- Key Distribution Response: 2.05 (Content) -------| 1169 | | 1171 Figure 7: Message Flow of Key Distribution Request-Response 1173 Alternatively, the re-distribution of keying material can be 1174 initiated by the KDC, which e.g.: 1176 o Can make the ace-group/gid/node resource Observable, and send 1177 notifications to Clients when the keying material is updated. 1179 o Can send the Key Distribution Response as one or multiple 1180 multicast requests to the members of the group, using secure 1181 rekeying schemes such as [RFC2093][RFC2094][RFC2627]. 1183 o Can send unicast requests to each Client over a secure channel, 1184 with the same payload as the Key Distribution Response. 1186 o Can act as a publisher in a pub-sub scenario, and update the 1187 keying material by publishing on a specific topic on a broker, 1188 which all the members of the group are subscribed to. 1190 Note that these methods of KDC-initiated key distribution have 1191 different security properties and require different security 1192 associations. 1194 4.4. Retrieval of New Keying Material 1196 Beside possible expiration and depending on what part of the keying 1197 material is no longer eligible to be used, the client may need to 1198 communicate to the KDC its need for that part to be renewed. For 1199 example, if the Client uses an individual key to protect outgoing 1200 traffic and has to renew it, the node may request a new one, or new 1201 input material to derive it, without renewing the whole group keying 1202 material. To this end, the client performs a Key Renewal Request/ 1203 Response exchange with the KDC, that is a CoAP PUT request to the 1204 /ace-group/gid/node endpoint at the KDC, where gid is the group 1205 identifier and node the node's name, and formatted as defined in 1206 Section 4.1.6.2. 1208 Figure 8 gives an overview of the exchange described above. 1210 Client KDC 1211 | | 1212 |---- Key Renewal Request: PUT ace-group/gid/node --->| 1213 | | 1214 |<----- Key Renewal Response: 2.05 (Content) ---------| 1215 | | 1217 Figure 8: Message Flow of Key Renewal Request-Response 1219 Note the difference between the Key Distribution Request and the Key 1220 Renewal Request: while the first one only triggers distribution (the 1221 renewal might have happened independently, e.g. because of 1222 expiration), the second one triggers the KDC to produce new 1223 individual keying material for the requesting node. 1225 4.5. Retrieval of Public Keys for Group Members 1227 In case the KDC maintains the public keys of group members, a node in 1228 the group can contact the KDC to request public keys of either all 1229 group members or a specified subset, by sending a CoAP GET or FETCH 1230 request to the /ace-group/gid/pub-key endpoint at the KDC, where gid 1231 is the group identifier, and formatted as defined in Section 4.1.3.2 1232 and Section 4.1.3.1. 1234 Figure 9 and Figure 10 give an overview of the exchanges described 1235 above. 1237 Client KDC 1238 | | 1239 |---- Public Key Request: GET /ace-group/gid/pub-key --->| 1240 | | 1241 |<--------- Public Key Response: 2.05 (Content) ---------| 1242 | | 1244 Figure 9: Message Flow of Public Key Exchange to Request All Members 1245 Public Keys 1247 Client KDC 1248 | | 1249 |--- Public Key Request: FETCH /ace-group/gid/pub-key --->| 1250 | | 1251 |<--------- Public Key Response: 2.01 (Created) ---------| 1252 | | 1254 Figure 10: Message Flow of Public Key Exchange to Request Specific 1255 Members Public Keys 1257 4.6. Retrieval of Group Policies 1259 A node in the group can contact the KDC to retrieve the current group 1260 policies, by sending a CoAP GET request to the /ace-group/gid/ 1261 policies endpoint at the KDC, where gid is the group identifier, and 1262 formatted as defined in Section 4.1.4.1 1264 Figure 11 gives an overview of the exchange described above. 1266 Client KDC 1267 | | 1268 |--- Policies Request: GET ace-group/gid/policies ---->| 1269 | | 1270 |<--------- Policies Response: 2.05 (Content) ---------| 1271 | | 1273 Figure 11: Message Flow of Policies Request-Response 1275 4.7. Retrieval of Keying Material Version 1277 A node in the group can contact the KDC to request information about 1278 the version number of the symmetric group keying material, by sending 1279 a CoAP GET request to the /ace-group/gid/ctx-num endpoint at the KDC, 1280 where gid is the group identifier, formatted as defined in 1281 Section 4.1.5.1. In particular, the version is incremented by the 1282 KDC every time the group keying material is renewed. 1284 Figure 12 gives an overview of the exchange described above. 1286 Client KDC 1287 | | 1288 |----- Version Request: GET ace-group/gid/ctx-num ----->| 1289 | | 1290 |<--------- Version Response: 2.05 (Content) -----------| 1291 | | 1293 Figure 12: Message Flow of Version Request-Response 1295 4.8. Group Leaving Request 1297 A node can actively request to leave the group. In this case, the 1298 Client sends a CoAP DELETE request to the endpoint /ace-group/gid/ 1299 node at the KDC, where gid is the group identifier and node the 1300 node's name, formatted as defined in Section 4.1.6.3 1302 Alternatively, a node may be removed by the KDC, without having 1303 explicitly asked for it. This is further discussed in Section 5. 1305 5. Removal of a Node from the Group 1307 This section describes the different scenarios according to which a 1308 node ends up being removed from the group. 1310 If the application requires forward security, the KDC MUST generate 1311 new group keying material and securely distribute it to all the 1312 current group members but the leaving node, using the message format 1313 of the Key Distribution Response (see Section 4.3). Application 1314 profiles may define alternative message formats. Once distributed 1315 the new group keying material, the KDC MUST increment the version 1316 number of the keying material. 1318 Note that, after having left the group, a node may wish to join it 1319 again. Then, as long as the node is still authorized to join the 1320 group, i.e. it still has a valid access token, it can re-request to 1321 join the group directly to the KDC without needing to retrieve a new 1322 access token from the AS. This means that the KDC might decide to 1323 keep track of nodes with valid access tokens, before deleting all 1324 information about the leaving node. 1326 A node may be evicted from the group in the following cases. 1328 1. The node explicitly asks to leave the group, as defined in 1329 Section 4.8. 1331 2. The node has been found compromised or is suspected so. 1333 3. The node's authorization to be a group member is expired. If the 1334 AS provides Token introspection (see Section 5.7 of 1335 [I-D.ietf-ace-oauth-authz]), the KDC can optionally use and check 1336 whether: 1338 * the node is not authorized anymore; 1340 * the access token is still valid, upon its expiration. 1342 Either case, once aware that a node is not authorized anymore, 1343 the KDC has to remove the unauthorized node from the list of 1344 group members, if the KDC keeps track of that. 1346 6. ACE Groupcomm Parameters 1348 This specification defines a number of fields used during the second 1349 part of the message exchange, after the ACE Token POST exchange. The 1350 table below summarizes them, and specifies the CBOR key to use 1351 instead of the full descriptive name. Note that the media type ace- 1352 groupcomm+cbor MUST be used when these fields are transported. 1354 +-----------------------+--------+---------------------+------------+ 1355 | Name | CBOR | CBOR Type | Reference | 1356 | | Key | | | 1357 +-----------------------+--------+---------------------+------------+ 1358 | scope | TBD | array | Section | 1359 | | | | 4.1.2.1 | 1360 | | | | | 1361 | get_pub_keys | TBD | array | Section | 1362 | | | | 4.1.2.1 | 1363 | | | | | 1364 | client_cred | TBD | byte string | Section | 1365 | | | | 4.1.2.1 | 1366 | | | | | 1367 | cnonce | TBD | byte string | Section | 1368 | | | | 4.1.2.1 | 1369 | | | | | 1370 | client_cred_verify | TBD | byte string | Section | 1371 | | | | 4.1.2.1 | 1372 | | | | | 1373 | pub_keys_repos | TBD | array | Section | 1374 | | | | 4.1.2.1 | 1375 | | | | | 1376 | gkty | TBD | int / byte string | Section | 1377 | | | | 4.1.2.1 | 1378 | | | | | 1379 | key | TBD | see "ACE Groupcomm | Section | 1380 | | | Key" Registry | 4.1.2.1 | 1381 | | | | | 1382 | num | TBD | int | Section | 1383 | | | | 4.1.2.1 | 1384 | | | | | 1385 | ace-groupcomm-profile | TBD | int | Section | 1386 | | | | 4.1.2.1 | 1387 | | | | | 1388 | exp | TBD | int / float | Section | 1389 | | | | 4.1.2.1 | 1390 | | | | | 1391 | pub_keys | TBD | byte string | Section | 1392 | | | | 4.1.2.1 | 1393 | | | | | 1394 | group_policies | TBD | map | Section | 1395 | | | | 4.1.2.1 | 1396 | | | | | 1397 | mgt_key_material | TBD | byte string | Section | 1398 | | | | 4.1.2.1 | 1399 | | | | | 1400 | get_pub_keys | TBD | array | Section | 1401 | | | | 4.1.3.1 | 1402 +-----------------------+--------+---------------------+------------+ 1404 7. Security Considerations 1406 When a Client receives a message from a sender for the first time, it 1407 needs to have a mechanism in place to avoid replay, e.g. 1408 Appendix B.2 of [RFC8613]. 1410 The KDC must renew the group keying material upon its expiration. 1412 The KDC should renew the keying material upon group membership 1413 change, and should provide it to the current group members through 1414 the rekeying scheme used in the group. 1416 The KDC may enforce a rekeying policy that takes into account the 1417 overall time required to rekey the group, as well as the expected 1418 rate of changes in the group membership. 1420 That is, the KDC may not rekey the group at every membership change, 1421 for instance if members' joining and leaving occur frequently and 1422 performing a group rekeying takes too long. Instead, the KDC may 1423 rekey the group after a minum number of group members have joined or 1424 left within a given time interval, or during predictable network 1425 inactivity periods. 1427 However, this would result in the KDC not constantly preserving 1428 backward and forward security. In fact, newly joining group members 1429 could be able to access the keying material used before their 1430 joining, and thus could access past group communications. Also, 1431 until the KDC performs a group rekeying, the newly leaving nodes 1432 would still be able to access upcoming group communications that are 1433 protected with the keying material that has not yet been updated. 1435 7.1. Update of Keying Material 1437 A group member can receive a message shortly after the group has been 1438 rekeyed, and new keying material has been distributed by the KDC. In 1439 the following two cases, this may result in misaligned keying 1440 material between the group members. 1442 In the first case, the sender protects a message using the old keying 1443 material. However, the recipient receives the message after having 1444 received the new keying material, hence not being able to correctly 1445 process it. A possible way to ameliorate this issue is to preserve 1446 the old, recent, keying material for a maximum amount of time defined 1447 by the application. By doing so, the recipient can still try to 1448 process the received message using the old retained keying material 1449 as second attempt. Note that a former (compromised) group member can 1450 take advantage of this by sending messages protected with the old 1451 retained keying material. Therefore, a conservative application 1452 policy should not admit the storage of old keying material. 1454 In the second case, the sender protects a message using the new 1455 keying material, but the recipient receives that request before 1456 having received the new keying material. Therefore, the recipient 1457 would not be able to correctly process the request and hence discards 1458 it. If the recipient receives the new keying material shortly after 1459 that and the sender endpoint uses CoAP retransmissions, the former 1460 will still be able to receive and correctly process the message. In 1461 any case, the recipient should actively ask the KDC for an updated 1462 keying material according to an application-defined policy, for 1463 instance after a given number of unsuccessfully decrypted incoming 1464 messages. 1466 A node that has left the group should not expect any of its outgoing 1467 messages to be successfully processed, if received after its leaving, 1468 due to a possible group rekeying occurred before the message 1469 reception. 1471 7.2. Block-Wise Considerations 1473 If the block-wise options [RFC7959] are used, and the keying material 1474 is updated in the middle of a block-wise transfer, the sender of the 1475 blocks just changes the keying material to the updated one and 1476 continues the transfer. As long as both sides get the new keying 1477 material, updating the keying material in the middle of a transfer 1478 will not cause any issue. Otherwise, the sender will have to 1479 transmit the message again, when receiving an error message from the 1480 recipient. 1482 Compared to a scenario where the transfer does not use block-wise, 1483 depending on how fast the keying material is changed, the nodes might 1484 consume a larger amount of the network bandwidth resending the blocks 1485 again and again, which might be problematic. 1487 8. IANA Considerations 1489 This document has the following actions for IANA. 1491 8.1. Media Type Registrations 1493 This specification registers the 'application/ace-groupcomm+cbor' 1494 media type for messages of the protocols defined in this document 1495 following the ACE exchange and carrying parameters encoded in CBOR. 1496 This registration follows the procedures specified in [RFC6838]. 1498 Type name: application 1500 Subtype name: ace-groupcomm+cbor 1502 Required parameters: none 1504 Optional parameters: none 1506 Encoding considerations: Must be encoded as CBOR map containing the 1507 protocol parameters defined in [this document]. 1509 Security considerations: See Section 7 of this document. 1511 Interoperability considerations: n/a 1513 Published specification: [this document] 1515 Applications that use this media type: The type is used by 1516 authorization servers, clients and resource servers that support the 1517 ACE groupcomm framework as specified in [this document]. 1519 Additional information: 1521 Magic number(s): n/a 1523 File extension(s): .ace-groupcomm 1524 Macintosh file type code(s): n/a 1526 Person & email address to contact for further information: 1527 iesg@ietf.org [1] 1529 Intended usage: COMMON 1531 Restrictions on usage: None 1533 Author: Francesca Palombini francesca.palombini@ericsson.com [2] 1535 Change controller: IESG 1537 8.2. CoAP Content-Formats Registry 1539 This specification registers the following entry to the "CoAP 1540 Content-Formats" registry, within the "CoRE Parameters" registry: 1542 Media Type: application/ace-groupcomm+cbor 1544 Encoding: - 1546 ID: TBD 1548 Reference: [this document] 1550 8.3. ACE Authorization Server Request Creation Hints Registry 1552 IANA is asked to register the following entries in the "ACE 1553 Authorization Server Request Creation Hints" Registry defined in 1554 Section 8.1 of [I-D.ietf-ace-oauth-authz]. 1556 o Name: sign_info 1558 o CBOR Key: TBD (range -256 to 255) 1560 o Value Type: any 1562 o Reference: [[This specification]] 1564 o Name: pub_key_enc 1566 o CBOR Key: TBD (range -256 to 255) 1568 o Value Type: integer 1570 o Reference: [[This specification]] 1571 o Name: rsnonce 1573 o CBOR Key: TBD (range -256 to 255) 1575 o Value Type: byte string 1577 o Reference: [[This specification]] 1579 8.4. ACE Groupcomm Parameters Registry 1581 This specification establishes the "ACE Groupcomm Parameters" IANA 1582 Registry. The Registry has been created to use the "Expert Review 1583 Required" registration procedure [RFC8126]. Expert review guidelines 1584 are provided in Section 8.9. 1586 The columns of this Registry are: 1588 o Name: This is a descriptive name that enables easier reference to 1589 the item. The name MUST be unique. It is not used in the 1590 encoding. 1592 o CBOR Key: This is the value used as CBOR key of the item. These 1593 values MUST be unique. The value can be a positive integer, a 1594 negative integer, or a string. 1596 o CBOR Type: This contains the CBOR type of the item, or a pointer 1597 to the registry that defines its type, when that depends on 1598 another item. 1600 o Reference: This contains a pointer to the public specification for 1601 the item. 1603 This Registry has been initially populated by the values in 1604 Section 6. The Reference column for all of these entries refers to 1605 sections of this document. 1607 8.5. ACE Groupcomm Key Registry 1609 This specification establishes the "ACE Groupcomm Key" IANA Registry. 1610 The Registry has been created to use the "Expert Review Required" 1611 registration procedure [RFC8126]. Expert review guidelines are 1612 provided in Section 8.9. 1614 The columns of this Registry are: 1616 o Name: This is a descriptive name that enables easier reference to 1617 the item. The name MUST be unique. It is not used in the 1618 encoding. 1620 o Key Type Value: This is the value used to identify the keying 1621 material. These values MUST be unique. The value can be a 1622 positive integer, a negative integer, or a string. 1624 o Profile: This field may contain one or more descriptive strings of 1625 application profiles to be used with this item. The values should 1626 be taken from the Name column of the "ACE Groupcomm Profile" 1627 Registry. 1629 o Description: This field contains a brief description of the keying 1630 material. 1632 o References: This contains a pointer to the public specification 1633 for the format of the keying material, if one exists. 1635 This Registry has been initially populated by the values in Figure 4. 1636 The specification column for all of these entries will be this 1637 document. 1639 8.6. ACE Groupcomm Profile Registry 1641 This specification establishes the "ACE Groupcomm Profile" IANA 1642 Registry. The Registry has been created to use the "Expert Review 1643 Required" registration procedure [RFC8126]. Expert review guidelines 1644 are provided in Section 8.9. It should be noted that, in addition to 1645 the expert review, some portions of the Registry require a 1646 specification, potentially a Standards Track RFC, be supplied as 1647 well. 1649 The columns of this Registry are: 1651 o Name: The name of the application profile, to be used as value of 1652 the profile attribute. 1654 o Description: Text giving an overview of the application profile 1655 and the context it is developed for. 1657 o CBOR Value: CBOR abbreviation for the name of this application 1658 profile. Different ranges of values use different registration 1659 policies [RFC8126]. Integer values from -256 to 255 are 1660 designated as Standards Action. Integer values from -65536 to 1661 -257 and from 256 to 65535 are designated as Specification 1662 Required. Integer values greater than 65535 are designated as 1663 Expert Review. Integer values less than -65536 are marked as 1664 Private Use. 1666 o Reference: This contains a pointer to the public specification of 1667 the abbreviation for this application profile, if one exists. 1669 8.7. ACE Groupcomm Policy Registry 1671 This specification establishes the "ACE Groupcomm Policy" IANA 1672 Registry. The Registry has been created to use the "Expert Review 1673 Required" registration procedure [RFC8126]. Expert review guidelines 1674 are provided in Section 8.9. It should be noted that, in addition to 1675 the expert review, some portions of the Registry require a 1676 specification, potentially a Standards Track RFC, be supplied as 1677 well. 1679 The columns of this Registry are: 1681 o Name: The name of the group communication policy. 1683 o CBOR label: The value to be used to identify this group 1684 communication policy. Key map labels MUST be unique. The label 1685 can be a positive integer, a negative integer or a string. 1686 Integer values between 0 and 255 and strings of length 1 are 1687 designated as Standards Track Document required. Integer values 1688 from 256 to 65535 and strings of length 2 are designated as 1689 Specification Required. Integer values of greater than 65535 and 1690 strings of length greater than 2 are designated as expert review. 1691 Integer values less than -65536 are marked as private use. 1693 o CBOR type: the CBOR type used to encode the value of this group 1694 communication policy. 1696 o Description: This field contains a brief description for this 1697 group communication policy. 1699 o Reference: This field contains a pointer to the public 1700 specification providing the format of the group communication 1701 policy, if one exists. 1703 This registry will be initially populated by the values in Figure 5. 1705 8.8. Sequence Number Synchronization Method Registry 1707 This specification establishes the "Sequence Number Synchronization 1708 Method" IANA Registry. The Registry has been created to use the 1709 "Expert Review Required" registration procedure [RFC8126]. Expert 1710 review guidelines are provided in Section 8.9. It should be noted 1711 that, in addition to the expert review, some portions of the Registry 1712 require a specification, potentially a Standards Track RFC, be 1713 supplied as well. 1715 The columns of this Registry are: 1717 o Name: The name of the sequence number synchronization method. 1719 o Value: The value to be used to identify this sequence number 1720 synchronization method. 1722 o Description: This field contains a brief description for this 1723 sequence number synchronization method. 1725 o Reference: This field contains a pointer to the public 1726 specification describing the sequence number synchronization 1727 method. 1729 8.9. Expert Review Instructions 1731 The IANA Registries established in this document are defined as 1732 expert review. This section gives some general guidelines for what 1733 the experts should be looking for, but they are being designated as 1734 experts for a reason so they should be given substantial latitude. 1736 Expert reviewers should take into consideration the following points: 1738 o Point squatting should be discouraged. Reviewers are encouraged 1739 to get sufficient information for registration requests to ensure 1740 that the usage is not going to duplicate one that is already 1741 registered and that the point is likely to be used in deployments. 1742 The zones tagged as private use are intended for testing purposes 1743 and closed environments, code points in other ranges should not be 1744 assigned for testing. 1746 o Specifications are required for the standards track range of point 1747 assignment. Specifications should exist for specification 1748 required ranges, but early assignment before a specification is 1749 available is considered to be permissible. Specifications are 1750 needed for the first-come, first-serve range if they are expected 1751 to be used outside of closed environments in an interoperable way. 1752 When specifications are not provided, the description provided 1753 needs to have sufficient information to identify what the point is 1754 being used for. 1756 o Experts should take into account the expected usage of fields when 1757 approving point assignment. The fact that there is a range for 1758 standards track documents does not mean that a standards track 1759 document cannot have points assigned outside of that range. The 1760 length of the encoded value should be weighed against how many 1761 code points of that length are left, the size of device it will be 1762 used on, and the number of code points left that encode to that 1763 size. 1765 9. References 1767 9.1. Normative References 1769 [I-D.ietf-ace-cwt-proof-of-possession] 1770 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 1771 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 1772 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 1773 possession-11 (work in progress), October 2019. 1775 [I-D.ietf-ace-oauth-authz] 1776 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1777 H. Tschofenig, "Authentication and Authorization for 1778 Constrained Environments (ACE) using the OAuth 2.0 1779 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-29 1780 (work in progress), December 2019. 1782 [I-D.ietf-ace-oauth-params] 1783 Seitz, L., "Additional OAuth Parameters for Authorization 1784 in Constrained Environments (ACE)", draft-ietf-ace-oauth- 1785 params-11 (work in progress), January 2020. 1787 [I-D.ietf-core-oscore-groupcomm] 1788 Tiloca, M., Selander, G., Palombini, F., and J. Park, 1789 "Group OSCORE - Secure Group Communication for CoAP", 1790 draft-ietf-core-oscore-groupcomm-06 (work in progress), 1791 November 2019. 1793 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1794 Requirement Levels", BCP 14, RFC 2119, 1795 DOI 10.17487/RFC2119, March 1997, 1796 . 1798 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1799 Specifications and Registration Procedures", BCP 13, 1800 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1801 . 1803 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1804 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1805 October 2013, . 1807 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1808 Writing an IANA Considerations Section in RFCs", BCP 26, 1809 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1810 . 1812 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1813 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1814 . 1816 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1817 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1818 May 2017, . 1820 9.2. Informative References 1822 [I-D.dijk-core-groupcomm-bis] 1823 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1824 for the Constrained Application Protocol (CoAP)", draft- 1825 dijk-core-groupcomm-bis-02 (work in progress), November 1826 2019. 1828 [I-D.ietf-ace-dtls-authorize] 1829 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 1830 L. Seitz, "Datagram Transport Layer Security (DTLS) 1831 Profile for Authentication and Authorization for 1832 Constrained Environments (ACE)", draft-ietf-ace-dtls- 1833 authorize-09 (work in progress), December 2019. 1835 [I-D.ietf-ace-mqtt-tls-profile] 1836 Sengul, C., Kirby, A., and P. Fremantle, "MQTT-TLS profile 1837 of ACE", draft-ietf-ace-mqtt-tls-profile-03 (work in 1838 progress), December 2019. 1840 [I-D.ietf-ace-oscore-profile] 1841 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 1842 "OSCORE profile of the Authentication and Authorization 1843 for Constrained Environments Framework", draft-ietf-ace- 1844 oscore-profile-08 (work in progress), July 2019. 1846 [I-D.ietf-core-coap-pubsub] 1847 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1848 Subscribe Broker for the Constrained Application Protocol 1849 (CoAP)", draft-ietf-core-coap-pubsub-09 (work in 1850 progress), September 2019. 1852 [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management 1853 Protocol (GKMP) Specification", RFC 2093, 1854 DOI 10.17487/RFC2093, July 1997, 1855 . 1857 [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management 1858 Protocol (GKMP) Architecture", RFC 2094, 1859 DOI 10.17487/RFC2094, July 1997, 1860 . 1862 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 1863 Multicast: Issues and Architectures", RFC 2627, 1864 DOI 10.17487/RFC2627, June 1999, 1865 . 1867 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1868 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1869 January 2012, . 1871 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 1872 the Constrained Application Protocol (CoAP)", RFC 7390, 1873 DOI 10.17487/RFC7390, October 2014, 1874 . 1876 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1877 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1878 . 1880 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1881 the Constrained Application Protocol (CoAP)", RFC 7959, 1882 DOI 10.17487/RFC7959, August 2016, 1883 . 1885 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1886 Interchange Format", STD 90, RFC 8259, 1887 DOI 10.17487/RFC8259, December 2017, 1888 . 1890 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1891 "Object Security for Constrained RESTful Environments 1892 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1893 . 1895 9.3. URIs 1897 [1] mailto:iesg@ietf.org 1899 [2] mailto:francesca.palombini@ericsson.com 1901 Appendix A. Requirements on Application Profiles 1903 This section lists the requirements on application profiles of this 1904 specification,for the convenience of application profile designers. 1906 o REQ1: Specify the encoding and value of the identifier of group or 1907 topic of 'scope' (see Section 3.1). 1909 o REQ2: Specify the encoding and value of roles of 'scope' (see 1910 Section 3.1). 1912 o REQ3: If used, specify the acceptable values for 'sign_alg' (see 1913 Section 3.3). 1915 o REQ4: If used, specify the acceptable values for 'sign_parameters' 1916 (see Section 3.3). 1918 o REQ5: If used, specify the acceptable values for 1919 'sign_key_parameters' (see Section 3.3). 1921 o REQ6: If used, specify the acceptable values for 'pub_key_enc' 1922 (see Section 3.3). 1924 o REQ7: Specify the exact format of the 'key' value (see 1925 Section 4.1.2.1). 1927 o REQ8: Specify the acceptable values of 'gkty' (see 1928 Section 4.1.2.1). 1930 o REQ9: Specify the format of the identifiers of group members (see 1931 Section 4.1.2.1). 1933 o REQ10: Specify the communication protocol the members of the group 1934 must use (e.g., multicast CoAP). 1936 o REQ11: Specify the security protocol the group members must use to 1937 protect their communication (e.g., group OSCORE). This must 1938 provide encryption, integrity and replay protection. 1940 o REQ12: Specify and register the application profile identifier 1941 (see Section 4.1.2.1). 1943 o REQ13: Specify policies at the KDC to handle ids that are not 1944 included in get_pub_keys (see Section 4.1.3.1). 1946 o REQ14: If used, specify the format and content of 'group_policies' 1947 and its entries (see Section 4.1.2.1). 1949 o REQ15: Specify the format of newly-generated individual keying 1950 material for group members, or of the information to derive it, 1951 and corresponding CBOR label (see Section 4.1.6.2). 1953 o REQ16: Specify how the communication is secured between Client and 1954 KDC. Optionally, specify tranport profile of ACE 1955 [I-D.ietf-ace-oauth-authz] to use between Client and KDC (see 1956 Section 4.2. 1958 o REQ17: Specify how the nonce N_S is generated, if the token is not 1959 being posted (e.g. if it is used directly to validate TLS 1960 instead). 1962 o REQ18: Specify if 'mgt_key_material' used, and if yes specify its 1963 format and content (see Section 4.1.2.1). If the usage of 1964 'mgt_key_material' is indicated and its format defined for a 1965 specific key management scheme, that format must explicitly 1966 indicate the key management scheme itself. If a new rekeying 1967 scheme is defined to be used for an existing 'mgt_key_material' in 1968 an existing profile, then that profile will have to be updated 1969 accordingly, especially with respect to the usage of 1970 'mgt_key_material' related format and content. 1972 o OPT1: Optionally, specify the encoding of public keys, of 1973 'client_cred', and of 'pub_keys' if COSE_Keys are not used (see 1974 Section 4.1.2.1). 1976 o OPT2: Optionally, specify the negotiation of parameter values for 1977 signature algorithm and signature keys, if 'sign_info' and 1978 'pub_key_enc' are not used (see Section 3.3). 1980 o OPT3: Optionally, specify the encoding of 'pub_keys_repos' if the 1981 default is not used (see Section 4.1.2.1). 1983 o OPT4: Optionally, specify policies that instruct clients to retain 1984 unsuccessfully decrypted messages and for how long, so that they 1985 can be decrypted after getting updated keying material. 1987 o OPT5: Optionally, specify the behavior of the handler in case of 1988 failure to retrieve a public key for the specific node (see 1989 Section 4.1.2.1). 1991 o OPT6: Optionally, specify possible or required payload formats for 1992 specific error cases. 1994 Appendix B. Document Updates 1996 RFC EDITOR: PLEASE REMOVE THIS SECTION. 1998 B.1. Version -03 to -04 2000 o Revised RESTful interface, as to methods and parameters. 2002 o Extended processing of joining request, as to check/retrieval of 2003 public keys. 2005 o Revised and extended profile requirements. 2007 o Clarified specific usage of parameters related to signature 2008 algorithms/keys. 2010 o Included general content previously in draft-ietf-ace-key- 2011 groupcomm-oscore 2013 o Registration of media type and content format application/ace- 2014 group+cbor 2016 o Editorial improvements. 2018 B.2. Version -02 to -03 2020 o Exchange of information on the countersignature algorithm and 2021 related parameters, during the Token POST (Section 3.3). 2023 o Restructured KDC interface, with new possible operations 2024 (Section 4). 2026 o Client PoP signature for the Joining Request upon joining 2027 (Section 4.1.2.1). 2029 o Revised text on group member removal (Section 5). 2031 o Added more profile requirements (Appendix A). 2033 B.3. Version -01 to -02 2035 o Editorial fixes. 2037 o Distinction between transport profile and application profile 2038 (Section 1.1). 2040 o New parameters 'sign_info' and 'pub_key_enc' to negotiate 2041 parameter values for signature algorithm and signature keys 2042 (Section 3.3). 2044 o New parameter 'type' to distinguish different Key Distribution 2045 Request messages (Section 4.1). 2047 o New parameter 'client_cred_verify' in the Key Distribution Request 2048 to convey a Client signature (Section 4.1). 2050 o Encoding of 'pub_keys_repos' (Section 4.1). 2052 o Encoding of 'mgt_key_material' (Section 4.1). 2054 o Improved description on retrieval of new or updated keying 2055 material (Section 6). 2057 o Encoding of 'get_pub_keys' in Public Key Request (Section 7.1). 2059 o Extended security considerations (Sections 10.1 and 10.2). 2061 o New "ACE Public Key Encoding" IANA Registry (Section 11.2). 2063 o New "ACE Groupcomm Parameters" IANA Registry (Section 11.3), 2064 populated with the entries in Section 8. 2066 o New "Ace Groupcomm Request Type" IANA Registry (Section 11.4), 2067 populated with the values in Section 9. 2069 o New "ACE Groupcomm Policy" IANA Registry (Section 11.7) populated 2070 with two entries "Sequence Number Synchronization Method" and "Key 2071 Update Check Interval" (Section 4.2). 2073 o Improved list of requirements for application profiles 2074 (Appendix A). 2076 B.4. Version -00 to -01 2078 o Changed name of 'req_aud' to 'audience' in the Authorization 2079 Request (Section 3.1). 2081 o Defined error handling on the KDC (Sections 4.2 and 6.2). 2083 o Updated format of the Key Distribution Response as a whole 2084 (Section 4.2). 2086 o Generalized format of 'pub_keys' in the Key Distribution Response 2087 (Section 4.2). 2089 o Defined format for the message to request leaving the group 2090 (Section 5.2). 2092 o Renewal of individual keying material and methods for group 2093 rekeying initiated by the KDC (Section 6). 2095 o CBOR type for node identifiers in 'get_pub_keys' (Section 7.1). 2097 o Added section on parameter identifiers and their CBOR keys 2098 (Section 8). 2100 o Added request types for requests to a Join Response (Section 9). 2102 o Extended security considerations (Section 10). 2104 o New IANA registries "ACE Groupcomm Key Registry", "ACE Groupcomm 2105 Profile Registry", "ACE Groupcomm Policy Registry" and "Sequence 2106 Number Synchronization Method Registry" (Section 11). 2108 o Added appendix about requirements for application profiles of ACE 2109 on group communication (Appendix A). 2111 Acknowledgments 2113 The following individuals were helpful in shaping this document: 2114 Carsten Bormann, Rikard Hoeglund, Ben Kaduk, John Mattsson, Daniel 2115 Migault, Jim Schaad, Ludwig Seitz, Goeran Selander and Peter van der 2116 Stok. 2118 The work on this document has been partly supported by VINNOVA and 2119 the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact 2120 Initiative ACTIVE. 2122 Authors' Addresses 2124 Francesca Palombini 2125 Ericsson AB 2126 Torshamnsgatan 23 2127 Kista SE-16440 Stockholm 2128 Sweden 2130 Email: francesca.palombini@ericsson.com 2131 Marco Tiloca 2132 RISE AB 2133 Isafjordsgatan 22 2134 Kista SE-16440 Stockholm 2135 Sweden 2137 Email: marco.tiloca@ri.se