idnits 2.17.1 draft-ietf-ace-key-groupcomm-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 November 2020) is 1271 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '01' on line 1582 -- Looks like a reference, but probably isn't: '02' on line 1582 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-35 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cbor-7049bis' == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-09 ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') == Outdated reference: A later version (-15) exists of draft-ietf-cose-rfc8152bis-struct-14 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' == Outdated reference: A later version (-07) exists of draft-ietf-ace-aif-00 == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-14 == Outdated reference: A later version (-17) exists of draft-ietf-ace-mqtt-tls-profile-08 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-13 == 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 (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group F. Palombini 3 Internet-Draft Ericsson AB 4 Intended status: Standards Track M. Tiloca 5 Expires: 6 May 2021 RISE AB 6 2 November 2020 8 Key Provisioning for Group Communication using ACE 9 draft-ietf-ace-key-groupcomm-10 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 6 May 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 . . . . . . . . . . . . . . . . . . . . . . . 10 64 4. Keying Material Provisioning and Group Membership 65 Management . . . . . . . . . . . . . . . . . . . . . . . 14 66 4.1. Interface at the KDC . . . . . . . . . . . . . . . . . . 15 67 4.2. Retrieval of Group Names and URIs . . . . . . . . . . . . 33 68 4.3. Joining Exchange . . . . . . . . . . . . . . . . . . . . 34 69 4.4. Retrieval of Updated Keying Material . . . . . . . . . . 36 70 4.5. Requesting a Change of Keying Material . . . . . . . . . 39 71 4.6. Retrieval of Public Keys and Roles for Group Members . . 40 72 4.7. Update of Public Key . . . . . . . . . . . . . . . . . . 42 73 4.8. Retrieval of Group Policies . . . . . . . . . . . . . . . 43 74 4.9. Retrieval of Keying Material Version . . . . . . . . . . 44 75 4.10. Group Leaving Request . . . . . . . . . . . . . . . . . . 45 76 5. Removal of a Node from the Group . . . . . . . . . . . . . . 45 77 6. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 46 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 48 79 7.1. Update of Keying Material . . . . . . . . . . . . . . . . 49 80 7.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 50 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 82 8.1. Media Type Registrations . . . . . . . . . . . . . . . . 50 83 8.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 51 84 8.3. OAuth Parameters Registry . . . . . . . . . . . . . . . . 51 85 8.4. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 52 86 8.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 52 87 8.6. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 53 88 8.7. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 53 89 8.8. ACE Groupcomm Policy Registry . . . . . . . . . . . . . . 54 90 8.9. Sequence Number Synchronization Method Registry . . . . . 55 91 8.10. Interface Description (if=) Link Target Attribute Values 92 Registry . . . . . . . . . . . . . . . . . . . . . . . . 55 93 8.11. Expert Review Instructions . . . . . . . . . . . . . . . 55 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 95 9.1. Normative References . . . . . . . . . . . . . . . . . . 56 96 9.2. Informative References . . . . . . . . . . . . . . . . . 58 98 Appendix A. Requirements on Application Profiles . . . . . . . . 60 99 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 63 100 B.1. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 63 101 B.2. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 63 102 B.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 64 103 B.4. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 64 104 B.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 65 105 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 66 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66 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 [I-D.ietf-cbor-7049bis], so CBOR is the format used in this 116 specification. However, using JSON [RFC8259] instead of CBOR is 117 possible, using the conversion method specified in Sections 6.1 and 118 6.2 of [I-D.ietf-cbor-7049bis]. 120 Profiles that use group communication can build on this document, by 121 defining a number of details such as the exact group communication 122 protocol and security protocols used. The specific list of details a 123 profile needs to define is shown in Appendix A. 125 If the application requires backward and forward security, new keying 126 material is generated and distributed to the group upon membership 127 changes. A key management scheme performs the actual distribution of 128 the new keying material to the group. In particular, the key 129 management scheme rekeys the current group members when a new node 130 joins the group, and the remaining group members when a node leaves 131 the group. Rekeying mechanisms can be based on [RFC2093], [RFC2094] 132 and [RFC2627]. 134 1.1. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in BCP 139 14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 Readers are expected to be familiar with the terms and concepts 143 described in [I-D.ietf-ace-oauth-authz][I-D.ietf-cose-rfc8152bis-stru 144 ct][I-D.ietf-cose-rfc8152bis-algs], such as Authorization Server (AS) 145 and Resource Server (RS). 147 This document uses names or identifiers for groups and nodes. Their 148 different meanings are summarized here: 150 * "Group name" is the invariant once established identifier of the 151 group. It is used in the communication between AS, RS and Client 152 to identify the group. 154 * "GROUPNAME" is the invariant once established text string used in 155 URIs. GROUPNAME maps to the group name of a group, although it is 156 not necessarily the same. 158 * "Group identifier" is the identifier of the group keying material. 159 Opposite to group name and GROUPNAME, this identifier changes over 160 time, when the keying material is updated. 162 * "Node name" is the invariant once established identifier of the 163 node. It is used in the communication between AS, RS and Client 164 to identify a member of the group. 166 * "NODENAME" is the invariant once established text string used in 167 URIs. NODENAME is used to identify a node in a group. 169 This document additionally uses the following terminology: 171 * Transport profile, to indicate a profile of ACE as per 172 Section 5.6.4.3 of [I-D.ietf-ace-oauth-authz]. A transport 173 profile specifies the communication protocol and communication 174 security protocol between an ACE Client and Resource Server, as 175 well as proof-of-possession methods, if it supports proof-of- 176 possession access tokens, etc. Tranport profiles of ACE include, 177 for instance, [I-D.ietf-ace-oscore-profile], 178 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-mqtt-tls-profile]. 180 * Application profile, that defines how applications enforce and use 181 supporting security services they require. These services may 182 include, for instance, provisioning, revocation and distribution 183 of keying material. An application profile may define specific 184 procedures and message formats. 186 2. Overview 188 The full procedure can be separated in two phases: the first one 189 follows the ACE framework, between Client, AS and KDC; the second one 190 is the key distribution between Client and KDC. After the two phases 191 are completed, the Client is able to participate in the group 192 communication, via a Dispatcher entity. 194 +------------+ +-----------+ 195 | AS | | KDC | 196 | | .-------->| | 197 +------------+ / +-----------+ 198 ^ / 199 | / 200 v / +-----------+ 201 +------------+ / +------------+ |+-----------+ 202 | Client |<-' | Dispatcher | ||+-----------+ 203 | |<-------->| |<------->|| Group | 204 +------------+ +------------+ +| members | 205 +-----------+ 207 Figure 1: Key Distribution Participants 209 The following participants (see Figure 1) take part in the 210 authorization and key distribution. 212 * Client (C): node that wants to join the group communication. It 213 can request write and/or read rights. 215 * Authorization Server (AS): same as AS in the ACE Framework; it 216 enforces access policies, and knows if a node is allowed to join a 217 given group with write and/or read rights. 219 * Key Distribution Center (KDC): maintains the keying material to 220 protect group communications, and provides it to Clients 221 authorized to join a given group. During the first part of the 222 exchange (Section 3), it takes the role of the RS in the ACE 223 Framework. During the second part (Section 4), which is not based 224 on the ACE Framework, it distributes the keying material. In 225 addition, it provides the latest keying material to group members 226 when requested or, if required by the application, when membership 227 changes. 229 * Dispatcher: entity through which the Clients communicate with the 230 group and which distributes messages to the group members. 231 Examples of dispatchers are: the Broker node in a pub-sub setting; 232 a relayer node for group communication that delivers group 233 messages as multiple unicast messages to all group members; an 234 implicit entity as in a multicast communication setting, where 235 messages are transmitted to a multicast IP address and delivered 236 on the transport channel. 238 This document specifies a mechanism for: 240 * Authorizing a new node to join the group (Section 3), and 241 providing it with the group keying material to communicate with 242 the other group members (Section 4). 244 * Allowing a group member to leave the group (Section 5). 246 * Evicting a group member from the group (Section 5). 248 * Allowing a group member to retrieve keying material (Section 4.4 249 and Section 4.5). 251 * Renewing and re-distributing the group keying material (rekeying) 252 upon a membership change in the group (Section 4.10 and 253 Section 5). 255 Figure 2 provides a high level overview of the message flow for a 256 node joining a group communication setting, which can be expanded as 257 follows. 259 1. The joining node requests an Access Token from the AS, in order 260 to access a specific group-membership resource on the KDC and 261 hence join the associated group. This exchange between Client 262 and AS MUST be secured, as specified by the transport profile of 263 ACE used between Client and KDC. The joining node will start or 264 continue using a secure communication association with the KDC, 265 according to the response from the AS. 267 2. The joining node transfers authentication and authorization 268 information to the KDC, by posting the obtained Access Token to 269 the /authz-info endpoint at the KDC. This exchange, and all 270 further communications between the Client and the KDC, MUST occur 271 over the secure channel established as a result of the transport 272 profile of ACE used between Client and KDC. After that, a 273 joining node MUST have a secure communication association 274 established with the KDC, before starting to join a group under 275 that KDC. Possible ways to provide a secure communication 276 association are described in the DTLS transport profile 277 [I-D.ietf-ace-dtls-authorize] and OSCORE transport profile 278 [I-D.ietf-ace-oscore-profile] of ACE. 280 3. The joining node starts the joining process to become a member of 281 the group, by accessing the related group-membership resource at 282 the KDC. At the end of the joining process, the joining node has 283 received from the KDC the parameters and keying material to 284 securely communicate with the other members of the group, and the 285 KDC has stored the association between the authorization 286 information from the access token and the secure session with the 287 joining node. 289 4. The joining node and the KDC maintain the secure association, to 290 support possible future communications. These especially include 291 key management operations, such as retrieval of updated keying 292 material or participation to a group rekeying process. 294 5. The joining node can communicate securely with the other group 295 members, using the keying material provided in step 3. 297 C AS KDC Group 298 | | | Member 299 / | | | | 300 | | Authorization Request | | | 301 Defined | |-------------------------->| | | 302 in the | | | | | 303 ACE | | Authorization Response | | | 304 framework | |<--------------------------| | | 305 | | | | 306 \ |---------- Token Post --------->| | 307 | | | 308 |------- Joining Request ------->| | 309 | | | 310 |<------ Joining Response -------|-- Group Rekeying -->| 311 | | | 312 | Dispatcher | 313 | | | 314 |<===== Secure group communication =======|===========>| 315 | | | 317 Figure 2: Message Flow Upon New Node's Joining 319 3. Authorization to Join a Group 321 This section describes in detail the format of messages exchanged by 322 the participants when a node requests access to a given group. This 323 exchange is based on ACE [I-D.ietf-ace-oauth-authz]. 325 As defined in [I-D.ietf-ace-oauth-authz], the Client requests from 326 the AS an authorization to join the group through the KDC (see 327 Section 3.1). If the request is approved and authorization is 328 granted, the AS provides the Client with a proof-of-possession access 329 token and parameters to securely communicate with the KDC (see 330 Section 3.2). 332 Communications between the Client and the AS MUST be secured, as 333 defined by the transport profile of ACE used. The Content-Format 334 used in the message depends on the used transport profile of ACE. 335 For example, this can be application/ace+cbor for the first two 336 messages and application/cwt for the third message, which are defined 337 in the ACE framework. The transport profile of ACE also defines a 338 number of details such as the communication and security protocols 339 used with the KDC (see Appendix C of [I-D.ietf-ace-oauth-authz]). 341 Figure 3 gives an overview of the exchange described above. 343 Client AS KDC 344 | | | 345 |---- Authorization Request: POST /token ------>| | 346 | | | 347 |<--- Authorization Response: 2.01 (Created) ---| | 348 | | | 349 |----- POST Token: POST /authz-info --------------->| 350 | | 352 Figure 3: Message Flow of Join Authorization 354 3.1. Authorization Request 356 The Authorization Request sent from the Client to the AS is defined 357 in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MAY contain the 358 following parameters, which, if included, MUST have the corresponding 359 values: 361 * 'scope', containing the identifier of the specific group(s), or 362 topic(s) in the case of pub-sub, that the Client wishes to access, 363 and optionally the role(s) that the Client wishes to take. 365 This value is a CBOR byte string, wrapping a CBOR array of one or 366 more entries. 368 By default, each entry is encoded as specified by 369 [I-D.ietf-ace-aif]. The object identifier Toid corresponds to the 370 group name and MUST be encoded as a tstr. The permission set 371 Tperm indicates the roles that the client wishes to take in the 372 group. It is up to the application profiles to define Tperm 373 (REQ2) and register Toid and Tperm to fit the use case. An 374 example of scope using the AIF format is given in Figure 4. 376 Otherwise, each scope entry can be defined as a CBOR array, which 377 contains: 379 - As first element, the identifier of the specific group or 380 topic, encoded as a tstr. 382 - Optionally, as second element, the role (or CBOR array of 383 roles) that the Client wishes to take in the group. This 384 element is optional since roles may have been pre-assigned to 385 the Client, as associated to its verifiable identity 386 credentials. Alternatively, the application may have defined a 387 single, well-known role for the target resource(s) and 388 audience(s). 390 In each entry, the encoding of the role identifiers is application 391 specific, and part of the requirements for the application profile 392 (REQ2). In particular, the application profile may specify CBOR 393 values to use for abbreviating role identifiers (OPT7). 395 An example of CDDL definition [RFC8610] of scope using the format 396 above, with group name and role identifiers encoded as text 397 strings is given in Figure 5. 399 * 'audience', with an identifier of a KDC. 401 As defined in [I-D.ietf-ace-oauth-authz], other additional parameters 402 can be included if necessary. 404 gname = tstr 406 permissions = uint . bits roles 408 roles = &( 409 Requester: 1, 410 Responder: 2, 411 Monitor: 3, 412 Verifier: 4 413 ) 415 scope_entry = AIF_Generic 417 scope = << [ + scope_entry ] >> 419 Figure 4: Example CDLL definition of scope, using the default 420 Authorization Information Format 422 gname = tstr 424 role = tstr 426 scope_entry = [ gname , ? ( role / [ 2*role ] ) ] 428 scope = << [ + scope_entry ] >> 430 Figure 5: CDLL definition of scope, using as example group name 431 encoded as tstr and role as tstr 433 3.2. Authorization Response 435 The Authorization Response sent from the AS to the Client is defined 436 in Section 5.6.2 of [I-D.ietf-ace-oauth-authz]. Note that the 437 parameter 'expires_in' MAY be omitted if the application defines how 438 the expiration time is communicated to the Client via other means, or 439 if it establishes a default value. 441 Additionally, when included, the following parameter MUST have the 442 corresponding values: 444 * 'scope' has the same format and encoding of 'scope' in the 445 Authorization Request, defined in Section 3.1. If this parameter 446 is not present, the granted scope is equal to the one requested in 447 Section 3.1}. 449 The proof-of-possession access token (in 'access_token' above) MUST 450 contain the following parameters: 452 * a confirmation claim (see for example 'cnf' defined in Section 3.1 453 of [RFC8747] for CWT); 455 * an expiration time claim (see for example 'exp' defined in 456 Section 3.1.4 of [RFC8392] for CWT); 458 * a scope claim (see for example 'scope' registered in Section 8.13 459 of [I-D.ietf-ace-oauth-authz] for CWT). This claim has the same 460 encoding as the 'scope' parameter above. Additionally, this claim 461 has the same value of the 'scope' parameter if the parameter is 462 present in the message, or it takes the value of 'scope' in the 463 Authorization Request otherwise. 465 The access token MAY additionally contain other claims that the 466 transport profile of ACE requires, or other optional parameters. 468 When receiving an Authorization Request from a Client that was 469 previously authorized, and for which the AS still owns a valid non- 470 expired access token, the AS MAY reply with that token. Note that it 471 is up to application profiles of ACE to make sure that re-posting the 472 same token does not cause re-use of keying material between nodes 473 (for example, that is done with the use of random nonces in 474 [I-D.ietf-ace-oscore-profile]). 476 3.3. Token Post 478 The Client sends a CoAP POST request including the access token to 479 the KDC, as specified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. 481 This request differs from the one defined in 482 [I-D.ietf-ace-oauth-authz], because it allows to transport additional 483 encoding information about the public keys in the group, used for 484 source authentication, as well as any other group parameters. The 485 joining node MAY ask for this information from the KDC in the same 486 message it uses to POST the token to the RS. 488 The payload of the message MUST be formatted as a CBOR map including 489 the access token. 491 Additionally, the CoAP POST request MAY contain the following 492 parameter, which, if included, MUST have the corresponding values: 494 * 'sign_info' defined in Section 3.3.1, encoding the CBOR simple 495 value Null to require information about the signature algorithm, 496 signature algorithm parameters, signature key parameters and on 497 the exact encoding of public keys used in the group. 499 Alternatively, the joining node may retrieve this information by 500 other means. 502 After successful verification, the Client is authorized to receive 503 the group keying material from the KDC and join the group. 505 The KDC replies to the Client with a 2.01 (Created) response, using 506 Content-Format "application/ace+cbor" defined in Section 8.14 of 507 [I-D.ietf-ace-oauth-authz]. 509 The payload of the 2.01 response is a CBOR map. If the access token 510 contains a role that requires the Client to send its own public key 511 to the KDC when joining the group, the CBOR map MUST include the 512 parameter 'kdcchallenge' defined in Section 3.3.2, specifying a 513 dedicated challenge N_S generated by the KDC. The Client uses this 514 challenge to prove possession of its own private key (see the 515 'client_cred_verify' parameter in Section 4). Note that the payload 516 format of the response deviates from the one defined in the ACE 517 framework (see Section 5.8.1 of [I-D.ietf-ace-oauth-authz]), which 518 has no payload. 520 The KDC MUST store the 'kdcchallenge' value associated to the Client 521 at least until it receives a join request from it (see Section 4.3), 522 to be able to verify that the Client possesses its own private key. 523 The same challenge MAY be reused several times by the Client, to 524 generate a new proof of possession, e.g. in case of update of the 525 public key, or to join a different group with a different signing 526 key, so it is RECOMMENDED that the KDC keeps storing the 527 'kdcchallenge' after the first join is processed as well. If the KDC 528 has already discarded the 'kdcchallenge', that will trigger an error 529 response with a newly generated 'kdcchallenge' that the Client can 530 use to restart the join process, as specified in Section 4.3. 532 If 'sign_info' is included in the request, the KDC MAY include the 533 'sign_info' parameter defined in Section 3.3.1, with the same 534 encoding. Note that the field 'id' takes the value of the group name 535 for which the 'sign_info_entry' applies to. 537 Note that the CBOR map specified as payload of the 2.01 (Created) 538 response may include further parameters, e.g. according to the 539 signalled transport profile of ACE. Application profiles MAY define 540 the additional parameters to use within this exchange (OPT2b). 542 Application profiles of this specification MAY define alternative 543 specific negotiations of parameter values for the signature algorithm 544 and signature keys, if 'sign_info' is not used (OPT2a). 546 3.3.1. 'sign_info' Parameter 548 The 'sign_info' parameter is an OPTIONAL parameter of the Token Post 549 response message defined in Section 5.1.2. of 550 [I-D.ietf-ace-oauth-authz]. This parameter contains information and 551 parameters about the signature algorithm and the public keys to be 552 used between the Client and the RS. Its exact content is application 553 specific. 555 In this specification and in application profiles building on it, 556 this parameter is used to ask and retrieve from the KDC information 557 about the signature algorithm and related parameters used in the 558 group. 560 When used in the request, the 'sign_info' encodes the CBOR simple 561 value Null, to require information and parameters on the signature 562 algorithm and on the public keys used. 564 The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as 565 in the request is given below. 567 sign_info_req = nil 569 The 'sign_info' parameter of the 2.01 (Created) response is a CBOR 570 array of one or more elements. The number of elements is at most the 571 number of groups that the client has been authorized to join. Each 572 element contains information about signing parameters and keys for 573 one or more group or topic, and is formatted as follows. 575 * The first element 'id' is a group name or an array of group names 576 for the group(s) for which this information applies. Below, each 577 specified group name is referred to as 'gname'. 579 * The second element 'sign_alg' is an integer or a text string if 580 the POST request included the 'sign_info' parameter with value 581 Null, and indicates the signature algorithm used in the group(s) 582 identified by (the set of) 'gname'. It is REQUIRED of the 583 application profiles to define specific values that this parameter 584 can take (REQ3), selected from the set of signing algorithms of 585 the COSE Algorithms registry [COSE.Algorithms]. 587 * The third element 'sign_parameters' is a CBOR array indicating the 588 parameters of the signature algorithm used in the group(s) 589 identified by (the set of) 'gname'. Its content depends on the 590 value of 'sign_alg'. It is REQUIRED of the application profiles 591 to define the possible values and structure for the elements of 592 this parameter (REQ4). 594 * The fourth element 'sign_key_parameters' is a CBOR array 595 indicating the parameters of the key used with the signature 596 algorithm, in the group(s) identified by (the set of) 'gname'. 597 Its content depends on the value of 'sign_alg'. It is REQUIRED of 598 the application profiles to define the possible values and 599 structure for the elements of this parameter (REQ5). 601 * The fifth element 'pub_key_enc' parameter is either a CBOR integer 602 indicating the encoding of public keys used in the group(s) 603 identified by (the set of) 'gname', or has value Null indicating 604 that the KDC does not act as repository of public keys for group 605 members. Its acceptable values are taken from the "CWT 606 Confirmation Method" Registry defined in [RFC8747]. It is 607 REQUIRED of the application profiles to define specific values to 608 use for this parameter (REQ6). 610 The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as 611 in the response is given below. 613 sign_info_res = [ + sign_info_entry ] 615 sign_info_entry = 616 [ 617 id : gname / [ + gname ], 618 sign_alg : int / tstr, 619 sign_parameters : [ any ], 620 sign_key_parameters : [ any ], 621 pub_key_enc = int / nil 622 ] 624 gname = tstr 626 3.3.2. 'kdcchallenge' Parameter 628 The 'kdcchallenge' parameter is an OPTIONAL parameter of the Token 629 Post response message defined in Section 5.8.1 of 630 [I-D.ietf-ace-oauth-authz]. This parameter contains a challenge 631 generated by the KDC and provided to the Client. The Client may use 632 this challenge to prove possession of its own private key in the 633 Joining Request (see the 'client_cred_verify' parameter in 634 Section 4). 636 4. Keying Material Provisioning and Group Membership Management 638 This section defines the interface available at the KDC. Moreover, 639 this section specifies how the clients can use this interface to join 640 a group, leave a group, retrieve the group policies or the new keying 641 material. 643 During the first exchange with the KDC ("Joining") after posting the 644 Token, the Client sends a request to the KDC, specifying the group it 645 wishes to join (see Section 4.3). Then, the KDC verifies the access 646 token and that the Client is authorized to join that group. If so, 647 it provides the Client with the keying material to securely 648 communicate with the other members of the group. Whenever used, the 649 Content-Format in messages containing a payload is set to 650 application/ace-groupcomm+cbor, as defined in Section 8.2. 652 When the Client is already a group member, the Client can use the 653 interface at the KDC to perform the following actions: 655 * The Client can get the current keying material, for cases such as 656 expiration, loss or suspected mismatch, due to e.g. reboot or 657 missed group rekeying. This is described in Section 4.4. 659 * The Client can retrieve new keying material for itself. This is 660 described in Section 4.5. 662 * The Client can get the public keys of other group members. This 663 is described in Section 4.6. 665 * The Client can upload a new, updated public key at the KDC. This 666 is described in Section 4.7. 668 * The Client can get the group policies. This is described in 669 Section 4.8. 671 * The Client can get the version number of the keying material 672 currently used in the group. This is described in Section 4.9. 674 * The Client can request to leave the group. This is further 675 discussed in Section 4.10. 677 Upon receiving a request from a Client, the KDC MUST check that it is 678 storing a valid access token from that Client for the group name 679 associated to the endpoint. If that is not the case, i.e. the KDC 680 does not store a valid access token or this is not valid for that 681 Client for the group name, the KDC MUST respond to the Client with a 682 4.01 (Unauthorized) error message. 684 4.1. Interface at the KDC 686 The KDC is configured with the following resources. Note that the 687 root url-path "ace-group" given here are default names: 688 implementations are not required to use these names, and can define 689 their own instead. Each application profile of this specification 690 MUST register a Resource Type for the root url-path (REQ7a), and that 691 Resource Type can be used to discover the correct url to access at 692 the KDC. This Resource Type can also be used at the GROUPNAME sub- 693 resource, to indicate different application profiles for different 694 groups. The Interface Description (if=) Link Target Attribute value 695 ace.group is registered (Section 8.10) and can be used to describe 696 this interface. 698 * /ace-group: this resource is invariant once established and 699 indicates that this specification is used. If other applications 700 run on a KDC implementing this specification and use this same 701 resource, these applications will collide, and a mechanism will be 702 needed to differentiate the endpoints. This resource supports the 703 FETCH method. 705 * /ace-group/GROUPNAME: one sub-resource to /ace-group is 706 implemented for each group the KDC manages. 708 If the value of the GROUPNAME URI path and the group name in the 709 access token scope ('gname' in Section 3.2) do not match, the KDC 710 MUST implement a mechanism to map the GROUPNAME value in the URI 711 to the group name, in order to retrieve the right group (REQ1). 712 Each resource contains the symmetric group keying material for 713 that group. These resources support the GET and POST methods. 715 * /ace-group/GROUPNAME/pub-key: this resource is invariant once 716 established and contains the public keys of all group members. 717 This resource supports the GET and FETCH methods. 719 * /ace-group/GROUPNAME/policies: this resource is invariant once 720 established and contains the group policies. This resource 721 supports the GET method. 723 * /ace-group/GROUPNAME/num: this resource is invariant once 724 established and contains the version number for the symmetric 725 group keying material. This sub-resource supports the GET method. 727 * /ace-group/GROUPNAME/nodes/NODENAME: one sub-resource to /ace- 728 group/GROUPNAME is implemented for each node in the group the KDC 729 manages. These resources are identified by the node name (in this 730 example, the node name has value "NODENAME"). Each resource 731 contains the group and individual keying material for that node. 732 These resources support the GET, PUT and DELETE methods. 734 * /ace-group/GROUPNAME/nodes/NODENAME/pub-key: one sub-resource to 735 /ace-group/GROUPNAME/nodes/NODENAME is implemented for each node 736 in the group the KDC manages. These resources are identified by 737 the node name (in this example, the node name has value 738 "NODENAME"). Each resource contains the individual public keying 739 material for that node. These resources support the POST method. 741 It is REQUIRED of the application profiles of this specification to 742 define what operations (i.e. CoAP methods) are allowed on each 743 resource, for each role defined in Section 3.1 according to REQ2 744 (REQ7aa). 746 The details for the handlers of each resource are given in the 747 following sections. These endpoints are used to perform the 748 operations introduced in Section 4. 750 4.1.1. ace-group 752 This resource implements a FETCH handler. 754 4.1.1.1. FETCH Handler 756 The FETCH handler receives group identifiers and returns the 757 corresponding group names and GROUPNAME URIs. 759 The handler expects a request with payload formatted as a CBOR map. 760 The payload of this request is a CBOR Map that MUST contain the 761 following fields: 763 * 'gid', whose value is encoded as a CBOR array, containing one or 764 more group identifiers. The exact encoding of group identifier 765 MUST be specified by the application profile (REQ7b). The Client 766 indicates that it wishes to receive the group names and GROUPNAMEs 767 of all groups having these identifiers. 769 The handler identifies the groups that are secured by the keying 770 material identified by those group identifiers. 772 Then, the handler returns a 2.05 (Content) message response with 773 payload formatted as a CBOR map that MUST contain the following 774 fields: 776 * 'gid', whose value is encoded as a CBOR array, containing zero or 777 more group identifiers. The handler indicates that those are the 778 identifiers it is sending group names and GROUPNAMEs for. This 779 CBOR array is a subset of the 'gid' array in the FETCH request. 781 * 'gname', whose value is encoded as a CBOR array, containing zero 782 or more group names. The elements of this array are encoded as 783 text strings. Each element of index i of this CBOR array 784 corresponds to the element of group identifier i in the 'gid' 785 array. 787 * 'guri', whose value is encoded as a CBOR array, containing zero or 788 more URIs, each indicating a GROUPNAME resource. The elements of 789 this array are encoded as text strings. Each element of index i 790 of this CBOR array corresponds to the element of group identifier 791 i in the 'gid' array. 793 If the KDC does not find any group associated with the specified 794 group identifiers, the handler returns a response with payload 795 formatted as a CBOR byte string of zero length. 797 Note that the KDC only verifies that the node is authorized by the AS 798 to access this resource. Nodes that are not members of the group but 799 are authorized to do signature verifications on the group messages 800 may be allowed to access this resource, if the application needs it. 802 4.1.2. ace-group/GROUPNAME 804 This resource implements GET and POST handlers. 806 4.1.2.1. POST Handler 808 The POST handler adds the public key of the client to the list of the 809 group members' public keys and returns the symmetric group keying 810 material for the group identified by "GROUPNAME". Note that the 811 group joining exchange is done by the client via this operation, as 812 described in Section 4.3. 814 The handler expects a request with payload formatted as a CBOR map 815 which MAY contain the following fields, which, if included, MUST have 816 the corresponding values: 818 * 'scope', with value the specific resource at the KDC that the 819 Client is authorized to access, i.e. group or topic name, and 820 role(s). This value is a CBOR byte string wrapping one scope 821 entry, as defined in Section 3.1. 823 * 'get_pub_keys', if the Client wishes to receive the public keys of 824 the other nodes in the group from the KDC. This parameter may be 825 present if the KDC stores the public keys of the nodes in the 826 group and distributes them to the Client; it is useless to have 827 here if the set of public keys of the members of the group is 828 known in another way, e.g. it was provided by the AS. Note that 829 including this parameter may result in a large message size for 830 the following response, which can be inconvenient for resource- 831 constrained devices. The parameter's value is either the CBOR 832 simple value Null or a non-empty CBOR array containing two CBOR 833 arrays: 835 - The first array is non-empty. Each element of the first array 836 contains one role or a combination of roles for the group 837 identified by "GROUPNAME". The Client indicates that it wishes 838 to receive the public keys of all group members having any of 839 the single roles, or at least all of the roles indicated in any 840 combinations of roles. For example, the array ["role1", 841 "role2+role3"] indicates that the Client wishes to receive the 842 public keys of all group members that have at least "role1" or 843 at least both "role2" and "role3". 845 - The second array is empty. 847 If the Client wishes to receive all public keys of all group 848 members, it encodes the 'get_pub_key' parameter as the CBOR simple 849 value Null. 851 The CDDL definition [RFC8610] of 'get_pub_keys' is given in 852 Figure 6, using as example encoding: node identifier encoded as a 853 CBOR byte string; role identifier encoded as a CBOR text string, 854 and combination of roles encoded as a CBOR array of roles. 856 Note that the second array (array of node identifiers) is empty 857 for this handler, because the joining node is not expected to 858 filter based on node identifiers, but is not necessarily empty for 859 the value of 'get_pub_keys' received by the handler of FETCH to 860 ace-group/GROUPNAME/pub-key (see Section 4.1.3.1). 862 Also note that the second array (array of roles) is non-empty for 863 this handler, but that is not necessarily the case for other 864 handlers using this parameter: if this array is empty it means 865 that the client is not filtering public keys based on roles. 867 Finally, 'get_pub_keys' is never used as an array containing two 868 empty arrays (in CBOR diagnostic notation: [ [ ], [ ] ] ), so if 869 this parameter is received as formatted in that way, it has to be 870 considered malformed. 872 id = bstr 874 role = tstr 876 comb_role = [ 2*role ] 878 get_pub_keys = null / [ [ *(role / comb_role) ], [ *id ] ] 880 Figure 6: CDLL definition of get_pub_keys, using as example node 881 identifier encoded as bstr and role as tstr 883 * 'client_cred', with value the public key or certificate of the 884 Client, encoded as a CBOR byte string. This field contains the 885 public key of the Client. This field is used if the KDC is 886 managing (collecting from/distributing to the Client) the public 887 keys of the group members, and if the Client's role in the group 888 will require for it to send messages to one or more group members. 889 The default encoding for public keys is COSE Keys. Alternative 890 specific encodings of this parameter MAY be defined in 891 applications of this specification (OPT1 in Appendix A). 893 * 'cnonce', encoded as a CBOR byte string, and including a dedicated 894 nonce N_C generated by the Client. This parameter MUST be present 895 if the 'client_cred' parameter is present. 897 * 'client_cred_verify', encoded as a CBOR byte string. This 898 parameter MUST be present if the 'client_cred' parameter is 899 present and no public key associated to the client's token can be 900 retrieved for that group. This parameter contains a signature 901 computed by the Client over the following signature input: the 902 scope (encoded as CBOR byte string), concatenated with N_S 903 (encoded as CBOR byte string) concatenated with N_C (encoded as 904 CBOR byte string), where: 906 - scope is the CBOR byte string either specified in the 'scope' 907 parameter above, if present, or as a default scope that the 908 handler is expected to understand, if omitted. 910 - N_S is the challenge received from the KDC in the 911 'kdcchallenge' parameter of the 2.01 (Created) response to the 912 token POST request (see Section 3.3), encoded as a CBOR byte 913 string. 915 - N_C is the nonce generated by the Client and specified in the 916 'cnonce' parameter above, encoded as a CBOR byte string. 918 An example of signature input construction to compute 919 'client_cred_verify' using CBOR encoding is given in Figure 7. 921 If the token was not posted (e.g. if it is used directly to 922 validate TLS instead), it is REQUIRED of the specific profile to 923 define how the challenge N_S is generated (REQ17). The Client 924 computes the signature by using its own private key, whose 925 corresponding public key is either directly specified in the 926 'client_cred' parameter or included in the certificate specified 927 in the 'client_cred' parameter. 929 * 'pub_keys_repos', can be present if a certificate is present in 930 the 'client_cred' field, with value the URI of the certificate of 931 the Client. This parameter is encoded as a CBOR text string. 932 Alternative specific encodings of this parameter MAY be defined in 933 applications of this specification (OPT3). 935 * 'control_path', with value a full URI, encoded as a CBOR text 936 string. If 'control_path' is supported by the Client, the Client 937 acts as a CoAP server and hosts a resource at this specific URI. 938 The KDC MAY use this URI to send CoAP requests to the Client 939 (acting as CoAP server in this exchange), for example for 940 individual provisioning of new keying material when performing a 941 group rekeying (see Section 4.4), or to inform the Client of its 942 removal from the group Section 5. If the KDC does not implement 943 mechanisms using this resource, it can just ignore this parameter. 944 Other additional functionalities of this resource MAY be defined 945 in application profiles of this specifications (OPT9). In 946 particular, this resource is intended for communications 947 concerning exclusively the group or topic specified in the 'scope' 948 parameter. 950 scope, N_S, and N_C expressed in CBOR diagnostic notation: 951 scope = h'826667726F7570316673656E646572' 952 N_S = h'018a278f7faab55a' 953 N_C = h'25a8991cd700ac01' 955 scope, N_S, and N_C as CBOR encoded byte strings: 956 scope = 0x4f826667726F7570316673656E646572 957 N_S = 0x48018a278f7faab55a 958 N_C = 0x4825a8991cd700ac01 960 input to client_cred_verify signature = 961 0x4f 826667726F7570316673656E646572 48 018a278f7faab55a 48 25a8991cd700ac01 963 Figure 7: Example of signature input construction to compute 964 'client_cred_verify' using CBOR encoding 966 The handler extracts the granted scope from the access token, and 967 checks the requested one against the token one. If the requested one 968 is not a subset of the token one, the KDC MUST respond with a 4.01 969 (Unauthorized) error message. If this join message does not include 970 a 'scope' field, the KDC is expected to understand which group and 971 role(s) the Client is requesting (e.g. there is only one the Client 972 has been granted). If the KDC can not recognize which scope the 973 Client is requesting, it MUST respond with a 4.00 (Bad Request) error 974 message. 976 The KDC verifies that the group name of the /ace-group/GROUPNAME path 977 is a subset of the 'scope' stored in the access token associated to 978 this client. The KDC also verifies that the roles the client is 979 granted in the group allow it to perform this operation on this 980 resource (REQ7aa). If either verification fails, the KDC MUST 981 respond with a 4.01 (Unauthorized) error message. The KDC MAY 982 respond with an AS Request Creation Hints, as defined in 983 Section 5.1.2 of [I-D.ietf-ace-oauth-authz]. Note that in this case, 984 the content format MUST be set to application/ace+cbor. 986 If the request is not formatted correctly (i.e. required fields non 987 received or received with incorrect format), the handler MUST respond 988 with a 4.00 (Bad Request) error message. The response MAY contain a 989 CBOR map in the payload with content format application/ace+cbor, 990 e.g. it could send back 'sign_info_res' with 'pub_key_enc' set to 991 Null if the Client sent its own public key and the KDC is not set to 992 store public keys of the group members. If the request contained 993 unknown or non-expected fields present, the handler MUST silently 994 drop them and continue processing. Application profiles MAY define 995 optional or mandatory payload formats for specific error cases 996 (OPT6). 998 If the KDC stores the group members' public keys, the handler checks 999 if one is included in the 'client_cred' field, retrieves it and 1000 associates it to the access token received, after verifications 1001 succeeded. In particular, the KDC verifies: 1003 * that such public key has an acceptable format for the group 1004 identified by "GROUPNAME", i.e. it is encoded as expected and is 1005 compatible with the signature algorithm and possible associated 1006 parameters. 1008 * that the signature contained in "client_cred_verify" passes 1009 verification. 1011 If that cannot be verified, it is RECOMMENDED that the handler stops 1012 the process and responds with a 4.00 (Bad Request) error message. 1013 Applications profiles MAY define alternatives (OPT5). 1015 If one public key is already associated to the access token and to 1016 that group, but the 'client_cred' is populated with a different 1017 public key, the handler MUST delete the previous one and replace it 1018 with this one, after verifying the points above. 1020 If no public key is included in the 'client_cred' field, the handler 1021 checks if one public key is already associated to the access token 1022 received (see Section 4.3 for an example) and to the group identified 1023 by "GROUPNAME". If that is not the case, the handler responds with a 1024 4.00 Bad Request error response. 1026 If the token was posted but the KDC cannot retrieve the 1027 'kdcchallenge' associated to this Client (see Section 3.3), the KDC 1028 MUST respond with a 4.00 Bad Request error response, including a 1029 newly generated 'kdcchallenge' in a CBOR map in the payload. This 1030 error response MUST also have Content-Format application/ace+cbor. 1032 If all verifications succeed, the handler: 1034 * Adds the node to the list of current members of the group. 1036 * Assigns a name NODENAME to the node, and creates a sub-resource to 1037 /ace-group/GROUPNAME/ at the KDC (e.g. "/ace- 1038 group/GROUPNAME/nodes/NODENAME"). 1040 * Associates the identifier "NODENAME" with the access token and the 1041 secure session for that node. 1043 * If the KDC manages public keys for group members: 1045 - Adds the retrieved public key of the node to the list of public 1046 keys stored for the group identified by "GROUPNAME" 1048 - Associates the node's public key with its access token and the 1049 group identified by "GROUPNAME", if such association did not 1050 already exist. 1052 * Returns a 2.01 (Created) message containing the symmetric group 1053 keying material, the group policies and all the public keys of the 1054 current members of the group, if the KDC manages those and the 1055 Client requested them. 1057 The response message also contains the URI path to the sub-resource 1058 created for that node in a Location-Path CoAP option. The payload of 1059 the response is formatted as a CBOR map which MUST contain the 1060 following fields and values: 1062 * 'gkty', identifying the key type of the 'key' parameter. The set 1063 of values can be found in the "Key Type" column of the "ACE 1064 Groupcomm Key" Registry. Implementations MUST verify that the key 1065 type matches the application profile being used, if present, as 1066 registered in the "ACE Groupcomm Key" registry. 1068 * 'key', containing the keying material for the group communication, 1069 or information required to derive it. 1071 * 'num', containing the version number of the keying material for 1072 the group communication, formatted as an integer. This is a 1073 strictly monotonic increasing field. The application profile MUST 1074 define the initial version number (REQ19). 1076 The exact format of the 'key' value MUST be defined in applications 1077 of this specification (REQ7), as well as values of 'gkty' accepted by 1078 the application (REQ8). Additionally, documents specifying the key 1079 format MUST register it in the "ACE Groupcomm Key" registry defined 1080 in Section 8.6, including its name, type and application profile to 1081 be used with. 1083 +----------+----------------+---------+-------------------------+ 1084 | Name | Key Type Value | Profile | Description | 1085 +----------+----------------+---------+-------------------------+ 1086 | Reserved | 0 | | This value is reserved | 1087 +----------+----------------+---------+-------------------------+ 1088 Figure 8: Key Type Values 1090 The response SHOULD contain the following parameter: 1092 * 'exp', with value the expiration time of the keying material for 1093 the group communication, encoded as a CBOR unsigned integer. This 1094 field contains a numeric value representing the number of seconds 1095 from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, 1096 ignoring leap seconds, analogous to what specified for NumericDate 1097 in Section 2 of [RFC7519]. Group members MUST stop using the 1098 keying material to protect outgoing messages and retrieve new 1099 keying material at the time indicated in this field. 1101 Optionally, the response MAY contain the following parameters, which, 1102 if included, MUST have the corresponding values: 1104 * 'ace-groupcomm-profile', with value a CBOR integer that MUST be 1105 used to uniquely identify the application profile for group 1106 communication. Applications of this specification MUST register 1107 an application profile identifier and the related value for this 1108 parameter in the "ACE Groupcomm Profile" Registry (REQ12). 1110 * 'pub_keys', may only be present if 'get_pub_keys' was present in 1111 the request. This parameter is a CBOR byte string, which encodes 1112 the public keys of all the group members paired with the 1113 respective member identifiers. The default encoding for public 1114 keys is COSE Keys, so the default encoding for 'pub_keys' is a 1115 CBOR byte string wrapping a COSE_KeySet (see 1116 [I-D.ietf-cose-rfc8152bis-struct]), which contains the public keys 1117 of all the members of the group. In particular, each COSE Key in 1118 the COSE_KeySet includes the node identifier of the corresponding 1119 group member as value of its 'kid' key parameter. Alternative 1120 specific encodings of this parameter MAY be defined in 1121 applications of this specification (OPT1). The specific format of 1122 the node identifiers of group members MUST be specified in the 1123 application profile (REQ9). 1125 * 'peer_roles', MUST be present if 'pub_keys' is present. This 1126 parameter is a CBOR array of n elements, with n the number of 1127 public keys included in the 'pub_keys' parameter (at most the 1128 number of members in the group). The i-th element of the array 1129 specifies the role (or CBOR array of roles) that the group member 1130 associated to the i-th public key in 'pub_keys' has in the group. 1131 In particular, each array element is encoded as the role element 1132 of a scope entry, as defined in Section 3.1. 1134 * 'group_policies', with value a CBOR map, whose entries specify how 1135 the group handles specific management aspects. These include, for 1136 instance, approaches to achieve synchronization of sequence 1137 numbers among group members. The elements of this field are 1138 registered in the "ACE Groupcomm Policy" Registry. This 1139 specification defines the three elements "Sequence Number 1140 Synchronization Method", "Key Update Check Interval" and 1141 "Expiration Delta", which are summarized in Figure 9. Application 1142 profiles that build on this document MUST specify the exact 1143 content format and default value of included map entries (REQ14). 1145 +--------------+-------+----------|---------------------|------------+ 1146 | Name | CBOR | CBOR | Description | Reference | 1147 | | label | type | | | 1148 |--------------+-------+----------|---------------------|------------| 1149 | Sequence | TBD1 | tstr/int | Method for a re- | [[this | 1150 | Number | | | cipient node to | document]] | 1151 | Synchroniza- | | | synchronize with | | 1152 | tion Method | | | sequence numbers | | 1153 | | | | of a sender node. | | 1154 | | | | Its value is taken | | 1155 | | | | from the 'Value' | | 1156 | | | | column of the | | 1157 | | | | Sequence Number | | 1158 | | | | Synchronization | | 1159 | | | | Method registry | | 1160 | | | | | | 1161 | Key Update | TBD2 | int | Polling interval | [[this | 1162 | Check | | | in seconds, to | document]] | 1163 | Interval | | | check for new | | 1164 | | | | keying material at | | 1165 | | | | the KDC | | 1166 | | | | | | 1167 | Expiration | TBD3 | uint | Number of seconds | [[this | 1168 | Delta | | | from 'exp' until | document]] | 1169 | | | | the specified UTC | | 1170 | | | | date/time after | | 1171 | | | | which group members | | 1172 | | | | MUST stop using the | | 1173 | | | | keying material to | | 1174 | | | | verify incoming | | 1175 | | | | messages. | | 1176 +--------------+-------+----------|---------------------|------------+ 1178 Figure 9: ACE Groupcomm Policies 1180 * 'mgt_key_material', encoded as a CBOR byte string and containing 1181 the administrative keying material to participate in the group 1182 rekeying performed by the KDC. The application profile MUST 1183 define if this field is used, and if used then MUST specify the 1184 exact format and content which depend on the specific rekeying 1185 scheme used in the group. If the usage of 'mgt_key_material' is 1186 indicated and its format defined for a specific key management 1187 scheme, that format must explicitly indicate the key management 1188 scheme itself. If a new rekeying scheme is defined to be used for 1189 an existing 'mgt_key_material' in an existing profile, then that 1190 profile will have to be updated accordingly, especially with 1191 respect to the usage of 'mgt_key_material' related format and 1192 content (REQ18). 1194 Specific application profiles that build on this document MUST 1195 specify the communication protocol that members of the group use to 1196 communicate with each other (REQ10) and how exactly the keying 1197 material is used to protect the group communication (REQ11). 1199 CBOR labels for these fields are defined in Section 6. 1201 4.1.2.2. GET Handler 1203 The GET handler returns the symmetric group keying material for the 1204 group identified by "GROUPNAME". 1206 The handler expects a GET request. 1208 The KDC verifies that the group name of the /ace-group/GROUPNAME path 1209 is a subset of the 'scope' stored in the access token associated to 1210 this client. The KDC also verifies that the roles the client is 1211 granted in the group allow it to perform this operation on this 1212 resource (REQ7aa). If either verification fails, the KDC MUST 1213 respond with a 4.01 (Unauthorized) error message. The KDC MAY 1214 respond with an AS Request Creation Hints, as defined in 1215 Section 5.1.2 of [I-D.ietf-ace-oauth-authz]. Note that in this case 1216 the content format MUST be set to application/ace+cbor. 1218 Additionally, the handler verifies that the node is a current member 1219 of the group. If verification fails, the KDC MUST respond with a 1220 4.01 (Unauthorized) error message. 1222 If verification succeeds, the handler returns a 2.05 (Content) 1223 message containing the symmetric group keying material. The payload 1224 of the response is formatted as a CBOR map which MUST contain the 1225 parameters 'gkty', 'key' and 'num' specified in Section 4.1.2.1. 1227 The payload MAY also include the parameters 'ace-groupcomm-profile', 1228 'exp', and 'mgt_key_material' parameters specified in 1229 Section 4.1.2.1. 1231 4.1.3. ace-group/GROUPNAME/pub-key 1233 If the KDC does not maintain public keys for the group, the handler 1234 for any request on this resource returns a 4.05 (Method Not Allowed) 1235 error message. If it does, the rest of this section applies. 1237 This resource implements GET and FETCH handlers. 1239 4.1.3.1. FETCH Handler 1241 The FETCH handler receives identifiers of group members for the group 1242 identified by "GROUPNAME" and returns the public keys of such group 1243 members. 1245 The handler expects a request with payload formatted as a CBOR map, 1246 that MUST contain the following fields: 1248 * 'get_pub_keys', whose value is encoded as in Section 4.1.2.1 with 1249 the following modification: 1251 - The first array may be empty, if the Client does not wish to 1252 filter the requested public keys based on roles of group 1253 members. 1255 - The second array contains zero or more node identifiers of 1256 group members, for the group identified by "GROUPNAME". The 1257 Client indicates that it wishes to receive the public keys of 1258 all nodes having these node identifiers. 1260 As mentioned, both arrays can not be empty at the same time. 1262 The specific format of public keys as well as identifiers, roles and 1263 combination of roles of group members MUST be specified by the 1264 application profile (OPT1, REQ2, REQ9). 1266 The KDC verifies that the group name of the /ace-group/GROUPNAME path 1267 is a subset of the 'scope' stored in the access token associated to 1268 this client. The KDC also verifies that the roles the client is 1269 granted in the group allow it to perform this operation on this 1270 resource (REQ7aa). If either verification fails, the KDC MUST 1271 respond with a 4.01 (Unauthorized) error message. 1273 If verification succeeds, the handler identifies the public keys of 1274 the current group members for which either: 1276 * the role identifier matches with one of those indicated in the 1277 request; note that the request can contain a "combination of 1278 roles", where the handler select all group members who have all 1279 roles included in the combination. 1281 * the node identifier matches with one of those indicated in the 1282 request. 1284 Then, the handler returns a 2.05 (Content) message response with 1285 payload formatted as a CBOR map, containing only the 'pub_keys' and 1286 'peer_roles' parameters from Section 4.1.2.1. In particular, 1287 'pub_keys' encodes the list of public keys of those group members 1288 including the respective member identifiers, while 'peer_roles' 1289 encodes their respective role (or CBOR array of roles) in the group. 1290 The specific format of public keys as well as of node identifiers of 1291 group members is specified by the application profile (OPT1, REQ9). 1293 If the KDC does not store any public key associated with the 1294 specified node identifiers, the handler returns a response with 1295 payload formatted as a CBOR byte string of zero length. 1297 The handler MAY enforce one of the following policies, in order to 1298 handle possible node identifiers that are included in the 1299 'get_pub_keys' parameter of the request but are not associated to any 1300 current group member. Such a policy MUST be specified by the 1301 application profile (REQ13). 1303 * The KDC silently ignores those node identifiers. 1305 * The KDC retains public keys of group members for a given amount of 1306 time after their leaving, before discarding them. As long as such 1307 public keys are retained, the KDC provides them to a requesting 1308 Client. 1310 Note that this resource handler only verifies that the node is 1311 authorized by the AS to access this resource. Nodes that are not 1312 members of the group but are authorized to do signature verifications 1313 on the group messages may be allowed to access this resource, if the 1314 application needs it. 1316 4.1.3.2. GET Handler 1318 The handler expects a GET request. 1320 The KDC performs the same verifications as the FETCH handler in 1321 Section 4.1.3.1, and if successful returns the same response as in 1322 Section 4.1.3.1 but without filtering based on roles or node 1323 identifiers: all the group members' public keys are returned. 1325 Note that this resource handler, as the FETCH handler for the same 1326 resource, only verifies that the node is authorized by the AS to 1327 access this resource. Nodes that are not members of the group but 1328 are authorized to do signature verifications on the group messages 1329 may be allowed to access this resource, if the application needs it. 1331 4.1.4. ace-group/GROUPNAME/policies 1333 This resource implements a GET handler. 1335 4.1.4.1. GET Handler 1337 The handler expects a GET request. 1339 The KDC verifies that the group name of the /ace-group/GROUPNAME path 1340 is a subset of the 'scope' stored in the access token associated to 1341 this client. The KDC also verifies that the roles the client is 1342 granted in the group allow it to perform this operation on this 1343 resource (REQ7aa). If either verification fails, the KDC MUST 1344 respond with a 4.01 (Unauthorized) error message. 1346 Additionally, the handler verifies that the node is a current member 1347 of the group. If verification fails, the KDC MUST respond with a 1348 4.01 (Unauthorized) error message. 1350 If verification succeeds, the handler returns a 2.05 (Content) 1351 message containing the list of policies for the group identified by 1352 "GROUPNAME". The payload of the response is formatted as a CBOR map 1353 including only the parameter 'group_policies' defined in 1354 Section 4.1.2.1 and specifying the current policies in the group. If 1355 the KDC does not store any policy, the payload is formatted as a 1356 zero-length CBOR byte string. 1358 The specific format and meaning of group policies MUST be specified 1359 in the application profile (REQ14). 1361 4.1.5. ace-group/GROUPNAME/num 1363 This resource implements a GET handler. 1365 4.1.5.1. GET Handler 1367 The handler expects a GET request. 1369 The KDC verifies that the group name of the /ace-group/GROUPNAME path 1370 is a subset of the 'scope' stored in the access token associated to 1371 this client. The KDC also verifies that the roles the client is 1372 granted in the group allow it to perform this operation on this 1373 resource (REQ7aa). If either verification fails, the KDC MUST 1374 respond with a 4.01 (Unauthorized) error message. 1376 Additionally, the handler verifies that the node is a current member 1377 of the group. If verification fails, the KDC MUST respond with a 1378 4.01 (Unauthorized) error message. 1380 If verification succeeds, the handler returns a 2.05 (Content) 1381 message containing an integer that represents the version number of 1382 the symmetric group keying material. This number is incremented on 1383 the KDC every time the KDC updates the symmetric group keying 1384 material, before the new keying material is distributed. This number 1385 is stored in persistent storage. 1387 The payload of the response is formatted as a CBOR integer. 1389 4.1.6. ace-group/GROUPNAME/nodes/NODENAME 1391 This resource implements GET, PUT and DELETE handlers. 1393 4.1.6.1. PUT Handler 1395 The PUT handler is used to get the KDC to produce and return 1396 individual keying material to protect outgoing messages for the node 1397 (identified by "NODENAME") for the group identified by "GROUPNAME". 1398 Application profiles MAY also use this handler to rekey the whole 1399 group. It is up to the application profiles to specify if this 1400 handler supports renewal of individual keying material, renewal of 1401 the group keying material or both (OPT8). 1403 The handler expects a request with empty payload. 1405 The KDC verifies that the group name of the /ace-group/GROUPNAME path 1406 is a subset of the 'scope' stored in the access token associated to 1407 this client, identified by "NODENAME". The KDC also verifies that 1408 the roles the client is granted in the group allow it to perform this 1409 operation on this resource (REQ7aa). If either verification fails, 1410 the KDC MUST respond with a 4.01 (Unauthorized) error message. 1412 Additionally, the handler verifies that the node is a current member 1413 of the group. If verification fails, the KDC MUST respond with a 1414 4.01 (Unauthorized) error message. 1416 If verification succeeds, the handler returns a 2.05 (Content) 1417 message containing newly-generated keying material for the Client, 1418 and/or, if the application profiles requires it (OPT8), starts the 1419 complete group rekeying. The payload of the response is formatted as 1420 a CBOR map. The specific format of newly-generated individual keying 1421 material for group members, or of the information to derive it, and 1422 corresponding CBOR label, MUST be specified in the application 1423 profile (REQ15) and registered in Section 8.5. 1425 4.1.6.2. GET Handler 1427 The handler expects a GET request. 1429 The KDC verifies that the group name of the /ace-group/GROUPNAME path 1430 is a subset of the 'scope' stored in the access token associated to 1431 this client, identified by "NODENAME". The KDC also verifies that 1432 the roles the client is granted in the group allow it to perform this 1433 operation on this resource (REQ7aa). If either verification fails, 1434 the KDC MUST respond with a 4.01 (Unauthorized) error message. 1436 The handler also verifies that the node sending the request and the 1437 node name used in the Uri-Path match. If that is not the case, the 1438 handler responds with a 4.01 (Unauthorized) error response. 1440 Additionally, the handler verifies that the node is a current member 1441 of the group. If verification fails, the KDC MUST respond with a 1442 4.01 (Unauthorized) error message. 1444 If verification succeeds, the handler returns a 2.05 (Content) 1445 message containing both the group keying material and the individual 1446 keying material for the Client, or information enabling the Client to 1447 derive it. The payload of the response is formatted as a CBOR map. 1448 The format for the group keying material is the same as defined in 1449 the response of Section 4.1.2.2. The specific format of individual 1450 keying material for group members, or of the information to derive 1451 it, and corresponding CBOR label, MUST be specified in the 1452 application profile (REQ15) and registered in Section 8.5. 1454 4.1.6.3. DELETE Handler 1456 The DELETE handler removes the node identified by "NODENAME" from the 1457 group identified by "GROUPNAME". 1459 The handler expects a request with method DELETE (and empty payload). 1461 The handler verifies that the group name of the /ace-group/GROUPNAME 1462 path is a subset of the 'scope' stored in the access token associated 1463 to this client, identified by "NODENAME". The KDC also verifies that 1464 the roles the client is granted in the group allow it to perform this 1465 operation on this resource (REQ7aa). If either verification fails, 1466 the KDC MUST respond with a 4.01 (Unauthorized) error message. 1468 The handler also verifies that the node sending the request and the 1469 node name used in the Uri-Path match. If that is not the case, the 1470 handler responds with a 4.01 (Unauthorized) error response. 1472 Additionally, the handler verifies that the node is a current member 1473 of the group. If verification fails, the KDC MUST respond with a 1474 4.01 (Unauthorized) error message. 1476 If verification succeeds, the handler removes the client from the 1477 group identified by "GROUPNAME", for specific roles if roles were 1478 specified in the 'scope' field, or for all roles. That includes 1479 removing the public key of the client if the KDC keep tracks of that. 1480 Then, the handler delete the sub-resource nodes/NODENAME and returns 1481 a 2.02 (Deleted) message with empty payload. 1483 4.1.7. ace-group/GROUPNAME/nodes/NODENAME/pub-key 1485 This resource implements a POST handler, if the KDC stores the public 1486 key of group members. If the KDC does not store the public keys of 1487 group members, the handler does not implement any method, and every 1488 request returns a 4.05 Method Not Allowed error. 1490 4.1.7.1. POST Handler 1492 The POST handler is used to replace the stored public key of this 1493 client (identified by "NODENAME") with the one specified in the 1494 request at the KDC, for the group identified by "GROUPNAME". 1496 The handler expects a POST request with payload as specified in 1497 Section 4.1.2.1, with the difference that it includes only the 1498 parameters 'client_cred', 'cnonce' and 'client_cred_verify'. In 1499 particular, the signature included in 'client_cred_verify' is 1500 expected to be computed as defined in Section 4.1.2.1, with a newly 1501 generated N_C nonce and the previously received N_S. The specific 1502 format of public keys is specified by the application profile (OPT1). 1504 The handler verifies that the group name GROUPNAME is a subset of the 1505 'scope' stored in the access token associated to this client. The 1506 KDC also verifies that the roles the client is granted in the group 1507 allow it to perform this operation on this resource (REQ7aa). If 1508 either verification fails, the KDC MUST respond with a 4.01 1509 (Unauthorized) error message. 1511 If the request is not formatted correctly (i.e. required fields non 1512 received or received with incorrect format), the handler MUST respond 1513 with a 4.00 (Bad Request) error message. If the request contains 1514 unknown or non-expected fields present, the handler MUST silently 1515 ignore them and continue processing. Application profiles MAY define 1516 optional or mandatory payload formats for specific error cases 1517 (OPT6). 1519 Otherwise, the handler checks that the public key specified in the 1520 'client_cred' field has a valid format for the group identified by 1521 "GROUPNAME", i.e. it is encoded as expected and is compatible with 1522 the signature algorithm and possible associated parameters. If that 1523 cannot be successfully verified, the handler MUST respond with a 4.00 1524 (Bad Request) error message. Applications profiles MAY define 1525 alternatives (OPT5). 1527 Otherwise, the handler verifies the signature contained in the 1528 'client_cred_verify' field of the request, using the public key 1529 specified in the 'client_cred' field. If the signature does not pass 1530 verification, the handler MUST respond with a 4.01 (Unauthorized) 1531 error message. If the KDC cannot retrieve the 'kdcchallenge' 1532 associated to this Client (see Section 3.3), the KDC MUST respond 1533 with a 4.00 Bad Request error response, whose payload is a CBOR map 1534 including a newly generated 'kdcchallenge'. This error response MUST 1535 also have Content-Format application/ace+cbor. 1537 If verification succeeds, the handler replaces the old public key of 1538 the node NODENAME with the one specified in the 'client_cred' field 1539 of the request, and stores it as the new current public key of the 1540 node NODENAME, in the list of group members' public keys for the 1541 group identified by GROUPNAME. Then, the handler replies with a 2.04 1542 (Changed) response, which does not include a payload. 1544 4.2. Retrieval of Group Names and URIs 1546 In case the joining node only knows the group identifier of the group 1547 it wishes to join or about which it wishes to get update information 1548 from the KDC, the node can contact the KDC to request the 1549 corresponding group name and joining resource URI. The node can 1550 request several group identifiers at once. It does so by sending a 1551 CoAP FETCH request to the /ace-group endpoint at the KDC formatted as 1552 defined in Section 4.1.1.1. 1554 Figure 10 gives an overview of the exchanges described above, and 1555 Figure 11 shows an example. 1557 Client KDC 1558 | | 1559 |-------- Group Name and URI Retrieval Request: -------->| 1560 | FETCH /ace-group | 1561 | | 1562 |<-Group Name and URI Retrieval Response: 2.05 (Content)-| 1563 | | 1565 Figure 10: Message Flow of Group Name and URI Retrieval Request- 1566 Response 1568 Request: 1570 Header: FETCH (Code=0.05) 1571 Uri-Host: "kdc.example.com" 1572 Uri-Path: "ace-group" 1573 Content-Format: "application/ace-groupcomm+cbor" 1574 Payload (in CBOR diagnostic notation): 1575 { "gid": [01, 02] } 1577 Response: 1579 Header: Content (Code=2.05) 1580 Content-Format: "application/ace-groupcomm+cbor" 1581 Payload (in CBOR diagnostic notation): 1582 { "gid": [01, 02], "gname": ["group1", "group2"], 1583 "guri": ["kdc.example.com/g1", "kdc.example.com/g2"] } 1585 Figure 11: Example of Group Name and URI Retrieval Request-Response 1587 4.3. Joining Exchange 1589 Figure 12 gives an overview of the Joining exchange between Client 1590 and KDC, when the Client first joins a group, while Figure 13 shows 1591 an example. 1593 Client KDC 1594 | | 1595 |----- Joining Request: POST /ace-group/GROUPNAME ------>| 1596 | | 1597 |<--------- Joining Response: 2.01 (Created) ----------- | 1598 | Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME" | 1600 Figure 12: Message Flow of First Exchange for Group Joining 1602 Request: 1604 Header: POST (Code=0.02) 1605 Uri-Host: "kdc.example.com" 1606 Uri-Path: "ace-group" 1607 Uri-Path: "g1" 1608 Content-Format: "application/ace-groupcomm+cbor" 1609 Payload (in CBOR diagnostic notation, 1610 with PUB_KEY and SIG being CBOR byte strings): 1611 { "scope": << [ "group1", ["sender", "receiver"] ] >> , 1612 "get_pub_keys": [["sender"], []], "client_cred": PUB_KEY 1613 "cnonce": h'6df49c495409a9b5', "client_cred_verify": SIG } 1615 Response: 1617 Header: Created (Code=2.01) 1618 Content-Format: "application/ace-groupcomm+cbor" 1619 Location-Path: "kdc.example.com" 1620 Location-Path: "g1" 1621 Location-Path: "nodes" 1622 Location-Path: "c101" 1623 Payload (in CBOR diagnostic notation, 1624 with KEY being a CBOR byte strings): 1625 { "gkty": 13, "key": KEY, "num": 12, "exp": 1609459200, 1626 "pub_keys": << [ PUB_KEY1, PUB_KEY2 ] >>, 1627 "peer_roles": ["sender", ["sender", "receiver"]] } 1629 Figure 13: Example of First Exchange for Group Joining 1631 If not previously established, the Client and the KDC MUST first 1632 establish a pairwise secure communication channel (REQ16). This can 1633 be achieved, for instance, by using a transport profile of ACE. The 1634 Joining exchange MUST occur over that secure channel. The Client and 1635 the KDC MAY use that same secure channel to protect further pairwise 1636 communications that must be secured. 1638 The secure communication protocol is REQUIRED to establish the secure 1639 channel between Client and KDC by using the proof-of-possession key 1640 bound to the access token. As a result, the proof-of-possession to 1641 bind the access token to the Client is performed by using the proof- 1642 of-possession key bound to the access token for establishing secure 1643 communication between the Client and the KDC. 1645 To join the group, the Client sends a CoAP POST request to the /ace- 1646 group/GROUPNAME endpoint at the KDC, where GROUPNAME is the group 1647 name of the group to join, formatted as specified in Section 4.1.2.1. 1648 This group name is the same as in the scope entry corresponding to 1649 that group, specified in the 'scope' parameter of the Authorization 1650 Request/Response, or it can be retrieved from it. Note that, in case 1651 of successful joining, the Client will receive the URI to retrieve 1652 group keying material and to leave the group in the Location-Path 1653 option of the response. 1655 If the node is joining a group for the first time, and the KDC 1656 maintains the public keys of the group members, the Client is 1657 REQUIRED to send its own public key and proof of possession 1658 ("client_cred" and "client_cred_verify" in Section 4.1.2.1). The 1659 request is only accepted if both public key and proof of possession 1660 are provided. If a node re-joins a group with the same access token 1661 and the same public key, it can omit to send the public key and the 1662 proof of possession, or just omit the proof of possession, and the 1663 KDC will be able to retrieve its public key associated to its token 1664 for that group (if the key has been discarded, the KDC will reply 1665 with 4.00 Bad Request, as specified in Section 4.1.2.1). If a node 1666 re-joins a group but wants to update its own public key, it needs to 1667 send both public key and proof of possession. 1669 If the application requires backward security, the KDC MUST generate 1670 new group keying material and securely distribute it to all the 1671 current group members, upon a new node's joining the group. To this 1672 end, the KDC uses the message format of the response defined in 1673 Section 4.1.2.2. Application profiles may define alternative ways of 1674 retrieving the keying material, such as sending separate requests to 1675 different resources at the KDC (Section 4.1.2.2, Section 4.1.3.2, 1676 Section 4.1.4.1). After distributing the new group keying material, 1677 the KDC MUST increment the version number of the keying material. 1679 4.4. Retrieval of Updated Keying Material 1681 When any of the following happens, a node MUST stop using the owned 1682 group keying material to protect outgoing messages, and SHOULD stop 1683 using it to decrypt and verify incoming messages. 1685 * Upon expiration of the keying material, according to what 1686 indicated by the KDC with the 'exp' parameter in a Joining 1687 Response, or to a pre-configured value. 1689 * Upon receiving a notification of revoked/renewed keying material 1690 from the KDC, possibly as part of an update of the keying material 1691 (rekeying) triggered by the KDC. 1693 * Upon receiving messages from other group members without being 1694 able to retrieve the keying material to correctly decrypt them. 1695 This may be due to rekeying messages previously sent by the KDC, 1696 that the Client was not able to receive or decrypt. 1698 In either case, if it wants to continue participating in the group 1699 communication, the node has to request the latest keying material 1700 from the KDC. To this end, the Client sends a CoAP GET request to 1701 the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, 1702 formatted as specified in Section 4.1.6.2. 1704 Note that policies can be set up, so that the Client sends a Key Re- 1705 Distribution request to the KDC only after a given number of received 1706 messages could not be decrypted (because of failed decryption 1707 processing or inability to retrieve the necessary keying material). 1709 It is application dependent and pertaining to the particular message 1710 exchange (e.g. [I-D.ietf-core-oscore-groupcomm]) to set up these 1711 policies for instructing clients to retain incoming messages and for 1712 how long (OPT4). This allows clients to possibly decrypt such 1713 messages after getting updated keying material, rather than just 1714 consider them non valid messages to discard right away. 1716 The same Key Distribution Request could also be sent by the Client 1717 without being triggered by a failed decryption of a message, if the 1718 Client wants to be sure that it has the latest group keying material. 1719 If that is the case, the Client will receive from the KDC the same 1720 group keying material it already has in memory. 1722 Figure 14 gives an overview of the exchange described above, while 1723 Figure 15 shows an example. 1725 Client KDC 1726 | | 1727 |------------------ Key Distribution Request: --------------->| 1728 | GET ace-group/GROUPNAME/nodes/NODENAME | 1729 | | 1730 |<-------- Key Distribution Response: 2.05 (Content) ---------| 1731 | | 1733 Figure 14: Message Flow of Key Distribution Request-Response 1734 Request: 1736 Header: GET (Code=0.01) 1737 Uri-Host: "kdc.example.com" 1738 Uri-Path: "ace-group" 1739 Uri-Path: "g1" 1740 Uri-Path: "nodes" 1741 Uri-Path: "c101" 1742 Payload: - 1744 Response: 1746 Header: Content (Code=2.05) 1747 Content-Format: "application/ace-groupcomm+cbor" 1748 Payload (in CBOR diagnostic notation, 1749 with KEY and IND_KEY being CBOR byte strings, 1750 and "ind-key" the profile-specified label 1751 for individual keying material): 1752 { "gkty": 13, "key": KEY, "num": 12, "ind-key": IND_KEY } 1754 Figure 15: Example of Key Distribution Request-Response 1756 Alternatively, the re-distribution of keying material can be 1757 initiated by the KDC, which e.g.: 1759 * Can make the ace-group/GROUPNAME resource Observable [RFC7641], 1760 and send notifications to Clients when the keying material is 1761 updated. 1763 * Can send the payload of the Key Distribution Response in one or 1764 multiple multicast POST requests to the members of the group, 1765 using secure rekeying schemes such as [RFC2093][RFC2094][RFC2627]. 1767 * Can send unicast POST requests to each Client over a secure 1768 channel, with the same payload as the Key Distribution Response. 1769 When sending such requests, the KDC can target the URI path 1770 provided by the intended recipient upon joining the group, as 1771 specified in the 'control_path' parameter of the Joining Request 1772 (see Section 4.1.2.1). 1774 * Can act as a publisher in a pub-sub scenario, and update the 1775 keying material by publishing on a specific topic on a broker, 1776 which all the members of the group are subscribed to. 1778 Note that these methods of KDC-initiated key distribution have 1779 different security properties and require different security 1780 associations. 1782 4.5. Requesting a Change of Keying Material 1784 Beside possible expiration, the client may need to communicate to the 1785 KDC its need for the keying material to be renewed, e.g. due to 1786 exhaustion of AEAD nonces, if AEAD is used for protecting group 1787 communnication. Depending on the application profile (OPT8), this 1788 can result in renewal of individual keying material, group keying 1789 material, or both. 1791 For example, if the Client uses an individual key to protect outgoing 1792 traffic and has to renew it, the node may request a new one, or new 1793 input material to derive it, without renewing the whole group keying 1794 material. 1796 To this end, the client performs a Key Renewal Request/Response 1797 exchange with the KDC, i.e. it sends a CoAP PUT request to the /ace- 1798 group/GROUPNAME/nodes/NODENAME endpoint at the KDC, where GROUPNAME 1799 is the group name and NODENAME is its node name, and formatted as 1800 defined in Section 4.1.6.2. 1802 Figure 16 gives an overview of the exchange described above, while 1803 Figure 17 shows an example. 1805 Client KDC 1806 | | 1807 |------------------ Key Renewal Request: -------------->| 1808 | PUT ace-group/GROUPNAME/nodes/NODENAME | 1809 | | 1810 |<-------- Key Renewal Response: 2.05 (Content) --------| 1811 | | 1813 Figure 16: Message Flow of Key Renewal Request-Response 1815 Request: 1817 Header: PUT (Code=0.03) 1818 Uri-Host: "kdc.example.com" 1819 Uri-Path: "ace-group" 1820 Uri-Path: "g1" 1821 Uri-Path: "nodes" 1822 Uri-Path: "c101" 1823 Payload: - 1825 Response: 1827 Header: Content (Code=2.05) 1828 Content-Format: "application/ace-groupcomm+cbor" 1829 Payload (in CBOR diagnostic notation, with IND_KEY being 1830 a CBOR byte string, and "ind-key" the profile-specified 1831 label for individual keying material): 1832 { "ind-key": IND_KEY } 1834 Figure 17: Example of Key Renewal Request-Response 1836 Note the difference between the Key Distribution Request and the Key 1837 Renewal Request: while the first one only triggers distribution (the 1838 renewal might have happened independently, e.g. because of 1839 expiration), the second one triggers the KDC to produce new 1840 individual keying material for the requesting node. 1842 4.6. Retrieval of Public Keys and Roles for Group Members 1844 In case the KDC maintains the public keys of group members, a node in 1845 the group can contact the KDC to request public keys and roles of 1846 either all group members or a specified subset, by sending a CoAP GET 1847 or FETCH request to the /ace-group/GROUPNAME/pub-key endpoint at the 1848 KDC, where GROUPNAME is the group name, and formatted as defined in 1849 Section 4.1.3.2 and Section 4.1.3.1. 1851 Figure 18 and Figure 20 give an overview of the exchanges described 1852 above, while Figure 19 and Figure 21 show an example for each 1853 exchange. 1855 Client KDC 1856 | | 1857 |--Public Key Request: GET /ace-group/GROUPNAME/pub-key->| 1858 | | 1859 |<--------- Public Key Response: 2.05 (Content) ---------| 1860 | | 1862 Figure 18: Message Flow of Public Key Exchange to Request All 1863 Members Public Keys 1865 Request: 1867 Header: GET (Code=0.01) 1868 Uri-Host: "kdc.example.com" 1869 Uri-Path: "ace-group" 1870 Uri-Path: "g1" 1871 Uri-Path: "pub-key" 1872 Payload: - 1874 Response: 1876 Header: Content (Code=2.05) 1877 Content-Format: "application/ace-groupcomm+cbor" 1878 Payload (in CBOR diagnostic notation): 1879 { "pub_keys": << [ PUB_KEY1, PUB_KEY2, PUB_KEY3 ] >>, 1880 "peer_roles": ["sender", ["sender", "receiver"], "receiver"] } 1882 Figure 19: Example of Public Key Exchange to Request All Members 1883 Public Keys 1885 Client KDC 1886 | | 1887 |-Public Key Request: FETCH /ace-group/GROUPNAME/pub-key->| 1888 | | 1889 |<--------- Public Key Response: 2.05 (Created) ----------| 1890 | | 1892 Figure 20: Message Flow of Public Key Exchange to Request 1893 Specific Members Public Keys 1895 Request: 1897 Header: FETCH (Code=0.05) 1898 Uri-Host: "kdc.example.com" 1899 Uri-Path: "ace-group" 1900 Uri-Path: "g1" 1901 Uri-Path: "pub-key" 1902 Content-Format: "application/ace-groupcomm+cbor" 1903 Payload: 1904 { "get_pub_keys": [[], ["c3"]] } 1906 Response: 1908 Header: Content (Code=2.05) 1909 Content-Format: "application/ace-groupcomm+cbor" 1910 Payload (in CBOR diagnostic notation): 1911 { "pub_keys": << [ PUB_KEY3 ] >>, 1912 "peer_roles": ["receiver"] } 1914 Figure 21: Example of Public Key Exchange to Request Specific 1915 Members Public Keys 1917 4.7. Update of Public Key 1919 In case the KDC maintains the public keys of group members, a node in 1920 the group can contact the KDC to upload a new public key to use in 1921 the group, and replace the currently stored one. 1923 To this end, the Client performs a Public Key Update Request/Response 1924 exchange with the KDC, i.e. it sends a CoAP POST request to the /ace- 1925 group/GROUPNAME/nodes/NODENAME/pub-key endpoint at the KDC, where 1926 GROUPNAME is the group name and NODENAME is its node name. 1928 The request is formatted as specified in Section 4.1.7.1. 1930 Figure Figure 22 gives an overview of the exchange described above, 1931 while Figure 23 shows an example. 1933 Client KDC 1934 | | 1935 |-------------- Public Key Update Request: ---------------------->| 1936 | POST ace-group/GROUPNAME/nodes/NODENAME/pub-key | 1937 | | 1938 |<------- Public Key Update Response: 2.04 (Changed) -------------| 1939 | | 1941 Figure 22: Message Flow of Public Key Update Request-Response 1942 Request: 1944 Header: POST (Code=0.02) 1945 Uri-Host: "kdc.example.com" 1946 Uri-Path: "ace-group" 1947 Uri-Path: "g1" 1948 Uri-Path: "nodes" 1949 Uri-Path: "c101" 1950 Uri-Path: "pub-key" 1951 Content-Format: "application/ace-groupcomm+cbor" 1952 Payload (in CBOR diagnostic notation, with PUB_KEY 1953 and SIG being CBOR byte strings): 1954 { "client_cred": PUB_KEY, "cnonce": h'9ff7684414affcc8', 1955 "client_cred_verify": SIG } 1957 Response: 1959 Header: Changed (Code=2.04) 1960 Payload: - 1962 Figure 23: Example of Public Key Update Request-Response 1964 If the application requires backward security, the KDC MUST generate 1965 new group keying material and securely distribute it to all the 1966 current group members, upon a group member updating its own public 1967 key. To this end, the KDC uses the message format of the response 1968 defined in Section 4.1.2.2. Application profiles may define 1969 alternative ways of retrieving the keying material, such as sending 1970 separate requests to different resources at the KDC (Section 4.1.2.2, 1971 Section 4.1.3.2, Section 4.1.4.1). The KDC MUST increment the 1972 version number of the current keying material, before distributing 1973 the newly generated keying material to the group. After that, the 1974 KDC SHOULD store the distributed keying material in persistent 1975 storage. 1977 Additionally, after updating its own public key, a group member MAY 1978 send a number of the later requests including an identifier of the 1979 updated public key, to signal nodes that they need to retrieve it. 1980 How that is done depends on the group communication protocol used, 1981 and therefore is application profile specific (OPT10). 1983 4.8. Retrieval of Group Policies 1985 A node in the group can contact the KDC to retrieve the current group 1986 policies, by sending a CoAP GET request to the /ace-group/GROUPNAME/ 1987 policies endpoint at the KDC, where GROUPNAME is the group name, and 1988 formatted as defined in Section 4.1.4.1 1989 Figure 24 gives an overview of the exchange described above, while 1990 Figure 25 shows an example. 1992 Client KDC 1993 | | 1994 |-Policies Request: GET ace-group/GROUPNAME/policies ->| 1995 | | 1996 |<--------- Policies Response: 2.05 (Content) ---------| 1997 | | 1999 Figure 24: Message Flow of Policies Request-Response 2001 Request: 2003 Header: GET (Code=0.01) 2004 Uri-Host: "kdc.example.com" 2005 Uri-Path: "ace-group" 2006 Uri-Path: "g1" 2007 Uri-Path: "policies" 2008 Payload: - 2010 Response: 2012 Header: Content (Code=2.05) 2013 Content-Format: "application/ace-groupcomm+cbor" 2014 Payload(in CBOR diagnostic notation): 2015 { "group_policies": {"exp-delta": 120} } 2017 Figure 25: Example of Policies Request-Response 2019 4.9. Retrieval of Keying Material Version 2021 A node in the group can contact the KDC to request information about 2022 the version number of the symmetric group keying material, by sending 2023 a CoAP GET request to the /ace-group/GROUPNAME/num endpoint at the 2024 KDC, where GROUPNAME is the group name, formatted as defined in 2025 Section 4.1.5.1. In particular, the version is incremented by the 2026 KDC every time the group keying material is renewed, before it's 2027 distributed to the group members. 2029 Figure 26 gives an overview of the exchange described above, while 2030 Figure 27 shows an example. 2032 Client KDC 2033 | | 2034 |---- Version Request: GET ace-group/GROUPNAME/num ---->| 2035 | | 2036 |<--------- Version Response: 2.05 (Content) -----------| 2037 | | 2039 Figure 26: Message Flow of Version Request-Response 2041 Request: 2043 Header: GET (Code=0.01) 2044 Uri-Host: "kdc.example.com" 2045 Uri-Path: "ace-group" 2046 Uri-Path: "g1" 2047 Uri-Path: "num" 2048 Payload: - 2050 Response: 2052 Header: Content (Code=2.05) 2053 Content-Format: text/plain 2054 Payload(in CBOR diagnostic notation): 2055 13 2057 Figure 27: Example of Version Request-Response 2059 4.10. Group Leaving Request 2061 A node can actively request to leave the group. In this case, the 2062 Client sends a CoAP DELETE request to the endpoint /ace- 2063 group/GROUPNAME/nodes/NODENAME at the KDC, where GROUPNAME is the 2064 group name and NODENAME is its node name, formatted as defined in 2065 Section 4.1.6.3 2067 Alternatively, a node may be removed by the KDC, without having 2068 explicitly asked for it. This is further discussed in Section 5. 2070 5. Removal of a Node from the Group 2072 This section describes the different scenarios according to which a 2073 node ends up being removed from the group. 2075 If the application requires forward security, the KDC MUST generate 2076 new group keying material and securely distribute it to all the 2077 current group members but the leaving node, using the message format 2078 of the Key Distribution Response (see Section 4.4). Application 2079 profiles may define alternative message formats. Before distributing 2080 the new group keying material, the KDC MUST increment the version 2081 number of the keying material. 2083 Note that, after having left the group, a node may wish to join it 2084 again. Then, as long as the node is still authorized to join the 2085 group, i.e. it still has a valid access token, it can request to re- 2086 join the group directly to the KDC without needing to retrieve a new 2087 access token from the AS. This means that the KDC might decide to 2088 keep track of nodes with valid access tokens, before deleting all 2089 information about the leaving node. 2091 A node may be evicted from the group in the following cases. 2093 1. The node explicitly asks to leave the group, as defined in 2094 Section 4.10. 2096 2. The node has been found compromised or is suspected so. 2098 3. The node's authorization to be a group member is not valid 2099 anymore, either because the access token has expired, or it has 2100 been revoked. If the AS provides Token introspection (see 2101 Section 5.7 of [I-D.ietf-ace-oauth-authz]), the KDC can 2102 optionally use it and check whether the node is still authorized 2103 for that group in that role. 2105 In either case, once aware that a node is not authorized anymore, the 2106 KDC has to remove the unauthorized node from the list of group 2107 members, if the KDC keeps track of that. 2109 In case of forced eviction, the KDC MAY explicitly inform the leaving 2110 node, if the Client implements the 'control_path' resource specified 2111 in Section 4.1.2.1. To this end, the KDC MAY send a DEL request, 2112 targeting the URI specified in the 'control_path' parameter of the 2113 Joining Request. 2115 6. ACE Groupcomm Parameters 2117 This specification defines a number of fields used during the second 2118 part of the message exchange, after the ACE Token POST exchange. The 2119 table below summarizes them, and specifies the CBOR key to use 2120 instead of the full descriptive name. Note that the media type ace- 2121 groupcomm+cbor MUST be used when these fields are transported. 2123 +=======================+======+================+==================+ 2124 | Name | CBOR | CBOR Type | Reference | 2125 | | Key | | | 2126 +=======================+======+================+==================+ 2127 | scope | TBD | byte string | Section 4.1.2.1 | 2128 +-----------------------+------+----------------+------------------+ 2129 | get_pub_keys | TBD | array / simple | Section 4.1.2.1, | 2130 | | | value null | Section 4.1.3.1 | 2131 +-----------------------+------+----------------+------------------+ 2132 | client_cred | TBD | byte string | Section 4.1.2.1 | 2133 +-----------------------+------+----------------+------------------+ 2134 | cnonce | TBD | byte string | Section 4.1.2.1 | 2135 +-----------------------+------+----------------+------------------+ 2136 | client_cred_verify | TBD | byte string | Section 4.1.2.1 | 2137 +-----------------------+------+----------------+------------------+ 2138 | pub_keys_repos | TBD | text string | Section 4.1.2.1 | 2139 +-----------------------+------+----------------+------------------+ 2140 | control_path | TBD | text string | Section 4.1.2.1 | 2141 +-----------------------+------+----------------+------------------+ 2142 | gkty | TBD | integer / text | Section 4.1.2.1 | 2143 | | | string | | 2144 +-----------------------+------+----------------+------------------+ 2145 | key | TBD | see "ACE | Section 4.1.2.1 | 2146 | | | Groupcomm Key" | | 2147 | | | Registry | | 2148 +-----------------------+------+----------------+------------------+ 2149 | num | TBD | int | Section 4.1.2.1 | 2150 +-----------------------+------+----------------+------------------+ 2151 | ace-groupcomm-profile | TBD | int | Section 4.1.2.1 | 2152 +-----------------------+------+----------------+------------------+ 2153 | exp | TBD | int | Section 4.1.2.1 | 2154 +-----------------------+------+----------------+------------------+ 2155 | pub_keys | TBD | byte string | Section 4.1.2.1 | 2156 +-----------------------+------+----------------+------------------+ 2157 | peer_roles | TBD | array | Section 4.1.2.1 | 2158 +-----------------------+------+----------------+------------------+ 2159 | group_policies | TBD | map | Section 4.1.2.1 | 2160 +-----------------------+------+----------------+------------------+ 2161 | mgt_key_material | TBD | byte string | Section 4.1.2.1 | 2162 +-----------------------+------+----------------+------------------+ 2163 | gid | TBD | array | Section 4.1.1.1 | 2164 +-----------------------+------+----------------+------------------+ 2165 | gname | TBD | array of text | Section 4.1.1.1 | 2166 | | | strings | | 2167 +-----------------------+------+----------------+------------------+ 2168 | guri | TBD | array of text | Section 4.1.1.1 | 2169 | | | strings | | 2170 +-----------------------+------+----------------+------------------+ 2171 Table 1 2173 7. Security Considerations 2175 When a Client receives a message from a sender for the first time, it 2176 needs to have a mechanism in place to avoid replay, e.g. 2177 Appendix B.2 of [RFC8613]. In case the Client rebooted and lost the 2178 security state used to protect previous communication with that 2179 sender, such a mechanism is useful for the recipient to be on the 2180 safe side. 2182 Besides, if the KDC has renewed the group keying material, and the 2183 time interval between the end of the rekeying process and the joining 2184 of the Client is sufficiently small, that Client is also on the safe 2185 side, since replayed older messages protected with the previous 2186 keying material will not be accepted. 2188 The KDC must renew the group keying material upon its expiration. 2190 The KDC should renew the keying material upon group membership 2191 change, and should provide it to the current group members through 2192 the rekeying scheme used in the group. 2194 The KDC should renew the group keying material after rebooting, even 2195 in the case where all keying material is stored in persistent 2196 storage. However, if the KDC relies on Observe responses to notify 2197 the group of renewed keying material, after rebooting the KDC will 2198 have lost all the current ongoing Observations with the group 2199 members, and the previous keying material will be used to protect 2200 messages in the group anyway. The KDC will rely on each node 2201 requesting updates of the group keying material to establish the new 2202 keying material in the nodes, or, if implemented, it can push the 2203 update to the nodes in the group using the 'control_path' resource. 2205 The KDC may enforce a rekeying policy that takes into account the 2206 overall time required to rekey the group, as well as the expected 2207 rate of changes in the group membership. 2209 That is, the KDC may not rekey the group at every membership change, 2210 for instance if members' joining and leaving occur frequently and 2211 performing a group rekeying takes too long. The KDC may rekey the 2212 group after a minimum number of group members have joined or left 2213 within a given time interval, or after maximum amount of time since 2214 the last rekeying was completed, or yet during predictable network 2215 inactivity periods. 2217 However, this would result in the KDC not constantly preserving 2218 backward and forward security. Newly joining group members could be 2219 able to access the keying material used before their joining, and 2220 thus could access past group communications. Also, until the KDC 2221 performs a group rekeying, the newly leaving nodes would still be 2222 able to access upcoming group communications that are protected with 2223 the keying material that has not yet been updated. 2225 The KDC needs to have a mechanism in place to detect DoS attacks from 2226 nodes constantly initiating rekey events (for example by updating 2227 their public key), such as removing these nodes from the group. 2229 The KDC also needs to have a congestion control mechanism in place to 2230 avoid network congestion when the KDC renews the group keying 2231 material; CoAP and Observe give guidance on such mechanisms, see 2232 Section 4.7 of [RFC7252] and Section 4.5.1 of [RFC7641]. 2234 7.1. Update of Keying Material 2236 A group member can receive a message shortly after the group has been 2237 rekeyed, and new keying material has been distributed by the KDC. In 2238 the following two cases, this may result in misaligned keying 2239 material between the group members. 2241 In the first case, the sender protects a message using the old keying 2242 material. However, the recipient receives the message after having 2243 received the new keying material, hence not being able to correctly 2244 process it. A possible way to ameliorate this issue is to preserve 2245 the old, recent, keying material for a maximum amount of time defined 2246 by the application. By doing so, the recipient can still try to 2247 process the received message using the old retained keying material. 2248 Note that a former (compromised) group member can take advantage of 2249 this by sending messages protected with the old retained keying 2250 material. Therefore, a conservative application policy should not 2251 admit the storage of old keying material. 2253 In the second case, the sender protects a message using the new 2254 keying material, but the recipient receives that request before 2255 having received the new keying material. Therefore, the recipient 2256 would not be able to correctly process the request and hence discards 2257 it. If the recipient receives the new keying material shortly after 2258 that and the application at the sender endpoint performs 2259 retransmissions, the former will still be able to receive and 2260 correctly process the message. In any case, the recipient should 2261 actively ask the KDC for an updated keying material according to an 2262 application-defined policy, for instance after a given number of 2263 unsuccessfully decrypted incoming messages. 2265 A node that has left the group should not expect any of its outgoing 2266 messages to be successfully processed, if received after its leaving, 2267 due to a possible group rekeying occurred before the message 2268 reception. 2270 7.2. Block-Wise Considerations 2272 If the block-wise options [RFC7959] are used, and the keying material 2273 is updated in the middle of a block-wise transfer, the sender of the 2274 blocks just changes the keying material to the updated one and 2275 continues the transfer. As long as both sides get the new keying 2276 material, updating the keying material in the middle of a transfer 2277 will not cause any issue. Otherwise, the sender will have to 2278 transmit the message again, when receiving an error message from the 2279 recipient. 2281 Compared to a scenario where the transfer does not use block-wise, 2282 depending on how fast the keying material is changed, the nodes might 2283 consume a larger amount of the network bandwidth resending the blocks 2284 again and again, which might be problematic. 2286 8. IANA Considerations 2288 This document has the following actions for IANA. 2290 8.1. Media Type Registrations 2292 This specification registers the 'application/ace-groupcomm+cbor' 2293 media type for messages of the protocols defined in this document 2294 following the ACE exchange and carrying parameters encoded in CBOR. 2295 This registration follows the procedures specified in [RFC6838]. 2297 Type name: application 2299 Subtype name: ace-groupcomm+cbor 2301 Required parameters: none 2303 Optional parameters: none 2305 Encoding considerations: Must be encoded as CBOR map containing the 2306 protocol parameters defined in [this document]. 2308 Security considerations: See Section 7 of this document. 2310 Interoperability considerations: n/a 2312 Published specification: [this document] 2313 Applications that use this media type: The type is used by 2314 authorization servers, clients and resource servers that support the 2315 ACE groupcomm framework as specified in [this document]. 2317 Additional information: n/a 2319 Person & email address to contact for further information: 2320 iesg@ietf.org (mailto:iesg@ietf.org) 2322 Intended usage: COMMON 2324 Restrictions on usage: None 2326 Author: Francesca Palombini francesca.palombini@ericsson.com 2327 (mailto:francesca.palombini@ericsson.com) 2329 Change controller: IESG 2331 8.2. CoAP Content-Formats Registry 2333 This specification registers the following entry to the "CoAP 2334 Content-Formats" registry, within the "CoRE Parameters" registry: 2336 Media Type: application/ace-groupcomm+cbor 2338 Encoding: - 2340 ID: TBD 2342 Reference: [this document] 2344 8.3. OAuth Parameters Registry 2346 The following registrations are done for the OAuth ParametersRegistry 2347 following the procedure specified in section 11.2 of [RFC6749]: 2349 o Parameter name: sign_info o Parameter usage location: token 2350 request, token response o Change Controller: IESG o Specification 2351 Document(s): [[This specification]] 2353 o Parameter name: kdcchallenge o Parameter usage location: token 2354 response o Change Controller: IESG o Specification Document(s): 2355 [[This specification]] 2357 8.4. OAuth Parameters CBOR Mappings Registry 2359 The following registrations are done for the OAuth Parameters CBOR 2360 Mappings Registry following the procedure specified in section 8.9 of 2361 [I-D.ietf-ace-oauth-authz]: 2363 * Name: sign_info 2364 * CBOR Key: TBD (range -256 to 255) 2365 * Value Type: any 2366 * Reference: \[\[This specification\]\] 2368 * Name: kdcchallenge 2369 * CBOR Key: TBD (range -256 to 255) 2370 * Value Type: byte string 2371 * Reference: \[\[This specification\]\] 2373 8.5. ACE Groupcomm Parameters Registry 2375 This specification establishes the "ACE Groupcomm Parameters" IANA 2376 Registry. The Registry has been created to use the "Expert Review 2377 Required" registration procedure [RFC8126]. Expert review guidelines 2378 are provided in Section 8.11. 2380 The columns of this Registry are: 2382 * Name: This is a descriptive name that enables easier reference to 2383 the item. The name MUST be unique. It is not used in the 2384 encoding. 2386 * CBOR Key: This is the value used as CBOR key of the item. These 2387 values MUST be unique. The value can be a positive integer, a 2388 negative integer, or a string. 2390 * CBOR Type: This contains the CBOR type of the item, or a pointer 2391 to the registry that defines its type, when that depends on 2392 another item. 2394 * Reference: This contains a pointer to the public specification for 2395 the item. 2397 This Registry has been initially populated by the values in 2398 Section 6. The Reference column for all of these entries refers to 2399 sections of this document. 2401 8.6. ACE Groupcomm Key Registry 2403 This specification establishes the "ACE Groupcomm Key" IANA Registry. 2404 The Registry has been created to use the "Expert Review Required" 2405 registration procedure [RFC8126]. Expert review guidelines are 2406 provided in Section 8.11. 2408 The columns of this Registry are: 2410 * Name: This is a descriptive name that enables easier reference to 2411 the item. The name MUST be unique. It is not used in the 2412 encoding. 2414 * Key Type Value: This is the value used to identify the keying 2415 material. These values MUST be unique. The value can be a 2416 positive integer, a negative integer, or a text string. 2418 * Profile: This field may contain one or more descriptive strings of 2419 application profiles to be used with this item. The values should 2420 be taken from the Name column of the "ACE Groupcomm Profile" 2421 Registry. 2423 * Description: This field contains a brief description of the keying 2424 material. 2426 * References: This contains a pointer to the public specification 2427 for the format of the keying material, if one exists. 2429 This Registry has been initially populated by the values in Figure 8. 2430 The specification column for all of these entries will be this 2431 document. 2433 8.7. ACE Groupcomm Profile Registry 2435 This specification establishes the "ACE Groupcomm Profile" IANA 2436 Registry. The Registry has been created to use the "Expert Review 2437 Required" registration procedure [RFC8126]. Expert review guidelines 2438 are provided in Section 8.11. It should be noted that, in addition 2439 to the expert review, some portions of the Registry require a 2440 specification, potentially a Standards Track RFC, be supplied as 2441 well. 2443 The columns of this Registry are: 2445 * Name: The name of the application profile, to be used as value of 2446 the profile attribute. 2448 * Description: Text giving an overview of the application profile 2449 and the context it is developed for. 2451 * CBOR Value: CBOR abbreviation for the name of this application 2452 profile. Different ranges of values use different registration 2453 policies [RFC8126]. Integer values from -256 to 255 are 2454 designated as Standards Action. Integer values from -65536 to 2455 -257 and from 256 to 65535 are designated as Specification 2456 Required. Integer values greater than 65535 are designated as 2457 Expert Review. Integer values less than -65536 are marked as 2458 Private Use. 2460 * Reference: This contains a pointer to the public specification of 2461 the abbreviation for this application profile, if one exists. 2463 8.8. ACE Groupcomm Policy Registry 2465 This specification establishes the "ACE Groupcomm Policy" IANA 2466 Registry. The Registry has been created to use the "Expert Review 2467 Required" registration procedure [RFC8126]. Expert review guidelines 2468 are provided in Section 8.11. It should be noted that, in addition 2469 to the expert review, some portions of the Registry require a 2470 specification, potentially a Standards Track RFC, be supplied as 2471 well. 2473 The columns of this Registry are: 2475 * Name: The name of the group communication policy. 2477 * CBOR label: The value to be used to identify this group 2478 communication policy. Key map labels MUST be unique. The label 2479 can be a positive integer, a negative integer or a string. 2480 Integer values between 0 and 255 and strings of length 1 are 2481 designated as Standards Track Document required. Integer values 2482 from 256 to 65535 and strings of length 2 are designated as 2483 Specification Required. Integer values of greater than 65535 and 2484 strings of length greater than 2 are designated as expert review. 2485 Integer values less than -65536 are marked as private use. 2487 * CBOR type: the CBOR type used to encode the value of this group 2488 communication policy. 2490 * Description: This field contains a brief description for this 2491 group communication policy. 2493 * Reference: This field contains a pointer to the public 2494 specification providing the format of the group communication 2495 policy, if one exists. 2497 This registry will be initially populated by the values in Figure 9. 2499 8.9. Sequence Number Synchronization Method Registry 2501 This specification establishes the "Sequence Number Synchronization 2502 Method" IANA Registry. The Registry has been created to use the 2503 "Expert Review Required" registration procedure [RFC8126]. Expert 2504 review guidelines are provided in Section 8.11. It should be noted 2505 that, in addition to the expert review, some portions of the Registry 2506 require a specification, potentially a Standards Track RFC, be 2507 supplied as well. 2509 The columns of this Registry are: 2511 * Name: The name of the sequence number synchronization method. 2513 * Value: The value to be used to identify this sequence number 2514 synchronization method. 2516 * Description: This field contains a brief description for this 2517 sequence number synchronization method. 2519 * Reference: This field contains a pointer to the public 2520 specification describing the sequence number synchronization 2521 method. 2523 8.10. Interface Description (if=) Link Target Attribute Values Registry 2525 This specification registers the following entry to the "Interface 2526 Description (if=) Link Target Attribute Values Registry" registry, 2527 within the "CoRE Parameters" registry: 2529 * Attribute Value: ace.group 2531 * Description: The 'ace group' interface is used to provision keying 2532 material and related informations and policies to members of a 2533 group using the Ace framework. 2535 * Reference: [This Document] 2537 8.11. Expert Review Instructions 2539 The IANA Registries established in this document are defined as 2540 expert review. This section gives some general guidelines for what 2541 the experts should be looking for, but they are being designated as 2542 experts for a reason so they should be given substantial latitude. 2544 Expert reviewers should take into consideration the following points: 2546 * Point squatting should be discouraged. Reviewers are encouraged 2547 to get sufficient information for registration requests to ensure 2548 that the usage is not going to duplicate one that is already 2549 registered and that the point is likely to be used in deployments. 2550 The zones tagged as private use are intended for testing purposes 2551 and closed environments, code points in other ranges should not be 2552 assigned for testing. 2554 * Specifications are required for the standards track range of point 2555 assignment. Specifications should exist for specification 2556 required ranges, but early assignment before a specification is 2557 available is considered to be permissible. Specifications are 2558 needed for the first-come, first-serve range if they are expected 2559 to be used outside of closed environments in an interoperable way. 2560 When specifications are not provided, the description provided 2561 needs to have sufficient information to identify what the point is 2562 being used for. 2564 * Experts should take into account the expected usage of fields when 2565 approving point assignment. The fact that there is a range for 2566 standards track documents does not mean that a standards track 2567 document cannot have points assigned outside of that range. The 2568 length of the encoded value should be weighed against how many 2569 code points of that length are left, the size of device it will be 2570 used on, and the number of code points left that encode to that 2571 size. 2573 9. References 2575 9.1. Normative References 2577 [COSE.Algorithms] 2578 IANA, "COSE Algorithms", 2579 . 2582 [I-D.ietf-ace-oauth-authz] 2583 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 2584 H. Tschofenig, "Authentication and Authorization for 2585 Constrained Environments (ACE) using the OAuth 2.0 2586 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 2587 draft-ietf-ace-oauth-authz-35, 24 June 2020, 2588 . 2591 [I-D.ietf-cbor-7049bis] 2592 Bormann, C. and P. Hoffman, "Concise Binary Object 2593 Representation (CBOR)", Work in Progress, Internet-Draft, 2594 draft-ietf-cbor-7049bis-16, 30 September 2020, 2595 . 2598 [I-D.ietf-core-oscore-groupcomm] 2599 Tiloca, M., Selander, G., Palombini, F., and J. Park, 2600 "Group OSCORE - Secure Group Communication for CoAP", Work 2601 in Progress, Internet-Draft, draft-ietf-core-oscore- 2602 groupcomm-09, 23 June 2020, . 2605 [I-D.ietf-cose-rfc8152bis-algs] 2606 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2607 Initial Algorithms", Work in Progress, Internet-Draft, 2608 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 2609 . 2612 [I-D.ietf-cose-rfc8152bis-struct] 2613 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2614 Structures and Process", Work in Progress, Internet-Draft, 2615 draft-ietf-cose-rfc8152bis-struct-14, 24 September 2020, 2616 . 2619 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2620 Requirement Levels", BCP 14, RFC 2119, 2621 DOI 10.17487/RFC2119, March 1997, 2622 . 2624 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 2625 RFC 6749, DOI 10.17487/RFC6749, October 2012, 2626 . 2628 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2629 Specifications and Registration Procedures", BCP 13, 2630 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2631 . 2633 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2634 Application Protocol (CoAP)", RFC 7252, 2635 DOI 10.17487/RFC7252, June 2014, 2636 . 2638 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2639 Writing an IANA Considerations Section in RFCs", BCP 26, 2640 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2641 . 2643 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2644 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2645 May 2017, . 2647 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 2648 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 2649 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2650 2020, . 2652 9.2. Informative References 2654 [I-D.ietf-ace-aif] 2655 Bormann, C., "An Authorization Information Format (AIF) 2656 for ACE", Work in Progress, Internet-Draft, draft-ietf- 2657 ace-aif-00, 29 July 2020, . 2660 [I-D.ietf-ace-dtls-authorize] 2661 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 2662 L. Seitz, "Datagram Transport Layer Security (DTLS) 2663 Profile for Authentication and Authorization for 2664 Constrained Environments (ACE)", Work in Progress, 2665 Internet-Draft, draft-ietf-ace-dtls-authorize-14, 29 2666 October 2020, . 2669 [I-D.ietf-ace-mqtt-tls-profile] 2670 Sengul, C. and A. Kirby, "Message Queuing Telemetry 2671 Transport (MQTT)-TLS profile of Authentication and 2672 Authorization for Constrained Environments (ACE) 2673 Framework", Work in Progress, Internet-Draft, draft-ietf- 2674 ace-mqtt-tls-profile-08, 1 November 2020, 2675 . 2678 [I-D.ietf-ace-oscore-profile] 2679 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 2680 "OSCORE Profile of the Authentication and Authorization 2681 for Constrained Environments Framework", Work in Progress, 2682 Internet-Draft, draft-ietf-ace-oscore-profile-13, 27 2683 October 2020, . 2686 [I-D.ietf-core-coap-pubsub] 2687 Koster, M., Keranen, A., and J. Jimenez, "Publish- 2688 Subscribe Broker for the Constrained Application Protocol 2689 (CoAP)", Work in Progress, Internet-Draft, draft-ietf- 2690 core-coap-pubsub-09, 30 September 2019, 2691 . 2694 [I-D.ietf-core-groupcomm-bis] 2695 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 2696 for the Constrained Application Protocol (CoAP)", Work in 2697 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 2698 01, 13 July 2020, . 2701 [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management 2702 Protocol (GKMP) Specification", RFC 2093, 2703 DOI 10.17487/RFC2093, July 1997, 2704 . 2706 [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management 2707 Protocol (GKMP) Architecture", RFC 2094, 2708 DOI 10.17487/RFC2094, July 1997, 2709 . 2711 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 2712 Multicast: Issues and Architectures", RFC 2627, 2713 DOI 10.17487/RFC2627, June 1999, 2714 . 2716 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 2717 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 2718 . 2720 [RFC7641] Hartke, K., "Observing Resources in the Constrained 2721 Application Protocol (CoAP)", RFC 7641, 2722 DOI 10.17487/RFC7641, September 2015, 2723 . 2725 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 2726 the Constrained Application Protocol (CoAP)", RFC 7959, 2727 DOI 10.17487/RFC7959, August 2016, 2728 . 2730 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2731 Interchange Format", STD 90, RFC 8259, 2732 DOI 10.17487/RFC8259, December 2017, 2733 . 2735 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 2736 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 2737 May 2018, . 2739 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2740 Definition Language (CDDL): A Notational Convention to 2741 Express Concise Binary Object Representation (CBOR) and 2742 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2743 June 2019, . 2745 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2746 "Object Security for Constrained RESTful Environments 2747 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2748 . 2750 Appendix A. Requirements on Application Profiles 2752 This section lists the requirements on application profiles of this 2753 specification,for the convenience of application profile designers. 2755 * REQ1: If the value of the GROUPNAME URI path and the group name in 2756 the access token scope (gname in Section 3.2) don't match, specify 2757 the mechanism to map the GROUPNAME value in the URI to the group 2758 name (REQ1) (see Section 4.1). 2760 * REQ2: Specify the encoding and value of roles, for scope entries 2761 of 'scope' (see Section 3.1). 2763 * REQ3: If used, specify the acceptable values for 'sign_alg' (see 2764 Section 3.3). 2766 * REQ4: If used, specify the acceptable values for 'sign_parameters' 2767 (see Section 3.3). 2769 * REQ5: If used, specify the acceptable values for 2770 'sign_key_parameters' (see Section 3.3). 2772 * REQ6: If used, specify the acceptable values for 'pub_key_enc' 2773 (see Section 3.3). 2775 * REQ7a: Register a Resource Type for the root url-path, which is 2776 used to discover the correct url to access at the KDC (see 2777 Section 4.1). 2779 * REQ7aa: Define what operations (i.e. CoAP methods) are allowed on 2780 each resource, for each role defined in REQ2 (see Section 3.3). 2782 * REQ7b: Specify the exact encoding of group identifier (see 2783 Section 4.1.1.1). 2785 * REQ7: Specify the exact format of the 'key' value (see 2786 Section 4.1.2.1). 2788 * REQ8: Specify the acceptable values of 'gkty' (see 2789 Section 4.1.2.1). 2791 * REQ9: Specify the format of the identifiers of group members (see 2792 Section 4.1.2.1). 2794 * REQ10: Specify the communication protocol the members of the group 2795 must use (e.g., multicast CoAP). 2797 * REQ11: Specify the security protocol the group members must use to 2798 protect their communication (e.g., group OSCORE). This must 2799 provide encryption, integrity and replay protection. 2801 * REQ12: Specify and register the application profile identifier 2802 (see Section 4.1.2.1). 2804 * REQ13: Specify policies at the KDC to handle ids that are not 2805 included in get_pub_keys (see Section 4.1.3.1). 2807 * REQ14: If used, specify the format and content of 'group_policies' 2808 and its entries. Specify the policies default values (see 2809 Section 4.1.2.1). 2811 * REQ15: Specify the format of newly-generated individual keying 2812 material for group members, or of the information to derive it, 2813 and corresponding CBOR label (see Section 4.1.6.2). 2815 * REQ16: Specify how the communication is secured between Client and 2816 KDC. Optionally, specify tranport profile of ACE 2817 [I-D.ietf-ace-oauth-authz] to use between Client and KDC (see 2818 Section 4.3. 2820 * REQ17: Specify how the nonce N_S is generated, if the token was 2821 not posted (e.g. if it is used directly to validate TLS instead). 2823 * REQ18: Specify if 'mgt_key_material' used, and if yes specify its 2824 format and content (see Section 4.1.2.1). If the usage of 2825 'mgt_key_material' is indicated and its format defined for a 2826 specific key management scheme, that format must explicitly 2827 indicate the key management scheme itself. If a new rekeying 2828 scheme is defined to be used for an existing 'mgt_key_material' in 2829 an existing profile, then that profile will have to be updated 2830 accordingly, especially with respect to the usage of 2831 'mgt_key_material' related format and content. 2833 * REQ19: Define the initial value of the 'num' parameter (sse 2834 Section 4.1.2.1). 2836 * OPT1: Optionally, specify the encoding of public keys, of 2837 'client_cred', and of 'pub_keys' if COSE_Keys are not used (see 2838 Section 4.1.2.1). 2840 * OPT2a: Optionally, specify the negotiation of parameter values for 2841 signature algorithm and signature keys, if 'sign_info' is not used 2842 (see Section 3.3). 2844 * OPT2b: Optionally, specify the additional parameters used in the 2845 Token Post exchange (see Section 3.3). 2847 * OPT3: Optionally, specify the encoding of 'pub_keys_repos' if the 2848 default is not used (see Section 4.1.2.1). 2850 * OPT4: Optionally, specify policies that instruct clients to retain 2851 messages and for how long, if they are unsuccessfully decrypted 2852 (see Section 4.4). This makes it possible to decrypt such 2853 messages after getting updated keying material. 2855 * OPT5: Optionally, specify the behavior of the handler in case of 2856 failure to retrieve a public key for the specific node (see 2857 Section 4.1.2.1). 2859 * OPT6: Optionally, specify possible or required payload formats for 2860 specific error cases. 2862 * OPT7: Optionally, specify CBOR values to use for abbreviating 2863 identifiers of roles in the group or topic (see Section 3.1). 2865 * OPT8: Optionally, specify for the KDC to perform group rekeying 2866 (together or instead of renewing individual keying material) when 2867 receiving a Key Renewal Request (see Section 4.5). 2869 * OPT9: Optionally, specify the functionalities implemented at the 2870 'control_path' resource hosted at the Client, including message 2871 exchange encoding and other details (see Section 4.1.2.1). 2873 * OPT10: Optionally, specify how the identifier of the sender's 2874 public key is included in the group request (see Section 4.7). 2876 Appendix B. Document Updates 2878 RFC EDITOR: PLEASE REMOVE THIS SECTION. 2880 B.1. Version -04 to -05 2882 * Updated uppercase/lowercase URI segments for KDC resources. 2884 * Supporting single Access Token for multiple groups/topics. 2886 * Added 'control_path' parameter in the Joining Request. 2888 * Added 'peer_roles' parameter to support legal requesters/ 2889 responders. 2891 * Clarification on stopping using owned keying material. 2893 * Clarification on different reasons for processing failures, 2894 related policies, and requirement OPT4. 2896 * Added a KDC sub-resource for group members to upload a new public 2897 key. 2899 * Possible group rekeying following an individual Key Renewal 2900 Request. 2902 * Clarified meaning of requirement REQ3; added requirement OPT8. 2904 * Editorial improvements. 2906 B.2. Version -03 to -04 2908 * Revised RESTful interface, as to methods and parameters. 2910 * Extended processing of joining request, as to check/retrieval of 2911 public keys. 2913 * Revised and extended profile requirements. 2915 * Clarified specific usage of parameters related to signature 2916 algorithms/keys. 2918 * Included general content previously in draft-ietf-ace-key- 2919 groupcomm-oscore 2921 * Registration of media type and content format application/ace- 2922 group+cbor 2924 * Editorial improvements. 2926 B.3. Version -02 to -03 2928 * Exchange of information on the countersignature algorithm and 2929 related parameters, during the Token POST (Section 3.3). 2931 * Restructured KDC interface, with new possible operations 2932 (Section 4). 2934 * Client PoP signature for the Joining Request upon joining 2935 (Section 4.1.2.1). 2937 * Revised text on group member removal (Section 5). 2939 * Added more profile requirements (Appendix A). 2941 B.4. Version -01 to -02 2943 * Editorial fixes. 2945 * Distinction between transport profile and application profile 2946 (Section 1.1). 2948 * New parameters 'sign_info' and 'pub_key_enc' to negotiate 2949 parameter values for signature algorithm and signature keys 2950 (Section 3.3). 2952 * New parameter 'type' to distinguish different Key Distribution 2953 Request messages (Section 4.1). 2955 * New parameter 'client_cred_verify' in the Key Distribution Request 2956 to convey a Client signature (Section 4.1). 2958 * Encoding of 'pub_keys_repos' (Section 4.1). 2960 * Encoding of 'mgt_key_material' (Section 4.1). 2962 * Improved description on retrieval of new or updated keying 2963 material (Section 6). 2965 * Encoding of 'get_pub_keys' in Public Key Request (Section 7.1). 2967 * Extended security considerations (Sections 10.1 and 10.2). 2969 * New "ACE Public Key Encoding" IANA Registry (Section 11.2). 2971 * New "ACE Groupcomm Parameters" IANA Registry (Section 11.3), 2972 populated with the entries in Section 8. 2974 * New "Ace Groupcomm Request Type" IANA Registry (Section 11.4), 2975 populated with the values in Section 9. 2977 * New "ACE Groupcomm Policy" IANA Registry (Section 11.7) populated 2978 with two entries "Sequence Number Synchronization Method" and "Key 2979 Update Check Interval" (Section 4.2). 2981 * Improved list of requirements for application profiles 2982 (Appendix A). 2984 B.5. Version -00 to -01 2986 * Changed name of 'req_aud' to 'audience' in the Authorization 2987 Request (Section 3.1). 2989 * Defined error handling on the KDC (Sections 4.2 and 6.2). 2991 * Updated format of the Key Distribution Response as a whole 2992 (Section 4.2). 2994 * Generalized format of 'pub_keys' in the Key Distribution Response 2995 (Section 4.2). 2997 * Defined format for the message to request leaving the group 2998 (Section 5.2). 3000 * Renewal of individual keying material and methods for group 3001 rekeying initiated by the KDC (Section 6). 3003 * CBOR type for node identifiers in 'get_pub_keys' (Section 7.1). 3005 * Added section on parameter identifiers and their CBOR keys 3006 (Section 8). 3008 * Added request types for requests to a Join Response (Section 9). 3010 * Extended security considerations (Section 10). 3012 * New IANA registries "ACE Groupcomm Key Registry", "ACE Groupcomm 3013 Profile Registry", "ACE Groupcomm Policy Registry" and "Sequence 3014 Number Synchronization Method Registry" (Section 11). 3016 * Added appendix about requirements for application profiles of ACE 3017 on group communication (Appendix A). 3019 Acknowledgments 3021 The following individuals were helpful in shaping this document: 3022 Christian Amsuess, Carsten Bormann, Rikard Hoeglund, Ben Kaduk, John 3023 Mattsson, Daniel Migault, Jim Schaad, Ludwig Seitz, Goeran Selander 3024 and Peter van der Stok. 3026 The work on this document has been partly supported by VINNOVA and 3027 the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home 3028 (Grant agreement 952652); and by the EIT-Digital High Impact 3029 Initiative ACTIVE. 3031 Authors' Addresses 3033 Francesca Palombini 3034 Ericsson AB 3035 Torshamnsgatan 23 3036 SE-16440 Stockholm Kista 3037 Sweden 3039 Email: francesca.palombini@ericsson.com 3041 Marco Tiloca 3042 RISE AB 3043 Isafjordsgatan 22 3044 SE-16440 Stockholm Kista 3045 Sweden 3047 Email: marco.tiloca@ri.se