idnits 2.17.1 draft-ietf-ace-key-groupcomm-oscore-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 02, 2020) is 1264 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) == Missing Reference: 'Toid' is mentioned on line 2141, but not defined == Missing Reference: 'Tperm' is mentioned on line 2141, but not defined == Missing Reference: 'RSA' is mentioned on line 1706, but not defined == Missing Reference: 'OKP' is mentioned on line 1748, but not defined == Missing Reference: 'Ed25519' is mentioned on line 1682, but not defined == Missing Reference: 'Ed448' is mentioned on line 1686, but not defined == Missing Reference: 'EC2' is mentioned on line 1763, but not defined == Missing Reference: 'P-256' is mentioned on line 1753, but not defined == Missing Reference: 'P-384' is mentioned on line 1758, but not defined == Missing Reference: 'P-521' is mentioned on line 1763, but not defined == Missing Reference: 'X25519' is mentioned on line 1744, but not defined == Missing Reference: 'X448' is mentioned on line 1748, but not defined -- Looks like a reference, but probably isn't: '1' on line 2469 -- Looks like a reference, but probably isn't: '2' on line 2471 == Outdated reference: A later version (-07) exists of draft-ietf-ace-aif-00 == Outdated reference: A later version (-18) exists of draft-ietf-ace-key-groupcomm-10 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-35 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-13 -- 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-10 ** 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' ** Downref: Normative reference to an Informational RFC: RFC 6979 ** Downref: Normative reference to an Informational RFC: RFC 8017 ** Downref: Normative reference to an Informational RFC: RFC 8032 == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-14 == Outdated reference: A later version (-11) exists of draft-ietf-ace-oscore-gm-admin-01 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-10 == Outdated reference: A later version (-10) exists of draft-ietf-core-groupcomm-bis-02 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-07 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 4 errors (**), 0 flaws (~~), 25 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group M. Tiloca 3 Internet-Draft RISE AB 4 Intended status: Standards Track J. Park 5 Expires: May 6, 2021 Universitaet Duisburg-Essen 6 F. Palombini 7 Ericsson AB 8 November 02, 2020 10 Key Management for OSCORE Groups in ACE 11 draft-ietf-ace-key-groupcomm-oscore-09 13 Abstract 15 This specification defines an application profile of the ACE 16 framework for Authentication and Authorization, to request and 17 provision keying material in group communication scenarios that are 18 based on CoAP and secured with Group Object Security for Constrained 19 RESTful Environments (OSCORE). This application profile delegates 20 the authentication and authorization of Clients that join an OSCORE 21 group through a Resource Server acting as Group Manager for that 22 group. This application profile leverages protocol-specific 23 transport profiles of ACE to achieve communication security, server 24 authentication and proof-of-possession for a key owned by the Client 25 and bound to an OAuth 2.0 Access Token. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 6, 2021. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 64 2.1. Overview of the Joining Process . . . . . . . . . . . . . 6 65 2.2. Overview of the Group Rekeying Process . . . . . . . . . 6 66 3. Format of Scope . . . . . . . . . . . . . . . . . . . . . . . 7 67 4. Joining Node to Authorization Server . . . . . . . . . . . . 8 68 4.1. Authorization Request . . . . . . . . . . . . . . . . . . 9 69 4.2. Authorization Response . . . . . . . . . . . . . . . . . 9 70 5. Interface at the Group Manager . . . . . . . . . . . . . . . 9 71 5.1. ace-group/GROUPNAME/active . . . . . . . . . . . . . . . 10 72 5.1.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 10 73 5.2. Admitted Methods . . . . . . . . . . . . . . . . . . . . 11 74 6. Token POST and Group Joining . . . . . . . . . . . . . . . . 11 75 6.1. Token Post . . . . . . . . . . . . . . . . . . . . . . . 12 76 6.1.1. 'ecdh_info' Parameter . . . . . . . . . . . . . . . . 14 77 6.2. Sending the Joining Request . . . . . . . . . . . . . . . 16 78 6.2.1. Value of the N_S Challenge . . . . . . . . . . . . . 17 79 6.3. Processing the Joining Request . . . . . . . . . . . . . 17 80 6.4. Joining Response . . . . . . . . . . . . . . . . . . . . 19 81 7. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 23 82 8. Retrieval of Updated Keying Material . . . . . . . . . . . . 25 83 8.1. Retrieval of Group Keying Material . . . . . . . . . . . 25 84 8.2. Retrieval of Group Keying Material and Sender ID . . . . 26 85 9. Requesting a Change of Keying Material . . . . . . . . . . . 26 86 10. Retrieval of Public Keys and Roles for Group Members . . . . 27 87 11. Update of Public Key . . . . . . . . . . . . . . . . . . . . 28 88 12. Retrieval of Group Policies . . . . . . . . . . . . . . . . . 29 89 13. Retrieval of Keying Material Version . . . . . . . . . . . . 29 90 14. Retrieval of Group Status . . . . . . . . . . . . . . . . . . 29 91 15. Retrieval of Group Names and URIs . . . . . . . . . . . . . . 30 92 16. Request to Leave the Group . . . . . . . . . . . . . . . . . 32 93 17. Removal of a Group Member . . . . . . . . . . . . . . . . . . 32 94 18. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 33 95 19. Default Values for Group Configuration Parameters . . . . . . 35 96 20. Security Considerations . . . . . . . . . . . . . . . . . . . 38 97 20.1. Management of OSCORE Groups . . . . . . . . . . . . . . 38 98 20.2. Size of Nonces for Signature Challenge . . . . . . . . . 39 99 20.3. Reusage of Nonces for Signature Challenge . . . . . . . 40 100 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 101 21.1. ACE Groupcomm Parameters Registry . . . . . . . . . . . 40 102 21.2. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 41 103 21.3. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 41 104 21.4. Sequence Number Synchronization Method Registry . . . . 41 105 21.5. OSCORE Security Context Parameters Registry . . . . . . 42 106 21.6. TLS Exporter Label Registry . . . . . . . . . . . . . . 44 107 21.7. AIF Registry . . . . . . . . . . . . . . . . . . . . . . 45 108 21.8. Media Type Registrations . . . . . . . . . . . . . . . . 45 109 21.9. CoAP Content-Format Registry . . . . . . . . . . . . . . 46 110 21.10. Group OSCORE Roles Registry . . . . . . . . . . . . . . 46 111 21.11. CoRE Resource Type Registry . . . . . . . . . . . . . . 47 112 21.12. Expert Review Instructions . . . . . . . . . . . . . . . 47 113 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 114 22.1. Normative References . . . . . . . . . . . . . . . . . . 48 115 22.2. Informative References . . . . . . . . . . . . . . . . . 51 116 22.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 52 117 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 52 118 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 55 119 B.1. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 56 120 B.2. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 56 121 B.3. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 57 122 B.4. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 57 123 B.5. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 58 124 B.6. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 58 125 B.7. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 59 126 B.8. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 59 127 B.9. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 60 128 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 60 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 131 1. Introduction 133 Object Security for Constrained RESTful Environments (OSCORE) 134 [RFC8613] is a method for application-layer protection of the 135 Constrained Application Protocol (CoAP) [RFC7252], using CBOR Object 136 Signing and Encryption (COSE) 137 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs] and 138 enabling end-to-end security of CoAP payload and options. 140 As described in [I-D.ietf-core-oscore-groupcomm], Group OSCORE is 141 used to protect CoAP group communication over IP multicast 142 [I-D.ietf-core-groupcomm-bis]. This relies on a Group Manager, which 143 is responsible for managing an OSCORE group and enables the group 144 members to exchange CoAP messages secured with Group OSCORE. The 145 Group Manager can be responsible for multiple groups, coordinates the 146 joining process of new group members, and is entrusted with the 147 distribution and renewal of group keying material. 149 This specification is an application profile of 150 [I-D.ietf-ace-key-groupcomm], which itself builds on the ACE 151 framework for Authentication and Authorization 152 [I-D.ietf-ace-oauth-authz]. Message exchanges among the participants 153 as well as message formats and processing follow what specified in 154 [I-D.ietf-ace-key-groupcomm] for provisioning and renewing keying 155 material in group communication scenarios, where Group OSCORE is used 156 to protect CoAP group communication over IP multicast. 158 1.1. Terminology 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in BCP 163 14 [RFC2119][RFC8174] when, and only when, they appear in all 164 capitals, as shown here. 166 Readers are expected to be familiar with: 168 o The terms and concepts described in the ACE framework for 169 authentication and authorization [I-D.ietf-ace-oauth-authz] and in 170 the Authorization Information Format (AIF) [I-D.ietf-ace-aif] to 171 express authorization information. The terminology for entities 172 in the considered architecture is defined in OAuth 2.0 [RFC6749]. 173 In particular, this includes Client (C), Resource Server (RS), and 174 Authorization Server (AS). 176 o The terms and concept related to the message formats and 177 processing specified in [I-D.ietf-ace-key-groupcomm], for 178 provisioning and renewing keying material in group communication 179 scenarios. 181 o The terms and concepts described in CBOR [I-D.ietf-cbor-7049bis] 182 and COSE 183 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs]. 185 o The terms and concepts decribed in CoAP [RFC7252] and group 186 communication for CoAP [I-D.ietf-core-groupcomm-bis]. Unless 187 otherwise indicated, the term "endpoint" is used here following 188 its OAuth definition, aimed at denoting resources such as /token 189 and /introspect at the AS, and /authz-info at the RS. This 190 document does not use the CoAP definition of "endpoint", which is 191 "An entity participating in the CoAP protocol". 193 o The terms and concepts for protection and processing of CoAP 194 messages through OSCORE [RFC8613] and through Group OSCORE 195 [I-D.ietf-core-oscore-groupcomm] in group communication scenarios. 196 These include the concept of Group Manager, as the entity 197 responsible for a set of groups where communications are secured 198 with Group OSCORE. In this specification, the Group Manager acts 199 as Resource Server. 201 Additionally, this document makes use of the following terminology. 203 o Requester: member of an OSCORE group that sends request messages 204 to other members of the group. 206 o Responder: member of an OSCORE group that receives request 207 messages from other members of the group. A responder may reply 208 back, by sending a response message to the requester which has 209 sent the request message. 211 o Monitor: member of an OSCORE group that is configured as responder 212 and never replies back to requesters after receiving request 213 messages. This corresponds to the term "silent server" used in 214 [I-D.ietf-core-oscore-groupcomm]. 216 o Signature verifier: entity external to the OSCORE group and 217 intended to verify the countersignature of messages exchanged in 218 the group. An authorized signature verifier does not join the 219 OSCORE group as an actual member, yet it can retrieve the public 220 keys of the current group members from the Group Manager. 222 2. Protocol Overview 224 Group communication for CoAP over IP multicast has been enabled in 225 [I-D.ietf-core-groupcomm-bis] and can be secured with Group Object 226 Security for Constrained RESTful Environments (OSCORE) [RFC8613] as 227 described in [I-D.ietf-core-oscore-groupcomm]. A network node joins 228 an OSCORE group by interacting with the responsible Group Manager. 229 Once registered in the group, the new node can securely exchange 230 messages with other group members. 232 This specification describes how to use [I-D.ietf-ace-key-groupcomm] 233 and [I-D.ietf-ace-oauth-authz] to perform a number of authentication, 234 authorization and key distribution actions, as defined in Section 2 235 of [I-D.ietf-ace-key-groupcomm], for an OSCORE group. 237 With reference to [I-D.ietf-ace-key-groupcomm]: 239 o The node wishing to join the OSCORE group, i.e. the joining node, 240 is the Client. 242 o The Group Manager is the Key Distribution Center (KDC), acting as 243 a Resource Server. 245 o The Authorization Server associated to the Group Manager is the 246 AS. 248 All communications between the involved entities MUST be secured. 250 In particular, communications between the Client and the Group 251 Manager leverage protocol-specific transport profiles of ACE to 252 achieve communication security, proof-of-possession and server 253 authentication. It is expected that, in the commonly referred base- 254 case of this specification, the transport profile to use is pre- 255 configured and well-known to nodes participating in constrained 256 applications. 258 Appendix A lists the specifications on this application profile of 259 ACE, based on the requirements defined in Appendix A of 260 [I-D.ietf-ace-key-groupcomm]. 262 2.1. Overview of the Joining Process 264 A node performs the steps described in Section 4.3 of 265 [I-D.ietf-ace-key-groupcomm] in order to join an OSCORE group. The 266 format and processing of messages exchanged among the participants 267 are further specified in Section 4 and Section 6 of this document. 269 2.2. Overview of the Group Rekeying Process 271 If the application requires backward and forward security, the Group 272 Manager MUST generate new keying material and distribute it to the 273 group (rekeying) upon membership changes. 275 That is, the group is rekeyed when a node joins the group as a new 276 member, or after a current member leaves the group. By doing so, a 277 joining node cannot access communications in the group prior its 278 joining, while a leaving node cannot access communications in the 279 group after its leaving. 281 The keying material distributed through a group rekeying MUST 282 include: 284 o A new Group Identifier (Gid) for the group as introduced in 285 [I-D.ietf-ace-key-groupcomm], used as ID Context parameter of the 286 Group OSCORE Common Security Context of that group (see Section 2 287 of [I-D.ietf-core-oscore-groupcomm]). 289 Note that the Gid differs from the group name also introduced in 290 [I-D.ietf-ace-key-groupcomm], which is a plain, stable and 291 invariant identifier, with no cryptographic relevance and meaning. 293 o A new value for the Master Secret parameter of the Group OSCORE 294 Common Security Context of that group (see Section 2 of 295 [I-D.ietf-core-oscore-groupcomm]). 297 Also, the distributed keying material MAY include a new value for the 298 Master Salt parameter of the Group OSCORE Common Security Context of 299 that group. 301 Upon generating the new group keying material and before starting its 302 distribution, the Group Manager MUST increment the version number of 303 the group keying material. When rekeying a group, the Group Manager 304 MUST preserve the current value of the Sender ID of each member in 305 that group. 307 The Group Manager MUST support the Group Rekeying Process described 308 in Section 18. Future application profiles may define alternative 309 message formats and distribution schemes to perform group rekeying. 311 3. Format of Scope 313 Building on Section 3.1 of [I-D.ietf-ace-key-groupcomm], this section 314 defines the exact format and encoding of scope to use. 316 To this end, this profile uses the Authorization Information Format 317 (AIF) [I-D.ietf-ace-aif], and defines the following AIF specific data 318 model AIF-OSCORE-GROUPCOMM. 320 With reference to the generic AIF model 322 AIF-Generic = [* [Toid, Tperm]] 324 the value of the CBOR byte string used as scope encodes the CBOR 325 array [* [Toid, Tperm]], where each [Toid, Tperm] element corresponds 326 to one scope entry. 328 Then, for each scope entry: 330 o the object identifier ("Toid") is specialized as a CBOR text 331 string, specifying the group name for the scope entry; 333 o the permission set ("Tperm") is specialized as a CBOR unsigned 334 integer with value R, specifying the role(s) that the client 335 wishes to take in the group (REQ2). The value R is computed as 336 follows: 338 * each role in the permission set is converted into the 339 corresponding numeric identifier X from the "Value" column of 340 the table in Figure 1. 342 * the set of N numbers is converted into the single value R, by 343 taking each numeric identifier X_1, X_2, ..., X_N to the power 344 of two, and then computing the inclusive OR of the binary 345 representations of all the power values. 347 +-----------+-------+-------------------------------------------------+ 348 | Name | Value | Description | 349 +===========+=======+=================================================+ 350 | Reserved | 0 | This value is reserved | 351 |-----------+-------+-------------------------------------------------+ 352 | Requester | 1 | Send requests; receive responses | 353 |-----------+-------+-------------------------------------------------+ 354 | Responder | 2 | Send responses; receive requests | 355 +-----------+-------+-------------------------------------------------+ 356 | Monitor | 3 | Receive requests; never send requests/responses | 357 |-----------+-------+-------------------------------------------------| 358 | Verifier | 4 | Verify countersignature of intercepted messages | 359 +-----------+-------+-------------------------------------------------+ 361 Figure 1: Numeric identifier of roles in the OSCORE group 363 The CDDL [RFC8610] definition of the AIF-OSCORE-GROUPCOMM data model 364 is as follows: 366 AIF-OSCORE-GROUPCOMM = AIF_Generic 368 path = tstr ; Group name 369 permissions = uint . bits roles 370 roles = &( 371 Requester: 1, 372 Responder: 2, 373 Monitor: 3, 374 Verifier: 4 375 ) 377 Future specifications that define new roles MUST register a 378 corresponding numeric identifier in the "Group OSCORE Roles" Registry 379 defined in Section 21.10 of this specification. 381 4. Joining Node to Authorization Server 383 This section describes how the joining node interacts with the AS in 384 order to be authorized to join an OSCORE group under a given Group 385 Manager. In particular, it considers a joining node that intends to 386 contact that Group Manager for the first time. 388 The message exchange between the joining node and the AS consists of 389 the messages Authorization Request and Authorization Response defined 390 in Section 3 of [I-D.ietf-ace-key-groupcomm]. Note that what is 391 defined in [I-D.ietf-ace-key-groupcomm] applies, and only additions 392 or modifications to that specification are defined here. 394 4.1. Authorization Request 396 The Authorization Request message is as defined in Section 3.1 of 397 [I-D.ietf-ace-key-groupcomm], with the following additions. 399 o If the 'scope' parameter is present: 401 * The value of the CBOR byte string encodes a CBOR array, whose 402 format MUST follow the data model AIF-OSCORE-GROUPCOMM defined 403 in Section 3. In particular, for each OSCORE group to join: 405 + The group name is encoded as a CBOR text string. 407 + The set of requested roles is expressed as a single CBOR 408 unsigned integer, computed as defined in Section 3 (REQ2) 409 from the numerical abbreviations defined in Figure 1 for 410 each requested role (OPT7). 412 4.2. Authorization Response 414 The Authorization Response message is as defined in Section 3.2 of 415 [I-D.ietf-ace-key-groupcomm], with the following additions: 417 o The AS MUST include the 'expires_in' parameter. Other means for 418 the AS to specify the lifetime of Access Tokens are out of the 419 scope of this specification. 421 o The AS MUST include the 'scope' parameter, when the value included 422 in the Access Token differs from the one specified by the joining 423 node in the request. In such a case, the second element of each 424 scope entry MUST be present, and specifies the set of roles that 425 the joining node is actually authorized to take in the OSCORE 426 group for that scope entry, encoded as specified in Section 4.1. 428 5. Interface at the Group Manager 430 The Group Manager provides the interface defined in Section 4.1 of 431 [I-D.ietf-ace-key-groupcomm], with one additional sub-resource 432 defined in Section 5.1 of this specification. 434 Furthermore, Section 5.2 provides a summary of the CoAP methods 435 admitted to access different resources at the Group Manager, for 436 nodes with different roles in the group or as non members (REQ7aa). 438 The GROUPNAME segment of the URI path MUST match with the group name 439 specified in the scope entry of the Access Token scope (i.e. 'gname' 440 in Section 3.1 of [I-D.ietf-ace-key-groupcomm]) (REQ1). 442 The Resource Type (rt=) Link Target Attribute value "core.osc.gm" is 443 registered in Section 21.11 (REQ7a), and can be used to describe 444 group-membership resources and its sub-resources at a Group Manager, 445 e.g. by using a link-format document [RFC6690]. 447 Applications can use this common resource type to discover links to 448 group-membership resources for joining OSCORE groups, e.g. by using 449 the approach described in [I-D.tiloca-core-oscore-discovery]. 451 5.1. ace-group/GROUPNAME/active 453 This resource implements a GET handler. 455 5.1.1. GET Handler 457 The handler expects a GET request. 459 The Group Manager verifies that the group name in the /ace- 460 group/GROUPNAME/active path is a subset of the 'scope' stored in the 461 Access Token associated to the requesting client. 463 The Group Manager also verifies that the roles granted to the 464 requesting client in the group allow it to perform this operation on 465 this resource (REQ7aa). If either verification fails, the Group 466 Manager MUST respond with a 4.01 (Unauthorized) error message. 468 Additionally, the handler verifies that the requesting client is a 469 current member of the group. If verification fails, the Group 470 Manager MUST respond with a 4.01 (Unauthorized) error message. 472 If verification succeeds, the handler returns a 2.05 (Content) 473 message containing the CBOR simple value True if the group is 474 currently active, or the CBOR simple value False otherwise. The 475 group is considered active if it is set to allow new members to join, 476 and if communication within the group is fine to happen. 478 The method to set the current group status, i.e. active or inactive, 479 is out of the scope of this specification, and is defined for the 480 administrator interface of the Group Manager specified in 481 [I-D.ietf-ace-oscore-gm-admin]. 483 5.2. Admitted Methods 485 The table in Figure 2 summarizes the CoAP methods admitted to access 486 different resources at the Group Manager, for (non-)members of a 487 group with group name GROUPNAME, and considering different roles. 488 The last two rows of the table apply to a node with node name 489 NODENAME. 491 +------------------------------+--------+-------+-------+-------+ 492 | Resource | Type1 | Type2 | Type3 | Type4 | 493 +------------------------------+--------+-------+-------+-------+ 494 | ace-group/ | F | F | F | - | 495 +------------------------------+--------+-------+-------+-------+ 496 | ace-group/GROUPNAME/ | G Po | G Po | Po * | Po | 497 +------------------------------+--------+-------+-------+-------+ 498 | ace-group/GROUPNAME/active | G | G | - | - | 499 +------------------------------+--------+-------+-------+-------+ 500 | ace-group/GROUPNAME/pub-key | G F | G F | G F | - | 501 +------------------------------+--------+-------+-------+-------+ 502 | ace-group/GROUPNAME/policies | G | G | - | - | 503 +------------------------------+--------+-------+-------+-------+ 504 | ace-group/GROUPNAME/num | G | G | - | - | 505 +------------------------------+--------+-------+-------+-------+ 506 | ace-group/GROUPNAME/nodes/ | G Pu D | G D | - | - | 507 | NODENAME | | | | | 508 +------------------------------+--------+-------+-------+-------+ 509 | ace-group/GROUPNAME/nodes/ | Po | - | - | - | 510 | NODENAME/pub-key | | | | | 511 +------------------------------+--------+-------+-------+-------+ 513 Type1 = Member as Requester and/or Responder | G = GET 514 Type2 = Member as Monitor | F = FETCH 515 Type3 = Non-member / Authorized to be Verifier | Po = POST 516 (*) = cannot join the group as Verifier | Pu = PUT 517 Type4 = Non-member / Not authorized to be Verifier | D = DELETE 519 Figure 2: Admitted CoAP Methods on the Group Manager Resources 521 6. Token POST and Group Joining 523 The rest of this section describes the interactions between the 524 joining node and the Group Manager, i.e. the sending of the Access 525 Token and the Request-Response exchange to join the OSCORE group. 526 The message exchange between the joining node and the Group Manager 527 consists of the messages defined in Section 3.3 and 4.3 of 528 [I-D.ietf-ace-key-groupcomm]. Note that what is defined in 529 [I-D.ietf-ace-key-groupcomm] applies, and only additions or 530 modifications to that specification are defined here. 532 A signature verifier provides the Group Manager with an Access Token, 533 as described in Section 6.1, just as any another joining node does. 534 However, unlike candidate group members, it does not join any OSCORE 535 group, i.e. it does not perform the joining process defined in 536 Section 6.2. After successfully posting an Access Token, a signature 537 verifier is authorized to perform only the operations specified in 538 Section 10, to retrieve the public keys of group members, and only 539 for the OSCORE groups specified in the validated Access Token. The 540 Group Manager MUST respond with a 4.01 (Unauthorized) error message, 541 in case a signature verifier attempts to access any other endpoint 542 than /ace-group/GROUPNAME/pub-key at the Group Manager. 544 6.1. Token Post 546 The Token post exchange is defined in Section 3.3 of 547 [I-D.ietf-ace-key-groupcomm]. 549 Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the 550 following applies. 552 o The CoAP POST request MAY additionally contain the following 553 parameter, which, if included, MUST have the corresponding values: 555 * 'ecdh_info' defined in Section 6.1.1, encoding the CBOR simple 556 value Null to require information on the ECDH algorithm, the 557 ECDH algorithm parameters, the ECDH key parameters and on the 558 exact encoding of public keys used in the group, in case the 559 joining node supports the pairwise mode of Group OSCORE 560 [I-D.ietf-core-oscore-groupcomm]. 562 Alternatively, the joining node may retrieve this information by 563 other means. 565 o The 'kdcchallenge' parameter contains a dedicated nonce N_S 566 generated by the Group Manager. For the N_S value, it is 567 RECOMMENDED to use a 8-byte long random nonce. The joining node 568 can use this nonce in order to prove the possession of its own 569 private key, upon joining the group (see Section 6.2). 571 The 'kdcchallenge' parameter MAY be omitted from the 2.01 572 (Created) response, if the 'scope' of the Access Token specifies 573 only the role "monitor" or only the role "verifier" or both of 574 them, for each and every of the specified groups. 576 o If the 'sign_info' parameter is present in the response, the 577 following applies for each element 'sign_info_entry'. 579 * 'sign_alg' takes value from the "Value" column of the "COSE 580 Algorithms" Registry [COSE.Algorithms]. 582 * 'sign_parameters' is a CBOR array including the following two 583 elements: 585 + 'sign_alg_capab', encoded as a CBOR array. Its format and 586 value are the same of the COSE capabilities for the 587 algorithm indicated in 'sign_alg', as specified for that 588 algorithm in the "Capabilities" column of the "COSE 589 Algorithms" Registry [COSE.Algorithms] (REQ4). 591 + 'sign_key_type_capab', encoded as a CBOR array. Its format 592 and value are the same of the COSE capabilities for the COSE 593 key type of the keys used with the algorithm indicated in 594 'sign_alg', as specified for that key type in the 595 "Capabilities" column of the "COSE Key Types" Registry 596 [COSE.Key.Types] (REQ4). 598 * 'sign_key_parameters' is a CBOR array. Its format and value 599 are the same of the COSE capabilities for the COSE key type of 600 the keys used with the algorithm indicated in 'sign_alg', as 601 specified for that key type in the "Capabilities" column of the 602 "COSE Key Types" Registry [COSE.Key.Types] (REQ5). 604 * 'pub_key_enc' takes value 1 ("COSE_Key") from the 'Confirmation 605 Key' column of the "CWT Confirmation Method" Registry 606 [CWT.Confirmation.Methods], so indicating that public keys in 607 the OSCORE group are encoded as COSE Keys 608 [I-D.ietf-cose-rfc8152bis-struct]. Future specifications may 609 define additional values for this parameter. 611 o If 'ecdh_info' is included in the request, the Group Manager MAY 612 include the 'ecdh_info' parameter defined in Section 6.1.1, with 613 the same encoding. Note that the field 'id' takes as value the 614 group name, or array of group names, for which the corresponding 615 'ecdh_info_entry' applies to. 617 Note that, other than through the above parameters as defined in 618 Section 3.3 of [I-D.ietf-ace-key-groupcomm], the joining node MAY 619 have previously retrieved this information by other means, e.g. by 620 using the approach described in [I-D.tiloca-core-oscore-discovery] to 621 discover the OSCORE group and the link to the associated group- 622 membership resource at the Group Manager (OPT2a). 624 Additionally, if allowed by the used transport profile of ACE, the 625 joining node may instead provide the Access Token to the Group 626 Manager by other means, e.g. during a secure session establishment 627 (see Section 3.3.2 of [I-D.ietf-ace-dtls-authorize]). 629 6.1.1. 'ecdh_info' Parameter 631 The 'ecdh_info' parameter is an OPTIONAL parameter of the Token Post 632 response message defined in Section 5.1.2. of 633 [I-D.ietf-ace-oauth-authz]. 635 This parameter is used to require and retrieve from the Group Manager 636 information and parameters about the ECDH algorithm and about the 637 public keys to be used in the OSCORE group to compute a static-static 638 Diffie-Hellman shared secret [NIST-800-56A], in case the group 639 supports the pairwise mode of Group OSCORE 640 [I-D.ietf-core-oscore-groupcomm]. 642 When used in the request, the 'ecdh_info' parameter encodes the CBOR 643 simple value Null, to require information and parameters on the ECDH 644 algorithm and on the public keys to be used to compute Diffie-Hellman 645 shared secrets in the OSCORE group. 647 The CDDL notation [RFC8610] of the 'ecdh_info' parameter formatted as 648 in the request is given below. 650 ecdh_info_req = nil 652 The 'ecdh_info' parameter of the 2.01 (Created) response is a CBOR 653 array of one or more elements. The number of elements is at most the 654 number of OSCORE groups the client has been authorized to join. 656 Each element contains information about ECDH parameters and about 657 public keys, for one or more OSCORE groups that support the pairwise 658 mode of Group OSCORE and that the client has been authorized to join. 659 Each element is formatted as follows. 661 o The first element 'id' is the group name of the OSCORE group or an 662 array of group names for the OSCORE groups for which the specified 663 information applies. 665 o The second element 'ecdh_alg' is an CBOR integer or a CBOR text 666 string indicating the ECDH algorithm used in the OSCORE group 667 identified by 'gname'. Values are taken from the "Value" column 668 of the "COSE Algorithms" Registry [COSE.Algorithms]. 670 o The third element 'ecdh_parameters' is a CBOR array indicating the 671 parameters of the ECDH algorithm used in the OSCORE group 672 identified by 'gname'. The CBOR array includes the following two 673 elements, and its exact content depends on the value of the 674 'ecdh_alg' element. 676 * 'ecdh_alg_capab', encoded as a CBOR array. Its format and 677 value are the same of the COSE capabilities for the algorithm 678 indicated in 'ecdh_alg', as specified for that algorithm in the 679 "Capabilities" column of the "COSE Algorithms" Registry 680 [COSE.Algorithms]. 682 * 'ecdh_key_type_capab', encoded as a CBOR array. Its format and 683 value are the same of the COSE capabilities for the COSE key 684 type of the keys used with the algorithm indicated in 685 'ecdh_alg', as specified for that key type in the 686 "Capabilities" column of the "COSE Key Types" Registry 687 [COSE.Key.Types]. 689 o The fourth element 'ecdh_key_parameters' is a CBOR array 690 indicating the parameters of the keys used with the ECDH algorithm 691 in the OSCORE group identified by 'gname'. Its content depends on 692 the value of 'ecdh_alg'. In particular, its format and value are 693 the same of the COSE capabilities for the COSE key type of the 694 keys used with the algorithm indicated in 'ecdh_alg', as specified 695 for that key type in the "Capabilities" column of the "COSE Key 696 Types" Registry [COSE.Key.Types]. 698 o The fifth element 'pub_key_enc' is CBOR integer indicating the 699 encoding of public keys used in the OSCORE group identified by 700 'gname'. It takes value 1 ("COSE_Key") from the 'Confirmation 701 Key' column of the "CWT Confirmation Method" Registry 702 [CWT.Confirmation.Methods], so indicating that public keys in the 703 OSCORE group are encoded as COSE Keys 704 [I-D.ietf-cose-rfc8152bis-struct]. Future specifications may 705 define additional values for this parameter. 707 The CDDL notation [RFC8610] of the 'ecdh_info' parameter formatted as 708 in the response is given below. 710 ecdh_info_res = [ + ecdh_info_entry ] 712 ecdh_info_entry = 713 [ 714 id : gname / [ + gname ], 715 ecdh_alg : int / tstr, 716 ecdh_parameters : [ any ], 717 ecdh_key_parameters : [ any ], 718 pub_key_enc = int 719 ] 721 gname = tstr 723 6.2. Sending the Joining Request 725 The joining node requests to join the OSCORE group by sending a 726 Joining Request message to the related group-membership resource at 727 the Group Manager, as per Section 4.3 of 728 [I-D.ietf-ace-key-groupcomm]. 730 Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the 731 following applies. 733 o The 'scope' parameter MUST be included. Its value encodes one 734 scope entry with the format defined in Section 3, indicating the 735 group name and the role(s) that the joining node wants to take in 736 the group. 738 o The 'get_pub_keys' parameter is present only if the joining node 739 wants to retrieve the public keys of the group members from the 740 Group Manager during the joining process (see Section 7). 741 Otherwise, this parameter MUST NOT be present. 743 If this parameter is present and its value is non-null, each 744 element of the first inner CBOR array is encoded as a CBOR 745 unsigned integer, with the same value of a permission set 746 ("Tperm") indicating that role or combination of roles in a scope 747 entry, as defined in Section 3. 749 o 'cnonce' contains a dedicated nonce N_C generated by the joining 750 node. For the N_C value, it is RECOMMENDED to use a 8-byte long 751 random nonce. 753 o The signature encoded in the 'client_cred_verify' parameter is 754 computed by the joining node by using the same private key and 755 countersignature algorithm it intends to use for signing messages 756 in the OSCORE group. Moreover, N_S is as defined in 757 Section 6.2.1. 759 6.2.1. Value of the N_S Challenge 761 The value of the N_S challenge is determined as follows. 763 1. If the joining node has posted the Access Token to the /authz- 764 info endpoint of the Group Manager as in Section 6.1, N_S takes 765 the same value of the most recent 'kdcchallenge' parameter 766 received by the joining node from the Group Manager. This can be 767 either the one specified in the 2.01 (Created) response to the 768 Token POST, or the one possibly specified in a 4.00 (Bad Request) 769 response to a following Joining Request (see Section 6.3). 771 2. If the Token posting has relied on the DTLS profile of ACE 772 [I-D.ietf-ace-dtls-authorize] with the Access Token as content of 773 the "psk_identity" field of the ClientKeyExchange message 774 [RFC6347], N_S is an exporter value computed as defined in 775 Section 7.5 of [RFC8446]. Specifically, N_S is exported from the 776 DTLS session between the joining node and the Group Manager, 777 using an empty 'context_value', 32 bytes as 'key_length', and the 778 exporter label "EXPORTER-ACE-Sign-Challenge-coap-group-oscore- 779 app" defined in Section 21.6 of this specification. 781 It is up to applications to define how N_S is computed in further 782 alternative settings. 784 Section 20.3 provides security considerations on the reusage of the 785 N_S challenge. 787 6.3. Processing the Joining Request 789 The Group Manager processes the Joining Request as defined in 790 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm]. Additionally, the 791 following applies. 793 o The Group Manager MUST return a 5.03 (Service Unavailable) 794 response in case the OSCORE group that the joining node has been 795 trying to join is currently inactive (see Section 5.1). 797 o In case the joining node is not going to join the group 798 exclusively as monitor and the Joining Request does not include 799 the 'client_cred' parameter, the joining process fails if the 800 Group Manager either: i) does not store a public key with an 801 accepted format for the joining node; or ii) stores multiple 802 public keys with an accepted format for the joining node. 804 o To compute the signature contained in 'client_cred_verify', the 805 Group Manager considers: 807 * as signed value, the value of the 'scope' parameter from the 808 Joining Request as a CBOR byte string, concatenated with N_S 809 encoded as a CBOR byte string, concatenated with N_C encoded as 810 a CBOR byte string. In particular, N_S is determined as 811 described in Section 6.2.1, while N_C is the nonce provided in 812 the 'cnonce' parameter of the Joining Request; 814 * the countersignature algorithm used in the OSCORE group, and 815 possible correponding parameters; 817 * the public key of the joining node, either retrieved from the 818 'client_cred' parameter, or already stored as acquired from 819 previous interactions with the joining node. 821 o A 4.00 (Bad Request) response from the Group Manager to the 822 joining node MUST have content format application/ace+cbor. The 823 response payload is a CBOR map which MUST contain the 'sign_info' 824 parameter, including a single element 'sign_info_entry' pertaining 825 to the OSCORE group that the joining node has tried to join with 826 the Joining Request. If the group supports the pairwise mode of 827 Group OSCORE, the CBOR map MUST contain also the 'ecdh_info' 828 parameter, including a single element 'ecdh_info_entry' pertaining 829 to the OSCORE group that the joining node has tried to join with 830 the Joining Request. 832 o The Group Manager MUST return a 4.00 (Bad Request) response in 833 case the 'scope' parameter is not present in the Joining Request, 834 or if it is present and specifies any set of roles not included in 835 the following list: "requester", "responder", "monitor", 836 ("requester", "responder"). Future specifications that define a 837 new role MUST define possible sets of roles including the new one 838 and existing ones, that are acceptable to specify in the 'scope' 839 parameter of a Joining Request. 841 o The Group Manager MUST return a 4.00 (Bad Request) response in 842 case the Joining Request includes the 'client_cred' parameter but 843 does not include both the 'cnonce' and 'client_cred_verify' 844 parameters. 846 o The Group Manager MUST return a 4.00 (Bad Request) response in 847 case it cannot retrieve a public key with an accepted format for 848 the joining node, either from the 'client_cred' parameter or as 849 already stored. 851 o When receiving a 4.00 Bad Request response, the joining node 852 SHOULD send a new Joining Request to the Group Manager, where: 854 * The 'cnonce' parameter MUST include a new dedicated nonce N_C 855 generated by the joining node. 857 * The 'client_cred' parameter MUST include a public key 858 compatible with the encoding, countersignature algorithm and 859 possible associated parameters indicated by the Group Manager. 861 * The 'client_cred_verify' parameter MUST include a signature 862 computed as described in Section 6.2, by using the public key 863 indicated in the current 'client_cred' parameter, with the 864 countersignature algorithm and possible associated parameters 865 indicated by the Group Manager. If the error response from the 866 Group Manager included the 'kdcchallenge' parameter, the 867 joining node MUST use its content as new N_S challenge to 868 compute the signature. 870 6.4. Joining Response 872 If the processing of the Joining Request described in Section 6.3 is 873 successful, the Group Manager updates the group membership by 874 registering the joining node NODENAME as a new member of the OSCORE 875 group GROUPNAME, as described in Section 4.1.2.1 of 876 [I-D.ietf-ace-key-groupcomm]. 878 If the joining node has not taken exclusively the role of monitor, 879 the Group Manager performs also the following actions. 881 o The Group Manager selects an available OSCORE Sender ID in the 882 OSCORE group, and exclusively assigns it to the joining node. 883 Consistently with Section 3 of [I-D.ietf-core-oscore-groupcomm], 884 the Group Manager MUST assign a Sender ID that has never been 885 assigned before in the OSCORE group. The Group Manager MUST NOT 886 assign a Sender ID to the joining node if this joins the group 887 exclusively with the role of monitor, according to what specified 888 in the Access Token (see Section 4.2). 890 o The Group Manager stores the association between i) the public key 891 of the joining node; and ii) the Group Identifier (Gid), i.e. the 892 OSCORE ID Context, associated to the OSCORE group together with 893 the OSCORE Sender ID assigned to the joining node in the group. 894 The Group Manager MUST keep this association updated over time. 896 Then, the Group Manager replies to the joining node, providing the 897 updated security parameters and keying meterial necessary to 898 participate in the group communication. This success Joining 899 Response is formatted as defined in Section 4.1.2.1 of 900 [I-D.ietf-ace-key-groupcomm], with the following additions: 902 o The 'gkty' parameter identifies a key of type 903 "Group_OSCORE_Input_Material object", defined in Section 21.2 of 904 this specification. 906 o The 'key' parameter includes what the joining node needs in order 907 to set up the Group OSCORE Security Context as per Section 2 of 908 [I-D.ietf-core-oscore-groupcomm]. 910 This parameter has as value a Group_OSCORE_Input_Material object, 911 which is defined in this specification and extends the 912 OSCORE_Input_Material object encoded in CBOR as defined in 913 Section 3.2.1 of [I-D.ietf-ace-oscore-profile]. In particular, it 914 contains the additional parameters 'group_senderId' 'cs_alg', 915 'cs_params', 'cs_key_params', 'cs_key_enc', 'ecdh_alg', 916 'ecdh_params' and 'ecdh_key_params' defined in Section 21.5 of 917 this specification. 919 More specifically, the 'key' parameter is composed as follows. 921 * The 'ms' parameter MUST be present and includes the OSCORE 922 Master Secret value used in the OSCORE group. 924 * The 'hkdf' parameter, if present, has as value the KDF 925 algorithm used in the OSCORE group. 927 * The 'alg' parameter, if present, has as value the AEAD 928 algorithm used in the OSCORE group. 930 * The 'salt' parameter, if present, has as value the OSCORE 931 Master Salt used in the OSCORE group. 933 * The 'contextId' parameter MUST be present and has as value the 934 Group Identifier (Gid), i.e. the OSCORE ID Context of the 935 OSCORE group. 937 * The 'group_senderId' parameter, if present, has as value the 938 OSCORE Sender ID assigned to the joining node by the Group 939 Manager, as described above. This parameter is not present if 940 the node joins the group exclusively with the role of monitor, 941 according to what specified in the Access Token (see 942 Section 4.2). In any other case, this parameter MUST be 943 present. 945 * The 'cs_alg' parameter MUST be present and specifies the 946 algorithm used to countersign messages in the OSCORE group. 947 This parameter takes values from the "Value" column of the 948 "COSE Algorithms" Registry [COSE.Algorithms]. 950 * The 'cs_params' parameter MAY be present and specifies the 951 parameters for the counter signature algorithm. This parameter 952 is a CBOR array, which includes the following two elements: 954 + 'sign_alg_capab', with the same encoding as defined in 955 Section 6.1. The value is the same as in the Token Post 956 response where the 'sign_parameters' value was non-null. 958 + 'sign_key_type_capab', with the same encoding as defined in 959 Section 6.1. The value is the same as in the Token Post 960 response where the 'sign_parameters' value was non-null. 962 * The 'cs_key_params' parameter MAY be present and specifies the 963 parameters for the key used with the counter signature 964 algorithm. This parameter is a CBOR array, with the same non- 965 null encoding and value as 'sign_key_parameters' of the 966 Section 6.1. 968 * The 'cs_key_enc' parameter MAY be present and specifies the 969 encoding of the public keys of the group members. This 970 parameter is a CBOR integer, whose value is 1 ("COSE_Key") 971 taken from the 'Confirmation Key' column of the "CWT 972 Confirmation Method" Registry [CWT.Confirmation.Methods], so 973 indicating that public keys in the OSCORE group are encoded as 974 COSE Keys [I-D.ietf-cose-rfc8152bis-struct]. Future 975 specifications may define additional values for this parameter. 976 If this parameter is not present, 1 ("COSE_Key") MUST be 977 assumed as default value. 979 * The 'ecdh_alg' parameter, if present, specifies the ECDH 980 algorithm used in the OSCORE group, if this supports the 981 pairwise mode of Group OSCORE. This parameter takes values 982 from the "Value" column of the "COSE Algorithms" Registry 983 [COSE.Algorithms]. This parameter MUST be present if the 984 OSCORE group supports the pairwise mode of Group OSCORE, and 985 MUST NOT be present otherwise. 987 * The 'ecdh_params' parameter, if present, specifies the 988 parameters for the ECDH algorithm. It MUST be present if the 989 'ecdh_alg' parameter is present, and MUST NOT be present 990 otherwise. This parameter is a CBOR array, which includes the 991 following two elements: 993 + 'ecdh_alg_capab', with the same encoding as defined in 994 Section 6.1.1. The value is the same as in the Token Post 995 response where the ecdh_parameters' value is non-null. 997 + 'ecdh_key_type_capab', with the same encoding as defined in 998 Section 6.1.1. The value is the same as in the Token Post 999 response where the 'ecdh_parameters' value is non-null. 1001 * The 'ecdh_key_params' parameter, if present, specifies the 1002 parameters for the key used with the ECDH algorithm. It MUST 1003 be present if the 'ecdh_alg' parameter is present, and MUST NOT 1004 be present otherwise. This parameter is a CBOR array, with the 1005 same non-null encoding and value of 'ecdh_key_parameters' 1006 defined in Section 6.1.1. 1008 o The 'exp' parameter MUST be present. 1010 o The 'ace-groupcomm-profile' parameter MUST be present and has 1011 value coap_group_oscore_app (TBD3), which is defined in 1012 Section 21.3 of this specification. 1014 o The 'pub_keys' parameter, if present, includes the public keys 1015 requested by the joining node by means of the 'get_pub_keys' 1016 parameter in the Joining Request. If public keys are encoded as 1017 COSE_Keys, each of them has as 'kid' the Sender ID that the 1018 corresponding owner has in the OSCORE group, thus used as group 1019 member identifier encoded as a CBOR byte string (REQ9). 1021 If the joining node has asked for the public keys of all the group 1022 members, i.e. 'get_pub_keys' had value Null in the Joining 1023 Request, then the Group Manager provides only the public keys of 1024 the group members that are relevant to the joining node. That is, 1025 in such a case, 'pub_keys' includes only: i) the public keys of 1026 the responders currently in the OSCORE group, in case the joining 1027 node is configured (also) as requester; and ii) the public keys of 1028 the requesters currently in the OSCORE group, in case the joining 1029 node is configured (also) as responder or monitor. 1031 o The 'group_policies' parameter SHOULD be present, and SHOULD 1032 include the following elements: 1034 * "Sequence Number Synchronization Method" defined in 1035 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm], with default 1036 value 1 ("Best effort"); 1038 * "Key Update Check Interval" defined in Section 4.1.2.1 of 1039 [I-D.ietf-ace-key-groupcomm], with default value 3600; 1041 * "Expiration Delta" defined in Section 4.1.2.1 of 1042 [I-D.ietf-ace-key-groupcomm], with default value 0. 1044 Finally, the joining node uses the information received in the 1045 Joining Response to set up the Group OSCORE Security Context, as 1046 described in Section 2 of [I-D.ietf-core-oscore-groupcomm]. In 1047 addition, the joining node maintains an association between each 1048 public key retrieved from the 'pub_keys' parameter and the role(s) 1049 that the corresponding group member has in the OSCORE group. 1051 From then on, the joining node can exchange group messages secured 1052 with Group OSCORE as described in [I-D.ietf-core-oscore-groupcomm]. 1053 When doing so: 1055 o The joining node MUST NOT process an incoming request message, if 1056 protected by a group member whose public key is not associated to 1057 the role "Requester". 1059 o The joining node MUST NOT process an incoming response message, if 1060 protected by a group member whose public key is not associated to 1061 the role "Responder". 1063 o The joining node MUST NOT use the pairwise mode of Group OSCORE to 1064 process messages in the group, if the Joining Response did not 1065 include the 'ecdh_alg' parameter. 1067 If the application requires backward security, the Group Manager MUST 1068 generate updated security parameters and group keying material, and 1069 provide it to the current group members upon the new node's joining 1070 (see Section 18). As a consequence, the joining node is not able to 1071 access secure communication in the OSCORE group occurred prior its 1072 joining. 1074 7. Public Keys of Joining Nodes 1076 Source authentication of a message sent within the group and 1077 protected with Group OSCORE is ensured by means of a digital counter 1078 signature embedded in the message (in group mode), or by integrity- 1079 protecting the message with pairwise keying material derived from the 1080 asymmetric keys of sender and recipient (in pairwise mode). 1082 Therefore, group members must be able to retrieve each other's public 1083 key from a trusted key repository, in order to verify source 1084 authenticity of incoming group messages. 1086 As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group 1087 Manager acts as trusted repository of the public keys of the group 1088 members, and provides those public keys to group members if requested 1089 to. Upon joining an OSCORE group, a joining node is thus expected to 1090 provide its own public key to the Group Manager. 1092 In particular, one of the following four cases can occur when a new 1093 node joins an OSCORE group. 1095 o The joining node is going to join the group exclusively as 1096 monitor. That is, it is not going to send messages to the group, 1097 and hence to produce signatures with its own private key. In this 1098 case, the joining node is not required to provide its own public 1099 key to the Group Manager, which thus does not have to perform any 1100 check related to the public key encoding, or to a countersignature 1101 algorithm and possible associated parameters for that joining 1102 node. In case that joining node still provides a public key in 1103 the 'client_cred' parameter of the Joining Request (see 1104 Section 6.2), the Group Manager silently ignores that parameter, 1105 as well as the related parameters 'cnonce' and 1106 'client_cred_verify'. 1108 o The Group Manager already acquired the public key of the joining 1109 node during a past joining process. In this case, the joining 1110 node MAY choose not to provide again its own public key to the 1111 Group Manager, in order to limit the size of the Joining Request. 1112 The joining node MUST provide its own public key again if it has 1113 provided the Group Manager with multiple public keys during past 1114 joining processes, intended for different OSCORE groups. If the 1115 joining node provides its own public key, the Group Manager 1116 performs consistency checks as per Section 6.3 and, in case of 1117 success, considers it as the public key associated to the joining 1118 node in the OSCORE group. 1120 o The joining node and the Group Manager use an asymmetric proof-of- 1121 possession key to establish a secure communication association. 1122 Then, two cases can occur. 1124 1. The proof-of-possession key is compatible with the encoding as 1125 well as with the counter signature algorithm and possible 1126 associated parameters used in the OSCORE group. Then, the 1127 Group Manager considers the proof-of-possession key as the 1128 public key associated to the joining node in the OSCORE group. 1129 If the joining node is aware that the proof-of-possession key 1130 is also valid for the OSCORE group, it MAY not provide it 1131 again as its own public key to the Group Manager. The joining 1132 node MUST provide its own public key again if it has provided 1133 the Group Manager with multiple public keys during past 1134 joining processes, intended for different OSCORE groups. If 1135 the joining node provides its own public key in the 1136 'client_cred' parameter of the Joining Request (see 1137 Section 6.2), the Group Manager performs consistency checks as 1138 per Section 6.3 and, in case of success, considers it as the 1139 public key associated to the joining node in the OSCORE group. 1141 2. The proof-of-possession key is not compatible with the 1142 encoding or with the counter signature algorithm and possible 1143 associated parameters used in the OSCORE group. In this case, 1144 the joining node MUST provide a different compatible public 1145 key to the Group Manager in the 'client_cred' parameter of the 1146 Joining Request (see Section 6.2). Then, the Group Manager 1147 performs consistency checks on this latest provided public key 1148 as per Section 6.3 and, in case of success, considers it as 1149 the public key associated to the joining node in the OSCORE 1150 group. 1152 o The joining node and the Group Manager use a symmetric proof-of- 1153 possession key to establish a secure communication association. 1154 In this case, upon performing a joining process with that Group 1155 Manager for the first time, the joining node specifies its own 1156 public key in the 'client_cred' parameter of the Joining Request 1157 targeting the group-membership endpoint (see Section 6.2). 1159 8. Retrieval of Updated Keying Material 1161 At some point, a group member considers the Group OSCORE Security 1162 Context invalid and to be renewed. This happens, for instance, after 1163 a number of unsuccessful security processing of incoming messages 1164 from other group members, or when the Security Context expires as 1165 specified by the 'exp' parameter of the Joining Response. 1167 When this happens, the group member retrieves updated security 1168 parameters and group keying material. This can occur in the two 1169 different ways described below. 1171 8.1. Retrieval of Group Keying Material 1173 If the group member wants to retrieve only the latest group keying 1174 material, it sends a Key Distribution Request to the Group Manager. 1176 In particular, it sends a CoAP GET request to the endpoint /ace- 1177 group/GROUPNAME at the Group Manager. 1179 The Group Manager processes the Key Distribution Request according to 1180 Section 4.1.2.2 of [I-D.ietf-ace-key-groupcomm]. The Key 1181 Distribution Response is formatted as defined in Section 4.1.2.2 of 1182 [I-D.ietf-ace-key-groupcomm]. In addition: 1184 o The 'key' parameter is formatted as defined in Section 6.4 of this 1185 specification, with the difference that it does not include the 1186 'group_SenderId' parameter. 1188 o The 'exp' parameter MUST be present. 1190 o The 'ace-groupcomm-profile' parameter MUST be present and has 1191 value coap_group_oscore_app. 1193 Upon receiving the Key Distribution Response, the group member 1194 retrieves the updated security parameters and group keying material, 1195 and, if they differ from the current ones, uses them to set up the 1196 new Group OSCORE Security Context as described in Section 2 of 1197 [I-D.ietf-core-oscore-groupcomm]. 1199 8.2. Retrieval of Group Keying Material and Sender ID 1201 If the group member wants to retrieve the latest group keying 1202 material as well as the Sender ID that it has in the OSCORE group, it 1203 sends a Key Distribution Request to the Group Manager. 1205 In particular, it sends a CoAP GET request to the endpoint /ace- 1206 group/GROUPNAME/nodes/NODENAME at the Group Manager. 1208 The Group Manager processes the Key Distribution Request according to 1209 Section 4.1.6.2 of [I-D.ietf-ace-key-groupcomm]. The Key 1210 Distribution Response is formatted as defined in Section 4.1.6.2 of 1211 [I-D.ietf-ace-key-groupcomm]. In addition: 1213 o The 'key' parameter is formatted as defined in Section 6.4 of this 1214 specification. In particular, if the requesting group member has 1215 exclusively the role of monitor, no 'group_SenderId' is specified 1216 within the 'key' parameter. 1218 Note that, in any other case, the current Sender ID of the group 1219 member is not specified as a separate parameter, but rather 1220 specified as 'group_SenderId' within the 'key' parameter. 1222 o The 'exp' parameter MUST be present. 1224 Upon receiving the Key Distribution Response, the group member 1225 retrieves the updated security parameters, group keying material and 1226 Sender ID, and, if they differ from the current ones, uses them to 1227 set up the new Group OSCORE Security Context as described in 1228 Section 2 of [I-D.ietf-core-oscore-groupcomm]. 1230 9. Requesting a Change of Keying Material 1232 As discussed in Section 2.4.2 of [I-D.ietf-core-oscore-groupcomm], a 1233 group member may at some point exhaust its Sender Sequence Numbers in 1234 the OSCORE group. 1236 When this happens, the group member MUST send a Key Renewal Request 1237 message to the Group Manager, as per Section 4.5 of 1239 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP PUT 1240 request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME at the 1241 Group Manager. 1243 Upon receiving the Key Renewal Request, the Group Manager processes 1244 it as defined in Section 4.1.6.1 of [I-D.ietf-ace-key-groupcomm], and 1245 performs one of the following actions. 1247 1. If the requesting group member has exclusively the role of 1248 monitor, the Group Manager replies with a 4.00 (Bad Request) 1249 error response. 1251 2. Otherwise, the Group Manager takes one of the following actions. 1253 a. The Group Manager rekeys the OSCORE group. That is, the 1254 Group Manager generates new group keying material for that group 1255 (see Section 18), and replies to the group member with a group 1256 rekeying message as defined in Section 18, providing the new 1257 group keying material. Then, the Group Manager rekeys the rest 1258 of the OSCORE group, as discussed in Section 18. 1260 The Group Manager SHOULD perform a group rekeying only if already 1261 scheduled to occur shortly, e.g. according to an application- 1262 dependent rekeying period, or as a reaction to a recent change in 1263 the group membership. In any other case, the Group Manager 1264 SHOULD NOT rekey the OSCORE group when receiving a Key Renewal 1265 Request (OPT8). 1267 b. The Group Manager generates a new Sender ID for that group 1268 member and replies with a Key Renewal Response, formatted as 1269 defined in Section 4.1.6.1 of [I-D.ietf-ace-key-groupcomm]. In 1270 particular, the CBOR Map in the response payload includes a 1271 single parameter 'group_SenderId' defined in Section 21.1 of this 1272 document, specifying the new Sender ID of the group member 1273 encoded as a CBOR byte string. 1275 Consistently with Section 2.4.3.1 of 1276 [I-D.ietf-core-oscore-groupcomm], the Group Manager MUST assign a 1277 new Sender ID that has never been assigned before in the OSCORE 1278 group. 1280 10. Retrieval of Public Keys and Roles for Group Members 1282 A group member or a signature verifier may need to retrieve the 1283 public keys of (other) group members. To this end, the group member 1284 or signature verifier sends a Public Key Request message to the Group 1285 Manager, as per Section 4.6 of [I-D.ietf-ace-key-groupcomm]. In 1286 particular, it sends the request to the endpoint /ace- 1287 group/GROUPNAME/pub-key at the Group Manager. 1289 If the Public Key Request uses the method FETCH, the Public Key 1290 Request is formatted as defined in Section 4.1.3.1 of 1291 [I-D.ietf-ace-key-groupcomm]. In particular: 1293 o Each element (if any) of the first inner CBOR array is formatted 1294 as in the first inner CBOR array of the 'get_pub_keys' parameter 1295 of the Joining Request when the parameter value is non-null (see 1296 Section 6.2). 1298 o Each element (if any) of the second inner CBOR array is a CBOR 1299 byte string (REQ9), which encodes the Sender ID of the group 1300 member for which the associated public key is requested. 1302 Upon receiving the Public Key Request, the Group Manager processes it 1303 as per Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm], 1304 depending on the request method being FETCH or GET, respectively. 1305 Additionally, if the Public Key Request uses the method FETCH, the 1306 Group Manager silently ignores node identifiers included in the 1307 'get_pub_keys' parameter of the request that are not associated to 1308 any current group member. 1310 The success Public Key Response is formatted as defined in 1311 Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm], depending 1312 on the request method being FETCH or GET, respectively. 1314 11. Update of Public Key 1316 A group member may need to provide the Group Manager with its new 1317 public key to use in the group from then on, hence replacing the 1318 current one. This can be the case, for instance, if the 1319 countersignature algorithm and possible associated parameters used in 1320 the OSCORE group have been changed, and the current public key is not 1321 compatible with them. 1323 To this end, the group member sends a Public Key Update Request 1324 message to the Group Manager, as per Section 4.7 of 1325 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP POST 1326 request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME/pub-key 1327 at the Group Manager. 1329 Upon receiving the Group Leaving Request, the Group Manager processes 1330 it as per Section 4.1.7.1 of [I-D.ietf-ace-key-groupcomm], with the 1331 following additions. 1333 o If the requesting group member has exclusively the role of 1334 monitor, the Group Manager replies with a 4.00 (Bad request) error 1335 response. 1337 o The N_S signature challenge is computed as per point (1) in 1338 Section 6.2.1 (REQ17). 1340 o If the request is successfully processed, the Group Manager stores 1341 the association between i) the new public key of the group member; 1342 and ii) the Group Identifier (Gid), i.e. the OSCORE ID Context, 1343 associated to the OSCORE group together with the OSCORE Sender ID 1344 assigned to the group member in the group. The Group Manager MUST 1345 keep this association updated over time. 1347 12. Retrieval of Group Policies 1349 A group member may request the current policies used in the OSCORE 1350 group. To this end, the group member sends a Policies Request, as 1351 per Section 4.8 of [I-D.ietf-ace-key-groupcomm]. In particular, it 1352 sends a CoAP GET request to the endpoint /ace-group/GROUPNAME/ 1353 policies at the Group Manager, where GROUPNAME is the name of the 1354 OSCORE group. 1356 Upon receiving the Policies Request, the Group Manager processes it 1357 as per Section 4.1.4.1 of [I-D.ietf-ace-key-groupcomm]. The success 1358 Policies Response is formatted as defined in Section 4.1.4.1 of 1359 [I-D.ietf-ace-key-groupcomm]. 1361 13. Retrieval of Keying Material Version 1363 A group member may request the current version of the keying material 1364 used in the OSCORE group. To this end, the group member sends a 1365 Version Request, as per Section 4.9 of [I-D.ietf-ace-key-groupcomm]. 1366 In particular, it sends a CoAP GET request to the endpoint /ace- 1367 group/GROUPNAME/num at the Group Manager, where GROUPNAME is the name 1368 of the OSCORE group. 1370 Upon receiving the Version Request, the Group Manager processes it as 1371 per Section 4.1.5.1 of [I-D.ietf-ace-key-groupcomm]. The success 1372 Version Response is formatted as defined in Section 4.1.5.1 of 1373 [I-D.ietf-ace-key-groupcomm]. 1375 14. Retrieval of Group Status 1377 A group member may request the current status of the the OSCORE 1378 group, i.e. active or inactive. To this end, the group member sends 1379 a Group Status Request to the Group Manager. 1381 In particular, the group member sends a CoAP GET request to the 1382 endpoint /ace-group/GROUPNAME/active at the Group Manager defined in 1383 Section 5.1 of this specification, where GROUPNAME is the name of the 1384 OSCORE group. The success Group Version Response is formatted as 1385 defined in Section 5.1 of this specification. 1387 Upon learning from a 2.05 (Content) response that the group is 1388 currently inactive, the group member SHOULD stop taking part in 1389 communications within the group, until it becomes active again. 1391 Upon learning from a 2.05 (Content) response that the group has 1392 become active again, the group member can resume taking part in 1393 communications within the group. 1395 Figure 3 gives an overview of the exchange described above. 1397 Group Group 1398 Member Manager 1399 | | 1400 |--- Group Status Request: GET ace-group/GROUPNAME/active --->| 1401 | | 1402 |<---------- Group Status Response: 2.05 (Content) -----------| 1403 | | 1405 Figure 3: Message Flow of Group Status Request-Response 1407 15. Retrieval of Group Names and URIs 1409 A node may want to retrieve from the Group Manager the group name and 1410 the URI of the group-membership resource of a group. This is 1411 relevant in the following cases. 1413 o Before joining a group, a joining node may know only the current 1414 Group Identifier (Gid) of that group, but not the group name and 1415 the URI to the group-membership resource. 1417 o As current group member in several groups, the node has missed a 1418 previous group rekeying in one of them (see Section 18). Hence, 1419 it retains stale keying material and fails to decrypt received 1420 messages exchanged in that group. 1422 Such messages do not provide a direct hint to the correct group 1423 name, that the node would need in order to retrieve the latest 1424 keying material and public keys from the Group Manager (see 1425 Section 8.1, Section 8.2 and Section 10). However, such messages 1426 may specify the current Gid of the group, as value of the 1427 'kid_context' field of the OSCORE CoAP option (see Section 6.1 of 1428 [RFC8613] and Section 4.2 of [I-D.ietf-core-oscore-groupcomm]). 1430 o As signature verifier, the node also refers to a group name for 1431 retrieving the required public keys from the Group Manager (see 1432 Section 10). As discussed above, intercepted messages do not 1433 provide a direct hint to the correct group name, while they may 1434 specify the current Gid of the group, as value of the 1435 'kid_context' field of the OSCORE CoAP option. In such a case, 1436 upon intercepting a message in the group, the node requires to 1437 correctly map the Gid currently used in the group with the 1438 invariant group name. 1440 Furthermore, since it is not a group member, the node does not 1441 take part to a possible group rekeying. Thus, following a group 1442 rekeying and the consequent change of Gid in a group, the node 1443 would retain the old Gid value and cannot correctly associate 1444 intercepted messages to the right group, especially if acting as 1445 signature verifier in several groups. This in turn prevents the 1446 efficient verification of counter signatures, and especially the 1447 retrieval of required, new public keys from the Group Manager. 1449 In either case, the node only knows the current Gid of the group, as 1450 learnt from received or intercepted messages exchanged in the group. 1451 As detailed below, the node can contact the Group Manager, and 1452 request the group name and URI to the group-membership resource 1453 corresponding to that Gid. Then, it can use that information to 1454 either join the group as a candidate group member, get the latest 1455 keying material as a current group member, or retrieve public keys 1456 used in the group as a signature verifier. To this end, the node 1457 sends a Group Name and URI Retrieval Request, as per Section 4.2 of 1458 [I-D.ietf-ace-key-groupcomm]. 1460 In particular, the node sends a CoAP FETCH request to the endpoint 1461 /ace-group at the Group Manager formatted as defined in 1462 Section 4.1.1.1 of [I-D.ietf-ace-key-groupcomm]. Each element of the 1463 CBOR array 'gid' is a CBOR byte string (REQ7b), which encodes the Gid 1464 of the group for which the group name and the URI to the group- 1465 membership resource are requested. 1467 Upon receiving the Group Name and URI Retrieval Request, the Group 1468 Manager processes it as per Section 4.1.1.1 of 1469 [I-D.ietf-ace-key-groupcomm]. The success Group Name and URI 1470 Retrieval Response is formatted as defined in Section 4.1.1.1 of 1471 [I-D.ietf-ace-key-groupcomm]. In particular, each element of the 1472 CBOR array 'gid' is a CBOR byte string (REQ7b), which encodes the Gid 1473 of the group for which the group name and the URI to the group- 1474 membership resource are provided. 1476 For each of its groups, the Group Manager maintains an association 1477 between the group name and the URI to the group-membership resource 1478 on one hand, and only the current Gid for that group on the other 1479 hand. That is, the Group Manager MUST NOT maintain an association 1480 between the former pair and any other Gid for that group than the 1481 current, most recent one. 1483 Figure 4 gives an overview of the exchanges described above. 1485 Group 1486 Node Manager 1487 | | 1488 |---- Group Name and URI Retrieval Request: FETCH ace-group/ --->| 1489 | | 1490 |<--- Group Name and URI Retrieval Response: 2.05 (Content) -----| 1491 | | 1493 Figure 4: Message Flow of Group Name and URI Retrieval Request- 1494 Response 1496 16. Request to Leave the Group 1498 A group member may request to leave the OSCORE group. To this end, 1499 the group member sends a Group Leaving Request, as per Section 4.10 1500 of [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP 1501 DELETE request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME at 1502 the Group Manager. 1504 Upon receiving the Group Leaving Request, the Group Manager processes 1505 it as per Section 4.1.6.3 of [I-D.ietf-ace-key-groupcomm]. 1507 17. Removal of a Group Member 1509 Other than after a spontaneous request to the Group Manager as 1510 described in Section 16, a node may be forcibly removed from the 1511 OSCORE group, e.g. due to expired or revoked authorization. 1513 If, upon joining the group (see Section 6.2), the leaving node 1514 specified a URI in the 'control_path' parameter defined in 1515 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm], the Group Manager 1516 MUST inform the leaving node of its eviction, by sending a DELETE 1517 request targeting the URI specified in the 'control_path' parameter 1518 (OPT9). 1520 If the leaving node has not exclusively the role of monitor, the 1521 Group Manager performs the following actions. 1523 o The Group Manager frees the OSCORE Sender ID value of the leaving 1524 node. However, this value MUST NOT become available for possible 1525 upcoming joining nodes in the same group. 1527 o The Group Manager cancels the association between, on one hand, 1528 the public key of the leaving node and, on the other hand, the 1529 Group Identifier (Gid) associated to the OSCORE group together 1530 with the freed OSCORE Sender ID value. The Group Manager deletes 1531 the public key of the leaving node, if that public key has no 1532 remaining association with any pair (Gid, Sender ID). 1534 If the application requires forward security, the Group Manager MUST 1535 generate updated security parameters and group keying material, and 1536 provide it to the remaining group members (see Section 18). As a 1537 consequence, the leaving node is not able to acquire the new security 1538 parameters and group keying material distributed after its leaving. 1540 Same considerations in Section 5 of [I-D.ietf-ace-key-groupcomm] 1541 apply here as well, considering the Group Manager acting as KDC. 1543 18. Group Rekeying Process 1545 In order to rekey the OSCORE group, the Group Manager distributes a 1546 new Group Identifier (Gid), i.e. a new OSCORE ID Context; a new 1547 OSCORE Master Secret; and, optionally, a new OSCORE Master Salt for 1548 that group. When doing so, the Group Manager MUST increment the 1549 version number of the group keying material, before starting its 1550 distribution. 1552 Consistently with Section 2.3 of [I-D.ietf-core-oscore-groupcomm], 1553 the Group Manager MUST assign a Gid that has never been assigned 1554 before to the OSCORE group. 1556 Furthermore, the Group Manager MUST preserve the same unchanged 1557 Sender IDs for all group members. This avoids affecting the 1558 retrieval of public keys from the Group Manager as well as the 1559 verification of group messages. 1561 The Group Manager MUST support at least the following group rekeying 1562 scheme. Future application profiles may define alternative message 1563 formats and distribution schemes. 1565 As group rekeying message, the Group Manager uses the same format of 1566 the Joining Response message in Section 6.4. In particular: 1568 o Only the parameters 'gkty', 'key', 'num', 'ace-groupcomm-profile' 1569 and 'exp' are present. 1571 o The 'ms' parameter of the 'key' parameter specifies the new OSCORE 1572 Master Secret value. 1574 o The 'contextId' parameter of the 'key' parameter specifies the new 1575 Group ID used as OSCORE ID Context value. 1577 The Group Manager separately sends a group rekeying message to each 1578 group member to be rekeyed. 1580 Each rekeying message MUST be secured with the pairwise secure 1581 communication channel between the Group Manager and the group member 1582 used during the joining process. In particular, each rekeying 1583 message can target the 'control_path' URI path defined in 1584 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm] (OPT9), if provided 1585 by the intended recipient upon joining the group (see Section 6.2). 1587 It is RECOMMENDED that the Group Manager gets confirmation of 1588 successful distribution from the group members, and admits a maximum 1589 number of individual retransmissions to non-confirming group members. 1591 This approach requires group members to act (also) as servers, in 1592 order to correctly handle unsolicited group rekeying messages from 1593 the Group Manager. In particular, if a group member and the Group 1594 Manager use OSCORE [RFC8613] to secure their pairwise communications, 1595 the group member MUST create a Replay Window in its own Recipient 1596 Context upon establishing the OSCORE Security Context with the Group 1597 Manager, e.g. by means of the OSCORE profile of ACE 1598 [I-D.ietf-ace-oscore-profile]. 1600 Group members and the Group Manager SHOULD additionally support 1601 alternative rekeying approaches that do not require group members to 1602 act (also) as servers. A number of such approaches are defined in 1603 Section 4.4 of [I-D.ietf-ace-key-groupcomm]. In particular, a group 1604 member may subscribe for updates to the group-membership resource of 1605 the group, at the endpoint /ace-group/GROUPNAME/ of the Group 1606 Manager. This can rely on CoAP Observe [RFC7641] or on a full- 1607 fledged Pub-Sub model [I-D.ietf-core-coap-pubsub] with the Group 1608 Manager acting as Broker. 1610 In case the rekeying terminates and some group members have not 1611 received the new keying material, they will not be able to correctly 1612 process following secured messages exchanged in the group. These 1613 group members will eventually contact the Group Manager, in order to 1614 retrieve the current keying material and its version. 1616 Some of these group members may be in multiple groups, each 1617 associated to a different Group Manager. When failing to correctly 1618 process messages secured with the new keying material, these group 1619 members may not have sufficient information to determine which exact 1620 Group Manager they should contact, in order to retrieve the current 1621 keying material they are missing. 1623 If the Gid is formatted as described in Appendix C of 1624 [I-D.ietf-core-oscore-groupcomm], the Group Prefix can be used as a 1625 hint to determine the right Group Manager, as long as no collisions 1626 among Group Prefixes are experienced. Otherwise, a group member 1627 needs to contact the Group Manager of each group, e.g. by first 1628 requesting only the version of the current group keying material (see 1629 Section 13) and then possibly requesting the current keying material 1630 (see Section 8.1). 1632 Furthermore, some of these group members can be in multiple groups, 1633 all of which associated to the same Group Manager. In this case, 1634 these group members may also not have sufficient information to 1635 determine which exact group they should refer to, when contacting the 1636 right Group Manager. Hence, they need to contact a Group Manager 1637 multiple times, i.e. separately for each group they belong to and 1638 associated to that Group Manager. 1640 19. Default Values for Group Configuration Parameters 1642 This section defines the default values that the Group Manager 1643 assumes for the configuration parameters of an OSCORE group, unless 1644 differently specified when creating and configuring the group. This 1645 can be achieved as specified in [I-D.ietf-ace-oscore-gm-admin]. 1647 The Group Manager SHOULD use the same default values defined in 1648 Section 3.2 of [RFC8613] for both the HKDF algorithm and the AEAD 1649 algorithm used in the group. 1651 The Group Manager SHOULD use the following default values for the 1652 algorithm, algorithm parameters and key parameters used to 1653 countersign messages in the group, consistently with the "COSE 1654 Algorithms" Registry [COSE.Algorithms], the "COSE Key Types" Registry 1655 [COSE.Key.Types] and the "COSE Elliptic Curves" Registry 1656 [COSE.Elliptic.Curves]. 1658 o For the algorithm 'cs_alg' used to countersign messages in the 1659 group, the signature algorithm EdDSA [RFC8032]. 1661 o For the parameters 'cs_params' of the counter signature algorithm: 1663 * The array [[OKP], [OKP, Ed25519]], indicating the elliptic 1664 curve Ed25519 [RFC8032], in case EdDSA is assumed or specified 1665 for 'cs_alg'. 1667 * The array [[EC2], [EC2, P-256]], indicating the elliptic curve 1668 P-256, in case ES256 [RFC6979] is specified for 'cs_alg'. 1670 * The array [[EC2], [EC2, P-384]], indicating the elliptic curve 1671 P-384, in case ES384 [RFC6979] is specified for 'cs_alg'. 1673 * The array [[EC2], [EC2, P-521]], indicating the elliptic curve 1674 P-521, in case ES512 [RFC6979] is specified for 'cs_alg'. 1676 * The array [[], [RSA]], in case PS256, PS384 or PS512 [RFC8017] 1677 is specified for 'cs_alg'. 1679 o For the parameters 'cs_key_params' of the key used with the 1680 counter signature algorithm: 1682 * The array [OKP, Ed25519] as pair (key type, elliptic curve), in 1683 case EdDSA is assumed or specified for 'cs_alg' and Ed25519 is 1684 assumed or specified within the second array of 'cs_params'. 1686 * The array [OKP, Ed448] as pair (key type, elliptic curve), in 1687 case EdDSA is assumed or specified for 'cs_alg' and the 1688 elliptic curve Ed448 [RFC8032] is specified within the second 1689 array of 'cs_params'. 1691 * The array [EC2, P-256] as pair (key type, elliptic curve), in 1692 case ES256 [RFC6979] is specified for 'cs_alg' and the elliptic 1693 curve P-256 is assumed or specified within the second array of 1694 'cs_params'. 1696 * The array [EC2, P-384] as pair (key type, elliptic curve), in 1697 case ES384 [RFC6979] is specified for 'cs_alg' and the elliptic 1698 curve P-384 is specified within the second array of 1699 'cs_params'. 1701 * The array [EC2, P-521] as pair (key type, elliptic curve), in 1702 case ES512 [RFC6979] is specified for 'cs_alg' and the elliptic 1703 curve P-521 is specified within the second array of 1704 'cs_params'. 1706 * The array [RSA] indicating RSA as key type, in case PS256, 1707 PS384 or PS512 [RFC8017] is specified for 'cs_alg'. 1709 o For the 'cs_key_enc' encoding of the public keys of the group 1710 members, COSE_Key from the "CWT Confirmation Methods" Registry 1711 [CWT.Confirmation.Methods]. 1713 If the group supports the pairwise mode of Group OSCORE, the Group 1714 Manager SHOULD use the following default values for the algorithm, 1715 algorithm parameters and key parameters used to compute static-static 1716 Diffie-Hellman shared secrets, consistently with the "COSE 1717 Algorithms" Registry [COSE.Algorithms], the "COSE Key Types" Registry 1719 [COSE.Key.Types] and the "COSE Elliptic Curves" Registry 1720 [COSE.Elliptic.Curves]. 1722 o For the algorithm 'ecdh_alg' used to compute static-static Diffie- 1723 Hellman shared secrets, the ECDH algorithm ECDH-SS + HKDF-256 1724 specified in Section 6.3.1 of [I-D.ietf-cose-rfc8152bis-algs]. 1726 o For the parameters 'ecdh_params' of the ECDH algorithm: 1728 * The array [[OKP], [OKP, X25519]], indicating the elliptic curve 1729 X25519 [RFC8032], in case EdDSA is assumed or specified for 1730 'cs_alg'. 1732 * The array [[EC2], [EC2, P-256]], indicating the elliptic curve 1733 P-256, in case ES256 [RFC6979] is specified for 'cs_alg'. 1735 * The array [[EC2], [EC2, P-384]], indicating the elliptic curve 1736 P-384, in case ES384 [RFC6979] is specified for 'cs_alg'. 1738 * The array [[EC2], [EC2, P-521]], indicating the elliptic curve 1739 P-521, in case ES512 [RFC6979] is specified for 'cs_alg'. 1741 o For the parameters 'ecdh_key_params' of the key used with the ECDH 1742 algorithm: 1744 * The array [OKP, X25519] as pair (key type, elliptic curve), in 1745 case EdDSA is assumed or specified for 'cs_alg' and X25519 is 1746 assumed or specified within the second array of 'ecdh_params'. 1748 * The array [OKP, X448] as pair (key type, elliptic curve), in 1749 case EdDSA is assumed or specified for 'cs_alg' and the 1750 elliptic curve X448 [RFC8032] is specified within the second 1751 array of 'ecdh_params'. 1753 * The array [EC2, P-256] as pair (key type, elliptic curve), in 1754 case ES256 [RFC6979] is specified for 'cs_alg' and the elliptic 1755 curve P-256 is assumed or specified within the second array of 1756 'ecdh_params'. 1758 * The array [EC2, P-384] as pair (key type, elliptic curve), in 1759 case ES384 [RFC6979] is specified for 'cs_alg' and the elliptic 1760 curve P-384 is specified within the second array of 1761 'ecdh_params'. 1763 * The array [EC2, P-521] as pair (key type, elliptic curve), in 1764 case ES512 [RFC6979] is specified for 'cs_alg' and the elliptic 1765 curve P-521 is specified within the second array of 1766 'ecdh_params'. 1768 20. Security Considerations 1770 Security considerations for this profile are inherited from 1771 [I-D.ietf-ace-key-groupcomm], the ACE framework for Authentication 1772 and Authorization [I-D.ietf-ace-oauth-authz], and the specific 1773 transport profile of ACE signalled by the AS, such as 1774 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile]. 1776 The following security considerations also apply for this profile. 1778 20.1. Management of OSCORE Groups 1780 This profile leverages the following management aspects related to 1781 OSCORE groups and discussed in the sections of 1782 [I-D.ietf-core-oscore-groupcomm] referred below. 1784 o Management of group keying material (see Section 3.1 of 1785 [I-D.ietf-core-oscore-groupcomm]). The Group Manager is 1786 responsible for the renewal and re-distribution of the keying 1787 material in the groups of its competence (rekeying). According to 1788 the specific application requirements, this can include rekeying 1789 the group upon changes in its membership. In particular, renewing 1790 the group keying material is required upon a new node's joining or 1791 a current node's leaving, in case backward security and forward 1792 security have to be preserved, respectively. 1794 o Provisioning and retrieval of public keys (see Section 2 of 1795 [I-D.ietf-core-oscore-groupcomm]). The Group Manager acts as key 1796 repository of public keys of group members, and provides them upon 1797 request. 1799 o Synchronization of sequence numbers (see Section 6.1 of 1800 [I-D.ietf-core-oscore-groupcomm]). This concerns how a responder 1801 node that has just joined an OSCORE group can synchronize with the 1802 sequence number of requesters in the same group. 1804 Before sending the Joining Response, the Group Manager MUST verify 1805 that the joining node actually owns the associated private key. To 1806 this end, the Group Manager can rely on the proof-of-possession 1807 challenge-response defined in Section 6. Alternatively, the joining 1808 node can use its own public key as asymmetric proof-of-possession key 1809 to establish a secure channel with the Group Manager, e.g. as in 1810 Section 3.2 of [I-D.ietf-ace-dtls-authorize]. However, this requires 1811 such proof-of-possession key to be compatible with the encoding as 1812 well as with the countersignature algorithm and possible associated 1813 parameters used in the OSCORE group. 1815 A node may have joined multiple OSCORE groups under different non- 1816 synchronized Group Managers. Therefore, it can happen that those 1817 OSCORE groups have the same Group Identifier (Gid). It follows that, 1818 upon receiving a Group OSCORE message addressed to one of those 1819 groups, the node would have multiple Security Contexts matching with 1820 the Gid in the incoming message. It is up to the application to 1821 decide how to handle such collisions of Group Identifiers, e.g. by 1822 trying to process the incoming message using one Security Context at 1823 the time until the right one is found. 1825 20.2. Size of Nonces for Signature Challenge 1827 With reference to the Joining Request message in Section 6.2, the 1828 proof-of-possession signature included in 'client_cred_verify' is 1829 computed over the challenge N_C | N_S, where | denotes concatenation. 1831 For the N_C challenge share, it is RECOMMENDED to use a 8-byte long 1832 random nonce. Furthermore, N_C is always conveyed in the 'cnonce' 1833 parameter of the Joining Request, which is always sent over the 1834 secure communication channel between the joining node and the Group 1835 Manager. 1837 As defined in Section 6.2.1, the way the N_S value is computed 1838 depends on the particular way the joining node provides the Group 1839 Manager with the Access Token, as well as on following interactions 1840 between the two. 1842 o If the Access Token is not explicitly posted to the /authz-info 1843 endpoint of the Group Manager, then N_S is computed as a 32-byte 1844 long challenge share. For an example, see point (2) of 1845 Section 6.2.1. 1847 o If the Access Token has been explicitly posted to the /authz-info 1848 endpoint of the Group Manager, N_S takes the most recent value 1849 provided to the client by the Group Manager in the 'kdcchallenge' 1850 parameter, as specified in point (1) of Section 6.2.1. This is 1851 provided either in the 2.01 response to the Token Post (see 1852 Section 6.1), or in a 4.00 response to a following Joining Request 1853 (see Section 6.3). In either case, it is RECOMMENDED to use a 1854 8-byte long random challenge as value for N_S. 1856 If we consider both N_C and N_S to take 8-byte long values, the 1857 following considerations hold. 1859 o Let us consider both N_C and N_S as taking random values, and the 1860 Group Manager to never change the value of the N_S provided to a 1861 Client during the lifetime of an Access Token. Then, as per the 1862 birthday paradox, the average collision for N_S will happen after 1863 2^32 new posted Access Tokens, while the average collision for N_C 1864 will happen after 2^32 new Joining Requests. This amounts to 1865 considerably more token provisionings than the expected new 1866 joinings of OSCORE groups under a same Group Manager, as well as 1867 to considerably more requests to join OSCORE groups from a same 1868 Client using a same Access Token under a same Group Manager. 1870 o Section 7 of [I-D.ietf-ace-oscore-profile] as well Appendix B.2 of 1871 [RFC8613] recommend the use of 8-byte random values as well. 1872 Unlike in those cases, the values of N_C and N_S considered in 1873 this specification are not used for as sensitive operations as the 1874 derivation of a Security Context, and thus do not have possible 1875 implications in the security of AEAD ciphers. 1877 20.3. Reusage of Nonces for Signature Challenge 1879 As long as the Group Manager preserves the same N_S value currently 1880 associated to an Access Token, i.e. the latest value provided to a 1881 Client in a 'kdcchallenge' parameter, the Client is able to 1882 successfully reuse the same signature challenge for multiple Joining 1883 Requests to that Group Manager. 1885 In particular, the Client can reuse the same N_C value for every 1886 Joining Request to the Group Manager, and combine it with the same 1887 unchanged N_S value. This results in reusing the same signature 1888 challenge for producing the signature to include in the 1889 'client_cred_verify' parameter of the Joining Requests. 1891 Unless the Group Manager maintains a list of N_C values already used 1892 by that Client since the latest update to the N_S value associated to 1893 the Access Token, the Group Manager can be forced to falsely believe 1894 that the Client possesses its own private key at that point in time, 1895 upon verifying the signature in the 'client_cred_verify' parameter. 1897 21. IANA Considerations 1899 Note to RFC Editor: Please replace all occurrences of "[[This 1900 specification]]" with the RFC number of this specification and delete 1901 this paragraph. 1903 This document has the following actions for IANA. 1905 21.1. ACE Groupcomm Parameters Registry 1907 IANA is asked to register the following entry to the "ACE Groupcomm 1908 Parameters" Registry defined in Section 8.5 of 1909 [I-D.ietf-ace-key-groupcomm]. 1911 o Name: group_senderId 1913 o CBOR Key: TBD1 1915 o CBOR Type: Byte string 1917 o Reference: [[This specification]] (Section 9) 1919 21.2. ACE Groupcomm Key Registry 1921 IANA is asked to register the following entry to the "ACE Groupcomm 1922 Key" Registry defined in Section 8.6 of [I-D.ietf-ace-key-groupcomm]. 1924 o Name: Group_OSCORE_Input_Material object 1926 o Key Type Value: TBD2 1928 o Profile: "coap_group_oscore_app", defined in Section 21.3 of this 1929 specification. 1931 o Description: A Group_OSCORE_Input_Material object encoded as 1932 described in Section 6.4 of this specification. 1934 o Reference: [[This specification]] (Section 6.4) 1936 21.3. ACE Groupcomm Profile Registry 1938 IANA is asked to register the following entry to the "ACE Groupcomm 1939 Profile" Registry defined in Section 8.7 of 1940 [I-D.ietf-ace-key-groupcomm]. 1942 o Name: coap_group_oscore_app 1944 o Description: Application profile to provision keying material for 1945 participating in group communication protected with Group OSCORE 1946 as per [I-D.ietf-core-oscore-groupcomm]. 1948 o CBOR Value: TBD3 1950 o Reference: [[This specification]] (Section 6.4) 1952 21.4. Sequence Number Synchronization Method Registry 1954 IANA is asked to register the following entries in the "Sequence 1955 Number Synchronization Method" Registry defined in Section 8.9 of 1956 [I-D.ietf-ace-key-groupcomm]. 1958 o Name: Best effort 1959 o Value: 1 1961 o Description: No action is taken. 1963 o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.1) 1965 o Name: Baseline 1967 o Value: 2 1969 o Description: The first received request sets the baseline 1970 reference point, and is discarded with no delivery to the 1971 application. 1973 o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.2) 1975 o Name: Echo challenge-response 1977 o Value: 3 1979 o Description: Challenge response using the Echo Option for CoAP 1980 from [I-D.ietf-core-echo-request-tag]. 1982 o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.3) 1984 21.5. OSCORE Security Context Parameters Registry 1986 IANA is asked to register the following entries in the "OSCORE 1987 Security Context Parameters" Registry defined in Section 9.4 of 1988 [I-D.ietf-ace-oscore-profile]. 1990 o Name: group_SenderId 1992 o CBOR Label: TBD4 1994 o CBOR Type: bstr 1996 o Registry: - 1998 o Description: OSCORE Sender ID assigned to a member of an OSCORE 1999 group 2001 o Reference: [[This specification]] (Section 6.4) 2003 o Name: cs_alg 2004 o CBOR Label: TBD5 2006 o CBOR Type: tstr / int 2008 o Registry: COSE Algorithms 2010 o Description: OSCORE Counter Signature Algorithm Value 2012 o Reference: [[This specification]] (Section 6.4) 2014 o Name: cs_params 2016 o CBOR Label: TBD6 2018 o CBOR Type: array 2020 o Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves 2022 o Description: OSCORE Counter Signature Algorithm Additional 2023 Parameters 2025 o Reference: [[This specification]] (Section 6.4) 2027 o Name: cs_key_params 2029 o CBOR Label: TBD7 2031 o CBOR Type: array 2033 o Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves 2035 o Description: OSCORE Counter Signature Key Additional Parameters 2037 o Reference: [[This specification]] (Section 6.4) 2039 o Name: cs_key_enc 2041 o CBOR Label: TBD8 2043 o CBOR Type: integer 2045 o Registry: CWT Confirmation Methods 2047 o Description: Encoding of Public Keys to be used with the OSCORE 2048 Counter Signature Algorithm 2050 o Reference: [[This specification]] (Section 6.4) 2052 o Name: ecdh_alg 2054 o CBOR Label: TBD9 2056 o CBOR Type: tstr / int 2058 o Registry: COSE Algorithms 2060 o Description: OSCORE ECDH Algorithm Value 2062 o Reference: [[This specification]] (Section 6.4) 2064 o Name: ecdh_params 2066 o CBOR Label: TBD10 2068 o CBOR Type: array 2070 o Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves 2072 o Description: OSCORE ECDH Algorithm Additional Parameters 2074 o Reference: [[This specification]] (Section 6.4) 2076 o Name: ecdh_key_params 2078 o CBOR Label: TBD11 2080 o CBOR Type: array 2082 o Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves 2084 o Description: OSCORE ECDH Key Additional Parameters 2086 o Reference: [[This specification]] (Section 6.4) 2088 21.6. TLS Exporter Label Registry 2090 IANA is asked to register the following entry to the "TLS Exporter 2091 Label" Registry defined in Section 6 of [RFC5705] and updated in 2092 Section 12 of [RFC8447]. 2094 o Value: EXPORTER-ACE-Sign-Challenge-coap-group-oscore-app 2095 o DTLS-OK: Y 2097 o Recommended: N 2099 o Reference: [[This specification]] (Section 6.2.1) 2101 21.7. AIF Registry 2103 IANA is asked to register the following entry to the "Toid" sub- 2104 registry of the "AIF" Registry defined in Section 5.2 of 2105 [I-D.ietf-ace-aif]. 2107 o Name: oscore-group-name 2109 o Description/Specification: group name of the OSCORE group, as 2110 specified in [[This specification]]. 2112 IANA is asked to register the following entry to the "Tperm" sub- 2113 Registry of the "AIF" Registry defined in Section 5.2 of 2114 [I-D.ietf-ace-aif]. 2116 o Name: oscore-group-roles 2118 o Description/Specification: role(s) of the member of the OSCORE 2119 group, as specified in [[This specification]]. 2121 21.8. Media Type Registrations 2123 This specification registers the 'application/aif-groupcomm- 2124 oscore+cbor' media type for the AIF specific data model AIF-OSCORE- 2125 GROUPCOMM defined in Section 3 of [[This specification]]. This 2126 registration follows the procedures specified in [RFC6838]. 2128 These media type has parameters for specifying the object identifier 2129 ("Toid") and set of permissions ("Tperm") defined for the AIF-generic 2130 model in [I-D.ietf-ace-aif]; default values are the values "oscore- 2131 group-name" for "Toid" and "oscore-group-roles" for "Tperm". 2133 Type name: application 2135 Subtype name: aif-groupcomm-oscore+cbor 2137 Required parameters: "Toid", "Tperm" 2139 Optional parameters: none 2140 Encoding considerations: Must be encoded as a CBOR array, each 2141 element of which is an array [Toid, Tperm] as defined in Section 3 of 2142 [[This specification]]. 2144 Security considerations: See Section 20 of [[This specification]]. 2146 Interoperability considerations: n/a 2148 Published specification: [[This specification]] 2150 Applications that use this media type: The type is used by 2151 applications that want to express authorization information about 2152 joining OSCORE groups, as specified in [[This specification]]. 2154 Additional information: n/a 2156 Person & email address to contact for further information: 2157 iesg@ietf.org [1] 2159 Intended usage: COMMON 2161 Restrictions on usage: None 2163 Author: Marco Tiloca marco.tiloca@ri.se [2] 2165 Change controller: IESG 2167 21.9. CoAP Content-Format Registry 2169 IANA is asked to register the following entry to the "CoAP Content- 2170 Formats" registry, within the "CoRE Parameters" registry: 2172 Media Type: application/aif-groupcomm-oscore+cbor;Toid="oscore-group- 2173 name",Tperm"oscore-group-roles" 2175 Encoding: - 2177 ID: TBD12 2179 Reference: [[This specification]] 2181 21.10. Group OSCORE Roles Registry 2183 This specification establishes the IANA "Group OSCORE Roles" 2184 Registry. The Registry has been created to use the "Expert Review 2185 Required" registration procedure [RFC8126]. Expert review guidelines 2186 are provided in Section 21.12. 2188 This registry includes the possible roles that nodes can take in an 2189 OSCORE group, each in combination with a numeric identifier. These 2190 numeric identifiers are used to express authorization information 2191 about joining OSCORE groups, as specified in Section 3 of [[This 2192 specification]]. 2194 The columns of this registry are: 2196 o Name: A value that can be used in documents for easier 2197 comprehension, to identify a possible role that nodes can take in 2198 an OSCORE group. 2200 o Value: The numeric identifier for this role. Integer values 2201 greater than 65535 are marked as "Private Use", all other values 2202 use the registration policy "Expert Review" [RFC8126]. 2204 o Description: This field contains a brief description of the role. 2206 o Reference: This contains a pointer to the public specification for 2207 the role. 2209 This registry will be initially populated by the values in Figure 1. 2211 The Reference column for all of these entries will be [[This 2212 specification]]. 2214 21.11. CoRE Resource Type Registry 2216 IANA is asked to register a new Resource Type (rt=) Link Target 2217 Attribute in the "Resource Type (rt=) Link Target Attribute Values" 2218 subregistry under the "Constrained Restful Environments (CoRE) 2219 Parameters" [CORE.Parameters] registry. 2221 o Value: "core.osc.gm" 2223 o Description: Group-membership resource of an OSCORE Group Manager. 2225 o Reference: [[This specification]] 2227 21.12. Expert Review Instructions 2229 The IANA Registry established in this document is defined as "Expert 2230 Review". This section gives some general guidelines for what the 2231 experts should be looking for, but they are being designated as 2232 experts for a reason so they should be given substantial latitude. 2234 Expert reviewers should take into consideration the following points: 2236 o Clarity and correctness of registrations. Experts are expected to 2237 check the clarity of purpose and use of the requested entries. 2238 Experts should inspect the entry for the considered role, to 2239 verify the correctness of its description against the role as 2240 intended in the specification that defined it. Expert should 2241 consider requesting an opinion on the correctness of registered 2242 parameters from the Authentication and Authorization for 2243 Constrained Environments (ACE) Working Group and the Constrained 2244 RESTful Environments (CoRE) Working Group. 2246 Entries that do not meet these objective of clarity and 2247 completeness should not be registered. 2249 o Duplicated registration and point squatting should be discouraged. 2250 Reviewers are encouraged to get sufficient information for 2251 registration requests to ensure that the usage is not going to 2252 duplicate one that is already registered and that the point is 2253 likely to be used in deployments. 2255 o Experts should take into account the expected usage of roles when 2256 approving point assignment. Given a 'Value' V as code point, the 2257 length of the encoding of (2^(V+1) - 1) should be weighed against 2258 the usage of the entry, considering the resources and capabilities 2259 of devices it will be used on. Additionally, given a 'Value' V as 2260 code point, the length of the encoding of (2^(V+1) - 1) should be 2261 weighed against how many code points resulting in that encoding 2262 length are left, and the resources and capabilities of devices it 2263 will be used on. 2265 o Specifications are recommended. When specifications are not 2266 provided, the description provided needs to have sufficient 2267 information to verify the points above. 2269 22. References 2271 22.1. Normative References 2273 [CORE.Parameters] 2274 IANA, "Constrained RESTful Environments (CoRE) 2275 Parameters", . 2278 [COSE.Algorithms] 2279 IANA, "COSE Algorithms", 2280 . 2283 [COSE.Elliptic.Curves] 2284 IANA, "COSE Elliptic Curves", 2285 . 2288 [COSE.Key.Types] 2289 IANA, "COSE Key Types", 2290 . 2293 [CWT.Confirmation.Methods] 2294 IANA, "CWT Confirmation Methods", 2295 . 2298 [I-D.ietf-ace-aif] 2299 Bormann, C., "An Authorization Information Format (AIF) 2300 for ACE", draft-ietf-ace-aif-00 (work in progress), July 2301 2020. 2303 [I-D.ietf-ace-key-groupcomm] 2304 Palombini, F. and M. Tiloca, "Key Provisioning for Group 2305 Communication using ACE", draft-ietf-ace-key-groupcomm-10 2306 (work in progress), November 2020. 2308 [I-D.ietf-ace-oauth-authz] 2309 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 2310 H. Tschofenig, "Authentication and Authorization for 2311 Constrained Environments (ACE) using the OAuth 2.0 2312 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35 2313 (work in progress), June 2020. 2315 [I-D.ietf-ace-oscore-profile] 2316 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 2317 "OSCORE Profile of the Authentication and Authorization 2318 for Constrained Environments Framework", draft-ietf-ace- 2319 oscore-profile-13 (work in progress), October 2020. 2321 [I-D.ietf-cbor-7049bis] 2322 Bormann, C. and P. Hoffman, "Concise Binary Object 2323 Representation (CBOR)", draft-ietf-cbor-7049bis-16 (work 2324 in progress), September 2020. 2326 [I-D.ietf-core-oscore-groupcomm] 2327 Tiloca, M., Selander, G., Palombini, F., and J. Park, 2328 "Group OSCORE - Secure Group Communication for CoAP", 2329 draft-ietf-core-oscore-groupcomm-10 (work in progress), 2330 November 2020. 2332 [I-D.ietf-cose-rfc8152bis-algs] 2333 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2334 Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-12 2335 (work in progress), September 2020. 2337 [I-D.ietf-cose-rfc8152bis-struct] 2338 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2339 Structures and Process", draft-ietf-cose-rfc8152bis- 2340 struct-14 (work in progress), September 2020. 2342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2343 Requirement Levels", BCP 14, RFC 2119, 2344 DOI 10.17487/RFC2119, March 1997, 2345 . 2347 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 2348 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 2349 March 2010, . 2351 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2352 Specifications and Registration Procedures", BCP 13, 2353 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2354 . 2356 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 2357 Algorithm (DSA) and Elliptic Curve Digital Signature 2358 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2359 2013, . 2361 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2362 Application Protocol (CoAP)", RFC 7252, 2363 DOI 10.17487/RFC7252, June 2014, 2364 . 2366 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 2367 "PKCS #1: RSA Cryptography Specifications Version 2.2", 2368 RFC 8017, DOI 10.17487/RFC8017, November 2016, 2369 . 2371 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 2372 Signature Algorithm (EdDSA)", RFC 8032, 2373 DOI 10.17487/RFC8032, January 2017, 2374 . 2376 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2377 Writing an IANA Considerations Section in RFCs", BCP 26, 2378 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2379 . 2381 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2382 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2383 May 2017, . 2385 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2386 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2387 . 2389 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 2390 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 2391 . 2393 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2394 Definition Language (CDDL): A Notational Convention to 2395 Express Concise Binary Object Representation (CBOR) and 2396 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2397 June 2019, . 2399 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2400 "Object Security for Constrained RESTful Environments 2401 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2402 . 2404 22.2. Informative References 2406 [I-D.ietf-ace-dtls-authorize] 2407 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 2408 L. Seitz, "Datagram Transport Layer Security (DTLS) 2409 Profile for Authentication and Authorization for 2410 Constrained Environments (ACE)", draft-ietf-ace-dtls- 2411 authorize-14 (work in progress), October 2020. 2413 [I-D.ietf-ace-oscore-gm-admin] 2414 Tiloca, M., Hoeglund, R., Stok, P., Palombini, F., and K. 2415 Hartke, "Admin Interface for the OSCORE Group Manager", 2416 draft-ietf-ace-oscore-gm-admin-01 (work in progress), 2417 November 2020. 2419 [I-D.ietf-core-coap-pubsub] 2420 Koster, M., Keranen, A., and J. Jimenez, "Publish- 2421 Subscribe Broker for the Constrained Application Protocol 2422 (CoAP)", draft-ietf-core-coap-pubsub-09 (work in 2423 progress), September 2019. 2425 [I-D.ietf-core-echo-request-tag] 2426 Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, 2427 Request-Tag, and Token Processing", draft-ietf-core-echo- 2428 request-tag-10 (work in progress), July 2020. 2430 [I-D.ietf-core-groupcomm-bis] 2431 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 2432 for the Constrained Application Protocol (CoAP)", draft- 2433 ietf-core-groupcomm-bis-02 (work in progress), November 2434 2020. 2436 [I-D.tiloca-core-oscore-discovery] 2437 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 2438 Groups with the CoRE Resource Directory", draft-tiloca- 2439 core-oscore-discovery-07 (work in progress), November 2440 2020. 2442 [NIST-800-56A] 2443 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 2444 Davis, "Recommendation for Pair-Wise Key-Establishment 2445 Schemes Using Discrete Logarithm Cryptography - NIST 2446 Special Publication 800-56A, Revision 3", April 2018, 2447 . 2450 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2451 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2452 January 2012, . 2454 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 2455 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 2456 . 2458 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 2459 RFC 6749, DOI 10.17487/RFC6749, October 2012, 2460 . 2462 [RFC7641] Hartke, K., "Observing Resources in the Constrained 2463 Application Protocol (CoAP)", RFC 7641, 2464 DOI 10.17487/RFC7641, September 2015, 2465 . 2467 22.3. URIs 2469 [1] mailto:iesg@ietf.org 2471 [2] mailto:marco.tiloca@ri.se 2473 Appendix A. Profile Requirements 2475 This appendix lists the specifications on this application profile of 2476 ACE, based on the requirements defined in Appendix A of 2477 [I-D.ietf-ace-key-groupcomm]. 2479 o REQ1 - If the value of the GROUPNAME URI path and the group name 2480 in the Access Token scope (gname in Section 3.1 of 2481 [I-D.ietf-ace-key-groupcomm]) do not match, specify the mechanism 2482 to map the GROUPNAME value in the URI to the group name: not 2483 applicable, since a match is required. 2485 o REQ2 - Specify the encoding and value of roles, for scope entries 2486 of 'scope': see Section 3 and Section 4.1. 2488 o REQ3 - if used, specify the acceptable values for 'sign_alg': 2489 values from the "Value" column of the "COSE Algorithms" Registry 2490 [COSE.Algorithms]. 2492 o REQ4 - If used, specify the acceptable values for 2493 'sign_parameters': format and values from the COSE algorithm 2494 capabilities as specified in the "COSE Algorithms" Registry 2495 [COSE.Algorithms] and from the COSE key type capabilities as 2496 specified in the "COSE Key Types" Registry [COSE.Key.Types]. 2498 o REQ5 - If used, specify the acceptable values for 2499 'sign_key_parameters': format and values from the COSE key type 2500 capabilities as specified in the "COSE Key Types" Registry 2501 [COSE.Key.Types]. 2503 o REQ6 - If used, specify the acceptable values for 'pub_key_enc': 1 2504 ("COSE_Key") from the 'Confirmation Key' column of the "CWT 2505 Confirmation Method" Registry [CWT.Confirmation.Methods]. Future 2506 specifications may define additional values for this parameter. 2508 o REQ7a - Register a Resource Type for the root url-path, which is 2509 used to discover the correct url to access at the KDC (see 2510 Section 4.1 of [I-D.ietf-ace-key-groupcomm]): the Resource Type 2511 (rt=) Link Target Attribute value "core.osc.gm" is registered in 2512 Section 21.11. 2514 o REQ7aa - Define what operations (i.e. CoAP methods) are allowed 2515 on each resource, for each role defined in REQ2: see Section 5.2. 2517 o REQ7b - Specify the exact encoding of group identifier (see 2518 Section 4.1.1.1 of [I-D.ietf-ace-key-groupcomm]): CBOR byte string 2519 (see Section 15). 2521 o REQ7 - Format of the 'key' value: see Section 6.4. 2523 o REQ8 - Acceptable values of 'gkty': Group_OSCORE_Input_Material 2524 object (see Section 6.4). 2526 o REQ9 - Specify the format of the identifiers of group members: 2527 CBOR byte string (see Section 6.4 and Section 10). 2529 o REQ10 - Specify the communication protocol that the members of the 2530 group must use: CoAP [RFC7252], possibly over IP multicast 2531 [I-D.ietf-core-groupcomm-bis]. 2533 o REQ11 - Specify the security protocols that the group members must 2534 use to protect their communication: Group OSCORE 2535 [I-D.ietf-core-oscore-groupcomm]. 2537 o REQ12 - Specify and register the application profile identifier: 2538 coap_group_oscore_app (see Section 21.3). 2540 o REQ13 - Specify policies at the KDC to handle member ids that are 2541 not included in 'get_pub_keys': see Section 10. 2543 o REQ14 - If used, specify the format and content of 2544 'group_policies' and its entries: see Section 6.4; see the three 2545 values defined and registered as content of the entry "Sequence 2546 Number Synchronization Method" (see Section 21.4). 2548 o REQ15 - Specify the format of newly-generated individual keying 2549 material for group members, or of the information to derive it, 2550 and corresponding CBOR label: see Section 9. 2552 o REQ16 - Specify how the communication is secured between the 2553 Client and KDC: by means of any transport profile of ACE 2554 [I-D.ietf-ace-oauth-authz] between Client and Group Manager that 2555 complies with the requirements in Appendix C of 2556 [I-D.ietf-ace-oauth-authz]. 2558 o REQ17 - Specify how the nonce N_S is generated, if the token is 2559 not being posted (e.g. if it is used directly to validate TLS 2560 instead): see Section 6.2.1. 2562 o REQ18 - Specify if 'mgt_key_material' is used, and if yes specify 2563 its format and content: not used in this version of the profile. 2565 o REQ19 - Define the initial value of the 'num' parameter: The 2566 initial value MUST be set to 0 when creating the OSCORE group, 2567 e.g. as in [I-D.ietf-ace-oscore-gm-admin]. 2569 o OPT1 (Optional) - Specify the encoding of public keys, of 2570 'client_cred', and of 'pub_keys' if COSE_Keys are not used: no. 2572 o OPT2a (Optional) - Specify the negotiation of parameter values for 2573 signature algorithm and signature keys, if 'sign_info' is not 2574 used: possible early discovery by using the approach based on the 2575 CoRE Resource Directory described in 2576 [I-D.tiloca-core-oscore-discovery]. 2578 o OPT2b (Optional) - Specify additional parameters used in the Token 2579 Post exchange: 'ecdh_info', to negotiate the ECDH algorithm, ECDH 2580 algorithm parameters, ECDH key parameters and exact encoding of 2581 public keys used in the group, in case the joining node supports 2582 the pairwise mode of Group OSCORE. 2584 o OPT3 (Optional) - Specify the encoding of 'pub_keys_repos' if the 2585 default is not used: no. 2587 o OPT4 (Optional) - Specify policies that instruct clients to retain 2588 unsuccessfully decrypted messages and for how long, so that they 2589 can be decrypted after getting updated keying material: no. 2591 o OPT5 (Optional) - Specify the behavior of the handler in case of 2592 failure to retrieve a public key for the specific node: send a 2593 4.00 Bad Request response to a Joining Request (see Section 6.3). 2595 o OPT6 (Optional) - Specify possible or required payload formats for 2596 specific error cases: send a 4.00 Bad Request response to a 2597 Joining Request (see Section 6.3). 2599 o OPT7 (Optional) - Specify CBOR values to use for abbreviating 2600 identifiers of roles in the group or topic: see Section 4.1. 2602 o OPT8 (Optional) - Specify for the KDC to perform group rekeying 2603 (together or instead of renewing individual keying material) when 2604 receiving a Key Renewal Request: the Group Manager SHOULD NOT 2605 perform a group rekeying, unless already scheduled to occur 2606 shortly (see Section 9). 2608 o OPT9 (Optional) - Specify the functionalities implemented at the 2609 'control_path' resource hosted at the Client, including message 2610 exchange encoding and other details (see Section 4.1.2.1 of 2611 [I-D.ietf-ace-key-groupcomm]): see Section 17 for the eviction of 2612 a group member; see Section 18 for the group rekeying process. 2614 o OPT10 (Optional) - Specify how the identifier of the sender's 2615 public key is included in the group request: no. 2617 Appendix B. Document Updates 2619 RFC EDITOR: PLEASE REMOVE THIS SECTION. 2621 B.1. Version -08 to -09 2623 o The url-path "ace-group" is used. 2625 o Added overview of admitted methods on the Group Manager resources. 2627 o Added exchange of parameters relevant for the pairwise mode of 2628 Group OSCORE. 2630 o The signed value for 'client_cred_verify' includes also the scope. 2632 o Renamed the key material object as Group_OSCORE_Input_Material 2633 object. 2635 o Replaced 'clientId' with 'group_SenderId'. 2637 o Added message exchange for Group Names request-response. 2639 o No reassignment of Sender ID and Gid in the same OSCORE group. 2641 o Updates on group rekeying contextual with request of new Sender 2642 ID. 2644 o Signature verifiers can also retrieve Group Names and URIs. 2646 o Removed group policy about supporting Group OSCORE in pairwise 2647 mode. 2649 o Registration of the resource type rt="core.osc.gm". 2651 o Update list of requirements. 2653 o Clarifications and editorial revision. 2655 B.2. Version -07 to -08 2657 o AIF specific data model to express scope entries. 2659 o A set of roles is checked as valid when processing the Joining 2660 Request. 2662 o Updated format of 'get_pub_keys' in the Joining Request. 2664 o Payload format and default values of group policies in the Joining 2665 Response. 2667 o Updated payload format of the FETCH request to retrieve public 2668 keys. 2670 o Default values for group configuration parameters. 2672 o IANA registrations to support the AIF specific data model. 2674 B.3. Version -06 to -07 2676 o Alignments with draft-ietf-core-oscore-groupcomm. 2678 o New format of 'sign_info', using the COSE capabilities. 2680 o New format of Joining Response parameters, using the COSE 2681 capabilities. 2683 o Considerations on group rekeying. 2685 o Editorial revision. 2687 B.4. Version -05 to -06 2689 o Added role of external signature verifier. 2691 o Parameter 'rsnonce' renamed to 'kdcchallenge'. 2693 o Parameter 'kdcchallenge' may be omitted in some cases. 2695 o Clarified difference between group name and OSCORE Gid. 2697 o Removed the role combination ["requester", "monitor"]. 2699 o Admit implicit scope and audience in the Authorization Request. 2701 o New format for the 'sign_info' parameter. 2703 o Scope not mandatory to include in the Joining Request. 2705 o Group policy about supporting Group OSCORE in pairwise mode. 2707 o Possible individual rekeying of a single requesting node combined 2708 with a group rekeying. 2710 o Security considerations on reusage of signature challenges. 2712 o Addressing optional requirement OPT9 from draft-ietf-ace-key- 2713 groupcomm 2715 o Editorial improvements. 2717 B.5. Version -04 to -05 2719 o Nonce N_S also in error responses to the Joining Requests. 2721 o Supporting single Access Token for multiple groups/topics. 2723 o Supporting legal requesters/responders using the 'peer_roles' 2724 parameter. 2726 o Registered and used dedicated label for TLS Exporter. 2728 o Added method for uploading a new public key to the Group Manager. 2730 o Added resource and method for retrieving the current group status. 2732 o Fixed inconsistency in retrieving group keying material only. 2734 o Clarified retrieval of keying material for monitor-only members. 2736 o Clarification on incrementing version number when rekeying the 2737 group. 2739 o Clarification on what is re-distributed with the group rekeying. 2741 o Security considerations on the size of the nonces used for the 2742 signature challenge. 2744 o Added CBOR values to abbreviate role identifiers in the group. 2746 B.6. Version -03 to -04 2748 o New abstract. 2750 o Moved general content to draft-ietf-ace-key-groupcomm 2752 o Terminology: node name; node resource. 2754 o Creation and pointing at node resource. 2756 o Updated Group Manager API (REST methods and offered services). 2758 o Size of challenges 'cnonce' and 'rsnonce'. 2760 o Value of 'rsnonce' for reused or non-traditionally-posted tokens. 2762 o Removed reference to RFC 7390. 2764 o New requirements from draft-ietf-ace-key-groupcomm 2765 o Editorial improvements. 2767 B.7. Version -02 to -03 2769 o New sections, aligned with the interface of ace-key-groupcomm . 2771 o Exchange of information on the countersignature algorithm and 2772 related parameters, during the Token POST (Section 4.1). 2774 o Nonce 'rsnonce' from the Group Manager to the Client 2775 (Section 4.1). 2777 o Client PoP signature in the Key Distribution Request upon joining 2778 (Section 4.2). 2780 o Local actions on the Group Manager, upon a new node's joining 2781 (Section 4.2). 2783 o Local actions on the Group Manager, upon a node's leaving 2784 (Section 12). 2786 o IANA registration in ACE Groupcomm Parameters Registry. 2788 o More fulfilled profile requirements (Appendix A). 2790 B.8. Version -01 to -02 2792 o Editorial fixes. 2794 o Changed: "listener" to "responder"; "pure listener" to "monitor". 2796 o Changed profile name to "coap_group_oscore_app", to reflect it is 2797 an application profile. 2799 o Added the 'type' parameter for all requests to a Join Resource. 2801 o Added parameters to indicate the encoding of public keys. 2803 o Challenge-response for proof-of-possession of signature keys 2804 (Section 4). 2806 o Renamed 'key_info' parameter to 'sign_info'; updated its format; 2807 extended to include also parameters of the countersignature key 2808 (Section 4.1). 2810 o Code 4.00 (Bad request), in responses to joining nodes providing 2811 an invalid public key (Section 4.3). 2813 o Clarifications on provisioning and checking of public keys 2814 (Sections 4 and 6). 2816 o Extended discussion on group rekeying and possible different 2817 approaches (Section 7). 2819 o Extended security considerations: proof-of-possession of signature 2820 keys; collision of OSCORE Group Identifiers (Section 8). 2822 o Registered three entries in the IANA Registry "Sequence Number 2823 Synchronization Method Registry" (Section 9). 2825 o Registered one public key encoding in the "ACE Public Key 2826 Encoding" IANA Registry (Section 9). 2828 B.9. Version -00 to -01 2830 o Changed name of 'req_aud' to 'audience' in the Authorization 2831 Request (Section 3.1). 2833 o Added negotiation of countersignature algorithm/parameters between 2834 Client and Group Manager (Section 4). 2836 o Updated format of the Key Distribution Response as a whole 2837 (Section 4.3). 2839 o Added parameter 'cs_params' in the 'key' parameter of the Key 2840 Distribution Response (Section 4.3). 2842 o New IANA registrations in the "ACE Authorization Server Request 2843 Creation Hints" Registry, "ACE Groupcomm Key" Registry, "OSCORE 2844 Security Context Parameters" Registry and "ACE Groupcomm Profile" 2845 Registry (Section 9). 2847 Acknowledgments 2849 The authors sincerely thank Santiago Aragon, Stefan Beck, Carsten 2850 Bormann, Martin Gunnarsson, Rikard Hoeglund, Daniel Migault, Jim 2851 Schaad, Ludwig Seitz, Goeran Selander and Peter van der Stok for 2852 their comments and feedback. 2854 The work on this document has been partly supported by VINNOVA and 2855 the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home 2856 (Grant agreement 952652); and by the EIT-Digital High Impact 2857 Initiative ACTIVE. 2859 Authors' Addresses 2861 Marco Tiloca 2862 RISE AB 2863 Isafjordsgatan 22 2864 Kista SE-164 29 Stockholm 2865 Sweden 2867 Email: marco.tiloca@ri.se 2869 Jiye Park 2870 Universitaet Duisburg-Essen 2871 Schuetzenbahn 70 2872 Essen 45127 2873 Germany 2875 Email: ji-ye.park@uni-due.de 2877 Francesca Palombini 2878 Ericsson AB 2879 Torshamnsgatan 23 2880 Kista SE-16440 Stockholm 2881 Sweden 2883 Email: francesca.palombini@ericsson.com