idnits 2.17.1 draft-ietf-ace-key-groupcomm-oscore-07.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 (June 18, 2020) is 1401 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-ace-key-groupcomm-07 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-33 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-10 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-08 == Outdated reference: A later version (-12) exists of draft-ietf-cose-rfc8152bis-algs-09 ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') == Outdated reference: A later version (-15) exists of draft-ietf-cose-rfc8152bis-struct-10 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-10 == 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 (-10) 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: 1 error (**), 0 flaws (~~), 13 warnings (==), 3 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: December 20, 2020 Universitaet Duisburg-Essen 6 F. Palombini 7 Ericsson AB 8 June 18, 2020 10 Key Management for OSCORE Groups in ACE 11 draft-ietf-ace-key-groupcomm-oscore-07 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 December 20, 2020. 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. Joining Node to Authorization Server . . . . . . . . . . . . 7 67 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 7 68 3.2. Authorization Response . . . . . . . . . . . . . . . . . 8 69 4. Interface at the Group Manager . . . . . . . . . . . . . . . 8 70 4.1. GET Handler . . . . . . . . . . . . . . . . . . . . . . . 8 71 5. Token POST and Group Joining . . . . . . . . . . . . . . . . 9 72 5.1. Token Post . . . . . . . . . . . . . . . . . . . . . . . 9 73 5.2. Sending the Joining Request . . . . . . . . . . . . . . . 10 74 5.2.1. Value of the N_S Challenge . . . . . . . . . . . . . 11 75 5.3. Processing the Joining Request . . . . . . . . . . . . . 12 76 5.4. Joining Response . . . . . . . . . . . . . . . . . . . . 13 77 5.5. ACE Groupcomm Policy for Group OSCORE Pairwise Mode 78 Support . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 6. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 16 80 7. Retrieval of Updated Keying Material . . . . . . . . . . . . 18 81 7.1. Retrieval of Group Keying Material . . . . . . . . . . . 18 82 7.2. Retrieval of Group Keying Material and Sender ID . . . . 19 83 8. Retrieval of New Keying Material . . . . . . . . . . . . . . 19 84 9. Retrieval of Public Keys of Group Members . . . . . . . . . . 20 85 10. Update of Public Key . . . . . . . . . . . . . . . . . . . . 21 86 11. Retrieval of Group Policies . . . . . . . . . . . . . . . . . 21 87 12. Retrieval of Keying Material Version . . . . . . . . . . . . 22 88 13. Retrieval of Group Status . . . . . . . . . . . . . . . . . . 22 89 14. Request to Leave the Group . . . . . . . . . . . . . . . . . 23 90 15. Removal of a Group Member . . . . . . . . . . . . . . . . . . 23 91 16. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 24 92 17. Security Considerations . . . . . . . . . . . . . . . . . . . 26 93 17.1. Management of OSCORE Groups . . . . . . . . . . . . . . 26 94 17.2. Size of Nonces for Signature Challenge . . . . . . . . . 27 95 17.3. Reusage of Nonces for Signature Challenge . . . . . . . 28 96 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 97 18.1. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 28 98 18.2. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 29 99 18.3. OSCORE Security Context Parameters Registry . . . . . . 29 100 18.4. Sequence Number Synchronization Method Registry . . . . 30 101 18.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . 31 102 18.6. ACE Groupcomm Policy Registry . . . . . . . . . . . . . 31 103 18.7. TLS Exporter Label Registry . . . . . . . . . . . . . . 32 104 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 105 19.1. Normative References . . . . . . . . . . . . . . . . . . 32 106 19.2. Informative References . . . . . . . . . . . . . . . . . 34 107 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 35 108 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 37 109 B.1. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 37 110 B.2. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 38 111 B.3. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 38 112 B.4. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 39 113 B.5. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 39 114 B.6. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 40 115 B.7. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 41 116 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 119 1. Introduction 121 Object Security for Constrained RESTful Environments (OSCORE) 122 [RFC8613] is a method for application-layer protection of the 123 Constrained Application Protocol (CoAP) [RFC7252], using CBOR Object 124 Signing and Encryption (COSE) 125 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs] and 126 enabling end-to-end security of CoAP payload and options. 128 As described in [I-D.ietf-core-oscore-groupcomm], Group OSCORE is 129 used to protect CoAP group communication over IP multicast 130 [I-D.ietf-core-groupcomm-bis]. This relies on a Group Manager, which 131 is responsible for managing an OSCORE group and enables the group 132 members to exchange CoAP messages secured with Group OSCORE. The 133 Group Manager can be responsible for multiple groups, coordinates the 134 joining process of new group members, and is entrusted with the 135 distribution and renewal of group keying material. 137 This specification is an application profile of 138 [I-D.ietf-ace-key-groupcomm], which itself builds on the ACE 139 framework for Authentication and Authorization 140 [I-D.ietf-ace-oauth-authz]. Message exchanges among the participants 141 as well as message formats and processing follow what specified in 142 [I-D.ietf-ace-key-groupcomm] for provisioning and renewing keying 143 material in group communication scenarios, where Group OSCORE is used 144 to protect CoAP group communication over IP multicast. 146 1.1. Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 150 "OPTIONAL" in this document are to be interpreted as described in BCP 151 14 [RFC2119][RFC8174] when, and only when, they appear in all 152 capitals, as shown here. 154 Readers are expected to be familiar with: 156 o The terms and concepts described in the ACE framework for 157 authentication and authorization [I-D.ietf-ace-oauth-authz]. The 158 terminology for entities in the considered architecture is defined 159 in OAuth 2.0 [RFC6749]. In particular, this includes Client (C), 160 Resource Server (RS), and Authorization Server (AS). 162 o The terms and concepts related to the CoAP protocol described in 163 [RFC7252][I-D.ietf-core-groupcomm-bis]. Unless otherwise 164 indicated, the term "endpoint" is used here following its OAuth 165 definition, aimed at denoting resources such as /token and 166 /introspect at the AS and /authz-info at the RS. This document 167 does not use the CoAP definition of "endpoint", which is "An 168 entity participating in the CoAP protocol". 170 o The terms and concept related to the message formats and 171 processing specified in [I-D.ietf-ace-key-groupcomm], for 172 provisioning and renewing keying material in group communication 173 scenarios. 175 o The terms and concepts for protection and processing of CoAP 176 messages through OSCORE [RFC8613] and through Group OSCORE 177 [I-D.ietf-core-oscore-groupcomm] in group communication scenarios. 178 These include the concept of Group Manager, as the entity 179 responsible for a set of groups where communications are secured 180 with Group OSCORE. In this specification, the Group Manager acts 181 as Resource Server. 183 Additionally, this document makes use of the following terminology. 185 o Group name is used as a synonym for group identifier in 186 [I-D.ietf-ace-key-groupcomm]. 188 o Requester: member of an OSCORE group that sends request messages 189 to other members of the group. 191 o Responder: member of an OSCORE group that receives request 192 messages from other members of the group. A responder may reply 193 back, by sending a response message to the requester which has 194 sent the request message. 196 o Monitor: member of an OSCORE group that is configured as responder 197 and never replies back to requesters after receiving request 198 messages. This corresponds to the term "silent server" used in 199 [I-D.ietf-core-oscore-groupcomm]. 201 o Signature verifier: entity external to the OSCORE group and 202 intended to verify the countersignature of messages exchanged in 203 the group. An authorized signature verifier does not join the 204 OSCORE group as an actual member, yet it can retrieve the public 205 keys of the current group members from the Group Manager. 207 2. Protocol Overview 209 Group communication for CoAP over IP multicast has been enabled in 210 [I-D.ietf-core-groupcomm-bis] and can be secured with Group Object 211 Security for Constrained RESTful Environments (OSCORE) [RFC8613] as 212 described in [I-D.ietf-core-oscore-groupcomm]. A network node joins 213 an OSCORE group by interacting with the responsible Group Manager. 214 Once registered in the group, the new node can securely exchange 215 messages with other group members. 217 This specification describes how to use [I-D.ietf-ace-key-groupcomm] 218 and [I-D.ietf-ace-oauth-authz] to perform a number of authentication, 219 authorization and key distribution actions, as defined in Section 2 220 of [I-D.ietf-ace-key-groupcomm], for an OSCORE group. 222 With reference to [I-D.ietf-ace-key-groupcomm]: 224 o The node wishing to joining the OSCORE group, i.e. the joining 225 node, is the Client. 227 o The Group Manager is the Key Distribution Center (KDC), acting as 228 a Resource Server. 230 o The Authorization Server associated to the Group Manager is the 231 AS. 233 All communications between the involved entities MUST be secured. 235 In particular, communications between the Client and the Group 236 Manager leverage protocol-specific transport profiles of ACE to 237 achieve communication security, proof-of-possession and server 238 authentication. Note that it is expected that in the commonly 239 referred base-case of this specification, the transport profile to 240 use is pre-configured and well-known to nodes participating in 241 constrained applications. 243 2.1. Overview of the Joining Process 245 A node performs the steps described in Section 4.2 of 246 [I-D.ietf-ace-key-groupcomm] in order to join an OSCORE group. The 247 format and processing of messages exchanged among the participants 248 are further specified in Section 3 and Section 5 of this document. 250 2.2. Overview of the Group Rekeying Process 252 If the application requires backward and forward security, the Group 253 Manager MUST generate new keying material and distribute it to the 254 group (rekeying) upon membership changes. 256 That is, the group is rekeyed when a node joins the group as a new 257 member, or after a current member leaves the group. By doing so, a 258 joining node cannot access communications in the group prior its 259 joining, while a leaving node cannot access communications in the 260 group after its leaving. 262 The keying material distributed through a group rekeying MUST 263 include: 265 o a new Group Identifier (Gid) for the group, used as ID Context 266 parameter of the OSCORE Common Security Context of that group (see 267 Section 2 of [I-D.ietf-core-oscore-groupcomm]). Note that the Gid 268 differs from the plain group name introduced in Section 1.1, which 269 is a plain, stable and invariant identifier, with no cryptographic 270 relevance and meaning. 272 o a new value for the Master Secret parameter of the OSCORE Common 273 Security Context of that group (see Section 2 of 274 [I-D.ietf-core-oscore-groupcomm]). 276 Also, the distributed keying material MAY include a new value for the 277 Master Salt parameter of the OSCORE Common Security Context of that 278 group. 280 Upon generating the new group keying material and before starting its 281 distribution, the Group Manager MUST increment the version number of 282 the group keying material. When rekeying a group, the Group Manager 283 MUST preserve the current value of the Sender ID of each member in 284 that group. 286 The Group Manager MUST support the Group Rekeying Process described 287 in Section 16. Future application profiles may define alternative 288 message formats and distribution schemes to perform group rekeying. 290 3. Joining Node to Authorization Server 292 This section describes how the joining node interacts with the AS in 293 order to be authorized to join an OSCORE group under a given Group 294 Manager. In particular, it considers a joining node that intends to 295 contact that Group Manager for the first time. 297 The message exchange between the joining node and the AS consists of 298 the messages Authorization Request and Authorization Response defined 299 in Section 3 of [I-D.ietf-ace-key-groupcomm]. Note that what is 300 defined in [I-D.ietf-ace-key-groupcomm] applies, and only additions 301 or modifications to that specification are defined here. 303 3.1. Authorization Request 305 The Authorization Request message is as defined in Section 3.1 of 306 [I-D.ietf-ace-key-groupcomm], with the following additions. 308 o If the 'scope' parameter is present: 310 * The group name of each OSCORE group to join under the Group 311 Manager is encoded as a CBOR text string (REQ1). 313 * Accepted values for role identifiers in the OSCORE group to 314 join are: "requester", "responder", and "monitor" (REQ2). 315 Possible combinations are: ["requester" , "responder"]. An 316 additional role identifier is "verifier", denoting an external 317 signature verifier that does not join the OSCORE group. Each 318 role identifier MUST be encoded as a CBOR integer (REQ2), by 319 using for abbreviation the values specified in Figure 1 (OPT7) 320 (see Appendix A). 322 +-----------+------------+ 323 | Name | CBOR Value | 324 +-----------+------------+ 325 | requester | TBD8 | 326 | responder | TBD9 | 327 | monitor | TBD10 | 328 | verifier | TBD11 | 329 +-----------+------------+ 331 Figure 1: CBOR Abbreviations for Role Identifiers in the Group 333 3.2. Authorization Response 335 The Authorization Response message is as defined in Section 3.2 of 336 [I-D.ietf-ace-key-groupcomm], with the following additions: 338 o The AS MUST include the 'expires_in' parameter. Other means for 339 the AS to specify the lifetime of Access Tokens are out of the 340 scope of this specification. 342 o The AS MUST include the 'scope' parameter, when the value included 343 in the Access Token differs from the one specified by the joining 344 node in the request. In such a case, the second element of each 345 scope entry MUST be present, and includes the role or CBOR array 346 of roles that the joining node is actually authorized to take in 347 the OSCORE group for that scope entry, encoded as specified in 348 Section 3.1 of this document. 350 4. Interface at the Group Manager 352 The Group Manager provides the interface defined in Section 4.1 of 353 [I-D.ietf-ace-key-groupcomm], with the following additional resource: 355 o /group-oscore/GROUPNAME/active: this sub-resource is fixed and 356 supports the GET method, whose handler is defined in Section 4.1. 358 4.1. GET Handler 360 The handler expects a GET request. 362 The handler verifies that the group identifier of the /group- 363 oscore/GROUPNAME/active path is a subset of the 'scope' stored in the 364 Access Token associated to the requesting client. If verification 365 fails, the Group Manager MUST respond with a 4.01 (Unauthorized) 366 error message. 368 If verification succeeds, the handler returns a 2.05 (Content) 369 message containing the CBOR simple value True if the group is 370 currently active, or the CBOR simple value False otherwise. The 371 group is considered active if it is set to allow new members to join, 372 and if communication within the group is expected. 374 The method to set the current group status, i.e. active or inactive, 375 is out of the scope of this specification, and is defined for the 376 administrator interface of the Group Manager specified in 377 [I-D.tiloca-ace-oscore-gm-admin]. 379 5. Token POST and Group Joining 381 The following subsections describe the interactions between the 382 joining node and the Group Manager, i.e. the sending of the Access 383 Token and the Request-Response exchange to join the OSCORE group. 384 The message exchange between the joining node and the KDC consists of 385 the messages defined in Section 3.3 and 4.2 of 386 [I-D.ietf-ace-key-groupcomm]. Note that what is defined in 387 [I-D.ietf-ace-key-groupcomm] applies, and only additions or 388 modifications to that specification are defined here. 390 A signature verifier provides the Group Manager with an Access Token, 391 as described in Section 5.1, just as any another joining node does. 392 However, unlike candidate group members, it does not join any OSCORE 393 group, i.e. it does not perform the joining process defined in 394 Section 5.2. After a successful token posting, a signature verifier 395 is authorized to perform only the operations specified in Section 9, 396 to retrieve the public keys of group members, and only for the OSCORE 397 groups specified in the validated Access Token. The Group Manager 398 MUST respond with a 4.01 (Unauthorized) error message, in case a 399 signature verifier attempts to access any other endpoint than /group- 400 oscore/GROUPNAME/pub-key at the Group Manager. 402 5.1. Token Post 404 The Token post exchange is defined in Section 3.3 of 405 [I-D.ietf-ace-key-groupcomm]. 407 Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the 408 following applies. 410 o The 'kdcchallenge' parameter contains a dedicated nonce N_S 411 generated by the Group Manager. For the N_S value, it is 412 RECOMMENDED to use a 8-byte long random nonce. The joining node 413 may use this nonce in order to prove the possession of its own 414 private key, upon joining the group (see Section 5.2). 416 The 'kdcchallenge' parameter MAY be omitted from the 2.01 417 (Created) response, if the 'scope' of the Access Token includes 418 only the role "monitor" or only the role "verifier", for each of 419 the specified groups. 421 o If the 'sign_info' parameter is present in the response, the 422 following applies for each element 'sign_info_entry'. 424 * In the 'id' element, every group name is encoded as a CBOR text 425 string (REQ1) (see Appendix A). 427 * 'sign_alg' takes value from the "Value" column of the "COSE 428 Algorithms" Registry [COSE.Algorithms], if not encoding the 429 CBOR simple value Null. 431 * If not encoding the CBOR simple value Null, 'sign_parameters' 432 is a CBOR array including the following two elements: 434 + 'sign_alg_capab', encoded as a CBOR array. Its precise 435 format and value is the same as the COSE capabilities entry 436 in the "Capabilities" column of the "COSE Algorithms" 437 Registry [COSE.Algorithms], for the algorithm indicated in 438 'sign_alg' (REQ4). 440 + 'sign_key_type_capab', encoded as a CBOR array. Its precise 441 format and value is the same as the COSE capabilities entry 442 in the "Capabilities" column of the "COSE Key Types" 443 Registry [COSE.Key.Types], for the algorithm indicated in 444 'sign_alg' (REQ4). 446 * If not encoding the CBOR simple value Null, 447 'sign_key_parameters' is a CBOR array. Its precise format and 448 value is the same as the COSE capabilities entry in the 449 "Capabilities" column of the "COSE Key Types" Registry 450 [COSE.Key.Types], for the algorithm indicated in 'sign_alg' 451 (REQ5). 453 * If 'pub_key_enc_res' is present, it takes value 1 ("COSE_Key") 454 from the 'Confirmation Key' column of the "CWT Confirmation 455 Method" Registry defined in [RFC8747], so indicating that 456 public keys in the OSCORE group are encoded as COSE Keys 457 [I-D.ietf-cose-rfc8152bis-struct]. Future specifications may 458 define additional values for this parameter. 460 Note that, other than through the above parameters as defined in 461 Section 3.3 of [I-D.ietf-ace-key-groupcomm], the joining node MAY 462 have previously retrieved this information by other means, e.g. by 463 using the approach described in [I-D.tiloca-core-oscore-discovery]. 465 Additionally, if allowed by the used transport profile of ACE, the 466 joining node may instead provide the Access Token to the Group 467 Manager by other means, e.g. during a secure session establishment 468 (see Section 3.3.1 of [I-D.ietf-ace-dtls-authorize]). 470 5.2. Sending the Joining Request 472 The joining node requests to join the OSCORE group, by sending a 473 Joining Request message to the related group-membership resource at 474 the Group Manager, as per Section 4.2 of 475 [I-D.ietf-ace-key-groupcomm]. 477 Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the 478 following applies. 480 o The string "group-oscore" is used instead of "ace-group" (see 481 Section 4.1 of [I-D.ietf-ace-key-groupcomm]) as the top level path 482 to the group-membership resource. The url-path /group-oscore/ is 483 a default name of this specifications: implementations are not 484 required to use this name, and can define their own instead. 486 o The 'get_pub_keys' parameter is present only if the joining node 487 wants to retrieve the public keys of the group members from the 488 Group Manager during the joining process (see Section 6). 489 Otherwise, this parameter MUST NOT be present. 491 o 'cnonce' contains a dedicated nonce N_C generated by the joining 492 node. For the N_C value, it is RECOMMENDED to use a 8-byte long 493 random nonce. 495 o The signature encoded in the 'client_cred_verify' parameter is 496 computed by the joining node by using the same private key and 497 countersignature algorithm it intends to use for signing messages 498 in the OSCORE group. Moreover, N_S is as defined in 499 Section 5.2.1. 501 5.2.1. Value of the N_S Challenge 503 The value of the N_S challenge is determined as follows. 505 1. If the joining node has posted the Access Token to the /authz- 506 info endpoint of the Group Manager as in Section 5.1, N_S takes 507 the same value of the most recent 'kdcchallenge' parameter 508 received by the joining node from the Group Manager. This can be 509 either the one specified in the 2.01 (Created) response to the 510 Token POST, or the one possibly specified in a 4.00 (Bad Request) 511 response to a following Joining Request (see Section 5.3). 513 2. If the Token posting has relied on the DTLS profile of ACE 514 [I-D.ietf-ace-dtls-authorize] with the Access Token as content of 515 the "psk_identity" field of the ClientKeyExchange message 516 [RFC6347], N_S is an exporter value computed as defined in 517 Section 7.5 of [RFC8446]. Specifically, N_S is exported from the 518 DTLS session between the joining node and the Group Manager, 519 using an empty 'context_value', 32 bytes as 'key_length', and the 520 exporter label "EXPORTER-ACE-Sign-Challenge-coap-group-oscore- 521 app" defined in Section 18.7 of this specification. 523 It is up to applications to define how N_S is computed in further 524 alternative settings. 526 Section 17.3 provides security considerations on the reusage of the 527 N_S challenge. 529 5.3. Processing the Joining Request 531 The Group Manager processes the Joining Request as defined in 532 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm]. Additionally, the 533 following applies. 535 o In case the Joining Request does not include the 'client_cred' 536 parameter, the joining process fails if the Group Manager either: 537 i) does not store a public key with an accepted format for the 538 joining node; or ii) stores multiple public keys with an accepted 539 format for the joining node. 541 o To compute the signature contained in 'client_cred_verify', the GM 542 considers: i) as signed value, N_S concatenated with N_C, where 543 N_S is determined as described in Section 5.2.1, while N_C is the 544 nonce provided in the 'cnonce' parameter of the Joining Request; 545 ii) the countersignature algorithm used in the OSCORE group, and 546 possible correponding parameters; and iii) the public key of the 547 joining node, either retrieved from the 'client_cred' parameter, 548 or already stored as acquired from previous interactions with the 549 joining node. 551 o A 4.00 Bad Request response from the Group Manager to the joining 552 node MUST have content format application/ace+cbor. The response 553 payload is a CBOR map which MUST contain the 'sign_info' 554 parameter, including a single element 'sign_info_entry' pertaining 555 the OSCORE group that the joining node tried to join with the 556 Joining Request. 558 o The Group Manager MUST return a 4.00 (Bad Request) response in 559 case the Joining Request includes the 'client_cred' parameter but 560 does not include both the 'cnonce' and 'client_cred_verify' 561 parameters. 563 o The Group Manager MUST return a 4.00 (Bad Request) response in 564 case it cannot retrieve a public key with an accepted format for 565 the joining node, either from the 'client_cred' parameter or as 566 already stored. 568 o When receiving a 4.00 Bad Request response, the joining node 569 SHOULD send a new Joining Request to the Group Manager, where: 571 * The 'cnonce' parameter MUST include a new dedicated nonce N_C 572 generated by the joining node. 574 * The 'client_cred' parameter MUST include a public key 575 compatible with the encoding, countersignature algorithm and 576 possible associated parameters indicated by the Group Manager. 578 * The 'client_cred_verify' parameter MUST include a signature 579 computed as described in Section 5.2, by using the public key 580 indicated in the current 'client_cred' parameter, with the 581 countersignature algorithm and possible associated parameters 582 indicated by the Group Manager. If the error response from the 583 Group Manager included the 'kdcchallenge' parameter, the 584 joining node MUST use its content as new N_S challenge to 585 compute the signature. 587 5.4. Joining Response 589 If the processing of the Joining Request described in Section 5.3 is 590 successful, the Group Manager updates the group membership by 591 registering the joining node NODENAME as a new member of the OSCORE 592 group GROUPNAME, as described in Section 4.1.2.1 of 593 [I-D.ietf-ace-key-groupcomm]. 595 If the joining node is not exclusively configured as monitor, the 596 Group Manager performs also the following actions. 598 o The Group Manager selects an available OSCORE Sender ID in the 599 OSCORE group, and exclusively assigns it to the joining node. 601 o The Group Manager stores the association between i) the public key 602 of the joining node; and ii) the Group Identifier (Gid), i.e. the 603 OSCORE ID Context, associated to the OSCORE group together with 604 the OSCORE Sender ID assigned to the joining node in the group. 605 The Group Manager MUST keep this association updated over time. 607 Then, the Group Manager replies to the joining node, providing the 608 updated security parameters and keying meterial necessary to 609 participate in the group communication. This success Joining 610 Response is formatted as defined in Section 4.1.2.1 of 611 [I-D.ietf-ace-key-groupcomm], with the following additions: 613 o The 'gkty' parameter identifies a key of type 614 "Group_OSCORE_Security_Context object", defined in Section 18.2 of 615 this specification. 617 o The 'key' parameter includes what the joining node needs in order 618 to set up the OSCORE Security Context as per Section 2 of 620 [I-D.ietf-core-oscore-groupcomm]. This parameter has as value a 621 Group_OSCORE_Security_Context object, which is defined in this 622 specification and extends the OSCORE_Security_Context object 623 encoded in CBOR as defined in Section 3.2.1 of 624 [I-D.ietf-ace-oscore-profile]. In particular, it contains the 625 additional parameters 'cs_alg', 'cs_params', 'cs_key_params' and 626 'cs_key_enc' defined in Section 18.3 of this specification. More 627 specifically, the 'key' parameter is composed as follows. 629 * The 'ms' parameter MUST be present and includes the OSCORE 630 Master Secret value. 632 * The 'clientId' parameter, if present, has as value the OSCORE 633 Sender ID assigned to the joining node by the Group Manager, as 634 described above. This parameter is not present if the node 635 joins the group exclusively as monitor, according to what 636 specified in the Access Token (see Section 3.2). In any other 637 case, this parameter MUST be present. 639 * The 'hkdf' parameter, if present, has as value the KDF 640 algorithm used in the group. 642 * The 'alg' parameter, if present, has as value the AEAD 643 algorithm used in the group. 645 * The 'salt' parameter, if present, has as value the OSCORE 646 Master Salt. 648 * The 'contextId' parameter MUST be present and has as value the 649 Group Identifier (Gid), i.e. the OSCORE ID Context of the 650 OSCORE group. 652 * The 'cs_alg' parameter MUST be present and specifies the 653 algorithm used to countersign messages in the group. This 654 parameter takes values from the "Value" column of the "COSE 655 Algorithms" Registry [COSE.Algorithms]. 657 * The 'cs_params' parameter MAY be present and specifies the 658 parameters for the counter signature algorithm. This parameter 659 is a CBOR array, which includes the following two elements: 661 + 'sign_alg_capab', with the same encoding as defined in 662 Section 5.1. The value is the same as in the Token Post 663 response where the 'sign_parameters' value was non-null. 665 + 'sign_key_type_capab', with the same encoding as defined in 666 Section 5.1. The value is the same as in the Token Post 667 response where the 'sign_parameters' value was non-null. 669 * The 'cs_key_params' parameter MAY be present and specifies the 670 parameters for the key used with the counter signature 671 algorithm. This parameter is a CBOR array, with the same non- 672 null encoding and value as 'sign_key_parameters' of the 673 Section 5.1. 675 * The 'cs_key_enc' parameter MAY be present and specifies the 676 encoding of the public keys of the group members. This 677 parameter is a CBOR integer, whose value is 1 ("COSE_Key") 678 taken from the 'Confirmation Key' column of the "CWT 679 Confirmation Method" Registry defined in [RFC8747], so 680 indicating that public keys in the OSCORE group are encoded as 681 COSE Keys [I-D.ietf-cose-rfc8152bis-struct]. Future 682 specifications may define additional values for this parameter. 683 If this parameter is not present, 1 ("COSE_Key") MUST be 684 assumed as default value. 686 o The 'num' parameter MUST be present. 688 o The 'ace-groupcomm-profile' parameter MUST be present and has 689 value coap_group_oscore_app (TBD1), which is defined in 690 Section 18.1 of this specification. 692 o The 'exp' parameter MUST be present. 694 o The 'pub_keys' parameter, if present, includes the public keys of 695 the group members that are relevant to the joining node. That is, 696 it includes: i) the public keys of the responders currently in the 697 group, in case the joining node is configured (also) as requester; 698 and ii) the public keys of the requesters currently in the group, 699 in case the joining node is configured (also) as responder or 700 monitor. If public keys are encoded as COSE_Keys, each of them 701 has as 'kid' the Sender ID that the corresponding owner has in the 702 group, thus used as group member identifier. 704 o The 'group_policies' parameter SHOULD be present, and SHOULD 705 include the elements "Sequence Number Synchronization Method" and 706 "Key Update Check Interval" defined in Section 4.1.2 of 707 [I-D.ietf-ace-key-groupcomm], as well as the element "Group OSCORE 708 Pairwise Mode Support" defined in Section 5.5 of this 709 specification. 711 Finally, the joining node uses the information received in the 712 Joining Response to set up the OSCORE Security Context, as described 713 in Section 2 of [I-D.ietf-core-oscore-groupcomm]. In addition, the 714 joining node maintains an association between each public key 715 retrieved from the 'pub_keys' parameter and the role(s) that the 716 corresponding group member has in the group. 718 From then on, the joining node can exchange group messages secured 719 with Group OSCORE as described in [I-D.ietf-core-oscore-groupcomm]. 720 When doing so: 722 o The joining node MUST NOT process an incoming request message, if 723 signed by a group member whose public key is not associated to the 724 role "Requester". 726 o The joining node MUST NOT process an incoming response message, if 727 signed by a group member whose public key is not associated to the 728 role "Responder". 730 If the application requires backward security, the Group Manager MUST 731 generate updated security parameters and group keying material, and 732 provide it to the current group members upon the new node's joining 733 (see Section 16). As a consequence, the joining node is not able to 734 access secure communication in the group occurred prior its joining. 736 5.5. ACE Groupcomm Policy for Group OSCORE Pairwise Mode Support 738 This specifications defines the group policy "Group OSCORE Pairwise 739 Mode Support", for which it registers an entry in the "ACE Groupcomm 740 Policy" IANA Registry defined in Section 8.8 of 741 [I-D.ietf-ace-key-groupcomm]. 743 The corresponding element in the 'group_policies' parameter of the 744 Joining Response (see Section 5.4) encodes the CBOR simple value 745 True, if the OSCORE group supports the pairwise mode of Group OSCORE 746 [I-D.ietf-core-oscore-groupcomm], or the CBOR simple value False 747 otherwise (REQ14). 749 6. Public Keys of Joining Nodes 751 Source authentication of a message sent within the group and 752 protected with Group OSCORE is ensured by means of a digital counter 753 signature embedded in the message (in group mode), or by integrity- 754 protecting the message with pairwise keying material derived from the 755 asymmetric keys of sender and recipient (in pairwise mode). 757 Therefore, group members must be able to retrieve each other's public 758 key from a trusted key repository, in order to verify source 759 authenticity of incoming group messages. 761 As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group 762 Manager acts as trusted repository of the public keys of the group 763 members, and provides those public keys to group members if requested 764 to. Upon joining an OSCORE group, a joining node is thus expected to 765 provide its own public key to the Group Manager. 767 In particular, one of the following four cases can occur when a new 768 node joins an OSCORE group. 770 o The joining node is going to join the group exclusively as 771 monitor. That is, it is not going to send messages to the group, 772 and hence to produce signatures with its own private key. In this 773 case, the joining node is not required to provide its own public 774 key to the Group Manager, which thus does not have to perform any 775 check related to the public key encoding, or to a countersignature 776 algorithm and possible associated parameters for that joining 777 node. In case that joining node still provides a public key in 778 the 'client_cred' parameter of the Joining Request (see 779 Section 5.2), the Group Manager silently ignores that parameter, 780 as well as related the parameters 'cnonce' and 781 'client_cred_verify'. 783 o The Group Manager already acquired the public key of the joining 784 node during a past joining process. In this case, the joining 785 node MAY choose not to provide again its own public key to the 786 Group Manager, in order to limit the size of the Joining Request. 787 The joining node MUST provide its own public key again if it has 788 provided the Group Manager with multiple public keys during past 789 joining processes, intended for different OSCORE groups. If the 790 joining node provides its own public key, the Group Manager 791 performs consistency checks as per Section 5.3 and, in case of 792 success, considers it as the public key associated to the joining 793 node in the OSCORE group. 795 o The joining node and the Group Manager use an asymmetric proof-of- 796 possession key to establish a secure communication channel. Then, 797 two cases can occur. 799 1. The proof-of-possession key is compatible with the encoding as 800 well as with the counter signature algorithm and possible 801 associated parameters used in the OSCORE group. Then, the 802 Group Manager considers the proof-of-possession key as the 803 public key associated to the joining node in the OSCORE group. 804 If the joining node is aware that the proof-of-possession key 805 is also valid for the OSCORE group, it MAY not provide it 806 again as its own public key to the Group Manager. The joining 807 node MUST provide its own public key again if it has provided 808 the Group Manager with multiple public keys during past 809 joining processes, intended for different OSCORE groups. If 810 the joining node provides its own public key in the 811 'client_cred' parameter of the Joining Request (see 812 Section 5.2), the Group Manager performs consistency checks as 813 per Section 5.3 and, in case of success, considers it as the 814 public key associated to the joining node in the OSCORE group. 816 2. The proof-of-possession key is not compatible with the 817 encoding or with the counter signature algorithm and possible 818 associated parameters used in the OSCORE group. In this case, 819 the joining node MUST provide a different compatible public 820 key to the Group Manager in the 'client_cred' parameter of the 821 Joining Request (see Section 5.2). Then, the Group Manager 822 performs consistency checks on this latest provided public key 823 as per Section 5.3 and, in case of success, considers it as 824 the public key associated to the joining node in the OSCORE 825 group. 827 o The joining node and the Group Manager use a symmetric proof-of- 828 possession key to establish a secure communication channel. In 829 this case, upon performing a joining process with that Group 830 Manager for the first time, the joining node specifies its own 831 public key in the 'client_cred' parameter of the Joining Request 832 targeting the group-membership endpoint (see Section 5.2). 834 7. Retrieval of Updated Keying Material 836 At some point, a group member considers the OSCORE Security Context 837 invalid and to be renewed. This happens, for instance, after a 838 number of unsuccessful security processing of incoming messages from 839 other group members, or when the Security Context expires as 840 specified by the 'exp' parameter of the Joining Response. 842 When this happens, the group member retrieves updated security 843 parameters and group keying material. This can occur in the two 844 different ways described below. 846 7.1. Retrieval of Group Keying Material 848 If the group member wants to retrieve only the latest group keying 849 material, it sends a Key Distribution Request to the Group Manager. 851 In particular, it sends a CoAP GET request to the endpoint /group- 852 oscore/GROUPNAME at the Group Manager. 854 The Group Manager processes the Key Distribution Request according to 855 Section 4.1.2.2 of [I-D.ietf-ace-key-groupcomm]. The Key 856 Distribution Response is formatted as defined in Section 4.1.2.2 of 857 [I-D.ietf-ace-key-groupcomm]. In particular, the 'key' parameter is 858 formatted as defined in Section 5.4 of this specification, with the 859 difference that it does not include the 'clientId' parameter. 861 Upon receiving the Key Distribution Response, the group member 862 retrieves the updated security parameters and group keying material, 863 and, if they differ from the current ones, use them to set up the new 864 OSCORE Security Context as described in Section 2 of 865 [I-D.ietf-core-oscore-groupcomm]. 867 7.2. Retrieval of Group Keying Material and Sender ID 869 If the group member wants to retrieve the latest group keying 870 material as well as the Sender ID that it has in the OSCORE group, it 871 sends a Key Distribution Request to the Group Manager. 873 In particular, it sends a CoAP GET request to the endpoint /group- 874 oscore/GROUPNAME/nodes/NODENAME at the Group Manager. 876 The Group Manager processes the Key Distribution Request according to 877 Section 4.1.6.2 of [I-D.ietf-ace-key-groupcomm]. The Key 878 Distribution Response is formatted as defined in Section 4.1.6.2 of 879 [I-D.ietf-ace-key-groupcomm]. 881 In particular, the 'key' parameter is formatted as defined in 882 Section 5.4 of this specification, with the difference that if the 883 requesting group member is configured exclusively as monitor, no 884 'clientId' is specified within the 'key' parameter. Note that, in 885 any other case, the current Sender ID of the group member is not 886 specified as a separate parameter, but rather specified as 'clientId' 887 within the 'key' parameter. 889 Upon receiving the Key Distribution Response, the group member 890 retrieves the updated security parameters, group keying material and 891 Sender ID, and, if they differ from the current ones, use them to set 892 up the new OSCORE Security Context as described in Section 2 of 893 [I-D.ietf-core-oscore-groupcomm]. 895 8. Retrieval of New Keying Material 897 As discussed in Section 2.4.2 of [I-D.ietf-core-oscore-groupcomm], a 898 group member may at some point exhaust its Sender Sequence Numbers in 899 the group. 901 When this happens, the group member MUST send a Key Renewal Request 902 message to the Group Manager, as per Section 4.4 of 903 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP PUT 904 request to the endpoint /group-oscore/GROUPNAME/nodes/NODENAME at the 905 Group Manager. 907 Upon receiving the Key Renewal Request, the Group Manager processes 908 it as defined in Section 4.1.6.1 of [I-D.ietf-ace-key-groupcomm], and 909 performs one of the following actions. 911 1. If the requesting group member is configured exclusively as 912 monitor, the Group Manager replies with a 4.00 (Bad Request) 913 error response. 915 2. Otherwise, depending on the configured policies (OPT8), the Group 916 Manager takes one of the following actions. 918 a. The Group Manager rekeys the OSCORE group. That is, the 919 Group Manager generates new group keying material for that group 920 (see Section 16), and replies to the group member with a group 921 rekeying message as defined in Section 16, providing the new 922 group keying material. Then, the Group Manager rekeys the rest 923 of the OSCORE group, as discussed in Section 16. 925 b. The Group Manager generates a new Sender ID for that group 926 member and replies with a Key Renewal Response, formatted as 927 defined in Section 4.1.6.1 of [I-D.ietf-ace-key-groupcomm]. In 928 particular, the CBOR Map in the response payload includes a 929 single parameter 'clientId' defined in Section 18.5 of this 930 document, specifying the new Sender ID of the group member 931 encoded as a CBOR byte string. 933 9. Retrieval of Public Keys of Group Members 935 A group member or a signature verifier may need to retrieve the 936 public keys of (other) group members. To this end, the group member 937 or signature verifier sends a Public Key Request message to the Group 938 Manager, as per Section 4.5 of [I-D.ietf-ace-key-groupcomm]. In 939 particular, it sends the request to the endpoint /group- 940 oscore/GROUPNAME/pub-key at the Group Manager. 942 If the Public Key Request uses the method FETCH, the Public Key 943 Request is formatted as defined in Section 4.1.3.1 of 944 [I-D.ietf-ace-key-groupcomm]. In particular, each element of the 945 'get_pub_keys' parameter is a CBOR byte string, which encodes the 946 Sender ID of the group member for which the associated public key is 947 requested. 949 Upon receiving the Public Key Request, the Group Manager processes it 950 as per Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm], 951 depending on the request method being FETCH or GET, respectively. 952 Additionally, if the Public Key Request uses the method FETCH, the 953 Group Manager silently ignores identifiers included in the 954 'get_pub_keys' parameter of the request that are not associated to 955 any current group member. 957 The success Public Key Response is formatted as defined in 958 Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm], depending 959 on the request method being FETCH or GET, respectively. 961 10. Update of Public Key 963 A group member may need to provide the Group Manager with its new 964 public key to use in the group from then on, hence replacing the 965 current one. This can be the case, for instance, if the 966 countersignature algorithm and possible associated parameters used in 967 the OSCORE group have been changed, and the current public key is not 968 compatible with them. 970 To this end, the group member sends a Public Key Update Request 971 message to the Group Manager, as per Section 4.6 of 972 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP POST 973 request to the endpoint /group-oscore/GROUPNAME/nodes/NODENAME/pub- 974 key at the Group Manager. 976 Upon receiving the Group Leaving Request, the Group Manager processes 977 it as per Section 4.1.7.1 of [I-D.ietf-ace-key-groupcomm], with the 978 following additions. 980 o If the requesting group member is configured exclusively as 981 monitor, the Group Manager replies with a 4.00 (Bad request) error 982 response. 984 o The N_S signature challenge is computed as per point (3) in 985 Section 5.2.1 (REQ17). 987 o If the request is successfully processed, the Group Manager stores 988 the association between i) the new public key of the group member; 989 and ii) the Group Identifier (Gid), i.e. the OSCORE ID Context, 990 associated to the OSCORE group together with the OSCORE Sender ID 991 assigned to the group member in the group. The Group Manager MUST 992 keep this association updated over time. 994 11. Retrieval of Group Policies 996 A group member may request the current policies used in the OSCORE 997 group. To this end, the group member sends a Policies Request, as 998 per Section 4.7 of [I-D.ietf-ace-key-groupcomm]. In particular, it 999 sends a CoAP GET request to the endpoint /group-oscore/GROUPNAME/ 1000 policies at the Group Manager, where GROUPNAME is the name of the 1001 OSCORE group. 1003 Upon receiving the Policies Request, the Group Manager processes it 1004 as per Section 4.1.4.1 of [I-D.ietf-ace-key-groupcomm]. The success 1005 Policies Response is formatted as defined in Section 4.1.4.1 of 1006 [I-D.ietf-ace-key-groupcomm]. 1008 12. Retrieval of Keying Material Version 1010 A group member may request the current version of the keying material 1011 used in the OSCORE group. To this end, the group member sends a 1012 Version Request, as per Section 4.8 of [I-D.ietf-ace-key-groupcomm]. 1013 In particular, it sends a CoAP GET request to the endpoint /group- 1014 oscore/GROUPNAME/ctx-num at the Group Manager, where GROUPNAME is the 1015 name of the OSCORE group. 1017 Upon receiving the Version Request, the Group Manager processes it as 1018 per Section 4.1.5.1 of [I-D.ietf-ace-key-groupcomm]. The success 1019 Version Response is formatted as defined in Section 4.1.5.1 of 1020 [I-D.ietf-ace-key-groupcomm]. 1022 13. Retrieval of Group Status 1024 A group member may request the current status of the the OSCORE 1025 group, i.e. active or inactive. To this end, the group member sends 1026 a Group Status Request to the Group Manager. 1028 In particular, the group member sends a CoAP GET request to the 1029 endpoint /group-oscore/GROUPNAME/active at the Group Manager defined 1030 in Section 4 of this specification, where GROUPNAME is the name of 1031 the OSCORE group. The success Group Version Response is formatted as 1032 defined in Section 4 of this specification. 1034 Upon learning from a 2.05 (Content) response that the group is 1035 currently inactive, the group member SHOULD stop taking part in 1036 communications within the group, until it becomes active again. 1038 Upon learning from a 2.05 (Content) response that the group has 1039 become active again, the group member can resume taking part in 1040 communications within the group. 1042 Figure 2 gives an overview of the exchange described above. 1044 Group Group 1045 Member Manager 1046 | | 1047 |------ Group Status Request: GET ace-group/GID/active ------>| 1048 | | 1049 |<---------- Group Status Response: 2.05 (Content) -----------| 1050 | | 1052 Figure 2: Message Flow of Group Status Request-Response 1054 14. Request to Leave the Group 1056 A group member may request to leave the OSCORE group. To this end, 1057 the group member sends a Group Leaving Request, as per Section 4.9 of 1058 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP DELETE 1059 request to the endpoint /group-oscore/GROUPNAME/nodes/NODENAME at the 1060 Group Manager. 1062 Upon receiving the Group Leaving Request, the Group Manager processes 1063 it as per Section 4.1.6.3 of [I-D.ietf-ace-key-groupcomm]. 1065 15. Removal of a Group Member 1067 Other than after a spontaneous request to the Group Manager as 1068 described in Section 14, a node may be forcibly removed from the 1069 OSCORE group, e.g. due to expired or revoked authorization. 1071 If, upon joining the group (see Section 5.2), the leaving node 1072 specified a URI in the 'control_path' parameter defined in 1073 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm], the Group Manager 1074 MUST inform the leaving node of its eviction, by sending a DELETE 1075 request targeting the URI specified in the 'control_path' parameter 1076 (OPT9). 1078 If the leaving node is not configured exclusively as monitor, the 1079 Group Manager performs the following actions. 1081 o The Group Manager frees the OSCORE Sender ID value of the leaving 1082 node, which becomes available for possible upcoming joining nodes. 1084 o The Group Manager cancels the association between, on one hand, 1085 the public key of the leaving node and, on the other hand, the 1086 Group Identifier (Gid) associated to the OSCORE group together 1087 with the freed OSCORE Sender ID value. The Group Manager deletes 1088 the public key of the leaving node, if that public key has no 1089 remaining association with any pair (Gid, Sender ID). 1091 If the application requires forward security, the Group Manager MUST 1092 generate updated security parameters and group keying material, and 1093 provide it to the remaining group members (see Section 16). As a 1094 consequence, the leaving node is not able to acquire the new security 1095 parameters and group keying material distributed after its leaving. 1097 Same considerations in Section 5 of [I-D.ietf-ace-key-groupcomm] 1098 apply here as well, considering the Group Manager acting as KDC. 1100 16. Group Rekeying Process 1102 In order to rekey the OSCORE group, the Group Manager distributes a 1103 new Group Identifier (Gid), i.e. a new OSCORE ID Context; a new 1104 OSCORE Master Secret; and, optionally, a new OSCORE Master Salt for 1105 that group. When doing so, the Group Manager MUST increment the 1106 version number of the group keying material, before starting its 1107 distribution. 1109 Furthermore, the Group Manager MUST preserve the same unchanged 1110 Sender IDs for all group members. This avoids affecting the 1111 retrieval of public keys from the Group Manager as well as the 1112 verification of message countersignatures. 1114 The Group Manager MUST support at least the following group rekeying 1115 scheme. Future application profiles may define alternative message 1116 formats and distribution schemes. 1118 As group rekeying message, the Group Manager uses the same format of 1119 the Joining Response message in Section 5.4. In particular: 1121 o Only the parameters 'gkty', 'key', 'num', 'ace-groupcomm-profile' 1122 and 'exp' are present. 1124 o The 'ms' parameter of the 'key' parameter specifies the new OSCORE 1125 Master Secret value. 1127 o The 'contextId' parameter of the 'key' parameter specifies the new 1128 Group ID. 1130 The Group Manager separately sends a group rekeying message to each 1131 group member to be rekeyed. 1133 Each rekeying message MUST be secured with the pairwise secure 1134 communication channel between the Group Manager and the group member 1135 used during the joining process. In particular, each rekeying 1136 message can target the 'control_path' URI path defined in 1137 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm] (OPT9), if provided 1138 by the intended recipient upon joining the group (see Section 5.2). 1140 It is RECOMMENDED that the Group Manager gets confirmation of 1141 successful distribution from the group members, and admits a maximum 1142 number of individual retransmissions to non-confirming group members. 1144 This approach requires group members to act (also) as servers, in 1145 order to correctly handle unsolicited group rekeying messages from 1146 the Group Manager. In particular, if a group member and the Group 1147 Manager use OSCORE [RFC8613] to secure their pairwise communications, 1148 the group member MUST create a Replay Window in its own Recipient 1149 Context upon establishing the OSCORE Security Context with the Group 1150 Manager, e.g. by means of the OSCORE profile of ACE 1151 [I-D.ietf-ace-oscore-profile]. 1153 Group members and the Group Manager SHOULD additionally support 1154 alternative rekeying approaches that do not require group members to 1155 act (also) as servers. A number of such approaches are defined in 1156 Section 4.3 of [I-D.ietf-ace-key-groupcomm]. In particular, a group 1157 member may subscribe for updates to the group-membership resource of 1158 the group, at the endpoint /group-oscore/GROUPNAME/nodes/NODENAME of 1159 the Group Manager. This can rely on CoAP Observe [RFC7641] or on a 1160 full-fledged Pub-Sub model [I-D.ietf-core-coap-pubsub] with the Group 1161 Manager acting as Broker. 1163 In case the rekeying terminates and some group members have not 1164 received the new keying material, they will not be able to correctly 1165 process following secured messages exchanged in the group. These 1166 group members will eventually contact the Group Manager, in order to 1167 retrieve the current keying material and its version. 1169 Some of these group members may be in multiple groups, each 1170 associated to a different Group Manager. When failing to correctly 1171 process messages secured with the new keying material, these group 1172 members may not have sufficient information to determine which exact 1173 Group Manager they should contact, in order to retrieve the current 1174 keying material they are missing. 1176 If the Gid is formatted as described in Appendix C of 1177 [I-D.ietf-core-oscore-groupcomm], the Group Prefix can be used as a 1178 hint to determine the right Group Manager, as long as no collisions 1179 among Group Prefixes are experienced. Otherwise, a group member 1180 needs to contact the Group Manager of each group, e.g. by first 1181 requesting only the version of the current group keying material (see 1182 Section 12) and then possibly requesting the current keying material 1183 (see Section 7.1). 1185 Furthermore, some of these group members can be in multiple groups, 1186 all of which associated to the same Group Manager. In this case, 1187 these group members may also not have sufficient information to 1188 determine which exact group they should refer to, when contacting the 1189 right Group Manager. Hence, they need to contact a Group Manager 1190 multiple times, i.e. separately for each group they belong to and 1191 associated to that Group Manager. 1193 17. Security Considerations 1195 Security considerations for this profile are inherited from 1196 [I-D.ietf-ace-key-groupcomm], the ACE framework for Authentication 1197 and Authorization [I-D.ietf-ace-oauth-authz], and the specific 1198 transport profile of ACE signalled by the AS, such as 1199 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile]. 1201 The following security considerations also apply for this profile. 1203 17.1. Management of OSCORE Groups 1205 This profile leverages the following management aspects related to 1206 OSCORE groups and discussed in the sections of 1207 [I-D.ietf-core-oscore-groupcomm] referred below. 1209 o Management of group keying material (see Section 3.1 of 1210 [I-D.ietf-core-oscore-groupcomm]). The Group Manager is 1211 responsible for the renewal and re-distribution of the keying 1212 material in the groups of its competence (rekeying). According to 1213 the specific application requirements, this can include rekeying 1214 the group upon changes in its membership. In particular, renewing 1215 the group keying material is required upon a new node's joining or 1216 a current node's leaving, in case backward security and forward 1217 security have to be preserved, respectively. 1219 o Provisioning and retrieval of public keys (see Section 2 of 1220 [I-D.ietf-core-oscore-groupcomm]). The Group Manager acts as key 1221 repository of public keys of group members, and provides them upon 1222 request. 1224 o Synchronization of sequence numbers (see Section 6.1 of 1225 [I-D.ietf-core-oscore-groupcomm]). This concerns how a responder 1226 node that has just joined an OSCORE group can synchronize with the 1227 sequence number of requesters in the same group. 1229 Before sending the Joining Response, the Group Manager MUST verify 1230 that the joining node actually owns the associated private key. To 1231 this end, the Group Manager can rely on the proof-of-possession 1232 challenge-response defined in Section 5. Alternatively, the joining 1233 node can use its own public key as asymmetric proof-of-possession key 1234 to establish a secure channel with the Group Manager, e.g. as in 1235 Section 3.2 of [I-D.ietf-ace-dtls-authorize]. However, this requires 1236 such proof-of-possession key to be compatible with the encoding as 1237 well as with the countersignature algorithm and possible associated 1238 parameters used in the OSCORE group. 1240 A node may have joined multiple OSCORE groups under different non- 1241 synchronized Group Managers. Therefore, it can happen that those 1242 OSCORE groups have the same Group Identifier (Gid). It follows that, 1243 upon receiving a Group OSCORE message addressed to one of those 1244 groups, the node would have multiple Security Contexts matching with 1245 the Gid in the incoming message. It is up to the application to 1246 decide how to handle such collisions of Group Identifiers, e.g. by 1247 trying to process the incoming message using one Security Context at 1248 the time until the right one is found. 1250 17.2. Size of Nonces for Signature Challenge 1252 With reference to the Joining Request message in Section 5.2, the 1253 proof-of-possession signature included in 'client_cred_verify' is 1254 computed over the challenge N_C | N_S, where | denotes concatenation. 1256 For the N_C challenge share, it is RECOMMENDED to use a 8-byte long 1257 random nonce. Furthermore, N_C is always conveyed in the 'cnonce' 1258 parameter of the Joining Request, which is always sent over the 1259 secure communication channel between the joining node and the Group 1260 Manager. 1262 As defined in Section 5.2.1, the way the N_S value is computed 1263 depends on the particular way the joining node provides the Group 1264 Manager with the Access Token, as well as on following interactions 1265 between the two. 1267 o If the Access Token is not explicitly posted to the /authz-info 1268 endpoint of the Group Manager, then N_S is computed as a 32-byte 1269 long challenge share (see points 2 of Section 5.2.1). 1271 o If the Access Token has been explicitly posted to the /authz-info 1272 endpoint of the Group Manager, N_S takes the most recent value 1273 specified to the client by the Group Manager in the 'kdcchallenge' 1274 parameter (see point 1 of Section 5.2.1). This is specified 1275 either in the 2.01 response to the Token Post (see Section 5.1), 1276 or in a 4.00 response to a following Joining Request (see 1277 Section 5.3). In either case, it is RECOMMENDED to use a 8-byte 1278 long random challenge as value for N_S. 1280 If we consider both N_C and N_S to take 8-byte long values, the 1281 following considerations hold. 1283 o Let us consider both N_C and N_S as taking random values, and the 1284 Group Manager to never change the value of the N_S provided to a 1285 Client during the lifetime of an Access Token. Then, as per the 1286 birthday paradox, the average collision for N_S will happen after 1287 2^32 new posted Access Tokens, while the average collision for N_C 1288 will happen after 2^32 new Joining Requests. This amounts to 1289 considerably more token provisionings than the expected new 1290 joinings of OSCORE groups under a same Group Manager, as well as 1291 to considerably more requests to join OSCORE groups from a same 1292 Client using a same Access Token under a same Group Manager. 1294 o Section 7 of [I-D.ietf-ace-oscore-profile] as well Appendix B.2 of 1295 [RFC8613] recommend the use of 8-byte random values as well. 1296 Unlike in those cases, the values of N_C and N_S considered in 1297 this specification are not used for as sensitive operations as the 1298 derivation of a Security Context, with possible implications in 1299 the security of AEAD ciphers. 1301 17.3. Reusage of Nonces for Signature Challenge 1303 As long as the Group Manager preserves the same N_S value currently 1304 associated to an Access Token, i.e. the latest value provided to a 1305 Client in a 'kdcchallenge' parameter, the Client is able to 1306 successfully reuse the same signature challenge for multiple Joining 1307 Requests to that Group Manager. 1309 In particular, the client can reuse the same N_C value for every 1310 Joining Request to the Group Manager, and combine it with the same 1311 unchanged N_S value. This results in reusing the same signature 1312 challenge for producing the signature to include in the 1313 'client_cred_verify' parameter of the Joining Requests. 1315 Unless the Group Manager maintains a list of N_C values already used 1316 by that Client since the latest update to the N_S value associated to 1317 the Access Token, the Group Manager can be forced to falsely believe 1318 that the Client possesses its own private key at that point in time, 1319 upon verifying the signature in the 'client_cred_verify' parameter. 1321 18. IANA Considerations 1323 Note to RFC Editor: Please replace all occurrences of "[[This 1324 specification]]" with the RFC number of this specification and delete 1325 this paragraph. 1327 This document has the following actions for IANA. 1329 18.1. ACE Groupcomm Profile Registry 1331 IANA is asked to register the following entry in the "ACE Groupcomm 1332 Profile" Registry defined in Section 8.7 of 1333 [I-D.ietf-ace-key-groupcomm]. 1335 o Name: coap_group_oscore_app 1336 o Description: Application profile to provision keying material for 1337 participating in group communication protected with Group OSCORE 1338 as per [I-D.ietf-core-oscore-groupcomm]. 1340 o CBOR Value: TBD1 1342 o Reference: [[This specification]] (Section 5.4) 1344 18.2. ACE Groupcomm Key Registry 1346 IANA is asked to register the following entry in the "ACE Groupcomm 1347 Key" Registry defined in Section 8.6 of [I-D.ietf-ace-key-groupcomm]. 1349 o Name: Group_OSCORE_Security_Context object 1351 o Key Type Value: TBD2 1353 o Profile: "coap_group_oscore_app", defined in Section 18.1 of this 1354 specification. 1356 o Description: A Group_OSCORE_Security_Context object encoded as 1357 described in Section 5.4 of this specification. 1359 o Reference: [[This specification]] (Section 5.4) 1361 18.3. OSCORE Security Context Parameters Registry 1363 IANA is asked to register the following entries in the "OSCORE 1364 Security Context Parameters" Registry defined in Section 9.4 of 1365 [I-D.ietf-ace-oscore-profile]. 1367 o Name: cs_alg 1369 o CBOR Label: TBD3 1371 o CBOR Type: tstr / int 1373 o Registry: COSE Algorithm Values (ECDSA, EdDSA) 1375 o Description: OSCORE Counter Signature Algorithm Value 1377 o Reference: [[This specification]] (Section 5.4) 1379 o Name: cs_params 1381 o CBOR Label: TBD4 1382 o CBOR Type: array 1384 o Registry: Counter Signatures Parameters 1386 o Description: OSCORE Counter Signature Algorithm Additional 1387 Parameters 1389 o Reference: [[This specification]] (Section 5.4) 1391 o Name: cs_key_params 1393 o CBOR Label: TBD5 1395 o CBOR Type: array 1397 o Registry: Counter Signatures Key Parameters 1399 o Description: OSCORE Counter Signature Key Additional Parameters 1401 o Reference: [[This specification]] (Section 5.4) 1403 o Name: cs_key_enc 1405 o CBOR Label: TBD6 1407 o CBOR Type: integer 1409 o Registry: ACE Public Key Encoding 1411 o Description: Encoding of Public Keys to be used with the OSCORE 1412 Counter Signature Algorithm 1414 o Reference: [[This specification]] (Section 5.4) 1416 18.4. Sequence Number Synchronization Method Registry 1418 IANA is asked to register the following entries in the "Sequence 1419 Number Synchronization Method" Registry defined in Section 8.9 of 1420 [I-D.ietf-ace-key-groupcomm]. 1422 o Name: Best effort 1424 o Value: 1 1426 o Description: No action is taken. 1428 o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.1) 1430 o Name: Baseline 1432 o Value: 2 1434 o Description: The first received request sets the baseline 1435 reference point, and is discarded with no delivery to the 1436 application. 1438 o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.2) 1440 o Name: Echo challenge-response 1442 o Value: 3 1444 o Description: Challenge response using the Echo Option for CoAP 1445 from [I-D.ietf-core-echo-request-tag]. 1447 o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.3) 1449 18.5. ACE Groupcomm Parameters Registry 1451 IANA is asked to register the following entry in the "ACE Groupcomm 1452 Parameters" Registry defined in Section 8.5 of 1453 [I-D.ietf-ace-key-groupcomm]. 1455 o Name: clientId 1457 o CBOR Key: TBD7 1459 o CBOR Type: Byte string 1461 o Reference: [[This specification]] (Section 8) 1463 18.6. ACE Groupcomm Policy Registry 1465 IANA is asked to register the following entry in the "ACE Groupcomm 1466 Policy" Registry defined in Section 8.8 of 1467 [I-D.ietf-ace-key-groupcomm]. 1469 o Name: Group OSCORE Pairwise Mode Support 1471 o CBOR Key: TBD8 1473 o CBOR Type: Simple value 1474 o Description: True if the OSCORE group supports the pairwise mode 1475 of Group OSCORE [I-D.ietf-core-oscore-groupcomm], False otherwise. 1477 o Reference: [[This specification]] (Section 5.5) 1479 18.7. TLS Exporter Label Registry 1481 IANA is asked to register the following entry in the "TLS Exporter 1482 Label" Registry defined in Section 6 of [RFC5705] and updated in 1483 Section 12 of [RFC8447]. 1485 o Value: EXPORTER-ACE-Sign-Challenge-coap-group-oscore-app 1487 o DTLS-OK: Y 1489 o Recommended: N 1491 o Reference: [[This specification]] (Section 5.2.1) 1493 19. References 1495 19.1. Normative References 1497 [COSE.Algorithms] 1498 IANA, "COSE Algorithms", 1499 . 1502 [COSE.Key.Types] 1503 IANA, "COSE Key Types", 1504 . 1507 [I-D.ietf-ace-key-groupcomm] 1508 Palombini, F. and M. Tiloca, "Key Provisioning for Group 1509 Communication using ACE", draft-ietf-ace-key-groupcomm-07 1510 (work in progress), June 2020. 1512 [I-D.ietf-ace-oauth-authz] 1513 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1514 H. Tschofenig, "Authentication and Authorization for 1515 Constrained Environments (ACE) using the OAuth 2.0 1516 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33 1517 (work in progress), February 2020. 1519 [I-D.ietf-ace-oscore-profile] 1520 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 1521 "OSCORE profile of the Authentication and Authorization 1522 for Constrained Environments Framework", draft-ietf-ace- 1523 oscore-profile-10 (work in progress), March 2020. 1525 [I-D.ietf-core-oscore-groupcomm] 1526 Tiloca, M., Selander, G., Palombini, F., and J. Park, 1527 "Group OSCORE - Secure Group Communication for CoAP", 1528 draft-ietf-core-oscore-groupcomm-08 (work in progress), 1529 April 2020. 1531 [I-D.ietf-cose-rfc8152bis-algs] 1532 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1533 Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-09 1534 (work in progress), June 2020. 1536 [I-D.ietf-cose-rfc8152bis-struct] 1537 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1538 Structures and Process", draft-ietf-cose-rfc8152bis- 1539 struct-10 (work in progress), June 2020. 1541 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1542 Requirement Levels", BCP 14, RFC 2119, 1543 DOI 10.17487/RFC2119, March 1997, 1544 . 1546 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1547 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1548 March 2010, . 1550 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1551 Application Protocol (CoAP)", RFC 7252, 1552 DOI 10.17487/RFC7252, June 2014, 1553 . 1555 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1556 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1557 May 2017, . 1559 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1560 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1561 . 1563 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 1564 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 1565 . 1567 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1568 "Object Security for Constrained RESTful Environments 1569 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1570 . 1572 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 1573 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 1574 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 1575 2020, . 1577 19.2. Informative References 1579 [I-D.ietf-ace-dtls-authorize] 1580 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 1581 L. Seitz, "Datagram Transport Layer Security (DTLS) 1582 Profile for Authentication and Authorization for 1583 Constrained Environments (ACE)", draft-ietf-ace-dtls- 1584 authorize-10 (work in progress), May 2020. 1586 [I-D.ietf-core-coap-pubsub] 1587 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1588 Subscribe Broker for the Constrained Application Protocol 1589 (CoAP)", draft-ietf-core-coap-pubsub-09 (work in 1590 progress), September 2019. 1592 [I-D.ietf-core-echo-request-tag] 1593 Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, 1594 Request-Tag, and Token Processing", draft-ietf-core-echo- 1595 request-tag-09 (work in progress), March 2020. 1597 [I-D.ietf-core-groupcomm-bis] 1598 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1599 for the Constrained Application Protocol (CoAP)", draft- 1600 ietf-core-groupcomm-bis-00 (work in progress), March 2020. 1602 [I-D.tiloca-ace-oscore-gm-admin] 1603 Tiloca, M., Hoeglund, R., Stok, P., Palombini, F., and K. 1604 Hartke, "Admin Interface for the OSCORE Group Manager", 1605 draft-tiloca-ace-oscore-gm-admin-01 (work in progress), 1606 March 2020. 1608 [I-D.tiloca-core-oscore-discovery] 1609 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 1610 Groups with the CoRE Resource Directory", draft-tiloca- 1611 core-oscore-discovery-05 (work in progress), March 2020. 1613 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1614 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1615 January 2012, . 1617 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1618 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1619 . 1621 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1622 Application Protocol (CoAP)", RFC 7641, 1623 DOI 10.17487/RFC7641, September 2015, 1624 . 1626 Appendix A. Profile Requirements 1628 This appendix lists the specifications on this application profile of 1629 ACE, based on the requiremens defined in Appendix A of 1630 [I-D.ietf-ace-key-groupcomm]. 1632 o REQ1 - Specify the encoding and value of the identifier of group, 1633 for scope entries of 'scope': see Section 3.1 and Section 5.1. 1635 o REQ2 - Specify the encoding and value of roles, for scope entries 1636 of 'scope': see Section 3.1. 1638 o REQ3 - if used, specify the acceptable values for 'sign_alg': 1639 values from the "Value" column of the "COSE Algorithms" Registry 1640 [COSE.Algorithms]. 1642 o REQ4 - If used, specify the acceptable values for 1643 'sign_parameters': values from the COSE capabilities in the "COSE 1644 Algorithms" Registry [COSE.Algorithms] and from the COSE 1645 capabilities in the "COSE Key Types" Registry [COSE.Key.Types]. 1647 o REQ5 - If used, specify the acceptable values for 1648 'sign_key_parameters': values from the COSE capabilities in the 1649 "COSE Key Types" Registry [COSE.Key.Types]. 1651 o REQ6 - If used, specify the acceptable values for 'pub_key_enc': 1 1652 ("COSE_Key") from the 'Confirmation Key' column of the "CWT 1653 Confirmation Method" Registry defined in [RFC8747]. Future 1654 specifications may define additional values for this parameter. 1656 o REQ7 - Format of the 'key' value: see Section 5.4. 1658 o REQ8 - Acceptable values of 'gkty': Group_OSCORE_Security_Context 1659 object (see Section 5.4). 1661 o REQ9: Specify the format of the identifiers of group members: see 1662 Section 5.4 and Section 9. 1664 o REQ10 - Specify the communication protocol that the members of the 1665 group must use: CoAP, possibly over IP multicast. 1667 o REQ11 - Specify the security protocols that the group members must 1668 use to protect their communication: Group OSCORE. 1670 o REQ12 - Specify and register the application profile identifier: 1671 coap_group_oscore_app (see Section 18.1). 1673 o REQ13 - Specify policies at the KDC to handle member ids that are 1674 not included in 'get_pub_keys': see Section 9. 1676 o REQ14 - If used, specify the format and content of 1677 'group_policies' and its entries: see Section 5.4; the three 1678 values defined and registered, as content of the entry "Sequence 1679 Number Synchronization Method" (see Section 18.4); the defined and 1680 registered encoding of the entry "Group OSCORE Pairwise Mode 1681 Support" (see Section 18.6). 1683 o REQ15 - Specify the format of newly-generated individual keying 1684 material for group members, or of the information to derive it, 1685 and corresponding CBOR label: see Section 8. 1687 o REQ16 - Specify how the communication is secured between the 1688 Client and KDC: by means of any transport profile of ACE 1689 [I-D.ietf-ace-oauth-authz] between Client and Group Manager that 1690 complies with the requirements in Appendix C of 1691 [I-D.ietf-ace-oauth-authz]. 1693 o REQ17: Specify how the nonce N_S is generated, if the token is not 1694 being posted (e.g. if it is used directly to validate TLS 1695 instead): see Section 5.2.1. 1697 o REQ18: Specify if 'mgt_key_material' used, and if yes specify its 1698 format and content: not used in this version of the profile. 1700 o OPT1 (Optional) - Specify the encoding of public keys, of 1701 'client_cred', and of 'pub_keys' if COSE_Keys are not used: no. 1703 o OPT2 (Optional) - Specify the negotiation of parameter values for 1704 signature algorithm and signature keys, if 'sign_info' and 1705 'pub_key_enc' are not used: possible early discovery by using the 1706 approach based on the CoRE Resource Directory described in 1707 [I-D.tiloca-core-oscore-discovery]. 1709 o OPT3 (Optional) - Specify the encoding of 'pub_keys_repos' if the 1710 default is not used: no. 1712 o OPT4 (Optional) - Specify policies that instruct clients to retain 1713 unsuccessfully decrypted messages and for how long, so that they 1714 can be decrypted after getting updated keying material: no. 1716 o OPT5 (Optional) - Specify the behavior of the handler in case of 1717 failure to retrieve a public key for the specific node: send a 1718 4.00 Bad Request response to a Joining Request (see Section 5.3). 1720 o OPT6 (Optional) - Specify possible or required payload formats for 1721 specific error cases: send a 4.00 Bad Request response to a 1722 Joining Request (see Section 5.3). 1724 o OPT7 (Optional) - Specify CBOR values to use for abbreviating 1725 identifiers of roles in the group or topic (see Section 3.1). 1727 o OPT8 (Optional) - Specify policies for the KDC to perform group 1728 rekeying after receiving a Key Renewal Request: no. 1730 o OPT9 (Optional) - Specify the functionalities implemented at the 1731 'control_path' resource hosted at the Client, including message 1732 exchange encoding and other details (see Section 4.1.2.1 of 1733 [I-D.ietf-ace-key-groupcomm]): see Section 15 for the eviction of 1734 a group member; see Section 16 for the group rekeying process. 1736 o OPT10 (Optional) - Specify how the identifier of the sender's 1737 public key is included in the group request: no. 1739 Appendix B. Document Updates 1741 RFC EDITOR: PLEASE REMOVE THIS SECTION. 1743 B.1. Version -06 to -07 1745 o Alignments with draft-ietf-core-oscore-groupcomm. 1747 o New format of 'sign_info', using the COSE capabilities. 1749 o New format of Joining Response parameters, using the COSE 1750 capabilities. 1752 o Considerations on group rekeying. 1754 o Editorial revision. 1756 B.2. Version -05 to -06 1758 o Added role of external signature verifier. 1760 o Parameter 'rsnonce' renamed to 'kdcchallenge'. 1762 o Parameter 'kdcchallenge' may be omitted in some cases. 1764 o Clarified difference between group name and OSCORE Gid. 1766 o Removed the role combination ["requester", "monitor"]. 1768 o Admit implicit scope and audience in the Authorization Request. 1770 o New format for the 'sign_info' parameter. 1772 o Scope not mandatory to include in the Joining Request. 1774 o Group policy about supporting Group OSCORE in pairwise mode. 1776 o Possible individual rekeying of a single requesting node combined 1777 with a group rekeying. 1779 o Security considerations on reusage of signature challenges. 1781 o Addressing optional requirement OPT9 from draft-ietf-ace-key- 1782 groupcomm 1784 o Editorial improvements. 1786 B.3. Version -04 to -05 1788 o Nonce N_S also in error responses to the Joining Requests. 1790 o Supporting single Access Token for multiple groups/topics. 1792 o Supporting legal requesters/responders using the 'peer_roles' 1793 parameter. 1795 o Registered and used dedicated label for TLS Exporter. 1797 o Added method for uploading a new public key to the Group Manager. 1799 o Added resource and method for retrieving the current group status. 1801 o Fixed inconsistency in retrieving group keying material only. 1803 o Clarified retrieval of keying material for monitor-only members. 1805 o Clarification on incrementing version number when rekeying the 1806 group. 1808 o Clarification on what is re-distributed with the group rekeying. 1810 o Security considerations on the size of the nonces used for the 1811 signature challenge. 1813 o Added CBOR values to abbreviate role identifiers in the group. 1815 B.4. Version -03 to -04 1817 o New abstract. 1819 o Moved general content to draft-ietf-ace-key-groupcomm 1821 o Terminology: node name; node resource. 1823 o Creation and pointing at node resource. 1825 o Updated Group Manager API (REST methods and offered services). 1827 o Size of challenges 'cnonce' and 'rsnonce'. 1829 o Value of 'rsnonce' for reused or non-traditionally-posted tokens. 1831 o Removed reference to RFC 7390. 1833 o New requirements from draft-ietf-ace-key-groupcomm 1835 o Editorial improvements. 1837 B.5. Version -02 to -03 1839 o New sections, aligned with the interface of ace-key-groupcomm . 1841 o Exchange of information on the countersignature algorithm and 1842 related parameters, during the Token POST (Section 4.1). 1844 o Nonce 'rsnonce' from the Group Manager to the Client 1845 (Section 4.1). 1847 o Client PoP signature in the Key Distribution Request upon joining 1848 (Section 4.2). 1850 o Local actions on the Group Manager, upon a new node's joining 1851 (Section 4.2). 1853 o Local actions on the Group Manager, upon a node's leaving 1854 (Section 12). 1856 o IANA registration in ACE Groupcomm Parameters Registry. 1858 o More fulfilled profile requirements (Appendix A). 1860 B.6. Version -01 to -02 1862 o Editorial fixes. 1864 o Changed: "listener" to "responder"; "pure listener" to "monitor". 1866 o Changed profile name to "coap_group_oscore_app", to reflect it is 1867 an application profile. 1869 o Added the 'type' parameter for all requests to a Join Resource. 1871 o Added parameters to indicate the encoding of public keys. 1873 o Challenge-response for proof-of-possession of signature keys 1874 (Section 4). 1876 o Renamed 'key_info' parameter to 'sign_info'; updated its format; 1877 extended to include also parameters of the countersignature key 1878 (Section 4.1). 1880 o Code 4.00 (Bad request), in responses to joining nodes providing 1881 an invalid public key (Section 4.3). 1883 o Clarifications on provisioning and checking of public keys 1884 (Sections 4 and 6). 1886 o Extended discussion on group rekeying and possible different 1887 approaches (Section 7). 1889 o Extended security considerations: proof-of-possession of signature 1890 keys; collision of OSCORE Group Identifiers (Section 8). 1892 o Registered three entries in the IANA Registry "Sequence Number 1893 Synchronization Method Registry" (Section 9). 1895 o Registered one public key encoding in the "ACE Public Key 1896 Encoding" IANA Registry (Section 9). 1898 B.7. Version -00 to -01 1900 o Changed name of 'req_aud' to 'audience' in the Authorization 1901 Request (Section 3.1). 1903 o Added negotiation of countersignature algorithm/parameters between 1904 Client and Group Manager (Section 4). 1906 o Updated format of the Key Distribution Response as a whole 1907 (Section 4.3). 1909 o Added parameter 'cs_params' in the 'key' parameter of the Key 1910 Distribution Response (Section 4.3). 1912 o New IANA registrations in the "ACE Authorization Server Request 1913 Creation Hints" Registry, "ACE Groupcomm Key" Registry, "OSCORE 1914 Security Context Parameters" Registry and "ACE Groupcomm Profile" 1915 Registry (Section 9). 1917 Acknowledgments 1919 The authors sincerely thank Santiago Aragon, Stefan Beck, Carsten 1920 Bormann, Martin Gunnarsson, Rikard Hoeglund, Daniel Migault, Jim 1921 Schaad, Ludwig Seitz, Goeran Selander and Peter van der Stok for 1922 their comments and feedback. 1924 The work on this document has been partly supported by VINNOVA and 1925 the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact 1926 Initiative ACTIVE. 1928 Authors' Addresses 1930 Marco Tiloca 1931 RISE AB 1932 Isafjordsgatan 22 1933 Kista SE-164 29 Stockholm 1934 Sweden 1936 Email: marco.tiloca@ri.se 1938 Jiye Park 1939 Universitaet Duisburg-Essen 1940 Schuetzenbahn 70 1941 Essen 45127 1942 Germany 1944 Email: ji-ye.park@uni-due.de 1945 Francesca Palombini 1946 Ericsson AB 1947 Torshamnsgatan 23 1948 Kista SE-16440 Stockholm 1949 Sweden 1951 Email: francesca.palombini@ericsson.com