idnits 2.17.1 draft-ietf-ace-key-groupcomm-oscore-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2020) is 1383 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 1698, but not defined == Missing Reference: 'Tperm' is mentioned on line 1698, but not defined == Missing Reference: 'RSA' is mentioned on line 1348, but not defined == Missing Reference: 'OKP' is mentioned on line 1328, but not defined == Missing Reference: 'Ed25519' is mentioned on line 1324, but not defined == Missing Reference: 'Ed448' is mentioned on line 1328, but not defined == Missing Reference: 'EC2' is mentioned on line 1343, but not defined == Missing Reference: 'P-256' is mentioned on line 1333, but not defined == Missing Reference: 'P-384' is mentioned on line 1338, but not defined == Missing Reference: 'P-521' is mentioned on line 1343, but not defined -- Looks like a reference, but probably isn't: '1' on line 1994 -- Looks like a reference, but probably isn't: '2' on line 1996 ** Downref: Normative reference to an Informational draft: draft-bormann-core-ace-aif (ref. 'I-D.bormann-core-ace-aif') == Outdated reference: A later version (-18) exists of draft-ietf-ace-key-groupcomm-08 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-35 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-11 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-09 == Outdated reference: A later version (-12) exists of draft-ietf-cose-rfc8152bis-algs-11 ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') == Outdated reference: A later version (-15) exists of draft-ietf-cose-rfc8152bis-struct-11 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' ** 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-12 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-09 == Outdated reference: A later version (-11) exists of draft-ietf-core-groupcomm-bis-00 == Outdated reference: A later version (-02) exists of draft-tiloca-ace-oscore-gm-admin-01 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-05 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 5 errors (**), 0 flaws (~~), 23 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: January 14, 2021 Universitaet Duisburg-Essen 6 F. Palombini 7 Ericsson AB 8 July 13, 2020 10 Key Management for OSCORE Groups in ACE 11 draft-ietf-ace-key-groupcomm-oscore-08 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 January 14, 2021. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 64 2.1. Overview of the Joining Process . . . . . . . . . . . . . 6 65 2.2. Overview of the Group Rekeying Process . . . . . . . . . 6 66 3. Format of Scope . . . . . . . . . . . . . . . . . . . . . . . 7 67 4. Joining Node to Authorization Server . . . . . . . . . . . . 8 68 4.1. Authorization Request . . . . . . . . . . . . . . . . . . 9 69 4.2. Authorization Response . . . . . . . . . . . . . . . . . 9 70 5. Interface at the Group Manager . . . . . . . . . . . . . . . 9 71 5.1. GET Handler . . . . . . . . . . . . . . . . . . . . . . . 9 72 6. Token POST and Group Joining . . . . . . . . . . . . . . . . 10 73 6.1. Token Post . . . . . . . . . . . . . . . . . . . . . . . 10 74 6.2. Sending the Joining Request . . . . . . . . . . . . . . . 12 75 6.2.1. Value of the N_S Challenge . . . . . . . . . . . . . 13 76 6.3. Processing the Joining Request . . . . . . . . . . . . . 13 77 6.4. Joining Response . . . . . . . . . . . . . . . . . . . . 15 78 6.5. ACE Groupcomm Policy for Group OSCORE Pairwise Mode 79 Support . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 7. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 18 81 8. Retrieval of Updated Keying Material . . . . . . . . . . . . 20 82 8.1. Retrieval of Group Keying Material . . . . . . . . . . . 20 83 8.2. Retrieval of Group Keying Material and Sender ID . . . . 21 84 9. Retrieval of New Keying Material . . . . . . . . . . . . . . 21 85 10. Retrieval of Public Keys of Group Members . . . . . . . . . . 22 86 11. Update of Public Key . . . . . . . . . . . . . . . . . . . . 23 87 12. Retrieval of Group Policies . . . . . . . . . . . . . . . . . 23 88 13. Retrieval of Keying Material Version . . . . . . . . . . . . 24 89 14. Retrieval of Group Status . . . . . . . . . . . . . . . . . . 24 90 15. Request to Leave the Group . . . . . . . . . . . . . . . . . 25 91 16. Removal of a Group Member . . . . . . . . . . . . . . . . . . 25 92 17. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 26 93 18. Default Values for Group Configuration Parameters . . . . . . 28 94 19. Security Considerations . . . . . . . . . . . . . . . . . . . 29 95 19.1. Management of OSCORE Groups . . . . . . . . . . . . . . 29 96 19.2. Size of Nonces for Signature Challenge . . . . . . . . . 30 97 19.3. Reusage of Nonces for Signature Challenge . . . . . . . 31 98 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 99 20.1. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 32 100 20.2. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 32 101 20.3. OSCORE Security Context Parameters Registry . . . . . . 33 102 20.4. Sequence Number Synchronization Method Registry . . . . 34 103 20.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . 35 104 20.6. ACE Groupcomm Policy Registry . . . . . . . . . . . . . 35 105 20.7. TLS Exporter Label Registry . . . . . . . . . . . . . . 35 106 20.8. AIF Registry . . . . . . . . . . . . . . . . . . . . . . 36 107 20.9. Media Type Registrations . . . . . . . . . . . . . . . . 36 108 20.10. CoAP Content-Format Registry . . . . . . . . . . . . . . 37 109 20.11. Group OSCORE Roles Registry . . . . . . . . . . . . . . 37 110 20.12. Expert Review Instructions . . . . . . . . . . . . . . . 38 111 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 112 21.1. Normative References . . . . . . . . . . . . . . . . . . 39 113 21.2. Informative References . . . . . . . . . . . . . . . . . 42 114 21.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 43 115 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 43 116 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 45 117 B.1. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 45 118 B.2. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 46 119 B.3. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 46 120 B.4. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 47 121 B.5. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 47 122 B.6. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 48 123 B.7. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 48 124 B.8. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 49 125 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 128 1. Introduction 130 Object Security for Constrained RESTful Environments (OSCORE) 131 [RFC8613] is a method for application-layer protection of the 132 Constrained Application Protocol (CoAP) [RFC7252], using CBOR Object 133 Signing and Encryption (COSE) 134 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs] and 135 enabling end-to-end security of CoAP payload and options. 137 As described in [I-D.ietf-core-oscore-groupcomm], Group OSCORE is 138 used to protect CoAP group communication over IP multicast 139 [I-D.ietf-core-groupcomm-bis]. This relies on a Group Manager, which 140 is responsible for managing an OSCORE group and enables the group 141 members to exchange CoAP messages secured with Group OSCORE. The 142 Group Manager can be responsible for multiple groups, coordinates the 143 joining process of new group members, and is entrusted with the 144 distribution and renewal of group keying material. 146 This specification is an application profile of 147 [I-D.ietf-ace-key-groupcomm], which itself builds on the ACE 148 framework for Authentication and Authorization 149 [I-D.ietf-ace-oauth-authz]. Message exchanges among the participants 150 as well as message formats and processing follow what specified in 151 [I-D.ietf-ace-key-groupcomm] for provisioning and renewing keying 152 material in group communication scenarios, where Group OSCORE is used 153 to protect CoAP group communication over IP multicast. 155 1.1. Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 159 "OPTIONAL" in this document are to be interpreted as described in BCP 160 14 [RFC2119][RFC8174] when, and only when, they appear in all 161 capitals, as shown here. 163 Readers are expected to be familiar with: 165 o The terms and concepts described in the ACE framework for 166 authentication and authorization [I-D.ietf-ace-oauth-authz] and in 167 the Authorization Information Format (AIF) 168 [I-D.bormann-core-ace-aif] to express authorization information. 169 The terminology for entities in the considered architecture is 170 defined in OAuth 2.0 [RFC6749]. In particular, this includes 171 Client (C), Resource Server (RS), and Authorization Server (AS). 173 o The terms and concepts related to the CoAP protocol described in 174 [RFC7252][I-D.ietf-core-groupcomm-bis]. Unless otherwise 175 indicated, the term "endpoint" is used here following its OAuth 176 definition, aimed at denoting resources such as /token and 177 /introspect at the AS and /authz-info at the RS. This document 178 does not use the CoAP definition of "endpoint", which is "An 179 entity participating in the CoAP protocol". 181 o The terms and concept related to the message formats and 182 processing specified in [I-D.ietf-ace-key-groupcomm], for 183 provisioning and renewing keying material in group communication 184 scenarios. 186 o The terms and concepts for protection and processing of CoAP 187 messages through OSCORE [RFC8613] and through Group OSCORE 188 [I-D.ietf-core-oscore-groupcomm] in group communication scenarios. 189 These include the concept of Group Manager, as the entity 190 responsible for a set of groups where communications are secured 191 with Group OSCORE. In this specification, the Group Manager acts 192 as Resource Server. 194 Additionally, this document makes use of the following terminology. 196 o Requester: member of an OSCORE group that sends request messages 197 to other members of the group. 199 o Responder: member of an OSCORE group that receives request 200 messages from other members of the group. A responder may reply 201 back, by sending a response message to the requester which has 202 sent the request message. 204 o Monitor: member of an OSCORE group that is configured as responder 205 and never replies back to requesters after receiving request 206 messages. This corresponds to the term "silent server" used in 207 [I-D.ietf-core-oscore-groupcomm]. 209 o Signature verifier: entity external to the OSCORE group and 210 intended to verify the countersignature of messages exchanged in 211 the group. An authorized signature verifier does not join the 212 OSCORE group as an actual member, yet it can retrieve the public 213 keys of the current group members from the Group Manager. 215 2. Protocol Overview 217 Group communication for CoAP over IP multicast has been enabled in 218 [I-D.ietf-core-groupcomm-bis] and can be secured with Group Object 219 Security for Constrained RESTful Environments (OSCORE) [RFC8613] as 220 described in [I-D.ietf-core-oscore-groupcomm]. A network node joins 221 an OSCORE group by interacting with the responsible Group Manager. 222 Once registered in the group, the new node can securely exchange 223 messages with other group members. 225 This specification describes how to use [I-D.ietf-ace-key-groupcomm] 226 and [I-D.ietf-ace-oauth-authz] to perform a number of authentication, 227 authorization and key distribution actions, as defined in Section 2 228 of [I-D.ietf-ace-key-groupcomm], for an OSCORE group. 230 With reference to [I-D.ietf-ace-key-groupcomm]: 232 o The node wishing to join the OSCORE group, i.e. the joining node, 233 is the Client. 235 o The Group Manager is the Key Distribution Center (KDC), acting as 236 a Resource Server. 238 o The Authorization Server associated to the Group Manager is the 239 AS. 241 All communications between the involved entities MUST be secured. 243 In particular, communications between the Client and the Group 244 Manager leverage protocol-specific transport profiles of ACE to 245 achieve communication security, proof-of-possession and server 246 authentication. Note that it is expected that in the commonly 247 referred base-case of this specification, the transport profile to 248 use is pre-configured and well-known to nodes participating in 249 constrained applications. 251 2.1. Overview of the Joining Process 253 A node performs the steps described in Section 4.2 of 254 [I-D.ietf-ace-key-groupcomm] in order to join an OSCORE group. The 255 format and processing of messages exchanged among the participants 256 are further specified in Section 4 and Section 6 of this document. 258 2.2. Overview of the Group Rekeying Process 260 If the application requires backward and forward security, the Group 261 Manager MUST generate new keying material and distribute it to the 262 group (rekeying) upon membership changes. 264 That is, the group is rekeyed when a node joins the group as a new 265 member, or after a current member leaves the group. By doing so, a 266 joining node cannot access communications in the group prior its 267 joining, while a leaving node cannot access communications in the 268 group after its leaving. 270 The keying material distributed through a group rekeying MUST 271 include: 273 o a new Group Identifier (Gid) for the group, used as ID Context 274 parameter of the OSCORE Common Security Context of that group (see 275 Section 2 of [I-D.ietf-core-oscore-groupcomm]). Note that the Gid 276 differs from the plain group name introduced in 277 [I-D.ietf-ace-key-groupcomm], which is a plain, stable and 278 invariant identifier, with no cryptographic relevance and meaning. 280 o a new value for the Master Secret parameter of the OSCORE Common 281 Security Context of that group (see Section 2 of 282 [I-D.ietf-core-oscore-groupcomm]). 284 Also, the distributed keying material MAY include a new value for the 285 Master Salt parameter of the OSCORE Common Security Context of that 286 group. 288 Upon generating the new group keying material and before starting its 289 distribution, the Group Manager MUST increment the version number of 290 the group keying material. When rekeying a group, the Group Manager 291 MUST preserve the current value of the Sender ID of each member in 292 that group. 294 The Group Manager MUST support the Group Rekeying Process described 295 in Section 17. Future application profiles may define alternative 296 message formats and distribution schemes to perform group rekeying. 298 3. Format of Scope 300 Building on Section 3.1 of [I-D.ietf-ace-key-groupcomm], this section 301 defines the exact format and encoding of scope to use. 303 To this end, this profile uses the Authorization Information Format 304 (AIF) [I-D.bormann-core-ace-aif], and defines the following AIF 305 specific data model AIF-OSCORE-GROUPCOMM. 307 With reference to the generic AIF model 309 AIF-Generic = [* [Toid, Tperm]] 311 the value of the CBOR byte string used as scope encodes the CBOR 312 array [* [Toid, Tperm]], where each [Toid, Tperm] element corresponds 313 to one scope entry. 315 Then, for each scope entry: 317 o the object identifier ("Toid") is specialized as a CBOR text 318 string, specifying the group name for the scope entry (REQ1) (see 319 Appendix A); 321 o the permission set ("Tperm") is specialized to a CBOR unsigned 322 integer with value R, specifying the role(s) that the client 323 wishes to take in the group (REQ2). The value R is computed as 324 follows: 326 * each role in the permission set is converted into the 327 corresponding numeric identifier X from the "Value" column of 328 the table in Figure 1. 330 * the set of N numbers is converted into the single value R, by 331 taking each numeric identifier X_1, X_2, ..., X_N to the power 332 of two, and then computing the inclusive OR of the binary 333 representations of all the power values. 335 +-----------+-------+-------------------------------------------------+ 336 | Name | Value | Description | 337 +===========+=======+=================================================+ 338 | Reserved | 0 | This value is reserved | 339 |-----------+-------+-------------------------------------------------+ 340 | Requester | 1 | Send requests; receive responses | 341 |-----------+-------+-------------------------------------------------+ 342 | Responder | 2 | Send responses; receive requests | 343 +-----------+-------+-------------------------------------------------+ 344 | Monitor | 3 | Receive requests; never send requests/responses | 345 |-----------+-------+-------------------------------------------------| 346 | Verifier | 4 | Verify countersignature of intercepted messages | 347 +-----------+-------+-------------------------------------------------+ 349 Figure 1: Numeric identifier of roles in the OSCORE group 351 The CDDL [RFC8610] definition of the AIF-OSCORE-GROUPCOMM data model 352 is as follows: 354 AIF-OSCORE-GROUPCOMM = AIF_Generic 356 path = tstr ; Group name 357 permissions = uint . bits roles 358 roles = &( 359 Requester: 1, 360 Responder: 2, 361 Monitor: 3, 362 Verifier: 4 363 ) 365 Future specifications that define new roles MUST register a 366 corresponding numeric identifier in the "Group OSCORE Roles" Registry 367 defined in Section 20.11 of this specification. 369 4. Joining Node to Authorization Server 371 This section describes how the joining node interacts with the AS in 372 order to be authorized to join an OSCORE group under a given Group 373 Manager. In particular, it considers a joining node that intends to 374 contact that Group Manager for the first time. 376 The message exchange between the joining node and the AS consists of 377 the messages Authorization Request and Authorization Response defined 378 in Section 3 of [I-D.ietf-ace-key-groupcomm]. Note that what is 379 defined in [I-D.ietf-ace-key-groupcomm] applies, and only additions 380 or modifications to that specification are defined here. 382 4.1. Authorization Request 384 The Authorization Request message is as defined in Section 3.1 of 385 [I-D.ietf-ace-key-groupcomm], with the following additions. 387 o If the 'scope' parameter is present: 389 * The value of the CBOR byte string encodes a CBOR array, whose 390 format MUST follow the data model AIF-OSCORE-GROUPCOMM defined 391 in Section 3. In particular, for each OSCORE group to join: 393 + The group name is encoded as a CBOR text string (REQ1). 395 + The set of requested roles is expressed as a single CBOR 396 unsigned integer, computed as defined in Section 3 (REQ2) 397 from the numerical abbreviations defined in Figure 1 for 398 each requested role (OPT7). 400 4.2. Authorization Response 402 The Authorization Response message is as defined in Section 3.2 of 403 [I-D.ietf-ace-key-groupcomm], with the following additions: 405 o The AS MUST include the 'expires_in' parameter. Other means for 406 the AS to specify the lifetime of Access Tokens are out of the 407 scope of this specification. 409 o The AS MUST include the 'scope' parameter, when the value included 410 in the Access Token differs from the one specified by the joining 411 node in the request. In such a case, the second element of each 412 scope entry MUST be present, and specifies the set of roles that 413 the joining node is actually authorized to take in the OSCORE 414 group for that scope entry, encoded as specified in Section 4.1. 416 5. Interface at the Group Manager 418 The Group Manager provides the interface defined in Section 4.1 of 419 [I-D.ietf-ace-key-groupcomm], with the following additional resource: 421 o /group-oscore/GROUPNAME/active: this sub-resource supports the GET 422 method, whose handler is defined in Section 5.1. 424 5.1. GET Handler 426 The handler expects a GET request. 428 The handler verifies that the group identifier of the /group- 429 oscore/GROUPNAME/active path is a subset of the 'scope' stored in the 430 Access Token associated to the requesting client. If verification 431 fails, the Group Manager MUST respond with a 4.01 (Unauthorized) 432 error message. 434 If verification succeeds, the handler returns a 2.05 (Content) 435 message containing the CBOR simple value True if the group is 436 currently active, or the CBOR simple value False otherwise. The 437 group is considered active if it is set to allow new members to join, 438 and if communication within the group is expected. 440 The method to set the current group status, i.e. active or inactive, 441 is out of the scope of this specification, and is defined for the 442 administrator interface of the Group Manager specified in 443 [I-D.tiloca-ace-oscore-gm-admin]. 445 6. Token POST and Group Joining 447 The following subsections describe the interactions between the 448 joining node and the Group Manager, i.e. the sending of the Access 449 Token and the Request-Response exchange to join the OSCORE group. 450 The message exchange between the joining node and the KDC consists of 451 the messages defined in Section 3.3 and 4.2 of 452 [I-D.ietf-ace-key-groupcomm]. Note that what is defined in 453 [I-D.ietf-ace-key-groupcomm] applies, and only additions or 454 modifications to that specification are defined here. 456 A signature verifier provides the Group Manager with an Access Token, 457 as described in Section 6.1, just as any another joining node does. 458 However, unlike candidate group members, it does not join any OSCORE 459 group, i.e. it does not perform the joining process defined in 460 Section 6.2. After successfully posting a token, a signature 461 verifier is authorized to perform only the operations specified in 462 Section 10, to retrieve the public keys of group members, and only 463 for the OSCORE groups specified in the validated Access Token. The 464 Group Manager MUST respond with a 4.01 (Unauthorized) error message, 465 in case a signature verifier attempts to access any other endpoint 466 than /group-oscore/GROUPNAME/pub-key at the Group Manager. 468 6.1. Token Post 470 The Token post exchange is defined in Section 3.3 of 471 [I-D.ietf-ace-key-groupcomm]. 473 Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the 474 following applies. 476 o The 'kdcchallenge' parameter contains a dedicated nonce N_S 477 generated by the Group Manager. For the N_S value, it is 478 RECOMMENDED to use a 8-byte long random nonce. The joining node 479 may use this nonce in order to prove the possession of its own 480 private key, upon joining the group (see Section 6.2). 482 The 'kdcchallenge' parameter MAY be omitted from the 2.01 483 (Created) response, if the 'scope' of the Access Token specifies 484 only the role "monitor" or only the role "verifier", for each of 485 the specified groups. 487 o If the 'sign_info' parameter is present in the response, the 488 following applies for each element 'sign_info_entry'. 490 * In the 'id' element, every group name is encoded as a CBOR text 491 string (REQ1) (see Appendix A). 493 * 'sign_alg' takes value from the "Value" column of the "COSE 494 Algorithms" Registry [COSE.Algorithms]. 496 * 'sign_parameters' is a CBOR array including the following two 497 elements: 499 + 'sign_alg_capab', encoded as a CBOR array. Its precise 500 format and value is the same as the COSE capabilities entry 501 in the "Capabilities" column of the "COSE Algorithms" 502 Registry [COSE.Algorithms], for the algorithm indicated in 503 'sign_alg' (REQ4). 505 + 'sign_key_type_capab', encoded as a CBOR array. Its precise 506 format and value is the same as the COSE capabilities entry 507 in the "Capabilities" column of the "COSE Key Types" 508 Registry [COSE.Key.Types], for the algorithm indicated in 509 'sign_alg' (REQ4). 511 * 'sign_key_parameters' is a CBOR array. Its precise format and 512 value is the same as the COSE capabilities entry in the 513 "Capabilities" column of the "COSE Key Types" Registry 514 [COSE.Key.Types], for the algorithm indicated in 'sign_alg' 515 (REQ5). 517 * 'pub_key_enc' takes value 1 ("COSE_Key") from the 'Confirmation 518 Key' column of the "CWT Confirmation Method" Registry 519 [CWT.Confirmation.Methods], so indicating that public keys in 520 the OSCORE group are encoded as COSE Keys 521 [I-D.ietf-cose-rfc8152bis-struct]. Future specifications may 522 define additional values for this parameter. 524 Note that, other than through the above parameters as defined in 525 Section 3.3 of [I-D.ietf-ace-key-groupcomm], the joining node MAY 526 have previously retrieved this information by other means, e.g. by 527 using the approach described in [I-D.tiloca-core-oscore-discovery]. 529 Additionally, if allowed by the used transport profile of ACE, the 530 joining node may instead provide the Access Token to the Group 531 Manager by other means, e.g. during a secure session establishment 532 (see Section 3.3.1 of [I-D.ietf-ace-dtls-authorize]). 534 6.2. Sending the Joining Request 536 The joining node requests to join the OSCORE group, by sending a 537 Joining Request message to the related group-membership resource at 538 the Group Manager, as per Section 4.2 of 539 [I-D.ietf-ace-key-groupcomm]. 541 Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the 542 following applies. 544 o The string "group-oscore" is used instead of "ace-group" (see 545 Section 4.1 of [I-D.ietf-ace-key-groupcomm]) as the top level path 546 to the group-membership resource. The url-path /group-oscore/ is 547 a default name of this specifications: implementations are not 548 required to use this name, and can define their own instead. 550 o The 'get_pub_keys' parameter is present only if the joining node 551 wants to retrieve the public keys of the group members from the 552 Group Manager during the joining process (see Section 7). 553 Otherwise, this parameter MUST NOT be present. 555 If this parameter is present, each element (if any) of the first 556 CBOR array is encoded as a CBOR integer, with the same value of a 557 permission set ("Tperm") indicating that role or combination of 558 roles in a scope entry, as defined in Section 3. 560 o 'cnonce' contains a dedicated nonce N_C generated by the joining 561 node. For the N_C value, it is RECOMMENDED to use a 8-byte long 562 random nonce. 564 o The signature encoded in the 'client_cred_verify' parameter is 565 computed by the joining node by using the same private key and 566 countersignature algorithm it intends to use for signing messages 567 in the OSCORE group. Moreover, N_S is as defined in 568 Section 6.2.1. 570 6.2.1. Value of the N_S Challenge 572 The value of the N_S challenge is determined as follows. 574 1. If the joining node has posted the Access Token to the /authz- 575 info endpoint of the Group Manager as in Section 6.1, N_S takes 576 the same value of the most recent 'kdcchallenge' parameter 577 received by the joining node from the Group Manager. This can be 578 either the one specified in the 2.01 (Created) response to the 579 Token POST, or the one possibly specified in a 4.00 (Bad Request) 580 response to a following Joining Request (see Section 6.3). 582 2. If the Token posting has relied on the DTLS profile of ACE 583 [I-D.ietf-ace-dtls-authorize] with the Access Token as content of 584 the "psk_identity" field of the ClientKeyExchange message 585 [RFC6347], N_S is an exporter value computed as defined in 586 Section 7.5 of [RFC8446]. Specifically, N_S is exported from the 587 DTLS session between the joining node and the Group Manager, 588 using an empty 'context_value', 32 bytes as 'key_length', and the 589 exporter label "EXPORTER-ACE-Sign-Challenge-coap-group-oscore- 590 app" defined in Section 20.7 of this specification. 592 It is up to applications to define how N_S is computed in further 593 alternative settings. 595 Section 19.3 provides security considerations on the reusage of the 596 N_S challenge. 598 6.3. Processing the Joining Request 600 The Group Manager processes the Joining Request as defined in 601 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm]. Additionally, the 602 following applies. 604 o In case the Joining Request does not include the 'client_cred' 605 parameter, the joining process fails if the Group Manager either: 606 i) does not store a public key with an accepted format for the 607 joining node; or ii) stores multiple public keys with an accepted 608 format for the joining node. 610 o To compute the signature contained in 'client_cred_verify', the GM 611 considers: i) as signed value, N_S concatenated with N_C, where 612 N_S is determined as described in Section 6.2.1, while N_C is the 613 nonce provided in the 'cnonce' parameter of the Joining Request; 614 ii) the countersignature algorithm used in the OSCORE group, and 615 possible correponding parameters; and iii) the public key of the 616 joining node, either retrieved from the 'client_cred' parameter, 617 or already stored as acquired from previous interactions with the 618 joining node. 620 o A 4.00 Bad Request response from the Group Manager to the joining 621 node MUST have content format application/ace+cbor. The response 622 payload is a CBOR map which MUST contain the 'sign_info' 623 parameter, including a single element 'sign_info_entry' pertaining 624 to the OSCORE group that the joining node tried to join with the 625 Joining Request. 627 o The Group Manager MUST return a 4.00 (Bad Request) response in 628 case the Joining Request includes the 'scope' parameter specifying 629 any set of roles not included in the following list: "requester", 630 "responder", "monitor", ("requester", "responder"). Future 631 specifications that define a new role MUST define possible sets of 632 roles including the new one and existing ones, that are acceptable 633 to specify in the 'scope' parameter of a Joining Request. 635 o The Group Manager MUST return a 4.00 (Bad Request) response in 636 case the Joining Request includes the 'client_cred' parameter but 637 does not include both the 'cnonce' and 'client_cred_verify' 638 parameters. 640 o The Group Manager MUST return a 4.00 (Bad Request) response in 641 case it cannot retrieve a public key with an accepted format for 642 the joining node, either from the 'client_cred' parameter or as 643 already stored. 645 o When receiving a 4.00 Bad Request response, the joining node 646 SHOULD send a new Joining Request to the Group Manager, where: 648 * The 'cnonce' parameter MUST include a new dedicated nonce N_C 649 generated by the joining node. 651 * The 'client_cred' parameter MUST include a public key 652 compatible with the encoding, countersignature algorithm and 653 possible associated parameters indicated by the Group Manager. 655 * The 'client_cred_verify' parameter MUST include a signature 656 computed as described in Section 6.2, by using the public key 657 indicated in the current 'client_cred' parameter, with the 658 countersignature algorithm and possible associated parameters 659 indicated by the Group Manager. If the error response from the 660 Group Manager included the 'kdcchallenge' parameter, the 661 joining node MUST use its content as new N_S challenge to 662 compute the signature. 664 6.4. Joining Response 666 If the processing of the Joining Request described in Section 6.3 is 667 successful, the Group Manager updates the group membership by 668 registering the joining node NODENAME as a new member of the OSCORE 669 group GROUPNAME, as described in Section 4.1.2.1 of 670 [I-D.ietf-ace-key-groupcomm]. 672 If the joining node has not taken exclusively the role of monitor, 673 the Group Manager performs also the following actions. 675 o The Group Manager selects an available OSCORE Sender ID in the 676 OSCORE group, and exclusively assigns it to the joining node. 678 o The Group Manager stores the association between i) the public key 679 of the joining node; and ii) the Group Identifier (Gid), i.e. the 680 OSCORE ID Context, associated to the OSCORE group together with 681 the OSCORE Sender ID assigned to the joining node in the group. 682 The Group Manager MUST keep this association updated over time. 684 Then, the Group Manager replies to the joining node, providing the 685 updated security parameters and keying meterial necessary to 686 participate in the group communication. This success Joining 687 Response is formatted as defined in Section 4.1.2.1 of 688 [I-D.ietf-ace-key-groupcomm], with the following additions: 690 o The 'gkty' parameter identifies a key of type 691 "Group_OSCORE_Security_Context object", defined in Section 20.2 of 692 this specification. 694 o The 'key' parameter includes what the joining node needs in order 695 to set up the OSCORE Security Context as per Section 2 of 696 [I-D.ietf-core-oscore-groupcomm]. This parameter has as value a 697 Group_OSCORE_Security_Context object, which is defined in this 698 specification and extends the OSCORE_Security_Context object 699 encoded in CBOR as defined in Section 3.2.1 of 700 [I-D.ietf-ace-oscore-profile]. In particular, it contains the 701 additional parameters 'cs_alg', 'cs_params', 'cs_key_params' and 702 'cs_key_enc' defined in Section 20.3 of this specification. More 703 specifically, the 'key' parameter is composed as follows. 705 * The 'ms' parameter MUST be present and includes the OSCORE 706 Master Secret value. 708 * The 'clientId' parameter, if present, has as value the OSCORE 709 Sender ID assigned to the joining node by the Group Manager, as 710 described above. This parameter is not present if the node 711 joins the group exclusively with the role of monitor, according 712 to what specified in the Access Token (see Section 4.2). In 713 any other case, this parameter MUST be present. 715 * The 'hkdf' parameter, if present, has as value the KDF 716 algorithm used in the group. 718 * The 'alg' parameter, if present, has as value the AEAD 719 algorithm used in the group. 721 * The 'salt' parameter, if present, has as value the OSCORE 722 Master Salt. 724 * The 'contextId' parameter MUST be present and has as value the 725 Group Identifier (Gid), i.e. the OSCORE ID Context of the 726 OSCORE group. 728 * The 'cs_alg' parameter MUST be present and specifies the 729 algorithm used to countersign messages in the group. This 730 parameter takes values from the "Value" column of the "COSE 731 Algorithms" Registry [COSE.Algorithms]. 733 * The 'cs_params' parameter MAY be present and specifies the 734 parameters for the counter signature algorithm. This parameter 735 is a CBOR array, which includes the following two elements: 737 + 'sign_alg_capab', with the same encoding as defined in 738 Section 6.1. The value is the same as in the Token Post 739 response where the 'sign_parameters' value was non-null. 741 + 'sign_key_type_capab', with the same encoding as defined in 742 Section 6.1. The value is the same as in the Token Post 743 response where the 'sign_parameters' value was non-null. 745 * The 'cs_key_params' parameter MAY be present and specifies the 746 parameters for the key used with the counter signature 747 algorithm. This parameter is a CBOR array, with the same non- 748 null encoding and value as 'sign_key_parameters' of the 749 Section 6.1. 751 * The 'cs_key_enc' parameter MAY be present and specifies the 752 encoding of the public keys of the group members. This 753 parameter is a CBOR integer, whose value is 1 ("COSE_Key") 754 taken from the 'Confirmation Key' column of the "CWT 755 Confirmation Method" Registry [CWT.Confirmation.Methods], so 756 indicating that public keys in the OSCORE group are encoded as 757 COSE Keys [I-D.ietf-cose-rfc8152bis-struct]. Future 758 specifications may define additional values for this parameter. 760 If this parameter is not present, 1 ("COSE_Key") MUST be 761 assumed as default value. 763 o The 'exp' parameter MUST be present. 765 o The 'ace-groupcomm-profile' parameter MUST be present and has 766 value coap_group_oscore_app (TBD1), which is defined in 767 Section 20.1 of this specification. 769 o The 'pub_keys' parameter, if present, includes the public keys of 770 the group members that are relevant to the joining node. That is, 771 it includes: i) the public keys of the responders currently in the 772 group, in case the joining node is configured (also) as requester; 773 and ii) the public keys of the requesters currently in the group, 774 in case the joining node is configured (also) as responder or 775 monitor. If public keys are encoded as COSE_Keys, each of them 776 has as 'kid' the Sender ID that the corresponding owner has in the 777 group, thus used as group member identifier. 779 o The 'group_policies' parameter SHOULD be present, and SHOULD 780 include the following elements: 782 * "Sequence Number Synchronization Method" defined in 783 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm], with default 784 value 1 ("Best effort"); 786 * "Key Update Check Interval" defined in Section 4.1.2.1 of 787 [I-D.ietf-ace-key-groupcomm], with default value 3600; 789 * "Expiration Delta" defined in Section 4.1.2.1 of 790 [I-D.ietf-ace-key-groupcomm], with default value 0. 792 * "Group OSCORE Pairwise Mode Support" defined in Section 6.5 of 793 this specification, with default value False. 795 Finally, the joining node uses the information received in the 796 Joining Response to set up the OSCORE Security Context, as described 797 in Section 2 of [I-D.ietf-core-oscore-groupcomm]. In addition, the 798 joining node maintains an association between each public key 799 retrieved from the 'pub_keys' parameter and the role(s) that the 800 corresponding group member has in the group. 802 From then on, the joining node can exchange group messages secured 803 with Group OSCORE as described in [I-D.ietf-core-oscore-groupcomm]. 804 When doing so: 806 o The joining node MUST NOT process an incoming request message, if 807 signed by a group member whose public key is not associated to the 808 role "Requester". 810 o The joining node MUST NOT process an incoming response message, if 811 signed by a group member whose public key is not associated to the 812 role "Responder". 814 If the application requires backward security, the Group Manager MUST 815 generate updated security parameters and group keying material, and 816 provide it to the current group members upon the new node's joining 817 (see Section 17). As a consequence, the joining node is not able to 818 access secure communication in the group occurred prior its joining. 820 6.5. ACE Groupcomm Policy for Group OSCORE Pairwise Mode Support 822 This specifications defines the group policy "Group OSCORE Pairwise 823 Mode Support", for which it registers an entry in the "ACE Groupcomm 824 Policy" IANA Registry defined in Section 8.8 of 825 [I-D.ietf-ace-key-groupcomm]. 827 The corresponding element in the 'group_policies' parameter of the 828 Joining Response (see Section 6.4) encodes the CBOR simple value 829 True, if the OSCORE group supports the pairwise mode of Group OSCORE 830 [I-D.ietf-core-oscore-groupcomm], or the CBOR simple value False 831 otherwise (REQ14). 833 7. Public Keys of Joining Nodes 835 Source authentication of a message sent within the group and 836 protected with Group OSCORE is ensured by means of a digital counter 837 signature embedded in the message (in group mode), or by integrity- 838 protecting the message with pairwise keying material derived from the 839 asymmetric keys of sender and recipient (in pairwise mode). 841 Therefore, group members must be able to retrieve each other's public 842 key from a trusted key repository, in order to verify source 843 authenticity of incoming group messages. 845 As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group 846 Manager acts as trusted repository of the public keys of the group 847 members, and provides those public keys to group members if requested 848 to. Upon joining an OSCORE group, a joining node is thus expected to 849 provide its own public key to the Group Manager. 851 In particular, one of the following four cases can occur when a new 852 node joins an OSCORE group. 854 o The joining node is going to join the group exclusively as 855 monitor. That is, it is not going to send messages to the group, 856 and hence to produce signatures with its own private key. In this 857 case, the joining node is not required to provide its own public 858 key to the Group Manager, which thus does not have to perform any 859 check related to the public key encoding, or to a countersignature 860 algorithm and possible associated parameters for that joining 861 node. In case that joining node still provides a public key in 862 the 'client_cred' parameter of the Joining Request (see 863 Section 6.2), the Group Manager silently ignores that parameter, 864 as well as related the parameters 'cnonce' and 865 'client_cred_verify'. 867 o The Group Manager already acquired the public key of the joining 868 node during a past joining process. In this case, the joining 869 node MAY choose not to provide again its own public key to the 870 Group Manager, in order to limit the size of the Joining Request. 871 The joining node MUST provide its own public key again if it has 872 provided the Group Manager with multiple public keys during past 873 joining processes, intended for different OSCORE groups. If the 874 joining node provides its own public key, the Group Manager 875 performs consistency checks as per Section 6.3 and, in case of 876 success, considers it as the public key associated to the joining 877 node in the OSCORE group. 879 o The joining node and the Group Manager use an asymmetric proof-of- 880 possession key to establish a secure communication channel. Then, 881 two cases can occur. 883 1. The proof-of-possession key is compatible with the encoding as 884 well as with the counter signature algorithm and possible 885 associated parameters used in the OSCORE group. Then, the 886 Group Manager considers the proof-of-possession key as the 887 public key associated to the joining node in the OSCORE group. 888 If the joining node is aware that the proof-of-possession key 889 is also valid for the OSCORE group, it MAY not provide it 890 again as its own public key to the Group Manager. The joining 891 node MUST provide its own public key again if it has provided 892 the Group Manager with multiple public keys during past 893 joining processes, intended for different OSCORE groups. If 894 the joining node provides its own public key in the 895 'client_cred' parameter of the Joining Request (see 896 Section 6.2), the Group Manager performs consistency checks as 897 per Section 6.3 and, in case of success, considers it as the 898 public key associated to the joining node in the OSCORE group. 900 2. The proof-of-possession key is not compatible with the 901 encoding or with the counter signature algorithm and possible 902 associated parameters used in the OSCORE group. In this case, 903 the joining node MUST provide a different compatible public 904 key to the Group Manager in the 'client_cred' parameter of the 905 Joining Request (see Section 6.2). Then, the Group Manager 906 performs consistency checks on this latest provided public key 907 as per Section 6.3 and, in case of success, considers it as 908 the public key associated to the joining node in the OSCORE 909 group. 911 o The joining node and the Group Manager use a symmetric proof-of- 912 possession key to establish a secure communication channel. In 913 this case, upon performing a joining process with that Group 914 Manager for the first time, the joining node specifies its own 915 public key in the 'client_cred' parameter of the Joining Request 916 targeting the group-membership endpoint (see Section 6.2). 918 8. Retrieval of Updated Keying Material 920 At some point, a group member considers the OSCORE Security Context 921 invalid and to be renewed. This happens, for instance, after a 922 number of unsuccessful security processing of incoming messages from 923 other group members, or when the Security Context expires as 924 specified by the 'exp' parameter of the Joining Response. 926 When this happens, the group member retrieves updated security 927 parameters and group keying material. This can occur in the two 928 different ways described below. 930 8.1. Retrieval of Group Keying Material 932 If the group member wants to retrieve only the latest group keying 933 material, it sends a Key Distribution Request to the Group Manager. 935 In particular, it sends a CoAP GET request to the endpoint /group- 936 oscore/GROUPNAME at the Group Manager. 938 The Group Manager processes the Key Distribution Request according to 939 Section 4.1.2.2 of [I-D.ietf-ace-key-groupcomm]. The Key 940 Distribution Response is formatted as defined in Section 4.1.2.2 of 941 [I-D.ietf-ace-key-groupcomm]. In particular, the 'key' parameter is 942 formatted as defined in Section 6.4 of this specification, with the 943 difference that it does not include the 'clientId' parameter. 945 Upon receiving the Key Distribution Response, the group member 946 retrieves the updated security parameters and group keying material, 947 and, if they differ from the current ones, use them to set up the new 948 OSCORE Security Context as described in Section 2 of 949 [I-D.ietf-core-oscore-groupcomm]. 951 8.2. Retrieval of Group Keying Material and Sender ID 953 If the group member wants to retrieve the latest group keying 954 material as well as the Sender ID that it has in the OSCORE group, it 955 sends a Key Distribution Request to the Group Manager. 957 In particular, it sends a CoAP GET request to the endpoint /group- 958 oscore/GROUPNAME/nodes/NODENAME at the Group Manager. 960 The Group Manager processes the Key Distribution Request according to 961 Section 4.1.6.2 of [I-D.ietf-ace-key-groupcomm]. The Key 962 Distribution Response is formatted as defined in Section 4.1.6.2 of 963 [I-D.ietf-ace-key-groupcomm]. 965 In particular, the 'key' parameter is formatted as defined in 966 Section 6.4 of this specification, with the difference that if the 967 requesting group member has exclusively the role of monitor, no 968 'clientId' is specified within the 'key' parameter. Note that, in 969 any other case, the current Sender ID of the group member is not 970 specified as a separate parameter, but rather specified as 'clientId' 971 within the 'key' parameter. 973 Upon receiving the Key Distribution Response, the group member 974 retrieves the updated security parameters, group keying material and 975 Sender ID, and, if they differ from the current ones, use them to set 976 up the new OSCORE Security Context as described in Section 2 of 977 [I-D.ietf-core-oscore-groupcomm]. 979 9. Retrieval of New Keying Material 981 As discussed in Section 2.4.2 of [I-D.ietf-core-oscore-groupcomm], a 982 group member may at some point exhaust its Sender Sequence Numbers in 983 the group. 985 When this happens, the group member MUST send a Key Renewal Request 986 message to the Group Manager, as per Section 4.4 of 987 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP PUT 988 request to the endpoint /group-oscore/GROUPNAME/nodes/NODENAME at the 989 Group Manager. 991 Upon receiving the Key Renewal Request, the Group Manager processes 992 it as defined in Section 4.1.6.1 of [I-D.ietf-ace-key-groupcomm], and 993 performs one of the following actions. 995 1. If the requesting group member has exclusively the role of 996 monitor, the Group Manager replies with a 4.00 (Bad Request) 997 error response. 999 2. Otherwise, depending on the configured policies (OPT8), the Group 1000 Manager takes one of the following actions. 1002 a. The Group Manager rekeys the OSCORE group. That is, the 1003 Group Manager generates new group keying material for that group 1004 (see Section 17), and replies to the group member with a group 1005 rekeying message as defined in Section 17, providing the new 1006 group keying material. Then, the Group Manager rekeys the rest 1007 of the OSCORE group, as discussed in Section 17. 1009 b. The Group Manager generates a new Sender ID for that group 1010 member and replies with a Key Renewal Response, formatted as 1011 defined in Section 4.1.6.1 of [I-D.ietf-ace-key-groupcomm]. In 1012 particular, the CBOR Map in the response payload includes a 1013 single parameter 'clientId' defined in Section 20.5 of this 1014 document, specifying the new Sender ID of the group member 1015 encoded as a CBOR byte string. 1017 10. Retrieval of Public Keys of Group Members 1019 A group member or a signature verifier may need to retrieve the 1020 public keys of (other) group members. To this end, the group member 1021 or signature verifier sends a Public Key Request message to the Group 1022 Manager, as per Section 4.5 of [I-D.ietf-ace-key-groupcomm]. In 1023 particular, it sends the request to the endpoint /group- 1024 oscore/GROUPNAME/pub-key at the Group Manager. 1026 If the Public Key Request uses the method FETCH, the Public Key 1027 Request is formatted as defined in Section 4.1.3.1 of 1028 [I-D.ietf-ace-key-groupcomm]. In particular: 1030 o Each element (if any) of the first CBOR array is formatted as in 1031 the first CBOR array of the 'get_pub_keys' parameter of the 1032 Joining Request (see Section 6.2). 1034 o Each element (if any) of the second CBOR array is a CBOR byte 1035 string, which encodes the Sender ID of the group member for which 1036 the associated public key is requested. 1038 Upon receiving the Public Key Request, the Group Manager processes it 1039 as per Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm], 1040 depending on the request method being FETCH or GET, respectively. 1041 Additionally, if the Public Key Request uses the method FETCH, the 1042 Group Manager silently ignores identifiers included in the 1043 'get_pub_keys' parameter of the request that are not associated to 1044 any current group member. 1046 The success Public Key Response is formatted as defined in 1047 Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm], depending 1048 on the request method being FETCH or GET, respectively. 1050 11. Update of Public Key 1052 A group member may need to provide the Group Manager with its new 1053 public key to use in the group from then on, hence replacing the 1054 current one. This can be the case, for instance, if the 1055 countersignature algorithm and possible associated parameters used in 1056 the OSCORE group have been changed, and the current public key is not 1057 compatible with them. 1059 To this end, the group member sends a Public Key Update Request 1060 message to the Group Manager, as per Section 4.6 of 1061 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP POST 1062 request to the endpoint /group-oscore/GROUPNAME/nodes/NODENAME/pub- 1063 key at the Group Manager. 1065 Upon receiving the Group Leaving Request, the Group Manager processes 1066 it as per Section 4.1.7.1 of [I-D.ietf-ace-key-groupcomm], with the 1067 following additions. 1069 o If the requesting group member has exclusively the role of 1070 monitor, the Group Manager replies with a 4.00 (Bad request) error 1071 response. 1073 o The N_S signature challenge is computed as per point (3) in 1074 Section 6.2.1 (REQ17). 1076 o If the request is successfully processed, the Group Manager stores 1077 the association between i) the new public key of the group member; 1078 and ii) the Group Identifier (Gid), i.e. the OSCORE ID Context, 1079 associated to the OSCORE group together with the OSCORE Sender ID 1080 assigned to the group member in the group. The Group Manager MUST 1081 keep this association updated over time. 1083 12. Retrieval of Group Policies 1085 A group member may request the current policies used in the OSCORE 1086 group. To this end, the group member sends a Policies Request, as 1087 per Section 4.7 of [I-D.ietf-ace-key-groupcomm]. In particular, it 1088 sends a CoAP GET request to the endpoint /group-oscore/GROUPNAME/ 1089 policies at the Group Manager, where GROUPNAME is the name of the 1090 OSCORE group. 1092 Upon receiving the Policies Request, the Group Manager processes it 1093 as per Section 4.1.4.1 of [I-D.ietf-ace-key-groupcomm]. The success 1094 Policies Response is formatted as defined in Section 4.1.4.1 of 1095 [I-D.ietf-ace-key-groupcomm]. 1097 13. Retrieval of Keying Material Version 1099 A group member may request the current version of the keying material 1100 used in the OSCORE group. To this end, the group member sends a 1101 Version Request, as per Section 4.8 of [I-D.ietf-ace-key-groupcomm]. 1102 In particular, it sends a CoAP GET request to the endpoint /group- 1103 oscore/GROUPNAME/num at the Group Manager, where GROUPNAME is the 1104 name of the OSCORE group. 1106 Upon receiving the Version Request, the Group Manager processes it as 1107 per Section 4.1.5.1 of [I-D.ietf-ace-key-groupcomm]. The success 1108 Version Response is formatted as defined in Section 4.1.5.1 of 1109 [I-D.ietf-ace-key-groupcomm]. 1111 14. Retrieval of Group Status 1113 A group member may request the current status of the the OSCORE 1114 group, i.e. active or inactive. To this end, the group member sends 1115 a Group Status Request to the Group Manager. 1117 In particular, the group member sends a CoAP GET request to the 1118 endpoint /group-oscore/GROUPNAME/active at the Group Manager defined 1119 in Section 5 of this specification, where GROUPNAME is the name of 1120 the OSCORE group. The success Group Version Response is formatted as 1121 defined in Section 5 of this specification. 1123 Upon learning from a 2.05 (Content) response that the group is 1124 currently inactive, the group member SHOULD stop taking part in 1125 communications within the group, until it becomes active again. 1127 Upon learning from a 2.05 (Content) response that the group has 1128 become active again, the group member can resume taking part in 1129 communications within the group. 1131 Figure 2 gives an overview of the exchange described above. 1133 Group Group 1134 Member Manager 1135 | | 1136 |------ Group Status Request: GET ace-group/GID/active ------>| 1137 | | 1138 |<---------- Group Status Response: 2.05 (Content) -----------| 1139 | | 1141 Figure 2: Message Flow of Group Status Request-Response 1143 15. Request to Leave the Group 1145 A group member may request to leave the OSCORE group. To this end, 1146 the group member sends a Group Leaving Request, as per Section 4.9 of 1147 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP DELETE 1148 request to the endpoint /group-oscore/GROUPNAME/nodes/NODENAME at the 1149 Group Manager. 1151 Upon receiving the Group Leaving Request, the Group Manager processes 1152 it as per Section 4.1.6.3 of [I-D.ietf-ace-key-groupcomm]. 1154 16. Removal of a Group Member 1156 Other than after a spontaneous request to the Group Manager as 1157 described in Section 15, a node may be forcibly removed from the 1158 OSCORE group, e.g. due to expired or revoked authorization. 1160 If, upon joining the group (see Section 6.2), the leaving node 1161 specified a URI in the 'control_path' parameter defined in 1162 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm], the Group Manager 1163 MUST inform the leaving node of its eviction, by sending a DELETE 1164 request targeting the URI specified in the 'control_path' parameter 1165 (OPT9). 1167 If the leaving node has not exclusively the role of monitor, the 1168 Group Manager performs the following actions. 1170 o The Group Manager frees the OSCORE Sender ID value of the leaving 1171 node, which becomes available for possible upcoming joining nodes. 1173 o The Group Manager cancels the association between, on one hand, 1174 the public key of the leaving node and, on the other hand, the 1175 Group Identifier (Gid) associated to the OSCORE group together 1176 with the freed OSCORE Sender ID value. The Group Manager deletes 1177 the public key of the leaving node, if that public key has no 1178 remaining association with any pair (Gid, Sender ID). 1180 If the application requires forward security, the Group Manager MUST 1181 generate updated security parameters and group keying material, and 1182 provide it to the remaining group members (see Section 17). As a 1183 consequence, the leaving node is not able to acquire the new security 1184 parameters and group keying material distributed after its leaving. 1186 Same considerations in Section 5 of [I-D.ietf-ace-key-groupcomm] 1187 apply here as well, considering the Group Manager acting as KDC. 1189 17. Group Rekeying Process 1191 In order to rekey the OSCORE group, the Group Manager distributes a 1192 new Group Identifier (Gid), i.e. a new OSCORE ID Context; a new 1193 OSCORE Master Secret; and, optionally, a new OSCORE Master Salt for 1194 that group. When doing so, the Group Manager MUST increment the 1195 version number of the group keying material, before starting its 1196 distribution. 1198 Furthermore, the Group Manager MUST preserve the same unchanged 1199 Sender IDs for all group members. This avoids affecting the 1200 retrieval of public keys from the Group Manager as well as the 1201 verification of message countersignatures. 1203 The Group Manager MUST support at least the following group rekeying 1204 scheme. Future application profiles may define alternative message 1205 formats and distribution schemes. 1207 As group rekeying message, the Group Manager uses the same format of 1208 the Joining Response message in Section 6.4. In particular: 1210 o Only the parameters 'gkty', 'key', 'num', 'ace-groupcomm-profile' 1211 and 'exp' are present. 1213 o The 'ms' parameter of the 'key' parameter specifies the new OSCORE 1214 Master Secret value. 1216 o The 'contextId' parameter of the 'key' parameter specifies the new 1217 Group ID. 1219 The Group Manager separately sends a group rekeying message to each 1220 group member to be rekeyed. 1222 Each rekeying message MUST be secured with the pairwise secure 1223 communication channel between the Group Manager and the group member 1224 used during the joining process. In particular, each rekeying 1225 message can target the 'control_path' URI path defined in 1226 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm] (OPT9), if provided 1227 by the intended recipient upon joining the group (see Section 6.2). 1229 It is RECOMMENDED that the Group Manager gets confirmation of 1230 successful distribution from the group members, and admits a maximum 1231 number of individual retransmissions to non-confirming group members. 1233 This approach requires group members to act (also) as servers, in 1234 order to correctly handle unsolicited group rekeying messages from 1235 the Group Manager. In particular, if a group member and the Group 1236 Manager use OSCORE [RFC8613] to secure their pairwise communications, 1237 the group member MUST create a Replay Window in its own Recipient 1238 Context upon establishing the OSCORE Security Context with the Group 1239 Manager, e.g. by means of the OSCORE profile of ACE 1240 [I-D.ietf-ace-oscore-profile]. 1242 Group members and the Group Manager SHOULD additionally support 1243 alternative rekeying approaches that do not require group members to 1244 act (also) as servers. A number of such approaches are defined in 1245 Section 4.3 of [I-D.ietf-ace-key-groupcomm]. In particular, a group 1246 member may subscribe for updates to the group-membership resource of 1247 the group, at the endpoint /group-oscore/GROUPNAME/nodes/NODENAME of 1248 the Group Manager. This can rely on CoAP Observe [RFC7641] or on a 1249 full-fledged Pub-Sub model [I-D.ietf-core-coap-pubsub] with the Group 1250 Manager acting as Broker. 1252 In case the rekeying terminates and some group members have not 1253 received the new keying material, they will not be able to correctly 1254 process following secured messages exchanged in the group. These 1255 group members will eventually contact the Group Manager, in order to 1256 retrieve the current keying material and its version. 1258 Some of these group members may be in multiple groups, each 1259 associated to a different Group Manager. When failing to correctly 1260 process messages secured with the new keying material, these group 1261 members may not have sufficient information to determine which exact 1262 Group Manager they should contact, in order to retrieve the current 1263 keying material they are missing. 1265 If the Gid is formatted as described in Appendix C of 1266 [I-D.ietf-core-oscore-groupcomm], the Group Prefix can be used as a 1267 hint to determine the right Group Manager, as long as no collisions 1268 among Group Prefixes are experienced. Otherwise, a group member 1269 needs to contact the Group Manager of each group, e.g. by first 1270 requesting only the version of the current group keying material (see 1271 Section 13) and then possibly requesting the current keying material 1272 (see Section 8.1). 1274 Furthermore, some of these group members can be in multiple groups, 1275 all of which associated to the same Group Manager. In this case, 1276 these group members may also not have sufficient information to 1277 determine which exact group they should refer to, when contacting the 1278 right Group Manager. Hence, they need to contact a Group Manager 1279 multiple times, i.e. separately for each group they belong to and 1280 associated to that Group Manager. 1282 18. Default Values for Group Configuration Parameters 1284 This section defines the default values that the Group Manager 1285 assumes for the configuration parameters of an OSCORE group, unless 1286 differently specified when creating and configuring the group. This 1287 can be achieved as specified in [I-D.tiloca-ace-oscore-gm-admin]. 1289 The Group Manager SHOULD use the same default values defined in 1290 Section 3.2 of [RFC8613] for both the HKDF algorithm and the AEAD 1291 algorithm used in the group. 1293 The Group Manager SHOULD use the following default values for the 1294 algorithm, algorithm parameters and key parameters used to 1295 countersign messages in the group, consistently with the "COSE 1296 Algorithms" Registry [COSE.Algorithms], the "COSE Key Types" Registry 1297 [COSE.Key.Types] and the "COSE Elliptic Curves" Registry 1298 [COSE.Elliptic.Curves]. 1300 o For the algorithm 'cs_alg' used to countersign messages in the 1301 group, the signature algorithm EdDSA [RFC8032]. 1303 o For the parameters 'cs_params' of the counter signature algorithm: 1305 * The array [[OKP], [OKP, Ed25519]], indicating the elliptic 1306 curve Ed25519 [RFC8032], in case EdDSA is assumed or specified 1307 for 'cs_alg'. 1309 * The array [[EC2], [EC2, P-256]], indicating the elliptic curve 1310 P-256, in case ES256 [RFC6979] is specified for 'cs_alg'. 1312 * The array [[EC2], [EC2, P-384]], indicating the elliptic curve 1313 P-384, in case ES384 [RFC6979] is specified for 'cs_alg'. 1315 * The array [[EC2], [EC2, P-521]], indicating the elliptic curve 1316 P-521, in case ES512 [RFC6979] is specified for 'cs_alg'. 1318 * The array [[], [RSA]], in case PS256, PS384 or PS512 [RFC8017] 1319 is specified for 'cs_alg'. 1321 o For the parameters 'cs_key_params' of the key used with the 1322 counter signature algorithm: 1324 * The array [OKP, Ed25519] as pair (key type, elliptic curve), in 1325 case EdDSA is assumed or specified for 'cs_alg' and Ed25519 is 1326 assumed or specified within the second array of 'cs_params'. 1328 * The array [OKP, Ed448] as pair (key type, elliptic curve), in 1329 case EdDSA is assumed or specified for 'cs_alg' and the 1330 elliptic curve Ed448 [RFC8032] is specified within the second 1331 array of 'cs_params'. 1333 * The array [EC2, P-256] as pair (key type, elliptic curve), in 1334 case ES256 [RFC6979] is specified for 'cs_alg' and the elliptic 1335 curve P-256 is assumed or specified within the second array of 1336 'cs_params'. 1338 * The array [EC2, P-384] as pair (key type, elliptic curve), in 1339 case ES384 [RFC6979] is specified for 'cs_alg' and the elliptic 1340 curve P-384 is specified within the second array of 1341 'cs_params'. 1343 * The array [EC2, P-521] as pair (key type, elliptic curve), in 1344 case ES512 [RFC6979] is specified for 'cs_alg' and the elliptic 1345 curve P-521 is specified within the second array of 1346 'cs_params'. 1348 * The array [RSA] indicating RSA as key type, in case PS256, 1349 PS384 or PS512 [RFC8017] is specified for 'cs_alg'. 1351 o For the 'cs_key_enc' encoding of the public keys of the group 1352 members, COSE_Key from the "CWT Confirmation Methods" Registry 1353 [CWT.Confirmation.Methods]. 1355 19. Security Considerations 1357 Security considerations for this profile are inherited from 1358 [I-D.ietf-ace-key-groupcomm], the ACE framework for Authentication 1359 and Authorization [I-D.ietf-ace-oauth-authz], and the specific 1360 transport profile of ACE signalled by the AS, such as 1361 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile]. 1363 The following security considerations also apply for this profile. 1365 19.1. Management of OSCORE Groups 1367 This profile leverages the following management aspects related to 1368 OSCORE groups and discussed in the sections of 1369 [I-D.ietf-core-oscore-groupcomm] referred below. 1371 o Management of group keying material (see Section 3.1 of 1372 [I-D.ietf-core-oscore-groupcomm]). The Group Manager is 1373 responsible for the renewal and re-distribution of the keying 1374 material in the groups of its competence (rekeying). According to 1375 the specific application requirements, this can include rekeying 1376 the group upon changes in its membership. In particular, renewing 1377 the group keying material is required upon a new node's joining or 1378 a current node's leaving, in case backward security and forward 1379 security have to be preserved, respectively. 1381 o Provisioning and retrieval of public keys (see Section 2 of 1382 [I-D.ietf-core-oscore-groupcomm]). The Group Manager acts as key 1383 repository of public keys of group members, and provides them upon 1384 request. 1386 o Synchronization of sequence numbers (see Section 6.1 of 1387 [I-D.ietf-core-oscore-groupcomm]). This concerns how a responder 1388 node that has just joined an OSCORE group can synchronize with the 1389 sequence number of requesters in the same group. 1391 Before sending the Joining Response, the Group Manager MUST verify 1392 that the joining node actually owns the associated private key. To 1393 this end, the Group Manager can rely on the proof-of-possession 1394 challenge-response defined in Section 6. Alternatively, the joining 1395 node can use its own public key as asymmetric proof-of-possession key 1396 to establish a secure channel with the Group Manager, e.g. as in 1397 Section 3.2 of [I-D.ietf-ace-dtls-authorize]. However, this requires 1398 such proof-of-possession key to be compatible with the encoding as 1399 well as with the countersignature algorithm and possible associated 1400 parameters used in the OSCORE group. 1402 A node may have joined multiple OSCORE groups under different non- 1403 synchronized Group Managers. Therefore, it can happen that those 1404 OSCORE groups have the same Group Identifier (Gid). It follows that, 1405 upon receiving a Group OSCORE message addressed to one of those 1406 groups, the node would have multiple Security Contexts matching with 1407 the Gid in the incoming message. It is up to the application to 1408 decide how to handle such collisions of Group Identifiers, e.g. by 1409 trying to process the incoming message using one Security Context at 1410 the time until the right one is found. 1412 19.2. Size of Nonces for Signature Challenge 1414 With reference to the Joining Request message in Section 6.2, the 1415 proof-of-possession signature included in 'client_cred_verify' is 1416 computed over the challenge N_C | N_S, where | denotes concatenation. 1418 For the N_C challenge share, it is RECOMMENDED to use a 8-byte long 1419 random nonce. Furthermore, N_C is always conveyed in the 'cnonce' 1420 parameter of the Joining Request, which is always sent over the 1421 secure communication channel between the joining node and the Group 1422 Manager. 1424 As defined in Section 6.2.1, the way the N_S value is computed 1425 depends on the particular way the joining node provides the Group 1426 Manager with the Access Token, as well as on following interactions 1427 between the two. 1429 o If the Access Token is not explicitly posted to the /authz-info 1430 endpoint of the Group Manager, then N_S is computed as a 32-byte 1431 long challenge share (see points 2 of Section 6.2.1). 1433 o If the Access Token has been explicitly posted to the /authz-info 1434 endpoint of the Group Manager, N_S takes the most recent value 1435 specified to the client by the Group Manager in the 'kdcchallenge' 1436 parameter (see point 1 of Section 6.2.1). This is specified 1437 either in the 2.01 response to the Token Post (see Section 6.1), 1438 or in a 4.00 response to a following Joining Request (see 1439 Section 6.3). In either case, it is RECOMMENDED to use a 8-byte 1440 long random challenge as value for N_S. 1442 If we consider both N_C and N_S to take 8-byte long values, the 1443 following considerations hold. 1445 o Let us consider both N_C and N_S as taking random values, and the 1446 Group Manager to never change the value of the N_S provided to a 1447 Client during the lifetime of an Access Token. Then, as per the 1448 birthday paradox, the average collision for N_S will happen after 1449 2^32 new posted Access Tokens, while the average collision for N_C 1450 will happen after 2^32 new Joining Requests. This amounts to 1451 considerably more token provisionings than the expected new 1452 joinings of OSCORE groups under a same Group Manager, as well as 1453 to considerably more requests to join OSCORE groups from a same 1454 Client using a same Access Token under a same Group Manager. 1456 o Section 7 of [I-D.ietf-ace-oscore-profile] as well Appendix B.2 of 1457 [RFC8613] recommend the use of 8-byte random values as well. 1458 Unlike in those cases, the values of N_C and N_S considered in 1459 this specification are not used for as sensitive operations as the 1460 derivation of a Security Context, with possible implications in 1461 the security of AEAD ciphers. 1463 19.3. Reusage of Nonces for Signature Challenge 1465 As long as the Group Manager preserves the same N_S value currently 1466 associated to an Access Token, i.e. the latest value provided to a 1467 Client in a 'kdcchallenge' parameter, the Client is able to 1468 successfully reuse the same signature challenge for multiple Joining 1469 Requests to that Group Manager. 1471 In particular, the client can reuse the same N_C value for every 1472 Joining Request to the Group Manager, and combine it with the same 1473 unchanged N_S value. This results in reusing the same signature 1474 challenge for producing the signature to include in the 1475 'client_cred_verify' parameter of the Joining Requests. 1477 Unless the Group Manager maintains a list of N_C values already used 1478 by that Client since the latest update to the N_S value associated to 1479 the Access Token, the Group Manager can be forced to falsely believe 1480 that the Client possesses its own private key at that point in time, 1481 upon verifying the signature in the 'client_cred_verify' parameter. 1483 20. IANA Considerations 1485 Note to RFC Editor: Please replace all occurrences of "[[This 1486 specification]]" with the RFC number of this specification and delete 1487 this paragraph. 1489 This document has the following actions for IANA. 1491 20.1. ACE Groupcomm Profile Registry 1493 IANA is asked to register the following entry to the "ACE Groupcomm 1494 Profile" Registry defined in Section 8.7 of 1495 [I-D.ietf-ace-key-groupcomm]. 1497 o Name: coap_group_oscore_app 1499 o Description: Application profile to provision keying material for 1500 participating in group communication protected with Group OSCORE 1501 as per [I-D.ietf-core-oscore-groupcomm]. 1503 o CBOR Value: TBD1 1505 o Reference: [[This specification]] (Section 6.4) 1507 20.2. ACE Groupcomm Key Registry 1509 IANA is asked to register the following entry to the "ACE Groupcomm 1510 Key" Registry defined in Section 8.6 of [I-D.ietf-ace-key-groupcomm]. 1512 o Name: Group_OSCORE_Security_Context object 1514 o Key Type Value: TBD2 1516 o Profile: "coap_group_oscore_app", defined in Section 20.1 of this 1517 specification. 1519 o Description: A Group_OSCORE_Security_Context object encoded as 1520 described in Section 6.4 of this specification. 1522 o Reference: [[This specification]] (Section 6.4) 1524 20.3. OSCORE Security Context Parameters Registry 1526 IANA is asked to register the following entries in the "OSCORE 1527 Security Context Parameters" Registry defined in Section 9.4 of 1528 [I-D.ietf-ace-oscore-profile]. 1530 o Name: cs_alg 1532 o CBOR Label: TBD3 1534 o CBOR Type: tstr / int 1536 o Registry: COSE Algorithm Values (ECDSA, EdDSA) 1538 o Description: OSCORE Counter Signature Algorithm Value 1540 o Reference: [[This specification]] (Section 6.4) 1542 o Name: cs_params 1544 o CBOR Label: TBD4 1546 o CBOR Type: array 1548 o Registry: Counter Signatures Parameters 1550 o Description: OSCORE Counter Signature Algorithm Additional 1551 Parameters 1553 o Reference: [[This specification]] (Section 6.4) 1555 o Name: cs_key_params 1557 o CBOR Label: TBD5 1559 o CBOR Type: array 1561 o Registry: Counter Signatures Key Parameters 1563 o Description: OSCORE Counter Signature Key Additional Parameters 1565 o Reference: [[This specification]] (Section 6.4) 1566 o Name: cs_key_enc 1568 o CBOR Label: TBD6 1570 o CBOR Type: integer 1572 o Registry: ACE Public Key Encoding 1574 o Description: Encoding of Public Keys to be used with the OSCORE 1575 Counter Signature Algorithm 1577 o Reference: [[This specification]] (Section 6.4) 1579 20.4. Sequence Number Synchronization Method Registry 1581 IANA is asked to register the following entries in the "Sequence 1582 Number Synchronization Method" Registry defined in Section 8.9 of 1583 [I-D.ietf-ace-key-groupcomm]. 1585 o Name: Best effort 1587 o Value: 1 1589 o Description: No action is taken. 1591 o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.1) 1593 o Name: Baseline 1595 o Value: 2 1597 o Description: The first received request sets the baseline 1598 reference point, and is discarded with no delivery to the 1599 application. 1601 o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.2) 1603 o Name: Echo challenge-response 1605 o Value: 3 1607 o Description: Challenge response using the Echo Option for CoAP 1608 from [I-D.ietf-core-echo-request-tag]. 1610 o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.3) 1612 20.5. ACE Groupcomm Parameters Registry 1614 IANA is asked to register the following entry to the "ACE Groupcomm 1615 Parameters" Registry defined in Section 8.5 of 1616 [I-D.ietf-ace-key-groupcomm]. 1618 o Name: clientId 1620 o CBOR Key: TBD7 1622 o CBOR Type: Byte string 1624 o Reference: [[This specification]] (Section 9) 1626 20.6. ACE Groupcomm Policy Registry 1628 IANA is asked to register the following entry to the "ACE Groupcomm 1629 Policy" Registry defined in Section 8.8 of 1630 [I-D.ietf-ace-key-groupcomm]. 1632 o Name: Group OSCORE Pairwise Mode Support 1634 o CBOR Key: TBD8 1636 o CBOR Type: Simple value 1638 o Description: True if the OSCORE group supports the pairwise mode 1639 of Group OSCORE [I-D.ietf-core-oscore-groupcomm], False otherwise. 1641 o Reference: [[This specification]] (Section 6.5) 1643 20.7. TLS Exporter Label Registry 1645 IANA is asked to register the following entry to the "TLS Exporter 1646 Label" Registry defined in Section 6 of [RFC5705] and updated in 1647 Section 12 of [RFC8447]. 1649 o Value: EXPORTER-ACE-Sign-Challenge-coap-group-oscore-app 1651 o DTLS-OK: Y 1653 o Recommended: N 1655 o Reference: [[This specification]] (Section 6.2.1) 1657 20.8. AIF Registry 1659 IANA is asked to register the following entry to the "Toid" sub- 1660 registry of the "AIF" Registry defined in Section 5.2 of 1661 [I-D.bormann-core-ace-aif]. 1663 o Name: oscore-group-name 1665 o Description/Specification: group name of the OSCORE group, as 1666 specified in [[This specification]]. 1668 IANA is asked to register the following entry to the "Tperm" sub- 1669 Registry of the "AIF" Registry defined in Section 5.2 of 1670 [I-D.bormann-core-ace-aif]. 1672 o Name: oscore-group-roles 1674 o Description/Specification: role(s) of the member of the OSCORE 1675 group, as specified in [[This specification]]. 1677 20.9. Media Type Registrations 1679 This specification registers the 'application/aif-groupcomm- 1680 oscore+cbor' media type for the AIF specific data model AIF-OSCORE- 1681 GROUPCOMM defined in Section 3 of [[This specification]]. This 1682 registration follows the procedures specified in [RFC6838]. 1684 These media type has parameters for specifying the object identifier 1685 ("Toid") and set of permissions ("Tperm") defined for the AIF-generic 1686 model in [I-D.bormann-core-ace-aif]; default values are the values 1687 "oscore-group-name" for "Toid" and "oscore-group-roles" for "Tperm". 1689 Type name: application 1691 Subtype name: aif-groupcomm-oscore+cbor 1693 Required parameters: "Toid", "Tperm" 1695 Optional parameters: none 1697 Encoding considerations: Must be encoded as a CBOR array, each 1698 element of which is an array [Toid, Tperm] as defined in Section 3 of 1699 [[This specification]]. 1701 Security considerations: See Section 19 of [[This specification]]. 1703 Interoperability considerations: n/a 1704 Published specification: [[This specification]] 1706 Applications that use this media type: The type is used by 1707 applications that want to express authorization information about 1708 joining OSCORE groups, as specified in [[This specification]]. 1710 Additional information: 1712 Magic number(s): n/a 1714 File extension(s): .aif-groupcomm-oscore 1716 Macintosh file type code(s): n/a 1718 Person & email address to contact for further information: 1719 iesg@ietf.org [1] 1721 Intended usage: COMMON 1723 Restrictions on usage: None 1725 Author: Marco Tiloca marco.tiloca@ri.se [2] 1727 Change controller: IESG 1729 20.10. CoAP Content-Format Registry 1731 IANA is asked to register the following entry to the "CoAP Content- 1732 Formats" registry, within the "CoRE Parameters" registry: 1734 Media Type: application/aif-groupcomm-oscore+cbor;Toid="oscore-group- 1735 name",Tperm"oscore-group-roles" 1737 Encoding: - 1739 ID: TBD9 1741 Reference: [[This specification]] 1743 20.11. Group OSCORE Roles Registry 1745 This specification establishes the IANA "Group OSCORE Roles" 1746 Registry. The Registry has been created to use the "Expert Review 1747 Required" registration procedure [RFC8126]. Expert review guidelines 1748 are provided in Section 20.12. 1750 This registry includes the possible roles that nodes can take in an 1751 OSCORE group, each in combination with a numeric identifier. These 1752 numeric identifiers are used to express authorization information 1753 about joining OSCORE groups, as specified in Section 3 of [[This 1754 specification]]. 1756 The columns of this registry are: 1758 o Name: A value that can be used in documents for easier 1759 comprehension, to identify a possible role that nodes can take in 1760 an OSCORE group. 1762 o Value: The numeric identifier for this role. Integer values less 1763 than -65536 are marked as "Private Use", all other values use the 1764 registration policy "Expert Review" [RFC8126]. 1766 o Description: This field contains a brief description of the role. 1768 o Reference: This contains a pointer to the public specification for 1769 the role. 1771 This registry will be initially populated by the values in Figure 1. 1773 The Reference column for all of these entries will be [[This 1774 specification]]. 1776 20.12. Expert Review Instructions 1778 The IANA Registry established in this document is defined as "Expert 1779 Review". This section gives some general guidelines for what the 1780 experts should be looking for, but they are being designated as 1781 experts for a reason so they should be given substantial latitude. 1783 Expert reviewers should take into consideration the following points: 1785 o Clarity and correctness of registrations. Experts are expected to 1786 check the clarity of purpose and use of the requested entries. 1787 Experts should inspect the entry for the considered role, to 1788 verify the correctness of its description against the role as 1789 intended in the specification that defined it. Expert should 1790 consider requesting an opinion on the correctness of registered 1791 parameters from the Authentication and Authorization for 1792 Constrained Environments (ACE) Working Group and the Constrained 1793 RESTful Environments (CoRE) Working Group. 1795 Entries that do not meet these objective of clarity and 1796 completeness should not be registered. 1798 o Duplicated registration and point squatting should be discouraged. 1799 Reviewers are encouraged to get sufficient information for 1800 registration requests to ensure that the usage is not going to 1801 duplicate one that is already registered and that the point is 1802 likely to be used in deployments. 1804 o Experts should take into account the expected usage of roles when 1805 approving point assignment. Given a 'Value' V as code point, the 1806 length of the encoding of (2^(V+1) - 1) should be weighed against 1807 the usage of the entry, considering the resources and capabilities 1808 of devices it will be used on. Additionally, given a 'Value' V as 1809 code point, the length of the encoding of (2^(V+1) - 1) should be 1810 weighed against how many code points resulting in that encoding 1811 length are left, and the resources and capabilities of devices it 1812 will be used on. 1814 o Specifications are recommended. When specifications are not 1815 provided, the description provided needs to have sufficient 1816 information to verify the points above. 1818 21. References 1820 21.1. Normative References 1822 [COSE.Algorithms] 1823 IANA, "COSE Algorithms", 1824 . 1827 [COSE.Elliptic.Curves] 1828 IANA, "COSE Elliptic Curves", 1829 . 1832 [COSE.Key.Types] 1833 IANA, "COSE Key Types", 1834 . 1837 [CWT.Confirmation.Methods] 1838 IANA, "COSE Elliptic Curves", 1839 . 1842 [I-D.bormann-core-ace-aif] 1843 Bormann, C., "An Authorization Information Format (AIF) 1844 for ACE", draft-bormann-core-ace-aif-09 (work in 1845 progress), June 2020. 1847 [I-D.ietf-ace-key-groupcomm] 1848 Palombini, F. and M. Tiloca, "Key Provisioning for Group 1849 Communication using ACE", draft-ietf-ace-key-groupcomm-08 1850 (work in progress), July 2020. 1852 [I-D.ietf-ace-oauth-authz] 1853 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1854 H. Tschofenig, "Authentication and Authorization for 1855 Constrained Environments (ACE) using the OAuth 2.0 1856 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35 1857 (work in progress), June 2020. 1859 [I-D.ietf-ace-oscore-profile] 1860 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 1861 "OSCORE profile of the Authentication and Authorization 1862 for Constrained Environments Framework", draft-ietf-ace- 1863 oscore-profile-11 (work in progress), June 2020. 1865 [I-D.ietf-core-oscore-groupcomm] 1866 Tiloca, M., Selander, G., Palombini, F., and J. Park, 1867 "Group OSCORE - Secure Group Communication for CoAP", 1868 draft-ietf-core-oscore-groupcomm-09 (work in progress), 1869 June 2020. 1871 [I-D.ietf-cose-rfc8152bis-algs] 1872 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1873 Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-11 1874 (work in progress), July 2020. 1876 [I-D.ietf-cose-rfc8152bis-struct] 1877 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1878 Structures and Process", draft-ietf-cose-rfc8152bis- 1879 struct-11 (work in progress), July 2020. 1881 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1882 Requirement Levels", BCP 14, RFC 2119, 1883 DOI 10.17487/RFC2119, March 1997, 1884 . 1886 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1887 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1888 March 2010, . 1890 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1891 Specifications and Registration Procedures", BCP 13, 1892 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1893 . 1895 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 1896 Algorithm (DSA) and Elliptic Curve Digital Signature 1897 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 1898 2013, . 1900 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1901 Application Protocol (CoAP)", RFC 7252, 1902 DOI 10.17487/RFC7252, June 2014, 1903 . 1905 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 1906 "PKCS #1: RSA Cryptography Specifications Version 2.2", 1907 RFC 8017, DOI 10.17487/RFC8017, November 2016, 1908 . 1910 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1911 Signature Algorithm (EdDSA)", RFC 8032, 1912 DOI 10.17487/RFC8032, January 2017, 1913 . 1915 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1916 Writing an IANA Considerations Section in RFCs", BCP 26, 1917 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1918 . 1920 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1921 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1922 May 2017, . 1924 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1925 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1926 . 1928 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 1929 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 1930 . 1932 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1933 Definition Language (CDDL): A Notational Convention to 1934 Express Concise Binary Object Representation (CBOR) and 1935 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1936 June 2019, . 1938 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1939 "Object Security for Constrained RESTful Environments 1940 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1941 . 1943 21.2. Informative References 1945 [I-D.ietf-ace-dtls-authorize] 1946 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 1947 L. Seitz, "Datagram Transport Layer Security (DTLS) 1948 Profile for Authentication and Authorization for 1949 Constrained Environments (ACE)", draft-ietf-ace-dtls- 1950 authorize-12 (work in progress), July 2020. 1952 [I-D.ietf-core-coap-pubsub] 1953 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1954 Subscribe Broker for the Constrained Application Protocol 1955 (CoAP)", draft-ietf-core-coap-pubsub-09 (work in 1956 progress), September 2019. 1958 [I-D.ietf-core-echo-request-tag] 1959 Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, 1960 Request-Tag, and Token Processing", draft-ietf-core-echo- 1961 request-tag-09 (work in progress), March 2020. 1963 [I-D.ietf-core-groupcomm-bis] 1964 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1965 for the Constrained Application Protocol (CoAP)", draft- 1966 ietf-core-groupcomm-bis-00 (work in progress), March 2020. 1968 [I-D.tiloca-ace-oscore-gm-admin] 1969 Tiloca, M., Hoeglund, R., Stok, P., Palombini, F., and K. 1970 Hartke, "Admin Interface for the OSCORE Group Manager", 1971 draft-tiloca-ace-oscore-gm-admin-01 (work in progress), 1972 March 2020. 1974 [I-D.tiloca-core-oscore-discovery] 1975 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 1976 Groups with the CoRE Resource Directory", draft-tiloca- 1977 core-oscore-discovery-05 (work in progress), March 2020. 1979 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1980 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1981 January 2012, . 1983 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1984 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1985 . 1987 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1988 Application Protocol (CoAP)", RFC 7641, 1989 DOI 10.17487/RFC7641, September 2015, 1990 . 1992 21.3. URIs 1994 [1] mailto:iesg@ietf.org 1996 [2] mailto:marco.tiloca@ri.se 1998 Appendix A. Profile Requirements 2000 This appendix lists the specifications on this application profile of 2001 ACE, based on the requirements defined in Appendix A of 2002 [I-D.ietf-ace-key-groupcomm]. 2004 o REQ1 - Specify the encoding and value of the identifier of group, 2005 for scope entries of 'scope': see Section 3, Section 4.1 and 2006 Section 6.1. 2008 o REQ2 - Specify the encoding and value of roles, for scope entries 2009 of 'scope': see Section 3 and Section 4.1. 2011 o REQ3 - if used, specify the acceptable values for 'sign_alg': 2012 values from the "Value" column of the "COSE Algorithms" Registry 2013 [COSE.Algorithms]. 2015 o REQ4 - If used, specify the acceptable values for 2016 'sign_parameters': values from the COSE capabilities in the "COSE 2017 Algorithms" Registry [COSE.Algorithms] and from the COSE 2018 capabilities in the "COSE Key Types" Registry [COSE.Key.Types]. 2020 o REQ5 - If used, specify the acceptable values for 2021 'sign_key_parameters': values from the COSE capabilities in the 2022 "COSE Key Types" Registry [COSE.Key.Types]. 2024 o REQ6 - If used, specify the acceptable values for 'pub_key_enc': 1 2025 ("COSE_Key") from the 'Confirmation Key' column of the "CWT 2026 Confirmation Method" Registry [CWT.Confirmation.Methods]. Future 2027 specifications may define additional values for this parameter. 2029 o REQ7 - Format of the 'key' value: see Section 6.4. 2031 o REQ8 - Acceptable values of 'gkty': Group_OSCORE_Security_Context 2032 object (see Section 6.4). 2034 o REQ9: Specify the format of the identifiers of group members: see 2035 Section 6.4 and Section 10. 2037 o REQ10 - Specify the communication protocol that the members of the 2038 group must use: CoAP, possibly over IP multicast. 2040 o REQ11 - Specify the security protocols that the group members must 2041 use to protect their communication: Group OSCORE. 2043 o REQ12 - Specify and register the application profile identifier: 2044 coap_group_oscore_app (see Section 20.1). 2046 o REQ13 - Specify policies at the KDC to handle member ids that are 2047 not included in 'get_pub_keys': see Section 10. 2049 o REQ14 - If used, specify the content format and default value of 2050 'group_policies' and its entries: see Section 6.4; the three 2051 values defined and registered as content of the entry "Sequence 2052 Number Synchronization Method" (see Section 20.4); the defined and 2053 registered encoding of the entry "Group OSCORE Pairwise Mode 2054 Support" (see Section 20.6). 2056 o REQ15 - Specify the format of newly-generated individual keying 2057 material for group members, or of the information to derive it, 2058 and corresponding CBOR label: see Section 9. 2060 o REQ16 - Specify how the communication is secured between the 2061 Client and KDC: by means of any transport profile of ACE 2062 [I-D.ietf-ace-oauth-authz] between Client and Group Manager that 2063 complies with the requirements in Appendix C of 2064 [I-D.ietf-ace-oauth-authz]. 2066 o REQ17 - Specify how the nonce N_S is generated, if the token is 2067 not being posted (e.g. if it is used directly to validate TLS 2068 instead): see Section 6.2.1. 2070 o REQ18 - Specify if 'mgt_key_material' used, and if yes specify its 2071 format and content: not used in this version of the profile. 2073 o REQ19 - Define the initial value of the 'num' parameter: The 2074 initial value MUST be set to 0 when creating the OSCORE group, 2075 e.g. as in [I-D.tiloca-ace-oscore-gm-admin]. 2077 o OPT1 (Optional) - Specify the encoding of public keys, of 2078 'client_cred', and of 'pub_keys' if COSE_Keys are not used: no. 2080 o OPT2 (Optional) - Specify the negotiation of parameter values for 2081 signature algorithm and signature keys, if 'sign_info' is not 2082 used: possible early discovery by using the approach based on the 2083 CoRE Resource Directory described in 2084 [I-D.tiloca-core-oscore-discovery]. 2086 o OPT3 (Optional) - Specify the encoding of 'pub_keys_repos' if the 2087 default is not used: no. 2089 o OPT4 (Optional) - Specify policies that instruct clients to retain 2090 unsuccessfully decrypted messages and for how long, so that they 2091 can be decrypted after getting updated keying material: no. 2093 o OPT5 (Optional) - Specify the behavior of the handler in case of 2094 failure to retrieve a public key for the specific node: send a 2095 4.00 Bad Request response to a Joining Request (see Section 6.3). 2097 o OPT6 (Optional) - Specify possible or required payload formats for 2098 specific error cases: send a 4.00 Bad Request response to a 2099 Joining Request (see Section 6.3). 2101 o OPT7 (Optional) - Specify CBOR values to use for abbreviating 2102 identifiers of roles in the group or topic (see Section 4.1). 2104 o OPT8 (Optional) - Specify policies for the KDC to perform group 2105 rekeying after receiving a Key Renewal Request: no. 2107 o OPT9 (Optional) - Specify the functionalities implemented at the 2108 'control_path' resource hosted at the Client, including message 2109 exchange encoding and other details (see Section 4.1.2.1 of 2110 [I-D.ietf-ace-key-groupcomm]): see Section 16 for the eviction of 2111 a group member; see Section 17 for the group rekeying process. 2113 o OPT10 (Optional) - Specify how the identifier of the sender's 2114 public key is included in the group request: no. 2116 Appendix B. Document Updates 2118 RFC EDITOR: PLEASE REMOVE THIS SECTION. 2120 B.1. Version -07 to -08 2122 o AIF specific data model to express scope entries. 2124 o A set of roles is checked as valid when processing the Joining 2125 Request. 2127 o Updated format of 'get_pub_keys' in the Joining Request. 2129 o Payload format and default values of group policies in the Joining 2130 Response. 2132 o Updated payload format of the FETCH request to retrieve public 2133 keys. 2135 o Default values for group configuration parameters. 2137 o IANA registrations to support the AIF specific data model. 2139 B.2. Version -06 to -07 2141 o Alignments with draft-ietf-core-oscore-groupcomm. 2143 o New format of 'sign_info', using the COSE capabilities. 2145 o New format of Joining Response parameters, using the COSE 2146 capabilities. 2148 o Considerations on group rekeying. 2150 o Editorial revision. 2152 B.3. Version -05 to -06 2154 o Added role of external signature verifier. 2156 o Parameter 'rsnonce' renamed to 'kdcchallenge'. 2158 o Parameter 'kdcchallenge' may be omitted in some cases. 2160 o Clarified difference between group name and OSCORE Gid. 2162 o Removed the role combination ["requester", "monitor"]. 2164 o Admit implicit scope and audience in the Authorization Request. 2166 o New format for the 'sign_info' parameter. 2168 o Scope not mandatory to include in the Joining Request. 2170 o Group policy about supporting Group OSCORE in pairwise mode. 2172 o Possible individual rekeying of a single requesting node combined 2173 with a group rekeying. 2175 o Security considerations on reusage of signature challenges. 2177 o Addressing optional requirement OPT9 from draft-ietf-ace-key- 2178 groupcomm 2180 o Editorial improvements. 2182 B.4. Version -04 to -05 2184 o Nonce N_S also in error responses to the Joining Requests. 2186 o Supporting single Access Token for multiple groups/topics. 2188 o Supporting legal requesters/responders using the 'peer_roles' 2189 parameter. 2191 o Registered and used dedicated label for TLS Exporter. 2193 o Added method for uploading a new public key to the Group Manager. 2195 o Added resource and method for retrieving the current group status. 2197 o Fixed inconsistency in retrieving group keying material only. 2199 o Clarified retrieval of keying material for monitor-only members. 2201 o Clarification on incrementing version number when rekeying the 2202 group. 2204 o Clarification on what is re-distributed with the group rekeying. 2206 o Security considerations on the size of the nonces used for the 2207 signature challenge. 2209 o Added CBOR values to abbreviate role identifiers in the group. 2211 B.5. Version -03 to -04 2213 o New abstract. 2215 o Moved general content to draft-ietf-ace-key-groupcomm 2217 o Terminology: node name; node resource. 2219 o Creation and pointing at node resource. 2221 o Updated Group Manager API (REST methods and offered services). 2223 o Size of challenges 'cnonce' and 'rsnonce'. 2225 o Value of 'rsnonce' for reused or non-traditionally-posted tokens. 2227 o Removed reference to RFC 7390. 2229 o New requirements from draft-ietf-ace-key-groupcomm 2230 o Editorial improvements. 2232 B.6. Version -02 to -03 2234 o New sections, aligned with the interface of ace-key-groupcomm . 2236 o Exchange of information on the countersignature algorithm and 2237 related parameters, during the Token POST (Section 4.1). 2239 o Nonce 'rsnonce' from the Group Manager to the Client 2240 (Section 4.1). 2242 o Client PoP signature in the Key Distribution Request upon joining 2243 (Section 4.2). 2245 o Local actions on the Group Manager, upon a new node's joining 2246 (Section 4.2). 2248 o Local actions on the Group Manager, upon a node's leaving 2249 (Section 12). 2251 o IANA registration in ACE Groupcomm Parameters Registry. 2253 o More fulfilled profile requirements (Appendix A). 2255 B.7. Version -01 to -02 2257 o Editorial fixes. 2259 o Changed: "listener" to "responder"; "pure listener" to "monitor". 2261 o Changed profile name to "coap_group_oscore_app", to reflect it is 2262 an application profile. 2264 o Added the 'type' parameter for all requests to a Join Resource. 2266 o Added parameters to indicate the encoding of public keys. 2268 o Challenge-response for proof-of-possession of signature keys 2269 (Section 4). 2271 o Renamed 'key_info' parameter to 'sign_info'; updated its format; 2272 extended to include also parameters of the countersignature key 2273 (Section 4.1). 2275 o Code 4.00 (Bad request), in responses to joining nodes providing 2276 an invalid public key (Section 4.3). 2278 o Clarifications on provisioning and checking of public keys 2279 (Sections 4 and 6). 2281 o Extended discussion on group rekeying and possible different 2282 approaches (Section 7). 2284 o Extended security considerations: proof-of-possession of signature 2285 keys; collision of OSCORE Group Identifiers (Section 8). 2287 o Registered three entries in the IANA Registry "Sequence Number 2288 Synchronization Method Registry" (Section 9). 2290 o Registered one public key encoding in the "ACE Public Key 2291 Encoding" IANA Registry (Section 9). 2293 B.8. Version -00 to -01 2295 o Changed name of 'req_aud' to 'audience' in the Authorization 2296 Request (Section 3.1). 2298 o Added negotiation of countersignature algorithm/parameters between 2299 Client and Group Manager (Section 4). 2301 o Updated format of the Key Distribution Response as a whole 2302 (Section 4.3). 2304 o Added parameter 'cs_params' in the 'key' parameter of the Key 2305 Distribution Response (Section 4.3). 2307 o New IANA registrations in the "ACE Authorization Server Request 2308 Creation Hints" Registry, "ACE Groupcomm Key" Registry, "OSCORE 2309 Security Context Parameters" Registry and "ACE Groupcomm Profile" 2310 Registry (Section 9). 2312 Acknowledgments 2314 The authors sincerely thank Santiago Aragon, Stefan Beck, Carsten 2315 Bormann, Martin Gunnarsson, Rikard Hoeglund, Daniel Migault, Jim 2316 Schaad, Ludwig Seitz, Goeran Selander and Peter van der Stok for 2317 their comments and feedback. 2319 The work on this document has been partly supported by VINNOVA and 2320 the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact 2321 Initiative ACTIVE. 2323 Authors' Addresses 2325 Marco Tiloca 2326 RISE AB 2327 Isafjordsgatan 22 2328 Kista SE-164 29 Stockholm 2329 Sweden 2331 Email: marco.tiloca@ri.se 2333 Jiye Park 2334 Universitaet Duisburg-Essen 2335 Schuetzenbahn 70 2336 Essen 45127 2337 Germany 2339 Email: ji-ye.park@uni-due.de 2341 Francesca Palombini 2342 Ericsson AB 2343 Torshamnsgatan 23 2344 Kista SE-16440 Stockholm 2345 Sweden 2347 Email: francesca.palombini@ericsson.com