idnits 2.17.00 (12 Aug 2021) /tmp/idnits43041/draft-ietf-ace-key-groupcomm-oscore-14.txt: -(3952): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (28 April 2022) is 16 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Toid' is mentioned on line 341, but not defined == Missing Reference: 'Tperm' is mentioned on line 341, but not defined == Missing Reference: 'EC2' is mentioned on line 3227, but not defined == Missing Reference: 'P-256' is mentioned on line 3219, but not defined == Missing Reference: 'P-384' is mentioned on line 3223, but not defined == Missing Reference: 'P-521' is mentioned on line 3227, but not defined -- Looks like a reference, but probably isn't: '0' on line 4347 == Unused Reference: 'RFC6838' is defined on line 3883, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-800-56A' ** Downref: Normative reference to an Informational RFC: RFC 6979 ** Downref: Normative reference to an Informational RFC: RFC 7748 ** Downref: Normative reference to an Informational RFC: RFC 8017 ** Downref: Normative reference to an Informational RFC: RFC 8032 == Outdated reference: A later version (-10) exists of draft-ietf-core-coap-pubsub-09 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group M. Tiloca 3 Internet-Draft RISE AB 4 Intended status: Standards Track J. Park 5 Expires: 30 October 2022 Universitaet Duisburg-Essen 6 F. Palombini 7 Ericsson AB 8 28 April 2022 10 Key Management for OSCORE Groups in ACE 11 draft-ietf-ace-key-groupcomm-oscore-14 13 Abstract 15 This document defines an application profile of the ACE framework for 16 Authentication and Authorization, to request and provision keying 17 material in group communication scenarios that are based on CoAP and 18 are secured with Group Object Security for Constrained RESTful 19 Environments (Group OSCORE). This application profile delegates the 20 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 30 October 2022. 44 Copyright Notice 46 Copyright (c) 2022 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 (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 62 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Format of Scope . . . . . . . . . . . . . . . . . . . . . . . 8 64 4. Authentication Credentials . . . . . . . . . . . . . . . . . 10 65 5. Authorization to Join a Group . . . . . . . . . . . . . . . . 12 66 5.1. Authorization Request . . . . . . . . . . . . . . . . . . 12 67 5.2. Authorization Response . . . . . . . . . . . . . . . . . 13 68 5.3. Token Transferring . . . . . . . . . . . . . . . . . . . 13 69 5.3.1. 'ecdh_info' Parameter . . . . . . . . . . . . . . . . 16 70 5.3.2. 'kdc_dh_creds' Parameter . . . . . . . . . . . . . . 18 71 6. Group Joining . . . . . . . . . . . . . . . . . . . . . . . . 20 72 6.1. Send the Joining Request . . . . . . . . . . . . . . . . 20 73 6.1.1. Value of the N_S Challenge . . . . . . . . . . . . . 22 74 6.2. Receive the Joining Request . . . . . . . . . . . . . . . 22 75 6.2.1. Follow-up to a 4.00 (Bad Request) Error Response . . 25 76 6.3. Send the Joining Response . . . . . . . . . . . . . . . . 26 77 6.4. Receive the Joining Response . . . . . . . . . . . . . . 32 78 7. Overview of the Group Rekeying Process . . . . . . . . . . . 34 79 7.1. Stale OSCORE Sender IDs . . . . . . . . . . . . . . . . . 35 80 8. Interface at the Group Manager . . . . . . . . . . . . . . . 37 81 8.1. ace-group/GROUPNAME/active . . . . . . . . . . . . . . . 37 82 8.1.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 37 83 8.2. ace-group/GROUPNAME/verif-data . . . . . . . . . . . . . 38 84 8.2.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 38 85 8.3. ace-group/GROUPNAME/stale-sids . . . . . . . . . . . . . 38 86 8.3.1. FETCH Handler . . . . . . . . . . . . . . . . . . . . 38 87 8.4. Admitted Methods . . . . . . . . . . . . . . . . . . . . 39 88 8.4.1. Signature Verifiers . . . . . . . . . . . . . . . . . 40 89 8.5. Operations Supported by Clients . . . . . . . . . . . . . 41 90 9. Additional Interactions with the Group Manager . . . . . . . 41 91 9.1. Retrieve Updated Keying Material . . . . . . . . . . . . 42 92 9.1.1. Get Group Keying Material . . . . . . . . . . . . . . 42 93 9.1.2. Get Group Keying Material and OSCORE Sender ID . . . 42 94 9.2. Request to Change Individual Keying Material . . . . . . 43 95 9.3. Retrieve Authentication Credentials of Group Members . . 45 96 9.4. Upload a New Authentication Credential . . . . . . . . . 45 97 9.5. Retrieve the Group Manager's Authentication Credential . 47 98 9.6. Retrieve Signature Verification Data . . . . . . . . . . 48 99 9.7. Retrieve the Group Policies . . . . . . . . . . . . . . . 50 100 9.8. Retrieve the Keying Material Version . . . . . . . . . . 50 101 9.9. Retrieve the Group Status . . . . . . . . . . . . . . . . 50 102 9.10. Retrieve Group Names . . . . . . . . . . . . . . . . . . 51 103 9.11. Leave the Group . . . . . . . . . . . . . . . . . . . . . 54 104 10. Removal of a Group Member . . . . . . . . . . . . . . . . . . 54 105 11. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 56 106 11.1. Sending Rekeying Messages . . . . . . . . . . . . . . . 58 107 11.2. Receiving Rekeying Messages . . . . . . . . . . . . . . 60 108 11.3. Missed Rekeying Instances . . . . . . . . . . . . . . . 61 109 11.3.1. Retrieve Stale Sender IDs . . . . . . . . . . . . . 63 110 12. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 65 111 13. ACE Groupcomm Error Identifiers . . . . . . . . . . . . . . . 67 112 14. Default Values for Group Configuration Parameters . . . . . . 68 113 14.1. Common . . . . . . . . . . . . . . . . . . . . . . . . . 68 114 14.2. Group Mode . . . . . . . . . . . . . . . . . . . . . . . 69 115 14.3. Pairwise Mode . . . . . . . . . . . . . . . . . . . . . 70 116 15. Security Considerations . . . . . . . . . . . . . . . . . . . 71 117 15.1. Management of OSCORE Groups . . . . . . . . . . . . . . 71 118 15.2. Size of Nonces as Proof-of-Possesion Challenge . . . . . 72 119 15.3. Reusage of Nonces for Proof-of-Possession Input . . . . 73 120 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74 121 16.1. OAuth Parameters . . . . . . . . . . . . . . . . . . . . 74 122 16.2. OAuth Parameters CBOR Mappings . . . . . . . . . . . . . 74 123 16.3. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . 75 124 16.4. ACE Groupcomm Key Types . . . . . . . . . . . . . . . . 76 125 16.5. ACE Groupcomm Profiles . . . . . . . . . . . . . . . . . 76 126 16.6. OSCORE Security Context Parameters . . . . . . . . . . . 76 127 16.7. TLS Exporter Labels . . . . . . . . . . . . . . . . . . 78 128 16.8. AIF . . . . . . . . . . . . . . . . . . . . . . . . . . 79 129 16.9. CoAP Content-Format . . . . . . . . . . . . . . . . . . 79 130 16.10. Group OSCORE Roles . . . . . . . . . . . . . . . . . . . 80 131 16.11. CoRE Resource Type . . . . . . . . . . . . . . . . . . . 80 132 16.12. ACE Scope Semantics . . . . . . . . . . . . . . . . . . 81 133 16.13. ACE Groupcomm Errors . . . . . . . . . . . . . . . . . . 81 134 16.14. Expert Review Instructions . . . . . . . . . . . . . . . 82 135 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 82 136 17.1. Normative References . . . . . . . . . . . . . . . . . . 82 137 17.2. Informative References . . . . . . . . . . . . . . . . . 86 138 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 88 139 A.1. Mandatory-to-Address Requirements . . . . . . . . . . . . 88 140 A.2. Optional-to-Address Requirements . . . . . . . . . . . . 91 141 Appendix B. Extensibility for Future COSE Algorithms . . . . . . 92 142 B.1. Format of 'ecdh_info_entry' . . . . . . . . . . . . . . . 93 143 B.2. Format of 'key' . . . . . . . . . . . . . . . . . . . . . 94 144 Appendix C. Document Updates . . . . . . . . . . . . . . . . . . 95 145 C.1. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 95 146 C.2. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 95 147 C.3. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 95 148 C.4. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 96 149 C.5. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 97 150 C.6. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 97 151 C.7. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 98 152 C.8. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 98 153 C.9. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 99 154 C.10. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 99 155 C.11. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 100 156 C.12. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 100 157 C.13. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 101 158 C.14. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 102 159 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 102 160 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 102 162 1. Introduction 164 Object Security for Constrained RESTful Environments (OSCORE) 165 [RFC8613] is a method for application-layer protection of the 166 Constrained Application Protocol (CoAP) [RFC7252], using CBOR Object 167 Signing and Encryption (COSE) 168 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs] and 169 enabling end-to-end security of CoAP payload and options. 171 As described in [I-D.ietf-core-oscore-groupcomm], Group OSCORE is 172 used to protect CoAP group communication 173 [I-D.ietf-core-groupcomm-bis], which can employ, for example, IP 174 multicast as underlying data transport. This relies on a Group 175 Manager, which is responsible for managing an OSCORE group and 176 enables the group members to exchange CoAP messages secured with 177 Group OSCORE. The Group Manager can be responsible for multiple 178 groups, coordinates the joining process of new group members, and is 179 entrusted with the distribution and renewal of group keying material. 181 This document is an application profile of 182 [I-D.ietf-ace-key-groupcomm], which itself builds on the ACE 183 framework for Authentication and Authorization 184 [I-D.ietf-ace-oauth-authz]. Message exchanges among the participants 185 as well as message formats and processing follow what specified in 186 [I-D.ietf-ace-key-groupcomm] for provisioning and renewing keying 187 material in group communication scenarios, where Group OSCORE is used 188 to protect CoAP group communication. 190 1.1. Terminology 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 194 "OPTIONAL" in this document are to be interpreted as described in BCP 195 14 [RFC2119][RFC8174] when, and only when, they appear in all 196 capitals, as shown here. 198 Readers are expected to be familiar with: 200 * The terms and concepts described in the ACE framework for 201 authentication and authorization [I-D.ietf-ace-oauth-authz] and in 202 the Authorization Information Format (AIF) [I-D.ietf-ace-aif] to 203 express authorization information. The terminology for entities 204 in the considered architecture is defined in OAuth 2.0 [RFC6749]. 205 In particular, this includes Client (C), Resource Server (RS), and 206 Authorization Server (AS). 208 * The terms and concept related to the message formats and 209 processing specified in [I-D.ietf-ace-key-groupcomm], for 210 provisioning and renewing keying material in group communication 211 scenarios. 213 * The terms and concepts described in CBOR [RFC8949] and COSE 214 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs]. 216 * The terms and concepts described in CoAP [RFC7252] and group 217 communication for CoAP [I-D.ietf-core-groupcomm-bis]. Unless 218 otherwise indicated, the term "endpoint" is used here following 219 its OAuth definition, aimed at denoting resources such as /token 220 and /introspect at the AS, and /authz-info at the RS. This 221 document does not use the CoAP definition of "endpoint", which is 222 "An entity participating in the CoAP protocol". 224 * The terms and concepts for protection and processing of CoAP 225 messages through OSCORE [RFC8613] and through Group OSCORE 226 [I-D.ietf-core-oscore-groupcomm] in group communication scenarios. 227 These especially include: 229 - Group Manager, as the entity responsible for a set of groups 230 where communications are secured with Group OSCORE. In this 231 document, the Group Manager acts as Resource Server. 233 - Authentication credential, as the set of information associated 234 with an entity, including that entity's public key and 235 parameters associated with the public key. Examples of 236 authentication credentials are CBOR Web Tokens (CWTs) and CWT 237 Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC7925] and 238 C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. 240 Additionally, this document makes use of the following terminology. 242 * Requester: member of an OSCORE group that sends request messages 243 to other members of the group. 245 * Responder: member of an OSCORE group that receives request 246 messages from other members of the group. A responder may reply 247 back, by sending a response message to the requester which has 248 sent the request message. 250 * Monitor: member of an OSCORE group that is configured as responder 251 and never replies back to requesters after receiving request 252 messages. This corresponds to the term "silent server" used in 253 [I-D.ietf-core-oscore-groupcomm]. 255 * Signature verifier: entity external to the OSCORE group and 256 intended to verify the signature of messages exchanged in the 257 group (see Sections 3.1 and 8.5 of 258 [I-D.ietf-core-oscore-groupcomm]). An authorized signature 259 verifier does not join the OSCORE group as an actual member, yet 260 it can retrieve the authentication credentials of the current 261 group members from the Group Manager. 263 * Signature-only group: an OSCORE group that uses only the group 264 mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]). 266 * Pairwise-only group: an OSCORE group that uses only the pairwise 267 mode (see Section 9 of [I-D.ietf-core-oscore-groupcomm]). 269 2. Protocol Overview 271 Group communication for CoAP has been enabled in 272 [I-D.ietf-core-groupcomm-bis] and can be secured with Group Object 273 Security for Constrained RESTful Environments (Group OSCORE) as 274 specified in [I-D.ietf-core-oscore-groupcomm]. A network node joins 275 an OSCORE group by interacting with the responsible Group Manager. 276 Once registered in the group, the new node can securely exchange 277 messages with other group members. 279 This document describes how to use [I-D.ietf-ace-key-groupcomm] and 280 [I-D.ietf-ace-oauth-authz] to perform a number of authentication, 281 authorization and key distribution actions as overviewed in Section 2 282 of [I-D.ietf-ace-key-groupcomm], when the considered group is 283 specifically an OSCORE group. 285 With reference to [I-D.ietf-ace-key-groupcomm]: 287 * The node wishing to join the OSCORE group, i.e., the joining node, 288 is the Client. 290 * The Group Manager is the Key Distribution Center (KDC), acting as 291 a Resource Server. 293 * The Authorization Server associated with the Group Manager is the 294 AS. 296 A node performs the steps described in Sections 3 and 4.3.1.1 of 297 [I-D.ietf-ace-key-groupcomm] in order to obtain an authorization for 298 joining an OSCORE group and then to join that group. The format and 299 processing of messages exchanged during such steps are further 300 specified in Section 5 and Section 6 of this document. 302 All communications between the involved entities MUST be secured. 304 In particular, communications between the Client and the Group 305 Manager leverage protocol-specific transport profiles of ACE to 306 achieve communication security, proof-of-possession and server 307 authentication. It is expected that, in the commonly referred base- 308 case of this document, the transport profile to use is pre-configured 309 and well-known to nodes participating in constrained applications. 311 With respect to what is defined in [I-D.ietf-ace-key-groupcomm]: 313 * The interface provided by the Group Manager extends the original 314 interface defined in Section 4.1 of [I-D.ietf-ace-key-groupcomm] 315 for the KDC, as specified in Section 8 of this document. 317 * In addition to those defined in Section 8 of 318 [I-D.ietf-ace-key-groupcomm], additional parameters are defined in 319 this document and summarized in Section 12. 321 * In addition to those defined in Section 9 of 322 [I-D.ietf-ace-key-groupcomm], additional error identifiers are 323 defined in this document and summarized in Section 13. 325 Finally, Appendix A lists the specifications on this application 326 profile of ACE, based on the requirements defined in Appendix A of 327 [I-D.ietf-ace-key-groupcomm]. 329 3. Format of Scope 331 Building on Section 3.1 of [I-D.ietf-ace-key-groupcomm], this section 332 defines the exact format and encoding of scope used in this profile. 334 To this end, this profile uses the Authorization Information Format 335 (AIF) [I-D.ietf-ace-aif]. In particular, with reference to the 336 generic AIF model 338 AIF-Generic = [* [Toid, Tperm]] 340 the value of the CBOR byte string used as scope encodes the CBOR 341 array [* [Toid, Tperm]], where each [Toid, Tperm] element corresponds 342 to one scope entry. 344 Furthermore, this document defines the new AIF specific data model 345 AIF-OSCORE-GROUPCOMM, that this profile MUST use to format and encode 346 scope entries. 348 In particular, the following holds for each scope entry. 350 * The object identifier ("Toid") is specialized as a CBOR item 351 specifying the name of the groups pertaining to the scope entry. 353 * The permission set ("Tperm") is specialized as a CBOR unsigned 354 integer with value R, specifying the permissions that the Client 355 wishes to have in the groups indicated by "Toid". 357 More specifically, the following applies when, as defined in this 358 document, a scope entry includes as set of permissions the set of 359 roles to take in an OSCORE group. 361 * The object identifier ("Toid") is a CBOR text string, specifying 362 the group name for the scope entry. 364 * The permission set ("Tperm") is a CBOR unsigned integer with value 365 R, specifying the role(s) that the Client wishes to take in the 366 group (REQ1). The value R is computed as follows. 368 - Each role in the permission set is converted into the 369 corresponding numeric identifier X from the "Value" column of 370 the "Group OSCORE Roles" registry, for which this document 371 defines the entries in Figure 1. 373 - The set of N numbers is converted into the single value R, by 374 taking two to the power of each numeric identifier X_1, X_2, 375 ..., X_N, and then computing the inclusive OR of the binary 376 representations of all the power values. 378 +-----------+-------+-------------------------------------------------+ 379 | Name | Value | Description | 380 +===========+=======+=================================================+ 381 | Reserved | 0 | This value is reserved | 382 |-----------+-------+-------------------------------------------------+ 383 | Requester | 1 | Send requests; receive responses | 384 |-----------+-------+-------------------------------------------------+ 385 | Responder | 2 | Send responses; receive requests | 386 +-----------+-------+-------------------------------------------------+ 387 | Monitor | 3 | Receive requests; never send requests/responses | 388 |-----------+-------+-------------------------------------------------| 389 | Verifier | 4 | Verify signature of intercepted messages | 390 +-----------+-------+-------------------------------------------------+ 392 Figure 1: Numeric identifier of roles in an OSCORE group 394 The following CDDL [RFC8610] notation defines a scope entry that uses 395 the AIF-OSCORE-GROUPCOMM data model and expresses a set of Group 396 OSCORE roles from those in Figure 1. 398 AIF-OSCORE-GROUPCOMM = AIF-Generic 400 oscore-gname = tstr ; Group name 401 oscore-gperm = uint . bits group-oscore-roles 403 group-oscore-roles = &( 404 Requester: 1, 405 Responder: 2, 406 Monitor: 3, 407 Verifier: 4 408 ) 410 scope_entry = [oscore-gname, oscore-gperm] 412 Future specifications that define new Group OSCORE roles MUST 413 register a corresponding numeric identifier in the "Group OSCORE 414 Roles" registry defined in Section 16.10 of this document. 416 Note that the value 0 is not available to use as numeric identifier 417 to specify a Group OSCORE role. It follows that, when expressing 418 Group OSCORE roles to take in a group as per this document, a scope 419 entry has the least significant bit of "Tperm" always set to 0. 421 This is an explicit feature of the AIF-OSCORE-GROUPCOMM data model. 422 That is, for each scope entry, the least significant bit of "Tperm" 423 set to 0 explicitly identifies the scope entry as exactly expressing 424 a set of Group OSCORE roles ("Tperm"), pertaining to a single group 425 whose name is specified by the string literal in "Toid". 427 Instead, by relying on the same AIF-OSCORE-GROUPCOMM data model, 428 [I-D.ietf-ace-oscore-gm-admin] defines the format of scope entries 429 for Administrator Clients that wish to access an admin interface at 430 the Group Manager. In such scope entries, the least significant bit 431 of "Tperm" is always set to 1. 433 4. Authentication Credentials 435 Source authentication of a message sent within the group and 436 protected with Group OSCORE is ensured by means of a digital 437 signature embedded in the message (in group mode), or by integrity- 438 protecting the message with pairwise keying material derived from the 439 asymmetric keys of sender and recipient (in pairwise mode). 441 Therefore, group members must be able to retrieve each other's 442 authentication credential from a trusted repository, in order to 443 verify source authenticity of incoming group messages. 445 As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group 446 Manager acts as trusted repository of the authentication credentials 447 of the group members, and provides those authentication credentials 448 to group members if requested to. Upon joining an OSCORE group, a 449 joining node is thus expected to provide its own authentication 450 credential to the Group Manager. 452 In particular, one of the following four cases can occur when a new 453 node joins an OSCORE group. 455 * The joining node is going to join the group exclusively as 456 monitor, i.e., it is not going to send messages to the group. In 457 this case, the joining node is not required to provide its own 458 authentication credential to the Group Manager, which thus does 459 not have to perform any check related to the format of the 460 authentication credential, to a signature or ECDH algorithm, and 461 to possible parameters associated with the algorithm and the 462 public key. In case the joining node still provides an 463 authentication credential in the 'client_cred' parameter of the 464 Joining Request (see Section 6.1), the Group Manager silently 465 ignores that parameter, as well as the related parameters 'cnonce' 466 and 'client_cred_verify'. 468 * The Group Manager already acquired the authentication credential 469 of the joining node during a past joining process. In this case, 470 the joining node MAY choose not to provide again its own 471 authentication credential to the Group Manager, in order to limit 472 the size of the Joining Request. The joining node MUST provide 473 its own authentication credential again if it has provided the 474 Group Manager with multiple authentication credentials during past 475 joining processes, intended for different OSCORE groups. If the 476 joining node provides its own authentication credential, the Group 477 Manager performs consistency checks as per Section 6.2 and, in 478 case of success, considers it as the authentication credential 479 associated with the joining node in the OSCORE group. 481 * The joining node and the Group Manager use an asymmetric proof-of- 482 possession key to establish a secure communication association. 483 Then, two cases can occur. 485 1. When establishing the secure communication association, the 486 Group Manager obtained from the joining node the joining 487 node's authentication credential, in the format used in the 488 OSCORE group and including the asymmetric proof-of-possession 489 key as public key. Also, such authentication credential and 490 the proof-of-possession key are compatible with the signature 491 or ECDH algorithm, and possible associated parameters used in 492 the OSCORE group. 494 In this case, the Group Manager considers the authentication 495 credential as the one associated with the joining node in the 496 OSCORE group. If the joining node is aware that the 497 authentication credential and the public key included thereof 498 are also valid for the OSCORE group, then the joining node MAY 499 choose to not provide again its own authentication credential 500 to the Group Manager. 502 The joining node MUST provide again its own authentication 503 credential if it has provided the Group Manager with multiple 504 authentication credentials during past joining processes, 505 intended for different OSCORE groups. If the joining node 506 provides its own authentication credential in the 507 'client_cred' parameter of the Joining Request (see 508 Section 6.1), the Group Manager performs consistency checks as 509 per Section 6.2 and, in case of success, considers it as the 510 authentication credential associated with the joining node in 511 the OSCORE group. 513 2. The authentication credential is not in the format used in the 514 OSCORE group, or else the authentication credential and the 515 proof-of-possession key included as public key are not 516 compatible with the signature or ECDH algorithm, and possible 517 associated parameters used in the OSCORE group. 519 In this case, the joining node MUST provide a different 520 compatible authentication credential and public key included 521 thereof to the Group Manager in the 'client_cred' parameter of 522 the Joining Request (see Section 6.1). Then, the Group 523 Manager performs consistency checks on this latest provided 524 authentication credential as per Section 6.2 and, in case of 525 success, considers it as the authentication credential 526 associated with the joining node in the OSCORE group. 528 * The joining node and the Group Manager use a symmetric proof-of- 529 possession key to establish a secure communication association. 530 In this case, upon performing a joining process with that Group 531 Manager for the first time, the joining node specifies its own 532 authentication credential in the 'client_cred' parameter of the 533 Joining Request (see Section 6.1). 535 5. Authorization to Join a Group 537 This section builds on Section 3 of [I-D.ietf-ace-key-groupcomm] and 538 is organized as follows. 540 First, Section 5.1 and Section 5.2 describe how the joining node 541 interacts with the AS, in order to be authorized to join an OSCORE 542 group under a given Group Manager and to obtain an Access Token. 543 Then, Section 5.3 describes how the joining node transfers the 544 obtained Access Token to the Group Manager. The following considers 545 a joining node that intends to contact the Group Manager for the 546 first time. 548 Note that what is defined in Section 3 of 549 [I-D.ietf-ace-key-groupcomm] applies, and only additions or 550 modifications to that specification are defined in this document. 552 5.1. Authorization Request 554 The Authorization Request message is as defined in Section 3.1 of 555 [I-D.ietf-ace-key-groupcomm], with the following additions. 557 * If the 'scope' parameter is present: 559 - The value of the CBOR byte string encodes a CBOR array, whose 560 format MUST follow the data model AIF-OSCORE-GROUPCOMM defined 561 in Section 3. In particular, for each OSCORE group to join: 563 o The group name is encoded as a CBOR text string. 565 o The set of requested roles is expressed as a single CBOR 566 unsigned integer. This is computed as defined in Section 3, 567 from the numerical abbreviations of each requested role 568 defined in the "Group OSCORE Roles" registry, for which this 569 document defines the entries in Figure 1 (REQ1). 571 5.2. Authorization Response 573 The Authorization Response message is as defined in Section 3.2 of 574 [I-D.ietf-ace-key-groupcomm], with the following additions: 576 * The AS MUST include the 'expires_in' parameter. Other means for 577 the AS to specify the lifetime of Access Tokens are out of the 578 scope of this document. 580 * The AS MUST include the 'scope' parameter, when the value included 581 in the Access Token differs from the one specified by the joining 582 node in the Authorization Request. In such a case, the second 583 element of each scope entry MUST be present, and specifies the set 584 of roles that the joining node is actually authorized to take in 585 the OSCORE group for that scope entry, encoded as specified in 586 Section 5.1. 588 Furthermore, if the AS uses the extended format of scope defined in 589 Section 7 of [I-D.ietf-ace-key-groupcomm] for the 'scope' claim of 590 the Access Token, the first element of the CBOR sequence [RFC8742] 591 MUST be the CBOR integer with value SEM_ID_TBD, defined in 592 Section 16.12 of this document (REQ28). This indicates that the 593 second element of the CBOR sequence, as conveying the actual access 594 control information, follows the scope semantics defined for this 595 application profile in Section 3 of this document. 597 5.3. Token Transferring 599 The exchange of Token Transfer Request and Token Transfer Response is 600 defined in Section 3.3 of [I-D.ietf-ace-key-groupcomm]. In addition 601 to that, the following applies. 603 * The Token Transfer Request MAY additionally contain the following 604 parameters, which, if included, MUST have the corresponding values 605 defined below (OPT2): 607 - 'ecdh_info' defined in Section 5.3.1 of this document, with 608 value the CBOR simple value "null" (0xf6) to request 609 information about the ECDH algorithm, the ECDH algorithm 610 parameters, the ECDH key parameters and the exact format of 611 authentication credentials used in the groups that the Client 612 has been authorized to join. This is relevant in case the 613 joining node supports the pairwise mode of Group OSCORE 614 [I-D.ietf-core-oscore-groupcomm]. 616 - 'kdc_dh_creds' defined in Section 5.3.2 of this document, with 617 value the CBOR simple value "null" (0xf6) to request the 618 Diffie-Hellman authentication credentials of the Group Manager 619 for the groups that the Client has been authorized to join. 620 That is, each of such authentication credentials includes a 621 Diffie-Hellman public key of the Group Manager. This is 622 relevant in case the joining node supports the pairwise mode of 623 Group OSCORE [I-D.ietf-core-oscore-groupcomm]. 625 Alternatively, the joining node may retrieve this information by 626 other means. 628 * The 'kdcchallenge' parameter contains a dedicated nonce N_S 629 generated by the Group Manager. For the N_S value, it is 630 RECOMMENDED to use a 8-byte long random nonce. The joining node 631 can use this nonce in order to prove the possession of its own 632 private key, upon joining the group (see Section 6.1). 634 The 'kdcchallenge' parameter MAY be omitted from the Token 635 Transfer Response, if the 'scope' of the Access Token specifies 636 only the role "monitor" or only the role "verifier" or only the 637 two roles combined, for each and every of the specified groups. 639 * If the 'sign_info' parameter is present in the response, the 640 following applies for each element 'sign_info_entry'. 642 - 'id' MUST NOT refer to OSCORE groups that are pairwise-only 643 groups. 645 - 'sign_alg' takes value from the "Value" column of the "COSE 646 Algorithms" registry [COSE.Algorithms]. 648 - 'sign_parameters' is a CBOR array. Its format and value are 649 the same of the COSE capabilities array for the algorithm 650 indicated in 'sign_alg', as specified for that algorithm in the 651 "Capabilities" column of the "COSE Algorithms" registry 652 [COSE.Algorithms] (REQ4). 654 - 'sign_key_parameters' is a CBOR array. Its format and value 655 are the same of the COSE capabilities array for the COSE key 656 type of the keys used with the algorithm indicated in 657 'sign_alg', as specified for that key type in the 658 "Capabilities" column of the "COSE Key Types" registry 659 [COSE.Key.Types] (REQ5). 661 - 'pub_key_enc' takes value from the "Label" column of the "COSE 662 Header Parameters" registry [COSE.Header.Parameters] (REQ6). 663 Consistently with Section 2.3 of 664 [I-D.ietf-core-oscore-groupcomm], acceptable values denote a 665 format of authentication credential that MUST explicitly 666 provide the public key as well as the comprehensive set of 667 information related to the public key algorithm, including, 668 e.g., the used elliptic curve (when applicable). 670 At the time of writing this specification, acceptable formats 671 of authentication credentials are CBOR Web Tokens (CWTs) and 672 CWT Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC7925] 673 and C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. 674 Further formats may be available in the future, and would be 675 acceptable to use as long as they comply with the criteria 676 defined above. 678 [ As to CWTs and CCSs, the COSE Header Parameters 'kcwt' and 679 'kccs' are under pending registration requested by draft-ietf- 680 lake-edhoc. ] 682 [ As to C509 certificates, the COSE Header Parameters 'c5b' and 683 'c5c' are under pending registration requested by draft-ietf- 684 cose-cbor-encoded-cert. ] 686 This format is consistent with every signature algorithm currently 687 considered in [I-D.ietf-cose-rfc8152bis-algs], i.e., with 688 algorithms that have only the COSE key type as their COSE 689 capability. Appendix B of [I-D.ietf-ace-key-groupcomm] describes 690 how the format of each 'sign_info_entry' can be generalized for 691 possible future registered algorithms having a different set of 692 COSE capabilities. 694 * If 'ecdh_info' is included in the Token Transfer Request, the 695 Group Manager SHOULD include the 'ecdh_info' parameter in the 696 Token Transfer Response, as per the format defined in 697 Section 5.3.1. Note that the field 'id' of each 'ecdh_info_entry' 698 specifies the name, or array of group names, for which that 699 'ecdh_info_entry' applies to. 701 As an exception, the KDC MAY omit the 'ecdh_info' parameter in the 702 Token Transfer Response even if 'ecdh_info' is included in the 703 Token Transfer Request, in case all the groups that the Client is 704 authorized to join are signature-only groups. 706 * If 'kdc_dh_creds' is included in the Token Transfer Request and 707 any of the groups that the Client has been authorized to join is a 708 pairwise-only group, then the Group Manager MUST include the 709 'kdc_dh_creds' parameter in the Token Transfer Response, as per 710 the format defined in Section 5.3.2. Otherwise, if 'kdc_dh_creds' 711 is included in the Token Transfer Request, the Group Manager MAY 712 include the 'kdc_dh_creds' parameter in the Token Transfer 713 Response. Note that the field 'id' specifies the group name, or 714 array of group names, for which the corresponding 'kdc_dh_creds' 715 applies to. 717 Note that, other than through the above parameters as defined in 718 Section 3.3 of [I-D.ietf-ace-key-groupcomm], the joining node may 719 have obtained such information by alternative means. For example, 720 information conveyed in the 'sign_info' and 'ecdh_info' parameters 721 may have been pre-configured, or the joining node MAY early retrieve 722 it by using the approach described in 723 [I-D.tiloca-core-oscore-discovery], to discover the OSCORE group and 724 the link to the associated group-membership resource at the Group 725 Manager (OPT3). 727 5.3.1. 'ecdh_info' Parameter 729 The 'ecdh_info' parameter is an OPTIONAL parameter of the request and 730 response messages exchanged between the Client and the authz-info 731 endpoint at the RS (see Section 5.10.1. of 732 [I-D.ietf-ace-oauth-authz]). 734 This parameter allows the Client and the RS to exchange information 735 about an ECDH algorithm as well as about the authentication 736 credentials and public keys to accordingly use for deriving Diffie- 737 Hellman secrets. Its exact semantics and content are application 738 specific. 740 In this application profile, this parameter is used to exchange 741 information about the ECDH algorithm as well as about the 742 authentication credentials and public keys to be used with it, in the 743 groups indicated by the transferred Acces Token as per its 'scope' 744 claim (see Section 3.2 of [I-D.ietf-ace-key-groupcomm]). 746 When used in the Token Transfer Request sent to the Group Manager, 747 the 'ecdh_info' parameter has value the CBOR simple value "null" 748 (0xf6). This is done to ask for information about the ECDH algorithm 749 as well as about the authentication credentials and public keys to be 750 used to compute static-static Diffie-Hellman shared secrets 751 [NIST-800-56A], in the OSCORE groups that the Client has been 752 authorized to join and that use the pairwise mode of Group OSCORE 753 [I-D.ietf-core-oscore-groupcomm]. 755 When used in the following Token Transfer Response from the Group 756 Manager, the 'ecdh_info' parameter is a CBOR array of one or more 757 elements. The number of elements is at most the number of OSCORE 758 groups that the Client has been authorized to join. 760 Each element contains information about ECDH parameters as well as 761 about authentication credentials and public keys, for one or more 762 OSCORE groups that use the pairwise mode of Group OSCORE and that the 763 Client has been authorized to join. Each element is formatted as 764 follows. 766 * The first element 'id' is the group name of the OSCORE group or an 767 array of group names for the OSCORE groups for which the specified 768 information applies. In particular 'id' MUST NOT refer to OSCORE 769 groups that are signature-only groups. 771 * The second element 'ecdh_alg' is a CBOR integer or a CBOR text 772 string indicating the ECDH algorithm used in the OSCORE group 773 identified by 'gname'. Values are taken from the "Value" column 774 of the "COSE Algorithms" registry [COSE.Algorithms]. 776 * The third element 'ecdh_parameters' is a CBOR array indicating the 777 parameters of the ECDH algorithm used in the OSCORE group 778 identified by 'gname'. Its format and value are the same of the 779 COSE capabilities array for the algorithm indicated in 'ecdh_alg', 780 as specified for that algorithm in the "Capabilities" column of 781 the "COSE Algorithms" registry [COSE.Algorithms]. 783 * The fourth element 'ecdh_key_parameters' is a CBOR array 784 indicating the parameters of the keys used with the ECDH algorithm 785 in the OSCORE group identified by 'gname'. Its content depends on 786 the value of 'ecdh_alg'. In particular, its format and value are 787 the same of the COSE capabilities array for the COSE key type of 788 the keys used with the algorithm indicated in 'ecdh_alg', as 789 specified for that key type in the "Capabilities" column of the 790 "COSE Key Types" registry [COSE.Key.Types]. 792 * The fifth element 'cred_fmt' is a CBOR integer indicating the 793 format of authentication credentials used in the OSCORE group 794 identified by 'gname'. It takes value from the "Label" column of 795 the "COSE Header Parameters" registry [COSE.Header.Parameters] 796 (REQ6). Acceptable values denote a format that MUST provide the 797 public key as well as the comprehensive set of information related 798 to the public key algorithm, including, e.g., the used elliptic 799 curve (when applicable). The same considerations and guidelines 800 for the 'pub_key_enc' element of 'sign_info' apply (see 801 Section 5.3). 803 The CDDL notation [RFC8610] of the 'ecdh_info' parameter is given 804 below. 806 ecdh_info = ecdh_info_req / ecdh_info_resp 808 ecdh_info_req = null ; in the Token Transfer 809 ; Request to the 810 ; Group Manager 812 ecdh_info_res = [ + ecdh_info_entry ] ; in the Token Transfer 813 ; Response from the 814 ; Group Manager 816 ecdh_info_entry = 817 [ 818 id : gname / [ + gname ], 819 ecdh_alg : int / tstr, 820 ecdh_parameters : [ any ], 821 ecdh_key_parameters : [ any ], 822 cred_fmt = int 823 ] 825 gname = tstr 827 This format is consistent with every ECDH algorithm currently defined 828 in [I-D.ietf-cose-rfc8152bis-algs], i.e., with algorithms that have 829 only the COSE key type as their COSE capability. Appendix B of this 830 document describes how the format of each 'ecdh_info_entry' can be 831 generalized for possible future registered algorithms having a 832 different set of COSE capabilities. 834 5.3.2. 'kdc_dh_creds' Parameter 836 The 'kdc_dh_creds' parameter is an OPTIONAL parameter of the request 837 and response messages exchanged between the Client and the authz-info 838 endpoint at the RS (see Section 5.10.1. of 839 [I-D.ietf-ace-oauth-authz]). 841 This parameter allows the Client to request and retrieve the Diffie- 842 Hellman authentication credentials of the RS, i.e., authentication 843 credentials including a Diffie-Hellman public key of the RS. 845 In this application profile, this parameter is used to request and 846 retrieve from the Group Manager its Diffie-Hellman authentication 847 credentials to use, in the OSCORE groups that the Client has been 848 authorized to join. The Group Manager has specifically a Diffie- 849 Hellman authentication credential in an OSCORE group, and thus a 850 Diffie-Hellman public key in that group, if and only if the group is 851 a pairwise-only group. In this case, the early retrieval of the 852 Group Manager's authentication credential is necessary in order for 853 the joining node to prove the possession of its own private key, upon 854 joining the group (see Section 6.1). 856 When used in the Token Transfer Request sent to the Group Manager, 857 the 'kdc_dh_creds' parameter has value the CBOR simple value "null" 858 (0xf6). This is done to ask for the Diffie-Hellman authentication 859 credentials that the Group Manager uses in the OSCORE groups that the 860 Client has been authorized to join. 862 When used in the following Token Transfer Response from the Group 863 Manager, the 'kdc_dh_creds' parameter is a CBOR array of one or more 864 elements. The number of elements is at most the number of OSCORE 865 groups that the Client has been authorized to join. 867 Each element 'kdc_dh_creds_entry' contains information about the 868 Group Manager's Diffie-Hellman authentication credentials, for one or 869 more OSCORE groups that are pairwise-only groups and that the Client 870 has been authorized to join. Each element is formatted as follows. 872 * The first element 'id' is the group name of the OSCORE group or an 873 array of group names for the OSCORE groups for which the specified 874 information applies. In particular 'id' MUST refer exclusively to 875 OSCORE groups that are pairwise-only groups. 877 * The second element 'cred_fmt' is a CBOR integer indicating the 878 format of authentication credentials used in the OSCORE group 879 identified by 'gname'. It takes value from the "Label" column of 880 the "COSE Header Parameters" registry [COSE.Header.Parameters] 881 (REQ6). Acceptable values denote a format that MUST explicitly 882 provide the public key as well as comprehensive set of information 883 related to the public key algorithm, including, e.g., the used 884 elliptic curve (when applicable). The same considerations and 885 guidelines for the 'pub_key_enc' element of 'sign_info' apply (see 886 Section 5.3). 888 * The third element 'cred' is a CBOR byte string, which encodes the 889 Group Manager's Diffie-Hellman authentication credential in its 890 original binary representation made available to other endpoints 891 in the group. In particular, the original binary representation 892 complies with the format specified by the 'cred_fmt' element. 894 Note that the authentication credential provides the comprehensive 895 set of information related to its public key algorithm, i.e., the 896 ECDH algorithm used in the OSCORE group as pairwise key agreement 897 algorithm. 899 The CDDL notation [RFC8610] of the 'kdc_dh_creds' parameter is given 900 below. 902 kdc_dh_creds = kdc_dh_creds_req / kdc_dh_creds_resp 904 kdc_dh_creds_req = null ; in the Token Transfer 905 ; Request to the 906 ; Group Manager 908 kdc_dh_creds_res = [ + kdc_dh_creds_entry ] ; in the Token Transfer 909 ; Response from the 910 ; Group Manager 912 kdc_dh_creds_entry = 913 [ 914 id : gname / [ + gname ], 915 cred_fmt = int, 916 cred = bstr 917 ] 919 gname = tstr 921 6. Group Joining 923 This section describes the interactions between the joining node and 924 the Group Manager to join an OSCORE group. The message exchange 925 between the joining node and the Group Manager consists of the 926 messages defined in Section 4.3.1.1 of [I-D.ietf-ace-key-groupcomm]. 927 Note that what is defined in [I-D.ietf-ace-key-groupcomm] applies, 928 and only additions or modifications to that specification are defined 929 in this document. 931 6.1. Send the Joining Request 933 The joining node requests to join the OSCORE group by sending a 934 Joining Request message to the related group-membership resource at 935 the Group Manager, as per Section 4.3.1.1 of 936 [I-D.ietf-ace-key-groupcomm]. Additionally to what is defined in 937 Section 4.3.1 of [I-D.ietf-ace-key-groupcomm], the following applies. 939 * The 'scope' parameter MUST be included. Its value encodes one 940 scope entry with the format defined in Section 3, indicating the 941 group name and the role(s) that the joining node wants to take in 942 the group. 944 * The 'get_pub_keys' parameter is present only if the joining node 945 wants to retrieve the authentication credentials of the group 946 members from the Group Manager during the joining process (see 947 Section 4). Otherwise, this parameter MUST NOT be present. 949 If this parameter is present and its value is not the CBOR simple 950 value "null" (0xf6), each element of the inner CBOR array 951 'role_filter' is encoded as a CBOR unsigned integer, with the same 952 value of a permission set ("Tperm") indicating that role or 953 combination of roles in a scope entry, as defined in Section 3. 955 * 'cnonce' contains a dedicated nonce N_C generated by the joining 956 node. For the N_C value, it is RECOMMENDED to use a 8-byte long 957 random nonce. 959 * The proof-of-possession (PoP) evidence included in 960 'client_cred_verify' is computed as defined below (REQ14). In 961 either case, the N_S used to build the PoP input is as defined in 962 Section 6.1.1. 964 - If the group is not a pairwise-only group, the PoP evidence 965 MUST be a signature. The joining node computes the signature 966 by using the same private key and signature algorithm it 967 intends to use for signing messages in the OSCORE group. 969 - If the group is a pairwise-only group, the PoP evidence MUST be 970 a MAC computed as follows, by using the HKDF Algorithm HKDF 971 SHA-256, which consists of composing the HKDF-Extract and HKDF- 972 Expand steps [RFC5869]. 974 MAC = HKDF(salt, IKM, info, L) 976 The input parameters of HKDF are as follows. 978 o salt takes as value the empty byte string. 980 o IKM is computed as a cofactor Diffie-Hellman shared secret, 981 see Section 5.7.1.2 of [NIST-800-56A], using the ECDH 982 algorithm used in the OSCORE group. The joining node uses 983 its own Diffie-Hellman private key and the Diffie-Hellman 984 public key of the Group Manager. For X25519 and X448, the 985 procedure is described in Section 5 of [RFC7748]. 987 o info takes as value the PoP input. 989 o L is equal to 8, i.e., the size of the MAC, in bytes. 991 6.1.1. Value of the N_S Challenge 993 The value of the N_S challenge is determined as follows. 995 1. If the joining node has provided the Access Token to the Group 996 Manager by means of a Token Transfer Request to the /authz-info 997 endpoint as in Section 5.3, then N_S takes the same value of the 998 most recent 'kdcchallenge' parameter received by the joining node 999 from the Group Manager. This can be either the one specified in 1000 the Token Transfer Response, or the one possibly specified in a 1001 4.00 (Bad Request) error response to a following Joining Request 1002 (see Section 6.2). 1004 2. If the provisioning of the Access Token to the Group Manager has 1005 relied on the DTLS profile of ACE [I-D.ietf-ace-dtls-authorize] 1006 with the Access Token as content of the "psk_identity" field of 1007 the ClientKeyExchange message [RFC6347], then N_S is an exporter 1008 value computed as defined in Section 7.5 of [RFC8446]. 1009 Specifically, N_S is exported from the DTLS session between the 1010 joining node and the Group Manager, using an empty 1011 'context_value', 32 bytes as 'key_length', and the exporter label 1012 "EXPORTER-ACE-Sign-Challenge-coap-group-oscore-app" defined in 1013 Section 16.7 of this document. 1015 It is up to applications to define how N_S is computed in further 1016 alternative settings. 1018 Section 15.3 provides security considerations on the reusage of the 1019 N_S challenge. 1021 6.2. Receive the Joining Request 1023 The Group Manager processes the Joining Request as defined in 1024 Section 4.3.1 of [I-D.ietf-ace-key-groupcomm], with the following 1025 additions. 1027 The Group Manager verifies the PoP evidence contained in 1028 'client_cred_verify' as follows: 1030 * As PoP input, the Group Manager uses the value of the 'scope' 1031 parameter from the Joining Request as a CBOR byte string, 1032 concatenated with N_S encoded as a CBOR byte string, concatenated 1033 with N_C encoded as a CBOR byte string. In particular, N_S is 1034 determined as described in Section 6.1.1, while N_C is the nonce 1035 provided in the 'cnonce' parameter of the Joining Request. 1037 * As public key of the joining node, the Group Manager uses either 1038 the one included in the authentication credential retrieved from 1039 the 'client_cred' parameter of the Joining Request, or the one 1040 from the already stored authentication credential as acquired from 1041 previous interactions with the joining node (see Section 4). 1043 * If the group is not a pairwise-only group, the PoP evidence is a 1044 signature. The Group Manager verifies it by using the public key 1045 of the joining node, as well as the signature algorithm used in 1046 the OSCORE group and possible corresponding parameters. 1048 * If the group is a pairwise-only group, the PoP evidence is a MAC. 1049 The Group Manager recomputes the MAC through the same process 1050 taken by the joining node when preparing the value of the 1051 'client_cred_verify' parameter for the Joining Request (see 1052 Section 6.1), with the difference that the Group Manager uses its 1053 own Diffie-Hellman private key and the Diffie-Hellman public key 1054 of the joining node. The verification succeeds if and only if the 1055 recomputed MAC is equal to the MAC conveyed as PoP evidence in the 1056 Joining Request. 1058 The Group Manager MUST reply with a 5.03 (Service Unavailable) error 1059 response in the following cases: 1061 * There are currently no OSCORE Sender IDs available to assign in 1062 the OSCORE group and, at the same time, the joining node is not 1063 going to join the group exclusively as monitor. The response MUST 1064 have Content-Format set to application/ace-groupcomm+cbor and is 1065 formatted as defined in Section 4.1.2 of 1066 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST 1067 be set to 4 ("No available node identifiers"). 1069 * The OSCORE group that the joining node has been trying to join is 1070 currently inactive (see Section 8.1). The response MUST have 1071 Content-Format set to application/ace-groupcomm+cbor and is 1072 formatted as defined in Section 4.1.2 of 1073 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST 1074 be set to 9 ("Group currently not active"). 1076 The Group Manager MUST reply with a 4.00 (Bad Request) error response 1077 in the following cases: 1079 * The 'client_cred' parameter is present in the Joining Request and 1080 its value is not an eligible authentication credential (e.g., it 1081 is not of the format accepted in the group). 1083 * The 'client_cred' parameter is not present in the Joining Request 1084 while the joining node is not going to join the group exclusively 1085 as monitor, and any of the following conditions holds: 1087 - The Group Manager does not store an eligible authentication 1088 credential (e.g., of the format accepted in the group) for the 1089 joining node. 1091 - The Group Manager stores multiple eligible authentication 1092 credentials (e.g., of the format accepted in the group) for the 1093 joining node. 1095 * The 'scope' parameter is not present in the Joining Request, or it 1096 is present and specifies any set of roles not included in the 1097 following list: "requester", "responder", "monitor", ("requester", 1098 "responder"). Future specifications that define a new role for 1099 members of OSCORE groups MUST define possible sets of roles 1100 (including the new role and existing roles) that are acceptable to 1101 specify in the 'scope' parameter of a Joining Request. 1103 * The Joining Request includes the 'client_cred' parameter but does 1104 not include both the 'cnonce' and 'client_cred_verify' parameters. 1106 In order to prevent the acceptance of Ed25519 and Ed448 public keys 1107 that cannot be successfully converted to Montgomery coordinates, and 1108 thus cannot be used for the derivation of pairwise keys (see 1109 Section 2.4.1 of [I-D.ietf-core-oscore-groupcomm]), the Group Manager 1110 MAY reply with a 4.00 (Bad Request) error response in case all the 1111 following conditions hold: 1113 * The OSCORE group uses the pairwise mode of Group OSCORE. 1115 * The OSCORE group uses EdDSA public keys [RFC8032]. 1117 * The authentication credential of the joining node from the 1118 'client_cred' parameter includes a public key which: 1120 - Is for the elliptic curve Ed25519 and has its Y coordinate 1121 equal to -1 or 1 (mod p), with p = (2^255 - 19), see 1122 Section 4.1 of [RFC7748]; or 1124 - Is for the elliptic curve Ed448 and has its Y coordinate equal 1125 to -1 or 1 (mod p), with p = (2^448 - 2^224 - 1), see 1126 Section 4.2 of [RFC7748]. 1128 A 4.00 (Bad Request) error response from the Group Manager to the 1129 joining node MUST have content format application/ace-groupcomm+cbor. 1130 The response payload is a CBOR map formatted as follows: 1132 * If the group uses (also) the group mode of Group OSCORE, the CBOR 1133 map MUST contain the 'sign_info' parameter, whose CBOR label is 1134 defined in Section 8 of [I-D.ietf-ace-key-groupcomm]. This 1135 parameter has the same format of 'sign_info_res' defined in 1136 Section 3.3.1 of [I-D.ietf-ace-key-groupcomm]. In particular, it 1137 includes a single element 'sign_info_entry' pertaining to the 1138 OSCORE group that the joining node has tried to join with the 1139 Joining Request. 1141 * If the group uses (also) the pairwise mode of Group OSCORE, the 1142 CBOR map MUST contain the 'ecdh_info' parameter, whose CBOR label 1143 is defined in Section 16.3. This parameter has the same format of 1144 'ecdh_info_res' defined in Section 5.3.1. In particular, it 1145 includes a single element 'ecdh_info_entry' pertaining to the 1146 OSCORE group that the joining node has tried to join with the 1147 Joining Request. 1149 * If the group is a pairwise-only group, the CBOR map MUST contain 1150 the 'kdc_dh_creds' parameter, whose CBOR label is defined in 1151 Section 16.3. This parameter has the same format of 1152 'kdc_dh_creds_res' defined in Section 5.3.2. In particular, it 1153 includes a single element 'kdc_dh_creds_entry' pertaining to the 1154 OSCORE group that the joining node has tried to join with the 1155 Joining Request. 1157 * The CBOR map MAY include the 'kdcchallenge' parameter, whose CBOR 1158 label is defined in Section 8 of [I-D.ietf-ace-key-groupcomm]. If 1159 present, this parameter is a CBOR byte string, which encodes a 1160 newly generated 'kdcchallenge' value that the Client can use when 1161 preparing a Joining Request (see Section 6.1). In such a case the 1162 Group Manager MUST store the newly generated value as the 1163 'kdcchallenge' value associated with the joining node, possibly 1164 replacing the currently stored value. 1166 6.2.1. Follow-up to a 4.00 (Bad Request) Error Response 1168 When receiving a 4.00 (Bad Request) error response, the joining node 1169 MAY send a new Joining Request to the Group Manager. In such a case: 1171 * The 'cnonce' parameter MUST include a new dedicated nonce N_C 1172 generated by the joining node. 1174 * The 'client_cred' parameter MUST include an authentication 1175 credential in the format indicated by the Group Manager. Also, 1176 the authentication credential as well as the included public key 1177 MUST be compatible with the signature or ECDH algorithm, and 1178 possible associated parameters. 1180 * The 'client_cred_verify' parameter MUST include a PoP evidence 1181 computed as described in Section 6.1, by using the private key 1182 associated with the authentication credential specified in the 1183 current 'client_cred' parameter, with the signature or ECDH 1184 algorithm, and possible associated parameters indicated by the 1185 Group Manager. If the error response from the Group Manager 1186 includes the 'kdcchallenge' parameter, the joining node MUST use 1187 its content as new N_S challenge to compute the PoP evidence. 1189 6.3. Send the Joining Response 1191 If the processing of the Joining Request described in Section 6.2 is 1192 successful, the Group Manager updates the group membership by 1193 registering the joining node NODENAME as a new member of the OSCORE 1194 group GROUPNAME, as described in Section 4.3.1 of 1195 [I-D.ietf-ace-key-groupcomm]. 1197 If the joining node has not taken exclusively the role of monitor, 1198 the Group Manager performs also the following actions. 1200 * The Group Manager selects an available OSCORE Sender ID in the 1201 OSCORE group, and exclusively assigns it to the joining node. The 1202 Group Manager MUST NOT assign an OSCORE Sender ID to the joining 1203 node if this joins the group exclusively with the role of monitor, 1204 according to what is specified in the Access Token (see 1205 Section 5.2). 1207 Consistently with Section 3.2.1 of 1208 [I-D.ietf-core-oscore-groupcomm], the Group Manager MUST assign an 1209 OSCORE Sender ID that has not been used in the OSCORE group since 1210 the latest time when the current Gid value was assigned to the 1211 group. 1213 If the joining node is recognized as a current group member, e.g., 1214 through the ongoing secure communication association, the 1215 following also applies. 1217 - The Group Manager MUST assign a new OSCORE Sender ID different 1218 than the one currently used by the joining node in the OSCORE 1219 group. 1221 - The Group Manager MUST add the old, relinquished OSCORE Sender 1222 ID of the joining node to the most recent set of stale Sender 1223 IDs, in the collection associated with the group (see 1224 Section 7.1). 1226 * The Group Manager stores the association between i) the 1227 authentication credential of the joining node; and ii) the Group 1228 Identifier (Gid), i.e., the OSCORE ID Context, associated with the 1229 OSCORE group together with the OSCORE Sender ID assigned to the 1230 joining node in the group. The Group Manager MUST keep this 1231 association updated over time. 1233 Then, the Group Manager replies to the joining node, providing the 1234 updated security parameters and keying meterial necessary to 1235 participate in the group communication. This success Joining 1236 Response is formatted as defined in Section 4.3.1 of 1237 [I-D.ietf-ace-key-groupcomm], with the following additions: 1239 * The 'gkty' parameter identifies a key of type 1240 "Group_OSCORE_Input_Material object", defined in Section 16.4 of 1241 this document. 1243 * The 'key' parameter includes what the joining node needs in order 1244 to set up the Group OSCORE Security Context as per Section 2 of 1245 [I-D.ietf-core-oscore-groupcomm]. 1247 This parameter has as value a Group_OSCORE_Input_Material object, 1248 which is defined in this document and extends the 1249 OSCORE_Input_Material object encoded in CBOR as defined in 1250 Section 3.2.1 of [I-D.ietf-ace-oscore-profile]. In particular, it 1251 contains the additional parameters 'group_senderId', 'cred_fmt', 1252 'sign_enc_alg', 'sign_alg', 'sign_params', 'ecdh_alg' and 1253 'ecdh_params' defined in Section 16.6 of this document. 1255 More specifically, the 'key' parameter is composed as follows. 1257 - The 'hkdf' parameter, if present, specifies the HKDF Algorithm 1258 used in the OSCORE group. The HKDF Algorithm is specified by 1259 the HMAC Algorithm value. This parameter MAY be omitted, if 1260 the HKDF Algorithm used in the group is HKDF SHA-256. 1261 Otherwise, this parameter MUST be present. 1263 - The 'salt' parameter, if present, has as value the OSCORE 1264 Master Salt used in the OSCORE group. This parameter MAY be 1265 omitted, if the Master Salt used in the group is the empty byte 1266 string. Otherwise, this parameter MUST be present. 1268 - The 'ms' parameter includes the OSCORE Master Secret value used 1269 in the OSCORE group. This parameter MUST be present. 1271 - The 'contextId' parameter has as value the Group Identifier 1272 (Gid), i.e., the OSCORE ID Context of the OSCORE group. This 1273 parameter MUST be present. 1275 - The 'group_senderId' parameter has as value the OSCORE Sender 1276 ID assigned to the joining node by the Group Manager, as 1277 described above. This parameter MUST be present if and only if 1278 the node does not join the OSCORE group exclusively with the 1279 role of monitor, according to what is specified in the Access 1280 Token (see Section 5.2). 1282 - The 'cred_fmt' parameter specifies the format of authentication 1283 credentials used in the OSCORE group. This parameter MUST be 1284 present and it takes value from the "Label" column of the "COSE 1285 Header Parameters" registry [COSE.Header.Parameters] (REQ6). 1286 Consistently with Section 2.3 of 1287 [I-D.ietf-core-oscore-groupcomm], acceptable values denote a 1288 format that MUST explicitly provide the public key as well as 1289 the comprehensive set of information related to the public key 1290 algorithm, including, e.g., the used elliptic curve (when 1291 applicable). 1293 At the time of writing this specification, acceptable formats 1294 of authentication credentials are CBOR Web Tokens (CWTs) and 1295 CWT Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC7925] 1296 and C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. 1297 Further formats may be available in the future, and would be 1298 acceptable to use as long as they comply with the criteria 1299 defined above. 1301 [ As to CWTs and CCSs, the COSE Header Parameters 'kcwt' and 1302 'kccs' are under pending registration requested by draft-ietf- 1303 lake-edhoc. ] 1305 [ As to C509 certificates, the COSE Header Parameters 'c5b' and 1306 'c5c' are under pending registration requested by draft-ietf- 1307 cose-cbor-encoded-cert. ] 1309 The 'key' parameter MUST also include the following parameters, if 1310 and only if the OSCORE group is not a pairwise-only group. 1312 - The 'sign_enc_alg' parameter, specifying the Signature 1313 Encryption Algorithm used in the OSCORE group to encrypt 1314 messages protected with the group mode. This parameter takes 1315 values from the "Value" column of the "COSE Algorithms" 1316 registry [COSE.Algorithms]. 1318 - The 'sign_alg' parameter, specifying the Signature Algorithm 1319 used to sign messages in the OSCORE group. This parameter 1320 takes values from the "Value" column of the "COSE Algorithms" 1321 registry [COSE.Algorithms]. 1323 - The 'sign_params' parameter, specifying the parameters of the 1324 Signature Algorithm. This parameter is a CBOR array, which 1325 includes the following two elements: 1327 o 'sign_alg_capab': a CBOR array, with the same format and 1328 value of the COSE capabilities array for the Signature 1329 Algorithm indicated in 'sign_alg', as specified for that 1330 algorithm in the "Capabilities" column of the "COSE 1331 Algorithms" registry [COSE.Algorithms]. 1333 o 'sign_key_type_capab': a CBOR array, with the same format 1334 and value of the COSE capabilities array for the COSE key 1335 type of the keys used with the Signature Algorithm indicated 1336 in 'sign_alg', as specified for that key type in the 1337 "Capabilities" column of the "COSE Key Types" registry 1338 [COSE.Key.Types]. 1340 The 'key' parameter MUST also include the following parameters, if 1341 and only if the OSCORE group is not a signature-only group. 1343 - The 'alg' parameter, specifying the AEAD Algorithm used in the 1344 OSCORE group to encrypt messages protected with the pairwise 1345 mode. 1347 - The 'ecdh_alg' parameter, specifying the Pairwise Key Agreement 1348 Algorithm used in the OSCORE group. This parameter takes 1349 values from the "Value" column of the "COSE Algorithms" 1350 registry [COSE.Algorithms]. 1352 - The 'ecdh_params' parameter, specifying the parameters of the 1353 Pairwise Key Agreement Algorithm. This parameter is a CBOR 1354 array, which includes the following two elements: 1356 o 'ecdh_alg_capab': a CBOR array, with the same format and 1357 value of the COSE capabilities array for the algorithm 1358 indicated in 'ecdh_alg', as specified for that algorithm in 1359 the "Capabilities" column of the "COSE Algorithms" registry 1360 [COSE.Algorithms]. 1362 o 'ecdh_key_type_capab': a CBOR array, with the same format 1363 and value of the COSE capabilities array for the COSE key 1364 type of the keys used with the algorithm indicated in 1365 'ecdh_alg', as specified for that key type in the 1366 "Capabilities" column of the "COSE Key Types" registry 1367 [COSE.Key.Types]. 1369 The format of 'key' defined above is consistent with every 1370 signature algorithm and ECDH algorithm currently considered in 1371 [I-D.ietf-cose-rfc8152bis-algs], i.e., with algorithms that have 1372 only the COSE key type as their COSE capability. Appendix B of 1373 this document describes how the format of the 'key' parameter can 1374 be generalized for possible future registered algorithms having a 1375 different set of COSE capabilities. 1377 Furthermore, the following applies. 1379 * The 'exp' parameter MUST be present. 1381 * The 'ace-groupcomm-profile' parameter MUST be present and has 1382 value coap_group_oscore_app (PROFILE_TBD), which is defined in 1383 Section 16.5 of this document. 1385 * The 'pub_keys' parameter, if present, includes the authentication 1386 credentials requested by the joining node by means of the 1387 'get_pub_keys' parameter in the Joining Request. 1389 If the joining node has asked for the authentication credentials 1390 of all the group members, i.e., 'get_pub_keys' had value the CBOR 1391 simple value "null" (0xf6) in the Joining Request, then the Group 1392 Manager provides only the authentication credentials of the group 1393 members that are relevant to the joining node. That is, in such a 1394 case, 'pub_keys' includes only: i) the authentication credentials 1395 of the responders currently in the OSCORE group, in case the 1396 joining node is configured (also) as requester; and ii) the 1397 authentication credentials of the requesters currently in the 1398 OSCORE group, in case the joining node is configured (also) as 1399 responder or monitor. 1401 * The 'peer_identifiers' parameter includes the OSCORE Sender ID of 1402 each group member whose authentication credential is specified in 1403 the 'pub_keys' parameter. That is, a group member's Sender ID is 1404 used as identifier for that group member (REQ25). 1406 * The 'group_policies' parameter SHOULD be present, and SHOULD 1407 include the following elements: 1409 - "Key Update Check Interval" defined in Section 4.3.1 of 1410 [I-D.ietf-ace-key-groupcomm], with default value 3600; 1412 - "Expiration Delta" defined in Section 4.3.1 of 1413 [I-D.ietf-ace-key-groupcomm], with default value 0. 1415 * The 'kdc_cred' parameter MUST be present, specifying the Group 1416 Manager's authentication credential in its original binary 1417 representation (REQ8). The Group Manager's authentication 1418 credential MUST be in the format used in the OSCORE group. Also, 1419 the authentication credential as well as the included public key 1420 MUST be compatible with the signature or ECDH algorithm, and 1421 possible associated parameters used in the OSCORE group. 1423 * The 'kdc_nonce' parameter MUST be present, specifying the 1424 dedicated nonce N_KDC generated by the Group Manager. For N_KDC, 1425 it is RECOMMENDED to use a 8-byte long random nonce. 1427 * The 'kdc_cred_verify' parameter MUST be present, specifying the 1428 proof-of-possession (PoP) evidence computed by the Group Manager. 1429 The PoP evidence is computed over the nonce N_KDC, which is 1430 specified in the 'kdc_nonce' parameter and taken as PoP input. 1431 The PoP evidence is computed as defined below (REQ21). 1433 - If the group is not a pairwise-only group, the PoP evidence 1434 MUST be a signature. The Group Manager computes the signature 1435 by using the signature algorithm used in the OSCORE group, as 1436 well as its own private key associated with the authentication 1437 credential specified in the 'kdc_cred' parameter. 1439 - If the group is a pairwise-only group, the PoP evidence MUST be 1440 a MAC computed as follows, by using the HKDF Algorithm HKDF 1441 SHA-256, which consists of composing the HKDF-Extract and HKDF- 1442 Expand steps [RFC5869]. 1444 MAC = HKDF(salt, IKM, info, L) 1446 The input parameters of HKDF are as follows. 1448 o salt takes as value the empty byte string. 1450 o IKM is computed as a cofactor Diffie-Hellman shared secret, 1451 see Section 5.7.1.2 of [NIST-800-56A], using the ECDH 1452 algorithm used in the OSCORE group. The Group Manager uses 1453 its own Diffie-Hellman private key and the Diffie-Hellman 1454 public key of the joining node. For X25519 and X448, the 1455 procedure is described in Section 5 of [RFC7748]. 1457 o info takes as value the PoP input. 1459 o L is equal to 8, i.e., the size of the MAC, in bytes. 1461 * The 'group_rekeying' parameter MAY be omitted, if the Group 1462 Manager uses the "Point-to-Point" group rekeying scheme registered 1463 in Section 11.14 of [I-D.ietf-ace-key-groupcomm] as rekeying 1464 scheme in the OSCORE group (OPT9). Its detailed use for this 1465 profile is defined in Section 11 of this document. In any other 1466 case, the 'group_rekeying' parameter MUST be included. 1468 As a last action, if the Group Manager reassigns Gid values during 1469 the group's lifetime (see Section 3.2.1.1 of 1470 [I-D.ietf-core-oscore-groupcomm]), then the Group Manager MUST store 1471 the Gid specified in the 'contextId' parameter of the 'key' 1472 parameter, as the Birth Gid of the joining node in the joined group 1473 (see Section 3 of [I-D.ietf-core-oscore-groupcomm]). This applies 1474 also in case the joining node is in fact re-joining the group; in 1475 such a case, the newly determined Birth Gid overwrites the one 1476 currently stored. 1478 6.4. Receive the Joining Response 1480 Upon receiving the Joining Response, the joining node retrieves the 1481 Group Manager's authentication credential from the 'kdc_cred' 1482 parameter. The joining node MUST verify the proof-of-possession 1483 (PoP) evidence specified in the 'kdc_cred_verify' parameter of the 1484 Joining Response as defined below (REQ21). 1486 * If the group is not a pairwise-only group, the PoP evidence is a 1487 signature. The joining node verifies it by using the public key 1488 of the Group Manager from the received authentication credential, 1489 as well as the signature algorithm used in the OSCORE group and 1490 possible corresponding parameters. 1492 * If the group is a pairwise-only group, the PoP evidence is a MAC. 1493 The joining node recomputes the MAC through the same process taken 1494 by the Group Manager when computing the value of the 1495 'kdc_cred_verify' parameter (see Section 6.3), with the difference 1496 that the joining node uses its own Diffie-Hellman private key and 1497 the Diffie-Hellman public key of the Group Manager from the 1498 received authentication credential. The verification succeeds if 1499 and only if the recomputed MAC is equal to the MAC conveyed as PoP 1500 evidence in the Joining Response. 1502 In case of failed verification of the PoP evidence, the joining node 1503 MUST stop processing the Joining Response and MAY send a new Joining 1504 Request to the Group Manager (see Section 6.1). 1506 In case of successful verification of the PoP evidence, the joining 1507 node uses the information received in the Joining Response to set up 1508 the Group OSCORE Security Context, as described in Section 2 of 1509 [I-D.ietf-core-oscore-groupcomm]. If the following parameters were 1510 not included in the 'key' parameter of the Joining Response, the 1511 joining node considers the default values specified below, 1512 consistently with Section 3.2 of [RFC8613]. 1514 * Absent the 'hkdf' parameter, the joining node considers HKDF 1515 SHA-256 as HKDF Algorithm to use in the OSCORE group. 1517 * Absent the 'salt' parameter, the joining node considers the empty 1518 byte string as Master Salt to use in the OSCORE group. 1520 * Absent the 'group_rekeying' parameter, the joining node considers 1521 the "Point-to-Point" group rekeying scheme registered in 1522 Section 11.14 of [I-D.ietf-ace-key-groupcomm] as the rekeying 1523 scheme used in the group (OPT9). Its detailed use for this 1524 profile is defined in Section 11 of this document. 1526 In addition, the joining node maintains an association between each 1527 authentication credential retrieved from the 'pub_keys' parameter and 1528 the role(s) that the corresponding group member has in the OSCORE 1529 group. 1531 From then on, the joining node can exchange group messages secured 1532 with Group OSCORE as described in [I-D.ietf-core-oscore-groupcomm]. 1533 When doing so: 1535 * The joining node MUST NOT process an incoming request message, if 1536 protected by a group member whose authentication credential is not 1537 associated with the role "Requester". 1539 * The joining node MUST NOT process an incoming response message, if 1540 protected by a group member whose authentication credential is not 1541 associated with the role "Responder". 1543 * The joining node MUST NOT use the pairwise mode of Group OSCORE to 1544 process messages in the group, if the Joining Response did not 1545 include the 'ecdh_alg' parameter. 1547 If the application requires backward security, the Group Manager MUST 1548 generate updated security parameters and group keying material, and 1549 provide it to the current group members, upon the new node's joining 1550 (see Section 11). In such a case, the joining node is not able to 1551 access secure communication in the OSCORE group occurred prior its 1552 joining. 1554 7. Overview of the Group Rekeying Process 1556 In a number of cases, the Group Manager has to generate new keying 1557 material and distribute it to the group (rekeying), as also discussed 1558 in Section 3.2 of [I-D.ietf-core-oscore-groupcomm]. 1560 To this end the Group Manager MUST support the Group Rekeying Process 1561 described in Section 11 of this document, as an instance of the 1562 "Point-to-Point" rekeying scheme defined in Section 6.1 of 1563 [I-D.ietf-ace-key-groupcomm] and registered in Section 11.14 of 1564 [I-D.ietf-ace-key-groupcomm]. Future documents may define the use of 1565 alternative group rekeying schemes for this application profile, 1566 together with the corresponding rekeying message formats. The 1567 resulting group rekeying process MUST comply with the functional 1568 steps defined in Section 3.2 of [I-D.ietf-core-oscore-groupcomm]. 1570 Upon generating the new group keying material and before starting its 1571 distribution, the Group Manager MUST increment the version number of 1572 the group keying material. When rekeying a group, the Group Manager 1573 MUST preserve the current value of the OSCORE Sender ID of each 1574 member in that group. 1576 The data distributed to a group through a rekeying MUST include: 1578 * The new version number of the group keying material for the group. 1580 * A new Group Identifier (Gid) for the group as introduced in 1581 [I-D.ietf-ace-key-groupcomm], used as ID Context parameter of the 1582 Group OSCORE Common Security Context of that group (see Section 2 1583 of [I-D.ietf-core-oscore-groupcomm]). 1585 Note that the Gid differs from the group name also introduced in 1586 [I-D.ietf-ace-key-groupcomm], which is a plain, stable and 1587 invariant identifier, with no cryptographic relevance and meaning. 1589 * A new value for the Master Secret parameter of the Group OSCORE 1590 Common Security Context of the group (see Section 2 of 1591 [I-D.ietf-core-oscore-groupcomm]). 1593 * A set of stale Sender IDs, which allows each rekeyed node to purge 1594 authentication credentials and Recipient Contexts used in the 1595 group and associated with those Sender IDs. This in turn allows 1596 every group member to rely on stored authentication credentials, 1597 in order to confidently assert the group membership of other 1598 sender nodes, when receiving protected messages in the group (see 1599 Section 3.2 of [I-D.ietf-core-oscore-groupcomm]). More details on 1600 the maintenance of stale Sender IDs are provided in Section 7.1. 1602 Also, the data distributed through a group rekeying MAY include a new 1603 value for the Master Salt parameter of the Group OSCORE Common 1604 Security Context of that group. 1606 The Group Manager MUST rekey the group in the following cases. 1608 * The application requires backward security - In this case, the 1609 group is rekeyed when a node joins the group as a new member. 1610 Therefore, a joining node cannot access communications in the 1611 group prior its joining. 1613 * One or more nodes leave the group - That is, the group is rekeyed 1614 when one or more current members spontaneously request to leave 1615 the group (see Section 9.11), or when the Group Manager forcibly 1616 evicts them from the group, e.g., due to expired or revoked 1617 authorization (see Section 10). Therefore, a leaving node cannot 1618 access communications in the group after its leaving, thus 1619 ensuring forward security in the group. 1621 Due to the set of stale Sender IDs distributed through the 1622 rekeying, this ensures that a node owning the latest group keying 1623 material does not store the authentication credentials of former 1624 group members (see Sections 3.2 and 12.1 of 1625 [I-D.ietf-core-oscore-groupcomm]). 1627 * Extension of group lifetime - That is, the group is rekeyed when 1628 the expiration time for the group keying material approaches or 1629 has passed, if it is appropriate to extend the group operation 1630 beyond that. 1632 The Group Manager MAY rekey the group for other reasons, e.g., 1633 according to an application-specific rekeying period or scheduling. 1635 7.1. Stale OSCORE Sender IDs 1637 Throughout the lifetime of every group, the Group Manager MUST 1638 maintain a collection of stale Sender IDs for that group. 1640 The collection associated with a group MUST include up to N > 1 1641 ordered sets of stale OSCORE Sender IDs. It is up to the application 1642 to specify the value of N, possibly on a per-group basis. 1644 The N-th set includes the Sender IDs that have become "stale" under 1645 the current version V of the group keying material. The (N - 1)-th 1646 set refers to the immediately previous version (V - 1) of the group 1647 keying material, and so on. 1649 In the following cases, the Group Manager MUST add a new element to 1650 the most recent set X, i.e., the set associated with the current 1651 version V of the group keying material. 1653 * When a current group member obtains a new Sender ID, its old 1654 Sender ID is added to X. This happens when the Group Manager 1655 assigns a new Sender ID upon request from the group member (see 1656 Section 9.2), or in case the group member re-joins the group (see 1657 Section 6.1 and Section 6.3), thus also obtaining a new Sender ID. 1659 * When a current group member leaves the group, its current Sender 1660 ID is added to X. This happens when a group member requests to 1661 leave the group (see Section 9.11) or is forcibly evicted from the 1662 group (see Section 10). 1664 The value of N can change throughout the lifetime of the group. If 1665 the new value N' is smaller than N, the Group Manager MUST preserve 1666 the (up to) N' most recent sets in the collection and MUST delete any 1667 possible older set from the collection. 1669 Finally, the Group Manager MUST perform the following actions, when 1670 the group is rekeyed and the group shifts to the next version V' = (V 1671 + 1) of the group keying material. 1673 1. The Group Manager rekeys the group. This includes also 1674 distributing the set of stale Sender IDs X associated with the 1675 old group keying material with version V (see Section 7). 1677 2. After completing the group rekeying, the Group Manager creates a 1678 new empty set X' associated with the new version V' of the newly 1679 established group keying material, i.e., V' = (V + 1). 1681 3. If the current collection of stale Sender IDs has size N, the 1682 Group Manager deletes the oldest set in the collection. 1684 4. The Group Manager adds the new set X' to the collection of stale 1685 Sender IDs, as the most recent set. 1687 8. Interface at the Group Manager 1689 The Group Manager provides the interface defined in Section 4.1 of 1690 [I-D.ietf-ace-key-groupcomm], with the additional sub-resources 1691 defined from Section 8.1 to Section 8.3 of this document. 1693 Furthermore, Section 8.4 provides a summary of the CoAP methods 1694 admitted to access different resources at the Group Manager, for 1695 nodes with different roles in the group or as non members (REQ11). 1697 The GROUPNAME segment of the URI path MUST match with the group name 1698 specified in the scope entry of the Access Token scope (i.e., 'gname' 1699 in Section 3.1 of [I-D.ietf-ace-key-groupcomm]) (REQ7). 1701 The Resource Type (rt=) Link Target Attribute value "core.osc.gm" is 1702 registered in Section 16.11 (REQ10), and can be used to describe 1703 group-membership resources and its sub-resources at a Group Manager, 1704 e.g., by using a link-format document [RFC6690]. 1706 Applications can use this common resource type to discover links to 1707 group-membership resources for joining OSCORE groups, e.g., by using 1708 the approach described in [I-D.tiloca-core-oscore-discovery]. 1710 8.1. ace-group/GROUPNAME/active 1712 This resource implements a GET handler. 1714 8.1.1. GET Handler 1716 The handler expects a GET request. 1718 In addition to what is defined in Section 4.1.2 of 1719 [I-D.ietf-ace-key-groupcomm], the handler verifies that the 1720 requesting Client is a current member of the group. If the 1721 verification fails, the KDC MUST reply with a 4.03 (Forbidden) error 1722 response. The response MUST have Content-Format set to application/ 1723 ace-groupcomm+cbor and is formatted as defined in Section 4.1.2 of 1724 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be 1725 set to 0 ("Operation permitted only to group members"). 1727 If all verifications succeed, the handler replies with a 2.05 1728 (Content) response, specifying the current status of the group, i.e., 1729 active or inactive. The payload of the response is formatted as 1730 defined in Section 9.9. 1732 The method to set the current group status is out of the scope of 1733 this document, and is defined for the administrator interface of the 1734 Group Manager specified in [I-D.ietf-ace-oscore-gm-admin]. 1736 8.2. ace-group/GROUPNAME/verif-data 1738 This resource implements a GET handler. 1740 8.2.1. GET Handler 1742 The handler expects a GET request. 1744 In addition to what is defined in Section 4.1.2 of 1745 [I-D.ietf-ace-key-groupcomm], the Group Manager performs the 1746 following checks. 1748 If the requesting Client is a current group member, the Group Manager 1749 MUST reply with a 4.03 (Forbidden) error response. The response MUST 1750 have Content-Format set to application/ace-groupcomm+cbor and is 1751 formatted as defined in Section 4.1.2 of 1752 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be 1753 set to 8 ("Operation permitted only to signature verifiers"). 1755 If GROUPNAME denotes a pairwise-only group, the Group Manager MUST 1756 reply with a 4.00 (Bad Request) error response. The response MUST 1757 have Content-Format set to application/ace-groupcomm+cbor and is 1758 formatted as defined in Section 4.1.2 of 1759 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be 1760 set to 7 ("Signatures not used in the group"). 1762 If all verifications succeed, the handler replies with a 2.05 1763 (Content) response, specifying data that allow also an external 1764 signature verifier to verify signatures of messages protected with 1765 the group mode and sent to the group (see Sections 3.1 and 8.5 of 1766 [I-D.ietf-core-oscore-groupcomm]). The response MUST have Content- 1767 Format set to application/ace-groupcomm+cbor. The payload of the 1768 response is a CBOR map, which is formatted as defined in Section 9.6. 1770 8.3. ace-group/GROUPNAME/stale-sids 1772 This resource implements a FETCH handler. 1774 8.3.1. FETCH Handler 1776 The handler expects a FETCH request, whose payload specifies a 1777 version number of the group keying material, encoded as an unsigned 1778 CBOR integer. 1780 In addition to what is defined in Section 4.1.2 of 1781 [I-D.ietf-ace-key-groupcomm], the handler verifies that the 1782 requesting Client is a current member of the group. If the 1783 verification fails, the Group Manager MUST reply with a 4.03 1784 (Forbidden) error response. The response MUST have Content-Format 1785 set to application/ace-groupcomm+cbor and is formatted as defined in 1786 Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value of the 1787 'error' field MUST be set to 0 ("Operation permitted only to group 1788 members"). 1790 If all verifications succeed, the handler replies with a 2.05 1791 (Content) response, specifying data that allow the requesting Client 1792 to delete the Recipient Contexts and authentication credentials 1793 associated with former members of the group (see Section 3.2 of 1794 [I-D.ietf-core-oscore-groupcomm]. The payload of the response is 1795 formatted as defined in Section 11.3.1. 1797 8.4. Admitted Methods 1799 The table in Figure 2 summarizes the CoAP methods admitted to access 1800 different resources at the Group Manager, for (non-)members of a 1801 group with group name GROUPNAME, and considering different roles. 1802 The last two rows of the table apply to a node with node name 1803 NODENAME. 1805 +---------------------------------+--------+-------+-------+-------+ 1806 | Resource | Type1 | Type2 | Type3 | Type4 | 1807 +---------------------------------+--------+-------+-------+-------+ 1808 | ace-group/ | F | F | F | F | 1809 +---------------------------------+--------+-------+-------+-------+ 1810 | ace-group/GROUPNAME/ | G Po | G Po | Po * | Po | 1811 +---------------------------------+--------+-------+-------+-------+ 1812 | ace-group/GROUPNAME/active | G | G | - | - | 1813 +---------------------------------+--------+-------+-------+-------+ 1814 | ace-group/GROUPNAME/verif-data | - | - | G | - | 1815 +---------------------------------+--------+-------+-------+-------+ 1816 | ace-group/GROUPNAME/pub-key | G F | G F | G F | - | 1817 +---------------------------------+--------+-------+-------+-------+ 1818 | ace-group/GROUPNAME/kdc-pub-key | G | G | G | - | 1819 +---------------------------------+--------+-------+-------+-------+ 1820 | ace-group/GROUPNAME/stale-sids | F | F | - | - | 1821 +---------------------------------+--------+-------+-------+-------+ 1822 | ace-group/GROUPNAME/policies | G | G | - | - | 1823 +---------------------------------+--------+-------+-------+-------+ 1824 | ace-group/GROUPNAME/num | G | G | - | - | 1825 +---------------------------------+--------+-------+-------+-------+ 1826 | ace-group/GROUPNAME/nodes/ | G Pu D | G D | - | - | 1827 | NODENAME | | | | | 1828 +---------------------------------+--------+-------+-------+-------+ 1829 | ace-group/GROUPNAME/nodes/ | Po | - | - | - | 1830 | NODENAME/pub-key | | | | | 1831 +---------------------------------+--------+-------+-------+-------+ 1833 CoAP methods: G = GET; F = FETCH; Po = POST; Pu = PUT; D = DELETE 1835 Type1 = Member as Requester and/or Responder 1836 Type2 = Member as Monitor 1837 Type3 = Non-member (authorized to be signature verifier) 1838 (*) = cannot join the group as signature verifier 1839 Type4 = Non-member (not authorized to be signature verifier) 1841 Figure 2: Admitted CoAP Methods on the Group Manager Resources 1843 8.4.1. Signature Verifiers 1845 Just like any candidate group member, a signature verifier provides 1846 the Group Manager with an Access Token, as described in Section 5.3. 1847 However, unlike candidate group members, it does not join any OSCORE 1848 group, i.e., it does not perform the joining process defined in 1849 Section 6. 1851 After successfully transferring an Access Token to the Group Manager, 1852 a signature verifier is allowed to perform only some operations as 1853 non-member of a group, and only for the OSCORE groups specified in 1854 the validated Access Token. These are the operations specified in 1855 Section 9.3, Section 9.5, Section 9.6 and Section 9.10. 1857 Consistently, in case a node is not a member of the group with group 1858 name GROUPNAME and is authorized to be only signature verifier for 1859 that group, the Group Manager MUST reply with a 4.03 (Forbidden) 1860 error response if that node attempts to access any other endpoint 1861 than: /ace-group; ace-group/GROUPNAME/verif-data; /ace- 1862 group/GROUPNAME/pub-key; and ace-group/GROUPNAME/kdc-pub-key. 1864 8.5. Operations Supported by Clients 1866 Building on what is defined in Section 4.1.1 of 1867 [I-D.ietf-ace-key-groupcomm], and with reference to the resources at 1868 the Group Manager newly defined earlier in Section 8 of this 1869 document, it is expected that a Client minimally supports also the 1870 following set of operations and corresponding interactions with the 1871 Group Manager (REQ12). 1873 * GET request to ace-group/GROUPNAME/active, in order to check the 1874 current status of the group. 1876 * GET request to ace-group/GROUPNAME/verif-data, in order for a 1877 signature verifier to retrieve data required to verify signatures 1878 of messages protected with the group mode of Group OSCORE and sent 1879 to a group (see Sections 3.1 and 8.5 of 1880 [I-D.ietf-core-oscore-groupcomm]). Note that this operation is 1881 relevant to support only to signature verifiers. 1883 * FETCH request to ace-group/GROUPNAME/stale-sids, in order to 1884 retrieve from the Group Manager the data required to delete some 1885 of the stored group members' authentication credentials and 1886 associated Recipient Contexts (see Section 8.3.1). These data are 1887 provided as an aggregated set of stale Sender IDs, which are used 1888 as specified in Section 11.3. 1890 9. Additional Interactions with the Group Manager 1892 This section defines the possible interactions with the Group 1893 Manager, in addition to the group joining specified in Section 6. 1895 9.1. Retrieve Updated Keying Material 1897 At some point, a group member considers the Group OSCORE Security 1898 Context invalid and to be renewed. This happens, for instance, after 1899 a number of unsuccessful security processing of incoming messages 1900 from other group members, or when the Security Context expires as 1901 specified by the 'exp' parameter of the Joining Response. 1903 When this happens, the group member retrieves updated security 1904 parameters and group keying material. This can occur in the two 1905 different ways described below. 1907 9.1.1. Get Group Keying Material 1909 If the group member wants to retrieve only the latest group keying 1910 material, it sends a Key Distribution Request to the Group Manager. 1912 In particular, it sends a CoAP GET request to the endpoint /ace- 1913 group/GROUPNAME at the Group Manager. 1915 The Group Manager processes the Key Distribution Request according to 1916 Section 4.3.2 of [I-D.ietf-ace-key-groupcomm]. The Key Distribution 1917 Response is formatted as defined in Section 4.3.2 of 1918 [I-D.ietf-ace-key-groupcomm], with the following additions. 1920 * The 'key' parameter is formatted as defined in Section 6.3 of this 1921 document, with the difference that it does not include the 1922 'group_SenderId' parameter. 1924 * The 'exp' parameter MUST be present. 1926 * The 'ace-groupcomm-profile' parameter MUST be present and has 1927 value coap_group_oscore_app. 1929 Upon receiving the Key Distribution Response, the group member 1930 retrieves the updated security parameters and group keying material, 1931 and, if they differ from the current ones, uses them to set up the 1932 new Group OSCORE Security Context as described in Section 2 of 1933 [I-D.ietf-core-oscore-groupcomm]. 1935 9.1.2. Get Group Keying Material and OSCORE Sender ID 1937 If the group member wants to retrieve the latest group keying 1938 material as well as the OSCORE Sender ID that it has in the OSCORE 1939 group, it sends a Key Distribution Request to the Group Manager. 1941 In particular, it sends a CoAP GET request to the endpoint /ace- 1942 group/GROUPNAME/nodes/NODENAME at the Group Manager. 1944 The Group Manager processes the Key Distribution Request according to 1945 Section 4.8.1 of [I-D.ietf-ace-key-groupcomm]. The Key Distribution 1946 Response is formatted as defined in Section 4.8.1 of 1947 [I-D.ietf-ace-key-groupcomm], with the following additions. 1949 * The 'key' parameter is formatted as defined in Section 6.3 of this 1950 document. In particular, if the requesting group member has 1951 exclusively the role of monitor, then the 'key' parameter does not 1952 include the 'group_SenderId'. 1954 Note that, in any other case, the current Sender ID of the group 1955 member is not specified as a separate parameter, but rather 1956 specified by 'group_SenderId' within the 'key' parameter. 1958 * The 'exp' parameter MUST be present. 1960 Upon receiving the Key Distribution Response, the group member 1961 retrieves the updated security parameters, group keying material and 1962 Sender ID, and, if they differ from the current ones, uses them to 1963 set up the new Group OSCORE Security Context as described in 1964 Section 2 of [I-D.ietf-core-oscore-groupcomm]. 1966 9.2. Request to Change Individual Keying Material 1968 As discussed in Section 2.5.2 of [I-D.ietf-core-oscore-groupcomm], a 1969 group member may at some point exhaust its Sender Sequence Numbers in 1970 the OSCORE group. 1972 When this happens, the group member MUST send a Key Renewal Request 1973 message to the Group Manager, as per Section 4.8.2.1 of 1974 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP PUT 1975 request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME at the 1976 Group Manager. 1978 Upon receiving the Key Renewal Request, the Group Manager processes 1979 it as defined in Section 4.8.2 of [I-D.ietf-ace-key-groupcomm], with 1980 the following additions. 1982 The Group Manager MUST return a 5.03 (Service Unavailable) response 1983 in case the OSCORE group identified by GROUPNAME is currently 1984 inactive (see Section 8.1). The response MUST have Content-Format 1985 set to application/ace-groupcomm+cbor and is formatted as defined in 1986 Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value of the 1987 'error' field MUST be set to 9 ("Group currently not active"). 1989 Otherwise, the Group Manager performs one of the following actions. 1991 1. If the requesting group member has exclusively the role of 1992 monitor, the Group Manager replies with a 4.03 (Forbidden) error 1993 response. The response MUST have Content-Format set to 1994 application/ace-groupcomm+cbor and is formatted as defined in 1995 Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value of the 1996 'error' field MUST be set to 1 ("Request inconsistent with the 1997 current roles"). 1999 2. Otherwise, the Group Manager takes one of the following actions. 2001 * The Group Manager rekeys the OSCORE group. That is, the Group 2002 Manager generates new group keying material for that group 2003 (see Section 11), and replies to the group member with a group 2004 rekeying message as defined in Section 11, providing the new 2005 group keying material. Then, the Group Manager rekeys the 2006 rest of the OSCORE group, as discussed in Section 11. 2008 The Group Manager SHOULD perform a group rekeying only if 2009 already scheduled to occur shortly, e.g., according to an 2010 application-specific rekeying period or scheduling, or as a 2011 reaction to a recent change in the group membership. In any 2012 other case, the Group Manager SHOULD NOT rekey the OSCORE 2013 group when receiving a Key Renewal Request (OPT12). 2015 * The Group Manager determines and assigns a new OSCORE Sender 2016 ID for that group member, and replies with a Key Renewal 2017 Response formatted as defined in Section 4.8.2 of 2018 [I-D.ietf-ace-key-groupcomm]. In particular, the CBOR Map in 2019 the response payload includes a single parameter 2020 'group_SenderId' defined in Section 16.3 of this document, 2021 specifying the new Sender ID of the group member encoded as a 2022 CBOR byte string. 2024 Consistently with Section 2.5.3.1 of 2025 [I-D.ietf-core-oscore-groupcomm], the Group Manager MUST 2026 assign a new Sender ID that has not been used in the OSCORE 2027 group since the latest time when the current Gid value was 2028 assigned to the group. 2030 Furthermore, the Group Manager MUST add the old, relinquished 2031 Sender ID of the group member to the most recent set of stale 2032 Sender IDs, in the collection associated with the group (see 2033 Section 7.1). 2035 The Group Manager MUST return a 5.03 (Service Unavailable) 2036 response in case there are currently no Sender IDs available 2037 to assign in the OSCORE group. The response MUST have 2038 Content-Format set to application/ace-groupcomm+cbor and is 2039 formatted as defined in Section 4.1.2 of 2040 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field 2041 MUST be set to 4 ("No available node identifiers"). 2043 9.3. Retrieve Authentication Credentials of Group Members 2045 A group member or a signature verifier may need to retrieve the 2046 authentication credentials of (other) group members. To this end, 2047 the group member or signature verifier sends a Public Key Request 2048 message to the Group Manager, as per Sections 4.4.1.1 and 4.4.2.1 of 2049 [I-D.ietf-ace-key-groupcomm]. In particular, it sends the request to 2050 the endpoint /ace-group/GROUPNAME/pub-key at the Group Manager. 2052 If the Public Key Request uses the method FETCH, the Public Key 2053 Request is formatted as defined in Section 4.4.1 of 2054 [I-D.ietf-ace-key-groupcomm]. In particular: 2056 * Each element (if any) of the inner CBOR array 'role_filter' is 2057 formatted as in the inner CBOR array 'role_filter' of the 2058 'get_pub_keys' parameter of the Joining Request when the parameter 2059 value is not the CBOR simple value "null" (0xf6) (see 2060 Section 6.1). 2062 * Each element (if any) of the inner CBOR array 'id_filter' is a 2063 CBOR byte string, which encodes the OSCORE Sender ID of the group 2064 member for which the associated authentication credential is 2065 requested (REQ25). 2067 Upon receiving the Public Key Request, the Group Manager processes it 2068 as per Section 4.4.1 or Section 4.4.2 of 2069 [I-D.ietf-ace-key-groupcomm], depending on the request method being 2070 FETCH or GET, respectively. Additionally, if the Public Key Request 2071 uses the method FETCH, the Group Manager silently ignores node 2072 identifiers included in the 'get_pub_keys' parameter of the request 2073 that are not associated with any current group member (REQ26). 2075 The success Public Key Response is formatted as defined in 2076 Section 4.4.1 or Section 4.4.2 of [I-D.ietf-ace-key-groupcomm], 2077 depending on the request method being FETCH or GET, respectively. 2079 9.4. Upload a New Authentication Credential 2081 A group member may need to provide the Group Manager with its new 2082 authentication credential to use in the group from then on, hence 2083 replacing the current one. This can be the case, for instance, if 2084 the signature or ECDH algorithm and possible associated parameters 2085 used in the OSCORE group have been changed, and the current 2086 authentication credential is not compatible with them. 2088 To this end, the group member sends a Public Key Update Request 2089 message to the Group Manager, as per Section 4.9.1.1 of 2090 [I-D.ietf-ace-key-groupcomm], with the following addition. 2092 * The group member computes the proof-of-possession (PoP) evidence 2093 included in 'client_cred_verify' in the same way taken when 2094 preparing a Joining Request for the OSCORE group in question, as 2095 defined in Section 6.1 (REQ14). 2097 In particular, the group member sends a CoAP POST request to the 2098 endpoint /ace-group/GROUPNAME/nodes/NODENAME/pub-key at the Group 2099 Manager. 2101 Upon receiving the Public Key Update Request, the Group Manager 2102 processes it as per Section 4.9.1 of [I-D.ietf-ace-key-groupcomm], 2103 with the following additions. 2105 * The N_S challenge used to build the proof-of-possession input is 2106 computed as defined in Section 6.1.1 (REQ15). 2108 * The Group Manager verifies the PoP challenge included in 2109 'client_cred_verify' in the same way taken when processing a 2110 Joining Request for the OSCORE group in question, as defined in 2111 Section 6.2 (REQ14). 2113 * The Group Manager MUST return a 5.03 (Service Unavailable) 2114 response in case the OSCORE group identified by GROUPNAME is 2115 currently inactive (see Section 8.1). The response MUST have 2116 Content-Format set to application/ace-groupcomm+cbor and is 2117 formatted as defined in Section 4.1.2 of 2118 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST 2119 be set to 9 ("Group currently not active"). 2121 * If the requesting group member has exclusively the role of 2122 monitor, the Group Manager replies with a 4.00 (Bad request) error 2123 response. The response MUST have Content-Format set to 2124 application/ace-groupcomm+cbor and is formatted as defined in 2125 Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value of the 2126 'error' field MUST be set to 1 ("Request inconsistent with the 2127 current roles"). 2129 * If the request is successfully processed, the Group Manager stores 2130 the association between i) the new authentication credential of 2131 the group member; and ii) the Group Identifier (Gid), i.e., the 2132 OSCORE ID Context, associated with the OSCORE group together with 2133 the OSCORE Sender ID assigned to the group member in the group. 2134 The Group Manager MUST keep this association updated over time. 2136 9.5. Retrieve the Group Manager's Authentication Credential 2138 A group member or a signature verifier may need to retrieve the 2139 authentication credential of the Group Manager. To this end, the 2140 requesting Client sends a KDC Public Key Request message to the Group 2141 Manager. 2143 In particular, it sends a CoAP GET request to the endpoint /ace- 2144 group/GROUPNAME/kdc-pub-key at the Group Manager defined in 2145 Section 4.5.1.1 of [I-D.ietf-ace-key-groupcomm], where GROUPNAME is 2146 the name of the OSCORE group. 2148 In addition to what is defined in Section 4.5.1 of 2149 [I-D.ietf-ace-key-groupcomm], the Group Manager MUST respond with a 2150 4.00 (Bad Request) error response, if the requesting Client is not a 2151 current group member and GROUPNAME denotes a pairwise-only group. 2152 The response MUST have Content-Format set to application/ace- 2153 groupcomm+cbor and is formatted as defined in Section 4.1.2 of 2154 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be 2155 set to 7 ("Signatures not used in the group"). 2157 The payload of the 2.05 (Content) KDC Public Key Response is a CBOR 2158 map, which is formatted as defined in Section 4.5.1 of 2159 [I-D.ietf-ace-key-groupcomm]. In particular, the Group Manager 2160 specifies the parameters 'kdc_cred', 'kdc_nonce' and 'kdc_challenge' 2161 as defined for the Joining Response in Section 6.3 of this document. 2162 This especially applies to the computing of the proof-of-possession 2163 (PoP) evidence included in 'kdc_cred_verify' (REQ21). 2165 Upon receiving a 2.05 (Content) KDC Public Key Response, the 2166 requesting Client retrieves the Group Manager's authentication 2167 credential from the 'kdc_cred' parameter, and proceeds as defined in 2168 Section 4.5.1.1 of [I-D.ietf-ace-key-groupcomm]. In particular, the 2169 requesting Client verifies the PoP evidence included in 2170 'kdc_cred_verify' by means of the same method used when processing 2171 the Joining Response, as defined in Section 6.3 of this document 2172 (REQ21). 2174 Note that a signature verifier would not receive a successful 2175 response from the Group Manager, in case GROUPNAME denotes a 2176 pairwise-only group. 2178 9.6. Retrieve Signature Verification Data 2180 A signature verifier may need to retrieve data required to verify 2181 signatures of messages protected with the group mode and sent to a 2182 group (see Sections 3.1 and 8.5 of [I-D.ietf-core-oscore-groupcomm]). 2183 To this end, the signature verifier sends a Signature Verification 2184 Data Request message to the Group Manager. 2186 In particular, it sends a CoAP GET request to the endpoint /ace- 2187 group/GROUPNAME/verif-data at the Group Manager defined in 2188 Section 8.2 of this document, where GROUPNAME is the name of the 2189 OSCORE group. 2191 The payload of the 2.05 (Content) Signature Verification Data 2192 Response is a CBOR map, which has the format used for the Joining 2193 Response message in Section 6.3, with the following differences. 2195 * From the Joining Response message, only the parameters 'gkty', 2196 'key', 'num', 'exp' and 'ace-groupcomm-profile' are present. In 2197 particular, the 'key' parameter includes only the following data. 2199 - The parameters 'hkdf', 'contextId', 'cred_fmt', 'sign_enc_alg', 2200 'sign_alg', 'sign_params'. These parameters MUST be present. 2202 - The parameters 'alg' and 'ecdh_alg'. These parameter MUST NOT 2203 be present if the group is a signature-only group. Otherwise, 2204 they MUST be present. 2206 * The parameter 'group_enc_key' is also included, with CBOR label 2207 defined in Section 16.3. This parameter specifies the Group 2208 Encryption Key of the OSCORE Group, encoded as a CBOR byte string. 2209 The Group Manager derives the Group Encryption Key from the group 2210 keying material, as per Section 2.1.6 of 2211 [I-D.ietf-core-oscore-groupcomm]. This parameter MUST be present. 2213 In order to verify signatures in the group (see Section 8.5 of 2214 [I-D.ietf-core-oscore-groupcomm]), the signature verifier relies on: 2215 the data retrieved from the 2.05 (Content) Signature Verification 2216 Data Response; the public keys of the group members signing the 2217 messages to verify, retrieved from those members' authentication 2218 credentials that can be obtained as defined in Section 9.3; and the 2219 public key of the Group Manager, retrieved from the Group Manager's 2220 authentication credential that can be obtained as defined in 2221 Section 9.5. 2223 Figure 3 gives an overview of the exchange described above, while 2224 Figure 4 shows an example. 2226 Signature Group 2227 Verifier Manager 2228 | | 2229 | Signature Verification Data Request | 2230 |------------------------------------------------------------>| 2231 | GET ace-group/GROUPNAME/verif-data | 2232 | | 2233 |<--- Signature Verification Data Response: 2.05 (Content) ---| 2234 | | 2236 Figure 3: Message Flow of Signature Verification Data Request- 2237 Response 2239 Request: 2241 Header: GET (Code=0.01) 2242 Uri-Host: "kdc.example.com" 2243 Uri-Path: "ace-group" 2244 Uri-Path: "g1" 2245 Uri-Path: "verif-data" 2246 Payload: - 2248 Response: 2250 Header: Content (Code=2.05) 2251 Content-Format: "application/ace-groupcomm+cbor" 2252 Payload (in CBOR diagnostic notation, with GROUPCOMM_KEY_TBD 2253 and PROFILE_TBD being CBOR integers, while GROUP_ENC_KEY 2254 being a CBOR byte string): 2255 { 2256 "gkty": GROUPCOMM_KEY_TBD, 2257 "key": { 2258 'hkdf': 5, ; HMAC 256/256 2259 'contextId': h'37fc', 2260 'cred_fmt': 33, ; x5chain 2261 'sign_enc_alg': 10, ; AES-CCM-16-64-128 2262 'sign_alg': -8, ; EdDSA 2263 'sign_params': [[1], [1, 6]] ; [[OKP], [OKP, Ed25519]] 2264 }, 2265 "num": 12, 2266 "exp": 1609459200, 2267 "ace_groupcomm_profile": PROFILE_TBD, 2268 "group_enc_key": GROUP_ENC_KEY 2269 } 2271 Figure 4: Example of Signature Verification Data Request-Response 2273 9.7. Retrieve the Group Policies 2275 A group member may request the current policies used in the OSCORE 2276 group. To this end, the group member sends a Policies Request, as 2277 per Section 4.6.1.1 of [I-D.ietf-ace-key-groupcomm]. In particular, 2278 it sends a CoAP GET request to the endpoint /ace-group/GROUPNAME/ 2279 policies at the Group Manager, where GROUPNAME is the name of the 2280 OSCORE group. 2282 Upon receiving the Policies Request, the Group Manager processes it 2283 as per Section 4.6.1 of [I-D.ietf-ace-key-groupcomm]. The success 2284 Policies Response is formatted as defined in Section 4.6.1 of 2285 [I-D.ietf-ace-key-groupcomm]. 2287 9.8. Retrieve the Keying Material Version 2289 A group member may request the current version of the keying material 2290 used in the OSCORE group. To this end, the group member sends a 2291 Version Request, as per Section 4.7.1.1 of 2292 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP GET 2293 request to the endpoint /ace-group/GROUPNAME/num at the Group 2294 Manager, where GROUPNAME is the name of the OSCORE group. 2296 Upon receiving the Version Request, the Group Manager processes it as 2297 per Section 4.7.1 of [I-D.ietf-ace-key-groupcomm]. The success 2298 Version Response is formatted as defined in Section 4.7.1 of 2299 [I-D.ietf-ace-key-groupcomm]. 2301 9.9. Retrieve the Group Status 2303 A group member may request the current status of the the OSCORE 2304 group, i.e., active or inactive. To this end, the group member sends 2305 a Group Status Request to the Group Manager. 2307 In particular, the group member sends a CoAP GET request to the 2308 endpoint /ace-group/GROUPNAME/active at the Group Manager defined in 2309 Section 8.1 of this document, where GROUPNAME is the name of the 2310 OSCORE group. 2312 The payload of the 2.05 (Content) Group Status Response includes the 2313 CBOR simple value "true" (0xf5) if the group is currently active, or 2314 the CBOR simple value "false" (0xf4) otherwise. The group is 2315 considered active if it is set to allow new members to join, and if 2316 communication within the group is fine to happen. 2318 Upon learning from a 2.05 (Content) response that the group is 2319 currently inactive, the group member SHOULD stop taking part in 2320 communications within the group, until it becomes active again. 2322 Upon learning from a 2.05 (Content) response that the group has 2323 become active again, the group member can resume taking part in 2324 communications within the group. 2326 Figure 5 gives an overview of the exchange described above, while 2327 Figure 6 shows an example. 2329 Group Group 2330 Member Manager 2331 | | 2332 |--- Group Status Request: GET ace-group/GROUPNAME/active --->| 2333 | | 2334 |<---------- Group Status Response: 2.05 (Content) -----------| 2335 | | 2337 Figure 5: Message Flow of Group Status Request-Response 2339 Request: 2341 Header: GET (Code=0.01) 2342 Uri-Host: "kdc.example.com" 2343 Uri-Path: "ace-group" 2344 Uri-Path: "g1" 2345 Uri-Path: "active" 2346 Payload: - 2348 Response: 2350 Header: Content (Code=2.05) 2351 Payload (in CBOR diagnostic notation): 2352 true 2354 Figure 6: Example of Group Status Request-Response 2356 9.10. Retrieve Group Names 2358 A node may want to retrieve from the Group Manager the group name and 2359 the URI of the group-membership resource of a group. This is 2360 relevant in the following cases. 2362 * Before joining a group, a joining node may know only the current 2363 Group Identifier (Gid) of that group, but not the group name and 2364 the URI to the group-membership resource. 2366 * As current group member in several groups, the node has missed a 2367 previous group rekeying in one of them (see Section 11). Hence, 2368 it retains stale keying material and fails to decrypt received 2369 messages exchanged in that group. 2371 Such messages do not provide a direct hint to the correct group 2372 name, that the node would need in order to retrieve the latest 2373 keying material and authentication credentials from the Group 2374 Manager (see Section 9.1.1, Section 9.1.2 and Section 9.3). 2375 However, such messages may specify the current Gid of the group, 2376 as value of the 'kid_context' field of the OSCORE CoAP option (see 2377 Section 6.1 of [RFC8613] and Section 4.2 of 2378 [I-D.ietf-core-oscore-groupcomm]). 2380 * As signature verifier, the node also refers to a group name for 2381 retrieving the required authentication credentials from the Group 2382 Manager (see Section 9.3). As discussed above, intercepted 2383 messages do not provide a direct hint to the correct group name, 2384 while they may specify the current Gid of the group, as value of 2385 the 'kid_context' field of the OSCORE CoAP option. In such a 2386 case, upon intercepting a message in the group, the node requires 2387 to correctly map the Gid currently used in the group with the 2388 invariant group name. 2390 Furthermore, since it is not a group member, the node does not 2391 take part to a possible group rekeying. Thus, following a group 2392 rekeying and the consequent change of Gid in a group, the node 2393 would retain the old Gid value and cannot correctly associate 2394 intercepted messages to the right group, especially if acting as 2395 signature verifier in several groups. This in turn prevents the 2396 efficient verification of signatures, and especially the retrieval 2397 of required, new authentication credentials from the Group 2398 Manager. 2400 In either case, the node only knows the current Gid of the group, as 2401 learned from received or intercepted messages exchanged in the group. 2402 As detailed below, the node can contact the Group Manager, and 2403 request the group name and URI to the group-membership resource 2404 corresponding to that Gid. Then, it can use that information to 2405 either join the group as a candidate group member, get the latest 2406 keying material as a current group member, or retrieve authentication 2407 credentials used in the group as a signature verifier. To this end, 2408 the node sends a Group Name and URI Retrieval Request, as per 2409 Section 4.2.1.1 of [I-D.ietf-ace-key-groupcomm]. 2411 In particular, the node sends a CoAP FETCH request to the endpoint 2412 /ace-group at the Group Manager formatted as defined in Section 4.2.1 2413 of [I-D.ietf-ace-key-groupcomm]. Each element of the CBOR array 2414 'gid' is a CBOR byte string (REQ13), which encodes the Gid of the 2415 group for which the group name and the URI to the group-membership 2416 resource are requested. 2418 Upon receiving the Group Name and URI Retrieval Request, the Group 2419 Manager processes it as per Section 4.2.1 of 2420 [I-D.ietf-ace-key-groupcomm]. The success Group Name and URI 2421 Retrieval Response is formatted as defined in Section 4.2.1 of 2422 [I-D.ietf-ace-key-groupcomm]. In particular, each element of the 2423 CBOR array 'gid' is a CBOR byte string (REQ13), which encodes the Gid 2424 of the group for which the group name and the URI to the group- 2425 membership resource are provided. 2427 For each of its groups, the Group Manager maintains an association 2428 between the group name and the URI to the group-membership resource 2429 on one hand, and only the current Gid for that group on the other 2430 hand. That is, the Group Manager does not maintain an association 2431 between the former pair and any other Gid for that group than the 2432 current, most recent one. 2434 Figure 7 gives an overview of the exchanges described above, while 2435 Figure 8 shows an example. 2437 Group 2438 Node Manager 2439 | | 2440 |---- Group Name and URI Retrieval Request: FETCH ace-group/ --->| 2441 | | 2442 |<--- Group Name and URI Retrieval Response: 2.05 (Content) -----| 2443 | | 2445 Figure 7: Message Flow of Group Name and URI Retrieval Request- 2446 Response 2448 Request: 2450 Header: FETCH (Code=0.05) 2451 Uri-Host: "kdc.example.com" 2452 Uri-Path: "ace-group" 2453 Content-Format: "application/ace-groupcomm+cbor" 2454 Payload (in CBOR diagnostic notation): 2455 { 2456 "gid": [h'37fc', h'84bd'] 2457 } 2459 Response: 2461 Header: Content (Code=2.05) 2462 Content-Format: "application/ace-groupcomm+cbor" 2463 Payload (in CBOR diagnostic notation): 2464 { 2465 "gid": [h'37fc', h'84bd'], 2466 "gname": ["g1", "g2"], 2467 "guri": ["ace-group/g1", "ace-group/g2"] 2468 } 2470 Figure 8: Example of Group Name and URI Retrieval Request-Response 2472 9.11. Leave the Group 2474 A group member may request to leave the OSCORE group. To this end, 2475 the group member sends a Group Leaving Request, as per 2476 Section 4.8.3.1 of [I-D.ietf-ace-key-groupcomm]. In particular, it 2477 sends a CoAP DELETE request to the endpoint /ace- 2478 group/GROUPNAME/nodes/NODENAME at the Group Manager. 2480 Upon receiving the Group Leaving Request, the Group Manager processes 2481 it as per Section 4.8.3 of [I-D.ietf-ace-key-groupcomm]. Then, the 2482 Group Manager performs the follow-up actions defined in Section 10 of 2483 this document. 2485 10. Removal of a Group Member 2487 Other than after a spontaneous request to the Group Manager as 2488 described in Section 9.11, a node may be forcibly removed from the 2489 OSCORE group, e.g., due to expired or revoked authorization. 2491 In either case, if the Group Manager reassigns Gid values during the 2492 group's lifetime (see Section 3.2.1.1 of 2493 [I-D.ietf-core-oscore-groupcomm]), the Group Manager "forgets" the 2494 Birth Gid currently associated with the leaving node in the OSCORE 2495 group. This was stored following the Joining Response sent to that 2496 node, after its latest (re-)joining of the OSCORE group (see 2497 Section 6.3). 2499 If any of the two conditions below holds, the Group Manager MUST 2500 inform the leaving node of its eviction as follows. If both 2501 conditions hold, the Group Manager MUST inform the leaving node by 2502 using only the method corresponding to one of either conditions. 2504 * If, upon joining the group (see Section 6.1), the leaving node 2505 specified a URI in the 'control_uri' parameter defined in 2506 Section 4.3.1 of [I-D.ietf-ace-key-groupcomm], the Group Manager 2507 sends a DELETE request targeting the URI specified in the 2508 'control_uri' parameter (OPT7). 2510 * If the leaving node has been observing the associated resource at 2511 ace-group/GROUPNAME/nodes/NODENAME, the Group Manager sends an 2512 unsolicited 4.04 (Not Found) error response to the leaving node, 2513 as specified in Section 4.3.2 of [I-D.ietf-ace-key-groupcomm]. 2515 Furthermore, the Group Manager might intend to evict all the current 2516 group members from the group at once. In such a case, if the Joining 2517 Responses sent by the Group Manager to nodes joining the group (see 2518 Section 6.3) specify a URI in the 'control_group_uri' parameter 2519 defined in Section 4.3.1 of [I-D.ietf-ace-key-groupcomm], then the 2520 Group Manager MUST additionally send a DELETE request targeting the 2521 URI specified in the 'control_group_uri' parameter (OPT10). 2523 If the leaving node has not exclusively the role of monitor, the 2524 Group Manager performs the following actions. 2526 * The Group Manager frees the OSCORE Sender ID value of the leaving 2527 node. This value MUST NOT become available for possible upcoming 2528 joining nodes in the same group, until the group has been rekeyed 2529 and assigned a new Group Identifier (Gid). 2531 * The Group Manager MUST add the relinquished Sender ID of the 2532 leaving node to the most recent set of stale Sender IDs, in the 2533 collection associated with the group (see Section 7.1). 2535 * The Group Manager cancels the association between, on one hand, 2536 the authentication credential of the leaving node and, on the 2537 other hand, the Gid associated with the OSCORE group together with 2538 the freed Sender ID value. The Group Manager deletes the 2539 authentication credential of the leaving node, if that 2540 authentication credential has no remaining association with any 2541 pair (Gid, Sender ID). 2543 Then, the Group Manager MUST generate updated security parameters and 2544 group keying material, and provide it to the remaining group members 2545 (see Section 11). As a consequence, the leaving node is not able to 2546 acquire the new security parameters and group keying material 2547 distributed after its leaving. 2549 The same considerations from Section 5 of 2550 [I-D.ietf-ace-key-groupcomm] apply here as well, considering the 2551 Group Manager acting as KDC. 2553 11. Group Rekeying Process 2555 In order to rekey the OSCORE group, the Group Manager distributes a 2556 new Group Identifier (Gid), i.e., a new OSCORE ID Context; a new 2557 OSCORE Master Secret; and, optionally, a new OSCORE Master Salt for 2558 that group. When doing so, the Group Manager MUST increment the 2559 version number of the group keying material, before starting its 2560 distribution. 2562 As per Section 3.2.1.1 of [I-D.ietf-core-oscore-groupcomm], the Group 2563 Manager MAY reassign a Gid to the same group over that group's 2564 lifetime, e.g., once the whole space of Gid values has been used for 2565 the group in question. If the Group Manager supports reassignment of 2566 Gid values and performs it in a group, then the Group Manager 2567 additionally takes the following actions. 2569 * Before rekeying the group, the Group Manager MUST check if the new 2570 Gid to be distributed coincides with the Birth Gid of any of the 2571 current group members (see Section 6.3). 2573 * If any of such "elder members" is found in the group, the Group 2574 Manager MUST evict them from the group. That is, the Group 2575 Manager MUST terminate their membership and MUST rekey the group 2576 in such a way that the new keying material is not provided to 2577 those evicted elder members. This also includes adding their 2578 relinquished Sender IDs to the most recent set of stale Sender 2579 IDs, in the collection associated with the group (see 2580 Section 7.1), before rekeying the group. 2582 Until a further following group rekeying, the Group Manager MUST 2583 store the list of those latest-evicted elder members. If any of 2584 those nodes re-joins the group before a further following group 2585 rekeying occurs, the Group Manager MUST NOT rekey the group upon 2586 their re-joining. When one of those nodes re-joins the group, the 2587 Group Manager can rely, e.g., on the ongoing secure communication 2588 association to recognize the node as included in the stored list. 2590 Across the rekeying execution, the Group Manager MUST preserve the 2591 same unchanged OSCORE Sender IDs for all group members intended to 2592 remain in the group. This avoids affecting the retrieval of 2593 authentication credentials from the Group Manager and the 2594 verification of group messages. 2596 The Group Manager MUST support the "Point-to-Point" group rekeying 2597 scheme registered in Section 11.14 of [I-D.ietf-ace-key-groupcomm], 2598 as per the detailed use defined in Section 11.1 of this document. 2599 Future specifications may define how this application profile can use 2600 alternative group rekeying schemes, which MUST comply with the 2601 functional steps defined in Section 3.2 of 2602 [I-D.ietf-core-oscore-groupcomm]. The Group Manager MUST indicate 2603 the use of such an alternative group rekeying scheme to joining 2604 nodes, by means of the 'group_rekeying' parameter included in Joining 2605 Response messages (see Section 6.3). 2607 It is RECOMMENDED that the Group Manager gets confirmation of 2608 successful distribution from the group members, and admits a maximum 2609 number of individual retransmissions to non-confirming group members. 2610 Once completed the group rekeying process, the Group Manager creates 2611 a new empty set X' of stale Sender IDs associated with the version of 2612 the newly distributed group keying material. Then, the Group Manager 2613 MUST add the set X' to the collection of stale Sender IDs associated 2614 with the group (see Section 7.1). 2616 In case the rekeying terminates and some group members have not 2617 received the new keying material, they will not be able to correctly 2618 process following secured messages exchanged in the group. These 2619 group members will eventually contact the Group Manager, in order to 2620 retrieve the current keying material and its version. 2622 Some of these group members may be in multiple groups, each 2623 associated with a different Group Manager. When failing to correctly 2624 process messages secured with the new keying material, these group 2625 members may not have sufficient information to determine which exact 2626 Group Manager they should contact, in order to retrieve the current 2627 keying material they are missing. 2629 If the Gid is formatted as described in Appendix C of 2630 [I-D.ietf-core-oscore-groupcomm], the Group Prefix can be used as a 2631 hint to determine the right Group Manager, as long as no collisions 2632 among Group Prefixes are experienced. Otherwise, a group member 2633 needs to contact the Group Manager of each group, e.g., by first 2634 requesting only the version of the current group keying material (see 2635 Section 9.8) and then possibly requesting the current keying material 2636 (see Section 9.1.1). 2638 Furthermore, some of these group members can be in multiple groups, 2639 all of which associated with the same Group Manager. In this case, 2640 these group members may also not have sufficient information to 2641 determine which exact group they should refer to, when contacting the 2642 right Group Manager. Hence, they need to contact a Group Manager 2643 multiple times, i.e., separately for each group they belong to and 2644 associated with that Group Manager. 2646 Section 11.2 defines the actions performed by a group member upon 2647 receiving the new group keying material. Section 11.3 discusses how 2648 a group member can realize that it has missed one or more rekeying 2649 instances, and the actions it is accordingly required to take. 2651 11.1. Sending Rekeying Messages 2653 When using the "Point-to-Point" group rekeying scheme, the group 2654 rekeying messages MUST have Content-Format set to application/ace- 2655 groupcomm+cbor and have the same format used for the Joining Response 2656 message in Section 6.3, with the following differences. Note that 2657 this extends the minimal content of a rekeying message as defined in 2658 Section 6 of [I-D.ietf-ace-key-groupcomm] (OPT14). 2660 * From the Joining Response, only the parameters 'gkty', 'key', 2661 'num', 'exp', and 'ace-groupcomm-profile' are present. In 2662 particular, the 'key' parameter includes only the following data. 2664 - The 'ms' parameter, specifying the new OSCORE Master Secret 2665 value. This parameter MUST be present. 2667 - The 'contextId' parameter, specifying the new Gid to use as 2668 OSCORE ID Context value. This parameter MUST be present. 2670 - The 'salt' value, specifying the new OSCORE Master Salt value. 2671 This parameter MAY be present. 2673 * The parameter 'stale_node_ids' MUST also be included, with CBOR 2674 label defined in Section 16.3. This parameter is encoded as a 2675 CBOR array, where each element is encoded as a CBOR byte string. 2676 The CBOR array has to be intended as a set, i.e., the order of its 2677 elements is irrelevant. The parameter is populated as follows. 2679 - The Group Manager creates an empty CBOR array ARRAY. 2681 - The Group Manager considers the collection of stale Sender IDs 2682 associated with the group (see Section 7.1), and takes the most 2683 recent set X, i.e., the set associated with the current version 2684 of the group keying material about to be relinquished. 2686 - For each Sender ID in X, the Group Manager encodes it as a CBOR 2687 byte string and adds the result to ARRAY. 2689 - The parameter 'stale_node_ids' takes ARRAY as value. 2691 * The parameters 'pub_keys', 'peer_roles' and 'peer_identifiers' 2692 SHOULD be present, if the group rekeying is performed due to one 2693 or multiple Clients that have requested to join the group. 2694 Following the same semantics used in the Joining Response message 2695 (see Section 6.3), the three parameters specify the authentication 2696 credential, roles in the group and node identifier of each of the 2697 Clients that have requested to join the group. The Group Manager 2698 MUST NOT include a non-empty subset of these three parameters. 2700 The Group Manager separately sends a group rekeying message formatted 2701 as defined above to each group member to be rekeyed. 2703 Each rekeying message MUST be secured with the pairwise secure 2704 communication association between the Group Manager and the group 2705 member used during the joining process. In particular, each rekeying 2706 message can target the 'control_uri' URI path defined in 2707 Section 4.3.1 of [I-D.ietf-ace-key-groupcomm] (OPT7), if provided by 2708 the intended recipient upon joining the group (see Section 6.1). 2710 This distribution approach requires group members to act (also) as 2711 servers, in order to correctly handle unsolicited group rekeying 2712 messages from the Group Manager. In particular, if a group member 2713 and the Group Manager use OSCORE [RFC8613] to secure their pairwise 2714 communications, the group member MUST create a Replay Window in its 2715 own Recipient Context upon establishing the OSCORE Security Context 2716 with the Group Manager, e.g., by means of the OSCORE profile of ACE 2717 [I-D.ietf-ace-oscore-profile]. 2719 Group members and the Group Manager SHOULD additionally support 2720 alternative distribution approaches that do not require group members 2721 to act (also) as servers. A number of such approaches are defined in 2722 Section 6 of [I-D.ietf-ace-key-groupcomm]. In particular, a group 2723 member may use CoAP Observe [RFC7641] and subscribe for updates to 2724 the group-membership resource of the group, at the endpoint /ace- 2725 group/GROUPNAME/ of the Group Manager (see Section 6.1 of 2726 [I-D.ietf-ace-key-groupcomm]). Alternatively, a full-fledged Pub-Sub 2727 model can be considered [I-D.ietf-core-coap-pubsub], where the Group 2728 Manager publishes to a rekeying topic hosted at a Broker, while the 2729 group members subscribe to such topic (see Section 6.2 of 2730 [I-D.ietf-ace-key-groupcomm]). 2732 11.2. Receiving Rekeying Messages 2734 Once received the new group keying material, a group member proceeds 2735 as follows. Unless otherwise specified, the following is independent 2736 of the specifically used group rekeying scheme. 2738 The group member considers the stale Sender IDs received from the 2739 Group Manager. If the "Point-to-Point" group rekeying scheme as 2740 detailed in Section 11.1 is used, the stale Sender IDs are specified 2741 by the 'stale_node_ids' parameter. 2743 After that, as per Section 3.2 of [I-D.ietf-core-oscore-groupcomm], 2744 the group member MUST remove every authentication credential 2745 associated with a stale Sender ID from its list of group members' 2746 authentication credentials used in the group, and MUST delete each of 2747 its Recipient Contexts used in the group whose corresponding 2748 Recipient ID is a stale Sender ID. 2750 Then, the following cases can occur, based on the version number V' 2751 of the new group keying material distributed through the rekeying 2752 process. If the "Point-to-Point" group rekeying scheme as detailed 2753 in Section 11.1 is used, this information is specified by the 'num' 2754 parameter. 2756 * The group member has not missed any group rekeying. That is, the 2757 old keying material stored by the group member has version number 2758 V, while the received new keying material has version number V' = 2759 (V + 1). In such a case, the group member simply installs the new 2760 keying material and derives the corresponding new Security 2761 Context. 2763 * The group member has missed one or more group rekeying instances. 2764 That is, the old keying material stored by the group member has 2765 version number V, while the received new keying material has 2766 version number V' > (V + 1). In such a case, the group member 2767 MUST proceed as defined in Section 11.3. 2769 * The group member has received keying material not newer than the 2770 stored one. That is, the old keying material stored by the group 2771 member has version number V, while the received keying material 2772 has version number V' < (V + 1). In such a case, the group member 2773 MUST ignore the received rekeying messages and MUST NOT install 2774 the received keying material. 2776 11.3. Missed Rekeying Instances 2778 A group member can realize to have missed one or more rekeying 2779 instances in one of the ways discussed below. In the following, V 2780 denotes the version number of the old keying material stored by the 2781 group member, while V' denotes the version number of the latest, 2782 possibly just distributed, keying material. 2784 a. The group member has participated to a rekeying process that has 2785 distributed new keying material with version number V' > (V + 1), as 2786 discussed in Section 11.2. 2788 b. The group member has obtained the latest keying material from the 2789 Group Manager, as a response to a Key Distribution Request (see 2790 Section 9.1.1) or to a Joining Request when re-joining the group (see 2791 Section 6.1). In particular, V is different than V' specified by the 2792 'num' parameter in the response. 2794 c. The group member has obtained the authentication credentials of 2795 other group members, through a Public Key Request-Response exchange 2796 with the Group Manager (see Section 9.3). In particular, V is 2797 different than V' specified by the 'num' parameter in the response. 2799 d. The group member has performed a Version Request-Response 2800 exchange with the Group Manager (see Section 9.8). In particular, V 2801 is different than V' specified by the 'num' parameter in the 2802 response. 2804 In either case, the group member MUST delete the stored keying 2805 material with version number V. 2807 If case (a) or case (b) applies, the group member MUST perform the 2808 following actions. 2810 1. The group member MUST NOT install the latest keying material yet, 2811 in case that was already obtained. 2813 2. The group member sends a Stale Sender IDs Request to the Group 2814 Manager (see Section 11.3.1), specifying the version number V as 2815 payload of the request. 2817 If the Stale Sender IDs Response from the Group Manager has no 2818 payload, the group member MUST remove all the authentication 2819 credentials from its list of group members' authentication 2820 credentials used in the group, and MUST delete all its Recipient 2821 Contexts used in the group. 2823 Otherwise, the group member considers the stale Sender IDs 2824 specified in the Stale Sender IDs Response from the Group 2825 Manager. Then, the group member MUST remove every authentication 2826 credential associated with a stale Sender ID from its list of 2827 group members' authentication credentials used in the group, and 2828 MUST delete each of its Recipient Contexts used in the group 2829 whose corresponding Recipient ID is a stale Sender ID. 2831 3. The group member installs the latest keying material with version 2832 number V' and derives the corresponding new Security Context. 2834 If case (c) or case (d) applies, the group member SHOULD perform the 2835 following actions. 2837 1. The group member sends a Stale Sender IDs Request to the Group 2838 Manager (see Section 11.3.1), specifying the version number V as 2839 payload of the request. 2841 If the Stale Sender IDs Response from the Group Manager has no 2842 payload, the group member MUST remove all the authentication 2843 credentials from its list of group members' authentication 2844 credentials used in the group, and MUST delete all its Recipient 2845 Contexts used in the group. 2847 Otherwise, the group member considers the stale Sender IDs 2848 specified in the Stale Sender IDs Response from the Group 2849 Manager. Then, the group member MUST remove every authentication 2850 credential associated with a stale Sender ID from its list of 2851 group members' authentication credentials used in the group, and 2852 MUST delete each of its Recipient Contexts used in the group 2853 whose corresponding Recipient ID is a stale Sender ID. 2855 2. The group member obtains the latest keying material with version 2856 number V' from the Group Manager. This can happen by sending a 2857 Key Distribution Request to the Group Manager (see Section 9.1.1) 2858 and Section 9.1.2). 2860 3. The group member installs the latest keying material with version 2861 number V' and derives the corresponding new Security Context. 2863 If case (c) or case (d) applies, the group member can alternatively 2864 perform the following actions. 2866 1. The group member re-joins the group (see Section 6.1). When 2867 doing so, the group member MUST re-join with the same roles it 2868 currently has in the group, and MUST request the Group Manager 2869 for the authentication credentials of all the current group 2870 members. That is, the 'get_pub_keys' parameter of the Joining 2871 Request MUST be present and MUST be set to the CBOR simple value 2872 "null" (0xf6). 2874 2. When receiving the Joining Response (see Section 6.4 and 2875 Section 6.4), the group member retrieves the set Z of 2876 authentication credentials specified in the 'pub_keys' parameter. 2878 Then, the group member MUST remove every authentication 2879 credential which is not in Z from its list of group members' 2880 authentication credentials used in the group, and MUST delete 2881 each of its Recipient Contexts used in the group that does not 2882 include any of the authentication credentials in Z. 2884 3. The group member installs the latest keying material with version 2885 number V' and derives the corresponding new Security Context. 2887 11.3.1. Retrieve Stale Sender IDs 2889 When realizing to have missed one or more group rekeying instances 2890 (see Section 11.3), a node needs to retrieve from the Group Manager 2891 the data required to delete some of its stored group members' 2892 authentication credentials and Recipient Contexts (see 2893 Section 8.3.1). These data are provided as an aggregated set of 2894 stale Sender IDs, which are used as specified in Section 11.3. 2896 In particular, the node sends a CoAP FETCH request to the endpoint 2897 /ace-group/GROUPNAME/stale-sids at the Group Manager defined in 2898 Section 8.3 of this document, where GROUPNAME is the name of the 2899 OSCORE group. 2901 The payload of the Stale Sender IDs Request MUST include a CBOR 2902 unsigned integer. This encodes the version number V of the most 2903 recent group keying material stored and installed by the requesting 2904 Client, which is older than the latest, possibly just distributed, 2905 keying material with version number V'. 2907 The handler MUST reply with a 4.00 (Bad Request) error response, if 2908 the request is not formatted correctly. Also, the handler MUST 2909 respond with a 4.00 (Bad Request) error response, if the specified 2910 version number V is greater or equal than the version number V' 2911 associated with the latest keying material in the group, i.e., in 2912 case V >= V'. 2914 Otherwise, the handler responds with a 2.05 (Content) Stale Sender 2915 IDs Response. The payload of the response is formatted as defined 2916 below, where SKEW = (V' - V + 1). 2918 * The Group Manager considers ITEMS as the current number of sets 2919 stored in the collection of stale Sender IDs associated with the 2920 group (see Section 7.1). 2922 * If SKEW > ITEMS, the Stale Sender IDs Response MUST NOT have a 2923 payload. 2925 * Otherwise, the payload of the Stale Sender IDs Response MUST 2926 include a CBOR array, where each element is encoded as a CBOR byte 2927 string. The CBOR array has to be intended as a set, i.e., the 2928 order of its elements is irrelevant. The Group Manager populates 2929 the CBOR array as follows. 2931 - The Group Manager creates an empty CBOR array ARRAY and an 2932 empty set X. 2934 - The Group Manager considers the SKEW most recent sets stored in 2935 the collection of stale Sender IDs associated with the group. 2936 Note that the most recent set is the one associate to the 2937 latest version of the group keying material. 2939 - The Group Manager copies all the Sender IDs from the selected 2940 sets into X. When doing so, the Group Manager MUST discard 2941 duplicates. That is, the same Sender ID MUST NOT be present 2942 more than once in the final content of X. 2944 - For each Sender ID in X, the Group Manager encodes it as a CBOR 2945 byte string and adds the result to ARRAY. 2947 - Finally, ARRAY is specified as payload of the Stale Sender IDs 2948 Response. Note that ARRAY might result in the empty CBOR 2949 array. 2951 Figure 9 gives an overview of the exchange described above, while 2952 Figure 10 shows an example. 2954 Group 2955 Node Manager 2956 | | 2957 | Stale Sender IDs Request | 2958 |------------------------------------------------------------>| 2959 | FETCH ace-group/GROUPNAME/stale-sids | 2960 | | 2961 |<---------- Stale Sender IDs Response: 2.05 (Content) -------| 2962 | | 2964 Figure 9: Message Flow of Stale Sender IDs Request-Response 2966 Request: 2968 Header: FETCH (Code=0.05) 2969 Uri-Host: "kdc.example.com" 2970 Uri-Path: "ace-group" 2971 Uri-Path: "g1" 2972 Uri-Path: "stale-sids" 2973 Payload (in CBOR diagnostic notation): 2974 42 2976 Response: 2978 Header: Content (Code=2.05) 2979 Payload (in CBOR diagnostic notation): 2980 [h'01', h'fc', h'12ab', h'de44', h'ff'] 2982 Figure 10: Example of Stale Sender IDs Request-Response 2984 12. ACE Groupcomm Parameters 2986 In addition to those defined in Section 8 of 2987 [I-D.ietf-ace-key-groupcomm], this application profile defines 2988 additional parameters used during the second part of the message 2989 exchange with the Group Manager, i.e., after the exchange of Token 2990 Transfer Request and Response (see Section 5.3). The table below 2991 summarizes them and specifies the CBOR key to use instead of the full 2992 descriptive name. 2994 Note that the media type application/ace-groupcomm+cbor MUST be used 2995 when these parameters are transported in the respective message 2996 fields. 2998 +----------------+------+-------+-----------------+ 2999 | Name | CBOR | CBOR | Reference | 3000 | | Key | Type | | 3001 +----------------+------+-------+-----------------+ 3002 | group_senderId | TBD | bstr | [this document] | 3003 +----------------+------+-------+-----------------+ 3004 | ecdh_info | TBD | array | [this document] | 3005 +----------------+------+-------+-----------------+ 3006 | kdc_dh_creds | TBD | array | [this document] | 3007 +----------------+------+-------+-----------------+ 3008 | group_enc_key | TBD | bstr | [this document] | 3009 +----------------+------+-------+-----------------+ 3010 | stale_node_ids | TBD | array | [this document] | 3011 +----------------+------+-------+-----------------+ 3013 Figure 11: ACE Groupcomm Parameters 3015 The Group Manager is expected to support and understand all the 3016 parameters above. Instead, a Client is required to support the new 3017 parameters defined in this application profile as specified below 3018 (REQ29). 3020 * 'group_senderId' MUST be supported by a Client that intends to 3021 join an OSCORE group with the role of Requester and/or Responder. 3023 * 'ecdh_info' MUST be supported by a Client that intends to join a 3024 group which uses the pairwise mode of Group OSCORE. 3026 * 'kdc_dh_creds' MUST be supported by a Client that intends to join 3027 a group which uses the pairwise mode of Group OSCORE and that does 3028 not plan to or cannot rely on an early retrieval of the Group 3029 Manager's Diffie-Hellman authentication credential. 3031 * 'group_enc_key' MUST be supported by a Client that intends to join 3032 a group which uses the group mode of Group OSCORE or to be 3033 signature verifier for that group. 3035 * 'stale_node_ids' MUST be supported. 3037 When the conditional parameters defined in Section 8 of 3038 [I-D.ietf-ace-key-groupcomm] are used with this application profile, 3039 a Client must, should or may support them as specified below (REQ30). 3041 * 'client_cred', 'cnonce', 'client_cred_verify'. A Client that has 3042 an own authentication credential to use in a group MUST support 3043 these parameters. 3045 * 'kdcchallenge'. A Client that has an own authentication 3046 credential to use in a group and that provides the Access Token to 3047 the Group Manager through a Token Transfer Request (see 3048 Section 5.3) MUST support this parameter. 3050 * 'pub_keys_repo'. This parameter is not relevant for this 3051 application profile, since the Group Manager always acts as 3052 repository of the group members' authentication credentials. 3054 * 'group_policies'. A Client that is interested in the specific 3055 policies used in a group, but that does not know them or cannot 3056 become aware of them before joining that group, SHOULD support 3057 this parameter. 3059 * 'peer_roles'. A Client MUST support this parameter, since in this 3060 application profile it is relevant for Clients to know the roles 3061 of the group member associated with each authentication 3062 credential. 3064 * 'kdc_nonce', 'kdc_cred' and 'kdc_cred_verify'. A Client MUST 3065 support these parameters, since the Group Manager's authentication 3066 credential is required to process messages protected with Group 3067 OSCORE (see Section 4.3 of [I-D.ietf-core-oscore-groupcomm]). 3069 * 'mgt_key_material'. A Client that supports an advanced rekeying 3070 scheme possibly used in the group, such as based on one-to-many 3071 rekeying messages sent by the Group Manager (e.g., over IP 3072 multicast), MUST support this parameter. 3074 * 'control_group_uri'. A Client that supports the hosting of local 3075 resources each associated with a group (hence acting as CoAP 3076 server) and the reception of one-to-many requests sent to those 3077 resources by the Group Manager (e.g., over IP multicast) MUST 3078 support this parameter. 3080 13. ACE Groupcomm Error Identifiers 3082 In addition to those defined in Section 9 of 3083 [I-D.ietf-ace-key-groupcomm], this application profile defines new 3084 values that the Group Manager can include as error identifiers, in 3085 the 'error' field of an error response with Content-Format 3086 application/ace-groupcomm+cbor. 3088 +-------+-------------------------------------------------+ 3089 | Value | Description | 3090 +-------+-------------------------------------------------+ 3091 | 7 | Signatures not used in the group | 3092 +-------+-------------------------------------------------+ 3093 | 8 | Operation permitted only to signature verifiers | 3094 +-------+-------------------------------------------------+ 3095 | 9 | Group currently not active | 3096 +-------+-------------------------------------------------+ 3098 Figure 12: ACE Groupcomm Error Identifiers 3100 A Client supporting the 'error' parameter (see Sections 4.1.2 and 8 3101 of [I-D.ietf-ace-key-groupcomm]) and able to understand the specified 3102 error may use that information to determine what actions to take 3103 next. If it is included in the error response and supported by the 3104 Client, the 'error_description' parameter may provide additional 3105 context. In particular, the following guidelines apply. 3107 * In case of error 7, the Client should stop sending the request in 3108 question to the Group Manager. In this application profile, this 3109 error is relevant only for a signature verifier, in case it tries 3110 to access resources related to a pairwise-only group. 3112 * In case of error 8, the Client should stop sending the request in 3113 question to the Group Manager. 3115 * In case of error 9, the Client should wait for a certain (pre- 3116 configured) amount of time, before trying re-sending its request 3117 to the Group Manager. 3119 14. Default Values for Group Configuration Parameters 3121 This section defines the default values that the Group Manager 3122 assumes for the configuration parameters of an OSCORE group, unless 3123 differently specified when creating and configuring the group. This 3124 can be achieved as specified in [I-D.ietf-ace-oscore-gm-admin]. 3126 14.1. Common 3128 This section always applies, as related to common configuration 3129 parameters. 3131 * For the HKDF Algorithm 'hkdf', the Group Manager SHOULD use HKDF 3132 SHA-256, defined as default in Section 3.2 of [RFC8613]. In the 3133 'hkdf' parameter, this HKDF Algorithm is specified by the HMAC 3134 Algorithm HMAC 256/256 (COSE algorithm encoding: 5). 3136 * For the format 'cred_fmt' used for the authentication credentials 3137 in the group, the Group Manager SHOULD use CBOR Web Token (CWT) or 3138 CWT Claims Set (CCS) [RFC8392], i.e., the COSE Header Parameter 3139 'kcwt' and 'kccs', respectively. 3141 [ These COSE Header Parameters are under pending registration 3142 requested by draft-ietf-lake-edhoc. ] 3144 * For 'max_stale_sets', the Group Manager SHOULD consider N = 3 as 3145 the maximum number of stored sets of stale Sender IDs in the 3146 collection associated with the group (see Section 7.1). 3148 14.2. Group Mode 3150 This section applies if the group uses (also) the group mode of Group 3151 OSCORE. 3153 * For the Signature Encryption Algorithm 'sign_enc_alg' used to 3154 encrypt messages protected with the group mode, the Group Manager 3155 SHOULD use AES-CCM-16-64-128 (COSE algorithm encoding: 10) as 3156 default value. 3158 The Group Manager SHOULD use the following default values for the 3159 Signature Algorithm 'sign_alg' and related parameters 'sign_params', 3160 consistently with the "COSE Algorithms" registry [COSE.Algorithms], 3161 the "COSE Key Types" registry [COSE.Key.Types] and the "COSE Elliptic 3162 Curves" registry [COSE.Elliptic.Curves]. 3164 * For the Signature Algorithm 'sign_alg' used to sign messages 3165 protected with the group mode, the signature algorithm EdDSA 3166 [RFC8032]. 3168 * For the parameters 'sign_params' of the Signature Algorithm: 3170 - The array [[OKP], [OKP, Ed25519]], in case EdDSA is assumed or 3171 specified for 'sign_alg'. In particular, this indicates to use 3172 the COSE key type OKP and the elliptic curve Ed25519 [RFC8032]. 3174 - The array [[EC2], [EC2, P-256]], in case ES256 [RFC6979] is 3175 specified for 'sign_alg'. In particular, this indicates to use 3176 the COSE key type EC2 and the elliptic curve P-256. 3178 - The array [[EC2], [EC2, P-384]], in case ES384 [RFC6979] is 3179 specified for 'sign_alg'. In particular, this indicates to use 3180 the COSE key type EC2 and the elliptic curve P-384. 3182 - The array [[EC2], [EC2, P-521]], in case ES512 [RFC6979] is 3183 specified for 'sign_alg'. In particular, this indicates to use 3184 the COSE key type EC2 and the elliptic curve P-521. 3186 - The array [[RSA], [RSA]], in case PS256, PS384 or PS512 3187 [RFC8017] is specified for 'sign_alg'. In particular, this 3188 indicates to use the COSE key type RSA. 3190 14.3. Pairwise Mode 3192 This section applies if the group uses (also) the pairwise mode of 3193 Group OSCORE. 3195 For the AEAD Algorithm 'alg' used to encrypt messages protected with 3196 the pairwise mode, the Group Manager SHOULD use the same default 3197 value defined in Section 3.2 of [RFC8613], i.e., AES-CCM-16-64-128 3198 (COSE algorithm encoding: 10). 3200 For the Pairwise Key Agreement Algorithm 'ecdh_alg' and related 3201 parameters 'ecdh_params', the Group Manager SHOULD use the following 3202 default values, consistently with the "COSE Algorithms" registry 3203 [COSE.Algorithms], the "COSE Key Types" registry [COSE.Key.Types] and 3204 the "COSE Elliptic Curves" registry [COSE.Elliptic.Curves]. 3206 * For the Pairwise Key Agreement Algorithm 'ecdh_alg' used to 3207 compute static-static Diffie-Hellman shared secrets, the ECDH 3208 algorithm ECDH-SS + HKDF-256 specified in Section 6.3.1 of 3209 [I-D.ietf-cose-rfc8152bis-algs]. 3211 * For the parameters 'ecdh_params' of the Pairwise Key Agreement 3212 Algorithm: 3214 - The array [[OKP], [OKP, X25519]], in case EdDSA is assumed or 3215 specified for 'sign_alg', or in case the group is a pairwise- 3216 only group. In particular, this indicates to use the COSE key 3217 type OKP and the elliptic curve X25519 [RFC8032]. 3219 - The array [[EC2], [EC2, P-256]], in case ES256 [RFC6979] is 3220 specified for 'sign_alg'. In particular, this indicates to use 3221 the COSE key type EC2 and the elliptic curve P-256. 3223 - The array [[EC2], [EC2, P-384]], in case ES384 [RFC6979] is 3224 specified for 'sign_alg'. In particular, this indicates to use 3225 the COSE key type EC2 and the elliptic curve P-384. 3227 - The array [[EC2], [EC2, P-521]], in case ES512 [RFC6979] is 3228 specified for 'sign_alg'. In particular, this indicates to use 3229 the COSE key type EC2 and the elliptic curve P-521. 3231 15. Security Considerations 3233 Security considerations for this profile are inherited from 3234 [I-D.ietf-ace-key-groupcomm], the ACE framework for Authentication 3235 and Authorization [I-D.ietf-ace-oauth-authz], and the specific 3236 transport profile of ACE signalled by the AS, such as 3237 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile]. 3239 The following security considerations also apply for this profile. 3241 15.1. Management of OSCORE Groups 3243 This profile leverages the following management aspects related to 3244 OSCORE groups and discussed in the sections of 3245 [I-D.ietf-core-oscore-groupcomm] referred below. 3247 * Management of group keying material (see Section 3.2 of 3248 [I-D.ietf-core-oscore-groupcomm]). The Group Manager is 3249 responsible for the renewal and re-distribution of the keying 3250 material in the groups of its competence (rekeying). 3252 The Group Manager performs a rekeying when one ore more members 3253 leave the group, thus preserving forward security and ensuring 3254 that the security properties of Group OSCORE are fulfilled. 3255 According to the specific application requirements, the Group 3256 Manager can also rekey the group upon a new node's joining, in 3257 case backward security has also to be preserved. 3259 * Provisioning and retrieval of authentication credentials (see 3260 Section 3 of [I-D.ietf-core-oscore-groupcomm]). The Group Manager 3261 acts as repository of authentication credentials of group members, 3262 and provides them upon request. 3264 * Synchronization of sequence numbers (see Section 6.3 of 3265 [I-D.ietf-core-oscore-groupcomm]). This concerns how a responder 3266 node that has just joined an OSCORE group can synchronize with the 3267 sequence number of requesters in the same group. 3269 Before sending the Joining Response, the Group Manager MUST verify 3270 that the joining node actually owns the associated private key. To 3271 this end, the Group Manager can rely on the proof-of-possession 3272 challenge-response defined in Section 6. 3274 Alternatively, when establishing a secure communication association 3275 with the Group Manager, the joining node can provide the Group 3276 Manager with its own authentication credential, and use the public 3277 key included thereof as asymmetric proof-of-possession key. For 3278 example, this is the case when the joining node relies on 3279 Section 3.2.2 of [I-D.ietf-ace-dtls-authorize] and authenticates 3280 itself during the DTLS handshake with the Group Manager. However, 3281 this requires the authentication credential to be in the format used 3282 in the OSCORE group, and that both the authentication credential of 3283 the joining node and the included public key are compatible with the 3284 signature or ECDH algorithm, and possible associated parameters used 3285 in the OSCORE group. 3287 A node may have joined multiple OSCORE groups under different non- 3288 synchronized Group Managers. Therefore, it can happen that those 3289 OSCORE groups have the same Group Identifier (Gid). It follows that, 3290 upon receiving a Group OSCORE message addressed to one of those 3291 groups, the node would have multiple Security Contexts matching with 3292 the Gid in the incoming message. It is up to the application to 3293 decide how to handle such collisions of Group Identifiers, e.g., by 3294 trying to process the incoming message using one Security Context at 3295 the time until the right one is found. 3297 15.2. Size of Nonces as Proof-of-Possesion Challenge 3299 With reference to the Joining Request message in Section 6.1, the 3300 proof-of-possession (PoP) evidence included in 'client_cred_verify' 3301 is computed over an input including also N_C | N_S, where | denotes 3302 concatenation. 3304 For the N_C challenge, it is RECOMMENDED to use a 8-byte long random 3305 nonce. Furthermore, N_C is always conveyed in the 'cnonce' parameter 3306 of the Joining Request, which is always sent over the secure 3307 communication association between the joining node and the Group 3308 Manager. 3310 As defined in Section 6.1.1, the way the N_S value is computed 3311 depends on the particular way the joining node provides the Group 3312 Manager with the Access Token, as well as on following interactions 3313 between the two. 3315 * If the Access Token has not been provided to the Group Manager by 3316 means of a Token Transfer Request to the /authz-info endpoint as 3317 in Section 5.3, then N_S is computed as a 32-byte long challenge. 3318 For an example, see point (2) of Section 6.1.1. 3320 * If the Access Token has been provided to the Group Manager by 3321 means of a Token Transfer Request to the /authz-info endpoint as 3322 in Section 5.3, then N_S takes the most recent value provided to 3323 the Client by the Group Manager in the 'kdcchallenge' parameter, 3324 as specified in point (1) of Section 6.1.1. This value is 3325 provided either in the Token Transfer Response (see Section 5.3), 3326 or in a 4.00 (Bad Request) error response to a following Joining 3327 Request (see Section 6.2). In either case, it is RECOMMENDED to 3328 use a 8-byte long random challenge as value for N_S. 3330 If we consider both N_C and N_S to take 8-byte long values, the 3331 following considerations hold. 3333 * Let us consider both N_C and N_S as taking random values, and the 3334 Group Manager to never change the value of the N_S provided to a 3335 Client during the lifetime of an Access Token. Then, as per the 3336 birthday paradox, the average collision for N_S will happen after 3337 2^32 new transferred Access Tokens, while the average collision 3338 for N_C will happen after 2^32 new Joining Requests. This amounts 3339 to considerably more token provisionings than the expected new 3340 joinings of OSCORE groups under a same Group Manager, as well as 3341 to considerably more requests to join OSCORE groups from a same 3342 Client using a same Access Token under a same Group Manager. 3344 * Section 7 of [I-D.ietf-ace-oscore-profile] as well Appendix B.2 of 3345 [RFC8613] recommend the use of 8-byte random values as well. 3346 Unlike in those cases, the values of N_C and N_S considered in 3347 this document are not used for as sensitive operations as the 3348 derivation of a Security Context, and thus do not have possible 3349 implications in the security of AEAD ciphers. 3351 15.3. Reusage of Nonces for Proof-of-Possession Input 3353 As long as the Group Manager preserves the same N_S value currently 3354 associated with an Access Token, i.e., the latest value provided to a 3355 Client in a 'kdcchallenge' parameter, the Client is able to 3356 successfully reuse the same proof-of-possession (PoP) input for 3357 multiple Joining Requests to that Group Manager. 3359 In particular, the Client can reuse the same N_C value for every 3360 Joining Request to the Group Manager, and combine it with the same 3361 unchanged N_S value. This results in reusing the same PoP input for 3362 producing the PoP evidence to include in the 'client_cred_verify' 3363 parameter of the Joining Requests. 3365 Unless the Group Manager maintains a list of N_C values already used 3366 by that Client since the latest update to the N_S value associated 3367 with the Access Token, the Group Manager can be forced to falsely 3368 believe that the Client possesses its own private key at that point 3369 in time, upon verifying the PoP evidence in the 'client_cred_verify' 3370 parameter. 3372 16. IANA Considerations 3374 Note to RFC Editor: Please replace all occurrences of "[[This 3375 document]]" with the RFC number of this specification and delete this 3376 paragraph. 3378 This document has the following actions for IANA. 3380 16.1. OAuth Parameters 3382 IANA is asked to register the following entries to the "OAuth 3383 Parameters" registry, as per the procedure specified in Section 11.2 3384 of [RFC6749]. 3386 * Parameter name: ecdh_info 3388 * Parameter usage location: client-rs request, rs-client response 3390 * Change Controller: IESG 3392 * Specification Document(s): [[This document]] 3394 * Parameter name: kdc_dh_creds 3396 * Parameter usage location: client-rs request, rs-client response 3398 * Change Controller: IESG 3400 * Specification Document(s): [[This document]] 3402 16.2. OAuth Parameters CBOR Mappings 3404 IANA is asked to register the following entries to the "OAuth 3405 Parameters CBOR Mappings" registry, as per the procedure specified in 3406 Section 8.10 of [I-D.ietf-ace-oauth-authz]. 3408 * Name: ecdh_info 3410 * CBOR Key: TBD (range -256 to 255) 3412 * Value Type: Simple value "null" / Array 3414 * Reference: [[This document]] 3415 * Name: kdc_dh_creds 3417 * CBOR Key: TBD (range -256 to 255) 3419 * Value Type: Simple value "null" / Array 3421 * Reference: [[This document]] 3423 16.3. ACE Groupcomm Parameters 3425 IANA is asked to register the following entry to the "ACE Groupcomm 3426 Parameters" registry defined in Section 11.7 of 3427 [I-D.ietf-ace-key-groupcomm]. 3429 * Name: group_senderId 3431 * CBOR Key: TBD 3433 * CBOR Type: Byte string 3435 * Reference: [[This document]] (Section 9.2) 3437 * Name: ecdh_info 3439 * CBOR Key: TBD 3441 * CBOR Type: Array 3443 * Reference: [[This document]] (Section 6.2) 3445 * Name: kdc_dh_creds 3447 * CBOR Key: TBD 3449 * CBOR Type: Array 3451 * Reference: [[This document]] (Section 6.2) 3453 * Name: group_enc_key 3455 * CBOR Key: TBD 3457 * CBOR Type: Byte string 3459 * Reference: [[This document]] (Section 8.2.1) 3460 * Name: stale_node_ids 3462 * CBOR Key: TBD 3464 * CBOR Type: Array 3466 * Reference: [[This document]] (Section 11) 3468 16.4. ACE Groupcomm Key Types 3470 IANA is asked to register the following entry to the "ACE Groupcomm 3471 Key Types" registry defined in Section 11.8 of 3472 [I-D.ietf-ace-key-groupcomm]. 3474 * Name: Group_OSCORE_Input_Material object 3476 * Key Type Value: GROUPCOMM_KEY_TBD 3478 * Profile: "coap_group_oscore_app", defined in Section 16.5 of this 3479 document. 3481 * Description: A Group_OSCORE_Input_Material object encoded as 3482 described in Section 6.3 of this document. 3484 * Reference: [[This document]] (Section 6.3) 3486 16.5. ACE Groupcomm Profiles 3488 IANA is asked to register the following entry to the "ACE Groupcomm 3489 Profiles" registry defined in Section 11.9 of 3490 [I-D.ietf-ace-key-groupcomm]. 3492 * Name: coap_group_oscore_app 3494 * Description: Application profile to provision keying material for 3495 participating in group communication protected with Group OSCORE 3496 as per [I-D.ietf-core-oscore-groupcomm]. 3498 * CBOR Value: PROFILE_TBD 3500 * Reference: [[This document]] (Section 6.3) 3502 16.6. OSCORE Security Context Parameters 3504 IANA is asked to register the following entries in the "OSCORE 3505 Security Context Parameters" registry defined in Section 9.4 of 3506 [I-D.ietf-ace-oscore-profile]. 3508 * Name: group_SenderId 3510 * CBOR Label: TBD 3512 * CBOR Type: Byte string 3514 * Registry: - 3516 * Description: OSCORE Sender ID assigned to a member of an OSCORE 3517 group 3519 * Reference: [[This document]] (Section 6.3) 3521 * Name: cred_fmt 3523 * CBOR Label: TBD 3525 * CBOR Type: Integer 3527 * Registry: COSE Header Parameters 3529 * Description: Format of authentication credentials to be used in 3530 the OSCORE group 3532 * Reference: [[This document]] (Section 6.3) 3534 * Name: sign_enc_alg 3536 * CBOR Label: TBD 3538 * CBOR Type: Text string / Integer 3540 * Registry: COSE Algorithms 3542 * Description: OSCORE Signature Encryption Algorithm Value 3544 * Reference: [[This document]] (Section 6.3) 3546 * Name: sign_alg 3548 * CBOR Label: TBD 3550 * CBOR Type: Text string / Integer 3552 * Registry: COSE Algorithms 3553 * Description: OSCORE Signature Algorithm Value 3555 * Reference: [[This document]] (Section 6.3) 3557 * Name: sign_params 3559 * CBOR Label: TBD 3561 * CBOR Type: Array 3563 * Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves 3565 * Description: OSCORE Signature Algorithm Parameters 3567 * Reference: [[This document]] (Section 6.3) 3569 * Name: ecdh_alg 3571 * CBOR Label: TBD 3573 * CBOR Type: Text string / Integer 3575 * Registry: COSE Algorithms 3577 * Description: OSCORE Pairwise Key Agreement Algorithm Value 3579 * Reference: [[This document]] (Section 6.3) 3581 * Name: ecdh_params 3583 * CBOR Label: TBD 3585 * CBOR Type: Array 3587 * Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves 3589 * Description: OSCORE Pairwise Key Agreement Algorithm Parameters 3591 * Reference: [[This document]] (Section 6.3) 3593 16.7. TLS Exporter Labels 3595 IANA is asked to register the following entry to the "TLS Exporter 3596 Labels" registry defined in Section 6 of [RFC5705] and updated in 3597 Section 12 of [RFC8447]. 3599 * Value: EXPORTER-ACE-Sign-Challenge-coap-group-oscore-app 3601 * DTLS-OK: Y 3603 * Recommended: N 3605 * Reference: [[This document]] (Section 6.1.1) 3607 16.8. AIF 3609 For the media-types application/aif+cbor and application/aif+json 3610 defined in Section 5.1 of [I-D.ietf-ace-aif], IANA is requested to 3611 register the following entries for the two media-type parameters Toid 3612 and Tperm, in the respective sub-registry defined in Section 5.2 of 3613 [I-D.ietf-ace-aif] within the "MIME Media Type Sub-Parameter" 3614 registry group. 3616 * Name: oscore-gname 3618 * Description/Specification: OSCORE group name 3620 * Reference: [[This document]] 3622 * Name: oscore-gperm 3624 * Description/Specification: permissions pertaining OSCORE groups 3626 * Reference: [[This document]] 3628 16.9. CoAP Content-Format 3630 IANA is asked to register the following entries to the "CoAP Content- 3631 Formats" registry within the "Constrained RESTful Environments (CoRE) 3632 Parameters" registry group. 3634 * Media Type: application/aif+cbor;Toid="oscore- 3635 gname",Tperm="oscore-gperm" 3637 * Encoding: - 3639 * ID: TBD 3641 * Reference: [[This document]] 3643 * Media Type: application/aif+json;Toid="oscore- 3644 gname",Tperm="oscore-gperm" 3646 * Encoding: - 3648 * ID: TBD 3650 * Reference: [[This document]] 3652 16.10. Group OSCORE Roles 3654 This document establishes the IANA "Group OSCORE Roles" registry. 3655 The registry has been created to use the "Expert Review" registration 3656 procedure [RFC8126]. Expert review guidelines are provided in 3657 Section 16.14. 3659 This registry includes the possible roles that nodes can take in an 3660 OSCORE group, each in combination with a numeric identifier. These 3661 numeric identifiers are used to express authorization information 3662 about joining OSCORE groups, as specified in Section 3 of [[This 3663 document]]. 3665 The columns of this registry are: 3667 * Name: A value that can be used in documents for easier 3668 comprehension, to identify a possible role that nodes can take in 3669 an OSCORE group. 3671 * Value: The numeric identifier for this role. Integer values 3672 greater than 65535 are marked as "Private Use", all other values 3673 use the registration policy "Expert Review" [RFC8126]. 3675 * Description: This field contains a brief description of the role. 3677 * Reference: This contains a pointer to the public specification for 3678 the role. 3680 This registry will be initially populated by the values in Figure 1. 3682 The Reference column for all of these entries will be [[This 3683 document]]. 3685 16.11. CoRE Resource Type 3687 IANA is asked to register the following entry in the "Resource Type 3688 (rt=) Link Target Attribute Values" registry within the "Constrained 3689 Restful Environments (CoRE) Parameters" registry group. 3691 * Value: "core.osc.gm" 3693 * Description: Group-membership resource of an OSCORE Group Manager. 3695 * Reference: [[This document]] 3697 Client applications can use this resource type to discover a group 3698 membership resource at an OSCORE Group Manager, where to send a 3699 request for joining the corresponding OSCORE group. 3701 16.12. ACE Scope Semantics 3703 IANA is asked to register the following entry in the "ACE Scope 3704 Semantics" registry defined in Section 11.12 of 3705 [I-D.ietf-ace-key-groupcomm]. 3707 * Value: SEM_ID_TBD 3709 * Description: Membership and key management operations at the ACE 3710 Group Manager for Group OSCORE. 3712 * Reference: [[This document]] 3714 16.13. ACE Groupcomm Errors 3716 IANA is asked to register the following entry in the "ACE Groupcomm 3717 Errors" registry defined in Section 11.13 of 3718 [I-D.ietf-ace-key-groupcomm]. 3720 * Value: 7 3722 * Description: Signatures not used in the group. 3724 * Reference: [[This document]] 3726 * Value: 8 3728 * Description: Operation permitted only to signature verifiers. 3730 * Reference: [[This document]] 3732 * Value: 9 3734 * Description: Group currently not active. 3736 * Reference: [[This document]] 3738 16.14. Expert Review Instructions 3740 The IANA registry established in this document is defined as "Expert 3741 Review". This section gives some general guidelines for what the 3742 experts should be looking for, but they are being designated as 3743 experts for a reason so they should be given substantial latitude. 3745 Expert reviewers should take into consideration the following points: 3747 * Clarity and correctness of registrations. Experts are expected to 3748 check the clarity of purpose and use of the requested entries. 3749 Experts should inspect the entry for the considered role, to 3750 verify the correctness of its description against the role as 3751 intended in the specification that defined it. Experts should 3752 consider requesting an opinion on the correctness of registered 3753 parameters from the Authentication and Authorization for 3754 Constrained Environments (ACE) Working Group and the Constrained 3755 RESTful Environments (CoRE) Working Group. 3757 Entries that do not meet these objective of clarity and 3758 completeness should not be registered. 3760 * Duplicated registration and point squatting should be discouraged. 3761 Reviewers are encouraged to get sufficient information for 3762 registration requests to ensure that the usage is not going to 3763 duplicate one that is already registered and that the point is 3764 likely to be used in deployments. 3766 * Experts should take into account the expected usage of roles when 3767 approving point assignment. Given a 'Value' V as code point, the 3768 length of the encoding of (2^(V+1) - 1) should be weighed against 3769 the usage of the entry, considering the resources and capabilities 3770 of devices it will be used on. Additionally, given a 'Value' V as 3771 code point, the length of the encoding of (2^(V+1) - 1) should be 3772 weighed against how many code points resulting in that encoding 3773 length are left, and the resources and capabilities of devices it 3774 will be used on. 3776 * Specifications are recommended. When specifications are not 3777 provided, the description provided needs to have sufficient 3778 information to verify the points above. 3780 17. References 3782 17.1. Normative References 3784 [COSE.Algorithms] 3785 IANA, "COSE Algorithms", 3786 . 3789 [COSE.Elliptic.Curves] 3790 IANA, "COSE Elliptic Curves", 3791 . 3794 [COSE.Header.Parameters] 3795 IANA, "COSE Header Parameters", 3796 . 3799 [COSE.Key.Types] 3800 IANA, "COSE Key Types", 3801 . 3804 [I-D.ietf-ace-aif] 3805 Bormann, C., "An Authorization Information Format (AIF) 3806 for ACE", Work in Progress, Internet-Draft, draft-ietf- 3807 ace-aif-07, 15 March 2022, 3808 . 3811 [I-D.ietf-ace-dtls-authorize] 3812 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 3813 L. Seitz, "Datagram Transport Layer Security (DTLS) 3814 Profile for Authentication and Authorization for 3815 Constrained Environments (ACE)", Work in Progress, 3816 Internet-Draft, draft-ietf-ace-dtls-authorize-18, 4 June 3817 2021, . 3820 [I-D.ietf-ace-key-groupcomm] 3821 Palombini, F. and M. Tiloca, "Key Provisioning for Group 3822 Communication using ACE", Work in Progress, Internet- 3823 Draft, draft-ietf-ace-key-groupcomm-15, 23 December 2021, 3824 . 3827 [I-D.ietf-ace-oauth-authz] 3828 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 3829 H. Tschofenig, "Authentication and Authorization for 3830 Constrained Environments (ACE) using the OAuth 2.0 3831 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 3832 draft-ietf-ace-oauth-authz-46, 8 November 2021, 3833 . 3836 [I-D.ietf-ace-oscore-profile] 3837 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 3838 "OSCORE Profile of the Authentication and Authorization 3839 for Constrained Environments Framework", Work in Progress, 3840 Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May 3841 2021, . 3844 [I-D.ietf-core-oscore-groupcomm] 3845 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 3846 and J. Park, "Group OSCORE - Secure Group Communication 3847 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 3848 core-oscore-groupcomm-14, 7 March 2022, 3849 . 3852 [I-D.ietf-cose-rfc8152bis-algs] 3853 Schaad, J., "CBOR Object Signing and Encryption (COSE): 3854 Initial Algorithms", Work in Progress, Internet-Draft, 3855 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 3856 . 3859 [I-D.ietf-cose-rfc8152bis-struct] 3860 Schaad, J., "CBOR Object Signing and Encryption (COSE): 3861 Structures and Process", Work in Progress, Internet-Draft, 3862 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 3863 . 3866 [NIST-800-56A] 3867 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 3868 Davis, "Recommendation for Pair-Wise Key-Establishment 3869 Schemes Using Discrete Logarithm Cryptography - NIST 3870 Special Publication 800-56A, Revision 3", April 2018, 3871 . 3874 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3875 Requirement Levels", BCP 14, RFC 2119, 3876 DOI 10.17487/RFC2119, March 1997, 3877 . 3879 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 3880 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 3881 March 2010, . 3883 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 3884 Specifications and Registration Procedures", BCP 13, 3885 RFC 6838, DOI 10.17487/RFC6838, January 2013, 3886 . 3888 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 3889 Algorithm (DSA) and Elliptic Curve Digital Signature 3890 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 3891 2013, . 3893 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 3894 Application Protocol (CoAP)", RFC 7252, 3895 DOI 10.17487/RFC7252, June 2014, 3896 . 3898 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 3899 for Security", RFC 7748, DOI 10.17487/RFC7748, January 3900 2016, . 3902 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 3903 "PKCS #1: RSA Cryptography Specifications Version 2.2", 3904 RFC 8017, DOI 10.17487/RFC8017, November 2016, 3905 . 3907 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 3908 Signature Algorithm (EdDSA)", RFC 8032, 3909 DOI 10.17487/RFC8032, January 2017, 3910 . 3912 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3913 Writing an IANA Considerations Section in RFCs", BCP 26, 3914 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3915 . 3917 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3918 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3919 May 2017, . 3921 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3922 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3923 . 3925 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 3926 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 3927 . 3929 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 3930 Definition Language (CDDL): A Notational Convention to 3931 Express Concise Binary Object Representation (CBOR) and 3932 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 3933 June 2019, . 3935 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 3936 "Object Security for Constrained RESTful Environments 3937 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 3938 . 3940 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 3941 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 3942 . 3944 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 3945 Representation (CBOR)", STD 94, RFC 8949, 3946 DOI 10.17487/RFC8949, December 2020, 3947 . 3949 17.2. Informative References 3951 [I-D.ietf-ace-oscore-gm-admin] 3952 Tiloca, M., Höglund, R., Stok, P. V. D., and F. Palombini, 3953 "Admin Interface for the OSCORE Group Manager", Work in 3954 Progress, Internet-Draft, draft-ietf-ace-oscore-gm-admin- 3955 05, 7 March 2022, . 3958 [I-D.ietf-core-coap-pubsub] 3959 Koster, M., Keranen, A., and J. Jimenez, "Publish- 3960 Subscribe Broker for the Constrained Application Protocol 3961 (CoAP)", Work in Progress, Internet-Draft, draft-ietf- 3962 core-coap-pubsub-09, 30 September 2019, 3963 . 3966 [I-D.ietf-core-groupcomm-bis] 3967 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 3968 for the Constrained Application Protocol (CoAP)", Work in 3969 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 3970 06, 7 March 2022, . 3973 [I-D.ietf-cose-cbor-encoded-cert] 3974 Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and 3975 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 3976 Certificates)", Work in Progress, Internet-Draft, draft- 3977 ietf-cose-cbor-encoded-cert-03, 10 January 2022, 3978 . 3981 [I-D.tiloca-core-oscore-discovery] 3982 Tiloca, M., Amsuess, C., and P. V. D. Stok, "Discovery of 3983 OSCORE Groups with the CoRE Resource Directory", Work in 3984 Progress, Internet-Draft, draft-tiloca-core-oscore- 3985 discovery-11, 7 March 2022, 3986 . 3989 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 3990 Key Derivation Function (HKDF)", RFC 5869, 3991 DOI 10.17487/RFC5869, May 2010, 3992 . 3994 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3995 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 3996 January 2012, . 3998 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 3999 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 4000 . 4002 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 4003 RFC 6749, DOI 10.17487/RFC6749, October 2012, 4004 . 4006 [RFC7641] Hartke, K., "Observing Resources in the Constrained 4007 Application Protocol (CoAP)", RFC 7641, 4008 DOI 10.17487/RFC7641, September 2015, 4009 . 4011 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 4012 Security (TLS) / Datagram Transport Layer Security (DTLS) 4013 Profiles for the Internet of Things", RFC 7925, 4014 DOI 10.17487/RFC7925, July 2016, 4015 . 4017 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 4018 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 4019 May 2018, . 4021 Appendix A. Profile Requirements 4023 This section lists how this application profile of ACE addresses the 4024 requirements defined in Appendix A of [I-D.ietf-ace-key-groupcomm]. 4026 A.1. Mandatory-to-Address Requirements 4028 * REQ1 - Specify the format and encoding of 'scope'. This includes 4029 defining the set of possible roles and their identifiers, as well 4030 as the corresponding encoding to use in the scope entries 4031 according to the used scope format: see Section 3 and Section 5.1. 4033 * REQ2 - If the AIF format of 'scope' is used, register its specific 4034 instance of "Toid" and "Tperm" as Media Type parameters and a 4035 corresponding Content-Format, as per the guidelines in 4036 [I-D.ietf-ace-aif]: see Section 16.8 and Section 16.9. 4038 * REQ3 - if used, specify the acceptable values for 'sign_alg': 4039 values from the "Value" column of the "COSE Algorithms" registry 4040 [COSE.Algorithms]. 4042 * REQ4 - If used, specify the acceptable values for 4043 'sign_parameters': format and values from the COSE algorithm 4044 capabilities as specified in the "COSE Algorithms" registry 4045 [COSE.Algorithms]. 4047 * REQ5 - If used, specify the acceptable values for 4048 'sign_key_parameters': format and values from the COSE key type 4049 capabilities as specified in the "COSE Key Types" registry 4050 [COSE.Key.Types]. 4052 * REQ6 - Specify the acceptable formats for authentication 4053 credentials and, if used, the acceptable values for 'pub_key_enc': 4054 acceptable formats explicitly provide the public key as well as 4055 the comprehensive set of information related to the public key 4056 algorithm (see Section 5.3 and Section 6.3). Consistent 4057 acceptable values for 'pub_key_enc' are taken from the "Label" 4058 column of the "COSE Header Parameters" registry 4059 [COSE.Header.Parameters]. 4061 * REQ7 - If the value of the GROUPNAME URI path and the group name 4062 in the Access Token scope (gname in Section 3.1 of 4063 [I-D.ietf-ace-key-groupcomm]) are not required to coincide, 4064 specify the mechanism to map the GROUPNAME value in the URI to the 4065 group name: not applicable, since a perfect matching is required. 4067 * REQ8 - Define whether the KDC has an authentication credential and 4068 if this has to be provided through the 'kdc_cred' parameter, see 4069 Section 4.1 of [I-D.ietf-ace-key-groupcomm]: yes, as required by 4070 the Group OSCORE protocol [I-D.ietf-core-oscore-groupcomm], see 4071 Section 6.3 of this document. 4073 * REQ9 - Specify if any part of the KDC interface as defined in 4074 Section 4.1 of [I-D.ietf-ace-key-groupcomm] is not supported by 4075 the KDC: not applicable. 4077 * REQ10 - Register a Resource Type for the root url-path, which is 4078 used to discover the correct url to access at the KDC (see 4079 Section 4.1 of [I-D.ietf-ace-key-groupcomm]): the Resource Type 4080 (rt=) Link Target Attribute value "core.osc.gm" is registered in 4081 Section 16.11. 4083 * REQ11 - Define what specific actions (e.g., CoAP methods) are 4084 allowed on each resource provided by the KDC interface, depending 4085 on whether the Client is a current group member; the roles that a 4086 Client is authorized to take as per the obtained access token; and 4087 the roles that the Client has as current group member: see 4088 Section 8.4. 4090 * REQ12 - Categorize possible newly defined operations for Clients 4091 into primary operations expected to be minimally supported and 4092 secondary operations, and provide accompanying considerations: see 4093 Section 8.5. 4095 * REQ13 - Specify the encoding of group identifier (see 4096 Section 4.2.1 of [I-D.ietf-ace-key-groupcomm]): CBOR byte string 4097 (see Section 9.10). 4099 * REQ14 - Specify the approaches used to compute and verify the PoP 4100 evidence to include in 'client_cred_verify', and which of those 4101 approaches is used in which case: see Section 6.1 and Section 6.2. 4103 * REQ15 - Specify how the nonce N_S is generated, if the token is 4104 not provided to the KDC through the Token Transfer Request to the 4105 authz-info endpoint (e.g., if it is used directly to validate TLS 4106 instead): see Section 6.1.1. 4108 * REQ16 - Define the initial value of the 'num' parameter: the 4109 initial value MUST be set to 0 when creating the OSCORE group, 4110 e.g., as in [I-D.ietf-ace-oscore-gm-admin]. 4112 * REQ17 - Specify the format of the 'key' parameter: see 4113 Section 6.3. 4115 * REQ18 - Specify acceptable values of the 'gkty' parameter: 4116 Group_OSCORE_Input_Material object (see Section 6.3). 4118 * REQ19 - Specify and register the application profile identifier: 4119 coap_group_oscore_app (see Section 16.5). 4121 * REQ20 - If used, specify the format and content of 4122 'group_policies' and its entries: see Section 6.3. 4124 * REQ21 - Specify the approaches used to compute and verify the PoP 4125 evidence to include in 'kdc_cred_verify', and which of those 4126 approaches is used in which case: see Section 6.3, Section 6.4 and 4127 Section 9.5. 4129 * REQ22 - Specify the communication protocol that the members of the 4130 group must use: CoAP [RFC7252], also for group communication 4131 [I-D.ietf-core-groupcomm-bis]. 4133 * REQ23 - Specify the security protocols that the group members must 4134 use to protect their communication: Group OSCORE 4135 [I-D.ietf-core-oscore-groupcomm]. 4137 * REQ24 - Specify how the communication is secured between the 4138 Client and KDC: by means of any transport profile of ACE 4139 [I-D.ietf-ace-oauth-authz] between Client and Group Manager that 4140 complies with the requirements in Appendix C of 4141 [I-D.ietf-ace-oauth-authz]. 4143 * REQ25 - Specify the format of the identifiers of group members: 4144 the Sender ID used in the OSCORE group (see Section 6.3 and 4145 Section 9.3). 4147 * REQ26 - Specify policies at the KDC to handle member ids that are 4148 not included in 'get_pub_keys': see Section 9.3. 4150 * REQ27 - Specify the format of newly-generated individual keying 4151 material for group members, or of the information to derive it, 4152 and corresponding CBOR label: see Section 9.2. 4154 * REQ28 - Specify and register the identifier of newly defined 4155 semantics for binary scopes: see Section 16.12. 4157 * REQ29 - Categorize newly defined parameters according to the same 4158 criteria of Section 8 of [I-D.ietf-ace-key-groupcomm]: see 4159 Section 12. 4161 * REQ30 - Define whether Clients must, should or may support the 4162 conditional parameters defined in Section 8 of 4163 [I-D.ietf-ace-key-groupcomm], and under which circumstances: see 4164 Section 12. 4166 A.2. Optional-to-Address Requirements 4168 * OPT1 (Optional) - If the textual format of 'scope' is used, 4169 specify CBOR values to use for abbreviating the role identifiers 4170 in the group: not applicable. 4172 * OPT2 (Optional) - Specify additional parameters used in the 4173 exchange of Token Transfer Request and Response: 4175 - 'ecdh_info', to negotiate the ECDH algorithm, ECDH algorithm 4176 parameters, ECDH key parameters and exact format of 4177 authentication credentials used in the group, in case the 4178 joining node supports the pairwise mode of Group OSCORE (see 4179 Section 5.3). 4181 - 'kdc_dh_creds', to ask for and retrieve the Group Manager's 4182 Diffie-Hellman authentication credentials, in case the joining 4183 node supports the pairwise mode of Group OSCORE and the Access 4184 Token authorizes to join parwise-only groups (see Section 5.3). 4186 * OPT3 (Optional) - Specify the negotiation of parameter values for 4187 signature algorithm and signature keys, if 'sign_info' is not 4188 used: possible early discovery by using the approach based on the 4189 CoRE Resource Directory described in 4190 [I-D.tiloca-core-oscore-discovery]. 4192 * OPT4 (Optional) - Specify possible or required payload formats for 4193 specific error cases: send a 4.00 (Bad Request) error response to 4194 a Joining Request (see Section 6.2). 4196 * OPT5 (Optional) - Specify additional identifiers of error types, 4197 as values of the 'error' field in an error response from the KDC: 4198 see Section 16.13. 4200 * OPT6 (Optional) - Specify the encoding of 'pub_keys_repos' if the 4201 default is not used: no. 4203 * OPT7 (Optional) - Specify the functionalities implemented at the 4204 'control_uri' resource hosted at the Client, including message 4205 exchange encoding and other details (see Section 4.3.1 of 4206 [I-D.ietf-ace-key-groupcomm]): see Section 10 for the eviction of 4207 a group member; see Section 11 for the group rekeying process. 4209 * OPT8 (Optional) - Specify the behavior of the handler in case of 4210 failure to retrieve an authentication credential for the specific 4211 node: send a 4.00 (Bad Request) error response to a Joining 4212 Request (see Section 6.2). 4214 * OPT9 (Optional) - Define a default group rekeying scheme, to refer 4215 to in case the 'rekeying_scheme' parameter is not included in the 4216 Joining Response (see Section 4.3.1.1 of 4217 [I-D.ietf-ace-key-groupcomm]): the "Point-to-Point" rekeying 4218 scheme registered in Section 11.14 of 4219 [I-D.ietf-ace-key-groupcomm], whose detailed use for this profile 4220 is defined in Section 11 of this document. 4222 * OPT10 (Optional) - Specify the functionalities implemented at the 4223 'control_group_uri' resource hosted at the Client, including 4224 message exchange encoding and other details (see Section 4.3.1 of 4225 [I-D.ietf-ace-key-groupcomm]): see Section 10 for the eviction of 4226 multiple group members. 4228 * OPT11 (Optional) - Specify policies that instruct Clients to 4229 retain unsuccessfully decrypted messages and for how long, so that 4230 they can be decrypted after getting updated keying material: no. 4232 * OPT12 (Optional) - Specify for the KDC to perform group rekeying 4233 (together or instead of renewing individual keying material) when 4234 receiving a Key Renewal Request: the Group Manager SHOULD NOT 4235 perform a group rekeying, unless already scheduled to occur 4236 shortly (see Section 9.2). 4238 * OPT13 (Optional) - Specify how the identifier of a group members's 4239 authentication credential is included in requests sent to other 4240 group members: no. 4242 * OPT14 (Optional) - Specify additional information to include in 4243 rekeying messages for the "Point-to-Point" group rekeying scheme 4244 (see Section 6.1 of [I-D.ietf-ace-key-groupcomm]): see 4245 Section 11.1. 4247 * OPT15 (Optional) - Specify if Clients must or should support any 4248 of the parameters defined as optional in Section 8 of 4249 [I-D.ietf-ace-key-groupcomm]: no. 4251 Appendix B. Extensibility for Future COSE Algorithms 4253 As defined in Section 8.1 of [I-D.ietf-cose-rfc8152bis-algs], future 4254 algorithms can be registered in the "COSE Algorithms" registry 4255 [COSE.Algorithms] as specifying none or multiple COSE capabilities. 4257 To enable the seamless use of such future registered algorithms, this 4258 section defines a general, agile format for: 4260 * Each 'ecdh_info_entry' of the 'ecdh_info' parameter in the Token 4261 Transfer Response (see Section 5.3 and Section 5.3.1); 4263 * The 'sign_params' and 'ecdh_params' parameters within the 'key' 4264 parameter (see Section 6.3), as part of the response payloads used 4265 in Section 6.3, Section 9.1.1, Section 9.1.2 and Section 11. 4267 Appendix B of [I-D.ietf-ace-key-groupcomm] describes the analogous 4268 general format for 'sign_info_entry' of the 'sign_info' parameter in 4269 the Token Transfer Response (see Section 5.3 of this document). 4271 If any of the currently registered COSE algorithms is considered, 4272 using this general format yields the same structure defined in this 4273 document for the items above, thus ensuring retro-compatibility. 4275 B.1. Format of 'ecdh_info_entry' 4277 The format of each 'ecdh_info_entry' (see Section 5.3 and 4278 Section 5.3.1) is generalized as follows. Given N the number of 4279 elements of the 'ecdh_parameters' array, i.e., the number of COSE 4280 capabilities of the ECDH algorithm, then: 4282 * 'ecdh_key_parameters' is replaced by N elements 'ecdh_capab_i', 4283 each of which is a CBOR array. 4285 * The i-th array following 'ecdh_parameters', i.e., 'ecdh_capab_i' 4286 (i = 0, ..., N-1), is the array of COSE capabilities for the 4287 algorithm capability specified in 'ecdh_parameters'[i]. 4289 ecdh_info_entry = 4290 [ 4291 id : gname / [ + gname ], 4292 ecdh_alg : int / tstr, 4293 ecdh_parameters : [ alg_capab_1 : any, 4294 alg_capab_2 : any, 4295 ..., 4296 alg_capab_N : any], 4297 ecdh_capab_1 : [ any ], 4298 ecdh_capab_2 : [ any ], 4299 ..., 4300 ecdh_capab_N : [ any ], 4301 cred_fmt = int / null 4302 ] 4304 gname = tstr 4305 Figure 13: 'ecdh_info_entry' with general format 4307 B.2. Format of 'key' 4309 The format of 'key' (see Section 6.3) is generalized as follows. 4311 * The 'sign_params' array includes N+1 elements, whose exact 4312 structure and value depend on the value of the signature algorithm 4313 specified in 'sign_alg'. 4315 - The first element, i.e., 'sign_params'[0], is the array of the 4316 N COSE capabilities for the signature algorithm, as specified 4317 for that algorithm in the "Capabilities" column of the "COSE 4318 Algorithms" registry [COSE.Algorithms] (see Section 8.1 of 4319 [I-D.ietf-cose-rfc8152bis-algs]). 4321 - Each following element 'sign_params'[i], i.e., with index i > 4322 0, is the array of COSE capabilities for the algorithm 4323 capability specified in 'sign_params'[0][i-1]. 4325 For example, if 'sign_params'[0][0] specifies the key type as 4326 capability of the algorithm, then 'sign_params'[1] is the array of 4327 COSE capabilities for the COSE key type associated with the 4328 signature algorithm, as specified for that key type in the 4329 "Capabilities" column of the "COSE Key Types" registry 4330 [COSE.Key.Types] (see Section 8.2 of 4331 [I-D.ietf-cose-rfc8152bis-algs]). 4333 * The 'ecdh_params' array includes M+1 elements, whose exact 4334 structure and value depend on the value of the ECDH algorithm 4335 specified in 'ecdh_alg'. 4337 - The first element, i.e., 'ecdh_params'[0], is the array of the 4338 M COSE capabilities for the ECDH algorithm, as specified for 4339 that algorithm in the "Capabilities" column of the "COSE 4340 Algorithms" registry [COSE.Algorithms] (see Section 8.1 of 4341 [I-D.ietf-cose-rfc8152bis-algs]). 4343 - Each following element 'ecdh_params'[i], i.e., with index i > 4344 0, is the array of COSE capabilities for the algorithm 4345 capability specified in 'ecdh_params'[0][i-1]. 4347 For example, if 'ecdh_params'[0][0] specifies the key type as 4348 capability of the algorithm, then 'ecdh_params'[1] is the array of 4349 COSE capabilities for the COSE key type associated with the ECDH 4350 algorithm, as specified for that key type in the "Capabilities" 4351 column of the "COSE Key Types" registry [COSE.Key.Types] (see 4352 Section 8.2 of [I-D.ietf-cose-rfc8152bis-algs]). 4354 Appendix C. Document Updates 4356 RFC EDITOR: PLEASE REMOVE THIS SECTION. 4358 C.1. Version -13 to -14 4360 * Major reordering of the document sections. 4362 * The HKDF Algorithm is specified by the HMAC Algorithm. 4364 * Group communication does not necessarily use IP multicast. 4366 * Generalized AIF data model, also for draft-ace-oscore-gm-admin. 4368 * Clarifications and editorial improvements. 4370 C.2. Version -12 to -13 4372 * Renamed parameters about authentication credentials. 4374 * It is optional for the Group Manager to reassign Gids by tracking 4375 "Birth Gids". 4377 * Distinction between authentication credentials and public keys. 4379 * Updated IANA considerations related to AIF. 4381 * Updated textual description of registered ACE Scope Semantics 4382 value. 4384 C.3. Version -11 to -12 4386 * Clarified semantics of 'ecdh_info' and 'kdc_dh_creds'. 4388 * Definition of /ace-group/GROUPNAME/kdc-pub-key moved to draft- 4389 ietf-ace-key-groupcomm. 4391 * ace-group/ accessible also to non-members that are not Verifiers. 4393 * Clarified what resources are accessible to Verifiers. 4395 * Revised error handling for the newly defined resources. 4397 * Revised use of CoAP error codes. 4399 * Use of "Token Tranfer Request" and "Token Transfer Response". 4401 * New parameter 'rekeying_scheme'. 4403 * Categorization of new parameters and inherited conditional 4404 parameters. 4406 * Clarifications on what to do in case of enhanced error responses. 4408 * Changed UCCS to CCS. 4410 * Authentication credentials of just joined Clients can be in 4411 rekeying messages. 4413 * Revised names of new IANA registries. 4415 * Clarified meaning of registered CoRE resource type. 4417 * Alignment to new requirements from draft-ietf-ace-key-groupcomm. 4419 * Fixes and editorial improvements. 4421 C.4. Version -10 to -11 4423 * Removed redundancy of key type capabilities, from 'sign_info', 4424 'ecdh_info' and 'key'. 4426 * New resource to retrieve the Group Manager's authentication 4427 credential. 4429 * New resource to retrieve material for Signature Verifiers. 4431 * New parameter 'sign_enc_alg' related to the group mode. 4433 * 'cred_fmt' takes value from the COSE Header Parameters registry. 4435 * Improved alignment of the Joining Response payload with the Group 4436 OSCORE Security Context parameters. 4438 * Recycling Group IDs by tracking "Birth GIDs". 4440 * Error handling in case of non available Sender IDs upon joining. 4442 * Error handling in case EdDSA public keys with invalid Y coordinate 4443 when the pairwise mode of Group OSCORE is supported. 4445 * Generalized proof-of-possession (PoP) for the joining node's 4446 private key; defined Diffie-Hellman based PoP for OSCORE groups 4447 using only the pairwise mode. 4449 * Proof-of-possession of the Group Manager's private key in the 4450 Joining Response. 4452 * Always use 'peer_identifiers' to convey Sender IDs as node 4453 identifiers. 4455 * Stale Sender IDs provided when rekeying the group. 4457 * New resource for late retrieval of stale Sender IDs. 4459 * Added examples of message exchanges. 4461 * Revised default values of group configuration parameters. 4463 * Fixes to IANA registrations. 4465 * General format of parameters related to COSE capabilities, 4466 supporting future registered COSE algorithms (new Appendix). 4468 C.5. Version -09 to -10 4470 * Updated non-recycling policy of Sender IDs. 4472 * Removed policies about Sender Sequence Number synchronization. 4474 * 'control_path' renamed to 'control_uri'. 4476 * Format of 'get_pub_keys' aligned with draft-ietf-ace-key- 4477 groupcomm. 4479 * Additional way to inform of group eviction. 4481 * Registered semantics identifier for extended scope format. 4483 * Extended error handling, with error type specified in some error 4484 responses. 4486 * Renumbered requirements. 4488 C.6. Version -08 to -09 4490 * The url-path "ace-group" is used. 4492 * Added overview of admitted methods on the Group Manager resources. 4494 * Added exchange of parameters relevant for the pairwise mode of 4495 Group OSCORE. 4497 * The signed value for 'client_cred_verify' includes also the scope. 4499 * Renamed the key material object as Group_OSCORE_Input_Material 4500 object. 4502 * Replaced 'clientId' with 'group_SenderId'. 4504 * Added message exchange for Group Names request-response. 4506 * No reassignment of Sender ID and Gid in the same OSCORE group. 4508 * Updates on group rekeying contextual with request of new Sender 4509 ID. 4511 * Signature verifiers can also retrieve Group Names and URIs. 4513 * Removed group policy about supporting Group OSCORE in pairwise 4514 mode. 4516 * Registration of the resource type rt="core.osc.gm". 4518 * Update list of requirements. 4520 * Clarifications and editorial revision. 4522 C.7. Version -07 to -08 4524 * AIF specific data model to express scope entries. 4526 * A set of roles is checked as valid when processing the Joining 4527 Request. 4529 * Updated format of 'get_pub_keys' in the Joining Request. 4531 * Payload format and default values of group policies in the Joining 4532 Response. 4534 * Updated payload format of the FETCH request to retrieve 4535 authentication credentials. 4537 * Default values for group configuration parameters. 4539 * IANA registrations to support the AIF specific data model. 4541 C.8. Version -06 to -07 4543 * Alignments with draft-ietf-core-oscore-groupcomm. 4545 * New format of 'sign_info', using the COSE capabilities. 4547 * New format of Joining Response parameters, using the COSE 4548 capabilities. 4550 * Considerations on group rekeying. 4552 * Editorial revision. 4554 C.9. Version -05 to -06 4556 * Added role of external signature verifier. 4558 * Parameter 'rsnonce' renamed to 'kdcchallenge'. 4560 * Parameter 'kdcchallenge' may be omitted in some cases. 4562 * Clarified difference between group name and OSCORE Gid. 4564 * Removed the role combination ["requester", "monitor"]. 4566 * Admit implicit scope and audience in the Authorization Request. 4568 * New format for the 'sign_info' parameter. 4570 * Scope not mandatory to include in the Joining Request. 4572 * Group policy about supporting Group OSCORE in pairwise mode. 4574 * Possible individual rekeying of a single requesting node combined 4575 with a group rekeying. 4577 * Security considerations on reusage of signature challenges. 4579 * Addressing optional requirement OPT12 from draft-ietf-ace-key- 4580 groupcomm 4582 * Editorial improvements. 4584 C.10. Version -04 to -05 4586 * Nonce N_S also in error responses to the Joining Requests. 4588 * Supporting single Access Token for multiple groups/topics. 4590 * Supporting legal requesters/responders using the 'peer_roles' 4591 parameter. 4593 * Registered and used dedicated label for TLS Exporter. 4595 * Added method for uploading a new authentication credential to the 4596 Group Manager. 4598 * Added resource and method for retrieving the current group status. 4600 * Fixed inconsistency in retrieving group keying material only. 4602 * Clarified retrieval of keying material for monitor-only members. 4604 * Clarification on incrementing version number when rekeying the 4605 group. 4607 * Clarification on what is re-distributed with the group rekeying. 4609 * Security considerations on the size of the nonces used for the 4610 signature challenge. 4612 * Added CBOR values to abbreviate role identifiers in the group. 4614 C.11. Version -03 to -04 4616 * New abstract. 4618 * Moved general content to draft-ietf-ace-key-groupcomm 4620 * Terminology: node name; node resource. 4622 * Creation and pointing at node resource. 4624 * Updated Group Manager API (REST methods and offered services). 4626 * Size of challenges 'cnonce' and 'rsnonce'. 4628 * Value of 'rsnonce' for reused or non-traditionally-posted tokens. 4630 * Removed reference to RFC 7390. 4632 * New requirements from draft-ietf-ace-key-groupcomm 4634 * Editorial improvements. 4636 C.12. Version -02 to -03 4638 * New sections, aligned with the interface of ace-key-groupcomm . 4640 * Exchange of information on the signature algorithm and related 4641 parameters, during the Token POST (Section 4.1). 4643 * Nonce 'rsnonce' from the Group Manager to the Client 4644 (Section 4.1). 4646 * Client PoP signature in the Key Distribution Request upon joining 4647 (Section 4.2). 4649 * Local actions on the Group Manager, upon a new node's joining 4650 (Section 4.2). 4652 * Local actions on the Group Manager, upon a node's leaving 4653 (Section 12). 4655 * IANA registration in ACE Groupcomm Parameters registry. 4657 * More fulfilled profile requirements (Appendix A). 4659 C.13. Version -01 to -02 4661 * Editorial fixes. 4663 * Changed: "listener" to "responder"; "pure listener" to "monitor". 4665 * Changed profile name to "coap_group_oscore_app", to reflect it is 4666 an application profile. 4668 * Added the 'type' parameter for all requests to a Join Resource. 4670 * Added parameters to indicate the encoding of authentication 4671 credentials. 4673 * Challenge-response for proof-of-possession of signature keys 4674 (Section 4). 4676 * Renamed 'key_info' parameter to 'sign_info'; updated its format; 4677 extended to include also parameters of the signature key 4678 (Section 4.1). 4680 * Code 4.00 (Bad request), in responses to joining nodes providing 4681 an invalid authentication credential (Section 4.3). 4683 * Clarifications on provisioning and checking of authentication 4684 credentials (Sections 4 and 6). 4686 * Extended discussion on group rekeying and possible different 4687 approaches (Section 7). 4689 * Extended security considerations: proof-of-possession of signature 4690 keys; collision of OSCORE Group Identifiers (Section 8). 4692 * Registered three entries in the IANA registry "Sequence Number 4693 Synchronization Method" (Section 9). 4695 * Registered one public key encoding in the "ACE Public Key 4696 Encoding" IANA registry (Section 9). 4698 C.14. Version -00 to -01 4700 * Changed name of 'req_aud' to 'audience' in the Authorization 4701 Request (Section 3.1). 4703 * Added negotiation of signature algorithm/parameters between Client 4704 and Group Manager (Section 4). 4706 * Updated format of the Key Distribution Response as a whole 4707 (Section 4.3). 4709 * Added parameter 'cs_params' in the 'key' parameter of the Key 4710 Distribution Response (Section 4.3). 4712 * New IANA registrations in the "ACE Authorization Server Request 4713 Creation Hints" registry, "ACE Groupcomm Key" registry, "OSCORE 4714 Security Context Parameters" registry and "ACE Groupcomm Profile" 4715 registry (Section 9). 4717 Acknowledgments 4719 The authors sincerely thank Christian Amsuess, Santiago Aragon, 4720 Stefan Beck, Carsten Bormann, Martin Gunnarsson, Rikard Hoeglund, 4721 Watson Ladd, Daniel Migault, Jim Schaad, Ludwig Seitz, Goeran 4722 Selander and Peter van der Stok for their comments and feedback. 4724 The work on this document has been partly supported by VINNOVA and 4725 the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home 4726 (Grant agreement 952652); and by the EIT-Digital High Impact 4727 Initiative ACTIVE. 4729 Authors' Addresses 4731 Marco Tiloca 4732 RISE AB 4733 Isafjordsgatan 22 4734 SE-164 29 Stockholm Kista 4735 Sweden 4736 Email: marco.tiloca@ri.se 4737 Jiye Park 4738 Universitaet Duisburg-Essen 4739 Schuetzenbahn 70 4740 45127 Essen 4741 Germany 4742 Email: ji-ye.park@uni-due.de 4744 Francesca Palombini 4745 Ericsson AB 4746 Torshamnsgatan 23 4747 SE-16440 Stockholm Kista 4748 Sweden 4749 Email: francesca.palombini@ericsson.com