idnits 2.17.1 draft-ietf-ace-key-groupcomm-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 18, 2020) is 1407 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 2372 -- Looks like a reference, but probably isn't: '2' on line 2374 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-33 == Outdated reference: A later version (-16) exists of draft-ietf-ace-oauth-params-13 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-08 == Outdated reference: A later version (-12) exists of draft-ietf-cose-rfc8152bis-algs-09 ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') == Outdated reference: A later version (-15) exists of draft-ietf-cose-rfc8152bis-struct-10 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-09) exists of draft-bormann-core-ace-aif-07 == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-10 == Outdated reference: A later version (-17) exists of draft-ietf-ace-mqtt-tls-profile-05 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-10 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-11) exists of draft-ietf-core-groupcomm-bis-00 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group F. Palombini 3 Internet-Draft Ericsson AB 4 Intended status: Standards Track M. Tiloca 5 Expires: December 20, 2020 RISE AB 6 June 18, 2020 8 Key Provisioning for Group Communication using ACE 9 draft-ietf-ace-key-groupcomm-07 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 December 20, 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 . . . . . . . . . . . . . . . . . 9 57 3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 10 58 4. Keying Material Provisioning and Group Membership Management 14 59 4.1. Interface at the KDC . . . . . . . . . . . . . . . . . . 15 60 4.2. Joining Exchange . . . . . . . . . . . . . . . . . . . . 30 61 4.3. Retrieval of Updated Keying Material . . . . . . . . . . 31 62 4.4. Retrieval of New Keying Material . . . . . . . . . . . . 33 63 4.5. Retrieval of Public Keys and Roles for Group Members . . 34 64 4.6. Update of Public Key . . . . . . . . . . . . . . . . . . 34 65 4.7. Retrieval of Group Policies . . . . . . . . . . . . . . . 35 66 4.8. Retrieval of Keying Material Version . . . . . . . . . . 36 67 4.9. Group Leaving Request . . . . . . . . . . . . . . . . . . 36 68 5. Removal of a Node from the Group . . . . . . . . . . . . . . 36 69 6. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 37 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 38 71 7.1. Update of Keying Material . . . . . . . . . . . . . . . . 40 72 7.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 40 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 74 8.1. Media Type Registrations . . . . . . . . . . . . . . . . 41 75 8.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 42 76 8.3. OAuth Parameters Registry . . . . . . . . . . . . . . . . 42 77 8.4. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 42 78 8.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 43 79 8.6. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 43 80 8.7. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 44 81 8.8. ACE Groupcomm Policy Registry . . . . . . . . . . . . . . 45 82 8.9. Sequence Number Synchronization Method Registry . . . . . 46 83 8.10. Interface Description (if=) Link Target Attribute Values 84 Registry . . . . . . . . . . . . . . . . . . . . . . . . 46 85 8.11. Expert Review Instructions . . . . . . . . . . . . . . . 46 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 47 88 9.2. Informative References . . . . . . . . . . . . . . . . . 49 89 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 51 90 Appendix A. Requirements on Application Profiles . . . . . . . . 51 91 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 53 92 B.1. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 53 93 B.2. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 54 94 B.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 54 95 B.4. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 54 96 B.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 55 98 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 56 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 101 1. Introduction 103 This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to 104 define the message exchanges used to request, distribute and renew 105 the keying material in a group communication scenario, e.g. based on 106 multicast [I-D.ietf-core-groupcomm-bis] or on publishing-subscribing 107 [I-D.ietf-core-coap-pubsub]. The ACE framework is based on CBOR 108 [RFC7049], so CBOR is the format used in this specification. 109 However, using JSON [RFC8259] instead of CBOR is possible, using the 110 conversion method specified in Sections 4.1 and 4.2 of [RFC7049]. 112 Profiles that use group communication can build on this document, by 113 defining a number of details such as the exact group communication 114 protocol and security protocols used. The specific list of details a 115 profile needs to define is shown in Appendix A. 117 If the application requires backward and forward security, new keying 118 material is generated and distributed to the group upon membership 119 changes. A key management scheme performs the actual distribution of 120 the new keying material to the group. In particular, the key 121 management scheme rekeys the current group members when a new node 122 joins the group, and the remaining group members when a node leaves 123 the group. Rekeying mechanisms can be based on [RFC2093], [RFC2094] 124 and [RFC2627]. 126 1.1. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in BCP 131 14 [RFC2119] [RFC8174] when, and only when, they appear in all 132 capitals, as shown here. 134 Readers are expected to be familiar with the terms and concepts 135 described in [I-D.ietf-ace-oauth-authz][I-D.ietf-cose-rfc8152bis-stru 136 ct][I-D.ietf-cose-rfc8152bis-algs], such as Authorization Server (AS) 137 and Resource Server (RS). 139 This document additionally uses the following terminology: 141 o Transport profile, to indicate a profile of ACE as per 142 Section 5.6.4.3 of [I-D.ietf-ace-oauth-authz]. A transport 143 profile specifies the communication protocol and communication 144 security protocol between an ACE Client and Resource Server, as 145 well as proof-of-possession methods, if it supports proof-of- 146 possession access tokens, etc. Tranport profiles of ACE include, 147 for instance, [I-D.ietf-ace-oscore-profile], 148 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-mqtt-tls-profile]. 150 o Application profile, that defines how applications enforce and use 151 supporting security services they require. These services may 152 include, for instance, provisioning, revocation and 153 (re-)distribution of keying material. An application profile may 154 define specific procedures and message formats. 156 2. Overview 158 +------------+ +-----------+ 159 | AS | | KDC | 160 | | .-------->| | 161 +------------+ / +-----------+ 162 ^ / 163 | / 164 v / +-----------+ 165 +------------+ / +------------+ |+-----------+ 166 | Client |<-' | Dispatcher | ||+-----------+ 167 | |<-------->| (RS) |<------->|| Group | 168 +------------+ +------------+ +| members | 169 +-----------+ 171 Figure 1: Key Distribution Participants 173 The following participants (see Figure 1) take part in the 174 authorization and key distribution. 176 o Client (C): node that wants to join the group communication. It 177 can request write and/or read rights. 179 o Authorization Server (AS): same as AS in the ACE Framework; it 180 enforces access policies, and knows if a node is allowed to join a 181 given group with write and/or read rights. 183 o Key Distribution Center (KDC): maintains the keying material to 184 protect group communications, and provides it to Clients 185 authorized to join a given group. During the first part of the 186 exchange (Section 3), it takes the role of the RS in the ACE 187 Framework. During the second part (Section 4), which is not based 188 on the ACE Framework, it distributes the keying material. In 189 addition, it provides the latest keying material to group members 190 when requested or, if required by the application, when membership 191 changes. 193 o Dispatcher: entity through which the Clients communicate with the 194 group and which distributes messages to the group members. 195 Examples of dispatchers are: the Broker node in a pub-sub setting; 196 a relayer node for group communication that delivers group 197 messages as multiple unicast messages to all group members; an 198 implicit entity as in a multicast communication setting, where 199 messages are transmitted to a multicast IP address and delivered 200 on the transport channel. 202 This document specifies a mechanism for: 204 o Authorizing a new node to join the group (Section 3), and 205 providing it with the group keying material to communicate with 206 the other group members (Section 4). 208 o Leaving or removing a current group member from the group 209 (Section 5). 211 o Retrieval of keying material by a group member (Section 4.3 and 212 Section 4.4). 214 o Renewing and re-distributing the group keying material (rekeying) 215 upon a membership change in the group (Section 4.9 and Section 5). 217 Figure 2 provides a high level overview of the message flow for a 218 node joining a group communication setting, which can be expanded as 219 follows. 221 1. The joining node requests an Access Token from the AS, in order 222 to access a specific group-membership resource on the KDC and 223 hence join the associated group. The joining node will start or 224 continue using a secure communication association with the KDC, 225 according to the response from the AS. 227 2. The joining node transfers authentication and authorization 228 information to the KDC, by posting the obtained Access Token to 229 the /authz-info endpoint at the KDC. After that, a joining node 230 MUST have a secure communication association established with the 231 KDC, before starting to join a group under that KDC. Possible 232 ways to provide a secure communication association are DTLS 233 [RFC6347] and OSCORE [RFC8613]. 235 3. The joining node starts the joining process to become a member of 236 the group, by accessing the related group-membership resource at 237 the KDC. At the end of the joining process, the joining node has 238 received from the KDC the parameters and keying material to 239 securely communicate with the other members of the group, and the 240 KDC has stored the association between the authorization 241 information from the access token and the secure session with the 242 client. 244 4. The joining node and the KDC maintain the secure association, to 245 support possible future communications. These especially include 246 key management operations, such as retrieval of updated keying 247 material or participation to a group rekeying process. 249 C AS KDC Group 250 | | | Member 251 / | | | | 252 | | Authorization Request | | | 253 Defined | |-------------------------->| | | 254 in the | | | | | 255 ACE | | Authorization Response | | | 256 framework | |<--------------------------| | | 257 | | | | 258 \ |---------- Token Post --------->| | 259 | | | 260 |------- Joining Request ------->| | 261 | | | 262 |<------ Joining Response -------|-- Group Rekeying -->| 263 | | | 264 | Dispatcher | 265 | | | 266 |<===== Secure group communication =======|===========>| 267 | | | 269 Figure 2: Message Flow Upon New Node's Joining 271 The exchange of Authorization Request and Authorization Response 272 between Client and AS MUST be secured, as specified by the transport 273 profile of ACE used between Client and KDC. 275 The Joining Request and Joining Response, and all further 276 communications between the Client and the KDC MUST be sent over the 277 secure channel established as a result of the transport profile of 278 ACE used between Client and KDC. 280 All communications between a Client and the other group members MUST 281 be secured using the keying material provided in Section 4. 283 3. Authorization to Join a Group 285 This section describes in detail the format of messages exchanged by 286 the participants when a node requests access to a given group. This 287 exchange is based on ACE [I-D.ietf-ace-oauth-authz]. 289 As defined in [I-D.ietf-ace-oauth-authz], the Client requests from 290 the AS an authorization to join the group through the KDC (see 291 Section 3.1). If the request is approved and authorization is 292 granted, the AS provides the Client with a proof-of-possession access 293 token and parameters to securely communicate with the KDC (see 294 Section 3.2). 296 Communications between the Client and the AS MUST be secured, as 297 defined by the transport profile of ACE used. The Content-Format 298 used in the messages is the one specified by the used transport 299 profile of ACE (e.g. application/ace+cbor for the first two messages 300 and application/cwt for the third message, depending on the format of 301 the access token). The transport profile of ACE also defines a 302 number of details such as the communication and security protocols 303 used with the KDC (see Appendix C of [I-D.ietf-ace-oauth-authz]). 305 Figure 3 gives an overview of the exchange described above. 307 Client AS KDC 308 | | | 309 |---- Authorization Request: POST /token ------>| | 310 | | | 311 |<--- Authorization Response: 2.01 (Created) ---| | 312 | | | 313 |----- POST Token: POST /authz-info --------------->| 314 | | 316 Figure 3: Message Flow of Join Authorization 318 3.1. Authorization Request 320 The Authorization Request sent from the Client to the AS is defined 321 in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MAY contain the 322 following parameters, which, if included, MUST have the corresponding 323 values: 325 o 'scope', containing the identifier of the specific group(s), or 326 topic(s) in the case of pub-sub, that the Client wishes to access, 327 and optionally the role(s) that the Client wishes to take. 329 This value is a CBOR byte string, encoding a CBOR array of one or 330 more entries. 332 An entry has as value a CBOR array, which contains: 334 * As first element, the identifier of the specific group or 335 topic. 337 * Optionally, as second element, the role (or CBOR array of 338 roles) that the Client wishes to take in the group. This 339 element is optional since roles may have been pre-assigned to 340 the Client, as associated to its verifiable identity 341 credentials. Alternatively, the application may have defined a 342 single, well-known role for the target resource(s) and 343 audience(s). Note that, if applicable in the application use 344 cases, the application profile can define a format for the role 345 as the one defined in [I-D.bormann-core-ace-aif]. 347 In each entry, the encoding of the group or topic identifier (REQ1 348 in Appendix A) and of the role identifiers (REQ2) is application 349 specific, and part of the requirements for the application 350 profile. 352 In particular, the application profile may specify CBOR values to 353 use for abbreviating role identifiers (OPT7). 355 The CDDL definition [RFC8610] of scope, using as example group 356 identifier encoded as byte string and role identifier as text 357 string, is given in Figure 4. 359 o 'audience', with an identifier of a KDC. 361 o 'req_cnf', as defined in Section 3.1 of 362 [I-D.ietf-ace-oauth-params], optionally containing the public key 363 or a reference to the public key of the Client, if it wishes to 364 communicate that to the AS. 366 o Other additional parameters as defined in 367 [I-D.ietf-ace-oauth-authz], if necessary. 369 As in [I-D.ietf-ace-oauth-authz], these parameters are included in 370 the payload, which is formatted as a CBOR map. The Content-Format 371 "application/ace+cbor" defined in Section 8.14 of 372 [I-D.ietf-ace-oauth-authz] is used. 374 gid = bstr 376 role = tstr 378 scope_entry = [ gid , ? ( role / [ 2*role ] ) ] 380 scope = << [ + scope_entry ] >> 382 Figure 4: CDLL definition of scope, using as example group identifier 383 encoded as bstr and role as tstr 385 3.2. Authorization Response 387 The Authorization Response sent from the AS to the Client is defined 388 in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST contain the 389 following parameters: 391 o 'access_token', containing the proof-of-possession access token. 393 o 'cnf' if symmetric keys are used, not present if asymmetric keys 394 are used. This parameter is defined in Section 3.2 of 395 [I-D.ietf-ace-oauth-params] and contains the symmetric proof-of- 396 possession key that the Client is supposed to use with the KDC. 398 o 'rs_cnf' if asymmetric keys are used, not present if symmetric 399 keys are used. This parameter is defined in Section 3.2 of 400 [I-D.ietf-ace-oauth-params] and contains information about the 401 public key of the KDC. 403 o 'expires_in', contains the lifetime in seconds of the access 404 token. This parameter MAY be omitted if the application defines 405 how the expiration time is communicated to the Client via other 406 means, or if it establishes a default value. 408 Additionally, the Authorization Response MAY contain the following 409 parameters, which, if included, MUST have the corresponding values: 411 o 'scope' containing the granted scope, if different from the scope 412 requested by the client. This parameter has the same format and 413 encoding of 'scope' in the Authorization Request, defined in 414 Section 3.1. 416 o Other additional parameters as defined in 417 [I-D.ietf-ace-oauth-authz], if necessary. 419 The proof-of-possession access token (in 'access_token' above) MUST 420 contain the following parameters: 422 o a confirmation claim (see for example 'cnf' defined in Section 3.1 423 of [RFC8747] for CWT); 425 o an expiration time claim (see for example 'exp' defined in 426 Section 3.1.4 of [RFC8392] for CWT); 428 o a scope claim (see for example 'scope' registered in Section 8.13 429 of [I-D.ietf-ace-oauth-authz] for CWT). This claim has the same 430 encoding as 'scope' parameter above. Additionally, this claim has 431 the same value of the 'scope' parameter if the parameter is 432 present in the message, or it takes the value of 'scope' in the 433 Authorization Request otherwise. 435 The access token MAY additionally contain other claims that the 436 transport profile of ACE requires, or other optional parameters. 438 As in [I-D.ietf-ace-oauth-authz], these parameters are included in 439 the payload, which is formatted as a CBOR map. The Content-Format 440 "application/ace+cbor" is used. 442 When receiving an Authorization Request from a Client that was 443 previously authorized, and for which the AS still owns a valid non 444 expired access token, the AS MAY reply with that token. Note that it 445 is up to application profiles of ACE to make sure that re-posting the 446 same token does not cause re-use of keying material between nodes 447 (for example, that is done with the use of random nonces in 448 [I-D.ietf-ace-oscore-profile]). 450 3.3. Token Post 452 The Client sends a CoAP POST request including the access token to 453 the KDC, as specified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. 454 If the specific transport profile of ACE defines it, the Client MAY 455 use a different endpoint than /authz-info at the KDC to post the 456 access token to. 458 Optionally, the Client might want to request necessary information 459 concerning the public keys in the group, as well as concerning the 460 algorithm and related parameters for computing signatures in the 461 group. In such a case, the joining node MAY ask for that information 462 to the KDC in this same request. To this end, it sends the CoAP POST 463 request to the /authz-info endpoint using the Content-Format 464 "application/ace+cbor". The payload of the message MUST be formatted 465 as a CBOR map, including the access token and the following 466 parameters: 468 o 'sign_info' defined in Section 3.3.1. 470 o 'pub_key_enc' defined in Section 3.3.2, encoding the CBOR simple 471 value Null, to require information on the exact encoding of public 472 keys used in the group. 474 Alternatively, the joining node may retrieve this information by 475 other means. 477 After successful verification, the Client is authorized to receive 478 the group keying material from the KDC and join the group. In 479 particular, the KDC replies to the Client with a 2.01 (Created) 480 response, using Content-Format "application/ace+cbor" defined in 481 Section 8.14 of [I-D.ietf-ace-oauth-authz]. 483 The payload of the 2.01 response is a CBOR map. If the access token 484 contains a role that requires the Client to send its own public key 485 to the KDC when joining the group, the CBOR map MUST include the 486 parameter 'kdcchallenge' defined in Section Section 3.3.3, specifying 487 a dedicated challenge N_S generated by the KDC. The Client uses this 488 challenge to prove possession of its own private key (see the 489 'client_cred_verify' parameter in Section 4). Note that the payload 490 format of the response deviates from the default as defined in the 491 ACE framework (see Section 5.8.1 of [I-D.ietf-ace-oauth-authz]). 493 The KDC MUST store the 'kdcchallenge' value associated to the Client 494 at least until it receives a join request from it (see Section 4.2), 495 to be able to verify the proof of possession. The same challenge MAY 496 be reused several times by the Client, to generate new proof of 497 possessions, e.g. in case of update of the public key, or to join a 498 different group with a different key, so it is RECOMMENDED that the 499 KDC keeps storing the 'kdcchallenge' after the first join is 500 processed as well. If the KDC has already discarded the 501 'kdcchallenge', that will trigger an error response with a newly 502 generated 'kdcchallenge' that the client can use to restart the join 503 process, as specified in Section 4.2. 505 If either of 'sign_info' or 'pub_key_enc' were included in the 506 request, the KDC MAY include the 'sign_info' parameter defined in 507 Section 3.3.1, optionally including the 'pub_key_enc' parameter 508 Section 3.3.2. 510 The 'sign_info' parameter MUST be present if the POST request 511 included the 'sign_info' parameter and/or the pub_key_enc with value 512 Null. The encoding of the 'sign_info' parameter in the response is 513 defined in Section 3.3.2. Note that the field 'id' takes the value 514 of the group identifier for which the 'sign_info' applies to, in this 515 specification. 517 Note that the CBOR map specified as payload of the 2.01 (Created) 518 response may include further parameters, e.g. according to the 519 signalled transport profile of ACE. 521 Applications of this specification MAY define alternative specific 522 negotiations of parameter values for signature algorithm and 523 signature keys, if 'sign_info' and 'pub_key_enc' are not used (OPT2). 525 3.3.1. 'sign_info' Parameter 527 The 'sign_info' parameter is an OPTIONAL parameter of the Token Post 528 response message defined in Section 5.1.2. of 529 [I-D.ietf-ace-oauth-authz]. This parameter contains information and 530 parameters about the signature algorithm and the public keys to be 531 used between the Client and the RS. Its exact content is application 532 specific. 534 In this specification and in application profiles building on it, 535 this parameter is used to ask and retrieve from the KDC information 536 about the signature algorithm and related parameters used in the 537 group. 539 When used in the request, the 'sign_info' encodes the CBOR simple 540 value Null, to require information and parameters on the signature 541 algorithm and on the public keys used. 543 The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as 544 in the request is given below. 546 sign_info_req = nil 548 The 'sign_info' parameter of the 2.01 (Created) response is a CBOR 549 array of one ore more elements. The number of elements is lower or 550 at most equal to the number of groups the client has been authorized 551 to join. Each element contains information about signing parameters 552 and keys for one or more group or topic and is formatted as follows. 554 o The first element 'id' is an identifier of the group or an array 555 of identifiers for the groups for which this information applies. 557 o The second element 'sign_alg' is an integer or a text string if 558 the POST request included the 'sign_info' parameter with value 559 Null, and indicates the signature algorithm used in the group 560 identified by 'gid'. It is REQUIRED of the application profiles 561 to define specific values that this parameter can take (REQ3), 562 selected from the set of signing algorithms of the COSE Algorithms 563 registry [COSE.Algorithms]. If the POST request did not include 564 the 'sing_info' parameter, this element is encoded as the CBOR 565 simple value Null. 567 o The third element 'sign_parameters' is a CBOR array indicating the 568 parameters of the signature algorithm. Its content depends on the 569 value of 'sign_alg'. It is REQUIRED of the application profiles 570 to define the possible values and structure for the elements of 571 this parameter (REQ4). If the POST request did not include the 572 'sign_info' parameter, this element is encoded as the CBOR simple 573 value Null. 575 o The fourth element 'sign_key_parameters' is a CBOR array 576 indicating the parameters of the key used with the signature 577 algorithm. Its content depends on the value of 'sign_alg'. It is 578 REQUIRED of the application profiles to define the possible values 579 and structure for the elements of this parameter (REQ5). If the 580 POST request did not include the 'sing_info' parameter, this 581 element is encoded as the CBOR simple value Null. 583 o The fifth element 'pub_key_enc' parameter is optional and MUST 584 only be present if the POST request included the 'pub_key_enc' 585 parameter with value Null. If present, it is either a CBOR 586 integer indicating the encoding of public keys used in the group 587 identified by 'gid', or has value Null indicating that the KDC 588 does not act as repository of public keys for group members. Its 589 acceptable values are taken from the "CWT Confirmation Method" 590 Registry defined in [RFC8747]. It is REQUIRED of the application 591 profiles to define specific values to use for this parameter 592 (REQ6). 594 The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as 595 in the response is given below, with gid formatted as a bstr (note 596 that gid can be encoded differently, see REQ1). 598 sign_info_res = [ + sign_info_entry ] 600 sign_info_entry = 601 [ 602 id : gid / [ + gid ], 603 sign_alg : int / tstr / nil, 604 sign_parameters : [ any ] / nil, 605 sign_key_parameters : [ any ] / nil, 606 ? pub_key_enc_res = int / nil 607 ] 609 gid = bstr 611 3.3.2. 'pub_key_enc' Parameter 613 The 'pub_key_enc' parameter is an OPTIONAL parameter of the Token 614 Post response message defined in Section 5.1.2. of 615 [I-D.ietf-ace-oauth-authz]. This parameter contains information 616 about the exact encoding of public keys to be used between the Client 617 and the RS. Its exact content is application specific. 619 In this specification and in application profiles building on it, 620 this parameter is used to ask the KDC information about the encoding 621 of public keys used in the group. 623 The CDDL notation [RFC8610] of the 'pub_key_enc' parameter formatted 624 as in the request is given below. 626 pub_key_enc_req = nil 628 3.3.3. 'kdcchallenge' Parameter 630 The 'kdcchallenge' parameter is an OPTIONAL parameter of the Token 631 Post response message defined in Section 5.1.2. of 632 [I-D.ietf-ace-oauth-authz]. This parameter contains a challenge 633 generated by the KDC and provided to the Client. The Client may use 634 this challenge to prove possession of its own private key in the 635 Joining Request ((see the 'client_cred_verify' parameter in 636 Section 4). 638 4. Keying Material Provisioning and Group Membership Management 640 This section defines the interface available at the KDC. Moreover, 641 this section specifies how the clients can use this interface to join 642 a group, leave a group, retrieve new keying material or policies. 644 During the first exchange with the KDC ("Joining"), the Client sends 645 a request to the KDC, specifying the group it wishes to join (see 646 Section 4.2). Then, the KDC verifies the access token and that the 647 Client is authorized to join that group. If so, it provides the 648 Client with the keying material to securely communicate with the 649 other members of the group. Whenever used, the Content-Format in 650 messages containing a payload is set to application/ace- 651 groupcomm+cbor, as defined in Section 8.2. 653 When the Client is already a group member, the Client can use the 654 interface at the KDC to perform the following actions: 656 o The Client can (re-)get the current keying material, for cases 657 such as expiration, loss or suspected mismatch, due to e.g. reboot 658 or missed group rekeying. This is described in Section 4.3. 660 o The Client can retrieve a new individual key, or new input 661 material to derive it. This is described in Section 4.4. 663 o The Client can (re-)get the public keys of other group members, 664 e.g. if it is aware of new nodes joining the group after itself. 665 This is described in Section 4.5. 667 o The Client can (re-)get the policies currently enforced in the 668 group. This is described in Section 4.7. 670 o The Client can (re-)get the version number of the keying material 671 currently used in the group. This is described in Section 4.8. 673 o The Client can request to leave the group. This is further 674 discussed in Section 4.9. 676 Upon receiving a request from a Client, the KDC MUST check that it is 677 storing a valid access token from that Client for the group 678 identifier associated to the endpoint. If that is not the case, i.e. 679 the KDC does not store a valid access token or this is not valid for 680 that Client for the group identifier at hand, the KDC MUST respond to 681 the Client with a 4.01 (Unauthorized) error message. 683 4.1. Interface at the KDC 685 The KDC is configured with the following resources. Note that the 686 root url-path "ace-group" given here are default names: 687 implementations are not required to use these names, and can define 688 their own instead. The Interface Description (if=) Link Target 689 Attribute value ace-group is registered (Section 8.10) and can be 690 used to describe this interface. 692 o /ace-group : this resource is fixed and indicates that this 693 specification is used. If other applications run on a KDC 694 implementing this specification and use this same resource, these 695 applications will collide, and a mechanism will be needed to 696 differentiate the endpoints. 698 o /ace-group/GROUPNAME : one sub-resource to /ace-group is 699 implemented for each group the KDC manages. These resources are 700 identified by the group identifiers of the groups the KDC manages 701 (in this example, the group identifier has value "GROUPNAME"). 702 These resources support GET and POST method. 704 o /ace-group/GROUPNAME/pub-key : this sub-resource is fixed and 705 supports GET and FETCH methods. 707 o /ace-group/GROUPNAME/policies: this sub-resource is fixed and 708 supports the GET method. 710 o /ace-group/GROUPNAME/ctx-num: this sub-resource is fixed and 711 supports the GET method. 713 o /ace-group/GROUPNAME/nodes/NODENAME: one sub-resource to /ace- 714 group/GROUPNAME is implemented for each node in the group the KDC 715 manages. These resources are identified by the node name (in this 716 example, the node name has value "NODENAME"). These resources 717 support GET, PUT and DELETE methods. 719 o /ace-group/GROUPNAME/nodes/NODENAME/pub-key: one sub-resource to 720 /ace-group/GROUPNAME/nodes/NODENAME is implemented for each node 721 in the group the KDC manages. These resources are identified by 722 the node name (in this example, the node name has value 723 "NODENAME"). These resources support the POST method. 725 The details for the handlers of each resource are given in the 726 following sections. These endpoints are used to perform the 727 operations introduced in Section 4. 729 4.1.1. ace-group 731 No handlers are implemented for this resource. 733 4.1.2. ace-group/GROUPNAME 735 This resource implements GET and POST handlers. 737 4.1.2.1. POST Handler 739 The POST handler adds the public key of the client to the list of the 740 group members' public keys and returns the symmetric group keying 741 material for the group identified by "GROUPNAME". 743 The handler expects a request with payload formatted as a CBOR map 744 which MAY contain the following fields, which, if included, MUST have 745 the corresponding values: 747 o 'scope', with value the specific resource at the KDC that the 748 Client is authorized to access, i.e. group or topic identifier, 749 and role(s). This value is a CBOR byte string encoding one scope 750 entry, as defined in Section 3.1. 752 o 'get_pub_keys', if the Client wishes to receive the public keys of 753 the other nodes in the group from the KDC. The value is an empty 754 CBOR array. This parameter may be present if the KDC stores the 755 public keys of the nodes in the group and distributes them to the 756 Client; it is useless to have here if the set of public keys of 757 the members of the group is known in another way, e.g. it was 758 provided by the AS. 760 o 'client_cred', with value the public key or certificate of the 761 Client, encoded as a CBOR byte string. This field contains the 762 public key of the Client. This field is used if the KDC is 763 managing (collecting from/distributing to the Client) the public 764 keys of the group members, and if the Client's role in the group 765 will require for it to send messages to the group. The default 766 encoding for public keys is COSE Keys. Alternative specific 767 encodings of this parameter MAY be defined in applications of this 768 specification (OPT1 in Appendix A). 770 o 'cnonce', with the same encoding as defined for the "cnonce" 771 parameter of Ace, in Section 5.1.2 of [I-D.ietf-ace-oauth-authz], 772 and including a dedicated nonce N_C generated by the Client. This 773 parameter MUST be present if the 'client_cred' parameter is 774 present. 776 o 'client_cred_verify', encoded as a CBOR byte string. This 777 parameter MUST be present if the 'client_cred' parameter is 778 present and no public key associated to the client's token can be 779 retrieved for that group. This parameter contains a signature 780 computed by the Client over the scope concatenated with N_S 781 concatenated with N_C, where: 783 * scope is the byte string specified in the 'scope parameter 784 above'. 786 * N_S is the challenge received from the KDC in the 787 'kdcchallenge' parameter of the 2.01 (Created) response to the 788 token POST request (see Section 3.3). 790 * N_C is the nonce generated by the Client and specified in the 791 'cnonce' parameter above. 793 If the token is not being posted (e.g. if it is used directly to 794 validate TLS instead), it is REQUIRED of the specific profile to 795 define how the challenge N_S is generated (REQ17). The Client 796 computes the signature by using its own private key, whose 797 corresponding public key is either directly specified in the 798 'client_cred' parameter or included in the certificate specified in 799 the 'client_cred' parameter. 801 o 'pub_keys_repos', can be present if a certificate is present in 802 the 'client_cred' field, with value the URI of the certificate of 803 the Client. This parameter is encoded as a CBOR text string. 804 Alternative specific encodings of this parameter MAY be defined in 805 applications of this specification (OPT3). 807 o 'control_path', with value a full URI, encoded as a CBOR text 808 string. If 'control_path' is supported by the Client, the Client 809 acts as a CoAP server and hosts a resource at this specific URI. 810 The KDC MAY use this URI to send CoAP requests to the Client 811 (acting as CoAP server in this exchange), for example for 812 individual provisioning of new keying material when performing a 813 group rekeying (see Section 4.3), or to inform the Client of its 814 removal from the group Section 5. If the KDC does not implement 815 mechanisms using this resource, it can just ignore this parameter. 816 Other additional functionalities of this resource MAY be defined 817 in application profiles of this specifications (OPT9). In 818 particular, this resource is intended for communications 819 concerning exclusively the group or topic specified in the 'scope' 820 parameter. 822 The handler verifies that the group identifier of the /ace-group/ 823 GROUPNAME path is a subset of the 'scope' stored in the access token 824 associated to this client. If verification fails, the KDC MUST 825 respond with a 4.01 (Unauthorized) error message. The KDC MAY set 826 the payload with the 'sign_info' and 'pub_key_enc' parameter, 827 formatted as 'sign_info_res' and 'pub_key_enc_res' in the payload of 828 the 2.01 (Created) response to the Token Post as defined in 829 Section 3.3. Note that in this case, the content format MUST be set 830 to application/ace+cbor. 832 If the request is not formatted correctly (e.g. unknown, not-expected 833 fields present, or expected fields with incorrect format), the 834 handler MUST respond with a 4.00 (Bad Request) error message. The 835 response MAY contain a CBOR map in the payload with ace+cbor format, 836 e.g. it could send back "pub_key_enc" set to Null if the Client sent 837 its own public key and the KDC is not set to store public keys of the 838 group members. Application profiles MAY define optional or mandatory 839 payload formats for specific error cases (OPT6). 841 If the KDC stores the group members' public keys, the handler checks 842 if one public key is already associated to the access token received 843 (see Section 4.2 for an example) and to the group identified by 844 "GROUPNAME". If that is not the case, it retrieves it from the 845 'client_cred' field and associates it to the access token received, 846 after verifications succed. In particular, the KDC verifies: 848 o that such public key has an acceptable format for the group 849 identified by "GROUPNAME", i.e. it is encoded as expected and is 850 compatible with the signature algorithm and possible associated 851 parameters. If that cannot be verified, it is RECOMMENDED that 852 the handler stops the process and responds with a 4.00 (Bad 853 Request) error message. Applications profiles MAY define 854 alternatives (OPT5). 856 o that the signature contained in "client_cred_verify" passes 857 verification. If that cannot be verified, the handler MUST 858 respond with a 4.00 (Bad Request) error message, and if the token 859 was posted (see REQ17) including the 'kdcchallenge' associated to 860 this Client (see Section 3.3) if it can be retrieved, or otherwise 861 newly generated, in a CBOR map in the payload. This error 862 response MUST also have Content-Format "application/ace+cbor". 864 If one public key is already associated to the access token and to 865 that group, but the 'client_cred' is populated with a different 866 public key, the handler MUST delete the previous one and replace it 867 with this one, after verifying the points above. 869 If the token was posted but the KDC cannot retrieve the 870 'kdcchallenge' associated to this Client (see Section 3.3), the KDC 871 MUST respond with a 4.00 Bad Request error response, including a 872 newly generated 'kdcchallenge' in a CBOR map in the payload. This 873 error response MUST also have Content-Format "application/ace+cbor". 875 If all verifications succeed, the handler: 877 o Adds the node to the list of current members of the group. 879 o Assigns a name NODENAME to the node, and creates a sub-resource to 880 /ace-group/GROUPNAME/ at the KDC (e.g. "/ace- 881 group/GROUPNAME/nodes/NODENAME"). 883 o Associates the identifier "NODENAME" with the access token and the 884 secure session for that node. 886 o If the KDC manages public keys for group members: 888 * Adds the retrieved public key of the node to the list of public 889 keys stored for the group identified by "GROUPNAME" 891 * Associates the node's public key with its access token and the 892 group identified by "GROUPNAME", if such association did not 893 already exist. 895 o Returns a 2.01 (Created) message containing the symmetric group 896 keying material, the group policies and all the public keys of the 897 current members of the group, if the KDC manages those and the 898 Client requested them. 900 The response message also contains the URI path to the sub-resource 901 created for that node in a Location-Path CoAP option. The payload of 902 the response is formatted as a CBOR map which MUST contain the 903 following fields and values: 905 o 'gkty', identifying the key type of the 'key' parameter. The set 906 of values can be found in the "Key Type" column of the "ACE 907 Groupcomm Key" Registry. Implementations MUST verify that the key 908 type matches the application profile being used, if present, as 909 registered in the "ACE Groupcomm Key" registry. 911 o 'key', containing the keying material for the group communication, 912 or information required to derive it. 914 o 'num', containing the version number of the keying material for 915 the group communication, formatted as an integer. The initial 916 version MUST be set to 0 at the KDC. This is a strictly monotonic 917 increasing field. 919 The exact format of the 'key' value MUST be defined in applications 920 of this specification (REQ7), as well as accepted values of 'gkty' by 921 the application (REQ8). Additionally, documents specifying the key 922 format MUST register it in the "ACE Groupcomm Key" registry defined 923 in Section 8.6, including its name, type and application profile to 924 be used with. 926 +----------+----------------+---------+-------------------------+ 927 | Name | Key Type Value | Profile | Description | 928 +----------+----------------+---------+-------------------------+ 929 | Reserved | 0 | | This value is reserved | 930 +----------+----------------+---------+-------------------------+ 932 Figure 5: Key Type Values 934 Optionally, the response MAY contain the following parameters, which, 935 if included, MUST have the corresponding values: 937 o 'ace-groupcomm-profile', with value a CBOR integer that MUST be 938 used to uniquely identify the application profile for group 939 communication. Applications of this specification MUST register 940 an application profile identifier and the related value for this 941 parameter in the "ACE Groupcomm Profile" Registry (REQ12). 943 o 'exp', with value the expiration time of the keying material for 944 the group communication, encoded as a CBOR unsigned integer. This 945 field contains a numeric value representing the number of seconds 946 from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, 947 ignoring leap seconds, analogous to what specified for NumericDate 948 in Section 2 of [RFC7519]. Group members MUST stop using the 949 keying material to protect outgoing messages and retrieve new 950 keying material at the time indicated in this field. 952 o 'exp_delta', with value the time interval (starting at 'exp') 953 during which the keying material for the group communication can 954 still be used for verifying incoming messages, encoded as a CBOR 955 unsigned integer. This field contains a numeric value 956 representing the number of seconds from 'exp' until the specified 957 UTC date/time after which group members MUST stop using the keying 958 material to verify incoming messages. 960 o 'pub_keys', may only be present if 'get_pub_keys' was present in 961 the request. This parameter is a CBOR byte string, which encodes 962 the public keys of all the group members paired with the 963 respective member identifiers. The default encoding for public 964 keys is COSE Keys, so the default encoding for 'pub_keys' is a 965 CBOR byte string wrapping a COSE_KeySet (see 966 [I-D.ietf-cose-rfc8152bis-struct]), which contains the public keys 967 of all the members of the group. In particular, each COSE Key in 968 the COSE_KeySet includes the identifier of the corresponding group 969 member as value of its 'kid' key parameter. Alternative specific 970 encodings of this parameter MAY be defined in applications of this 971 specification (OPT1). The specific format of the identifiers of 972 group members MUST be specified in the application profile (REQ9). 974 o 'peer_roles', MUST be present if 'pub_keys' is present. This 975 parameter is a CBOR array of n elements, with n the number of 976 members in the group (and number of public keys included in the 977 'pub_keys' parameter). The i-th element of the array specifies 978 the role (or CBOR array of roles) that the group member associated 979 to the i-th public key in 'pub_keys' has in the group. In 980 particular, each array element is encoded as the role element of a 981 scope entry, as defined in Section 3.1. 983 o 'group_policies', with value a CBOR map, whose entries specify how 984 the group handles specific management aspects. These include, for 985 instance, approaches to achieve synchronization of sequence 986 numbers among group members. The elements of this field are 987 registered in the "ACE Groupcomm Policy" Registry. This 988 specification defines the two elements "Sequence Number 989 Synchronization Method" and "Key Update Check Interval", which are 990 summarized in Figure 6. Application profiles that build on this 991 document MUST specify the exact content format of included map 992 entries (REQ14). 994 +--------------+-------+----------|--------------------|------------+ 995 | Name | CBOR | CBOR | Description | Reference | 996 | | label | type | | | 997 |--------------+-------+----------|--------------------|------------| 998 | Sequence | TBD1 | tstr/int | Method for a re- | [[this | 999 | Number | | | cipient node to | document]] | 1000 | Synchroniza- | | | synchronize with | | 1001 | tion Method | | | sequence numbers | | 1002 | | | | of a sender node. | | 1003 | | | | Its value is taken | | 1004 | | | | from the 'Value' | | 1005 | | | | column of the | | 1006 | | | | Sequence Number | | 1007 | | | | Synchronization | | 1008 | | | | Method registry | | 1009 | | | | | | 1010 | Key Update | TBD2 | int | Polling interval | [[this | 1011 | Check | | | in seconds, to | document]] | 1012 | Interval | | | check for new | | 1013 | | | | keying material at | | 1014 | | | | the KDC | | 1015 +--------------+-------+----------|--------------------|------------+ 1017 Figure 6: ACE Groupcomm Policies 1019 o 'mgt_key_material', encoded as a CBOR byte string and containing 1020 the administrative keying material to participate in the group 1021 rekeying performed by the KDC. The application profile MUST 1022 define if this field is used, and if used then MUST specify the 1023 exact format and content which depend on the specific rekeying 1024 scheme used in the group. If the usage of 'mgt_key_material' is 1025 indicated and its format defined for a specific key management 1026 scheme, that format must explicitly indicate the key management 1027 scheme itself. If a new rekeying scheme is defined to be used for 1028 an existing 'mgt_key_material' in an existing profile, then that 1029 profile will have to be updated accordingly, especially with 1030 respect to the usage of 'mgt_key_material' related format and 1031 content (REQ18). 1033 Specific application profiles that build on this document MUST 1034 specify the communication protocol that members of the group use to 1035 communicate with each other (REQ10) and how exactly the keying 1036 material is used to protect the group communication (REQ11). 1038 CBOR labels for these fields are defined in Section 6. 1040 4.1.2.2. GET Handler 1042 The GET handler returns the symmetric group keying material for the 1043 group identified by "GROUPNAME". 1045 The handler expects a GET request. 1047 The handler verifies that the group identifier of the /ace-group/ 1048 GROUPNAME path is a subset of the 'scope' stored in the access token 1049 associated to this client. If verification fails, the KDC MUST 1050 respond with a 4.01 (Unauthorized) error message. The KDC MAY set 1051 the payload with the 'sign_info' and 'pub_key_enc' parameter, 1052 formatted as 'sign_info_res' and 'pub_key_enc_res' in the payload of 1053 the 2.01 (Created) response to the Token Post as defined in 1054 Section 3.3. Note that in this case, the content format MUST be set 1055 to application/ace+cbor. 1057 Additionally, the handler verifies that the node is a current member 1058 of the group. If verification fails, the KDC MUST respond with a 1059 4.00 (Bad Request) error message. 1061 If verification succeeds, the handler returns a 2.05 (Content) 1062 message containing the symmetric group keying material. The payload 1063 of the response is formatted as a CBOR map which MUST contain the 1064 parameters 'gkty','key' and 'num' specified in Section 4.1.2.1. 1066 The payload MAY also include the parameters 'ace-groupcomm-profile', 1067 'exp', 'exp_delta' and 'mgt_key_material' parameters specified in 1068 Section 4.1.2.1. 1070 4.1.3. ace-group/GROUPNAME/pub-key 1072 This resource implements GET and FETCH handlers. 1074 4.1.3.1. FETCH Handler 1076 The FETCH handler receives identifiers of group members for the group 1077 identified by "GROUPNAME" and returns the public keys of such group 1078 members. 1080 The handler expects a request with payload formatted as a CBOR map. 1081 The payload of this request is a CBOR Map that MUST contain the 1082 following fields: 1084 o 'get_pub_keys', whose value is a non-empty CBOR array containing 1085 two CBOR arrays: 1087 * The first array contains zero or more roles (or combination of 1088 roles) of group members for the group identified by 1089 "GROUPNAME". 1091 * The second array contains zero or more identifiers of group 1092 members for the group identified by "GROUPNAME". 1094 The CDDL definition [RFC8610] of 'get_pub_keys' is given in Figure 7 1095 using as example encoding: node identifier encoded as byte string, 1096 role identifier as text string, and combination of roles encoded as a 1097 CBOR array of roles. Note that the empty array is not valid for this 1098 handler, but is valid for the value of "get_pub_keys" received by the 1099 handler of POST to ace-group/GROUPNAME (see Section 4.1.2.1). 1101 id = bstr 1103 role = tstr 1105 comb_role = [ 2*role ] 1107 get_pub_keys = [ [ *(role / comb_role) ], [ *id ] ] / [ ] 1109 Figure 7: CDLL definition of get_pub_keys, using as example node 1110 identifier encoded as bstr and role as tstr 1112 The specific format of public keys as well as identifiers, roles and 1113 combination of roles of group members MUST be specified by the 1114 application profile (OPT1, REQ2, REQ9). 1116 The handler verifies that the group identifier of the /ace-group/ 1117 GROUPNAME path is a subset of the 'scope' stored in the access token 1118 associated to this client. If verification fails, the KDC MUST 1119 respond with a 4.01 (Unauthorized) error message. 1121 If verification succeeds, the handler identifies the public keys of 1122 the current group members for which either: - the role identifier 1123 matches with one of those indicated in the request (including the 1124 exact combination of roles requested), or - the identifier matches 1125 with one of those indicated in the request. 1127 Then, the handler returns a 2.05 (Content) message response with 1128 payload formatted as a CBOR map, containing only the 'pub_keys' and 1129 'peer_roles' parameters from Section 4.1.2.1. In particular, 1130 'pub_keys' encodes the list of public keys of those group members 1131 including the respective member identifiers, while 'peer_roles' 1132 encodes their respective role (or CBOR array of roles) in the group. 1134 If the KDC does not store any public key associated with the 1135 specified member identifiers, the handler returns a response with 1136 payload formatted as a CBOR byte string of zero length. The specific 1137 format of public keys as well as of identifiers of group members is 1138 specified by the application profile (OPT1, REQ9). 1140 The handler MAY enforce one of the following policies, in order to 1141 handle possible identifiers that are included in the 'get_pub_keys' 1142 parameter of the request but are not associated to any current group 1143 member. Such a policy MUST be specified by the application profile 1144 (REQ13) 1146 o The KDC silently ignores those identifiers. 1148 o The KDC retains public keys of group members for a given amount of 1149 time after their leaving, before discarding them. As long as such 1150 public keys are retained, the KDC provides them to a requesting 1151 Client. 1153 Note that this resource handlers only verify that the node is 1154 authorized by the AS to access this resource. Nodes that are not 1155 members of the group but are authorized to do signature verifications 1156 on the group messages may be allowed to access this resource, if the 1157 application needs it. 1159 4.1.3.2. GET Handler 1161 The handler expects a GET request. 1163 The handler verifies that the group identifier of the /ace-group/ 1164 GROUPNAME path is a subset of the 'scope' stored in the access token 1165 associated to this client. If verification fails, the KDC MUST 1166 respond with a 4.01 (Unauthorized) error message. 1168 If verification succeeds, the handler returns a 2.05 (Content) 1169 message containing the public keys of all the current group members, 1170 for the group identified by "GROUPNAME". The payload of the response 1171 is formatted as a CBOR map, containing only the 'pub_keys' and 1172 'peer_roles' parameters from Section 4.1.2.1. In particular, 1173 'pub_keys' encodes the list of public keys of those group members 1174 including the respective member identifiers, while 'peer_roles' 1175 encodes their respective role (or CBOR array of roles) in the group. 1177 If the KDC does not store any public key for the group, the handler 1178 returns a response with payload formatted as a CBOR byte string of 1179 zero length. The specific format of public keys as well as of 1180 identifiers of group members is specified by the application profile 1181 (OPT1, REQ9). 1183 Note that this resource handlers only verify that the node is 1184 authorized by the AS to access this resource. Nodes that are not 1185 members of the group but are authorized to do signature verifications 1186 on the group messages may be allowed to access this resource, if the 1187 application needs it. 1189 4.1.4. ace-group/GROUPNAME/policies 1191 This resource implements a GET handler. 1193 4.1.4.1. GET Handler 1195 The handler expects a GET request. 1197 The handler verifies that the group identifier of the /ace-group/ 1198 GROUPNAME path is a subset of the 'scope' stored in the access token 1199 associated to this client. If verification fails, the KDC MUST 1200 respond with a 4.01 (Unauthorized) error message. 1202 Additionally, the handler verifies that the node is a current member 1203 of the group. If verification fails, the KDC MUST respond with a 1204 4.00 (Bad Request) error message. 1206 If verification succeeds, the handler returns a 2.05 (Content) 1207 message containing the list of policies for the group identified by 1208 "GROUPNAME". The payload of the response is formatted as a CBOR map 1209 including only the parameter 'group_policies' defined in 1210 Section 4.1.2.1 and specifying the current policies in the group. If 1211 the KDC does not store any policy, the payload is formatted as a 1212 zero-length CBOR byte string. 1214 The specific format and meaning of group policies MUST be specified 1215 in the application profile (REQ14). 1217 4.1.5. ace-group/GROUPNAME/ctx-num 1219 This resource implements a GET handler. 1221 4.1.5.1. GET Handler 1223 The handler expects a GET request. 1225 The handler verifies that the group identifier of the /ace-group/ 1226 GROUPNAME path is a subset of the 'scope' stored in the access token 1227 associated to this client. If verification fails, the KDC MUST 1228 respond with a 4.01 (Unauthorized) error message. 1230 Additionally, the handler verifies that the node is a current member 1231 of the group. If verification fails, the KDC MUST respond with a 1232 4.00 (Bad Request) error message. 1234 If verification succeeds, the handler returns a 2.05 (Content) 1235 message containing an integer that represents the version number of 1236 the symmetric group keying material. This number is incremented on 1237 the KDC every time the KDC updates the symmetric group keying 1238 material. The payload of the response is formatted as a CBOR 1239 integer. 1241 4.1.6. ace-group/GROUPNAME/nodes/NODENAME 1243 This resource implements GET, PUT and DELETE handlers. 1245 4.1.6.1. PUT Handler 1247 The PUT handler is used to get the KDC to produce and return 1248 individual keying material to protect outgoing messages for the node 1249 (identified by "NODENAME") for the group identified by "GROUPNAME". 1251 The handler expects a request with empty payload. 1253 The handler verifies that the group identifier of the /ace-group/ 1254 GROUPNAME path is a subset of the 'scope' stored in the access token 1255 associated to this client, identified by "NODENAME". If verification 1256 fails, the KDC MUST respond with a 4.01 (Unauthorized) error message. 1258 Additionally, the handler verifies that the node is a current member 1259 of the group. If verification fails, the KDC MUST respond with a 1260 4.00 (Bad Request) error message. 1262 If verification succeeds, the handler returns a 2.05 (Content) 1263 message containing newly-generated individual keying material for the 1264 Client, or information enabling the Client to derive it. The payload 1265 of the response is formatted as a CBOR map. The specific format of 1266 newly-generated individual keying material for group members, or of 1267 the information to derive it, and corresponding CBOR label, MUST be 1268 specified in the application profile (REQ15) and registered in 1269 Section 8.5. 1271 4.1.6.2. GET Handler 1273 The handler expects a GET request. 1275 The handler verifies that the group identifier of the /ace-group/ 1276 GROUPNAME path is a subset of the 'scope' stored in the access token 1277 associated to this client, identified by "NODENAME". If verification 1278 fails, the KDC MUST respond with a 4.01 (Unauthorized) error message. 1280 The handler also verifies that the node sending the request and the 1281 node name used in the Uri-Path match. If that is not the case, the 1282 handler responds with a 4.01 (Unauthorized) error response. 1284 Additionally, the handler verifies that the node is a current member 1285 of the group. If verification fails, the KDC MUST respond with a 1286 4.00 (Bad Request) error message. 1288 If verification succeeds, the handler returns a 2.05 (Content) 1289 message containing both the group keying material and the individual 1290 keying material for the Client, or information enabling the Client to 1291 derive it. The payload of the response is formatted as a CBOR map. 1292 The format for the group keying material is the same as defined in 1293 the response of Section 4.1.2.2. The specific format of individual 1294 keying material for group members, or of the information to derive 1295 it, and corresponding CBOR label, MUST be specified in the 1296 application profile (REQ15) and registered in Section 8.5. 1298 4.1.6.3. DELETE Handler 1300 The DELETE handler removes the node identified by "NODENAME" from the 1301 group identified by "GROUPNAME". 1303 The handler expects a request with method DELETE (and empty payload). 1305 The handler only accept a request from the node that matches the 1306 "NODENAME" used in Uri-Path, and that is part of the "GROUPNAME" 1307 group: the handler verifies that the group identifier "GROUPNAME" is 1308 a subset of the 'scope' stored in the access token associated to this 1309 client, and that this client is identified by "NODENAME". If 1310 verification fails, the KDC MUST respond with a 4.01 (Unauthorized) 1311 error message. 1313 The handler also verifies that the node sending the request and the 1314 node name used in the Uri-Path match. If that is not the case, the 1315 handler responds with a 4.01 (Unauthorized) error response. 1317 Additionally, the handler verifies that the node is a current member 1318 of the group. If verification fails, the KDC MUST respond with a 1319 4.00 (Bad Request) error message. 1321 If verification succeeds, the handler removes the client from the 1322 group identified by "GROUPNAME", for specific roles if roles were 1323 specified in the 'scope' field, or for all roles. That includes 1324 removing the public key of the client if the KDC keep tracks of that. 1326 Then, the handler delete the sub-resource nodes/NODENAME and returns 1327 a 2.02 (Deleted) message with empty payload. 1329 4.1.7. ace-group/GROUPNAME/nodes/NODENAME/pub-key 1331 This resource implements a POST handler, if the KDC stores the public 1332 key of group members. If the KDC does not store the public keys of 1333 group members, the handler does not implement any method, and every 1334 request returns a 4.05 Method Not Allowed error. 1336 4.1.7.1. POST Handler 1338 The POST handler is used to replace the stored public key of this 1339 client (identified by "NODENAME") with the one specified in the 1340 request at the KDC, for the group identified by "GROUPNAME". 1342 The handler expects a POST request with payload as specified in 1343 Section 4.1.2.1, with the difference that it includes only the 1344 parameters 'client_cred', 'cnonce' and 'client_cred_verify'. In 1345 particular, the signature included in 'client_cred_verify' is 1346 expected to be computed as defined in Section 4.1.2.1, with a newly 1347 generated N_C nonce and the previously received N_S. The specific 1348 format of public keys is specified by the application profile (OPT1). 1350 The handler verifies that the group identifier GROUPNAME is a subset 1351 of the 'scope' stored in the access token associated to this client. 1352 If verification fails, the KDC MUST respond with a 4.01 1353 (Unauthorized) error message. 1355 If the request is not formatted correctly (e.g. unknown, not-expected 1356 fields present, or expected fields with incorrect format), the 1357 handler MUST respond with a 4.00 (Bad Request) error message. 1358 Application profiles MAY define optional or mandatory payload formats 1359 for specific error cases (OPT6). 1361 Otherwise, the handler checks that the public key specified in the 1362 'client_cred' field has a valid format for the group identified by 1363 "GROUPNAME", i.e. it is encoded as expected and is compatible with 1364 the signature algorithm and possible associated parameters. If that 1365 cannot be verified, the handler MUST respond with a 4.00 (Bad 1366 Request) error message. Applications profiles MAY define 1367 alternatives (OPT5). 1369 Otherwise, the handler verifies the signature contained in the 1370 'client_cred_verify' field of the request, using the public key 1371 specified in the 'client_cred' field. If the signature does not pass 1372 verification, the handler MUST respond with a 4.00 (Bad Request) 1373 error message. If the KDC cannot retrieve the 'kdcchallenge' 1374 associated to this Client (see Section 3.3), the KDC MUST respond 1375 with a 4.00 Bad Request error respons, including a newly generated 1376 'kdcchallenge' in a CBOR map in the payload the payload. This error 1377 response MUST also have Content-Format "application/ace+cbor". 1379 If verification succeeds, the handler replaces the old public key of 1380 the node NODENAME with the one specified in the 'client_cred' field 1381 of the request, and stores it as the new current public key of the 1382 node NODENAME, in the list of group members' public keys for the 1383 group identified by GROUPNAME. Then, the handler replies with a 2.04 1384 (Changed) response, which does not include a payload. 1386 4.2. Joining Exchange 1388 Figure 8 gives an overview of the Joining exchange between Client and 1389 KDC, when the Client first joins a group. 1391 Client KDC 1392 | | 1393 |----- Joining Request: POST /ace-group/GROUPNAME ------>| 1394 | | 1395 |<--------- Joining Response: 2.01 (Created) ----------- | 1396 | Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME" | 1398 Figure 8: Message Flow of First Exchange for Group Joining 1400 If not previously established, the Client and the KDC MUST first 1401 establish a pairwise secure communication channel (REQ16). This can 1402 be achieved, for instance, by using a transport profile of ACE. The 1403 Joining exchange MUST occur over that secure channel. The Client and 1404 the KDC MAY use that same secure channel to protect further pairwise 1405 communications that must be secured. 1407 The secure communication protocol is REQUIRED to establish the secure 1408 channel between Client and KDC by using the proof-of-possession key 1409 bound to the access token. As a result, the proof-of-possession to 1410 bind the access token to the Client is performed by using the proof- 1411 of-possession key bound to the access token for establishing secure 1412 communication between the Client and the KDC. 1414 To join the group, the Client sends a CoAP POST request to the /ace- 1415 group/GROUPNAME endpoint at the KDC, where GROUPNAME is the group 1416 identifier of the group to join, formatted as specified in 1417 Section 4.1.2.1. This group identifier is the same as in the scope 1418 entry corresponding to that group, specified in the 'scope' parameter 1419 of the Authorization Request/Response, or it can be retrieved from 1420 it. Note that, in case of successful joining, the Client will 1421 receive the URI to retrieve individual or group keying material and 1422 to leave the group in the Location-Path option of the response. 1424 If the node is joining a group for the first time, and the KDC 1425 maintains the public keys of the group members, the Client is 1426 REQUIRED to send its own public key and proof of possession 1427 ("client_cred" and "client_cred_verify" in Section 4.1.2.1). The 1428 request is only accepted if both public key and proof of possession 1429 are provided. If a node re-joins a group with the same access token 1430 and the same public key, it can omit to send the public key and the 1431 proof of possession, or just omit the proof of possession, and the 1432 KDC will be able to retrieve its public key associated to its token 1433 for that group (if the key has been discarded, the KDC will reply 1434 with 4.00 Bad Request, as specified in Section 4.1.2.1). If a node 1435 re-joins a group but wants to update its own public key, it needs to 1436 send both public key and proof of possession. 1438 If the application requires backward security, the KDC MUST generate 1439 new group keying material and securely distribute it to all the 1440 current group members, upon a new node's joining the group. To this 1441 end, the KDC uses the message format of the response defined in 1442 Section 4.1.2.2. Application profiles may define alternative ways of 1443 retrieving the keying material, such as sending separate requests to 1444 different resources at the KDC (Section 4.1.2.2, Section 4.1.3.2, 1445 Section 4.1.4.1). After distributing the new group keying material, 1446 the KDC MUST increment the version number of the keying material. 1448 4.3. Retrieval of Updated Keying Material 1450 When any of the following happens, a node MUST stop using the owned 1451 group keying material to protect outgoing messages, and SHOULD stop 1452 using it to decrypt and verify incoming messages. 1454 o Upon expiration of the keying material, according to what 1455 indicated by the KDC with the 'exp' (and possibly the 'exp_delta') 1456 parameter in a Joining Response, or to a pre-configured value. 1458 o Upon receiving a notification of revoked/renewed keying material 1459 from the KDC, possibly as part of an update of the keying material 1460 (rekeying) triggered by the KDC. 1462 o Upon receiving messages from other group members without being 1463 able to retrieve the keying material to correctly decrypt them. 1464 This may be due to rekeying messages previously sent by the KDC, 1465 that the Client was not able to receive or decrypt. 1467 In either case, if it wants to continue participating in the group 1468 communication, the node has to request the latest keying material 1469 from the KDC. To this end, the Client sends a CoAP GET request to 1470 the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, 1471 formatted as specified in Section 4.1.6.2. 1473 Note that policies can be set up, so that the Client sends a Key Re- 1474 Distribution request to the KDC only after a given number of received 1475 messages could not be decrypted (because of failed decryption 1476 processing or inability to retrieve the necessary keying material). 1478 It is application dependent and pertaining to the particular message 1479 exchange (e.g. [I-D.ietf-core-oscore-groupcomm]) to set up these 1480 policies, to instruct clients to retain incoming messages and for how 1481 long (OPT4). This allows clients to possibly decrypt such messages 1482 after getting updated keying material, rather than just consider them 1483 non valid messages to discard right away. 1485 The same Key Distribution Request could also be sent by the Client 1486 without being triggered by a failed decryption of a message, if the 1487 Client wants to be sure that it has the latest group keying material. 1488 If that is the case, the Client will receive from the KDC the same 1489 group keying material it already has in memory. 1491 Figure 9 gives an overview of the exchange described above. 1493 Client KDC 1494 | | 1495 |------------------ Key Distribution Request: --------------->| 1496 | GET ace-group/GROUPNAME/nodes/NODENAME | 1497 | | 1498 |<-------- Key Distribution Response: 2.05 (Content) ---------| 1499 | | 1501 Figure 9: Message Flow of Key Distribution Request-Response 1503 Alternatively, the re-distribution of keying material can be 1504 initiated by the KDC, which e.g.: 1506 o Can make the ace-group/GROUPNAME/nodes/NODENAME resource 1507 Observable [RFC7641], and send notifications to Clients when the 1508 keying material is updated. 1510 o Can send the payload of the Key Distribution Response in one or 1511 multiple multicast POST requests to the members of the group, 1512 using secure rekeying schemes such as [RFC2093][RFC2094][RFC2627]. 1514 o Can send unicast POST requests to each Client over a secure 1515 channel, with the same payload as the Key Distribution Response. 1516 When sending such requests, the KDC can target the URI path 1517 possibly provided by the intended recipient upon joining the 1518 group, as specified in the 'control_path' parameter of the Joining 1519 Request (see Section 4.1.2.1). 1521 o Can act as a publisher in a pub-sub scenario, and update the 1522 keying material by publishing on a specific topic on a broker, 1523 which all the members of the group are subscribed to. 1525 Note that these methods of KDC-initiated key distribution have 1526 different security properties and require different security 1527 associations. Moreover, congestion control mechanism need to be 1528 implemented where Observe is used, see Section 4.5.1 of [RFC7641]. 1530 4.4. Retrieval of New Keying Material 1532 Beside possible expiration and depending on what part of the keying 1533 material is no longer eligible to be used, the client may need to 1534 communicate to the KDC its need for that part to be renewed. For 1535 example, if the Client uses an individual key to protect outgoing 1536 traffic and has to renew it, the node may request a new one, or new 1537 input material to derive it, without renewing the whole group keying 1538 material. 1540 To this end, the client performs a Key Renewal Request/Response 1541 exchange with the KDC, i.e. it sends a CoAP PUT request to the /ace- 1542 group/GROUPNAME/nodes/NODENAME endpoint at the KDC, where GROUPNAME 1543 is the group identifier and NODENAME is the node's name, and 1544 formatted as defined in Section 4.1.6.2. 1546 Figure 10 gives an overview of the exchange described above. 1548 Client KDC 1549 | | 1550 |------------------ Key Renewal Request: -------------->| 1551 | PUT ace-group/GROUPNAME/nodes/NODENAME | 1552 | | 1553 |<-------- Key Renewal Response: 2.05 (Content) --------| 1554 | | 1556 Figure 10: Message Flow of Key Renewal Request-Response 1558 Note the difference between the Key Distribution Request and the Key 1559 Renewal Request: while the first one only triggers distribution (the 1560 renewal might have happened independently, e.g. because of 1561 expiration), the second one triggers the KDC to produce new 1562 individual keying material for the requesting node. 1564 Furthermore, policies can be set up so that, upon receiving a Key 1565 Renewal Request, the KDC replies to the client with an error 1566 response, and then performs a complete group rekeying (OPT8). 1568 4.5. Retrieval of Public Keys and Roles for Group Members 1570 In case the KDC maintains the public keys of group members, a node in 1571 the group can contact the KDC to request public keys and roles of 1572 either all group members or a specified subset, by sending a CoAP GET 1573 or FETCH request to the /ace-group/GROUPNAME/pub-key endpoint at the 1574 KDC, where GROUPNAME is the group identifier, and formatted as 1575 defined in Section 4.1.3.2 and Section 4.1.3.1. 1577 When receiving a Public Key Response, the requesting group member 1578 stores (or updates) the public keys (in the 'pub_keys' parameter) and 1579 roles (in the 'peer_roles' parameter) of the group members. 1581 Figure 11 and Figure 12 give an overview of the exchanges described 1582 above. 1584 Client KDC 1585 | | 1586 |--Public Key Request: GET /ace-group/GROUPNAME/pub-key->| 1587 | | 1588 |<--------- Public Key Response: 2.05 (Content) ---------| 1589 | | 1591 Figure 11: Message Flow of Public Key Exchange to Request All Members 1592 Public Keys 1594 Client KDC 1595 | | 1596 |-Public Key Request: FETCH /ace-group/GROUPNAME/pub-key->| 1597 | | 1598 |<--------- Public Key Response: 2.05 (Created) ----------| 1599 | | 1601 Figure 12: Message Flow of Public Key Exchange to Request Specific 1602 Members Public Keys 1604 4.6. Update of Public Key 1606 In case the KDC maintains the public keys of group members, a node in 1607 the group can contact the KDC to upload a new public key to use in 1608 the group, and replace the currently stored one. 1610 To this end, the Client performs a Public Key Update Request/Response 1611 exchange with the KDC, i.e. it sends a CoAP POST request to the /ace- 1612 group/GROUPNAME/nodes/NODENAME/pub-key endpoint at the KDC, where 1613 GROUPNAME is the group identifier and NODENAME is the node's name. 1615 The request is formatted as specified in Section 4.1.7.1. 1617 Figure Figure 13 gives an overview of the exchange described above. 1619 Client KDC 1620 | | 1621 |-------------- Public Key Update Request: ---------------------->| 1622 | POST ace-group/GROUPNAME/nodes/NODENAME/pub-key | 1623 | | 1624 |<------- Public Key Update Response: 2.04 (Changed) -------------| 1625 | | 1627 Figure 13: Message Flow of Public Key Update Request-Response 1629 If the application requires backward security, the KDC MUST generate 1630 new group keying material and securely distribute it to all the 1631 current group members, upon a group member updating its own public 1632 key. To this end, the KDC uses the message format of the response 1633 defined in Section 4.1.2.2. Application profiles may define 1634 alternative ways of retrieving the keying material, such as sending 1635 separate requests to different resources at the KDC (Section 4.1.2.2, 1636 Section 4.1.3.2, Section 4.1.4.1). After distributing the new group 1637 keying material, the KDC MUST increment the version number of the 1638 keying material. 1640 Additionally, after updating its own public key, a group member MAY 1641 send a number of the later requests including an identifier of the 1642 updated public key, to signal nodes that they need to retrieve it. 1643 How that is done depends on the group communication protocol used, 1644 and therefore is application profile specific (OPT10). 1646 4.7. Retrieval of Group Policies 1648 A node in the group can contact the KDC to retrieve the current group 1649 policies, by sending a CoAP GET request to the /ace-group/GROUPNAME/ 1650 policies endpoint at the KDC, where GROUPNAME is the group 1651 identifier, and formatted as defined in Section 4.1.4.1 1653 Figure 14 gives an overview of the exchange described above. 1655 Client KDC 1656 | | 1657 |-Policies Request: GET ace-group/GROUPNAME/policies ->| 1658 | | 1659 |<--------- Policies Response: 2.05 (Content) ---------| 1660 | | 1662 Figure 14: Message Flow of Policies Request-Response 1664 4.8. Retrieval of Keying Material Version 1666 A node in the group can contact the KDC to request information about 1667 the version number of the symmetric group keying material, by sending 1668 a CoAP GET request to the /ace-group/GROUPNAME/ctx-num endpoint at 1669 the KDC, where GROUPNAME is the group identifier, formatted as 1670 defined in Section 4.1.5.1. In particular, the version is 1671 incremented by the KDC every time the group keying material is 1672 renewed. 1674 Figure 15 gives an overview of the exchange described above. 1676 Client KDC 1677 | | 1678 |-- Version Request: GET ace-group/GROUPNAME/ctx-num -->| 1679 | | 1680 |<--------- Version Response: 2.05 (Content) -----------| 1681 | | 1683 Figure 15: Message Flow of Version Request-Response 1685 4.9. Group Leaving Request 1687 A node can actively request to leave the group. In this case, the 1688 Client sends a CoAP DELETE request to the endpoint /ace- 1689 group/GROUPNAME/nodes/NODENAME at the KDC, where GROUPNAME is the 1690 group identifier and NODENAME is the node's name, formatted as 1691 defined in Section 4.1.6.3 1693 Alternatively, a node may be removed by the KDC, without having 1694 explicitly asked for it. This is further discussed in Section 5. 1696 5. Removal of a Node from the Group 1698 This section describes the different scenarios according to which a 1699 node ends up being removed from the group. 1701 If the application requires forward security, the KDC MUST generate 1702 new group keying material and securely distribute it to all the 1703 current group members but the leaving node, using the message format 1704 of the Key Distribution Response (see Section 4.3). Application 1705 profiles may define alternative message formats. Once distributed 1706 the new group keying material, the KDC MUST increment the version 1707 number of the keying material. 1709 Note that, after having left the group, a node may wish to join it 1710 again. Then, as long as the node is still authorized to join the 1711 group, i.e. it still has a valid access token, it can re-request to 1712 join the group directly to the KDC without needing to retrieve a new 1713 access token from the AS. This means that the KDC might decide to 1714 keep track of nodes with valid access tokens, before deleting all 1715 information about the leaving node. 1717 A node may be evicted from the group in the following cases. 1719 1. The node explicitly asks to leave the group, as defined in 1720 Section 4.9. 1722 2. The node has been found compromised or is suspected so. 1724 3. The node's authorization to be a group member is not valid 1725 anymore, either because the access token has expired, or it has 1726 been revoked. If the AS provides Token introspection (see 1727 Section 5.7 of [I-D.ietf-ace-oauth-authz]), the KDC can 1728 optionally use it and check whether the node is still authorized 1729 for that group in that role. 1731 In either case, once aware that a node is not authorized anymore, the 1732 KDC has to remove the unauthorized node from the list of group 1733 members, if the KDC keeps track of that. 1735 In case of forced eviction, the KDC MAY explicitly inform the leaving 1736 node, if the Client implements the 'control_path' resource specified 1737 in Section 4.1.2.1. To this end, the KDC MAY send a DEL request, 1738 targeting the URI specified in the 'control_path' parameter of the 1739 Joining Request. 1741 6. ACE Groupcomm Parameters 1743 This specification defines a number of fields used during the second 1744 part of the message exchange, after the ACE Token POST exchange. The 1745 table below summarizes them, and specifies the CBOR key to use 1746 instead of the full descriptive name. Note that the media type ace- 1747 groupcomm+cbor MUST be used when these fields are transported. 1749 +-----------------------+------+-----------------+------------------+ 1750 | Name | CBOR | CBOR Type | Reference | 1751 | | Key | | | 1752 +-----------------------+------+-----------------+------------------+ 1753 | scope | TBD | byte string | Section 4.1.2.1 | 1754 | | | | | 1755 | get_pub_keys | TBD | array | Section 4.1.2.1, | 1756 | | | | Section 4.1.3.1 | 1757 | | | | | 1758 | client_cred | TBD | byte string | Section 4.1.2.1 | 1759 | | | | | 1760 | cnonce | TBD | byte string | Section 4.1.2.1 | 1761 | | | | | 1762 | client_cred_verify | TBD | byte string | Section 4.1.2.1 | 1763 | | | | | 1764 | pub_keys_repos | TBD | text string | Section 4.1.2.1 | 1765 | | | | | 1766 | control_path | TBD | text string | Section 4.1.2.1 | 1767 | | | | | 1768 | gkty | TBD | int / text | Section 4.1.2.1 | 1769 | | | string | | 1770 | | | | | 1771 | key | TBD | see "ACE | Section 4.1.2.1 | 1772 | | | Groupcomm Key" | | 1773 | | | Registry | | 1774 | | | | | 1775 | num | TBD | int | Section 4.1.2.1 | 1776 | | | | | 1777 | ace-groupcomm-profile | TBD | int | Section 4.1.2.1 | 1778 | | | | | 1779 | exp | TBD | int | Section 4.1.2.1 | 1780 | | | | | 1781 | exp_delta | TBD | int | Section 4.1.2.1 | 1782 | | | | | 1783 | pub_keys | TBD | byte string | Section 4.1.2.1 | 1784 | | | | | 1785 | peer_roles | TBD | array | Section 4.1.2.1 | 1786 | | | | | 1787 | group_policies | TBD | map | Section 4.1.2.1 | 1788 | | | | | 1789 | mgt_key_material | TBD | byte string | Section 4.1.2.1 | 1790 +-----------------------+------+-----------------+------------------+ 1792 7. Security Considerations 1794 When a Client receives a message from a sender for the first time, it 1795 needs to have a mechanism in place to avoid replay, e.g. 1796 Appendix B.2 of [RFC8613]. In case the Client rebooted and lost the 1797 security state used to protect previous communication with that 1798 sender, such a mechanism is useful for the recipient to be on the 1799 safe side. If the group has renewed its group keying material, the 1800 time window between the end of the rekeying process and the next loss 1801 of security state is safe for recipients, as replayed older messages 1802 protected with previous keying material will not be accepted. 1804 The KDC must renew the group keying material upon its expiration. 1806 The KDC should renew the keying material upon group membership 1807 change, and should provide it to the current group members through 1808 the rekeying scheme used in the group. 1810 The KDC should renew the group keying material after rebooting, even 1811 in the case where all keying material is stored in persistent 1812 storage. However, if the KDC relies on Observe responses to notify 1813 the group of renewed keying material, after rebooting the KDC will 1814 have lost all the Observations up to that point, and the previous 1815 keying material will be used to protect messages in the group anyway. 1816 The KDC will rely on each node requesting updates of the group keying 1817 material to establish the new keying material in the nodes, or, if 1818 implemented, it can push the update to the nodes in the group using 1819 the 'control_path' resource. 1821 The KDC may enforce a rekeying policy that takes into account the 1822 overall time required to rekey the group, as well as the expected 1823 rate of changes in the group membership. 1825 That is, the KDC may not rekey the group at every membership change, 1826 for instance if members' joining and leaving occur frequently and 1827 performing a group rekeying takes too long. Instead, the KDC may 1828 rekey the group after a minimum number of group members have joined 1829 or left within a given time interval, or during predictable network 1830 inactivity periods. 1832 However, this would result in the KDC not constantly preserving 1833 backward and forward security. In fact, newly joining group members 1834 could be able to access the keying material used before their 1835 joining, and thus could access past group communications. Also, 1836 until the KDC performs a group rekeying, the newly leaving nodes 1837 would still be able to access upcoming group communications that are 1838 protected with the keying material that has not yet been updated. 1840 The KDC needs to have a mechanism in place to detect DoS attacks from 1841 nodes constantly initiating rekeys (for example by updating their 1842 public key), such as removing these nodes from the group. 1844 The KDC also needs to have a congestion control mechanism in place to 1845 avoid network congestion when the KDC renews the group keying 1846 material; CoAP and Observe give guidancee on such mechanisms, see 1847 Section 4.7 of [RFC7252] and Section 4.5.1 of [RFC7641]. 1849 7.1. Update of Keying Material 1851 A group member can receive a message shortly after the group has been 1852 rekeyed, and new keying material has been distributed by the KDC. In 1853 the following two cases, this may result in misaligned keying 1854 material between the group members. 1856 In the first case, the sender protects a message using the old keying 1857 material. However, the recipient receives the message after having 1858 received the new keying material, hence not being able to correctly 1859 process it. A possible way to ameliorate this issue is to preserve 1860 the old, recent, keying material for a maximum amount of time defined 1861 by the application. By doing so, the recipient can still try to 1862 process the received message using the old retained keying material 1863 as second attempt. Note that a former (compromised) group member can 1864 take advantage of this by sending messages protected with the old 1865 retained keying material. Therefore, a conservative application 1866 policy should not admit the storage of old keying material. 1868 In the second case, the sender protects a message using the new 1869 keying material, but the recipient receives that request before 1870 having received the new keying material. Therefore, the recipient 1871 would not be able to correctly process the request and hence discards 1872 it. If the recipient receives the new keying material shortly after 1873 that and the application at the sender endpoint performs 1874 retransmissions, the former will still be able to receive and 1875 correctly process the message. In any case, the recipient should 1876 actively ask the KDC for an updated keying material according to an 1877 application-defined policy, for instance after a given number of 1878 unsuccessfully decrypted incoming messages. 1880 A node that has left the group should not expect any of its outgoing 1881 messages to be successfully processed, if received after its leaving, 1882 due to a possible group rekeying occurred before the message 1883 reception. 1885 7.2. Block-Wise Considerations 1887 If the block-wise options [RFC7959] are used, and the keying material 1888 is updated in the middle of a block-wise transfer, the sender of the 1889 blocks just changes the keying material to the updated one and 1890 continues the transfer. As long as both sides get the new keying 1891 material, updating the keying material in the middle of a transfer 1892 will not cause any issue. Otherwise, the sender will have to 1893 transmit the message again, when receiving an error message from the 1894 recipient. 1896 Compared to a scenario where the transfer does not use block-wise, 1897 depending on how fast the keying material is changed, the nodes might 1898 consume a larger amount of the network bandwidth resending the blocks 1899 again and again, which might be problematic. 1901 8. IANA Considerations 1903 This document has the following actions for IANA. 1905 8.1. Media Type Registrations 1907 This specification registers the 'application/ace-groupcomm+cbor' 1908 media type for messages of the protocols defined in this document 1909 following the ACE exchange and carrying parameters encoded in CBOR. 1910 This registration follows the procedures specified in [RFC6838]. 1912 Type name: application 1914 Subtype name: ace-groupcomm+cbor 1916 Required parameters: none 1918 Optional parameters: none 1920 Encoding considerations: Must be encoded as CBOR map containing the 1921 protocol parameters defined in [this document]. 1923 Security considerations: See Section 7 of this document. 1925 Interoperability considerations: n/a 1927 Published specification: [this document] 1929 Applications that use this media type: The type is used by 1930 authorization servers, clients and resource servers that support the 1931 ACE groupcomm framework as specified in [this document]. 1933 Additional information: 1935 Magic number(s): n/a 1937 File extension(s): .ace-groupcomm 1939 Macintosh file type code(s): n/a 1940 Person & email address to contact for further information: 1941 iesg@ietf.org [1] 1943 Intended usage: COMMON 1945 Restrictions on usage: None 1947 Author: Francesca Palombini francesca.palombini@ericsson.com [2] 1949 Change controller: IESG 1951 8.2. CoAP Content-Formats Registry 1953 This specification registers the following entry to the "CoAP 1954 Content-Formats" registry, within the "CoRE Parameters" registry: 1956 Media Type: application/ace-groupcomm+cbor 1958 Encoding: - 1960 ID: TBD 1962 Reference: [this document] 1964 8.3. OAuth Parameters Registry 1966 The following registrations are done for the OAuth ParametersRegistry 1967 following the procedure specified in section 11.2 of [RFC6749]: 1969 o Parameter name: sign_info o Parameter usage location: token 1970 request, token response o Change Controller: IESG o Specification 1971 Document(s): [[This specification]] 1973 o Parameter name: pub_key_enc o Parameter usage location: token 1974 request, token response o Change Controller: IESG o Specification 1975 Document(s): [[This specification]] 1977 o Parameter name: kdcchallenge o Parameter usage location: token 1978 response o Change Controller: IESG o Specification Document(s): 1979 [[This specification]] 1981 8.4. OAuth Parameters CBOR Mappings Registry 1983 The following registrations are done for the OAuth Parameters CBOR 1984 Mappings Registry following the procedure specified in section 8.9 of 1985 [I-D.ietf-ace-oauth-authz]: 1987 * Name: sign_info 1988 * CBOR Key: TBD (range -256 to 255) 1989 * Value Type: any 1990 * Reference: \[\[This specification\]\] 1992 * Name: pub_key_enc 1993 * CBOR Key: TBD (range -256 to 255) 1994 * Value Type: integer 1995 * Reference: \[\[This specification\]\] 1997 * Name: kdcchallenge 1998 * CBOR Key: TBD (range -256 to 255) 1999 * Value Type: byte string 2000 * Reference: \[\[This specification\]\] 2002 8.5. ACE Groupcomm Parameters Registry 2004 This specification establishes the "ACE Groupcomm Parameters" IANA 2005 Registry. The Registry has been created to use the "Expert Review 2006 Required" registration procedure [RFC8126]. Expert review guidelines 2007 are provided in Section 8.11. 2009 The columns of this Registry are: 2011 o Name: This is a descriptive name that enables easier reference to 2012 the item. The name MUST be unique. It is not used in the 2013 encoding. 2015 o CBOR Key: This is the value used as CBOR key of the item. These 2016 values MUST be unique. The value can be a positive integer, a 2017 negative integer, or a string. 2019 o CBOR Type: This contains the CBOR type of the item, or a pointer 2020 to the registry that defines its type, when that depends on 2021 another item. 2023 o Reference: This contains a pointer to the public specification for 2024 the item. 2026 This Registry has been initially populated by the values in 2027 Section 6. The Reference column for all of these entries refers to 2028 sections of this document. 2030 8.6. ACE Groupcomm Key Registry 2032 This specification establishes the "ACE Groupcomm Key" IANA Registry. 2033 The Registry has been created to use the "Expert Review Required" 2034 registration procedure [RFC8126]. Expert review guidelines are 2035 provided in Section 8.11. 2037 The columns of this Registry are: 2039 o Name: This is a descriptive name that enables easier reference to 2040 the item. The name MUST be unique. It is not used in the 2041 encoding. 2043 o Key Type Value: This is the value used to identify the keying 2044 material. These values MUST be unique. The value can be a 2045 positive integer, a negative integer, or a text string. 2047 o Profile: This field may contain one or more descriptive strings of 2048 application profiles to be used with this item. The values should 2049 be taken from the Name column of the "ACE Groupcomm Profile" 2050 Registry. 2052 o Description: This field contains a brief description of the keying 2053 material. 2055 o References: This contains a pointer to the public specification 2056 for the format of the keying material, if one exists. 2058 This Registry has been initially populated by the values in Figure 5. 2059 The specification column for all of these entries will be this 2060 document. 2062 8.7. ACE Groupcomm Profile Registry 2064 This specification establishes the "ACE Groupcomm Profile" IANA 2065 Registry. The Registry has been created to use the "Expert Review 2066 Required" registration procedure [RFC8126]. Expert review guidelines 2067 are provided in Section 8.11. It should be noted that, in addition 2068 to the expert review, some portions of the Registry require a 2069 specification, potentially a Standards Track RFC, be supplied as 2070 well. 2072 The columns of this Registry are: 2074 o Name: The name of the application profile, to be used as value of 2075 the profile attribute. 2077 o Description: Text giving an overview of the application profile 2078 and the context it is developed for. 2080 o CBOR Value: CBOR abbreviation for the name of this application 2081 profile. Different ranges of values use different registration 2082 policies [RFC8126]. Integer values from -256 to 255 are 2083 designated as Standards Action. Integer values from -65536 to 2084 -257 and from 256 to 65535 are designated as Specification 2085 Required. Integer values greater than 65535 are designated as 2086 Expert Review. Integer values less than -65536 are marked as 2087 Private Use. 2089 o Reference: This contains a pointer to the public specification of 2090 the abbreviation for this application profile, if one exists. 2092 8.8. ACE Groupcomm Policy Registry 2094 This specification establishes the "ACE Groupcomm Policy" IANA 2095 Registry. The Registry has been created to use the "Expert Review 2096 Required" registration procedure [RFC8126]. Expert review guidelines 2097 are provided in Section 8.11. It should be noted that, in addition 2098 to the expert review, some portions of the Registry require a 2099 specification, potentially a Standards Track RFC, be supplied as 2100 well. 2102 The columns of this Registry are: 2104 o Name: The name of the group communication policy. 2106 o CBOR label: The value to be used to identify this group 2107 communication policy. Key map labels MUST be unique. The label 2108 can be a positive integer, a negative integer or a string. 2109 Integer values between 0 and 255 and strings of length 1 are 2110 designated as Standards Track Document required. Integer values 2111 from 256 to 65535 and strings of length 2 are designated as 2112 Specification Required. Integer values of greater than 65535 and 2113 strings of length greater than 2 are designated as expert review. 2114 Integer values less than -65536 are marked as private use. 2116 o CBOR type: the CBOR type used to encode the value of this group 2117 communication policy. 2119 o Description: This field contains a brief description for this 2120 group communication policy. 2122 o Reference: This field contains a pointer to the public 2123 specification providing the format of the group communication 2124 policy, if one exists. 2126 This registry will be initially populated by the values in Figure 6. 2128 8.9. Sequence Number Synchronization Method Registry 2130 This specification establishes the "Sequence Number Synchronization 2131 Method" IANA Registry. The Registry has been created to use the 2132 "Expert Review Required" registration procedure [RFC8126]. Expert 2133 review guidelines are provided in Section 8.11. It should be noted 2134 that, in addition to the expert review, some portions of the Registry 2135 require a specification, potentially a Standards Track RFC, be 2136 supplied as well. 2138 The columns of this Registry are: 2140 o Name: The name of the sequence number synchronization method. 2142 o Value: The value to be used to identify this sequence number 2143 synchronization method. 2145 o Description: This field contains a brief description for this 2146 sequence number synchronization method. 2148 o Reference: This field contains a pointer to the public 2149 specification describing the sequence number synchronization 2150 method. 2152 8.10. Interface Description (if=) Link Target Attribute Values Registry 2154 This specification registers the following entry to the "Interface 2155 Description (if=) Link Target Attribute Values Registry" registry, 2156 within the "CoRE Parameters" registry: 2158 o Attribute Value: ace-group 2160 o Description: The 'ace group' interface is used to provision keying 2161 material and related informations and policies to members of a 2162 group using the Ace framework. 2164 o Reference: [This Document] 2166 8.11. Expert Review Instructions 2168 The IANA Registries established in this document are defined as 2169 expert review. This section gives some general guidelines for what 2170 the experts should be looking for, but they are being designated as 2171 experts for a reason so they should be given substantial latitude. 2173 Expert reviewers should take into consideration the following points: 2175 o Point squatting should be discouraged. Reviewers are encouraged 2176 to get sufficient information for registration requests to ensure 2177 that the usage is not going to duplicate one that is already 2178 registered and that the point is likely to be used in deployments. 2179 The zones tagged as private use are intended for testing purposes 2180 and closed environments, code points in other ranges should not be 2181 assigned for testing. 2183 o Specifications are required for the standards track range of point 2184 assignment. Specifications should exist for specification 2185 required ranges, but early assignment before a specification is 2186 available is considered to be permissible. Specifications are 2187 needed for the first-come, first-serve range if they are expected 2188 to be used outside of closed environments in an interoperable way. 2189 When specifications are not provided, the description provided 2190 needs to have sufficient information to identify what the point is 2191 being used for. 2193 o Experts should take into account the expected usage of fields when 2194 approving point assignment. The fact that there is a range for 2195 standards track documents does not mean that a standards track 2196 document cannot have points assigned outside of that range. The 2197 length of the encoded value should be weighed against how many 2198 code points of that length are left, the size of device it will be 2199 used on, and the number of code points left that encode to that 2200 size. 2202 9. References 2204 9.1. Normative References 2206 [COSE.Algorithms] 2207 IANA, "COSE Algorithms", 2208 . 2211 [COSE.Key.Types] 2212 IANA, "COSE Key Types", 2213 . 2216 [I-D.ietf-ace-oauth-authz] 2217 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 2218 H. Tschofenig, "Authentication and Authorization for 2219 Constrained Environments (ACE) using the OAuth 2.0 2220 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33 2221 (work in progress), February 2020. 2223 [I-D.ietf-ace-oauth-params] 2224 Seitz, L., "Additional OAuth Parameters for Authorization 2225 in Constrained Environments (ACE)", draft-ietf-ace-oauth- 2226 params-13 (work in progress), April 2020. 2228 [I-D.ietf-core-oscore-groupcomm] 2229 Tiloca, M., Selander, G., Palombini, F., and J. Park, 2230 "Group OSCORE - Secure Group Communication for CoAP", 2231 draft-ietf-core-oscore-groupcomm-08 (work in progress), 2232 April 2020. 2234 [I-D.ietf-cose-rfc8152bis-algs] 2235 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2236 Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-09 2237 (work in progress), June 2020. 2239 [I-D.ietf-cose-rfc8152bis-struct] 2240 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2241 Structures and Process", draft-ietf-cose-rfc8152bis- 2242 struct-10 (work in progress), June 2020. 2244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2245 Requirement Levels", BCP 14, RFC 2119, 2246 DOI 10.17487/RFC2119, March 1997, 2247 . 2249 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 2250 RFC 6749, DOI 10.17487/RFC6749, October 2012, 2251 . 2253 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2254 Specifications and Registration Procedures", BCP 13, 2255 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2256 . 2258 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2259 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2260 October 2013, . 2262 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2263 Application Protocol (CoAP)", RFC 7252, 2264 DOI 10.17487/RFC7252, June 2014, 2265 . 2267 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2268 Writing an IANA Considerations Section in RFCs", BCP 26, 2269 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2270 . 2272 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2273 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2274 May 2017, . 2276 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 2277 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 2278 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2279 2020, . 2281 9.2. Informative References 2283 [I-D.bormann-core-ace-aif] 2284 Bormann, C., "An Authorization Information Format (AIF) 2285 for ACE", draft-bormann-core-ace-aif-07 (work in 2286 progress), February 2020. 2288 [I-D.ietf-ace-dtls-authorize] 2289 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 2290 L. Seitz, "Datagram Transport Layer Security (DTLS) 2291 Profile for Authentication and Authorization for 2292 Constrained Environments (ACE)", draft-ietf-ace-dtls- 2293 authorize-10 (work in progress), May 2020. 2295 [I-D.ietf-ace-mqtt-tls-profile] 2296 Sengul, C., Kirby, A., and P. Fremantle, "MQTT-TLS profile 2297 of ACE", draft-ietf-ace-mqtt-tls-profile-05 (work in 2298 progress), May 2020. 2300 [I-D.ietf-ace-oscore-profile] 2301 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 2302 "OSCORE profile of the Authentication and Authorization 2303 for Constrained Environments Framework", draft-ietf-ace- 2304 oscore-profile-10 (work in progress), March 2020. 2306 [I-D.ietf-core-coap-pubsub] 2307 Koster, M., Keranen, A., and J. Jimenez, "Publish- 2308 Subscribe Broker for the Constrained Application Protocol 2309 (CoAP)", draft-ietf-core-coap-pubsub-09 (work in 2310 progress), September 2019. 2312 [I-D.ietf-core-groupcomm-bis] 2313 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 2314 for the Constrained Application Protocol (CoAP)", draft- 2315 ietf-core-groupcomm-bis-00 (work in progress), March 2020. 2317 [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management 2318 Protocol (GKMP) Specification", RFC 2093, 2319 DOI 10.17487/RFC2093, July 1997, 2320 . 2322 [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management 2323 Protocol (GKMP) Architecture", RFC 2094, 2324 DOI 10.17487/RFC2094, July 1997, 2325 . 2327 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 2328 Multicast: Issues and Architectures", RFC 2627, 2329 DOI 10.17487/RFC2627, June 1999, 2330 . 2332 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2333 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2334 January 2012, . 2336 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 2337 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 2338 . 2340 [RFC7641] Hartke, K., "Observing Resources in the Constrained 2341 Application Protocol (CoAP)", RFC 7641, 2342 DOI 10.17487/RFC7641, September 2015, 2343 . 2345 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 2346 the Constrained Application Protocol (CoAP)", RFC 7959, 2347 DOI 10.17487/RFC7959, August 2016, 2348 . 2350 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2351 Interchange Format", STD 90, RFC 8259, 2352 DOI 10.17487/RFC8259, December 2017, 2353 . 2355 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 2356 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 2357 May 2018, . 2359 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2360 Definition Language (CDDL): A Notational Convention to 2361 Express Concise Binary Object Representation (CBOR) and 2362 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2363 June 2019, . 2365 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2366 "Object Security for Constrained RESTful Environments 2367 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2368 . 2370 9.3. URIs 2372 [1] mailto:iesg@ietf.org 2374 [2] mailto:francesca.palombini@ericsson.com 2376 Appendix A. Requirements on Application Profiles 2378 This section lists the requirements on application profiles of this 2379 specification,for the convenience of application profile designers. 2381 o REQ1: Specify the encoding and value of the identifier of group or 2382 topic, for scope entries of 'scope' (see Section 3.1). 2384 o REQ2: Specify the encoding and value of roles, for scope entries 2385 of 'scope' (see Section 3.1). 2387 o REQ3: If used, specify the acceptable values for 'sign_alg' (see 2388 Section 3.3). 2390 o REQ4: If used, specify the acceptable values for 'sign_parameters' 2391 (see Section 3.3). 2393 o REQ5: If used, specify the acceptable values for 2394 'sign_key_parameters' (see Section 3.3). 2396 o REQ6: If used, specify the acceptable values for 'pub_key_enc' 2397 (see Section 3.3). 2399 o REQ7: Specify the exact format of the 'key' value (see 2400 Section 4.1.2.1). 2402 o REQ8: Specify the acceptable values of 'gkty' (see 2403 Section 4.1.2.1). 2405 o REQ9: Specify the format of the identifiers of group members (see 2406 Section 4.1.2.1). 2408 o REQ10: Specify the communication protocol the members of the group 2409 must use (e.g., multicast CoAP). 2411 o REQ11: Specify the security protocol the group members must use to 2412 protect their communication (e.g., group OSCORE). This must 2413 provide encryption, integrity and replay protection. 2415 o REQ12: Specify and register the application profile identifier 2416 (see Section 4.1.2.1). 2418 o REQ13: Specify policies at the KDC to handle ids that are not 2419 included in get_pub_keys (see Section 4.1.3.1). 2421 o REQ14: If used, specify the format and content of 'group_policies' 2422 and its entries (see Section 4.1.2.1). 2424 o REQ15: Specify the format of newly-generated individual keying 2425 material for group members, or of the information to derive it, 2426 and corresponding CBOR label (see Section 4.1.6.2). 2428 o REQ16: Specify how the communication is secured between Client and 2429 KDC. Optionally, specify tranport profile of ACE 2430 [I-D.ietf-ace-oauth-authz] to use between Client and KDC (see 2431 Section 4.2. 2433 o REQ17: Specify how the nonce N_S is generated, if the token is not 2434 being posted (e.g. if it is used directly to validate TLS 2435 instead). 2437 o REQ18: Specify if 'mgt_key_material' used, and if yes specify its 2438 format and content (see Section 4.1.2.1). If the usage of 2439 'mgt_key_material' is indicated and its format defined for a 2440 specific key management scheme, that format must explicitly 2441 indicate the key management scheme itself. If a new rekeying 2442 scheme is defined to be used for an existing 'mgt_key_material' in 2443 an existing profile, then that profile will have to be updated 2444 accordingly, especially with respect to the usage of 2445 'mgt_key_material' related format and content. 2447 o OPT1: Optionally, specify the encoding of public keys, of 2448 'client_cred', and of 'pub_keys' if COSE_Keys are not used (see 2449 Section 4.1.2.1). 2451 o OPT2: Optionally, specify the negotiation of parameter values for 2452 signature algorithm and signature keys, if 'sign_info' and 2453 'pub_key_enc' are not used (see Section 3.3). 2455 o OPT3: Optionally, specify the encoding of 'pub_keys_repos' if the 2456 default is not used (see Section 4.1.2.1). 2458 o OPT4: Optionally, specify policies that instruct clients to retain 2459 messages and for how long, if they are unsuccessfully decrypted 2460 (see Section 4.3). This makes it possible to decrypt such 2461 messages after getting updated keying material. 2463 o OPT5: Optionally, specify the behavior of the handler in case of 2464 failure to retrieve a public key for the specific node (see 2465 Section 4.1.2.1). 2467 o OPT6: Optionally, specify possible or required payload formats for 2468 specific error cases. 2470 o OPT7: Optionally, specify CBOR values to use for abbreviating 2471 identifiers of roles in the group or topic (see Section 3.1). 2473 o OPT8: Optionally, specify policies for the KDC to perform group 2474 rekeying after receiving a Key Renewal Request (see Section 4.4). 2476 o OPT9: Optionally, specify the functionalities implemented at the 2477 'control_path' resource hosted at the Client, including message 2478 exchange encoding and other details (see Section 4.1.2.1). 2480 o OPT10: Optionally, specify how the identifier of the sender's 2481 public key is included in the group request (see Section 4.6). 2483 Appendix B. Document Updates 2485 RFC EDITOR: PLEASE REMOVE THIS SECTION. 2487 B.1. Version -04 to -05 2489 o Updated uppercase/lowercase URI segments for KDC resources. 2491 o Supporting single Access Token for multiple groups/topics. 2493 o Added 'control_path' parameter in the Joining Request. 2495 o Added 'peer_roles' parameter to support legal requesters/ 2496 responders. 2498 o Clarification on stopping using owned keying material. 2500 o Clarification on different reasons for processing failures, 2501 related policies, and requirement OPT4. 2503 o Added a KDC sub-resource for group members to upload a new public 2504 key. 2506 o Possible group rekeying following an individual Key Renewal 2507 Request. 2509 o Clarified meaning of requirement REQ3; added requirement OPT8. 2511 o Editorial improvements. 2513 B.2. Version -03 to -04 2515 o Revised RESTful interface, as to methods and parameters. 2517 o Extended processing of joining request, as to check/retrieval of 2518 public keys. 2520 o Revised and extended profile requirements. 2522 o Clarified specific usage of parameters related to signature 2523 algorithms/keys. 2525 o Included general content previously in draft-ietf-ace-key- 2526 groupcomm-oscore 2528 o Registration of media type and content format application/ace- 2529 group+cbor 2531 o Editorial improvements. 2533 B.3. Version -02 to -03 2535 o Exchange of information on the countersignature algorithm and 2536 related parameters, during the Token POST (Section 3.3). 2538 o Restructured KDC interface, with new possible operations 2539 (Section 4). 2541 o Client PoP signature for the Joining Request upon joining 2542 (Section 4.1.2.1). 2544 o Revised text on group member removal (Section 5). 2546 o Added more profile requirements (Appendix A). 2548 B.4. Version -01 to -02 2550 o Editorial fixes. 2552 o Distinction between transport profile and application profile 2553 (Section 1.1). 2555 o New parameters 'sign_info' and 'pub_key_enc' to negotiate 2556 parameter values for signature algorithm and signature keys 2557 (Section 3.3). 2559 o New parameter 'type' to distinguish different Key Distribution 2560 Request messages (Section 4.1). 2562 o New parameter 'client_cred_verify' in the Key Distribution Request 2563 to convey a Client signature (Section 4.1). 2565 o Encoding of 'pub_keys_repos' (Section 4.1). 2567 o Encoding of 'mgt_key_material' (Section 4.1). 2569 o Improved description on retrieval of new or updated keying 2570 material (Section 6). 2572 o Encoding of 'get_pub_keys' in Public Key Request (Section 7.1). 2574 o Extended security considerations (Sections 10.1 and 10.2). 2576 o New "ACE Public Key Encoding" IANA Registry (Section 11.2). 2578 o New "ACE Groupcomm Parameters" IANA Registry (Section 11.3), 2579 populated with the entries in Section 8. 2581 o New "Ace Groupcomm Request Type" IANA Registry (Section 11.4), 2582 populated with the values in Section 9. 2584 o New "ACE Groupcomm Policy" IANA Registry (Section 11.7) populated 2585 with two entries "Sequence Number Synchronization Method" and "Key 2586 Update Check Interval" (Section 4.2). 2588 o Improved list of requirements for application profiles 2589 (Appendix A). 2591 B.5. Version -00 to -01 2593 o Changed name of 'req_aud' to 'audience' in the Authorization 2594 Request (Section 3.1). 2596 o Defined error handling on the KDC (Sections 4.2 and 6.2). 2598 o Updated format of the Key Distribution Response as a whole 2599 (Section 4.2). 2601 o Generalized format of 'pub_keys' in the Key Distribution Response 2602 (Section 4.2). 2604 o Defined format for the message to request leaving the group 2605 (Section 5.2). 2607 o Renewal of individual keying material and methods for group 2608 rekeying initiated by the KDC (Section 6). 2610 o CBOR type for node identifiers in 'get_pub_keys' (Section 7.1). 2612 o Added section on parameter identifiers and their CBOR keys 2613 (Section 8). 2615 o Added request types for requests to a Join Response (Section 9). 2617 o Extended security considerations (Section 10). 2619 o New IANA registries "ACE Groupcomm Key Registry", "ACE Groupcomm 2620 Profile Registry", "ACE Groupcomm Policy Registry" and "Sequence 2621 Number Synchronization Method Registry" (Section 11). 2623 o Added appendix about requirements for application profiles of ACE 2624 on group communication (Appendix A). 2626 Acknowledgments 2628 The following individuals were helpful in shaping this document: 2629 Carsten Bormann, Rikard Hoeglund, Ben Kaduk, John Mattsson, Daniel 2630 Migault, Jim Schaad, Ludwig Seitz, Goeran Selander and Peter van der 2631 Stok. 2633 The work on this document has been partly supported by VINNOVA and 2634 the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact 2635 Initiative ACTIVE. 2637 Authors' Addresses 2639 Francesca Palombini 2640 Ericsson AB 2641 Torshamnsgatan 23 2642 Kista SE-16440 Stockholm 2643 Sweden 2645 Email: francesca.palombini@ericsson.com 2646 Marco Tiloca 2647 RISE AB 2648 Isafjordsgatan 22 2649 Kista SE-16440 Stockholm 2650 Sweden 2652 Email: marco.tiloca@ri.se