idnits 2.17.1 draft-ietf-ace-key-groupcomm-oscore-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2021) is 1153 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 2172, but not defined == Missing Reference: 'Tperm' is mentioned on line 2172, but not defined == Missing Reference: 'OKP' is mentioned on line 1809, but not defined == Missing Reference: 'Ed25519' is mentioned on line 1744, but not defined == Missing Reference: 'Ed448' is mentioned on line 1748, but not defined == Missing Reference: 'EC2' is mentioned on line 1824, but not defined == Missing Reference: 'P-256' is mentioned on line 1814, but not defined == Missing Reference: 'P-384' is mentioned on line 1819, but not defined == Missing Reference: 'P-521' is mentioned on line 1824, but not defined == Missing Reference: 'RSA' is mentioned on line 1768, but not defined == Missing Reference: 'X25519' is mentioned on line 1805, but not defined == Missing Reference: 'X448' is mentioned on line 1809, but not defined -- Looks like a reference, but probably isn't: '1' on line 2526 -- Looks like a reference, but probably isn't: '2' on line 2528 == Outdated reference: A later version (-07) exists of draft-ietf-ace-aif-02 == Outdated reference: A later version (-18) exists of draft-ietf-ace-key-groupcomm-11 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-37 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-16 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-11 ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') -- 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-15 == Outdated reference: A later version (-11) exists of draft-ietf-ace-oscore-gm-admin-02 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-10) exists of draft-ietf-core-groupcomm-bis-03 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-08 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 4 errors (**), 0 flaws (~~), 24 warnings (==), 5 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: August 26, 2021 Universitaet Duisburg-Essen 6 F. Palombini 7 Ericsson AB 8 February 22, 2021 10 Key Management for OSCORE Groups in ACE 11 draft-ietf-ace-key-groupcomm-oscore-10 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 August 26, 2021. 44 Copyright Notice 46 Copyright (c) 2021 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 . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . 12 75 6.1. Token Post . . . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . 18 80 6.4. Joining Response . . . . . . . . . . . . . . . . . . . . 20 81 7. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 24 82 8. Retrieval of Updated Keying Material . . . . . . . . . . . . 26 83 8.1. Retrieval of Group Keying Material . . . . . . . . . . . 26 84 8.2. Retrieval of Group Keying Material and Sender ID . . . . 27 85 9. Requesting a Change of Keying Material . . . . . . . . . . . 27 86 10. Retrieval of Public Keys and Roles for Group Members . . . . 29 87 11. Update of Public Key . . . . . . . . . . . . . . . . . . . . 29 88 12. Retrieval of Group Policies . . . . . . . . . . . . . . . . . 30 89 13. Retrieval of Keying Material Version . . . . . . . . . . . . 31 90 14. Retrieval of Group Status . . . . . . . . . . . . . . . . . . 31 91 15. Retrieval of Group Names and URIs . . . . . . . . . . . . . . 32 92 16. Request to Leave the Group . . . . . . . . . . . . . . . . . 34 93 17. Removal of a Group Member . . . . . . . . . . . . . . . . . . 34 94 18. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 35 95 19. Default Values for Group Configuration Parameters . . . . . . 37 96 20. Security Considerations . . . . . . . . . . . . . . . . . . . 40 97 20.1. Management of OSCORE Groups . . . . . . . . . . . . . . 40 98 20.2. Size of Nonces for Signature Challenge . . . . . . . . . 41 99 20.3. Reusage of Nonces for Signature Challenge . . . . . . . 42 100 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 101 21.1. ACE Groupcomm Parameters Registry . . . . . . . . . . . 43 102 21.2. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 43 103 21.3. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 43 104 21.4. OSCORE Security Context Parameters Registry . . . . . . 44 105 21.5. TLS Exporter Label Registry . . . . . . . . . . . . . . 46 106 21.6. AIF Registry . . . . . . . . . . . . . . . . . . . . . . 46 107 21.7. Media Type Registrations . . . . . . . . . . . . . . . . 47 108 21.8. CoAP Content-Format Registry . . . . . . . . . . . . . . 48 109 21.9. Group OSCORE Roles Registry . . . . . . . . . . . . . . 48 110 21.10. CoRE Resource Type Registry . . . . . . . . . . . . . . 49 111 21.11. ACE Scope Semantics Registry . . . . . . . . . . . . . . 49 112 21.12. ACE Groupcomm Errors . . . . . . . . . . . . . . . . . . 49 113 21.13. Expert Review Instructions . . . . . . . . . . . . . . . 49 114 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 115 22.1. Normative References . . . . . . . . . . . . . . . . . . 50 116 22.2. Informative References . . . . . . . . . . . . . . . . . 53 117 22.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 54 118 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 54 119 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 58 120 B.1. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 58 121 B.2. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 58 122 B.3. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 59 123 B.4. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 59 124 B.5. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 59 125 B.6. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 60 126 B.7. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 61 127 B.8. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 61 128 B.9. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 62 129 B.10. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 62 130 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 63 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 133 1. Introduction 135 Object Security for Constrained RESTful Environments (OSCORE) 136 [RFC8613] is a method for application-layer protection of the 137 Constrained Application Protocol (CoAP) [RFC7252], using CBOR Object 138 Signing and Encryption (COSE) 139 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs] and 140 enabling end-to-end security of CoAP payload and options. 142 As described in [I-D.ietf-core-oscore-groupcomm], Group OSCORE is 143 used to protect CoAP group communication over IP multicast 144 [I-D.ietf-core-groupcomm-bis]. This relies on a Group Manager, which 145 is responsible for managing an OSCORE group and enables the group 146 members to exchange CoAP messages secured with Group OSCORE. The 147 Group Manager can be responsible for multiple groups, coordinates the 148 joining process of new group members, and is entrusted with the 149 distribution and renewal of group keying material. 151 This specification is an application profile of 152 [I-D.ietf-ace-key-groupcomm], which itself builds on the ACE 153 framework for Authentication and Authorization 154 [I-D.ietf-ace-oauth-authz]. Message exchanges among the participants 155 as well as message formats and processing follow what specified in 156 [I-D.ietf-ace-key-groupcomm] for provisioning and renewing keying 157 material in group communication scenarios, where Group OSCORE is used 158 to protect CoAP group communication over IP multicast. 160 1.1. Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 164 "OPTIONAL" in this document are to be interpreted as described in BCP 165 14 [RFC2119][RFC8174] when, and only when, they appear in all 166 capitals, as shown here. 168 Readers are expected to be familiar with: 170 o The terms and concepts described in the ACE framework for 171 authentication and authorization [I-D.ietf-ace-oauth-authz] and in 172 the Authorization Information Format (AIF) [I-D.ietf-ace-aif] to 173 express authorization information. The terminology for entities 174 in the considered architecture is defined in OAuth 2.0 [RFC6749]. 175 In particular, this includes Client (C), Resource Server (RS), and 176 Authorization Server (AS). 178 o The terms and concept related to the message formats and 179 processing specified in [I-D.ietf-ace-key-groupcomm], for 180 provisioning and renewing keying material in group communication 181 scenarios. 183 o The terms and concepts described in CBOR [RFC8949] and COSE 184 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs]. 186 o The terms and concepts described in CoAP [RFC7252] and group 187 communication for CoAP [I-D.ietf-core-groupcomm-bis]. Unless 188 otherwise indicated, the term "endpoint" is used here following 189 its OAuth definition, aimed at denoting resources such as /token 190 and /introspect at the AS, and /authz-info at the RS. This 191 document does not use the CoAP definition of "endpoint", which is 192 "An entity participating in the CoAP protocol". 194 o The terms and concepts for protection and processing of CoAP 195 messages through OSCORE [RFC8613] and through Group OSCORE 196 [I-D.ietf-core-oscore-groupcomm] in group communication scenarios. 197 These include the concept of Group Manager, as the entity 198 responsible for a set of groups where communications are secured 199 with Group OSCORE. In this specification, the Group Manager acts 200 as Resource Server. 202 Additionally, this document makes use of the following terminology. 204 o Requester: member of an OSCORE group that sends request messages 205 to other members of the group. 207 o Responder: member of an OSCORE group that receives request 208 messages from other members of the group. A responder may reply 209 back, by sending a response message to the requester which has 210 sent the request message. 212 o Monitor: member of an OSCORE group that is configured as responder 213 and never replies back to requesters after receiving request 214 messages. This corresponds to the term "silent server" used in 215 [I-D.ietf-core-oscore-groupcomm]. 217 o Signature verifier: entity external to the OSCORE group and 218 intended to verify the countersignature of messages exchanged in 219 the group. An authorized signature verifier does not join the 220 OSCORE group as an actual member, yet it can retrieve the public 221 keys of the current group members from the Group Manager. 223 2. Protocol Overview 225 Group communication for CoAP over IP multicast has been enabled in 226 [I-D.ietf-core-groupcomm-bis] and can be secured with Group Object 227 Security for Constrained RESTful Environments (OSCORE) [RFC8613] as 228 described in [I-D.ietf-core-oscore-groupcomm]. A network node joins 229 an OSCORE group by interacting with the responsible Group Manager. 230 Once registered in the group, the new node can securely exchange 231 messages with other group members. 233 This specification describes how to use [I-D.ietf-ace-key-groupcomm] 234 and [I-D.ietf-ace-oauth-authz] to perform a number of authentication, 235 authorization and key distribution actions, as defined in Section 2 236 of [I-D.ietf-ace-key-groupcomm], for an OSCORE group. 238 With reference to [I-D.ietf-ace-key-groupcomm]: 240 o The node wishing to join the OSCORE group, i.e. the joining node, 241 is the Client. 243 o The Group Manager is the Key Distribution Center (KDC), acting as 244 a Resource Server. 246 o The Authorization Server associated to the Group Manager is the 247 AS. 249 All communications between the involved entities MUST be secured. 251 In particular, communications between the Client and the Group 252 Manager leverage protocol-specific transport profiles of ACE to 253 achieve communication security, proof-of-possession and server 254 authentication. It is expected that, in the commonly referred base- 255 case of this specification, the transport profile to use is pre- 256 configured and well-known to nodes participating in constrained 257 applications. 259 Appendix A lists the specifications on this application profile of 260 ACE, based on the requirements defined in Appendix A of 261 [I-D.ietf-ace-key-groupcomm]. 263 2.1. Overview of the Joining Process 265 A node performs the steps described in Section 4.3 of 266 [I-D.ietf-ace-key-groupcomm] in order to join an OSCORE group. The 267 format and processing of messages exchanged among the participants 268 are further specified in Section 4 and Section 6 of this document. 270 2.2. Overview of the Group Rekeying Process 272 If the application requires backward and forward security, the Group 273 Manager MUST generate new keying material and distribute it to the 274 group (rekeying) upon membership changes. 276 That is, the group is rekeyed when a node joins the group as a new 277 member, or after a current member leaves the group. By doing so, a 278 joining node cannot access communications in the group prior its 279 joining, while a leaving node cannot access communications in the 280 group after its leaving. 282 The keying material distributed through a group rekeying MUST 283 include: 285 o A new Group Identifier (Gid) for the group as introduced in 286 [I-D.ietf-ace-key-groupcomm], used as ID Context parameter of the 287 Group OSCORE Common Security Context of that group (see Section 2 288 of [I-D.ietf-core-oscore-groupcomm]). 290 Note that the Gid differs from the group name also introduced in 291 [I-D.ietf-ace-key-groupcomm], which is a plain, stable and 292 invariant identifier, with no cryptographic relevance and meaning. 294 o A new value for the Master Secret parameter of the Group OSCORE 295 Common Security Context of that group (see Section 2 of 296 [I-D.ietf-core-oscore-groupcomm]). 298 Also, the distributed keying material MAY include a new value for the 299 Master Salt parameter of the Group OSCORE Common Security Context of 300 that group. 302 Upon generating the new group keying material and before starting its 303 distribution, the Group Manager MUST increment the version number of 304 the group keying material. When rekeying a group, the Group Manager 305 MUST preserve the current value of the Sender ID of each member in 306 that group. 308 The Group Manager MUST support the Group Rekeying Process described 309 in Section 18. Future application profiles may define alternative 310 message formats and distribution schemes to perform group rekeying. 312 3. Format of Scope 314 Building on Section 3.1 of [I-D.ietf-ace-key-groupcomm], this section 315 defines the exact format and encoding of scope to use. 317 To this end, this profile uses the Authorization Information Format 318 (AIF) [I-D.ietf-ace-aif], and defines the following AIF specific data 319 model AIF-OSCORE-GROUPCOMM. 321 With reference to the generic AIF model 323 AIF-Generic = [* [Toid, Tperm]] 325 the value of the CBOR byte string used as scope encodes the CBOR 326 array [* [Toid, Tperm]], where each [Toid, Tperm] element corresponds 327 to one scope entry. 329 Then, for each scope entry: 331 o the object identifier ("Toid") is specialized as a CBOR text 332 string, specifying the group name for the scope entry; 334 o the permission set ("Tperm") is specialized as a CBOR unsigned 335 integer with value R, specifying the role(s) that the client 336 wishes to take in the group (REQ2). The value R is computed as 337 follows: 339 * each role in the permission set is converted into the 340 corresponding numeric identifier X from the "Value" column of 341 the table in Figure 1. 343 * the set of N numbers is converted into the single value R, by 344 taking each numeric identifier X_1, X_2, ..., X_N to the power 345 of two, and then computing the inclusive OR of the binary 346 representations of all the power values. 348 +-----------+-------+-------------------------------------------------+ 349 | Name | Value | Description | 350 +===========+=======+=================================================+ 351 | Reserved | 0 | This value is reserved | 352 |-----------+-------+-------------------------------------------------+ 353 | Requester | 1 | Send requests; receive responses | 354 |-----------+-------+-------------------------------------------------+ 355 | Responder | 2 | Send responses; receive requests | 356 +-----------+-------+-------------------------------------------------+ 357 | Monitor | 3 | Receive requests; never send requests/responses | 358 |-----------+-------+-------------------------------------------------| 359 | Verifier | 4 | Verify countersignature of intercepted messages | 360 +-----------+-------+-------------------------------------------------+ 362 Figure 1: Numeric identifier of roles in the OSCORE group 364 The CDDL [RFC8610] definition of the AIF-OSCORE-GROUPCOMM data model 365 is as follows: 367 AIF-OSCORE-GROUPCOMM = AIF_Generic 369 path = tstr ; Group name 370 permissions = uint . bits roles 371 roles = &( 372 Requester: 1, 373 Responder: 2, 374 Monitor: 3, 375 Verifier: 4 376 ) 378 Future specifications that define new roles MUST register a 379 corresponding numeric identifier in the "Group OSCORE Roles" Registry 380 defined in Section 21.9 of this specification. 382 4. Joining Node to Authorization Server 384 This section describes how the joining node interacts with the AS in 385 order to be authorized to join an OSCORE group under a given Group 386 Manager. In particular, it considers a joining node that intends to 387 contact that Group Manager for the first time. 389 The message exchange between the joining node and the AS consists of 390 the messages Authorization Request and Authorization Response defined 391 in Section 3 of [I-D.ietf-ace-key-groupcomm]. Note that what is 392 defined in [I-D.ietf-ace-key-groupcomm] applies, and only additions 393 or modifications to that specification are defined here. 395 4.1. Authorization Request 397 The Authorization Request message is as defined in Section 3.1 of 398 [I-D.ietf-ace-key-groupcomm], with the following additions. 400 o If the 'scope' parameter is present: 402 * The value of the CBOR byte string encodes a CBOR array, whose 403 format MUST follow the data model AIF-OSCORE-GROUPCOMM defined 404 in Section 3. In particular, for each OSCORE group to join: 406 + The group name is encoded as a CBOR text string. 408 + The set of requested roles is expressed as a single CBOR 409 unsigned integer, computed as defined in Section 3 (REQ2) 410 from the numerical abbreviations defined in Figure 1 for 411 each requested role (OPT8). 413 4.2. Authorization Response 415 The Authorization Response message is as defined in Section 3.2 of 416 [I-D.ietf-ace-key-groupcomm], with the following additions: 418 o The AS MUST include the 'expires_in' parameter. Other means for 419 the AS to specify the lifetime of Access Tokens are out of the 420 scope of this specification. 422 o The AS MUST include the 'scope' parameter, when the value included 423 in the Access Token differs from the one specified by the joining 424 node in the request. In such a case, the second element of each 425 scope entry MUST be present, and specifies the set of roles that 426 the joining node is actually authorized to take in the OSCORE 427 group for that scope entry, encoded as specified in Section 4.1. 429 Furthermore, if the AS uses the extended format of scope defined in 430 Section 6 of [I-D.ietf-ace-key-groupcomm] for the 'scope' claim of 431 the Access Token, the first element of the CBOR sequence [RFC8742] 432 MUST be the CBOR integer with value SEM_ID_TBD, defined in 433 Section 21.11 of this specification (REQ23). This indicates that the 434 second element of the CBOR sequence, as conveying the actual access 435 control information, follows the scope semantics defined for this 436 application profile in Section 3 of this specification. 438 5. Interface at the Group Manager 440 The Group Manager provides the interface defined in Section 4.1 of 441 [I-D.ietf-ace-key-groupcomm], with one additional sub-resource 442 defined in Section 5.1 of this specification. 444 Furthermore, Section 5.2 provides a summary of the CoAP methods 445 admitted to access different resources at the Group Manager, for 446 nodes with different roles in the group or as non members (REQ8). 448 The GROUPNAME segment of the URI path MUST match with the group name 449 specified in the scope entry of the Access Token scope (i.e. 'gname' 450 in Section 3.1 of [I-D.ietf-ace-key-groupcomm]) (REQ1). 452 The Resource Type (rt=) Link Target Attribute value "core.osc.gm" is 453 registered in Section 21.10 (REQ7), and can be used to describe 454 group-membership resources and its sub-resources at a Group Manager, 455 e.g. by using a link-format document [RFC6690]. 457 Applications can use this common resource type to discover links to 458 group-membership resources for joining OSCORE groups, e.g. by using 459 the approach described in [I-D.tiloca-core-oscore-discovery]. 461 5.1. ace-group/GROUPNAME/active 463 This resource implements a GET handler. 465 5.1.1. GET Handler 467 The handler expects a GET request. 469 The Group Manager verifies that the group name in the /ace- 470 group/GROUPNAME/active path is a subset of the 'scope' stored in the 471 Access Token associated to the requesting client. 473 The Group Manager also verifies that the roles granted to the 474 requesting client in the group allow it to perform this operation on 475 this resource (REQ8). If either verification fails, the Group 476 Manager MUST respond with a 4.01 (Unauthorized) error message. 478 Additionally, the handler verifies that the requesting client is a 479 current member of the group. If verification fails, the Group 480 Manager MUST respond with a 4.01 (Unauthorized) error message. The 481 response MUST have Content-Format set to application/ace- 482 groupcomm+cbor and is formatted as defined in Section 4 of 483 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be 484 set to 0 ("Operation permitted only to group members"). 486 If verification succeeds, the handler returns a 2.05 (Content) 487 message containing the CBOR simple value True if the group is 488 currently active, or the CBOR simple value False otherwise. The 489 group is considered active if it is set to allow new members to join, 490 and if communication within the group is fine to happen. 492 The method to set the current group status, i.e. active or inactive, 493 is out of the scope of this specification, and is defined for the 494 administrator interface of the Group Manager specified in 495 [I-D.ietf-ace-oscore-gm-admin]. 497 5.2. Admitted Methods 499 The table in Figure 2 summarizes the CoAP methods admitted to access 500 different resources at the Group Manager, for (non-)members of a 501 group with group name GROUPNAME, and considering different roles. 502 The last two rows of the table apply to a node with node name 503 NODENAME. 505 +------------------------------+--------+-------+-------+-------+ 506 | Resource | Type1 | Type2 | Type3 | Type4 | 507 +------------------------------+--------+-------+-------+-------+ 508 | ace-group/ | F | F | F | - | 509 +------------------------------+--------+-------+-------+-------+ 510 | ace-group/GROUPNAME/ | G Po | G Po | Po * | Po | 511 +------------------------------+--------+-------+-------+-------+ 512 | ace-group/GROUPNAME/active | G | G | - | - | 513 +------------------------------+--------+-------+-------+-------+ 514 | ace-group/GROUPNAME/pub-key | G F | G F | G F | - | 515 +------------------------------+--------+-------+-------+-------+ 516 | ace-group/GROUPNAME/policies | G | G | - | - | 517 +------------------------------+--------+-------+-------+-------+ 518 | ace-group/GROUPNAME/num | G | G | - | - | 519 +------------------------------+--------+-------+-------+-------+ 520 | ace-group/GROUPNAME/nodes/ | G Pu D | G D | - | - | 521 | NODENAME | | | | | 522 +------------------------------+--------+-------+-------+-------+ 523 | ace-group/GROUPNAME/nodes/ | Po | - | - | - | 524 | NODENAME/pub-key | | | | | 525 +------------------------------+--------+-------+-------+-------+ 527 Type1 = Member as Requester and/or Responder | G = GET 528 Type2 = Member as Monitor | F = FETCH 529 Type3 = Non-member / Authorized to be Verifier | Po = POST 530 (*) = cannot join the group as Verifier | Pu = PUT 531 Type4 = Non-member / Not authorized to be Verifier | D = DELETE 533 Figure 2: Admitted CoAP Methods on the Group Manager Resources 535 6. Token POST and Group Joining 537 The rest of this section describes the interactions between the 538 joining node and the Group Manager, i.e. the sending of the Access 539 Token and the Request-Response exchange to join the OSCORE group. 540 The message exchange between the joining node and the Group Manager 541 consists of the messages defined in Section 3.3 and 4.3 of 542 [I-D.ietf-ace-key-groupcomm]. Note that what is defined in 543 [I-D.ietf-ace-key-groupcomm] applies, and only additions or 544 modifications to that specification are defined here. 546 A signature verifier provides the Group Manager with an Access Token, 547 as described in Section 6.1, just as any another joining node does. 548 However, unlike candidate group members, it does not join any OSCORE 549 group, i.e. it does not perform the joining process defined in 550 Section 6.2. After successfully posting an Access Token, a signature 551 verifier is authorized to perform only the operations specified in 552 Section 10, to retrieve the public keys of group members, and only 553 for the OSCORE groups specified in the validated Access Token. The 554 Group Manager MUST respond with a 4.01 (Unauthorized) error message, 555 in case a signature verifier attempts to access any other endpoint 556 than /ace-group/GROUPNAME/pub-key at the Group Manager. 558 6.1. Token Post 560 The Token post exchange is defined in Section 3.3 of 561 [I-D.ietf-ace-key-groupcomm]. 563 Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the 564 following applies. 566 o The CoAP POST request MAY additionally contain the following 567 parameter, which, if included, MUST have the corresponding values: 569 * 'ecdh_info' defined in Section 6.1.1, encoding the CBOR simple 570 value Null to require information on the ECDH algorithm, the 571 ECDH algorithm parameters, the ECDH key parameters and on the 572 exact encoding of public keys used in the group, in case the 573 joining node supports the pairwise mode of Group OSCORE 574 [I-D.ietf-core-oscore-groupcomm]. 576 Alternatively, the joining node may retrieve this information by 577 other means. 579 o The 'kdcchallenge' parameter contains a dedicated nonce N_S 580 generated by the Group Manager. For the N_S value, it is 581 RECOMMENDED to use a 8-byte long random nonce. The joining node 582 can use this nonce in order to prove the possession of its own 583 private key, upon joining the group (see Section 6.2). 585 The 'kdcchallenge' parameter MAY be omitted from the 2.01 586 (Created) response, if the 'scope' of the Access Token specifies 587 only the role "monitor" or only the role "verifier" or both of 588 them, for each and every of the specified groups. 590 o If the 'sign_info' parameter is present in the response, the 591 following applies for each element 'sign_info_entry'. 593 * 'sign_alg' takes value from the "Value" column of the "COSE 594 Algorithms" Registry [COSE.Algorithms]. 596 * 'sign_parameters' is a CBOR array including the following two 597 elements: 599 + 'sign_alg_capab', encoded as a CBOR array. Its format and 600 value are the same of the COSE capabilities for the 601 algorithm indicated in 'sign_alg', as specified for that 602 algorithm in the "Capabilities" column of the "COSE 603 Algorithms" Registry [COSE.Algorithms] (REQ4). 605 + 'sign_key_type_capab', encoded as a CBOR array. Its format 606 and value are the same of the COSE capabilities for the COSE 607 key type of the keys used with the algorithm indicated in 608 'sign_alg', as specified for that key type in the 609 "Capabilities" column of the "COSE Key Types" Registry 610 [COSE.Key.Types] (REQ4). 612 * 'sign_key_parameters' is a CBOR array. Its format and value 613 are the same of the COSE capabilities for the COSE key type of 614 the keys used with the algorithm indicated in 'sign_alg', as 615 specified for that key type in the "Capabilities" column of the 616 "COSE Key Types" Registry [COSE.Key.Types] (REQ5). 618 * 'pub_key_enc' takes value 1 ("COSE_Key") from the 'Confirmation 619 Key' column of the "CWT Confirmation Method" Registry 620 [CWT.Confirmation.Methods], so indicating that public keys in 621 the OSCORE group are encoded as COSE Keys 622 [I-D.ietf-cose-rfc8152bis-struct]. Future specifications may 623 define additional values for this parameter. 625 o If 'ecdh_info' is included in the request, the Group Manager MAY 626 include the 'ecdh_info' parameter defined in Section 6.1.1, with 627 the same encoding. Note that the field 'id' takes as value the 628 group name, or array of group names, for which the corresponding 629 'ecdh_info_entry' applies to. 631 Note that, other than through the above parameters as defined in 632 Section 3.3 of [I-D.ietf-ace-key-groupcomm], the joining node MAY 633 have previously retrieved this information by other means, e.g. by 634 using the approach described in [I-D.tiloca-core-oscore-discovery] to 635 discover the OSCORE group and the link to the associated group- 636 membership resource at the Group Manager (OPT2). 638 Additionally, if allowed by the used transport profile of ACE, the 639 joining node may instead provide the Access Token to the Group 640 Manager by other means, e.g. during a secure session establishment 641 (see Section 3.3.2 of [I-D.ietf-ace-dtls-authorize]). 643 6.1.1. 'ecdh_info' Parameter 645 The 'ecdh_info' parameter is an OPTIONAL parameter of the Token Post 646 response message defined in Section 5.10.1. of 647 [I-D.ietf-ace-oauth-authz]. 649 This parameter is used to require and retrieve from the Group Manager 650 information and parameters about the ECDH algorithm and about the 651 public keys to be used in the OSCORE group to compute a static-static 652 Diffie-Hellman shared secret [NIST-800-56A], in case the group 653 supports the pairwise mode of Group OSCORE 654 [I-D.ietf-core-oscore-groupcomm]. 656 When used in the request, the 'ecdh_info' parameter encodes the CBOR 657 simple value Null, to require information and parameters on the ECDH 658 algorithm and on the public keys to be used to compute Diffie-Hellman 659 shared secrets in the OSCORE group. 661 The CDDL notation [RFC8610] of the 'ecdh_info' parameter formatted as 662 in the request is given below. 664 ecdh_info_req = nil 666 The 'ecdh_info' parameter of the 2.01 (Created) response is a CBOR 667 array of one or more elements. The number of elements is at most the 668 number of OSCORE groups the client has been authorized to join. 670 Each element contains information about ECDH parameters and about 671 public keys, for one or more OSCORE groups that support the pairwise 672 mode of Group OSCORE and that the client has been authorized to join. 673 Each element is formatted as follows. 675 o The first element 'id' is the group name of the OSCORE group or an 676 array of group names for the OSCORE groups for which the specified 677 information applies. 679 o The second element 'ecdh_alg' is an CBOR integer or a CBOR text 680 string indicating the ECDH algorithm used in the OSCORE group 681 identified by 'gname'. Values are taken from the "Value" column 682 of the "COSE Algorithms" Registry [COSE.Algorithms]. 684 o The third element 'ecdh_parameters' is a CBOR array indicating the 685 parameters of the ECDH algorithm used in the OSCORE group 686 identified by 'gname'. The CBOR array includes the following two 687 elements, and its exact content depends on the value of the 688 'ecdh_alg' element. 690 * 'ecdh_alg_capab', encoded as a CBOR array. Its format and 691 value are the same of the COSE capabilities for the algorithm 692 indicated in 'ecdh_alg', as specified for that algorithm in the 693 "Capabilities" column of the "COSE Algorithms" Registry 694 [COSE.Algorithms]. 696 * 'ecdh_key_type_capab', encoded as a CBOR array. Its format and 697 value are the same of the COSE capabilities for the COSE key 698 type of the keys used with the algorithm indicated in 699 'ecdh_alg', as specified for that key type in the 700 "Capabilities" column of the "COSE Key Types" Registry 701 [COSE.Key.Types]. 703 o The fourth element 'ecdh_key_parameters' is a CBOR array 704 indicating the parameters of the keys used with the ECDH algorithm 705 in the OSCORE group identified by 'gname'. Its content depends on 706 the value of 'ecdh_alg'. In particular, its format and value are 707 the same of the COSE capabilities for the COSE key type of the 708 keys used with the algorithm indicated in 'ecdh_alg', as specified 709 for that key type in the "Capabilities" column of the "COSE Key 710 Types" Registry [COSE.Key.Types]. 712 o The fifth element 'pub_key_enc' is CBOR integer indicating the 713 encoding of public keys used in the OSCORE group identified by 714 'gname'. It takes value 1 ("COSE_Key") from the 'Confirmation 715 Key' column of the "CWT Confirmation Method" Registry 716 [CWT.Confirmation.Methods], so indicating that public keys in the 717 OSCORE group are encoded as COSE Keys 718 [I-D.ietf-cose-rfc8152bis-struct]. Future specifications may 719 define additional values for this parameter. 721 The CDDL notation [RFC8610] of the 'ecdh_info' parameter formatted as 722 in the response is given below. 724 ecdh_info_res = [ + ecdh_info_entry ] 726 ecdh_info_entry = 727 [ 728 id : gname / [ + gname ], 729 ecdh_alg : int / tstr, 730 ecdh_parameters : [ any ], 731 ecdh_key_parameters : [ any ], 732 pub_key_enc = int 733 ] 735 gname = tstr 737 6.2. Sending the Joining Request 739 The joining node requests to join the OSCORE group by sending a 740 Joining Request message to the related group-membership resource at 741 the Group Manager, as per Section 4.3 of 742 [I-D.ietf-ace-key-groupcomm]. 744 Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the 745 following applies. 747 o The 'scope' parameter MUST be included. Its value encodes one 748 scope entry with the format defined in Section 3, indicating the 749 group name and the role(s) that the joining node wants to take in 750 the group. 752 o The 'get_pub_keys' parameter is present only if the joining node 753 wants to retrieve the public keys of the group members from the 754 Group Manager during the joining process (see Section 7). 755 Otherwise, this parameter MUST NOT be present. 757 If this parameter is present and its value is non-null, each 758 element of the inner CBOR array 'role_filter' is encoded as a CBOR 759 unsigned integer, with the same value of a permission set 760 ("Tperm") indicating that role or combination of roles in a scope 761 entry, as defined in Section 3. 763 o 'cnonce' contains a dedicated nonce N_C generated by the joining 764 node. For the N_C value, it is RECOMMENDED to use a 8-byte long 765 random nonce. 767 o The signature encoded in the 'client_cred_verify' parameter is 768 computed by the joining node by using the same private key and 769 countersignature algorithm it intends to use for signing messages 770 in the OSCORE group. Moreover, N_S is as defined in 771 Section 6.2.1. 773 6.2.1. Value of the N_S Challenge 775 The value of the N_S challenge is determined as follows. 777 1. If the joining node has posted the Access Token to the /authz- 778 info endpoint of the Group Manager as in Section 6.1, N_S takes 779 the same value of the most recent 'kdcchallenge' parameter 780 received by the joining node from the Group Manager. This can be 781 either the one specified in the 2.01 (Created) response to the 782 Token POST, or the one possibly specified in a 4.00 (Bad Request) 783 response to a following Joining Request (see Section 6.3). 785 2. If the Token posting has relied on the DTLS profile of ACE 786 [I-D.ietf-ace-dtls-authorize] with the Access Token as content of 787 the "psk_identity" field of the ClientKeyExchange message 788 [RFC6347], N_S is an exporter value computed as defined in 789 Section 7.5 of [RFC8446]. Specifically, N_S is exported from the 790 DTLS session between the joining node and the Group Manager, 791 using an empty 'context_value', 32 bytes as 'key_length', and the 792 exporter label "EXPORTER-ACE-Sign-Challenge-coap-group-oscore- 793 app" defined in Section 21.5 of this specification. 795 It is up to applications to define how N_S is computed in further 796 alternative settings. 798 Section 20.3 provides security considerations on the reusage of the 799 N_S challenge. 801 6.3. Processing the Joining Request 803 The Group Manager processes the Joining Request as defined in 804 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm]. Additionally, the 805 following applies. 807 o The Group Manager MUST return a 5.03 (Service Unavailable) 808 response in case the OSCORE group that the joining node has been 809 trying to join is currently inactive (see Section 5.1). The 810 response MUST have Content-Format set to application/ace- 811 groupcomm+cbor and is formatted as defined in Section 4 of 812 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST 813 be set to 7 ("Group currently not active"). 815 o In case the joining node is not going to join the group 816 exclusively as monitor and the Joining Request does not include 817 the 'client_cred' parameter, the joining process fails if the 818 Group Manager either: i) does not store a public key with an 819 accepted format for the joining node; or ii) stores multiple 820 public keys with an accepted format for the joining node. 822 o To compute the signature contained in 'client_cred_verify', the 823 Group Manager considers: 825 * as signed value, the value of the 'scope' parameter from the 826 Joining Request as a CBOR byte string, concatenated with N_S 827 encoded as a CBOR byte string, concatenated with N_C encoded as 828 a CBOR byte string. In particular, N_S is determined as 829 described in Section 6.2.1, while N_C is the nonce provided in 830 the 'cnonce' parameter of the Joining Request; 832 * the countersignature algorithm used in the OSCORE group, and 833 possible corresponding parameters; 835 * the public key of the joining node, either retrieved from the 836 'client_cred' parameter, or already stored as acquired from 837 previous interactions with the joining node. 839 o A 4.00 (Bad Request) response from the Group Manager to the 840 joining node MUST have content format application/ace+cbor. The 841 response payload is a CBOR map which MUST contain the 'sign_info' 842 parameter, including a single element 'sign_info_entry' pertaining 843 to the OSCORE group that the joining node has tried to join with 844 the Joining Request. If the group supports the pairwise mode of 845 Group OSCORE, the CBOR map MUST contain also the 'ecdh_info' 846 parameter, including a single element 'ecdh_info_entry' pertaining 847 to the OSCORE group that the joining node has tried to join with 848 the Joining Request. 850 o The Group Manager MUST return a 4.00 (Bad Request) response in 851 case the 'scope' parameter is not present in the Joining Request, 852 or if it is present and specifies any set of roles not included in 853 the following list: "requester", "responder", "monitor", 854 ("requester", "responder"). Future specifications that define a 855 new role MUST define possible sets of roles including the new one 856 and existing ones, that are acceptable to specify in the 'scope' 857 parameter of a Joining Request. 859 o The Group Manager MUST return a 4.00 (Bad Request) response in 860 case the Joining Request includes the 'client_cred' parameter but 861 does not include both the 'cnonce' and 'client_cred_verify' 862 parameters. 864 o The Group Manager MUST return a 4.00 (Bad Request) response in 865 case it cannot retrieve a public key with an accepted format for 866 the joining node, either from the 'client_cred' parameter or as 867 already stored. 869 o When receiving a 4.00 Bad Request response, the joining node 870 SHOULD send a new Joining Request to the Group Manager, where: 872 * The 'cnonce' parameter MUST include a new dedicated nonce N_C 873 generated by the joining node. 875 * The 'client_cred' parameter MUST include a public key 876 compatible with the encoding, countersignature algorithm and 877 possible associated parameters indicated by the Group Manager. 879 * The 'client_cred_verify' parameter MUST include a signature 880 computed as described in Section 6.2, by using the public key 881 indicated in the current 'client_cred' parameter, with the 882 countersignature algorithm and possible associated parameters 883 indicated by the Group Manager. If the error response from the 884 Group Manager included the 'kdcchallenge' parameter, the 885 joining node MUST use its content as new N_S challenge to 886 compute the signature. 888 6.4. Joining Response 890 If the processing of the Joining Request described in Section 6.3 is 891 successful, the Group Manager updates the group membership by 892 registering the joining node NODENAME as a new member of the OSCORE 893 group GROUPNAME, as described in Section 4.1.2.1 of 894 [I-D.ietf-ace-key-groupcomm]. 896 If the joining node has not taken exclusively the role of monitor, 897 the Group Manager performs also the following actions. 899 o The Group Manager selects an available OSCORE Sender ID in the 900 OSCORE group, and exclusively assigns it to the joining node. If 901 the joining node is recognized as a current group member, e.g. 902 through the ongoing secure communication association, the Group 903 Manager MUST assign a new Sender ID different than the one 904 currently used by the joining node in the OSCORE group. 906 Consistently with Section 3 of [I-D.ietf-core-oscore-groupcomm], 907 the Group Manager MUST assign a Sender ID that has never been 908 assigned before in the OSCORE group under the current Gid value. 910 The Group Manager MUST NOT assign a Sender ID to the joining node 911 if this joins the group exclusively with the role of monitor, 912 according to what specified in the Access Token (see Section 4.2). 914 o The Group Manager stores the association between i) the public key 915 of the joining node; and ii) the Group Identifier (Gid), i.e. the 916 OSCORE ID Context, associated to the OSCORE group together with 917 the OSCORE Sender ID assigned to the joining node in the group. 918 The Group Manager MUST keep this association updated over time. 920 Then, the Group Manager replies to the joining node, providing the 921 updated security parameters and keying meterial necessary to 922 participate in the group communication. This success Joining 923 Response is formatted as defined in Section 4.1.2.1 of 924 [I-D.ietf-ace-key-groupcomm], with the following additions: 926 o The 'gkty' parameter identifies a key of type 927 "Group_OSCORE_Input_Material object", defined in Section 21.2 of 928 this specification. 930 o The 'key' parameter includes what the joining node needs in order 931 to set up the Group OSCORE Security Context as per Section 2 of 932 [I-D.ietf-core-oscore-groupcomm]. 934 This parameter has as value a Group_OSCORE_Input_Material object, 935 which is defined in this specification and extends the 936 OSCORE_Input_Material object encoded in CBOR as defined in 937 Section 3.2.1 of [I-D.ietf-ace-oscore-profile]. In particular, it 938 contains the additional parameters 'group_senderId' 'cs_alg', 939 'cs_params', 'cs_key_params', 'cs_key_enc', 'ecdh_alg', 940 'ecdh_params' and 'ecdh_key_params' defined in Section 21.4 of 941 this specification. 943 More specifically, the 'key' parameter is composed as follows. 945 * The 'ms' parameter MUST be present and includes the OSCORE 946 Master Secret value used in the OSCORE group. 948 * The 'hkdf' parameter, if present, has as value the KDF 949 algorithm used in the OSCORE group. 951 * The 'alg' parameter, if present, has as value the AEAD 952 algorithm used in the OSCORE group. 954 * The 'salt' parameter, if present, has as value the OSCORE 955 Master Salt used in the OSCORE group. 957 * The 'contextId' parameter MUST be present and has as value the 958 Group Identifier (Gid), i.e. the OSCORE ID Context of the 959 OSCORE group. 961 * The 'group_senderId' parameter, if present, has as value the 962 OSCORE Sender ID assigned to the joining node by the Group 963 Manager, as described above. This parameter is not present if 964 the node joins the group exclusively with the role of monitor, 965 according to what specified in the Access Token (see 966 Section 4.2). In any other case, this parameter MUST be 967 present. 969 * The 'cs_alg' parameter MUST be present and specifies the 970 algorithm used to countersign messages in the OSCORE group. 971 This parameter takes values from the "Value" column of the 972 "COSE Algorithms" Registry [COSE.Algorithms]. 974 * The 'cs_params' parameter MAY be present and specifies the 975 parameters for the counter signature algorithm. This parameter 976 is a CBOR array, which includes the following two elements: 978 + 'sign_alg_capab', with the same encoding as defined in 979 Section 6.1. The value is the same as in the Token Post 980 response where the 'sign_parameters' value was non-null. 982 + 'sign_key_type_capab', with the same encoding as defined in 983 Section 6.1. The value is the same as in the Token Post 984 response where the 'sign_parameters' value was non-null. 986 * The 'cs_key_params' parameter MAY be present and specifies the 987 parameters for the key used with the counter signature 988 algorithm. This parameter is a CBOR array, with the same non- 989 null encoding and value as 'sign_key_parameters' of the 990 Section 6.1. 992 * The 'cs_key_enc' parameter MAY be present and specifies the 993 encoding of the public keys of the group members. This 994 parameter is a CBOR integer, whose value is 1 ("COSE_Key") 995 taken from the 'Confirmation Key' column of the "CWT 996 Confirmation Method" Registry [CWT.Confirmation.Methods], so 997 indicating that public keys in the OSCORE group are encoded as 998 COSE Keys [I-D.ietf-cose-rfc8152bis-struct]. Future 999 specifications may define additional values for this parameter. 1000 If this parameter is not present, 1 ("COSE_Key") MUST be 1001 assumed as default value. 1003 * The 'ecdh_alg' parameter, if present, specifies the ECDH 1004 algorithm used in the OSCORE group, if this supports the 1005 pairwise mode of Group OSCORE. This parameter takes values 1006 from the "Value" column of the "COSE Algorithms" Registry 1007 [COSE.Algorithms]. This parameter MUST be present if the 1008 OSCORE group supports the pairwise mode of Group OSCORE, and 1009 MUST NOT be present otherwise. 1011 * The 'ecdh_params' parameter, if present, specifies the 1012 parameters for the ECDH algorithm. It MUST be present if the 1013 'ecdh_alg' parameter is present, and MUST NOT be present 1014 otherwise. This parameter is a CBOR array, which includes the 1015 following two elements: 1017 + 'ecdh_alg_capab', with the same encoding as defined in 1018 Section 6.1.1. The value is the same as in the Token Post 1019 response where the ecdh_parameters' value is non-null. 1021 + 'ecdh_key_type_capab', with the same encoding as defined in 1022 Section 6.1.1. The value is the same as in the Token Post 1023 response where the 'ecdh_parameters' value is non-null. 1025 * The 'ecdh_key_params' parameter, if present, specifies the 1026 parameters for the key used with the ECDH algorithm. It MUST 1027 be present if the 'ecdh_alg' parameter is present, and MUST NOT 1028 be present otherwise. This parameter is a CBOR array, with the 1029 same non-null encoding and value of 'ecdh_key_parameters' 1030 defined in Section 6.1.1. 1032 o The 'exp' parameter MUST be present. 1034 o The 'ace-groupcomm-profile' parameter MUST be present and has 1035 value coap_group_oscore_app (TBD3), which is defined in 1036 Section 21.3 of this specification. 1038 o The 'pub_keys' parameter, if present, includes the public keys 1039 requested by the joining node by means of the 'get_pub_keys' 1040 parameter in the Joining Request. If public keys are encoded as 1041 COSE_Keys, each of them has as 'kid' the Sender ID that the 1042 corresponding owner has in the OSCORE group, thus used as group 1043 member identifier encoded as a CBOR byte string (REQ12). 1045 If the joining node has asked for the public keys of all the group 1046 members, i.e. 'get_pub_keys' had value Null in the Joining 1047 Request, then the Group Manager provides only the public keys of 1048 the group members that are relevant to the joining node. That is, 1049 in such a case, 'pub_keys' includes only: i) the public keys of 1050 the responders currently in the OSCORE group, in case the joining 1051 node is configured (also) as requester; and ii) the public keys of 1052 the requesters currently in the OSCORE group, in case the joining 1053 node is configured (also) as responder or monitor. 1055 o The 'group_policies' parameter SHOULD be present, and SHOULD 1056 include the following elements: 1058 * "Key Update Check Interval" defined in Section 4.1.2.1 of 1059 [I-D.ietf-ace-key-groupcomm], with default value 3600; 1061 * "Expiration Delta" defined in Section 4.1.2.1 of 1062 [I-D.ietf-ace-key-groupcomm], with default value 0. 1064 Finally, the joining node uses the information received in the 1065 Joining Response to set up the Group OSCORE Security Context, as 1066 described in Section 2 of [I-D.ietf-core-oscore-groupcomm]. In 1067 addition, the joining node maintains an association between each 1068 public key retrieved from the 'pub_keys' parameter and the role(s) 1069 that the corresponding group member has in the OSCORE group. 1071 From then on, the joining node can exchange group messages secured 1072 with Group OSCORE as described in [I-D.ietf-core-oscore-groupcomm]. 1073 When doing so: 1075 o The joining node MUST NOT process an incoming request message, if 1076 protected by a group member whose public key is not associated to 1077 the role "Requester". 1079 o The joining node MUST NOT process an incoming response message, if 1080 protected by a group member whose public key is not associated to 1081 the role "Responder". 1083 o The joining node MUST NOT use the pairwise mode of Group OSCORE to 1084 process messages in the group, if the Joining Response did not 1085 include the 'ecdh_alg' parameter. 1087 If the application requires backward security, the Group Manager MUST 1088 generate updated security parameters and group keying material, and 1089 provide it to the current group members upon the new node's joining 1090 (see Section 18). As a consequence, the joining node is not able to 1091 access secure communication in the OSCORE group occurred prior its 1092 joining. 1094 7. Public Keys of Joining Nodes 1096 Source authentication of a message sent within the group and 1097 protected with Group OSCORE is ensured by means of a digital counter 1098 signature embedded in the message (in group mode), or by integrity- 1099 protecting the message with pairwise keying material derived from the 1100 asymmetric keys of sender and recipient (in pairwise mode). 1102 Therefore, group members must be able to retrieve each other's public 1103 key from a trusted key repository, in order to verify source 1104 authenticity of incoming group messages. 1106 As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group 1107 Manager acts as trusted repository of the public keys of the group 1108 members, and provides those public keys to group members if requested 1109 to. Upon joining an OSCORE group, a joining node is thus expected to 1110 provide its own public key to the Group Manager. 1112 In particular, one of the following four cases can occur when a new 1113 node joins an OSCORE group. 1115 o The joining node is going to join the group exclusively as 1116 monitor. That is, it is not going to send messages to the group, 1117 and hence to produce signatures with its own private key. In this 1118 case, the joining node is not required to provide its own public 1119 key to the Group Manager, which thus does not have to perform any 1120 check related to the public key encoding, or to a countersignature 1121 algorithm and possible associated parameters for that joining 1122 node. In case that joining node still provides a public key in 1123 the 'client_cred' parameter of the Joining Request (see 1124 Section 6.2), the Group Manager silently ignores that parameter, 1125 as well as the related parameters 'cnonce' and 1126 'client_cred_verify'. 1128 o The Group Manager already acquired the public key of the joining 1129 node during a past joining process. In this case, the joining 1130 node MAY choose not to provide again its own public key to the 1131 Group Manager, in order to limit the size of the Joining Request. 1132 The joining node MUST provide its own public key again if it has 1133 provided the Group Manager with multiple public keys during past 1134 joining processes, intended for different OSCORE groups. If the 1135 joining node provides its own public key, the Group Manager 1136 performs consistency checks as per Section 6.3 and, in case of 1137 success, considers it as the public key associated to the joining 1138 node in the OSCORE group. 1140 o The joining node and the Group Manager use an asymmetric proof-of- 1141 possession key to establish a secure communication association. 1142 Then, two cases can occur. 1144 1. The proof-of-possession key is compatible with the encoding as 1145 well as with the counter signature algorithm and possible 1146 associated parameters used in the OSCORE group. Then, the 1147 Group Manager considers the proof-of-possession key as the 1148 public key associated to the joining node in the OSCORE group. 1149 If the joining node is aware that the proof-of-possession key 1150 is also valid for the OSCORE group, it MAY not provide it 1151 again as its own public key to the Group Manager. The joining 1152 node MUST provide its own public key again if it has provided 1153 the Group Manager with multiple public keys during past 1154 joining processes, intended for different OSCORE groups. If 1155 the joining node provides its own public key in the 1156 'client_cred' parameter of the Joining Request (see 1157 Section 6.2), the Group Manager performs consistency checks as 1158 per Section 6.3 and, in case of success, considers it as the 1159 public key associated to the joining node in the OSCORE group. 1161 2. The proof-of-possession key is not compatible with the 1162 encoding or with the counter signature algorithm and possible 1163 associated parameters used in the OSCORE group. In this case, 1164 the joining node MUST provide a different compatible public 1165 key to the Group Manager in the 'client_cred' parameter of the 1166 Joining Request (see Section 6.2). Then, the Group Manager 1167 performs consistency checks on this latest provided public key 1168 as per Section 6.3 and, in case of success, considers it as 1169 the public key associated to the joining node in the OSCORE 1170 group. 1172 o The joining node and the Group Manager use a symmetric proof-of- 1173 possession key to establish a secure communication association. 1174 In this case, upon performing a joining process with that Group 1175 Manager for the first time, the joining node specifies its own 1176 public key in the 'client_cred' parameter of the Joining Request 1177 targeting the group-membership endpoint (see Section 6.2). 1179 8. Retrieval of Updated Keying Material 1181 At some point, a group member considers the Group OSCORE Security 1182 Context invalid and to be renewed. This happens, for instance, after 1183 a number of unsuccessful security processing of incoming messages 1184 from other group members, or when the Security Context expires as 1185 specified by the 'exp' parameter of the Joining Response. 1187 When this happens, the group member retrieves updated security 1188 parameters and group keying material. This can occur in the two 1189 different ways described below. 1191 8.1. Retrieval of Group Keying Material 1193 If the group member wants to retrieve only the latest group keying 1194 material, it sends a Key Distribution Request to the Group Manager. 1196 In particular, it sends a CoAP GET request to the endpoint /ace- 1197 group/GROUPNAME at the Group Manager. 1199 The Group Manager processes the Key Distribution Request according to 1200 Section 4.1.2.2 of [I-D.ietf-ace-key-groupcomm]. The Key 1201 Distribution Response is formatted as defined in Section 4.1.2.2 of 1202 [I-D.ietf-ace-key-groupcomm]. In addition: 1204 o The 'key' parameter is formatted as defined in Section 6.4 of this 1205 specification, with the difference that it does not include the 1206 'group_SenderId' parameter. 1208 o The 'exp' parameter MUST be present. 1210 o The 'ace-groupcomm-profile' parameter MUST be present and has 1211 value coap_group_oscore_app. 1213 Upon receiving the Key Distribution Response, the group member 1214 retrieves the updated security parameters and group keying material, 1215 and, if they differ from the current ones, uses them to set up the 1216 new Group OSCORE Security Context as described in Section 2 of 1217 [I-D.ietf-core-oscore-groupcomm]. 1219 8.2. Retrieval of Group Keying Material and Sender ID 1221 If the group member wants to retrieve the latest group keying 1222 material as well as the Sender ID that it has in the OSCORE group, it 1223 sends a Key Distribution Request to the Group Manager. 1225 In particular, it sends a CoAP GET request to the endpoint /ace- 1226 group/GROUPNAME/nodes/NODENAME at the Group Manager. 1228 The Group Manager processes the Key Distribution Request according to 1229 Section 4.1.6.2 of [I-D.ietf-ace-key-groupcomm]. The Key 1230 Distribution Response is formatted as defined in Section 4.1.6.2 of 1231 [I-D.ietf-ace-key-groupcomm]. In addition: 1233 o The 'key' parameter is formatted as defined in Section 6.4 of this 1234 specification. In particular, if the requesting group member has 1235 exclusively the role of monitor, no 'group_SenderId' is specified 1236 within the 'key' parameter. 1238 Note that, in any other case, the current Sender ID of the group 1239 member is not specified as a separate parameter, but rather 1240 specified as 'group_SenderId' within the 'key' parameter. 1242 o The 'exp' parameter MUST be present. 1244 Upon receiving the Key Distribution Response, the group member 1245 retrieves the updated security parameters, group keying material and 1246 Sender ID, and, if they differ from the current ones, uses them to 1247 set up the new Group OSCORE Security Context as described in 1248 Section 2 of [I-D.ietf-core-oscore-groupcomm]. 1250 9. Requesting a Change of Keying Material 1252 As discussed in Section 2.4.2 of [I-D.ietf-core-oscore-groupcomm], a 1253 group member may at some point exhaust its Sender Sequence Numbers in 1254 the OSCORE group. 1256 When this happens, the group member MUST send a Key Renewal Request 1257 message to the Group Manager, as per Section 4.5 of 1258 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP PUT 1259 request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME at the 1260 Group Manager. 1262 Upon receiving the Key Renewal Request, the Group Manager processes 1263 it as defined in Section 4.1.6.1 of [I-D.ietf-ace-key-groupcomm], 1264 with the following additions. 1266 The Group Manager MUST return a 5.03 (Service Unavailable) response 1267 in case the OSCORE group identified by GROUPNAME is currently 1268 inactive (see Section 5.1). The response MUST have Content-Format 1269 set to application/ace-groupcomm+cbor and is formatted as defined in 1270 Section 4 of [I-D.ietf-ace-key-groupcomm]. The value of the 'error' 1271 field MUST be set to 7 ("Group currently not active"). 1273 Otherwise, the Group Manager performs one of the following actions. 1275 1. If the requesting group member has exclusively the role of 1276 monitor, the Group Manager replies with a 4.00 (Unauthorized) 1277 error response. The response MUST have Content-Format set to 1278 application/ace-groupcomm+cbor and is formatted as defined in 1279 Section 4 of [I-D.ietf-ace-key-groupcomm]. The value of the 1280 'error' field MUST be set to 1 ("Request inconsistent with the 1281 current roles"). 1283 2. Otherwise, the Group Manager takes one of the following actions. 1285 * The Group Manager rekeys the OSCORE group. That is, the Group 1286 Manager generates new group keying material for that group 1287 (see Section 18), and replies to the group member with a group 1288 rekeying message as defined in Section 18, providing the new 1289 group keying material. Then, the Group Manager rekeys the 1290 rest of the OSCORE group, as discussed in Section 18. 1292 The Group Manager SHOULD perform a group rekeying only if 1293 already scheduled to occur shortly, e.g. according to an 1294 application-dependent rekeying period, or as a reaction to a 1295 recent change in the group membership. In any other case, the 1296 Group Manager SHOULD NOT rekey the OSCORE group when receiving 1297 a Key Renewal Request (OPT9). 1299 * The Group Manager determines and assigns a new Sender ID for 1300 that group member, and replies with a Key Renewal Response 1301 formatted as defined in Section 4.1.6.1 of 1302 [I-D.ietf-ace-key-groupcomm]. In particular, the CBOR Map in 1303 the response payload includes a single parameter 1304 'group_SenderId' defined in Section 21.1 of this document, 1305 specifying the new Sender ID of the group member encoded as a 1306 CBOR byte string. 1308 Consistently with Section 2.4.3.1 of 1309 [I-D.ietf-core-oscore-groupcomm], the Group Manager MUST 1310 assign a new Sender ID that has never been assigned before in 1311 the OSCORE group under the current Gid value. 1313 The Group Manager MUST return a 5.03 (Service Unavailable) 1314 response in case there are currently no Sender IDs available 1315 to assign in the OSCORE group. The response MUST have 1316 Content-Format set to application/ace-groupcomm+cbor and is 1317 formatted as defined in Section 4 of 1318 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field 1319 MUST be set to 4 ("No available node identifiers"). 1321 10. Retrieval of Public Keys and Roles for Group Members 1323 A group member or a signature verifier may need to retrieve the 1324 public keys of (other) group members. To this end, the group member 1325 or signature verifier sends a Public Key Request message to the Group 1326 Manager, as per Section 4.6 of [I-D.ietf-ace-key-groupcomm]. In 1327 particular, it sends the request to the endpoint /ace- 1328 group/GROUPNAME/pub-key at the Group Manager. 1330 If the Public Key Request uses the method FETCH, the Public Key 1331 Request is formatted as defined in Section 4.1.3.1 of 1332 [I-D.ietf-ace-key-groupcomm]. In particular: 1334 o Each element (if any) of the inner CBOR array 'role_filter' is 1335 formatted as in the inner CBOR array 'role_filter' of the 1336 'get_pub_keys' parameter of the Joining Request when the parameter 1337 value is non-null (see Section 6.2). 1339 o Each element (if any) of the inner CBOR array 'id_filter' is a 1340 CBOR byte string (REQ12), which encodes the Sender ID of the group 1341 member for which the associated public key is requested. 1343 Upon receiving the Public Key Request, the Group Manager processes it 1344 as per Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm], 1345 depending on the request method being FETCH or GET, respectively. 1346 Additionally, if the Public Key Request uses the method FETCH, the 1347 Group Manager silently ignores node identifiers included in the 1348 'get_pub_keys' parameter of the request that are not associated to 1349 any current group member. 1351 The success Public Key Response is formatted as defined in 1352 Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm], depending 1353 on the request method being FETCH or GET, respectively. 1355 11. Update of Public Key 1357 A group member may need to provide the Group Manager with its new 1358 public key to use in the group from then on, hence replacing the 1359 current one. This can be the case, for instance, if the 1360 countersignature algorithm and possible associated parameters used in 1361 the OSCORE group have been changed, and the current public key is not 1362 compatible with them. 1364 To this end, the group member sends a Public Key Update Request 1365 message to the Group Manager, as per Section 4.7 of 1366 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP POST 1367 request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME/pub-key 1368 at the Group Manager. 1370 Upon receiving the Public Key Update Request, the Group Manager 1371 processes it as per Section 4.1.7.1 of [I-D.ietf-ace-key-groupcomm], 1372 with the following additions. 1374 o The Group Manager MUST return a 5.03 (Service Unavailable) 1375 response in case the OSCORE group identified by GROUPNAME is 1376 currently inactive (see Section 5.1). The response MUST have 1377 Content-Format set to application/ace-groupcomm+cbor and is 1378 formatted as defined in Section 4 of [I-D.ietf-ace-key-groupcomm]. 1379 The value of the 'error' field MUST be set to 7 ("Group currently 1380 not active"). 1382 o If the requesting group member has exclusively the role of 1383 monitor, the Group Manager replies with a 4.00 (Bad request) error 1384 response. The response MUST have Content-Format set to 1385 application/ace-groupcomm+cbor and is formatted as defined in 1386 Section 4 of [I-D.ietf-ace-key-groupcomm]. The value of the 1387 'error' field MUST be set to 1 ("Request inconsistent with the 1388 current roles"). 1390 o The N_S signature challenge is computed as per point (1) in 1391 Section 6.2.1 (REQ20). 1393 o If the request is successfully processed, the Group Manager stores 1394 the association between i) the new public key of the group member; 1395 and ii) the Group Identifier (Gid), i.e. the OSCORE ID Context, 1396 associated to the OSCORE group together with the OSCORE Sender ID 1397 assigned to the group member in the group. The Group Manager MUST 1398 keep this association updated over time. 1400 12. Retrieval of Group Policies 1402 A group member may request the current policies used in the OSCORE 1403 group. To this end, the group member sends a Policies Request, as 1404 per Section 4.8 of [I-D.ietf-ace-key-groupcomm]. In particular, it 1405 sends a CoAP GET request to the endpoint /ace-group/GROUPNAME/ 1406 policies at the Group Manager, where GROUPNAME is the name of the 1407 OSCORE group. 1409 Upon receiving the Policies Request, the Group Manager processes it 1410 as per Section 4.1.4.1 of [I-D.ietf-ace-key-groupcomm]. The success 1411 Policies Response is formatted as defined in Section 4.1.4.1 of 1412 [I-D.ietf-ace-key-groupcomm]. 1414 13. Retrieval of Keying Material Version 1416 A group member may request the current version of the keying material 1417 used in the OSCORE group. To this end, the group member sends a 1418 Version Request, as per Section 4.9 of [I-D.ietf-ace-key-groupcomm]. 1419 In particular, it sends a CoAP GET request to the endpoint /ace- 1420 group/GROUPNAME/num at the Group Manager, where GROUPNAME is the name 1421 of the OSCORE group. 1423 Upon receiving the Version Request, the Group Manager processes it as 1424 per Section 4.1.5.1 of [I-D.ietf-ace-key-groupcomm]. The success 1425 Version Response is formatted as defined in Section 4.1.5.1 of 1426 [I-D.ietf-ace-key-groupcomm]. 1428 14. Retrieval of Group Status 1430 A group member may request the current status of the the OSCORE 1431 group, i.e. active or inactive. To this end, the group member sends 1432 a Group Status Request to the Group Manager. 1434 In particular, the group member sends a CoAP GET request to the 1435 endpoint /ace-group/GROUPNAME/active at the Group Manager defined in 1436 Section 5.1 of this specification, where GROUPNAME is the name of the 1437 OSCORE group. The success Group Version Response is formatted as 1438 defined in Section 5.1 of this specification. 1440 Upon learning from a 2.05 (Content) response that the group is 1441 currently inactive, the group member SHOULD stop taking part in 1442 communications within the group, until it becomes active again. 1444 Upon learning from a 2.05 (Content) response that the group has 1445 become active again, the group member can resume taking part in 1446 communications within the group. 1448 Figure 3 gives an overview of the exchange described above. 1450 Group Group 1451 Member Manager 1452 | | 1453 |--- Group Status Request: GET ace-group/GROUPNAME/active --->| 1454 | | 1455 |<---------- Group Status Response: 2.05 (Content) -----------| 1456 | | 1458 Figure 3: Message Flow of Group Status Request-Response 1460 15. Retrieval of Group Names and URIs 1462 A node may want to retrieve from the Group Manager the group name and 1463 the URI of the group-membership resource of a group. This is 1464 relevant in the following cases. 1466 o Before joining a group, a joining node may know only the current 1467 Group Identifier (Gid) of that group, but not the group name and 1468 the URI to the group-membership resource. 1470 o As current group member in several groups, the node has missed a 1471 previous group rekeying in one of them (see Section 18). Hence, 1472 it retains stale keying material and fails to decrypt received 1473 messages exchanged in that group. 1475 Such messages do not provide a direct hint to the correct group 1476 name, that the node would need in order to retrieve the latest 1477 keying material and public keys from the Group Manager (see 1478 Section 8.1, Section 8.2 and Section 10). However, such messages 1479 may specify the current Gid of the group, as value of the 1480 'kid_context' field of the OSCORE CoAP option (see Section 6.1 of 1481 [RFC8613] and Section 4.2 of [I-D.ietf-core-oscore-groupcomm]). 1483 o As signature verifier, the node also refers to a group name for 1484 retrieving the required public keys from the Group Manager (see 1485 Section 10). As discussed above, intercepted messages do not 1486 provide a direct hint to the correct group name, while they may 1487 specify the current Gid of the group, as value of the 1488 'kid_context' field of the OSCORE CoAP option. In such a case, 1489 upon intercepting a message in the group, the node requires to 1490 correctly map the Gid currently used in the group with the 1491 invariant group name. 1493 Furthermore, since it is not a group member, the node does not 1494 take part to a possible group rekeying. Thus, following a group 1495 rekeying and the consequent change of Gid in a group, the node 1496 would retain the old Gid value and cannot correctly associate 1497 intercepted messages to the right group, especially if acting as 1498 signature verifier in several groups. This in turn prevents the 1499 efficient verification of counter signatures, and especially the 1500 retrieval of required, new public keys from the Group Manager. 1502 In either case, the node only knows the current Gid of the group, as 1503 learned from received or intercepted messages exchanged in the group. 1504 As detailed below, the node can contact the Group Manager, and 1505 request the group name and URI to the group-membership resource 1506 corresponding to that Gid. Then, it can use that information to 1507 either join the group as a candidate group member, get the latest 1508 keying material as a current group member, or retrieve public keys 1509 used in the group as a signature verifier. To this end, the node 1510 sends a Group Name and URI Retrieval Request, as per Section 4.2 of 1511 [I-D.ietf-ace-key-groupcomm]. 1513 In particular, the node sends a CoAP FETCH request to the endpoint 1514 /ace-group at the Group Manager formatted as defined in 1515 Section 4.1.1.1 of [I-D.ietf-ace-key-groupcomm]. Each element of the 1516 CBOR array 'gid' is a CBOR byte string (REQ9), which encodes the Gid 1517 of the group for which the group name and the URI to the group- 1518 membership resource are requested. 1520 Upon receiving the Group Name and URI Retrieval Request, the Group 1521 Manager processes it as per Section 4.1.1.1 of 1522 [I-D.ietf-ace-key-groupcomm]. The success Group Name and URI 1523 Retrieval Response is formatted as defined in Section 4.1.1.1 of 1524 [I-D.ietf-ace-key-groupcomm]. In particular, each element of the 1525 CBOR array 'gid' is a CBOR byte string (REQ9), which encodes the Gid 1526 of the group for which the group name and the URI to the group- 1527 membership resource are provided. 1529 For each of its groups, the Group Manager maintains an association 1530 between the group name and the URI to the group-membership resource 1531 on one hand, and only the current Gid for that group on the other 1532 hand. That is, the Group Manager MUST NOT maintain an association 1533 between the former pair and any other Gid for that group than the 1534 current, most recent one. 1536 Figure 4 gives an overview of the exchanges described above. 1538 Group 1539 Node Manager 1540 | | 1541 |---- Group Name and URI Retrieval Request: FETCH ace-group/ --->| 1542 | | 1543 |<--- Group Name and URI Retrieval Response: 2.05 (Content) -----| 1544 | | 1546 Figure 4: Message Flow of Group Name and URI Retrieval Request- 1547 Response 1549 16. Request to Leave the Group 1551 A group member may request to leave the OSCORE group. To this end, 1552 the group member sends a Group Leaving Request, as per Section 4.10 1553 of [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP 1554 DELETE request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME at 1555 the Group Manager. 1557 Upon receiving the Group Leaving Request, the Group Manager processes 1558 it as per Section 4.1.6.3 of [I-D.ietf-ace-key-groupcomm]. 1560 17. Removal of a Group Member 1562 Other than after a spontaneous request to the Group Manager as 1563 described in Section 16, a node may be forcibly removed from the 1564 OSCORE group, e.g. due to expired or revoked authorization. 1566 If any of the two conditions below holds, the Group Manager MUST 1567 inform the leaving node of its eviction as follows. If both 1568 conditions hold, the Group Manager MUST inform the leaving node only 1569 once, using either of the corresponding methods. 1571 o If, upon joining the group (see Section 6.2), the leaving node 1572 specified a URI in the 'control_uri' parameter defined in 1573 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm], the Group Manager 1574 sends a DELETE request targeting the URI specified in the 1575 'control_uri' parameter (OPT10). 1577 o If the leaving node has been observing the associated resource at 1578 ace-group/GROUPNAME/nodes/NODENAME, the Group Manager sends an 1579 unsolicited 4.04 (Not Found) response to the leaving node, as 1580 specified in 4.1.6.2 of [I-D.ietf-ace-key-groupcomm]. 1582 If the leaving node has not exclusively the role of monitor, the 1583 Group Manager performs the following actions. 1585 o The Group Manager frees the OSCORE Sender ID value of the leaving 1586 node. However, this value MUST NOT become available for possible 1587 upcoming joining nodes in the same group. 1589 o The Group Manager cancels the association between, on one hand, 1590 the public key of the leaving node and, on the other hand, the 1591 Group Identifier (Gid) associated to the OSCORE group together 1592 with the freed OSCORE Sender ID value. The Group Manager deletes 1593 the public key of the leaving node, if that public key has no 1594 remaining association with any pair (Gid, Sender ID). 1596 If the application requires forward security, the Group Manager MUST 1597 generate updated security parameters and group keying material, and 1598 provide it to the remaining group members (see Section 18). As a 1599 consequence, the leaving node is not able to acquire the new security 1600 parameters and group keying material distributed after its leaving. 1602 Same considerations in Section 5 of [I-D.ietf-ace-key-groupcomm] 1603 apply here as well, considering the Group Manager acting as KDC. 1605 18. Group Rekeying Process 1607 In order to rekey the OSCORE group, the Group Manager distributes a 1608 new Group Identifier (Gid), i.e. a new OSCORE ID Context; a new 1609 OSCORE Master Secret; and, optionally, a new OSCORE Master Salt for 1610 that group. When doing so, the Group Manager MUST increment the 1611 version number of the group keying material, before starting its 1612 distribution. 1614 Consistently with Section 2.3 of [I-D.ietf-core-oscore-groupcomm], 1615 the Group Manager MUST assign a Gid that has never been assigned 1616 before to the OSCORE group. 1618 Furthermore, the Group Manager MUST preserve the same unchanged 1619 Sender IDs for all group members. This avoids affecting the 1620 retrieval of public keys from the Group Manager as well as the 1621 verification of group messages. 1623 The Group Manager MUST support at least the following group rekeying 1624 scheme. Future application profiles may define alternative message 1625 formats and distribution schemes. 1627 As group rekeying message, the Group Manager uses the same format of 1628 the Joining Response message in Section 6.4. In particular: 1630 o Only the parameters 'gkty', 'key', 'num', 'ace-groupcomm-profile' 1631 and 'exp' are present. 1633 o The 'ms' parameter of the 'key' parameter specifies the new OSCORE 1634 Master Secret value. 1636 o The 'contextId' parameter of the 'key' parameter specifies the new 1637 Gid used as OSCORE ID Context value. 1639 The Group Manager separately sends a group rekeying message to each 1640 group member to be rekeyed. 1642 Each rekeying message MUST be secured with the pairwise secure 1643 communication channel between the Group Manager and the group member 1644 used during the joining process. In particular, each rekeying 1645 message can target the 'control_uri' URI path defined in 1646 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm] (OPT10), if provided 1647 by the intended recipient upon joining the group (see Section 6.2). 1649 It is RECOMMENDED that the Group Manager gets confirmation of 1650 successful distribution from the group members, and admits a maximum 1651 number of individual retransmissions to non-confirming group members. 1653 This approach requires group members to act (also) as servers, in 1654 order to correctly handle unsolicited group rekeying messages from 1655 the Group Manager. In particular, if a group member and the Group 1656 Manager use OSCORE [RFC8613] to secure their pairwise communications, 1657 the group member MUST create a Replay Window in its own Recipient 1658 Context upon establishing the OSCORE Security Context with the Group 1659 Manager, e.g. by means of the OSCORE profile of ACE 1660 [I-D.ietf-ace-oscore-profile]. 1662 Group members and the Group Manager SHOULD additionally support 1663 alternative rekeying approaches that do not require group members to 1664 act (also) as servers. A number of such approaches are defined in 1665 Section 4.4 of [I-D.ietf-ace-key-groupcomm]. In particular, a group 1666 member may subscribe for updates to the group-membership resource of 1667 the group, at the endpoint /ace-group/GROUPNAME/ of the Group 1668 Manager. This can rely on CoAP Observe [RFC7641] or on a full- 1669 fledged Pub-Sub model [I-D.ietf-core-coap-pubsub] with the Group 1670 Manager acting as Broker. 1672 In case the rekeying terminates and some group members have not 1673 received the new keying material, they will not be able to correctly 1674 process following secured messages exchanged in the group. These 1675 group members will eventually contact the Group Manager, in order to 1676 retrieve the current keying material and its version. 1678 Some of these group members may be in multiple groups, each 1679 associated to a different Group Manager. When failing to correctly 1680 process messages secured with the new keying material, these group 1681 members may not have sufficient information to determine which exact 1682 Group Manager they should contact, in order to retrieve the current 1683 keying material they are missing. 1685 If the Gid is formatted as described in Appendix C of 1686 [I-D.ietf-core-oscore-groupcomm], the Group Prefix can be used as a 1687 hint to determine the right Group Manager, as long as no collisions 1688 among Group Prefixes are experienced. Otherwise, a group member 1689 needs to contact the Group Manager of each group, e.g. by first 1690 requesting only the version of the current group keying material (see 1691 Section 13) and then possibly requesting the current keying material 1692 (see Section 8.1). 1694 Furthermore, some of these group members can be in multiple groups, 1695 all of which associated to the same Group Manager. In this case, 1696 these group members may also not have sufficient information to 1697 determine which exact group they should refer to, when contacting the 1698 right Group Manager. Hence, they need to contact a Group Manager 1699 multiple times, i.e. separately for each group they belong to and 1700 associated to that Group Manager. 1702 19. Default Values for Group Configuration Parameters 1704 This section defines the default values that the Group Manager 1705 assumes for the configuration parameters of an OSCORE group, unless 1706 differently specified when creating and configuring the group. This 1707 can be achieved as specified in [I-D.ietf-ace-oscore-gm-admin]. 1709 The Group Manager SHOULD use the same default values defined in 1710 Section 3.2 of [RFC8613] for both the HKDF algorithm and the AEAD 1711 algorithm used in the group. 1713 The Group Manager SHOULD use the following default values for the 1714 algorithm, algorithm parameters and key parameters used to 1715 countersign messages in the group, consistently with the "COSE 1716 Algorithms" Registry [COSE.Algorithms], the "COSE Key Types" Registry 1717 [COSE.Key.Types] and the "COSE Elliptic Curves" Registry 1718 [COSE.Elliptic.Curves]. 1720 o For the algorithm 'cs_alg' used to countersign messages in the 1721 group, the signature algorithm EdDSA [RFC8032]. 1723 o For the parameters 'cs_params' of the counter signature algorithm: 1725 * The array [[OKP], [OKP, Ed25519]], indicating the elliptic 1726 curve Ed25519 [RFC8032], in case EdDSA is assumed or specified 1727 for 'cs_alg'. 1729 * The array [[EC2], [EC2, P-256]], indicating the elliptic curve 1730 P-256, in case ES256 [RFC6979] is specified for 'cs_alg'. 1732 * The array [[EC2], [EC2, P-384]], indicating the elliptic curve 1733 P-384, in case ES384 [RFC6979] is specified for 'cs_alg'. 1735 * The array [[EC2], [EC2, P-521]], indicating the elliptic curve 1736 P-521, in case ES512 [RFC6979] is specified for 'cs_alg'. 1738 * The array [[RSA], [RSA]], in case PS256, PS384 or PS512 1739 [RFC8017] is specified for 'cs_alg'. 1741 o For the parameters 'cs_key_params' of the key used with the 1742 counter signature algorithm: 1744 * The array [OKP, Ed25519] as pair (key type, elliptic curve), in 1745 case EdDSA is assumed or specified for 'cs_alg' and Ed25519 is 1746 assumed or specified within the second array of 'cs_params'. 1748 * The array [OKP, Ed448] as pair (key type, elliptic curve), in 1749 case EdDSA is assumed or specified for 'cs_alg' and the 1750 elliptic curve Ed448 [RFC8032] is specified within the second 1751 array of 'cs_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 'cs_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 'cs_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 'cs_params'. 1768 * The array [RSA] indicating RSA as key type, in case PS256, 1769 PS384 or PS512 [RFC8017] is specified for 'cs_alg'. 1771 o For the 'cs_key_enc' encoding of the public keys of the group 1772 members, COSE_Key from the "CWT Confirmation Methods" Registry 1773 [CWT.Confirmation.Methods]. 1775 If the group supports the pairwise mode of Group OSCORE, the Group 1776 Manager SHOULD use the following default values for the algorithm, 1777 algorithm parameters and key parameters used to compute static-static 1778 Diffie-Hellman shared secrets, consistently with the "COSE 1779 Algorithms" Registry [COSE.Algorithms], the "COSE Key Types" Registry 1780 [COSE.Key.Types] and the "COSE Elliptic Curves" Registry 1781 [COSE.Elliptic.Curves]. 1783 o For the algorithm 'ecdh_alg' used to compute static-static Diffie- 1784 Hellman shared secrets, the ECDH algorithm ECDH-SS + HKDF-256 1785 specified in Section 6.3.1 of [I-D.ietf-cose-rfc8152bis-algs]. 1787 o For the parameters 'ecdh_params' of the ECDH algorithm: 1789 * The array [[OKP], [OKP, X25519]], indicating the elliptic curve 1790 X25519 [RFC8032], in case EdDSA is assumed or specified for 1791 'cs_alg'. 1793 * The array [[EC2], [EC2, P-256]], indicating the elliptic curve 1794 P-256, in case ES256 [RFC6979] is specified for 'cs_alg'. 1796 * The array [[EC2], [EC2, P-384]], indicating the elliptic curve 1797 P-384, in case ES384 [RFC6979] is specified for 'cs_alg'. 1799 * The array [[EC2], [EC2, P-521]], indicating the elliptic curve 1800 P-521, in case ES512 [RFC6979] is specified for 'cs_alg'. 1802 o For the parameters 'ecdh_key_params' of the key used with the ECDH 1803 algorithm: 1805 * The array [OKP, X25519] as pair (key type, elliptic curve), in 1806 case EdDSA is assumed or specified for 'cs_alg' and X25519 is 1807 assumed or specified within the second array of 'ecdh_params'. 1809 * The array [OKP, X448] as pair (key type, elliptic curve), in 1810 case EdDSA is assumed or specified for 'cs_alg' and the 1811 elliptic curve X448 [RFC8032] is specified within the second 1812 array of 'ecdh_params'. 1814 * The array [EC2, P-256] as pair (key type, elliptic curve), in 1815 case ES256 [RFC6979] is specified for 'cs_alg' and the elliptic 1816 curve P-256 is assumed or specified within the second array of 1817 'ecdh_params'. 1819 * The array [EC2, P-384] as pair (key type, elliptic curve), in 1820 case ES384 [RFC6979] is specified for 'cs_alg' and the elliptic 1821 curve P-384 is specified within the second array of 1822 'ecdh_params'. 1824 * The array [EC2, P-521] as pair (key type, elliptic curve), in 1825 case ES512 [RFC6979] is specified for 'cs_alg' and the elliptic 1826 curve P-521 is specified within the second array of 1827 'ecdh_params'. 1829 20. Security Considerations 1831 Security considerations for this profile are inherited from 1832 [I-D.ietf-ace-key-groupcomm], the ACE framework for Authentication 1833 and Authorization [I-D.ietf-ace-oauth-authz], and the specific 1834 transport profile of ACE signalled by the AS, such as 1835 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile]. 1837 The following security considerations also apply for this profile. 1839 20.1. Management of OSCORE Groups 1841 This profile leverages the following management aspects related to 1842 OSCORE groups and discussed in the sections of 1843 [I-D.ietf-core-oscore-groupcomm] referred below. 1845 o Management of group keying material (see Section 3.1 of 1846 [I-D.ietf-core-oscore-groupcomm]). The Group Manager is 1847 responsible for the renewal and re-distribution of the keying 1848 material in the groups of its competence (rekeying). According to 1849 the specific application requirements, this can include rekeying 1850 the group upon changes in its membership. In particular, renewing 1851 the group keying material is required upon a new node's joining or 1852 a current node's leaving, in case backward security and forward 1853 security have to be preserved, respectively. 1855 o Provisioning and retrieval of public keys (see Section 2 of 1856 [I-D.ietf-core-oscore-groupcomm]). The Group Manager acts as key 1857 repository of public keys of group members, and provides them upon 1858 request. 1860 o Synchronization of sequence numbers (see Section 6.2 of 1861 [I-D.ietf-core-oscore-groupcomm]). This concerns how a responder 1862 node that has just joined an OSCORE group can synchronize with the 1863 sequence number of requesters in the same group. 1865 Before sending the Joining Response, the Group Manager MUST verify 1866 that the joining node actually owns the associated private key. To 1867 this end, the Group Manager can rely on the proof-of-possession 1868 challenge-response defined in Section 6. Alternatively, the joining 1869 node can use its own public key as asymmetric proof-of-possession key 1870 to establish a secure channel with the Group Manager, e.g. as in 1871 Section 3.2.2 of [I-D.ietf-ace-dtls-authorize]. However, this 1872 requires such proof-of-possession key to be compatible with the 1873 encoding as well as with the countersignature algorithm and possible 1874 associated parameters used in the OSCORE group. 1876 A node may have joined multiple OSCORE groups under different non- 1877 synchronized Group Managers. Therefore, it can happen that those 1878 OSCORE groups have the same Group Identifier (Gid). It follows that, 1879 upon receiving a Group OSCORE message addressed to one of those 1880 groups, the node would have multiple Security Contexts matching with 1881 the Gid in the incoming message. It is up to the application to 1882 decide how to handle such collisions of Group Identifiers, e.g. by 1883 trying to process the incoming message using one Security Context at 1884 the time until the right one is found. 1886 20.2. Size of Nonces for Signature Challenge 1888 With reference to the Joining Request message in Section 6.2, the 1889 proof-of-possession signature included in 'client_cred_verify' is 1890 computed over the challenge N_C | N_S, where | denotes concatenation. 1892 For the N_C challenge share, it is RECOMMENDED to use a 8-byte long 1893 random nonce. Furthermore, N_C is always conveyed in the 'cnonce' 1894 parameter of the Joining Request, which is always sent over the 1895 secure communication channel between the joining node and the Group 1896 Manager. 1898 As defined in Section 6.2.1, the way the N_S value is computed 1899 depends on the particular way the joining node provides the Group 1900 Manager with the Access Token, as well as on following interactions 1901 between the two. 1903 o If the Access Token is not explicitly posted to the /authz-info 1904 endpoint of the Group Manager, then N_S is computed as a 32-byte 1905 long challenge share. For an example, see point (2) of 1906 Section 6.2.1. 1908 o If the Access Token has been explicitly posted to the /authz-info 1909 endpoint of the Group Manager, N_S takes the most recent value 1910 provided to the client by the Group Manager in the 'kdcchallenge' 1911 parameter, as specified in point (1) of Section 6.2.1. This is 1912 provided either in the 2.01 response to the Token Post (see 1913 Section 6.1), or in a 4.00 response to a following Joining Request 1914 (see Section 6.3). In either case, it is RECOMMENDED to use a 1915 8-byte long random challenge as value for N_S. 1917 If we consider both N_C and N_S to take 8-byte long values, the 1918 following considerations hold. 1920 o Let us consider both N_C and N_S as taking random values, and the 1921 Group Manager to never change the value of the N_S provided to a 1922 Client during the lifetime of an Access Token. Then, as per the 1923 birthday paradox, the average collision for N_S will happen after 1924 2^32 new posted Access Tokens, while the average collision for N_C 1925 will happen after 2^32 new Joining Requests. This amounts to 1926 considerably more token provisionings than the expected new 1927 joinings of OSCORE groups under a same Group Manager, as well as 1928 to considerably more requests to join OSCORE groups from a same 1929 Client using a same Access Token under a same Group Manager. 1931 o Section 7 of [I-D.ietf-ace-oscore-profile] as well Appendix B.2 of 1932 [RFC8613] recommend the use of 8-byte random values as well. 1933 Unlike in those cases, the values of N_C and N_S considered in 1934 this specification are not used for as sensitive operations as the 1935 derivation of a Security Context, and thus do not have possible 1936 implications in the security of AEAD ciphers. 1938 20.3. Reusage of Nonces for Signature Challenge 1940 As long as the Group Manager preserves the same N_S value currently 1941 associated to an Access Token, i.e. the latest value provided to a 1942 Client in a 'kdcchallenge' parameter, the Client is able to 1943 successfully reuse the same signature challenge for multiple Joining 1944 Requests to that Group Manager. 1946 In particular, the Client can reuse the same N_C value for every 1947 Joining Request to the Group Manager, and combine it with the same 1948 unchanged N_S value. This results in reusing the same signature 1949 challenge for producing the signature to include in the 1950 'client_cred_verify' parameter of the Joining Requests. 1952 Unless the Group Manager maintains a list of N_C values already used 1953 by that Client since the latest update to the N_S value associated to 1954 the Access Token, the Group Manager can be forced to falsely believe 1955 that the Client possesses its own private key at that point in time, 1956 upon verifying the signature in the 'client_cred_verify' parameter. 1958 21. IANA Considerations 1960 Note to RFC Editor: Please replace all occurrences of "[[This 1961 specification]]" with the RFC number of this specification and delete 1962 this paragraph. 1964 This document has the following actions for IANA. 1966 21.1. ACE Groupcomm Parameters Registry 1968 IANA is asked to register the following entry to the "ACE Groupcomm 1969 Parameters" Registry defined in Section 10.5 of 1970 [I-D.ietf-ace-key-groupcomm]. 1972 o Name: group_senderId 1974 o CBOR Key: TBD1 1976 o CBOR Type: Byte string 1978 o Reference: [[This specification]] (Section 9) 1980 21.2. ACE Groupcomm Key Registry 1982 IANA is asked to register the following entry to the "ACE Groupcomm 1983 Key" Registry defined in Section 10.6 of 1984 [I-D.ietf-ace-key-groupcomm]. 1986 o Name: Group_OSCORE_Input_Material object 1988 o Key Type Value: TBD2 1990 o Profile: "coap_group_oscore_app", defined in Section 21.3 of this 1991 specification. 1993 o Description: A Group_OSCORE_Input_Material object encoded as 1994 described in Section 6.4 of this specification. 1996 o Reference: [[This specification]] (Section 6.4) 1998 21.3. ACE Groupcomm Profile Registry 2000 IANA is asked to register the following entry to the "ACE Groupcomm 2001 Profile" Registry defined in Section 10.7 of 2002 [I-D.ietf-ace-key-groupcomm]. 2004 o Name: coap_group_oscore_app 2006 o Description: Application profile to provision keying material for 2007 participating in group communication protected with Group OSCORE 2008 as per [I-D.ietf-core-oscore-groupcomm]. 2010 o CBOR Value: TBD3 2012 o Reference: [[This specification]] (Section 6.4) 2014 21.4. OSCORE Security Context Parameters Registry 2016 IANA is asked to register the following entries in the "OSCORE 2017 Security Context Parameters" Registry defined in Section 9.4 of 2018 [I-D.ietf-ace-oscore-profile]. 2020 o Name: group_SenderId 2022 o CBOR Label: TBD4 2024 o CBOR Type: bstr 2026 o Registry: - 2028 o Description: OSCORE Sender ID assigned to a member of an OSCORE 2029 group 2031 o Reference: [[This specification]] (Section 6.4) 2033 o Name: cs_alg 2035 o CBOR Label: TBD5 2037 o CBOR Type: tstr / int 2039 o Registry: COSE Algorithms 2041 o Description: OSCORE Counter Signature Algorithm Value 2043 o Reference: [[This specification]] (Section 6.4) 2045 o Name: cs_params 2047 o CBOR Label: TBD6 2049 o CBOR Type: array 2051 o Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves 2053 o Description: OSCORE Counter Signature Algorithm Additional 2054 Parameters 2056 o Reference: [[This specification]] (Section 6.4) 2058 o Name: cs_key_params 2059 o CBOR Label: TBD7 2061 o CBOR Type: array 2063 o Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves 2065 o Description: OSCORE Counter Signature Key Additional Parameters 2067 o Reference: [[This specification]] (Section 6.4) 2069 o Name: cs_key_enc 2071 o CBOR Label: TBD8 2073 o CBOR Type: integer 2075 o Registry: CWT Confirmation Methods 2077 o Description: Encoding of Public Keys to be used with the OSCORE 2078 Counter Signature Algorithm 2080 o Reference: [[This specification]] (Section 6.4) 2082 o Name: ecdh_alg 2084 o CBOR Label: TBD9 2086 o CBOR Type: tstr / int 2088 o Registry: COSE Algorithms 2090 o Description: OSCORE ECDH Algorithm Value 2092 o Reference: [[This specification]] (Section 6.4) 2094 o Name: ecdh_params 2096 o CBOR Label: TBD10 2098 o CBOR Type: array 2100 o Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves 2102 o Description: OSCORE ECDH Algorithm Additional Parameters 2103 o Reference: [[This specification]] (Section 6.4) 2105 o Name: ecdh_key_params 2107 o CBOR Label: TBD11 2109 o CBOR Type: array 2111 o Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves 2113 o Description: OSCORE ECDH Key Additional Parameters 2115 o Reference: [[This specification]] (Section 6.4) 2117 21.5. TLS Exporter Label Registry 2119 IANA is asked to register the following entry to the "TLS Exporter 2120 Label" Registry defined in Section 6 of [RFC5705] and updated in 2121 Section 12 of [RFC8447]. 2123 o Value: EXPORTER-ACE-Sign-Challenge-coap-group-oscore-app 2125 o DTLS-OK: Y 2127 o Recommended: N 2129 o Reference: [[This specification]] (Section 6.2.1) 2131 21.6. AIF Registry 2133 IANA is asked to register the following entry to the "Toid" sub- 2134 registry of the "AIF" Registry defined in Section 5.2 of 2135 [I-D.ietf-ace-aif]. 2137 o Name: oscore-group-name 2139 o Description/Specification: group name of the OSCORE group, as 2140 specified in [[This specification]]. 2142 IANA is asked to register the following entry to the "Tperm" sub- 2143 Registry of the "AIF" Registry defined in Section 5.2 of 2144 [I-D.ietf-ace-aif]. 2146 o Name: oscore-group-roles 2148 o Description/Specification: role(s) of the member of the OSCORE 2149 group, as specified in [[This specification]]. 2151 21.7. Media Type Registrations 2153 This specification registers the 'application/aif-groupcomm- 2154 oscore+cbor' media type for the AIF specific data model AIF-OSCORE- 2155 GROUPCOMM defined in Section 3 of [[This specification]]. This 2156 registration follows the procedures specified in [RFC6838]. 2158 These media type has parameters for specifying the object identifier 2159 ("Toid") and set of permissions ("Tperm") defined for the AIF-generic 2160 model in [I-D.ietf-ace-aif]; default values are the values "oscore- 2161 group-name" for "Toid" and "oscore-group-roles" for "Tperm". 2163 Type name: application 2165 Subtype name: aif-groupcomm-oscore+cbor 2167 Required parameters: "Toid", "Tperm" 2169 Optional parameters: N/A 2171 Encoding considerations: Must be encoded as a CBOR array, each 2172 element of which is an array [Toid, Tperm] as defined in Section 3 of 2173 [[This specification]]. 2175 Security considerations: See Section 20 of [[This specification]]. 2177 Interoperability considerations: N/A 2179 Published specification: [[This specification]] 2181 Applications that use this media type: The type is used by 2182 applications that want to express authorization information about 2183 joining OSCORE groups, as specified in [[This specification]]. 2185 Fragment identifier considerations: N/A 2187 Additional information: N/A 2189 Person & email address to contact for further information: 2190 iesg@ietf.org [1] 2192 Intended usage: COMMON 2194 Restrictions on usage: None 2196 Author: Marco Tiloca marco.tiloca@ri.se [2] 2198 Change controller: IESG 2200 21.8. CoAP Content-Format Registry 2202 IANA is asked to register the following entry to the "CoAP Content- 2203 Formats" registry, within the "CoRE Parameters" registry: 2205 Media Type: application/aif-groupcomm-oscore+cbor;Toid="oscore-group- 2206 name",Tperm"oscore-group-roles" 2208 Encoding: - 2210 ID: TBD12 2212 Reference: [[This specification]] 2214 21.9. Group OSCORE Roles Registry 2216 This specification establishes the IANA "Group OSCORE Roles" 2217 Registry. The Registry has been created to use the "Expert Review" 2218 registration procedure [RFC8126]. Expert review guidelines are 2219 provided in Section 21.13. 2221 This registry includes the possible roles that nodes can take in an 2222 OSCORE group, each in combination with a numeric identifier. These 2223 numeric identifiers are used to express authorization information 2224 about joining OSCORE groups, as specified in Section 3 of [[This 2225 specification]]. 2227 The columns of this registry are: 2229 o Name: A value that can be used in documents for easier 2230 comprehension, to identify a possible role that nodes can take in 2231 an OSCORE group. 2233 o Value: The numeric identifier for this role. Integer values 2234 greater than 65535 are marked as "Private Use", all other values 2235 use the registration policy "Expert Review" [RFC8126]. 2237 o Description: This field contains a brief description of the role. 2239 o Reference: This contains a pointer to the public specification for 2240 the role. 2242 This registry will be initially populated by the values in Figure 1. 2244 The Reference column for all of these entries will be [[This 2245 specification]]. 2247 21.10. CoRE Resource Type Registry 2249 IANA is asked to register a new Resource Type (rt=) Link Target 2250 Attribute in the "Resource Type (rt=) Link Target Attribute Values" 2251 subregistry under the "Constrained Restful Environments (CoRE) 2252 Parameters" [CORE.Parameters] registry. 2254 o Value: "core.osc.gm" 2256 o Description: Group-membership resource of an OSCORE Group Manager. 2258 o Reference: [[This specification]] 2260 21.11. ACE Scope Semantics Registry 2262 IANA is asked to register the following entry in the "ACE Scope 2263 Semantics" registry defined in Section 10.12 of 2264 [I-D.ietf-ace-key-groupcomm]. 2266 o Value: SEM_ID_TBD 2268 o Description: Access to OSCORE groups through the ACE Group 2269 Manager. 2271 o Reference: [[This specification]] 2273 21.12. ACE Groupcomm Errors 2275 IANA is asked to register the following entry in the "ACE Scope 2276 Semantics" registry defined in Section 10.13 of 2277 [I-D.ietf-ace-key-groupcomm]. 2279 o Value: 7 2281 o Description: Group currently not active. 2283 o Reference: [[This specification]] 2285 21.13. Expert Review Instructions 2287 The IANA Registry established in this document is defined as "Expert 2288 Review". This section gives some general guidelines for what the 2289 experts should be looking for, but they are being designated as 2290 experts for a reason so they should be given substantial latitude. 2292 Expert reviewers should take into consideration the following points: 2294 o Clarity and correctness of registrations. Experts are expected to 2295 check the clarity of purpose and use of the requested entries. 2296 Experts should inspect the entry for the considered role, to 2297 verify the correctness of its description against the role as 2298 intended in the specification that defined it. Expert should 2299 consider requesting an opinion on the correctness of registered 2300 parameters from the Authentication and Authorization for 2301 Constrained Environments (ACE) Working Group and the Constrained 2302 RESTful Environments (CoRE) Working Group. 2304 Entries that do not meet these objective of clarity and 2305 completeness should not be registered. 2307 o Duplicated registration and point squatting should be discouraged. 2308 Reviewers are encouraged to get sufficient information for 2309 registration requests to ensure that the usage is not going to 2310 duplicate one that is already registered and that the point is 2311 likely to be used in deployments. 2313 o Experts should take into account the expected usage of roles when 2314 approving point assignment. Given a 'Value' V as code point, the 2315 length of the encoding of (2^(V+1) - 1) should be weighed against 2316 the usage of the entry, considering the resources and capabilities 2317 of devices it will be used on. Additionally, given a 'Value' V as 2318 code point, the length of the encoding of (2^(V+1) - 1) should be 2319 weighed against how many code points resulting in that encoding 2320 length are left, and the resources and capabilities of devices it 2321 will be used on. 2323 o Specifications are recommended. When specifications are not 2324 provided, the description provided needs to have sufficient 2325 information to verify the points above. 2327 22. References 2329 22.1. Normative References 2331 [CORE.Parameters] 2332 IANA, "Constrained RESTful Environments (CoRE) 2333 Parameters", . 2336 [COSE.Algorithms] 2337 IANA, "COSE Algorithms", 2338 . 2341 [COSE.Elliptic.Curves] 2342 IANA, "COSE Elliptic Curves", 2343 . 2346 [COSE.Key.Types] 2347 IANA, "COSE Key Types", 2348 . 2351 [CWT.Confirmation.Methods] 2352 IANA, "CWT Confirmation Methods", 2353 . 2356 [I-D.ietf-ace-aif] 2357 Bormann, C., "An Authorization Information Format (AIF) 2358 for ACE", draft-ietf-ace-aif-02 (work in progress), 2359 February 2021. 2361 [I-D.ietf-ace-key-groupcomm] 2362 Palombini, F. and M. Tiloca, "Key Provisioning for Group 2363 Communication using ACE", draft-ietf-ace-key-groupcomm-11 2364 (work in progress), February 2021. 2366 [I-D.ietf-ace-oauth-authz] 2367 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 2368 H. Tschofenig, "Authentication and Authorization for 2369 Constrained Environments (ACE) using the OAuth 2.0 2370 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-37 2371 (work in progress), February 2021. 2373 [I-D.ietf-ace-oscore-profile] 2374 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 2375 "OSCORE Profile of the Authentication and Authorization 2376 for Constrained Environments Framework", draft-ietf-ace- 2377 oscore-profile-16 (work in progress), January 2021. 2379 [I-D.ietf-core-oscore-groupcomm] 2380 Tiloca, M., Selander, G., Palombini, F., Mattsson, J., and 2381 J. Park, "Group OSCORE - Secure Group Communication for 2382 CoAP", draft-ietf-core-oscore-groupcomm-11 (work in 2383 progress), February 2021. 2385 [I-D.ietf-cose-rfc8152bis-algs] 2386 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2387 Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-12 2388 (work in progress), September 2020. 2390 [I-D.ietf-cose-rfc8152bis-struct] 2391 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2392 Structures and Process", draft-ietf-cose-rfc8152bis- 2393 struct-15 (work in progress), February 2021. 2395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2396 Requirement Levels", BCP 14, RFC 2119, 2397 DOI 10.17487/RFC2119, March 1997, 2398 . 2400 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 2401 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 2402 March 2010, . 2404 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2405 Specifications and Registration Procedures", BCP 13, 2406 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2407 . 2409 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 2410 Algorithm (DSA) and Elliptic Curve Digital Signature 2411 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2412 2013, . 2414 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2415 Application Protocol (CoAP)", RFC 7252, 2416 DOI 10.17487/RFC7252, June 2014, 2417 . 2419 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 2420 "PKCS #1: RSA Cryptography Specifications Version 2.2", 2421 RFC 8017, DOI 10.17487/RFC8017, November 2016, 2422 . 2424 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 2425 Signature Algorithm (EdDSA)", RFC 8032, 2426 DOI 10.17487/RFC8032, January 2017, 2427 . 2429 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2430 Writing an IANA Considerations Section in RFCs", BCP 26, 2431 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2432 . 2434 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2435 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2436 May 2017, . 2438 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2439 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2440 . 2442 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 2443 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 2444 . 2446 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2447 Definition Language (CDDL): A Notational Convention to 2448 Express Concise Binary Object Representation (CBOR) and 2449 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2450 June 2019, . 2452 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2453 "Object Security for Constrained RESTful Environments 2454 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2455 . 2457 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 2458 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 2459 . 2461 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 2462 Representation (CBOR)", STD 94, RFC 8949, 2463 DOI 10.17487/RFC8949, December 2020, 2464 . 2466 22.2. Informative References 2468 [I-D.ietf-ace-dtls-authorize] 2469 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 2470 L. Seitz, "Datagram Transport Layer Security (DTLS) 2471 Profile for Authentication and Authorization for 2472 Constrained Environments (ACE)", draft-ietf-ace-dtls- 2473 authorize-15 (work in progress), January 2021. 2475 [I-D.ietf-ace-oscore-gm-admin] 2476 Tiloca, M., Hoeglund, R., Stok, P., Palombini, F., and K. 2477 Hartke, "Admin Interface for the OSCORE Group Manager", 2478 draft-ietf-ace-oscore-gm-admin-02 (work in progress), 2479 February 2021. 2481 [I-D.ietf-core-coap-pubsub] 2482 Koster, M., Keranen, A., and J. Jimenez, "Publish- 2483 Subscribe Broker for the Constrained Application Protocol 2484 (CoAP)", draft-ietf-core-coap-pubsub-09 (work in 2485 progress), September 2019. 2487 [I-D.ietf-core-groupcomm-bis] 2488 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 2489 for the Constrained Application Protocol (CoAP)", draft- 2490 ietf-core-groupcomm-bis-03 (work in progress), February 2491 2021. 2493 [I-D.tiloca-core-oscore-discovery] 2494 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 2495 Groups with the CoRE Resource Directory", draft-tiloca- 2496 core-oscore-discovery-08 (work in progress), February 2497 2021. 2499 [NIST-800-56A] 2500 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 2501 Davis, "Recommendation for Pair-Wise Key-Establishment 2502 Schemes Using Discrete Logarithm Cryptography - NIST 2503 Special Publication 800-56A, Revision 3", April 2018, 2504 . 2507 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2508 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2509 January 2012, . 2511 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 2512 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 2513 . 2515 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 2516 RFC 6749, DOI 10.17487/RFC6749, October 2012, 2517 . 2519 [RFC7641] Hartke, K., "Observing Resources in the Constrained 2520 Application Protocol (CoAP)", RFC 7641, 2521 DOI 10.17487/RFC7641, September 2015, 2522 . 2524 22.3. URIs 2526 [1] mailto:iesg@ietf.org 2528 [2] mailto:marco.tiloca@ri.se 2530 Appendix A. Profile Requirements 2532 This appendix lists the specifications on this application profile of 2533 ACE, based on the requirements defined in Appendix A of 2534 [I-D.ietf-ace-key-groupcomm]. 2536 o REQ1 - If the value of the GROUPNAME URI path and the group name 2537 in the Access Token scope (gname in Section 3.1 of 2538 [I-D.ietf-ace-key-groupcomm]) do not match, specify the mechanism 2539 to map the GROUPNAME value in the URI to the group name: not 2540 applicable, since a match is required. 2542 o REQ2 - Specify the encoding and value of roles, for scope entries 2543 of 'scope': see Section 3 and Section 4.1. 2545 o REQ3 - if used, specify the acceptable values for 'sign_alg': 2546 values from the "Value" column of the "COSE Algorithms" Registry 2547 [COSE.Algorithms]. 2549 o REQ4 - If used, specify the acceptable values for 2550 'sign_parameters': format and values from the COSE algorithm 2551 capabilities as specified in the "COSE Algorithms" Registry 2552 [COSE.Algorithms] and from the COSE key type capabilities as 2553 specified in the "COSE Key Types" Registry [COSE.Key.Types]. 2555 o REQ5 - If used, specify the acceptable values for 2556 'sign_key_parameters': format and values from the COSE key type 2557 capabilities as specified in the "COSE Key Types" Registry 2558 [COSE.Key.Types]. 2560 o REQ6 - If used, specify the acceptable values for 'pub_key_enc': 1 2561 ("COSE_Key") from the 'Confirmation Key' column of the "CWT 2562 Confirmation Method" Registry [CWT.Confirmation.Methods]. Future 2563 specifications may define additional values for this parameter. 2565 o REQ7 - Register a Resource Type for the root url-path, which is 2566 used to discover the correct url to access at the KDC (see 2567 Section 4.1 of [I-D.ietf-ace-key-groupcomm]): the Resource Type 2568 (rt=) Link Target Attribute value "core.osc.gm" is registered in 2569 Section 21.10. 2571 o REQ8 - Define what operations (e.g. CoAP methods) are allowed on 2572 each resource, for each role defined in REQ2: see Section 5.2. 2574 o REQ9 - Specify the exact encoding of group identifier (see 2575 Section 4.1.1.1 of [I-D.ietf-ace-key-groupcomm]): CBOR byte string 2576 (see Section 15). 2578 o REQ10 - Format of the 'key' value: see Section 6.4. 2580 o REQ11 - Acceptable values of 'gkty': Group_OSCORE_Input_Material 2581 object (see Section 6.4). 2583 o REQ12 - Specify the format of the identifiers of group members: 2584 CBOR byte string (see Section 6.4 and Section 10). 2586 o REQ13 - Specify the communication protocol that the members of the 2587 group must use: CoAP [RFC7252], possibly over IP multicast 2588 [I-D.ietf-core-groupcomm-bis]. 2590 o REQ14 - Specify the security protocols that the group members must 2591 use to protect their communication: Group OSCORE 2592 [I-D.ietf-core-oscore-groupcomm]. 2594 o REQ15 - Specify and register the application profile identifier: 2595 coap_group_oscore_app (see Section 21.3). 2597 o REQ16 - Specify policies at the KDC to handle member ids that are 2598 not included in 'get_pub_keys': see Section 10. 2600 o REQ17 - If used, specify the format and content of 2601 'group_policies' and its entries: see Section 6.4. 2603 o REQ18 - Specify the format of newly-generated individual keying 2604 material for group members, or of the information to derive it, 2605 and corresponding CBOR label: see Section 9. 2607 o REQ19 - Specify how the communication is secured between the 2608 Client and KDC: by means of any transport profile of ACE 2609 [I-D.ietf-ace-oauth-authz] between Client and Group Manager that 2610 complies with the requirements in Appendix C of 2611 [I-D.ietf-ace-oauth-authz]. 2613 o REQ20 - Specify how the nonce N_S is generated, if the token is 2614 not being posted (e.g. if it is used directly to validate TLS 2615 instead): see Section 6.2.1. 2617 o REQ21 - Specify if 'mgt_key_material' is used, and if yes specify 2618 its format and content: not used in this version of the profile. 2620 o REQ22 - Define the initial value of the 'num' parameter: The 2621 initial value MUST be set to 0 when creating the OSCORE group, 2622 e.g. as in [I-D.ietf-ace-oscore-gm-admin]. 2624 o REQ23 - Specify and register the identifier of newly defined 2625 semantics for binary scopes: see Section 21.11. 2627 o OPT1 (Optional) - Specify the encoding of public keys, of 2628 'client_cred', and of 'pub_keys' if COSE_Keys are not used: no. 2630 o OPT2 (Optional) - Specify the negotiation of parameter values for 2631 signature algorithm and signature keys, if 'sign_info' is not 2632 used: possible early discovery by using the approach based on the 2633 CoRE Resource Directory described in 2634 [I-D.tiloca-core-oscore-discovery]. 2636 o OPT3 (Optional) - Specify additional parameters used in the Token 2637 Post exchange: 'ecdh_info', to negotiate the ECDH algorithm, ECDH 2638 algorithm parameters, ECDH key parameters and exact encoding of 2639 public keys used in the group, in case the joining node supports 2640 the pairwise mode of Group OSCORE. 2642 o OPT4 (Optional) - Specify the encoding of 'pub_keys_repos' if the 2643 default is not used: no. 2645 o OPT5 (Optional) - Specify policies that instruct clients to retain 2646 unsuccessfully decrypted messages and for how long, so that they 2647 can be decrypted after getting updated keying material: no. 2649 o OPT6 (Optional) - Specify the behavior of the handler in case of 2650 failure to retrieve a public key for the specific node: send a 2651 4.00 Bad Request response to a Joining Request (see Section 6.3). 2653 o OPT7 (Optional) - Specify possible or required payload formats for 2654 specific error cases: send a 4.00 Bad Request response to a 2655 Joining Request (see Section 6.3). 2657 o OPT8 (Optional) - Specify CBOR values to use for abbreviating 2658 identifiers of roles in the group or topic: see Section 4.1. 2660 o OPT9 (Optional) - Specify for the KDC to perform group rekeying 2661 (together or instead of renewing individual keying material) when 2662 receiving a Key Renewal Request: the Group Manager SHOULD NOT 2663 perform a group rekeying, unless already scheduled to occur 2664 shortly (see Section 9). 2666 o OPT10 (Optional) - Specify the functionalities implemented at the 2667 'control_uri' resource hosted at the Client, including message 2668 exchange encoding and other details (see Section 4.1.2.1 of 2669 [I-D.ietf-ace-key-groupcomm]): see Section 17 for the eviction of 2670 a group member; see Section 18 for the group rekeying process. 2672 o OPT11 (Optional) - Specify how the identifier of the sender's 2673 public key is included in the group request: no. 2675 o OPT12 (Optional) - Specify additional identifiers of error types, 2676 as values of the 'error' field in an error response from the KDC: 2677 see Section 21.12. 2679 Appendix B. Document Updates 2681 RFC EDITOR: PLEASE REMOVE THIS SECTION. 2683 B.1. Version -09 to -10 2685 o Updated non-recycling policy of Sender IDs. 2687 o Removed policies about Sender Sequence Number synchronization. 2689 o 'control_path' renamed to 'control_uri'. 2691 o Format of 'get_pub_keys' aligned with draft-ietf-ace-key- 2692 groupcomm. 2694 o Additional way to inform of group eviction. 2696 o Registered semantics identifier for extended scope format. 2698 o Extended error handling, with error type specified in some error 2699 responses. 2701 o Renumbered requirements. 2703 B.2. Version -08 to -09 2705 o The url-path "ace-group" is used. 2707 o Added overview of admitted methods on the Group Manager resources. 2709 o Added exchange of parameters relevant for the pairwise mode of 2710 Group OSCORE. 2712 o The signed value for 'client_cred_verify' includes also the scope. 2714 o Renamed the key material object as Group_OSCORE_Input_Material 2715 object. 2717 o Replaced 'clientId' with 'group_SenderId'. 2719 o Added message exchange for Group Names request-response. 2721 o No reassignment of Sender ID and Gid in the same OSCORE group. 2723 o Updates on group rekeying contextual with request of new Sender 2724 ID. 2726 o Signature verifiers can also retrieve Group Names and URIs. 2728 o Removed group policy about supporting Group OSCORE in pairwise 2729 mode. 2731 o Registration of the resource type rt="core.osc.gm". 2733 o Update list of requirements. 2735 o Clarifications and editorial revision. 2737 B.3. Version -07 to -08 2739 o AIF specific data model to express scope entries. 2741 o A set of roles is checked as valid when processing the Joining 2742 Request. 2744 o Updated format of 'get_pub_keys' in the Joining Request. 2746 o Payload format and default values of group policies in the Joining 2747 Response. 2749 o Updated payload format of the FETCH request to retrieve public 2750 keys. 2752 o Default values for group configuration parameters. 2754 o IANA registrations to support the AIF specific data model. 2756 B.4. Version -06 to -07 2758 o Alignments with draft-ietf-core-oscore-groupcomm. 2760 o New format of 'sign_info', using the COSE capabilities. 2762 o New format of Joining Response parameters, using the COSE 2763 capabilities. 2765 o Considerations on group rekeying. 2767 o Editorial revision. 2769 B.5. Version -05 to -06 2771 o Added role of external signature verifier. 2773 o Parameter 'rsnonce' renamed to 'kdcchallenge'. 2775 o Parameter 'kdcchallenge' may be omitted in some cases. 2777 o Clarified difference between group name and OSCORE Gid. 2779 o Removed the role combination ["requester", "monitor"]. 2781 o Admit implicit scope and audience in the Authorization Request. 2783 o New format for the 'sign_info' parameter. 2785 o Scope not mandatory to include in the Joining Request. 2787 o Group policy about supporting Group OSCORE in pairwise mode. 2789 o Possible individual rekeying of a single requesting node combined 2790 with a group rekeying. 2792 o Security considerations on reusage of signature challenges. 2794 o Addressing optional requirement OPT9 from draft-ietf-ace-key- 2795 groupcomm 2797 o Editorial improvements. 2799 B.6. Version -04 to -05 2801 o Nonce N_S also in error responses to the Joining Requests. 2803 o Supporting single Access Token for multiple groups/topics. 2805 o Supporting legal requesters/responders using the 'peer_roles' 2806 parameter. 2808 o Registered and used dedicated label for TLS Exporter. 2810 o Added method for uploading a new public key to the Group Manager. 2812 o Added resource and method for retrieving the current group status. 2814 o Fixed inconsistency in retrieving group keying material only. 2816 o Clarified retrieval of keying material for monitor-only members. 2818 o Clarification on incrementing version number when rekeying the 2819 group. 2821 o Clarification on what is re-distributed with the group rekeying. 2823 o Security considerations on the size of the nonces used for the 2824 signature challenge. 2826 o Added CBOR values to abbreviate role identifiers in the group. 2828 B.7. Version -03 to -04 2830 o New abstract. 2832 o Moved general content to draft-ietf-ace-key-groupcomm 2834 o Terminology: node name; node resource. 2836 o Creation and pointing at node resource. 2838 o Updated Group Manager API (REST methods and offered services). 2840 o Size of challenges 'cnonce' and 'rsnonce'. 2842 o Value of 'rsnonce' for reused or non-traditionally-posted tokens. 2844 o Removed reference to RFC 7390. 2846 o New requirements from draft-ietf-ace-key-groupcomm 2848 o Editorial improvements. 2850 B.8. Version -02 to -03 2852 o New sections, aligned with the interface of ace-key-groupcomm . 2854 o Exchange of information on the countersignature algorithm and 2855 related parameters, during the Token POST (Section 4.1). 2857 o Nonce 'rsnonce' from the Group Manager to the Client 2858 (Section 4.1). 2860 o Client PoP signature in the Key Distribution Request upon joining 2861 (Section 4.2). 2863 o Local actions on the Group Manager, upon a new node's joining 2864 (Section 4.2). 2866 o Local actions on the Group Manager, upon a node's leaving 2867 (Section 12). 2869 o IANA registration in ACE Groupcomm Parameters Registry. 2871 o More fulfilled profile requirements (Appendix A). 2873 B.9. Version -01 to -02 2875 o Editorial fixes. 2877 o Changed: "listener" to "responder"; "pure listener" to "monitor". 2879 o Changed profile name to "coap_group_oscore_app", to reflect it is 2880 an application profile. 2882 o Added the 'type' parameter for all requests to a Join Resource. 2884 o Added parameters to indicate the encoding of public keys. 2886 o Challenge-response for proof-of-possession of signature keys 2887 (Section 4). 2889 o Renamed 'key_info' parameter to 'sign_info'; updated its format; 2890 extended to include also parameters of the countersignature key 2891 (Section 4.1). 2893 o Code 4.00 (Bad request), in responses to joining nodes providing 2894 an invalid public key (Section 4.3). 2896 o Clarifications on provisioning and checking of public keys 2897 (Sections 4 and 6). 2899 o Extended discussion on group rekeying and possible different 2900 approaches (Section 7). 2902 o Extended security considerations: proof-of-possession of signature 2903 keys; collision of OSCORE Group Identifiers (Section 8). 2905 o Registered three entries in the IANA Registry "Sequence Number 2906 Synchronization Method Registry" (Section 9). 2908 o Registered one public key encoding in the "ACE Public Key 2909 Encoding" IANA Registry (Section 9). 2911 B.10. Version -00 to -01 2913 o Changed name of 'req_aud' to 'audience' in the Authorization 2914 Request (Section 3.1). 2916 o Added negotiation of countersignature algorithm/parameters between 2917 Client and Group Manager (Section 4). 2919 o Updated format of the Key Distribution Response as a whole 2920 (Section 4.3). 2922 o Added parameter 'cs_params' in the 'key' parameter of the Key 2923 Distribution Response (Section 4.3). 2925 o New IANA registrations in the "ACE Authorization Server Request 2926 Creation Hints" Registry, "ACE Groupcomm Key" Registry, "OSCORE 2927 Security Context Parameters" Registry and "ACE Groupcomm Profile" 2928 Registry (Section 9). 2930 Acknowledgments 2932 The authors sincerely thank Santiago Aragon, Stefan Beck, Carsten 2933 Bormann, Martin Gunnarsson, Rikard Hoeglund, Daniel Migault, Jim 2934 Schaad, Ludwig Seitz, Goeran Selander and Peter van der Stok for 2935 their comments and feedback. 2937 The work on this document has been partly supported by VINNOVA and 2938 the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home 2939 (Grant agreement 952652); and by the EIT-Digital High Impact 2940 Initiative ACTIVE. 2942 Authors' Addresses 2944 Marco Tiloca 2945 RISE AB 2946 Isafjordsgatan 22 2947 Kista SE-164 29 Stockholm 2948 Sweden 2950 Email: marco.tiloca@ri.se 2952 Jiye Park 2953 Universitaet Duisburg-Essen 2954 Schuetzenbahn 70 2955 Essen 45127 2956 Germany 2958 Email: ji-ye.park@uni-due.de 2960 Francesca Palombini 2961 Ericsson AB 2962 Torshamnsgatan 23 2963 Kista SE-16440 Stockholm 2964 Sweden 2966 Email: francesca.palombini@ericsson.com