idnits 2.17.1 draft-ietf-ace-key-groupcomm-09.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 (September 4, 2020) is 1331 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-12 -- 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-06 == 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-01 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group F. Palombini 3 Internet-Draft Ericsson AB 4 Intended status: Standards Track M. Tiloca 5 Expires: March 8, 2021 RISE AB 6 September 4, 2020 8 Key Provisioning for Group Communication using ACE 9 draft-ietf-ace-key-groupcomm-09 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 March 8, 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 . . . . . . . . . . . . . . . . . . 8 62 3.2. Authorization Response . . . . . . . . . . . . . . . . . 10 63 3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 11 64 4. Keying Material Provisioning and Group Membership 65 Management . . . . . . . . . . . . . . . . . . . . . . . 15 66 4.1. Interface at the KDC . . . . . . . . . . . . . . . . . . 16 67 4.2. Retrieval of Group Names and URIs . . . . . . . . . . . . 33 68 4.3. Joining Exchange . . . . . . . . . . . . . . . . . . . . 33 69 4.4. Retrieval of Updated Keying Material . . . . . . . . . . 35 70 4.5. Requesting a Change of Keying Material . . . . . . . . . 37 71 4.6. Retrieval of Public Keys and Roles for Group Members . . 37 72 4.7. Update of Public Key . . . . . . . . . . . . . . . . . . 38 73 4.8. Retrieval of Group Policies . . . . . . . . . . . . . . . 39 74 4.9. Retrieval of Keying Material Version . . . . . . . . . . 39 75 4.10. Group Leaving Request . . . . . . . . . . . . . . . . . . 40 76 5. Removal of a Node from the Group . . . . . . . . . . . . . . 40 77 6. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 41 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 42 79 7.1. Update of Keying Material . . . . . . . . . . . . . . . . 43 80 7.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 44 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 82 8.1. Media Type Registrations . . . . . . . . . . . . . . . . 45 83 8.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 46 84 8.3. OAuth Parameters Registry . . . . . . . . . . . . . . . . 46 85 8.4. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 46 86 8.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 47 87 8.6. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 47 88 8.7. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 48 89 8.8. ACE Groupcomm Policy Registry . . . . . . . . . . . . . . 49 90 8.9. Sequence Number Synchronization Method Registry . . . . . 49 91 8.10. Interface Description (if=) Link Target Attribute Values 92 Registry . . . . . . . . . . . . . . . . . . . . . . . . 50 93 8.11. Expert Review Instructions . . . . . . . . . . . . . . . 50 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 95 9.1. Normative References . . . . . . . . . . . . . . . . . . 51 96 9.2. Informative References . . . . . . . . . . . . . . . . . 53 98 Appendix A. Requirements on Application Profiles . . . . . . . . 55 99 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 57 100 B.1. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 57 101 B.2. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 58 102 B.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 58 103 B.4. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 59 104 B.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 59 105 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 60 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 108 1. Introduction 110 This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to 111 define the message exchanges used to request, distribute and renew 112 the keying material in a group communication scenario, e.g. based on 113 multicast [I-D.ietf-core-groupcomm-bis] or on publishing-subscribing 114 [I-D.ietf-core-coap-pubsub]. The ACE framework is based on CBOR 115 [RFC7049], so CBOR is the format used in this specification. 116 However, using JSON [RFC8259] instead of CBOR is possible, using the 117 conversion method specified in Sections 4.1 and 4.2 of [RFC7049]. 119 Profiles that use group communication can build on this document, by 120 defining a number of details such as the exact group communication 121 protocol and security protocols used. The specific list of details a 122 profile needs to define is shown in Appendix A. 124 If the application requires backward and forward security, new keying 125 material is generated and distributed to the group upon membership 126 changes. A key management scheme performs the actual distribution of 127 the new keying material to the group. In particular, the key 128 management scheme rekeys the current group members when a new node 129 joins the group, and the remaining group members when a node leaves 130 the group. Rekeying mechanisms can be based on [RFC2093], [RFC2094] 131 and [RFC2627]. 133 1.1. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in BCP 138 14 [RFC2119] [RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 Readers are expected to be familiar with the terms and concepts 142 described in [I-D.ietf-ace-oauth-authz][I-D.ietf-cose-rfc8152bis-stru 143 ct][I-D.ietf-cose-rfc8152bis-algs], such as Authorization Server (AS) 144 and Resource Server (RS). 146 This document uses names or identifiers for groups and nodes. Their 147 different meanings are summarized here: 149 * "Group name" is the invariant once established identifier of the 150 group. It is used in the communication between AS, RS and Client 151 to identify the group. 153 * "GROUPNAME" is the invariant once established text string used in 154 URIs. GROUPNAME maps to the group name of a group, although it is 155 not necessarily the same. 157 * "Group identifier" is the identifier of the group keying material. 158 Opposite to group name and GROUPNAME, this identifier changes over 159 time, when the keying material is updated. 161 * "NODENAME" is the invariant once established text string used in 162 URIs. NODENAME is used to identify a node in a group. 164 This document additionally uses the following terminology: 166 * Transport profile, to indicate a profile of ACE as per 167 Section 5.6.4.3 of [I-D.ietf-ace-oauth-authz]. A transport 168 profile specifies the communication protocol and communication 169 security protocol between an ACE Client and Resource Server, as 170 well as proof-of-possession methods, if it supports proof-of- 171 possession access tokens, etc. Tranport profiles of ACE include, 172 for instance, [I-D.ietf-ace-oscore-profile], 173 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-mqtt-tls-profile]. 175 * Application profile, that defines how applications enforce and use 176 supporting security services they require. These services may 177 include, for instance, provisioning, revocation and distribution 178 of keying material. An application profile may define specific 179 procedures and message formats. 181 2. Overview 183 The full procedure can be separated in two phases: the first follows 184 the ACE framework, between Client, AS and KDC. The second part is 185 the key distribution between Client and KDC. After the two phases 186 the Client is able to participate in the group communication, via a 187 Dispatcher entity. 189 +------------+ +-----------+ 190 | AS | | KDC | 191 | | .-------->| | 192 +------------+ / +-----------+ 193 ^ / 194 | / 195 v / +-----------+ 196 +------------+ / +------------+ |+-----------+ 197 | Client |<-' | Dispatcher | ||+-----------+ 198 | |<-------->| |<------->|| Group | 199 +------------+ +------------+ +| members | 200 +-----------+ 202 Figure 1: Key Distribution Participants 204 The following participants (see Figure 1) take part in the 205 authorization and key distribution. 207 * Client (C): node that wants to join the group communication. It 208 can request write and/or read rights. 210 * Authorization Server (AS): same as AS in the ACE Framework; it 211 enforces access policies, and knows if a node is allowed to join a 212 given group with write and/or read rights. 214 * Key Distribution Center (KDC): maintains the keying material to 215 protect group communications, and provides it to Clients 216 authorized to join a given group. During the first part of the 217 exchange (Section 3), it takes the role of the RS in the ACE 218 Framework. During the second part (Section 4), which is not based 219 on the ACE Framework, it distributes the keying material. In 220 addition, it provides the latest keying material to group members 221 when requested or, if required by the application, when membership 222 changes. 224 * Dispatcher: entity through which the Clients communicate with the 225 group and which distributes messages to the group members. 226 Examples of dispatchers are: the Broker node in a pub-sub setting; 227 a relayer node for group communication that delivers group 228 messages as multiple unicast messages to all group members; an 229 implicit entity as in a multicast communication setting, where 230 messages are transmitted to a multicast IP address and delivered 231 on the transport channel. 233 This document specifies a mechanism for: 235 * Authorizing a new node to join the group (Section 3), and 236 providing it with the group keying material to communicate with 237 the other group members (Section 4). 239 * Allowing a group member to leave the group (Section 5). 241 * Evicting a group member from the group (Section 5). 243 * Allowing a group member to retrieve keying material (Section 4.4 244 and Section 4.5). 246 * Renewing and re-distributing the group keying material (rekeying) 247 upon a membership change in the group (Section 4.10 and 248 Section 5). 250 Figure 2 provides a high level overview of the message flow for a 251 node joining a group communication setting, which can be expanded as 252 follows. 254 1. The joining node requests an Access Token from the AS, in order 255 to access a specific group-membership resource on the KDC and 256 hence join the associated group. This exchange between Client 257 and AS MUST be secured, as specified by the transport profile of 258 ACE used between Client and KDC. The joining node will start or 259 continue using a secure communication association with the KDC, 260 according to the response from the AS. 262 2. The joining node transfers authentication and authorization 263 information to the KDC, by posting the obtained Access Token to 264 the /authz-info endpoint at the KDC. This exchange, and all 265 further communications between the Client and the KDC, MUST occur 266 over the secure channel established as a result of the transport 267 profile of ACE used between Client and KDC. After that, a 268 joining node MUST have a secure communication association 269 established with the KDC, before starting to join a group under 270 that KDC. Possible ways to provide a secure communication 271 association are described in the DTLS transport profile 272 [I-D.ietf-ace-dtls-authorize] and OSCORE transport profile 273 [I-D.ietf-ace-oscore-profile] of ACE. 275 3. The joining node starts the joining process to become a member of 276 the group, by accessing the related group-membership resource at 277 the KDC. At the end of the joining process, the joining node has 278 received from the KDC the parameters and keying material to 279 securely communicate with the other members of the group, and the 280 KDC has stored the association between the authorization 281 information from the access token and the secure session with the 282 client. 284 4. The joining node and the KDC maintain the secure association, to 285 support possible future communications. These especially include 286 key management operations, such as retrieval of updated keying 287 material or participation to a group rekeying process. 289 5. The joining node can communicate securely with the other group 290 members, using the keying material provided in step 3. 292 C AS KDC Group 293 | | | Member 294 / | | | | 295 | | Authorization Request | | | 296 Defined | |-------------------------->| | | 297 in the | | | | | 298 ACE | | Authorization Response | | | 299 framework | |<--------------------------| | | 300 | | | | 301 \ |---------- Token Post --------->| | 302 | | | 303 |------- Joining Request ------->| | 304 | | | 305 |<------ Joining Response -------|-- Group Rekeying -->| 306 | | | 307 | Dispatcher | 308 | | | 309 |<===== Secure group communication =======|===========>| 310 | | | 312 Figure 2: Message Flow Upon New Node's Joining 314 3. Authorization to Join a Group 316 This section describes in detail the format of messages exchanged by 317 the participants when a node requests access to a given group. This 318 exchange is based on ACE [I-D.ietf-ace-oauth-authz]. 320 As defined in [I-D.ietf-ace-oauth-authz], the Client requests from 321 the AS an authorization to join the group through the KDC (see 322 Section 3.1). If the request is approved and authorization is 323 granted, the AS provides the Client with a proof-of-possession access 324 token and parameters to securely communicate with the KDC (see 325 Section 3.2). 327 Communications between the Client and the AS MUST be secured, as 328 defined by the transport profile of ACE used. The Content-Format 329 used in the message depends on the used transport profile of ACE. 330 For example, this can be application/ace+cbor for the first two 331 messages and application/cwt for the third message, which are defined 332 in the ACE framework. The transport profile of ACE also defines a 333 number of details such as the communication and security protocols 334 used with the KDC (see Appendix C of [I-D.ietf-ace-oauth-authz]). 336 Figure 3 gives an overview of the exchange described above. 338 Client AS KDC 339 | | | 340 |---- Authorization Request: POST /token ------>| | 341 | | | 342 |<--- Authorization Response: 2.01 (Created) ---| | 343 | | | 344 |----- POST Token: POST /authz-info --------------->| 345 | | 347 Figure 3: Message Flow of Join Authorization 349 3.1. Authorization Request 351 The Authorization Request sent from the Client to the AS is defined 352 in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MAY contain the 353 following parameters, which, if included, MUST have the corresponding 354 values: 356 * 'scope', containing the identifier of the specific group(s), or 357 topic(s) in the case of pub-sub, that the Client wishes to access, 358 and optionally the role(s) that the Client wishes to take. 360 This value is a CBOR byte string, encoding a CBOR array of one or 361 more entries. 363 By default, each entry is encoded as specified by 364 [I-D.bormann-core-ace-aif]. The object identifier Toid 365 corresponds to the group name and MUST be encoded as a tstr. The 366 permission set Tperm indicates the roles that the client wishes to 367 take in the group. It is up to the application profiles to define 368 Tperm (REQ2) and register Toid and Tperm to fit the use case. An 369 example of scope using the AIF format is given in Figure 5. 371 Otherwise, each scope entry can be defined as a CBOR array, which 372 contains: 374 - As first element, the identifier of the specific group or 375 topic, encoded as a tstr. 377 - Optionally, as second element, the role (or CBOR array of 378 roles) that the Client wishes to take in the group. This 379 element is optional since roles may have been pre-assigned to 380 the Client, as associated to its verifiable identity 381 credentials. Alternatively, the application may have defined a 382 single, well-known role for the target resource(s) and 383 audience(s). 385 In each entry, the encoding of the role identifiers is application 386 specific, and part of the requirements for the application profile 387 (REQ2). In particular, the application profile may specify CBOR 388 values to use for abbreviating role identifiers (OPT7). 390 An example of CDDL definition [RFC8610] of scope using the format 391 above, with group name and role identifiers encoded as text 392 strings is given in Figure 4. 394 * 'audience', with an identifier of a KDC. 396 * 'req_cnf', as defined in Section 3.1 of 397 [I-D.ietf-ace-oauth-params], optionally containing the public key 398 or a reference to the public key of the Client, if it wishes to 399 communicate that to the AS. 401 Other additional parameters as defined in [I-D.ietf-ace-oauth-authz], 402 can be included if necessary. 404 As in [I-D.ietf-ace-oauth-authz], these parameters are included in 405 the payload, which is formatted as a CBOR map. The Content-Format 406 "application/ace+cbor" defined in Section 8.14 of 407 [I-D.ietf-ace-oauth-authz] is used. 409 gname = tstr 411 role = tstr 413 scope_entry = [ gname , ? ( role / [ 2*role ] ) ] 415 scope = << [ + scope_entry ] >> 417 Figure 4: CDLL definition of scope, using as example group name 418 encoded as tstr and role as tstr 420 gname = tstr 422 permissions = uint . bits roles 424 roles = &( 425 Requester: 1, 426 Responder: 2, 427 Monitor: 3, 428 Verifier: 4 429 ) 431 scope_entry = AIF_Generic 433 scope = << [ + scope_entry ] >> 435 Figure 5: Example CDLL definition of scope, using the default 436 Authorization Information Format 438 3.2. Authorization Response 440 The Authorization Response sent from the AS to the Client is defined 441 in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST contain the 442 following parameters: 444 * 'access_token', containing the proof-of-possession access token. 446 * 'cnf' if symmetric keys are used, not present if asymmetric keys 447 are used. This parameter is defined in Section 3.2 of 448 [I-D.ietf-ace-oauth-params] and contains the symmetric proof-of- 449 possession key that the Client is supposed to use with the KDC. 451 * 'rs_cnf' if asymmetric keys are used, not present if symmetric 452 keys are used. This parameter is defined in Section 3.2 of 453 [I-D.ietf-ace-oauth-params] and contains information about the 454 public key of the KDC. 456 * 'expires_in', contains the lifetime in seconds of the access 457 token. This parameter MAY be omitted if the application defines 458 how the expiration time is communicated to the Client via other 459 means, or if it establishes a default value. 461 Additionally, the Authorization Response MAY contain the following 462 parameters, which, if included, MUST have the corresponding values: 464 * 'scope' containing the scope the AS grants access to. This 465 parameter has the same format and encoding of 'scope' in the 466 Authorization Request, defined in Section 3.1. If this parameter 467 is not present the granted scope is equal to the one requested in 468 Section 3.1}. 470 Other additional parameters as defined in [I-D.ietf-ace-oauth-authz], 471 if necessary. 473 The proof-of-possession access token (in 'access_token' above) MUST 474 contain the following parameters: 476 * a confirmation claim (see for example 'cnf' defined in Section 3.1 477 of [RFC8747] for CWT); 479 * an expiration time claim (see for example 'exp' defined in 480 Section 3.1.4 of [RFC8392] for CWT); 482 * a scope claim (see for example 'scope' registered in Section 8.13 483 of [I-D.ietf-ace-oauth-authz] for CWT). This claim has the same 484 encoding as 'scope' parameter above. Additionally, this claim has 485 the same value of the 'scope' parameter if the parameter is 486 present in the message, or it takes the value of 'scope' in the 487 Authorization Request otherwise. 489 The access token MAY additionally contain other claims that the 490 transport profile of ACE requires, or other optional parameters. 492 As in [I-D.ietf-ace-oauth-authz], these parameters are included in 493 the payload, which is formatted as a CBOR map. The Content-Format 494 "application/ace+cbor" is used. 496 When receiving an Authorization Request from a Client that was 497 previously authorized, and for which the AS still owns a valid non- 498 expired access token, the AS MAY reply with that token. Note that it 499 is up to application profiles of ACE to make sure that re-posting the 500 same token does not cause re-use of keying material between nodes 501 (for example, that is done with the use of random nonces in 502 [I-D.ietf-ace-oscore-profile]). 504 3.3. Token Post 506 The Client sends a CoAP POST request including the access token to 507 the KDC, as specified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. 508 If the specific transport profile of ACE defines it, the Client MAY 509 use a different endpoint than /authz-info at the KDC to post the 510 access token to. 512 Optionally, the Client might want to request encoding information 513 about the public keys in the group, used for source authentication, 514 as well as any other group parameters. The joining node MAY ask for 515 this information from the KDC in the same message it uses to POST the 516 token to the RS. 518 The payload of the message MUST be formatted as a CBOR map including 519 the access token. 521 Additionally, the CoAP POST request MAY contain the following 522 parameter, which, if included, MUST have the corresponding values: 524 * 'sign_info' defined in Section 3.3.1, encoding the CBOR simple 525 value Null to require information about the signature algorithm, 526 signature algorithm parameters, signature key parameters and on 527 the exact encoding of public keys used in the group. 529 Alternatively, the joining node may retrieve this information by 530 other means. 532 After successful verification, the Client is authorized to receive 533 the group keying material from the KDC and join the group. 535 The KDC replies to the Client with a 2.01 (Created) response, using 536 Content-Format "application/ace+cbor" defined in Section 8.14 of 537 [I-D.ietf-ace-oauth-authz]. 539 The payload of the 2.01 response is a CBOR map. If the access token 540 contains a role that requires the Client to send its own public key 541 to the KDC when joining the group, the CBOR map MUST include the 542 parameter 'kdcchallenge' defined in Section Section 3.3.2, specifying 543 a dedicated challenge N_S generated by the KDC. The Client uses this 544 challenge to prove possession of its own private key (see the 545 'client_cred_verify' parameter in Section 4). Note that the payload 546 format of the response deviates from the one defined in the ACE 547 framework (see Section 5.8.1 of [I-D.ietf-ace-oauth-authz]), which 548 has no payload. 550 The KDC MUST store the 'kdcchallenge' value associated to the Client 551 at least until it receives a join request from it (see Section 4.3), 552 to be able to verify the proof of possession. The same challenge MAY 553 be reused several times by the Client, to generate new proof of 554 possessions, e.g. in case of update of the public key, or to join a 555 different group with a different signing key, so it is RECOMMENDED 556 that the KDC keeps storing the 'kdcchallenge' after the first join is 557 processed as well. If the KDC has already discarded the 558 'kdcchallenge', that will trigger an error response with a newly 559 generated 'kdcchallenge' that the client can use to restart the join 560 process, as specified in Section 4.3. 562 If 'sign_info' is included in the request, the KDC MAY include the 563 'sign_info' parameter defined in Section 3.3.1, with the same 564 encoding. Note that the field 'id' takes the value of the group name 565 for which the 'sign_info_entry' applies to. 567 Note that the CBOR map specified as payload of the 2.01 (Created) 568 response may include further parameters, e.g. according to the 569 signalled transport profile of ACE. 571 Application profiles of this specification MAY define alternative 572 specific negotiations of parameter values for signature algorithm and 573 signature keys, if 'sign_info' is not used (OPT2). 575 3.3.1. 'sign_info' Parameter 577 The 'sign_info' parameter is an OPTIONAL parameter of the Token Post 578 response message defined in Section 5.1.2. of 579 [I-D.ietf-ace-oauth-authz]. This parameter contains information and 580 parameters about the signature algorithm and the public keys to be 581 used between the Client and the RS. Its exact content is application 582 specific. 584 In this specification and in application profiles building on it, 585 this parameter is used to ask and retrieve from the KDC information 586 about the signature algorithm and related parameters used in the 587 group. 589 When used in the request, the 'sign_info' encodes the CBOR simple 590 value Null, to require information and parameters on the signature 591 algorithm and on the public keys used. 593 The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as 594 in the request is given below. 596 sign_info_req = nil 598 The 'sign_info' parameter of the 2.01 (Created) response is a CBOR 599 array of one or more elements. The number of elements is at most the 600 number of groups the client has been authorized to join. Each 601 element contains information about signing parameters and keys for 602 one or more group or topic and is formatted as follows. 604 * The first element 'id' is an identifier of the group or an array 605 of identifiers for the groups for which this information applies. 607 * The second element 'sign_alg' is an integer or a text string if 608 the POST request included the 'sign_info' parameter with value 609 Null, and indicates the signature algorithm used in the group 610 identified by 'gname'. It is REQUIRED of the application profiles 611 to define specific values that this parameter can take (REQ3), 612 selected from the set of signing algorithms of the COSE Algorithms 613 registry [COSE.Algorithms]. 615 * The third element 'sign_parameters' is a CBOR array indicating the 616 parameters of the signature algorithm. Its content depends on the 617 value of 'sign_alg'. It is REQUIRED of the application profiles 618 to define the possible values and structure for the elements of 619 this parameter (REQ4). 621 * The fourth element 'sign_key_parameters' is a CBOR array 622 indicating the parameters of the key used with the signature 623 algorithm. Its content depends on the value of 'sign_alg'. It is 624 REQUIRED of the application profiles to define the possible values 625 and structure for the elements of this parameter (REQ5). 627 * The fifth element 'pub_key_enc' parameter is either a CBOR integer 628 indicating the encoding of public keys used in the group 629 identified by 'gname', or has value Null indicating that the KDC 630 does not act as repository of public keys for group members. Its 631 acceptable values are taken from the "CWT Confirmation Method" 632 Registry defined in [RFC8747]. It is REQUIRED of the application 633 profiles to define specific values to use for this parameter 634 (REQ6). 636 The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as 637 in the response is given below. 639 sign_info_res = [ + sign_info_entry ] 641 sign_info_entry = 642 [ 643 id : gname / [ + gname ], 644 sign_alg : int / tstr, 645 sign_parameters : [ any ], 646 sign_key_parameters : [ any ], 647 pub_key_enc = int / nil 648 ] 650 gname = tstr 652 3.3.2. 'kdcchallenge' Parameter 654 The 'kdcchallenge' parameter is an OPTIONAL parameter of the Token 655 Post response message defined in Section 5.1.2. of 656 [I-D.ietf-ace-oauth-authz]. This parameter contains a challenge 657 generated by the KDC and provided to the Client. The Client may use 658 this challenge to prove possession of its own private key in the 659 Joining Request (see the 'client_cred_verify' parameter in 660 Section 4). 662 4. Keying Material Provisioning and Group Membership Management 664 This section defines the interface available at the KDC. Moreover, 665 this section specifies how the clients can use this interface to join 666 a group, leave a group, retrieve the group policies or the new keying 667 material. 669 During the first exchange with the KDC ("Joining") after posting the 670 Token, the Client sends a request to the KDC, specifying the group it 671 wishes to join (see Section 4.3). Then, the KDC verifies the access 672 token and that the Client is authorized to join that group. If so, 673 it provides the Client with the keying material to securely 674 communicate with the other members of the group. Whenever used, the 675 Content-Format in messages containing a payload is set to 676 application/ace-groupcomm+cbor, as defined in Section 8.2. 678 When the Client is already a group member, the Client can use the 679 interface at the KDC to perform the following actions: 681 * The Client can get the current keying material, for cases such as 682 expiration, loss or suspected mismatch, due to e.g. reboot or 683 missed group rekeying. This is described in Section 4.4. 685 * The Client can retrieve new keying material for itself. This is 686 described in Section 4.5. 688 * The Client can get the public keys of other group members. This 689 is described in Section 4.6. 691 * The Client can get the group policies. This is described in 692 Section 4.8. 694 * The Client can get the version number of the keying material 695 currently used in the group. This is described in Section 4.9. 697 * The Client can request to leave the group. This is further 698 discussed in Section 4.10. 700 Upon receiving a request from a Client, the KDC MUST check that it is 701 storing a valid access token from that Client for the group name 702 associated to the endpoint. If that is not the case, i.e. the KDC 703 does not store a valid access token or this is not valid for that 704 Client for the group name, the KDC MUST respond to the Client with a 705 4.01 (Unauthorized) error message. 707 4.1. Interface at the KDC 709 The KDC is configured with the following resources. Note that the 710 root url-path "ace-group" given here are default names: 711 implementations are not required to use these names, and can define 712 their own instead. Each application profile of this specification 713 MUST register a Resource Type for the root url-path (REQ7a), and that 714 Resource Type can be used to discover the correct url to access at 715 the KDC. This Resource Type can also be used at the GROUPNAME sub- 716 resource, to indicate different application profiles for different 717 groups. The Interface Description (if=) Link Target Attribute value 718 ace.group is registered (Section 8.10) and can be used to describe 719 this interface. 721 * /ace-group: this resource is invariant once established and 722 indicates that this specification is used. If other applications 723 run on a KDC implementing this specification and use this same 724 resource, these applications will collide, and a mechanism will be 725 needed to differentiate the endpoints. This resource supports 726 FETCH method. 728 * /ace-group/GROUPNAME: one sub-resource to /ace-group is 729 implemented for each group the KDC manages. If the value of the 730 GROUPNAME URI path and the group name in the access token scope 731 (gname in Section 3.2) don't match, the KDC MUST implement a 732 mechanism to map the GROUPNAME value in the URI to the group name, 733 to retrieve the right group (REQ1). Each resource contains the 734 symmetric group keying material for that group. These resources 735 support GET and POST method. 737 * /ace-group/GROUPNAME/pub-key: this resource is invariant once 738 established and contains the public keys of all group members. 739 This resource supports GET and FETCH methods. 741 * /ace-group/GROUPNAME/policies: this resource is invariant once 742 established and contains the group policies. This resource 743 supports the GET method. 745 * /ace-group/GROUPNAME/num: this resource is invariant once 746 established and contains the version number for the symmetric 747 group keying material. This sub-resource supports the GET method. 749 * /ace-group/GROUPNAME/nodes/NODENAME: one sub-resource to /ace- 750 group/GROUPNAME is implemented for each node in the group the KDC 751 manages. These resources are identified by the node name (in this 752 example, the node name has value "NODENAME"). Each resource 753 contains the group and individual keying material for that node. 754 These resources support GET, PUT and DELETE methods. 756 * /ace-group/GROUPNAME/nodes/NODENAME/pub-key: one sub-resource to 757 /ace-group/GROUPNAME/nodes/NODENAME is implemented for each node 758 in the group the KDC manages. These resources are identified by 759 the node name (in this example, the node name has value 760 "NODENAME"). Each resource contains the individual public keying 761 material for that node. These resources support the POST method. 763 The details for the handlers of each resource are given in the 764 following sections. These endpoints are used to perform the 765 operations introduced in Section 4. 767 4.1.1. ace-group 769 This resource implements a FETCH handler. 771 4.1.1.1. FETCH Handler 773 The FETCH handler receives group identifiers and returns the 774 corresponding group names and GROUPNAME URIs. 776 The handler expects a request with payload formatted as a CBOR map. 777 The payload of this request is a CBOR Map that MUST contain the 778 following fields: 780 * 'gid', whose value is encoded as a CBOR array, containing one or 781 more group identifiers. The exact encoding of group identifier 782 MUST be specified by the application profile (REQ7b). The Client 783 indicates that it wishes to receive the group names and GROUPNAMEs 784 of all groups having these identifiers. 786 The handler identifies the groups that are secured by the keying 787 material identified by those group identifiers. 789 Then, the handler returns a 2.05 (Content) message response with 790 payload formatted as a CBOR map that MUST contain the following 791 fields: 793 * 'gid', whose value is encoded as a CBOR array, containing zero or 794 more group identifiers. The handler indicates that those are the 795 identifiers it is sending group names and GROUPNAMEs for. This 796 CBOR array is a subset of the 'gid' array in the FETCH request. 798 * 'gname', whose value is encoded as a CBOR array, containing zero 799 or more group names. The elements of this array are encoded as 800 text strings. Each element of index i of this CBOR array 801 corresponds to the element of group identifier i in the 'gid' 802 array. 804 * 'guri', whose value is encoded as a CBOR array, containing zero or 805 more URIs, each indicating a GROUPNAME resource. The elements of 806 this array are encoded as text strings. Each element of index i 807 of this CBOR array corresponds to the element of group identifier 808 i in the 'gid' array. 810 If the KDC does not find any group associated with the specified 811 group identifiers, the handler returns a response with payload 812 formatted as a CBOR byte string of zero length. 814 4.1.2. ace-group/GROUPNAME 816 This resource implements GET and POST handlers. 818 4.1.2.1. POST Handler 820 The POST handler adds the public key of the client to the list of the 821 group members' public keys and returns the symmetric group keying 822 material for the group identified by "GROUPNAME". Note that the 823 group joining exchange is done by the client via this operation, as 824 described in Section 4.3. 826 The handler expects a request with payload formatted as a CBOR map 827 which MAY contain the following fields, which, if included, MUST have 828 the corresponding values: 830 * 'scope', with value the specific resource at the KDC that the 831 Client is authorized to access, i.e. group or topic identifier, 832 and role(s). This value is a CBOR byte string encoding one scope 833 entry, as defined in Section 3.1. 835 * 'get_pub_keys', if the Client wishes to receive the public keys of 836 the other nodes in the group from the KDC. This parameter may be 837 present if the KDC stores the public keys of the nodes in the 838 group and distributes them to the Client; it is useless to have 839 here if the set of public keys of the members of the group is 840 known in another way, e.g. it was provided by the AS. Note that 841 including this parameter may result in a large message size for 842 the following response, which can be inconvenient for resource- 843 constrained devices. The parameter's value is a non-empty CBOR 844 array containing two CBOR arrays: 846 - The first array contains zero or more roles (or combination of 847 roles) of group members for the group identified by 848 "GROUPNAME". The Client indicates that it wishes to receive 849 the public keys of all nodes having these roles. If empty, it 850 means the client wishes to receive the public keys of all 851 nodes. 853 - The second array is empty. 855 The CDDL definition [RFC8610] of 'get_pub_keys' is given in 856 Figure 6 using as example encoding: node identifier encoded as 857 byte string, role identifier as text string, and combination of 858 roles encoded as a CBOR array of roles. Note that the array ids 859 is empty for this handler, but is not necessarily empty for the 860 value of "get_pub_keys" received by the handler of FETCH to ace- 861 group/GROUPNAME/pub-key (see Section 4.1.3.1). 863 id = bstr 865 role = tstr 867 comb_role = [ 2*role ] 869 get_pub_keys = [ [ *(role / comb_role) ], [ *id ] ] 871 Figure 6: CDLL definition of get_pub_keys, using as example node 872 identifier encoded as bstr and role as tstr 874 * 'client_cred', with value the public key or certificate of the 875 Client, encoded as a CBOR byte string. This field contains the 876 public key of the Client. This field is used if the KDC is 877 managing (collecting from/distributing to the Client) the public 878 keys of the group members, and if the Client's role in the group 879 will require for it to send messages to one or more group members. 880 The default encoding for public keys is COSE Keys. Alternative 881 specific encodings of this parameter MAY be defined in 882 applications of this specification (OPT1 in Appendix A). 884 * 'cnonce', encoded as a CBOR byte string, and including a dedicated 885 nonce N_C generated by the Client. This parameter MUST be present 886 if the 'client_cred' parameter is present. 888 * 'client_cred_verify', encoded as a CBOR byte string. This 889 parameter MUST be present if the 'client_cred' parameter is 890 present and no public key associated to the client's token can be 891 retrieved for that group. This parameter contains a signature 892 computed by the Client over the scope concatenated with N_S 893 concatenated with N_C, where: 895 - scope is the byte string specified in the 'scope parameter 896 above'. 898 - N_S is the challenge received from the KDC in the 899 'kdcchallenge' parameter of the 2.01 (Created) response to the 900 token POST request (see Section 3.3). 902 - N_C is the nonce generated by the Client and specified in the 903 'cnonce' parameter above. 905 If the token was not posted (e.g. if it is used directly to 906 validate TLS instead), it is REQUIRED of the specific profile to 907 define how the challenge N_S is generated (REQ17). The Client 908 computes the signature by using its own private key, whose 909 corresponding public key is either directly specified in the 910 'client_cred' parameter or included in the certificate specified 911 in the 'client_cred' parameter. 913 * 'pub_keys_repos', can be present if a certificate is present in 914 the 'client_cred' field, with value the URI of the certificate of 915 the Client. This parameter is encoded as a CBOR text string. 916 Alternative specific encodings of this parameter MAY be defined in 917 applications of this specification (OPT3). 919 * 'control_path', with value a full URI, encoded as a CBOR text 920 string. If 'control_path' is supported by the Client, the Client 921 acts as a CoAP server and hosts a resource at this specific URI. 922 The KDC MAY use this URI to send CoAP requests to the Client 923 (acting as CoAP server in this exchange), for example for 924 individual provisioning of new keying material when performing a 925 group rekeying (see Section 4.4), or to inform the Client of its 926 removal from the group Section 5. If the KDC does not implement 927 mechanisms using this resource, it can just ignore this parameter. 928 Other additional functionalities of this resource MAY be defined 929 in application profiles of this specifications (OPT9). In 930 particular, this resource is intended for communications 931 concerning exclusively the group or topic specified in the 'scope' 932 parameter. 934 The handler extracts the granted scope from the access token, and 935 checks the requested one against the token one. If this join message 936 does not include a 'scope' field, the KDC is expected to understand 937 which group and role the Client is requesting (e.g. there is only one 938 the Client has been granted). If the KDC can not recognize which 939 scope the Client is requesting, it MUST respond with a 4.00 (Bad 940 Request) error message. 942 The handler verifies that the group name of the /ace-group/GROUPNAME 943 path is a subset of the 'scope' stored in the access token associated 944 to this client. If verification fails, the KDC MUST respond with a 945 4.01 (Unauthorized) error message. The KDC MAY respond with an AS 946 Request Creation Hints, as defined in Section 5.1.2 of 947 [I-D.ietf-ace-oauth-authz]. Note that in this case, the content 948 format MUST be set to application/ace+cbor. 950 If the request is not formatted correctly (i.e. required fields non 951 received or received with incorrect format), the handler MUST respond 952 with a 4.00 (Bad Request) error message. The response MAY contain a 953 CBOR map in the payload with ace+cbor format, e.g. it could send back 954 'sign_info_res' with 'pub_key_enc' set to Null if the Client sent its 955 own public key and the KDC is not set to store public keys of the 956 group members. If the request contained unknown or non-expected 957 fields present, the handler MUST silently drop them and continue 958 processing. Application profiles MAY define optional or mandatory 959 payload formats for specific error cases (OPT6). 961 If the KDC stores the group members' public keys, the handler checks 962 if one is included in the 'client_cred' field, retrieves it and 963 associates it to the access token received, after verifications 964 succeeded. In particular, the KDC verifies: 966 * that such public key has an acceptable format for the group 967 identified by "GROUPNAME", i.e. it is encoded as expected and is 968 compatible with the signature algorithm and possible associated 969 parameters. 971 * that the signature contained in "client_cred_verify" passes 972 verification. 974 If that cannot be verified, it is RECOMMENDED that the handler stops 975 the process and responds with a 4.00 (Bad Request) error message. 976 Applications profiles MAY define alternatives (OPT5). 978 If one public key is already associated to the access token and to 979 that group, but the 'client_cred' is populated with a different 980 public key, the handler MUST delete the previous one and replace it 981 with this one, after verifying the points above. 983 If no public key is included in the 'client_cred' field, the handler 984 checks if one public key is already associated to the access token 985 received (see Section 4.3 for an example) and to the group identified 986 by "GROUPNAME". If that is not the case, the handler responds with a 987 4.00 Bad Request error response. 989 If the token was posted but the KDC cannot retrieve the 990 'kdcchallenge' associated to this Client (see Section 3.3), the KDC 991 MUST respond with a 4.00 Bad Request error response, including a 992 newly generated 'kdcchallenge' in a CBOR map in the payload. This 993 error response MUST also have Content-Format "application/ace+cbor". 995 If all verifications succeed, the handler: 997 * Adds the node to the list of current members of the group. 999 * Assigns a name NODENAME to the node, and creates a sub-resource to 1000 /ace-group/GROUPNAME/ at the KDC (e.g. "/ace- 1001 group/GROUPNAME/nodes/NODENAME"). 1003 * Associates the identifier "NODENAME" with the access token and the 1004 secure session for that node. 1006 * If the KDC manages public keys for group members: 1008 - Adds the retrieved public key of the node to the list of public 1009 keys stored for the group identified by "GROUPNAME" 1011 - Associates the node's public key with its access token and the 1012 group identified by "GROUPNAME", if such association did not 1013 already exist. 1015 * Returns a 2.01 (Created) message containing the symmetric group 1016 keying material, the group policies and all the public keys of the 1017 current members of the group, if the KDC manages those and the 1018 Client requested them. 1020 The response message also contains the URI path to the sub-resource 1021 created for that node in a Location-Path CoAP option. The payload of 1022 the response is formatted as a CBOR map which MUST contain the 1023 following fields and values: 1025 * 'gkty', identifying the key type of the 'key' parameter. The set 1026 of values can be found in the "Key Type" column of the "ACE 1027 Groupcomm Key" Registry. Implementations MUST verify that the key 1028 type matches the application profile being used, if present, as 1029 registered in the "ACE Groupcomm Key" registry. 1031 * 'key', containing the keying material for the group communication, 1032 or information required to derive it. 1034 * 'num', containing the version number of the keying material for 1035 the group communication, formatted as an integer. This is a 1036 strictly monotonic increasing field. The application profile MUST 1037 define the initial version number (REQ19). 1039 The exact format of the 'key' value MUST be defined in applications 1040 of this specification (REQ7), as well as accepted values of 'gkty' by 1041 the application (REQ8). Additionally, documents specifying the key 1042 format MUST register it in the "ACE Groupcomm Key" registry defined 1043 in Section 8.6, including its name, type and application profile to 1044 be used with. 1046 +----------+----------------+---------+-------------------------+ 1047 | Name | Key Type Value | Profile | Description | 1048 +----------+----------------+---------+-------------------------+ 1049 | Reserved | 0 | | This value is reserved | 1050 +----------+----------------+---------+-------------------------+ 1052 Figure 7: Key Type Values 1054 The response SHOULD contain the following parameter: 1056 * 'exp', with value the expiration time of the keying material for 1057 the group communication, encoded as a CBOR unsigned integer. This 1058 field contains a numeric value representing the number of seconds 1059 from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, 1060 ignoring leap seconds, analogous to what specified for NumericDate 1061 in Section 2 of [RFC7519]. Group members MUST stop using the 1062 keying material to protect outgoing messages and retrieve new 1063 keying material at the time indicated in this field. 1065 Optionally, the response MAY contain the following parameters, which, 1066 if included, MUST have the corresponding values: 1068 * 'ace-groupcomm-profile', with value a CBOR integer that MUST be 1069 used to uniquely identify the application profile for group 1070 communication. Applications of this specification MUST register 1071 an application profile identifier and the related value for this 1072 parameter in the "ACE Groupcomm Profile" Registry (REQ12). 1074 * 'pub_keys', may only be present if 'get_pub_keys' was present in 1075 the request. This parameter is a CBOR byte string, which encodes 1076 the public keys of all the group members paired with the 1077 respective member identifiers. The default encoding for public 1078 keys is COSE Keys, so the default encoding for 'pub_keys' is a 1079 CBOR byte string wrapping a COSE_KeySet (see 1080 [I-D.ietf-cose-rfc8152bis-struct]), which contains the public keys 1081 of all the members of the group. In particular, each COSE Key in 1082 the COSE_KeySet includes the identifier of the corresponding group 1083 member as value of its 'kid' key parameter. Alternative specific 1084 encodings of this parameter MAY be defined in applications of this 1085 specification (OPT1). The specific format of the identifiers of 1086 group members MUST be specified in the application profile (REQ9). 1088 * 'peer_roles', MUST be present if 'pub_keys' is present. This 1089 parameter is a CBOR array of n elements, with n the number of 1090 members in the group (and number of public keys included in the 1091 'pub_keys' parameter). The i-th element of the array specifies 1092 the role (or CBOR array of roles) that the group member associated 1093 to the i-th public key in 'pub_keys' has in the group. In 1094 particular, each array element is encoded as the role element of a 1095 scope entry, as defined in Section 3.1. 1097 * 'group_policies', with value a CBOR map, whose entries specify how 1098 the group handles specific management aspects. These include, for 1099 instance, approaches to achieve synchronization of sequence 1100 numbers among group members. The elements of this field are 1101 registered in the "ACE Groupcomm Policy" Registry. This 1102 specification defines the three elements "Sequence Number 1103 Synchronization Method", "Key Update Check Interval" and 1104 "Expiration Delta", which are summarized in Figure 8. Application 1105 profiles that build on this document MUST specify the exact 1106 content format and default value of included map entries (REQ14). 1108 +--------------+-------+----------|--------------------|------------+ 1109 | Name | CBOR | CBOR | Description | Reference | 1110 | | label | type | | | 1111 |--------------+-------+----------|--------------------|------------| 1112 | Sequence | TBD1 | tstr/int | Method for a re- | [[this | 1113 | Number | | | cipient node to | document]] | 1114 | Synchroniza- | | | synchronize with | | 1115 | tion Method | | | sequence numbers | | 1116 | | | | of a sender node. | | 1117 | | | | Its value is taken | | 1118 | | | | from the 'Value' | | 1119 | | | | column of the | | 1120 | | | | Sequence Number | | 1121 | | | | Synchronization | | 1122 | | | | Method registry | | 1123 | | | | | | 1124 | Key Update | TBD2 | int | Polling interval | [[this | 1125 | Check | | | in seconds, to | document]] | 1126 | Interval | | | check for new | | 1127 | | | | keying material at | | 1128 | | | | the KDC | | 1129 | | | | | | 1130 | Expiration | TBD3 | uint | Number of seconds | [[this | 1131 | Delta | | | from 'exp' until | document]] | 1132 | | | | the specified UTC | | 1133 | | | | date/time after | | 1134 | | | | which group members| | 1135 | | | | MUST stop using the| | 1136 | | | | keying material to | | 1137 | | | | verify incoming | | 1138 | | | | messages. | | 1139 +--------------+-------+----------|--------------------|------------+ 1141 Figure 8: ACE Groupcomm Policies 1143 * 'mgt_key_material', encoded as a CBOR byte string and containing 1144 the administrative keying material to participate in the group 1145 rekeying performed by the KDC. The application profile MUST 1146 define if this field is used, and if used then MUST specify the 1147 exact format and content which depend on the specific rekeying 1148 scheme used in the group. If the usage of 'mgt_key_material' is 1149 indicated and its format defined for a specific key management 1150 scheme, that format must explicitly indicate the key management 1151 scheme itself. If a new rekeying scheme is defined to be used for 1152 an existing 'mgt_key_material' in an existing profile, then that 1153 profile will have to be updated accordingly, especially with 1154 respect to the usage of 'mgt_key_material' related format and 1155 content (REQ18). 1157 Specific application profiles that build on this document MUST 1158 specify the communication protocol that members of the group use to 1159 communicate with each other (REQ10) and how exactly the keying 1160 material is used to protect the group communication (REQ11). 1162 CBOR labels for these fields are defined in Section 6. 1164 4.1.2.2. GET Handler 1166 The GET handler returns the symmetric group keying material for the 1167 group identified by "GROUPNAME". 1169 The handler expects a GET request. 1171 The handler verifies that the group name of the /ace-group/GROUPNAME 1172 path is a subset of the 'scope' stored in the access token associated 1173 to this client. If verification fails, the KDC MUST respond with a 1174 4.01 (Unauthorized) error message. The KDC MAY respond with an AS 1175 Request Creation Hints, as defined in Section 5.1.2 of 1176 [I-D.ietf-ace-oauth-authz]. Note that in this case, the content 1177 format MUST be set to application/ace+cbor. 1179 Additionally, the handler verifies that the node is a current member 1180 of the group. If verification fails, the KDC MUST respond with a 1181 4.00 (Bad Request) error message. 1183 If verification succeeds, the handler returns a 2.05 (Content) 1184 message containing the symmetric group keying material. The payload 1185 of the response is formatted as a CBOR map which MUST contain the 1186 parameters 'gkty','key' and 'num' specified in Section 4.1.2.1. 1188 The payload MAY also include the parameters 'ace-groupcomm-profile', 1189 'exp', and 'mgt_key_material' parameters specified in 1190 Section 4.1.2.1. 1192 4.1.3. ace-group/GROUPNAME/pub-key 1194 If the KDC does not maintain public keys for the group, the handler 1195 for any request on this resource returns a 4.05 (Method Not Allowed) 1196 error message. If it does, the rest of this section applies. 1198 This resource implements GET and FETCH handlers. 1200 4.1.3.1. FETCH Handler 1202 The FETCH handler receives identifiers of group members for the group 1203 identified by "GROUPNAME" and returns the public keys of such group 1204 members. 1206 The handler expects a request with payload formatted as a CBOR map. 1207 The payload of this request is a CBOR Map that MUST contain the 1208 following fields: 1210 * 'get_pub_keys', whose value is encoded as in Section 4.1.2.1 with 1211 the following modification: 1213 - The second array contains zero or more identifiers of group 1214 members for the group identified by "GROUPNAME". The Client 1215 indicates that it wishes to receive the public keys of all 1216 nodes having these identifiers. 1218 The specific format of public keys as well as identifiers, roles and 1219 combination of roles of group members MUST be specified by the 1220 application profile (OPT1, REQ2, REQ9). 1222 The handler verifies that the group name of the /ace-group/GROUPNAME 1223 path is a subset of the 'scope' stored in the access token associated 1224 to this client. If verification fails, the KDC MUST respond with a 1225 4.01 (Unauthorized) error message. 1227 If verification succeeds, the handler identifies the public keys of 1228 the current group members for which either: 1230 * the role identifier matches with one of those indicated in the 1231 request; note that the request can contain a "combination of 1232 roles", where the handler select all group members who have all 1233 roles included in the combination. 1235 * the identifier matches with one of those indicated in the request. 1237 Then, the handler returns a 2.05 (Content) message response with 1238 payload formatted as a CBOR map, containing only the 'pub_keys' and 1239 'peer_roles' parameters from Section 4.1.2.1. In particular, 1240 'pub_keys' encodes the list of public keys of those group members 1241 including the respective member identifiers, while 'peer_roles' 1242 encodes their respective role (or CBOR array of roles) in the group. 1243 The specific format of public keys as well as of identifiers of group 1244 members is specified by the application profile (OPT1, REQ9). 1246 If the KDC does not store any public key associated with the 1247 specified member identifiers, the handler returns a response with 1248 payload formatted as a CBOR byte string of zero length. 1250 The handler MAY enforce one of the following policies, in order to 1251 handle possible identifiers that are included in the 'get_pub_keys' 1252 parameter of the request but are not associated to any current group 1253 member. Such a policy MUST be specified by the application profile 1254 (REQ13) 1256 * The KDC silently ignores those identifiers. 1258 * The KDC retains public keys of group members for a given amount of 1259 time after their leaving, before discarding them. As long as such 1260 public keys are retained, the KDC provides them to a requesting 1261 Client. 1263 Note that this resource handler only verifies that the node is 1264 authorized by the AS to access this resource. Nodes that are not 1265 members of the group but are authorized to do signature verifications 1266 on the group messages may be allowed to access this resource, if the 1267 application needs it. 1269 4.1.3.2. GET Handler 1271 The handler expects a GET request. 1273 The handler verifies that the group name of the /ace-group/GROUPNAME 1274 path is a subset of the 'scope' stored in the access token associated 1275 to this client. If verification fails, the KDC MUST respond with a 1276 4.01 (Unauthorized) error message. 1278 If verification succeeds, the handler returns a 2.05 (Content) 1279 message containing the public keys of all the current group members, 1280 for the group identified by "GROUPNAME". The payload of the response 1281 is formatted as a CBOR map, containing only the 'pub_keys' and 1282 'peer_roles' parameters from Section 4.1.2.1. In particular, 1283 'pub_keys' encodes the list of public keys of those group members 1284 including the respective member identifiers, while 'peer_roles' 1285 encodes their respective role (or CBOR array of roles) in the group. 1287 If the KDC does not store any public key for the group, the handler 1288 returns a response with payload formatted as a CBOR byte string of 1289 zero length. The specific format of public keys as well as of 1290 identifiers of group members is specified by the application profile 1291 (OPT1, REQ9). 1293 Note that this resource handler only verifies that the node is 1294 authorized by the AS to access this resource. Nodes that are not 1295 members of the group but are authorized to do signature verifications 1296 on the group messages may be allowed to access this resource, if the 1297 application needs it. 1299 4.1.4. ace-group/GROUPNAME/policies 1301 This resource implements a GET handler. 1303 4.1.4.1. GET Handler 1305 The handler expects a GET request. 1307 The handler verifies that the group name of the /ace-group/GROUPNAME 1308 path is a subset of the 'scope' stored in the access token associated 1309 to this client. If verification fails, the KDC MUST respond with a 1310 4.01 (Unauthorized) error message. 1312 Additionally, the handler verifies that the node is a current member 1313 of the group. If verification fails, the KDC MUST respond with a 1314 4.00 (Bad Request) error message. 1316 If verification succeeds, the handler returns a 2.05 (Content) 1317 message containing the list of policies for the group identified by 1318 "GROUPNAME". The payload of the response is formatted as a CBOR map 1319 including only the parameter 'group_policies' defined in 1320 Section 4.1.2.1 and specifying the current policies in the group. If 1321 the KDC does not store any policy, the payload is formatted as a 1322 zero-length CBOR byte string. 1324 The specific format and meaning of group policies MUST be specified 1325 in the application profile (REQ14). 1327 4.1.5. ace-group/GROUPNAME/num 1329 This resource implements a GET handler. 1331 4.1.5.1. GET Handler 1333 The handler expects a GET request. 1335 The handler verifies that the group name of the /ace-group/GROUPNAME 1336 path is a subset of the 'scope' stored in the access token associated 1337 to this client. If verification fails, the KDC MUST respond with a 1338 4.01 (Unauthorized) error message. 1340 Additionally, the handler verifies that the node is a current member 1341 of the group. If verification fails, the KDC MUST respond with a 1342 4.00 (Bad Request) error message. 1344 If verification succeeds, the handler returns a 2.05 (Content) 1345 message containing an integer that represents the version number of 1346 the symmetric group keying material. This number is incremented on 1347 the KDC every time the KDC updates the symmetric group keying 1348 material, before the new keying material is distributed. This number 1349 is stored in persistent storage. 1351 The payload of the response is formatted as a CBOR integer. 1353 4.1.6. ace-group/GROUPNAME/nodes/NODENAME 1355 This resource implements GET, PUT and DELETE handlers. 1357 4.1.6.1. PUT Handler 1359 The PUT handler is used to get the KDC to produce and return 1360 individual keying material to protect outgoing messages for the node 1361 (identified by "NODENAME") for the group identified by "GROUPNAME". 1362 Application profiles MAY also use this handler to rekey the whole 1363 group. (OPT8) It is up to the application profiles to specify if 1364 this handler supports renewal of individual keying material, renewal 1365 of the group keying material or both. 1367 The handler expects a request with empty payload. 1369 The handler verifies that the group name of the /ace-group/GROUPNAME 1370 path is a subset of the 'scope' stored in the access token associated 1371 to this client, identified by "NODENAME". If verification fails, the 1372 KDC MUST respond with a 4.01 (Unauthorized) error message. 1374 Additionally, the handler verifies that the node is a current member 1375 of the group. If verification fails, the KDC MUST respond with a 1376 4.00 (Bad Request) error message. 1378 If verification succeeds, the handler returns a 2.05 (Content) 1379 message containing newly-generated keying material for the Client, 1380 and/or, if the application profiles requires it (OPT8), starts the 1381 comprete group rekeying. The payload of the response is formatted as 1382 a CBOR map. The specific format of newly-generated individual keying 1383 material for group members, or of the information to derive it, and 1384 corresponding CBOR label, MUST be specified in the application 1385 profile (REQ15) and registered in Section 8.5. 1387 4.1.6.2. GET Handler 1389 The handler expects a GET request. 1391 The handler verifies that the group name of the /ace-group/GROUPNAME 1392 path is a subset of the 'scope' stored in the access token associated 1393 to this client, identified by "NODENAME". If verification fails, the 1394 KDC MUST respond with a 4.01 (Unauthorized) error message. 1396 The handler also verifies that the node sending the request and the 1397 node name used in the Uri-Path match. If that is not the case, the 1398 handler responds with a 4.01 (Unauthorized) error response. 1400 Additionally, the handler verifies that the node is a current member 1401 of the group. If verification fails, the KDC MUST respond with a 1402 4.00 (Bad Request) error message. 1404 If verification succeeds, the handler returns a 2.05 (Content) 1405 message containing both the group keying material and the individual 1406 keying material for the Client, or information enabling the Client to 1407 derive it. The payload of the response is formatted as a CBOR map. 1408 The format for the group keying material is the same as defined in 1409 the response of Section 4.1.2.2. The specific format of individual 1410 keying material for group members, or of the information to derive 1411 it, and corresponding CBOR label, MUST be specified in the 1412 application profile (REQ15) and registered in Section 8.5. 1414 4.1.6.3. DELETE Handler 1416 The DELETE handler removes the node identified by "NODENAME" from the 1417 group identified by "GROUPNAME". 1419 The handler expects a request with method DELETE (and empty payload). 1421 The handler verifies that the group name of the /ace-group/GROUPNAME 1422 path is a subset of the 'scope' stored in the access token associated 1423 to this client, identified by "NODENAME". If verification fails, the 1424 KDC MUST respond with a 4.01 (Unauthorized) error message. 1426 The handler also verifies that the node sending the request and the 1427 node name used in the Uri-Path match. If that is not the case, the 1428 handler responds with a 4.01 (Unauthorized) error response. 1430 Additionally, the handler verifies that the node is a current member 1431 of the group. If verification fails, the KDC MUST respond with a 1432 4.00 (Bad Request) error message. 1434 If verification succeeds, the handler removes the client from the 1435 group identified by "GROUPNAME", for specific roles if roles were 1436 specified in the 'scope' field, or for all roles. That includes 1437 removing the public key of the client if the KDC keep tracks of that. 1438 Then, the handler delete the sub-resource nodes/NODENAME and returns 1439 a 2.02 (Deleted) message with empty payload. 1441 4.1.7. ace-group/GROUPNAME/nodes/NODENAME/pub-key 1443 This resource implements a POST handler, if the KDC stores the public 1444 key of group members. If the KDC does not store the public keys of 1445 group members, the handler does not implement any method, and every 1446 request returns a 4.05 Method Not Allowed error. 1448 4.1.7.1. POST Handler 1450 The POST handler is used to replace the stored public key of this 1451 client (identified by "NODENAME") with the one specified in the 1452 request at the KDC, for the group identified by "GROUPNAME". 1454 The handler expects a POST request with payload as specified in 1455 Section 4.1.2.1, with the difference that it includes only the 1456 parameters 'client_cred', 'cnonce' and 'client_cred_verify'. In 1457 particular, the signature included in 'client_cred_verify' is 1458 expected to be computed as defined in Section 4.1.2.1, with a newly 1459 generated N_C nonce and the previously received N_S. The specific 1460 format of public keys is specified by the application profile (OPT1). 1462 The handler verifies that the group name GROUPNAME is a subset of the 1463 'scope' stored in the access token associated to this client. If 1464 verification fails, the KDC MUST respond with a 4.01 (Unauthorized) 1465 error message. 1467 If the request is not formatted correctly (i.e. required fields non 1468 received or received with incorrect format), the handler MUST respond 1469 with a 4.00 (Bad Request) error message. If the request contained 1470 unknown or non-expected fields present, the handler MUST silently 1471 drop them and continue processing. Application profiles MAY define 1472 optional or mandatory payload formats for specific error cases 1473 (OPT6). 1475 Otherwise, the handler checks that the public key specified in the 1476 'client_cred' field has a valid format for the group identified by 1477 "GROUPNAME", i.e. it is encoded as expected and is compatible with 1478 the signature algorithm and possible associated parameters. If that 1479 cannot be verified, the handler MUST respond with a 4.00 (Bad 1480 Request) error message. Applications profiles MAY define 1481 alternatives (OPT5). 1483 Otherwise, the handler verifies the signature contained in the 1484 'client_cred_verify' field of the request, using the public key 1485 specified in the 'client_cred' field. If the signature does not pass 1486 verification, the handler MUST respond with a 4.00 (Bad Request) 1487 error message. If the KDC cannot retrieve the 'kdcchallenge' 1488 associated to this Client (see Section 3.3), the KDC MUST respond 1489 with a 4.00 Bad Request error respons, including a newly generated 1490 'kdcchallenge' in a CBOR map in the payload the payload. This error 1491 response MUST also have Content-Format "application/ace+cbor". 1493 If verification succeeds, the handler replaces the old public key of 1494 the node NODENAME with the one specified in the 'client_cred' field 1495 of the request, and stores it as the new current public key of the 1496 node NODENAME, in the list of group members' public keys for the 1497 group identified by GROUPNAME. Then, the handler replies with a 2.04 1498 (Changed) response, which does not include a payload. 1500 4.2. Retrieval of Group Names and URIs 1502 In case the joining node only knows the group identifier of the group 1503 it wishes to join or about which it wishes to get update information 1504 from the KDC, the node can contact the KDC to request the 1505 corresponding group name and joining resource URI. The node can 1506 request several group identifiers at once. It does so by sending a 1507 CoAP FETCH request to the /ace-group endpoint at the KDC formatted as 1508 defined in Section 4.1.1.1. 1510 Figure 9 gives an overview of the exchanges described above. 1512 Client KDC 1513 | | 1514 |-------- Group Name and URI Retrieval Request: -------->| 1515 | FETCH /ace-group | 1516 | | 1517 |<-Group Name and URI Retrieval Response: 2.05 (Content)-| 1518 | | 1520 Figure 9: Message Flow of Group Name and URI Retrieval Request- 1521 Response 1523 4.3. Joining Exchange 1525 Figure 10 gives an overview of the Joining exchange between Client 1526 and KDC, when the Client first joins a group. 1528 Client KDC 1529 | | 1530 |----- Joining Request: POST /ace-group/GROUPNAME ------>| 1531 | | 1532 |<--------- Joining Response: 2.01 (Created) ----------- | 1533 | Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME" | 1535 Figure 10: Message Flow of First Exchange for Group Joining 1537 If not previously established, the Client and the KDC MUST first 1538 establish a pairwise secure communication channel (REQ16). This can 1539 be achieved, for instance, by using a transport profile of ACE. The 1540 Joining exchange MUST occur over that secure channel. The Client and 1541 the KDC MAY use that same secure channel to protect further pairwise 1542 communications that must be secured. 1544 The secure communication protocol is REQUIRED to establish the secure 1545 channel between Client and KDC by using the proof-of-possession key 1546 bound to the access token. As a result, the proof-of-possession to 1547 bind the access token to the Client is performed by using the proof- 1548 of-possession key bound to the access token for establishing secure 1549 communication between the Client and the KDC. 1551 To join the group, the Client sends a CoAP POST request to the /ace- 1552 group/GROUPNAME endpoint at the KDC, where GROUPNAME is the group 1553 name of the group to join, formatted as specified in Section 4.1.2.1. 1554 This group name is the same as in the scope entry corresponding to 1555 that group, specified in the 'scope' parameter of the Authorization 1556 Request/Response, or it can be retrieved from it. Note that, in case 1557 of successful joining, the Client will receive the URI to retrieve 1558 group keying material and to leave the group in the Location-Path 1559 option of the response. 1561 If the node is joining a group for the first time, and the KDC 1562 maintains the public keys of the group members, the Client is 1563 REQUIRED to send its own public key and proof of possession 1564 ("client_cred" and "client_cred_verify" in Section 4.1.2.1). The 1565 request is only accepted if both public key and proof of possession 1566 are provided. If a node re-joins a group with the same access token 1567 and the same public key, it can omit to send the public key and the 1568 proof of possession, or just omit the proof of possession, and the 1569 KDC will be able to retrieve its public key associated to its token 1570 for that group (if the key has been discarded, the KDC will reply 1571 with 4.00 Bad Request, as specified in Section 4.1.2.1). If a node 1572 re-joins a group but wants to update its own public key, it needs to 1573 send both public key and proof of possession. 1575 If the application requires backward security, the KDC MUST generate 1576 new group keying material and securely distribute it to all the 1577 current group members, upon a new node's joining the group. To this 1578 end, the KDC uses the message format of the response defined in 1579 Section 4.1.2.2. Application profiles may define alternative ways of 1580 retrieving the keying material, such as sending separate requests to 1581 different resources at the KDC (Section 4.1.2.2, Section 4.1.3.2, 1582 Section 4.1.4.1). After distributing the new group keying material, 1583 the KDC MUST increment the version number of the keying material. 1585 4.4. Retrieval of Updated Keying Material 1587 When any of the following happens, a node MUST stop using the owned 1588 group keying material to protect outgoing messages, and SHOULD stop 1589 using it to decrypt and verify incoming messages. 1591 * Upon expiration of the keying material, according to what 1592 indicated by the KDC with the 'exp' parameter in a Joining 1593 Response, or to a pre-configured value. 1595 * Upon receiving a notification of revoked/renewed keying material 1596 from the KDC, possibly as part of an update of the keying material 1597 (rekeying) triggered by the KDC. 1599 * Upon receiving messages from other group members without being 1600 able to retrieve the keying material to correctly decrypt them. 1601 This may be due to rekeying messages previously sent by the KDC, 1602 that the Client was not able to receive or decrypt. 1604 In either case, if it wants to continue participating in the group 1605 communication, the node has to request the latest keying material 1606 from the KDC. To this end, the Client sends a CoAP GET request to 1607 the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, 1608 formatted as specified in Section 4.1.6.2. 1610 Note that policies can be set up, so that the Client sends a Key Re- 1611 Distribution request to the KDC only after a given number of received 1612 messages could not be decrypted (because of failed decryption 1613 processing or inability to retrieve the necessary keying material). 1615 It is application dependent and pertaining to the particular message 1616 exchange (e.g. [I-D.ietf-core-oscore-groupcomm]) to set up these 1617 policies, to instruct clients to retain incoming messages and for how 1618 long (OPT4). This allows clients to possibly decrypt such messages 1619 after getting updated keying material, rather than just consider them 1620 non valid messages to discard right away. 1622 The same Key Distribution Request could also be sent by the Client 1623 without being triggered by a failed decryption of a message, if the 1624 Client wants to be sure that it has the latest group keying material. 1625 If that is the case, the Client will receive from the KDC the same 1626 group keying material it already has in memory. 1628 Figure 11 gives an overview of the exchange described above. 1630 Client KDC 1631 | | 1632 |------------------ Key Distribution Request: --------------->| 1633 | GET ace-group/GROUPNAME/nodes/NODENAME | 1634 | | 1635 |<-------- Key Distribution Response: 2.05 (Content) ---------| 1636 | | 1638 Figure 11: Message Flow of Key Distribution Request-Response 1640 Alternatively, the re-distribution of keying material can be 1641 initiated by the KDC, which e.g.: 1643 * Can make the ace-group/GROUPNAME/nodes/NODENAME resource 1644 Observable [RFC7641], and send notifications to Clients when the 1645 keying material is updated. 1647 * Can send the payload of the Key Distribution Response in one or 1648 multiple multicast POST requests to the members of the group, 1649 using secure rekeying schemes such as [RFC2093][RFC2094][RFC2627]. 1651 * Can send unicast POST requests to each Client over a secure 1652 channel, with the same payload as the Key Distribution Response. 1653 When sending such requests, the KDC can target the URI path 1654 provided by the intended recipient upon joining the group, as 1655 specified in the 'control_path' parameter of the Joining Request 1656 (see Section 4.1.2.1). 1658 * Can act as a publisher in a pub-sub scenario, and update the 1659 keying material by publishing on a specific topic on a broker, 1660 which all the members of the group are subscribed to. 1662 Note that these methods of KDC-initiated key distribution have 1663 different security properties and require different security 1664 associations. 1666 4.5. Requesting a Change of Keying Material 1668 Beside possible expiration, the client may need to communicate to the 1669 KDC its need for the keying material to be renewed, e.g. due to 1670 exhaustion of AEAD nonces, if AEAD is used for protecting group 1671 communnication. Depending on the application profile (OPT8), this 1672 can result in renewal of idividual keying material, group keying 1673 material, or both. For example, if the Client uses an individual key 1674 to protect outgoing traffic and has to renew it, the node may request 1675 a new one, or new input material to derive it, without renewing the 1676 whole group keying material. 1678 To this end, the client performs a Key Renewal Request/Response 1679 exchange with the KDC, i.e. it sends a CoAP PUT request to the /ace- 1680 group/GROUPNAME/nodes/NODENAME endpoint at the KDC, where GROUPNAME 1681 is the group name and NODENAME is the node's name, and formatted as 1682 defined in Section 4.1.6.2. 1684 Figure 12 gives an overview of the exchange described above. 1686 Client KDC 1687 | | 1688 |------------------ Key Renewal Request: -------------->| 1689 | PUT ace-group/GROUPNAME/nodes/NODENAME | 1690 | | 1691 |<-------- Key Renewal Response: 2.05 (Content) --------| 1692 | | 1694 Figure 12: Message Flow of Key Renewal Request-Response 1696 Note the difference between the Key Distribution Request and the Key 1697 Renewal Request: while the first one only triggers distribution (the 1698 renewal might have happened independently, e.g. because of 1699 expiration), the second one triggers the KDC to produce new 1700 individual keying material for the requesting node. 1702 4.6. Retrieval of Public Keys and Roles for Group Members 1704 In case the KDC maintains the public keys of group members, a node in 1705 the group can contact the KDC to request public keys and roles of 1706 either all group members or a specified subset, by sending a CoAP GET 1707 or FETCH request to the /ace-group/GROUPNAME/pub-key endpoint at the 1708 KDC, where GROUPNAME is the group name, and formatted as defined in 1709 Section 4.1.3.2 and Section 4.1.3.1. 1711 Figure 13 and Figure 14 give an overview of the exchanges described 1712 above. 1714 Client KDC 1715 | | 1716 |--Public Key Request: GET /ace-group/GROUPNAME/pub-key->| 1717 | | 1718 |<--------- Public Key Response: 2.05 (Content) ---------| 1719 | | 1721 Figure 13: Message Flow of Public Key Exchange to Request All 1722 Members Public Keys 1724 Client KDC 1725 | | 1726 |-Public Key Request: FETCH /ace-group/GROUPNAME/pub-key->| 1727 | | 1728 |<--------- Public Key Response: 2.05 (Created) ----------| 1729 | | 1731 Figure 14: Message Flow of Public Key Exchange to Request 1732 Specific Members Public Keys 1734 4.7. Update of Public Key 1736 In case the KDC maintains the public keys of group members, a node in 1737 the group can contact the KDC to upload a new public key to use in 1738 the group, and replace the currently stored one. 1740 To this end, the Client performs a Public Key Update Request/Response 1741 exchange with the KDC, i.e. it sends a CoAP POST request to the /ace- 1742 group/GROUPNAME/nodes/NODENAME/pub-key endpoint at the KDC, where 1743 GROUPNAME is the group name and NODENAME is the node's name. 1745 The request is formatted as specified in Section 4.1.7.1. 1747 Figure Figure 15 gives an overview of the exchange described above. 1749 Client KDC 1750 | | 1751 |-------------- Public Key Update Request: ---------------------->| 1752 | POST ace-group/GROUPNAME/nodes/NODENAME/pub-key | 1753 | | 1754 |<------- Public Key Update Response: 2.04 (Changed) -------------| 1755 | | 1757 Figure 15: Message Flow of Public Key Update Request-Response 1759 If the application requires backward security, the KDC MUST generate 1760 new group keying material and securely distribute it to all the 1761 current group members, upon a group member updating its own public 1762 key. To this end, the KDC uses the message format of the response 1763 defined in Section 4.1.2.2. Application profiles may define 1764 alternative ways of retrieving the keying material, such as sending 1765 separate requests to different resources at the KDC (Section 4.1.2.2, 1766 Section 4.1.3.2, Section 4.1.4.1). The KDC MUST increment the 1767 version number of the current keying material, before distributing 1768 the newly generated keying material to the group. After that, the 1769 KDC SHOULD store the distributed keying material in persistent 1770 storage. 1772 Additionally, after updating its own public key, a group member MAY 1773 send a number of the later requests including an identifier of the 1774 updated public key, to signal nodes that they need to retrieve it. 1775 How that is done depends on the group communication protocol used, 1776 and therefore is application profile specific (OPT10). 1778 4.8. Retrieval of Group Policies 1780 A node in the group can contact the KDC to retrieve the current group 1781 policies, by sending a CoAP GET request to the /ace-group/GROUPNAME/ 1782 policies endpoint at the KDC, where GROUPNAME is the group name, and 1783 formatted as defined in Section 4.1.4.1 1785 Figure 16 gives an overview of the exchange described above. 1787 Client KDC 1788 | | 1789 |-Policies Request: GET ace-group/GROUPNAME/policies ->| 1790 | | 1791 |<--------- Policies Response: 2.05 (Content) ---------| 1792 | | 1794 Figure 16: Message Flow of Policies Request-Response 1796 4.9. Retrieval of Keying Material Version 1798 A node in the group can contact the KDC to request information about 1799 the version number of the symmetric group keying material, by sending 1800 a CoAP GET request to the /ace-group/GROUPNAME/num endpoint at the 1801 KDC, where GROUPNAME is the group name, formatted as defined in 1802 Section 4.1.5.1. In particular, the version is incremented by the 1803 KDC every time the group keying material is renewed, before it's 1804 distributed to the group members. 1806 Figure 17 gives an overview of the exchange described above. 1808 Client KDC 1809 | | 1810 |---- Version Request: GET ace-group/GROUPNAME/num ---->| 1811 | | 1812 |<--------- Version Response: 2.05 (Content) -----------| 1813 | | 1815 Figure 17: Message Flow of Version Request-Response 1817 4.10. Group Leaving Request 1819 A node can actively request to leave the group. In this case, the 1820 Client sends a CoAP DELETE request to the endpoint /ace- 1821 group/GROUPNAME/nodes/NODENAME at the KDC, where GROUPNAME is the 1822 group name and NODENAME is the node's name, formatted as defined in 1823 Section 4.1.6.3 1825 Alternatively, a node may be removed by the KDC, without having 1826 explicitly asked for it. This is further discussed in Section 5. 1828 5. Removal of a Node from the Group 1830 This section describes the different scenarios according to which a 1831 node ends up being removed from the group. 1833 If the application requires forward security, the KDC MUST generate 1834 new group keying material and securely distribute it to all the 1835 current group members but the leaving node, using the message format 1836 of the Key Distribution Response (see Section 4.4). Application 1837 profiles may define alternative message formats. Before distributing 1838 the new group keying material, the KDC MUST increment the version 1839 number of the keying material. 1841 Note that, after having left the group, a node may wish to join it 1842 again. Then, as long as the node is still authorized to join the 1843 group, i.e. it still has a valid access token, it can re-request to 1844 join the group directly to the KDC without needing to retrieve a new 1845 access token from the AS. This means that the KDC might decide to 1846 keep track of nodes with valid access tokens, before deleting all 1847 information about the leaving node. 1849 A node may be evicted from the group in the following cases. 1851 1. The node explicitly asks to leave the group, as defined in 1852 Section 4.10. 1854 2. The node has been found compromised or is suspected so. 1856 3. The node's authorization to be a group member is not valid 1857 anymore, either because the access token has expired, or it has 1858 been revoked. If the AS provides Token introspection (see 1859 Section 5.7 of [I-D.ietf-ace-oauth-authz]), the KDC can 1860 optionally use it and check whether the node is still authorized 1861 for that group in that role. 1863 In either case, once aware that a node is not authorized anymore, the 1864 KDC has to remove the unauthorized node from the list of group 1865 members, if the KDC keeps track of that. 1867 In case of forced eviction, the KDC MAY explicitly inform the leaving 1868 node, if the Client implements the 'control_path' resource specified 1869 in Section 4.1.2.1. To this end, the KDC MAY send a DEL request, 1870 targeting the URI specified in the 'control_path' parameter of the 1871 Joining Request. 1873 6. ACE Groupcomm Parameters 1875 This specification defines a number of fields used during the second 1876 part of the message exchange, after the ACE Token POST exchange. The 1877 table below summarizes them, and specifies the CBOR key to use 1878 instead of the full descriptive name. Note that the media type ace- 1879 groupcomm+cbor MUST be used when these fields are transported. 1881 +=======================+======+===============+==================+ 1882 | Name | CBOR | CBOR Type | Reference | 1883 | | Key | | | 1884 +=======================+======+===============+==================+ 1885 | scope | TBD | byte string | Section 4.1.2.1 | 1886 +-----------------------+------+---------------+------------------+ 1887 | get_pub_keys | TBD | array | Section 4.1.2.1, | 1888 | | | | Section 4.1.3.1 | 1889 +-----------------------+------+---------------+------------------+ 1890 | client_cred | TBD | byte string | Section 4.1.2.1 | 1891 +-----------------------+------+---------------+------------------+ 1892 | cnonce | TBD | byte string | Section 4.1.2.1 | 1893 +-----------------------+------+---------------+------------------+ 1894 | client_cred_verify | TBD | byte string | Section 4.1.2.1 | 1895 +-----------------------+------+---------------+------------------+ 1896 | pub_keys_repos | TBD | text string | Section 4.1.2.1 | 1897 +-----------------------+------+---------------+------------------+ 1898 | control_path | TBD | text string | Section 4.1.2.1 | 1899 +-----------------------+------+---------------+------------------+ 1900 | gkty | TBD | integer / | Section 4.1.2.1 | 1901 | | | text string | | 1902 +-----------------------+------+---------------+------------------+ 1903 | key | TBD | see "ACE | Section 4.1.2.1 | 1904 | | | Groupcomm | | 1905 | | | Key" Registry | | 1906 +-----------------------+------+---------------+------------------+ 1907 | num | TBD | integer | Section 4.1.2.1 | 1908 +-----------------------+------+---------------+------------------+ 1909 | ace-groupcomm-profile | TBD | int | Section 4.1.2.1 | 1910 +-----------------------+------+---------------+------------------+ 1911 | exp | TBD | int | Section 4.1.2.1 | 1912 +-----------------------+------+---------------+------------------+ 1913 | pub_keys | TBD | byte string | Section 4.1.2.1 | 1914 +-----------------------+------+---------------+------------------+ 1915 | peer_roles | TBD | array | Section 4.1.2.1 | 1916 +-----------------------+------+---------------+------------------+ 1917 | group_policies | TBD | map | Section 4.1.2.1 | 1918 +-----------------------+------+---------------+------------------+ 1919 | mgt_key_material | TBD | byte string | Section 4.1.2.1 | 1920 +-----------------------+------+---------------+------------------+ 1921 | gid | TBD | array | Section 4.1.1.1 | 1922 +-----------------------+------+---------------+------------------+ 1923 | gname | TBD | array of text | Section 4.1.1.1 | 1924 | | | string | | 1925 +-----------------------+------+---------------+------------------+ 1926 | guri | TBD | array of text | Section 4.1.1.1 | 1927 | | | string | | 1928 +-----------------------+------+---------------+------------------+ 1930 Table 1 1932 7. Security Considerations 1934 When a Client receives a message from a sender for the first time, it 1935 needs to have a mechanism in place to avoid replay, e.g. 1936 Appendix B.2 of [RFC8613]. In case the Client rebooted and lost the 1937 security state used to protect previous communication with that 1938 sender, such a mechanism is useful for the recipient to be on the 1939 safe side. Besides, if the KDC has renewed the group keying 1940 material, and the time interval between the end of the rekeying 1941 process and the joining of the Client is sufficiently small, that 1942 Client is also on the safe side, since replayed older messages 1943 protected with the previous keying material will not be accepted. 1945 The KDC must renew the group keying material upon its expiration. 1947 The KDC should renew the keying material upon group membership 1948 change, and should provide it to the current group members through 1949 the rekeying scheme used in the group. 1951 The KDC should renew the group keying material after rebooting, even 1952 in the case where all keying material is stored in persistent 1953 storage. However, if the KDC relies on Observe responses to notify 1954 the group of renewed keying material, after rebooting the KDC will 1955 have lost all the current ongoing Observations with the group 1956 members, and the previous keying material will be used to protect 1957 messages in the group anyway. The KDC will rely on each node 1958 requesting updates of the group keying material to establish the new 1959 keying material in the nodes, or, if implemented, it can push the 1960 update to the nodes in the group using the 'control_path' resource. 1962 The KDC may enforce a rekeying policy that takes into account the 1963 overall time required to rekey the group, as well as the expected 1964 rate of changes in the group membership. 1966 That is, the KDC may not rekey the group at every membership change, 1967 for instance if members' joining and leaving occur frequently and 1968 performing a group rekeying takes too long. The KDC may rekey the 1969 group after a minimum number of group members have joined or left 1970 within a given time interval, or after maximum amount of time since 1971 the last rekeying was completed, or yet during predictable network 1972 inactivity periods. 1974 However, this would result in the KDC not constantly preserving 1975 backward and forward security. Newly joining group members could be 1976 able to access the keying material used before their joining, and 1977 thus could access past group communications. Also, until the KDC 1978 performs a group rekeying, the newly leaving nodes would still be 1979 able to access upcoming group communications that are protected with 1980 the keying material that has not yet been updated. 1982 The KDC needs to have a mechanism in place to detect DoS attacks from 1983 nodes constantly initiating rekey events (for example by updating 1984 their public key), such as removing these nodes from the group. 1986 The KDC also needs to have a congestion control mechanism in place to 1987 avoid network congestion when the KDC renews the group keying 1988 material; CoAP and Observe give guidance on such mechanisms, see 1989 Section 4.7 of [RFC7252] and Section 4.5.1 of [RFC7641]. 1991 7.1. Update of Keying Material 1993 A group member can receive a message shortly after the group has been 1994 rekeyed, and new keying material has been distributed by the KDC. In 1995 the following two cases, this may result in misaligned keying 1996 material between the group members. 1998 In the first case, the sender protects a message using the old keying 1999 material. However, the recipient receives the message after having 2000 received the new keying material, hence not being able to correctly 2001 process it. A possible way to ameliorate this issue is to preserve 2002 the old, recent, keying material for a maximum amount of time defined 2003 by the application. By doing so, the recipient can still try to 2004 process the received message using the old retained keying material. 2005 Note that a former (compromised) group member can take advantage of 2006 this by sending messages protected with the old retained keying 2007 material. Therefore, a conservative application policy should not 2008 admit the storage of old keying material. 2010 In the second case, the sender protects a message using the new 2011 keying material, but the recipient receives that request before 2012 having received the new keying material. Therefore, the recipient 2013 would not be able to correctly process the request and hence discards 2014 it. If the recipient receives the new keying material shortly after 2015 that and the application at the sender endpoint performs 2016 retransmissions, the former will still be able to receive and 2017 correctly process the message. In any case, the recipient should 2018 actively ask the KDC for an updated keying material according to an 2019 application-defined policy, for instance after a given number of 2020 unsuccessfully decrypted incoming messages. 2022 A node that has left the group should not expect any of its outgoing 2023 messages to be successfully processed, if received after its leaving, 2024 due to a possible group rekeying occurred before the message 2025 reception. 2027 7.2. Block-Wise Considerations 2029 If the block-wise options [RFC7959] are used, and the keying material 2030 is updated in the middle of a block-wise transfer, the sender of the 2031 blocks just changes the keying material to the updated one and 2032 continues the transfer. As long as both sides get the new keying 2033 material, updating the keying material in the middle of a transfer 2034 will not cause any issue. Otherwise, the sender will have to 2035 transmit the message again, when receiving an error message from the 2036 recipient. 2038 Compared to a scenario where the transfer does not use block-wise, 2039 depending on how fast the keying material is changed, the nodes might 2040 consume a larger amount of the network bandwidth resending the blocks 2041 again and again, which might be problematic. 2043 8. IANA Considerations 2045 This document has the following actions for IANA. 2047 8.1. Media Type Registrations 2049 This specification registers the 'application/ace-groupcomm+cbor' 2050 media type for messages of the protocols defined in this document 2051 following the ACE exchange and carrying parameters encoded in CBOR. 2052 This registration follows the procedures specified in [RFC6838]. 2054 Type name: application 2056 Subtype name: ace-groupcomm+cbor 2058 Required parameters: none 2060 Optional parameters: none 2062 Encoding considerations: Must be encoded as CBOR map containing the 2063 protocol parameters defined in [this document]. 2065 Security considerations: See Section 7 of this document. 2067 Interoperability considerations: n/a 2069 Published specification: [this document] 2071 Applications that use this media type: The type is used by 2072 authorization servers, clients and resource servers that support the 2073 ACE groupcomm framework as specified in [this document]. 2075 Additional information: 2077 Magic number(s): n/a 2079 File extension(s): .ace-groupcomm 2081 Macintosh file type code(s): n/a 2083 Person & email address to contact for further information: 2084 iesg@ietf.org (mailto:iesg@ietf.org) 2086 Intended usage: COMMON 2088 Restrictions on usage: None 2089 Author: Francesca Palombini francesca.palombini@ericsson.com 2090 (mailto:francesca.palombini@ericsson.com) 2092 Change controller: IESG 2094 8.2. CoAP Content-Formats Registry 2096 This specification registers the following entry to the "CoAP 2097 Content-Formats" registry, within the "CoRE Parameters" registry: 2099 Media Type: application/ace-groupcomm+cbor 2101 Encoding: - 2103 ID: TBD 2105 Reference: [this document] 2107 8.3. OAuth Parameters Registry 2109 The following registrations are done for the OAuth ParametersRegistry 2110 following the procedure specified in section 11.2 of [RFC6749]: 2112 o Parameter name: sign_info o Parameter usage location: token 2113 request, token response o Change Controller: IESG o Specification 2114 Document(s): [[This specification]] 2116 o Parameter name: kdcchallenge o Parameter usage location: token 2117 response o Change Controller: IESG o Specification Document(s): 2118 [[This specification]] 2120 8.4. OAuth Parameters CBOR Mappings Registry 2122 The following registrations are done for the OAuth Parameters CBOR 2123 Mappings Registry following the procedure specified in section 8.9 of 2124 [I-D.ietf-ace-oauth-authz]: 2126 * Name: sign_info 2127 * CBOR Key: TBD (range -256 to 255) 2128 * Value Type: any 2129 * Reference: \[\[This specification\]\] 2131 * Name: kdcchallenge 2132 * CBOR Key: TBD (range -256 to 255) 2133 * Value Type: byte string 2134 * Reference: \[\[This specification\]\] 2136 8.5. ACE Groupcomm Parameters Registry 2138 This specification establishes the "ACE Groupcomm Parameters" IANA 2139 Registry. The Registry has been created to use the "Expert Review 2140 Required" registration procedure [RFC8126]. Expert review guidelines 2141 are provided in Section 8.11. 2143 The columns of this Registry are: 2145 * Name: This is a descriptive name that enables easier reference to 2146 the item. The name MUST be unique. It is not used in the 2147 encoding. 2149 * CBOR Key: This is the value used as CBOR key of the item. These 2150 values MUST be unique. The value can be a positive integer, a 2151 negative integer, or a string. 2153 * CBOR Type: This contains the CBOR type of the item, or a pointer 2154 to the registry that defines its type, when that depends on 2155 another item. 2157 * Reference: This contains a pointer to the public specification for 2158 the item. 2160 This Registry has been initially populated by the values in 2161 Section 6. The Reference column for all of these entries refers to 2162 sections of this document. 2164 8.6. ACE Groupcomm Key Registry 2166 This specification establishes the "ACE Groupcomm Key" IANA Registry. 2167 The Registry has been created to use the "Expert Review Required" 2168 registration procedure [RFC8126]. Expert review guidelines are 2169 provided in Section 8.11. 2171 The columns of this Registry are: 2173 * Name: This is a descriptive name that enables easier reference to 2174 the item. The name MUST be unique. It is not used in the 2175 encoding. 2177 * Key Type Value: This is the value used to identify the keying 2178 material. These values MUST be unique. The value can be a 2179 positive integer, a negative integer, or a text string. 2181 * Profile: This field may contain one or more descriptive strings of 2182 application profiles to be used with this item. The values should 2183 be taken from the Name column of the "ACE Groupcomm Profile" 2184 Registry. 2186 * Description: This field contains a brief description of the keying 2187 material. 2189 * References: This contains a pointer to the public specification 2190 for the format of the keying material, if one exists. 2192 This Registry has been initially populated by the values in Figure 7. 2193 The specification column for all of these entries will be this 2194 document. 2196 8.7. ACE Groupcomm Profile Registry 2198 This specification establishes the "ACE Groupcomm Profile" IANA 2199 Registry. The Registry has been created to use the "Expert Review 2200 Required" registration procedure [RFC8126]. Expert review guidelines 2201 are provided in Section 8.11. It should be noted that, in addition 2202 to the expert review, some portions of the Registry require a 2203 specification, potentially a Standards Track RFC, be supplied as 2204 well. 2206 The columns of this Registry are: 2208 * Name: The name of the application profile, to be used as value of 2209 the profile attribute. 2211 * Description: Text giving an overview of the application profile 2212 and the context it is developed for. 2214 * CBOR Value: CBOR abbreviation for the name of this application 2215 profile. Different ranges of values use different registration 2216 policies [RFC8126]. Integer values from -256 to 255 are 2217 designated as Standards Action. Integer values from -65536 to 2218 -257 and from 256 to 65535 are designated as Specification 2219 Required. Integer values greater than 65535 are designated as 2220 Expert Review. Integer values less than -65536 are marked as 2221 Private Use. 2223 * Reference: This contains a pointer to the public specification of 2224 the abbreviation for this application profile, if one exists. 2226 8.8. ACE Groupcomm Policy Registry 2228 This specification establishes the "ACE Groupcomm Policy" IANA 2229 Registry. The Registry has been created to use the "Expert Review 2230 Required" registration procedure [RFC8126]. Expert review guidelines 2231 are provided in Section 8.11. It should be noted that, in addition 2232 to the expert review, some portions of the Registry require a 2233 specification, potentially a Standards Track RFC, be supplied as 2234 well. 2236 The columns of this Registry are: 2238 * Name: The name of the group communication policy. 2240 * CBOR label: The value to be used to identify this group 2241 communication policy. Key map labels MUST be unique. The label 2242 can be a positive integer, a negative integer or a string. 2243 Integer values between 0 and 255 and strings of length 1 are 2244 designated as Standards Track Document required. Integer values 2245 from 256 to 65535 and strings of length 2 are designated as 2246 Specification Required. Integer values of greater than 65535 and 2247 strings of length greater than 2 are designated as expert review. 2248 Integer values less than -65536 are marked as private use. 2250 * CBOR type: the CBOR type used to encode the value of this group 2251 communication policy. 2253 * Description: This field contains a brief description for this 2254 group communication policy. 2256 * Reference: This field contains a pointer to the public 2257 specification providing the format of the group communication 2258 policy, if one exists. 2260 This registry will be initially populated by the values in Figure 8. 2262 8.9. Sequence Number Synchronization Method Registry 2264 This specification establishes the "Sequence Number Synchronization 2265 Method" IANA Registry. The Registry has been created to use the 2266 "Expert Review Required" registration procedure [RFC8126]. Expert 2267 review guidelines are provided in Section 8.11. It should be noted 2268 that, in addition to the expert review, some portions of the Registry 2269 require a specification, potentially a Standards Track RFC, be 2270 supplied as well. 2272 The columns of this Registry are: 2274 * Name: The name of the sequence number synchronization method. 2276 * Value: The value to be used to identify this sequence number 2277 synchronization method. 2279 * Description: This field contains a brief description for this 2280 sequence number synchronization method. 2282 * Reference: This field contains a pointer to the public 2283 specification describing the sequence number synchronization 2284 method. 2286 8.10. Interface Description (if=) Link Target Attribute Values Registry 2288 This specification registers the following entry to the "Interface 2289 Description (if=) Link Target Attribute Values Registry" registry, 2290 within the "CoRE Parameters" registry: 2292 * Attribute Value: ace.group 2294 * Description: The 'ace group' interface is used to provision keying 2295 material and related informations and policies to members of a 2296 group using the Ace framework. 2298 * Reference: [This Document] 2300 8.11. Expert Review Instructions 2302 The IANA Registries established in this document are defined as 2303 expert review. This section gives some general guidelines for what 2304 the experts should be looking for, but they are being designated as 2305 experts for a reason so they should be given substantial latitude. 2307 Expert reviewers should take into consideration the following points: 2309 * Point squatting should be discouraged. Reviewers are encouraged 2310 to get sufficient information for registration requests to ensure 2311 that the usage is not going to duplicate one that is already 2312 registered and that the point is likely to be used in deployments. 2313 The zones tagged as private use are intended for testing purposes 2314 and closed environments, code points in other ranges should not be 2315 assigned for testing. 2317 * Specifications are required for the standards track range of point 2318 assignment. Specifications should exist for specification 2319 required ranges, but early assignment before a specification is 2320 available is considered to be permissible. Specifications are 2321 needed for the first-come, first-serve range if they are expected 2322 to be used outside of closed environments in an interoperable way. 2323 When specifications are not provided, the description provided 2324 needs to have sufficient information to identify what the point is 2325 being used for. 2327 * Experts should take into account the expected usage of fields when 2328 approving point assignment. The fact that there is a range for 2329 standards track documents does not mean that a standards track 2330 document cannot have points assigned outside of that range. The 2331 length of the encoded value should be weighed against how many 2332 code points of that length are left, the size of device it will be 2333 used on, and the number of code points left that encode to that 2334 size. 2336 9. References 2338 9.1. Normative References 2340 [COSE.Algorithms] 2341 IANA, "COSE Algorithms", 2342 . 2345 [I-D.ietf-ace-oauth-authz] 2346 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 2347 H. Tschofenig, "Authentication and Authorization for 2348 Constrained Environments (ACE) using the OAuth 2.0 2349 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 2350 draft-ietf-ace-oauth-authz-35, June 24, 2020, 2351 . 2354 [I-D.ietf-ace-oauth-params] 2355 Seitz, L., "Additional OAuth Parameters for Authorization 2356 in Constrained Environments (ACE)", Work in Progress, 2357 Internet-Draft, draft-ietf-ace-oauth-params-13, April 28, 2358 2020, . 2361 [I-D.ietf-core-oscore-groupcomm] 2362 Tiloca, M., Selander, G., Palombini, F., and J. Park, 2363 "Group OSCORE - Secure Group Communication for CoAP", Work 2364 in Progress, Internet-Draft, draft-ietf-core-oscore- 2365 groupcomm-09, June 23, 2020, . 2368 [I-D.ietf-cose-rfc8152bis-algs] 2369 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2370 Initial Algorithms", Work in Progress, Internet-Draft, 2371 draft-ietf-cose-rfc8152bis-algs-11, July 1, 2020, 2372 . 2375 [I-D.ietf-cose-rfc8152bis-struct] 2376 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2377 Structures and Process", Work in Progress, Internet-Draft, 2378 draft-ietf-cose-rfc8152bis-struct-12, August 24, 2020, 2379 . 2382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2383 Requirement Levels", BCP 14, RFC 2119, 2384 DOI 10.17487/RFC2119, March 1997, 2385 . 2387 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 2388 RFC 6749, DOI 10.17487/RFC6749, October 2012, 2389 . 2391 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2392 Specifications and Registration Procedures", BCP 13, 2393 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2394 . 2396 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2397 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2398 October 2013, . 2400 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2401 Application Protocol (CoAP)", RFC 7252, 2402 DOI 10.17487/RFC7252, June 2014, 2403 . 2405 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2406 Writing an IANA Considerations Section in RFCs", BCP 26, 2407 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2408 . 2410 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2411 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2412 May 2017, . 2414 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 2415 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 2416 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2417 2020, . 2419 9.2. Informative References 2421 [I-D.bormann-core-ace-aif] 2422 Bormann, C., "An Authorization Information Format (AIF) 2423 for ACE", Work in Progress, Internet-Draft, draft-bormann- 2424 core-ace-aif-09, June 27, 2020, . 2427 [I-D.ietf-ace-dtls-authorize] 2428 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 2429 L. Seitz, "Datagram Transport Layer Security (DTLS) 2430 Profile for Authentication and Authorization for 2431 Constrained Environments (ACE)", Work in Progress, 2432 Internet-Draft, draft-ietf-ace-dtls-authorize-12, July 6, 2433 2020, . 2436 [I-D.ietf-ace-mqtt-tls-profile] 2437 Sengul, C., Kirby, A., and P. Fremantle, "MQTT-TLS profile 2438 of ACE", Work in Progress, Internet-Draft, draft-ietf-ace- 2439 mqtt-tls-profile-06, July 13, 2020, . 2442 [I-D.ietf-ace-oscore-profile] 2443 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 2444 "OSCORE profile of the Authentication and Authorization 2445 for Constrained Environments Framework", Work in Progress, 2446 Internet-Draft, draft-ietf-ace-oscore-profile-11, June 18, 2447 2020, . 2450 [I-D.ietf-core-coap-pubsub] 2451 Koster, M., Keranen, A., and J. Jimenez, "Publish- 2452 Subscribe Broker for the Constrained Application Protocol 2453 (CoAP)", Work in Progress, Internet-Draft, draft-ietf- 2454 core-coap-pubsub-09, September 30, 2019, 2455 . 2458 [I-D.ietf-core-groupcomm-bis] 2459 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 2460 for the Constrained Application Protocol (CoAP)", Work in 2461 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 2462 01, July 13, 2020, . 2465 [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management 2466 Protocol (GKMP) Specification", RFC 2093, 2467 DOI 10.17487/RFC2093, July 1997, 2468 . 2470 [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management 2471 Protocol (GKMP) Architecture", RFC 2094, 2472 DOI 10.17487/RFC2094, July 1997, 2473 . 2475 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 2476 Multicast: Issues and Architectures", RFC 2627, 2477 DOI 10.17487/RFC2627, June 1999, 2478 . 2480 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 2481 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 2482 . 2484 [RFC7641] Hartke, K., "Observing Resources in the Constrained 2485 Application Protocol (CoAP)", RFC 7641, 2486 DOI 10.17487/RFC7641, September 2015, 2487 . 2489 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 2490 the Constrained Application Protocol (CoAP)", RFC 7959, 2491 DOI 10.17487/RFC7959, August 2016, 2492 . 2494 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2495 Interchange Format", STD 90, RFC 8259, 2496 DOI 10.17487/RFC8259, December 2017, 2497 . 2499 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 2500 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 2501 May 2018, . 2503 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2504 Definition Language (CDDL): A Notational Convention to 2505 Express Concise Binary Object Representation (CBOR) and 2506 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2507 June 2019, . 2509 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2510 "Object Security for Constrained RESTful Environments 2511 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2512 . 2514 Appendix A. Requirements on Application Profiles 2516 This section lists the requirements on application profiles of this 2517 specification,for the convenience of application profile designers. 2519 * REQ1: If the value of the GROUPNAME URI path and the group name in 2520 the access token scope (gname in Section 3.2) don't match, specify 2521 the mechanism to map the GROUPNAME value in the URI to the group 2522 name (REQ1) (see Section 4.1). 2524 * REQ2: Specify the encoding and value of roles, for scope entries 2525 of 'scope' (see Section 3.1). 2527 * REQ3: If used, specify the acceptable values for 'sign_alg' (see 2528 Section 3.3). 2530 * REQ4: If used, specify the acceptable values for 'sign_parameters' 2531 (see Section 3.3). 2533 * REQ5: If used, specify the acceptable values for 2534 'sign_key_parameters' (see Section 3.3). 2536 * REQ6: If used, specify the acceptable values for 'pub_key_enc' 2537 (see Section 3.3). 2539 * REQ7a: Register a Resource Type for the root url-path, which is 2540 used to discover the correct url to access at the KDC (see 2541 Section 4.1). 2543 * REQ7b: Specify the exact encoding of group identifier (see 2544 Section 4.1.1.1). 2546 * REQ7: Specify the exact format of the 'key' value (see 2547 Section 4.1.2.1). 2549 * REQ8: Specify the acceptable values of 'gkty' (see 2550 Section 4.1.2.1). 2552 * REQ9: Specify the format of the identifiers of group members (see 2553 Section 4.1.2.1). 2555 * REQ10: Specify the communication protocol the members of the group 2556 must use (e.g., multicast CoAP). 2558 * REQ11: Specify the security protocol the group members must use to 2559 protect their communication (e.g., group OSCORE). This must 2560 provide encryption, integrity and replay protection. 2562 * REQ12: Specify and register the application profile identifier 2563 (see Section 4.1.2.1). 2565 * REQ13: Specify policies at the KDC to handle ids that are not 2566 included in get_pub_keys (see Section 4.1.3.1). 2568 * REQ14: If used, specify the format and content of 'group_policies' 2569 and its entries. Specify the policies default values (see 2570 Section 4.1.2.1). 2572 * REQ15: Specify the format of newly-generated individual keying 2573 material for group members, or of the information to derive it, 2574 and corresponding CBOR label (see Section 4.1.6.2). 2576 * REQ16: Specify how the communication is secured between Client and 2577 KDC. Optionally, specify tranport profile of ACE 2578 [I-D.ietf-ace-oauth-authz] to use between Client and KDC (see 2579 Section 4.3. 2581 * REQ17: Specify how the nonce N_S is generated, if the token was 2582 not posted (e.g. if it is used directly to validate TLS instead). 2584 * REQ18: Specify if 'mgt_key_material' used, and if yes specify its 2585 format and content (see Section 4.1.2.1). If the usage of 2586 'mgt_key_material' is indicated and its format defined for a 2587 specific key management scheme, that format must explicitly 2588 indicate the key management scheme itself. If a new rekeying 2589 scheme is defined to be used for an existing 'mgt_key_material' in 2590 an existing profile, then that profile will have to be updated 2591 accordingly, especially with respect to the usage of 2592 'mgt_key_material' related format and content. 2594 * REQ19: Define the initial value of the 'num' parameter (sse 2595 Section 4.1.2.1). 2597 * OPT1: Optionally, specify the encoding of public keys, of 2598 'client_cred', and of 'pub_keys' if COSE_Keys are not used (see 2599 Section 4.1.2.1). 2601 * OPT2: Optionally, specify the negotiation of parameter values for 2602 signature algorithm and signature keys, if 'sign_info' is not used 2603 (see Section 3.3). 2605 * OPT3: Optionally, specify the encoding of 'pub_keys_repos' if the 2606 default is not used (see Section 4.1.2.1). 2608 * OPT4: Optionally, specify policies that instruct clients to retain 2609 messages and for how long, if they are unsuccessfully decrypted 2610 (see Section 4.4). This makes it possible to decrypt such 2611 messages after getting updated keying material. 2613 * OPT5: Optionally, specify the behavior of the handler in case of 2614 failure to retrieve a public key for the specific node (see 2615 Section 4.1.2.1). 2617 * OPT6: Optionally, specify possible or required payload formats for 2618 specific error cases. 2620 * OPT7: Optionally, specify CBOR values to use for abbreviating 2621 identifiers of roles in the group or topic (see Section 3.1). 2623 * OPT8: Optionally, specify for the KDC to perform group rekeying 2624 (together or instead of renewing individual keying material) when 2625 receiving a Key Renewal Request (see Section 4.5). 2627 * OPT9: Optionally, specify the functionalities implemented at the 2628 'control_path' resource hosted at the Client, including message 2629 exchange encoding and other details (see Section 4.1.2.1). 2631 * OPT10: Optionally, specify how the identifier of the sender's 2632 public key is included in the group request (see Section 4.7). 2634 Appendix B. Document Updates 2636 RFC EDITOR: PLEASE REMOVE THIS SECTION. 2638 B.1. Version -04 to -05 2640 * Updated uppercase/lowercase URI segments for KDC resources. 2642 * Supporting single Access Token for multiple groups/topics. 2644 * Added 'control_path' parameter in the Joining Request. 2646 * Added 'peer_roles' parameter to support legal requesters/ 2647 responders. 2649 * Clarification on stopping using owned keying material. 2651 * Clarification on different reasons for processing failures, 2652 related policies, and requirement OPT4. 2654 * Added a KDC sub-resource for group members to upload a new public 2655 key. 2657 * Possible group rekeying following an individual Key Renewal 2658 Request. 2660 * Clarified meaning of requirement REQ3; added requirement OPT8. 2662 * Editorial improvements. 2664 B.2. Version -03 to -04 2666 * Revised RESTful interface, as to methods and parameters. 2668 * Extended processing of joining request, as to check/retrieval of 2669 public keys. 2671 * Revised and extended profile requirements. 2673 * Clarified specific usage of parameters related to signature 2674 algorithms/keys. 2676 * Included general content previously in draft-ietf-ace-key- 2677 groupcomm-oscore 2679 * Registration of media type and content format application/ace- 2680 group+cbor 2682 * Editorial improvements. 2684 B.3. Version -02 to -03 2686 * Exchange of information on the countersignature algorithm and 2687 related parameters, during the Token POST (Section 3.3). 2689 * Restructured KDC interface, with new possible operations 2690 (Section 4). 2692 * Client PoP signature for the Joining Request upon joining 2693 (Section 4.1.2.1). 2695 * Revised text on group member removal (Section 5). 2697 * Added more profile requirements (Appendix A). 2699 B.4. Version -01 to -02 2701 * Editorial fixes. 2703 * Distinction between transport profile and application profile 2704 (Section 1.1). 2706 * New parameters 'sign_info' and 'pub_key_enc' to negotiate 2707 parameter values for signature algorithm and signature keys 2708 (Section 3.3). 2710 * New parameter 'type' to distinguish different Key Distribution 2711 Request messages (Section 4.1). 2713 * New parameter 'client_cred_verify' in the Key Distribution Request 2714 to convey a Client signature (Section 4.1). 2716 * Encoding of 'pub_keys_repos' (Section 4.1). 2718 * Encoding of 'mgt_key_material' (Section 4.1). 2720 * Improved description on retrieval of new or updated keying 2721 material (Section 6). 2723 * Encoding of 'get_pub_keys' in Public Key Request (Section 7.1). 2725 * Extended security considerations (Sections 10.1 and 10.2). 2727 * New "ACE Public Key Encoding" IANA Registry (Section 11.2). 2729 * New "ACE Groupcomm Parameters" IANA Registry (Section 11.3), 2730 populated with the entries in Section 8. 2732 * New "Ace Groupcomm Request Type" IANA Registry (Section 11.4), 2733 populated with the values in Section 9. 2735 * New "ACE Groupcomm Policy" IANA Registry (Section 11.7) populated 2736 with two entries "Sequence Number Synchronization Method" and "Key 2737 Update Check Interval" (Section 4.2). 2739 * Improved list of requirements for application profiles 2740 (Appendix A). 2742 B.5. Version -00 to -01 2743 * Changed name of 'req_aud' to 'audience' in the Authorization 2744 Request (Section 3.1). 2746 * Defined error handling on the KDC (Sections 4.2 and 6.2). 2748 * Updated format of the Key Distribution Response as a whole 2749 (Section 4.2). 2751 * Generalized format of 'pub_keys' in the Key Distribution Response 2752 (Section 4.2). 2754 * Defined format for the message to request leaving the group 2755 (Section 5.2). 2757 * Renewal of individual keying material and methods for group 2758 rekeying initiated by the KDC (Section 6). 2760 * CBOR type for node identifiers in 'get_pub_keys' (Section 7.1). 2762 * Added section on parameter identifiers and their CBOR keys 2763 (Section 8). 2765 * Added request types for requests to a Join Response (Section 9). 2767 * Extended security considerations (Section 10). 2769 * New IANA registries "ACE Groupcomm Key Registry", "ACE Groupcomm 2770 Profile Registry", "ACE Groupcomm Policy Registry" and "Sequence 2771 Number Synchronization Method Registry" (Section 11). 2773 * Added appendix about requirements for application profiles of ACE 2774 on group communication (Appendix A). 2776 Acknowledgments 2778 The following individuals were helpful in shaping this document: 2779 Carsten Bormann, Rikard Hoeglund, Ben Kaduk, John Mattsson, Daniel 2780 Migault, Jim Schaad, Ludwig Seitz, Goeran Selander and Peter van der 2781 Stok. 2783 The work on this document has been partly supported by VINNOVA and 2784 the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact 2785 Initiative ACTIVE. 2787 Authors' Addresses 2788 Francesca Palombini 2789 Ericsson AB 2790 Torshamnsgatan 23 2791 SE-16440 Stockholm Kista 2792 Sweden 2794 Email: francesca.palombini@ericsson.com 2796 Marco Tiloca 2797 RISE AB 2798 Isafjordsgatan 22 2799 SE-16440 Stockholm Kista 2800 Sweden 2802 Email: marco.tiloca@ri.se