idnits 2.17.1 draft-ietf-ace-key-groupcomm-oscore-13.txt: -(3851): 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 document date (7 March 2022) is 778 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 459, but not defined == Missing Reference: 'Tperm' is mentioned on line 459, but not defined == Missing Reference: 'EC2' is mentioned on line 3130, but not defined == Missing Reference: 'P-256' is mentioned on line 3122, but not defined == Missing Reference: 'P-384' is mentioned on line 3126, but not defined == Missing Reference: 'P-521' is mentioned on line 3130, but not defined -- Looks like a reference, but probably isn't: '0' on line 4246 == Unused Reference: 'RFC6838' is defined on line 3782, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-ace-aif-06 == Outdated reference: A later version (-18) exists of draft-ietf-ace-key-groupcomm-15 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-14 ** 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-05 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-10) exists of draft-ietf-core-groupcomm-bis-06 == Outdated reference: A later version (-09) exists of draft-ietf-cose-cbor-encoded-cert-03 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-11 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 5 errors (**), 0 flaws (~~), 18 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group M. Tiloca 3 Internet-Draft RISE AB 4 Intended status: Standards Track J. Park 5 Expires: 8 September 2022 Universitaet Duisburg-Essen 6 F. Palombini 7 Ericsson AB 8 7 March 2022 10 Key Management for OSCORE Groups in ACE 11 draft-ietf-ace-key-groupcomm-oscore-13 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 8 September 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 13 71 5.1. ace-group/GROUPNAME/active . . . . . . . . . . . . . . . 13 72 5.1.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 13 73 5.2. ace-group/GROUPNAME/verif-data . . . . . . . . . . . . . 14 74 5.2.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 14 75 5.3. ace-group/GROUPNAME/stale-sids . . . . . . . . . . . . . 14 76 5.3.1. FETCH Handler . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . 18 81 6.1.1. 'ecdh_info' Parameter . . . . . . . . . . . . . . . . 20 82 6.1.2. 'kdc_dh_creds' Parameter . . . . . . . . . . . . . . 23 83 6.2. Send the Joining Request . . . . . . . . . . . . . . . . 24 84 6.2.1. Value of the N_S Challenge . . . . . . . . . . . . . 26 85 6.3. Receive the Joining Request . . . . . . . . . . . . . . . 26 86 6.4. Send the Joining Response . . . . . . . . . . . . . . . . 30 87 6.5. Receive the Joining Response . . . . . . . . . . . . . . 36 88 7. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 38 89 8. Retrieve of Updated Keying Material . . . . . . . . . . . . . 40 90 8.1. Retrieve of Group Keying Material . . . . . . . . . . . . 40 91 8.2. Retrieve of Group Keying Material and OSCORE Sender ID . 41 92 9. Request to Change Individual Keying Material . . . . . . . . 41 93 10. Retrieve Authentication Credentials of Group Members . . . . 43 94 11. Upload a New Authentication Credential . . . . . . . . . . . 44 95 12. Retrieve the Group Manager's Authentication Credential . . . 45 96 13. Retrieve Signature Verification Data . . . . . . . . . . . . 46 97 14. Retrieve the Group Policies . . . . . . . . . . . . . . . . . 48 98 15. Retrieve the Keying Material Version . . . . . . . . . . . . 49 99 16. Retrieve the Group Status . . . . . . . . . . . . . . . . . . 49 100 17. Retrieve Group Names . . . . . . . . . . . . . . . . . . . . 50 101 18. Leave the Group . . . . . . . . . . . . . . . . . . . . . . . 53 102 19. Removal of a Group Member . . . . . . . . . . . . . . . . . . 53 103 20. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 55 104 20.1. Sending Rekeying Messages . . . . . . . . . . . . . . . 57 105 20.2. Receiving Rekeying Messages . . . . . . . . . . . . . . 59 106 20.3. Missed Rekeying Instances . . . . . . . . . . . . . . . 60 107 20.3.1. Retrieval of Stale Sender IDs . . . . . . . . . . . 62 108 21. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 64 109 22. ACE Groupcomm Error Identifiers . . . . . . . . . . . . . . . 66 110 23. Default Values for Group Configuration Parameters . . . . . . 66 111 23.1. Common . . . . . . . . . . . . . . . . . . . . . . . . . 67 112 23.2. Group Mode . . . . . . . . . . . . . . . . . . . . . . . 67 113 23.3. Pairwise Mode . . . . . . . . . . . . . . . . . . . . . 68 114 24. Security Considerations . . . . . . . . . . . . . . . . . . . 69 115 24.1. Management of OSCORE Groups . . . . . . . . . . . . . . 69 116 24.2. Size of Nonces as Proof-of-Possesion Challenge . . . . . 70 117 24.3. Reusage of Nonces for Proof-of-Possession Input . . . . 71 118 25. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 119 25.1. OAuth Parameters . . . . . . . . . . . . . . . . . . . . 72 120 25.2. OAuth Parameters CBOR Mappings . . . . . . . . . . . . . 72 121 25.3. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . 73 122 25.4. ACE Groupcomm Key Types . . . . . . . . . . . . . . . . 74 123 25.5. ACE Groupcomm Profiles . . . . . . . . . . . . . . . . . 74 124 25.6. OSCORE Security Context Parameters . . . . . . . . . . . 74 125 25.7. TLS Exporter Labels . . . . . . . . . . . . . . . . . . 76 126 25.8. AIF . . . . . . . . . . . . . . . . . . . . . . . . . . 77 127 25.9. CoAP Content-Format . . . . . . . . . . . . . . . . . . 77 128 25.10. Group OSCORE Roles . . . . . . . . . . . . . . . . . . . 78 129 25.11. CoRE Resource Type . . . . . . . . . . . . . . . . . . . 78 130 25.12. ACE Scope Semantics . . . . . . . . . . . . . . . . . . 79 131 25.13. ACE Groupcomm Errors . . . . . . . . . . . . . . . . . . 79 132 25.14. Expert Review Instructions . . . . . . . . . . . . . . . 80 133 26. References . . . . . . . . . . . . . . . . . . . . . . . . . 80 134 26.1. Normative References . . . . . . . . . . . . . . . . . . 80 135 26.2. Informative References . . . . . . . . . . . . . . . . . 84 136 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 86 137 A.1. Mandatory-to-Address Requirements . . . . . . . . . . . . 86 138 A.2. Optional-to-Address Requirements . . . . . . . . . . . . 89 139 Appendix B. Extensibility for Future COSE Algorithms . . . . . . 90 140 B.1. Format of 'ecdh_info_entry' . . . . . . . . . . . . . . . 91 141 B.2. Format of 'key' . . . . . . . . . . . . . . . . . . . . . 92 142 Appendix C. Document Updates . . . . . . . . . . . . . . . . . . 93 143 C.1. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 93 144 C.2. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 93 145 C.3. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 94 146 C.4. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 95 147 C.5. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 95 148 C.6. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 96 149 C.7. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 96 150 C.8. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 96 151 C.9. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 97 152 C.10. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 98 153 C.11. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 98 154 C.12. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 99 155 C.13. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 99 156 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 100 157 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 100 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 especially include: 225 - Group Manager, as the entity responsible for a set of groups 226 where communications are secured with Group OSCORE. In this 227 document, the Group Manager acts as Resource Server. 229 - Authentication credential, as the set of information associated 230 with an entity, including that entity's public key and 231 parameters associated with the public key. Examples of 232 authentication credentials are CBOR Web Tokens (CWTs) and CWT 233 Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC7925] and 234 C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. 236 Additionally, this document makes use of the following terminology. 238 * Requester: member of an OSCORE group that sends request messages 239 to other members of the group. 241 * Responder: member of an OSCORE group that receives request 242 messages from other members of the group. A responder may reply 243 back, by sending a response message to the requester which has 244 sent the request message. 246 * Monitor: member of an OSCORE group that is configured as responder 247 and never replies back to requesters after receiving request 248 messages. This corresponds to the term "silent server" used in 249 [I-D.ietf-core-oscore-groupcomm]. 251 * Signature verifier: entity external to the OSCORE group and 252 intended to verify the signature of messages exchanged in the 253 group (see Sections 3.1 and 8.5 of 254 [I-D.ietf-core-oscore-groupcomm]). An authorized signature 255 verifier does not join the OSCORE group as an actual member, yet 256 it can retrieve the authentication credentials of the current 257 group members from the Group Manager. 259 * Signature-only group: an OSCORE group that uses only the group 260 mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]). 262 * Pairwise-only group: an OSCORE group that uses only the pairwise 263 mode (see Section 9 of [I-D.ietf-core-oscore-groupcomm]). 265 2. Protocol Overview 267 Group communication for CoAP over IP multicast has been enabled in 268 [I-D.ietf-core-groupcomm-bis] and can be secured with Group Object 269 Security for Constrained RESTful Environments (OSCORE) [RFC8613] as 270 described in [I-D.ietf-core-oscore-groupcomm]. A network node joins 271 an OSCORE group by interacting with the responsible Group Manager. 272 Once registered in the group, the new node can securely exchange 273 messages with other group members. 275 This document describes how to use [I-D.ietf-ace-key-groupcomm] and 276 [I-D.ietf-ace-oauth-authz] to perform a number of authentication, 277 authorization and key distribution actions, as overviewed in 278 Section 2 of [I-D.ietf-ace-key-groupcomm], when the considered group 279 is specifically an OSCORE group. 281 With reference to [I-D.ietf-ace-key-groupcomm]: 283 * The node wishing to join the OSCORE group, i.e., the joining node, 284 is the Client. 286 * The Group Manager is the Key Distribution Center (KDC), acting as 287 a Resource Server. 289 * The Authorization Server associated with the Group Manager is the 290 AS. 292 All communications between the involved entities MUST be secured. 294 In particular, communications between the Client and the Group 295 Manager leverage protocol-specific transport profiles of ACE to 296 achieve communication security, proof-of-possession and server 297 authentication. It is expected that, in the commonly referred base- 298 case of this document, the transport profile to use is pre-configured 299 and well-known to nodes participating in constrained applications. 301 Appendix A lists the specifications on this application profile of 302 ACE, based on the requirements defined in Appendix A of 303 [I-D.ietf-ace-key-groupcomm]. 305 2.1. Overview of the Joining Process 307 A node performs the steps described in Section 4.3.1.1 of 308 [I-D.ietf-ace-key-groupcomm] in order to join an OSCORE group. The 309 format and processing of messages exchanged among the participants 310 are further specified in Section 4 and Section 6 of this document. 312 2.2. Overview of the Group Rekeying Process 314 In a number of cases, the Group Manager has to generate new keying 315 material and distribute it to the group (rekeying), as also discussed 316 in Section 3.2 of [I-D.ietf-core-oscore-groupcomm]. 318 To this end the Group Manager MUST support the Group Rekeying Process 319 described in Section 20 of this document, as an instance of the 320 "Point-to-Point" rekeying scheme defined in Section 6.1 of 321 [I-D.ietf-ace-key-groupcomm] and registered in Section 11.14 of 322 [I-D.ietf-ace-key-groupcomm]. Future documents may define the use of 323 alternative group rekeying schemes for this application profile, 324 together with the corresponding rekeying message formats. The 325 resulting group rekeying process MUST comply with the functional 326 steps defined in Section 3.2 of [I-D.ietf-core-oscore-groupcomm]. 328 Upon generating the new group keying material and before starting its 329 distribution, the Group Manager MUST increment the version number of 330 the group keying material. When rekeying a group, the Group Manager 331 MUST preserve the current value of the OSCORE Sender ID of each 332 member in that group. 334 The data distributed to a group through a rekeying MUST include: 336 * The new version number of the group keying material for the group. 338 * A new Group Identifier (Gid) for the group as introduced in 339 [I-D.ietf-ace-key-groupcomm], used as ID Context parameter of the 340 Group OSCORE Common Security Context of that group (see Section 2 341 of [I-D.ietf-core-oscore-groupcomm]). 343 Note that the Gid differs from the group name also introduced in 344 [I-D.ietf-ace-key-groupcomm], which is a plain, stable and 345 invariant identifier, with no cryptographic relevance and meaning. 347 * A new value for the Master Secret parameter of the Group OSCORE 348 Common Security Context of the group (see Section 2 of 349 [I-D.ietf-core-oscore-groupcomm]). 351 * A set of stale Sender IDs, which allows each rekeyed node to purge 352 authentication credentials and Recipient Contexts used in the 353 group and associated with those Sender IDs. This in turn allows 354 every group member to rely on stored authentication credentials to 355 confidently assert the group membership of other sender nodes, 356 when receiving protected messages in the group (see Section 3.2 of 357 [I-D.ietf-core-oscore-groupcomm]). More details on the 358 maintenance of stale Sender IDs are provided in Section 2.2.1. 360 Also, the data distributed through a group rekeying MAY include a new 361 value for the Master Salt parameter of the Group OSCORE Common 362 Security Context of that group. 364 The Group Manager MUST rekeying the group in the following cases. 366 * The application requires backward security - In this case, the 367 group is rekeyed when a node joins the group as a new member. 368 Therefore, a joining node cannot access communications in the 369 group prior its joining. 371 * One or more nodes leave the group - That is, the group is rekeyed 372 when one or more current members spontaneously request to leave 373 the group (see Section 18), or when the Group Manager forcibly 374 evicts them from the group, e.g., due to expired or revoked 375 authorization (see Section 19). Therefore, a leaving node cannot 376 access communications in the group after its leaving, thus 377 ensuring forward security in the group. 379 Due to the set of stale Sender IDs distributed through the 380 rekeying, this ensures that a node owning the latest group keying 381 material does not store the authentication credentials of former 382 group members (see Sections 3.2 and 12.1 of 383 [I-D.ietf-core-oscore-groupcomm]). 385 * Extension of group lifetime - That is, the group is rekeyed when 386 the expiration time for the group keying material approaches or 387 has passed, if it is appropriate to extend the group operation 388 beyond that. 390 The Group Manager MAY rekey the group for other reasons, e.g., 391 according to an application-dependent rekeying period or scheduling. 393 2.2.1. Stale OSCORE Sender IDs 395 Throughout the lifetime of every group, the Group Manager MUST 396 maintain a collection of stale Sender IDs for that group. 398 The collection associated with a group MUST include up to N > 1 399 ordered sets of stale OSCORE Sender IDs. It is up to the application 400 to specify the value of N, possibly on a per-group basis. 402 The N-th set includes the Sender IDs that have become "stale" under 403 the current version V of the group keying material. The (N-1)-th set 404 refers to the immediately previous version (V - 1) of the group 405 keying material, and so on. 407 In the following cases, the Group Manager MUST add a new element to 408 the most recent set X, i.e., the set associated with the current 409 version V of the group keying material. 411 * When a current group member obtains a new Sender ID, its old 412 Sender ID is added to X. This happens when the Group Manager 413 assigns a new Sender ID upon request from the group member (see 414 Section 9), or in case the group member re-joins the group (see 415 Section 6.2 and Section 6.4), thus also obtaining a new Sender ID. 417 * When a current group member leaves the group, its current Sender 418 ID is added to X. This happens when a group member requests to 419 leave the group (see Section 18) or is forcibly evicted from the 420 group (see Section 19). 422 The value of N can change throughout the lifetime of the group. If 423 the new value N' is smaller than N, the Group Manager MUST preserve 424 the (up to) N' most recent sets in the collection and MUST delete any 425 possible older set from the collection. 427 Finally, the Group Manager MUST perform the following actions, when 428 the group is rekeyed and the group shifts to the next version V' = (V 429 + 1) of the group keying material. 431 1. The Group Manager rekeys the group. This includes also 432 distributing the set of stale Sender IDs X associated with the 433 old group keying material with version V (see Section 2.2). 435 2. After completing the group rekeying, the Group Manager creates a 436 new empty set X' associated with the new version V' of the newly 437 established group keying material, i.e., V' = (V + 1). 439 3. If the current collection of stale Sender IDs has size N, the 440 Group Manager deletes the oldest set in the collection. 442 4. The Group Manager adds the new set X' to the collection of stale 443 Sender IDs, as the most recent set. 445 3. Format of Scope 447 Building on Section 3.1 of [I-D.ietf-ace-key-groupcomm], this section 448 defines the exact format and encoding of scope to use. 450 To this end, this profile uses the Authorization Information Format 451 (AIF) [I-D.ietf-ace-aif], and defines the following AIF specific data 452 model AIF-OSCORE-GROUPCOMM. 454 With reference to the generic AIF model 456 AIF-Generic = [* [Toid, Tperm]] 458 the value of the CBOR byte string used as scope encodes the CBOR 459 array [* [Toid, Tperm]], where each [Toid, Tperm] element corresponds 460 to one scope entry. 462 Then, for each scope entry: 464 * the object identifier ("Toid") is specialized as a CBOR text 465 string, specifying the group name for the scope entry; 467 * the permission set ("Tperm") is specialized as a CBOR unsigned 468 integer with value R, specifying the role(s) that the client 469 wishes to take in the group (REQ1). The value R is computed as 470 follows: 472 - each role in the permission set is converted into the 473 corresponding numeric identifier X from the "Value" column of 474 the "Group OSCORE Roles" registry, for which this document 475 defines the entries in Figure 1. 477 - the set of N numbers is converted into the single value R, by 478 taking each numeric identifier X_1, X_2, ..., X_N to the power 479 of two, and then computing the inclusive OR of the binary 480 representations of all the power values. 482 +-----------+-------+-------------------------------------------------+ 483 | Name | Value | Description | 484 +===========+=======+=================================================+ 485 | Reserved | 0 | This value is reserved | 486 |-----------+-------+-------------------------------------------------+ 487 | Requester | 1 | Send requests; receive responses | 488 |-----------+-------+-------------------------------------------------+ 489 | Responder | 2 | Send responses; receive requests | 490 +-----------+-------+-------------------------------------------------+ 491 | Monitor | 3 | Receive requests; never send requests/responses | 492 |-----------+-------+-------------------------------------------------| 493 | Verifier | 4 | Verify signature of intercepted messages | 494 +-----------+-------+-------------------------------------------------+ 496 Figure 1: Numeric identifier of roles in the OSCORE group 498 The CDDL [RFC8610] definition of the AIF-OSCORE-GROUPCOMM data model 499 is as follows: 501 AIF-OSCORE-GROUPCOMM = AIF-Generic 503 gname = tstr ; Group name 504 permissions = uint . bits roles 505 roles = &( 506 Requester: 1, 507 Responder: 2, 508 Monitor: 3, 509 Verifier: 4 510 ) 512 Future specifications that define new roles MUST register a 513 corresponding numeric identifier in the "Group OSCORE Roles" registry 514 defined in Section 25.10 of this document. 516 4. Joining Node to Authorization Server 518 This section describes how the joining node interacts with the AS in 519 order to be authorized to join an OSCORE group under a given Group 520 Manager. In particular, it considers a joining node that intends to 521 contact that Group Manager for the first time. 523 The message exchange between the joining node and the AS consists of 524 the messages Authorization Request and Authorization Response defined 525 in Sections 3.1 and 3.2 of [I-D.ietf-ace-key-groupcomm]. Note that 526 what is defined in [I-D.ietf-ace-key-groupcomm] applies, and only 527 additions or modifications to that specification are defined here. 529 4.1. Authorization Request 531 The Authorization Request message is as defined in Section 3.1 of 532 [I-D.ietf-ace-key-groupcomm], with the following additions. 534 * If the 'scope' parameter is present: 536 - The value of the CBOR byte string encodes a CBOR array, whose 537 format MUST follow the data model AIF-OSCORE-GROUPCOMM defined 538 in Section 3. In particular, for each OSCORE group to join: 540 o The group name is encoded as a CBOR text string. 542 o The set of requested roles is expressed as a single CBOR 543 unsigned integer. This is computed as defined in Section 3, 544 from the numerical abbreviations of each requested role 545 defined in the "Group OSCORE Roles" registry, for which this 546 document defines the entry in Figure 1 (REQ1). 548 4.2. Authorization Response 550 The Authorization Response message is as defined in Section 3.2 of 551 [I-D.ietf-ace-key-groupcomm], with the following additions: 553 * The AS MUST include the 'expires_in' parameter. Other means for 554 the AS to specify the lifetime of Access Tokens are out of the 555 scope of this document. 557 * The AS MUST include the 'scope' parameter, when the value included 558 in the Access Token differs from the one specified by the joining 559 node in the request. In such a case, the second element of each 560 scope entry MUST be present, and specifies the set of roles that 561 the joining node is actually authorized to take in the OSCORE 562 group for that scope entry, encoded as specified in Section 4.1. 564 Furthermore, if the AS uses the extended format of scope defined in 565 Section 7 of [I-D.ietf-ace-key-groupcomm] for the 'scope' claim of 566 the Access Token, the first element of the CBOR sequence [RFC8742] 567 MUST be the CBOR integer with value SEM_ID_TBD, defined in 568 Section 25.12 of this document (REQ28). This indicates that the 569 second element of the CBOR sequence, as conveying the actual access 570 control information, follows the scope semantics defined for this 571 application profile in Section 3 of this document. 573 5. Interface at the Group Manager 575 The Group Manager provides the interface defined in Section 4.1 of 576 [I-D.ietf-ace-key-groupcomm], with the additional sub-resources 577 defined from Section 5.1 to Section 5.3 of this document. 579 Furthermore, Section 5.4 provides a summary of the CoAP methods 580 admitted to access different resources at the Group Manager, for 581 nodes with different roles in the group or as non members (REQ11). 583 The GROUPNAME segment of the URI path MUST match with the group name 584 specified in the scope entry of the Access Token scope (i.e., 'gname' 585 in Section 3.1 of [I-D.ietf-ace-key-groupcomm]) (REQ7). 587 The Resource Type (rt=) Link Target Attribute value "core.osc.gm" is 588 registered in Section 25.11 (REQ10), and can be used to describe 589 group-membership resources and its sub-resources at a Group Manager, 590 e.g., by using a link-format document [RFC6690]. 592 Applications can use this common resource type to discover links to 593 group-membership resources for joining OSCORE groups, e.g., by using 594 the approach described in [I-D.tiloca-core-oscore-discovery]. 596 5.1. ace-group/GROUPNAME/active 598 This resource implements a GET handler. 600 5.1.1. GET Handler 602 The handler expects a GET request. 604 In addition to what is defined in Section 4.1.2 of 605 [I-D.ietf-ace-key-groupcomm], the handler verifies that the 606 requesting client is a current member of the group. If the 607 verification fails, the KDC MUST reply with a 4.03 (Forbidden) error 608 response. The response MUST have Content-Format set to application/ 609 ace-groupcomm+cbor and is formatted as defined in Section 4.1.2 of 610 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be 611 set to 0 ("Operation permitted only to group members"). 613 If all verifications succeed, the handler replies with a 2.05 614 (Content) response, specifying the current status of the group, i.e., 615 active or inactive. The payload of the response is formatted as 616 defined in Section 16. 618 The method to set the current group status is out of the scope of 619 this document, and is defined for the administrator interface of the 620 Group Manager specified in [I-D.ietf-ace-oscore-gm-admin]. 622 5.2. ace-group/GROUPNAME/verif-data 624 This resource implements a GET handler. 626 5.2.1. GET Handler 628 The handler expects a GET request. 630 In addition to what is defined in Section 4.1.2 of 631 [I-D.ietf-ace-key-groupcomm], the Group Manager performs the 632 following checks. 634 If the requesting client is a current group member, the Group Manager 635 MUST reply with a 4.03 (Forbidden) error response. The response MUST 636 have Content-Format set to application/ace-groupcomm+cbor and is 637 formatted as defined in Section 4.1.2 of 638 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be 639 set to 8 ("Operation permitted only to signature verifiers"). 641 If GROUPNAME denotes a pairwise-only group, the Group Manager MUST 642 reply with a 4.00 (Bad Request) error response. The response MUST 643 have Content-Format set to application/ace-groupcomm+cbor and is 644 formatted as defined in Section 4.1.2 of 645 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be 646 set to 7 ("Signatures not used in the group"). 648 If all verifications succeed, the handler replies with a 2.05 649 (Content) response, specifying data that allows also a signature 650 verifier to verify signatures of messages protected with the group 651 mode and sent to the group (see Sections 3.1 and 8.5 of 652 [I-D.ietf-core-oscore-groupcomm]). The response MUST have Content- 653 Format set to application/ace-groupcomm+cbor. The payload of the 654 response is a CBOR map, which is formatted as defined in Section 13. 656 5.3. ace-group/GROUPNAME/stale-sids 658 This resource implements a FETCH handler. 660 5.3.1. FETCH Handler 662 The handler expects a FETCH request, whose payload specifies a 663 version number of the group keying material, encoded as an unsigned 664 CBOR integer. 666 In addition to what is defined in Section 4.1.2 of 667 [I-D.ietf-ace-key-groupcomm], the handler verifies that the 668 requesting client is a current member of the group. If the 669 verification fails, the Group Manager MUST reply with a 4.03 670 (Forbidden) error response. The response MUST have Content-Format 671 set to application/ace-groupcomm+cbor and is formatted as defined in 672 Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value of the 673 'error' field MUST be set to 0 ("Operation permitted only to group 674 members"). 676 If all verifications succeed, the handler replies with a 2.05 677 (Content) response, specifying data that allows the requesting client 678 to delete the Recipient Contexts and authentication credentials 679 associated with former members of the group (see Section 3.2 of 680 [I-D.ietf-core-oscore-groupcomm]. The payload of the response is 681 formatted as defined in Section 20.3.1. 683 5.4. Admitted Methods 685 The table in Figure 2 summarizes the CoAP methods admitted to access 686 different resources at the Group Manager, for (non-)members of a 687 group with group name GROUPNAME, and considering different roles. 688 The last two rows of the table apply to a node with node name 689 NODENAME. 691 +---------------------------------+--------+-------+-------+-------+ 692 | Resource | Type1 | Type2 | Type3 | Type4 | 693 +---------------------------------+--------+-------+-------+-------+ 694 | ace-group/ | F | F | F | F | 695 +---------------------------------+--------+-------+-------+-------+ 696 | ace-group/GROUPNAME/ | G Po | G Po | Po * | Po | 697 +---------------------------------+--------+-------+-------+-------+ 698 | ace-group/GROUPNAME/active | G | G | - | - | 699 +---------------------------------+--------+-------+-------+-------+ 700 | ace-group/GROUPNAME/verif-data | - | - | G | - | 701 +---------------------------------+--------+-------+-------+-------+ 702 | ace-group/GROUPNAME/pub-key | G F | G F | G F | - | 703 +---------------------------------+--------+-------+-------+-------+ 704 | ace-group/GROUPNAME/kdc-pub-key | G | G | G | - | 705 +---------------------------------+--------+-------+-------+-------+ 706 | ace-group/GROUPNAME/stale-sids | F | F | - | - | 707 +---------------------------------+--------+-------+-------+-------+ 708 | ace-group/GROUPNAME/policies | G | G | - | - | 709 +---------------------------------+--------+-------+-------+-------+ 710 | ace-group/GROUPNAME/num | G | G | - | - | 711 +---------------------------------+--------+-------+-------+-------+ 712 | ace-group/GROUPNAME/nodes/ | G Pu D | G D | - | - | 713 | NODENAME | | | | | 714 +---------------------------------+--------+-------+-------+-------+ 715 | ace-group/GROUPNAME/nodes/ | Po | - | - | - | 716 | NODENAME/pub-key | | | | | 717 +---------------------------------+--------+-------+-------+-------+ 719 Type1 = Member as Requester and/or Responder | G = GET 720 Type2 = Member as Monitor | F = FETCH 721 Type3 = Non-member (authorized to be Verifier) | Po = POST 722 (*) = cannot join the group as Verifier | Pu = PUT 723 Type4 = Non-member (not authorized to be Verifier) | D = DELETE 725 Figure 2: Admitted CoAP Methods on the Group Manager Resources 727 5.5. Operations Supported by Clients 729 Building on what is defined in Section 4.1.1 of 730 [I-D.ietf-ace-key-groupcomm], and with reference to the resources at 731 the Group Manager newly defined earlier in Section 5 of this 732 document, it is expected that a Client minimally supports also the 733 following set of operations and corresponding interactions with the 734 Group (REQ12). 736 * GET request to ace-group/GROUPNAME/active , in order to check the 737 current status of the group. 739 * GET request to ace-group/GROUPNAME/verif-data , in order for a 740 signature verifier to retrieve data required to verify signatures 741 of messages protected with the group mode of Group OSCORE and sent 742 to a group (see Sections 3.1 and 8.5 of 743 [I-D.ietf-core-oscore-groupcomm]). Note that this operation is 744 relevant to support only to signature verifiers. 746 * FETCH request to ace-group/GROUPNAME/stale-sids , in order to 747 retrieve from the Group Manager the data required to delete some 748 of the stored group members' authentication credentials and 749 Recipient Contexts (see Section 5.3.1). This data is provided as 750 an aggregated set of stale Sender IDs, which are used as specified 751 in Section 20.3. 753 6. Token Transferring and Group Joining 755 The rest of this section describes the interactions between the 756 joining node and the Group Manager, i.e., the transferring of the 757 Access Token to the Group Manager and the Request-Response exchange 758 to join the OSCORE group. The message exchange between the joining 759 node and the Group Manager consists of the messages defined in 760 Sections 3.3 and 4.3.1.1 of [I-D.ietf-ace-key-groupcomm]. Note that 761 what is defined in [I-D.ietf-ace-key-groupcomm] applies, and only 762 additions or modifications to that specification are defined here. 764 Just like any candidate group member, a signature verifier provides 765 the Group Manager with an Access Token, as described in Section 6.1. 766 However, unlike candidate group members, it does not join any OSCORE 767 group, i.e., it does not perform the joining process defined in 768 Section 6.2. 770 After successfully transferring an Access Token to the Group Manager, 771 a signature verifier is allowed to perform only some operations as 772 non-member of a group, and only for the OSCORE groups specified in 773 the validated Access Token. These are the operations specified in 774 Section 10, Section 12, Section 13 and Section 17. 776 Consistently, in case a node is non-member of the group with group 777 name GROUPNAME and is authorized to be only signature verifier for 778 that group, the Group Manager MUST reply with a 4.03 (Forbidden) 779 error response if that node attempts to access any other endpoint 780 than: /ace-group/GROUPNAME/pub-key; ace-group/GROUPNAME/gm-pub-key; 781 ace-group/GROUPNAME/verif-data; and /ace-group. 783 6.1. Token Transferring 785 The exchange of Token Transfer Request and Response is defined in 786 Section 3.3 of [I-D.ietf-ace-key-groupcomm]. In addition to that, 787 the following applies. 789 * The Token Transfer Request MAY additionally contain the following 790 parameters, which, if included, MUST have the corresponding values 791 (OPT2): 793 - 'ecdh_info' defined in Section 6.1.1 of this document, with 794 value the CBOR simple value "null" (0xf6) to request 795 information about the ECDH algorithm, the ECDH algorithm 796 parameters, the ECDH key parameters and about the exact format 797 of authentication credentials used in the groups that the 798 client has been authorized to join. This is relevant in case 799 the joining node supports the pairwise mode of Group OSCORE 800 [I-D.ietf-core-oscore-groupcomm]. 802 - 'kdc_dh_creds' defined in Section 6.1.2 of this document, with 803 value the CBOR simple value "null" (0xf6) to request the 804 Diffie-Hellman authentication credentials of the Group Manager 805 for the groups that the client has been authorized to join. 806 That is, each of such authentication credentials includes a 807 Diffie-Hellman public key of the Group Manager. This is 808 relevant in case the joining node supports the pairwise mode of 809 Group OSCORE [I-D.ietf-core-oscore-groupcomm]. 811 Alternatively, the joining node may retrieve this information by 812 other means. 814 * The 'kdcchallenge' parameter contains a dedicated nonce N_S 815 generated by the Group Manager. For the N_S value, it is 816 RECOMMENDED to use a 8-byte long random nonce. The joining node 817 can use this nonce in order to prove the possession of its own 818 private key, upon joining the group (see Section 6.2). 820 The 'kdcchallenge' parameter MAY be omitted from the Token 821 Transfer Response, if the 'scope' of the Access Token specifies 822 only the role "monitor" or only the role "verifier" or only a 823 combination of the two, for each and every of the specified 824 groups. 826 * If the 'sign_info' parameter is present in the response, the 827 following applies for each element 'sign_info_entry'. 829 - 'id' MUST NOT refer to OSCORE groups that are pairwise-only 830 groups. 832 - 'sign_alg' takes value from the "Value" column of the "COSE 833 Algorithms" registry [COSE.Algorithms]. 835 - 'sign_parameters' is a CBOR array. Its format and value are 836 the same of the COSE capabilities array for the algorithm 837 indicated in 'sign_alg', as specified for that algorithm in the 838 "Capabilities" column of the "COSE Algorithms" registry 839 [COSE.Algorithms] (REQ4). 841 - 'sign_key_parameters' is a CBOR array. Its format and value 842 are the same of the COSE capabilities array for the COSE key 843 type of the keys used with the algorithm indicated in 844 'sign_alg', as specified for that key type in the 845 "Capabilities" column of the "COSE Key Types" registry 846 [COSE.Key.Types] (REQ5). 848 - 'pub_key_enc' takes value from the "Label" column of the "COSE 849 Header Parameters" registry [COSE.Header.Parameters] (REQ6). 850 Consistently with Section 2.3 of 851 [I-D.ietf-core-oscore-groupcomm], acceptable values denote a 852 format of authentication credential that MUST explicitly 853 provide the public key as well as the comprehensive set of 854 information related to the public key algorithm, including, 855 e.g., the used elliptic curve (when applicable). 857 At the time of writing this specification, acceptable formats 858 of authentication credentials are CBOR Web Tokens (CWTs) and 859 CWT Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC7925] 860 and C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. 861 Further formats may be available in the future, and would be 862 acceptable to use as long as they comply with the criteria 863 defined above. 865 [ As to CWTs and CCSs, the COSE Header Parameters 'kcwt' and 866 'kccs' are under pending registration requested by draft-ietf- 867 lake-edhoc. ] 869 [ As to C509 certificates, the COSE Header Parameters 'c5b' and 870 'c5c' are under pending registration requested by draft-ietf- 871 cose-cbor-encoded-cert. ] 873 This format is consistent with every signature algorithm currently 874 considered in [I-D.ietf-cose-rfc8152bis-algs], i.e., with 875 algorithms that have only the COSE key type as their COSE 876 capability. Appendix B of [I-D.ietf-ace-key-groupcomm] describes 877 how the format of each 'sign_info_entry' can be generalized for 878 possible future registered algorithms having a different set of 879 COSE capabilities. 881 * If 'ecdh_info' is included in the Token Transfer Request, the 882 Group Manager SHOULD include the 'ecdh_info' parameter in the 883 Token Transfer Response, as per the format defined in 884 Section 6.1.1. Note that the field 'id' of each 'ecdh_info_entry' 885 specifies the name, or array of group names, for which that 886 'ecdh_info_entry' applies to. 888 As an exception, the KDC MAY omit the 'ecdh_info' parameter in the 889 Token Transfer Response even if 'ecdh_info' is included in the 890 Token Transfer Request, in case all the groups that the Client is 891 authorized to join are signature-only groups. 893 * If 'kdc_dh_creds' is included in the Token Transfer Request and 894 any of the groups that the client has been authorized to join is a 895 pairwise-only group, then the Group Manager MUST include the 896 'kdc_dh_creds' parameter in the Token Transfer Response, as per 897 the format defined in Section 6.1.2. Otherwise, if 'kdc_dh_creds' 898 is included in the Token Transfer Request, the Group Manager MAY 899 include the 'kdc_dh_creds' parameter in the Token Transfer 900 Response. Note that the field 'id' specifies the group name, or 901 array of group names, for which the corresponding 'kdc_dh_creds' 902 applies to. 904 Note that, other than through the above parameters as defined in 905 Section 3.3 of [I-D.ietf-ace-key-groupcomm], the joining node may 906 have obtained such information by alternative means. For example, 907 information conveyed in the 'sign_info' and 'ecdh_info' parameters 908 may have been pre-configured, or the joining node MAY early retrieve 909 it by using the approach described in 910 [I-D.tiloca-core-oscore-discovery], to discover the OSCORE group and 911 the link to the associated group-membership resource at the Group 912 Manager (OPT3). 914 6.1.1. 'ecdh_info' Parameter 916 The 'ecdh_info' parameter is an OPTIONAL parameter of the request and 917 response messages exchanged between the client and the authz-info 918 endpoint at the RS (see Section 5.10.1. of 919 [I-D.ietf-ace-oauth-authz]). 921 This parameter allows the client and the RS to exchange information 922 about an ECDH algorithm as well as about the authentication 923 credentials and public keys to accordingly use for deriving Diffie- 924 Hellman secrets. Its exact semantics and content are application 925 specific. 927 In this application profile, this parameter is used to exchange 928 information about the ECDH algorithm as well as about the 929 authentication credentials and public keys to be used with it, in the 930 groups indicated by the transferred Acces Token as per its 'scope' 931 claim (see Section 3.2 of [I-D.ietf-ace-key-groupcomm]). 933 When used in the Token Transfer Request sent to the Group Manager, 934 the 'ecdh_info' parameter has value the CBOR simple value "null" 935 (0xf6). This is done to ask for information about the ECDH algorithm 936 as well as about the authentication credentials and public keys to be 937 used to compute static-static Diffie-Hellman shared secrets 938 [NIST-800-56A], in the OSCORE groups that the client has been 939 authorized to join and that use the pairwise mode of Group OSCORE 940 [I-D.ietf-core-oscore-groupcomm]. 942 When used in the following Token Transfer Response from the Group 943 Manager, the 'ecdh_info' parameter is a CBOR array of one or more 944 elements. The number of elements is at most the number of OSCORE 945 groups that the client has been authorized to join. 947 Each element contains information about ECDH parameters as well as 948 about authentication credentials and public keys, for one or more 949 OSCORE groups that use the pairwise mode of Group OSCORE and that the 950 client has been authorized to join. Each element is formatted as 951 follows. 953 * The first element 'id' is the group name of the OSCORE group or an 954 array of group names for the OSCORE groups for which the specified 955 information applies. In particular 'id' MUST NOT refer to OSCORE 956 groups that are signature-only groups. 958 * The second element 'ecdh_alg' is a CBOR integer or a CBOR text 959 string indicating the ECDH algorithm used in the OSCORE group 960 identified by 'gname'. Values are taken from the "Value" column 961 of the "COSE Algorithms" registry [COSE.Algorithms]. 963 * The third element 'ecdh_parameters' is a CBOR array indicating the 964 parameters of the ECDH algorithm used in the OSCORE group 965 identified by 'gname'. Its format and value are the same of the 966 COSE capabilities array for the algorithm indicated in 'ecdh_alg', 967 as specified for that algorithm in the "Capabilities" column of 968 the "COSE Algorithms" registry [COSE.Algorithms]. 970 * The fourth element 'ecdh_key_parameters' is a CBOR array 971 indicating the parameters of the keys used with the ECDH algorithm 972 in the OSCORE group identified by 'gname'. Its content depends on 973 the value of 'ecdh_alg'. In particular, its format and value are 974 the same of the COSE capabilities array for the COSE key type of 975 the keys used with the algorithm indicated in 'ecdh_alg', as 976 specified for that key type in the "Capabilities" column of the 977 "COSE Key Types" registry [COSE.Key.Types]. 979 * The fifth element 'cred_fmt' is a CBOR integer indicating the 980 format of authentication credentials used in the OSCORE group 981 identified by 'gname'. It takes value from the "Label" column of 982 the "COSE Header Parameters" registry [COSE.Header.Parameters] 983 (REQ6). Acceptable values denote a format that MUST provide the 984 public key as well as the comprehensive set of information related 985 to the public key algorithm, including, e.g., the used elliptic 986 curve (when applicable). The same considerations and guidelines 987 for the 'pub_key_enc' element of 'sign_info' (see Section 6.1) 988 apply. 990 The CDDL notation [RFC8610] of the 'ecdh_info' parameter is given 991 below. 993 ecdh_info = ecdh_info_req / ecdh_info_resp 995 ecdh_info_req = null ; in the Token Transfer 996 ; Request to the KDC 998 ecdh_info_res = [ + ecdh_info_entry ] ; in the Token Transfer 999 ; Response from the KDC 1001 ecdh_info_entry = 1002 [ 1003 id : gname / [ + gname ], 1004 ecdh_alg : int / tstr, 1005 ecdh_parameters : [ any ], 1006 ecdh_key_parameters : [ any ], 1007 cred_fmt = int 1008 ] 1010 gname = tstr 1012 This format is consistent with every ECDH algorithm currently defined 1013 in [I-D.ietf-cose-rfc8152bis-algs], i.e., with algorithms that have 1014 only the COSE key type as their COSE capability. Appendix B of this 1015 document describes how the format of each 'ecdh_info_entry' can be 1016 generalized for possible future registered algorithms having a 1017 different set of COSE capabilities. 1019 6.1.2. 'kdc_dh_creds' Parameter 1021 The 'kdc_dh_creds' parameter is an OPTIONAL parameter of the request 1022 and response messages exchanged between the Client and the authz-info 1023 endpoint at the RS (see Section 5.10.1. of 1024 [I-D.ietf-ace-oauth-authz]). 1026 This parameter allows the client to request and retrieve the Diffie- 1027 Hellman authentication credentials of the RS, i.e., authentication 1028 credentials including a Diffie-Hellman public key of the RS. 1030 In this application profile, this parameter is used to request and 1031 retrieve from the Group Manager its Diffie-Hellman authentication 1032 credentials to use, in the OSCORE groups that the client has been 1033 authorized to join. The Group Manager has specifically a Diffie- 1034 Hellman authentication credential in an OSCORE group, and thus a 1035 Diffie-Hellman public key in that group, if and only if the group is 1036 a pairwise-only group. In this case, the early retrieval of the 1037 Group Manager's authentication credential is necessary in order for 1038 the joining node to prove the possession of its own private key, upon 1039 joining the group (see Section 6.2). 1041 When used in the Token Transfer Request sent to the Group Manager, 1042 the 'kdc_dh_creds' parameter has value the CBOR simple value "null" 1043 (0xf6). This is done to ask for the Diffie-Hellman authentication 1044 credentials that the Group Manager uses in the OSCORE groups that the 1045 client has been authorized to join. 1047 When used in the following Token Transfer Response from the Group 1048 Manager, the 'kdc_dh_creds' parameter is a CBOR array of one or more 1049 elements. The number of elements is at most the number of OSCORE 1050 groups that the client has been authorized to join. 1052 Each element 'kdc_dh_creds_entry' contains information about the 1053 Group Manager's Diffie-Hellman authentication credentials, for one or 1054 more OSCORE groups that are pairwise-only groups and that the client 1055 has been authorized to join. Each element is formatted as follows. 1057 * The first element 'id' is the group name of the OSCORE group or an 1058 array of group names for the OSCORE groups for which the specified 1059 information applies. In particular 'id' MUST refer exclusively to 1060 OSCORE groups that are pairwise-only groups. 1062 * The second element 'cred_fmt' is a CBOR integer indicating the 1063 format of authentication credentials used in the OSCORE group 1064 identified by 'gname'. It takes value from the "Label" column of 1065 the "COSE Header Parameters" registry [COSE.Header.Parameters] 1066 (REQ6). Acceptable values denote a format that MUST explicitly 1067 provide the public key as well as comprehensive set of information 1068 related to the public key algorithm, including, e.g., the used 1069 elliptic curve (when applicable). The same considerations and 1070 guidelines for the 'pub_key_enc' element of 'sign_info' (see 1071 Section 6.1) apply. 1073 * The third element 'cred' is a CBOR byte string, which encodes the 1074 Group Manager's Diffie-Hellman authentication credential in its 1075 original binary representation made available to other endpoints 1076 in the group. In particular, the original binary representation 1077 complies with the format specified by the 'cred_fmt' element. 1078 Note that the authentication credential provides the comprehensive 1079 set of information related to its public key algorithm, i.e., the 1080 ECDH algorithm used in the OSCORE group as pairwise key agreement 1081 algorithm. 1083 The CDDL notation [RFC8610] of the 'kdc_dh_creds' parameter is given 1084 below. 1086 kdc_dh_creds = kdc_dh_creds_req / kdc_dh_creds_resp 1088 kdc_dh_creds_req = null ; in the Token Transfer 1089 ; Request to the 1090 ; Group Manager 1092 kdc_dh_creds_res = [ + kdc_dh_creds_entry ] ; in the Token Transfer 1093 ; Response from the 1094 ; Group Manager 1096 kdc_dh_creds_entry = 1097 [ 1098 id : gname / [ + gname ], 1099 cred_fmt = int, 1100 cred = bstr 1101 ] 1103 gname = tstr 1105 6.2. Send the Joining Request 1107 The joining node requests to join the OSCORE group by sending a 1108 Joining Request message to the related group-membership resource at 1109 the Group Manager, as per Section 4.3.1.1 of 1110 [I-D.ietf-ace-key-groupcomm]. 1112 Additionally to what defined in Section 4.3.1 of 1113 [I-D.ietf-ace-key-groupcomm], the following applies. 1115 * The 'scope' parameter MUST be included. Its value encodes one 1116 scope entry with the format defined in Section 3, indicating the 1117 group name and the role(s) that the joining node wants to take in 1118 the group. 1120 * The 'get_pub_keys' parameter is present only if the joining node 1121 wants to retrieve the authentication credentials of the group 1122 members from the Group Manager during the joining process (see 1123 Section 7). Otherwise, this parameter MUST NOT be present. 1125 If this parameter is present and its value is not the CBOR simple 1126 value "null" (0xf6), each element of the inner CBOR array 1127 'role_filter' is encoded as a CBOR unsigned integer, with the same 1128 value of a permission set ("Tperm") indicating that role or 1129 combination of roles in a scope entry, as defined in Section 3. 1131 * 'cnonce' contains a dedicated nonce N_C generated by the joining 1132 node. For the N_C value, it is RECOMMENDED to use a 8-byte long 1133 random nonce. 1135 * The proof-of-possession (PoP) evidence included in 1136 'client_cred_verify' is computed as defined below (REQ14). In 1137 either case, the N_S used to build the PoP input is as defined in 1138 Section 6.2.1. 1140 - If the group is not a pairwise-only group, the PoP evidence 1141 MUST be a signature. The joining node computes the signature 1142 by using the same private key and signature algorithm it 1143 intends to use for signing messages in the OSCORE group. 1145 - If the group is a pairwise-only group, the PoP evidence MUST be 1146 a MAC computed as follows, by using the HKDF Algorithm HKDF 1147 SHA-256, which consists of composing the HKDF-Extract and HKDF- 1148 Expand steps [RFC5869]. 1150 MAC = HKDF(salt, IKM, info, L) 1152 The input parameters of HKDF are as follows. 1154 o salt takes as value the empty byte string. 1156 o IKM is computed as a cofactor Diffie-Hellman shared secret, 1157 see Section 5.7.1.2 of [NIST-800-56A], using the ECDH 1158 algorithm used in the OSCORE group. The joining node uses 1159 its own Diffie-Hellman private key and the Diffie-Hellman 1160 public key of the Group Manager. For X25519 and X448, the 1161 procedure is described in Section 5 of [RFC7748]. 1163 o info takes as value the PoP input. 1165 o L is equal to 8, i.e., the size of the MAC, in bytes. 1167 6.2.1. Value of the N_S Challenge 1169 The value of the N_S challenge is determined as follows. 1171 1. If the joining node has provided the Access Token to the Group 1172 Manager by means of a Token Transfer Request to the /authz-info 1173 endpoint as in Section 6.1, then N_S takes the same value of the 1174 most recent 'kdcchallenge' parameter received by the joining node 1175 from the Group Manager. This can be either the one specified in 1176 the Token Transfer Response, or the one possibly specified in a 1177 4.00 (Bad Request) error response to a following Joining Request 1178 (see Section 6.3). 1180 2. If the provisioning of the Access Token to the Group Manager has 1181 relied on the DTLS profile of ACE [I-D.ietf-ace-dtls-authorize] 1182 with the Access Token as content of the "psk_identity" field of 1183 the ClientKeyExchange message [RFC6347], N_S is an exporter value 1184 computed as defined in Section 7.5 of [RFC8446]. Specifically, 1185 N_S is exported from the DTLS session between the joining node 1186 and the Group Manager, using an empty 'context_value', 32 bytes 1187 as 'key_length', and the exporter label "EXPORTER-ACE-Sign- 1188 Challenge-coap-group-oscore-app" defined in Section 25.7 of this 1189 document. 1191 It is up to applications to define how N_S is computed in further 1192 alternative settings. 1194 Section 24.3 provides security considerations on the reusage of the 1195 N_S challenge. 1197 6.3. Receive the Joining Request 1199 The Group Manager processes the Joining Request as defined in 1200 Section 4.3.1 of [I-D.ietf-ace-key-groupcomm], with the following 1201 additions. 1203 * The Group Manager MUST return a 5.03 (Service Unavailable) 1204 response in case the OSCORE group that the joining node has been 1205 trying to join is currently inactive (see Section 5.1). The 1206 response MUST have Content-Format set to application/ace- 1207 groupcomm+cbor and is formatted as defined in Section 4.1.2 of 1208 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST 1209 be set to 9 ("Group currently not active"). 1211 * In case the joining node is not going to join the group 1212 exclusively as monitor, the Group Manager MUST return a 5.03 1213 (Service Unavailable) response if there are currently no OSCORE 1214 Sender IDs available to assign in the OSCORE group. The response 1215 MUST have Content-Format set to application/ace-groupcomm+cbor and 1216 is formatted as defined in Section 4.1.2 of 1217 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST 1218 be set to 4 ("No available node identifiers"). 1220 * In case the joining node is not going to join the group 1221 exclusively as monitor and the Joining Request does not include 1222 the 'client_cred' parameter, the joining process fails if the 1223 Group Manager either: i) does not store an authentication 1224 credential with an accepted format for the joining node; or ii) 1225 stores multiple authentication credentials with an accepted format 1226 for the joining node. 1228 * In order to verify the PoP evidence contained in 1229 'client_cred_verify', the Group Manager proceeds as follows. 1231 - As PoP input, the Group Manager uses the value of the 'scope' 1232 parameter from the Joining Request as a CBOR byte string, 1233 concatenated with N_S encoded as a CBOR byte string, 1234 concatenated with N_C encoded as a CBOR byte string. In 1235 particular, N_S is determined as described in Section 6.2.1, 1236 while N_C is the nonce provided in the 'cnonce' parameter of 1237 the Joining Request; 1239 - As public key of the joining node, the Group Manager uses 1240 either the one included in the authentication credential 1241 retrieved from the 'client_cred' parameter of the Joining 1242 Request, or the one from the already stored authentication 1243 credential as acquired from previous interactions with the 1244 joining node. 1246 - The Group Manager verifies the PoP evidence as defined below. 1248 o If the group is not a pairwise-only group, the PoP evidence 1249 is a signature. The Group Manager verifies it by using the 1250 public key of the joining node, as well as the signature 1251 algorithm used in the OSCORE group and possible 1252 corresponding parameters. 1254 o If the group is a pairwise-only group, the PoP evidence is a 1255 MAC. The Group Manager recomputes the MAC through the same 1256 process taken by the joining node when preparing the value 1257 of the 'client_cred_verify' parameter for the Joining 1258 Request (see Section 6.2), with the difference that the 1259 Group Manager uses its own Diffie-Hellman private key and 1260 the Diffie-Hellman public key of the joining node. The 1261 verification succeeds if and only if the recomputed MAC is 1262 equal to the MAC conveyed as PoP evidence in the Joining 1263 Request. 1265 * A 4.00 (Bad Request) error response from the Group Manager to the 1266 joining node MUST have content format application/ace- 1267 groupcomm+cbor. The response payload is a CBOR map formatted as 1268 follows. 1270 - If the group uses (also) the group mode of Group OSCORE, the 1271 CBOR map MUST contain the 'sign_info' parameter, whose CBOR 1272 label is defined in Section 8 of [I-D.ietf-ace-key-groupcomm]. 1273 This parameter has the same format of 'sign_info_res' defined 1274 in Section 3.3.1 of [I-D.ietf-ace-key-groupcomm]. In 1275 particular, it includes a single element 'sign_info_entry' 1276 pertaining to the OSCORE group that the joining node has tried 1277 to join with the Joining Request. 1279 - If the group uses (also) the pairwise mode of Group OSCORE, the 1280 CBOR map MUST contain the 'ecdh_info' parameter, whose CBOR 1281 label is defined in Section 25.3. This parameter has the same 1282 format of 'ecdh_info_res' defined in Section 6.1.1. In 1283 particular, it includes a single element 'ecdh_info_entry' 1284 pertaining to the OSCORE group that the joining node has tried 1285 to join with the Joining Request. 1287 - If the group is a pairwise-only group, the CBOR map MUST 1288 contain the 'kdc_dh_creds' parameter, whose CBOR label is 1289 defined in Section 25.3. This parameter has the same format of 1290 'kdc_dh_creds_res' defined in Section 6.1.2. In particular, it 1291 includes a single element 'kdc_dh_creds_entry' pertaining to 1292 the OSCORE group that the joining node has tried to join with 1293 the Joining Request. 1295 - The CBOR map MAY include the 'kdcchallenge' parameter, whose 1296 CBOR label is defined in Section 8 of 1297 [I-D.ietf-ace-key-groupcomm]. If present, this parameter is a 1298 CBOR byte string, which encodes a newly generated 1299 'kdcchallenge' value that the Client can use when preparing a 1300 Joining Request (see Section 6.2). In such a case the Group 1301 Manager MUST store the newly generated value as the 1302 'kdcchallenge' value associated with the joining node, possibly 1303 replacing the currently stored value. 1305 * The Group Manager MUST reply with a 4.00 (Bad Request) error 1306 response in case the 'scope' parameter is not present in the 1307 Joining Request, or if it is present and specifies any set of 1308 roles not included in the following list: "requester", 1309 "responder", "monitor", ("requester", "responder"). Future 1310 specifications that define a new role MUST define possible sets of 1311 roles including the new one and existing ones, that are acceptable 1312 to specify in the 'scope' parameter of a Joining Request. 1314 * The Group Manager MUST reply with a 4.00 (Bad Request) error 1315 response in case the Joining Request includes the 'client_cred' 1316 parameter but does not include both the 'cnonce' and 1317 'client_cred_verify' parameters. 1319 * The Group Manager MUST reply with a 4.00 (Bad Request) error 1320 response in case an eligible authentication credential for the 1321 joining node is neither present in the 'client_cred' parameter nor 1322 already stored. 1324 * The Group Manager MAY reply with a 4.00 (Bad Request) error 1325 response in case all the following conditions hold. 1327 - The OSCORE group uses the pairwise mode of Group OSCORE. 1329 - The OSCORE group uses EdDSA public keys [RFC8032]. 1331 - The authentication credential of the joining node from the 1332 'client_cred' parameter includes a public key which: 1334 o Is for the elliptic curve Ed25519 and has its Y coordinate 1335 equal to -1 or 1 (mod p), with p = (2^255 - 19), see 1336 Section 4.1 of [RFC7748]; or 1338 o Is for the elliptic curve Ed448 and has its Y coordinate 1339 equal to -1 or 1 (mod p), with p = (2^448 - 2^224 - 1), see 1340 Section 4.2 of [RFC7748]. 1342 This prevents the acceptance of Ed25519 and Ed448 public keys that 1343 cannot be successfully converted to Montgomery coordinates, and 1344 thus cannot be used for the derivation of pairwise keys (see 1345 Section 2.4.1 of [I-D.ietf-core-oscore-groupcomm]). 1347 * When receiving a 4.00 (Bad Request) error response, the joining 1348 node SHOULD send a new Joining Request to the Group Manager, 1349 where: 1351 - The 'cnonce' parameter MUST include a new dedicated nonce N_C 1352 generated by the joining node. 1354 - The 'client_cred' parameter MUST include an authentication 1355 credential in the format indicated by the Group Manager. Also, 1356 the authentication credential as well as the included public 1357 key MUST be compatible with the signature or ECDH algorithm, 1358 and possible associated parameters. 1360 - The 'client_cred_verify' parameter MUST include a PoP evidence 1361 computed as described in Section 6.2, by using the private key 1362 associated with the authentication credential specified in the 1363 current 'client_cred' parameter, with the signature or ECDH 1364 algorithm, and possible associated parameters indicated by the 1365 Group Manager. If the error response from the Group Manager 1366 includes the 'kdcchallenge' parameter, the joining node MUST 1367 use its content as new N_S challenge to compute the PoP 1368 evidence. 1370 6.4. Send the Joining Response 1372 If the processing of the Joining Request described in Section 6.3 is 1373 successful, the Group Manager updates the group membership by 1374 registering the joining node NODENAME as a new member of the OSCORE 1375 group GROUPNAME, as described in Section 4.3.1 of 1376 [I-D.ietf-ace-key-groupcomm]. 1378 If the joining node has not taken exclusively the role of monitor, 1379 the Group Manager performs also the following actions. 1381 * The Group Manager selects an available OSCORE Sender ID in the 1382 OSCORE group, and exclusively assigns it to the joining node. The 1383 Group Manager MUST NOT assign an OSCORE Sender ID to the joining 1384 node if this joins the group exclusively with the role of monitor, 1385 according to what specified in the Access Token (see Section 4.2). 1387 Consistently with Section 3.2.1 of 1388 [I-D.ietf-core-oscore-groupcomm], the Group Manager MUST assign an 1389 OSCORE Sender ID that has not been used in the OSCORE group since 1390 the latest time when the current Gid value was assigned to the 1391 group. 1393 If the joining node is recognized as a current group member, e.g., 1394 through the ongoing secure communication association, the 1395 following also applies. 1397 - The Group Manager MUST assign a new OSCORE Sender ID different 1398 than the one currently used by the joining node in the OSCORE 1399 group. 1401 - The Group Manager MUST add the old, relinquished OSCORE Sender 1402 ID of the joining node to the most recent set of stale Sender 1403 IDs, in the collection associated with the group (see 1404 Section 2.2.1). 1406 * The Group Manager stores the association between i) the 1407 authentication credential of the joining node; and ii) the Group 1408 Identifier (Gid), i.e., the OSCORE ID Context, associated with the 1409 OSCORE group together with the OSCORE Sender ID assigned to the 1410 joining node in the group. The Group Manager MUST keep this 1411 association updated over time. 1413 Then, the Group Manager replies to the joining node, providing the 1414 updated security parameters and keying meterial necessary to 1415 participate in the group communication. This success Joining 1416 Response is formatted as defined in Section 4.3.1 of 1417 [I-D.ietf-ace-key-groupcomm], with the following additions: 1419 * The 'gkty' parameter identifies a key of type 1420 "Group_OSCORE_Input_Material object", defined in Section 25.4 of 1421 this document. 1423 * The 'key' parameter includes what the joining node needs in order 1424 to set up the Group OSCORE Security Context as per Section 2 of 1425 [I-D.ietf-core-oscore-groupcomm]. 1427 This parameter has as value a Group_OSCORE_Input_Material object, 1428 which is defined in this document and extends the 1429 OSCORE_Input_Material object encoded in CBOR as defined in 1430 Section 3.2.1 of [I-D.ietf-ace-oscore-profile]. In particular, it 1431 contains the additional parameters 'group_senderId', 'cred_fmt', 1432 'sign_enc_alg', 'sign_alg', 'sign_params', 'ecdh_alg' and 1433 'ecdh_params' defined in Section 25.6 of this document. 1435 More specifically, the 'key' parameter is composed as follows. 1437 - The 'hkdf' parameter, if present, has as value the HKDF 1438 Algorithm used in the OSCORE group. This parameter MAY be 1439 omitted, if the HKDF Algorithm used in the group is HKDF SHA- 1440 256. Otherwise, this parameter MUST be present. 1442 - The 'salt' parameter, if present, has as value the OSCORE 1443 Master Salt used in the OSCORE group. This parameter MAY be 1444 omitted, if the Master Salt used in the group is the empty byte 1445 string. Otherwise, this parameter MUST be present. 1447 - The 'ms' parameter includes the OSCORE Master Secret value used 1448 in the OSCORE group. This parameter MUST be present. 1450 - The 'contextId' parameter MUST be present and has as value the 1451 Group Identifier (Gid), i.e., the OSCORE ID Context of the 1452 OSCORE group. This parameter MUST be present. 1454 - The 'group_senderId' parameter, if present, has as value the 1455 OSCORE Sender ID assigned to the joining node by the Group 1456 Manager, as described above. This parameter MUST NOT be 1457 present if the node joins the OSCORE group exclusively with the 1458 role of monitor, according to what specified in the Access 1459 Token (see Section 4.2). In any other case, this parameter 1460 MUST be present. 1462 - The 'cred_fmt' parameter MUST be present and specifies the 1463 format of authentication credentials used in the OSCORE group. 1464 It takes value from the "Label" column of the "COSE Header 1465 Parameters" registry [COSE.Header.Parameters] (REQ6). 1466 Consistently with Section 2.3 of 1467 [I-D.ietf-core-oscore-groupcomm], acceptable values denote a 1468 format that MUST explicitly provide the public key as well as 1469 the comprehensive set of information related to the public key 1470 algorithm, including, e.g., the used elliptic curve (when 1471 applicable). 1473 At the time of writing this specification, acceptable formats 1474 of authentication credentials are CBOR Web Tokens (CWTs) and 1475 CWT Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC7925] 1476 and C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. 1477 Further formats may be available in the future, and would be 1478 acceptable to use as long as they comply with the criteria 1479 defined above. 1481 [ As to CWTs and CCSs, the COSE Header Parameters 'kcwt' and 1482 'kccs' are under pending registration requested by draft-ietf- 1483 lake-edhoc. ] 1485 [ As to C509 certificates, the COSE Header Parameters 'c5b' and 1486 'c5c' are under pending registration requested by draft-ietf- 1487 cose-cbor-encoded-cert. ] 1489 - The 'sign_enc_alg' parameter MUST NOT be present if the OSCORE 1490 group is a pairwise-only group. Otherwise, it MUST be present 1491 and specifies the Signature Encryption Algorithm used in the 1492 OSCORE group to encrypt messages protected with the group mode. 1493 This parameter takes values from the "Value" column of the 1494 "COSE Algorithms" registry [COSE.Algorithms]. 1496 - The 'sign_alg' parameter MUST NOT be present if the OSCORE 1497 group is a pairwise-only group. Otherwise, it MUST be present 1498 and specifies the Signature Algorithm used to sign messages in 1499 the OSCORE group. This parameter takes values from the "Value" 1500 column of the "COSE Algorithms" registry [COSE.Algorithms]. 1502 - The 'sign_params' parameter MUST NOT be present if the OSCORE 1503 group is a pairwise-only group. Otherwise, it MUST be present 1504 and specifies the parameters of the Signature Algorithm. This 1505 parameter is a CBOR array, which includes the following two 1506 elements: 1508 o 'sign_alg_capab': a CBOR array, with the same format and 1509 value of the COSE capabilities array for the Signature 1510 Algorithm indicated in 'sign_alg', as specified for that 1511 algorithm in the "Capabilities" column of the "COSE 1512 Algorithms" registry [COSE.Algorithms]. 1514 o 'sign_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 Signature Algorithm indicated 1517 in 'sign_alg', as specified for that key type in the 1518 "Capabilities" column of the "COSE Key Types" registry 1519 [COSE.Key.Types]. 1521 - The 'alg' parameter MUST NOT be present if the OSCORE group is 1522 a signature-only group. Otherwise, it MUST be present and 1523 specifies the AEAD Algorithm used in the OSCORE group to 1524 encrypt messages protected with the pairwise mode. 1526 - The 'ecdh_alg' parameter MUST NOT be present if the OSCORE 1527 group is a signature-only group. Otherwise, it MUST be present 1528 and specifies the Pairwise Key Agreement Algorithm used in the 1529 OSCORE group. This parameter takes values from the "Value" 1530 column of the "COSE Algorithms" registry [COSE.Algorithms]. 1532 - The 'ecdh_params' parameter MUST NOT be present if the OSCORE 1533 group is a signature-only group. Otherwise, it MUST be present 1534 and specifies the parameters of the Pairwise Key Agreement 1535 Algorithm. This parameter is a CBOR array, which includes the 1536 following two elements: 1538 o 'ecdh_alg_capab': a CBOR array, with the same format and 1539 value of the COSE capabilities array for the algorithm 1540 indicated in 'ecdh_alg', as specified for that algorithm in 1541 the "Capabilities" column of the "COSE Algorithms" registry 1542 [COSE.Algorithms]. 1544 o 'ecdh_key_type_capab': a CBOR array, with the same format 1545 and value of the COSE capabilities array for the COSE key 1546 type of the keys used with the algorithm indicated in 1547 'ecdh_alg', as specified for that key type in the 1548 "Capabilities" column of the "COSE Key Types" registry 1549 [COSE.Key.Types]. 1551 The format of 'key' defined above is consistent with every 1552 signature algorithm and ECDH algorithm currently considered in 1553 [I-D.ietf-cose-rfc8152bis-algs], i.e., with algorithms that have 1554 only the COSE key type as their COSE capability. Appendix B of 1555 this document describes how the format of the 'key' parameter can 1556 be generalized for possible future registered algorithms having a 1557 different set of COSE capabilities. 1559 * The 'exp' parameter MUST be present. 1561 * The 'ace-groupcomm-profile' parameter MUST be present and has 1562 value coap_group_oscore_app (PROFILE_TBD), which is defined in 1563 Section 25.5 of this document. 1565 * The 'pub_keys' parameter, if present, includes the authentication 1566 credentials requested by the joining node by means of the 1567 'get_pub_keys' parameter in the Joining Request. 1569 If the joining node has asked for the authentication credentials 1570 of all the group members, i.e., 'get_pub_keys' had value the CBOR 1571 simple value "null" (0xf6) in the Joining Request, then the Group 1572 Manager provides only the authentication credentials of the group 1573 members that are relevant to the joining node. That is, in such a 1574 case, 'pub_keys' includes only: i) the authentication credentials 1575 of the responders currently in the OSCORE group, in case the 1576 joining node is configured (also) as requester; and ii) the 1577 authentication credentials of the requesters currently in the 1578 OSCORE group, in case the joining node is configured (also) as 1579 responder or monitor. 1581 * The 'peer_identifiers' parameter includes the OSCORE Sender ID of 1582 each group member whose authentication credential is specified in 1583 the 'pub_keys' parameter. That is, a group member's Sender ID is 1584 used as identifier for that group member (REQ25). 1586 * The 'group_policies' parameter SHOULD be present, and SHOULD 1587 include the following elements: 1589 - "Key Update Check Interval" defined in Section 4.3.1 of 1590 [I-D.ietf-ace-key-groupcomm], with default value 3600; 1592 - "Expiration Delta" defined in Section 4.3.1 of 1593 [I-D.ietf-ace-key-groupcomm], with default value 0. 1595 * The 'kdc_cred' parameter MUST be present, specifying the Group 1596 Manager's authentication credential in its original binary 1597 representation (REQ8). The Group Manager's authentication 1598 credential MUST be in the format used in the OSCORE group. Also, 1599 the authentication credential as well as the included public key 1600 MUST be compatible with the signature or ECDH algorithm, and 1601 possible associated parameters used in the OSCORE group. 1603 * The 'kdc_nonce' parameter MUST be present, specifying the 1604 dedicated nonce N_KDC generated by the Group Manager. For N_KDC, 1605 it is RECOMMENDED to use a 8-byte long random nonce. 1607 * The 'kdc_cred_verify' parameter MUST be present, specifying the 1608 proof-of-possession (PoP) evidence computed by the Group Manager. 1609 The PoP evidence is computed over the nonce N_KDC, which is 1610 specified in the 'kdc_nonce' parameter and taken as PoP input. 1611 The PoP evidence is computed as defined below (REQ21). 1613 - If the group is not a pairwise-only group, the PoP evidence 1614 MUST be a signature. The Group Manager computes the signature 1615 by using the signature algorithm used in the OSCORE group, as 1616 well as its own private key associated with the authentication 1617 credential specified in the 'kdc_cred' parameter. 1619 - If the group is a pairwise-only group, the PoP evidence MUST be 1620 a MAC computed as follows, by using the HKDF Algorithm HKDF 1621 SHA-256, which consists of composing the HKDF-Extract and HKDF- 1622 Expand steps [RFC5869]. 1624 MAC = HKDF(salt, IKM, info, L) 1626 The input parameters of HKDF are as follows. 1628 o salt takes as value the empty byte string. 1630 o IKM is computed as a cofactor Diffie-Hellman shared secret, 1631 see Section 5.7.1.2 of [NIST-800-56A], using the ECDH 1632 algorithm used in the OSCORE group. The Group Manager uses 1633 its own Diffie-Hellman private key and the Diffie-Hellman 1634 public key of the joining node. For X25519 and X448, the 1635 procedure is described in Section 5 of [RFC7748]. 1637 o info takes as value the PoP input. 1639 o L is equal to 8, i.e., the size of the MAC, in bytes. 1641 * The 'group_rekeying' parameter MAY be omitted, if the Group 1642 Manager uses the "Point-to-Point" group rekeying scheme registered 1643 in Section 11.14 of [I-D.ietf-ace-key-groupcomm] as rekeying 1644 scheme in the OSCORE group (OPT9). Its detailed use for this 1645 profile is defined in Section 20 of this document. In any other 1646 case, the 'group_rekeying' parameter MUST be included. 1648 As a last action, if the Group Manager reassigns Gid values during 1649 the group's lifetime (see Section 3.2.1.1 of 1650 [I-D.ietf-core-oscore-groupcomm]), the Group Manager MUST store the 1651 Gid specified in the 'contextId' parameter of the 'key' parameter, as 1652 the Birth Gid of the joining node in the joined group (see Section 3 1653 of [I-D.ietf-core-oscore-groupcomm]). This applies also in case the 1654 node is in fact re-joining the group; in such a case, the newly 1655 determined Birth Gid overwrites the one currently stored. 1657 6.5. Receive the Joining Response 1659 Upon receiving the Joining Response, the joining node retrieves the 1660 Group Manager's authentication credential from the 'kdc_cred' 1661 parameter. The joining node MUST verify the proof-of-possession 1662 (PoP) evidence specified in the 'kdc_cred_verify' parameter of the 1663 Joining Response as defined below (REQ21). 1665 * If the group is not a pairwise-only group, the PoP evidence is a 1666 signature. The joining node verifies it by using the public key 1667 of the Group Manager from the received authentication credential, 1668 as well as the signature algorithm used in the OSCORE group and 1669 possible corresponding parameters. 1671 * If the group is a pairwise-only group, the PoP evidence is a MAC. 1672 The joining node recomputes the MAC through the same process taken 1673 by the Group Manager when computing the value of the 1674 'kdc_cred_verify' parameter (see Section 6.4), with the difference 1675 that the joining node uses its own Diffie-Hellman private key and 1676 the Diffie-Hellman public key of the Group Manager from the 1677 received authentication credential. The verification succeeds if 1678 and only if the recomputed MAC is equal to the MAC conveyed as PoP 1679 evidence in the Joining Response. 1681 In case of failed verification of the PoP evidence, the joining node 1682 MUST stop processing the Joining Response and MAY send a new Joining 1683 Request to the Group Manager (see Section 6.2). 1685 In case of successful verification of the PoP evidence, the joining 1686 node uses the information received in the Joining Response to set up 1687 the Group OSCORE Security Context, as described in Section 2 of 1688 [I-D.ietf-core-oscore-groupcomm]. If the following parameters were 1689 not included in the 'key' parameter of the Joining Response, the 1690 joining node considers the following default values, consistently 1691 with Section 3.2 of [RFC8613]. 1693 * Absent the 'hkdf' parameter, the joining node considers HKDF 1694 SHA-256 as HKDF Algorithm to use in the OSCORE group. 1696 * Absent the 'salt' parameter, the joining node considers the empty 1697 byte string as Master Salt to use in the OSCORE group. 1699 * Absent the 'group_rekeying' parameter, the joining node considers 1700 the "Point-to-Point" group rekeying scheme registered in 1701 Section 11.14 of [I-D.ietf-ace-key-groupcomm] as the rekeying 1702 scheme used in the group (OPT9). Its detailed use for this 1703 profile is defined in Section 20 of this document. 1705 In addition, the joining node maintains an association between each 1706 authentication credential retrieved from the 'pub_keys' parameter and 1707 the role(s) that the corresponding group member has in the OSCORE 1708 group. 1710 From then on, the joining node can exchange group messages secured 1711 with Group OSCORE as described in [I-D.ietf-core-oscore-groupcomm]. 1712 When doing so: 1714 * The joining node MUST NOT process an incoming request message, if 1715 protected by a group member whose authentication credential is not 1716 associated with the role "Requester". 1718 * The joining node MUST NOT process an incoming response message, if 1719 protected by a group member whose authentication credential is not 1720 associated with the role "Responder". 1722 * The joining node MUST NOT use the pairwise mode of Group OSCORE to 1723 process messages in the group, if the Joining Response did not 1724 include the 'ecdh_alg' parameter. 1726 If the application requires backward security, the Group Manager MUST 1727 generate updated security parameters and group keying material, and 1728 provide it to the current group members upon the new node's joining 1729 (see Section 20). As a consequence, the joining node is not able to 1730 access secure communication in the OSCORE group occurred prior its 1731 joining. 1733 7. Public Keys of Joining Nodes 1735 Source authentication of a message sent within the group and 1736 protected with Group OSCORE is ensured by means of a digital 1737 signature embedded in the message (in group mode), or by integrity- 1738 protecting the message with pairwise keying material derived from the 1739 asymmetric keys of sender and recipient (in pairwise mode). 1741 Therefore, group members must be able to retrieve each other's 1742 authentication credential from a trusted repository, in order to 1743 verify source authenticity of incoming group messages. 1745 As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group 1746 Manager acts as trusted repository of the authentication credentials 1747 of the group members, and provides those authentication credentials 1748 to group members if requested to. Upon joining an OSCORE group, a 1749 joining node is thus expected to provide its own authentication 1750 credential to the Group Manager. 1752 In particular, one of the following four cases can occur when a new 1753 node joins an OSCORE group. 1755 * The joining node is going to join the group exclusively as 1756 monitor, i.e., it is not going to send messages to the group. In 1757 this case, the joining node is not required to provide its own 1758 authentication credential to the Group Manager, which thus does 1759 not have to perform any check related to the format of the 1760 authentication credential, to a signature or ECDH algorithm, and 1761 to possible parameters associated with the algorithm and the 1762 public key. In case that joining node still provides an 1763 authentication credential in the 'client_cred' parameter of the 1764 Joining Request (see Section 6.2), the Group Manager silently 1765 ignores that parameter, as well as the related parameters 'cnonce' 1766 and 'client_cred_verify'. 1768 * The Group Manager already acquired the authentication credential 1769 of the joining node during a past joining process. In this case, 1770 the joining node MAY choose not to provide again its own 1771 authentication credential to the Group Manager, in order to limit 1772 the size of the Joining Request. The joining node MUST provide 1773 its own authentication credential again if it has provided the 1774 Group Manager with multiple authentication credentials during past 1775 joining processes, intended for different OSCORE groups. If the 1776 joining node provides its own authentication credential, the Group 1777 Manager performs consistency checks as per Section 6.3 and, in 1778 case of success, considers it as the authentication credential 1779 associated with the joining node in the OSCORE group. 1781 * The joining node and the Group Manager use an asymmetric proof-of- 1782 possession key to establish a secure communication association. 1783 Then, two cases can occur. 1785 1. When establishing the secure communication association, the 1786 Group Manager obtained from the joining node the joining 1787 node's authentication credential, in the format used in the 1788 OSCORE group and including the asymmetric proof-of-possession 1789 key as public key. Also, such authentication credential and 1790 the proof-of-possession key are compatible with the signature 1791 or ECDH algorithm, and possible associated parameters used in 1792 the OSCORE group. 1794 In this case, the Group Manager considers the authentication 1795 credential as the one associated with the joining node in the 1796 OSCORE group. If the joining node is aware that the 1797 authentication credential and the public key included thereof 1798 are also valid for the OSCORE group, then the joining node MAY 1799 choose to not provide again its own authentication credential 1800 to the Group Manager. 1802 The joining node MUST provide again its own authentication 1803 credential if it has provided the Group Manager with multiple 1804 authentication credentials during past joining processes, 1805 intended for different OSCORE groups. If the joining node 1806 provides its own authentication credential in the 1807 'client_cred' parameter of the Joining Request (see 1808 Section 6.2), the Group Manager performs consistency checks as 1809 per Section 6.3 and, in case of success, considers it as the 1810 authentication credential associated with the joining node in 1811 the OSCORE group. 1813 2. The authentication credential is not in the format used in the 1814 OSCORE group, or else the authentication credential and the 1815 proof-of-possession key included as public key are not 1816 compatible with the signature or ECDH algorithm, and possible 1817 associated parameters used in the OSCORE group. 1819 In this case, the joining node MUST provide a different 1820 compatible authentication credential and public key included 1821 thereof to the Group Manager in the 'client_cred' parameter of 1822 the Joining Request (see Section 6.2). Then, the Group 1823 Manager performs consistency checks on this latest provided 1824 authentication credential as per Section 6.3 and, in case of 1825 success, considers it as the authentication credential 1826 associated with the joining node in the OSCORE group. 1828 * The joining node and the Group Manager use a symmetric proof-of- 1829 possession key to establish a secure communication association. 1830 In this case, upon performing a joining process with that Group 1831 Manager for the first time, the joining node specifies its own 1832 authentication credential in the 'client_cred' parameter of the 1833 Joining Request targeting the group-membership endpoint (see 1834 Section 6.2). 1836 8. Retrieve of Updated Keying Material 1838 At some point, a group member considers the Group OSCORE Security 1839 Context invalid and to be renewed. This happens, for instance, after 1840 a number of unsuccessful security processing of incoming messages 1841 from other group members, or when the Security Context expires as 1842 specified by the 'exp' parameter of the Joining Response. 1844 When this happens, the group member retrieves updated security 1845 parameters and group keying material. This can occur in the two 1846 different ways described below. 1848 8.1. Retrieve of Group Keying Material 1850 If the group member wants to retrieve only the latest group keying 1851 material, it sends a Key Distribution Request to the Group Manager. 1853 In particular, it sends a CoAP GET request to the endpoint /ace- 1854 group/GROUPNAME at the Group Manager. 1856 The Group Manager processes the Key Distribution Request according to 1857 Section 4.3.2 of [I-D.ietf-ace-key-groupcomm]. The Key Distribution 1858 Response is formatted as defined in Section 4.3.2 of 1859 [I-D.ietf-ace-key-groupcomm], with the following additions. 1861 * The 'key' parameter is formatted as defined in Section 6.4 of this 1862 document, with the difference that it does not include the 1863 'group_SenderId' parameter. 1865 * The 'exp' parameter MUST be present. 1867 * The 'ace-groupcomm-profile' parameter MUST be present and has 1868 value coap_group_oscore_app. 1870 Upon receiving the Key Distribution Response, the group member 1871 retrieves the updated security parameters and group keying material, 1872 and, if they differ from the current ones, uses them to set up the 1873 new Group OSCORE Security Context as described in Section 2 of 1874 [I-D.ietf-core-oscore-groupcomm]. 1876 8.2. Retrieve of Group Keying Material and OSCORE Sender ID 1878 If the group member wants to retrieve the latest group keying 1879 material as well as the OSCORE Sender ID that it has in the OSCORE 1880 group, it sends a Key Distribution Request to the Group Manager. 1882 In particular, it sends a CoAP GET request to the endpoint /ace- 1883 group/GROUPNAME/nodes/NODENAME at the Group Manager. 1885 The Group Manager processes the Key Distribution Request according to 1886 Section 4.8.1 of [I-D.ietf-ace-key-groupcomm]. The Key Distribution 1887 Response is formatted as defined in Section 4.8.1 of 1888 [I-D.ietf-ace-key-groupcomm], with the following additions. 1890 * The 'key' parameter is formatted as defined in Section 6.4 of this 1891 document. In particular, if the requesting group member has 1892 exclusively the role of monitor, no 'group_SenderId' is specified 1893 within the 'key' parameter. 1895 Note that, in any other case, the current Sender ID of the group 1896 member is not specified as a separate parameter, but rather 1897 specified as 'group_SenderId' within the 'key' parameter. 1899 * The 'exp' parameter MUST be present. 1901 Upon receiving the Key Distribution Response, the group member 1902 retrieves the updated security parameters, group keying material and 1903 Sender ID, and, if they differ from the current ones, uses them to 1904 set up the new Group OSCORE Security Context as described in 1905 Section 2 of [I-D.ietf-core-oscore-groupcomm]. 1907 9. Request to Change Individual Keying Material 1909 As discussed in Section 2.5.2 of [I-D.ietf-core-oscore-groupcomm], a 1910 group member may at some point exhaust its Sender Sequence Numbers in 1911 the OSCORE group. 1913 When this happens, the group member MUST send a Key Renewal Request 1914 message to the Group Manager, as per Section 4.8.2.1 of 1915 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP PUT 1916 request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME at the 1917 Group Manager. 1919 Upon receiving the Key Renewal Request, the Group Manager processes 1920 it as defined in Section 4.8.2 of [I-D.ietf-ace-key-groupcomm], with 1921 the following additions. 1923 The Group Manager MUST return a 5.03 (Service Unavailable) response 1924 in case the OSCORE group identified by GROUPNAME is currently 1925 inactive (see Section 5.1). The response MUST have Content-Format 1926 set to application/ace-groupcomm+cbor and is formatted as defined in 1927 Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value of the 1928 'error' field MUST be set to 9 ("Group currently not active"). 1930 Otherwise, the Group Manager performs one of the following actions. 1932 1. If the requesting group member has exclusively the role of 1933 monitor, the Group Manager replies with a 4.03 (Forbidden) error 1934 response. The response MUST have Content-Format set to 1935 application/ace-groupcomm+cbor and is formatted as defined in 1936 Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value of the 1937 'error' field MUST be set to 1 ("Request inconsistent with the 1938 current roles"). 1940 2. Otherwise, the Group Manager takes one of the following actions. 1942 * The Group Manager rekeys the OSCORE group. That is, the Group 1943 Manager generates new group keying material for that group 1944 (see Section 20), and replies to the group member with a group 1945 rekeying message as defined in Section 20, providing the new 1946 group keying material. Then, the Group Manager rekeys the 1947 rest of the OSCORE group, as discussed in Section 20. 1949 The Group Manager SHOULD perform a group rekeying only if 1950 already scheduled to occur shortly, e.g., according to an 1951 application-dependent rekeying period or scheduling, or as a 1952 reaction to a recent change in the group membership. In any 1953 other case, the Group Manager SHOULD NOT rekey the OSCORE 1954 group when receiving a Key Renewal Request (OPT12). 1956 * The Group Manager determines and assigns a new OSCORE Sender 1957 ID for that group member, and replies with a Key Renewal 1958 Response formatted as defined in Section 4.8.2 of 1959 [I-D.ietf-ace-key-groupcomm]. In particular, the CBOR Map in 1960 the response payload includes a single parameter 1961 'group_SenderId' defined in Section 25.3 of this document, 1962 specifying the new Sender ID of the group member encoded as a 1963 CBOR byte string. 1965 Consistently with Section 2.5.3.1 of 1966 [I-D.ietf-core-oscore-groupcomm], the Group Manager MUST 1967 assign a new Sender ID that has not been used in the OSCORE 1968 group since the latest time when the current Gid value was 1969 assigned to the group. 1971 Furthermore, the Group Manager MUST add the old, relinquished 1972 Sender ID of the group member to the most recent set of stale 1973 Sender IDs, in the collection associated with the group (see 1974 Section 2.2.1). 1976 The Group Manager MUST return a 5.03 (Service Unavailable) 1977 response in case there are currently no Sender IDs available 1978 to assign in the OSCORE group. The response MUST have 1979 Content-Format set to application/ace-groupcomm+cbor and is 1980 formatted as defined in Section 4.1.2 of 1981 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field 1982 MUST be set to 4 ("No available node identifiers"). 1984 10. Retrieve Authentication Credentials of Group Members 1986 A group member or a signature verifier may need to retrieve the 1987 authentication credentials of (other) group members. To this end, 1988 the group member or signature verifier sends a Public Key Request 1989 message to the Group Manager, as per Sections 4.4.1.1 and 4.4.2.1 of 1990 [I-D.ietf-ace-key-groupcomm]. In particular, it sends the request to 1991 the endpoint /ace-group/GROUPNAME/pub-key at the Group Manager. 1993 If the Public Key Request uses the method FETCH, the Public Key 1994 Request is formatted as defined in Section 4.4.1 of 1995 [I-D.ietf-ace-key-groupcomm]. In particular: 1997 * Each element (if any) of the inner CBOR array 'role_filter' is 1998 formatted as in the inner CBOR array 'role_filter' of the 1999 'get_pub_keys' parameter of the Joining Request when the parameter 2000 value is not the CBOR simple value "null" (0xf6) (see 2001 Section 6.2). 2003 * Each element (if any) of the inner CBOR array 'id_filter' is a 2004 CBOR byte string, which encodes the OSCORE Sender ID of the group 2005 member for which the associated authentication credential is 2006 requested (REQ25). 2008 Upon receiving the Public Key Request, the Group Manager processes it 2009 as per Section 4.4.1 or Section 4.4.2 of 2010 [I-D.ietf-ace-key-groupcomm], depending on the request method being 2011 FETCH or GET, respectively. Additionally, if the Public Key Request 2012 uses the method FETCH, the Group Manager silently ignores node 2013 identifiers included in the 'get_pub_keys' parameter of the request 2014 that are not associated with any current group member (REQ26). 2016 The success Public Key Response is formatted as defined in 2017 Section 4.4.1 or Section 4.4.2 of [I-D.ietf-ace-key-groupcomm], 2018 depending on the request method being FETCH or GET, respectively. 2020 11. Upload a New Authentication Credential 2022 A group member may need to provide the Group Manager with its new 2023 authentication credential to use in the group from then on, hence 2024 replacing the current one. This can be the case, for instance, if 2025 the signature or ECDH algorithm, and possible associated parameters 2026 used in the OSCORE group have been changed, and the current 2027 authentication credential is not compatible with them. 2029 To this end, the group member sends a Public Key Update Request 2030 message to the Group Manager, as per Section 4.9.1.1 of 2031 [I-D.ietf-ace-key-groupcomm], with the following addition. 2033 * The group member computes the proof-of-possession (PoP) evidence 2034 included in 'client_cred_verify' in the same way taken when 2035 preparing a Joining Request for the OSCORE group in question, as 2036 defined in Section 6.2 (REQ14). 2038 In particular, the group member sends a CoAP POST request to the 2039 endpoint /ace-group/GROUPNAME/nodes/NODENAME/pub-key at the Group 2040 Manager. 2042 Upon receiving the Public Key Update Request, the Group Manager 2043 processes it as per Section 4.9.1 of [I-D.ietf-ace-key-groupcomm], 2044 with the following additions. 2046 * The N_S challenge used to build the proof-of-possession input is 2047 computed as per point (1) in Section 6.2.1 (REQ15). 2049 * The Group Manager verifies the PoP challenge included in 2050 'client_cred_verify' in the same way taken when processing a 2051 Joining Request for the OSCORE group in question, as defined in 2052 Section 6.3 (REQ14). 2054 * The Group Manager MUST return a 5.03 (Service Unavailable) 2055 response in case the OSCORE group identified by GROUPNAME is 2056 currently inactive (see Section 5.1). The response MUST have 2057 Content-Format set to application/ace-groupcomm+cbor and is 2058 formatted as defined in Section 4.1.2 of 2059 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST 2060 be set to 9 ("Group currently not active"). 2062 * If the requesting group member has exclusively the role of 2063 monitor, the Group Manager replies with a 4.00 (Bad request) error 2064 response. The response MUST have Content-Format set to 2065 application/ace-groupcomm+cbor and is formatted as defined in 2066 Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value of the 2067 'error' field MUST be set to 1 ("Request inconsistent with the 2068 current roles"). 2070 * If the request is successfully processed, the Group Manager stores 2071 the association between i) the new authentication credential of 2072 the group member; and ii) the Group Identifier (Gid), i.e., the 2073 OSCORE ID Context, associated with the OSCORE group together with 2074 the OSCORE Sender ID assigned to the group member in the group. 2075 The Group Manager MUST keep this association updated over time. 2077 12. Retrieve the Group Manager's Authentication Credential 2079 A group member or a signature verifier may need to retrieve the 2080 authentication credential of the Group Manager. To this end, the 2081 requesting client sends a KDC Public Key Request message to the Group 2082 Manager. 2084 In particular, it sends a CoAP GET request to the endpoint /ace- 2085 group/GROUPNAME/kdc-pub-key at the Group Manager defined in 2086 Section 4.5.1.1 of [I-D.ietf-ace-key-groupcomm], where GROUPNAME is 2087 the name of the OSCORE group. 2089 In addition to what is defined in Section 4.5.1 of 2090 [I-D.ietf-ace-key-groupcomm], the Group Manager MUST respond with a 2091 4.00 (Bad Request) error response, if the requesting client is not a 2092 current group member and GROUPNAME denotes a pairwise-only group. 2093 The response MUST have Content-Format set to application/ace- 2094 groupcomm+cbor and is formatted as defined in Section 4.1.2 of 2095 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be 2096 set to 7 ("Signatures not used in the group"). 2098 The payload of the 2.05 (Content) KDC Public Key Response is a CBOR 2099 map, which is formatted as defined in Section 4.5.1 of 2100 [I-D.ietf-ace-key-groupcomm]. In particular, the Group Manager 2101 specifies the parameters 'kdc_cred', 'kdc_nonce' and 'kdc_challenge' 2102 as defined for the Joining Response in Section 6.4 of this document. 2103 This especially applies to the computing of the proof-of-possession 2104 (PoP) evidence included in 'kdc_cred_verify' (REQ21). 2106 Upon receiving a 2.05 (Content) KDC Public Key Response, the 2107 requesting client retrieves the Group Manager's authentication 2108 credential from the 'kdc_cred' parameter, and proceeds as defined in 2109 Section 4.5.1.1 of [I-D.ietf-ace-key-groupcomm]. In particular, the 2110 requesting client verifies the PoP evidence included in 2111 'kdc_cred_verify' by means of the same method used when processing 2112 the Joining Response, as defined in Section 6.4 of this document 2113 (REQ21). 2115 Note that a signature verifier would not receive a successful 2116 response from the Group Manager, in case GROUPNAME denotes a 2117 pairwise-only group. 2119 13. Retrieve Signature Verification Data 2121 A signature verifier may need to retrieve data required to verify 2122 signatures of messages protected with the group mode and sent to a 2123 group (see Sections 3.1 and 8.5 of [I-D.ietf-core-oscore-groupcomm]). 2124 To this end, the signature verifier sends a Signature Verification 2125 Data Request message to the Group Manager. 2127 In particular, it sends a CoAP GET request to the endpoint /ace- 2128 group/GROUPNAME/verif-data at the Group Manager defined in 2129 Section 5.2 of this document, where GROUPNAME is the name of the 2130 OSCORE group. 2132 The payload of the 2.05 (Content) Signature Verification Data 2133 Response is a CBOR map, which has the format used for the Joining 2134 Response message in Section 6.4, with the following differences. 2136 * From the Joining Response message, only the parameters 'gkty', 2137 'key', 'num', 'exp' and 'ace-groupcomm-profile' are present. In 2138 particular, the 'key' parameter includes only the following data. 2140 - The parameters 'hkdf', 'contextId', 'cred_fmt', 'sign_enc_alg', 2141 'sign_alg', 'sign_params'. These parameters MUST be present. 2143 - The parameters 'alg' and 'ecdh_alg'. These parameter MUST NOT 2144 be present if the group is a signature-only group. Otherwise, 2145 they MUST be present. 2147 * The parameter 'group_enc_key' is also included, with CBOR label 2148 defined in Section 25.3. This parameter specifies the Group 2149 Encryption Key of the OSCORE Group, encoded as a CBOR byte string. 2150 The Group Manager derives the Group Encryption Key from the group 2151 keying material, as per Section 2.1.6 of 2152 [I-D.ietf-core-oscore-groupcomm]. This parameter MUST be present. 2154 In order to verify signatures in the group (see Section 8.5 of 2155 [I-D.ietf-core-oscore-groupcomm]), the signature verifier relies on: 2156 the data retrieved from the 2.05 (Content) Signature Verification 2157 Data Response; the public keys of the group members signing the 2158 messages to verify, retrieved from those members' authentication 2159 credentials that can be obtained as defined in Section 10; and the 2160 public key of the Group Manager, retrieved from the Group Manager's 2161 authentication credential that can be obtained as defined in 2162 Section 12. 2164 Figure 3 gives an overview of the exchange described above, while 2165 Figure 4 shows an example. 2167 Signature Group 2168 Verifier Manager 2169 | | 2170 | Signature Verification Data Request | 2171 |------------------------------------------------------------>| 2172 | GET ace-group/GROUPNAME/verif-data | 2173 | | 2174 |<--- Signature Verification Data Response: 2.05 (Content) ---| 2175 | | 2177 Figure 3: Message Flow of Signature Verification Data Request- 2178 Response 2180 Request: 2182 Header: GET (Code=0.01) 2183 Uri-Host: "kdc.example.com" 2184 Uri-Path: "ace-group" 2185 Uri-Path: "g1" 2186 Uri-Path: "verif-data" 2187 Payload: - 2189 Response: 2191 Header: Content (Code=2.05) 2192 Content-Format: "application/ace-groupcomm+cbor" 2193 Payload (in CBOR diagnostic notation, with GROUPCOMM_KEY_TBD 2194 and PROFILE_TBD being CBOR integers, while GROUP_ENC_KEY 2195 being a CBOR byte string): 2196 { 2197 "gkty": GROUPCOMM_KEY_TBD, 2198 "key": { 2199 'hkdf': -10, ; HKDF SHA-256 2200 'contextId': h'37fc', 2201 'cred_fmt': 33, ; x5chain 2202 'sign_enc_alg': 10, ; AES-CCM-16-64-128 2203 'sign_alg': -8, ; EdDSA 2204 'sign_params': [[1], [1, 6]] ; [[OKP], [OKP, Ed25519]] 2205 }, 2206 "num": 12, 2207 "exp": 1609459200, 2208 "ace_groupcomm_profile": PROFILE_TBD, 2209 "group_enc_key": GROUP_ENC_KEY 2210 } 2212 Figure 4: Example of Signature Verification Data Request-Response 2214 14. Retrieve the Group Policies 2216 A group member may request the current policies used in the OSCORE 2217 group. To this end, the group member sends a Policies Request, as 2218 per Section 4.6.1.1 of [I-D.ietf-ace-key-groupcomm]. In particular, 2219 it sends a CoAP GET request to the endpoint /ace-group/GROUPNAME/ 2220 policies at the Group Manager, where GROUPNAME is the name of the 2221 OSCORE group. 2223 Upon receiving the Policies Request, the Group Manager processes it 2224 as per Section 4.6.1 of [I-D.ietf-ace-key-groupcomm]. The success 2225 Policies Response is formatted as defined in Section 4.6.1 of 2226 [I-D.ietf-ace-key-groupcomm]. 2228 15. Retrieve the Keying Material Version 2230 A group member may request the current version of the keying material 2231 used in the OSCORE group. To this end, the group member sends a 2232 Version Request, as per Section 4.7.1.1 of 2233 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP GET 2234 request to the endpoint /ace-group/GROUPNAME/num at the Group 2235 Manager, where GROUPNAME is the name of the OSCORE group. 2237 Upon receiving the Version Request, the Group Manager processes it as 2238 per Section 4.7.1 of [I-D.ietf-ace-key-groupcomm]. The success 2239 Version Response is formatted as defined in Section 4.7.1 of 2240 [I-D.ietf-ace-key-groupcomm]. 2242 16. Retrieve the Group Status 2244 A group member may request the current status of the the OSCORE 2245 group, i.e., active or inactive. To this end, the group member sends 2246 a Group Status Request to the Group Manager. 2248 In particular, the group member sends a CoAP GET request to the 2249 endpoint /ace-group/GROUPNAME/active at the Group Manager defined in 2250 Section 5.1 of this document, where GROUPNAME is the name of the 2251 OSCORE group. 2253 The payload of the 2.05 (Content) Group Status Response includes the 2254 CBOR simple value "true" (0xf5) if the group is currently active, or 2255 the CBOR simple value "false" (0xf4) otherwise. The group is 2256 considered active if it is set to allow new members to join, and if 2257 communication within the group is fine to happen. 2259 Upon learning from a 2.05 (Content) response that the group is 2260 currently inactive, the group member SHOULD stop taking part in 2261 communications within the group, until it becomes active again. 2263 Upon learning from a 2.05 (Content) response that the group has 2264 become active again, the group member can resume taking part in 2265 communications within the group. 2267 Figure 5 gives an overview of the exchange described above, while 2268 Figure 6 shows an example. 2270 Group Group 2271 Member Manager 2272 | | 2273 |--- Group Status Request: GET ace-group/GROUPNAME/active --->| 2274 | | 2275 |<---------- Group Status Response: 2.05 (Content) -----------| 2276 | | 2278 Figure 5: Message Flow of Group Status Request-Response 2280 Request: 2282 Header: GET (Code=0.01) 2283 Uri-Host: "kdc.example.com" 2284 Uri-Path: "ace-group" 2285 Uri-Path: "g1" 2286 Uri-Path: "active" 2287 Payload: - 2289 Response: 2291 Header: Content (Code=2.05) 2292 Payload (in CBOR diagnostic notation): 2293 true 2295 Figure 6: Example of Group Status Request-Response 2297 17. Retrieve Group Names 2299 A node may want to retrieve from the Group Manager the group name and 2300 the URI of the group-membership resource of a group. This is 2301 relevant in the following cases. 2303 * Before joining a group, a joining node may know only the current 2304 Group Identifier (Gid) of that group, but not the group name and 2305 the URI to the group-membership resource. 2307 * As current group member in several groups, the node has missed a 2308 previous group rekeying in one of them (see Section 20). Hence, 2309 it retains stale keying material and fails to decrypt received 2310 messages exchanged in that group. 2312 Such messages do not provide a direct hint to the correct group 2313 name, that the node would need in order to retrieve the latest 2314 keying material and authentication credentials from the Group 2315 Manager (see Section 8.1, Section 8.2 and Section 10). However, 2316 such messages may specify the current Gid of the group, as value 2317 of the 'kid_context' field of the OSCORE CoAP option (see 2318 Section 6.1 of [RFC8613] and Section 4.2 of 2319 [I-D.ietf-core-oscore-groupcomm]). 2321 * As signature verifier, the node also refers to a group name for 2322 retrieving the required authentication credentials from the Group 2323 Manager (see Section 10). As discussed above, intercepted 2324 messages do not provide a direct hint to the correct group name, 2325 while they may specify the current Gid of the group, as value of 2326 the 'kid_context' field of the OSCORE CoAP option. In such a 2327 case, upon intercepting a message in the group, the node requires 2328 to correctly map the Gid currently used in the group with the 2329 invariant group name. 2331 Furthermore, since it is not a group member, the node does not 2332 take part to a possible group rekeying. Thus, following a group 2333 rekeying and the consequent change of Gid in a group, the node 2334 would retain the old Gid value and cannot correctly associate 2335 intercepted messages to the right group, especially if acting as 2336 signature verifier in several groups. This in turn prevents the 2337 efficient verification of signatures, and especially the retrieval 2338 of required, new authentication credentials from the Group 2339 Manager. 2341 In either case, the node only knows the current Gid of the group, as 2342 learned from received or intercepted messages exchanged in the group. 2343 As detailed below, the node can contact the Group Manager, and 2344 request the group name and URI to the group-membership resource 2345 corresponding to that Gid. Then, it can use that information to 2346 either join the group as a candidate group member, get the latest 2347 keying material as a current group member, or retrieve authentication 2348 credentials used in the group as a signature verifier. To this end, 2349 the node sends a Group Name and URI Retrieval Request, as per 2350 Section 4.2.1.1 of [I-D.ietf-ace-key-groupcomm]. 2352 In particular, the node sends a CoAP FETCH request to the endpoint 2353 /ace-group at the Group Manager formatted as defined in Section 4.2.1 2354 of [I-D.ietf-ace-key-groupcomm]. Each element of the CBOR array 2355 'gid' is a CBOR byte string (REQ13), which encodes the Gid of the 2356 group for which the group name and the URI to the group-membership 2357 resource are requested. 2359 Upon receiving the Group Name and URI Retrieval Request, the Group 2360 Manager processes it as per Section 4.2.1 of 2361 [I-D.ietf-ace-key-groupcomm]. The success Group Name and URI 2362 Retrieval Response is formatted as defined in Section 4.2.1 of 2363 [I-D.ietf-ace-key-groupcomm]. In particular, each element of the 2364 CBOR array 'gid' is a CBOR byte string (REQ13), which encodes the Gid 2365 of the group for which the group name and the URI to the group- 2366 membership resource are provided. 2368 For each of its groups, the Group Manager maintains an association 2369 between the group name and the URI to the group-membership resource 2370 on one hand, and only the current Gid for that group on the other 2371 hand. That is, the Group Manager MUST NOT maintain an association 2372 between the former pair and any other Gid for that group than the 2373 current, most recent one. 2375 Figure 7 gives an overview of the exchanges described above, while 2376 Figure 8 shows an example. 2378 Group 2379 Node Manager 2380 | | 2381 |---- Group Name and URI Retrieval Request: FETCH ace-group/ --->| 2382 | | 2383 |<--- Group Name and URI Retrieval Response: 2.05 (Content) -----| 2384 | | 2386 Figure 7: Message Flow of Group Name and URI Retrieval Request- 2387 Response 2389 Request: 2391 Header: FETCH (Code=0.05) 2392 Uri-Host: "kdc.example.com" 2393 Uri-Path: "ace-group" 2394 Content-Format: "application/ace-groupcomm+cbor" 2395 Payload (in CBOR diagnostic notation): 2396 { 2397 "gid": [h'37fc', h'84bd'] 2398 } 2400 Response: 2402 Header: Content (Code=2.05) 2403 Content-Format: "application/ace-groupcomm+cbor" 2404 Payload (in CBOR diagnostic notation): 2405 { 2406 "gid": [h'37fc', h'84bd'], 2407 "gname": ["g1", "g2"], 2408 "guri": ["ace-group/g1", "ace-group/g2"] 2409 } 2411 Figure 8: Example of Group Name and URI Retrieval Request-Response 2413 18. Leave the Group 2415 A group member may request to leave the OSCORE group. To this end, 2416 the group member sends a Group Leaving Request, as per 2417 Section 4.8.3.1 of [I-D.ietf-ace-key-groupcomm]. In particular, it 2418 sends a CoAP DELETE request to the endpoint /ace- 2419 group/GROUPNAME/nodes/NODENAME at the Group Manager. 2421 Upon receiving the Group Leaving Request, the Group Manager processes 2422 it as per Section 4.8.3 of [I-D.ietf-ace-key-groupcomm]. Then, the 2423 Group Manager performs the follow-up actions defined in Section 19. 2425 19. Removal of a Group Member 2427 Other than after a spontaneous request to the Group Manager as 2428 described in Section 18, a node may be forcibly removed from the 2429 OSCORE group, e.g., due to expired or revoked authorization. 2431 In either case, if the Group Manager reassigns Gid values during the 2432 group's lifetime (see Section 3.2.1.1 of 2433 [I-D.ietf-core-oscore-groupcomm]), the Group Manager "forgets" the 2434 Birth Gid currently associated with the leaving node in the OSCORE 2435 group. This was stored following the Joining Response sent to that 2436 node, after its latest (re-)joining of the OSCORE group (see 2437 Section 6.4). 2439 If any of the two conditions below holds, the Group Manager MUST 2440 inform the leaving node of its eviction as follows. If both 2441 conditions hold, the Group Manager MUST inform the leaving node only 2442 once, using either of the corresponding methods. 2444 * If, upon joining the group (see Section 6.2), the leaving node 2445 specified a URI in the 'control_uri' parameter defined in 2446 Section 4.3.1 of [I-D.ietf-ace-key-groupcomm], the Group Manager 2447 sends a DELETE request targeting the URI specified in the 2448 'control_uri' parameter (OPT7). 2450 * If, when sending Joining Responses to nodes joining the group (see 2451 Section 6.4) the Group Manager specifies a URI in the 2452 'control_group_uri' parameter defined in Section 4.3.1 of 2453 [I-D.ietf-ace-key-groupcomm], the Group Manager sends a DELETE 2454 request targeting the URI specified in the 'control_group_uri' 2455 parameter (OPT10). 2457 * If the leaving node has been observing the associated resource at 2458 ace-group/GROUPNAME/nodes/NODENAME, the Group Manager sends an 2459 unsolicited 4.04 (Not Found) error response to the leaving node, 2460 as specified in Section 4.3.2 of [I-D.ietf-ace-key-groupcomm]. 2462 If the leaving node has not exclusively the role of monitor, the 2463 Group Manager performs the following actions. 2465 * The Group Manager frees the OSCORE Sender ID value of the leaving 2466 node. This value MUST NOT become available for possible upcoming 2467 joining nodes in the same group, until the group has been rekeyed 2468 and assigned a new Group Identifier (Gid). 2470 * The Group Manager MUST add the relinquished Sender ID of the 2471 leaving node to the most recent set of stale Sender IDs, in the 2472 collection associated with the group (see Section 2.2.1). 2474 * The Group Manager cancels the association between, on one hand, 2475 the authentication credential of the leaving node and, on the 2476 other hand, the Gid associated with the OSCORE group together with 2477 the freed Sender ID value. The Group Manager deletes the 2478 authentication credential of the leaving node, if that 2479 authentication credential has no remaining association with any 2480 pair (Gid, Sender ID). 2482 Then, the Group Manager MUST generate updated security parameters and 2483 group keying material, and provide it to the remaining group members 2484 (see Section 20). As a consequence, the leaving node is not able to 2485 acquire the new security parameters and group keying material 2486 distributed after its leaving. 2488 The same considerations from Section 5 of 2489 [I-D.ietf-ace-key-groupcomm] apply here as well, considering the 2490 Group Manager acting as KDC. 2492 20. Group Rekeying Process 2494 In order to rekey the OSCORE group, the Group Manager distributes a 2495 new Group Identifier (Gid), i.e., a new OSCORE ID Context; a new 2496 OSCORE Master Secret; and, optionally, a new OSCORE Master Salt for 2497 that group. When doing so, the Group Manager MUST increment the 2498 version number of the group keying material, before starting its 2499 distribution. 2501 As per Section 3.2.1.1 of [I-D.ietf-core-oscore-groupcomm], the Group 2502 Manager MAY reassign a Gid to the same group over that group's 2503 lifetime, e.g., once the whole space of Gid values has been used for 2504 the group in question. If the Group Manager supports reassignment of 2505 Gid values and performs it in a group, then the Group Manager 2506 additionally takes the following actions. 2508 * Before rekeying the group, the Group Manager MUST check if the new 2509 Gid to be distributed coincides with the Birth Gid of any of the 2510 current group members (see Section 6.4). 2512 * If any of such "elder members" is found in the group, the Group 2513 Manager MUST evict them from the group. That is, the Group 2514 Manager MUST terminate their membership and MUST rekey the group 2515 in such a way that the new keying material is not provided to 2516 those evicted elder members. This also includes adding their 2517 relinquished Sender IDs to the most recent set of stale Sender 2518 IDs, in the collection associated with the group (see 2519 Section 2.2.1), before rekeying the group. 2521 Until a further following group rekeying, the Group Manager MUST 2522 store the list of those latest-evicted elder members. If any of 2523 those nodes re-joins the group before a further following group 2524 rekeying occurs, the Group Manager MUST NOT rekey the group upon 2525 their re-joining. When one of those nodes re-joins the group, the 2526 Group Manager can rely, e.g., on the ongoing secure communication 2527 association to recognize the node as included in the stored list. 2529 Across the rekeying execution, the Group Manager MUST preserve the 2530 same unchanged OSCORE Sender IDs for all group members intended to 2531 remain in the group. This avoids affecting the retrieval of 2532 authentication credentials from the Group Manager and the 2533 verification of group messages. 2535 The Group Manager MUST support the "Point-to-Point" group rekeying 2536 scheme registered in Section 11.14 of [I-D.ietf-ace-key-groupcomm], 2537 as per the detailed use defined in Section 20.1 of this document. 2538 Future specifications may define how this application profile can use 2539 alternative group rekeying schemes, which MUST comply with the 2540 functional steps defined in Section 3.2 of 2541 [I-D.ietf-core-oscore-groupcomm]. The Group Manager MUST indicate 2542 the use of such an alternative group rekeying scheme to joining 2543 nodes, by means of the 'group_rekeying' parameter included in Joining 2544 Response messages (see Section 6.4). 2546 It is RECOMMENDED that the Group Manager gets confirmation of 2547 successful distribution from the group members, and admits a maximum 2548 number of individual retransmissions to non-confirming group members. 2549 Once completed the group rekeying process, the Group Manager creates 2550 a new empty set X' of stale Sender IDs associated with the version of 2551 the newly distributed group keying material. Then, the Group Manager 2552 MUST add the set X' to the collection of stale Sender IDs associated 2553 with the group (see Section 2.2.1). 2555 In case the rekeying terminates and some group members have not 2556 received the new keying material, they will not be able to correctly 2557 process following secured messages exchanged in the group. These 2558 group members will eventually contact the Group Manager, in order to 2559 retrieve the current keying material and its version. 2561 Some of these group members may be in multiple groups, each 2562 associated with a different Group Manager. When failing to correctly 2563 process messages secured with the new keying material, these group 2564 members may not have sufficient information to determine which exact 2565 Group Manager they should contact, in order to retrieve the current 2566 keying material they are missing. 2568 If the Gid is formatted as described in Appendix C of 2569 [I-D.ietf-core-oscore-groupcomm], the Group Prefix can be used as a 2570 hint to determine the right Group Manager, as long as no collisions 2571 among Group Prefixes are experienced. Otherwise, a group member 2572 needs to contact the Group Manager of each group, e.g., by first 2573 requesting only the version of the current group keying material (see 2574 Section 15) and then possibly requesting the current keying material 2575 (see Section 8.1). 2577 Furthermore, some of these group members can be in multiple groups, 2578 all of which associated with the same Group Manager. In this case, 2579 these group members may also not have sufficient information to 2580 determine which exact group they should refer to, when contacting the 2581 right Group Manager. Hence, they need to contact a Group Manager 2582 multiple times, i.e., separately for each group they belong to and 2583 associated with that Group Manager. 2585 Finally, Section 20.3 discusses how a group member can realize that 2586 it has missed one or more rekeying instances, and the actions it is 2587 accordingly required to take. 2589 20.1. Sending Rekeying Messages 2591 The group rekeying messages MUST have Content-Format set to 2592 application/ace-groupcomm+cbor and have the same format used for the 2593 Joining Response message in Section 6.4, with the following 2594 differences. Note that this extends the minimal content of a 2595 rekeying message as defined in Section 6 of 2596 [I-D.ietf-ace-key-groupcomm] (OPT14). 2598 * From the Joining Response, only the parameters 'gkty', 'key', 2599 'num', 'exp', and 'ace-groupcomm-profile' are present. In 2600 particular, the 'key' parameter includes only the following data. 2602 - The 'ms' parameter, specifying the new OSCORE Master Secret 2603 value. This parameter MUST be present. 2605 - The 'contextId' parameter, specifying the new Gid to use as 2606 OSCORE ID Context value. This parameter MUST be present. 2608 - The 'salt' value, specifying the new OSCORE Master Salt value. 2609 This parameter MAY be present. 2611 * The parameter 'stale_node_ids' MUST also be included, with CBOR 2612 label defined in Section 25.3. This parameter is encoded as a 2613 CBOR array, where each element is encoded as a CBOR byte string. 2614 The CBOR array has to be intended as a set, i.e., the order of its 2615 elements is irrelevant. The parameter is populated as follows. 2617 - The Group Manager creates an empty CBOR array ARRAY. 2619 - The Group Manager considers the collection of stale Sender IDs 2620 associated with the group (see Section 2.2.1), and takes the 2621 most recent set X, i.e., the set associated with the current 2622 version of the group keying material about to be relinquished. 2624 - For each Sender ID in X, the Group Manager encodes it as a CBOR 2625 byte string and adds the result to ARRAY. 2627 - The parameter 'stale_node_ids' takes ARRAY as value. 2629 * The parameters 'pub_keys', 'peer_roles' and 'peer_identifiers' 2630 SHOULD be present, if the group rekeying is performed due to one 2631 or multiple Clients that have requested join the group. Following 2632 the same semantics used in the Joining Response message (see 2633 Section 6.4), the three parameters specify the authentication 2634 credential, roles in the group and node identifier of each of the 2635 Clients that have requested to join the group. The Group Manager 2636 MUST NOT include a non-empty subset of these three parameters. 2638 The Group Manager separately sends a group rekeying message formatted 2639 as defined above to each group member to be rekeyed. 2641 Each rekeying message MUST be secured with the pairwise secure 2642 communication channel between the Group Manager and the group member 2643 used during the joining process. In particular, each rekeying 2644 message can target the 'control_uri' URI path defined in 2645 Section 4.3.1 of [I-D.ietf-ace-key-groupcomm] (OPT7), if provided by 2646 the intended recipient upon joining the group (see Section 6.2). 2648 This distribution approach requires group members to act (also) as 2649 servers, in order to correctly handle unsolicited group rekeying 2650 messages from the Group Manager. In particular, if a group member 2651 and the Group Manager use OSCORE [RFC8613] to secure their pairwise 2652 communications, the group member MUST create a Replay Window in its 2653 own Recipient Context upon establishing the OSCORE Security Context 2654 with the Group Manager, e.g., by means of the OSCORE profile of ACE 2655 [I-D.ietf-ace-oscore-profile]. 2657 Group members and the Group Manager SHOULD additionally support 2658 alternative distribution approaches that do not require group members 2659 to act (also) as servers. A number of such approaches are defined in 2660 Section 6 of [I-D.ietf-ace-key-groupcomm]. In particular, a group 2661 member may use CoAP Observe [RFC7641] and subscribe for updates to 2662 the group-membership resource of the group, at the endpoint /ace- 2663 group/GROUPNAME/ of the Group Manager (see Section 6.1 of 2664 [I-D.ietf-ace-key-groupcomm]). Alternatively, a full-fledged Pub-Sub 2665 model can be considered [I-D.ietf-core-coap-pubsub], where the Group 2666 Manager publishes to a rekeying topic hosted at a Broker, while the 2667 group members subscribe to such topic (see Section 6.2 of 2668 [I-D.ietf-ace-key-groupcomm]). 2670 20.2. Receiving Rekeying Messages 2672 Once received the new group keying material, a group member proceeds 2673 as follows. 2675 The group member considers the stale Sender IDs received from the 2676 Group Manager. If the group rekeying scheme defined in Section 20.1 2677 is used, the stale Sender IDs are specified by the 'stale_node_ids' 2678 parameter. 2680 After that, as per Section 3.2 of [I-D.ietf-core-oscore-groupcomm], 2681 the group member MUST remove every authentication credential 2682 associated with a stale Sender ID from its list of group members' 2683 authentication credentials used in the group, and MUST delete each of 2684 its Recipient Contexts used in the group whose corresponding 2685 Recipient ID is a stale Sender ID. 2687 Then, the following cases can occur, based on the version number V' 2688 of the new group keying material distributed through the rekeying 2689 process. If the group rekeying scheme defined in Section 20.1 is 2690 used, this information is specified by the 'num' parameter. 2692 * The group member has not missed any group rekeying. That is, the 2693 old keying material stored by the group member has version number 2694 V, while the received new keying material has version number V' = 2695 (V + 1). In such a case, the group member simply installs the new 2696 keying material and derives the corresponding new Security 2697 Context. 2699 * The group member has missed one or more group rekeying instances. 2700 That is, the old keying material stored by the group member has 2701 version number V, while the received new keying material has 2702 version number V' > (V + 1). In such a case, the group member 2703 MUST proceed as defined in Section 20.3. 2705 * The group member has received keying material not newer than the 2706 stored one. That is, the old keying material stored by the group 2707 member has version number V, while the received keying material 2708 has version number V' < (V + 1). In such a case, the group member 2709 MUST ignore the received rekeying messages and MUST NOT install 2710 the received keying material. 2712 20.3. Missed Rekeying Instances 2714 A group member can realize to have missed one or more rekeying 2715 instances in one of the ways discussed below. In the following, V 2716 denotes the version number of the old keying material stored by the 2717 group member, while V' denotes the version number of the latest, 2718 possibly just distributed, keying material. 2720 a. The group member has participated to a rekeying process that has 2721 distributed new keying material with version number V' > (V + 1), as 2722 discussed in Section 20.2. 2724 b. The group member has obtained the latest keying material from the 2725 Group Manager, as a response to a Key Distribution Request (see 2726 Section 8.1) or to a Joining Request when re-joining the group (see 2727 Section 6.2). In particular, V is different than V' specified by the 2728 'num' parameter in the response. 2730 c. The group member has obtained the authentication credentials of 2731 other group members, through a Public Key Request-Response exchange 2732 with the Group Manager (see Section 10). In particular, V is 2733 different than V' specified by the 'num' parameter in the response. 2735 d. The group member has performed a Version Request-Response 2736 exchange with the Group Manager (see Section 15). In particular, V 2737 is different than V' specified by the 'num' parameter in the 2738 response. 2740 In either case, the group member MUST delete the stored keying 2741 material with version number V. 2743 If case (a) or case (b) applies, the group member MUST perform the 2744 following actions. 2746 1. The group member MUST NOT install the latest keying material yet, 2747 in case that was already obtained. 2749 2. The group member sends a Stale Sender IDs Request to the Group 2750 Manager (see Section 20.3.1), specifying the version number V as 2751 payload of the request. 2753 If the Stale Sender IDs Response from the Group Manager has no 2754 payload, the group member MUST remove all the authentication 2755 credentials from its list of group members' authentication 2756 credentials used in the group, and MUST delete all its Recipient 2757 Contexts used in the group. 2759 Otherwise, the group member considers the stale Sender IDs 2760 specified in the Stale Sender IDs Response from the Group 2761 Manager. Then, the group member MUST remove every authentication 2762 credential associated with a stale Sender ID from its list of 2763 group members' authentication credentials used in the group, and 2764 MUST delete each of its Recipient Contexts used in the group 2765 whose corresponding Recipient ID is a stale Sender ID. 2767 3. The group member installs the latest keying material with version 2768 number V' and derives the corresponding new Security Context. 2770 If case (c) or case (d) applies, the group member SHOULD perform the 2771 following actions. 2773 1. The group member sends a Stale Sender IDs Request to the Group 2774 Manager (see Section 20.3.1), specifying the version number V as 2775 payload of the request. 2777 If the Stale Sender IDs Response from the Group Manager has no 2778 payload, the group member MUST remove all the authentication 2779 credentials from its list of group members' authentication 2780 credentials used in the group, and MUST delete all its Recipient 2781 Contexts used in the group. 2783 Otherwise, the group member considers the stale Sender IDs 2784 specified in the Stale Sender IDs Response from the Group 2785 Manager. Then, the group member MUST remove every authentication 2786 credential associated with a stale Sender ID from its list of 2787 group members' authentication credentials used in the group, and 2788 MUST delete each of its Recipient Contexts used in the group 2789 whose corresponding Recipient ID is a stale Sender ID. 2791 2. The group member obtains the latest keying material with version 2792 number V' from the Group Manager. This can happen by sending a 2793 Key Distribution Request to the Group Manager (see Section 8.1), 2794 or by re-joining the group (see Section 6.2). 2796 3. The group member installs the latest keying material with version 2797 number V' and derives the corresponding new Security Context. 2799 If case (c) or case (d) applies, the group member can alternatively 2800 perform the following actions. 2802 1. The group member re-joins the group (see Section 6.2). When 2803 doing so, the group member MUST re-join with the same roles it 2804 currently has in the group, and MUST request the Group Manager 2805 for the authentication credentials of all the current group 2806 members. That is, the 'get_pub_keys' parameter of the Joining 2807 Request MUST be present and MUST be set to the CBOR simple value 2808 "null" (0xf6). 2810 2. When receiving the Joining Response (see Section 6.5 and 2811 Section 6.5), the group member retrieves the set Z of 2812 authentication credentials specified in the 'pub_keys' parameter. 2814 Then, the group member MUST remove every authentication 2815 credential which is not in Z from its list of group members' 2816 authentication credentials used in the group, and MUST delete 2817 each of its Recipient Contexts used in the group that does not 2818 include any of the authentication credentials in Z. 2820 3. The group member installs the latest keying material with version 2821 number V' and derives the corresponding new Security Context. 2823 20.3.1. Retrieval of Stale Sender IDs 2825 When realizing to have missed one or more group rekeying instances 2826 (see Section 20.3), a node needs to retrieve from the Group Manager 2827 the data required to delete some of its stored group members' 2828 authentication credentials and Recipient Contexts (see 2829 Section 5.3.1). This data is provided as an aggregated set of stale 2830 Sender IDs, which are used as specified in Section 20.3. 2832 In particular, the node sends a CoAP FETCH request to the endpoint 2833 /ace-group/GROUPNAME/stale-sids at the Group Manager defined in 2834 Section 5.3 of this document, where GROUPNAME is the name of the 2835 OSCORE group. 2837 The payload of the Stale Sender IDs Request MUST include a CBOR 2838 unsigned integer. This encodes the version number V of the most 2839 recent group keying material stored and installed by the requesting 2840 client, which is older than the latest, possibly just distributed, 2841 keying material with version number V'. 2843 The handler MUST reply with a 4.00 (Bad Request) error response, if 2844 the request is not formatted correctly. Also, the handler MUST 2845 respond with a 4.00 (Bad Request) error response, if the specified 2846 version number V is greater or equal than the version number V' 2847 associated with the latest keying material in the group, i.e., if V 2848 >= V'. 2850 Otherwise, the handler responds with a 2.05 (Content) Stale Sender 2851 IDs Response. The payload of the response is formatted as defined 2852 below, where SKEW = (V' - V + 1). 2854 * The Group Manager considers ITEMS as the current number of sets 2855 stored in the collection of stale Sender IDs associated with the 2856 group (see Section 2.2.1). 2858 * If SKEW > ITEMS, the Stale Sender IDs Response MUST NOT have a 2859 payload. 2861 * Otherwise, the payload of the Stale Sender IDs Response MUST 2862 include a CBOR array, where each element is encoded as a CBOR byte 2863 string. The CBOR array has to be intended as a set, i.e., the 2864 order of its elements is irrelevant. The Group Manager populates 2865 the CBOR array as follows. 2867 - The Group Manager creates an empty CBOR array ARRAY and an 2868 empty set X. 2870 - The Group Manager considers the SKEW most recent sets stored in 2871 the collection of stale Sender IDs associated with the group. 2872 Note that the most recent set is the one associate to the 2873 latest version of the group keying material. 2875 - The Group Manager copies all the Sender IDs from the selected 2876 sets into X. When doing so, the Group Manager MUST discard 2877 duplicates. That is, the same Sender ID MUST NOT be present 2878 more than once in the final content of X. 2880 - For each Sender ID in X, the Group Manager encodes it as a CBOR 2881 byte string and adds the result to ARRAY. 2883 - Finally, ARRAY is specified as payload of the Stale Sender IDs 2884 Response. Note that ARRAY might result in the empty CBOR 2885 array. 2887 Figure 9 gives an overview of the exchange described above, while 2888 Figure 10 shows an example. 2890 Group 2891 Node Manager 2892 | | 2893 | Stale Sender IDs Request | 2894 |------------------------------------------------------------>| 2895 | FETCH ace-group/GROUPNAME/stale-sids | 2896 | | 2897 |<---------- Stale Sender IDs Response: 2.05 (Content) -------| 2898 | | 2900 Figure 9: Message Flow of Stale Sender IDs Request-Response 2902 Request: 2904 Header: FETCH (Code=0.05) 2905 Uri-Host: "kdc.example.com" 2906 Uri-Path: "ace-group" 2907 Uri-Path: "g1" 2908 Uri-Path: "stale-sids" 2909 Payload (in CBOR diagnostic notation): 2910 42 2912 Response: 2914 Header: Content (Code=2.05) 2915 Payload (in CBOR diagnostic notation): 2916 [h'01', h'fc', h'12ab', h'de44', h'ff'] 2918 Figure 10: Example of Stale Sender IDs Request-Response 2920 21. ACE Groupcomm Parameters 2922 Clients are required to support the new parameters defined in this 2923 application profile as specified below (REQ29). 2925 * 'group_senderId' MUST be supported by a Client that intends to 2926 join an OSCORE group with the role of Requester and/or Responder. 2928 * 'ecdh_info' MUST be supported by a Client that intends to join a 2929 group which uses the pairwise mode of Group OSCORE. 2931 * 'kdc_dh_creds' MUST be supported by a Client that intends to join 2932 a group which uses the pairwise mode of Group OSCORE and that does 2933 not plan to or cannot rely on an early retrieval of the Group 2934 Manager's Diffie-Hellman authentication credential. 2936 * 'group_enc_key' MUST be supported by a Client that intends to join 2937 a group which uses the group mode of Group OSCORE or to be 2938 signature verifier for that group. 2940 * 'stale_node_ids' MUST be supported. 2942 When the conditional parameters defined in Section 8 of 2943 [I-D.ietf-ace-key-groupcomm] are used with this application profile, 2944 Clients must, should or may support them as specified below (REQ30). 2946 * 'client_cred', 'cnonce', 'client_cred_verify'. A Client that has 2947 an own authentication credential to use in a group MUST support 2948 these parameters. 2950 * 'kdcchallenge'. A Client that has an own authentication 2951 credential to use in a group and that provides the Access Token to 2952 the Group Manager through a Token Transfer Request (see 2953 Section 6.1) MUST support this parameter. 2955 * 'pub_keys_repo'. This parameter is not relevant for this 2956 application profile, since the Group Manager always acts as 2957 repository of the group members' authentication credentials. 2959 * 'group_policies'. A Client that is interested in the specific 2960 policies used in a group, but that does not know them or cannot 2961 become aware of them before joining that group SHOULD support this 2962 parameter. 2964 * 'peer_roles'. A Client MUST support this parameter, since in this 2965 application profile it is relevant for Clients to know the roles 2966 of the group member associated with each authentication 2967 credential. 2969 * 'kdc_nonce', 'kdc_cred' and 'kdc_cred_verify'. A Client MUST 2970 support these parameters, since the Group Manager's authentication 2971 credential is required to process messages protected with Group 2972 OSCORE (see Section 4.3 of [I-D.ietf-core-oscore-groupcomm]). 2974 * 'mgt_key_material'. A Client that supports an advanced rekeying 2975 scheme possibly used in the group, such as based on one-to-many 2976 rekeying messages sent over IP multicast, MUST support this 2977 parameter. 2979 * 'control_group_uri'. A Client that support the hosting of local 2980 resources each associated with a group (hence acting as CoAP 2981 server) and the reception of one-to-many requests sent to those 2982 resources by the Group Manager (e.g., over IP multicast) MUST 2983 support this parameter. 2985 22. ACE Groupcomm Error Identifiers 2987 In addition to what is defined in Section 9 of 2988 [I-D.ietf-ace-key-groupcomm], this application profile defines new 2989 values that the Group Manager can include as error identifiers, in 2990 the 'error' field of an error response with Content-Format 2991 application/ace-groupcomm+cbor. 2993 +-------+-------------------------------------------------+ 2994 | Value | Description | 2995 +-------+-------------------------------------------------+ 2996 | 7 | Signatures not used in the group | 2997 +-------+-------------------------------------------------+ 2998 | 8 | Operation permitted only to signature verifiers | 2999 +-------+-------------------------------------------------+ 3000 | 9 | Group currently not active | 3001 +-------+-------------------------------------------------+ 3003 Figure 11: ACE Groupcomm Error Identifiers 3005 A Client supporting the 'error' parameter (see Sections 4.1.2 and 8 3006 of [I-D.ietf-ace-key-groupcomm]) and able to understand the specified 3007 error may use that information to determine what actions to take 3008 next. If it is included in the error response and supported by the 3009 Client, the 'error_description' parameter may provide additional 3010 context. In particular, the following guidelines apply. 3012 * In case of error 7, the Client should stop sending the request in 3013 question to the Group Manager. In this application profile, this 3014 error is relevant only for a signature verifiers, in case it tries 3015 to access resources related to a pairwise-only group. 3017 * In case of error 8, the Client should stop sending the request in 3018 question to the Group Manager. 3020 * In case of error 9, the Client should wait for a certain (pre- 3021 configured) amount of time, before trying re-sending its request 3022 to the Group Manager. 3024 23. Default Values for Group Configuration Parameters 3026 This section defines the default values that the Group Manager 3027 assumes for the configuration parameters of an OSCORE group, unless 3028 differently specified when creating and configuring the group. This 3029 can be achieved as specified in [I-D.ietf-ace-oscore-gm-admin]. 3031 23.1. Common 3033 This section always applies, as related to common configuration 3034 parameters. 3036 * For the HKDF Algorithm 'hkdf', the Group Manager SHOULD use the 3037 same default value defined in Section 3.2 of [RFC8613], i.e., HKDF 3038 SHA-256 (COSE algorithm encoding: -10). 3040 * For the format 'cred_fmt' used for the authentication credentials 3041 in the group, the Group Manager SHOULD use CBOR Web Token (CWT) or 3042 CWT Claims Set (CCS) [RFC8392], i.e., the COSE Header Parameter 3043 'kcwt' and 'kccs', respectively. 3045 [ These COSE Header Parameters are under pending registration 3046 requested by draft-ietf-lake-edhoc. ] 3048 * For 'max_stale_sets', the Group Manager SHOULD consider N = 3 as 3049 the maximum number of stored sets of stale Sender IDs in the 3050 collection associated with the group (see Section 2.2.1). 3052 23.2. Group Mode 3054 This section applies if the group uses (also) the group mode of Group 3055 OSCORE. 3057 * For the Signature Encryption Algorithm 'sign_enc_alg' used to 3058 encrypted messages protected with the group mode, the Group 3059 Manager SHOULD use AES-CCM-16-64-128 (COSE algorithm encoding: 10) 3060 as default value. 3062 The Group Manager SHOULD use the following default values for the 3063 Signature Algorithm 'sign_alg' and related parameters 'sign_params', 3064 consistently with the "COSE Algorithms" registry [COSE.Algorithms], 3065 the "COSE Key Types" registry [COSE.Key.Types] and the "COSE Elliptic 3066 Curves" registry [COSE.Elliptic.Curves]. 3068 * For the Signature Algorithm 'sign_alg' used to sign messages 3069 protected with the group mode, the signature algorithm EdDSA 3070 [RFC8032]. 3072 * For the parameters 'sign_params' of the Signature Algorithm: 3074 - The array [[OKP], [OKP, Ed25519]], in case EdDSA is assumed or 3075 specified for 'sign_alg'. In particular, this indicates to use 3076 the COSE key type OKP and the elliptic curve Ed25519 [RFC8032]. 3078 - The array [[EC2], [EC2, P-256]], in case ES256 [RFC6979] is 3079 specified for 'sign_alg'. In particular, this indicates to use 3080 the COSE key type EC2 and the elliptic curve P-256. 3082 - The array [[EC2], [EC2, P-384]], in case ES384 [RFC6979] is 3083 specified for 'sign_alg'. In particular, this indicates to use 3084 the COSE key type EC2 and the elliptic curve P-384. 3086 - The array [[EC2], [EC2, P-521]], in case ES512 [RFC6979] is 3087 specified for 'sign_alg'. In particular, this indicates to use 3088 the COSE key type EC2 and the elliptic curve P-521. 3090 - The array [[RSA], [RSA]], in case PS256, PS384 or PS512 3091 [RFC8017] is specified for 'sign_alg'. In particular, this 3092 indicates to use the COSE key type RSA. 3094 23.3. Pairwise Mode 3096 This section applies if the group uses (also) the pairwise mode of 3097 Group OSCORE. 3099 For the AEAD Algorithm 'alg' used to encrypt messages protected with 3100 the pairwise mode, the Group Manager SHOULD use the same default 3101 value defined in Section 3.2 of [RFC8613], i.e., AES-CCM-16-64-128 3102 (COSE algorithm encoding: 10). 3104 For the Pairwise Key Agreement Algorithm 'ecdh_alg' and related 3105 parameters 'ecdh_params', the Group Manager SHOULD use the following 3106 default values, consistently with the "COSE Algorithms" registry 3107 [COSE.Algorithms], the "COSE Key Types" registry [COSE.Key.Types] and 3108 the "COSE Elliptic Curves" registry [COSE.Elliptic.Curves]. 3110 * For the Pairwise Key Agreement Algorithm 'ecdh_alg' used to 3111 compute static-static Diffie-Hellman shared secrets, the ECDH 3112 algorithm ECDH-SS + HKDF-256 specified in Section 6.3.1 of 3113 [I-D.ietf-cose-rfc8152bis-algs]. 3115 * For the parameters 'ecdh_params' of the Pairwise Key Agreement 3116 Algorithm: 3118 - The array [[OKP], [OKP, X25519]], in case EdDSA is assumed or 3119 specified for 'sign_alg'. In particular, this indicates to use 3120 the COSE key type OKP and the elliptic curve X25519 [RFC8032]. 3122 - The array [[EC2], [EC2, P-256]], in case ES256 [RFC6979] is 3123 specified for 'sign_alg'. In particular, this indicates to use 3124 the COSE key type EC2 and the elliptic curve P-256. 3126 - The array [[EC2], [EC2, P-384]], in case ES384 [RFC6979] is 3127 specified for 'sign_alg'. In particular, this indicates to use 3128 the COSE key type EC2 and the elliptic curve P-384. 3130 - The array [[EC2], [EC2, P-521]], in case ES512 [RFC6979] is 3131 specified for 'sign_alg'. In particular, this indicates to use 3132 the COSE key type EC2 and the elliptic curve P-521. 3134 24. Security Considerations 3136 Security considerations for this profile are inherited from 3137 [I-D.ietf-ace-key-groupcomm], the ACE framework for Authentication 3138 and Authorization [I-D.ietf-ace-oauth-authz], and the specific 3139 transport profile of ACE signalled by the AS, such as 3140 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile]. 3142 The following security considerations also apply for this profile. 3144 24.1. Management of OSCORE Groups 3146 This profile leverages the following management aspects related to 3147 OSCORE groups and discussed in the sections of 3148 [I-D.ietf-core-oscore-groupcomm] referred below. 3150 * Management of group keying material (see Section 3.2 of 3151 [I-D.ietf-core-oscore-groupcomm]). The Group Manager is 3152 responsible for the renewal and re-distribution of the keying 3153 material in the groups of its competence (rekeying). According to 3154 the specific application requirements, this can include rekeying 3155 the group upon changes in its membership. In particular, renewing 3156 the group keying material is required upon a new node's joining or 3157 a current node's leaving, in case backward security and forward 3158 security have to be preserved, respectively. 3160 * Provisioning and retrieval of authentication credentials (see 3161 Section 3 of [I-D.ietf-core-oscore-groupcomm]). The Group Manager 3162 acts as repository of authentication credentials of group members, 3163 and provides them upon request. 3165 * Synchronization of sequence numbers (see Section 6.3 of 3166 [I-D.ietf-core-oscore-groupcomm]). This concerns how a responder 3167 node that has just joined an OSCORE group can synchronize with the 3168 sequence number of requesters in the same group. 3170 Before sending the Joining Response, the Group Manager MUST verify 3171 that the joining node actually owns the associated private key. To 3172 this end, the Group Manager can rely on the proof-of-possession 3173 challenge-response defined in Section 6. 3175 Alternatively, when establishing a secure communication association 3176 with the Group Manager, the joining node can provide the Group 3177 Manager with its own authentication credential, and use the public 3178 key included thereof as asymmetric proof-of-possession key, e.g., as 3179 in Section 3.2.2 of [I-D.ietf-ace-dtls-authorize] in case the joining 3180 node authenticates itself during the DTLS handshake with the the 3181 Group Manager. However, this requires the authentication credential 3182 to be in the format used in the OSCORE group, and that both the 3183 authentication credential and the included public key are compatible 3184 with the signature or ECDH algorithm, and possible associated 3185 parameters used in the OSCORE group. 3187 A node may have joined multiple OSCORE groups under different non- 3188 synchronized Group Managers. Therefore, it can happen that those 3189 OSCORE groups have the same Group Identifier (Gid). It follows that, 3190 upon receiving a Group OSCORE message addressed to one of those 3191 groups, the node would have multiple Security Contexts matching with 3192 the Gid in the incoming message. It is up to the application to 3193 decide how to handle such collisions of Group Identifiers, e.g., by 3194 trying to process the incoming message using one Security Context at 3195 the time until the right one is found. 3197 24.2. Size of Nonces as Proof-of-Possesion Challenge 3199 With reference to the Joining Request message in Section 6.2, the 3200 proof-of-possession (PoP) evidence included in 'client_cred_verify' 3201 is computed over an input including also N_C | N_S, where | denotes 3202 concatenation. 3204 For the N_C challenge, it is RECOMMENDED to use a 8-byte long random 3205 nonce. Furthermore, N_C is always conveyed in the 'cnonce' parameter 3206 of the Joining Request, which is always sent over the secure 3207 communication channel between the joining node and the Group Manager. 3209 As defined in Section 6.2.1, the way the N_S value is computed 3210 depends on the particular way the joining node provides the Group 3211 Manager with the Access Token, as well as on following interactions 3212 between the two. 3214 * If the Access Token has not been provided to the Group Manager by 3215 means of a Token Transfer Request to the /authz-info endpoint as 3216 in Section 6.1, then N_S is computed as a 32-byte long challenge. 3217 For an example, see point (2) of Section 6.2.1. 3219 * If the Access Token has been provided to the Group Manager by 3220 means of a Token Transfer Request to the /authz-info endpoint as 3221 in Section 6.1, then N_S takes the most recent value provided to 3222 the client by the Group Manager in the 'kdcchallenge' parameter, 3223 as specified in point (1) of Section 6.2.1. This is provided 3224 either in the Token Transfer Response (see Section 6.1), or in a 3225 4.00 (Bad Request) error response to a following Joining Request 3226 (see Section 6.3). In either case, it is RECOMMENDED to use a 3227 8-byte long random challenge as value for N_S. 3229 If we consider both N_C and N_S to take 8-byte long values, the 3230 following considerations hold. 3232 * Let us consider both N_C and N_S as taking random values, and the 3233 Group Manager to never change the value of the N_S provided to a 3234 Client during the lifetime of an Access Token. Then, as per the 3235 birthday paradox, the average collision for N_S will happen after 3236 2^32 new transferred Access Tokens, while the average collision 3237 for N_C will happen after 2^32 new Joining Requests. This amounts 3238 to considerably more token provisionings than the expected new 3239 joinings of OSCORE groups under a same Group Manager, as well as 3240 to considerably more requests to join OSCORE groups from a same 3241 Client using a same Access Token under a same Group Manager. 3243 * Section 7 of [I-D.ietf-ace-oscore-profile] as well Appendix B.2 of 3244 [RFC8613] recommend the use of 8-byte random values as well. 3245 Unlike in those cases, the values of N_C and N_S considered in 3246 this document are not used for as sensitive operations as the 3247 derivation of a Security Context, and thus do not have possible 3248 implications in the security of AEAD ciphers. 3250 24.3. Reusage of Nonces for Proof-of-Possession Input 3252 As long as the Group Manager preserves the same N_S value currently 3253 associated with an Access Token, i.e., the latest value provided to a 3254 Client in a 'kdcchallenge' parameter, the Client is able to 3255 successfully reuse the same proof-of-possession (PoP) input for 3256 multiple Joining Requests to that Group Manager. 3258 In particular, the Client can reuse the same N_C value for every 3259 Joining Request to the Group Manager, and combine it with the same 3260 unchanged N_S value. This results in reusing the same PoP input for 3261 producing the PoP evidence to include in the 'client_cred_verify' 3262 parameter of the Joining Requests. 3264 Unless the Group Manager maintains a list of N_C values already used 3265 by that Client since the latest update to the N_S value associated 3266 with the Access Token, the Group Manager can be forced to falsely 3267 believe that the Client possesses its own private key at that point 3268 in time, upon verifying the PoP evidence in the 'client_cred_verify' 3269 parameter. 3271 25. IANA Considerations 3273 Note to RFC Editor: Please replace all occurrences of "[[This 3274 document]]" with the RFC number of this specification and delete this 3275 paragraph. 3277 This document has the following actions for IANA. 3279 25.1. OAuth Parameters 3281 IANA is asked to register the following entries to the "OAuth 3282 Parameters" registry, as per the procedure specified in Section 11.2 3283 of [RFC6749]. 3285 * Parameter name: ecdh_info 3287 * Parameter usage location: client-rs request, rs-client response 3289 * Change Controller: IESG 3291 * Specification Document(s): [[This specification]] 3293 * Parameter name: kdc_dh_creds 3295 * Parameter usage location: client-rs request, rs-client response 3297 * Change Controller: IESG 3299 * Specification Document(s): [[This specification]] 3301 25.2. OAuth Parameters CBOR Mappings 3303 IANA is asked to register the following entries to the "OAuth 3304 Parameters CBOR Mappings" registry, as per the procedure specified in 3305 Section 8.10 of [I-D.ietf-ace-oauth-authz]. 3307 * Name: ecdh_info 3309 * CBOR Key: TBD (range -256 to 255) 3311 * Value Type: Simple value "null" / array 3313 * Reference: [[This specification]] 3315 * Name: kdc_dh_creds 3316 * CBOR Key: TBD (range -256 to 255) 3318 * Value Type: Simple value "null" / array 3320 * Reference: [[This specification]] 3322 25.3. ACE Groupcomm Parameters 3324 IANA is asked to register the following entry to the "ACE Groupcomm 3325 Parameters" registry defined in Section 11.7 of 3326 [I-D.ietf-ace-key-groupcomm]. 3328 * Name: group_senderId 3330 * CBOR Key: TBD 3332 * CBOR Type: Byte string 3334 * Reference: [[This document]] (Section 9) 3336 * Name: ecdh_info 3338 * CBOR Key: TBD 3340 * CBOR Type: Array 3342 * Reference: [[This document]] (Section 6.3) 3344 * Name: kdc_dh_creds 3346 * CBOR Key: TBD 3348 * CBOR Type: Array 3350 * Reference: [[This document]] (Section 6.3) 3352 * Name: group_enc_key 3354 * CBOR Key: TBD 3356 * CBOR Type: Byte String 3358 * Reference: [[This document]] (Section 5.2.1) 3359 * Name: stale_node_ids 3361 * CBOR Key: TBD 3363 * CBOR Type: Array 3365 * Reference: [[This document]] (Section 20) 3367 25.4. ACE Groupcomm Key Types 3369 IANA is asked to register the following entry to the "ACE Groupcomm 3370 Key Types" registry defined in Section 11.8 of 3371 [I-D.ietf-ace-key-groupcomm]. 3373 * Name: Group_OSCORE_Input_Material object 3375 * Key Type Value: GROUPCOMM_KEY_TBD 3377 * Profile: "coap_group_oscore_app", defined in Section 25.5 of this 3378 document. 3380 * Description: A Group_OSCORE_Input_Material object encoded as 3381 described in Section 6.4 of this document. 3383 * Reference: [[This document]] (Section 6.4) 3385 25.5. ACE Groupcomm Profiles 3387 IANA is asked to register the following entry to the "ACE Groupcomm 3388 Profiles" registry defined in Section 11.9 of 3389 [I-D.ietf-ace-key-groupcomm]. 3391 * Name: coap_group_oscore_app 3393 * Description: Application profile to provision keying material for 3394 participating in group communication protected with Group OSCORE 3395 as per [I-D.ietf-core-oscore-groupcomm]. 3397 * CBOR Value: PROFILE_TBD 3399 * Reference: [[This document]] (Section 6.4) 3401 25.6. OSCORE Security Context Parameters 3403 IANA is asked to register the following entries in the "OSCORE 3404 Security Context Parameters" registry defined in Section 9.4 of 3405 [I-D.ietf-ace-oscore-profile]. 3407 * Name: group_SenderId 3409 * CBOR Label: TBD 3411 * CBOR Type: bstr 3413 * Registry: - 3415 * Description: OSCORE Sender ID assigned to a member of an OSCORE 3416 group 3418 * Reference: [[This document]] (Section 6.4) 3420 * Name: cred_fmt 3422 * CBOR Label: TBD 3424 * CBOR Type: integer 3426 * Registry: COSE Header Parameters 3428 * Description: Format of authentication credentials to be used in 3429 the OSCORE group 3431 * Reference: [[This document]] (Section 6.4) 3433 * Name: sign_enc_alg 3435 * CBOR Label: TBD 3437 * CBOR Type: tstr / int 3439 * Registry: COSE Algorithms 3441 * Description: OSCORE Signature Encryption Algorithm Value 3443 * Reference: [[This document]] (Section 6.4) 3445 * Name: sign_alg 3447 * CBOR Label: TBD 3449 * CBOR Type: tstr / int 3451 * Registry: COSE Algorithms 3452 * Description: OSCORE Signature Algorithm Value 3454 * Reference: [[This document]] (Section 6.4) 3456 * Name: sign_params 3458 * CBOR Label: TBD 3460 * CBOR Type: array 3462 * Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves 3464 * Description: OSCORE Signature Algorithm Parameters 3466 * Reference: [[This document]] (Section 6.4) 3468 * Name: ecdh_alg 3470 * CBOR Label: TBD 3472 * CBOR Type: tstr / int 3474 * Registry: COSE Algorithms 3476 * Description: OSCORE Pairwise Key Agreement Algorithm Value 3478 * Reference: [[This document]] (Section 6.4) 3480 * Name: ecdh_params 3482 * CBOR Label: TBD 3484 * CBOR Type: array 3486 * Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves 3488 * Description: OSCORE Pairwise Key Agreement Algorithm Parameters 3490 * Reference: [[This document]] (Section 6.4) 3492 25.7. TLS Exporter Labels 3494 IANA is asked to register the following entry to the "TLS Exporter 3495 Labels" registry defined in Section 6 of [RFC5705] and updated in 3496 Section 12 of [RFC8447]. 3498 * Value: EXPORTER-ACE-Sign-Challenge-coap-group-oscore-app 3500 * DTLS-OK: Y 3502 * Recommended: N 3504 * Reference: [[This document]] (Section 6.2.1) 3506 25.8. AIF 3508 For the media-types application/aif+cbor and application/aif+json 3509 defined in Section 5.1 of [I-D.ietf-ace-aif], IANA is requested to 3510 register the following entries for the two media-type parameters Toid 3511 and Tperm, in the respective sub-registry defined in Section 5.2 of 3512 [I-D.ietf-ace-aif] within the "MIME Media Type Sub-Parameter" 3513 registry group. 3515 * Name: oscore-group-name 3517 * Description/Specification: group name of an OSCORE group 3519 * Reference: [[This document]] 3521 * Name: oscore-group-roles 3523 * Description/Specification: role(s) in the OSCORE group 3525 * Reference: [[This document]] 3527 25.9. CoAP Content-Format 3529 IANA is asked to register the following entries to the "CoAP Content- 3530 Formats" registry within the "Constrained RESTful Environments (CoRE) 3531 Parameters" registry group. 3533 * Media Type: application/aif+cbor;Toid="oscore-group- 3534 name",Tperm="oscore-group-roles" 3536 * Encoding: - 3538 * ID: TBD 3540 * Reference: [[This document]] 3542 * Media Type: application/aif+json;Toid="oscore-group- 3543 name",Tperm="oscore-group-roles" 3545 * Encoding: - 3547 * ID: TBD 3549 * Reference: [[This document]] 3551 25.10. Group OSCORE Roles 3553 This document establishes the IANA "Group OSCORE Roles" registry. 3554 The registry has been created to use the "Expert Review" registration 3555 procedure [RFC8126]. Expert review guidelines are provided in 3556 Section 25.14. 3558 This registry includes the possible roles that nodes can take in an 3559 OSCORE group, each in combination with a numeric identifier. These 3560 numeric identifiers are used to express authorization information 3561 about joining OSCORE groups, as specified in Section 3 of [[This 3562 document]]. 3564 The columns of this registry are: 3566 * Name: A value that can be used in documents for easier 3567 comprehension, to identify a possible role that nodes can take in 3568 an OSCORE group. 3570 * Value: The numeric identifier for this role. Integer values 3571 greater than 65535 are marked as "Private Use", all other values 3572 use the registration policy "Expert Review" [RFC8126]. 3574 * Description: This field contains a brief description of the role. 3576 * Reference: This contains a pointer to the public specification for 3577 the role. 3579 This registry will be initially populated by the values in Figure 1. 3581 The Reference column for all of these entries will be [[This 3582 document]]. 3584 25.11. CoRE Resource Type 3586 IANA is asked to register the following entry in the "Resource Type 3587 (rt=) Link Target Attribute Values" registry within the "Constrained 3588 Restful Environments (CoRE) Parameters" registry group. 3590 * Value: "core.osc.gm" 3592 * Description: Group-membership resource of an OSCORE Group Manager. 3594 * Reference: [[This document]] 3596 Client applications can use this resource type to discover a group 3597 membership resource at an OSCORE Group Manager, where to send a 3598 request for joining the corresponding OSCORE group. 3600 25.12. ACE Scope Semantics 3602 IANA is asked to register the following entry in the "ACE Scope 3603 Semantics" registry defined in Section 11.12 of 3604 [I-D.ietf-ace-key-groupcomm]. 3606 * Value: SEM_ID_TBD 3608 * Description: Membership and key management operations at the ACE 3609 Group Manager for Group OSCORE. 3611 * Reference: [[This document]] 3613 25.13. ACE Groupcomm Errors 3615 IANA is asked to register the following entry in the "ACE Groupcomm 3616 Errors" registry defined in Section 11.13 of 3617 [I-D.ietf-ace-key-groupcomm]. 3619 * Value: 7 3621 * Description: Signatures not used in the group. 3623 * Reference: [[This document]] 3625 * Value: 8 3627 * Description: Operation permitted only to signature verifiers. 3629 * Reference: [[This document]] 3631 * Value: 9 3633 * Description: Group currently not active. 3635 * Reference: [[This document]] 3637 25.14. Expert Review Instructions 3639 The IANA registry established in this document is defined as "Expert 3640 Review". This section gives some general guidelines for what the 3641 experts should be looking for, but they are being designated as 3642 experts for a reason so they should be given substantial latitude. 3644 Expert reviewers should take into consideration the following points: 3646 * Clarity and correctness of registrations. Experts are expected to 3647 check the clarity of purpose and use of the requested entries. 3648 Experts should inspect the entry for the considered role, to 3649 verify the correctness of its description against the role as 3650 intended in the specification that defined it. Expert should 3651 consider requesting an opinion on the correctness of registered 3652 parameters from the Authentication and Authorization for 3653 Constrained Environments (ACE) Working Group and the Constrained 3654 RESTful Environments (CoRE) Working Group. 3656 Entries that do not meet these objective of clarity and 3657 completeness should not be registered. 3659 * Duplicated registration and point squatting should be discouraged. 3660 Reviewers are encouraged to get sufficient information for 3661 registration requests to ensure that the usage is not going to 3662 duplicate one that is already registered and that the point is 3663 likely to be used in deployments. 3665 * Experts should take into account the expected usage of roles when 3666 approving point assignment. Given a 'Value' V as code point, the 3667 length of the encoding of (2^(V+1) - 1) should be weighed against 3668 the usage of the entry, considering the resources and capabilities 3669 of devices it will be used on. Additionally, given a 'Value' V as 3670 code point, the length of the encoding of (2^(V+1) - 1) should be 3671 weighed against how many code points resulting in that encoding 3672 length are left, and the resources and capabilities of devices it 3673 will be used on. 3675 * Specifications are recommended. When specifications are not 3676 provided, the description provided needs to have sufficient 3677 information to verify the points above. 3679 26. References 3681 26.1. Normative References 3683 [COSE.Algorithms] 3684 IANA, "COSE Algorithms", 3685 . 3688 [COSE.Elliptic.Curves] 3689 IANA, "COSE Elliptic Curves", 3690 . 3693 [COSE.Header.Parameters] 3694 IANA, "COSE Header Parameters", 3695 . 3698 [COSE.Key.Types] 3699 IANA, "COSE Key Types", 3700 . 3703 [I-D.ietf-ace-aif] 3704 Bormann, C., "An Authorization Information Format (AIF) 3705 for ACE", Work in Progress, Internet-Draft, draft-ietf- 3706 ace-aif-06, 4 March 2022, 3707 . 3710 [I-D.ietf-ace-dtls-authorize] 3711 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 3712 L. Seitz, "Datagram Transport Layer Security (DTLS) 3713 Profile for Authentication and Authorization for 3714 Constrained Environments (ACE)", Work in Progress, 3715 Internet-Draft, draft-ietf-ace-dtls-authorize-18, 4 June 3716 2021, . 3719 [I-D.ietf-ace-key-groupcomm] 3720 Palombini, F. and M. Tiloca, "Key Provisioning for Group 3721 Communication using ACE", Work in Progress, Internet- 3722 Draft, draft-ietf-ace-key-groupcomm-15, 23 December 2021, 3723 . 3726 [I-D.ietf-ace-oauth-authz] 3727 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 3728 H. Tschofenig, "Authentication and Authorization for 3729 Constrained Environments (ACE) using the OAuth 2.0 3730 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 3731 draft-ietf-ace-oauth-authz-46, 8 November 2021, 3732 . 3735 [I-D.ietf-ace-oscore-profile] 3736 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 3737 "OSCORE Profile of the Authentication and Authorization 3738 for Constrained Environments Framework", Work in Progress, 3739 Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May 3740 2021, . 3743 [I-D.ietf-core-oscore-groupcomm] 3744 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 3745 and J. Park, "Group OSCORE - Secure Group Communication 3746 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 3747 core-oscore-groupcomm-14, 7 March 2022, 3748 . 3751 [I-D.ietf-cose-rfc8152bis-algs] 3752 Schaad, J., "CBOR Object Signing and Encryption (COSE): 3753 Initial Algorithms", Work in Progress, Internet-Draft, 3754 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 3755 . 3758 [I-D.ietf-cose-rfc8152bis-struct] 3759 Schaad, J., "CBOR Object Signing and Encryption (COSE): 3760 Structures and Process", Work in Progress, Internet-Draft, 3761 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 3762 . 3765 [NIST-800-56A] 3766 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 3767 Davis, "Recommendation for Pair-Wise Key-Establishment 3768 Schemes Using Discrete Logarithm Cryptography - NIST 3769 Special Publication 800-56A, Revision 3", April 2018, 3770 . 3773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3774 Requirement Levels", BCP 14, RFC 2119, 3775 DOI 10.17487/RFC2119, March 1997, 3776 . 3778 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 3779 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 3780 March 2010, . 3782 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 3783 Specifications and Registration Procedures", BCP 13, 3784 RFC 6838, DOI 10.17487/RFC6838, January 2013, 3785 . 3787 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 3788 Algorithm (DSA) and Elliptic Curve Digital Signature 3789 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 3790 2013, . 3792 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 3793 Application Protocol (CoAP)", RFC 7252, 3794 DOI 10.17487/RFC7252, June 2014, 3795 . 3797 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 3798 for Security", RFC 7748, DOI 10.17487/RFC7748, January 3799 2016, . 3801 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 3802 "PKCS #1: RSA Cryptography Specifications Version 2.2", 3803 RFC 8017, DOI 10.17487/RFC8017, November 2016, 3804 . 3806 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 3807 Signature Algorithm (EdDSA)", RFC 8032, 3808 DOI 10.17487/RFC8032, January 2017, 3809 . 3811 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3812 Writing an IANA Considerations Section in RFCs", BCP 26, 3813 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3814 . 3816 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3817 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3818 May 2017, . 3820 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3821 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3822 . 3824 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 3825 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 3826 . 3828 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 3829 Definition Language (CDDL): A Notational Convention to 3830 Express Concise Binary Object Representation (CBOR) and 3831 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 3832 June 2019, . 3834 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 3835 "Object Security for Constrained RESTful Environments 3836 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 3837 . 3839 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 3840 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 3841 . 3843 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 3844 Representation (CBOR)", STD 94, RFC 8949, 3845 DOI 10.17487/RFC8949, December 2020, 3846 . 3848 26.2. Informative References 3850 [I-D.ietf-ace-oscore-gm-admin] 3851 Tiloca, M., Höglund, R., Stok, P. V. D., and F. Palombini, 3852 "Admin Interface for the OSCORE Group Manager", Work in 3853 Progress, Internet-Draft, draft-ietf-ace-oscore-gm-admin- 3854 05, 7 March 2022, . 3857 [I-D.ietf-core-coap-pubsub] 3858 Koster, M., Keranen, A., and J. Jimenez, "Publish- 3859 Subscribe Broker for the Constrained Application Protocol 3860 (CoAP)", Work in Progress, Internet-Draft, draft-ietf- 3861 core-coap-pubsub-09, 30 September 2019, 3862 . 3865 [I-D.ietf-core-groupcomm-bis] 3866 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 3867 for the Constrained Application Protocol (CoAP)", Work in 3868 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 3869 06, 7 March 2022, . 3872 [I-D.ietf-cose-cbor-encoded-cert] 3873 Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and 3874 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 3875 Certificates)", Work in Progress, Internet-Draft, draft- 3876 ietf-cose-cbor-encoded-cert-03, 10 January 2022, 3877 . 3880 [I-D.tiloca-core-oscore-discovery] 3881 Tiloca, M., Amsuess, C., and P. V. D. Stok, "Discovery of 3882 OSCORE Groups with the CoRE Resource Directory", Work in 3883 Progress, Internet-Draft, draft-tiloca-core-oscore- 3884 discovery-11, 7 March 2022, 3885 . 3888 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 3889 Key Derivation Function (HKDF)", RFC 5869, 3890 DOI 10.17487/RFC5869, May 2010, 3891 . 3893 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3894 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 3895 January 2012, . 3897 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 3898 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 3899 . 3901 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 3902 RFC 6749, DOI 10.17487/RFC6749, October 2012, 3903 . 3905 [RFC7641] Hartke, K., "Observing Resources in the Constrained 3906 Application Protocol (CoAP)", RFC 7641, 3907 DOI 10.17487/RFC7641, September 2015, 3908 . 3910 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 3911 Security (TLS) / Datagram Transport Layer Security (DTLS) 3912 Profiles for the Internet of Things", RFC 7925, 3913 DOI 10.17487/RFC7925, July 2016, 3914 . 3916 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 3917 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 3918 May 2018, . 3920 Appendix A. Profile Requirements 3922 This section lists how this application profile of ACE addresses the 3923 requirements defined in Appendix A of [I-D.ietf-ace-key-groupcomm]. 3925 A.1. Mandatory-to-Address Requirements 3927 * REQ1 - Specify the format and encoding of 'scope'. This includes 3928 defining the set of possible roles and their identifiers, as well 3929 as the corresponding encoding to use in the scope entries 3930 according to the used scope format: see Section 3 and Section 4.1. 3932 * REQ2 - If the AIF format of 'scope' is used, register its specific 3933 instance of "Toid" and "Tperm" as Media Type parameters and a 3934 corresponding Content-Format, as per the guidelines in 3935 [I-D.ietf-ace-aif]: see Section 25.8 and Section 25.9. 3937 * REQ3 - if used, specify the acceptable values for 'sign_alg': 3938 values from the "Value" column of the "COSE Algorithms" registry 3939 [COSE.Algorithms]. 3941 * REQ4 - If used, specify the acceptable values for 3942 'sign_parameters': format and values from the COSE algorithm 3943 capabilities as specified in the "COSE Algorithms" registry 3944 [COSE.Algorithms]. 3946 * REQ5 - If used, specify the acceptable values for 3947 'sign_key_parameters': format and values from the COSE key type 3948 capabilities as specified in the "COSE Key Types" registry 3949 [COSE.Key.Types]. 3951 * REQ6 - Specify the acceptable formats for authentication 3952 credentials and, if used, the acceptable values for 'pub_key_enc': 3953 acceptable formats explicitly provide the public key as well as 3954 the comprehensive set of information related to the public key 3955 algorithm (see Section 6.1 and Section 6.4). Consistent 3956 acceptable values for 'pub_key_enc' are taken from the "Label" 3957 column of the "COSE Header Parameters" registry 3958 [COSE.Header.Parameters]. 3960 * REQ7 - If the value of the GROUPNAME URI path and the group name 3961 in the Access Token scope (gname in Section 3.1 of 3962 [I-D.ietf-ace-key-groupcomm]) are not required to coincide, 3963 specify the mechanism to map the GROUPNAME value in the URI to the 3964 group name: not applicable, since a perfect matching is required. 3966 * REQ8 - Define whether the KDC has an authentication credential and 3967 if this has to be provided through the 'kdc_cred' parameter, see 3968 Section 4.1 of [I-D.ietf-ace-key-groupcomm]: yes, as required by 3969 the Group OSCORE protocol [I-D.ietf-core-oscore-groupcomm], see 3970 Section 6.4 of this document. 3972 * REQ9 - Specify if any part of the KDC interface as defined in 3973 Section 4.1 of [I-D.ietf-ace-key-groupcomm] is not supported by 3974 the KDC: not applicable. 3976 * REQ10 - Register a Resource Type for the root url-path, which is 3977 used to discover the correct url to access at the KDC (see 3978 Section 4.1 of [I-D.ietf-ace-key-groupcomm]): the Resource Type 3979 (rt=) Link Target Attribute value "core.osc.gm" is registered in 3980 Section 25.11. 3982 * REQ11 - Define what specific actions (e.g., CoAP methods) are 3983 allowed on each resource provided by the KDC interface, depending 3984 on whether the Client is a current group member; the roles that a 3985 Client is authorized to take as per the obtained access token; and 3986 the roles that the Client has as current group member: see 3987 Section 5.4. 3989 * REQ12 - Categorize possible newly defined operations for Clients 3990 into primary operations expected to be minimally supported and 3991 secondary operations, and provide accompanying considerations (see 3992 Section 5.5). 3994 * REQ13 - Specify the encoding of group identifier (see 3995 Section 4.2.1 of [I-D.ietf-ace-key-groupcomm]): CBOR byte string 3996 (see Section 17). 3998 * REQ14 - Specify the approaches used to compute and verify the PoP 3999 evidence to include in 'client_cred_verify', and which of those 4000 approaches is used in which case: see Section 6.2 and Section 6.3. 4002 * REQ15 - Specify how the nonce N_S is generated, if the token is 4003 not provided to the KDC through the Token Transfer Request to the 4004 authz-info endpoint (e.g., if it is used directly to validate TLS 4005 instead): see Section 6.2.1. 4007 * REQ16 - Define the initial value of the 'num' parameter: The 4008 initial value MUST be set to 0 when creating the OSCORE group, 4009 e.g., as in [I-D.ietf-ace-oscore-gm-admin]. 4011 * REQ17 - Specify the format of the 'key' parameter: see 4012 Section 6.4. 4014 * REQ18 - Specify acceptable values of the 'gkty' parameter: 4015 Group_OSCORE_Input_Material object (see Section 6.4). 4017 * REQ19 - Specify and register the application profile identifier: 4018 coap_group_oscore_app (see Section 25.5). 4020 * REQ20 - If used, specify the format and content of 4021 'group_policies' and its entries: see Section 6.4. 4023 * REQ21 - Specify the approaches used to compute and verify the PoP 4024 evidence to include in 'kdc_cred_verify', and which of those 4025 approaches is used in which case: see Section 6.4, Section 6.5 and 4026 Section 12. 4028 * REQ22 - Specify the communication protocol that the members of the 4029 group must use: CoAP [RFC7252], possibly over IP multicast 4030 [I-D.ietf-core-groupcomm-bis]. 4032 * REQ23 - Specify the security protocols that the group members must 4033 use to protect their communication: Group OSCORE 4034 [I-D.ietf-core-oscore-groupcomm]. 4036 * REQ24 - Specify how the communication is secured between the 4037 Client and KDC: by means of any transport profile of ACE 4038 [I-D.ietf-ace-oauth-authz] between Client and Group Manager that 4039 complies with the requirements in Appendix C of 4040 [I-D.ietf-ace-oauth-authz]. 4042 * REQ25 - Specify the format of the identifiers of group members: 4043 the Sender ID used in the OSCORE group (see Section 6.4 and 4044 Section 10). 4046 * REQ26 - Specify policies at the KDC to handle member ids that are 4047 not included in 'get_pub_keys': see Section 10. 4049 * REQ27 - Specify the format of newly-generated individual keying 4050 material for group members, or of the information to derive it, 4051 and corresponding CBOR label: see Section 9. 4053 * REQ28 - Specify and register the identifier of newly defined 4054 semantics for binary scopes: see Section 25.12. 4056 * REQ29 - Categorize newly defined parameters according to the same 4057 criteria of Section 8 of [I-D.ietf-ace-key-groupcomm]: see 4058 Section 21. 4060 * REQ30 - Define whether Clients must, should or may support the 4061 conditional parameters defined in Section 8 of 4062 [I-D.ietf-ace-key-groupcomm], and under which circumstances: see 4063 Section 21. 4065 A.2. Optional-to-Address Requirements 4067 * OPT1 (Optional) - If the textual format of 'scope' is used, 4068 specify CBOR values to use for abbreviating the role identifiers 4069 in the group: not applicable. 4071 * OPT2 (Optional) - Specify additional parameters used in the 4072 exchange of Token Transfer Request and Response: 4074 - 'ecdh_info', to negotiate the ECDH algorithm, ECDH algorithm 4075 parameters, ECDH key parameters and exact format of 4076 authentication credentials used in the group, in case the 4077 joining node supports the pairwise mode of Group OSCORE (see 4078 Section 6.1). 4080 - 'kdc_dh_creds', to ask for and retrieve the Group Manager's 4081 Diffie-Hellman authentication credentials, in case the joining 4082 node supports the pairwise mode of Group OSCORE and the Access 4083 Token authorizes to join parwise-only groups (see Section 6.1). 4085 * OPT3 (Optional) - Specify the negotiation of parameter values for 4086 signature algorithm and signature keys, if 'sign_info' is not 4087 used: possible early discovery by using the approach based on the 4088 CoRE Resource Directory described in 4089 [I-D.tiloca-core-oscore-discovery]. 4091 * OPT4 (Optional) - Specify possible or required payload formats for 4092 specific error cases: send a 4.00 (Bad Request) error response to 4093 a Joining Request (see Section 6.3). 4095 * OPT5 (Optional) - Specify additional identifiers of error types, 4096 as values of the 'error' field in an error response from the KDC: 4097 see Section 25.13. 4099 * OPT6 (Optional) - Specify the encoding of 'pub_keys_repos' if the 4100 default is not used: no. 4102 * OPT7 (Optional) - Specify the functionalities implemented at the 4103 'control_uri' resource hosted at the Client, including message 4104 exchange encoding and other details (see Section 4.3.1 of 4105 [I-D.ietf-ace-key-groupcomm]): see Section 19 for the eviction of 4106 a group member; see Section 20 for the group rekeying process. 4108 * OPT8 (Optional) - Specify the behavior of the handler in case of 4109 failure to retrieve an authentication credential for the specific 4110 node: send a 4.00 (Bad Request) error response to a Joining 4111 Request (see Section 6.3). 4113 * OPT9 (Optional) - Define a default group rekeying scheme, to refer 4114 to in case the 'rekeying_scheme' parameter is not included in the 4115 Joining Response (see Section 4.3.1.1 of 4116 [I-D.ietf-ace-key-groupcomm]): the "Point-to-Point" rekeying 4117 scheme registered in Section 11.14 of 4118 [I-D.ietf-ace-key-groupcomm], whose detailed use for this profile 4119 is defined in Section 20 of this document. 4121 * OPT10 (Optional) - Specify the functionalities implemented at the 4122 'control_group_uri' resource hosted at the Client, including 4123 message exchange encoding and other details (see Section 4.3.1 of 4124 [I-D.ietf-ace-key-groupcomm]): see Section 19 for the eviction of 4125 multiple group members. 4127 * OPT11 (Optional) - Specify policies that instruct clients to 4128 retain unsuccessfully decrypted messages and for how long, so that 4129 they can be decrypted after getting updated keying material: no. 4131 * OPT12 (Optional) - Specify for the KDC to perform group rekeying 4132 (together or instead of renewing individual keying material) when 4133 receiving a Key Renewal Request: the Group Manager SHOULD NOT 4134 perform a group rekeying, unless already scheduled to occur 4135 shortly (see Section 9). 4137 * OPT13 (Optional) - Specify how the identifier of a group members's 4138 authentication credential is included in requests sent to other 4139 group members: no. 4141 * OPT14 (Optional) - Specify additional information to include in 4142 rekeying messages for the "Point-to-Point" group rekeying scheme 4143 (see Section 6.1 of [I-D.ietf-ace-key-groupcomm]): see 4144 Section 20.1. 4146 * OPT15 (Optional) - Specify if Clients must or should support any 4147 of the parameters defined as optional in Section 8 of 4148 [I-D.ietf-ace-key-groupcomm]: no. 4150 Appendix B. Extensibility for Future COSE Algorithms 4152 As defined in Section 8.1 of [I-D.ietf-cose-rfc8152bis-algs], future 4153 algorithms can be registered in the "COSE Algorithms" registry 4154 [COSE.Algorithms] as specifying none or multiple COSE capabilities. 4156 To enable the seamless use of such future registered algorithms, this 4157 section defines a general, agile format for: 4159 * Each 'ecdh_info_entry' of the 'ecdh_info' parameter in the Token 4160 Transfer Response, see Section 6.1 and Section 6.1.1; 4162 * The 'sign_params' and 'ecdh_params' parameters within the 'key' 4163 parameter, see Section 6.4, as part of the response payloads used 4164 in Section 6.4, Section 8.1, Section 8.2 and Section 20. 4166 Appendix B of [I-D.ietf-ace-key-groupcomm] describes the analogous 4167 general format for 'sign_info_entry' of the 'sign_info' parameter in 4168 the Token Transfer Response, see Section 6.1. 4170 If any of the currently registered COSE algorithms is considered, 4171 using this general format yields the same structure defined in this 4172 document for the items above, thus ensuring retro-compatibility. 4174 B.1. Format of 'ecdh_info_entry' 4176 The format of each 'ecdh_info_entry' (see Section 6.1 and 4177 Section 6.1.1) is generalized as follows. Given N the number of 4178 elements of the 'ecdh_parameters' array, i.e., the number of COSE 4179 capabilities of the ECDH algorithm, then: 4181 * 'ecdh_key_parameters' is replaced by N elements 'ecdh_capab_i', 4182 each of which is a CBOR array. 4184 * The i-th array following 'ecdh_parameters', i.e., 'ecdh_capab_i' 4185 (i = 0, ..., N-1), is the array of COSE capabilities for the 4186 algorithm capability specified in 'ecdh_parameters'[i]. 4188 ecdh_info_entry = 4189 [ 4190 id : gname / [ + gname ], 4191 ecdh_alg : int / tstr, 4192 ecdh_parameters : [ alg_capab_1 : any, 4193 alg_capab_2 : any, 4194 ..., 4195 alg_capab_N : any], 4196 ecdh_capab_1 : [ any ], 4197 ecdh_capab_2 : [ any ], 4198 ..., 4199 ecdh_capab_N : [ any ], 4200 cred_fmt = int / null 4201 ] 4203 gname = tstr 4204 Figure 12: 'ecdh_info_entry' with general format 4206 B.2. Format of 'key' 4208 The format of 'key' (see Section 6.4) is generalized as follows. 4210 * The 'sign_params' array includes N+1 elements, whose exact 4211 structure and value depend on the value of the signature algorithm 4212 specified in 'sign_alg'. 4214 - The first element, i.e., 'sign_params'[0], is the array of the 4215 N COSE capabilities for the signature algorithm, as specified 4216 for that algorithm in the "Capabilities" column of the "COSE 4217 Algorithms" registry [COSE.Algorithms] (see Section 8.1 of 4218 [I-D.ietf-cose-rfc8152bis-algs]). 4220 - Each following element 'sign_params'[i], i.e., with index i > 4221 0, is the array of COSE capabilities for the algorithm 4222 capability specified in 'sign_params'[0][i-1]. 4224 For example, if 'sign_params'[0][0] specifies the key type as 4225 capability of the algorithm, then 'sign_params'[1] is the array of 4226 COSE capabilities for the COSE key type associated with the 4227 signature algorithm, as specified for that key type in the 4228 "Capabilities" column of the "COSE Key Types" registry 4229 [COSE.Key.Types] (see Section 8.2 of 4230 [I-D.ietf-cose-rfc8152bis-algs]). 4232 * The 'ecdh_params' array includes M+1 elements, whose exact 4233 structure and value depend on the value of the ECDH algorithm 4234 specified in 'ecdh_alg'. 4236 - The first element, i.e., 'ecdh_params'[0], is the array of the 4237 M COSE capabilities for the ECDH algorithm, as specified for 4238 that algorithm in the "Capabilities" column of the "COSE 4239 Algorithms" registry [COSE.Algorithms] (see Section 8.1 of 4240 [I-D.ietf-cose-rfc8152bis-algs]). 4242 - Each following element 'ecdh_params'[i], i.e., with index i > 4243 0, is the array of COSE capabilities for the algorithm 4244 capability specified in 'ecdh_params'[0][i-1]. 4246 For example, if 'ecdh_params'[0][0] specifies the key type as 4247 capability of the algorithm, then 'ecdh_params'[1] is the array of 4248 COSE capabilities for the COSE key type associated with the ECDH 4249 algorithm, as specified for that key type in the "Capabilities" 4250 column of the "COSE Key Types" registry [COSE.Key.Types] (see 4251 Section 8.2 of [I-D.ietf-cose-rfc8152bis-algs]). 4253 Appendix C. Document Updates 4255 RFC EDITOR: PLEASE REMOVE THIS SECTION. 4257 C.1. Version -12 to -13 4259 * Renamed parameters about authentication credentials. 4261 * It is optional for the Group Manager to reassign Gids by tracking 4262 "Birth Gids". 4264 * Distinction between authentication credentials and public keys. 4266 * Updated IANA considerations related to AIF. 4268 * Updated textual description of registered ACE Scope Semantics 4269 value. 4271 C.2. Version -11 to -12 4273 * Clarified semantics of 'ecdh_info' and 'kdc_dh_creds'. 4275 * Definition of /ace-group/GROUPNAME/kdc-pub-key moved to draft- 4276 ietf-ace-key-groupcomm. 4278 * ace-group/ accessible also to non-members that are not Verifiers. 4280 * Clarified what resources are accessible to Verifiers. 4282 * Revised error handling for the newly defined resources. 4284 * Revised use of CoAP error codes. 4286 * Use of "Token Tranfer Request" and "Token Transfer Response". 4288 * New parameter 'rekeying_scheme'. 4290 * Categorization of new parameters and inherited conditional 4291 parameters. 4293 * Clarifications on what to do in case of enhanced error responses. 4295 * Changed UCCS to CCS. 4297 * Authentication credentials of just joined Clients can be in 4298 rekeying messages. 4300 * Revised names of new IANA registries. 4302 * Clarified meaning of registered CoRE resource type. 4304 * Alignment to new requirements from draft-ietf-ace-key-groupcomm. 4306 * Fixes and editorial improvements. 4308 C.3. Version -10 to -11 4310 * Removed redundancy of key type capabilities, from 'sign_info', 4311 'ecdh_info' and 'key'. 4313 * New resource to retrieve the Group Manager's authentication 4314 credential. 4316 * New resource to retrieve material for Signature Verifiers. 4318 * New parameter 'sign_enc_alg' related to the group mode. 4320 * 'cred_fmt' takes value from the COSE Header Parameters registry. 4322 * Improved alignment of the Joining Response payload with the Group 4323 OSCORE Security Context parameters. 4325 * Recycling Group IDs by tracking "Birth GIDs". 4327 * Error handling in case of non available Sender IDs upon joining. 4329 * Error handling in case EdDSA public keys with invalid Y coordinate 4330 when the pairwise mode of Group OSCORE is supported. 4332 * Generalized proof-of-possession (PoP) for the joining node's 4333 private key; defined Diffie-Hellman based PoP for OSCORE groups 4334 using only the pairwise mode. 4336 * Proof-of-possession of the Group Manager's private key in the 4337 Joining Response. 4339 * Always use 'peer_identifiers' to convey Sender IDs as node 4340 identifiers. 4342 * Stale Sender IDs provided when rekeying the group. 4344 * New resource for late retrieval of stale Sender IDs. 4346 * Added examples of message exchanges. 4348 * Revised default values of group configuration parameters. 4350 * Fixes to IANA registrations. 4352 * General format of parameters related to COSE capabilities, 4353 supporting future registered COSE algorithms (new Appendix). 4355 C.4. Version -09 to -10 4357 * Updated non-recycling policy of Sender IDs. 4359 * Removed policies about Sender Sequence Number synchronization. 4361 * 'control_path' renamed to 'control_uri'. 4363 * Format of 'get_pub_keys' aligned with draft-ietf-ace-key- 4364 groupcomm. 4366 * Additional way to inform of group eviction. 4368 * Registered semantics identifier for extended scope format. 4370 * Extended error handling, with error type specified in some error 4371 responses. 4373 * Renumbered requirements. 4375 C.5. Version -08 to -09 4377 * The url-path "ace-group" is used. 4379 * Added overview of admitted methods on the Group Manager resources. 4381 * Added exchange of parameters relevant for the pairwise mode of 4382 Group OSCORE. 4384 * The signed value for 'client_cred_verify' includes also the scope. 4386 * Renamed the key material object as Group_OSCORE_Input_Material 4387 object. 4389 * Replaced 'clientId' with 'group_SenderId'. 4391 * Added message exchange for Group Names request-response. 4393 * No reassignment of Sender ID and Gid in the same OSCORE group. 4395 * Updates on group rekeying contextual with request of new Sender 4396 ID. 4398 * Signature verifiers can also retrieve Group Names and URIs. 4400 * Removed group policy about supporting Group OSCORE in pairwise 4401 mode. 4403 * Registration of the resource type rt="core.osc.gm". 4405 * Update list of requirements. 4407 * Clarifications and editorial revision. 4409 C.6. Version -07 to -08 4411 * AIF specific data model to express scope entries. 4413 * A set of roles is checked as valid when processing the Joining 4414 Request. 4416 * Updated format of 'get_pub_keys' in the Joining Request. 4418 * Payload format and default values of group policies in the Joining 4419 Response. 4421 * Updated payload format of the FETCH request to retrieve 4422 authentication credentials. 4424 * Default values for group configuration parameters. 4426 * IANA registrations to support the AIF specific data model. 4428 C.7. Version -06 to -07 4430 * Alignments with draft-ietf-core-oscore-groupcomm. 4432 * New format of 'sign_info', using the COSE capabilities. 4434 * New format of Joining Response parameters, using the COSE 4435 capabilities. 4437 * Considerations on group rekeying. 4439 * Editorial revision. 4441 C.8. Version -05 to -06 4443 * Added role of external signature verifier. 4445 * Parameter 'rsnonce' renamed to 'kdcchallenge'. 4447 * Parameter 'kdcchallenge' may be omitted in some cases. 4449 * Clarified difference between group name and OSCORE Gid. 4451 * Removed the role combination ["requester", "monitor"]. 4453 * Admit implicit scope and audience in the Authorization Request. 4455 * New format for the 'sign_info' parameter. 4457 * Scope not mandatory to include in the Joining Request. 4459 * Group policy about supporting Group OSCORE in pairwise mode. 4461 * Possible individual rekeying of a single requesting node combined 4462 with a group rekeying. 4464 * Security considerations on reusage of signature challenges. 4466 * Addressing optional requirement OPT12 from draft-ietf-ace-key- 4467 groupcomm 4469 * Editorial improvements. 4471 C.9. Version -04 to -05 4473 * Nonce N_S also in error responses to the Joining Requests. 4475 * Supporting single Access Token for multiple groups/topics. 4477 * Supporting legal requesters/responders using the 'peer_roles' 4478 parameter. 4480 * Registered and used dedicated label for TLS Exporter. 4482 * Added method for uploading a new authentication credential to the 4483 Group Manager. 4485 * Added resource and method for retrieving the current group status. 4487 * Fixed inconsistency in retrieving group keying material only. 4489 * Clarified retrieval of keying material for monitor-only members. 4491 * Clarification on incrementing version number when rekeying the 4492 group. 4494 * Clarification on what is re-distributed with the group rekeying. 4496 * Security considerations on the size of the nonces used for the 4497 signature challenge. 4499 * Added CBOR values to abbreviate role identifiers in the group. 4501 C.10. Version -03 to -04 4503 * New abstract. 4505 * Moved general content to draft-ietf-ace-key-groupcomm 4507 * Terminology: node name; node resource. 4509 * Creation and pointing at node resource. 4511 * Updated Group Manager API (REST methods and offered services). 4513 * Size of challenges 'cnonce' and 'rsnonce'. 4515 * Value of 'rsnonce' for reused or non-traditionally-posted tokens. 4517 * Removed reference to RFC 7390. 4519 * New requirements from draft-ietf-ace-key-groupcomm 4521 * Editorial improvements. 4523 C.11. Version -02 to -03 4525 * New sections, aligned with the interface of ace-key-groupcomm . 4527 * Exchange of information on the signature algorithm and related 4528 parameters, during the Token POST (Section 4.1). 4530 * Nonce 'rsnonce' from the Group Manager to the Client 4531 (Section 4.1). 4533 * Client PoP signature in the Key Distribution Request upon joining 4534 (Section 4.2). 4536 * Local actions on the Group Manager, upon a new node's joining 4537 (Section 4.2). 4539 * Local actions on the Group Manager, upon a node's leaving 4540 (Section 12). 4542 * IANA registration in ACE Groupcomm Parameters registry. 4544 * More fulfilled profile requirements (Appendix A). 4546 C.12. Version -01 to -02 4548 * Editorial fixes. 4550 * Changed: "listener" to "responder"; "pure listener" to "monitor". 4552 * Changed profile name to "coap_group_oscore_app", to reflect it is 4553 an application profile. 4555 * Added the 'type' parameter for all requests to a Join Resource. 4557 * Added parameters to indicate the encoding of authentication 4558 credentials. 4560 * Challenge-response for proof-of-possession of signature keys 4561 (Section 4). 4563 * Renamed 'key_info' parameter to 'sign_info'; updated its format; 4564 extended to include also parameters of the signature key 4565 (Section 4.1). 4567 * Code 4.00 (Bad request), in responses to joining nodes providing 4568 an invalid authentication credential (Section 4.3). 4570 * Clarifications on provisioning and checking of authentication 4571 credentials (Sections 4 and 6). 4573 * Extended discussion on group rekeying and possible different 4574 approaches (Section 7). 4576 * Extended security considerations: proof-of-possession of signature 4577 keys; collision of OSCORE Group Identifiers (Section 8). 4579 * Registered three entries in the IANA registry "Sequence Number 4580 Synchronization Method" (Section 9). 4582 * Registered one public key encoding in the "ACE Public Key 4583 Encoding" IANA registry (Section 9). 4585 C.13. Version -00 to -01 4587 * Changed name of 'req_aud' to 'audience' in the Authorization 4588 Request (Section 3.1). 4590 * Added negotiation of signature algorithm/parameters between Client 4591 and Group Manager (Section 4). 4593 * Updated format of the Key Distribution Response as a whole 4594 (Section 4.3). 4596 * Added parameter 'cs_params' in the 'key' parameter of the Key 4597 Distribution Response (Section 4.3). 4599 * New IANA registrations in the "ACE Authorization Server Request 4600 Creation Hints" registry, "ACE Groupcomm Key" registry, "OSCORE 4601 Security Context Parameters" registry and "ACE Groupcomm Profile" 4602 registry (Section 9). 4604 Acknowledgments 4606 The authors sincerely thank Christian Amsuess, Santiago Aragon, 4607 Stefan Beck, Carsten Bormann, Martin Gunnarsson, Rikard Hoeglund, 4608 Watson Ladd, Daniel Migault, Jim Schaad, Ludwig Seitz, Goeran 4609 Selander and Peter van der Stok for their comments and feedback. 4611 The work on this document has been partly supported by VINNOVA and 4612 the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home 4613 (Grant agreement 952652); and by the EIT-Digital High Impact 4614 Initiative ACTIVE. 4616 Authors' Addresses 4618 Marco Tiloca 4619 RISE AB 4620 Isafjordsgatan 22 4621 SE-164 29 Stockholm Kista 4622 Sweden 4623 Email: marco.tiloca@ri.se 4625 Jiye Park 4626 Universitaet Duisburg-Essen 4627 Schuetzenbahn 70 4628 45127 Essen 4629 Germany 4630 Email: ji-ye.park@uni-due.de 4632 Francesca Palombini 4633 Ericsson AB 4634 Torshamnsgatan 23 4635 SE-16440 Stockholm Kista 4636 Sweden 4637 Email: francesca.palombini@ericsson.com