idnits 2.17.1 draft-ietf-ace-key-groupcomm-08.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 (13 July 2020) is 1382 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-35 == 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-09 == Outdated reference: A later version (-12) exists of draft-ietf-cose-rfc8152bis-algs-11 ** 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-11 -- 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 (-18) exists of draft-ietf-ace-dtls-authorize-12 == 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-11 == 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 (~~), 11 warnings (==), 3 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: 14 January 2021 RISE AB 6 13 July 2020 8 Key Provisioning for Group Communication using ACE 9 draft-ietf-ace-key-groupcomm-08 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 Discussion Venues 19 This note is to be removed before publishing as an RFC. 21 Source for this draft and an issue tracker can be found at 22 https://github.com/ace-wg/ace-key-groupcomm. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 14 January 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Authorization to Join a Group . . . . . . . . . . . . . . . . 7 61 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 7 62 3.2. Authorization Response . . . . . . . . . . . . . . . . . 9 63 3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 10 64 4. Keying Material Provisioning and Group Membership 65 Management . . . . . . . . . . . . . . . . . . . . . . . 14 66 4.1. Interface at the KDC . . . . . . . . . . . . . . . . . . 15 67 4.2. Joining Exchange . . . . . . . . . . . . . . . . . . . . 31 68 4.3. Retrieval of Updated Keying Material . . . . . . . . . . 32 69 4.4. Retrieval of New Individual Keying Material . . . . . . . 34 70 4.5. Retrieval of Public Keys and Roles for Group Members . . 35 71 4.6. Update of Public Key . . . . . . . . . . . . . . . . . . 35 72 4.7. Retrieval of Group Policies . . . . . . . . . . . . . . . 36 73 4.8. Retrieval of Keying Material Version . . . . . . . . . . 37 74 4.9. Group Leaving Request . . . . . . . . . . . . . . . . . . 37 75 5. Removal of a Node from the Group . . . . . . . . . . . . . . 37 76 6. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 38 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 40 78 7.1. Update of Keying Material . . . . . . . . . . . . . . . . 41 79 7.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 42 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 81 8.1. Media Type Registrations . . . . . . . . . . . . . . . . 42 82 8.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 43 83 8.3. OAuth Parameters Registry . . . . . . . . . . . . . . . . 43 84 8.4. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 44 85 8.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 44 86 8.6. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 45 87 8.7. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 45 88 8.8. ACE Groupcomm Policy Registry . . . . . . . . . . . . . . 46 89 8.9. Sequence Number Synchronization Method Registry . . . . . 47 90 8.10. Interface Description (if=) Link Target Attribute Values 91 Registry . . . . . . . . . . . . . . . . . . . . . . . . 47 92 8.11. Expert Review Instructions . . . . . . . . . . . . . . . 47 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 94 9.1. Normative References . . . . . . . . . . . . . . . . . . 48 95 9.2. Informative References . . . . . . . . . . . . . . . . . 50 96 Appendix A. Requirements on Application Profiles . . . . . . . . 52 97 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 54 98 B.1. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 54 99 B.2. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 55 100 B.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 55 101 B.4. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 56 102 B.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 56 103 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 57 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 106 1. Introduction 108 This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to 109 define the message exchanges used to request, distribute and renew 110 the keying material in a group communication scenario, e.g. based on 111 multicast [I-D.ietf-core-groupcomm-bis] or on publishing-subscribing 112 [I-D.ietf-core-coap-pubsub]. The ACE framework is based on CBOR 113 [RFC7049], so CBOR is the format used in this specification. 114 However, using JSON [RFC8259] instead of CBOR is possible, using the 115 conversion method specified in Sections 4.1 and 4.2 of [RFC7049]. 117 Profiles that use group communication can build on this document, by 118 defining a number of details such as the exact group communication 119 protocol and security protocols used. The specific list of details a 120 profile needs to define is shown in Appendix A. 122 If the application requires backward and forward security, new keying 123 material is generated and distributed to the group upon membership 124 changes. A key management scheme performs the actual distribution of 125 the new keying material to the group. In particular, the key 126 management scheme rekeys the current group members when a new node 127 joins the group, and the remaining group members when a node leaves 128 the group. Rekeying mechanisms can be based on [RFC2093], [RFC2094] 129 and [RFC2627]. 131 1.1. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in BCP 136 14 [RFC2119] [RFC8174] when, and only when, they appear in all 137 capitals, as shown here. 139 Readers are expected to be familiar with the terms and concepts 140 described in [I-D.ietf-ace-oauth-authz][I-D.ietf-cose-rfc8152bis-stru 141 ct][I-D.ietf-cose-rfc8152bis-algs], such as Authorization Server (AS) 142 and Resource Server (RS). 144 This document additionally uses the following terminology: 146 * Transport profile, to indicate a profile of ACE as per 147 Section 5.6.4.3 of [I-D.ietf-ace-oauth-authz]. A transport 148 profile specifies the communication protocol and communication 149 security protocol between an ACE Client and Resource Server, as 150 well as proof-of-possession methods, if it supports proof-of- 151 possession access tokens, etc. Tranport profiles of ACE include, 152 for instance, [I-D.ietf-ace-oscore-profile], 153 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-mqtt-tls-profile]. 155 * Application profile, that defines how applications enforce and use 156 supporting security services they require. These services may 157 include, for instance, provisioning, revocation and 158 (re-)distribution of keying material. An application profile may 159 define specific procedures and message formats. 161 2. Overview 163 The full procedure can be separated in two phases: the first follows 164 the ACE framework, between Client, AS and KDC. The second part is 165 the key distribution between Client and KDC. After the two phases 166 the Client is able to participate in the group communication, via a 167 Dispatcher entity. 169 +------------+ +-----------+ 170 | AS | | KDC | 171 | | .-------->| | 172 +------------+ / +-----------+ 173 ^ / 174 | / 175 v / +-----------+ 176 +------------+ / +------------+ |+-----------+ 177 | Client |<-' | Dispatcher | ||+-----------+ 178 | |<-------->| |<------->|| Group | 179 +------------+ +------------+ +| members | 180 +-----------+ 182 Figure 1: Key Distribution Participants 184 The following participants (see Figure 1) take part in the 185 authorization and key distribution. 187 * Client (C): node that wants to join the group communication. It 188 can request write and/or read rights. 190 * Authorization Server (AS): same as AS in the ACE Framework; it 191 enforces access policies, and knows if a node is allowed to join a 192 given group with write and/or read rights. 194 * Key Distribution Center (KDC): maintains the keying material to 195 protect group communications, and provides it to Clients 196 authorized to join a given group. During the first part of the 197 exchange (Section 3), it takes the role of the RS in the ACE 198 Framework. During the second part (Section 4), which is not based 199 on the ACE Framework, it distributes the keying material. In 200 addition, it provides the latest keying material to group members 201 when requested or, if required by the application, when membership 202 changes. 204 * Dispatcher: entity through which the Clients communicate with the 205 group and which distributes messages to the group members. 206 Examples of dispatchers are: the Broker node in a pub-sub setting; 207 a relayer node for group communication that delivers group 208 messages as multiple unicast messages to all group members; an 209 implicit entity as in a multicast communication setting, where 210 messages are transmitted to a multicast IP address and delivered 211 on the transport channel. 213 This document specifies a mechanism for: 215 * Authorizing a new node to join the group (Section 3), and 216 providing it with the group keying material to communicate with 217 the other group members (Section 4). 219 * Allowing a group member to leave the group (Section 5). 221 * Evicting a group member from the group (Section 5). 223 * Allowing a group member to retrieve keying material (Section 4.3 224 and Section 4.4). 226 * Renewing and re-distributing the group keying material (rekeying) 227 upon a membership change in the group (Section 4.9 and Section 5). 229 Figure 2 provides a high level overview of the message flow for a 230 node joining a group communication setting, which can be expanded as 231 follows. 233 1. The joining node requests an Access Token from the AS, in order 234 to access a specific group-membership resource on the KDC and 235 hence join the associated group. This exchange between Client 236 and AS MUST be secured, as specified by the transport profile of 237 ACE used between Client and KDC. The joining node will start or 238 continue using a secure communication association with the KDC, 239 according to the response from the AS. 241 2. The joining node transfers authentication and authorization 242 information to the KDC, by posting the obtained Access Token to 243 the /authz-info endpoint at the KDC. This exchange, and all 244 further communications between the Client and the KDC, MUST occur 245 over the secure channel established as a result of the transport 246 profile of ACE used between Client and KDC. After that, a 247 joining node MUST have a secure communication association 248 established with the KDC, before starting to join a group under 249 that KDC. Possible ways to provide a secure communication 250 association are DTLS [RFC6347] and OSCORE [RFC8613]. 252 3. The joining node starts the joining process to become a member of 253 the group, by accessing the related group-membership resource at 254 the KDC. At the end of the joining process, the joining node has 255 received from the KDC the parameters and keying material to 256 securely communicate with the other members of the group, and the 257 KDC has stored the association between the authorization 258 information from the access token and the secure session with the 259 client. 261 4. The joining node and the KDC maintain the secure association, to 262 support possible future communications. These especially include 263 key management operations, such as retrieval of updated keying 264 material or participation to a group rekeying process. 266 5. The joining node can communicate securely with the other group 267 members, using the keying material provided in step 3. 269 C AS KDC Group 270 | | | Member 271 / | | | | 272 | | Authorization Request | | | 273 Defined | |-------------------------->| | | 274 in the | | | | | 275 ACE | | Authorization Response | | | 276 framework | |<--------------------------| | | 277 | | | | 278 \ |---------- Token Post --------->| | 279 | | | 280 |------- Joining Request ------->| | 281 | | | 282 |<------ Joining Response -------|-- Group Rekeying -->| 283 | | | 284 | Dispatcher | 285 | | | 286 |<===== Secure group communication =======|===========>| 287 | | | 288 Figure 2: Message Flow Upon New Node's Joining 290 3. Authorization to Join a Group 292 This section describes in detail the format of messages exchanged by 293 the participants when a node requests access to a given group. This 294 exchange is based on ACE [I-D.ietf-ace-oauth-authz]. 296 As defined in [I-D.ietf-ace-oauth-authz], the Client requests from 297 the AS an authorization to join the group through the KDC (see 298 Section 3.1). If the request is approved and authorization is 299 granted, the AS provides the Client with a proof-of-possession access 300 token and parameters to securely communicate with the KDC (see 301 Section 3.2). 303 Communications between the Client and the AS MUST be secured, as 304 defined by the transport profile of ACE used. The Content-Format 305 used in the message is the one indicated by the used transport 306 profile of ACE. For example, this can be application/ace+cbor for 307 the first two messages and application/cwt for the third message, 308 which are defined in the ACE framework. The transport profile of ACE 309 also defines a number of details such as the communication and 310 security protocols used with the KDC (see Appendix C of 311 [I-D.ietf-ace-oauth-authz]). 313 Figure 3 gives an overview of the exchange described above. 315 Client AS KDC 316 | | | 317 |---- Authorization Request: POST /token ------>| | 318 | | | 319 |<--- Authorization Response: 2.01 (Created) ---| | 320 | | | 321 |----- POST Token: POST /authz-info --------------->| 322 | | 324 Figure 3: Message Flow of Join Authorization 326 3.1. Authorization Request 328 The Authorization Request sent from the Client to the AS is defined 329 in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MAY contain the 330 following parameters, which, if included, MUST have the corresponding 331 values: 333 * 'scope', containing the identifier of the specific group(s), or 334 topic(s) in the case of pub-sub, that the Client wishes to access, 335 and optionally the role(s) that the Client wishes to take. 337 This value is a CBOR byte string, encoding a CBOR array of one or 338 more entries. 340 By default, each entry is encoded as specified by 341 [I-D.bormann-core-ace-aif]. It is up to the application profiles 342 to define and register Toid and Tperm to fit the use case. The 343 object identifier Toid corresponds to the group name, while the 344 permission set Tperm indicates the roles that the client wishes to 345 take in the group. 347 Otherwise, each scope entry can be defined as a CBOR array, which 348 contains: 350 - As first element, the identifier of the specific group or 351 topic. 353 - Optionally, as second element, the role (or CBOR array of 354 roles) that the Client wishes to take in the group. This 355 element is optional since roles may have been pre-assigned to 356 the Client, as associated to its verifiable identity 357 credentials. Alternatively, the application may have defined a 358 single, well-known role for the target resource(s) and 359 audience(s). 361 In each entry, the encoding of the group or topic identifier (REQ1 362 in Appendix A) and of the role identifiers (REQ2) is application 363 specific, and part of the requirements for the application 364 profile. 366 In particular, the application profile may specify CBOR values to 367 use for abbreviating role identifiers (OPT7). 369 An example of CDDL definition [RFC8610] of scope using the format 370 above, with group name and role identifiers encoded as text 371 strings is given in Figure 4. 373 * 'audience', with an identifier of a KDC. 375 * 'req_cnf', as defined in Section 3.1 of 376 [I-D.ietf-ace-oauth-params], optionally containing the public key 377 or a reference to the public key of the Client, if it wishes to 378 communicate that to the AS. 380 Other additional parameters as defined in [I-D.ietf-ace-oauth-authz], 381 can be included if necessary. 383 As in [I-D.ietf-ace-oauth-authz], these parameters are included in 384 the payload, which is formatted as a CBOR map. The Content-Format 385 "application/ace+cbor" defined in Section 8.14 of 386 [I-D.ietf-ace-oauth-authz] is used. 388 gname = tstr 390 role = tstr 392 scope_entry = [ gname , ? ( role / [ 2*role ] ) ] 394 scope = << [ + scope_entry ] >> 396 Figure 4: CDLL definition of scope, using as example group name 397 encoded as tstr and role as tstr 399 3.2. Authorization Response 401 The Authorization Response sent from the AS to the Client is defined 402 in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST contain the 403 following parameters: 405 * 'access_token', containing the proof-of-possession access token. 407 * 'cnf' if symmetric keys are used, not present if asymmetric keys 408 are used. This parameter is defined in Section 3.2 of 409 [I-D.ietf-ace-oauth-params] and contains the symmetric proof-of- 410 possession key that the Client is supposed to use with the KDC. 412 * 'rs_cnf' if asymmetric keys are used, not present if symmetric 413 keys are used. This parameter is defined in Section 3.2 of 414 [I-D.ietf-ace-oauth-params] and contains information about the 415 public key of the KDC. 417 * 'expires_in', contains the lifetime in seconds of the access 418 token. This parameter MAY be omitted if the application defines 419 how the expiration time is communicated to the Client via other 420 means, or if it establishes a default value. 422 Additionally, the Authorization Response MAY contain the following 423 parameters, which, if included, MUST have the corresponding values: 425 * 'scope' containing the scope the AS grants access to. This 426 parameter has the same format and encoding of 'scope' in the 427 Authorization Request, defined in Section 3.1. 429 Other additional parameters as defined in [I-D.ietf-ace-oauth-authz], 430 if necessary. 432 The proof-of-possession access token (in 'access_token' above) MUST 433 contain the following parameters: 435 * a confirmation claim (see for example 'cnf' defined in Section 3.1 436 of [RFC8747] for CWT); 438 * an expiration time claim (see for example 'exp' defined in 439 Section 3.1.4 of [RFC8392] for CWT); 441 * a scope claim (see for example 'scope' registered in Section 8.13 442 of [I-D.ietf-ace-oauth-authz] for CWT). This claim has the same 443 encoding as 'scope' parameter above. Additionally, this claim has 444 the same value of the 'scope' parameter if the parameter is 445 present in the message, or it takes the value of 'scope' in the 446 Authorization Request otherwise. 448 The access token MAY additionally contain other claims that the 449 transport profile of ACE requires, or other optional parameters. 451 As in [I-D.ietf-ace-oauth-authz], these parameters are included in 452 the payload, which is formatted as a CBOR map. The Content-Format 453 "application/ace+cbor" is used. 455 When receiving an Authorization Request from a Client that was 456 previously authorized, and for which the AS still owns a valid non- 457 expired access token, the AS MAY reply with that token. Note that it 458 is up to application profiles of ACE to make sure that re-posting the 459 same token does not cause re-use of keying material between nodes 460 (for example, that is done with the use of random nonces in 461 [I-D.ietf-ace-oscore-profile]). 463 3.3. Token Post 465 The Client sends a CoAP POST request including the access token to 466 the KDC, as specified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. 467 If the specific transport profile of ACE defines it, the Client MAY 468 use a different endpoint than /authz-info at the KDC to post the 469 access token to. 471 Optionally, the Client might want to request information concerning 472 the public keys in the group, as well as concerning the algorithm and 473 related parameters for computing signatures in the group. In such a 474 case, the joining node MAY ask for that information to the KDC in 475 this same request. To this end, it sends the CoAP POST request to 476 the /authz-info endpoint using the Content-Format "application/ 477 ace+cbor". 479 The payload of the message MUST be formatted as a CBOR map including 480 the access token. 482 Additionally, the CoAP POST request MAY contain the following 483 parameter, which, if included, MUST have the corresponding values: 485 * 'sign_info' defined in Section 3.3.1, encoding the CBOR simple 486 value Null to require information about the signature algorithm, 487 signature algorithm parameters, signature key parameters and on 488 the exact encoding of public keys used in the group. 490 Alternatively, the joining node may retrieve this information by 491 other means. 493 After successful verification, the Client is authorized to receive 494 the group keying material from the KDC and join the group. In 495 particular, the KDC replies to the Client with a 2.01 (Created) 496 response, using Content-Format "application/ace+cbor" defined in 497 Section 8.14 of [I-D.ietf-ace-oauth-authz]. 499 The payload of the 2.01 response is a CBOR map. If the access token 500 contains a role that requires the Client to send its own public key 501 to the KDC when joining the group, the CBOR map MUST include the 502 parameter 'kdcchallenge' defined in Section Section 3.3.2, specifying 503 a dedicated challenge N_S generated by the KDC. The Client uses this 504 challenge to prove possession of its own private key (see the 505 'client_cred_verify' parameter in Section 4). Note that the payload 506 format of the response deviates from the one defined in the ACE 507 framework (see Section 5.8.1 of [I-D.ietf-ace-oauth-authz]), which 508 has no payload. 510 The KDC MUST store the 'kdcchallenge' value associated to the Client 511 at least until it receives a join request from it (see Section 4.2), 512 to be able to verify the proof of possession. The same challenge MAY 513 be reused several times by the Client, to generate new proof of 514 possessions, e.g. in case of update of the public key, or to join a 515 different group with a different key, so it is RECOMMENDED that the 516 KDC keeps storing the 'kdcchallenge' after the first join is 517 processed as well. If the KDC has already discarded the 518 'kdcchallenge', that will trigger an error response with a newly 519 generated 'kdcchallenge' that the client can use to restart the join 520 process, as specified in Section 4.2. 522 If 'sign_info' is included in the request, the KDC MAY include the 523 'sign_info' parameter defined in Section 3.3.1, with the same 524 encoding. Note that the field 'id' takes the value of the group name 525 for which the 'sign_info_entry' applies to. 527 Note that the CBOR map specified as payload of the 2.01 (Created) 528 response may include further parameters, e.g. according to the 529 signalled transport profile of ACE. 531 Applications of this specification MAY define alternative specific 532 negotiations of parameter values for signature algorithm and 533 signature keys, if 'sign_info' is not used (OPT2). 535 3.3.1. 'sign_info' Parameter 537 The 'sign_info' parameter is an OPTIONAL parameter of the Token Post 538 response message defined in Section 5.1.2. of 539 [I-D.ietf-ace-oauth-authz]. This parameter contains information and 540 parameters about the signature algorithm and the public keys to be 541 used between the Client and the RS. Its exact content is application 542 specific. 544 In this specification and in application profiles building on it, 545 this parameter is used to ask and retrieve from the KDC information 546 about the signature algorithm and related parameters used in the 547 group. 549 When used in the request, the 'sign_info' encodes the CBOR simple 550 value Null, to require information and parameters on the signature 551 algorithm and on the public keys used. 553 The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as 554 in the request is given below. 556 sign_info_req = nil 558 The 'sign_info' parameter of the 2.01 (Created) response is a CBOR 559 array of one or more elements. The number of elements is at most the 560 number of groups the client has been authorized to join. Each 561 element contains information about signing parameters and keys for 562 one or more group or topic and is formatted as follows. 564 * The first element 'id' is an identifier of the group or an array 565 of identifiers for the groups for which this information applies. 567 * The second element 'sign_alg' is an integer or a text string if 568 the POST request included the 'sign_info' parameter with value 569 Null, and indicates the signature algorithm used in the group 570 identified by 'gname'. It is REQUIRED of the application profiles 571 to define specific values that this parameter can take (REQ3), 572 selected from the set of signing algorithms of the COSE Algorithms 573 registry [COSE.Algorithms]. 575 * The third element 'sign_parameters' is a CBOR array indicating the 576 parameters of the signature algorithm. Its content depends on the 577 value of 'sign_alg'. It is REQUIRED of the application profiles 578 to define the possible values and structure for the elements of 579 this parameter (REQ4). 581 * The fourth element 'sign_key_parameters' is a CBOR array 582 indicating the parameters of the key used with the signature 583 algorithm. Its content depends on the value of 'sign_alg'. It is 584 REQUIRED of the application profiles to define the possible values 585 and structure for the elements of this parameter (REQ5). 587 * The fifth element 'pub_key_enc' parameter is either a CBOR integer 588 indicating the encoding of public keys used in the group 589 identified by 'gname', or has value Null indicating that the KDC 590 does not act as repository of public keys for group members. Its 591 acceptable values are taken from the "CWT Confirmation Method" 592 Registry defined in [RFC8747]. It is REQUIRED of the application 593 profiles to define specific values to use for this parameter 594 (REQ6). 596 The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as 597 in the response is given below, with gname formatted as a bstr (note 598 that gname can be encoded differently, see REQ1). 600 sign_info_res = [ + sign_info_entry ] 602 sign_info_entry = 603 [ 604 id : gname / [ + gname ], 605 sign_alg : int / tstr / nil, 606 sign_parameters : [ any ] / nil, 607 sign_key_parameters : [ any ] / nil, 608 pub_key_enc = int / nil 609 ] 611 gname = tstr 613 3.3.2. 'kdcchallenge' Parameter 615 The 'kdcchallenge' parameter is an OPTIONAL parameter of the Token 616 Post response message defined in Section 5.1.2. of 617 [I-D.ietf-ace-oauth-authz]. This parameter contains a challenge 618 generated by the KDC and provided to the Client. The Client may use 619 this challenge to prove possession of its own private key in the 620 Joining Request (see the 'client_cred_verify' parameter in 621 Section 4). 623 4. Keying Material Provisioning and Group Membership Management 625 This section defines the interface available at the KDC. Moreover, 626 this section specifies how the clients can use this interface to join 627 a group, leave a group, retrieve the group policies or the new keying 628 material. 630 During the first exchange with the KDC ("Joining") after posting the 631 Token, the Client sends a request to the KDC, specifying the group it 632 wishes to join (see Section 4.2). Then, the KDC verifies the access 633 token and that the Client is authorized to join that group. If so, 634 it provides the Client with the keying material to securely 635 communicate with the other members of the group. Whenever used, the 636 Content-Format in messages containing a payload is set to 637 application/ace-groupcomm+cbor, as defined in Section 8.2. 639 When the Client is already a group member, the Client can use the 640 interface at the KDC to perform the following actions: 642 * The Client can get the current keying material, for cases such as 643 expiration, loss or suspected mismatch, due to e.g. reboot or 644 missed group rekeying. This is described in Section 4.3. 646 * The Client can retrieve a new individual key, or new input 647 material to derive it. This is described in Section 4.4. 649 * The Client can get the public keys of other group members. This 650 is described in Section 4.5. 652 * The Client can get the group policies. This is described in 653 Section 4.7. 655 * The Client can get the version number of the keying material 656 currently used in the group. This is described in Section 4.8. 658 * The Client can request to leave the group. This is further 659 discussed in Section 4.9. 661 Upon receiving a request from a Client, the KDC MUST check that it is 662 storing a valid access token from that Client for the group name 663 associated to the endpoint. If that is not the case, i.e. the KDC 664 does not store a valid access token or this is not valid for that 665 Client for the group name, the KDC MUST respond to the Client with a 666 4.01 (Unauthorized) error message. 668 4.1. Interface at the KDC 670 The KDC is configured with the following resources. Note that the 671 root url-path "ace-group" given here are default names: 672 implementations are not required to use these names, and can define 673 their own instead. The Interface Description (if=) Link Target 674 Attribute value ace.group is registered (Section 8.10) and can be 675 used to describe this interface. 677 * /ace-group: this resource indicates that this specification is 678 used. If other applications run on a KDC implementing this 679 specification and use this same resource, these applications will 680 collide, and a mechanism will be needed to differentiate the 681 endpoints. 683 * /ace-group/GROUPNAME: one sub-resource to /ace-group is 684 implemented for each group the KDC manages. These resources are 685 identified by the group names of the groups the KDC manages (in 686 this example, the group name has value "GROUPNAME"). Each 687 resource contains the symmetric group keying material for that 688 group. These resources support GET and POST method. 690 * /ace-group/GROUPNAME/pub-key: this resource contains the public 691 keys of all group members. This resource supports GET and FETCH 692 methods. 694 * /ace-group/GROUPNAME/policies: this resource contains the group 695 policies. This resource supports the GET method. 697 * /ace-group/GROUPNAME/num: this resource contains the version 698 number for the symmetric group keying material. This sub-resource 699 supports the GET method. 701 * /ace-group/GROUPNAME/nodes/NODENAME: one sub-resource to /ace- 702 group/GROUPNAME is implemented for each node in the group the KDC 703 manages. These resources are identified by the node name (in this 704 example, the node name has value "NODENAME"). Each resource 705 contains the group and individual keying material for that node. 706 These resources support GET, PUT and DELETE methods. 708 * /ace-group/GROUPNAME/nodes/NODENAME/pub-key: one sub-resource to 709 /ace-group/GROUPNAME/nodes/NODENAME is implemented for each node 710 in the group the KDC manages. These resources are identified by 711 the node name (in this example, the node name has value 712 "NODENAME"). Each resource contains the individual public keying 713 material for that node. These resources support the POST method. 715 The details for the handlers of each resource are given in the 716 following sections. These endpoints are used to perform the 717 operations introduced in Section 4. 719 4.1.1. ace-group 721 No handlers are implemented for this resource. 723 4.1.2. ace-group/GROUPNAME 725 This resource implements GET and POST handlers. 727 4.1.2.1. POST Handler 729 The POST handler adds the public key of the client to the list of the 730 group members' public keys and returns the symmetric group keying 731 material for the group identified by "GROUPNAME". Note that the 732 group joining exchange is done by the client via this operation, as 733 described in Section 4.2. 735 The handler expects a request with payload formatted as a CBOR map 736 which MAY contain the following fields, which, if included, MUST have 737 the corresponding values: 739 * 'scope', with value the specific resource at the KDC that the 740 Client is authorized to access, i.e. group or topic identifier, 741 and role(s). This value is a CBOR byte string encoding one scope 742 entry, as defined in Section 3.1. 744 * 'get_pub_keys', if the Client wishes to receive the public keys of 745 the other nodes in the group from the KDC. This parameter may be 746 present if the KDC stores the public keys of the nodes in the 747 group and distributes them to the Client; it is useless to have 748 here if the set of public keys of the members of the group is 749 known in another way, e.g. it was provided by the AS. Note that 750 including this parameter may result in a large message size for 751 the following response, which can be inconvenient for resource- 752 constrained devices. The parameter's value is a non-empty CBOR 753 array containing two CBOR arrays: 755 - The first array contains zero or more roles (or combination of 756 roles) of group members for the group identified by 757 "GROUPNAME". The Client indicates that it wishes to receive 758 the public keys of all nodes having these roles. If empty, it 759 means the client wishes to receive the public keys of all 760 nodes. 762 - The second array is empty. 764 The CDDL definition [RFC8610] of 'get_pub_keys' is given in 765 Figure 5 using as example encoding: node identifier encoded as 766 byte string, role identifier as text string, and combination of 767 roles encoded as a CBOR array of roles. Note that the array ids 768 is empty for this handler, but is not necessarily empty for the 769 value of "get_pub_keys" received by the handler of FETCH to ace- 770 group/GROUPNAME/pub-key (see Section 4.1.3.1). 772 id = bstr 774 role = tstr 776 comb_role = [ 2*role ] 778 get_pub_keys = [ [ *(role / comb_role) ], [ *id ] ] 780 Figure 5: CDLL definition of get_pub_keys, using as example node 781 identifier encoded as bstr and role as tstr 783 * 'client_cred', with value the public key or certificate of the 784 Client, encoded as a CBOR byte string. This field contains the 785 public key of the Client. This field is used if the KDC is 786 managing (collecting from/distributing to the Client) the public 787 keys of the group members, and if the Client's role in the group 788 will require for it to send messages to one or more group members. 789 The default encoding for public keys is COSE Keys. Alternative 790 specific encodings of this parameter MAY be defined in 791 applications of this specification (OPT1 in Appendix A). 793 * 'cnonce', with the same encoding as defined for the "cnonce" 794 parameter of Ace, in Section 5.1.2 of [I-D.ietf-ace-oauth-authz], 795 and including a dedicated nonce N_C generated by the Client. This 796 parameter MUST be present if the 'client_cred' parameter is 797 present. 799 * 'client_cred_verify', encoded as a CBOR byte string. This 800 parameter MUST be present if the 'client_cred' parameter is 801 present and no public key associated to the client's token can be 802 retrieved for that group. This parameter contains a signature 803 computed by the Client over the scope concatenated with N_S 804 concatenated with N_C, where: 806 - scope is the byte string specified in the 'scope parameter 807 above'. 809 - N_S is the challenge received from the KDC in the 810 'kdcchallenge' parameter of the 2.01 (Created) response to the 811 token POST request (see Section 3.3). 813 - N_C is the nonce generated by the Client and specified in the 814 'cnonce' parameter above. 816 If the token was not posted (e.g. if it is used directly to 817 validate TLS instead), it is REQUIRED of the specific profile to 818 define how the challenge N_S is generated (REQ17). The Client 819 computes the signature by using its own private key, whose 820 corresponding public key is either directly specified in the 821 'client_cred' parameter or included in the certificate specified 822 in the 'client_cred' parameter. 824 * 'pub_keys_repos', can be present if a certificate is present in 825 the 'client_cred' field, with value the URI of the certificate of 826 the Client. This parameter is encoded as a CBOR text string. 827 Alternative specific encodings of this parameter MAY be defined in 828 applications of this specification (OPT3). 830 * 'control_path', with value a full URI, encoded as a CBOR text 831 string. If 'control_path' is supported by the Client, the Client 832 acts as a CoAP server and hosts a resource at this specific URI. 833 The KDC MAY use this URI to send CoAP requests to the Client 834 (acting as CoAP server in this exchange), for example for 835 individual provisioning of new keying material when performing a 836 group rekeying (see Section 4.3), or to inform the Client of its 837 removal from the group Section 5. If the KDC does not implement 838 mechanisms using this resource, it can just ignore this parameter. 839 Other additional functionalities of this resource MAY be defined 840 in application profiles of this specifications (OPT9). In 841 particular, this resource is intended for communications 842 concerning exclusively the group or topic specified in the 'scope' 843 parameter. 845 The handler verifies that the group name of the /ace-group/GROUPNAME 846 path is a subset of the 'scope' stored in the access token associated 847 to this client. If verification fails, the KDC MUST respond with a 848 4.01 (Unauthorized) error message. The KDC MAY respond with an AS 849 Request Creation Hints, as defined in Section 5.1.2 of 850 [I-D.ietf-ace-oauth-authz]. Note that in this case, the content 851 format MUST be set to application/ace+cbor. 853 If the request is not formatted correctly (i.e. required fields non 854 received or received with incorrect format), the handler MUST respond 855 with a 4.00 (Bad Request) error message. The response MAY contain a 856 CBOR map in the payload with ace+cbor format, e.g. it could send back 857 'sign_info_res' with 'pub_key_enc' set to Null if the Client sent its 858 own public key and the KDC is not set to store public keys of the 859 group members. If the request contained unknown or non-expected 860 fields present, the handler MUST silently drop them and continue 861 processing. Application profiles MAY define optional or mandatory 862 payload formats for specific error cases (OPT6). 864 If the KDC stores the group members' public keys, the handler checks 865 if one is included in the the 'client_cred' field, retrieves it and 866 associates it to the access token received, after verifications 867 succeeded. In particular, the KDC verifies: 869 * that such public key has an acceptable format for the group 870 identified by "GROUPNAME", i.e. it is encoded as expected and is 871 compatible with the signature algorithm and possible associated 872 parameters. If that cannot be verified, it is RECOMMENDED that 873 the handler stops the process and responds with a 4.00 (Bad 874 Request) error message. Applications profiles MAY define 875 alternatives (OPT5). 877 * that the signature contained in "client_cred_verify" passes 878 verification. If that cannot be verified, the handler MUST 879 respond with a 4.00 (Bad Request) error message, and if the token 880 was posted (see REQ17) including the 'kdcchallenge' associated to 881 this Client (see Section 3.3) if it can be retrieved, or otherwise 882 newly generated, in a CBOR map in the payload. This error 883 response MUST also have Content-Format "application/ace+cbor". 885 If one public key is already associated to the access token and to 886 that group, but the 'client_cred' is populated with a different 887 public key, the handler MUST delete the previous one and replace it 888 with this one, after verifying the points above. 890 If no public key is included in the 'client_cred' field, the handler 891 checks if one public key is already associated to the access token 892 received (see Section 4.2 for an example) and to the group identified 893 by "GROUPNAME". If that is not the case, the handler responds with a 894 4.00 Bad Request error response. 896 If the token was posted but the KDC cannot retrieve the 897 'kdcchallenge' associated to this Client (see Section 3.3), the KDC 898 MUST respond with a 4.00 Bad Request error response, including a 899 newly generated 'kdcchallenge' in a CBOR map in the payload. This 900 error response MUST also have Content-Format "application/ace+cbor". 902 If all verifications succeed, the handler: 904 * Adds the node to the list of current members of the group. 906 * Assigns a name NODENAME to the node, and creates a sub-resource to 907 /ace-group/GROUPNAME/ at the KDC (e.g. "/ace- 908 group/GROUPNAME/nodes/NODENAME"). 910 * Associates the identifier "NODENAME" with the access token and the 911 secure session for that node. 913 * If the KDC manages public keys for group members: 915 - Adds the retrieved public key of the node to the list of public 916 keys stored for the group identified by "GROUPNAME" 918 - Associates the node's public key with its access token and the 919 group identified by "GROUPNAME", if such association did not 920 already exist. 922 * Returns a 2.01 (Created) message containing the symmetric group 923 keying material, the group policies and all the public keys of the 924 current members of the group, if the KDC manages those and the 925 Client requested them. 927 The response message also contains the URI path to the sub-resource 928 created for that node in a Location-Path CoAP option. The payload of 929 the response is formatted as a CBOR map which MUST contain the 930 following fields and values: 932 * 'gkty', identifying the key type of the 'key' parameter. The set 933 of values can be found in the "Key Type" column of the "ACE 934 Groupcomm Key" Registry. Implementations MUST verify that the key 935 type matches the application profile being used, if present, as 936 registered in the "ACE Groupcomm Key" registry. 938 * 'key', containing the keying material for the group communication, 939 or information required to derive it. 941 * 'num', containing the version number of the keying material for 942 the group communication, formatted as an integer. This is a 943 strictly monotonic increasing field. The application profile MUST 944 define the initial version number (REQ19). 946 The exact format of the 'key' value MUST be defined in applications 947 of this specification (REQ7), as well as accepted values of 'gkty' by 948 the application (REQ8). Additionally, documents specifying the key 949 format MUST register it in the "ACE Groupcomm Key" registry defined 950 in Section 8.6, including its name, type and application profile to 951 be used with. 953 +----------+----------------+---------+-------------------------+ 954 | Name | Key Type Value | Profile | Description | 955 +----------+----------------+---------+-------------------------+ 956 | Reserved | 0 | | This value is reserved | 957 +----------+----------------+---------+-------------------------+ 959 Figure 6: Key Type Values 961 The response SHOULD contain the following parameter: 963 * 'exp', with value the expiration time of the keying material for 964 the group communication, encoded as a CBOR unsigned integer. This 965 field contains a numeric value representing the number of seconds 966 from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, 967 ignoring leap seconds, analogous to what specified for NumericDate 968 in Section 2 of [RFC7519]. Group members MUST stop using the 969 keying material to protect outgoing messages and retrieve new 970 keying material at the time indicated in this field. 972 Optionally, the response MAY contain the following parameters, which, 973 if included, MUST have the corresponding values: 975 * 'ace-groupcomm-profile', with value a CBOR integer that MUST be 976 used to uniquely identify the application profile for group 977 communication. Applications of this specification MUST register 978 an application profile identifier and the related value for this 979 parameter in the "ACE Groupcomm Profile" Registry (REQ12). 981 * 'pub_keys', may only be present if 'get_pub_keys' was present in 982 the request. This parameter is a CBOR byte string, which encodes 983 the public keys of all the group members paired with the 984 respective member identifiers. The default encoding for public 985 keys is COSE Keys, so the default encoding for 'pub_keys' is a 986 CBOR byte string wrapping a COSE_KeySet (see 987 [I-D.ietf-cose-rfc8152bis-struct]), which contains the public keys 988 of all the members of the group. In particular, each COSE Key in 989 the COSE_KeySet includes the identifier of the corresponding group 990 member as value of its 'kid' key parameter. Alternative specific 991 encodings of this parameter MAY be defined in applications of this 992 specification (OPT1). The specific format of the identifiers of 993 group members MUST be specified in the application profile (REQ9). 995 * 'peer_roles', MUST be present if 'pub_keys' is present. This 996 parameter is a CBOR array of n elements, with n the number of 997 members in the group (and number of public keys included in the 998 'pub_keys' parameter). The i-th element of the array specifies 999 the role (or CBOR array of roles) that the group member associated 1000 to the i-th public key in 'pub_keys' has in the group. In 1001 particular, each array element is encoded as the role element of a 1002 scope entry, as defined in Section 3.1. 1004 * 'group_policies', with value a CBOR map, whose entries specify how 1005 the group handles specific management aspects. These include, for 1006 instance, approaches to achieve synchronization of sequence 1007 numbers among group members. The elements of this field are 1008 registered in the "ACE Groupcomm Policy" Registry. This 1009 specification defines the three elements "Sequence Number 1010 Synchronization Method", "Key Update Check Interval" and 1011 "Expiration Delta", which are summarized in Figure 7. Application 1012 profiles that build on this document MUST specify the exact 1013 content format and default value of included map entries (REQ14). 1015 +--------------+-------+----------|--------------------|------------+ 1016 | Name | CBOR | CBOR | Description | Reference | 1017 | | label | type | | | 1018 |--------------+-------+----------|--------------------|------------| 1019 | Sequence | TBD1 | tstr/int | Method for a re- | [[this | 1020 | Number | | | cipient node to | document]] | 1021 | Synchroniza- | | | synchronize with | | 1022 | tion Method | | | sequence numbers | | 1023 | | | | of a sender node. | | 1024 | | | | Its value is taken | | 1025 | | | | from the 'Value' | | 1026 | | | | column of the | | 1027 | | | | Sequence Number | | 1028 | | | | Synchronization | | 1029 | | | | Method registry | | 1030 | | | | | | 1031 | Key Update | TBD2 | int | Polling interval | [[this | 1032 | Check | | | in seconds, to | document]] | 1033 | Interval | | | check for new | | 1034 | | | | keying material at | | 1035 | | | | the KDC | | 1036 | | | | | | 1037 | Expiration | TBD3 | uint | Number of seconds | [[this | 1038 | Delta | | | from 'exp' until | document]] | 1039 | | | | the specified UTC | | 1040 | | | | date/time after | | 1041 | | | | which group members| | 1042 | | | | MUST stop using the| | 1043 | | | | keying material to | | 1044 | | | | verify incoming | | 1045 | | | | messages. | | 1046 +--------------+-------+----------|--------------------|------------+ 1048 Figure 7: ACE Groupcomm Policies 1050 * 'mgt_key_material', encoded as a CBOR byte string and containing 1051 the administrative keying material to participate in the group 1052 rekeying performed by the KDC. The application profile MUST 1053 define if this field is used, and if used then MUST specify the 1054 exact format and content which depend on the specific rekeying 1055 scheme used in the group. If the usage of 'mgt_key_material' is 1056 indicated and its format defined for a specific key management 1057 scheme, that format must explicitly indicate the key management 1058 scheme itself. If a new rekeying scheme is defined to be used for 1059 an existing 'mgt_key_material' in an existing profile, then that 1060 profile will have to be updated accordingly, especially with 1061 respect to the usage of 'mgt_key_material' related format and 1062 content (REQ18). 1064 Specific application profiles that build on this document MUST 1065 specify the communication protocol that members of the group use to 1066 communicate with each other (REQ10) and how exactly the keying 1067 material is used to protect the group communication (REQ11). 1069 CBOR labels for these fields are defined in Section 6. 1071 4.1.2.2. GET Handler 1073 The GET handler returns the symmetric group keying material for the 1074 group identified by "GROUPNAME". 1076 The handler expects a GET request. 1078 The handler verifies that the group name of the /ace-group/GROUPNAME 1079 path is a subset of the 'scope' stored in the access token associated 1080 to this client. If verification fails, the KDC MUST respond with a 1081 4.01 (Unauthorized) error message. The KDC MAY respond with an AS 1082 Request Creation Hints, as defined in Section 5.1.2 of 1083 [I-D.ietf-ace-oauth-authz]. Note that in this case, the content 1084 format MUST be set to application/ace+cbor. 1086 Additionally, the handler verifies that the node is a current member 1087 of the group. If verification fails, the KDC MUST respond with a 1088 4.00 (Bad Request) error message. 1090 If verification succeeds, the handler returns a 2.05 (Content) 1091 message containing the symmetric group keying material. The payload 1092 of the response is formatted as a CBOR map which MUST contain the 1093 parameters 'gkty','key' and 'num' specified in Section 4.1.2.1. 1095 The payload MAY also include the parameters 'ace-groupcomm-profile', 1096 'exp', and 'mgt_key_material' parameters specified in 1097 Section 4.1.2.1. 1099 4.1.3. ace-group/GROUPNAME/pub-key 1101 If the KDC does not maintain public keys for the group, the handler 1102 for any request on this resource returns a 4.05 (Method Not Allowed) 1103 error message. If it does, the rest of this section applies. 1105 This resource implements GET and FETCH handlers. 1107 4.1.3.1. FETCH Handler 1109 The FETCH handler receives identifiers of group members for the group 1110 identified by "GROUPNAME" and returns the public keys of such group 1111 members. 1113 The handler expects a request with payload formatted as a CBOR map. 1114 The payload of this request is a CBOR Map that MUST contain the 1115 following fields: 1117 * 'get_pub_keys', whose value is encoded as in Section 4.1.2.1 with 1118 the following modification: 1120 - The second array contains zero or more identifiers of group 1121 members for the group identified by "GROUPNAME". The Client 1122 indicates that it wishes to receive the public keys of all 1123 nodes having these identifiers. 1125 The specific format of public keys as well as identifiers, roles and 1126 combination of roles of group members MUST be specified by the 1127 application profile (OPT1, REQ2, REQ9). 1129 The handler verifies that the group name of the /ace-group/GROUPNAME 1130 path is a subset of the 'scope' stored in the access token associated 1131 to this client. If verification fails, the KDC MUST respond with a 1132 4.01 (Unauthorized) error message. 1134 If verification succeeds, the handler identifies the public keys of 1135 the current group members for which either: 1137 * the role identifier matches with one of those indicated in the 1138 request; note that the request can contain a "combination of 1139 roles", where the handler select all group members who have all 1140 roles included in the combination. 1142 * the identifier matches with one of those indicated in the request. 1144 Then, the handler returns a 2.05 (Content) message response with 1145 payload formatted as a CBOR map, containing only the 'pub_keys' and 1146 'peer_roles' parameters from Section 4.1.2.1. In particular, 1147 'pub_keys' encodes the list of public keys of those group members 1148 including the respective member identifiers, while 'peer_roles' 1149 encodes their respective role (or CBOR array of roles) in the group. 1150 The specific format of public keys as well as of identifiers of group 1151 members is specified by the application profile (OPT1, REQ9). 1153 If the KDC does not store any public key associated with the 1154 specified member identifiers, the handler returns a response with 1155 payload formatted as a CBOR byte string of zero length. 1157 The handler MAY enforce one of the following policies, in order to 1158 handle possible identifiers that are included in the 'get_pub_keys' 1159 parameter of the request but are not associated to any current group 1160 member. Such a policy MUST be specified by the application profile 1161 (REQ13) 1163 * The KDC silently ignores those identifiers. 1165 * The KDC retains public keys of group members for a given amount of 1166 time after their leaving, before discarding them. As long as such 1167 public keys are retained, the KDC provides them to a requesting 1168 Client. 1170 Note that this resource handler only verifies that the node is 1171 authorized by the AS to access this resource. Nodes that are not 1172 members of the group but are authorized to do signature verifications 1173 on the group messages may be allowed to access this resource, if the 1174 application needs it. 1176 4.1.3.2. GET Handler 1178 The handler expects a GET request. 1180 The handler verifies that the group name of the /ace-group/GROUPNAME 1181 path is a subset of the 'scope' stored in the access token associated 1182 to this client. If verification fails, the KDC MUST respond with a 1183 4.01 (Unauthorized) error message. 1185 If verification succeeds, the handler returns a 2.05 (Content) 1186 message containing the public keys of all the current group members, 1187 for the group identified by "GROUPNAME". The payload of the response 1188 is formatted as a CBOR map, containing only the 'pub_keys' and 1189 'peer_roles' parameters from Section 4.1.2.1. In particular, 1190 'pub_keys' encodes the list of public keys of those group members 1191 including the respective member identifiers, while 'peer_roles' 1192 encodes their respective role (or CBOR array of roles) in the group. 1194 If the KDC does not store any public key for the group, the handler 1195 returns a response with payload formatted as a CBOR byte string of 1196 zero length. The specific format of public keys as well as of 1197 identifiers of group members is specified by the application profile 1198 (OPT1, REQ9). 1200 Note that this resource handler only verifies that the node is 1201 authorized by the AS to access this resource. Nodes that are not 1202 members of the group but are authorized to do signature verifications 1203 on the group messages may be allowed to access this resource, if the 1204 application needs it. 1206 4.1.4. ace-group/GROUPNAME/policies 1208 This resource implements a GET handler. 1210 4.1.4.1. GET Handler 1212 The handler expects a GET request. 1214 The handler verifies that the group name of the /ace-group/GROUPNAME 1215 path is a subset of the 'scope' stored in the access token associated 1216 to this client. If verification fails, the KDC MUST respond with a 1217 4.01 (Unauthorized) error message. 1219 Additionally, the handler verifies that the node is a current member 1220 of the group. If verification fails, the KDC MUST respond with a 1221 4.00 (Bad Request) error message. 1223 If verification succeeds, the handler returns a 2.05 (Content) 1224 message containing the list of policies for the group identified by 1225 "GROUPNAME". The payload of the response is formatted as a CBOR map 1226 including only the parameter 'group_policies' defined in 1227 Section 4.1.2.1 and specifying the current policies in the group. If 1228 the KDC does not store any policy, the payload is formatted as a 1229 zero-length CBOR byte string. 1231 The specific format and meaning of group policies MUST be specified 1232 in the application profile (REQ14). 1234 4.1.5. ace-group/GROUPNAME/num 1236 This resource implements a GET handler. 1238 4.1.5.1. GET Handler 1240 The handler expects a GET request. 1242 The handler verifies that the group name of the /ace-group/GROUPNAME 1243 path is a subset of the 'scope' stored in the access token associated 1244 to this client. If verification fails, the KDC MUST respond with a 1245 4.01 (Unauthorized) error message. 1247 Additionally, the handler verifies that the node is a current member 1248 of the group. If verification fails, the KDC MUST respond with a 1249 4.00 (Bad Request) error message. 1251 If verification succeeds, the handler returns a 2.05 (Content) 1252 message containing an integer that represents the version number of 1253 the symmetric group keying material. This number is incremented on 1254 the KDC every time the KDC updates the symmetric group keying 1255 material, before the new keying material is distributed. This number 1256 is stored in persistent storage. 1258 The payload of the response is formatted as a CBOR integer. 1260 4.1.6. ace-group/GROUPNAME/nodes/NODENAME 1262 This resource implements GET, PUT and DELETE handlers. 1264 4.1.6.1. PUT Handler 1266 The PUT handler is used to get the KDC to produce and return 1267 individual keying material to protect outgoing messages for the node 1268 (identified by "NODENAME") for the group identified by "GROUPNAME". 1270 The handler expects a request with empty payload. 1272 The handler verifies that the group name of the /ace-group/GROUPNAME 1273 path is a subset of the 'scope' stored in the access token associated 1274 to this client, identified by "NODENAME". If verification fails, the 1275 KDC MUST respond with a 4.01 (Unauthorized) error message. 1277 Additionally, the handler verifies that the node is a current member 1278 of the group. If verification fails, the KDC MUST respond with a 1279 4.00 (Bad Request) error message. 1281 If verification succeeds, the handler returns a 2.05 (Content) 1282 message containing newly-generated individual keying material for the 1283 Client, or information enabling the Client to derive it. The payload 1284 of the response is formatted as a CBOR map. The specific format of 1285 newly-generated individual keying material for group members, or of 1286 the information to derive it, and corresponding CBOR label, MUST be 1287 specified in the application profile (REQ15) and registered in 1288 Section 8.5. 1290 4.1.6.2. GET Handler 1292 The handler expects a GET request. 1294 The handler verifies that the group name of the /ace-group/GROUPNAME 1295 path is a subset of the 'scope' stored in the access token associated 1296 to this client, identified by "NODENAME". If verification fails, the 1297 KDC MUST respond with a 4.01 (Unauthorized) error message. 1299 The handler also verifies that the node sending the request and the 1300 node name used in the Uri-Path match. If that is not the case, the 1301 handler responds with a 4.01 (Unauthorized) error response. 1303 Additionally, the handler verifies that the node is a current member 1304 of the group. If verification fails, the KDC MUST respond with a 1305 4.00 (Bad Request) error message. 1307 If verification succeeds, the handler returns a 2.05 (Content) 1308 message containing both the group keying material and the individual 1309 keying material for the Client, or information enabling the Client to 1310 derive it. The payload of the response is formatted as a CBOR map. 1311 The format for the group keying material is the same as defined in 1312 the response of Section 4.1.2.2. The specific format of individual 1313 keying material for group members, or of the information to derive 1314 it, and corresponding CBOR label, MUST be specified in the 1315 application profile (REQ15) and registered in Section 8.5. 1317 4.1.6.3. DELETE Handler 1319 The DELETE handler removes the node identified by "NODENAME" from the 1320 group identified by "GROUPNAME". 1322 The handler expects a request with method DELETE (and empty payload). 1324 The handler only accepts a request from the node identified by 1325 "NODENAME" via the secure session, where NODENAME is used in Uri- 1326 Path, and that is part of the "GROUPNAME" group: the handler verifies 1327 that the group name "GROUPNAME" is a subset of the 'scope' stored in 1328 the access token associated to this client, and that this client is 1329 identified by "NODENAME". If verification fails, the KDC MUST 1330 respond with a 4.01 (Unauthorized) error message. 1332 The handler also verifies that the node sending the request and the 1333 node name used in the Uri-Path match. If that is not the case, the 1334 handler responds with a 4.01 (Unauthorized) error response. 1336 Additionally, the handler verifies that the node is a current member 1337 of the group. If verification fails, the KDC MUST respond with a 1338 4.00 (Bad Request) error message. 1340 If verification succeeds, the handler removes the client from the 1341 group identified by "GROUPNAME", for specific roles if roles were 1342 specified in the 'scope' field, or for all roles. That includes 1343 removing the public key of the client if the KDC keep tracks of that. 1344 Then, the handler delete the sub-resource nodes/NODENAME and returns 1345 a 2.02 (Deleted) message with empty payload. 1347 4.1.7. ace-group/GROUPNAME/nodes/NODENAME/pub-key 1349 This resource implements a POST handler, if the KDC stores the public 1350 key of group members. If the KDC does not store the public keys of 1351 group members, the handler does not implement any method, and every 1352 request returns a 4.05 Method Not Allowed error. 1354 4.1.7.1. POST Handler 1356 The POST handler is used to replace the stored public key of this 1357 client (identified by "NODENAME") with the one specified in the 1358 request at the KDC, for the group identified by "GROUPNAME". 1360 The handler expects a POST request with payload as specified in 1361 Section 4.1.2.1, with the difference that it includes only the 1362 parameters 'client_cred', 'cnonce' and 'client_cred_verify'. In 1363 particular, the signature included in 'client_cred_verify' is 1364 expected to be computed as defined in Section 4.1.2.1, with a newly 1365 generated N_C nonce and the previously received N_S. The specific 1366 format of public keys is specified by the application profile (OPT1). 1368 The handler verifies that the group name GROUPNAME is a subset of the 1369 'scope' stored in the access token associated to this client. If 1370 verification fails, the KDC MUST respond with a 4.01 (Unauthorized) 1371 error message. 1373 If the request is not formatted correctly (i.e. required fields non 1374 received or received with incorrect format), the handler MUST respond 1375 with a 4.00 (Bad Request) error message. If the request contained 1376 unknown or non-expected fields present, the handler MUST silently 1377 drop them and continue processing. Application profiles MAY define 1378 optional or mandatory payload formats for specific error cases 1379 (OPT6). 1381 Otherwise, the handler checks that the public key specified in the 1382 'client_cred' field has a valid format for the group identified by 1383 "GROUPNAME", i.e. it is encoded as expected and is compatible with 1384 the signature algorithm and possible associated parameters. If that 1385 cannot be verified, the handler MUST respond with a 4.00 (Bad 1386 Request) error message. Applications profiles MAY define 1387 alternatives (OPT5). 1389 Otherwise, the handler verifies the signature contained in the 1390 'client_cred_verify' field of the request, using the public key 1391 specified in the 'client_cred' field. If the signature does not pass 1392 verification, the handler MUST respond with a 4.00 (Bad Request) 1393 error message. If the KDC cannot retrieve the 'kdcchallenge' 1394 associated to this Client (see Section 3.3), the KDC MUST respond 1395 with a 4.00 Bad Request error respons, including a newly generated 1396 'kdcchallenge' in a CBOR map in the payload the payload. This error 1397 response MUST also have Content-Format "application/ace+cbor". 1399 If verification succeeds, the handler replaces the old public key of 1400 the node NODENAME with the one specified in the 'client_cred' field 1401 of the request, and stores it as the new current public key of the 1402 node NODENAME, in the list of group members' public keys for the 1403 group identified by GROUPNAME. Then, the handler replies with a 2.04 1404 (Changed) response, which does not include a payload. 1406 4.2. Joining Exchange 1408 Figure 8 gives an overview of the Joining exchange between Client and 1409 KDC, when the Client first joins a group. 1411 Client KDC 1412 | | 1413 |----- Joining Request: POST /ace-group/GROUPNAME ------>| 1414 | | 1415 |<--------- Joining Response: 2.01 (Created) ----------- | 1416 | Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME" | 1418 Figure 8: Message Flow of First Exchange for Group Joining 1420 If not previously established, the Client and the KDC MUST first 1421 establish a pairwise secure communication channel (REQ16). This can 1422 be achieved, for instance, by using a transport profile of ACE. The 1423 Joining exchange MUST occur over that secure channel. The Client and 1424 the KDC MAY use that same secure channel to protect further pairwise 1425 communications that must be secured. 1427 The secure communication protocol is REQUIRED to establish the secure 1428 channel between Client and KDC by using the proof-of-possession key 1429 bound to the access token. As a result, the proof-of-possession to 1430 bind the access token to the Client is performed by using the proof- 1431 of-possession key bound to the access token for establishing secure 1432 communication between the Client and the KDC. 1434 To join the group, the Client sends a CoAP POST request to the /ace- 1435 group/GROUPNAME endpoint at the KDC, where GROUPNAME is the group 1436 name of the group to join, formatted as specified in Section 4.1.2.1. 1437 This group name is the same as in the scope entry corresponding to 1438 that group, specified in the 'scope' parameter of the Authorization 1439 Request/Response, or it can be retrieved from it. Note that, in case 1440 of successful joining, the Client will receive the URI to retrieve 1441 individual or group keying material and to leave the group in the 1442 Location-Path option of the response. 1444 If the node is joining a group for the first time, and the KDC 1445 maintains the public keys of the group members, the Client is 1446 REQUIRED to send its own public key and proof of possession 1447 ("client_cred" and "client_cred_verify" in Section 4.1.2.1). The 1448 request is only accepted if both public key and proof of possession 1449 are provided. If a node re-joins a group with the same access token 1450 and the same public key, it can omit to send the public key and the 1451 proof of possession, or just omit the proof of possession, and the 1452 KDC will be able to retrieve its public key associated to its token 1453 for that group (if the key has been discarded, the KDC will reply 1454 with 4.00 Bad Request, as specified in Section 4.1.2.1). If a node 1455 re-joins a group but wants to update its own public key, it needs to 1456 send both public key and proof of possession. 1458 If the application requires backward security, the KDC MUST generate 1459 new group keying material and securely distribute it to all the 1460 current group members, upon a new node's joining the group. To this 1461 end, the KDC uses the message format of the response defined in 1462 Section 4.1.2.2. Application profiles may define alternative ways of 1463 retrieving the keying material, such as sending separate requests to 1464 different resources at the KDC (Section 4.1.2.2, Section 4.1.3.2, 1465 Section 4.1.4.1). After distributing the new group keying material, 1466 the KDC MUST increment the version number of the keying material. 1468 4.3. Retrieval of Updated Keying Material 1470 When any of the following happens, a node MUST stop using the owned 1471 group keying material to protect outgoing messages, and SHOULD stop 1472 using it to decrypt and verify incoming messages. 1474 * Upon expiration of the keying material, according to what 1475 indicated by the KDC with the 'exp' parameter in a Joining 1476 Response, or to a pre-configured value. 1478 * Upon receiving a notification of revoked/renewed keying material 1479 from the KDC, possibly as part of an update of the keying material 1480 (rekeying) triggered by the KDC. 1482 * Upon receiving messages from other group members without being 1483 able to retrieve the keying material to correctly decrypt them. 1484 This may be due to rekeying messages previously sent by the KDC, 1485 that the Client was not able to receive or decrypt. 1487 In either case, if it wants to continue participating in the group 1488 communication, the node has to request the latest keying material 1489 from the KDC. To this end, the Client sends a CoAP GET request to 1490 the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, 1491 formatted as specified in Section 4.1.6.2. 1493 Note that policies can be set up, so that the Client sends a Key Re- 1494 Distribution request to the KDC only after a given number of received 1495 messages could not be decrypted (because of failed decryption 1496 processing or inability to retrieve the necessary keying material). 1498 It is application dependent and pertaining to the particular message 1499 exchange (e.g. [I-D.ietf-core-oscore-groupcomm]) to set up these 1500 policies, to instruct clients to retain incoming messages and for how 1501 long (OPT4). This allows clients to possibly decrypt such messages 1502 after getting updated keying material, rather than just consider them 1503 non valid messages to discard right away. 1505 The same Key Distribution Request could also be sent by the Client 1506 without being triggered by a failed decryption of a message, if the 1507 Client wants to be sure that it has the latest group keying material. 1508 If that is the case, the Client will receive from the KDC the same 1509 group keying material it already has in memory. 1511 Figure 9 gives an overview of the exchange described above. 1513 Client KDC 1514 | | 1515 |------------------ Key Distribution Request: --------------->| 1516 | GET ace-group/GROUPNAME/nodes/NODENAME | 1517 | | 1518 |<-------- Key Distribution Response: 2.05 (Content) ---------| 1519 | | 1521 Figure 9: Message Flow of Key Distribution Request-Response 1523 Alternatively, the re-distribution of keying material can be 1524 initiated by the KDC, which e.g.: 1526 * Can make the ace-group/GROUPNAME/nodes/NODENAME resource 1527 Observable [RFC7641], and send notifications to Clients when the 1528 keying material is updated. 1530 * Can send the payload of the Key Distribution Response in one or 1531 multiple multicast POST requests to the members of the group, 1532 using secure rekeying schemes such as [RFC2093][RFC2094][RFC2627]. 1534 * Can send unicast POST requests to each Client over a secure 1535 channel, with the same payload as the Key Distribution Response. 1536 When sending such requests, the KDC can target the URI path 1537 provided by the intended recipient upon joining the group, as 1538 specified in the 'control_path' parameter of the Joining Request 1539 (see Section 4.1.2.1). 1541 * Can act as a publisher in a pub-sub scenario, and update the 1542 keying material by publishing on a specific topic on a broker, 1543 which all the members of the group are subscribed to. 1545 Note that these methods of KDC-initiated key distribution have 1546 different security properties and require different security 1547 associations. 1549 Congestion control mechanisms need to be implemented: see Section 4.7 1550 of [RFC7252] and, where Observe is used, Section 4.5.1 of [RFC7641]. 1552 4.4. Retrieval of New Individual Keying Material 1554 Beside possible expiration, the client may need to communicate to the 1555 KDC its need for part of the keying material to be renewed. For 1556 example, if the Client uses an individual key to protect outgoing 1557 traffic and has to renew it, the node may request a new one, or new 1558 input material to derive it, without renewing the whole group keying 1559 material. 1561 To this end, the client performs a Key Renewal Request/Response 1562 exchange with the KDC, i.e. it sends a CoAP PUT request to the /ace- 1563 group/GROUPNAME/nodes/NODENAME endpoint at the KDC, where GROUPNAME 1564 is the group name and NODENAME is the node's name, and formatted as 1565 defined in Section 4.1.6.2. 1567 Figure 10 gives an overview of the exchange described above. 1569 Client KDC 1570 | | 1571 |------------------ Key Renewal Request: -------------->| 1572 | PUT ace-group/GROUPNAME/nodes/NODENAME | 1573 | | 1574 |<-------- Key Renewal Response: 2.05 (Content) --------| 1575 | | 1577 Figure 10: Message Flow of Key Renewal Request-Response 1579 Note the difference between the Key Distribution Request and the Key 1580 Renewal Request: while the first one only triggers distribution (the 1581 renewal might have happened independently, e.g. because of 1582 expiration), the second one triggers the KDC to produce new 1583 individual keying material for the requesting node. 1585 Furthermore, policies can be set up so that, upon receiving a Key 1586 Renewal Request, the KDC performs a complete group rekeying before or 1587 after replying to the client (OPT8). 1589 4.5. Retrieval of Public Keys and Roles for Group Members 1591 In case the KDC maintains the public keys of group members, a node in 1592 the group can contact the KDC to request public keys and roles of 1593 either all group members or a specified subset, by sending a CoAP GET 1594 or FETCH request to the /ace-group/GROUPNAME/pub-key endpoint at the 1595 KDC, where GROUPNAME is the group name, and formatted as defined in 1596 Section 4.1.3.2 and Section 4.1.3.1. 1598 When receiving a Public Key Response, the requesting group member 1599 stores (or updates) the public keys (in the 'pub_keys' parameter) and 1600 roles (in the 'peer_roles' parameter) of the group members. 1602 Figure 11 and Figure 12 give an overview of the exchanges described 1603 above. 1605 Client KDC 1606 | | 1607 |--Public Key Request: GET /ace-group/GROUPNAME/pub-key->| 1608 | | 1609 |<--------- Public Key Response: 2.05 (Content) ---------| 1610 | | 1612 Figure 11: Message Flow of Public Key Exchange to Request All 1613 Members Public Keys 1615 Client KDC 1616 | | 1617 |-Public Key Request: FETCH /ace-group/GROUPNAME/pub-key->| 1618 | | 1619 |<--------- Public Key Response: 2.05 (Created) ----------| 1620 | | 1622 Figure 12: Message Flow of Public Key Exchange to Request 1623 Specific Members Public Keys 1625 4.6. Update of Public Key 1627 In case the KDC maintains the public keys of group members, a node in 1628 the group can contact the KDC to upload a new public key to use in 1629 the group, and replace the currently stored one. 1631 To this end, the Client performs a Public Key Update Request/Response 1632 exchange with the KDC, i.e. it sends a CoAP POST request to the /ace- 1633 group/GROUPNAME/nodes/NODENAME/pub-key endpoint at the KDC, where 1634 GROUPNAME is the group name and NODENAME is the node's name. 1636 The request is formatted as specified in Section 4.1.7.1. 1638 Figure Figure 13 gives an overview of the exchange described above. 1640 Client KDC 1641 | | 1642 |-------------- Public Key Update Request: ---------------------->| 1643 | POST ace-group/GROUPNAME/nodes/NODENAME/pub-key | 1644 | | 1645 |<------- Public Key Update Response: 2.04 (Changed) -------------| 1646 | | 1648 Figure 13: Message Flow of Public Key Update Request-Response 1650 If the application requires backward security, the KDC MUST generate 1651 new group keying material and securely distribute it to all the 1652 current group members, upon a group member updating its own public 1653 key. To this end, the KDC uses the message format of the response 1654 defined in Section 4.1.2.2. Application profiles may define 1655 alternative ways of retrieving the keying material, such as sending 1656 separate requests to different resources at the KDC (Section 4.1.2.2, 1657 Section 4.1.3.2, Section 4.1.4.1). The KDC MUST increment the 1658 version number of the current keying material, before distributing 1659 the newly generated keying material to the group. After that, the 1660 KDC SHOULD store the distributed keying material in persistent 1661 storage. 1663 Additionally, after updating its own public key, a group member MAY 1664 send a number of the later requests including an identifier of the 1665 updated public key, to signal nodes that they need to retrieve it. 1666 How that is done depends on the group communication protocol used, 1667 and therefore is application profile specific (OPT10). 1669 4.7. Retrieval of Group Policies 1671 A node in the group can contact the KDC to retrieve the current group 1672 policies, by sending a CoAP GET request to the /ace-group/GROUPNAME/ 1673 policies endpoint at the KDC, where GROUPNAME is the group name, and 1674 formatted as defined in Section 4.1.4.1 1676 Figure 14 gives an overview of the exchange described above. 1678 Client KDC 1679 | | 1680 |-Policies Request: GET ace-group/GROUPNAME/policies ->| 1681 | | 1682 |<--------- Policies Response: 2.05 (Content) ---------| 1683 | | 1685 Figure 14: Message Flow of Policies Request-Response 1687 4.8. Retrieval of Keying Material Version 1689 A node in the group can contact the KDC to request information about 1690 the version number of the symmetric group keying material, by sending 1691 a CoAP GET request to the /ace-group/GROUPNAME/num endpoint at the 1692 KDC, where GROUPNAME is the group name, formatted as defined in 1693 Section 4.1.5.1. In particular, the version is incremented by the 1694 KDC every time the group keying material is renewed, before it's 1695 distributed to the group members. 1697 Figure 15 gives an overview of the exchange described above. 1699 Client KDC 1700 | | 1701 |---- Version Request: GET ace-group/GROUPNAME/num ---->| 1702 | | 1703 |<--------- Version Response: 2.05 (Content) -----------| 1704 | | 1706 Figure 15: Message Flow of Version Request-Response 1708 4.9. Group Leaving Request 1710 A node can actively request to leave the group. In this case, the 1711 Client sends a CoAP DELETE request to the endpoint /ace- 1712 group/GROUPNAME/nodes/NODENAME at the KDC, where GROUPNAME is the 1713 group name and NODENAME is the node's name, formatted as defined in 1714 Section 4.1.6.3 1716 Alternatively, a node may be removed by the KDC, without having 1717 explicitly asked for it. This is further discussed in Section 5. 1719 5. Removal of a Node from the Group 1721 This section describes the different scenarios according to which a 1722 node ends up being removed from the group. 1724 If the application requires forward security, the KDC MUST generate 1725 new group keying material and securely distribute it to all the 1726 current group members but the leaving node, using the message format 1727 of the Key Distribution Response (see Section 4.3). Application 1728 profiles may define alternative message formats. Before distributing 1729 the new group keying material, the KDC MUST increment the version 1730 number of the keying material. 1732 Note that, after having left the group, a node may wish to join it 1733 again. Then, as long as the node is still authorized to join the 1734 group, i.e. it still has a valid access token, it can re-request to 1735 join the group directly to the KDC without needing to retrieve a new 1736 access token from the AS. This means that the KDC might decide to 1737 keep track of nodes with valid access tokens, before deleting all 1738 information about the leaving node. 1740 A node may be evicted from the group in the following cases. 1742 1. The node explicitly asks to leave the group, as defined in 1743 Section 4.9. 1745 2. The node has been found compromised or is suspected so. 1747 3. The node's authorization to be a group member is not valid 1748 anymore, either because the access token has expired, or it has 1749 been revoked. If the AS provides Token introspection (see 1750 Section 5.7 of [I-D.ietf-ace-oauth-authz]), the KDC can 1751 optionally use it and check whether the node is still authorized 1752 for that group in that role. 1754 In either case, once aware that a node is not authorized anymore, the 1755 KDC has to remove the unauthorized node from the list of group 1756 members, if the KDC keeps track of that. 1758 In case of forced eviction, the KDC MAY explicitly inform the leaving 1759 node, if the Client implements the 'control_path' resource specified 1760 in Section 4.1.2.1. To this end, the KDC MAY send a DEL request, 1761 targeting the URI specified in the 'control_path' parameter of the 1762 Joining Request. 1764 6. ACE Groupcomm Parameters 1766 This specification defines a number of fields used during the second 1767 part of the message exchange, after the ACE Token POST exchange. The 1768 table below summarizes them, and specifies the CBOR key to use 1769 instead of the full descriptive name. Note that the media type ace- 1770 groupcomm+cbor MUST be used when these fields are transported. 1772 +=======================+======+===============+==================+ 1773 | Name | CBOR | CBOR Type | Reference | 1774 | | Key | | | 1775 +=======================+======+===============+==================+ 1776 | scope | TBD | byte string | Section 4.1.2.1 | 1777 +-----------------------+------+---------------+------------------+ 1778 | get_pub_keys | TBD | array | Section 4.1.2.1, | 1779 | | | | Section 4.1.3.1 | 1780 +-----------------------+------+---------------+------------------+ 1781 | client_cred | TBD | byte string | Section 4.1.2.1 | 1782 +-----------------------+------+---------------+------------------+ 1783 | cnonce | TBD | byte string | Section 4.1.2.1 | 1784 +-----------------------+------+---------------+------------------+ 1785 | client_cred_verify | TBD | byte string | Section 4.1.2.1 | 1786 +-----------------------+------+---------------+------------------+ 1787 | pub_keys_repos | TBD | text string | Section 4.1.2.1 | 1788 +-----------------------+------+---------------+------------------+ 1789 | control_path | TBD | text string | Section 4.1.2.1 | 1790 +-----------------------+------+---------------+------------------+ 1791 | gkty | TBD | int / text | Section 4.1.2.1 | 1792 | | | string | | 1793 +-----------------------+------+---------------+------------------+ 1794 | key | TBD | see "ACE | Section 4.1.2.1 | 1795 | | | Groupcomm | | 1796 | | | Key" Registry | | 1797 +-----------------------+------+---------------+------------------+ 1798 | num | TBD | int | Section 4.1.2.1 | 1799 +-----------------------+------+---------------+------------------+ 1800 | ace-groupcomm-profile | TBD | int | Section 4.1.2.1 | 1801 +-----------------------+------+---------------+------------------+ 1802 | exp | TBD | int | Section 4.1.2.1 | 1803 +-----------------------+------+---------------+------------------+ 1804 | pub_keys | TBD | byte string | Section 4.1.2.1 | 1805 +-----------------------+------+---------------+------------------+ 1806 | peer_roles | TBD | array | Section 4.1.2.1 | 1807 +-----------------------+------+---------------+------------------+ 1808 | group_policies | TBD | map | Section 4.1.2.1 | 1809 +-----------------------+------+---------------+------------------+ 1810 | mgt_key_material | TBD | byte string | Section 4.1.2.1 | 1811 +-----------------------+------+---------------+------------------+ 1813 Table 1 1815 7. Security Considerations 1817 When a Client receives a message from a sender for the first time, it 1818 needs to have a mechanism in place to avoid replay, e.g. 1819 Appendix B.2 of [RFC8613]. In case the Client rebooted and lost the 1820 security state used to protect previous communication with that 1821 sender, such a mechanism is useful for the recipient to be on the 1822 safe side. Besides, if the KDC has renewed the group keying 1823 material, and the time interval between the end of the rekeying 1824 process and the joining of the Client is sufficiently small, that 1825 Client is also on the safe side, since replayed older messages 1826 protected with the previous keying material will not be accepted. 1828 The KDC must renew the group keying material upon its expiration. 1830 The KDC should renew the keying material upon group membership 1831 change, and should provide it to the current group members through 1832 the rekeying scheme used in the group. 1834 The KDC should renew the group keying material after rebooting, even 1835 in the case where all keying material is stored in persistent 1836 storage. However, if the KDC relies on Observe responses to notify 1837 the group of renewed keying material, after rebooting the KDC will 1838 have lost all the current ongoing Observations with the group 1839 members, and the previous keying material will be used to protect 1840 messages in the group anyway. The KDC will rely on each node 1841 requesting updates of the group keying material to establish the new 1842 keying material in the nodes, or, if implemented, it can push the 1843 update to the nodes in the group using the 'control_path' resource. 1845 The KDC may enforce a rekeying policy that takes into account the 1846 overall time required to rekey the group, as well as the expected 1847 rate of changes in the group membership. 1849 That is, the KDC may not rekey the group at every membership change, 1850 for instance if members' joining and leaving occur frequently and 1851 performing a group rekeying takes too long. The KDC may rekey the 1852 group after a minimum number of group members have joined or left 1853 within a given time interval, or after maximum amount of time since 1854 the last rekeying was completed, or yet during predictable network 1855 inactivity periods. 1857 However, this would result in the KDC not constantly preserving 1858 backward and forward security. Newly joining group members could be 1859 able to access the keying material used before their joining, and 1860 thus could access past group communications. Also, until the KDC 1861 performs a group rekeying, the newly leaving nodes would still be 1862 able to access upcoming group communications that are protected with 1863 the keying material that has not yet been updated. 1865 The KDC needs to have a mechanism in place to detect DoS attacks from 1866 nodes constantly initiating rekey events (for example by updating 1867 their public key), such as removing these nodes from the group. 1869 The KDC also needs to have a congestion control mechanism in place to 1870 avoid network congestion when the KDC renews the group keying 1871 material; CoAP and Observe give guidance on such mechanisms, see 1872 Section 4.7 of [RFC7252] and Section 4.5.1 of [RFC7641]. 1874 7.1. Update of Keying Material 1876 A group member can receive a message shortly after the group has been 1877 rekeyed, and new keying material has been distributed by the KDC. In 1878 the following two cases, this may result in misaligned keying 1879 material between the group members. 1881 In the first case, the sender protects a message using the old keying 1882 material. However, the recipient receives the message after having 1883 received the new keying material, hence not being able to correctly 1884 process it. A possible way to ameliorate this issue is to preserve 1885 the old, recent, keying material for a maximum amount of time defined 1886 by the application. By doing so, the recipient can still try to 1887 process the received message using the old retained keying material. 1888 Note that a former (compromised) group member can take advantage of 1889 this by sending messages protected with the old retained keying 1890 material. Therefore, a conservative application policy should not 1891 admit the storage of old keying material. 1893 In the second case, the sender protects a message using the new 1894 keying material, but the recipient receives that request before 1895 having received the new keying material. Therefore, the recipient 1896 would not be able to correctly process the request and hence discards 1897 it. If the recipient receives the new keying material shortly after 1898 that and the application at the sender endpoint performs 1899 retransmissions, the former will still be able to receive and 1900 correctly process the message. In any case, the recipient should 1901 actively ask the KDC for an updated keying material according to an 1902 application-defined policy, for instance after a given number of 1903 unsuccessfully decrypted incoming messages. 1905 A node that has left the group should not expect any of its outgoing 1906 messages to be successfully processed, if received after its leaving, 1907 due to a possible group rekeying occurred before the message 1908 reception. 1910 7.2. Block-Wise Considerations 1912 If the block-wise options [RFC7959] are used, and the keying material 1913 is updated in the middle of a block-wise transfer, the sender of the 1914 blocks just changes the keying material to the updated one and 1915 continues the transfer. As long as both sides get the new keying 1916 material, updating the keying material in the middle of a transfer 1917 will not cause any issue. Otherwise, the sender will have to 1918 transmit the message again, when receiving an error message from the 1919 recipient. 1921 Compared to a scenario where the transfer does not use block-wise, 1922 depending on how fast the keying material is changed, the nodes might 1923 consume a larger amount of the network bandwidth resending the blocks 1924 again and again, which might be problematic. 1926 8. IANA Considerations 1928 This document has the following actions for IANA. 1930 8.1. Media Type Registrations 1932 This specification registers the 'application/ace-groupcomm+cbor' 1933 media type for messages of the protocols defined in this document 1934 following the ACE exchange and carrying parameters encoded in CBOR. 1935 This registration follows the procedures specified in [RFC6838]. 1937 Type name: application 1939 Subtype name: ace-groupcomm+cbor 1941 Required parameters: none 1943 Optional parameters: none 1945 Encoding considerations: Must be encoded as CBOR map containing the 1946 protocol parameters defined in [this document]. 1948 Security considerations: See Section 7 of this document. 1950 Interoperability considerations: n/a 1952 Published specification: [this document] 1953 Applications that use this media type: The type is used by 1954 authorization servers, clients and resource servers that support the 1955 ACE groupcomm framework as specified in [this document]. 1957 Additional information: 1959 Magic number(s): n/a 1961 File extension(s): .ace-groupcomm 1963 Macintosh file type code(s): n/a 1965 Person & email address to contact for further information: 1966 iesg@ietf.org (mailto:iesg@ietf.org) 1968 Intended usage: COMMON 1970 Restrictions on usage: None 1972 Author: Francesca Palombini francesca.palombini@ericsson.com 1973 (mailto:francesca.palombini@ericsson.com) 1975 Change controller: IESG 1977 8.2. CoAP Content-Formats Registry 1979 This specification registers the following entry to the "CoAP 1980 Content-Formats" registry, within the "CoRE Parameters" registry: 1982 Media Type: application/ace-groupcomm+cbor 1984 Encoding: - 1986 ID: TBD 1988 Reference: [this document] 1990 8.3. OAuth Parameters Registry 1992 The following registrations are done for the OAuth ParametersRegistry 1993 following the procedure specified in section 11.2 of [RFC6749]: 1995 o Parameter name: sign_info o Parameter usage location: token 1996 request, token response o Change Controller: IESG o Specification 1997 Document(s): [[This specification]] 1998 o Parameter name: kdcchallenge o Parameter usage location: token 1999 response o Change Controller: IESG o Specification Document(s): 2000 [[This specification]] 2002 8.4. OAuth Parameters CBOR Mappings Registry 2004 The following registrations are done for the OAuth Parameters CBOR 2005 Mappings Registry following the procedure specified in section 8.9 of 2006 [I-D.ietf-ace-oauth-authz]: 2008 * Name: sign_info 2009 * CBOR Key: TBD (range -256 to 255) 2010 * Value Type: any 2011 * Reference: \[\[This specification\]\] 2013 * Name: kdcchallenge 2014 * CBOR Key: TBD (range -256 to 255) 2015 * Value Type: byte string 2016 * Reference: \[\[This specification\]\] 2018 8.5. ACE Groupcomm Parameters Registry 2020 This specification establishes the "ACE Groupcomm Parameters" IANA 2021 Registry. The Registry has been created to use the "Expert Review 2022 Required" registration procedure [RFC8126]. Expert review guidelines 2023 are provided in Section 8.11. 2025 The columns of this Registry are: 2027 * Name: This is a descriptive name that enables easier reference to 2028 the item. The name MUST be unique. It is not used in the 2029 encoding. 2031 * CBOR Key: This is the value used as CBOR key of the item. These 2032 values MUST be unique. The value can be a positive integer, a 2033 negative integer, or a string. 2035 * CBOR Type: This contains the CBOR type of the item, or a pointer 2036 to the registry that defines its type, when that depends on 2037 another item. 2039 * Reference: This contains a pointer to the public specification for 2040 the item. 2042 This Registry has been initially populated by the values in 2043 Section 6. The Reference column for all of these entries refers to 2044 sections of this document. 2046 8.6. ACE Groupcomm Key Registry 2048 This specification establishes the "ACE Groupcomm Key" IANA Registry. 2049 The Registry has been created to use the "Expert Review Required" 2050 registration procedure [RFC8126]. Expert review guidelines are 2051 provided in Section 8.11. 2053 The columns of this Registry are: 2055 * Name: This is a descriptive name that enables easier reference to 2056 the item. The name MUST be unique. It is not used in the 2057 encoding. 2059 * Key Type Value: This is the value used to identify the keying 2060 material. These values MUST be unique. The value can be a 2061 positive integer, a negative integer, or a text string. 2063 * Profile: This field may contain one or more descriptive strings of 2064 application profiles to be used with this item. The values should 2065 be taken from the Name column of the "ACE Groupcomm Profile" 2066 Registry. 2068 * Description: This field contains a brief description of the keying 2069 material. 2071 * References: This contains a pointer to the public specification 2072 for the format of the keying material, if one exists. 2074 This Registry has been initially populated by the values in Figure 6. 2075 The specification column for all of these entries will be this 2076 document. 2078 8.7. ACE Groupcomm Profile Registry 2080 This specification establishes the "ACE Groupcomm Profile" IANA 2081 Registry. The Registry has been created to use the "Expert Review 2082 Required" registration procedure [RFC8126]. Expert review guidelines 2083 are provided in Section 8.11. It should be noted that, in addition 2084 to the expert review, some portions of the Registry require a 2085 specification, potentially a Standards Track RFC, be supplied as 2086 well. 2088 The columns of this Registry are: 2090 * Name: The name of the application profile, to be used as value of 2091 the profile attribute. 2093 * Description: Text giving an overview of the application profile 2094 and the context it is developed for. 2096 * CBOR Value: CBOR abbreviation for the name of this application 2097 profile. Different ranges of values use different registration 2098 policies [RFC8126]. Integer values from -256 to 255 are 2099 designated as Standards Action. Integer values from -65536 to 2100 -257 and from 256 to 65535 are designated as Specification 2101 Required. Integer values greater than 65535 are designated as 2102 Expert Review. Integer values less than -65536 are marked as 2103 Private Use. 2105 * Reference: This contains a pointer to the public specification of 2106 the abbreviation for this application profile, if one exists. 2108 8.8. ACE Groupcomm Policy Registry 2110 This specification establishes the "ACE Groupcomm Policy" IANA 2111 Registry. The Registry has been created to use the "Expert Review 2112 Required" registration procedure [RFC8126]. Expert review guidelines 2113 are provided in Section 8.11. It should be noted that, in addition 2114 to the expert review, some portions of the Registry require a 2115 specification, potentially a Standards Track RFC, be supplied as 2116 well. 2118 The columns of this Registry are: 2120 * Name: The name of the group communication policy. 2122 * CBOR label: The value to be used to identify this group 2123 communication policy. Key map labels MUST be unique. The label 2124 can be a positive integer, a negative integer or a string. 2125 Integer values between 0 and 255 and strings of length 1 are 2126 designated as Standards Track Document required. Integer values 2127 from 256 to 65535 and strings of length 2 are designated as 2128 Specification Required. Integer values of greater than 65535 and 2129 strings of length greater than 2 are designated as expert review. 2130 Integer values less than -65536 are marked as private use. 2132 * CBOR type: the CBOR type used to encode the value of this group 2133 communication policy. 2135 * Description: This field contains a brief description for this 2136 group communication policy. 2138 * Reference: This field contains a pointer to the public 2139 specification providing the format of the group communication 2140 policy, if one exists. 2142 This registry will be initially populated by the values in Figure 7. 2144 8.9. Sequence Number Synchronization Method Registry 2146 This specification establishes the "Sequence Number Synchronization 2147 Method" IANA Registry. The Registry has been created to use the 2148 "Expert Review Required" registration procedure [RFC8126]. Expert 2149 review guidelines are provided in Section 8.11. It should be noted 2150 that, in addition to the expert review, some portions of the Registry 2151 require a specification, potentially a Standards Track RFC, be 2152 supplied as well. 2154 The columns of this Registry are: 2156 * Name: The name of the sequence number synchronization method. 2158 * Value: The value to be used to identify this sequence number 2159 synchronization method. 2161 * Description: This field contains a brief description for this 2162 sequence number synchronization method. 2164 * Reference: This field contains a pointer to the public 2165 specification describing the sequence number synchronization 2166 method. 2168 8.10. Interface Description (if=) Link Target Attribute Values Registry 2170 This specification registers the following entry to the "Interface 2171 Description (if=) Link Target Attribute Values Registry" registry, 2172 within the "CoRE Parameters" registry: 2174 * Attribute Value: ace.group 2176 * Description: The 'ace group' interface is used to provision keying 2177 material and related informations and policies to members of a 2178 group using the Ace framework. 2180 * Reference: [This Document] 2182 8.11. Expert Review Instructions 2184 The IANA Registries established in this document are defined as 2185 expert review. This section gives some general guidelines for what 2186 the experts should be looking for, but they are being designated as 2187 experts for a reason so they should be given substantial latitude. 2189 Expert reviewers should take into consideration the following points: 2191 * Point squatting should be discouraged. Reviewers are encouraged 2192 to get sufficient information for registration requests to ensure 2193 that the usage is not going to duplicate one that is already 2194 registered and that the point is likely to be used in deployments. 2195 The zones tagged as private use are intended for testing purposes 2196 and closed environments, code points in other ranges should not be 2197 assigned for testing. 2199 * Specifications are required for the standards track range of point 2200 assignment. Specifications should exist for specification 2201 required ranges, but early assignment before a specification is 2202 available is considered to be permissible. Specifications are 2203 needed for the first-come, first-serve range if they are expected 2204 to be used outside of closed environments in an interoperable way. 2205 When specifications are not provided, the description provided 2206 needs to have sufficient information to identify what the point is 2207 being used for. 2209 * Experts should take into account the expected usage of fields when 2210 approving point assignment. The fact that there is a range for 2211 standards track documents does not mean that a standards track 2212 document cannot have points assigned outside of that range. The 2213 length of the encoded value should be weighed against how many 2214 code points of that length are left, the size of device it will be 2215 used on, and the number of code points left that encode to that 2216 size. 2218 9. References 2220 9.1. Normative References 2222 [COSE.Algorithms] 2223 IANA, "COSE Algorithms", 2224 . 2227 [I-D.ietf-ace-oauth-authz] 2228 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 2229 H. Tschofenig, "Authentication and Authorization for 2230 Constrained Environments (ACE) using the OAuth 2.0 2231 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 2232 draft-ietf-ace-oauth-authz-35, 24 June 2020, 2233 . 2236 [I-D.ietf-ace-oauth-params] 2237 Seitz, L., "Additional OAuth Parameters for Authorization 2238 in Constrained Environments (ACE)", Work in Progress, 2239 Internet-Draft, draft-ietf-ace-oauth-params-13, 28 April 2240 2020, . 2243 [I-D.ietf-core-oscore-groupcomm] 2244 Tiloca, M., Selander, G., Palombini, F., and J. Park, 2245 "Group OSCORE - Secure Group Communication for CoAP", Work 2246 in Progress, Internet-Draft, draft-ietf-core-oscore- 2247 groupcomm-09, 23 June 2020, . 2250 [I-D.ietf-cose-rfc8152bis-algs] 2251 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2252 Initial Algorithms", Work in Progress, Internet-Draft, 2253 draft-ietf-cose-rfc8152bis-algs-11, 1 July 2020, 2254 . 2257 [I-D.ietf-cose-rfc8152bis-struct] 2258 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2259 Structures and Process", Work in Progress, Internet-Draft, 2260 draft-ietf-cose-rfc8152bis-struct-11, 1 July 2020, 2261 . 2264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2265 Requirement Levels", BCP 14, RFC 2119, 2266 DOI 10.17487/RFC2119, March 1997, 2267 . 2269 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 2270 RFC 6749, DOI 10.17487/RFC6749, October 2012, 2271 . 2273 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2274 Specifications and Registration Procedures", BCP 13, 2275 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2276 . 2278 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2279 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2280 October 2013, . 2282 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2283 Application Protocol (CoAP)", RFC 7252, 2284 DOI 10.17487/RFC7252, June 2014, 2285 . 2287 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2288 Writing an IANA Considerations Section in RFCs", BCP 26, 2289 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2290 . 2292 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2293 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2294 May 2017, . 2296 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 2297 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 2298 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2299 2020, . 2301 9.2. Informative References 2303 [I-D.bormann-core-ace-aif] 2304 Bormann, C., "An Authorization Information Format (AIF) 2305 for ACE", Work in Progress, Internet-Draft, draft-bormann- 2306 core-ace-aif-09, 27 June 2020, . 2309 [I-D.ietf-ace-dtls-authorize] 2310 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 2311 L. Seitz, "Datagram Transport Layer Security (DTLS) 2312 Profile for Authentication and Authorization for 2313 Constrained Environments (ACE)", Work in Progress, 2314 Internet-Draft, draft-ietf-ace-dtls-authorize-12, 6 July 2315 2020, . 2318 [I-D.ietf-ace-mqtt-tls-profile] 2319 Sengul, C., Kirby, A., and P. Fremantle, "MQTT-TLS profile 2320 of ACE", Work in Progress, Internet-Draft, draft-ietf-ace- 2321 mqtt-tls-profile-05, 28 May 2020, . 2324 [I-D.ietf-ace-oscore-profile] 2325 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 2326 "OSCORE profile of the Authentication and Authorization 2327 for Constrained Environments Framework", Work in Progress, 2328 Internet-Draft, draft-ietf-ace-oscore-profile-11, 18 June 2329 2020, . 2332 [I-D.ietf-core-coap-pubsub] 2333 Koster, M., Keranen, A., and J. Jimenez, "Publish- 2334 Subscribe Broker for the Constrained Application Protocol 2335 (CoAP)", Work in Progress, Internet-Draft, draft-ietf- 2336 core-coap-pubsub-09, 30 September 2019, 2337 . 2340 [I-D.ietf-core-groupcomm-bis] 2341 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 2342 for the Constrained Application Protocol (CoAP)", Work in 2343 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 2344 00, 30 March 2020, . 2347 [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management 2348 Protocol (GKMP) Specification", RFC 2093, 2349 DOI 10.17487/RFC2093, July 1997, 2350 . 2352 [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management 2353 Protocol (GKMP) Architecture", RFC 2094, 2354 DOI 10.17487/RFC2094, July 1997, 2355 . 2357 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 2358 Multicast: Issues and Architectures", RFC 2627, 2359 DOI 10.17487/RFC2627, June 1999, 2360 . 2362 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2363 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2364 January 2012, . 2366 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 2367 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 2368 . 2370 [RFC7641] Hartke, K., "Observing Resources in the Constrained 2371 Application Protocol (CoAP)", RFC 7641, 2372 DOI 10.17487/RFC7641, September 2015, 2373 . 2375 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 2376 the Constrained Application Protocol (CoAP)", RFC 7959, 2377 DOI 10.17487/RFC7959, August 2016, 2378 . 2380 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2381 Interchange Format", STD 90, RFC 8259, 2382 DOI 10.17487/RFC8259, December 2017, 2383 . 2385 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 2386 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 2387 May 2018, . 2389 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2390 Definition Language (CDDL): A Notational Convention to 2391 Express Concise Binary Object Representation (CBOR) and 2392 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2393 June 2019, . 2395 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2396 "Object Security for Constrained RESTful Environments 2397 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2398 . 2400 Appendix A. Requirements on Application Profiles 2402 This section lists the requirements on application profiles of this 2403 specification,for the convenience of application profile designers. 2405 * REQ1: Specify the encoding and value of the identifier of group or 2406 topic, for scope entries of 'scope' (see Section 3.1). 2408 * REQ2: Specify the encoding and value of roles, for scope entries 2409 of 'scope' (see Section 3.1). 2411 * REQ3: If used, specify the acceptable values for 'sign_alg' (see 2412 Section 3.3). 2414 * REQ4: If used, specify the acceptable values for 'sign_parameters' 2415 (see Section 3.3). 2417 * REQ5: If used, specify the acceptable values for 2418 'sign_key_parameters' (see Section 3.3). 2420 * REQ6: If used, specify the acceptable values for 'pub_key_enc' 2421 (see Section 3.3). 2423 * REQ7: Specify the exact format of the 'key' value (see 2424 Section 4.1.2.1). 2426 * REQ8: Specify the acceptable values of 'gkty' (see 2427 Section 4.1.2.1). 2429 * REQ9: Specify the format of the identifiers of group members (see 2430 Section 4.1.2.1). 2432 * REQ10: Specify the communication protocol the members of the group 2433 must use (e.g., multicast CoAP). 2435 * REQ11: Specify the security protocol the group members must use to 2436 protect their communication (e.g., group OSCORE). This must 2437 provide encryption, integrity and replay protection. 2439 * REQ12: Specify and register the application profile identifier 2440 (see Section 4.1.2.1). 2442 * REQ13: Specify policies at the KDC to handle ids that are not 2443 included in get_pub_keys (see Section 4.1.3.1). 2445 * REQ14: If used, specify the format and content of 'group_policies' 2446 and its entries. Specify the policies default values (see 2447 Section 4.1.2.1). 2449 * REQ15: Specify the format of newly-generated individual keying 2450 material for group members, or of the information to derive it, 2451 and corresponding CBOR label (see Section 4.1.6.2). 2453 * REQ16: Specify how the communication is secured between Client and 2454 KDC. Optionally, specify tranport profile of ACE 2455 [I-D.ietf-ace-oauth-authz] to use between Client and KDC (see 2456 Section 4.2. 2458 * REQ17: Specify how the nonce N_S is generated, if the token was 2459 not posted (e.g. if it is used directly to validate TLS instead). 2461 * REQ18: Specify if 'mgt_key_material' used, and if yes specify its 2462 format and content (see Section 4.1.2.1). If the usage of 2463 'mgt_key_material' is indicated and its format defined for a 2464 specific key management scheme, that format must explicitly 2465 indicate the key management scheme itself. If a new rekeying 2466 scheme is defined to be used for an existing 'mgt_key_material' in 2467 an existing profile, then that profile will have to be updated 2468 accordingly, especially with respect to the usage of 2469 'mgt_key_material' related format and content. 2471 * REQ19: Define the initial value of the 'num' parameter (sse 2472 Section 4.1.2.1). 2474 * OPT1: Optionally, specify the encoding of public keys, of 2475 'client_cred', and of 'pub_keys' if COSE_Keys are not used (see 2476 Section 4.1.2.1). 2478 * OPT2: Optionally, specify the negotiation of parameter values for 2479 signature algorithm and signature keys, if 'sign_info' is not used 2480 (see Section 3.3). 2482 * OPT3: Optionally, specify the encoding of 'pub_keys_repos' if the 2483 default is not used (see Section 4.1.2.1). 2485 * OPT4: Optionally, specify policies that instruct clients to retain 2486 messages and for how long, if they are unsuccessfully decrypted 2487 (see Section 4.3). This makes it possible to decrypt such 2488 messages after getting updated keying material. 2490 * OPT5: Optionally, specify the behavior of the handler in case of 2491 failure to retrieve a public key for the specific node (see 2492 Section 4.1.2.1). 2494 * OPT6: Optionally, specify possible or required payload formats for 2495 specific error cases. 2497 * OPT7: Optionally, specify CBOR values to use for abbreviating 2498 identifiers of roles in the group or topic (see Section 3.1). 2500 * OPT8: Optionally, specify policies for the KDC to perform group 2501 rekeying after receiving a Key Renewal Request (see Section 4.4). 2503 * OPT9: Optionally, specify the functionalities implemented at the 2504 'control_path' resource hosted at the Client, including message 2505 exchange encoding and other details (see Section 4.1.2.1). 2507 * OPT10: Optionally, specify how the identifier of the sender's 2508 public key is included in the group request (see Section 4.6). 2510 Appendix B. Document Updates 2512 RFC EDITOR: PLEASE REMOVE THIS SECTION. 2514 B.1. Version -04 to -05 2516 * Updated uppercase/lowercase URI segments for KDC resources. 2518 * Supporting single Access Token for multiple groups/topics. 2520 * Added 'control_path' parameter in the Joining Request. 2522 * Added 'peer_roles' parameter to support legal requesters/ 2523 responders. 2525 * Clarification on stopping using owned keying material. 2527 * Clarification on different reasons for processing failures, 2528 related policies, and requirement OPT4. 2530 * Added a KDC sub-resource for group members to upload a new public 2531 key. 2533 * Possible group rekeying following an individual Key Renewal 2534 Request. 2536 * Clarified meaning of requirement REQ3; added requirement OPT8. 2538 * Editorial improvements. 2540 B.2. Version -03 to -04 2542 * Revised RESTful interface, as to methods and parameters. 2544 * Extended processing of joining request, as to check/retrieval of 2545 public keys. 2547 * Revised and extended profile requirements. 2549 * Clarified specific usage of parameters related to signature 2550 algorithms/keys. 2552 * Included general content previously in draft-ietf-ace-key- 2553 groupcomm-oscore 2555 * Registration of media type and content format application/ace- 2556 group+cbor 2558 * Editorial improvements. 2560 B.3. Version -02 to -03 2562 * Exchange of information on the countersignature algorithm and 2563 related parameters, during the Token POST (Section 3.3). 2565 * Restructured KDC interface, with new possible operations 2566 (Section 4). 2568 * Client PoP signature for the Joining Request upon joining 2569 (Section 4.1.2.1). 2571 * Revised text on group member removal (Section 5). 2573 * Added more profile requirements (Appendix A). 2575 B.4. Version -01 to -02 2577 * Editorial fixes. 2579 * Distinction between transport profile and application profile 2580 (Section 1.1). 2582 * New parameters 'sign_info' and 'pub_key_enc' to negotiate 2583 parameter values for signature algorithm and signature keys 2584 (Section 3.3). 2586 * New parameter 'type' to distinguish different Key Distribution 2587 Request messages (Section 4.1). 2589 * New parameter 'client_cred_verify' in the Key Distribution Request 2590 to convey a Client signature (Section 4.1). 2592 * Encoding of 'pub_keys_repos' (Section 4.1). 2594 * Encoding of 'mgt_key_material' (Section 4.1). 2596 * Improved description on retrieval of new or updated keying 2597 material (Section 6). 2599 * Encoding of 'get_pub_keys' in Public Key Request (Section 7.1). 2601 * Extended security considerations (Sections 10.1 and 10.2). 2603 * New "ACE Public Key Encoding" IANA Registry (Section 11.2). 2605 * New "ACE Groupcomm Parameters" IANA Registry (Section 11.3), 2606 populated with the entries in Section 8. 2608 * New "Ace Groupcomm Request Type" IANA Registry (Section 11.4), 2609 populated with the values in Section 9. 2611 * New "ACE Groupcomm Policy" IANA Registry (Section 11.7) populated 2612 with two entries "Sequence Number Synchronization Method" and "Key 2613 Update Check Interval" (Section 4.2). 2615 * Improved list of requirements for application profiles 2616 (Appendix A). 2618 B.5. Version -00 to -01 2620 * Changed name of 'req_aud' to 'audience' in the Authorization 2621 Request (Section 3.1). 2623 * Defined error handling on the KDC (Sections 4.2 and 6.2). 2625 * Updated format of the Key Distribution Response as a whole 2626 (Section 4.2). 2628 * Generalized format of 'pub_keys' in the Key Distribution Response 2629 (Section 4.2). 2631 * Defined format for the message to request leaving the group 2632 (Section 5.2). 2634 * Renewal of individual keying material and methods for group 2635 rekeying initiated by the KDC (Section 6). 2637 * CBOR type for node identifiers in 'get_pub_keys' (Section 7.1). 2639 * Added section on parameter identifiers and their CBOR keys 2640 (Section 8). 2642 * Added request types for requests to a Join Response (Section 9). 2644 * Extended security considerations (Section 10). 2646 * New IANA registries "ACE Groupcomm Key Registry", "ACE Groupcomm 2647 Profile Registry", "ACE Groupcomm Policy Registry" and "Sequence 2648 Number Synchronization Method Registry" (Section 11). 2650 * Added appendix about requirements for application profiles of ACE 2651 on group communication (Appendix A). 2653 Acknowledgments 2655 The following individuals were helpful in shaping this document: 2656 Carsten Bormann, Rikard Hoeglund, Ben Kaduk, John Mattsson, Daniel 2657 Migault, Jim Schaad, Ludwig Seitz, Goeran Selander and Peter van der 2658 Stok. 2660 The work on this document has been partly supported by VINNOVA and 2661 the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact 2662 Initiative ACTIVE. 2664 Authors' Addresses 2665 Francesca Palombini 2666 Ericsson AB 2667 Torshamnsgatan 23 2668 SE-16440 Stockholm Kista 2669 Sweden 2671 Email: francesca.palombini@ericsson.com 2673 Marco Tiloca 2674 RISE AB 2675 Isafjordsgatan 22 2676 SE-16440 Stockholm Kista 2677 Sweden 2679 Email: marco.tiloca@ri.se