idnits 2.17.1 draft-ietf-ace-key-groupcomm-oscore-12.txt: -(3806): 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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: As an exception, the KDC MAY NOT include the 'ecdh_info' parameter in the Token Transfer Response even if 'ecdh_info' is included in the Token Transfer Request, in case all the groups that the Client is authorized to join are signature-only groups. -- The document date (25 October 2021) is 885 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 3461, but not defined == Missing Reference: 'Tperm' is mentioned on line 3461, but not defined == Missing Reference: 'EC2' is mentioned on line 3051, but not defined == Missing Reference: 'P-256' is mentioned on line 3043, but not defined == Missing Reference: 'P-384' is mentioned on line 3047, but not defined == Missing Reference: 'P-521' is mentioned on line 3051, but not defined -- Looks like a reference, but probably isn't: '0' on line 4200 == Outdated reference: A later version (-07) exists of draft-ietf-ace-aif-03 == Outdated reference: A later version (-18) exists of draft-ietf-ace-key-groupcomm-14 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-45 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-13 ** 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 (-11) exists of draft-ietf-ace-oscore-gm-admin-04 == Outdated reference: A later version (-13) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-10) exists of draft-ietf-core-groupcomm-bis-05 == Outdated reference: A later version (-09) exists of draft-ietf-cose-cbor-encoded-cert-02 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-10 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 5 errors (**), 0 flaws (~~), 19 warnings (==), 6 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: 28 April 2022 Universitaet Duisburg-Essen 6 F. Palombini 7 Ericsson AB 8 25 October 2021 10 Key Management for OSCORE Groups in ACE 11 draft-ietf-ace-key-groupcomm-oscore-12 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 secured with Group Object Security for Constrained RESTful 19 Environments (OSCORE). This application profile delegates the 20 authentication and authorization of Clients that join an OSCORE group 21 through a Resource Server acting as Group Manager for that group. 22 This application profile leverages protocol-specific transport 23 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 28 April 2022. 44 Copyright Notice 46 Copyright (c) 2021 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 Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 63 2.1. Overview of the Joining Process . . . . . . . . . . . . . 7 64 2.2. Overview of the Group Rekeying Process . . . . . . . . . 7 65 2.2.1. Stale OSCORE Sender IDs . . . . . . . . . . . . . . . 9 66 3. Format of Scope . . . . . . . . . . . . . . . . . . . . . . . 10 67 4. Joining Node to Authorization Server . . . . . . . . . . . . 11 68 4.1. Authorization Request . . . . . . . . . . . . . . . . . . 12 69 4.2. Authorization Response . . . . . . . . . . . . . . . . . 12 70 5. Interface at the Group Manager . . . . . . . . . . . . . . . 12 71 5.1. ace-group/GROUPNAME/active . . . . . . . . . . . . . . . 13 72 5.1.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 13 73 5.2. ace-group/GROUPNAME/verif-data . . . . . . . . . . . . . 13 74 5.2.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 14 75 5.3. ace-group/GROUPNAME/stale-sids . . . . . . . . . . . . . 14 76 5.3.1. FETCH Handler . . . . . . . . . . . . . . . . . . . . 14 77 5.4. Admitted Methods . . . . . . . . . . . . . . . . . . . . 15 78 5.5. Operations Supported by Clients . . . . . . . . . . . . . 16 79 6. Token Transferring and Group Joining . . . . . . . . . . . . 17 80 6.1. Token Transferring . . . . . . . . . . . . . . . . . . . 17 81 6.1.1. 'ecdh_info' Parameter . . . . . . . . . . . . . . . . 20 82 6.1.2. 'gm_dh_pub_keys' Parameter . . . . . . . . . . . . . 22 83 6.2. Send the Joining Request . . . . . . . . . . . . . . . . 24 84 6.2.1. Value of the N_S Challenge . . . . . . . . . . . . . 25 85 6.3. Receive the Joining Request . . . . . . . . . . . . . . . 26 86 6.4. Send the Joining Response . . . . . . . . . . . . . . . . 29 87 6.5. Receive the Joining Response . . . . . . . . . . . . . . 35 88 7. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 37 89 8. Retrieve of Updated Keying Material . . . . . . . . . . . . . 39 90 8.1. Retrieve of Group Keying Material . . . . . . . . . . . . 39 91 8.2. Retrieve of Group Keying Material and OSCORE Sender ID . 39 92 9. Request to Change Individual Keying Material . . . . . . . . 40 93 10. Retrieve Public Keys of Group Members . . . . . . . . . . . . 42 94 11. Upload a New Public Key . . . . . . . . . . . . . . . . . . . 42 95 12. Retrieve the Group Manager's Public Key . . . . . . . . . . . 44 96 13. Retrieve Signature Verification Data . . . . . . . . . . . . 44 97 14. Retrieve the Group Policies . . . . . . . . . . . . . . . . . 46 98 15. Retrieve the Keying Material Version . . . . . . . . . . . . 47 99 16. Retrieve the Group Status . . . . . . . . . . . . . . . . . . 47 100 17. Retrieve Group Names . . . . . . . . . . . . . . . . . . . . 48 101 18. Leave the Group . . . . . . . . . . . . . . . . . . . . . . . 51 102 19. Removal of a Group Member . . . . . . . . . . . . . . . . . . 51 103 20. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 52 104 20.1. Sending Rekeying Messages . . . . . . . . . . . . . . . 54 105 20.2. Receiving Rekeying Messages . . . . . . . . . . . . . . 56 106 20.3. Missed Rekeying Instances . . . . . . . . . . . . . . . 57 107 20.3.1. Retrieval of Stale Sender IDs . . . . . . . . . . . 59 108 21. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 61 109 22. ACE Groupcomm Error Identifiers . . . . . . . . . . . . . . . 63 110 23. Default Values for Group Configuration Parameters . . . . . . 63 111 23.1. Common . . . . . . . . . . . . . . . . . . . . . . . . . 64 112 23.2. Group Mode . . . . . . . . . . . . . . . . . . . . . . . 64 113 23.3. Pairwise Mode . . . . . . . . . . . . . . . . . . . . . 65 114 24. Security Considerations . . . . . . . . . . . . . . . . . . . 66 115 24.1. Management of OSCORE Groups . . . . . . . . . . . . . . 66 116 24.2. Size of Nonces as Proof-of-Possesion Challenge . . . . . 67 117 24.3. Reusage of Nonces for Proof-of-Possession Input . . . . 68 118 25. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 68 119 25.1. OAuth Parameters . . . . . . . . . . . . . . . . . . . . 69 120 25.2. OAuth Parameters CBOR Mappings . . . . . . . . . . . . . 69 121 25.3. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . 70 122 25.4. ACE Groupcomm Key Types . . . . . . . . . . . . . . . . 71 123 25.5. ACE Groupcomm Profiles . . . . . . . . . . . . . . . . . 71 124 25.6. OSCORE Security Context Parameters . . . . . . . . . . . 71 125 25.7. TLS Exporter Labels . . . . . . . . . . . . . . . . . . 73 126 25.8. AIF . . . . . . . . . . . . . . . . . . . . . . . . . . 74 127 25.9. Media Type Registrations . . . . . . . . . . . . . . . . 74 128 25.10. CoAP Content-Format . . . . . . . . . . . . . . . . . . 75 129 25.11. Group OSCORE Roles . . . . . . . . . . . . . . . . . . . 75 130 25.12. CoRE Resource Type . . . . . . . . . . . . . . . . . . . 76 131 25.13. ACE Scope Semantics . . . . . . . . . . . . . . . . . . 76 132 25.14. ACE Groupcomm Errors . . . . . . . . . . . . . . . . . . 77 133 25.15. Expert Review Instructions . . . . . . . . . . . . . . . 77 134 26. References . . . . . . . . . . . . . . . . . . . . . . . . . 78 135 26.1. Normative References . . . . . . . . . . . . . . . . . . 78 136 26.2. Informative References . . . . . . . . . . . . . . . . . 82 137 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 83 138 A.1. Mandatory-to-Address Requirements . . . . . . . . . . . . 83 139 A.2. Optional-to-Address Requirements . . . . . . . . . . . . 86 140 Appendix B. Extensibility for Future COSE Algorithms . . . . . . 88 141 B.1. Format of 'ecdh_info_entry' . . . . . . . . . . . . . . . 89 142 B.2. Format of 'key' . . . . . . . . . . . . . . . . . . . . . 89 143 Appendix C. Document Updates . . . . . . . . . . . . . . . . . . 90 144 C.1. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 90 145 C.2. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 91 146 C.3. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 92 147 C.4. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 93 148 C.5. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 93 149 C.6. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 94 150 C.7. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 94 151 C.8. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 95 152 C.9. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 95 153 C.10. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 96 154 C.11. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 96 155 C.12. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 97 156 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 97 157 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 98 159 1. Introduction 161 Object Security for Constrained RESTful Environments (OSCORE) 162 [RFC8613] is a method for application-layer protection of the 163 Constrained Application Protocol (CoAP) [RFC7252], using CBOR Object 164 Signing and Encryption (COSE) 165 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs] and 166 enabling end-to-end security of CoAP payload and options. 168 As described in [I-D.ietf-core-oscore-groupcomm], Group OSCORE is 169 used to protect CoAP group communication over IP multicast 170 [I-D.ietf-core-groupcomm-bis]. This relies on a Group Manager, which 171 is responsible for managing an OSCORE group and enables the group 172 members to exchange CoAP messages secured with Group OSCORE. The 173 Group Manager can be responsible for multiple groups, coordinates the 174 joining process of new group members, and is entrusted with the 175 distribution and renewal of group keying material. 177 This document is an application profile of 178 [I-D.ietf-ace-key-groupcomm], which itself builds on the ACE 179 framework for Authentication and Authorization 180 [I-D.ietf-ace-oauth-authz]. Message exchanges among the participants 181 as well as message formats and processing follow what specified in 182 [I-D.ietf-ace-key-groupcomm] for provisioning and renewing keying 183 material in group communication scenarios, where Group OSCORE is used 184 to protect CoAP group communication over IP multicast. 186 1.1. Terminology 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 190 "OPTIONAL" in this document are to be interpreted as described in BCP 191 14 [RFC2119][RFC8174] when, and only when, they appear in all 192 capitals, as shown here. 194 Readers are expected to be familiar with: 196 * The terms and concepts described in the ACE framework for 197 authentication and authorization [I-D.ietf-ace-oauth-authz] and in 198 the Authorization Information Format (AIF) [I-D.ietf-ace-aif] to 199 express authorization information. The terminology for entities 200 in the considered architecture is defined in OAuth 2.0 [RFC6749]. 201 In particular, this includes Client (C), Resource Server (RS), and 202 Authorization Server (AS). 204 * The terms and concept related to the message formats and 205 processing specified in [I-D.ietf-ace-key-groupcomm], for 206 provisioning and renewing keying material in group communication 207 scenarios. 209 * The terms and concepts described in CBOR [RFC8949] and COSE 210 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs]. 212 * The terms and concepts described in CoAP [RFC7252] and group 213 communication for CoAP [I-D.ietf-core-groupcomm-bis]. Unless 214 otherwise indicated, the term "endpoint" is used here following 215 its OAuth definition, aimed at denoting resources such as /token 216 and /introspect at the AS, and /authz-info at the RS. This 217 document does not use the CoAP definition of "endpoint", which is 218 "An entity participating in the CoAP protocol". 220 * The terms and concepts for protection and processing of CoAP 221 messages through OSCORE [RFC8613] and through Group OSCORE 222 [I-D.ietf-core-oscore-groupcomm] in group communication scenarios. 223 These include the concept of Group Manager, as the entity 224 responsible for a set of groups where communications are secured 225 with Group OSCORE. In this document, the Group Manager acts as 226 Resource Server. 228 Additionally, this document makes use of the following terminology. 230 * Requester: member of an OSCORE group that sends request messages 231 to other members of the group. 233 * Responder: member of an OSCORE group that receives request 234 messages from other members of the group. A responder may reply 235 back, by sending a response message to the requester which has 236 sent the request message. 238 * Monitor: member of an OSCORE group that is configured as responder 239 and never replies back to requesters after receiving request 240 messages. This corresponds to the term "silent server" used in 241 [I-D.ietf-core-oscore-groupcomm]. 243 * Signature verifier: entity external to the OSCORE group and 244 intended to verify the signature of messages exchanged in the 245 group (see Sections 3.1 and 8.5 of 246 [I-D.ietf-core-oscore-groupcomm]). An authorized signature 247 verifier does not join the OSCORE group as an actual member, yet 248 it can retrieve the public keys of the current group members from 249 the Group Manager. 251 * Signature-only group: an OSCORE group that uses only the group 252 mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]). 254 * Pairwise-only group: an OSCORE group that uses only the pairwise 255 mode (see Section 9 of [I-D.ietf-core-oscore-groupcomm]). 257 2. Protocol Overview 259 Group communication for CoAP over IP multicast has been enabled in 260 [I-D.ietf-core-groupcomm-bis] and can be secured with Group Object 261 Security for Constrained RESTful Environments (OSCORE) [RFC8613] as 262 described in [I-D.ietf-core-oscore-groupcomm]. A network node joins 263 an OSCORE group by interacting with the responsible Group Manager. 264 Once registered in the group, the new node can securely exchange 265 messages with other group members. 267 This document describes how to use [I-D.ietf-ace-key-groupcomm] and 268 [I-D.ietf-ace-oauth-authz] to perform a number of authentication, 269 authorization and key distribution actions, as overviewed in 270 Section 2 of [I-D.ietf-ace-key-groupcomm], when the considered group 271 is specifically an OSCORE group. 273 With reference to [I-D.ietf-ace-key-groupcomm]: 275 * The node wishing to join the OSCORE group, i.e., the joining node, 276 is the Client. 278 * The Group Manager is the Key Distribution Center (KDC), acting as 279 a Resource Server. 281 * The Authorization Server associated to the Group Manager is the 282 AS. 284 All communications between the involved entities MUST be secured. 286 In particular, communications between the Client and the Group 287 Manager leverage protocol-specific transport profiles of ACE to 288 achieve communication security, proof-of-possession and server 289 authentication. It is expected that, in the commonly referred base- 290 case of this document, the transport profile to use is pre-configured 291 and well-known to nodes participating in constrained applications. 293 Appendix A lists the specifications on this application profile of 294 ACE, based on the requirements defined in Appendix A of 295 [I-D.ietf-ace-key-groupcomm]. 297 2.1. Overview of the Joining Process 299 A node performs the steps described in Section 4.3.1.1 of 300 [I-D.ietf-ace-key-groupcomm] in order to join an OSCORE group. The 301 format and processing of messages exchanged among the participants 302 are further specified in Section 4 and Section 6 of this document. 304 2.2. Overview of the Group Rekeying Process 306 In a number of cases, the Group Manager has to generate new keying 307 material and distribute it to the group (rekeying), as also discussed 308 in Section 3.2 of [I-D.ietf-core-oscore-groupcomm]. 310 To this end the Group Manager MUST support the Group Rekeying Process 311 described in Section 20 of this document, as an instance of the 312 "Point-to-Point" rekeying scheme defined in Section 6.1 of 313 [I-D.ietf-ace-key-groupcomm] and registered in Section 11.14 of 314 [I-D.ietf-ace-key-groupcomm]. Future documents may define the use of 315 alternative group rekeying schemes for this application profile, 316 together with the corresponding rekeying message formats. The 317 resulting group rekeying process MUST comply with the functional 318 steps defined in Section 3.2 of [I-D.ietf-core-oscore-groupcomm]. 320 Upon generating the new group keying material and before starting its 321 distribution, the Group Manager MUST increment the version number of 322 the group keying material. When rekeying a group, the Group Manager 323 MUST preserve the current value of the OSCORE Sender ID of each 324 member in that group. 326 The data distributed to a group through a rekeying MUST include: 328 * The new version number of the group keying material for the group. 330 * A new Group Identifier (Gid) for the group as introduced in 331 [I-D.ietf-ace-key-groupcomm], used as ID Context parameter of the 332 Group OSCORE Common Security Context of that group (see Section 2 333 of [I-D.ietf-core-oscore-groupcomm]). 335 Note that the Gid differs from the group name also introduced in 336 [I-D.ietf-ace-key-groupcomm], which is a plain, stable and 337 invariant identifier, with no cryptographic relevance and meaning. 339 * A new value for the Master Secret parameter of the Group OSCORE 340 Common Security Context of the group (see Section 2 of 341 [I-D.ietf-core-oscore-groupcomm]). 343 * A set of stale Sender IDs, which allows each rekeyed node to purge 344 public keys and Recipient Contexts used in the group and 345 associated to those Sender IDs. This in turn allows every group 346 member to rely on owned public keys to confidently assert the 347 group membership of other sender nodes, when receiving protected 348 messages in the group (see Section 3.2 of 349 [I-D.ietf-core-oscore-groupcomm]). More details on the 350 maintenance of stale Sender IDs are provided in Section 2.2.1. 352 Also, the data distributed through a group rekeying MAY include a new 353 value for the Master Salt parameter of the Group OSCORE Common 354 Security Context of that group. 356 The Group Manager MUST rekeying the group in the following cases. 358 * The application requires backward security - In this case, the 359 group is rekeyed when a node joins the group as a new member. 360 Therefore, a joining node cannot access communications in the 361 group prior its joining. 363 * One or more nodes leave the group - That is, the group is rekeyed 364 when one or more current members spontaneously request to leave 365 the group (see Section 18), or when the Group Manager forcibly 366 evicts them from the group, e.g., due to expired or revoked 367 authorization (see Section 19). Therefore, a leaving node cannot 368 access communications in the group after its leaving, thus 369 ensuring forward security in the group. 371 Due to the set of stale Sender IDs distributed through the 372 rekeying, this ensures that a node owning the latest group keying 373 material does not store the public keys of former group members 374 (see Sections 3.2 and 10.1 of [I-D.ietf-core-oscore-groupcomm]). 376 * Extension of group lifetime - That is, the group is rekeyed when 377 the expiration time for the group keying material approaches or 378 has passed, if it is appropriate to extend the group operation 379 beyond that. 381 The Group Manager MAY rekey the group for other reasons, e.g., 382 according to an application-dependent rekeying period or scheduling. 384 2.2.1. Stale OSCORE Sender IDs 386 Throughout the lifetime of every group, the Group Manager MUST 387 maintain a collection of stale Sender IDs for that group. 389 The collection associated to a group MUST include up to N > 1 ordered 390 sets of stale OSCORE Sender IDs. It is up to the application to 391 specify the value of N, possibly on a per-group basis. 393 The N-th set includes the Sender IDs that have become "stale" under 394 the current version V of the group keying material. The (N-1)-th set 395 refers to the immediately previous version (V - 1) of the group 396 keying material, and so on. 398 In the following cases, the Group Manager MUST add a new element to 399 the most recent set X, i.e., the set associated to the current 400 version V of the group keying material. 402 * When a current group member obtains a new Sender ID, its old 403 Sender ID is added to X. This happens when the Group Manager 404 assigns a new Sender ID upon request from the group member (see 405 Section 9), or in case the group member re-joins the group (see 406 Section 6.2 and Section 6.4), thus also obtaining a new Sender ID. 408 * When a current group member leaves the group, its current Sender 409 ID is added to X. This happens when a group member requests to 410 leave the group (see Section 18) or is forcibly evicted from the 411 group (see Section 19). 413 The value of N can change throughout the lifetime of the group. If 414 the new value N' is smaller than N, the Group Manager MUST preserve 415 the (up to) N' most recent sets in the collection and MUST delete any 416 possible older set from the collection. 418 Finally, the Group Manager MUST perform the following actions, when 419 the group is rekeyed and the group shifts to the next version V' = (V 420 + 1) of the group keying material. 422 1. The Group Manager rekeys the group. This includes also 423 distributing the set of stale Sender IDs X associated to the old 424 group keying material with version V (see Section 2.2). 426 2. After completing the group rekeying, the Group Manager creates a 427 new empty set X' associated to the new version V' of the newly 428 established group keying material, i.e., V' = (V + 1). 430 3. If the current collection of stale Sender IDs has size N, the 431 Group Manager deletes the oldest set in the collection. 433 4. The Group Manager adds the new set X' to the collection of stale 434 Sender IDs, as the most recent set. 436 3. Format of Scope 438 Building on Section 3.1 of [I-D.ietf-ace-key-groupcomm], this section 439 defines the exact format and encoding of scope to use. 441 To this end, this profile uses the Authorization Information Format 442 (AIF) [I-D.ietf-ace-aif], and defines the following AIF specific data 443 model AIF-OSCORE-GROUPCOMM. 445 With reference to the generic AIF model 447 AIF-Generic = [* [Toid, Tperm]] 449 the value of the CBOR byte string used as scope encodes the CBOR 450 array [* [Toid, Tperm]], where each [Toid, Tperm] element corresponds 451 to one scope entry. 453 Then, for each scope entry: 455 * the object identifier ("Toid") is specialized as a CBOR text 456 string, specifying the group name for the scope entry; 458 * the permission set ("Tperm") is specialized as a CBOR unsigned 459 integer with value R, specifying the role(s) that the client 460 wishes to take in the group (REQ1). The value R is computed as 461 follows: 463 - each role in the permission set is converted into the 464 corresponding numeric identifier X from the "Value" column of 465 the table in Figure 1. 467 - the set of N numbers is converted into the single value R, by 468 taking each numeric identifier X_1, X_2, ..., X_N to the power 469 of two, and then computing the inclusive OR of the binary 470 representations of all the power values. 472 +-----------+-------+-------------------------------------------------+ 473 | Name | Value | Description | 474 +===========+=======+=================================================+ 475 | Reserved | 0 | This value is reserved | 476 |-----------+-------+-------------------------------------------------+ 477 | Requester | 1 | Send requests; receive responses | 478 |-----------+-------+-------------------------------------------------+ 479 | Responder | 2 | Send responses; receive requests | 480 +-----------+-------+-------------------------------------------------+ 481 | Monitor | 3 | Receive requests; never send requests/responses | 482 |-----------+-------+-------------------------------------------------| 483 | Verifier | 4 | Verify signature of intercepted messages | 484 +-----------+-------+-------------------------------------------------+ 486 Figure 1: Numeric identifier of roles in the OSCORE group 488 The CDDL [RFC8610] definition of the AIF-OSCORE-GROUPCOMM data model 489 is as follows: 491 AIF-OSCORE-GROUPCOMM = AIF_Generic 493 path = tstr ; Group name 494 permissions = uint . bits roles 495 roles = &( 496 Requester: 1, 497 Responder: 2, 498 Monitor: 3, 499 Verifier: 4 500 ) 502 Future specifications that define new roles MUST register a 503 corresponding numeric identifier in the "Group OSCORE Roles" registry 504 defined in Section 25.11 of this document. 506 4. Joining Node to Authorization Server 508 This section describes how the joining node interacts with the AS in 509 order to be authorized to join an OSCORE group under a given Group 510 Manager. In particular, it considers a joining node that intends to 511 contact that Group Manager for the first time. 513 The message exchange between the joining node and the AS consists of 514 the messages Authorization Request and Authorization Response defined 515 in Sections 3.1 and 3.2 of [I-D.ietf-ace-key-groupcomm]. Note that 516 what is defined in [I-D.ietf-ace-key-groupcomm] applies, and only 517 additions or modifications to that specification are defined here. 519 4.1. Authorization Request 521 The Authorization Request message is as defined in Section 3.1 of 522 [I-D.ietf-ace-key-groupcomm], with the following additions. 524 * If the 'scope' parameter is present: 526 - The value of the CBOR byte string encodes a CBOR array, whose 527 format MUST follow the data model AIF-OSCORE-GROUPCOMM defined 528 in Section 3. In particular, for each OSCORE group to join: 530 o The group name is encoded as a CBOR text string. 532 o The set of requested roles is expressed as a single CBOR 533 unsigned integer, computed as defined in Section 3 from the 534 numerical abbreviations defined in Figure 1 for each 535 requested role (REQ1). 537 4.2. Authorization Response 539 The Authorization Response message is as defined in Section 3.2 of 540 [I-D.ietf-ace-key-groupcomm], with the following additions: 542 * The AS MUST include the 'expires_in' parameter. Other means for 543 the AS to specify the lifetime of Access Tokens are out of the 544 scope of this document. 546 * The AS MUST include the 'scope' parameter, when the value included 547 in the Access Token differs from the one specified by the joining 548 node in the request. In such a case, the second element of each 549 scope entry MUST be present, and specifies the set of roles that 550 the joining node is actually authorized to take in the OSCORE 551 group for that scope entry, encoded as specified in Section 4.1. 553 Furthermore, if the AS uses the extended format of scope defined in 554 Section 7 of [I-D.ietf-ace-key-groupcomm] for the 'scope' claim of 555 the Access Token, the first element of the CBOR sequence [RFC8742] 556 MUST be the CBOR integer with value SEM_ID_TBD, defined in 557 Section 25.13 of this document (REQ28). This indicates that the 558 second element of the CBOR sequence, as conveying the actual access 559 control information, follows the scope semantics defined for this 560 application profile in Section 3 of this document. 562 5. Interface at the Group Manager 564 The Group Manager provides the interface defined in Section 4.1 of 565 [I-D.ietf-ace-key-groupcomm], with the additional sub-resources 566 defined from Section 5.1 to Section 5.3 of this document. 568 Furthermore, Section 5.4 provides a summary of the CoAP methods 569 admitted to access different resources at the Group Manager, for 570 nodes with different roles in the group or as non members (REQ11). 572 The GROUPNAME segment of the URI path MUST match with the group name 573 specified in the scope entry of the Access Token scope (i.e., 'gname' 574 in Section 3.1 of [I-D.ietf-ace-key-groupcomm]) (REQ7). 576 The Resource Type (rt=) Link Target Attribute value "core.osc.gm" is 577 registered in Section 25.12 (REQ10), and can be used to describe 578 group-membership resources and its sub-resources at a Group Manager, 579 e.g., by using a link-format document [RFC6690]. 581 Applications can use this common resource type to discover links to 582 group-membership resources for joining OSCORE groups, e.g., by using 583 the approach described in [I-D.tiloca-core-oscore-discovery]. 585 5.1. ace-group/GROUPNAME/active 587 This resource implements a GET handler. 589 5.1.1. GET Handler 591 The handler expects a GET request. 593 In addition to what is defined in Section 4.1.2 of 594 [I-D.ietf-ace-key-groupcomm], the handler verifies that the 595 requesting client is a current member of the group. If the 596 verification fails, the KDC MUST reply with a 4.03 (Forbidden) error 597 response. The response MUST have Content-Format set to application/ 598 ace-groupcomm+cbor and is formatted as defined in Section 4.1.2 of 599 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be 600 set to 0 ("Operation permitted only to group members"). 602 If all verifications succeed, the handler replies with a 2.05 603 (Content) response, specifying the current status of the group, i.e., 604 active or inactive. The payload of the response is formatted as 605 defined in Section 16. 607 The method to set the current group status is out of the scope of 608 this document, and is defined for the administrator interface of the 609 Group Manager specified in [I-D.ietf-ace-oscore-gm-admin]. 611 5.2. ace-group/GROUPNAME/verif-data 613 This resource implements a GET handler. 615 5.2.1. GET Handler 617 The handler expects a GET request. 619 In addition to what is defined in Section 4.1.2 of 620 [I-D.ietf-ace-key-groupcomm], the Group Manager performs the 621 following checks. 623 If the requesting client is a current group member, the Group Manager 624 MUST reply with a 4.03 (Forbidden) error response. The response MUST 625 have Content-Format set to application/ace-groupcomm+cbor and is 626 formatted as defined in Section 4.1.2 of 627 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be 628 set to 8 ("Operation permitted only to signature verifiers"). 630 If GROUPNAME denotes a pairwise-only group, the Group Manager MUST 631 reply with a 4.00 (Bad Request) error response. The response MUST 632 have Content-Format set to application/ace-groupcomm+cbor and is 633 formatted as defined in Section 4.1.2 of 634 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be 635 set to 7 ("Signatures not used in the group"). 637 If all verifications succeed, the handler replies with a 2.05 638 (Content) response, specifying data that allows also a signature 639 verifier to verify signatures of messages protected with the group 640 mode and sent to the group (see Sections 3.1 and 8.5 of 641 [I-D.ietf-core-oscore-groupcomm]). The response MUST have Content- 642 Format set to application/ace-groupcomm+cbor. The payload of the 643 response is a CBOR map, which is formatted as defined in Section 13. 645 5.3. ace-group/GROUPNAME/stale-sids 647 This resource implements a FETCH handler. 649 5.3.1. FETCH Handler 651 The handler expects a FETCH request, whose payload specifies a 652 version number of the group keying material, encoded as an unsigned 653 CBOR integer. 655 In addition to what is defined in Section 4.1.2 of 656 [I-D.ietf-ace-key-groupcomm], the handler verifies that the 657 requesting client is a current member of the group. If the 658 verification fails, the Group Manager MUST reply with a 4.03 659 (Forbidden) error response. The response MUST have Content-Format 660 set to application/ace-groupcomm+cbor and is formatted as defined in 661 Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value of the 662 'error' field MUST be set to 0 ("Operation permitted only to group 663 members"). 665 If all verifications succeed, the handler replies with a 2.05 666 (Content) response, specifying data that allows the requesting client 667 to delete the Recipient Contexts and public keys associated to former 668 members of the group (see Section 3.2 of 669 [I-D.ietf-core-oscore-groupcomm]. The payload of the response is 670 formatted as defined in Section 20.3.1. 672 5.4. Admitted Methods 674 The table in Figure 2 summarizes the CoAP methods admitted to access 675 different resources at the Group Manager, for (non-)members of a 676 group with group name GROUPNAME, and considering different roles. 677 The last two rows of the table apply to a node with node name 678 NODENAME. 680 +---------------------------------+--------+-------+-------+-------+ 681 | Resource | Type1 | Type2 | Type3 | Type4 | 682 +---------------------------------+--------+-------+-------+-------+ 683 | ace-group/ | F | F | F | F | 684 +---------------------------------+--------+-------+-------+-------+ 685 | ace-group/GROUPNAME/ | G Po | G Po | Po * | Po | 686 +---------------------------------+--------+-------+-------+-------+ 687 | ace-group/GROUPNAME/active | G | G | - | - | 688 +---------------------------------+--------+-------+-------+-------+ 689 | ace-group/GROUPNAME/verif-data | - | - | G | - | 690 +---------------------------------+--------+-------+-------+-------+ 691 | ace-group/GROUPNAME/pub-key | G F | G F | G F | - | 692 +---------------------------------+--------+-------+-------+-------+ 693 | ace-group/GROUPNAME/kdc-pub-key | G | G | G | - | 694 +---------------------------------+--------+-------+-------+-------+ 695 | ace-group/GROUPNAME/stale-sids | F | F | - | - | 696 +---------------------------------+--------+-------+-------+-------+ 697 | ace-group/GROUPNAME/policies | G | G | - | - | 698 +---------------------------------+--------+-------+-------+-------+ 699 | ace-group/GROUPNAME/num | G | G | - | - | 700 +---------------------------------+--------+-------+-------+-------+ 701 | ace-group/GROUPNAME/nodes/ | G Pu D | G D | - | - | 702 | NODENAME | | | | | 703 +---------------------------------+--------+-------+-------+-------+ 704 | ace-group/GROUPNAME/nodes/ | Po | - | - | - | 705 | NODENAME/pub-key | | | | | 706 +---------------------------------+--------+-------+-------+-------+ 708 Type1 = Member as Requester and/or Responder | G = GET 709 Type2 = Member as Monitor | F = FETCH 710 Type3 = Non-member (authorized to be Verifier) | Po = POST 711 (*) = cannot join the group as Verifier | Pu = PUT 712 Type4 = Non-member (not authorized to be Verifier) | D = DELETE 714 Figure 2: Admitted CoAP Methods on the Group Manager Resources 716 5.5. Operations Supported by Clients 718 Building on what is defined in Section 4.1.1 of 719 [I-D.ietf-ace-key-groupcomm], and with reference to the resources at 720 the Group Manager newly defined earlier in Section 5 of this 721 document, it is expected that a Client minimally supports also the 722 following set of operations and corresponding interactions with the 723 Group (REQ12). 725 * GET request to ace-group/GROUPNAME/active , in order to check the 726 current status of the group. 728 * GET request to ace-group/GROUPNAME/verif-data , in order for a 729 signature verifier to retrieve data required to verify signatures 730 of messages protected with the group mode of Group OSCORE and sent 731 to a group (see Sections 3.1 and 8.5 of 732 [I-D.ietf-core-oscore-groupcomm]). Note that this operation is 733 relevant to support only to signature verifiers. 735 * FETCH request to ace-group/GROUPNAME/stale-sids , in order to 736 retrieve from the Group Manager the data required to delete some 737 of the stored group members' public keys and Recipient Contexts 738 (see Section 5.3.1). This data is provided as an aggregated set 739 of stale Sender IDs, which are used as specified in Section 20.3. 741 6. Token Transferring and Group Joining 743 The rest of this section describes the interactions between the 744 joining node and the Group Manager, i.e., the transferring of the 745 Access Token to the Group Manager and the Request-Response exchange 746 to join the OSCORE group. The message exchange between the joining 747 node and the Group Manager consists of the messages defined in 748 Sections 3.3 and 4.3.1.1 of [I-D.ietf-ace-key-groupcomm]. Note that 749 what is defined in [I-D.ietf-ace-key-groupcomm] applies, and only 750 additions or modifications to that specification are defined here. 752 Just like any candidate group member, a signature verifier provides 753 the Group Manager with an Access Token, as described in Section 6.1. 754 However, unlike candidate group members, it does not join any OSCORE 755 group, i.e., it does not perform the joining process defined in 756 Section 6.2. 758 After successfully transferring an Access Token to the Group Manager, 759 a signature verifier is allowed to perform only some operations as 760 non-member of a group, and only for the OSCORE groups specified in 761 the validated Access Token. These are the operations specified in 762 Section 10, Section 12, Section 13 and Section 17. 764 Consistently, in case a node is non-member of the group with group 765 name GROUPNAME and is authorized to be only signature verifier for 766 that group, the Group Manager MUST reply with a 4.03 (Forbidden) 767 error response if that node attempts to access any other endpoint 768 than: /ace-group/GROUPNAME/pub-key; ace-group/GROUPNAME/gm-pub-key; 769 ace-group/GROUPNAME/verif-data; and /ace-group. 771 6.1. Token Transferring 773 The exchange of Token Transfer Request and Response is defined in 774 Section 3.3 of [I-D.ietf-ace-key-groupcomm]. In addition to that, 775 the following applies. 777 * The Token Transfer Request MAY additionally contain the following 778 parameters, which, if included, MUST have the corresponding values 779 (OPT2): 781 - 'ecdh_info' defined in Section 6.1.1 of this document, with 782 value the CBOR simple value 'null' (0xf6) to request 783 information about the ECDH algorithm, the ECDH algorithm 784 parameters, the ECDH key parameters and about the exact 785 encoding of public keys used in the groups that the client has 786 been authorized to join. This is relevant in case the joining 787 node supports the pairwise mode of Group OSCORE 788 [I-D.ietf-core-oscore-groupcomm]. 790 - 'gm_dh_pub_keys' defined in Section 6.1.2 of this document, 791 with value the CBOR simple value 'null' (0xf6) to request the 792 Diffie-Hellman public keys of the Group Manager in the groups 793 that the client has been authorized to join. This is relevant 794 in case the joining node supports the pairwise mode of Group 795 OSCORE [I-D.ietf-core-oscore-groupcomm]. 797 Alternatively, the joining node may retrieve this information by 798 other means. 800 * The 'kdcchallenge' parameter contains a dedicated nonce N_S 801 generated by the Group Manager. For the N_S value, it is 802 RECOMMENDED to use a 8-byte long random nonce. The joining node 803 can use this nonce in order to prove the possession of its own 804 private key, upon joining the group (see Section 6.2). 806 The 'kdcchallenge' parameter MAY be omitted from the Token 807 Transfer Response, if the 'scope' of the Access Token specifies 808 only the role "monitor" or only the role "verifier" or only a 809 combination of the two, for each and every of the specified 810 groups. 812 * If the 'sign_info' parameter is present in the response, the 813 following applies for each element 'sign_info_entry'. 815 - 'id' MUST NOT refer to OSCORE groups that are pairwise-only 816 groups. 818 - 'sign_alg' takes value from the "Value" column of the "COSE 819 Algorithms" registry [COSE.Algorithms]. 821 - 'sign_parameters' is a CBOR array. Its format and value are 822 the same of the COSE capabilities array for the algorithm 823 indicated in 'sign_alg', as specified for that algorithm in the 824 "Capabilities" column of the "COSE Algorithms" registry 825 [COSE.Algorithms] (REQ4). 827 - 'sign_key_parameters' is a CBOR array. Its format and value 828 are the same of the COSE capabilities array for the COSE key 829 type of the keys used with the algorithm indicated in 830 'sign_alg', as specified for that key type in the 831 "Capabilities" column of the "COSE Key Types" registry 832 [COSE.Key.Types] (REQ5). 834 - 'pub_key_enc' takes value from the "Label" column of the "COSE 835 Header Parameters" registry [COSE.Header.Parameters] (REQ6). 836 Consistently with Section 2.3 of 837 [I-D.ietf-core-oscore-groupcomm], acceptable values denote an 838 encoding that MUST explicitly provide the full set of 839 information related to the public key algorithm, including, 840 e.g., the used elliptic curve (when applicable). 842 At the time of writing this specification, acceptable public 843 key encodings are CBOR Web Tokens (CWTs) and CWT Claims Sets 844 (CCSs) [RFC8392], X.509 certificates [RFC7925] and C509 845 certificates [I-D.ietf-cose-cbor-encoded-cert]. Further 846 encodings may be available in the future, and would be 847 acceptable to use as long as they comply with the criteria 848 defined above. 850 [ As to CWTs and CCSs, the COSE Header Parameters 'kcwt' and 851 'kccs' are under pending registration requested by draft-ietf- 852 lake-edhoc. ] 854 [ As to C509 certificates, the COSE Header Parameters 'c5b' and 855 'c5c' are under pending registration requested by draft-ietf- 856 cose-cbor-encoded-cert. ] 858 This format is consistent with every signature algorithm currently 859 considered in [I-D.ietf-cose-rfc8152bis-algs], i.e., with 860 algorithms that have only the COSE key type as their COSE 861 capability. Appendix B of [I-D.ietf-ace-key-groupcomm] describes 862 how the format of each 'sign_info_entry' can be generalized for 863 possible future registered algorithms having a different set of 864 COSE capabilities. 866 * If 'ecdh_info' is included in the Token Transfer Request, the 867 Group Manager SHOULD include the 'ecdh_info' parameter in the 868 Token Transfer Response, as per the format defined in 869 Section 6.1.1. Note that the field 'id' of each 'ecdh_info_entry' 870 specifies the name, or array of group names, for which that 871 'ecdh_info_entry' applies to. 873 As an exception, the KDC MAY NOT include the 'ecdh_info' parameter 874 in the Token Transfer Response even if 'ecdh_info' is included in 875 the Token Transfer Request, in case all the groups that the Client 876 is authorized to join are signature-only groups. 878 * If 'gm_dh_pub_keys' is included in the Token Transfer Request and 879 any of the groups that the client has been authorized to join is a 880 pairwise-only group, then the Group Manager MUST include the 881 'gm_dh_pub_keys' parameter in the Token Transfer Response, as per 882 the format defined in Section 6.1.2. Otherwise, if 883 'gm_dh_pub_keys' is included in the Token Transfer Request, the 884 Group Manager MAY include the 'gm_dh_pub_keys' parameter in the 885 Token Transfer Response. Note that the field 'id' specifies the 886 group name, or array of group names, for which the corresponding 887 'gm_dh_pub_keys' applies to. 889 Note that, other than through the above parameters as defined in 890 Section 3.3 of [I-D.ietf-ace-key-groupcomm], the joining node may 891 have obtained such information by alternative means. For example, 892 information conveyed in the 'sign_info' and 'ecdh_info' parameters 893 may have been pre-configured, or the joining node MAY early retrieve 894 it by using the approach described in 895 [I-D.tiloca-core-oscore-discovery], to discover the OSCORE group and 896 the link to the associated group-membership resource at the Group 897 Manager (OPT3). 899 6.1.1. 'ecdh_info' Parameter 901 The 'ecdh_info' parameter is an OPTIONAL parameter of the request and 902 response messages exchanged between the client and the authz-info 903 endpoint at the RS (see Section 5.10.1. of 904 [I-D.ietf-ace-oauth-authz]). 906 This parameter allows the client and the RS to exchange information 907 about an ECDH algorithm and about public keys to accordingly use for 908 deriving Diffie-Hellman secrets. Its exact semantics and content are 909 application specific. 911 In this application profile, this parameter is used to exchange 912 information about the ECDH algorithm and about public keys to be used 913 with it, in the groups indicated by the transferred Acces Token as 914 per its 'scope' claim (see Section 3.2 of 915 [I-D.ietf-ace-key-groupcomm]). 917 When used in the Token Transfer Request sent to the Group Manager, 918 the 'ecdh_info' parameter has value the CBOR simple value 'null' 919 (0xf6). This is done to ask for information about the ECDH algorithm 920 and about the public keys to be used to compute static-static Diffie- 921 Hellman shared secrets [NIST-800-56A], in the OSCORE groups that the 922 client has been authorized to join and that use the pairwise mode of 923 Group OSCORE [I-D.ietf-core-oscore-groupcomm]. 925 When used in the following Token Transfer Response from the Group 926 Manager, the 'ecdh_info' parameter is a CBOR array of one or more 927 elements. The number of elements is at most the number of OSCORE 928 groups that the client has been authorized to join. 930 Each element contains information about ECDH parameters and about 931 public keys, for one or more OSCORE groups that use the pairwise mode 932 of Group OSCORE and that the client has been authorized to join. 933 Each element is formatted as follows. 935 * The first element 'id' is the group name of the OSCORE group or an 936 array of group names for the OSCORE groups for which the specified 937 information applies. In particular 'id' MUST NOT refer to OSCORE 938 groups that are signature-only groups. 940 * The second element 'ecdh_alg' is a CBOR integer or a CBOR text 941 string indicating the ECDH algorithm used in the OSCORE group 942 identified by 'gname'. Values are taken from the "Value" column 943 of the "COSE Algorithms" registry [COSE.Algorithms]. 945 * The third element 'ecdh_parameters' is a CBOR array indicating the 946 parameters of the ECDH algorithm used in the OSCORE group 947 identified by 'gname'. Its format and value are the same of the 948 COSE capabilities array for the algorithm indicated in 'ecdh_alg', 949 as specified for that algorithm in the "Capabilities" column of 950 the "COSE Algorithms" registry [COSE.Algorithms]. 952 * The fourth element 'ecdh_key_parameters' is a CBOR array 953 indicating the parameters of the keys used with the ECDH algorithm 954 in the OSCORE group identified by 'gname'. Its content depends on 955 the value of 'ecdh_alg'. In particular, its format and value are 956 the same of the COSE capabilities array for the COSE key type of 957 the keys used with the algorithm indicated in 'ecdh_alg', as 958 specified for that key type in the "Capabilities" column of the 959 "COSE Key Types" registry [COSE.Key.Types]. 961 * The fifth element 'pub_key_enc' is a CBOR integer indicating the 962 encoding of public keys used in the OSCORE group identified by 963 'gname'. It takes value from the "Label" column of the "COSE 964 Header Parameters" registry [COSE.Header.Parameters] (REQ6). 966 Acceptable values denote an encoding that MUST explicitly provide 967 the full set of information related to the public key algorithm, 968 including, e.g., the used elliptic curve (when applicable). The 969 same considerations and guidelines for the 'pub_key_enc' element 970 of 'sign_info' (see Section 6.1) apply. 972 The CDDL notation [RFC8610] of the 'ecdh_info' parameter is given 973 below. 975 ecdh_info = ecdh_info_req / ecdh_info_resp 977 ecdh_info_req = nil ; in the Token Transfer 978 ; Request to the KDC 980 ecdh_info_res = [ + ecdh_info_entry ] ; in the Token Transfer 981 ; Response from the KDC 983 ecdh_info_entry = 984 [ 985 id : gname / [ + gname ], 986 ecdh_alg : int / tstr, 987 ecdh_parameters : [ any ], 988 ecdh_key_parameters : [ any ], 989 pub_key_enc = int 990 ] 992 gname = tstr 994 This format is consistent with every ECDH algorithm currently defined 995 in [I-D.ietf-cose-rfc8152bis-algs], i.e., with algorithms that have 996 only the COSE key type as their COSE capability. Appendix B of this 997 document describes how the format of each 'ecdh_info_entry' can be 998 generalized for possible future registered algorithms having a 999 different set of COSE capabilities. 1001 6.1.2. 'gm_dh_pub_keys' Parameter 1003 The 'gm_dh_pub_keys' parameter is an OPTIONAL parameter of the 1004 request and response messages exchanged between the Client and the 1005 authz-info endpoint at the RS (see Section 5.10.1. of 1006 [I-D.ietf-ace-oauth-authz]). 1008 This parameter allows the client to request and retrieve the Diffie- 1009 Hellman public keys of the RS. 1011 In this application profile, this parameter is used to request and 1012 retrieve from the Group Manager its Diffie-Hellman public keys to 1013 use, in the OSCORE groups that the client has been authorized to 1014 join. The Group Manager has specifically a Diffie-Hellman public key 1015 in an OSCORE group, if and only if the group is a pairwise-only 1016 group. In this case, the early retrieval of the Group Manager's 1017 public key is necessary in order for the joining node to prove the 1018 possession of its own private key, upon joining the group (see 1019 Section 6.2). 1021 When used in the Token Transfer Request sent to the Group Manager, 1022 the 'gm_dh_pub_keys' parameter has value the CBOR simple value 'null' 1023 (0xf6). This is done to ask for the Diffie-Hellman public keys that 1024 the Group Manager uses in the OSCORE groups that the client has been 1025 authorized to join. 1027 When used in the following Token Transfer Response from the Group 1028 Manager, the 'gm_dh_pub_keys' parameter is a CBOR array of one or 1029 more elements. The number of elements is at most the number of 1030 OSCORE groups that the client has been authorized to join. 1032 Each element 'gm_dh_pub_keys_entry' contains information about the 1033 Group Manager's Diffie-Hellman public keys, for one or more OSCORE 1034 groups that are pairwise-only groups and that the client has been 1035 authorized to join. Each element is formatted as follows. 1037 * The first element 'id' is the group name of the OSCORE group or an 1038 array of group names for the OSCORE groups for which the specified 1039 information applies. In particular 'id' MUST refer exclusively to 1040 OSCORE groups that are pairwise-only groups. 1042 * The second element 'pub_key_enc' is a CBOR integer indicating the 1043 encoding of public keys used in the OSCORE group identified by 1044 'gname'. It takes value from the "Label" column of the "COSE 1045 Header Parameters" registry [COSE.Header.Parameters] (REQ6). 1046 Acceptable values denote an encoding that MUST explicitly provide 1047 the full set of information related to the public key algorithm, 1048 including, e.g., the used elliptic curve (when applicable). The 1049 same considerations and guidelines for the 'pub_key_enc' element 1050 of 'sign_info' (see Section 6.1) apply. 1052 * The third element 'pub_key' is a CBOR byte string, which encodes 1053 the Group Manager's Diffie-Hellman public key in its original 1054 binary representation made available to other endpoints in the 1055 group. In particular, the original binary representation complies 1056 with the encoding specified by the 'pub_key_enc' parameter. Note 1057 that the public key provides the full set of information related 1058 to its public key algorithm, i.e., the ECDH algorithm used in the 1059 OSCORE group as pairwise key agreement algorithm. 1061 The CDDL notation [RFC8610] of the 'gm_dh_pub_keys' parameter is 1062 given below. 1064 gm_dh_pub_keys = gm_dh_pub_keys_req / gm_dh_pub_keys_resp 1066 gm_dh_pub_keys_req = nil ; in the Token 1067 ; Transfer Request to 1068 ; the Group Manager 1070 gm_dh_pub_keys_res = [ + gm_dh_pub_keys_entry ] ; in the Token 1071 ; Transfer Response 1072 ; from the Group 1073 ; Manager 1075 gm_dh_pub_keys_entry = 1076 [ 1077 id : gname / [ + gname ], 1078 pub_key_enc = int, 1079 pub_key = bstr 1080 ] 1082 gname = tstr 1084 6.2. Send the Joining Request 1086 The joining node requests to join the OSCORE group by sending a 1087 Joining Request message to the related group-membership resource at 1088 the Group Manager, as per Section 4.3.1.1 of 1089 [I-D.ietf-ace-key-groupcomm]. 1091 Additionally to what defined in Section 4.3.1 of 1092 [I-D.ietf-ace-key-groupcomm], the following applies. 1094 * The 'scope' parameter MUST be included. Its value encodes one 1095 scope entry with the format defined in Section 3, indicating the 1096 group name and the role(s) that the joining node wants to take in 1097 the group. 1099 * The 'get_pub_keys' parameter is present only if the joining node 1100 wants to retrieve the public keys of the group members from the 1101 Group Manager during the joining process (see Section 7). 1102 Otherwise, this parameter MUST NOT be present. 1104 If this parameter is present and its value is non-null, each 1105 element of the inner CBOR array 'role_filter' is encoded as a CBOR 1106 unsigned integer, with the same value of a permission set 1107 ("Tperm") indicating that role or combination of roles in a scope 1108 entry, as defined in Section 3. 1110 * 'cnonce' contains a dedicated nonce N_C generated by the joining 1111 node. For the N_C value, it is RECOMMENDED to use a 8-byte long 1112 random nonce. 1114 * The proof-of-possession (PoP) evidence included in 1115 'client_cred_verify' is computed as defined below (REQ14). In 1116 either case, the N_S used to build the PoP input is as defined in 1117 Section 6.2.1. 1119 - If the group is not a pairwise-only group, the PoP evidence 1120 MUST be a signature. The joining node computes the signature 1121 by using the same private key and signature algorithm it 1122 intends to use for signing messages in the OSCORE group. 1124 - If the group is a pairwise-only group, the PoP evidence MUST be 1125 a MAC computed as follows, by using the HKDF Algorithm HKDF 1126 SHA-256, which consists of composing the HKDF-Extract and HKDF- 1127 Expand steps [RFC5869]. 1129 MAC = HKDF(salt, IKM, info, L) 1131 The input parameters of HKDF are as follows. 1133 o salt takes as value the empty byte string. 1135 o IKM is computed as a cofactor Diffie-Hellman shared secret, 1136 see Section 5.7.1.2 of [NIST-800-56A], using the ECDH 1137 algorithm used in the OSCORE group. The joining node uses 1138 its own Diffie-Hellman private key and the Diffie-Hellman 1139 public key of the Group Manager. For X25519 and X448, the 1140 procedure is described in Section 5 of [RFC7748]. 1142 o info takes as value the PoP input. 1144 o L is equal to 8, i.e., the size of the MAC, in bytes. 1146 6.2.1. Value of the N_S Challenge 1148 The value of the N_S challenge is determined as follows. 1150 1. If the joining node has provided the Access Token to the Group 1151 Manager by means of a Token Transfer Request to the /authz-info 1152 endpoint as in Section 6.1, then N_S takes the same value of the 1153 most recent 'kdcchallenge' parameter received by the joining node 1154 from the Group Manager. This can be either the one specified in 1155 the Token Transfer Response, or the one possibly specified in a 1156 4.00 (Bad Request) error response to a following Joining Request 1157 (see Section 6.3). 1159 2. If the provisioning of the Access Token to the Group Manager has 1160 relied on the DTLS profile of ACE [I-D.ietf-ace-dtls-authorize] 1161 with the Access Token as content of the "psk_identity" field of 1162 the ClientKeyExchange message [RFC6347], N_S is an exporter value 1163 computed as defined in Section 7.5 of [RFC8446]. Specifically, 1164 N_S is exported from the DTLS session between the joining node 1165 and the Group Manager, using an empty 'context_value', 32 bytes 1166 as 'key_length', and the exporter label "EXPORTER-ACE-Sign- 1167 Challenge-coap-group-oscore-app" defined in Section 25.7 of this 1168 document. 1170 It is up to applications to define how N_S is computed in further 1171 alternative settings. 1173 Section 24.3 provides security considerations on the reusage of the 1174 N_S challenge. 1176 6.3. Receive the Joining Request 1178 The Group Manager processes the Joining Request as defined in 1179 Section 4.3.1 of [I-D.ietf-ace-key-groupcomm], with the following 1180 additions. 1182 * The Group Manager MUST return a 5.03 (Service Unavailable) 1183 response in case the OSCORE group that the joining node has been 1184 trying to join is currently inactive (see Section 5.1). The 1185 response MUST have Content-Format set to application/ace- 1186 groupcomm+cbor and is formatted as defined in Section 4.1.2 of 1187 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST 1188 be set to 9 ("Group currently not active"). 1190 * In case the joining node is not going to join the group 1191 exclusively as monitor, the Group Manager MUST return a 5.03 1192 (Service Unavailable) response if there are currently no OSCORE 1193 Sender IDs available to assign in the OSCORE group. The response 1194 MUST have Content-Format set to application/ace-groupcomm+cbor and 1195 is formatted as defined in Section 4.1.2 of 1196 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST 1197 be set to 4 ("No available node identifiers"). 1199 * In case the joining node is not going to join the group 1200 exclusively as monitor and the Joining Request does not include 1201 the 'client_cred' parameter, the joining process fails if the 1202 Group Manager either: i) does not store a public key with an 1203 accepted format for the joining node; or ii) stores multiple 1204 public keys with an accepted format for the joining node. 1206 * In order to verify the PoP evidence contained in 1207 'client_cred_verify', the Group Manager proceeds as follows. 1209 - As PoP input, the Group Manager uses the value of the 'scope' 1210 parameter from the Joining Request as a CBOR byte string, 1211 concatenated with N_S encoded as a CBOR byte string, 1212 concatenated with N_C encoded as a CBOR byte string. In 1213 particular, N_S is determined as described in Section 6.2.1, 1214 while N_C is the nonce provided in the 'cnonce' parameter of 1215 the Joining Request; 1217 - As public key of the joining node, the Group Manager uses 1218 either the one retrieved from the 'client_cred' parameter of 1219 the Joining Request, or the one already stored as acquired from 1220 previous interactions with the joining node. 1222 - The Group Manager verifies the PoP evidence as defined below. 1224 o If the group is not a pairwise-only group, the PoP evidence 1225 is a signature. The Group Manager verifies it by using the 1226 public key of the joining node, as well as the signature 1227 algorithm used in the OSCORE group and possible 1228 corresponding parameters. 1230 o If the group is a pairwise-only group, the PoP evidence is a 1231 MAC. The Group Manager recomputes the MAC through the same 1232 process taken by the joining node when preparing the value 1233 of the 'client_cred_verify' parameter for the Joining 1234 Request (see Section 6.2), with the difference that the 1235 Group Manager uses its own Diffie-Hellman private key and 1236 the Diffie-Hellman public key of the joining node. The 1237 verification succeeds if and only if the recomputed MAC is 1238 equal to the MAC conveyed as PoP evidence in the Joining 1239 Request. 1241 * A 4.00 (Bad Request) error response from the Group Manager to the 1242 joining node MUST have content format application/ace- 1243 groupcomm+cbor. The response payload is a CBOR map formatted as 1244 follows. 1246 - If the group uses (also) the group mode of Group OSCORE, the 1247 CBOR map MUST contain the 'sign_info' parameter, whose CBOR 1248 label is defined in Section 8 of [I-D.ietf-ace-key-groupcomm]. 1249 This parameter has the same format of 'sign_info_res' defined 1250 in Section 3.3.1 of [I-D.ietf-ace-key-groupcomm]. In 1251 particular, it includes a single element 'sign_info_entry' 1252 pertaining to the OSCORE group that the joining node has tried 1253 to join with the Joining Request. 1255 - If the group uses (also) the pairwise mode of Group OSCORE, the 1256 CBOR map MUST contain the 'ecdh_info' parameter, whose CBOR 1257 label is defined in Section 25.3. This parameter has the same 1258 format of 'ecdh_info_res' defined in Section 6.1.1. In 1259 particular, it includes a single element 'ecdh_info_entry' 1260 pertaining to the OSCORE group that the joining node has tried 1261 to join with the Joining Request. 1263 - If the group is a pairwise-only group, the CBOR map MUST 1264 contain the 'gm_dh_pub_keys' parameter, whose CBOR label is 1265 defined in Section 25.3. This parameter has the same format of 1266 'gm_dh_pub_keys_res' defined in Section 6.1.2. In particular, 1267 it includes a single element 'gm_dh_pub_keys_entry' pertaining 1268 to the OSCORE group that the joining node has tried to join 1269 with the Joining Request. 1271 - The CBOR map MAY include the 'kdcchallenge' parameter, whose 1272 CBOR label is defined in Section 8 of 1273 [I-D.ietf-ace-key-groupcomm]. If present, this parameter is a 1274 CBOR byte string, which encodes a newly generated 1275 'kdcchallenge' value that the Client can use when preparing a 1276 Joining Request (see Section 6.2). In such a case the Group 1277 Manager MUST store the newly generated value as the 1278 'kdcchallenge' value associated to the joining node, possibly 1279 replacing the currently stored value. 1281 * The Group Manager MUST reply with a 4.00 (Bad Request) error 1282 response in case the 'scope' parameter is not present in the 1283 Joining Request, or if it is present and specifies any set of 1284 roles not included in the following list: "requester", 1285 "responder", "monitor", ("requester", "responder"). Future 1286 specifications that define a new role MUST define possible sets of 1287 roles including the new one and existing ones, that are acceptable 1288 to specify in the 'scope' parameter of a Joining Request. 1290 * The Group Manager MUST reply with a 4.00 (Bad Request) error 1291 response in case the Joining Request includes the 'client_cred' 1292 parameter but does not include both the 'cnonce' and 1293 'client_cred_verify' parameters. 1295 * The Group Manager MUST reply with a 4.00 (Bad Request) error 1296 response in case an eligible public key for the joining node is 1297 neither present in the 'client_cred' parameter nor already stored. 1299 * The Group Manager MAY reply with a 4.00 (Bad Request) error 1300 response in case all the following conditions hold. 1302 - The OSCORE group uses the pairwise mode of Group OSCORE. 1304 - The OSCORE group uses EdDSA public keys [RFC8032]. 1306 - The public key of the joining node from the 'client_cred' 1307 parameter: 1309 o Is for the elliptic curve Ed25519 and has its Y coordinate 1310 equal to -1 or 1 (mod p), with p = (2^255 - 19), see 1311 Section 4.1 of [RFC7748]; or 1313 o Is for the elliptic curve Ed448 and has its Y coordinate 1314 equal to -1 or 1 (mod p), with p = (2^448 - 2^224 - 1), see 1315 Section 4.2 of [RFC7748]. 1317 This prevents the acceptance of Ed25519 and Ed448 public keys that 1318 cannot be successfully converted to Montgomery coordinates, and 1319 thus cannot be used for the derivation of pairwise keys (see 1320 Section 2.4.1 of [I-D.ietf-core-oscore-groupcomm]). 1322 * When receiving a 4.00 (Bad Request) error response, the joining 1323 node SHOULD send a new Joining Request to the Group Manager, 1324 where: 1326 - The 'cnonce' parameter MUST include a new dedicated nonce N_C 1327 generated by the joining node. 1329 - The 'client_cred' parameter MUST include a public key 1330 compatible with the encoding, signature or ECDH algorithm, and 1331 possible associated parameters indicated by the Group Manager. 1333 - The 'client_cred_verify' parameter MUST include a PoP evidence 1334 computed as described in Section 6.2, by using the public key 1335 indicated in the current 'client_cred' parameter, with the 1336 signature or ECDH algorithm, and possible associated parameters 1337 indicated by the Group Manager. If the error response from the 1338 Group Manager includes the 'kdcchallenge' parameter, the 1339 joining node MUST use its content as new N_S challenge to 1340 compute the PoP evidence. 1342 6.4. Send the Joining Response 1344 If the processing of the Joining Request described in Section 6.3 is 1345 successful, the Group Manager updates the group membership by 1346 registering the joining node NODENAME as a new member of the OSCORE 1347 group GROUPNAME, as described in Section 4.3.1 of 1348 [I-D.ietf-ace-key-groupcomm]. 1350 If the joining node has not taken exclusively the role of monitor, 1351 the Group Manager performs also the following actions. 1353 * The Group Manager selects an available OSCORE Sender ID in the 1354 OSCORE group, and exclusively assigns it to the joining node. The 1355 Group Manager MUST NOT assign an OSCORE Sender ID to the joining 1356 node if this joins the group exclusively with the role of monitor, 1357 according to what specified in the Access Token (see Section 4.2). 1359 Consistently with Section 3.2.1 of 1360 [I-D.ietf-core-oscore-groupcomm], the Group Manager MUST assign an 1361 OSCORE Sender ID that has not been used in the OSCORE group since 1362 the latest time when the current Gid value was assigned to the 1363 group. 1365 If the joining node is recognized as a current group member, e.g., 1366 through the ongoing secure communication association, the 1367 following also applies. 1369 - The Group Manager MUST assign a new OSCORE Sender ID different 1370 than the one currently used by the joining node in the OSCORE 1371 group. 1373 - The Group Manager MUST add the old, relinquished OSCORE Sender 1374 ID of the joining node to the most recent set of stale Sender 1375 IDs, in the collection associated to the group (see 1376 Section 2.2.1). 1378 * The Group Manager stores the association between i) the public key 1379 of the joining node; and ii) the Group Identifier (Gid), i.e., the 1380 OSCORE ID Context, associated to the OSCORE group together with 1381 the OSCORE Sender ID assigned to the joining node in the group. 1382 The Group Manager MUST keep this association updated over time. 1384 Then, the Group Manager replies to the joining node, providing the 1385 updated security parameters and keying meterial necessary to 1386 participate in the group communication. This success Joining 1387 Response is formatted as defined in Section 4.3.1 of 1388 [I-D.ietf-ace-key-groupcomm], with the following additions: 1390 * The 'gkty' parameter identifies a key of type 1391 "Group_OSCORE_Input_Material object", defined in Section 25.4 of 1392 this document. 1394 * The 'key' parameter includes what the joining node needs in order 1395 to set up the Group OSCORE Security Context as per Section 2 of 1396 [I-D.ietf-core-oscore-groupcomm]. 1398 This parameter has as value a Group_OSCORE_Input_Material object, 1399 which is defined in this document and extends the 1400 OSCORE_Input_Material object encoded in CBOR as defined in 1401 Section 3.2.1 of [I-D.ietf-ace-oscore-profile]. In particular, it 1402 contains the additional parameters 'group_senderId', 1403 'pub_key_enc', 'sign_enc_alg', 'sign_alg', 'sign_params', 1404 'ecdh_alg' and 'ecdh_params' defined in Section 25.6 of this 1405 document. 1407 More specifically, the 'key' parameter is composed as follows. 1409 - The 'hkdf' parameter, if present, has as value the HKDF 1410 Algorithm used in the OSCORE group. This parameter MAY be 1411 omitted, if the HKDF Algorithm used in the group is HKDF SHA- 1412 256. Otherwise, this parameter MUST be present. 1414 - The 'salt' parameter, if present, has as value the OSCORE 1415 Master Salt used in the OSCORE group. This parameter MAY be 1416 omitted, if the Master Salt used in the group is the empty byte 1417 string. Otherwise, this parameter MUST be present. 1419 - The 'ms' parameter includes the OSCORE Master Secret value used 1420 in the OSCORE group. This parameter MUST be present. 1422 - The 'contextId' parameter MUST be present and has as value the 1423 Group Identifier (Gid), i.e., the OSCORE ID Context of the 1424 OSCORE group. This parameter MUST be present. 1426 - The 'group_senderId' parameter, if present, has as value the 1427 OSCORE Sender ID assigned to the joining node by the Group 1428 Manager, as described above. This parameter MUST NOT be 1429 present if the node joins the OSCORE group exclusively with the 1430 role of monitor, according to what specified in the Access 1431 Token (see Section 4.2). In any other case, this parameter 1432 MUST be present. 1434 - The 'pub_key_enc' parameter MUST be present and specifies the 1435 encoding of public keys used in the OSCORE group. It takes 1436 value from the "Label" column of the "COSE Header Parameters" 1437 registry [COSE.Header.Parameters] (REQ6). Consistently with 1438 Section 2.3 of [I-D.ietf-core-oscore-groupcomm], acceptable 1439 values denote an encoding that MUST explicitly provide the full 1440 set of information related to the public key algorithm, 1441 including, e.g., the used elliptic curve (when applicable). 1443 At the time of writing this specification, acceptable public 1444 key encodings are CBOR Web Tokens (CWTs) and CWT Claims Sets 1445 (CCSs) [RFC8392], X.509 certificates [RFC7925] and C509 1446 certificates [I-D.ietf-cose-cbor-encoded-cert]. Further 1447 encodings may be available in the future, and would be 1448 acceptable to use as long as they comply with the criteria 1449 defined above. 1451 [ As to CWTs and CCSs, the COSE Header Parameters 'kcwt' and 1452 'kccs' are under pending registration requested by draft-ietf- 1453 lake-edhoc. ] 1455 [ As to C509 certificates, the COSE Header Parameters 'c5b' and 1456 'c5c' are under pending registration requested by draft-ietf- 1457 cose-cbor-encoded-cert. ] 1459 - The 'sign_enc_alg' parameter MUST NOT be present if the OSCORE 1460 group is a pairwise-only group. Otherwise, it MUST be present 1461 and specifies the Signature Encryption Algorithm used in the 1462 OSCORE group to encrypt messages protected with the group mode. 1463 This parameter takes values from the "Value" column of the 1464 "COSE Algorithms" registry [COSE.Algorithms]. 1466 - The 'sign_alg' parameter MUST NOT be present if the OSCORE 1467 group is a pairwise-only group. Otherwise, it MUST be present 1468 and specifies the Signature Algorithm used to sign messages in 1469 the OSCORE group. This parameter takes values from the "Value" 1470 column of the "COSE Algorithms" registry [COSE.Algorithms]. 1472 - The 'sign_params' parameter MUST NOT be present if the OSCORE 1473 group is a pairwise-only group. Otherwise, it MUST be present 1474 and specifies the parameters of the Signature Algorithm. This 1475 parameter is a CBOR array, which includes the following two 1476 elements: 1478 o 'sign_alg_capab': a CBOR array, with the same format and 1479 value of the COSE capabilities array for the Signature 1480 Algorithm indicated in 'sign_alg', as specified for that 1481 algorithm in the "Capabilities" column of the "COSE 1482 Algorithms" registry [COSE.Algorithms]. 1484 o 'sign_key_type_capab': a CBOR array, with the same format 1485 and value of the COSE capabilities array for the COSE key 1486 type of the keys used with the Signature Algorithm indicated 1487 in 'sign_alg', as specified for that key type in the 1488 "Capabilities" column of the "COSE Key Types" registry 1489 [COSE.Key.Types]. 1491 - The 'alg' parameter MUST NOT be present if the OSCORE group is 1492 a signature-only group. Otherwise, it MUST be present and 1493 specifies the AEAD Algorithm used in the OSCORE group to 1494 encrypt messages protected with the pairwise mode. 1496 - The 'ecdh_alg' parameter MUST NOT be present if the OSCORE 1497 group is a signature-only group. Otherwise, it MUST be present 1498 and specifies the Pairwise Key Agreement Algorithm used in the 1499 OSCORE group. This parameter takes values from the "Value" 1500 column of the "COSE Algorithms" registry [COSE.Algorithms]. 1502 - The 'ecdh_params' parameter MUST NOT be present if the OSCORE 1503 group is a signature-only group. Otherwise, it MUST be present 1504 and specifies the parameters of the Pairwise Key Agreement 1505 Algorithm. This parameter is a CBOR array, which includes the 1506 following two elements: 1508 o 'ecdh_alg_capab': a CBOR array, with the same format and 1509 value of the COSE capabilities array for the algorithm 1510 indicated in 'ecdh_alg', as specified for that algorithm in 1511 the "Capabilities" column of the "COSE Algorithms" registry 1512 [COSE.Algorithms]. 1514 o 'ecdh_key_type_capab': a CBOR array, with the same format 1515 and value of the COSE capabilities array for the COSE key 1516 type of the keys used with the algorithm indicated in 1517 'ecdh_alg', as specified for that key type in the 1518 "Capabilities" column of the "COSE Key Types" registry 1519 [COSE.Key.Types]. 1521 The format of 'key' defined above is consistent with every 1522 signature algorithm and ECDH algorithm currently considered in 1523 [I-D.ietf-cose-rfc8152bis-algs], i.e., with algorithms that have 1524 only the COSE key type as their COSE capability. Appendix B of 1525 this document describes how the format of the 'key' parameter can 1526 be generalized for possible future registered algorithms having a 1527 different set of COSE capabilities. 1529 * The 'exp' parameter MUST be present. 1531 * The 'ace-groupcomm-profile' parameter MUST be present and has 1532 value coap_group_oscore_app (PROFILE_TBD), which is defined in 1533 Section 25.5 of this document. 1535 * The 'pub_keys' parameter, if present, includes the public keys 1536 requested by the joining node by means of the 'get_pub_keys' 1537 parameter in the Joining Request. 1539 If the joining node has asked for the public keys of all the group 1540 members, i.e., 'get_pub_keys' had value the CBOR simple value 1541 'null' (0xf6) in the Joining Request, then the Group Manager 1542 provides only the public keys of the group members that are 1543 relevant to the joining node. That is, in such a case, 'pub_keys' 1544 includes only: i) the public keys of the responders currently in 1545 the OSCORE group, in case the joining node is configured (also) as 1546 requester; and ii) the public keys of the requesters currently in 1547 the OSCORE group, in case the joining node is configured (also) as 1548 responder or monitor. 1550 * The 'peer_identifiers' parameter includes the OSCORE Sender ID of 1551 each group member whose public key is specified in the 'pub_keys' 1552 parameter. That is, a group member's Sender ID is used as 1553 identifier for that group member (REQ25). 1555 * The 'group_policies' parameter SHOULD be present, and SHOULD 1556 include the following elements: 1558 - "Key Update Check Interval" defined in Section 4.3.1 of 1559 [I-D.ietf-ace-key-groupcomm], with default value 3600; 1561 - "Expiration Delta" defined in Section 4.3.1 of 1562 [I-D.ietf-ace-key-groupcomm], with default value 0. 1564 * The 'kdc_cred' parameter MUST be present, specifying the Group 1565 Manager's public key in its original binary representation (REQ8). 1566 The Group Manager's public key MUST be compatible with the 1567 encoding, signature or ECDH algorithm, and possible associated 1568 parameters used in the OSCORE group. 1570 * The 'kdc_nonce' parameter MUST be present, specifying the 1571 dedicated nonce N_KDC generated by the Group Manager. For N_KDC, 1572 it is RECOMMENDED to use a 8-byte long random nonce. 1574 * The 'kdc_cred_verify' parameter MUST be present, specifying the 1575 proof-of-possession (PoP) evidence computed by the Group Manager. 1576 The PoP evidence is computed over the nonce N_KDC, which is 1577 specified in the 'kdc_nonce' parameter and taken as PoP input. 1578 The PoP evidence is computed as defined below (REQ21). 1580 - If the group is not a pairwise-only group, the PoP evidence 1581 MUST be a signature. The Group Manager computes the signature 1582 by using the signature algorithm used in the OSCORE group, as 1583 well as its own private key associated to the public key 1584 specified in the 'kdc_cred' parameter. 1586 - If the group is a pairwise-only group, the PoP evidence MUST be 1587 a MAC computed as follows, by using the HKDF Algorithm HKDF 1588 SHA-256, which consists of composing the HKDF-Extract and HKDF- 1589 Expand steps [RFC5869]. 1591 MAC = HKDF(salt, IKM, info, L) 1593 The input parameters of HKDF are as follows. 1595 o salt takes as value the empty byte string. 1597 o IKM is computed as a cofactor Diffie-Hellman shared secret, 1598 see Section 5.7.1.2 of [NIST-800-56A], using the ECDH 1599 algorithm used in the OSCORE group. The Group Manager uses 1600 its own Diffie-Hellman private key and the Diffie-Hellman 1601 public key of the joining node. For X25519 and X448, the 1602 procedure is described in Section 5 of [RFC7748]. 1604 o info takes as value the PoP input. 1606 o L is equal to 8, i.e., the size of the MAC, in bytes. 1608 * The 'group_rekeying' parameter MAY be omitted, if the Group 1609 Manager uses the "Point-to-Point" group rekeying scheme registered 1610 in Section 11.14 of [I-D.ietf-ace-key-groupcomm] as rekeying 1611 scheme in the OSCORE group (OPT9). Its detailed use for this 1612 profile is defined in Section 20 of this document. In any other 1613 case, the 'group_rekeying' parameter MUST be included. 1615 As a last action, the Group Manager MUST store the Gid specified in 1616 the 'contextId' parameter of the 'key' parameter, as the Birth Gid of 1617 the joining node in the joined group (see Section 3 of 1618 [I-D.ietf-core-oscore-groupcomm]). This applies also in case the 1619 node is in fact re-joining the group; in such a case, the newly 1620 determined Birth Gid overwrites the one currently stored. 1622 6.5. Receive the Joining Response 1624 Upon receiving the Joining Response, the joining node retrieves the 1625 Group Manager's public key from the 'kdc_cred' parameter. The 1626 joining node MUST verify the proof-of-possession (PoP) evidence 1627 specified in the 'kdc_cred_verify' parameter of the Joining Response 1628 as defined below (REQ21). 1630 * If the group is not a pairwise-only group, the PoP evidence is a 1631 signature. The joining node verifies it by using the public key 1632 of the Group Manager, as well as the signature algorithm used in 1633 the OSCORE group and possible corresponding parameters. 1635 * If the group is a pairwise-only group, the PoP evidence is a MAC. 1636 The joining node recomputes the MAC through the same process taken 1637 by the Group Manager when computing the value of the 1638 'kdc_cred_verify' parameter (see Section 6.4), with the difference 1639 that the joining node uses its own Diffie-Hellman private key and 1640 the Diffie-Hellman public key of the Group Manager. The 1641 verification succeeds if and only if the recomputed MAC is equal 1642 to the MAC conveyed as PoP evidence in the Joining Response. 1644 In case of failed verification of the PoP evidence, the joining node 1645 MUST stop processing the Joining Response and MAY send a new Joining 1646 Request to the Group Manager (see Section 6.2). 1648 In case of successful verification of the PoP evidence, the joining 1649 node uses the information received in the Joining Response to set up 1650 the Group OSCORE Security Context, as described in Section 2 of 1651 [I-D.ietf-core-oscore-groupcomm]. If the following parameters were 1652 not included in the 'key' parameter of the Joining Response, the 1653 joining node considers the following default values, consistently 1654 with Section 3.2 of [RFC8613]. 1656 * Absent the 'hkdf' parameter, the joining node considers HKDF 1657 SHA-256 as HKDF Algorithm to use in the OSCORE group. 1659 * Absent the 'salt' parameter, the joining node considers the empty 1660 byte string as Master Salt to use in the OSCORE group. 1662 * Absent the 'group_rekeying' parameter, the joining node considers 1663 the "Point-to-Point" group rekeying scheme registered in 1664 Section 11.14 of [I-D.ietf-ace-key-groupcomm] as the rekeying 1665 scheme used in the group (OPT9). Its detailed use for this 1666 profile is defined in Section 20 of this document. 1668 In addition, the joining node maintains an association between each 1669 public key retrieved from the 'pub_keys' parameter and the role(s) 1670 that the corresponding group member has in the OSCORE group. 1672 From then on, the joining node can exchange group messages secured 1673 with Group OSCORE as described in [I-D.ietf-core-oscore-groupcomm]. 1674 When doing so: 1676 * The joining node MUST NOT process an incoming request message, if 1677 protected by a group member whose public key is not associated to 1678 the role "Requester". 1680 * The joining node MUST NOT process an incoming response message, if 1681 protected by a group member whose public key is not associated to 1682 the role "Responder". 1684 * The joining node MUST NOT use the pairwise mode of Group OSCORE to 1685 process messages in the group, if the Joining Response did not 1686 include the 'ecdh_alg' parameter. 1688 If the application requires backward security, the Group Manager MUST 1689 generate updated security parameters and group keying material, and 1690 provide it to the current group members upon the new node's joining 1691 (see Section 20). As a consequence, the joining node is not able to 1692 access secure communication in the OSCORE group occurred prior its 1693 joining. 1695 7. Public Keys of Joining Nodes 1697 Source authentication of a message sent within the group and 1698 protected with Group OSCORE is ensured by means of a digital 1699 signature embedded in the message (in group mode), or by integrity- 1700 protecting the message with pairwise keying material derived from the 1701 asymmetric keys of sender and recipient (in pairwise mode). 1703 Therefore, group members must be able to retrieve each other's public 1704 key from a trusted key repository, in order to verify source 1705 authenticity of incoming group messages. 1707 As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group 1708 Manager acts as trusted repository of the public keys of the group 1709 members, and provides those public keys to group members if requested 1710 to. Upon joining an OSCORE group, a joining node is thus expected to 1711 provide its own public key to the Group Manager. 1713 In particular, one of the following four cases can occur when a new 1714 node joins an OSCORE group. 1716 * The joining node is going to join the group exclusively as 1717 monitor, i.e., it is not going to send messages to the group. In 1718 this case, the joining node is not required to provide its own 1719 public key to the Group Manager, which thus does not have to 1720 perform any check related to the public key encoding, to a 1721 signature or ECDH algorithm, and to possible associated 1722 parameters. In case that joining node still provides a public key 1723 in the 'client_cred' parameter of the Joining Request (see 1724 Section 6.2), the Group Manager silently ignores that parameter, 1725 as well as the related parameters 'cnonce' and 1726 'client_cred_verify'. 1728 * The Group Manager already acquired the public key of the joining 1729 node during a past joining process. In this case, the joining 1730 node MAY choose not to provide again its own public key to the 1731 Group Manager, in order to limit the size of the Joining Request. 1733 The joining node MUST provide its own public key again if it has 1734 provided the Group Manager with multiple public keys during past 1735 joining processes, intended for different OSCORE groups. If the 1736 joining node provides its own public key, the Group Manager 1737 performs consistency checks as per Section 6.3 and, in case of 1738 success, considers it as the public key associated to the joining 1739 node in the OSCORE group. 1741 * The joining node and the Group Manager use an asymmetric proof-of- 1742 possession key to establish a secure communication association. 1743 Then, two cases can occur. 1745 1. The proof-of-possession key is compatible with the encoding, 1746 as well as with the signature or ECDH algorithm, and with 1747 possible associated parameters used in the OSCORE group. 1748 Then, the Group Manager considers the proof-of-possession key 1749 as the public key associated to the joining node in the OSCORE 1750 group. If the joining node is aware that the proof-of- 1751 possession key is also valid for the OSCORE group, it MAY not 1752 provide it again as its own public key to the Group Manager. 1753 The joining node MUST provide its own public key again if it 1754 has provided the Group Manager with multiple public keys 1755 during past joining processes, intended for different OSCORE 1756 groups. If the joining node provides its own public key in 1757 the 'client_cred' parameter of the Joining Request (see 1758 Section 6.2), the Group Manager performs consistency checks as 1759 per Section 6.3 and, in case of success, considers it as the 1760 public key associated to the joining node in the OSCORE group. 1762 2. The proof-of-possession key is not compatible with the 1763 encoding, or with the signature or algorithm, and with 1764 possible associated parameters used in the OSCORE group. In 1765 this case, the joining node MUST provide a different 1766 compatible public key to the Group Manager in the 1767 'client_cred' parameter of the Joining Request (see 1768 Section 6.2). Then, the Group Manager performs consistency 1769 checks on this latest provided public key as per Section 6.3 1770 and, in case of success, considers it as the public key 1771 associated to the joining node in the OSCORE group. 1773 * The joining node and the Group Manager use a symmetric proof-of- 1774 possession key to establish a secure communication association. 1775 In this case, upon performing a joining process with that Group 1776 Manager for the first time, the joining node specifies its own 1777 public key in the 'client_cred' parameter of the Joining Request 1778 targeting the group-membership endpoint (see Section 6.2). 1780 8. Retrieve of Updated Keying Material 1782 At some point, a group member considers the Group OSCORE Security 1783 Context invalid and to be renewed. This happens, for instance, after 1784 a number of unsuccessful security processing of incoming messages 1785 from other group members, or when the Security Context expires as 1786 specified by the 'exp' parameter of the Joining Response. 1788 When this happens, the group member retrieves updated security 1789 parameters and group keying material. This can occur in the two 1790 different ways described below. 1792 8.1. Retrieve of Group Keying Material 1794 If the group member wants to retrieve only the latest group keying 1795 material, it sends a Key Distribution Request to the Group Manager. 1797 In particular, it sends a CoAP GET request to the endpoint /ace- 1798 group/GROUPNAME at the Group Manager. 1800 The Group Manager processes the Key Distribution Request according to 1801 Section 4.3.2 of [I-D.ietf-ace-key-groupcomm]. The Key Distribution 1802 Response is formatted as defined in Section 4.3.2 of 1803 [I-D.ietf-ace-key-groupcomm], with the following additions. 1805 * The 'key' parameter is formatted as defined in Section 6.4 of this 1806 document, with the difference that it does not include the 1807 'group_SenderId' parameter. 1809 * The 'exp' parameter MUST be present. 1811 * The 'ace-groupcomm-profile' parameter MUST be present and has 1812 value coap_group_oscore_app. 1814 Upon receiving the Key Distribution Response, the group member 1815 retrieves the updated security parameters and group keying material, 1816 and, if they differ from the current ones, uses them to set up the 1817 new Group OSCORE Security Context as described in Section 2 of 1818 [I-D.ietf-core-oscore-groupcomm]. 1820 8.2. Retrieve of Group Keying Material and OSCORE Sender ID 1822 If the group member wants to retrieve the latest group keying 1823 material as well as the OSCORE Sender ID that it has in the OSCORE 1824 group, it sends a Key Distribution Request to the Group Manager. 1826 In particular, it sends a CoAP GET request to the endpoint /ace- 1827 group/GROUPNAME/nodes/NODENAME at the Group Manager. 1829 The Group Manager processes the Key Distribution Request according to 1830 Section 4.8.1 of [I-D.ietf-ace-key-groupcomm]. The Key Distribution 1831 Response is formatted as defined in Section 4.8.1 of 1832 [I-D.ietf-ace-key-groupcomm], with the following additions. 1834 * The 'key' parameter is formatted as defined in Section 6.4 of this 1835 document. In particular, if the requesting group member has 1836 exclusively the role of monitor, no 'group_SenderId' is specified 1837 within the 'key' parameter. 1839 Note that, in any other case, the current Sender ID of the group 1840 member is not specified as a separate parameter, but rather 1841 specified as 'group_SenderId' within the 'key' parameter. 1843 * The 'exp' parameter MUST be present. 1845 Upon receiving the Key Distribution Response, the group member 1846 retrieves the updated security parameters, group keying material and 1847 Sender ID, and, if they differ from the current ones, uses them to 1848 set up the new Group OSCORE Security Context as described in 1849 Section 2 of [I-D.ietf-core-oscore-groupcomm]. 1851 9. Request to Change Individual Keying Material 1853 As discussed in Section 2.5.2 of [I-D.ietf-core-oscore-groupcomm], a 1854 group member may at some point exhaust its Sender Sequence Numbers in 1855 the OSCORE group. 1857 When this happens, the group member MUST send a Key Renewal Request 1858 message to the Group Manager, as per Section 4.8.2.1 of 1859 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP PUT 1860 request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME at the 1861 Group Manager. 1863 Upon receiving the Key Renewal Request, the Group Manager processes 1864 it as defined in Section 4.8.2 of [I-D.ietf-ace-key-groupcomm], with 1865 the following additions. 1867 The Group Manager MUST return a 5.03 (Service Unavailable) response 1868 in case the OSCORE group identified by GROUPNAME is currently 1869 inactive (see Section 5.1). The response MUST have Content-Format 1870 set to application/ace-groupcomm+cbor and is formatted as defined in 1871 Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value of the 1872 'error' field MUST be set to 9 ("Group currently not active"). 1874 Otherwise, the Group Manager performs one of the following actions. 1876 1. If the requesting group member has exclusively the role of 1877 monitor, the Group Manager replies with a 4.03 (Forbidden) error 1878 response. The response MUST have Content-Format set to 1879 application/ace-groupcomm+cbor and is formatted as defined in 1880 Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value of the 1881 'error' field MUST be set to 1 ("Request inconsistent with the 1882 current roles"). 1884 2. Otherwise, the Group Manager takes one of the following actions. 1886 * The Group Manager rekeys the OSCORE group. That is, the Group 1887 Manager generates new group keying material for that group 1888 (see Section 20), and replies to the group member with a group 1889 rekeying message as defined in Section 20, providing the new 1890 group keying material. Then, the Group Manager rekeys the 1891 rest of the OSCORE group, as discussed in Section 20. 1893 The Group Manager SHOULD perform a group rekeying only if 1894 already scheduled to occur shortly, e.g., according to an 1895 application-dependent rekeying period or scheduling, or as a 1896 reaction to a recent change in the group membership. In any 1897 other case, the Group Manager SHOULD NOT rekey the OSCORE 1898 group when receiving a Key Renewal Request (OPT12). 1900 * The Group Manager determines and assigns a new OSCORE Sender 1901 ID for that group member, and replies with a Key Renewal 1902 Response formatted as defined in Section 4.8.2 of 1903 [I-D.ietf-ace-key-groupcomm]. In particular, the CBOR Map in 1904 the response payload includes a single parameter 1905 'group_SenderId' defined in Section 25.3 of this document, 1906 specifying the new Sender ID of the group member encoded as a 1907 CBOR byte string. 1909 Consistently with Section 2.5.3.1 of 1910 [I-D.ietf-core-oscore-groupcomm], the Group Manager MUST 1911 assign a new Sender ID that has not been used in the OSCORE 1912 group since the latest time when the current Gid value was 1913 assigned to the group. 1915 Furthermore, the Group Manager MUST add the old, relinquished 1916 Sender ID of the group member to the most recent set of stale 1917 Sender IDs, in the collection associated to the group (see 1918 Section 2.2.1). 1920 The Group Manager MUST return a 5.03 (Service Unavailable) 1921 response in case there are currently no Sender IDs available 1922 to assign in the OSCORE group. The response MUST have 1923 Content-Format set to application/ace-groupcomm+cbor and is 1924 formatted as defined in Section 4.1.2 of 1925 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field 1926 MUST be set to 4 ("No available node identifiers"). 1928 10. Retrieve Public Keys of Group Members 1930 A group member or a signature verifier may need to retrieve the 1931 public keys of (other) group members. To this end, the group member 1932 or signature verifier sends a Public Key Request message to the Group 1933 Manager, as per Sections 4.4.1.1 and 4.4.2.1 of 1934 [I-D.ietf-ace-key-groupcomm]. In particular, it sends the request to 1935 the endpoint /ace-group/GROUPNAME/pub-key at the Group Manager. 1937 If the Public Key Request uses the method FETCH, the Public Key 1938 Request is formatted as defined in Section 4.4.1 of 1939 [I-D.ietf-ace-key-groupcomm]. In particular: 1941 * Each element (if any) of the inner CBOR array 'role_filter' is 1942 formatted as in the inner CBOR array 'role_filter' of the 1943 'get_pub_keys' parameter of the Joining Request when the parameter 1944 value is non-null (see Section 6.2). 1946 * Each element (if any) of the inner CBOR array 'id_filter' is a 1947 CBOR byte string, which encodes the OSCORE Sender ID of the group 1948 member for which the associated public key is requested (REQ25). 1950 Upon receiving the Public Key Request, the Group Manager processes it 1951 as per Section 4.4.1 or Section 4.4.2 of 1952 [I-D.ietf-ace-key-groupcomm], depending on the request method being 1953 FETCH or GET, respectively. Additionally, if the Public Key Request 1954 uses the method FETCH, the Group Manager silently ignores node 1955 identifiers included in the 'get_pub_keys' parameter of the request 1956 that are not associated to any current group member (REQ26). 1958 The success Public Key Response is formatted as defined in 1959 Section 4.4.1 or Section 4.4.2 of [I-D.ietf-ace-key-groupcomm], 1960 depending on the request method being FETCH or GET, respectively. 1962 11. Upload a New Public Key 1964 A group member may need to provide the Group Manager with its new 1965 public key to use in the group from then on, hence replacing the 1966 current one. This can be the case, for instance, if the signature or 1967 ECDH algorithm, and possible associated parameters used in the OSCORE 1968 group have been changed, and the current public key is not compatible 1969 with them. 1971 To this end, the group member sends a Public Key Update Request 1972 message to the Group Manager, as per Section 4.9.1.1 of 1973 [I-D.ietf-ace-key-groupcomm], with the following addition. 1975 * The group member computes the proof-of-possession (PoP) evidence 1976 included in 'client_cred_verify' in the same way taken when 1977 preparing a Joining Request for the OSCORE group in question, as 1978 defined in Section 6.2 (REQ14). 1980 In particular, the group member sends a CoAP POST request to the 1981 endpoint /ace-group/GROUPNAME/nodes/NODENAME/pub-key at the Group 1982 Manager. 1984 Upon receiving the Public Key Update Request, the Group Manager 1985 processes it as per Section 4.9.1 of [I-D.ietf-ace-key-groupcomm], 1986 with the following additions. 1988 * The N_S challenge used to build the proof-of-possession input is 1989 computed as per point (1) in Section 6.2.1 (REQ15). 1991 * The Group Manager verifies the PoP challenge included in 1992 'client_cred_verify' in the same way taken when processing a 1993 Joining Request for the OSCORE group in question, as defined in 1994 Section 6.3 (REQ14). 1996 * The Group Manager MUST return a 5.03 (Service Unavailable) 1997 response in case the OSCORE group identified by GROUPNAME is 1998 currently inactive (see Section 5.1). The response MUST have 1999 Content-Format set to application/ace-groupcomm+cbor and is 2000 formatted as defined in Section 4.1.2 of 2001 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST 2002 be set to 9 ("Group currently not active"). 2004 * If the requesting group member has exclusively the role of 2005 monitor, the Group Manager replies with a 4.00 (Bad request) error 2006 response. The response MUST have Content-Format set to 2007 application/ace-groupcomm+cbor and is formatted as defined in 2008 Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value of the 2009 'error' field MUST be set to 1 ("Request inconsistent with the 2010 current roles"). 2012 * If the request is successfully processed, the Group Manager stores 2013 the association between i) the new public key of the group member; 2014 and ii) the Group Identifier (Gid), i.e., the OSCORE ID Context, 2015 associated to the OSCORE group together with the OSCORE Sender ID 2016 assigned to the group member in the group. The Group Manager MUST 2017 keep this association updated over time. 2019 12. Retrieve the Group Manager's Public Key 2021 A group member or a signature verifier may need to retrieve the 2022 public key of the Group Manager. To this end, the requesting client 2023 sends a KDC Public Key Request message to the Group Manager. 2025 In particular, it sends a CoAP GET request to the endpoint /ace- 2026 group/GROUPNAME/kdc-pub-key at the Group Manager defined in 2027 Section 4.5.1.1 of [I-D.ietf-ace-key-groupcomm], where GROUPNAME is 2028 the name of the OSCORE group. 2030 In addition to what is defined in Section 4.5.1 of 2031 [I-D.ietf-ace-key-groupcomm], the Group Manager MUST respond with a 2032 4.00 (Bad Request) error response, if the requesting client is not a 2033 current group member and GROUPNAME denotes a pairwise-only group. 2034 The response MUST have Content-Format set to application/ace- 2035 groupcomm+cbor and is formatted as defined in Section Section 4.1.2 2036 of [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST 2037 be set to 7 ("Signatures not used in the group"). 2039 The payload of the 2.05 (Content) KDC Public Key Response is a CBOR 2040 map, which is formatted as defined in Section 4.5.1 of 2041 [I-D.ietf-ace-key-groupcomm]. In particular, the Group Manager 2042 specifies the parameters 'kdc_cred', 'kdc_nonce' and 'kdc_challenge' 2043 as defined for the Joining Response in Section 6.4 of this document. 2044 This especially applies to the computing of the proof-of-possession 2045 (PoP) evidence included in 'kdc_cred_verify' (REQ21). 2047 Upon receiving a 2.05 (Content) KDC Public Key Response, the 2048 requesting client retrieves the Group Manager's public key from the 2049 'kdc_cred' parameter, and proceeds as defined in Section 4.5.1.1 of 2050 [I-D.ietf-ace-key-groupcomm]. In particular, the requesting client 2051 verifies the PoP evidence included in 'kdc_cred_verify' by means of 2052 the same method used when processing the Joining Response, as defined 2053 in Section 6.4 of this document (REQ21). 2055 Note that a signature verifier would not receive a successful 2056 response from the Group Manager, in case GROUPNAME denotes a 2057 pairwise-only group. 2059 13. Retrieve Signature Verification Data 2061 A signature verifier may need to retrieve data required to verify 2062 signatures of messages protected with the group mode and sent to a 2063 group (see Sections 3.1 and 8.5 of [I-D.ietf-core-oscore-groupcomm]). 2064 To this end, the signature verifier sends a Signature Verification 2065 Data Request message to the Group Manager. 2067 In particular, it sends a CoAP GET request to the endpoint /ace- 2068 group/GROUPNAME/verif-data at the Group Manager defined in 2069 Section 5.2 of this document, where GROUPNAME is the name of the 2070 OSCORE group. 2072 The payload of the 2.05 (Content) Signature Verification Data 2073 Response is a CBOR map, which has the format used for the Joining 2074 Response message in Section 6.4, with the following differences. 2076 * From the Joining Response message, only the parameters 'gkty', 2077 'key', 'num', 'exp' and 'ace-groupcomm-profile' are present. In 2078 particular, the 'key' parameter includes only the following data. 2080 - The parameters 'hkdf', 'contextId', 'pub_key_enc', 2081 'sign_enc_alg', 'sign_alg', 'sign_params'. These parameters 2082 MUST be present. 2084 - The parameters 'alg' and 'ecdh_alg'. These parameter MUST NOT 2085 be present if the group is a signature-only group. Otherwise, 2086 they MUST be present. 2088 * The parameter 'group_enc_key' is also included, with CBOR label 2089 defined in Section 25.3. This parameter specifies the Group 2090 Encryption Key of the OSCORE Group, encoded as a CBOR byte string. 2091 The Group Manager derives the Group Encryption Key from the group 2092 keying material, as per Section 2.1.6 of 2093 [I-D.ietf-core-oscore-groupcomm]. This parameter MUST be present. 2095 In order to verify signatures in the group (see Section 8.5 of 2096 [I-D.ietf-core-oscore-groupcomm]), the signature verifier relies on: 2097 the data retrieved from the 2.05 (Content) Signature Verification 2098 Data Response; the public keys of the group members signing the 2099 messages to verify, that can be retrieved as defined in Section 10; 2100 and the public key of the Group Manager, which can be retrieved as 2101 defined in Section 12. 2103 Figure 3 gives an overview of the exchange described above, while 2104 Figure 4 shows an example. 2106 Signature Group 2107 Verifier Manager 2108 | | 2109 | Signature Verification Data Request | 2110 |------------------------------------------------------------>| 2111 | GET ace-group/GROUPNAME/verif-data | 2112 | | 2113 |<--- Signature Verification Data Response: 2.05 (Content) ---| 2114 | | 2115 Figure 3: Message Flow of Signature Verification Data Request- 2116 Response 2118 Request: 2120 Header: GET (Code=0.01) 2121 Uri-Host: "kdc.example.com" 2122 Uri-Path: "ace-group" 2123 Uri-Path: "g1" 2124 Uri-Path: "verif-data" 2125 Payload: - 2127 Response: 2129 Header: Content (Code=2.05) 2130 Content-Format: "application/ace-groupcomm+cbor" 2131 Payload (in CBOR diagnostic notation, with GROUPCOMM_KEY_TBD 2132 and PROFILE_TBD being CBOR integers, while GROUP_ENC_KEY 2133 being a CBOR byte string): 2134 { 2135 "gkty": GROUPCOMM_KEY_TBD, 2136 "key": { 2137 'hkdf': -10, ; HKDF SHA-256 2138 'contextId': h'37fc', 2139 'pub_key_enc': 33, ; x5chain 2140 'sign_enc_alg': 10, ; AES-CCM-16-64-128 2141 'sign_alg': -8, ; EdDSA 2142 'sign_params': [[1], [1, 6]] ; [[OKP], [OKP, Ed25519]] 2143 }, 2144 "num": 12, 2145 "exp": 1609459200, 2146 "ace_groupcomm_profile": PROFILE_TBD, 2147 "group_enc_key": GROUP_ENC_KEY 2148 } 2150 Figure 4: Example of Signature Verification Data Request-Response 2152 14. Retrieve the Group Policies 2154 A group member may request the current policies used in the OSCORE 2155 group. To this end, the group member sends a Policies Request, as 2156 per Section 4.6.1.1 of [I-D.ietf-ace-key-groupcomm]. In particular, 2157 it sends a CoAP GET request to the endpoint /ace-group/GROUPNAME/ 2158 policies at the Group Manager, where GROUPNAME is the name of the 2159 OSCORE group. 2161 Upon receiving the Policies Request, the Group Manager processes it 2162 as per Section 4.6.1 of [I-D.ietf-ace-key-groupcomm]. The success 2163 Policies Response is formatted as defined in Section 4.6.1 of 2164 [I-D.ietf-ace-key-groupcomm]. 2166 15. Retrieve the Keying Material Version 2168 A group member may request the current version of the keying material 2169 used in the OSCORE group. To this end, the group member sends a 2170 Version Request, as per Section 4.7.1.1 of 2171 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP GET 2172 request to the endpoint /ace-group/GROUPNAME/num at the Group 2173 Manager, where GROUPNAME is the name of the OSCORE group. 2175 Upon receiving the Version Request, the Group Manager processes it as 2176 per Section 4.7.1 of [I-D.ietf-ace-key-groupcomm]. The success 2177 Version Response is formatted as defined in Section 4.7.1 of 2178 [I-D.ietf-ace-key-groupcomm]. 2180 16. Retrieve the Group Status 2182 A group member may request the current status of the the OSCORE 2183 group, i.e., active or inactive. To this end, the group member sends 2184 a Group Status Request to the Group Manager. 2186 In particular, the group member sends a CoAP GET request to the 2187 endpoint /ace-group/GROUPNAME/active at the Group Manager defined in 2188 Section 5.1 of this document, where GROUPNAME is the name of the 2189 OSCORE group. 2191 The payload of the 2.05 (Content) Group Status Response includes the 2192 CBOR simple value True if the group is currently active, or the CBOR 2193 simple value False otherwise. The group is considered active if it 2194 is set to allow new members to join, and if communication within the 2195 group is fine to happen. 2197 Upon learning from a 2.05 (Content) response that the group is 2198 currently inactive, the group member SHOULD stop taking part in 2199 communications within the group, until it becomes active again. 2201 Upon learning from a 2.05 (Content) response that the group has 2202 become active again, the group member can resume taking part in 2203 communications within the group. 2205 Figure 5 gives an overview of the exchange described above, while 2206 Figure 6 shows an example. 2208 Group Group 2209 Member Manager 2210 | | 2211 |--- Group Status Request: GET ace-group/GROUPNAME/active --->| 2212 | | 2213 |<---------- Group Status Response: 2.05 (Content) -----------| 2214 | | 2216 Figure 5: Message Flow of Group Status Request-Response 2218 Request: 2220 Header: GET (Code=0.01) 2221 Uri-Host: "kdc.example.com" 2222 Uri-Path: "ace-group" 2223 Uri-Path: "g1" 2224 Uri-Path: "active" 2225 Payload: - 2227 Response: 2229 Header: Content (Code=2.05) 2230 Payload (in CBOR diagnostic notation): 2231 true 2233 Figure 6: Example of Group Status Request-Response 2235 17. Retrieve Group Names 2237 A node may want to retrieve from the Group Manager the group name and 2238 the URI of the group-membership resource of a group. This is 2239 relevant in the following cases. 2241 * Before joining a group, a joining node may know only the current 2242 Group Identifier (Gid) of that group, but not the group name and 2243 the URI to the group-membership resource. 2245 * As current group member in several groups, the node has missed a 2246 previous group rekeying in one of them (see Section 20). Hence, 2247 it retains stale keying material and fails to decrypt received 2248 messages exchanged in that group. 2250 Such messages do not provide a direct hint to the correct group 2251 name, that the node would need in order to retrieve the latest 2252 keying material and public keys from the Group Manager (see 2253 Section 8.1, Section 8.2 and Section 10). However, such messages 2254 may specify the current Gid of the group, as value of the 2255 'kid_context' field of the OSCORE CoAP option (see Section 6.1 of 2256 [RFC8613] and Section 4.2 of [I-D.ietf-core-oscore-groupcomm]). 2258 * As signature verifier, the node also refers to a group name for 2259 retrieving the required public keys from the Group Manager (see 2260 Section 10). As discussed above, intercepted messages do not 2261 provide a direct hint to the correct group name, while they may 2262 specify the current Gid of the group, as value of the 2263 'kid_context' field of the OSCORE CoAP option. In such a case, 2264 upon intercepting a message in the group, the node requires to 2265 correctly map the Gid currently used in the group with the 2266 invariant group name. 2268 Furthermore, since it is not a group member, the node does not 2269 take part to a possible group rekeying. Thus, following a group 2270 rekeying and the consequent change of Gid in a group, the node 2271 would retain the old Gid value and cannot correctly associate 2272 intercepted messages to the right group, especially if acting as 2273 signature verifier in several groups. This in turn prevents the 2274 efficient verification of signatures, and especially the retrieval 2275 of required, new public keys from the Group Manager. 2277 In either case, the node only knows the current Gid of the group, as 2278 learned from received or intercepted messages exchanged in the group. 2279 As detailed below, the node can contact the Group Manager, and 2280 request the group name and URI to the group-membership resource 2281 corresponding to that Gid. Then, it can use that information to 2282 either join the group as a candidate group member, get the latest 2283 keying material as a current group member, or retrieve public keys 2284 used in the group as a signature verifier. To this end, the node 2285 sends a Group Name and URI Retrieval Request, as per Section 4.2.1.1 2286 of [I-D.ietf-ace-key-groupcomm]. 2288 In particular, the node sends a CoAP FETCH request to the endpoint 2289 /ace-group at the Group Manager formatted as defined in Section 4.2.1 2290 of [I-D.ietf-ace-key-groupcomm]. Each element of the CBOR array 2291 'gid' is a CBOR byte string (REQ13), which encodes the Gid of the 2292 group for which the group name and the URI to the group-membership 2293 resource are requested. 2295 Upon receiving the Group Name and URI Retrieval Request, the Group 2296 Manager processes it as per Section 4.2.1 of 2297 [I-D.ietf-ace-key-groupcomm]. The success Group Name and URI 2298 Retrieval Response is formatted as defined in Section 4.2.1 of 2299 [I-D.ietf-ace-key-groupcomm]. In particular, each element of the 2300 CBOR array 'gid' is a CBOR byte string (REQ13), which encodes the Gid 2301 of the group for which the group name and the URI to the group- 2302 membership resource are provided. 2304 For each of its groups, the Group Manager maintains an association 2305 between the group name and the URI to the group-membership resource 2306 on one hand, and only the current Gid for that group on the other 2307 hand. That is, the Group Manager MUST NOT maintain an association 2308 between the former pair and any other Gid for that group than the 2309 current, most recent one. 2311 Figure 7 gives an overview of the exchanges described above, while 2312 Figure 8 shows an example. 2314 Group 2315 Node Manager 2316 | | 2317 |---- Group Name and URI Retrieval Request: FETCH ace-group/ --->| 2318 | | 2319 |<--- Group Name and URI Retrieval Response: 2.05 (Content) -----| 2320 | | 2322 Figure 7: Message Flow of Group Name and URI Retrieval Request- 2323 Response 2325 Request: 2327 Header: FETCH (Code=0.05) 2328 Uri-Host: "kdc.example.com" 2329 Uri-Path: "ace-group" 2330 Content-Format: "application/ace-groupcomm+cbor" 2331 Payload (in CBOR diagnostic notation): 2332 { 2333 "gid": [h'37fc', h'84bd'] 2334 } 2336 Response: 2338 Header: Content (Code=2.05) 2339 Content-Format: "application/ace-groupcomm+cbor" 2340 Payload (in CBOR diagnostic notation): 2341 { 2342 "gid": [h'37fc', h'84bd'], 2343 "gname": ["g1", "g2"], 2344 "guri": ["ace-group/g1", "ace-group/g2"] 2345 } 2347 Figure 8: Example of Group Name and URI Retrieval Request-Response 2349 18. Leave the Group 2351 A group member may request to leave the OSCORE group. To this end, 2352 the group member sends a Group Leaving Request, as per 2353 Section 4.8.3.1 of [I-D.ietf-ace-key-groupcomm]. In particular, it 2354 sends a CoAP DELETE request to the endpoint /ace- 2355 group/GROUPNAME/nodes/NODENAME at the Group Manager. 2357 Upon receiving the Group Leaving Request, the Group Manager processes 2358 it as per Section 4.8.3 of [I-D.ietf-ace-key-groupcomm]. Then, the 2359 Group Manager performs the follow-up actions defined in Section 19. 2361 19. Removal of a Group Member 2363 Other than after a spontaneous request to the Group Manager as 2364 described in Section 18, a node may be forcibly removed from the 2365 OSCORE group, e.g., due to expired or revoked authorization. 2367 In either case, the Group Manager "forgets" the Birth Gid currently 2368 associated to the leaving node in the OSCORE group. This was stored 2369 following the Joining Response sent to that node, after its latest 2370 (re-)joining of the OSCORE group (see Section 6.4). 2372 If any of the two conditions below holds, the Group Manager MUST 2373 inform the leaving node of its eviction as follows. If both 2374 conditions hold, the Group Manager MUST inform the leaving node only 2375 once, using either of the corresponding methods. 2377 * If, upon joining the group (see Section 6.2), the leaving node 2378 specified a URI in the 'control_uri' parameter defined in 2379 Section 4.3.1 of [I-D.ietf-ace-key-groupcomm], the Group Manager 2380 sends a DELETE request targeting the URI specified in the 2381 'control_uri' parameter (OPT7). 2383 * If, when sending Joining Responses to nodes joining the group (see 2384 Section 6.4) the Group Manager specifies a URI in the 2385 'control_group_uri' parameter defined in Section 4.3.1 of 2386 [I-D.ietf-ace-key-groupcomm], the Group Manager sends a DELETE 2387 request targeting the URI specified in the 'control_group_uri' 2388 parameter (OPT10). 2390 * If the leaving node has been observing the associated resource at 2391 ace-group/GROUPNAME/nodes/NODENAME, the Group Manager sends an 2392 unsolicited 4.04 (Not Found) error response to the leaving node, 2393 as specified in Section 4.3.2 of [I-D.ietf-ace-key-groupcomm]. 2395 If the leaving node has not exclusively the role of monitor, the 2396 Group Manager performs the following actions. 2398 * The Group Manager frees the OSCORE Sender ID value of the leaving 2399 node. This value MUST NOT become available for possible upcoming 2400 joining nodes in the same group, until the group has been rekeyed 2401 and assigned a new Group Identifier (Gid). 2403 * The Group Manager MUST add the relinquished Sender ID of the 2404 leaving node to the most recent set of stale Sender IDs, in the 2405 collection associated to the group (see Section 2.2.1). 2407 * The Group Manager cancels the association between, on one hand, 2408 the public key of the leaving node and, on the other hand, the Gid 2409 associated to the OSCORE group together with the freed Sender ID 2410 value. The Group Manager deletes the public key of the leaving 2411 node, if that public key has no remaining association with any 2412 pair (Gid, Sender ID). 2414 Then, the Group Manager MUST generate updated security parameters and 2415 group keying material, and provide it to the remaining group members 2416 (see Section 20). As a consequence, the leaving node is not able to 2417 acquire the new security parameters and group keying material 2418 distributed after its leaving. 2420 The same considerations from Section 5 of 2421 [I-D.ietf-ace-key-groupcomm] apply here as well, considering the 2422 Group Manager acting as KDC. 2424 20. Group Rekeying Process 2426 In order to rekey the OSCORE group, the Group Manager distributes a 2427 new Group Identifier (Gid), i.e., a new OSCORE ID Context; a new 2428 OSCORE Master Secret; and, optionally, a new OSCORE Master Salt for 2429 that group. When doing so, the Group Manager MUST increment the 2430 version number of the group keying material, before starting its 2431 distribution. 2433 Consistently with Section 3.2 of [I-D.ietf-core-oscore-groupcomm]: 2435 * The Group Manager can reassign a Gid to the same group over that 2436 group's lifetime, e.g., once the whole space of Gid values has 2437 been used for the group in question. 2439 * Before rekeying the group, the Group Manager MUST check if the new 2440 Gid to be distributed coincides with the Birth Gid of any of the 2441 current group members (see Section 6.4). If any of such "elder 2442 members" is found in the group, the Group Manager MUST evict them 2443 from the group. That is, the Group Manager MUST terminate their 2444 membership and MUST rekey the group in such a way that the new 2445 keying material is not provided to those evicted elder members. 2446 This also includes adding their relinquished Sender IDs to the 2447 most recent set of stale Sender IDs, in the collection associated 2448 to the group (see Section 2.2.1), before rekeying the group. 2450 Until a further following group rekeying, the Group Manager MUST 2451 store the list of those latest-evicted elder members. If any of 2452 those nodes re-joins the group before a further following group 2453 rekeying occurs, the Group Manager MUST NOT rekey the group upon 2454 their re-joining. When one of those nodes re-joins the group, the 2455 Group Manager can rely, e.g., on the ongoing secure communication 2456 association to recognize the node as included in the stored list. 2458 Across the rekeying execution, the Group Manager MUST preserve the 2459 same unchanged OSCORE Sender IDs for all group members intended to 2460 remain in the group. This avoids affecting the retrieval of public 2461 keys from the Group Manager and the verification of group messages. 2463 The Group Manager MUST support the "Point-to-Point" group rekeying 2464 scheme registered in Section 11.14 of [I-D.ietf-ace-key-groupcomm], 2465 as per the detailed use defined in Section 20.1 of this document. 2466 Future specifications may define how this application profile can use 2467 alternative group rekeying schemes, which MUST comply with the 2468 functional steps defined in Section 3.2 of 2469 [I-D.ietf-core-oscore-groupcomm]. The Group Manager MUST indicate 2470 the use of such an alternative group rekeying scheme to joining 2471 nodes, by means of the 'group_rekeying' parameter included in Joining 2472 Response messages (see Section 6.4). 2474 It is RECOMMENDED that the Group Manager gets confirmation of 2475 successful distribution from the group members, and admits a maximum 2476 number of individual retransmissions to non-confirming group members. 2477 Once completed the group rekeying process, the Group Manager creates 2478 a new empty set X' of stale Sender IDs associated to the version of 2479 the newly distributed group keying material. Then, the Group Manager 2480 MUST add the set X' to the collection of stale Sender IDs associated 2481 to the group (see Section 2.2.1). 2483 In case the rekeying terminates and some group members have not 2484 received the new keying material, they will not be able to correctly 2485 process following secured messages exchanged in the group. These 2486 group members will eventually contact the Group Manager, in order to 2487 retrieve the current keying material and its version. 2489 Some of these group members may be in multiple groups, each 2490 associated to a different Group Manager. When failing to correctly 2491 process messages secured with the new keying material, these group 2492 members may not have sufficient information to determine which exact 2493 Group Manager they should contact, in order to retrieve the current 2494 keying material they are missing. 2496 If the Gid is formatted as described in Appendix C of 2497 [I-D.ietf-core-oscore-groupcomm], the Group Prefix can be used as a 2498 hint to determine the right Group Manager, as long as no collisions 2499 among Group Prefixes are experienced. Otherwise, a group member 2500 needs to contact the Group Manager of each group, e.g., by first 2501 requesting only the version of the current group keying material (see 2502 Section 15) and then possibly requesting the current keying material 2503 (see Section 8.1). 2505 Furthermore, some of these group members can be in multiple groups, 2506 all of which associated to the same Group Manager. In this case, 2507 these group members may also not have sufficient information to 2508 determine which exact group they should refer to, when contacting the 2509 right Group Manager. Hence, they need to contact a Group Manager 2510 multiple times, i.e., separately for each group they belong to and 2511 associated to that Group Manager. 2513 Finally, Section 20.3 discusses how a group member can realize that 2514 it has missed one or more rekeying instances, and the actions it is 2515 accordingly required to take. 2517 20.1. Sending Rekeying Messages 2519 The group rekeying messages MUST have Content-Format set to 2520 application/ace-groupcomm+cbor and have the same format used for the 2521 Joining Response message in Section 6.4, with the following 2522 differences. Note that this extends the minimal content of a 2523 rekeying message as defined in Section 6 of 2524 [I-D.ietf-ace-key-groupcomm] (OPT14). 2526 * From the Joining Response, only the parameters 'gkty', 'key', 2527 'num', 'exp', and 'ace-groupcomm-profile' are present. In 2528 particular, the 'key' parameter includes only the following data. 2530 - The 'ms' parameter, specifying the new OSCORE Master Secret 2531 value. This parameter MUST be present. 2533 - The 'contextId' parameter, specifying the new Gid to use as 2534 OSCORE ID Context value. This parameter MUST be present. 2536 - The 'salt' value, specifying the new OSCORE Master Salt value. 2537 This parameter MAY be present. 2539 * The parameter 'stale_node_ids' MUST also be included, with CBOR 2540 label defined in Section 25.3. This parameter is encoded as a 2541 CBOR array, where each element is encoded as a CBOR byte string. 2542 The CBOR array has to be intended as a set, i.e., the order of its 2543 elements is irrelevant. The parameter is populated as follows. 2545 - The Group Manager creates an empty CBOR array ARRAY. 2547 - The Group Manager considers the collection of stale Sender IDs 2548 associated to the group (see Section 2.2.1), and takes the most 2549 recent set X, i.e., the set associated to the current version 2550 of the group keying material about to be relinquished. 2552 - For each Sender ID in X, the Group Manager encodes it as a CBOR 2553 byte string and adds the result to ARRAY. 2555 - The parameter 'stale_node_ids' takes ARRAY as value. 2557 * The parameters 'pub_keys', 'peer_roles' and 'peer_identifiers' 2558 SHOULD be present, if the group rekeying is performed due to one 2559 or multiple Clients that have requested join the group. Following 2560 the same semantics used in the Joining Response message (see 2561 Section 6.4), the three parameters specify the public key, roles 2562 in the group and node identifier of each of the Clients that have 2563 requested to join the group. The Group Manager MUST NOT include a 2564 non-empty subset of these three parameters. 2566 The Group Manager separately sends a group rekeying message formatted 2567 as defined above to each group member to be rekeyed. 2569 Each rekeying message MUST be secured with the pairwise secure 2570 communication channel between the Group Manager and the group member 2571 used during the joining process. In particular, each rekeying 2572 message can target the 'control_uri' URI path defined in 2573 Section 4.3.1 of [I-D.ietf-ace-key-groupcomm] (OPT7), if provided by 2574 the intended recipient upon joining the group (see Section 6.2). 2576 This distribution approach requires group members to act (also) as 2577 servers, in order to correctly handle unsolicited group rekeying 2578 messages from the Group Manager. In particular, if a group member 2579 and the Group Manager use OSCORE [RFC8613] to secure their pairwise 2580 communications, the group member MUST create a Replay Window in its 2581 own Recipient Context upon establishing the OSCORE Security Context 2582 with the Group Manager, e.g., by means of the OSCORE profile of ACE 2583 [I-D.ietf-ace-oscore-profile]. 2585 Group members and the Group Manager SHOULD additionally support 2586 alternative distribution approaches that do not require group members 2587 to act (also) as servers. A number of such approaches are defined in 2588 Section 6 of [I-D.ietf-ace-key-groupcomm]. In particular, a group 2589 member may use CoAP Observe [RFC7641] and subscribe for updates to 2590 the group-membership resource of the group, at the endpoint /ace- 2591 group/GROUPNAME/ of the Group Manager (see Section 6.1 of 2592 [I-D.ietf-ace-key-groupcomm]). Alternatively, a full-fledged Pub-Sub 2593 model can be considered [I-D.ietf-core-coap-pubsub], where the Group 2594 Manager publishes to a rekeying topic hosted at a Broker, while the 2595 group members subscribe to such topic (see Section 6.2 of 2596 [I-D.ietf-ace-key-groupcomm]). 2598 20.2. Receiving Rekeying Messages 2600 Once received the new group keying material, a group member proceeds 2601 as follows. 2603 The group member considers the stale Sender IDs received from the 2604 Group Manager. If the group rekeying scheme defined in Section 20.1 2605 is used, the stale Sender IDs are specified by the 'stale_node_ids' 2606 parameter. 2608 After that, as per Section 3.2 of [I-D.ietf-core-oscore-groupcomm], 2609 the group member MUST remove every public key associated to a stale 2610 Sender ID from its list of group members' public keys used in the 2611 group, and MUST delete each of its Recipient Contexts used in the 2612 group whose corresponding Recipient ID is a stale Sender ID. 2614 Then, the following cases can occur, based on the version number V' 2615 of the new group keying material distributed through the rekeying 2616 process. If the group rekeying scheme defined in Section 20.1 is 2617 used, this information is specified by the 'num' parameter. 2619 * The group member has not missed any group rekeying. That is, the 2620 old keying material owned by the group member has version number 2621 V, while the received new keying material has version number V' = 2622 (V + 1). In such a case, the group member simply installs the new 2623 keying material and derives the corresponding new Security 2624 Context. 2626 * The group member has missed one or more group rekeying instances. 2627 That is, the old keying material owned by the group member has 2628 version number V, while the received new keying material has 2629 version number V' > (V + 1). In such a case, the group member 2630 MUST proceed as defined in Section 20.3. 2632 * The group member has received keying material not newer than the 2633 stored one. That is, the stored keying material owned by the 2634 group member has version number V, while the received keying 2635 material has version number V' < (V + 1). In such a case, the 2636 group member MUST ignore the received rekeying messages and MUST 2637 NOT install the received keying material. 2639 20.3. Missed Rekeying Instances 2641 A group member can realize to have missed one or more rekeying 2642 instances in one of the ways discussed below. In the following, V 2643 denotes the version number of the old keying material stored by the 2644 group member, while V' denotes the version number of the latest, 2645 possibly just distributed, keying material. 2647 a. The group member has participated to a rekeying process that has 2648 distributed new keying material with version number V' > (V + 1), as 2649 discussed in Section 20.2. 2651 b. The group member has obtained the latest keying material from the 2652 Group Manager, as a response to a Key Distribution Request (see 2653 Section 8.1) or to a Joining Request when re-joining the group (see 2654 Section 6.2). In particular, V is different than V' specified by the 2655 'num' parameter in the response. 2657 c. The group member has obtained the public keys of other group 2658 members, through a Public Key Request-Response exchange with the 2659 Group Manager (see Section 10). In particular, V is different than 2660 V' specified by the 'num' parameter in the response. 2662 d. The group member has performed a Version Request-Response 2663 exchange with the Group Manager (see Section 15). In particular, V 2664 is different than V' specified by the 'num' parameter in the 2665 response. 2667 In either case, the group member MUST delete the stored keying 2668 material with version number V. 2670 If case (a) or case (b) applies, the group member MUST perform the 2671 following actions. 2673 1. The group member MUST NOT install the latest keying material yet, 2674 in case that was already obtained. 2676 2. The group member sends a Stale Sender IDs Request to the Group 2677 Manager (see Section 20.3.1), specifying the version number V as 2678 payload of the request. 2680 If the Stale Sender IDs Response from the Group Manager has no 2681 payload, the group member MUST remove all the public keys from 2682 its list of group members' public keys used in the group, and 2683 MUST delete all its Recipient Contexts used in the group. 2685 Otherwise, the group member considers the stale Sender IDs 2686 specified in the Stale Sender IDs Response from the Group 2687 Manager. Then, the group member MUST remove every public key 2688 associated to a stale Sender ID from its list of group members' 2689 public keys used in the group, and MUST delete each of its 2690 Recipient Contexts used in the group whose corresponding 2691 Recipient ID is a stale Sender ID. 2693 3. The group member installs the latest keying material with version 2694 number V' and derives the corresponding new Security Context. 2696 If case (c) or case (d) applies, the group member SHOULD perform the 2697 following actions. 2699 1. The group member sends a Stale Sender IDs Request to the Group 2700 Manager (see Section 20.3.1), specifying the version number V as 2701 payload of the request. 2703 If the Stale Sender IDs Response from the Group Manager has no 2704 payload, the group member MUST remove all the public keys from 2705 its list of group members' public keys used in the group, and 2706 MUST delete all its Recipient Contexts used in the group. 2708 Otherwise, the group member considers the stale Sender IDs 2709 specified in the Stale Sender IDs Response from the Group 2710 Manager. Then, the group member MUST remove every public key 2711 associated to a stale Sender ID from its list of group members' 2712 public keys used in the group, and MUST delete each of its 2713 Recipient Contexts used in the group whose corresponding 2714 Recipient ID is a stale Sender ID. 2716 2. The group member obtains the latest keying material with version 2717 number V' from the Group Manager. This can happen by sending a 2718 Key Distribution Request to the Group Manager (see Section 8.1), 2719 or by re-joining the group (see Section 6.2). 2721 3. The group member installs the latest keying material with version 2722 number V' and derives the corresponding new Security Context. 2724 If case (c) or case (d) applies, the group member can alternatively 2725 perform the following actions. 2727 1. The group member re-joins the group (see Section 6.2). When 2728 doing so, the group member MUST re-join with the same roles it 2729 currently has in the group, and MUST request the Group Manager 2730 for the public keys of all the current group members. That is, 2731 the 'get_pub_keys' parameter of the Joining Request MUST be 2732 present and MUST be set to the CBOR simple value 'null' (0xf6). 2734 2. When receiving the Joining Response (see Section 6.5 and 2735 Section 6.5), the group member retrieves the set Z of public keys 2736 specified in the 'pub_keys' parameter. 2738 Then, the group member MUST remove every public key which is not 2739 in Z from its list of group members' public keys used in the 2740 group, and MUST delete each of its Recipient Contexts used in the 2741 group that does not include any of the public keys in Z. 2743 3. The group member installs the latest keying material with version 2744 number V' and derives the corresponding new Security Context. 2746 20.3.1. Retrieval of Stale Sender IDs 2748 When realizing to have missed one or more group rekeying instances 2749 (see Section 20.3), a node needs to retrieve from the Group Manager 2750 the data required to delete some of its stored group members' public 2751 keys and Recipient Contexts (see Section 5.3.1). This data is 2752 provided as an aggregated set of stale Sender IDs, which are used as 2753 specified in Section 20.3. 2755 In particular, the node sends a CoAP FETCH request to the endpoint 2756 /ace-group/GROUPNAME/stale-sids at the Group Manager defined in 2757 Section 5.3 of this document, where GROUPNAME is the name of the 2758 OSCORE group. 2760 The payload of the Stale Sender IDs Request MUST include a CBOR 2761 unsigned integer. This encodes the version number V of the most 2762 recent group keying material owned and installed by the requesting 2763 client, which is older than the latest, possibly just distributed, 2764 keying material with version number V'. 2766 The handler MUST reply with a 4.00 (Bad Request) error response, if 2767 the request is not formatted correctly. Also, the handler MUST 2768 respond with a 4.00 (Bad Request) error response, if the specified 2769 version number V is greater or equal than the version number V' 2770 associated to the latest keying material in the group, i.e., if V >= 2771 V'. 2773 Otherwise, the handler responds with a 2.05 (Content) Stale Sender 2774 IDs Response. The payload of the response is formatted as defined 2775 below, where SKEW = (V' - V + 1). 2777 * The Group Manager considers ITEMS as the current number of sets 2778 stored in the collection of stale Sender IDs associated to the 2779 group (see Section 2.2.1). 2781 * If SKEW > ITEMS, the Stale Sender IDs Response MUST NOT have a 2782 payload. 2784 * Otherwise, the payload of the Stale Sender IDs Response MUST 2785 include a CBOR array, where each element is encoded as a CBOR byte 2786 string. The CBOR array has to be intended as a set, i.e., the 2787 order of its elements is irrelevant. The Group Manager populates 2788 the CBOR array as follows. 2790 - The Group Manager creates an empty CBOR array ARRAY and an 2791 empty set X. 2793 - The Group Manager considers the SKEW most recent sets stored in 2794 the collection of stale Sender IDs associated to the group. 2795 Note that the most recent set is the one associate to the 2796 latest version of the group keying material. 2798 - The Group Manager copies all the Sender IDs from the selected 2799 sets into X. When doing so, the Group Manager MUST discard 2800 duplicates. That is, the same Sender ID MUST NOT be present 2801 more than once in the final content of X. 2803 - For each Sender ID in X, the Group Manager encodes it as a CBOR 2804 byte string and adds the result to ARRAY. 2806 - Finally, ARRAY is specified as payload of the Stale Sender IDs 2807 Response. Note that ARRAY might result in the empty CBOR 2808 array. 2810 Figure 9 gives an overview of the exchange described above, while 2811 Figure 10 shows an example. 2813 Group 2814 Node Manager 2815 | | 2816 | Stale Sender IDs Request | 2817 |------------------------------------------------------------>| 2818 | FETCH ace-group/GROUPNAME/stale-sids | 2819 | | 2820 |<---------- Stale Sender IDs Response: 2.05 (Content) -------| 2821 | | 2823 Figure 9: Message Flow of Stale Sender IDs Request-Response 2825 Request: 2827 Header: FETCH (Code=0.05) 2828 Uri-Host: "kdc.example.com" 2829 Uri-Path: "ace-group" 2830 Uri-Path: "g1" 2831 Uri-Path: "stale-sids" 2832 Payload (in CBOR diagnostic notation): 2833 42 2835 Response: 2837 Header: Content (Code=2.05) 2838 Payload (in CBOR diagnostic notation): 2839 [h'01', h'fc', h'12ab', h'de44', h'ff'] 2841 Figure 10: Example of Stale Sender IDs Request-Response 2843 21. ACE Groupcomm Parameters 2845 Clients are required to support the new parameters defined in this 2846 application profile as specified below (REQ29). 2848 * 'group_senderId' MUST be supported by a Client that intends to 2849 join an OSCORE group with the role of Requester and/or Responder. 2851 * 'ecdh_info' MUST be supported by a Client that intends to join a 2852 group which uses the pairwise mode of Group OSCORE. 2854 * 'gm_dh_pub_keys' MUST be supported by a Client that intends to 2855 join a group which uses the pairwise mode of Group OSCORE and that 2856 does not plan to or cannot rely on an early retrieval of the Group 2857 Manager's Diffie-Hellman public key. 2859 * 'group_enc_key' MUST be supported by a Client that intends to join 2860 a group which uses the group mode of Group OSCORE or to be 2861 signature verifier for that group. 2863 * 'stale_node_ids' MUST be supported. 2865 When the conditional parameters defined in Section 8 of 2866 [I-D.ietf-ace-key-groupcomm] are used with this application profile, 2867 Clients must, should or may support them as specified below (REQ30). 2869 * 'client_cred', 'cnonce', 'client_cred_verify'. A Client that has 2870 a public key to use in a group MUST support these parameters. 2872 * 'kdcchallenge'. A Client that has a public key to use in a group 2873 and that provides the Access Token to the Group Manager through a 2874 Token Transfer Request (see Section 6.1) MUST support this 2875 parameter. 2877 * 'pub_keys_repo'. This parameter is not relevant for this 2878 application profile, since the Group Manager always acts as 2879 repository of the group members' public keys. 2881 * 'group_policies'. A Client that is interested in the specific 2882 policies used in a group, but that does not know them or cannot 2883 become aware of them before joining that group SHOULD support this 2884 parameter. 2886 * 'peer_roles'. A Client MUST support this parameter, since in this 2887 application profile it is relevant for Clients to know the roles 2888 of the group member associated to each public key. 2890 * 'kdc_nonce', 'kdc_cred' and 'kdc_cred_verify'. A Client MUST 2891 support these parameters, since the Group Manager's public key is 2892 required to process messages protected with Group OSCORE (see 2893 Section 4.3 of [I-D.ietf-core-oscore-groupcomm]). 2895 * 'mgt_key_material'. A Client that supports an advanced rekeying 2896 scheme possibly used in the group, such as based on one-to-many 2897 rekeying messages sent over IP multicast, MUST support this 2898 parameter. 2900 * 'control_group_uri'. A Client that support the hosting of local 2901 resources each associated to a group (hence acting as CoAP server) 2902 and the reception of one-to-many requests sent to those resources 2903 by the Group Manager (e.g., over IP multicast) MUST support this 2904 parameter. 2906 22. ACE Groupcomm Error Identifiers 2908 In addition to what is defined in Section 9 of 2909 [I-D.ietf-ace-key-groupcomm], this application profile defines new 2910 values that the Group Manager can include as error identifiers, in 2911 the 'error' field of an error response with Content-Format 2912 application/ace-groupcomm+cbor. 2914 +-------+-------------------------------------------------+ 2915 | Value | Description | 2916 +-------+-------------------------------------------------+ 2917 | 7 | Signatures not used in the group | 2918 +-------+-------------------------------------------------+ 2919 | 8 | Operation permitted only to signature verifiers | 2920 +-------+-------------------------------------------------+ 2921 | 9 | Group currently not active | 2922 +-------+-------------------------------------------------+ 2924 Figure 11: ACE Groupcomm Error Identifiers 2926 A Client supporting the 'error' parameter (see Sections 4.1.2 and 8 2927 of [I-D.ietf-ace-key-groupcomm]) and able to understand the specified 2928 error may use that information to determine what actions to take 2929 next. If it is included in the error response and supported by the 2930 Client, the 'error_description' parameter may provide additional 2931 context. In particular, the following guidelines apply. 2933 * In case of error 7, the Client should stop sending the request in 2934 question to the Group Manager. In this application profile, this 2935 error is relevant only for a signature verifiers, in case it tries 2936 to access resources related to a pairwise-only group. 2938 * In case of error 8, the Client should stop sending the request in 2939 question to the Group Manager. 2941 * In case of error 9, the Client should wait for a certain (pre- 2942 configured) amount of time, before trying re-sending its request 2943 to the Group Manager. 2945 23. Default Values for Group Configuration Parameters 2947 This section defines the default values that the Group Manager 2948 assumes for the configuration parameters of an OSCORE group, unless 2949 differently specified when creating and configuring the group. This 2950 can be achieved as specified in [I-D.ietf-ace-oscore-gm-admin]. 2952 23.1. Common 2954 This section always applies, as related to common configuration 2955 parameters. 2957 * For the HKDF Algorithm 'hkdf', the Group Manager SHOULD use the 2958 same default value defined in Section 3.2 of [RFC8613], i.e., HKDF 2959 SHA-256 (COSE algorithm encoding: -10). 2961 * For the format 'pub_key_enc' used to encode the public keys in the 2962 group, the Group Manager SHOULD use CBOR Web Token (CWT) or CWT 2963 Claims Set (CCS) [RFC8392], i.e., the COSE Header Parameter 'kcwt' 2964 and 'kccs', respectively. 2966 [ These COSE Header Parameters are under pending registration 2967 requested by draft-ietf-lake-edhoc. ] 2969 * For 'max_stale_sets', the Group Manager SHOULD consider N = 3 as 2970 the maximum number of stored sets of stale Sender IDs in the 2971 collection associated to the group (see Section 2.2.1). 2973 23.2. Group Mode 2975 This section applies if the group uses (also) the group mode of Group 2976 OSCORE. 2978 * For the Signature Encryption Algorithm 'sign_enc_alg' used to 2979 encrypted messages protected with the group mode, the Group 2980 Manager SHOULD use AES-CCM-16-64-128 (COSE algorithm encoding: 10) 2981 as default value. 2983 The Group Manager SHOULD use the following default values for the 2984 Signature Algorithm 'sign_alg' and related parameters 'sign_params', 2985 consistently with the "COSE Algorithms" registry [COSE.Algorithms], 2986 the "COSE Key Types" registry [COSE.Key.Types] and the "COSE Elliptic 2987 Curves" registry [COSE.Elliptic.Curves]. 2989 * For the Signature Algorithm 'sign_alg' used to sign messages 2990 protected with the group mode, the signature algorithm EdDSA 2991 [RFC8032]. 2993 * For the parameters 'sign_params' of the Signature Algorithm: 2995 - The array [[OKP], [OKP, Ed25519]], in case EdDSA is assumed or 2996 specified for 'sign_alg'. In particular, this indicates to use 2997 the COSE key type OKP and the elliptic curve Ed25519 [RFC8032]. 2999 - The array [[EC2], [EC2, P-256]], in case ES256 [RFC6979] is 3000 specified for 'sign_alg'. In particular, this indicates to use 3001 the COSE key type EC2 and the elliptic curve P-256. 3003 - The array [[EC2], [EC2, P-384]], in case ES384 [RFC6979] is 3004 specified for 'sign_alg'. In particular, this indicates to use 3005 the COSE key type EC2 and the elliptic curve P-384. 3007 - The array [[EC2], [EC2, P-521]], in case ES512 [RFC6979] is 3008 specified for 'sign_alg'. In particular, this indicates to use 3009 the COSE key type EC2 and the elliptic curve P-521. 3011 - The array [[RSA], [RSA]], in case PS256, PS384 or PS512 3012 [RFC8017] is specified for 'sign_alg'. In particular, this 3013 indicates to use the COSE key type RSA. 3015 23.3. Pairwise Mode 3017 This section applies if the group uses (also) the pairwise mode of 3018 Group OSCORE. 3020 For the AEAD Algorithm 'alg' used to encrypt messages protected with 3021 the pairwise mode, the Group Manager SHOULD use the same default 3022 value defined in Section 3.2 of [RFC8613], i.e., AES-CCM-16-64-128 3023 (COSE algorithm encoding: 10). 3025 For the Pairwise Key Agreement Algorithm 'ecdh_alg' and related 3026 parameters 'ecdh_params', the Group Manager SHOULD use the following 3027 default values, consistently with the "COSE Algorithms" registry 3028 [COSE.Algorithms], the "COSE Key Types" registry [COSE.Key.Types] and 3029 the "COSE Elliptic Curves" registry [COSE.Elliptic.Curves]. 3031 * For the Pairwise Key Agreement Algorithm 'ecdh_alg' used to 3032 compute static-static Diffie-Hellman shared secrets, the ECDH 3033 algorithm ECDH-SS + HKDF-256 specified in Section 6.3.1 of 3034 [I-D.ietf-cose-rfc8152bis-algs]. 3036 * For the parameters 'ecdh_params' of the Pairwise Key Agreement 3037 Algorithm: 3039 - The array [[OKP], [OKP, X25519]], in case EdDSA is assumed or 3040 specified for 'sign_alg'. In particular, this indicates to use 3041 the COSE key type OKP and the elliptic curve X25519 [RFC8032]. 3043 - The array [[EC2], [EC2, P-256]], in case ES256 [RFC6979] is 3044 specified for 'sign_alg'. In particular, this indicates to use 3045 the COSE key type EC2 and the elliptic curve P-256. 3047 - The array [[EC2], [EC2, P-384]], in case ES384 [RFC6979] is 3048 specified for 'sign_alg'. In particular, this indicates to use 3049 the COSE key type EC2 and the elliptic curve P-384. 3051 - The array [[EC2], [EC2, P-521]], in case ES512 [RFC6979] is 3052 specified for 'sign_alg'. In particular, this indicates to use 3053 the COSE key type EC2 and the elliptic curve P-521. 3055 24. Security Considerations 3057 Security considerations for this profile are inherited from 3058 [I-D.ietf-ace-key-groupcomm], the ACE framework for Authentication 3059 and Authorization [I-D.ietf-ace-oauth-authz], and the specific 3060 transport profile of ACE signalled by the AS, such as 3061 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile]. 3063 The following security considerations also apply for this profile. 3065 24.1. Management of OSCORE Groups 3067 This profile leverages the following management aspects related to 3068 OSCORE groups and discussed in the sections of 3069 [I-D.ietf-core-oscore-groupcomm] referred below. 3071 * Management of group keying material (see Section 3.2 of 3072 [I-D.ietf-core-oscore-groupcomm]). The Group Manager is 3073 responsible for the renewal and re-distribution of the keying 3074 material in the groups of its competence (rekeying). According to 3075 the specific application requirements, this can include rekeying 3076 the group upon changes in its membership. In particular, renewing 3077 the group keying material is required upon a new node's joining or 3078 a current node's leaving, in case backward security and forward 3079 security have to be preserved, respectively. 3081 * Provisioning and retrieval of public keys (see Section 3 of 3082 [I-D.ietf-core-oscore-groupcomm]). The Group Manager acts as key 3083 repository of public keys of group members, and provides them upon 3084 request. 3086 * Synchronization of sequence numbers (see Section 6.3 of 3087 [I-D.ietf-core-oscore-groupcomm]). This concerns how a responder 3088 node that has just joined an OSCORE group can synchronize with the 3089 sequence number of requesters in the same group. 3091 Before sending the Joining Response, the Group Manager MUST verify 3092 that the joining node actually owns the associated private key. To 3093 this end, the Group Manager can rely on the proof-of-possession 3094 challenge-response defined in Section 6. Alternatively, the joining 3095 node can use its own public key as asymmetric proof-of-possession key 3096 to establish a secure channel with the Group Manager, e.g., as in 3097 Section 3.2.2 of [I-D.ietf-ace-dtls-authorize]. However, this 3098 requires such proof-of-possession key to be compatible with the 3099 encoding, as well as with the signature algorithm, and possible 3100 associated parameters used in the OSCORE group. 3102 A node may have joined multiple OSCORE groups under different non- 3103 synchronized Group Managers. Therefore, it can happen that those 3104 OSCORE groups have the same Group Identifier (Gid). It follows that, 3105 upon receiving a Group OSCORE message addressed to one of those 3106 groups, the node would have multiple Security Contexts matching with 3107 the Gid in the incoming message. It is up to the application to 3108 decide how to handle such collisions of Group Identifiers, e.g., by 3109 trying to process the incoming message using one Security Context at 3110 the time until the right one is found. 3112 24.2. Size of Nonces as Proof-of-Possesion Challenge 3114 With reference to the Joining Request message in Section 6.2, the 3115 proof-of-possession (PoP) evidence included in 'client_cred_verify' 3116 is computed over an input including also N_C | N_S, where | denotes 3117 concatenation. 3119 For the N_C challenge, it is RECOMMENDED to use a 8-byte long random 3120 nonce. Furthermore, N_C is always conveyed in the 'cnonce' parameter 3121 of the Joining Request, which is always sent over the secure 3122 communication channel between the joining node and the Group Manager. 3124 As defined in Section 6.2.1, the way the N_S value is computed 3125 depends on the particular way the joining node provides the Group 3126 Manager with the Access Token, as well as on following interactions 3127 between the two. 3129 * If the Access Token has not been provided to the Group Manager by 3130 means of a Token Transfer Request to the /authz-info endpoint as 3131 in Section 6.1, then N_S is computed as a 32-byte long challenge. 3132 For an example, see point (2) of Section 6.2.1. 3134 * If the Access Token has been provided to the Group Manager by 3135 means of a Token Transfer Request to the /authz-info endpoint as 3136 in Section 6.1, then N_S takes the most recent value provided to 3137 the client by the Group Manager in the 'kdcchallenge' parameter, 3138 as specified in point (1) of Section 6.2.1. This is provided 3139 either in the Token Transfer Response (see Section 6.1), or in a 3140 4.00 (Bad Request) error response to a following Joining Request 3141 (see Section 6.3). In either case, it is RECOMMENDED to use a 3142 8-byte long random challenge as value for N_S. 3144 If we consider both N_C and N_S to take 8-byte long values, the 3145 following considerations hold. 3147 * Let us consider both N_C and N_S as taking random values, and the 3148 Group Manager to never change the value of the N_S provided to a 3149 Client during the lifetime of an Access Token. Then, as per the 3150 birthday paradox, the average collision for N_S will happen after 3151 2^32 new transferred Access Tokens, while the average collision 3152 for N_C will happen after 2^32 new Joining Requests. This amounts 3153 to considerably more token provisionings than the expected new 3154 joinings of OSCORE groups under a same Group Manager, as well as 3155 to considerably more requests to join OSCORE groups from a same 3156 Client using a same Access Token under a same Group Manager. 3158 * Section 7 of [I-D.ietf-ace-oscore-profile] as well Appendix B.2 of 3159 [RFC8613] recommend the use of 8-byte random values as well. 3160 Unlike in those cases, the values of N_C and N_S considered in 3161 this document are not used for as sensitive operations as the 3162 derivation of a Security Context, and thus do not have possible 3163 implications in the security of AEAD ciphers. 3165 24.3. Reusage of Nonces for Proof-of-Possession Input 3167 As long as the Group Manager preserves the same N_S value currently 3168 associated to an Access Token, i.e., the latest value provided to a 3169 Client in a 'kdcchallenge' parameter, the Client is able to 3170 successfully reuse the same proof-of-possession (PoP) input for 3171 multiple Joining Requests to that Group Manager. 3173 In particular, the Client can reuse the same N_C value for every 3174 Joining Request to the Group Manager, and combine it with the same 3175 unchanged N_S value. This results in reusing the same PoP input for 3176 producing the PoP evidence to include in the 'client_cred_verify' 3177 parameter of the Joining Requests. 3179 Unless the Group Manager maintains a list of N_C values already used 3180 by that Client since the latest update to the N_S value associated to 3181 the Access Token, the Group Manager can be forced to falsely believe 3182 that the Client possesses its own private key at that point in time, 3183 upon verifying the PoP evidence in the 'client_cred_verify' 3184 parameter. 3186 25. IANA Considerations 3188 Note to RFC Editor: Please replace all occurrences of "[[This 3189 document]]" with the RFC number of this specification and delete this 3190 paragraph. 3192 This document has the following actions for IANA. 3194 25.1. OAuth Parameters 3196 IANA is asked to register the following entries to the "OAuth 3197 Parameters" registry, as per the procedure specified in Section 11.2 3198 of [RFC6749]. 3200 * Parameter name: ecdh_info 3202 * Parameter usage location: client-rs request, rs-client response 3204 * Change Controller: IESG 3206 * Specification Document(s): [[This specification]] 3208 * Parameter name: gm_dh_pub_keys 3210 * Parameter usage location: client-rs request, rs-client response 3212 * Change Controller: IESG 3214 * Specification Document(s): [[This specification]] 3216 25.2. OAuth Parameters CBOR Mappings 3218 IANA is asked to register the following entries to the "OAuth 3219 Parameters CBOR Mappings" registry, as per the procedure specified in 3220 Section 8.10 of [I-D.ietf-ace-oauth-authz]. 3222 * Name: ecdh_info 3224 * CBOR Key: TBD (range -256 to 255) 3226 * Value Type: Simple value null / array 3228 * Reference: [[This specification]] 3230 * Name: gm_dh_pub_keys 3232 * CBOR Key: TBD (range -256 to 255) 3234 * Value Type: Simple value null / array 3236 * Reference: [[This specification]] 3238 25.3. ACE Groupcomm Parameters 3240 IANA is asked to register the following entry to the "ACE Groupcomm 3241 Parameters" registry defined in Section 11.7 of 3242 [I-D.ietf-ace-key-groupcomm]. 3244 * Name: group_senderId 3246 * CBOR Key: TBD 3248 * CBOR Type: Byte string 3250 * Reference: [[This document]] (Section 9) 3252 * Name: ecdh_info 3254 * CBOR Key: TBD 3256 * CBOR Type: Array 3258 * Reference: [[This document]] (Section 6.3) 3260 * Name: gm_dh_pub_keys 3262 * CBOR Key: TBD 3264 * CBOR Type: Array 3266 * Reference: [[This document]] (Section 6.3) 3268 * Name: group_enc_key 3270 * CBOR Key: TBD 3272 * CBOR Type: Byte String 3274 * Reference: [[This document]] (Section 5.2.1) 3276 * Name: stale_node_ids 3278 * CBOR Key: TBD 3280 * CBOR Type: Array 3281 * Reference: [[This document]] (Section 20) 3283 25.4. ACE Groupcomm Key Types 3285 IANA is asked to register the following entry to the "ACE Groupcomm 3286 Key Types" registry defined in Section 11.8 of 3287 [I-D.ietf-ace-key-groupcomm]. 3289 * Name: Group_OSCORE_Input_Material object 3291 * Key Type Value: GROUPCOMM_KEY_TBD 3293 * Profile: "coap_group_oscore_app", defined in Section 25.5 of this 3294 document. 3296 * Description: A Group_OSCORE_Input_Material object encoded as 3297 described in Section 6.4 of this document. 3299 * Reference: [[This document]] (Section 6.4) 3301 25.5. ACE Groupcomm Profiles 3303 IANA is asked to register the following entry to the "ACE Groupcomm 3304 Profiles" registry defined in Section 11.9 of 3305 [I-D.ietf-ace-key-groupcomm]. 3307 * Name: coap_group_oscore_app 3309 * Description: Application profile to provision keying material for 3310 participating in group communication protected with Group OSCORE 3311 as per [I-D.ietf-core-oscore-groupcomm]. 3313 * CBOR Value: PROFILE_TBD 3315 * Reference: [[This document]] (Section 6.4) 3317 25.6. OSCORE Security Context Parameters 3319 IANA is asked to register the following entries in the "OSCORE 3320 Security Context Parameters" registry defined in Section 9.4 of 3321 [I-D.ietf-ace-oscore-profile]. 3323 * Name: group_SenderId 3325 * CBOR Label: TBD 3327 * CBOR Type: bstr 3328 * Registry: - 3330 * Description: OSCORE Sender ID assigned to a member of an OSCORE 3331 group 3333 * Reference: [[This document]] (Section 6.4) 3335 * Name: pub_key_enc 3337 * CBOR Label: TBD 3339 * CBOR Type: integer 3341 * Registry: COSE Header Parameters 3343 * Description: Encoding of Public Keys to be used in the OSCORE 3344 group 3346 * Reference: [[This document]] (Section 6.4) 3348 * Name: sign_enc_alg 3350 * CBOR Label: TBD 3352 * CBOR Type: tstr / int 3354 * Registry: COSE Algorithms 3356 * Description: OSCORE Signature Encryption Algorithm Value 3358 * Reference: [[This document]] (Section 6.4) 3360 * Name: sign_alg 3362 * CBOR Label: TBD 3364 * CBOR Type: tstr / int 3366 * Registry: COSE Algorithms 3368 * Description: OSCORE Signature Algorithm Value 3370 * Reference: [[This document]] (Section 6.4) 3371 * Name: sign_params 3373 * CBOR Label: TBD 3375 * CBOR Type: array 3377 * Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves 3379 * Description: OSCORE Signature Algorithm Parameters 3381 * Reference: [[This document]] (Section 6.4) 3383 * Name: ecdh_alg 3385 * CBOR Label: TBD 3387 * CBOR Type: tstr / int 3389 * Registry: COSE Algorithms 3391 * Description: OSCORE Pairwise Key Agreement Algorithm Value 3393 * Reference: [[This document]] (Section 6.4) 3395 * Name: ecdh_params 3397 * CBOR Label: TBD 3399 * CBOR Type: array 3401 * Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves 3403 * Description: OSCORE Pairwise Key Agreement Algorithm Parameters 3405 * Reference: [[This document]] (Section 6.4) 3407 25.7. TLS Exporter Labels 3409 IANA is asked to register the following entry to the "TLS Exporter 3410 Labels" registry defined in Section 6 of [RFC5705] and updated in 3411 Section 12 of [RFC8447]. 3413 * Value: EXPORTER-ACE-Sign-Challenge-coap-group-oscore-app 3415 * DTLS-OK: Y 3416 * Recommended: N 3418 * Reference: [[This document]] (Section 6.2.1) 3420 25.8. AIF 3422 IANA is asked to register the following entry to the "Toid" registry 3423 within the "AIF" registry group defined in Section 5.2 of 3424 [I-D.ietf-ace-aif]. 3426 * Name: oscore-group-name 3428 * Description/Specification: group name of the OSCORE group, as 3429 specified in [[This document]]. 3431 IANA is asked to register the following entry to the "Tperm" registry 3432 within the "AIF" registry group defined in Section 5.2 of 3433 [I-D.ietf-ace-aif]. 3435 * Name: oscore-group-roles 3437 * Description/Specification: role(s) of the member of the OSCORE 3438 group, as specified in [[This document]]. 3440 25.9. Media Type Registrations 3442 This document registers the 'application/aif-groupcomm-oscore+cbor' 3443 media type for the AIF specific data model AIF-OSCORE-GROUPCOMM 3444 defined in Section 3 of [[This document]]. This registration follows 3445 the procedures specified in [RFC6838]. 3447 These media type has parameters for specifying the object identifier 3448 ("Toid") and set of permissions ("Tperm") defined for the AIF-generic 3449 model in [I-D.ietf-ace-aif]; default values are the values "oscore- 3450 group-name" for "Toid" and "oscore-group-roles" for "Tperm". 3452 Type name: application 3454 Subtype name: aif-groupcomm-oscore+cbor 3456 Required parameters: "Toid", "Tperm" 3458 Optional parameters: N/A 3460 Encoding considerations: Must be encoded as a CBOR array, each 3461 element of which is an array [Toid, Tperm] as defined in Section 3 of 3462 [[This document]]. 3464 Security considerations: See Section 24 of [[This document]]. 3466 Interoperability considerations: N/A 3468 Published specification: [[This document]] 3470 Applications that use this media type: The type is used by 3471 applications that want to express authorization information about 3472 joining OSCORE groups, as specified in [[This document]]. 3474 Fragment identifier considerations: N/A 3476 Additional information: N/A 3478 Person & email address to contact for further information: 3479 iesg@ietf.org (mailto:iesg@ietf.org) 3481 Intended usage: COMMON 3483 Restrictions on usage: None 3485 Author: Marco Tiloca marco.tiloca@ri.se (mailto:marco.tiloca@ri.se) 3487 Change controller: IESG 3489 Provisional registration? No 3491 25.10. CoAP Content-Format 3493 IANA is asked to register the following entry to the "CoAP Content- 3494 Formats" registry within the "Constrained RESTful Environments (CoRE) 3495 Parameters" registry group: 3497 Media Type: application/aif-groupcomm-oscore+cbor;Toid="oscore-group- 3498 name",Tperm"oscore-group-roles" 3500 Encoding: - 3502 ID: TBD 3504 Reference: [[This document]] 3506 25.11. Group OSCORE Roles 3508 This document establishes the IANA "Group OSCORE Roles" registry. 3509 The registry has been created to use the "Expert Review" registration 3510 procedure [RFC8126]. Expert review guidelines are provided in 3511 Section 25.15. 3513 This registry includes the possible roles that nodes can take in an 3514 OSCORE group, each in combination with a numeric identifier. These 3515 numeric identifiers are used to express authorization information 3516 about joining OSCORE groups, as specified in Section 3 of [[This 3517 document]]. 3519 The columns of this registry are: 3521 * Name: A value that can be used in documents for easier 3522 comprehension, to identify a possible role that nodes can take in 3523 an OSCORE group. 3525 * Value: The numeric identifier for this role. Integer values 3526 greater than 65535 are marked as "Private Use", all other values 3527 use the registration policy "Expert Review" [RFC8126]. 3529 * Description: This field contains a brief description of the role. 3531 * Reference: This contains a pointer to the public specification for 3532 the role. 3534 This registry will be initially populated by the values in Figure 1. 3536 The Reference column for all of these entries will be [[This 3537 document]]. 3539 25.12. CoRE Resource Type 3541 IANA is asked to register the following entry in the "Resource Type 3542 (rt=) Link Target Attribute Values" registry within the "Constrained 3543 Restful Environments (CoRE) Parameters" registry group. 3545 * Value: "core.osc.gm" 3547 * Description: Group-membership resource of an OSCORE Group Manager. 3549 * Reference: [[This document]] 3551 Client applications can use this resource type to discover a group 3552 membership resource at an OSCORE Group Manager, where to send a 3553 request for joining the corresponding OSCORE group. 3555 25.13. ACE Scope Semantics 3557 IANA is asked to register the following entry in the "ACE Scope 3558 Semantics" registry defined in Section 11.12 of 3559 [I-D.ietf-ace-key-groupcomm]. 3561 * Value: SEM_ID_TBD 3563 * Description: Access to OSCORE groups through the ACE Group 3564 Manager. 3566 * Reference: [[This document]] 3568 25.14. ACE Groupcomm Errors 3570 IANA is asked to register the following entry in the "ACE Groupcomm 3571 Errors" registry defined in Section 11.13 of 3572 [I-D.ietf-ace-key-groupcomm]. 3574 * Value: 7 3576 * Description: Signatures not used in the group. 3578 * Reference: [[This document]] 3580 * Value: 8 3582 * Description: Operation permitted only to signature verifiers. 3584 * Reference: [[This document]] 3586 * Value: 9 3588 * Description: Group currently not active. 3590 * Reference: [[This document]] 3592 25.15. Expert Review Instructions 3594 The IANA registry established in this document is defined as "Expert 3595 Review". This section gives some general guidelines for what the 3596 experts should be looking for, but they are being designated as 3597 experts for a reason so they should be given substantial latitude. 3599 Expert reviewers should take into consideration the following points: 3601 * Clarity and correctness of registrations. Experts are expected to 3602 check the clarity of purpose and use of the requested entries. 3603 Experts should inspect the entry for the considered role, to 3604 verify the correctness of its description against the role as 3605 intended in the specification that defined it. Expert should 3606 consider requesting an opinion on the correctness of registered 3607 parameters from the Authentication and Authorization for 3608 Constrained Environments (ACE) Working Group and the Constrained 3609 RESTful Environments (CoRE) Working Group. 3611 Entries that do not meet these objective of clarity and 3612 completeness should not be registered. 3614 * Duplicated registration and point squatting should be discouraged. 3615 Reviewers are encouraged to get sufficient information for 3616 registration requests to ensure that the usage is not going to 3617 duplicate one that is already registered and that the point is 3618 likely to be used in deployments. 3620 * Experts should take into account the expected usage of roles when 3621 approving point assignment. Given a 'Value' V as code point, the 3622 length of the encoding of (2^(V+1) - 1) should be weighed against 3623 the usage of the entry, considering the resources and capabilities 3624 of devices it will be used on. Additionally, given a 'Value' V as 3625 code point, the length of the encoding of (2^(V+1) - 1) should be 3626 weighed against how many code points resulting in that encoding 3627 length are left, and the resources and capabilities of devices it 3628 will be used on. 3630 * Specifications are recommended. When specifications are not 3631 provided, the description provided needs to have sufficient 3632 information to verify the points above. 3634 26. References 3636 26.1. Normative References 3638 [COSE.Algorithms] 3639 IANA, "COSE Algorithms", 3640 . 3643 [COSE.Elliptic.Curves] 3644 IANA, "COSE Elliptic Curves", 3645 . 3648 [COSE.Header.Parameters] 3649 IANA, "COSE Header Parameters", 3650 . 3653 [COSE.Key.Types] 3654 IANA, "COSE Key Types", 3655 . 3658 [I-D.ietf-ace-aif] 3659 Bormann, C., "An Authorization Information Format (AIF) 3660 for ACE", Work in Progress, Internet-Draft, draft-ietf- 3661 ace-aif-03, 24 June 2021, 3662 . 3665 [I-D.ietf-ace-key-groupcomm] 3666 Palombini, F. and M. Tiloca, "Key Provisioning for Group 3667 Communication using ACE", Work in Progress, Internet- 3668 Draft, draft-ietf-ace-key-groupcomm-14, 25 October 2021, 3669 . 3672 [I-D.ietf-ace-oauth-authz] 3673 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 3674 H. Tschofenig, "Authentication and Authorization for 3675 Constrained Environments (ACE) using the OAuth 2.0 3676 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 3677 draft-ietf-ace-oauth-authz-45, 29 August 2021, 3678 . 3681 [I-D.ietf-ace-oscore-profile] 3682 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 3683 "OSCORE Profile of the Authentication and Authorization 3684 for Constrained Environments Framework", Work in Progress, 3685 Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May 3686 2021, . 3689 [I-D.ietf-core-oscore-groupcomm] 3690 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 3691 and J. Park, "Group OSCORE - Secure Group Communication 3692 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 3693 core-oscore-groupcomm-13, 25 October 2021, 3694 . 3697 [I-D.ietf-cose-rfc8152bis-algs] 3698 Schaad, J., "CBOR Object Signing and Encryption (COSE): 3699 Initial Algorithms", Work in Progress, Internet-Draft, 3700 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 3701 . 3704 [I-D.ietf-cose-rfc8152bis-struct] 3705 Schaad, J., "CBOR Object Signing and Encryption (COSE): 3706 Structures and Process", Work in Progress, Internet-Draft, 3707 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 3708 . 3711 [NIST-800-56A] 3712 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 3713 Davis, "Recommendation for Pair-Wise Key-Establishment 3714 Schemes Using Discrete Logarithm Cryptography - NIST 3715 Special Publication 800-56A, Revision 3", April 2018, 3716 . 3719 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3720 Requirement Levels", BCP 14, RFC 2119, 3721 DOI 10.17487/RFC2119, March 1997, 3722 . 3724 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 3725 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 3726 March 2010, . 3728 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 3729 Specifications and Registration Procedures", BCP 13, 3730 RFC 6838, DOI 10.17487/RFC6838, January 2013, 3731 . 3733 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 3734 Algorithm (DSA) and Elliptic Curve Digital Signature 3735 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 3736 2013, . 3738 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 3739 Application Protocol (CoAP)", RFC 7252, 3740 DOI 10.17487/RFC7252, June 2014, 3741 . 3743 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 3744 for Security", RFC 7748, DOI 10.17487/RFC7748, January 3745 2016, . 3747 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 3748 "PKCS #1: RSA Cryptography Specifications Version 2.2", 3749 RFC 8017, DOI 10.17487/RFC8017, November 2016, 3750 . 3752 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 3753 Signature Algorithm (EdDSA)", RFC 8032, 3754 DOI 10.17487/RFC8032, January 2017, 3755 . 3757 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3758 Writing an IANA Considerations Section in RFCs", BCP 26, 3759 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3760 . 3762 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3763 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3764 May 2017, . 3766 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3767 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3768 . 3770 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 3771 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 3772 . 3774 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 3775 Definition Language (CDDL): A Notational Convention to 3776 Express Concise Binary Object Representation (CBOR) and 3777 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 3778 June 2019, . 3780 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 3781 "Object Security for Constrained RESTful Environments 3782 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 3783 . 3785 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 3786 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 3787 . 3789 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 3790 Representation (CBOR)", STD 94, RFC 8949, 3791 DOI 10.17487/RFC8949, December 2020, 3792 . 3794 26.2. Informative References 3796 [I-D.ietf-ace-dtls-authorize] 3797 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 3798 L. Seitz, "Datagram Transport Layer Security (DTLS) 3799 Profile for Authentication and Authorization for 3800 Constrained Environments (ACE)", Work in Progress, 3801 Internet-Draft, draft-ietf-ace-dtls-authorize-18, 4 June 3802 2021, . 3805 [I-D.ietf-ace-oscore-gm-admin] 3806 Tiloca, M., Höglund, R., Stok, P. V. D., and F. Palombini, 3807 "Admin Interface for the OSCORE Group Manager", Work in 3808 Progress, Internet-Draft, draft-ietf-ace-oscore-gm-admin- 3809 04, 25 October 2021, . 3812 [I-D.ietf-core-coap-pubsub] 3813 Koster, M., Keranen, A., and J. Jimenez, "Publish- 3814 Subscribe Broker for the Constrained Application Protocol 3815 (CoAP)", Work in Progress, Internet-Draft, draft-ietf- 3816 core-coap-pubsub-09, 30 September 2019, 3817 . 3820 [I-D.ietf-core-groupcomm-bis] 3821 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 3822 for the Constrained Application Protocol (CoAP)", Work in 3823 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 3824 05, 25 October 2021, . 3827 [I-D.ietf-cose-cbor-encoded-cert] 3828 Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and 3829 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 3830 Certificates)", Work in Progress, Internet-Draft, draft- 3831 ietf-cose-cbor-encoded-cert-02, 12 July 2021, 3832 . 3835 [I-D.tiloca-core-oscore-discovery] 3836 Tiloca, M., Amsuess, C., and P. V. D. Stok, "Discovery of 3837 OSCORE Groups with the CoRE Resource Directory", Work in 3838 Progress, Internet-Draft, draft-tiloca-core-oscore- 3839 discovery-10, 25 October 2021, 3840 . 3843 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 3844 Key Derivation Function (HKDF)", RFC 5869, 3845 DOI 10.17487/RFC5869, May 2010, 3846 . 3848 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3849 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 3850 January 2012, . 3852 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 3853 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 3854 . 3856 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 3857 RFC 6749, DOI 10.17487/RFC6749, October 2012, 3858 . 3860 [RFC7641] Hartke, K., "Observing Resources in the Constrained 3861 Application Protocol (CoAP)", RFC 7641, 3862 DOI 10.17487/RFC7641, September 2015, 3863 . 3865 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 3866 Security (TLS) / Datagram Transport Layer Security (DTLS) 3867 Profiles for the Internet of Things", RFC 7925, 3868 DOI 10.17487/RFC7925, July 2016, 3869 . 3871 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 3872 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 3873 May 2018, . 3875 Appendix A. Profile Requirements 3877 This section lists how this application profile of ACE addresses the 3878 requirements defined in Appendix A of [I-D.ietf-ace-key-groupcomm]. 3880 A.1. Mandatory-to-Address Requirements 3881 * REQ1 - Specify the format and encoding of 'scope'. This includes 3882 defining the set of possible roles and their identifiers, as well 3883 as the corresponding encoding to use in the scope entries 3884 according to the used scope format: see Section 3 and Section 4.1. 3886 * REQ2 - If the AIF format of 'scope' is used, register its specific 3887 instance of "Toid" and "Tperm", as well as the corresponding Media 3888 Type and Content-Format, as per the guidelines in 3889 [I-D.ietf-ace-aif]: see Section 25.8, Section 25.9 and 3890 Section 25.10. 3892 * REQ3 - if used, specify the acceptable values for 'sign_alg': 3893 values from the "Value" column of the "COSE Algorithms" registry 3894 [COSE.Algorithms]. 3896 * REQ4 - If used, specify the acceptable values for 3897 'sign_parameters': format and values from the COSE algorithm 3898 capabilities as specified in the "COSE Algorithms" registry 3899 [COSE.Algorithms]. 3901 * REQ5 - If used, specify the acceptable values for 3902 'sign_key_parameters': format and values from the COSE key type 3903 capabilities as specified in the "COSE Key Types" registry 3904 [COSE.Key.Types]. 3906 * REQ6 - Specify the acceptable formats for encoding public keys 3907 and, if used, the acceptable values for 'pub_key_enc': acceptable 3908 formats explicitly provide the full set of information related to 3909 the public key algorithm (see Section 6.1 and Section 6.4). 3910 Consistent acceptable values for 'pub_key_enc' are taken from the 3911 "Label" column of the "COSE Header Parameters" registry 3912 [COSE.Header.Parameters]. 3914 * REQ7 - If the value of the GROUPNAME URI path and the group name 3915 in the Access Token scope (gname in Section 3.1 of 3916 [I-D.ietf-ace-key-groupcomm]) are not required to coincide, 3917 specify the mechanism to map the GROUPNAME value in the URI to the 3918 group name: not applicable, since a perfect matching is required. 3920 * REQ8 - Define whether the KDC has a public key and if this has to 3921 be provided through the 'kdc_cred' parameter, see Section 4.1 of 3922 [I-D.ietf-ace-key-groupcomm]: yes, as required by the Group OSCORE 3923 protocol [I-D.ietf-core-oscore-groupcomm], see Section 6.4 of this 3924 document. 3926 * REQ9 - Specify if any part of the KDC interface as defined in 3927 Section 4.1 of [I-D.ietf-ace-key-groupcomm] is not supported by 3928 the KDC: not applicable. 3930 * REQ10 - Register a Resource Type for the root url-path, which is 3931 used to discover the correct url to access at the KDC (see 3932 Section 4.1 of [I-D.ietf-ace-key-groupcomm]): the Resource Type 3933 (rt=) Link Target Attribute value "core.osc.gm" is registered in 3934 Section 25.12. 3936 * REQ11 - Define what specific actions (e.g., CoAP methods) are 3937 allowed on each resource provided by the KDC interface, depending 3938 on whether the Client is a current group member; the roles that a 3939 Client is authorized to take as per the obtained access token; and 3940 the roles that the Client has as current group member: see 3941 Section 5.4. 3943 * REQ12 - Categorize possible newly defined operations for Clients 3944 into primary operations expected to be minimally supported and 3945 secondary operations, and provide accompanying considerations (see 3946 Section 5.5). 3948 * REQ13 - Specify the encoding of group identifier (see 3949 Section 4.2.1 of [I-D.ietf-ace-key-groupcomm]): CBOR byte string 3950 (see Section 17). 3952 * REQ14 - Specify the approaches used to compute and verify the PoP 3953 evidence to include in 'client_cred_verify', and which of those 3954 approaches is used in which case: see Section 6.2 and Section 6.3. 3956 * REQ15 - Specify how the nonce N_S is generated, if the token is 3957 not provided to the KDC through the Token Transfer Request to the 3958 authz-info endpoint (e.g., if it is used directly to validate TLS 3959 instead): see Section 6.2.1. 3961 * REQ16 - Define the initial value of the 'num' parameter: The 3962 initial value MUST be set to 0 when creating the OSCORE group, 3963 e.g., as in [I-D.ietf-ace-oscore-gm-admin]. 3965 * REQ17 - Specify the format of the 'key' parameter: see 3966 Section 6.4. 3968 * REQ18 - Specify acceptable values of the 'gkty' parameter: 3969 Group_OSCORE_Input_Material object (see Section 6.4). 3971 * REQ19 - Specify and register the application profile identifier: 3972 coap_group_oscore_app (see Section 25.5). 3974 * REQ20 - If used, specify the format and content of 3975 'group_policies' and its entries: see Section 6.4. 3977 * REQ21 - Specify the approaches used to compute and verify the PoP 3978 evidence to include in 'kdc_cred_verify', and which of those 3979 approaches is used in which case: see Section 6.4, Section 6.5 and 3980 Section 12. 3982 * REQ22 - Specify the communication protocol that the members of the 3983 group must use: CoAP [RFC7252], possibly over IP multicast 3984 [I-D.ietf-core-groupcomm-bis]. 3986 * REQ23 - Specify the security protocols that the group members must 3987 use to protect their communication: Group OSCORE 3988 [I-D.ietf-core-oscore-groupcomm]. 3990 * REQ24 - Specify how the communication is secured between the 3991 Client and KDC: by means of any transport profile of ACE 3992 [I-D.ietf-ace-oauth-authz] between Client and Group Manager that 3993 complies with the requirements in Appendix C of 3994 [I-D.ietf-ace-oauth-authz]. 3996 * REQ25 - Specify the format of the identifiers of group members: 3997 the Sender ID used in the OSCORE group (see Section 6.4 and 3998 Section 10). 4000 * REQ26 - Specify policies at the KDC to handle member ids that are 4001 not included in 'get_pub_keys': see Section 10. 4003 * REQ27 - Specify the format of newly-generated individual keying 4004 material for group members, or of the information to derive it, 4005 and corresponding CBOR label: see Section 9. 4007 * REQ28 - Specify and register the identifier of newly defined 4008 semantics for binary scopes: see Section 25.13. 4010 * REQ29 - Categorize newly defined parameters according to the same 4011 criteria of Section 8 of [I-D.ietf-ace-key-groupcomm]: see 4012 Section 21. 4014 * REQ30 - Define whether Clients must, should or may support the 4015 conditional parameters defined in Section 8 of 4016 [I-D.ietf-ace-key-groupcomm], and under which circumstances: see 4017 Section 21. 4019 A.2. Optional-to-Address Requirements 4021 * OPT1 (Optional) - If the textual format of 'scope' is used, 4022 specify CBOR values to use for abbreviating the role identifiers 4023 in the group: not applicable. 4025 * OPT2 (Optional) - Specify additional parameters used in the 4026 exchange of Token Transfer Request and Response: 4028 - 'ecdh_info', to negotiate the ECDH algorithm, ECDH algorithm 4029 parameters, ECDH key parameters and exact encoding of public 4030 keys used in the group, in case the joining node supports the 4031 pairwise mode of Group OSCORE (see Section 6.1). 4033 - 'gm_dh_pub_keys', to ask for and retrieve the Group Manager's 4034 Diffie-Hellman public keys, in case the the joining node 4035 supports the pairwise mode of Group OSCORE and the Access Token 4036 authorizes to join parwise-only groups (see Section 6.1). 4038 * OPT3 (Optional) - Specify the negotiation of parameter values for 4039 signature algorithm and signature keys, if 'sign_info' is not 4040 used: possible early discovery by using the approach based on the 4041 CoRE Resource Directory described in 4042 [I-D.tiloca-core-oscore-discovery]. 4044 * OPT4 (Optional) - Specify possible or required payload formats for 4045 specific error cases: send a 4.00 (Bad Request) error response to 4046 a Joining Request (see Section 6.3). 4048 * OPT5 (Optional) - Specify additional identifiers of error types, 4049 as values of the 'error' field in an error response from the KDC: 4050 see Section 25.14. 4052 * OPT6 (Optional) - Specify the encoding of 'pub_keys_repos' if the 4053 default is not used: no. 4055 * OPT7 (Optional) - Specify the functionalities implemented at the 4056 'control_uri' resource hosted at the Client, including message 4057 exchange encoding and other details (see Section 4.3.1 of 4058 [I-D.ietf-ace-key-groupcomm]): see Section 19 for the eviction of 4059 a group member; see Section 20 for the group rekeying process. 4061 * OPT8 (Optional) - Specify the behavior of the handler in case of 4062 failure to retrieve a public key for the specific node: send a 4063 4.00 (Bad Request) error response to a Joining Request (see 4064 Section 6.3). 4066 * OPT9 (Optional) - Define a default group rekeying scheme, to refer 4067 to in case the 'rekeying_scheme' parameter is not included in the 4068 Joining Response (see Section 4.3.1.1 of 4069 [I-D.ietf-ace-key-groupcomm]): the "Point-to-Point" rekeying 4070 scheme registered in Section 11.14 of 4071 [I-D.ietf-ace-key-groupcomm], whose detailed use for this profile 4072 is defined in Section 20 of this document. 4074 * OPT10 (Optional) - Specify the functionalities implemented at the 4075 'control_group_uri' resource hosted at the Client, including 4076 message exchange encoding and other details (see Section 4.3.1 of 4077 [I-D.ietf-ace-key-groupcomm]): see Section 19 for the eviction of 4078 multiple group members. 4080 * OPT11 (Optional) - Specify policies that instruct clients to 4081 retain unsuccessfully decrypted messages and for how long, so that 4082 they can be decrypted after getting updated keying material: no. 4084 * OPT12 (Optional) - Specify for the KDC to perform group rekeying 4085 (together or instead of renewing individual keying material) when 4086 receiving a Key Renewal Request: the Group Manager SHOULD NOT 4087 perform a group rekeying, unless already scheduled to occur 4088 shortly (see Section 9). 4090 * OPT13 (Optional) - Specify how the identifier of a group members's 4091 public key is included in requests sent to other group members: 4092 no. 4094 * OPT14 (Optional) - Specify additional information to include in 4095 rekeying messages for the "Point-to-Point" group rekeying scheme 4096 (see Section 6.1 of [I-D.ietf-ace-key-groupcomm]): see 4097 Section 20.1. 4099 * OPT15 (Optional) - Specify if Clients must or should support any 4100 of the parameters defined as optional in Section 8 of 4101 [I-D.ietf-ace-key-groupcomm]: no. 4103 Appendix B. Extensibility for Future COSE Algorithms 4105 As defined in Section 8.1 of [I-D.ietf-cose-rfc8152bis-algs], future 4106 algorithms can be registered in the "COSE Algorithms" registry 4107 [COSE.Algorithms] as specifying none or multiple COSE capabilities. 4109 To enable the seamless use of such future registered algorithms, this 4110 section defines a general, agile format for: 4112 * Each 'ecdh_info_entry' of the 'ecdh_info' parameter in the Token 4113 Transfer Response, see Section 6.1 and Section 6.1.1; 4115 * The 'sign_params' and 'ecdh_params' parameters within the 'key' 4116 parameter, see Section 6.4, as part of the response payloads used 4117 in Section 6.4, Section 8.1, Section 8.2 and Section 20. 4119 Appendix B of [I-D.ietf-ace-key-groupcomm] describes the analogous 4120 general format for 'sign_info_entry' of the 'sign_info' parameter in 4121 the Token Transfer Response, see Section 6.1. 4123 If any of the currently registered COSE algorithms is considered, 4124 using this general format yields the same structure defined in this 4125 document for the items above, thus ensuring retro-compatibility. 4127 B.1. Format of 'ecdh_info_entry' 4129 The format of each 'ecdh_info_entry' (see Section 6.1 and 4130 Section 6.1.1) is generalized as follows. Given N the number of 4131 elements of the 'ecdh_parameters' array, i.e., the number of COSE 4132 capabilities of the ECDH algorithm, then: 4134 * 'ecdh_key_parameters' is replaced by N elements 'ecdh_capab_i', 4135 each of which is a CBOR array. 4137 * The i-th array following 'ecdh_parameters', i.e., 'ecdh_capab_i' 4138 (i = 0, ..., N-1), is the array of COSE capabilities for the 4139 algorithm capability specified in 'ecdh_parameters'[i]. 4141 ecdh_info_entry = 4142 [ 4143 id : gname / [ + gname ], 4144 ecdh_alg : int / tstr, 4145 ecdh_parameters : [ alg_capab_1 : any, 4146 alg_capab_2 : any, 4147 ..., 4148 alg_capab_N : any], 4149 ecdh_capab_1 : [ any ], 4150 ecdh_capab_2 : [ any ], 4151 ..., 4152 ecdh_capab_N : [ any ], 4153 pub_key_enc = int / nil 4154 ] 4156 gname = tstr 4158 Figure 12: 'ecdh_info_entry' with general format 4160 B.2. Format of 'key' 4162 The format of 'key' (see Section 6.4) is generalized as follows. 4164 * The 'sign_params' array includes N+1 elements, whose exact 4165 structure and value depend on the value of the signature algorithm 4166 specified in 'sign_alg'. 4168 - The first element, i.e., 'sign_params'[0], is the array of the 4169 N COSE capabilities for the signature algorithm, as specified 4170 for that algorithm in the "Capabilities" column of the "COSE 4171 Algorithms" registry [COSE.Algorithms] (see Section 8.1 of 4172 [I-D.ietf-cose-rfc8152bis-algs]). 4174 - Each following element 'sign_params'[i], i.e., with index i > 4175 0, is the array of COSE capabilities for the algorithm 4176 capability specified in 'sign_params'[0][i-1]. 4178 For example, if 'sign_params'[0][0] specifies the key type as 4179 capability of the algorithm, then 'sign_params'[1] is the array of 4180 COSE capabilities for the COSE key type associated to the 4181 signature algorithm, as specified for that key type in the 4182 "Capabilities" column of the "COSE Key Types" registry 4183 [COSE.Key.Types] (see Section 8.2 of 4184 [I-D.ietf-cose-rfc8152bis-algs]). 4186 * The 'ecdh_params' array includes M+1 elements, whose exact 4187 structure and value depend on the value of the ECDH algorithm 4188 specified in 'ecdh_alg'. 4190 - The first element, i.e., 'ecdh_params'[0], is the array of the 4191 M COSE capabilities for the ECDH algorithm, as specified for 4192 that algorithm in the "Capabilities" column of the "COSE 4193 Algorithms" registry [COSE.Algorithms] (see Section 8.1 of 4194 [I-D.ietf-cose-rfc8152bis-algs]). 4196 - Each following element 'ecdh_params'[i], i.e., with index i > 4197 0, is the array of COSE capabilities for the algorithm 4198 capability specified in 'ecdh_params'[0][i-1]. 4200 For example, if 'ecdh_params'[0][0] specifies the key type as 4201 capability of the algorithm, then 'ecdh_params'[1] is the array of 4202 COSE capabilities for the COSE key type associated to the ECDH 4203 algorithm, as specified for that key type in the "Capabilities" 4204 column of the "COSE Key Types" registry [COSE.Key.Types] (see 4205 Section 8.2 of [I-D.ietf-cose-rfc8152bis-algs]). 4207 Appendix C. Document Updates 4209 RFC EDITOR: PLEASE REMOVE THIS SECTION. 4211 C.1. Version -11 to -12 4213 * Clarified semantics of 'ecdh_info' and 'gm_dh_pub_keys'. 4215 * Definition of /ace-group/GROUPNAME/kdc-pub-key moved to draft- 4216 ietf-ace-key-groupcomm. 4218 * ace-group/ accessible also to non-members that are not Verifiers. 4220 * Clarified what resources are accessible to Verifiers. 4222 * Revised error handling for the newly defined resources. 4224 * Revised use of CoAP error codes. 4226 * Use of "Token Tranfer Request" and "Token Transfer Response". 4228 * New parameter 'rekeying_scheme'. 4230 * Categorization of new parameters and inherited conditional 4231 parameters. 4233 * Clarifications on what to do in case of enhanced error responses. 4235 * Changed UCCS to CCS. 4237 * Public keys of just joined Clients can be in rekeying messages. 4239 * Revised names of new IANA registries. 4241 * Clarified meaning of registered CoRE resource type. 4243 * Alignment to new requirements from draft-ietf-ace-key-groupcomm. 4245 * Fixes and editorial improvements. 4247 C.2. Version -10 to -11 4249 * Removed redundancy of key type capabilities, from 'sign_info', 4250 'ecdh_info' and 'key'. 4252 * New resource to retrieve the Group Manager's public key. 4254 * New resource to retrieve material for Signature Verifiers. 4256 * New parameter 'sign_enc_alg' related to the group mode. 4258 * 'pub_key_enc' takes value from the COSE Header Parameters 4259 registry. 4261 * Improved alignment of the Joining Response payload with the Group 4262 OSCORE Security Context parameters. 4264 * Recycling Group IDs by tracking "Birth GIDs". 4266 * Error handling in case of non available Sender IDs upon joining. 4268 * Error handling in case EdDSA public keys with invalid Y coordinate 4269 when the pairwise mode of Group OSCORE is supported. 4271 * Generalized proof-of-possession (PoP) for the joining node's 4272 private key; defined Diffie-Hellman based PoP for OSCORE groups 4273 using only the pairwise mode. 4275 * Proof-of-possession of the Group Manager's private key in the 4276 Joining Response. 4278 * Always use 'peer_identifiers' to convey Sender IDs as node 4279 identifiers. 4281 * Stale Sender IDs provided when rekeying the group. 4283 * New resource for late retrieval of stale Sender IDs. 4285 * Added examples of message exchanges. 4287 * Revised default values of group configuration parameters. 4289 * Fixes to IANA registrations. 4291 * General format of parameters related to COSE capabilities, 4292 supporting future registered COSE algorithms (new Appendix). 4294 C.3. Version -09 to -10 4296 * Updated non-recycling policy of Sender IDs. 4298 * Removed policies about Sender Sequence Number synchronization. 4300 * 'control_path' renamed to 'control_uri'. 4302 * Format of 'get_pub_keys' aligned with draft-ietf-ace-key- 4303 groupcomm. 4305 * Additional way to inform of group eviction. 4307 * Registered semantics identifier for extended scope format. 4309 * Extended error handling, with error type specified in some error 4310 responses. 4312 * Renumbered requirements. 4314 C.4. Version -08 to -09 4316 * The url-path "ace-group" is used. 4318 * Added overview of admitted methods on the Group Manager resources. 4320 * Added exchange of parameters relevant for the pairwise mode of 4321 Group OSCORE. 4323 * The signed value for 'client_cred_verify' includes also the scope. 4325 * Renamed the key material object as Group_OSCORE_Input_Material 4326 object. 4328 * Replaced 'clientId' with 'group_SenderId'. 4330 * Added message exchange for Group Names request-response. 4332 * No reassignment of Sender ID and Gid in the same OSCORE group. 4334 * Updates on group rekeying contextual with request of new Sender 4335 ID. 4337 * Signature verifiers can also retrieve Group Names and URIs. 4339 * Removed group policy about supporting Group OSCORE in pairwise 4340 mode. 4342 * Registration of the resource type rt="core.osc.gm". 4344 * Update list of requirements. 4346 * Clarifications and editorial revision. 4348 C.5. Version -07 to -08 4350 * AIF specific data model to express scope entries. 4352 * A set of roles is checked as valid when processing the Joining 4353 Request. 4355 * Updated format of 'get_pub_keys' in the Joining Request. 4357 * Payload format and default values of group policies in the Joining 4358 Response. 4360 * Updated payload format of the FETCH request to retrieve public 4361 keys. 4363 * Default values for group configuration parameters. 4365 * IANA registrations to support the AIF specific data model. 4367 C.6. Version -06 to -07 4369 * Alignments with draft-ietf-core-oscore-groupcomm. 4371 * New format of 'sign_info', using the COSE capabilities. 4373 * New format of Joining Response parameters, using the COSE 4374 capabilities. 4376 * Considerations on group rekeying. 4378 * Editorial revision. 4380 C.7. Version -05 to -06 4382 * Added role of external signature verifier. 4384 * Parameter 'rsnonce' renamed to 'kdcchallenge'. 4386 * Parameter 'kdcchallenge' may be omitted in some cases. 4388 * Clarified difference between group name and OSCORE Gid. 4390 * Removed the role combination ["requester", "monitor"]. 4392 * Admit implicit scope and audience in the Authorization Request. 4394 * New format for the 'sign_info' parameter. 4396 * Scope not mandatory to include in the Joining Request. 4398 * Group policy about supporting Group OSCORE in pairwise mode. 4400 * Possible individual rekeying of a single requesting node combined 4401 with a group rekeying. 4403 * Security considerations on reusage of signature challenges. 4405 * Addressing optional requirement OPT12 from draft-ietf-ace-key- 4406 groupcomm 4408 * Editorial improvements. 4410 C.8. Version -04 to -05 4412 * Nonce N_S also in error responses to the Joining Requests. 4414 * Supporting single Access Token for multiple groups/topics. 4416 * Supporting legal requesters/responders using the 'peer_roles' 4417 parameter. 4419 * Registered and used dedicated label for TLS Exporter. 4421 * Added method for uploading a new public key to the Group Manager. 4423 * Added resource and method for retrieving the current group status. 4425 * Fixed inconsistency in retrieving group keying material only. 4427 * Clarified retrieval of keying material for monitor-only members. 4429 * Clarification on incrementing version number when rekeying the 4430 group. 4432 * Clarification on what is re-distributed with the group rekeying. 4434 * Security considerations on the size of the nonces used for the 4435 signature challenge. 4437 * Added CBOR values to abbreviate role identifiers in the group. 4439 C.9. Version -03 to -04 4441 * New abstract. 4443 * Moved general content to draft-ietf-ace-key-groupcomm 4445 * Terminology: node name; node resource. 4447 * Creation and pointing at node resource. 4449 * Updated Group Manager API (REST methods and offered services). 4451 * Size of challenges 'cnonce' and 'rsnonce'. 4453 * Value of 'rsnonce' for reused or non-traditionally-posted tokens. 4455 * Removed reference to RFC 7390. 4457 * New requirements from draft-ietf-ace-key-groupcomm 4459 * Editorial improvements. 4461 C.10. Version -02 to -03 4463 * New sections, aligned with the interface of ace-key-groupcomm . 4465 * Exchange of information on the signature algorithm and related 4466 parameters, during the Token POST (Section 4.1). 4468 * Nonce 'rsnonce' from the Group Manager to the Client 4469 (Section 4.1). 4471 * Client PoP signature in the Key Distribution Request upon joining 4472 (Section 4.2). 4474 * Local actions on the Group Manager, upon a new node's joining 4475 (Section 4.2). 4477 * Local actions on the Group Manager, upon a node's leaving 4478 (Section 12). 4480 * IANA registration in ACE Groupcomm Parameters registry. 4482 * More fulfilled profile requirements (Appendix A). 4484 C.11. Version -01 to -02 4486 * Editorial fixes. 4488 * Changed: "listener" to "responder"; "pure listener" to "monitor". 4490 * Changed profile name to "coap_group_oscore_app", to reflect it is 4491 an application profile. 4493 * Added the 'type' parameter for all requests to a Join Resource. 4495 * Added parameters to indicate the encoding of public keys. 4497 * Challenge-response for proof-of-possession of signature keys 4498 (Section 4). 4500 * Renamed 'key_info' parameter to 'sign_info'; updated its format; 4501 extended to include also parameters of the signature key 4502 (Section 4.1). 4504 * Code 4.00 (Bad request), in responses to joining nodes providing 4505 an invalid public key (Section 4.3). 4507 * Clarifications on provisioning and checking of public keys 4508 (Sections 4 and 6). 4510 * Extended discussion on group rekeying and possible different 4511 approaches (Section 7). 4513 * Extended security considerations: proof-of-possession of signature 4514 keys; collision of OSCORE Group Identifiers (Section 8). 4516 * Registered three entries in the IANA registry "Sequence Number 4517 Synchronization Method" (Section 9). 4519 * Registered one public key encoding in the "ACE Public Key 4520 Encoding" IANA registry (Section 9). 4522 C.12. Version -00 to -01 4524 * Changed name of 'req_aud' to 'audience' in the Authorization 4525 Request (Section 3.1). 4527 * Added negotiation of signature algorithm/parameters between Client 4528 and Group Manager (Section 4). 4530 * Updated format of the Key Distribution Response as a whole 4531 (Section 4.3). 4533 * Added parameter 'cs_params' in the 'key' parameter of the Key 4534 Distribution Response (Section 4.3). 4536 * New IANA registrations in the "ACE Authorization Server Request 4537 Creation Hints" registry, "ACE Groupcomm Key" registry, "OSCORE 4538 Security Context Parameters" registry and "ACE Groupcomm Profile" 4539 registry (Section 9). 4541 Acknowledgments 4543 The authors sincerely thank Christian Amsuess, Santiago Aragon, 4544 Stefan Beck, Carsten Bormann, Martin Gunnarsson, Rikard Hoeglund, 4545 Watson Ladd, Daniel Migault, Jim Schaad, Ludwig Seitz, Goeran 4546 Selander and Peter van der Stok for their comments and feedback. 4548 The work on this document has been partly supported by VINNOVA and 4549 the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home 4550 (Grant agreement 952652); and by the EIT-Digital High Impact 4551 Initiative ACTIVE. 4553 Authors' Addresses 4555 Marco Tiloca 4556 RISE AB 4557 Isafjordsgatan 22 4558 SE-164 29 Stockholm Kista 4559 Sweden 4561 Email: marco.tiloca@ri.se 4563 Jiye Park 4564 Universitaet Duisburg-Essen 4565 Schuetzenbahn 70 4566 45127 Essen 4567 Germany 4569 Email: ji-ye.park@uni-due.de 4571 Francesca Palombini 4572 Ericsson AB 4573 Torshamnsgatan 23 4574 SE-16440 Stockholm Kista 4575 Sweden 4577 Email: francesca.palombini@ericsson.com