idnits 2.17.1 draft-ietf-ace-key-groupcomm-oscore-06.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 (May 11, 2020) is 1444 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-06 == 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 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-09 == 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 (~~), 11 warnings (==), 2 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: November 12, 2020 Universitaet Duisburg-Essen 6 F. Palombini 7 Ericsson AB 8 May 11, 2020 10 Key Management for OSCORE Groups in ACE 11 draft-ietf-ace-key-groupcomm-oscore-06 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 November 12, 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 . . . . 18 83 8. Retrieval of New Keying Material . . . . . . . . . . . . . . 19 84 9. Retrieval of Public Keys of Group Members . . . . . . . . . . 20 85 10. Update of Public Key . . . . . . . . . . . . . . . . . . . . 20 86 11. Retrieval of Group Policies . . . . . . . . . . . . . . . . . 21 87 12. Retrieval of Keying Material Version . . . . . . . . . . . . 21 88 13. Retrieval of Group Status . . . . . . . . . . . . . . . . . . 22 89 14. Request to Leave the Group . . . . . . . . . . . . . . . . . 22 90 15. Removal of a Group Member . . . . . . . . . . . . . . . . . . 23 91 16. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 23 92 17. Security Considerations . . . . . . . . . . . . . . . . . . . 25 93 17.1. Management of OSCORE Groups . . . . . . . . . . . . . . 25 94 17.2. Size of Nonces for Signature Challenge . . . . . . . . . 26 95 17.3. Reusage of Nonces for Signature Challenge . . . . . . . 27 96 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 97 18.1. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 28 98 18.2. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 28 99 18.3. OSCORE Security Context Parameters Registry . . . . . . 28 100 18.4. Sequence Number Synchronization Method Registry . . . . 29 101 18.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . 30 102 18.6. ACE Groupcomm Policy Registry . . . . . . . . . . . . . 30 103 18.7. TLS Exporter Label Registry . . . . . . . . . . . . . . 31 104 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 105 19.1. Normative References . . . . . . . . . . . . . . . . . . 31 106 19.2. Informative References . . . . . . . . . . . . . . . . . 33 107 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 34 108 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 36 109 B.1. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 36 110 B.2. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 37 111 B.3. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 37 112 B.4. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 38 113 B.5. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 38 114 B.6. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 39 115 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 39 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 118 1. Introduction 120 Object Security for Constrained RESTful Environments (OSCORE) 121 [RFC8613] is a method for application-layer protection of the 122 Constrained Application Protocol (CoAP) [RFC7252], using CBOR Object 123 Signing and Encryption (COSE) [RFC8152] and enabling end-to-end 124 security of CoAP payload and options. 126 As described in [I-D.ietf-core-oscore-groupcomm], Group OSCORE is 127 used to protect CoAP group communication over IP multicast 128 [I-D.ietf-core-groupcomm-bis]. This relies on a Group Manager, which 129 is responsible for managing an OSCORE group and enables the group 130 members to exchange CoAP messages secured with Group OSCORE. The 131 Group Manager can be responsible for multiple groups, coordinates the 132 joining process of new group members, and is entrusted with the 133 distribution and renewal of group keying material. 135 This specification is an application profile of 136 [I-D.ietf-ace-key-groupcomm], which itself builds on the ACE 137 framework for Authentication and Authorization 138 [I-D.ietf-ace-oauth-authz]. Message exchanges among the participants 139 as well as message formats and processing follow what specified in 140 [I-D.ietf-ace-key-groupcomm] for provisioning and renewing keying 141 material in group communication scenarios, where Group OSCORE is used 142 to protect CoAP group communication over IP multicast. 144 1.1. Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 148 "OPTIONAL" in this document are to be interpreted as described in BCP 149 14 [RFC2119][RFC8174] when, and only when, they appear in all 150 capitals, as shown here. 152 Readers are expected to be familiar with: 154 o The terms and concepts described in the ACE framework for 155 authentication and authorization [I-D.ietf-ace-oauth-authz]. The 156 terminology for entities in the considered architecture is defined 157 in OAuth 2.0 [RFC6749]. In particular, this includes Client (C), 158 Resource Server (RS), and Authorization Server (AS). 160 o The terms and concepts related to the CoAP protocol described in 161 [RFC7252][I-D.ietf-core-groupcomm-bis]. Unless otherwise 162 indicated, the term "endpoint" is used here following its OAuth 163 definition, aimed at denoting resources such as /token and 164 /introspect at the AS and /authz-info at the RS. This document 165 does not use the CoAP definition of "endpoint", which is "An 166 entity participating in the CoAP protocol". 168 o The terms and concept related to the message formats and 169 processing specified in [I-D.ietf-ace-key-groupcomm], for 170 provisioning and renewing keying material in group communication 171 scenarios. 173 o The terms and concepts for protection and processing of CoAP 174 messages through OSCORE [RFC8613] and through Group OSCORE 175 [I-D.ietf-core-oscore-groupcomm] in group communication scenarios. 176 These include the concept of Group Manager, as the entity 177 responsible for a set of groups where communications are secured 178 with Group OSCORE. In this specification, the Group Manager acts 179 as Resource Server. 181 Additionally, this document makes use of the following terminology. 183 o Group name is used as a synonym for group identifier in 184 [I-D.ietf-ace-key-groupcomm]. 186 o Requester: member of an OSCORE group that sends request messages 187 to other members of the group. 189 o Responder: member of an OSCORE group that receives request 190 messages from other members of the group. A responder may reply 191 back, by sending a response message to the requester which has 192 sent the request message. 194 o Monitor: member of an OSCORE group that is configured as responder 195 and never replies back to requesters after receiving request 196 messages. This corresponds to the term "silent server" used in 197 [I-D.ietf-core-oscore-groupcomm]. 199 o Signature verifier: entity external to the OSCORE group and 200 intended to verify the countersignature of messages exchanged in 201 the group. An authorized signature verifier does not join the 202 OSCORE group as an actual member, yet it can retrieve the public 203 keys of the current group members from the Group Manager. 205 2. Protocol Overview 207 Group communication for CoAP over IP multicast has been enabled in 208 [I-D.ietf-core-groupcomm-bis] and can be secured with Group Object 209 Security for Constrained RESTful Environments (OSCORE) [RFC8613] as 210 described in [I-D.ietf-core-oscore-groupcomm]. A network node joins 211 an OSCORE group by interacting with the responsible Group Manager. 212 Once registered in the group, the new node can securely exchange 213 messages with other group members. 215 This specification describes how to use [I-D.ietf-ace-key-groupcomm] 216 and [I-D.ietf-ace-oauth-authz] to perform a number of authentication, 217 authorization and key distribution actions, as defined in Section 2. 218 of [I-D.ietf-ace-key-groupcomm], for an OSCORE group. 220 With reference to [I-D.ietf-ace-key-groupcomm]: 222 o The node wishing to joining the OSCORE group, i.e. the joining 223 node, is the Client. 225 o The Group Manager is the Key Distribution Center (KDC), acting as 226 a Resource Server. 228 o The Authorization Server associated to the Group Manager is the 229 AS. 231 All communications between the involved entities MUST be secured. 233 In particular, communications between the Client and the Group 234 Manager leverage protocol-specific transport profiles of ACE to 235 achieve communication security, proof-of-possession and server 236 authentication. Note that it is expected that in the commonly 237 referred base-case of this specification, the transport profile to 238 use is pre-configured and well-known to nodes participating in 239 constrained applications. 241 2.1. Overview of the Joining Process 243 A node performs the steps described in Section 4.2 of 244 [I-D.ietf-ace-key-groupcomm] in order to join an OSCORE group. The 245 format and processing of messages exchanged among the participants 246 are further specified in Section 3 and Section 5 of this document. 248 2.2. Overview of the Group Rekeying Process 250 If the application requires backward and forward security, the Group 251 Manager MUST generate new keying material and distribute it to the 252 group (rekeying) upon membership changes. 254 That is, the group is rekeyed when a node joins the group as a new 255 member, or after a current member leaves the group. By doing so, a 256 joining node cannot access communications in the group prior its 257 joining, while a leaving node cannot access communications in the 258 group after its leaving. 260 The keying material distributed through a group rekeying MUST 261 include: 263 o a new Group Identifier (Gid) for the group, used as ID Context 264 parameter of the OSCORE Common Security Context of that group (see 265 Section 2 of [I-D.ietf-core-oscore-groupcomm]). Note that the Gid 266 differs from the plain group name introduced in Section 1.1, which 267 is a plain, stable and invariant identifier, with no cryptographic 268 relevance and meaning. 270 o a new value for the Master Secret parameter of the OSCORE Common 271 Security Context of that group (see Section 2 of 272 [I-D.ietf-core-oscore-groupcomm]). 274 Also, the distributed keying material MAY include a new value for the 275 Master Salt parameter of the OSCORE Common Security Context of that 276 group. 278 Upon generating the new group keying material and before starting its 279 distribution, the Group Manager MUST increment the version number of 280 the group keying material. When rekeying a group, the Group Manager 281 MUST preserve the current value of the Sender ID of each member in 282 that group. 284 The Group Manager MUST support the Group Rekeying Process described 285 in Section 16. Future application profiles may define alternative 286 message formats and distribution schemes to perform group rekeying. 288 3. Joining Node to Authorization Server 290 This section describes how the joining node interacts with the AS in 291 order to be authorized to join an OSCORE group under a given Group 292 Manager. In particular, it considers a joining node that intends to 293 contact that Group Manager for the first time. 295 The message exchange between the joining node and the AS consists of 296 the messages Authorization Request and Authorization Response defined 297 in Section 3 of [I-D.ietf-ace-key-groupcomm]. Note that what is 298 defined in [I-D.ietf-ace-key-groupcomm] applies, and only additions 299 or modifications to that specification are defined here. 301 3.1. Authorization Request 303 The Authorization Request message is as defined in Section 3.1 of 304 [I-D.ietf-ace-key-groupcomm], with the following additions. 306 o If the 'scope' parameter is present: 308 * The group name of each OSCORE group to join under the Group 309 Manager is encoded as a CBOR text string (REQ1). 311 * Accepted values for role identifiers in the OSCORE group to 312 join are: "requester", "responder", and "monitor" (REQ2). 313 Possible combinations are: ["requester" , "responder"]. An 314 additional role identifier is "verifier", denoting an external 315 signature verifier that does not join the OSCORE group. Each 316 role identifier MUST be encoded as a CBOR integer (REQ2), by 317 using for abbreviation the values specified in Figure 1 (OPT7). 319 +-----------+------------+ 320 | Name | CBOR Value | 321 +-----------+------------+ 322 | requester | TBD8 | 323 | responder | TBD9 | 324 | monitor | TBD10 | 325 | verifier | TBD11 | 326 +-----------+------------+ 328 Figure 1: CBOR Abbreviations for Role Identifiers in the Group 330 3.2. Authorization Response 332 The Authorization Response message is as defined in Section 3.2 of 333 [I-D.ietf-ace-key-groupcomm], with the following additions: 335 o The AS MUST include the 'expires_in' parameter. Other means for 336 the AS to specify the lifetime of Access Tokens are out of the 337 scope of this specification. 339 o The AS MUST include the 'scope' parameter, when the value included 340 in the Access Token differs from the one specified by the joining 341 node in the request. In such a case, the second element of each 342 scope entry MUST be present, and includes the role or CBOR array 343 of roles that the joining node is actually authorized to take in 344 the OSCORE group for that scope entry, encoded as specified in 345 Section 3.1 of this document. 347 4. Interface at the Group Manager 349 The Group Manager provides the interface defined in Section 4.1 of 350 [I-D.ietf-ace-key-groupcomm], with the following additional resource: 352 o /group-oscore/GROUPNAME/active: this sub-resource is fixed and 353 supports the GET method, whose handler is defined in Section 4.1. 355 4.1. GET Handler 357 The handler expects a GET request. 359 The handler verifies that the group identifier of the /group- 360 oscore/GROUPNAME/active path is a subset of the 'scope' stored in the 361 Access Token associated to the requesting client. If verification 362 fails, the Group Manager MUST respond with a 4.01 (Unauthorized) 363 error message. 365 If verification succeeds, the handler returns a 2.05 (Content) 366 message containing the CBOR simple value True if the group is 367 currently active, or the CBOR simple value False otherwise. The 368 group is considered active if it is set to allow new members to join, 369 and if communication within the group is expected. 371 The method to set the current group status, i.e. active or inactive, 372 is out of the scope of this specification, and is defined for the 373 administrator interface of the Group Manager specified in 374 [I-D.tiloca-ace-oscore-gm-admin]. 376 5. Token POST and Group Joining 378 The following subsections describe the interactions between the 379 joining node and the Group Manager, i.e. the sending of the Access 380 Token and the Request-Response exchange to join the OSCORE group. 381 The message exchange between the joining node and the KDC consists of 382 the messages defined in Section 3.3 and 4.2 of 383 [I-D.ietf-ace-key-groupcomm]. Note that what is defined in 384 [I-D.ietf-ace-key-groupcomm] applies, and only additions or 385 modifications to that specification are defined here. 387 A signature verifier provides the Group Manager with an Access Token, 388 as described in Section 5.1, just as any another joining node does. 389 However, unlike candidate group members, it does not join any OSCORE 390 group, i.e. it does not perform the joining process defined in 391 Section 5.2. After a successful token posting, a signature verifier 392 is authorized to perform only the operations specified in Section 9, 393 to retrieve the public keys of group members, and only for the OSCORE 394 groups specified in the validated Access Token. The Group Manager 395 MUST respond with a 4.01 (Unauthorized) error message, in case a 396 signature verifier attempts to access any other endpoint than /group- 397 oscore/GROUPNAME/pub-key at the Group Manager. 399 5.1. Token Post 401 The Token post exchange is defined in Section 3.3 of 402 [I-D.ietf-ace-key-groupcomm]. 404 Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the 405 following applies. 407 o The 'kdcchallenge' parameter contains a dedicated nonce N_S 408 generated by the Group Manager. For the N_S value, it is 409 RECOMMENDED to use a 8-byte long random nonce. The joining node 410 may use this nonce in order to prove the possession of its own 411 private key, upon joining the group (see Section 5.2). 413 The 'kdcchallenge' parameter MAY be omitted from the 2.01 414 (Created) response, if the 'scope' of the Access Token includes 415 only the role "monitor" or only the role "verifier", for each of 416 the specified groups. 418 o If the 'sign_info' parameter is present in the response, the 419 following applies for each element 'sign_info_entry'. 421 * In the 'id' element, every group name is encoded as a CBOR text 422 string (REQ1). 424 * 'sign_alg' takes value from Tables 5 and 6 of [RFC8152], if not 425 encoding the CBOR simple value Null. 427 * 'sign_parameters' takes values from the "Counter Signature 428 Parameters" Registry (see Section 11.1 of 429 [I-D.ietf-core-oscore-groupcomm]). Its structure depends on 430 the value of 'sign_alg'. If no parameters of the counter 431 signature algorithm are specified or if 'sign_alg' encodes the 432 CBOR simple value Null, 'sign_parameters' MUST be encoding the 433 CBOR simple value Null. 435 * 'sign_key_parameters' takes values from the "Counter Signature 436 Key Parameters" Registry (see Section 11.2 of 437 [I-D.ietf-core-oscore-groupcomm]). Its structure depends on 438 the value of 'sign_alg'. If no parameters of the key used with 439 the counter signature algorithm are specified or if 'sign_alg' 440 encodes the CBOR simple value Null, 'sign_key_parameters' MUST 441 be encoding the CBOR simple value Null. 443 * If 'pub_key_enc_res' is present, it takes value 1 ("COSE_Key") 444 from the 'Confirmation Key' column of the "CWT Confirmation 445 Method" Registry defined in [RFC8747], so indicating that 446 public keys in the OSCORE group are encoded as COSE Keys 447 [RFC8152]. Future specifications may define additional values 448 for this parameter. 450 Note that, other than through the above parameters as defined in 451 Section 3.3 of [I-D.ietf-ace-key-groupcomm], the joining node MAY 452 have previously retrieved this information by other means, e.g. by 453 using the approach described in [I-D.tiloca-core-oscore-discovery]. 455 Additionally, if allowed by the used transport profile of ACE, the 456 joining node may instead provide the Access Token to the Group 457 Manager by other means, e.g. during a secure session establishment 458 (see Section 3.3.1 of [I-D.ietf-ace-dtls-authorize]). 460 5.2. Sending the Joining Request 462 The joining node requests to join the OSCORE group, by sending a 463 Joining Request message to the related group-membership resource at 464 the Group Manager, as per Section 4.2 of 465 [I-D.ietf-ace-key-groupcomm]. 467 Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the 468 following applies. 470 o The string "group-oscore" is used instead of "ace-group" (see 471 Section 4.1 of [I-D.ietf-ace-key-groupcomm]) as the top level path 472 to the group-membership resource. The url-path /group-oscore/ is 473 a default name of this specifications: implementations are not 474 required to use this name, and can define their own instead. 476 o The 'get_pub_keys' parameter is present only if the joining node 477 wants to retrieve the public keys of the group members from the 478 Group Manager during the joining process (see Section 6). 479 Otherwise, this parameter MUST NOT be present. 481 o 'cnonce' contains a dedicated nonce N_C generated by the joining 482 node. For the N_C value, it is RECOMMENDED to use a 8-byte long 483 random nonce. 485 o The signature encoded in the 'client_cred_verify' parameter is 486 computed by the joining node by using the same private key and 487 countersignature algorithm it intends to use for signing messages 488 in the OSCORE group. Moreover, N_S is as defined in 489 Section 5.2.1. 491 5.2.1. Value of the N_S Challenge 493 The value of the N_S challenge is determined as follows. 495 1. If the joining node has posted the Access Token to the /authz- 496 info endpoint of the Group Manager as in Section 5.1, N_S takes 497 the same value of the most recent 'kdcchallenge' parameter 498 received by the joining node from the Group Manager. This can be 499 either the one specified in the 2.01 (Created) response to the 500 Token POST, or the one possibly specified in a 4.00 (Bad Request) 501 response to a following Joining Request (see Section 5.3). 503 2. If the Token posting has relied on the DTLS profile of ACE 504 [I-D.ietf-ace-dtls-authorize] with the Access Token as content of 505 the "psk_identity" field of the ClientKeyExchange message 506 [RFC6347], N_S is an exporter value computed as defined in 507 Section 7.5 of [RFC8446]. Specifically, N_S is exported from the 508 DTLS session between the joining node and the Group Manager, 509 using an empty 'context_value', 32 bytes as 'key_length', and the 510 exporter label "EXPORTER-ACE-Sign-Challenge-coap-group-oscore- 511 app" defined in Section 18.7 of this specification. 513 It is up to applications to define how N_S is computed in further 514 alternative settings. 516 Section 17.3 provides security considerations on the reusage of the 517 N_S challenge. 519 5.3. Processing the Joining Request 521 The Group Manager processes the Joining Request as defined in 522 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm]. Additionally, the 523 following applies. 525 o In case the Joining Request does not include the 'client_cred' 526 parameter, the joining process fails if the Group Manager either: 527 i) does not store a public key with an accepted format for the 528 joining node; or ii) stores multiple public keys with an accepted 529 format for the joining node. 531 o To compute the signature contained in 'client_cred_verify', the GM 532 considers: i) as signed value, N_S concatenated with N_C, where 533 N_S is determined as described in Section 5.2.1, while N_C is the 534 nonce provided in the 'cnonce' parameter of the Joining Request; 535 ii) the countersignature algorithm used in the OSCORE group, and 536 possible correponding parameters; and iii) the public key of the 537 joining node, either retrieved from the 'client_cred' parameter, 538 or already stored as acquired from previous interactions with the 539 joining node. 541 o A 4.00 Bad Request response from the Group Manager to the joining 542 node MUST have content format application/ace+cbor. The response 543 payload is a CBOR map which MUST contain the 'sign_info' 544 parameter, including a single element 'sign_info_entry' pertaining 545 the OSCORE group that the joining node tried to join with the 546 Joining Request. 548 o The Group Manager MUST return a 4.00 (Bad Request) response in 549 case the Joining Request includes the 'client_cred' parameter but 550 does not include both the 'cnonce' and 'client_cred_verify' 551 parameters. 553 o The Group Manager MUST return a 4.00 (Bad Request) response in 554 case it cannot retrieve a public key with an accepted format for 555 the joining node, either from the 'client_cred' parameter or as 556 already stored. 558 o When receiving a 4.00 Bad Request response, the joining node 559 SHOULD send a new Joining Request to the Group Manager, where: 561 * The 'cnonce' parameter MUST include a new dedicated nonce N_C 562 generated by the joining node. 564 * The 'client_cred' parameter MUST include a public key 565 compatible with the encoding, countersignature algorithm and 566 possible associated parameters indicated by the Group Manager. 568 * The 'client_cred_verify' parameter MUST include a signature 569 computed as described in Section 5.2, by using the public key 570 indicated in the current 'client_cred' parameter, with the 571 countersignature algorithm and possible associated parameters 572 indicated by the Group Manager. If the error response from the 573 Group Manager included the 'kdcchallenge' parameter, the 574 joining node MUST use its content as new N_S challenge to 575 compute the signature. 577 5.4. Joining Response 579 If the processing of the Joining Request described in Section 5.3 is 580 successful, the Group Manager updates the group membership by 581 registering the joining node NODENAME as a new member of the OSCORE 582 group GROUPNAME, as described in Section 4.1.2.1 of 583 [I-D.ietf-ace-key-groupcomm]. 585 If the joining node is not exclusively configured as monitor, the 586 Group Manager performs also the following actions. 588 o The Group Manager selects an available OSCORE Sender ID in the 589 OSCORE group, and exclusively assigns it to the joining node. 591 o The Group Manager stores the association between i) the public key 592 of the joining node; and ii) the Group Identifier (Gid), i.e. the 593 OSCORE ID Context, associated to the OSCORE group together with 594 the OSCORE Sender ID assigned to the joining node in the group. 595 The Group Manager MUST keep this association updated over time. 597 Then, the Group Manager replies to the joining node, providing the 598 updated security parameters and keying meterial necessary to 599 participate in the group communication. This success Joining 600 Response is formatted as defined in Section 4.1.2.1 of 601 [I-D.ietf-ace-key-groupcomm], with the following additions: 603 o The 'gkty' parameter identifies a key of type 604 "Group_OSCORE_Security_Context object", defined in Section 18.2 of 605 this specification. 607 o The 'key' parameter includes what the joining node needs in order 608 to set up the OSCORE Security Context as per Section 2 of 609 [I-D.ietf-core-oscore-groupcomm]. This parameter has as value a 610 Group_OSCORE_Security_Context object, which is defined in this 611 specification and extends the OSCORE_Security_Context object 612 encoded in CBOR as defined in Section 3.2.1 of 613 [I-D.ietf-ace-oscore-profile]. In particular, it contains the 614 additional parameters 'cs_alg', 'cs_params', 'cs_key_params' and 615 'cs_key_enc' defined in Section 18.3 of this specification. More 616 specifically, the 'key' parameter is composed as follows. 618 * The 'ms' parameter MUST be present and includes the OSCORE 619 Master Secret value. 621 * The 'clientId' parameter, if present, has as value the OSCORE 622 Sender ID assigned to the joining node by the Group Manager, as 623 described above. This parameter is not present if the node 624 joins the group exclusively as monitor, according to what 625 specified in the Access Token (see Section 3.2). In any other 626 case, this parameter MUST be present. 628 * The 'hkdf' parameter, if present, has as value the KDF 629 algorithm used in the group. 631 * The 'alg' parameter, if present, has as value the AEAD 632 algorithm used in the group. 634 * The 'salt' parameter, if present, has as value the OSCORE 635 Master Salt. 637 * The 'contextId' parameter MUST be present and has as value the 638 Group Identifier (Gid), i.e. the OSCORE ID Context of the 639 OSCORE group. 641 * The 'cs_alg' parameter MUST be present and specifies the 642 algorithm used to countersign messages in the group. This 643 parameter takes values from the "COSE Algorithms" Registry, 644 defined in Section 16.4 of [RFC8152]. 646 * The 'cs_params' parameter MAY be present and specifies the 647 additional parameters for the counter signature algorithm. 648 This parameter is a CBOR map whose content depends on the 649 counter signature algorithm, as specified in Section 2 and 650 Section 11.1 of [I-D.ietf-core-oscore-groupcomm]. 652 * The 'cs_key_params' parameter MAY be present and specifies the 653 additional parameters for the key used with the counter 654 signature algorithm. This parameter is a CBOR map whose 655 content depends on the counter signature algorithm, as 656 specified in Section 2 and Section 11.2 of 657 [I-D.ietf-core-oscore-groupcomm]. 659 * The 'cs_key_enc' parameter MAY be present and specifies the 660 encoding of the public keys of the group members. This 661 parameter is a CBOR integer, whose value is 1 ("COSE_Key") 662 taken from the 'Confirmation Key' column of the "CWT 663 Confirmation Method" Registry defined in [RFC8747], so 664 indicating that public keys in the OSCORE group are encoded as 665 COSE Keys [RFC8152]. Future specifications may define 666 additional values for this parameter. If this parameter is not 667 present, 1 ("COSE_Key") MUST be assumed as default value. 669 o The 'num' parameter MUST be present. 671 o The 'ace-groupcomm-profile' parameter MUST be present and has 672 value coap_group_oscore_app (TBD1), which is defined in 673 Section 18.1 of this specification. 675 o The 'exp' parameter MUST be present. 677 o The 'pub_keys' parameter, if present, includes the public keys of 678 the group members that are relevant to the joining node. That is, 679 it includes: i) the public keys of the responders currently in the 680 group, in case the joining node is configured (also) as requester; 681 and ii) the public keys of the requesters currently in the group, 682 in case the joining node is configured (also) as responder or 683 monitor. If public keys are encoded as COSE_Keys, each of them 684 has as 'kid' the Sender ID that the corresponding owner has in the 685 group, thus used as group member identifier. 687 o The 'group_policies' parameter SHOULD be present, and SHOULD 688 include the elements "Sequence Number Synchronization Method" and 689 "Key Update Check Interval" defined in Section 4.1.2 of 690 [I-D.ietf-ace-key-groupcomm], as well as the element "Group OSCORE 691 Pairwise Mode Support" defined in Section 5.5 of this 692 specification. 694 Finally, the joining node uses the information received in the 695 Joining Response to set up the OSCORE Security Context, as described 696 in Section 2 of [I-D.ietf-core-oscore-groupcomm]. In addition, the 697 joining node maintains an association between each public key 698 retrieved from the 'pub_keys' parameter and the role(s) that the 699 corresponding group member has in the group. 701 From then on, the joining node can exchange group messages secured 702 with Group OSCORE as described in [I-D.ietf-core-oscore-groupcomm]. 703 When doing so: 705 o The joining node MUST NOT process an incoming request message, if 706 signed by a group member whose public key is not associated to the 707 role "Requester". 709 o The joining node MUST NOT process an incoming response message, if 710 signed by a group member whose public key is not associated to the 711 role "Responder". 713 If the application requires backward security, the Group Manager MUST 714 generate updated security parameters and group keying material, and 715 provide it to the current group members upon the new node's joining 716 (see Section 16). As a consequence, the joining node is not able to 717 access secure communication in the group occurred prior its joining. 719 5.5. ACE Groupcomm Policy for Group OSCORE Pairwise Mode Support 721 This specifications defines the group policy "Group OSCORE Pairwise 722 Mode Support", for which it registers an entry in the "ACE Groupcomm 723 Policy" IANA Registry defined in Section 8.7 of 724 [I-D.ietf-ace-key-groupcomm]. 726 The corresponding element in the 'group_policies' parameter of the 727 Joining Response (see Section 5.4) encodes the CBOR simple value 728 True, if the OSCORE group supports the pairwise mode of Group OSCORE 729 [I-D.ietf-core-oscore-groupcomm], or the CBOR simple value False 730 otherwise (REQ14). 732 6. Public Keys of Joining Nodes 734 Source authentication of OSCORE messages exchanged within the group 735 is ensured by means of digital counter signatures (see Sections 2 and 736 4 of [I-D.ietf-core-oscore-groupcomm]). Therefore, group members 737 must be able to retrieve each other's public key from a trusted key 738 repository, in order to verify source authenticity of incoming group 739 messages. 741 As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group 742 Manager acts as trusted repository of the public keys of the group 743 members, and provides those public keys to group members if requested 744 to. Upon joining an OSCORE group, a joining node is thus expected to 745 provide its own public key to the Group Manager. 747 In particular, one of the following four cases can occur when a new 748 node joins an OSCORE group. 750 o The joining node is going to join the group exclusively as 751 monitor. That is, it is not going to send messages to the group, 752 and hence to produce signatures with its own private key. In this 753 case, the joining node is not required to provide its own public 754 key to the Group Manager, which thus does not have to perform any 755 check related to the public key encoding, or to a countersignature 756 algorithm and possible associated parameters for that joining 757 node. In case that joining node still provides a public key in 758 the 'client_cred' parameter of the Joining Request (see 759 Section 5.2), the Group Manager silently ignores that parameter, 760 as well as related the parameters 'cnonce' and 761 'client_cred_verify'. 763 o The Group Manager already acquired the public key of the joining 764 node during a past joining process. In this case, the joining 765 node MAY choose not to provide again its own public key to the 766 Group Manager, in order to limit the size of the Joining Request. 767 The joining node MUST provide its own public key again if it has 768 provided the Group Manager with multiple public keys during past 769 joining processes, intended for different OSCORE groups. If the 770 joining node provides its own public key, the Group Manager 771 performs consistency checks as per Section 5.3 and, in case of 772 success, considers it as the public key associated to the joining 773 node in the OSCORE group. 775 o The joining node and the Group Manager use an asymmetric proof-of- 776 possession key to establish a secure communication channel. Then, 777 two cases can occur. 779 1. The proof-of-possession key is compatible with the encoding as 780 well as with the counter signature algorithm and possible 781 associated parameters used in the OSCORE group. Then, the 782 Group Manager considers the proof-of-possession key as the 783 public key associated to the joining node in the OSCORE group. 784 If the joining node is aware that the proof-of-possession key 785 is also valid for the OSCORE group, it MAY not provide it 786 again as its own public key to the Group Manager. The joining 787 node MUST provide its own public key again if it has provided 788 the Group Manager with multiple public keys during past 789 joining processes, intended for different OSCORE groups. If 790 the joining node provides its own public key in the 791 'client_cred' parameter of the Joining Request (see 792 Section 5.2), the Group Manager performs consistency checks as 793 per Section 5.3 and, in case of success, considers it as the 794 public key associated to the joining node in the OSCORE group. 796 2. The proof-of-possession key is not compatible with the 797 encoding or with the counter signature algorithm and possible 798 associated parameters used in the OSCORE group. In this case, 799 the joining node MUST provide a different compatible public 800 key to the Group Manager in the 'client_cred' parameter of the 801 Joining Request (see Section 5.2). Then, the Group Manager 802 performs consistency checks on this latest provided public key 803 as per Section 5.3 and, in case of success, considers it as 804 the public key associated to the joining node in the OSCORE 805 group. 807 o The joining node and the Group Manager use a symmetric proof-of- 808 possession key to establish a secure communication channel. In 809 this case, upon performing a joining process with that Group 810 Manager for the first time, the joining node specifies its own 811 public key in the 'client_cred' parameter of the Joining Request 812 targeting the group-membership endpoint (see Section 5.2). 814 7. Retrieval of Updated Keying Material 816 At some point, a group member considers the OSCORE Security Context 817 invalid and to be renewed. This happens, for instance, after a 818 number of unsuccessful security processing of incoming messages from 819 other group members, or when the Security Context expires as 820 specified by the 'exp' parameter of the Joining Response. 822 When this happens, the group member retrieves updated security 823 parameters and group keying material. This can occur in the two 824 different ways described below. 826 7.1. Retrieval of Group Keying Material 828 If the group member wants to retrieve only the latest group keying 829 material, it sends a Key Distribution Request to the Group Manager. 831 In particular, it sends a CoAP GET request to the endpoint /group- 832 oscore/GROUPNAME at the Group Manager. 834 The Group Manager processes the Key Distribution Request according to 835 Section 4.1.2.2 of [I-D.ietf-ace-key-groupcomm]. The Key 836 Distribution Response is formatted as defined in Section 4.1.2.2 of 837 [I-D.ietf-ace-key-groupcomm]. In particular, the 'key' parameter is 838 formatted as defined in Section 5.4 of this specification, with the 839 difference that it does not include the 'clientId' parameter. 841 Upon receiving the Key Distribution Response, the group member 842 retrieves the updated security parameters and group keying material, 843 and, if they differ from the current ones, use them to set up the new 844 OSCORE Security Context as described in Section 2 of 845 [I-D.ietf-core-oscore-groupcomm]. 847 7.2. Retrieval of Group Keying Material and Sender ID 849 If the group member wants to retrieve the latest group keying 850 material as well as the Sender ID that it has in the OSCORE group, it 851 sends a Key Distribution Request to the Group Manager. 853 In particular, it sends a CoAP GET request to the endpoint /group- 854 oscore/GROUPNAME/nodes/NODENAME at the Group Manager. 856 The Group Manager processes the Key Distribution Request according to 857 Section 4.1.6.2 of [I-D.ietf-ace-key-groupcomm]. The Key 858 Distribution Response is formatted as defined in Section 4.1.6.2 of 859 [I-D.ietf-ace-key-groupcomm]. 861 In particular, the 'key' parameter is formatted as defined in 862 Section 5.4 of this specification, with the difference that if the 863 requesting group member is configured exclusively as monitor, no 864 'clientId' is specified within the 'key' parameter. Note that, in 865 any other case, the current Sender ID of the group member is not 866 specified as a separate parameter, but rather specified as 'clientId' 867 within the 'key' parameter. 869 Upon receiving the Key Distribution Response, the group member 870 retrieves the updated security parameters, group keying material and 871 Sender ID, and, if they differ from the current ones, use them to set 872 up the new OSCORE Security Context as described in Section 2 of 873 [I-D.ietf-core-oscore-groupcomm]. 875 8. Retrieval of New Keying Material 877 As discussed in Section 2.5 of [I-D.ietf-core-oscore-groupcomm], a 878 group member may at some point experience a wrap-around of its own 879 Sender Sequence Number in the group. 881 When this happens, the group member MUST send a Key Renewal Request 882 message to the Group Manager, as per Section 4.4 of 883 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP PUT 884 request to the endpoint /group-oscore/GROUPNAME/nodes/NODENAME at the 885 Group Manager. 887 Upon receiving the Key Renewal Request, the Group Manager processes 888 it as defined in Section 4.1.6.1 of [I-D.ietf-ace-key-groupcomm], and 889 performs one of the following actions. 891 1. If the requesting group member is configured exclusively as 892 monitor, the Group Manager replies with a 4.00 (Bad Request) 893 error response. 895 2. Otherwise, depending on the configured policies (OPT8), the Group 896 Manager takes one of the following actions. 898 a. The Group Manager rekeys the OSCORE group. That is, the 899 Group Manager generates new group keying material for that group 900 (see Section 16), and replies to the group member with a group 901 rekeying message as defined in Section 16, providing the new 902 group keying material. Then, the Group Manager rekeys the rest 903 of the OSCORE group, as discussed in Section 16. 905 b. The Group Manager generates a new Sender ID for that group 906 member and replies with a Key Renewal Response, formatted as 907 defined in Section 4.1.6.1 of [I-D.ietf-ace-key-groupcomm]. In 908 particular, the CBOR Map in the response payload includes a 909 single parameter 'clientId' defined in Section 18.5 of this 910 document, specifying the new Sender ID of the group member 911 encoded as a CBOR byte string. 913 9. Retrieval of Public Keys of Group Members 915 A group member or a signature verifier may need to retrieve the 916 public keys of (other) group members. To this end, the group member 917 or signature verifier sends a Public Key Request message to the Group 918 Manager, as per Section 4.5 of [I-D.ietf-ace-key-groupcomm]. In 919 particular, it sends the request to the endpoint /group- 920 oscore/GROUPNAME/pub-key at the Group Manager. 922 If the Public Key Request uses the method FETCH, the Public Key 923 Request is formatted as defined in Section 4.1.3.1 of 924 [I-D.ietf-ace-key-groupcomm]. In particular, each element of the 925 'get_pub_keys' parameter is a CBOR byte string, which encodes the 926 Sender ID of the group member for which the associated public key is 927 requested. 929 Upon receiving the Public Key Request, the Group Manager processes it 930 as per Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm], 931 depending on the request method being FETCH or GET, respectively. 932 Additionally, if the Public Key Request uses the method FETCH, the 933 Group Manager silently ignores identifiers included in the 934 'get_pub_keys' parameter of the request that are not associated to 935 any current group member. 937 The success Public Key Response is formatted as defined in 938 Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm], depending 939 on the request method being FETCH or GET, respectively. 941 10. Update of Public Key 943 A group member may need to provide the Group Manager with its new 944 public key to use in the group from then on, hence replacing the 945 current one. This can be the case, for instance, if the 946 countersignature algorithm and possible associated parameters used in 947 the OSCORE group have been changed, and the current public key is not 948 compatible with them. 950 To this end, the group member sends a Public Key Update Request 951 message to the Group Manager, as per Section 4.6 of 952 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP POST 953 request to the endpoint /group-oscore/GROUPNAME/nodes/NODENAME/pub- 954 key at the Group Manager. 956 Upon receiving the Group Leaving Request, the Group Manager processes 957 it as per Section 4.1.7.1 of [I-D.ietf-ace-key-groupcomm], with the 958 following additions. 960 o If the requesting group member is configured exclusively as 961 monitor, the Group Manager replies with a 4.00 (Bad request) error 962 response. 964 o The N_S signature challenge is computed as per point (3) in 965 Section 5.2.1 (REQ17). 967 o If the request is successfully processed, the Group Manager stores 968 the association between i) the new public key of the group member; 969 and ii) the Group Identifier (Gid), i.e. the OSCORE ID Context, 970 associated to the OSCORE group together with the OSCORE Sender ID 971 assigned to the group member in the group. The Group Manager MUST 972 keep this association updated over time. 974 11. Retrieval of Group Policies 976 A group member may request the current policies used in the OSCORE 977 group. To this end, the group member sends a Policies Request, as 978 per Section 4.7 of [I-D.ietf-ace-key-groupcomm]. In particular, it 979 sends a CoAP GET request to the endpoint /group-oscore/GROUPNAME/ 980 policies at the Group Manager, where GROUPNAME is the name of the 981 OSCORE group. 983 Upon receiving the Policies Request, the Group Manager processes it 984 as per Section 4.1.4.1 of [I-D.ietf-ace-key-groupcomm]. The success 985 Policies Response is formatted as defined in Section 4.1.4.1 of 986 [I-D.ietf-ace-key-groupcomm]. 988 12. Retrieval of Keying Material Version 990 A group member may request the current version of the keying material 991 used in the OSCORE group. To this end, the group member sends a 992 Version Request, as per Section 4.8 of [I-D.ietf-ace-key-groupcomm]. 993 In particular, it sends a CoAP GET request to the endpoint /group- 994 oscore/GROUPNAME/ctx-num at the Group Manager, where GROUPNAME is the 995 name of the OSCORE group. 997 Upon receiving the Version Request, the Group Manager processes it as 998 per Section 4.1.5.1 of [I-D.ietf-ace-key-groupcomm]. The success 999 Version Response is formatted as defined in Section 4.1.5.1 of 1000 [I-D.ietf-ace-key-groupcomm]. 1002 13. Retrieval of Group Status 1004 A group member may request the current status of the the OSCORE 1005 group, i.e. active or inactive. To this end, the group member sends 1006 a Group Status Request to the Group Manager. 1008 In particular, the group member sends a CoAP GET request to the 1009 endpoint /group-oscore/GROUPNAME/active at the Group Manager defined 1010 in Section 4 of this specification, where GROUPNAME is the name of 1011 the OSCORE group. The success Group Version Response is formatted as 1012 defined in Section 4 of this specification. 1014 Upon learning from a 2.05 (Content) response that the group is 1015 currently inactive, the group member SHOULD stop taking part in 1016 communications within the group, until it becomes active again. 1018 Upon learning from a 2.05 (Content) response that the group has 1019 become active again, the group member can resume taking part in 1020 communications within the group. 1022 Figure 2 gives an overview of the exchange described above. 1024 Group Group 1025 Member Manager 1026 | | 1027 |------ Group Status Request: GET ace-group/GID/active ------>| 1028 | | 1029 |<---------- Group Status Response: 2.05 (Content) -----------| 1030 | | 1032 Figure 2: Message Flow of Group Status Request-Response 1034 14. Request to Leave the Group 1036 A group member may request to leave the OSCORE group. To this end, 1037 the group member sends a Group Leaving Request, as per Section 4.9 of 1038 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP DELETE 1039 request to the endpoint /group-oscore/GROUPNAME/nodes/NODENAME at the 1040 Group Manager. 1042 Upon receiving the Group Leaving Request, the Group Manager processes 1043 it as per Section 4.1.6.3 of [I-D.ietf-ace-key-groupcomm]. 1045 15. Removal of a Group Member 1047 Other than after a spontaneous request to the Group Manager as 1048 described in Section 14, a node may be forcibly removed from the 1049 OSCORE group, e.g. due to expired or revoked authorization. 1051 If, upon joining the group (see Section 5.2), the leaving node 1052 specified a URI in the 'control_path' parameter defined in 1053 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm], the Group Manager 1054 MUST inform the leaving node of its eviction, by sending a DELETE 1055 request targeting the URI specified in the 'control_path' parameter 1056 (OPT9). 1058 If the leaving node is not configured exclusively as monitor, the 1059 Group Manager performs the following actions. 1061 o The Group Manager frees the OSCORE Sender ID value of the leaving 1062 node, which becomes available for possible upcoming joining nodes. 1064 o The Group Manager cancels the association between, on one hand, 1065 the public key of the leaving node and, on the other hand, the 1066 Group Identifier (Gid) associated to the OSCORE group together 1067 with the freed OSCORE Sender ID value. The Group Manager deletes 1068 the public key of the leaving node, if that public key has no 1069 remaining association with any pair (Gid, Sender ID). 1071 If the application requires forward security, the Group Manager MUST 1072 generate updated security parameters and group keying material, and 1073 provide it to the remaining group members (see Section 16). As a 1074 consequence, the leaving node is not able to acquire the new security 1075 parameters and group keying material distributed after its leaving. 1077 Same considerations in Section 5 of [I-D.ietf-ace-key-groupcomm] 1078 apply here as well, considering the Group Manager acting as KDC. 1080 16. Group Rekeying Process 1082 In order to rekey the OSCORE group, the Group Manager distributes a 1083 new Group Identifier (Gid), i.e. a new OSCORE ID Context; a new 1084 OSCORE Master Secret; and, optionally, a new OSCORE Master Salt for 1085 that group. When doing so, the Group Manager MUST increment the 1086 version number of the group keying material, before starting its 1087 distribution. 1089 Furthermore, the Group Manager MUST preserve the same unchanged 1090 Sender IDs for all group members. This avoids affecting the 1091 retrieval of public keys from the Group Manager as well as the 1092 verification of message countersignatures. 1094 The Group Manager MUST support at least the following group rekeying 1095 scheme. Future application profiles may define alternative message 1096 formats and distribution schemes. 1098 As group rekeying message, the Group Manager uses the same format of 1099 the Joining Response message in Section 5.4. In particular: 1101 o Only the parameters 'gkty', 'key', 'num', 'ace-groupcomm-profile' 1102 and 'exp' are present. 1104 o The 'ms' parameter of the 'key' parameter specifies the new OSCORE 1105 Master Secret value. 1107 o The 'contextId' parameter of the 'key' parameter specifies the new 1108 Group ID. 1110 The Group Manager separately sends a group rekeying message to each 1111 group member to be rekeyed. 1113 Each rekeying message MUST be secured with the pairwise secure 1114 communication channel between the Group Manager and the group member 1115 used during the joining process. In particular, each rekeying 1116 message can target the 'control_path' URI path defined in 1117 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm] (OPT9), if provided 1118 by the intended recipient upon joining the group (see Section 5.2). 1120 It is RECOMMENDED that the Group Manager gets confirmation of 1121 successful distribution from the group members, and admits a maximum 1122 number of individual retransmissions to non-confirming group members. 1124 In case the rekeying terminates and some group members have not 1125 received the new keying material, they will not be able to correctly 1126 process following secured messages exchanged in the group. These 1127 group members will eventually contact the Group Manager, in order to 1128 retrieve the current keying material and its version. 1130 This approach requires group members to act (also) as servers, in 1131 order to correctly handle unsolicited group rekeying messages from 1132 the Group Manager. In particular, if a group member and the Group 1133 Manager use OSCORE [RFC8613] to secure their pairwise communications, 1134 the group member MUST create a Replay Window in its own Recipient 1135 Context upon establishing the OSCORE Security Context with the Group 1136 Manager, e.g. by means of the OSCORE profile of ACE 1137 [I-D.ietf-ace-oscore-profile]. 1139 Group members and the Group Manager SHOULD additionally support 1140 alternative rekeying approaches that do not require group members to 1141 act (also) as servers. A number of such approaches are defined in 1142 Section 4.3 of [I-D.ietf-ace-key-groupcomm]. In particular, a group 1143 member may subscribe for updates to the group-membership resource of 1144 the group, at the endpoint /group-oscore/GROUPNAME/nodes/NODENAME of 1145 the Group Manager. This can rely on CoAP Observe [RFC7641] or on a 1146 full-fledged Pub-Sub model [I-D.ietf-core-coap-pubsub] with the Group 1147 Manager acting as Broker. 1149 17. Security Considerations 1151 Security considerations for this profile are inherited from 1152 [I-D.ietf-ace-key-groupcomm], the ACE framework for Authentication 1153 and Authorization [I-D.ietf-ace-oauth-authz], and the specific 1154 transport profile of ACE signalled by the AS, such as 1155 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile]. 1157 The following security considerations also apply for this profile. 1159 17.1. Management of OSCORE Groups 1161 This profile leverages the following management aspects related to 1162 OSCORE groups and discussed in the sections of 1163 [I-D.ietf-core-oscore-groupcomm] referred below. 1165 o Management of group keying material (see Section 2.4 of 1166 [I-D.ietf-core-oscore-groupcomm]). The Group Manager is 1167 responsible for the renewal and re-distribution of the keying 1168 material in the groups of its competence (rekeying). According to 1169 the specific application requirements, this can include rekeying 1170 the group upon changes in its membership. In particular, renewing 1171 the group keying material is required upon a new node's joining or 1172 a current node's leaving, in case backward security and forward 1173 security have to be preserved, respectively. 1175 o Provisioning and retrieval of public keys (see Section 2 of 1176 [I-D.ietf-core-oscore-groupcomm]). The Group Manager acts as key 1177 repository of public keys of group members, and provides them upon 1178 request. 1180 o Synchronization of sequence numbers (see Section 6.1 of 1181 [I-D.ietf-core-oscore-groupcomm]). This concerns how a responder 1182 node that has just joined an OSCORE group can synchronize with the 1183 sequence number of requesters in the same group. 1185 Before sending the Joining Response, the Group Manager MUST verify 1186 that the joining node actually owns the associated private key. To 1187 this end, the Group Manager can rely on the proof-of-possession 1188 challenge-response defined in Section 5. Alternatively, the joining 1189 node can use its own public key as asymmetric proof-of-possession key 1190 to establish a secure channel with the Group Manager, e.g. as in 1191 Section 3.2 of [I-D.ietf-ace-dtls-authorize]. However, this requires 1192 such proof-of-possession key to be compatible with the encoding as 1193 well as with the countersignature algorithm and possible associated 1194 parameters used in the OSCORE group. 1196 A node may have joined multiple OSCORE groups under different non- 1197 synchronized Group Managers. Therefore, it can happen that those 1198 OSCORE groups have the same Group Identifier (Gid). It follows that, 1199 upon receiving a Group OSCORE message addressed to one of those 1200 groups, the node would have multiple Security Contexts matching with 1201 the Gid in the incoming message. It is up to the application to 1202 decide how to handle such collisions of Group Identifiers, e.g. by 1203 trying to process the incoming message using one Security Context at 1204 the time until the right one is found. 1206 17.2. Size of Nonces for Signature Challenge 1208 With reference to the Joining Request message in Section 5.2, the 1209 proof-of-possession signature included in 'client_cred_verify' is 1210 computed over the challenge N_C | N_S, where | denotes concatenation. 1212 For the N_C challenge share, it is RECOMMENDED to use a 8-byte long 1213 random nonce. Furthermore, N_C is always conveyed in the 'cnonce' 1214 parameter of the Joining Request, which is always sent over the 1215 secure communication channel between the joining node and the Group 1216 Manager. 1218 As defined in Section 5.2.1, the way the N_S value is computed 1219 depends on the particular way the joining node provides the Group 1220 Manager with the Access Token, as well as on following interactions 1221 between the two. 1223 o If the Access Token is not explicitly posted to the /authz-info 1224 endpoint of the Group Manager, then N_S is computed as a 32-byte 1225 long challenge share (see points 2 of Section 5.2.1). 1227 o If the Access Token has been explicitly posted to the /authz-info 1228 endpoint of the Group Manager, N_S takes the most recent value 1229 specified to the client by the Group Manager in the 'kdcchallenge' 1230 parameter (see point 1 of Section 5.2.1). This is specified 1231 either in the 2.01 response to the Token Post (see Section 5.1), 1232 or in a 4.00 response to a following Joining Request (see 1233 Section 5.3). In either case, it is RECOMMENDED to use a 8-byte 1234 long random challenge as value for N_S. 1236 If we consider both N_C and N_S to take 8-byte long values, the 1237 following considerations hold. 1239 o Let us consider both N_C and N_S as taking random values, and the 1240 Group Manager to never change the value of the N_S provided to a 1241 Client during the lifetime of an Access Token. Then, as per the 1242 birthday paradox, the average collision for N_S will happen after 1243 2^32 new posted Access Tokens, while the average collision for N_C 1244 will happen after 2^32 new Joining Requests. This amounts to 1245 considerably more token provisionings than the expected new 1246 joinings of OSCORE groups under a same Group Manager, as well as 1247 to considerably more requests to join OSCORE groups from a same 1248 Client using a same Access Token under a same Group Manager. 1250 o Section 7 of [I-D.ietf-ace-oscore-profile] as well Appendix B.2 of 1251 [RFC8613] recommend the use of 8-byte random values as well. 1252 Unlike in those cases, the values of N_C and N_S considered in 1253 this specification are not used for as sensitive operations as the 1254 derivation of a Security Context, with possible implications in 1255 the security of AEAD ciphers. 1257 17.3. Reusage of Nonces for Signature Challenge 1259 As long as the Group Manager preserves the same N_S value currently 1260 associated to an Access Token, i.e. the latest value provided to a 1261 Client in a 'kdcchallenge' parameter, the Client is able to 1262 successfully reuse the same signature challenge for multiple Joining 1263 Requests to that Group Manager. 1265 In particular, the client can reuse the same N_C value for every 1266 Joining Request to the Group Manager, and combine it with the same 1267 unchanged N_S value. This results in reusing the same signature 1268 challenge for producing the signature to include in the 1269 'client_cred_verify' parameter of the Joining Requests. 1271 Unless the Group Manager maintains a list of N_C values already used 1272 by that Client since the latest update to the N_S value associated to 1273 the Access Token, the Group Manager can be forced to falsely believe 1274 that the Client possesses its own private key at that point in time, 1275 upon verifying the signature in the 'client_cred_verify' parameter. 1277 18. IANA Considerations 1279 Note to RFC Editor: Please replace all occurrences of "[[This 1280 specification]]" with the RFC number of this specification and delete 1281 this paragraph. 1283 This document has the following actions for IANA. 1285 18.1. ACE Groupcomm Profile Registry 1287 IANA is asked to register the following entry in the "ACE Groupcomm 1288 Profile" Registry defined in Section 9.6 of 1289 [I-D.ietf-ace-key-groupcomm]. 1291 o Name: coap_group_oscore_app 1293 o Description: Application profile to provision keying material for 1294 participating in group communication protected with Group OSCORE 1295 as per [I-D.ietf-core-oscore-groupcomm]. 1297 o CBOR Value: TBD1 1299 o Reference: [[This specification]] (Section 5.4) 1301 18.2. ACE Groupcomm Key Registry 1303 IANA is asked to register the following entry in the "ACE Groupcomm 1304 Key" Registry defined in Section 9.5 of [I-D.ietf-ace-key-groupcomm]. 1306 o Name: Group_OSCORE_Security_Context object 1308 o Key Type Value: TBD2 1310 o Profile: "coap_group_oscore_app", defined in Section 18.1 of this 1311 specification. 1313 o Description: A Group_OSCORE_Security_Context object encoded as 1314 described in Section 5.4 of this specification. 1316 o Reference: [[This specification]] (Section 5.4) 1318 18.3. OSCORE Security Context Parameters Registry 1320 IANA is asked to register the following entries in the "OSCORE 1321 Security Context Parameters" Registry defined in Section 9.4 of 1322 [I-D.ietf-ace-oscore-profile]. 1324 o Name: cs_alg 1326 o CBOR Label: TBD3 1328 o CBOR Type: tstr / int 1330 o Registry: COSE Algorithm Values (ECDSA, EdDSA) 1332 o Description: OSCORE Counter Signature Algorithm Value 1333 o Reference: [[This specification]] (Section 5.4) 1335 o Name: cs_params 1337 o CBOR Label: TBD4 1339 o CBOR Type: map 1341 o Registry: Counter Signatures Parameters 1343 o Description: OSCORE Counter Signature Algorithm Additional 1344 Parameters 1346 o Reference: [[This specification]] (Section 5.4) 1348 o Name: cs_key_params 1350 o CBOR Label: TBD5 1352 o CBOR Type: map 1354 o Registry: Counter Signatures Key Parameters 1356 o Description: OSCORE Counter Signature Key Additional Parameters 1358 o Reference: [[This specification]] (Section 5.4) 1360 o Name: cs_key_enc 1362 o CBOR Label: TBD6 1364 o CBOR Type: integer 1366 o Registry: ACE Public Key Encoding 1368 o Description: Encoding of Public Keys to be used with the OSCORE 1369 Counter Signature Algorithm 1371 o Reference: [[This specification]] (Section 5.4) 1373 18.4. Sequence Number Synchronization Method Registry 1375 IANA is asked to register the following entries in the "Sequence 1376 Number Synchronization Method" Registry defined in Section 9.8 of 1377 [I-D.ietf-ace-key-groupcomm]. 1379 o Name: Best effort 1381 o Value: 1 1383 o Description: No action is taken. 1385 o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.1) 1387 o Name: Baseline 1389 o Value: 2 1391 o Description: The first received request sets the baseline 1392 reference point, and is discarded with no delivery to the 1393 application. 1395 o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.2) 1397 o Name: Echo challenge-response 1399 o Value: 3 1401 o Description: Challenge response using the Echo Option for CoAP 1402 from [I-D.ietf-core-echo-request-tag]. 1404 o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.3) 1406 18.5. ACE Groupcomm Parameters Registry 1408 IANA is asked to register the following entry in the "ACE Groupcomm 1409 Parameters" Registry defined in Section 9.4 of 1410 [I-D.ietf-ace-key-groupcomm]. 1412 o Name: clientId 1414 o CBOR Key: TBD7 1416 o CBOR Type: Byte string 1418 o Reference: [[This specification]] (Section 8) 1420 18.6. ACE Groupcomm Policy Registry 1422 IANA is asked to register the following entry in the "ACE Groupcomm 1423 Policy" Registry defined in Section 8.7 of 1424 [I-D.ietf-ace-key-groupcomm]. 1426 o Name: Group OSCORE Pairwise Mode Support 1428 o CBOR Key: TBD8 1430 o CBOR Type: Simple value 1432 o Description: True if the OSCORE group supports the pairwise mode 1433 of Group OSCORE [I-D.ietf-core-oscore-groupcomm], False otherwise. 1435 o Reference: [[This specification]] (Section 5.5) 1437 18.7. TLS Exporter Label Registry 1439 IANA is asked to register the following entry in the "TLS Exporter 1440 Label" Registry defined in Section 6 of [RFC5705] and updated in 1441 Section 12 of [RFC8447]. 1443 o Value: EXPORTER-ACE-Sign-Challenge-coap-group-oscore-app 1445 o DTLS-OK: Y 1447 o Recommended: N 1449 o Reference: [[This specification]] (Section 5.2.1) 1451 19. References 1453 19.1. Normative References 1455 [I-D.ietf-ace-key-groupcomm] 1456 Palombini, F. and M. Tiloca, "Key Provisioning for Group 1457 Communication using ACE", draft-ietf-ace-key-groupcomm-06 1458 (work in progress), May 2020. 1460 [I-D.ietf-ace-oauth-authz] 1461 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1462 H. Tschofenig, "Authentication and Authorization for 1463 Constrained Environments (ACE) using the OAuth 2.0 1464 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33 1465 (work in progress), February 2020. 1467 [I-D.ietf-ace-oscore-profile] 1468 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 1469 "OSCORE profile of the Authentication and Authorization 1470 for Constrained Environments Framework", draft-ietf-ace- 1471 oscore-profile-10 (work in progress), March 2020. 1473 [I-D.ietf-core-oscore-groupcomm] 1474 Tiloca, M., Selander, G., Palombini, F., and J. Park, 1475 "Group OSCORE - Secure Group Communication for CoAP", 1476 draft-ietf-core-oscore-groupcomm-08 (work in progress), 1477 April 2020. 1479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1480 Requirement Levels", BCP 14, RFC 2119, 1481 DOI 10.17487/RFC2119, March 1997, 1482 . 1484 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1485 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1486 March 2010, . 1488 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1489 Application Protocol (CoAP)", RFC 7252, 1490 DOI 10.17487/RFC7252, June 2014, 1491 . 1493 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1494 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1495 . 1497 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1498 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1499 May 2017, . 1501 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1502 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1503 . 1505 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 1506 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 1507 . 1509 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1510 "Object Security for Constrained RESTful Environments 1511 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1512 . 1514 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 1515 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 1516 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 1517 2020, . 1519 19.2. Informative References 1521 [I-D.ietf-ace-dtls-authorize] 1522 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 1523 L. Seitz, "Datagram Transport Layer Security (DTLS) 1524 Profile for Authentication and Authorization for 1525 Constrained Environments (ACE)", draft-ietf-ace-dtls- 1526 authorize-09 (work in progress), December 2019. 1528 [I-D.ietf-core-coap-pubsub] 1529 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1530 Subscribe Broker for the Constrained Application Protocol 1531 (CoAP)", draft-ietf-core-coap-pubsub-09 (work in 1532 progress), September 2019. 1534 [I-D.ietf-core-echo-request-tag] 1535 Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, 1536 Request-Tag, and Token Processing", draft-ietf-core-echo- 1537 request-tag-09 (work in progress), March 2020. 1539 [I-D.ietf-core-groupcomm-bis] 1540 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1541 for the Constrained Application Protocol (CoAP)", draft- 1542 ietf-core-groupcomm-bis-00 (work in progress), March 2020. 1544 [I-D.tiloca-ace-oscore-gm-admin] 1545 Tiloca, M., Hoeglund, R., Stok, P., Palombini, F., and K. 1546 Hartke, "Admin Interface for the OSCORE Group Manager", 1547 draft-tiloca-ace-oscore-gm-admin-01 (work in progress), 1548 March 2020. 1550 [I-D.tiloca-core-oscore-discovery] 1551 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 1552 Groups with the CoRE Resource Directory", draft-tiloca- 1553 core-oscore-discovery-05 (work in progress), March 2020. 1555 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1556 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1557 January 2012, . 1559 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1560 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1561 . 1563 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1564 Application Protocol (CoAP)", RFC 7641, 1565 DOI 10.17487/RFC7641, September 2015, 1566 . 1568 Appendix A. Profile Requirements 1570 This appendix lists the specifications on this application profile of 1571 ACE, based on the requiremens defined in Appendix A of 1572 [I-D.ietf-ace-key-groupcomm]. 1574 o REQ1 - Specify the encoding and value of the identifier of group, 1575 for scope entries of 'scope': see Section 3.1 and Section 5.1. 1577 o REQ2 - Specify the encoding and value of roles, for scope entries 1578 of 'scope': see Section 3.1. 1580 o REQ3 - if used, specify the acceptable values for 'sign_alg': 1581 values from Tables 5 and 6 of [RFC8152]. 1583 o REQ4 - If used, specify the acceptable values for 1584 'sign_parameters': values from the "Counter Signature Parameters" 1585 Registry (see Section 11.1 of [I-D.ietf-core-oscore-groupcomm]). 1587 o REQ5 - If used, specify the acceptable values for 1588 'sign_key_parameters': values from the "Counter Signature Key 1589 Parameters" Registry (see Section 11.2 of 1590 [I-D.ietf-core-oscore-groupcomm]). 1592 o REQ6 - If used, specify the acceptable values for 'pub_key_enc': 1 1593 ("COSE_Key") from the 'Confirmation Key' column of the "CWT 1594 Confirmation Method" Registry defined in [RFC8747]. Future 1595 specifications may define additional values for this parameter. 1597 o REQ7 - Format of the 'key' value: see Section 5.4. 1599 o REQ8 - Acceptable values of 'gkty': Group_OSCORE_Security_Context 1600 object (see Section 5.4). 1602 o REQ9: Specify the format of the identifiers of group members: see 1603 Section 5.4 and Section 9. 1605 o REQ10 - Specify the communication protocol that the members of the 1606 group must use: CoAP, possibly over IP multicast. 1608 o REQ11 - Specify the security protocols that the group members must 1609 use to protect their communication: Group OSCORE. 1611 o REQ12 - Specify and register the application profile identifier: 1612 coap_group_oscore_app (see Section 18.1). 1614 o REQ13 - Specify policies at the KDC to handle member ids that are 1615 not included in 'get_pub_keys': see Section 9. 1617 o REQ14 - If used, specify the format and content of 1618 'group_policies' and its entries: see Section 5.4; the three 1619 values defined and registered, as content of the entry "Sequence 1620 Number Synchronization Method" (see Section 18.4); the defined and 1621 registered encoding of the entry "Group OSCORE Pairwise Mode 1622 Support" (see Section 18.6). 1624 o REQ15 - Specify the format of newly-generated individual keying 1625 material for group members, or of the information to derive it, 1626 and corresponding CBOR label: see Section 8. 1628 o REQ16 - Specify how the communication is secured between the 1629 Client and KDC: by means of any transport profile of ACE 1630 [I-D.ietf-ace-oauth-authz] between Client and Group Manager that 1631 complies with the requirements in Appendix C of 1632 [I-D.ietf-ace-oauth-authz]. 1634 o REQ17: Specify how the nonce N_S is generated, if the token is not 1635 being posted (e.g. if it is used directly to validate TLS 1636 instead): see Section 5.2.1. 1638 o REQ18: Specify if 'mgt_key_material' used, and if yes specify its 1639 format and content: not used in this version of the profile. 1641 o OPT1 (Optional) - Specify the encoding of public keys, of 1642 'client_cred', and of 'pub_keys' if COSE_Keys are not used: no. 1644 o OPT2 (Optional) - Specify the negotiation of parameter values for 1645 signature algorithm and signature keys, if 'sign_info' and 1646 'pub_key_enc' are not used: possible early discovery by using the 1647 approach based on the CoRE Resource Directory described in 1648 [I-D.tiloca-core-oscore-discovery]. 1650 o OPT3 (Optional) - Specify the encoding of 'pub_keys_repos' if the 1651 default is not used: no. 1653 o OPT4 (Optional) - Specify policies that instruct clients to retain 1654 unsuccessfully decrypted messages and for how long, so that they 1655 can be decrypted after getting updated keying material: no. 1657 o OPT5 (Optional) - Specify the behavior of the handler in case of 1658 failure to retrieve a public key for the specific node: send a 1659 4.00 Bad Request response to a Joining Request (see Section 5.3). 1661 o OPT6 (Optional) - Specify possible or required payload formats for 1662 specific error cases: send a 4.00 Bad Request response to a 1663 Joining Request (see Section 5.3). 1665 o OPT7 (Optional) - Specify CBOR values to use for abbreviating 1666 identifiers of roles in the group or topic (see Section 3.1). 1668 o OPT8 (Optional) - Specify policies for the KDC to perform group 1669 rekeying after receiving a Key Renewal Request: no. 1671 o OPT9 (Optional) - Specify the functionalities implemented at the 1672 'control_path' resource hosted at the Client, including message 1673 exchange encoding and other details (see Section 4.1.2.1 of 1674 [I-D.ietf-ace-key-groupcomm]): see Section 15 for the eviction of 1675 a group member; see Section 16 for the group rekeying process. 1677 o OPT10 (Optional) - Specify how the identifier of the sender's 1678 public key is included in the group request: no. 1680 Appendix B. Document Updates 1682 RFC EDITOR: PLEASE REMOVE THIS SECTION. 1684 B.1. Version -05 to -06 1686 o Added role of external signature verifier. 1688 o Parameter 'rsnonce' renamed to 'kdcchallenge'. 1690 o Parameter 'kdcchallenge' may be omitted in some cases. 1692 o Clarified difference between group name and OSCORE Gid. 1694 o Removed the role combination ["requester", "monitor"]. 1696 o Admit implicit scope and audience in the Authorization Request. 1698 o New format for the 'sign_info' parameter. 1700 o Scope not mandatory to include in the Joining Request. 1702 o Group policy about supporting Group OSCORE in pairwise mode. 1704 o Possible individual rekeying of a single requesting node combined 1705 with a group rekeying. 1707 o Security considerations on reusage of signature challenges. 1709 o Addressing optional requirement OPT9 from draft-ietf-ace-key- 1710 groupcomm 1712 o Editorial improvements. 1714 B.2. Version -04 to -05 1716 o Nonce N_S also in error responses to the Joining Requests. 1718 o Supporting single Access Token for multiple groups/topics. 1720 o Supporting legal requesters/responders using the 'peer_roles' 1721 parameter. 1723 o Registered and used dedicated label for TLS Exporter. 1725 o Added method for uploading a new public key to the Group Manager. 1727 o Added resource and method for retrieving the current group status. 1729 o Fixed inconsistency in retrieving group keying material only. 1731 o Clarified retrieval of keying material for monitor-only members. 1733 o Clarification on incrementing version number when rekeying the 1734 group. 1736 o Clarification on what is re-distributed with the group rekeying. 1738 o Security considerations on the size of the nonces used for the 1739 signature challenge. 1741 o Added CBOR values to abbreviate role identifiers in the group. 1743 B.3. Version -03 to -04 1745 o New abstract. 1747 o Moved general content to draft-ietf-ace-key-groupcomm 1749 o Terminology: node name; node resource. 1751 o Creation and pointing at node resource. 1753 o Updated Group Manager API (REST methods and offered services). 1755 o Size of challenges 'cnonce' and 'rsnonce'. 1757 o Value of 'rsnonce' for reused or non-traditionally-posted tokens. 1759 o Removed reference to RFC 7390. 1761 o New requirements from draft-ietf-ace-key-groupcomm 1762 o Editorial improvements. 1764 B.4. Version -02 to -03 1766 o New sections, aligned with the interface of ace-key-groupcomm . 1768 o Exchange of information on the countersignature algorithm and 1769 related parameters, during the Token POST (Section 4.1). 1771 o Nonce 'rsnonce' from the Group Manager to the Client 1772 (Section 4.1). 1774 o Client PoP signature in the Key Distribution Request upon joining 1775 (Section 4.2). 1777 o Local actions on the Group Manager, upon a new node's joining 1778 (Section 4.2). 1780 o Local actions on the Group Manager, upon a node's leaving 1781 (Section 12). 1783 o IANA registration in ACE Groupcomm Parameters Registry. 1785 o More fulfilled profile requirements (Appendix A). 1787 B.5. Version -01 to -02 1789 o Editorial fixes. 1791 o Changed: "listener" to "responder"; "pure listener" to "monitor". 1793 o Changed profile name to "coap_group_oscore_app", to reflect it is 1794 an application profile. 1796 o Added the 'type' parameter for all requests to a Join Resource. 1798 o Added parameters to indicate the encoding of public keys. 1800 o Challenge-response for proof-of-possession of signature keys 1801 (Section 4). 1803 o Renamed 'key_info' parameter to 'sign_info'; updated its format; 1804 extended to include also parameters of the countersignature key 1805 (Section 4.1). 1807 o Code 4.00 (Bad request), in responses to joining nodes providing 1808 an invalid public key (Section 4.3). 1810 o Clarifications on provisioning and checking of public keys 1811 (Sections 4 and 6). 1813 o Extended discussion on group rekeying and possible different 1814 approaches (Section 7). 1816 o Extended security considerations: proof-of-possession of signature 1817 keys; collision of OSCORE Group Identifiers (Section 8). 1819 o Registered three entries in the IANA Registry "Sequence Number 1820 Synchronization Method Registry" (Section 9). 1822 o Registered one public key encoding in the "ACE Public Key 1823 Encoding" IANA Registry (Section 9). 1825 B.6. Version -00 to -01 1827 o Changed name of 'req_aud' to 'audience' in the Authorization 1828 Request (Section 3.1). 1830 o Added negotiation of countersignature algorithm/parameters between 1831 Client and Group Manager (Section 4). 1833 o Updated format of the Key Distribution Response as a whole 1834 (Section 4.3). 1836 o Added parameter 'cs_params' in the 'key' parameter of the Key 1837 Distribution Response (Section 4.3). 1839 o New IANA registrations in the "ACE Authorization Server Request 1840 Creation Hints" Registry, "ACE Groupcomm Key" Registry, "OSCORE 1841 Security Context Parameters" Registry and "ACE Groupcomm Profile" 1842 Registry (Section 9). 1844 Acknowledgments 1846 The authors sincerely thank Santiago Aragon, Stefan Beck, Carsten 1847 Bormann, Martin Gunnarsson, Rikard Hoeglund, Daniel Migault, Jim 1848 Schaad, Ludwig Seitz, Goeran Selander and Peter van der Stok for 1849 their comments and feedback. 1851 The work on this document has been partly supported by VINNOVA and 1852 the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact 1853 Initiative ACTIVE. 1855 Authors' Addresses 1857 Marco Tiloca 1858 RISE AB 1859 Isafjordsgatan 22 1860 Kista SE-164 29 Stockholm 1861 Sweden 1863 Email: marco.tiloca@ri.se 1865 Jiye Park 1866 Universitaet Duisburg-Essen 1867 Schuetzenbahn 70 1868 Essen 45127 1869 Germany 1871 Email: ji-ye.park@uni-due.de 1873 Francesca Palombini 1874 Ericsson AB 1875 Torshamnsgatan 23 1876 Kista SE-16440 Stockholm 1877 Sweden 1879 Email: francesca.palombini@ericsson.com