idnits 2.17.1 draft-ietf-ace-key-groupcomm-oscore-05.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 (March 09, 2020) is 1506 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-05 == 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-07 ** Downref: Normative reference to an Informational RFC: RFC 5869 ** 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 (-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: 2 errors (**), 0 flaws (~~), 10 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: September 10, 2020 Universitaet Duisburg-Essen 6 F. Palombini 7 Ericsson AB 8 March 09, 2020 10 Key Management for OSCORE Groups in ACE 11 draft-ietf-ace-key-groupcomm-oscore-05 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 September 10, 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 . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 64 2.1. Overview of the Joining Process . . . . . . . . . . . . . 5 65 2.2. Overview of the Group Rekeying Process . . . . . . . . . 6 66 3. Joining Node to Authorization Server . . . . . . . . . . . . 6 67 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 6 68 3.2. Authorization Response . . . . . . . . . . . . . . . . . 7 69 4. Interface at the Group Manager . . . . . . . . . . . . . . . 7 70 4.1. GET Handler . . . . . . . . . . . . . . . . . . . . . . . 8 71 5. Joining a Group . . . . . . . . . . . . . . . . . . . . . . . 8 72 5.1. Token Post . . . . . . . . . . . . . . . . . . . . . . . 8 73 5.2. Sending the Joining Request . . . . . . . . . . . . . . . 9 74 5.2.1. Value of the N_S Challenge . . . . . . . . . . . . . 10 75 5.3. Processing the Joining Request . . . . . . . . . . . . . 11 76 5.4. Joining Response . . . . . . . . . . . . . . . . . . . . 12 77 6. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 15 78 7. Retrieval of Updated Keying Material . . . . . . . . . . . . 17 79 7.1. Retrieval of Group Keying Material . . . . . . . . . . . 17 80 7.2. Retrieval of Group Keying Material and Sender ID . . . . 17 81 8. Retrieval of New Keying Material . . . . . . . . . . . . . . 18 82 9. Retrieval of Public Keys of Group Members . . . . . . . . . . 19 83 10. Update of Public Key . . . . . . . . . . . . . . . . . . . . 19 84 11. Retrieval of Group Policies . . . . . . . . . . . . . . . . . 20 85 12. Retrieval of Keying Material Version . . . . . . . . . . . . 20 86 13. Retrieval of Group Status . . . . . . . . . . . . . . . . . . 21 87 14. Request to Leave the Group . . . . . . . . . . . . . . . . . 21 88 15. Removal of a Group Member . . . . . . . . . . . . . . . . . . 21 89 16. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 22 90 17. Security Considerations . . . . . . . . . . . . . . . . . . . 23 91 17.1. Management of OSCORE Groups . . . . . . . . . . . . . . 24 92 17.2. Size of Nonces for Signature Challenge . . . . . . . . . 25 93 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 94 18.1. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 26 95 18.2. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 27 96 18.3. OSCORE Security Context Parameters Registry . . . . . . 27 97 18.4. Sequence Number Synchronization Method Registry . . . . 28 98 18.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . 29 99 18.6. TLS Exporter Label Registry . . . . . . . . . . . . . . 29 100 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 101 19.1. Normative References . . . . . . . . . . . . . . . . . . 29 102 19.2. Informative References . . . . . . . . . . . . . . . . . 31 103 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 32 104 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 34 105 B.1. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 34 106 B.2. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 35 107 B.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 35 108 B.4. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 36 109 B.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 37 110 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 37 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 113 1. Introduction 115 Object Security for Constrained RESTful Environments (OSCORE) 116 [RFC8613] is a method for application-layer protection of the 117 Constrained Application Protocol (CoAP) [RFC7252], using CBOR Object 118 Signing and Encryption (COSE) [RFC8152] and enabling end-to-end 119 security of CoAP payload and options. 121 As described in [I-D.ietf-core-oscore-groupcomm], Group OSCORE is 122 used to protect CoAP group communication over IP multicast 123 [I-D.dijk-core-groupcomm-bis]. This relies on a Group Manager, which 124 is responsible for managing an OSCORE group, where members exchange 125 CoAP messages secured with Group OSCORE. The Group Manager can be 126 responsible for multiple groups, coordinates the joining process of 127 new group members, and is entrusted with the distribution and renewal 128 of group keying material. 130 This specification is an application profile of 131 [I-D.ietf-ace-key-groupcomm], which itself builds on the ACE 132 framework for Authentication and Authorization 133 [I-D.ietf-ace-oauth-authz]. Message exchanges among the participants 134 as well as message formats and processing follow what specified in 135 [I-D.ietf-ace-key-groupcomm] for provisioning and renewing keying 136 material in group communication scenarios, where Group OSCORE is used 137 to protect CoAP group communication over IP multicast. 139 1.1. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119][RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 Readers are expected to be familiar with: 149 o The terms and concepts described in the ACE framework for 150 authentication and authorization [I-D.ietf-ace-oauth-authz]. The 151 terminology for entities in the considered architecture is defined 152 in OAuth 2.0 [RFC6749]. In particular, this includes Client (C), 153 Resource Server (RS), and Authorization Server (AS). 155 o The terms and concepts related to the CoAP protocol described in 156 [RFC7252][I-D.dijk-core-groupcomm-bis]. Unless otherwise 157 indicated, the term "endpoint" is used here following its OAuth 158 definition, aimed at denoting resources such as /token and 159 /introspect at the AS and /authz-info at the RS. This document 160 does not use the CoAP definition of "endpoint", which is "An 161 entity participating in the CoAP protocol". 163 o The terms and concept related to the message formats and 164 processing specified in [I-D.ietf-ace-key-groupcomm], for 165 provisioning and renewing keying material in group communication 166 scenarios. 168 o The terms and concepts for protection and processing of CoAP 169 messages through OSCORE [RFC8613] and through Group OSCORE 170 [I-D.ietf-core-oscore-groupcomm] in group communication scenarios. 171 These include the concept of Group Manager, as the entity 172 responsible for a set of groups where communications are secured 173 with Group OSCORE. In this specification, the Group Manager acts 174 as Resource Server. 176 Additionally, this document makes use of the following terminology. 178 o Group name is used as a synonym for group identifier in 179 [I-D.ietf-ace-key-groupcomm]. 181 o Requester: member of an OSCORE group that sends request messages 182 to other members of the group. 184 o Responder: member of an OSCORE group that receives request 185 messages from other members of the group. A responder may reply 186 back, by sending a response message to the requester which has 187 sent the request message. 189 o Monitor: member of an OSCORE group that is configured as responder 190 and never replies back to requesters after receiving request 191 messages. This corresponds to the term "silent server" used in 192 [I-D.ietf-core-oscore-groupcomm]. 194 2. Protocol Overview 196 Group communication for CoAP over IP multicast has been enabled in 197 [I-D.dijk-core-groupcomm-bis] and can be secured with Group Object 198 Security for Constrained RESTful Environments (OSCORE) [RFC8613] as 199 described in [I-D.ietf-core-oscore-groupcomm]. A network node joins 200 an OSCORE group by interacting with the responsible Group Manager. 201 Once registered in the group, the new node can securely exchange 202 messages with other group members. 204 This specification describes how to use [I-D.ietf-ace-key-groupcomm] 205 and [I-D.ietf-ace-oauth-authz] to perform a number of authentication, 206 authorization and key distribution actions, as defined in Section 2. 207 of [I-D.ietf-ace-key-groupcomm], for an OSCORE group. 209 With reference to [I-D.ietf-ace-key-groupcomm]: 211 o The node wishing to joining the OSCORE group, i.e. the joining 212 node, is the Client. 214 o The Group Manager is the Key Distribution Center (KDC), acting as 215 a Resource Server. 217 o The Authorization Server associated to the Group Manager is the 218 AS. 220 All communications between the involved entities rely on the CoAP 221 protocol and MUST be secured. 223 In particular, communications between the Client and the Group 224 Manager leverage protocol-specific transport profiles of ACE to 225 achieve communication security, proof-of-possession and server 226 authentication. Note that it is expected that in the commonly 227 referred base-case of this specification, the transport profile to 228 use is pre-configured and well-known to nodes participating in 229 constrained applications. 231 2.1. Overview of the Joining Process 233 A node performs the steps described in Section 4.2 of 234 [I-D.ietf-ace-key-groupcomm] in order to join an OSCORE group. The 235 format and processing of messages exchanged among the participants 236 are further specified in Section 3 and Section 5 of this document. 238 2.2. Overview of the Group Rekeying Process 240 If the application requires backward and forward security, the Group 241 Manager MUST generate new keying material and distribute it to the 242 group (rekeying) upon membership changes. 244 That is, the group is rekeyed when a node joins the group as a new 245 member, or after a current member leaves the group. By doing so, a 246 joining node cannot access communications in the group prior its 247 joining, while a leaving node cannot access communications in the 248 group after its leaving. 250 The keying material distributed through a group rekeying MUST include 251 a new Group Identifier (Gid) for the group and a new value for the 252 Master Secret parameter of the OSCORE Common Security Context of that 253 group (see Section 2 of [I-D.ietf-core-oscore-groupcomm]). Also, it 254 MAY include a new value for the Master Salt parameter of the OSCORE 255 Common Security Context of that group. 257 Upon generating the new group keying material and before starting its 258 distribution, the Group Manager MUST increment the version number of 259 the group keying material. When rekeying a group, the Group Manager 260 MUST preserve the current value of the Sender ID of each member in 261 that group. 263 The Group Manager MUST support the Group Rekeying Process described 264 in Section 16. Future application profiles may define alternative 265 message formats and distribution schemes to perform group rekeying. 267 3. Joining Node to Authorization Server 269 This section describes how the joining node interacts with the AS in 270 order to be authorized to join an OSCORE group under a given Group 271 Manager. In particular, it considers a joining node that intends to 272 contact that Group Manager for the first time. 274 The message exchange between the joining node and the AS consists of 275 the messages Authorization Request and Authorization Response defined 276 in Section 3 of [I-D.ietf-ace-key-groupcomm]. Note that what is 277 defined in [I-D.ietf-ace-key-groupcomm] applies, and only additions 278 or modifications to that specification are defined here. 280 3.1. Authorization Request 282 The Authorization Request message defined in Section 3.1 of 283 [I-D.ietf-ace-key-groupcomm], with the following additions: 285 o The 'scope' parameter MUST be present. 287 * The group name of the OSCORE group to join under the Group 288 Manager is encoded as a CBOR text string (REQ1). 290 * Accepted values for role identifiers in the OSCORE group to 291 join are: "requester", "responder", and "monitor" (REQ2). 292 Possible combinations are: ["requester" , "responder"]; 293 ["requester" , "monitor"]. Each role identifier MUST be 294 encoded as a CBOR integer (REQ2), by using for abbreviation the 295 values specified in Figure 1 (OPT7). 297 +-----------+------------+ 298 | Name | CBOR Value | 299 +-----------+------------+ 300 | requester | TBD8 | 301 | responder | TBD9 | 302 | monitor | TBD10 | 303 +-----------+------------+ 305 Figure 1: CBOR Abbreviations for Role Identifiers in the Group 307 o The 'audience' parameter MUST be present. 309 3.2. Authorization Response 311 The Authorization Response message defined in Section 3.2 of 312 [I-D.ietf-ace-key-groupcomm], with the following additions: 314 o The AS MUST include the 'expires_in' parameter. Other means for 315 the AS to specify the lifetime of Access Tokens are out of the 316 scope of this specification. 318 o The AS MUST include the 'scope' parameter, when the value included 319 in the Access Token differs from the one specified by the joining 320 node in the request. In such a case, the second element of each 321 scope entry MUST be present, and includes the role or CBOR array 322 of roles that the joining node is actually authorized to take in 323 the OSCORE group for that scope entry, encoded as specified in 324 Section 3.1 of this document. 326 4. Interface at the Group Manager 328 The Group Manager provides the interface defined in Section 4.1 of 329 [I-D.ietf-ace-key-groupcomm], with the following additional resource: 331 o /group-manager/GROUPNAME/active: this sub-resource is fixed and 332 supports the GET method, whose handler is defined in Section 4.1. 334 4.1. GET Handler 336 The handler expects a GET request. 338 The handler verifies that the group identifier of the /group- 339 manager/GROUPNAME/active path is a subset of the 'scope' stored in 340 the Access Token associated to the requesting client. If 341 verification fails, the Group Manager MUST respond with a 4.01 342 (Unauthorized) error message. 344 If verification succeeds, the handler returns a 2.05 (Content) 345 message containing the CBOR simple value True if the group is 346 currently active, or the CBOR simple value False otherwise. The 347 group is considered active if it is set to allow new members to join, 348 and if communication within the group is expected. 350 The method to set the current group status, i.e. active or inactive, 351 is out of the scope of this specification, and is defined for the 352 administrator interface of the Group Manager specified in 353 [I-D.tiloca-ace-oscore-gm-admin]. 355 5. Joining a Group 357 The following subsections describe the interactions between the 358 joining node and the Group Manager, i.e. the sending of the Access 359 Token and the Request-Response exchange to join the OSCORE group. 360 The message exchange between the joining node and the KDC consists of 361 the messages defined in Section 3.3 and 4.2 of 362 [I-D.ietf-ace-key-groupcomm]. Note that what is defined in 363 [I-D.ietf-ace-key-groupcomm] applies, and only additions or 364 modifications to that specification are defined here. 366 5.1. Token Post 368 The Token post exchange is defined in Section 3.3 of 369 [I-D.ietf-ace-key-groupcomm]. 371 Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the 372 following applies. 374 o The 'rsnonce' parameter contains a dedicated nonce N_S generated 375 by the Group Manager. For the N_S value, it is RECOMMENDED to use 376 a 8-byte long random nonce. The joining node may use this nonce 377 in order to prove the possession of its own private key, upon 378 joining the group (see Section 5.2). 380 o If 'sign_info' is present in the response: 382 TODO: have 'sign_info' as an array of arrays, if 'scope' in the 383 Access Token covers multiple groups/topics. 385 * 'sign_alg' takes value from Tables 5 and 6 of [RFC8152]. 387 * 'sign_parameters' takes values from the "Counter Signature 388 Parameters" Registry (see Section 11.1 of 389 [I-D.ietf-core-oscore-groupcomm]). Its structure depends on 390 the value of 'sign_alg'. If no parameters of the counter 391 signature algorithm are specified, 'sign_parameters' MUST be 392 encoding the CBOR simple value Null. 394 * 'sign_key_parameters' takes values from the "Counter Signature 395 Key Parameters" Registry (see Section 11.2 of 396 [I-D.ietf-core-oscore-groupcomm]). Its structure depends on 397 the value of 'sign_alg'. If no parameters of the key used with 398 the counter signature algorithm are specified, 399 'sign_key_parameters' MUST be encoding the CBOR simple value 400 Null. 402 TODO: have 'pub_key_enc' as an array of arrays, if 'scope' in the 403 Access Token covers multiple groups/topics. 405 o If 'pub_key_enc' is present in the response, it takes value 1 406 ("COSE_Key") from the 'Confirmation Key' column of the "CWT 407 Confirmation Method" Registry defined in 408 [I-D.ietf-ace-cwt-proof-of-possession], so indicating that public 409 keys in the OSCORE group are encoded as COSE Keys [RFC8152]. 410 Future specifications may define additional values for this 411 parameter. 413 Note that, other than through the above parameters as defined in 414 Section 3.3 of [I-D.ietf-ace-key-groupcomm], the joining node MAY 415 have previously retrieved this information by other means, e.g. by 416 using the approach described in [I-D.tiloca-core-oscore-discovery]. 418 Additionally, if allowed by the used transport profile of ACE, the 419 joining node may instead provide the Access Token to the Group 420 Manager by other means, e.g. during a secure session establishment 421 (see Section 3.3.1 of [I-D.ietf-ace-dtls-authorize]). 423 5.2. Sending the Joining Request 425 The joining node requests to join the OSCORE group, by sending a 426 Joining Request message to the related group-membership resource at 427 the Group Manager, as per Section 4.2 of 428 [I-D.ietf-ace-key-groupcomm]. 430 Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the 431 following applies. 433 o The string "group-oscore" is used instead of "ace-group" (see 434 Section 4.1 of [I-D.ietf-ace-key-groupcomm]) as the top level path 435 to the group-membership resource. The url-path /group-oscore/ is 436 a default name of this specifications: implementations are not 437 required to use this name, and can define their own instead. 439 o The 'scope' parameter MUST be present. 441 o The 'get_pub_keys' parameter is present only if the joining node 442 wants to retrieve the public keys of the group members from the 443 Group Manager during the joining process (see Section 6). 444 Otherwise, this parameter MUST NOT be present. 446 o 'cnonce' contains a dedicated nonce N_C generated by the joining 447 node. For the N_C value, it is RECOMMENDED to use a 8-byte long 448 random nonce. 450 o The signature encoded in the 'client_cred_verify' parameter is 451 computed by the joining node by using the same private key and 452 countersignature algorithm it intends to use for signing messages 453 in the OSCORE group. Moreover, N_S is as defined in 454 Section 5.2.1. 456 5.2.1. Value of the N_S Challenge 458 The N_S challenge takes one of the following values. 460 1. If the joining node has posted the Access Token to the /authz- 461 info endpoint of the Group Manager as in Section 5.1, N_S takes 462 the same value of the 'rsnonce' parameter in the 2.01 (Created) 463 response to the Token POST. 465 2. If the Token posting has relied on the DTLS profile of ACE 466 [I-D.ietf-ace-dtls-authorize] and the joining node included the 467 Access Token as content of the "psk_identity" field of the 468 ClientKeyExchange message [RFC6347], N_S is an exporter value 469 computed as defined in Section 7.5 of [RFC8446]. Specifically, 470 N_S is exported from the DTLS session between the joining node 471 and the Group Manager, using an empty 'context_value', 32 bytes 472 as 'key_length', and the exporter label "EXPORTER-ACE-Sign- 473 Challenge-coap-group-oscore-app" defined in Section 18.6 of this 474 specification. 476 3. If the joining node is in fact re-joining the group, without 477 posting again the same and still valid Access Token: 479 * If the joining node and the Group Manager communicates using 480 DTLS, N_S is an exporter value, computed as described in point 481 (2) above. 483 * If the joining node and the Group Manager communicates using 484 OSCORE [RFC8613], the N_S is the output PRK of a HKDF-Extract 485 step [RFC5869], i.e. PRK = HMAC-Hash(salt, IKM). In 486 particular, 'salt' takes (x1 | x2), where x1 is the ID Context 487 of the OSCORE Security Context between the joining node and 488 the Group Manager, x2 is the Sender ID of the joining node in 489 that Context, and | denotes byte string concatenation. Also, 490 'IKM' is the OSCORE Master Secret of the OSCORE Security 491 Context between the joining node and the Group Manager. The 492 HKDF MUST be one of the HMAC-based HKDF [RFC5869] algorithms 493 defined for COSE [RFC8152]. HKDF SHA-256 is mandatory to 494 implement. 496 It is up to applications to define how N_S is computed in further 497 alternative settings. 499 5.3. Processing the Joining Request 501 The Group Manager processes the Joining Request as defined in 502 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm]. Additionally, the 503 following applies. 505 o In case the Joining Request does not include the 'client_cred' 506 parameter, the joining process fails if the Group Manager either: 507 i) does not store a public key with an accepted format for the 508 joining node; or ii) stores multiple public keys with an accepted 509 format for the joining node. 511 o To compute the signature contained in 'client_cred_verify', the GM 512 considers: i) as signed value, N_S concatenated with N_C, where 513 N_S is determined as described in Section 5.2.1, while N_C is the 514 nonce provided in the 'cnonce' parameter of the Joining Request; 515 ii) the countersignature algorithm used in the OSCORE group, and 516 possible correponding parameters; and iii) the public key of the 517 joining node, either retrieved from the 'client_cred' parameter, 518 or already stored as acquired from previous interactions with the 519 joining node. 521 o A 4.00 Bad Request response from the Group Manager to the joining 522 node MUST have content format application/ace-group+cbor. The 523 response payload is a CBOR map which MUST contain the 'sign_info' 524 and 'pub_key_enc' parameters. The CBOR map SHOULD additionally 525 contain the 'rsnonce' parameter, specifying a new dedicated 8-byte 526 nonce generated by the Group Manager (see Section 5.1). 528 o The Group Manager MUST return a 4.00 (Bad Request) response in 529 case the Joining Request includes the 'client_cred' parameter but 530 does not include both the 'cnonce' and 'client_cred_verify' 531 parameters. 533 o The Group Manager MUST return a 4.00 (Bad Request) response in 534 case it cannot retrieve a public key with an accepted format for 535 the joining node, either from the 'client_cred' parameter or as 536 already stored. 538 o When receiving a 4.00 Bad Request response, the joining node 539 SHOULD send a new Joining Request to the Group Manager, where: 541 * The 'cnonce' parameter MUST include a new dedicated nonce N_C 542 generated by the joining node. 544 * The 'client_cred' parameter MUST include a public key 545 compatible with the encoding, countersignature algorithm and 546 possible associated parameters indicated by the Group Manager. 548 * The 'client_cred_verify' parameter MUST include a signature 549 computed as described in Section 5.2, by using the public key 550 indicated in the current 'client_cred' parameter, with the 551 countersignature algorithm and possible associated parameters 552 indicated by the Group Manager. If the error response from the 553 Group Manager included the 'rsnonce' parameter, the joining 554 node MUST use its content as new N_S challenge to compute the 555 signature. 557 5.4. Joining Response 559 If the processing of the Joining Request described in Section 5.3 is 560 successful, the Group Manager updates the group membership by 561 registering the joining node NODENAME as a new member of the OSCORE 562 group GROUPNAME, as described in Section 4.1.2.1 of 563 [I-D.ietf-ace-key-groupcomm]. 565 If the joining node is not exclusively configured as monitor, the 566 Group Manager performs also the following actions. 568 o The Group Manager selects an available OSCORE Sender ID in the 569 OSCORE group, and exclusively assigns it to the joining node. 571 o The Group Manager stores the association between i) the public key 572 of the joining node; and ii) the Group Identifier (Gid), i.e. the 573 OSCORE ID Context, associated to the OSCORE group together with 574 the OSCORE Sender ID assigned to the joining node in the group. 575 The Group Manager MUST keep this association updated over time. 577 Then, the Group Manager replies to the joining node, providing the 578 updated security parameters and keying meterial necessary to 579 participate in the group communication. This success Joining 580 Response is formatted as defined in Section 4.1.2.1 of 581 [I-D.ietf-ace-key-groupcomm], with the following additions: 583 o The 'gkty' parameter identifies a key of type 584 "Group_OSCORE_Security_Context object", defined in Section 18.2 of 585 this specification. 587 o The 'key' parameter includes what the joining node needs in order 588 to set up the OSCORE Security Context as per Section 2 of 589 [I-D.ietf-core-oscore-groupcomm]. This parameter has as value a 590 Group_OSCORE_Security_Context object, which is defined in this 591 specification and extends the OSCORE_Security_Context object 592 encoded in CBOR as defined in Section 3.2.1 of 593 [I-D.ietf-ace-oscore-profile]. In particular, it contains the 594 additional parameters 'cs_alg', 'cs_params', 'cs_key_params' and 595 'cs_key_enc' defined in Section 18.3 of this specification. More 596 specifically, the 'key' parameter is composed as follows. 598 * The 'ms' parameter MUST be present and includes the OSCORE 599 Master Secret value. 601 * The 'clientId' parameter, if present, has as value the OSCORE 602 Sender ID assigned to the joining node by the Group Manager, as 603 described above. This parameter is not present if the node 604 joins the group exclusively as monitor, according to what 605 specified in the Access Token (see Section 3.2). In any other 606 case, this parameter MUST be present. 608 * The 'hkdf' parameter, if present, has as value the KDF 609 algorithm used in the group. 611 * The 'alg' parameter, if present, has as value the AEAD 612 algorithm used in the group. 614 * The 'salt' parameter, if present, has as value the OSCORE 615 Master Salt. 617 * The 'contextId' parameter MUST be present and has as value the 618 Group Identifier (Gid), i.e. the OSCORE ID Context of the 619 OSCORE group. 621 * The 'cs_alg' parameter MUST be present and specifies the 622 algorithm used to countersign messages in the group. This 623 parameter takes values from Tables 5 and 6 of [RFC8152]. 625 * The 'cs_params' parameter MAY be present and specifies the 626 additional parameters for the counter signature algorithm. 627 This parameter is a CBOR map whose content depends on the 628 counter signature algorithm, as specified in Section 2 and 629 Section 11.1 of [I-D.ietf-core-oscore-groupcomm]. 631 * The 'cs_key_params' parameter MAY be present and specifies the 632 additional parameters for the key used with the counter 633 signature algorithm. This parameter is a CBOR map whose 634 content depends on the counter signature algorithm, as 635 specified in Section 2 and Section 11.2 of 636 [I-D.ietf-core-oscore-groupcomm]. 638 * The 'cs_key_enc' parameter MAY be present and specifies the 639 encoding of the public keys of the group members. This 640 parameter is a CBOR integer, whose value is 1 ("COSE_Key") 641 taken from the 'Confirmation Key' column of the "CWT 642 Confirmation Method" Registry defined in 643 [I-D.ietf-ace-cwt-proof-of-possession], so indicating that 644 public keys in the OSCORE group are encoded as COSE Keys 645 [RFC8152]. Future specifications may define additional values 646 for this parameter. If this parameter is not present, 1 647 ("COSE_Key") MUST be assumed as default value. 649 o The 'num' parameter MUST be present. 651 o The 'ace-groupcomm-profile' parameter MUST be present and has 652 value coap_group_oscore_app (TBD1), which is defined in 653 Section 18.1 of this specification. 655 o The 'exp' parameter MUST be present. 657 o The 'pub_keys' parameter, if present, includes the public keys of 658 the group members that are relevant to the joining node. That is, 659 it includes: i) the public keys of the responders currently in the 660 group, in case the joining node is configured (also) as requester; 661 and ii) the public keys of the requesters currently in the group, 662 in case the joining node is configured (also) as responder or 663 monitor. If public keys are encoded as COSE_Keys, each of them 664 has as 'kid' the Sender ID that the corresponding owner has in the 665 group, thus used as group member identifier. 667 o The 'group_policies' parameter SHOULD be present, and SHOULD 668 include the elements "Sequence Number Synchronization Method" and 669 "Key Update Check Interval" defined in Section 4.1.2. of 670 [I-D.ietf-ace-key-groupcomm]. 672 Finally, the joining node uses the information received in the 673 Joining Response to set up the OSCORE Security Context, as described 674 in Section 2 of [I-D.ietf-core-oscore-groupcomm]. In addition, the 675 joining node maintains an association between each public key 676 retrieved from the 'pub_keys' parameter and the role(s) that the 677 corresponding group member has in the group. 679 From then on, the joining node can exchange group messages secured 680 with Group OSCORE as described in [I-D.ietf-core-oscore-groupcomm]. 681 When doing so: 683 o The joining node MUST NOT process an incoming request message, if 684 signed by a group member whose public key is not associated to the 685 role "Requester". 687 o The joining node MUST NOT process an incoming response message, if 688 signed by a group member whose public key is not associated to the 689 role "Responder". 691 If the application requires backward security, the Group Manager MUST 692 generate updated security parameters and group keying material, and 693 provide it to the current group members upon the new node's joining 694 (see Section 16). As a consequence, the joining node is not able to 695 access secure communication in the group occurred prior its joining. 697 6. Public Keys of Joining Nodes 699 Source authentication of OSCORE messages exchanged within the group 700 is ensured by means of digital counter signatures (see Sections 2 and 701 4 of [I-D.ietf-core-oscore-groupcomm]). Therefore, group members 702 must be able to retrieve each other's public key from a trusted key 703 repository, in order to verify source authenticity of incoming group 704 messages. 706 As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group 707 Manager acts as trusted repository of the public keys of the group 708 members, and provides those public keys to group members if requested 709 to. Upon joining an OSCORE group, a joining node is thus expected to 710 provide its own public key to the Group Manager. 712 In particular, one of the following four cases can occur when a new 713 node joins an OSCORE group. 715 o The joining node is going to join the group exclusively as 716 monitor. That is, it is not going to send messages to the group, 717 and hence to produce signatures with its own private key. In this 718 case, the joining node is not required to provide its own public 719 key to the Group Manager, which thus does not have to perform any 720 check related to the public key encoding, or to a countersignature 721 algorithm and possible associated parameters for that joining 722 node. 724 o The Group Manager already acquired the public key of the joining 725 node during a past joining process. In this case, the joining 726 node MAY choose not to provide again its own public key to the 727 Group Manager, in order to limit the size of the Joining Request. 728 The joining node MUST provide its own public key again if it has 729 provided the Group Manager with multiple public keys during past 730 joining processes, intended for different OSCORE groups. If the 731 joining node provides its own public key, the Group Manager 732 performs consistency checks as per Section 5.3 and, in case of 733 success, considers it as the public key associated to the joining 734 node in the OSCORE group. 736 o The joining node and the Group Manager use an asymmetric proof-of- 737 possession key to establish a secure communication channel. Then, 738 two cases can occur. 740 1. The proof-of-possession key is compatible with the encoding as 741 well as with the counter signature algorithm and possible 742 associated parameters used in the OSCORE group. Then, the 743 Group Manager considers the proof-of-possession key as the 744 public key associated to the joining node in the OSCORE group. 745 If the joining node is aware that the proof-of-possession key 746 is also valid for the OSCORE group, it MAY not provide it 747 again as its own public key to the Group Manager. The joining 748 node MUST provide its own public key again if it has provided 749 the Group Manager with multiple public keys during past 750 joining processes, intended for different OSCORE groups. If 751 the joining node provides its own public key in the 752 'client_cred' parameter of the Joining Request (see 753 Section 5.2), the Group Manager performs consistency checks as 754 per Section 5.3 and, in case of success, considers it as the 755 public key associated to the joining node in the OSCORE group. 757 2. The proof-of-possession key is not compatible with the 758 encoding or with the counter signature algorithm and possible 759 associated parameters used in the OSCORE group. In this case, 760 the joining node MUST provide a different compatible public 761 key to the Group Manager in the 'client_cred' parameter of the 762 Joining Request (see Section 5.2). Then, the Group Manager 763 performs consistency checks on this latest provided public key 764 as per Section 5.3 and, in case of success, considers it as 765 the public key associated to the joining node in the OSCORE 766 group. 768 o The joining node and the Group Manager use a symmetric proof-of- 769 possession key to establish a secure communication channel. In 770 this case, upon performing a joining process with that Group 771 Manager for the first time, the joining node specifies its own 772 public key in the 'client_cred' parameter of the Joining Request 773 targeting the group-membership endpoint (see Section 5.2). 775 7. Retrieval of Updated Keying Material 777 At some point, a group member considers the OSCORE Security Context 778 invalid and to be renewed. This happens, for instance, after a 779 number of unsuccessful security processing of incoming messages from 780 other group members, or when the Security Context expires as 781 specified by the 'exp' parameter of the Joining Response. 783 When this happens, the group member retrieves updated security 784 parameters and group keying material. This can occur in the two 785 different ways described below. 787 7.1. Retrieval of Group Keying Material 789 If the group member wants to retrieve only the latest group keying 790 material, it sends a Key Distribution Request to the Group Manager. 792 In particular, it sends a CoAP GET request to the endpoint /group- 793 oscore/GROUPNAME at the Group Manager. 795 The Group Manager processes the Key Distribution Request according to 796 Section 4.1.2.2 of [I-D.ietf-ace-key-groupcomm]. The Key 797 Distribution Response is formatted as defined in Section 4.1.2.2 of 798 [I-D.ietf-ace-key-groupcomm]. In particular, the 'key' parameter is 799 formatted as defined in Section 5.4 of this specification, with the 800 difference that it does not include the 'clientId' parameter. 802 Upon receiving the Key Distribution Response, the group member 803 retrieves the updated security parameters and group keying material, 804 and, if they differ from the current ones, use them to set up the new 805 OSCORE Security Context as described in Section 2 of 806 [I-D.ietf-core-oscore-groupcomm]. 808 7.2. Retrieval of Group Keying Material and Sender ID 810 If the group member wants to retrieve the latest group keying 811 material as well as the Sender ID that it has in the OSCORE group, it 812 sends a Key Distribution Request to the Group Manager. 814 In particular, it sends a CoAP GET request to the endpoint /group- 815 oscore/GROUPNAME/nodes/NODENAME at the Group Manager. 817 The Group Manager processes the Key Distribution Request according to 818 Section 4.1.6.2 of [I-D.ietf-ace-key-groupcomm]. The Key 819 Distribution Response is formatted as defined in Section 4.1.6.2 of 820 [I-D.ietf-ace-key-groupcomm]. 822 In particular, the 'key' parameter is formatted as defined in 823 Section 5.4 of this specification, with the difference that if the 824 requesting group member is configured exclusively as monitor, no 825 'clientId' is specified within the 'key' parameter. Note that, in 826 any other case, the current Sender ID of the group member is not 827 specified as a separate parameter, but rather specified as 'clientId' 828 within the 'key' parameter. 830 Upon receiving the Key Distribution Response, the group member 831 retrieves the updated security parameters, group keying material and 832 Sender ID, and, if they differ from the current ones, use them to set 833 up the new OSCORE Security Context as described in Section 2 of 834 [I-D.ietf-core-oscore-groupcomm]. 836 8. Retrieval of New Keying Material 838 As discussed in Section 2.5 of [I-D.ietf-core-oscore-groupcomm], a 839 group member may at some point experience a wrap-around of its own 840 Sender Sequence Number in the group. 842 When this happens, the group member MUST send a Key Renewal Request 843 message to the Group Manager, as per Section 4.4 of 844 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP PUT 845 request to the endpoint /group-oscore/GROUPNAME/nodes/NODENAME at the 846 Group Manager. 848 Upon receiving the Key Renewal Request, the Group Manager processes 849 it as defined in Section 4.1.6.1 of [I-D.ietf-ace-key-groupcomm], and 850 performs one of the following actions. 852 1. If the requesting group member is configured exclusively as 853 monitor, the Group Manager replies with a 4.00 (Bad Request) 854 error response. 856 2. Otherwise, depending on the policies configured (OPT8): 858 a. Either the Group Manager replies to the group member with a 859 4.00 (Bad Request) error response, and rekeys the whole OSCORE 860 group as discussed in Section 16; 862 b. Or the Group Manager generates a new Sender ID for that group 863 member and replies with a Key Renewal Response, formatted as 864 defined in Section 4.1.6.1 of [I-D.ietf-ace-key-groupcomm]. In 865 particular, the CBOR Map in the response payload includes a 866 single parameter 'clientId' defined in Section 18.5 of this 867 document, specifying the new Sender ID of the group member 868 encoded as a CBOR byte string. 870 9. Retrieval of Public Keys of Group Members 872 A group member may need to retrieve the public keys of other group 873 members. To this end, the group member sends a Public Key Request 874 message to the Group Manager, as per Section 4.5 of 875 [I-D.ietf-ace-key-groupcomm]. In particular, it sends the request to 876 the endpoint /group-oscore/GROUPNAME/pub-key at the Group Manager. 878 If the Public Key Request uses the method FETCH, the Public Key 879 Request is formatted as defined in Section 4.1.3.1 of 880 [I-D.ietf-ace-key-groupcomm]. In particular, each element of the 881 'get_pub_keys' parameter is a CBOR byte string, which encodes the 882 Sender ID of the group member for which the associated public key is 883 requested. 885 Upon receiving the Public Key Request, the Group Manager processes it 886 as per Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm], 887 depending on the request method being FETCH or GET, respectively. 888 Additionally, if the Public Key Request uses the method FETCH, the 889 Group Manager silently ignores identifiers included in the 890 'get_pub_keys' parameter of the request that are not associated to 891 any current group member. 893 The success Public Key Response is formatted as defined in 894 Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm], depending 895 on the request method being FETCH or GET, respectively. 897 10. Update of Public Key 899 A group member may need to provide the Group Manager with its new 900 public key to use in the group from then on, hence replacing the 901 current one. This can be the case, for instance, if the 902 countersignature algorithm and possible associated parameters used in 903 the OSCORE group have been changed, and the current public key is not 904 compatible with them. 906 To this end, the group member sends a Public Key Update Request 907 message to the Group Manager, as per Section 4.6 of 908 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP POST 909 request to the endpoint /group-oscore/GROUPNAME/nodes/NODENAME/pub- 910 key at the Group Manager. 912 Upon receiving the Group Leaving Request, the Group Manager processes 913 it as per Section 4.1.7.1 of [I-D.ietf-ace-key-groupcomm], with the 914 following additions. 916 o If the requesting group member is configured exclusively as 917 monitor, the Group Manager replies with a 4.00 (Bad request) error 918 response. 920 o The N_S signature challenge is computed as per point (3) in 921 Section 5.2.1 (REQ17). 923 o If the request is successfully processed, the Group Manager stores 924 the association between i) the new public key of the group member; 925 and ii) the Group Identifier (Gid), i.e. the OSCORE ID Context, 926 associated to the OSCORE group together with the OSCORE Sender ID 927 assigned to the group member in the group. The Group Manager MUST 928 keep this association updated over time. 930 11. Retrieval of Group Policies 932 A group member may request the current policies used in the OSCORE 933 group. To this end, the group member sends a Policies Request, as 934 per Section 4.7 of [I-D.ietf-ace-key-groupcomm]. In particular, it 935 sends a CoAP GET request to the endpoint /group-oscore/GROUPNAME/ 936 policies at the Group Manager, where GROUPNAME is the name of the 937 OSCORE group. 939 Upon receiving the Policies Request, the Group Manager processes it 940 as per Section 4.1.4.1 of [I-D.ietf-ace-key-groupcomm]. The success 941 Policies Response is formatted as defined in Section 4.1.4.1 of 942 [I-D.ietf-ace-key-groupcomm]. 944 12. Retrieval of Keying Material Version 946 A group member may request the current version of the keying material 947 used in the OSCORE group. To this end, the group member sends a 948 Version Request, as per Section 4.8 of [I-D.ietf-ace-key-groupcomm]. 949 In particular, it sends a CoAP GET request to the endpoint /group- 950 oscore/GROUPNAME/ctx-num at the Group Manager, where GROUPNAME is the 951 name of the OSCORE group. 953 Upon receiving the Version Request, the Group Manager processes it as 954 per Section 4.1.5.1 of [I-D.ietf-ace-key-groupcomm]. The success 955 Version Response is formatted as defined in Section 4.1.5.1 of 956 [I-D.ietf-ace-key-groupcomm]. 958 13. Retrieval of Group Status 960 A group member may request the current status of the the OSCORE 961 group, i.e. active or inactive. To this end, the group member sends 962 a Group Status Request to the Group Manager. 964 In particular, the group member sends a CoAP GET request to the 965 endpoint /group-oscore/GROUPNAME/active at the Group Manager defined 966 in Section 4 of this specification, where GROUPNAME is the name of 967 the OSCORE group. The success Group Version Response is formatted as 968 defined in Section 4 of this specification. 970 Upon learning from a 2.05 (Content) response that the group is 971 currently inactive, the group member SHOULD stop taking part in 972 communications within the group, until it becomes active again. 974 Upon learning from a 2.05 (Content) response that the group has 975 become active again, the group member can resume taking part in 976 communications within the group. 978 Figure 2 gives an overview of the exchange described above. 980 Group Group 981 Member Manager 982 | | 983 |------ Group Status Request: GET ace-group/GID/active ------>| 984 | | 985 |<---------- Group Status Response: 2.05 (Content) -----------| 986 | | 988 Figure 2: Message Flow of Group Status Request-Response 990 14. Request to Leave the Group 992 A group member may request to leave the OSCORE group. To this end, 993 the group member sends a Group Leaving Request, as per Section 4.9 of 994 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP DELETE 995 request to the endpoint /group-oscore/GROUPNAME/nodes/NODENAME at the 996 Group Manager. 998 Upon receiving the Group Leaving Request, the Group Manager processes 999 it as per Section 4.1.6.3 of [I-D.ietf-ace-key-groupcomm]. 1001 15. Removal of a Group Member 1003 Other than after a spontaneous request to the Group Manager as 1004 described in Section 14, a node may be forcibly removed from the 1005 OSCORE group, e.g. due to expired or revoked authorization. 1007 In either case, if the leaving node is not configured exclusively as 1008 monitor, the Group Manager performs the following actions. 1010 o The Group Manager frees the OSCORE Sender ID value of the leaving 1011 node, which becomes available for possible upcoming joining nodes. 1013 o The Group Manager cancels the association between, on one hand, 1014 the public key of the leaving node and, on the other hand, the 1015 Group Identifier (Gid) associated to the OSCORE group together 1016 with the freed OSCORE Sender ID value. The Group Manager deletes 1017 the public key of the leaving node, if that public key has no 1018 remaining association with any pair (Gid, Sender ID). 1020 If the application requires forward security, the Group Manager MUST 1021 generate updated security parameters and group keying material, and 1022 provide it to the remaining group members (see Section 16). As a 1023 consequence, the leaving node is not able to acquire the new security 1024 parameters and group keying material distributed after its leaving. 1026 Same considerations in Section 5 of [I-D.ietf-ace-key-groupcomm] 1027 apply here as well, considering the Group Manager acting as KDC. 1029 16. Group Rekeying Process 1031 In order to rekey the OSCORE group, the Group Manager distributes a 1032 new Group Identifier (Gid), i.e. a new OSCORE ID Context; a new 1033 OSCORE Master Secret; and, optionally, a new OSCORE Master Salt for 1034 that group. When doing so, the Group Manager MUST increment the 1035 version number of the group keying material, before starting its 1036 distribution. 1038 Furthermore, the Group Manager MUST preserve the same unchanged 1039 Sender IDs for all group members. This avoids affecting the 1040 retrieval of public keys from the Group Manager as well as the 1041 verification of message countersignatures. 1043 The Group Manager MUST support at least the following group rekeying 1044 scheme. Future application profiles may define alternative message 1045 formats and distribution schemes. 1047 The Group Manager uses the same format of the Joining Response 1048 message in Section 5.4. In particular: 1050 o Only the parameters 'gkty', 'key', 'num', 'ace-groupcomm-profile' 1051 and 'exp' are present. 1053 o The 'ms' parameter of the 'key' parameter specifies the new OSCORE 1054 Master Secret value. 1056 o The 'contextId' parameter of the 'key' parameter specifies the new 1057 Group ID. 1059 The Group Manager separately sends a group rekeying message to each 1060 group member to be rekeyed. 1062 Each rekeying message MUST be secured with the pairwise secure 1063 communication channel between the Group Manager and the group member 1064 used during the joining process. In particular, each rekeying 1065 message can target the 'control_path' URI path defined in 1066 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm], if provided by the 1067 intended recipient upon joining the group (see Section 5.2). 1069 It is RECOMMENDED that the Group Manager gets confirmation of 1070 successful distribution from the group members, and admits a maximum 1071 number of individual retransmissions to non-confirming group members. 1073 In case the rekeying terminates and some group members have not 1074 received the new keying material, they will not be able to correctly 1075 process following secured messages exchanged in the group. These 1076 group members will eventually contact the Group Manager, in order to 1077 retrieve the current keying material and its version. 1079 This approach requires group members to act (also) as servers, in 1080 order to correctly handle unsolicited group rekeying messages from 1081 the Group Manager. In particular, if a group member and the Group 1082 Manager use OSCORE [RFC8613] to secure their pairwise communications, 1083 the group member MUST create a Replay Window in its own Recipient 1084 Context upon establishing the OSCORE Security Context with the Group 1085 Manager, e.g. by means of the OSCORE profile of ACE 1086 [I-D.ietf-ace-oscore-profile]. 1088 Group members and the Group Manager SHOULD additionally support 1089 alternative rekeying approaches that do not require group members to 1090 act (also) as servers. A number of such approaches are defined in 1091 Section 4.3 of [I-D.ietf-ace-key-groupcomm]. In particular, a group 1092 member may subscribe for updates to the group-membership resource of 1093 the group, at the endpoint /group-oscore/GROUPNAME/nodes/NODENAME of 1094 the Group Manager. This can rely on CoAP Observe [RFC7641] or on a 1095 full-fledged Pub-Sub model [I-D.ietf-core-coap-pubsub] with the Group 1096 Manager acting as Broker. 1098 17. Security Considerations 1100 Security considerations for this profile are inherited from 1101 [I-D.ietf-ace-key-groupcomm], the ACE framework for Authentication 1102 and Authorization [I-D.ietf-ace-oauth-authz], and the specific 1103 transport profile of ACE signalled by the AS, such as 1104 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile]. 1106 The following security considerations also apply for this profile. 1108 17.1. Management of OSCORE Groups 1110 This profile leverages the following management aspects related to 1111 OSCORE groups and discussed in the sections of 1112 [I-D.ietf-core-oscore-groupcomm] referred below. 1114 o Management of group keying material (see Section 2.4 of 1115 [I-D.ietf-core-oscore-groupcomm]). The Group Manager is 1116 responsible for the renewal and re-distribution of the keying 1117 material in the groups of its competence (rekeying). According to 1118 the specific application requirements, this can include rekeying 1119 the group upon changes in its membership. In particular, renewing 1120 the group keying material is required upon a new node's joining or 1121 a current node's leaving, in case backward security and forward 1122 security have to be preserved, respectively. 1124 o Provisioning and retrieval of public keys (see Section 2 of 1125 [I-D.ietf-core-oscore-groupcomm]). The Group Manager acts as key 1126 repository of public keys of group members, and provides them upon 1127 request. 1129 o Synchronization of sequence numbers (see Section 6.1 of 1130 [I-D.ietf-core-oscore-groupcomm]). This concerns how a responder 1131 node that has just joined an OSCORE group can synchronize with the 1132 sequence number of requesters in the same group. 1134 Before sending the Joining Response, the Group Manager MUST verify 1135 that the joining node actually owns the associated private key. To 1136 this end, the Group Manager can rely on the proof-of-possession 1137 challenge-response defined in Section 5. Alternatively, the joining 1138 node can use its own public key as asymmetric proof-of-possession key 1139 to establish a secure channel with the Group Manager, e.g. as in 1140 Section 3.2 of [I-D.ietf-ace-dtls-authorize]. However, this requires 1141 such proof-of-possession key to be compatible with the encoding as 1142 well as with the countersignature algorithm and possible associated 1143 parameters used in the OSCORE group. 1145 A node may have joined multiple OSCORE groups under different non- 1146 synchronized Group Managers. Therefore, it can happen that those 1147 OSCORE groups have the same Group Identifier (Gid). It follows that, 1148 upon receiving a Group OSCORE message addressed to one of those 1149 groups, the node would have multiple Security Contexts matching with 1150 the Gid in the incoming message. It is up to the application to 1151 decide how to handle such collisions of Group Identifiers, e.g. by 1152 trying to process the incoming message using one Security Context at 1153 the time until the right one is found. 1155 17.2. Size of Nonces for Signature Challenge 1157 With reference to the Joining Request message in Section 5.2, the 1158 proof-of-possession signature included in 'client_cred_verify' is 1159 computed over the challenge N_C | N_S, where | denotes concatenation. 1161 For the N_C value, it is RECOMMENDED to use a 8-byte long random 1162 nonce. Furthermore, N_C is always conveyed in the 'cnonce' parameter 1163 of the Joining Request, which is always sent over the secure 1164 communication channel between the joining node and the Group Manager. 1166 As defined in Section 5.2.1, the way the N_S value is computed 1167 depends on the particular interaction between the joining node and 1168 the Group Manager. 1170 o If the Access Token is not explicitly posted to the /authz-info 1171 endpoint of the Group Manager, or if the joining node re-joins 1172 without re-posting the same still valid Access Token, then N_S is 1173 computed as a 32-byte long nonce (see points (2) and (3) of 1174 Section 5.2.1). 1176 o If the Access Token has been explicitly posted to the /authz-info 1177 endpoint of the Group Manager, N_S takes the value conveyed in the 1178 'rsnonce' parameter of the 2.01 response to the Token Post (see 1179 Section 5.1). Similarly, if a Joining Request is not successfully 1180 processed by the Group Manager, the returned error response should 1181 also include the 'rsnonce' parameter specifying a new nonce N_S 1182 (see Section 5.3). In either case, it is RECOMMENDED to use a 1183 8-byte long random nonce as value for N_S. 1185 If we consider both N_C and N_S to be 8-byte long nonces, the 1186 following considerations hold. 1188 o If both N_C and N_S are random nonces, the average collision for 1189 each nonce will happen after 2^32 messages, as per the birthday 1190 paradox and as also discussed in Section 7 of 1191 [I-D.ietf-ace-oscore-profile]. This amounts to considerably more 1192 token provisionings than the expected new joinings of OSCORE 1193 groups under a same Group Manager. 1195 o If N_C and N_S are not generated randomly, e.g. by using a 1196 counter, the joining node and the Group Manager need to guarantee 1197 that reboot and loss of state on either node does not provoke re- 1198 use. If that is not guaranteed, a joining node may repeatedly 1199 post a valid Access Token to the /authz-info endpoint of the Group 1200 Manager, until it gets back an exact, re-used value N_S* to use as 1201 nonce. Then, the joining node can send a Joining Request, 1202 conveying a reused N_C* nonce in 'cnonce' and an old stored 1203 signature in 'client_cred_verify', computed over N_C* | N_S*. By 1204 verifying the signature, the Group Manager would falsely believe 1205 that the joining node possesses its own private key at that point 1206 in time. 1208 o Since N_C is always conveyed in a secured Joining Request, it is 1209 practically infeasible for an on-path attacker to replay Joining 1210 Requests from a joining node to the Group Manager, in order to 1211 cause that joining node to use an arbitrary nonce N_S. 1213 o Section 7 of [I-D.ietf-ace-oscore-profile] as well Appendix B.2 of 1214 [RFC8613] recommend the use of 8-byte random nonces as well. 1215 Unlike in those cases, the nonces N_C and N_S considered in this 1216 specification are not used for as sensitive operations as the 1217 derivation of a Security Context, with possible implications in 1218 the security of AEAD ciphers. 1220 18. IANA Considerations 1222 Note to RFC Editor: Please replace all occurrences of "[[This 1223 specification]]" with the RFC number of this specification and delete 1224 this paragraph. 1226 This document has the following actions for IANA. 1228 18.1. ACE Groupcomm Profile Registry 1230 IANA is asked to register the following entry in the "ACE Groupcomm 1231 Profile" Registry defined in Section 9.6 of 1232 [I-D.ietf-ace-key-groupcomm]. 1234 o Name: coap_group_oscore_app 1236 o Description: Application profile to provision keying material for 1237 participating in group communication protected with Group OSCORE 1238 as per [I-D.ietf-core-oscore-groupcomm]. 1240 o CBOR Value: TBD1 1242 o Reference: [[This specification]] (Section 5.4) 1244 18.2. ACE Groupcomm Key Registry 1246 IANA is asked to register the following entry in the "ACE Groupcomm 1247 Key" Registry defined in Section 9.5 of [I-D.ietf-ace-key-groupcomm]. 1249 o Name: Group_OSCORE_Security_Context object 1251 o Key Type Value: TBD2 1253 o Profile: "coap_group_oscore_app", defined in Section 18.1 of this 1254 specification. 1256 o Description: A Group_OSCORE_Security_Context object encoded as 1257 described in Section 5.4 of this specification. 1259 o Reference: [[This specification]] (Section 5.4) 1261 18.3. OSCORE Security Context Parameters Registry 1263 IANA is asked to register the following entries in the "OSCORE 1264 Security Context Parameters" Registry defined in Section 9.4 of 1265 [I-D.ietf-ace-oscore-profile]. 1267 o Name: cs_alg 1269 o CBOR Label: TBD3 1271 o CBOR Type: tstr / int 1273 o Registry: COSE Algorithm Values (ECDSA, EdDSA) 1275 o Description: OSCORE Counter Signature Algorithm Value 1277 o Reference: [[This specification]] (Section 5.4) 1279 o Name: cs_params 1281 o CBOR Label: TBD4 1283 o CBOR Type: map 1285 o Registry: Counter Signatures Parameters 1287 o Description: OSCORE Counter Signature Algorithm Additional 1288 Parameters 1290 o Reference: [[This specification]] (Section 5.4) 1291 o Name: cs_key_params 1293 o CBOR Label: TBD5 1295 o CBOR Type: map 1297 o Registry: Counter Signatures Key Parameters 1299 o Description: OSCORE Counter Signature Key Additional Parameters 1301 o Reference: [[This specification]] (Section 5.4) 1303 o Name: cs_key_enc 1305 o CBOR Label: TBD6 1307 o CBOR Type: integer 1309 o Registry: ACE Public Key Encoding 1311 o Description: Encoding of Public Keys to be used with the OSCORE 1312 Counter Signature Algorithm 1314 o Reference: [[This specification]] (Section 5.4) 1316 18.4. Sequence Number Synchronization Method Registry 1318 IANA is asked to register the following entries in the "Sequence 1319 Number Synchronization Method" Registry defined in Section 9.8 of 1320 [I-D.ietf-ace-key-groupcomm]. 1322 o Name: Best effort 1324 o Value: 1 1326 o Description: No action is taken. 1328 o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.1) 1330 o Name: Baseline 1332 o Value: 2 1334 o Description: The first received request sets the baseline 1335 reference point, and is discarded with no delivery to the 1336 application. 1338 o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.2) 1339 o Name: Echo challenge-response 1341 o Value: 3 1343 o Description: Challenge response using the Echo Option for CoAP 1344 from [I-D.ietf-core-echo-request-tag]. 1346 o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.3) 1348 18.5. ACE Groupcomm Parameters Registry 1350 IANA is asked to register the following entry in the "ACE Groupcomm 1351 Parameters" Registry defined in Section 9.4 of 1352 [I-D.ietf-ace-key-groupcomm]. 1354 o Name: clientId 1356 o CBOR Key: TBD7 1358 o CBOR Type: Byte string 1360 o Reference: [[This specification]] (Section 8) 1362 18.6. TLS Exporter Label Registry 1364 IANA is asked to register the following entry in the "TLS Exporter 1365 Label" Registry defined in Section 6 of [RFC5705] and updated in 1366 Section 12 of [RFC8447]. 1368 o Value: EXPORTER-ACE-Sign-Challenge-coap-group-oscore-app 1370 o DTLS-OK: Y 1372 o Recommended: N 1374 o Reference: [[This specification]] (Section 5.2.1) 1376 19. References 1378 19.1. Normative References 1380 [I-D.ietf-ace-cwt-proof-of-possession] 1381 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 1382 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 1383 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 1384 possession-11 (work in progress), October 2019. 1386 [I-D.ietf-ace-key-groupcomm] 1387 Palombini, F. and M. Tiloca, "Key Provisioning for Group 1388 Communication using ACE", draft-ietf-ace-key-groupcomm-05 1389 (work in progress), March 2020. 1391 [I-D.ietf-ace-oauth-authz] 1392 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1393 H. Tschofenig, "Authentication and Authorization for 1394 Constrained Environments (ACE) using the OAuth 2.0 1395 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33 1396 (work in progress), February 2020. 1398 [I-D.ietf-ace-oscore-profile] 1399 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 1400 "OSCORE profile of the Authentication and Authorization 1401 for Constrained Environments Framework", draft-ietf-ace- 1402 oscore-profile-10 (work in progress), March 2020. 1404 [I-D.ietf-core-oscore-groupcomm] 1405 Tiloca, M., Selander, G., Palombini, F., and J. Park, 1406 "Group OSCORE - Secure Group Communication for CoAP", 1407 draft-ietf-core-oscore-groupcomm-07 (work in progress), 1408 March 2020. 1410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1411 Requirement Levels", BCP 14, RFC 2119, 1412 DOI 10.17487/RFC2119, March 1997, 1413 . 1415 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1416 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1417 March 2010, . 1419 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1420 Key Derivation Function (HKDF)", RFC 5869, 1421 DOI 10.17487/RFC5869, May 2010, 1422 . 1424 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1425 Application Protocol (CoAP)", RFC 7252, 1426 DOI 10.17487/RFC7252, June 2014, 1427 . 1429 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1430 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1431 . 1433 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1434 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1435 May 2017, . 1437 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1438 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1439 . 1441 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 1442 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 1443 . 1445 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1446 "Object Security for Constrained RESTful Environments 1447 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1448 . 1450 19.2. Informative References 1452 [I-D.dijk-core-groupcomm-bis] 1453 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1454 for the Constrained Application Protocol (CoAP)", draft- 1455 dijk-core-groupcomm-bis-03 (work in progress), March 1456 2020. 1458 [I-D.ietf-ace-dtls-authorize] 1459 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 1460 L. Seitz, "Datagram Transport Layer Security (DTLS) 1461 Profile for Authentication and Authorization for 1462 Constrained Environments (ACE)", draft-ietf-ace-dtls- 1463 authorize-09 (work in progress), December 2019. 1465 [I-D.ietf-core-coap-pubsub] 1466 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1467 Subscribe Broker for the Constrained Application Protocol 1468 (CoAP)", draft-ietf-core-coap-pubsub-09 (work in 1469 progress), September 2019. 1471 [I-D.ietf-core-echo-request-tag] 1472 Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, 1473 Request-Tag, and Token Processing", draft-ietf-core-echo- 1474 request-tag-09 (work in progress), March 2020. 1476 [I-D.tiloca-ace-oscore-gm-admin] 1477 Tiloca, M., Hoeglund, R., Stok, P., and F. Palombini, 1478 "Admin Interface for the OSCORE Group Manager", draft- 1479 tiloca-ace-oscore-gm-admin-01 (work in progress), March 1480 2020. 1482 [I-D.tiloca-core-oscore-discovery] 1483 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 1484 Groups with the CoRE Resource Directory", draft-tiloca- 1485 core-oscore-discovery-05 (work in progress), March 1486 2020. 1488 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1489 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1490 January 2012, . 1492 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1493 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1494 . 1496 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1497 Application Protocol (CoAP)", RFC 7641, 1498 DOI 10.17487/RFC7641, September 2015, 1499 . 1501 Appendix A. Profile Requirements 1503 This appendix lists the specifications on this application profile of 1504 ACE, based on the requiremens defined in Appendix A of 1505 [I-D.ietf-ace-key-groupcomm]. 1507 o REQ1 - Specify the encoding and value of the identifier of group, 1508 for scope entries of 'scope': see Section 3.1. 1510 o REQ2 - Specify the encoding and value of roles, for scope entries 1511 of 'scope': see Section 3.1. 1513 o REQ3 - if used, specify the acceptable values for 'sign_alg': 1514 values from Tables 5 and 6 of [RFC8152]. 1516 o REQ4 - If used, specify the acceptable values for 1517 'sign_parameters': values from the "Counter Signature Parameters" 1518 Registry (see Section 11.1 of [I-D.ietf-core-oscore-groupcomm]). 1520 o REQ5 - If used, specify the acceptable values for 1521 'sign_key_parameters': values from the "Counter Signature Key 1522 Parameters" Registry (see Section 11.2 of 1523 [I-D.ietf-core-oscore-groupcomm]). 1525 o REQ6 - If used, specify the acceptable values for 'pub_key_enc': 1 1526 ("COSE_Key") from the 'Confirmation Key' column of the "CWT 1527 Confirmation Method" Registry defined in 1528 [I-D.ietf-ace-cwt-proof-of-possession]. Future specifications may 1529 define additional values for this parameter. 1531 o REQ7 - Format of the 'key' value: see Section 5.4. 1533 o REQ8 - Acceptable values of 'gkty': Group_OSCORE_Security_Context 1534 object (see Section 5.4). 1536 o REQ9: Specify the format of the identifiers of group members: see 1537 Section 5.4 and Section 9. 1539 o REQ10 - Specify the communication protocol that the members of the 1540 group must use: CoAP, possibly over IP multicast. 1542 o REQ11 - Specify the security protocols that the group members must 1543 use to protect their communication: Group OSCORE. 1545 o REQ12 - Specify and register the application profile identifier: 1546 coap_group_oscore_app (see Section 18.1). 1548 o REQ13 - Specify policies at the KDC to handle member ids that are 1549 not included in 'get_pub_keys': see Section 9. 1551 o REQ14 - If used, specify the format and content of 1552 'group_policies' and its entries: see Section 5.4, and the three 1553 values defined and registered, as content of the entry "Sequence 1554 Number Synchronization Method" (see Section 18.4). 1556 o REQ15 - Specify the format of newly-generated individual keying 1557 material for group members, or of the information to derive it, 1558 and corresponding CBOR label: see Section 8. 1560 o REQ16 - Specify how the communication is secured between the 1561 Client and KDC: by means of any transport profile of ACE 1562 [I-D.ietf-ace-oauth-authz] between Client and Group Manager that 1563 complies with the requirements in Appendix C of 1564 [I-D.ietf-ace-oauth-authz]. 1566 o REQ17: Specify how the nonce N_S is generated, if the token is not 1567 being posted (e.g. if it is used directly to validate TLS 1568 instead): see Section 5.2.1. 1570 o REQ18: Specify if 'mgt_key_material' used, and if yes specify its 1571 format and content: not used in this version of the profile. 1573 o OPT1 (Optional) - Specify the encoding of public keys, of 1574 'client_cred', and of 'pub_keys' if COSE_Keys are not used: no. 1576 o OPT2 (Optional) - Specify the negotiation of parameter values for 1577 signature algorithm and signature keys, if 'sign_info' and 1578 'pub_key_enc' are not used: possible early discovery by using the 1579 approach based on the CoRE Resource Directory described in 1580 [I-D.tiloca-core-oscore-discovery]. 1582 o OPT3 (Optional) - Specify the encoding of 'pub_keys_repos' if the 1583 default is not used: no. 1585 o OPT4 (Optional) - Specify policies that instruct clients to retain 1586 unsuccessfully decrypted messages and for how long, so that they 1587 can be decrypted after getting updated keying material: no. 1589 o OPT5 (Optional) - Specify the behavior of the handler in case of 1590 failure to retrieve a public key for the specific node: send a 1591 4.00 Bad Request response to a Joining Request (see Section 5.3). 1593 o OPT6 (Optional) - Specify possible or required payload formats for 1594 specific error cases: send a 4.00 Bad Request response to a 1595 Joining Request (see Section 5.3). 1597 o OPT7 (Optional) - Specify CBOR values to use for abbreviating 1598 identifiers of roles in the group or topic (see Section 3.1). 1600 o OPT8 (Optional) - Specify policies for the KDC to perform group 1601 rekeying after receiving a Key Renewal Request: no. 1603 Appendix B. Document Updates 1605 RFC EDITOR: PLEASE REMOVE THIS SECTION. 1607 B.1. Version -04 to -05 1609 o Nonce N_S also in error responses to the Joining Requests. 1611 o Supporting single Access Token for multiple groups/topics. 1613 o Supporting legal requesters/responders using the 'peer_roles' 1614 parameter. 1616 o Registered and used dedicated label for TLS Exporter. 1618 o Added method for uploading a new public key to the Group Manager. 1620 o Added resource and method for retrieving the current group status. 1622 o Fixed inconsistency in retrieving group keying material only. 1624 o Clarified retrieval of keying material for monitor-only members. 1626 o Clarification on incrementing version number when rekeying the 1627 group. 1629 o Clarification on what is re-distributed with the group rekeying. 1631 o Security considerations on the size of the nonces used for the 1632 signature challenge. 1634 o Added CBOR values to abbreviate role identifiers in the group. 1636 B.2. Version -03 to -04 1638 o New abstract. 1640 o Moved general content to draft-ietf-ace-key-groupcomm 1642 o Terminology: node name; node resource. 1644 o Creation and pointing at node resource. 1646 o Updated Group Manager API (REST methods and offered services). 1648 o Size of challenges 'cnonce' and 'rsnonce'. 1650 o Value of 'rsnonce' for reused or non-traditionally-posted tokens. 1652 o Removed reference to RFC 7390. 1654 o New requirements from draft-ietf-ace-key-groupcomm 1656 o Editorial improvements. 1658 B.3. Version -02 to -03 1660 o New sections, aligned with the interface of ace-key-groupcomm . 1662 o Exchange of information on the countersignature algorithm and 1663 related parameters, during the Token POST (Section 4.1). 1665 o Nonce 'rsnonce' from the Group Manager to the Client 1666 (Section 4.1). 1668 o Client PoP signature in the Key Distribution Request upon joining 1669 (Section 4.2). 1671 o Local actions on the Group Manager, upon a new node's joining 1672 (Section 4.2). 1674 o Local actions on the Group Manager, upon a node's leaving 1675 (Section 12). 1677 o IANA registration in ACE Groupcomm Parameters Registry. 1679 o More fulfilled profile requirements (Appendix A). 1681 B.4. Version -01 to -02 1683 o Editorial fixes. 1685 o Changed: "listener" to "responder"; "pure listener" to "monitor". 1687 o Changed profile name to "coap_group_oscore_app", to reflect it is 1688 an application profile. 1690 o Added the 'type' parameter for all requests to a Join Resource. 1692 o Added parameters to indicate the encoding of public keys. 1694 o Challenge-response for proof-of-possession of signature keys 1695 (Section 4). 1697 o Renamed 'key_info' parameter to 'sign_info'; updated its format; 1698 extended to include also parameters of the countersignature key 1699 (Section 4.1). 1701 o Code 4.00 (Bad request), in responses to joining nodes providing 1702 an invalid public key (Section 4.3). 1704 o Clarifications on provisioning and checking of public keys 1705 (Sections 4 and 6). 1707 o Extended discussion on group rekeying and possible different 1708 approaches (Section 7). 1710 o Extended security considerations: proof-of-possession of signature 1711 keys; collision of OSCORE Group Identifiers (Section 8). 1713 o Registered three entries in the IANA Registry "Sequence Number 1714 Synchronization Method Registry" (Section 9). 1716 o Registered one public key encoding in the "ACE Public Key 1717 Encoding" IANA Registry (Section 9). 1719 B.5. Version -00 to -01 1721 o Changed name of 'req_aud' to 'audience' in the Authorization 1722 Request (Section 3.1). 1724 o Added negotiation of countersignature algorithm/parameters between 1725 Client and Group Manager (Section 4). 1727 o Updated format of the Key Distribution Response as a whole 1728 (Section 4.3). 1730 o Added parameter 'cs_params' in the 'key' parameter of the Key 1731 Distribution Response (Section 4.3). 1733 o New IANA registrations in the "ACE Authorization Server Request 1734 Creation Hints" Registry, "ACE Groupcomm Key" Registry, "OSCORE 1735 Security Context Parameters" Registry and "ACE Groupcomm Profile" 1736 Registry (Section 9). 1738 Acknowledgments 1740 The authors sincerely thank Santiago Aragon, Stefan Beck, Carsten 1741 Bormann, Martin Gunnarsson, Rikard Hoeglund, Daniel Migault, Jim 1742 Schaad, Ludwig Seitz, Goeran Selander and Peter van der Stok for 1743 their comments and feedback. 1745 The work on this document has been partly supported by VINNOVA and 1746 the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact 1747 Initiative ACTIVE. 1749 Authors' Addresses 1751 Marco Tiloca 1752 RISE AB 1753 Isafjordsgatan 22 1754 Kista SE-164 29 Stockholm 1755 Sweden 1757 Email: marco.tiloca@ri.se 1759 Jiye Park 1760 Universitaet Duisburg-Essen 1761 Schuetzenbahn 70 1762 Essen 45127 1763 Germany 1765 Email: ji-ye.park@uni-due.de 1766 Francesca Palombini 1767 Ericsson AB 1768 Torshamnsgatan 23 1769 Kista SE-16440 Stockholm 1770 Sweden 1772 Email: francesca.palombini@ericsson.com