idnits 2.17.1 draft-ietf-ace-key-groupcomm-oscore-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 (12 July 2021) is 1009 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 3375, but not defined == Missing Reference: 'Tperm' is mentioned on line 3375, but not defined == Missing Reference: 'EC2' is mentioned on line 2943, but not defined == Missing Reference: 'P-256' is mentioned on line 2935, but not defined == Missing Reference: 'P-384' is mentioned on line 2939, but not defined == Missing Reference: 'P-521' is mentioned on line 2943, but not defined -- Looks like a reference, but probably isn't: '0' on line 4048 == Outdated reference: A later version (-07) exists of draft-ietf-ace-aif-03 == Outdated reference: A later version (-18) exists of draft-ietf-ace-key-groupcomm-13 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-43 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-12 ** 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-03 == Outdated reference: A later version (-13) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-10) exists of draft-ietf-core-groupcomm-bis-04 == Outdated reference: A later version (-09) exists of draft-ietf-cose-cbor-encoded-cert-01 == Outdated reference: A later version (-09) exists of draft-ietf-rats-uccs-00 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-09 -- 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: 13 January 2022 Universitaet Duisburg-Essen 6 F. Palombini 7 Ericsson AB 8 12 July 2021 10 Key Management for OSCORE Groups in ACE 11 draft-ietf-ace-key-groupcomm-oscore-11 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 13 January 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 63 2.1. Overview of the Joining Process . . . . . . . . . . . . . 7 64 2.2. Overview of the Group Rekeying Process . . . . . . . . . 7 65 2.2.1. Stale OSCORE Sender IDs . . . . . . . . . . . . . . . 8 66 3. Format of Scope . . . . . . . . . . . . . . . . . . . . . . . 10 67 4. Joining Node to Authorization Server . . . . . . . . . . . . 11 68 4.1. Authorization Request . . . . . . . . . . . . . . . . . . 12 69 4.2. Authorization Response . . . . . . . . . . . . . . . . . 12 70 5. Interface at the Group Manager . . . . . . . . . . . . . . . 12 71 5.1. ace-group/GROUPNAME/active . . . . . . . . . . . . . . . 13 72 5.1.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 13 73 5.2. ace-group/GROUPNAME/gm-pub-key . . . . . . . . . . . . . 14 74 5.2.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 14 75 5.3. ace-group/GROUPNAME/verif-data . . . . . . . . . . . . . 14 76 5.3.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 14 77 5.4. ace-group/GROUPNAME/stale-sids . . . . . . . . . . . . . 15 78 5.4.1. FETCH Handler . . . . . . . . . . . . . . . . . . . . 15 79 5.5. Admitted Methods . . . . . . . . . . . . . . . . . . . . 16 80 6. Token POST and Group Joining . . . . . . . . . . . . . . . . 17 81 6.1. Token Post . . . . . . . . . . . . . . . . . . . . . . . 18 82 6.1.1. 'ecdh_info' Parameter . . . . . . . . . . . . . . . . 20 83 6.1.2. 'gm_dh_pub_keys' Parameter . . . . . . . . . . . . . 22 84 6.2. Sending the Joining Request . . . . . . . . . . . . . . . 24 85 6.2.1. Value of the N_S Challenge . . . . . . . . . . . . . 25 86 6.3. Receiving the Joining Request . . . . . . . . . . . . . . 26 87 6.4. Sending the Joining Response . . . . . . . . . . . . . . 29 88 6.5. Receiving the Joining Response . . . . . . . . . . . . . 35 89 7. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 36 90 8. Retrieval of Updated Keying Material . . . . . . . . . . . . 38 91 8.1. Retrieval of Group Keying Material . . . . . . . . . . . 38 92 8.2. Retrieval of Group Keying Material and OSCORE Sender 93 ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 94 9. Requesting a Change of Keying Material . . . . . . . . . . . 40 95 10. Retrieval of Public Keys and Roles of Group Members . . . . . 41 96 11. Update of Public Key . . . . . . . . . . . . . . . . . . . . 42 97 12. Retrieval of the Group Manager's Public Key . . . . . . . . . 43 98 13. Retrieval of Signature Verification Data . . . . . . . . . . 45 99 14. Retrieval of Group Policies . . . . . . . . . . . . . . . . . 47 100 15. Retrieval of Keying Material Version . . . . . . . . . . . . 48 101 16. Retrieval of Group Status . . . . . . . . . . . . . . . . . . 48 102 17. Retrieval of Group Names and URIs . . . . . . . . . . . . . . 49 103 18. Request to Leave the Group . . . . . . . . . . . . . . . . . 52 104 19. Removal of a Group Member . . . . . . . . . . . . . . . . . . 52 105 20. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 53 106 20.1. Sending Rekeying Messages . . . . . . . . . . . . . . . 55 107 20.2. Receiving Rekeying Messages . . . . . . . . . . . . . . 57 108 20.3. Missed Rekeying Instances . . . . . . . . . . . . . . . 57 109 20.3.1. Retrieval of Stale Sender IDs . . . . . . . . . . . 60 110 21. Default Values for Group Configuration Parameters . . . . . . 62 111 21.1. Common . . . . . . . . . . . . . . . . . . . . . . . . . 62 112 21.2. Group Mode . . . . . . . . . . . . . . . . . . . . . . . 62 113 21.3. Pairwise Mode . . . . . . . . . . . . . . . . . . . . . 63 114 22. Security Considerations . . . . . . . . . . . . . . . . . . . 64 115 22.1. Management of OSCORE Groups . . . . . . . . . . . . . . 64 116 22.2. Size of Nonces as Proof-of-Possesion Challenge . . . . . 65 117 22.3. Reusage of Nonces for Proof-of-Possession Input . . . . 66 118 23. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 119 23.1. OAuth Parameters Registry . . . . . . . . . . . . . . . 67 120 23.2. OAuth Parameters CBOR Mappings Registry . . . . . . . . 67 121 23.3. ACE Groupcomm Parameters Registry . . . . . . . . . . . 68 122 23.4. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 69 123 23.5. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 70 124 23.6. OSCORE Security Context Parameters Registry . . . . . . 70 125 23.7. TLS Exporter Label Registry . . . . . . . . . . . . . . 72 126 23.8. AIF Registry . . . . . . . . . . . . . . . . . . . . . . 73 127 23.9. Media Type Registrations . . . . . . . . . . . . . . . . 73 128 23.10. CoAP Content-Format Registry . . . . . . . . . . . . . . 74 129 23.11. Group OSCORE Roles Registry . . . . . . . . . . . . . . 74 130 23.12. CoRE Resource Type Registry . . . . . . . . . . . . . . 75 131 23.13. ACE Scope Semantics Registry . . . . . . . . . . . . . . 75 132 23.14. ACE Groupcomm Errors . . . . . . . . . . . . . . . . . . 76 133 23.15. Expert Review Instructions . . . . . . . . . . . . . . . 76 134 24. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 135 24.1. Normative References . . . . . . . . . . . . . . . . . . 77 136 24.2. Informative References . . . . . . . . . . . . . . . . . 81 137 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 83 138 Appendix B. Extensibility for Future COSE Algorithms . . . . . . 86 139 B.1. Format of 'ecdh_info_entry' . . . . . . . . . . . . . . . 87 140 B.2. Format of 'key' . . . . . . . . . . . . . . . . . . . . . 87 141 Appendix C. Document Updates . . . . . . . . . . . . . . . . . . 88 142 C.1. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 88 143 C.2. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 89 144 C.3. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 90 145 C.4. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 90 146 C.5. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 91 147 C.6. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 91 148 C.7. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 92 149 C.8. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 92 150 C.9. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 93 151 C.10. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 93 152 C.11. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 94 153 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 94 154 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 95 156 1. Introduction 158 Object Security for Constrained RESTful Environments (OSCORE) 159 [RFC8613] is a method for application-layer protection of the 160 Constrained Application Protocol (CoAP) [RFC7252], using CBOR Object 161 Signing and Encryption (COSE) 162 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs] and 163 enabling end-to-end security of CoAP payload and options. 165 As described in [I-D.ietf-core-oscore-groupcomm], Group OSCORE is 166 used to protect CoAP group communication over IP multicast 167 [I-D.ietf-core-groupcomm-bis]. This relies on a Group Manager, which 168 is responsible for managing an OSCORE group and enables the group 169 members to exchange CoAP messages secured with Group OSCORE. The 170 Group Manager can be responsible for multiple groups, coordinates the 171 joining process of new group members, and is entrusted with the 172 distribution and renewal of group keying material. 174 This document is an application profile of 175 [I-D.ietf-ace-key-groupcomm], which itself builds on the ACE 176 framework for Authentication and Authorization 177 [I-D.ietf-ace-oauth-authz]. Message exchanges among the participants 178 as well as message formats and processing follow what specified in 179 [I-D.ietf-ace-key-groupcomm] for provisioning and renewing keying 180 material in group communication scenarios, where Group OSCORE is used 181 to protect CoAP group communication over IP multicast. 183 1.1. Terminology 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 187 "OPTIONAL" in this document are to be interpreted as described in BCP 188 14 [RFC2119][RFC8174] when, and only when, they appear in all 189 capitals, as shown here. 191 Readers are expected to be familiar with: 193 * The terms and concepts described in the ACE framework for 194 authentication and authorization [I-D.ietf-ace-oauth-authz] and in 195 the Authorization Information Format (AIF) [I-D.ietf-ace-aif] to 196 express authorization information. The terminology for entities 197 in the considered architecture is defined in OAuth 2.0 [RFC6749]. 198 In particular, this includes Client (C), Resource Server (RS), and 199 Authorization Server (AS). 201 * The terms and concept related to the message formats and 202 processing specified in [I-D.ietf-ace-key-groupcomm], for 203 provisioning and renewing keying material in group communication 204 scenarios. 206 * The terms and concepts described in CBOR [RFC8949] and COSE 207 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs]. 209 * The terms and concepts described in CoAP [RFC7252] and group 210 communication for CoAP [I-D.ietf-core-groupcomm-bis]. Unless 211 otherwise indicated, the term "endpoint" is used here following 212 its OAuth definition, aimed at denoting resources such as /token 213 and /introspect at the AS, and /authz-info at the RS. This 214 document does not use the CoAP definition of "endpoint", which is 215 "An entity participating in the CoAP protocol". 217 * The terms and concepts for protection and processing of CoAP 218 messages through OSCORE [RFC8613] and through Group OSCORE 219 [I-D.ietf-core-oscore-groupcomm] in group communication scenarios. 220 These include the concept of Group Manager, as the entity 221 responsible for a set of groups where communications are secured 222 with Group OSCORE. In this document, the Group Manager acts as 223 Resource Server. 225 Additionally, this document makes use of the following terminology. 227 * Requester: member of an OSCORE group that sends request messages 228 to other members of the group. 230 * Responder: member of an OSCORE group that receives request 231 messages from other members of the group. A responder may reply 232 back, by sending a response message to the requester which has 233 sent the request message. 235 * Monitor: member of an OSCORE group that is configured as responder 236 and never replies back to requesters after receiving request 237 messages. This corresponds to the term "silent server" used in 238 [I-D.ietf-core-oscore-groupcomm]. 240 * Signature verifier: entity external to the OSCORE group and 241 intended to verify the signature of messages exchanged in the 242 group (see Sections 3.1 and 8.5 of 243 [I-D.ietf-core-oscore-groupcomm]). An authorized signature 244 verifier does not join the OSCORE group as an actual member, yet 245 it can retrieve the public keys of the current group members from 246 the Group Manager. 248 * Signature-only group: an OSCORE group that uses only the group 249 mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]). 251 * Pairwise-only group: an OSCORE group that uses only the pairwise 252 mode (see Section 9 of [I-D.ietf-core-oscore-groupcomm]). 254 2. Protocol Overview 256 Group communication for CoAP over IP multicast has been enabled in 257 [I-D.ietf-core-groupcomm-bis] and can be secured with Group Object 258 Security for Constrained RESTful Environments (OSCORE) [RFC8613] as 259 described in [I-D.ietf-core-oscore-groupcomm]. A network node joins 260 an OSCORE group by interacting with the responsible Group Manager. 261 Once registered in the group, the new node can securely exchange 262 messages with other group members. 264 This document describes how to use [I-D.ietf-ace-key-groupcomm] and 265 [I-D.ietf-ace-oauth-authz] to perform a number of authentication, 266 authorization and key distribution actions, as defined in Section 2 267 of [I-D.ietf-ace-key-groupcomm], for an OSCORE group. 269 With reference to [I-D.ietf-ace-key-groupcomm]: 271 * The node wishing to join the OSCORE group, i.e., the joining node, 272 is the Client. 274 * The Group Manager is the Key Distribution Center (KDC), acting as 275 a Resource Server. 277 * The Authorization Server associated to the Group Manager is the 278 AS. 280 All communications between the involved entities MUST be secured. 282 In particular, communications between the Client and the Group 283 Manager leverage protocol-specific transport profiles of ACE to 284 achieve communication security, proof-of-possession and server 285 authentication. It is expected that, in the commonly referred base- 286 case of this document, the transport profile to use is pre-configured 287 and well-known to nodes participating in constrained applications. 289 Appendix A lists the specifications on this application profile of 290 ACE, based on the requirements defined in Appendix A of 291 [I-D.ietf-ace-key-groupcomm]. 293 2.1. Overview of the Joining Process 295 A node performs the steps described in Section 4.3 of 296 [I-D.ietf-ace-key-groupcomm] in order to join an OSCORE group. The 297 format and processing of messages exchanged among the participants 298 are further specified in Section 4 and Section 6 of this document. 300 2.2. Overview of the Group Rekeying Process 302 In a number of cases, the Group Manager has to generate new keying 303 material and distribute it to the group (rekeying), as also discussed 304 in Section 3.2 of [I-D.ietf-core-oscore-groupcomm]. 306 To this end the Group Manager MUST support the Group Rekeying Process 307 described in Section 20 of this document. Future application 308 profiles may define alternative rekeying message formats and group 309 rekeying schemes, which MUST comply with the functional steps defined 310 in Section 3.2 of [I-D.ietf-core-oscore-groupcomm]. 312 Upon generating the new group keying material and before starting its 313 distribution, the Group Manager MUST increment the version number of 314 the group keying material. When rekeying a group, the Group Manager 315 MUST preserve the current value of the OSCORE Sender ID of each 316 member in that group. 318 The data distributed to a group through a rekeying MUST include: 320 * The new version number of the group keying material for the group. 322 * A new Group Identifier (Gid) for the group as introduced in 323 [I-D.ietf-ace-key-groupcomm], used as ID Context parameter of the 324 Group OSCORE Common Security Context of that group (see Section 2 325 of [I-D.ietf-core-oscore-groupcomm]). 327 Note that the Gid differs from the group name also introduced in 328 [I-D.ietf-ace-key-groupcomm], which is a plain, stable and 329 invariant identifier, with no cryptographic relevance and meaning. 331 * A new value for the Master Secret parameter of the Group OSCORE 332 Common Security Context of the group (see Section 2 of 333 [I-D.ietf-core-oscore-groupcomm]). 335 * A set of stale Sender IDs, which allows each rekeyed node to purge 336 public keys and Recipient Contexts used in the group and 337 associated to those Sender IDs. This in turn allows every group 338 member to rely on owned public keys to confidently assert the 339 group membership of other sender nodes, when receiving protected 340 messages in the group (see Section 3.2 of 341 [I-D.ietf-core-oscore-groupcomm]). More details on the 342 maintenance of stale Sender IDs are provided in Section 2.2.1. 344 Also, the data distributed through a group rekeying MAY include a new 345 value for the Master Salt parameter of the Group OSCORE Common 346 Security Context of that group. 348 The Group Manager MUST rekeying the group in the following cases. 350 * The application requires backward security - In this case, the 351 group is rekeyed when a node joins the group as a new member. 352 Therefore, a joining node cannot access communications in the 353 group prior its joining. 355 * One or more nodes leave the group - That is, the group is rekeyed 356 when one or more current members spontaneously request to leave 357 the group (see Section 18), or when the Group Manager forcibly 358 evicts them from the group, e.g., due to expired or revoked 359 authorization (see Section 19). Therefore, a leaving node cannot 360 access communications in the group after its leaving, thus 361 ensuring forward security in the group. 363 Due to the set of stale Sender IDs distributed through the 364 rekeying, this ensures that a node owning the latest group keying 365 material does not store the public keys of former group members 366 (see Sections 3.2 and 10.1 of [I-D.ietf-core-oscore-groupcomm]). 368 * Extension of group lifetime - That is, the group is rekeyed when 369 the expiration time for the group keying material approaches or 370 has passed, if it is appropriate to extend the group operation 371 beyond that. 373 The Group Manager MAY rekey the group for other reasons, e.g., 374 according to an application-dependent rekeying period or scheduling. 376 2.2.1. Stale OSCORE Sender IDs 378 Throughout the lifetime of every group, the Group Manager MUST 379 maintain a collection of stale Sender IDs for that group. 381 The collection associated to a group MUST include up to N > 1 ordered 382 sets of stale OSCORE Sender IDs. It is up to the application to 383 specify the value of N, possibly on a per-group basis. 385 The N-th set includes the Sender IDs that have become "stale" under 386 the current version V of the group keying material. The (N-1)-th set 387 refers to the immediately previous version (V - 1) of the group 388 keying material, and so on. 390 In the following cases, the Group Manager MUST add a new element to 391 the most recent set X, i.e., the set associated to the current 392 version V of the group keying material. 394 * When a current group member obtains a new Sender ID, its old 395 Sender ID is added to X. This happens when the Group Manager 396 assigns a new Sender ID upon request from the group member (see 397 Section 9), or in case the group member re-joins the group (see 398 Section 6.2 and Section 6.4), thus also obtaining a new Sender ID. 400 * When a current group member leaves the group, its current Sender 401 ID is added to X. This happens when a group member requests to 402 leave the group (see Section 18) or is forcibly evicted from the 403 group (see Section 19). 405 The value of N can change throughout the lifetime of the group. If 406 the new value N' is smaller than N, the Group Manager MUST preserve 407 the (up to) N' most recent sets in the collection and MUST delete any 408 possible older set from the collection. 410 Finally, the Group Manager MUST perform the following actions, when 411 the group is rekeyed and the group shifts to the next version V' = (V 412 + 1) of the group keying material. 414 1. The Group Manager rekeys the group. This includes also 415 distributing the set of stale Sender IDs X associated to the old 416 group keying material with version V (see Section 2.2). 418 2. After completing the group rekeying, the Group Manager creates a 419 new empty set X' associated to the new version V' of the newly 420 established group keying material, i.e., V' = (V + 1). 422 3. If the current collection of stale Sender IDs has size N, the 423 Group Manager deletes the oldest set in the collection. 425 4. The Group Manager adds the new set X' to the collection of stale 426 Sender IDs, as the most recent set. 428 3. Format of Scope 430 Building on Section 3.1 of [I-D.ietf-ace-key-groupcomm], this section 431 defines the exact format and encoding of scope to use. 433 To this end, this profile uses the Authorization Information Format 434 (AIF) [I-D.ietf-ace-aif], and defines the following AIF specific data 435 model AIF-OSCORE-GROUPCOMM. 437 With reference to the generic AIF model 439 AIF-Generic = [* [Toid, Tperm]] 441 the value of the CBOR byte string used as scope encodes the CBOR 442 array [* [Toid, Tperm]], where each [Toid, Tperm] element corresponds 443 to one scope entry. 445 Then, for each scope entry: 447 * the object identifier ("Toid") is specialized as a CBOR text 448 string, specifying the group name for the scope entry; 450 * the permission set ("Tperm") is specialized as a CBOR unsigned 451 integer with value R, specifying the role(s) that the client 452 wishes to take in the group (REQ2). The value R is computed as 453 follows: 455 - each role in the permission set is converted into the 456 corresponding numeric identifier X from the "Value" column of 457 the table in Figure 1. 459 - the set of N numbers is converted into the single value R, by 460 taking each numeric identifier X_1, X_2, ..., X_N to the power 461 of two, and then computing the inclusive OR of the binary 462 representations of all the power values. 464 +-----------+-------+-------------------------------------------------+ 465 | Name | Value | Description | 466 +===========+=======+=================================================+ 467 | Reserved | 0 | This value is reserved | 468 |-----------+-------+-------------------------------------------------+ 469 | Requester | 1 | Send requests; receive responses | 470 |-----------+-------+-------------------------------------------------+ 471 | Responder | 2 | Send responses; receive requests | 472 +-----------+-------+-------------------------------------------------+ 473 | Monitor | 3 | Receive requests; never send requests/responses | 474 |-----------+-------+-------------------------------------------------| 475 | Verifier | 4 | Verify signature of intercepted messages | 476 +-----------+-------+-------------------------------------------------+ 478 Figure 1: Numeric identifier of roles in the OSCORE group 480 The CDDL [RFC8610] definition of the AIF-OSCORE-GROUPCOMM data model 481 is as follows: 483 AIF-OSCORE-GROUPCOMM = AIF_Generic 485 path = tstr ; Group name 486 permissions = uint . bits roles 487 roles = &( 488 Requester: 1, 489 Responder: 2, 490 Monitor: 3, 491 Verifier: 4 492 ) 494 Future specifications that define new roles MUST register a 495 corresponding numeric identifier in the "Group OSCORE Roles" Registry 496 defined in Section 23.11 of this document. 498 4. Joining Node to Authorization Server 500 This section describes how the joining node interacts with the AS in 501 order to be authorized to join an OSCORE group under a given Group 502 Manager. In particular, it considers a joining node that intends to 503 contact that Group Manager for the first time. 505 The message exchange between the joining node and the AS consists of 506 the messages Authorization Request and Authorization Response defined 507 in Section 3 of [I-D.ietf-ace-key-groupcomm]. Note that what is 508 defined in [I-D.ietf-ace-key-groupcomm] applies, and only additions 509 or modifications to that specification are defined here. 511 4.1. Authorization Request 513 The Authorization Request message is as defined in Section 3.1 of 514 [I-D.ietf-ace-key-groupcomm], with the following additions. 516 * If the 'scope' parameter is present: 518 - The value of the CBOR byte string encodes a CBOR array, whose 519 format MUST follow the data model AIF-OSCORE-GROUPCOMM defined 520 in Section 3. In particular, for each OSCORE group to join: 522 o The group name is encoded as a CBOR text string. 524 o The set of requested roles is expressed as a single CBOR 525 unsigned integer, computed as defined in Section 3 (REQ2) 526 from the numerical abbreviations defined in Figure 1 for 527 each requested role (OPT7). 529 4.2. Authorization Response 531 The Authorization Response message is as defined in Section 3.2 of 532 [I-D.ietf-ace-key-groupcomm], with the following additions: 534 * The AS MUST include the 'expires_in' parameter. Other means for 535 the AS to specify the lifetime of Access Tokens are out of the 536 scope of this document. 538 * The AS MUST include the 'scope' parameter, when the value included 539 in the Access Token differs from the one specified by the joining 540 node in the request. In such a case, the second element of each 541 scope entry MUST be present, and specifies the set of roles that 542 the joining node is actually authorized to take in the OSCORE 543 group for that scope entry, encoded as specified in Section 4.1. 545 Furthermore, if the AS uses the extended format of scope defined in 546 Section 6 of [I-D.ietf-ace-key-groupcomm] for the 'scope' claim of 547 the Access Token, the first element of the CBOR sequence [RFC8742] 548 MUST be the CBOR integer with value SEM_ID_TBD, defined in 549 Section 23.13 of this document (REQ24). This indicates that the 550 second element of the CBOR sequence, as conveying the actual access 551 control information, follows the scope semantics defined for this 552 application profile in Section 3 of this document. 554 5. Interface at the Group Manager 556 The Group Manager provides the interface defined in Section 4.1 of 557 [I-D.ietf-ace-key-groupcomm], with the additional sub-resources 558 defined from Section 5.1 to Section 5.4 of this document. 560 Furthermore, Section 5.5 provides a summary of the CoAP methods 561 admitted to access different resources at the Group Manager, for 562 nodes with different roles in the group or as non members (REQ8). 564 The GROUPNAME segment of the URI path MUST match with the group name 565 specified in the scope entry of the Access Token scope (i.e., 'gname' 566 in Section 3.1 of [I-D.ietf-ace-key-groupcomm]) (REQ1). 568 The Resource Type (rt=) Link Target Attribute value "core.osc.gm" is 569 registered in Section 23.12 (REQ7), and can be used to describe 570 group-membership resources and its sub-resources at a Group Manager, 571 e.g., by using a link-format document [RFC6690]. 573 Applications can use this common resource type to discover links to 574 group-membership resources for joining OSCORE groups, e.g., by using 575 the approach described in [I-D.tiloca-core-oscore-discovery]. 577 5.1. ace-group/GROUPNAME/active 579 This resource implements a GET handler. 581 5.1.1. GET Handler 583 The handler expects a GET request. 585 The handler verifies that the group name in the /ace-group/GROUPNAME/ 586 active path is a subset of the 'scope' stored in the Access Token 587 associated to the requesting client. 589 The handler also verifies that the roles granted to the requesting 590 client in the group allow it to perform this operation on this 591 resource (REQ8). If either verification fails, the Group Manager 592 MUST respond with a 4.01 (Unauthorized) error message. 594 Additionally, the handler verifies that the requesting client is a 595 current member of the group. If verification fails, the Group 596 Manager MUST respond with a 4.01 (Unauthorized) error message. The 597 response MUST have Content-Format set to application/ace- 598 groupcomm+cbor and is formatted as defined in Section 4 of 599 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be 600 set to 0 ("Operation permitted only to group members"). 602 If the verifications above succeed, the handler returns a 2.05 603 (Content) message, specifying the current status of the group, i.e., 604 active or inactive. The payload of the response is formatted as 605 defined in Section 16. 607 The method to set the current group status is out of the scope of 608 this document, and is defined for the administrator interface of the 609 Group Manager specified in [I-D.ietf-ace-oscore-gm-admin]. 611 5.2. ace-group/GROUPNAME/gm-pub-key 613 This resource implements a GET handler. 615 5.2.1. GET Handler 617 The handler expects a GET request. 619 The handler verifies that the group name in the /ace-group/GROUPNAME/ 620 gm-pub-key path is a subset of the 'scope' stored in the Access Token 621 associated to the requesting client. 623 The handler also verifies that the roles granted to the requesting 624 client allow it to perform this operation on this resource (REQ8). 625 If either verification fails, the Group Manager MUST respond with a 626 4.01 (Unauthorized) error message. 628 If the requesting client is not a current group member and GROUPNAME 629 denotes a pairwise-only group, the Group Manager MUST respond with a 630 4.00 (Bad Request) error message. The response MUST have Content- 631 Format set to application/ace-groupcomm+cbor and is formatted as 632 defined in Section 4 of [I-D.ietf-ace-key-groupcomm]. The value of 633 the 'error' field MUST be set to 7 ("Signatures not used in the 634 group"). 636 If the verifications above succeed, the handler returns a 2.05 637 (Content) message, specifying the Group Manager's public key together 638 with a proof-of-possession evidence. The response MUST have Content- 639 Format set to application/ace-groupcomm+cbor. The payload of the 640 response is a CBOR map, which is formatted as defined in Section 12. 642 5.3. ace-group/GROUPNAME/verif-data 644 This resource implements a GET handler. 646 5.3.1. GET Handler 648 The handler expects a GET request. 650 The handler verifies that the group name in the /ace-group/GROUPNAME/ 651 verif-data path is a subset of the 'scope' stored in the Access Token 652 associated to the requesting client. 654 The handler also verifies that the roles granted to the requesting 655 client allow it to perform this operation on this resource (REQ8). 656 If either verification fails, the Group Manager MUST respond with a 657 4.01 (Unauthorized) error message. 659 If the requesting client is a current group member, the Group Manager 660 MUST respond with a 4.01 (Unauthorized) error message. The response 661 MUST have Content-Format set to application/ace-groupcomm+cbor and is 662 formatted as defined in Section 4 of [I-D.ietf-ace-key-groupcomm]. 663 The value of the 'error' field MUST be set to 8 ("Operation permitted 664 only to signature verifiers"). 666 If GROUPNAME denotes a pairwise-only group, the Group Manager MUST 667 respond with a 4.00 (Bad Request) error message. The response MUST 668 have Content-Format set to application/ace-groupcomm+cbor and is 669 formatted as defined in Section 4 of [I-D.ietf-ace-key-groupcomm]. 670 The value of the 'error' field MUST be set to 7 ("Signatures not used 671 in the group"). 673 If the verifications above succeed, the handler returns a 2.05 674 (Content) message, specifying data that allows also a signature 675 verifier to verify signatures of messages protected with the group 676 mode and sent to the group (see Sections 3.1 and 8.5 of 677 [I-D.ietf-core-oscore-groupcomm]). The response MUST have Content- 678 Format set to application/ace-groupcomm+cbor. The payload of the 679 response is a CBOR map, which is formatted as defined in Section 13. 681 5.4. ace-group/GROUPNAME/stale-sids 683 This resource implements a FETCH handler. 685 5.4.1. FETCH Handler 687 The handler expects a FETCH request, whose payload specifies a 688 version number of the group keying material, encoded as an unsigned 689 CBOR integer. 691 The handler verifies that the group name in the /ace-group/GROUPNAME/ 692 stale-sids path is a subset of the 'scope' stored in the Access Token 693 associated to the requesting client. 695 The handler also verifies that the roles granted to the requesting 696 client allow it to perform this operation on this resource (REQ8). 697 If either verification fails, the Group Manager MUST respond with a 698 4.01 (Unauthorized) error message. 700 Additionally, the handler verifies that the requesting client is a 701 current member of the group. If verification fails, the Group 702 Manager MUST respond with a 4.01 (Unauthorized) error message. The 703 response MUST have Content-Format set to application/ace- 704 groupcomm+cbor and is formatted as defined in Section 4 of 705 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be 706 set to 0 ("Operation permitted only to group members"). 708 If the verifications above succeed, the handler returns a 2.05 709 (Content) message, specifying data that allows the requesting client 710 to delete the Recipient Contexts and public keys associated to former 711 members of the group (see Section 3.2 of 712 [I-D.ietf-core-oscore-groupcomm]. The payload of the response is 713 formatted as defined in Section 20.3.1. 715 5.5. Admitted Methods 717 The table in Figure 2 summarizes the CoAP methods admitted to access 718 different resources at the Group Manager, for (non-)members of a 719 group with group name GROUPNAME, and considering different roles. 720 The last two rows of the table apply to a node with node name 721 NODENAME. 723 +--------------------------------+--------+-------+-------+-------+ 724 | Resource | Type1 | Type2 | Type3 | Type4 | 725 +--------------------------------+--------+-------+-------+-------+ 726 | ace-group/ | F | F | F | - | 727 +--------------------------------+--------+-------+-------+-------+ 728 | ace-group/GROUPNAME/ | G Po | G Po | Po * | Po | 729 +--------------------------------+--------+-------+-------+-------+ 730 | ace-group/GROUPNAME/active | G | G | - | - | 731 +--------------------------------+--------+-------+-------+-------+ 732 | ace-group/GROUPNAME/gm-pub-key | G | G | G | - | 733 +--------------------------------+--------+-------+-------+-------+ 734 | ace-group/GROUPNAME/verif-data | - | - | G | - | 735 +--------------------------------+--------+-------+-------+-------+ 736 | ace-group/GROUPNAME/pub-key | G F | G F | G F | - | 737 +--------------------------------+--------+-------+-------+-------+ 738 | ace-group/GROUPNAME/stale-sids | F | F | - | - | 739 +--------------------------------+--------+-------+-------+-------+ 740 | ace-group/GROUPNAME/policies | G | G | - | - | 741 +--------------------------------+--------+-------+-------+-------+ 742 | ace-group/GROUPNAME/num | G | G | - | - | 743 +--------------------------------+--------+-------+-------+-------+ 744 | ace-group/GROUPNAME/nodes/ | G Pu D | G D | - | - | 745 | NODENAME | | | | | 746 +--------------------------------+--------+-------+-------+-------+ 747 | ace-group/GROUPNAME/nodes/ | Po | - | - | - | 748 | NODENAME/pub-key | | | | | 749 +--------------------------------+--------+-------+-------+-------+ 751 Type1 = Member as Requester and/or Responder | G = GET 752 Type2 = Member as Monitor | F = FETCH 753 Type3 = Non-member (authorized to be Verifier) | Po = POST 754 (*) = cannot join the group as Verifier | Pu = PUT 755 Type4 = Non-member (not authorized to be Verifier) | D = DELETE 757 Figure 2: Admitted CoAP Methods on the Group Manager Resources 759 6. Token POST and Group Joining 761 The rest of this section describes the interactions between the 762 joining node and the Group Manager, i.e., the sending of the Access 763 Token and the Request-Response exchange to join the OSCORE group. 764 The message exchange between the joining node and the Group Manager 765 consists of the messages defined in Sections 3.3 and 4.3 of 766 [I-D.ietf-ace-key-groupcomm]. Note that what is defined in 767 [I-D.ietf-ace-key-groupcomm] applies, and only additions or 768 modifications to that specification are defined here. 770 A signature verifier provides the Group Manager with an Access Token, 771 as described in Section 6.1, just as any another joining node does. 772 However, unlike candidate group members, it does not join any OSCORE 773 group, i.e., it does not perform the joining process defined in 774 Section 6.2. After successfully posting an Access Token, a signature 775 verifier is authorized to perform only the operations specified in 776 Section 10, to retrieve the public keys of group members, and only 777 for the OSCORE groups specified in the validated Access Token. The 778 Group Manager MUST respond with a 4.01 (Unauthorized) error message, 779 in case a signature verifier attempts to access any other endpoint 780 than /ace-group/GROUPNAME/pub-key at the Group Manager. 782 6.1. Token Post 784 The Token post exchange is defined in Section 3.3 of 785 [I-D.ietf-ace-key-groupcomm]. 787 Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the 788 following applies. 790 * The CoAP POST request MAY additionally contain the following 791 parameters, which, if included, MUST have the corresponding 792 values: 794 - 'ecdh_info' defined in Section 6.1.1, encoding the CBOR simple 795 value Null to require information on the ECDH algorithm, the 796 ECDH algorithm parameters, the ECDH key parameters and on the 797 exact encoding of public keys used in the group, in case the 798 joining node supports the pairwise mode of Group OSCORE 799 [I-D.ietf-core-oscore-groupcomm]. 801 - 'gm_dh_pub_keys' defined in Section 6.1.2, encoding the CBOR 802 simple value Null to require the Diffie-Hellman public key of 803 the Group Manager in the group, in case the joining node 804 supports the pairwise mode of Group OSCORE 805 [I-D.ietf-core-oscore-groupcomm]. 807 Alternatively, the joining node may retrieve this information by 808 other means. 810 * The 'kdcchallenge' parameter contains a dedicated nonce N_S 811 generated by the Group Manager. For the N_S value, it is 812 RECOMMENDED to use a 8-byte long random nonce. The joining node 813 can use this nonce in order to prove the possession of its own 814 private key, upon joining the group (see Section 6.2). 816 The 'kdcchallenge' parameter MAY be omitted from the 2.01 817 (Created) response, if the 'scope' of the Access Token specifies 818 only the role "monitor" or only the role "verifier" or both of 819 them, for each and every of the specified groups. 821 * If the 'sign_info' parameter is present in the response, the 822 following applies for each element 'sign_info_entry'. 824 - 'id' MUST NOT refer to OSCORE groups that are pairwise-only 825 groups. 827 - 'sign_alg' takes value from the "Value" column of the "COSE 828 Algorithms" Registry [COSE.Algorithms]. 830 - 'sign_parameters' is a CBOR array. Its format and value are 831 the same of the COSE capabilities array for the algorithm 832 indicated in 'sign_alg', as specified for that algorithm in the 833 "Capabilities" column of the "COSE Algorithms" Registry 834 [COSE.Algorithms] (REQ4). 836 - 'sign_key_parameters' is a CBOR array. Its format and value 837 are the same of the COSE capabilities array for the COSE key 838 type of the keys used with the algorithm indicated in 839 'sign_alg', as specified for that key type in the 840 "Capabilities" column of the "COSE Key Types" Registry 841 [COSE.Key.Types] (REQ5). 843 - 'pub_key_enc' takes value from the "Label" column of the "COSE 844 Header Parameters" Registry [COSE.Header.Parameters] (REQ6). 845 Consistently with Section 2.3 of 846 [I-D.ietf-core-oscore-groupcomm], acceptable values denote an 847 encoding that MUST explicitly provide the full set of 848 information related to the public key algorithm, including, 849 e.g., the used elliptic curve (when applicable). 851 At the time of writing this specification, acceptable public 852 key encodings are CWTs [RFC8392], unprotected CWT claim sets 853 [I-D.ietf-rats-uccs], X.509 certificates [RFC7925] and C509 854 certificates [I-D.ietf-cose-cbor-encoded-cert]. Further 855 encodings may be available in the future, and would be 856 acceptable to use as long as they comply with the criteria 857 defined above. 859 [ As to CWTs and unprotected CWT claim sets, there is a pending 860 registration requested by draft-ietf-lake-edhoc. ] 862 [ As to C509 certificates, there is a pending registration 863 requested by draft-ietf-cose-cbor-encoded-cert. ] 865 This format is consistent with every signature algorithm currently 866 considered in [I-D.ietf-cose-rfc8152bis-algs], i.e., with 867 algorithms that have only the COSE key type as their COSE 868 capability. Appendix B of [I-D.ietf-ace-key-groupcomm] describes 869 how the format of each 'sign_info_entry' can be generalized for 870 possible future registered algorithms having a different set of 871 COSE capabilities. 873 * If 'ecdh_info' is included in the request, the Group Manager MAY 874 include in the response the 'ecdh_info' parameter defined in 875 Section 6.1.1, with the same encoding. Note that the field 'id' 876 takes as value the group name, or array of group names, for which 877 the corresponding 'ecdh_info_entry' applies to. 879 * If 'gm_dh_pub_keys' is included in the request and any of the 880 groups that the client has been authorized to join is a pairwise- 881 only group, then the Group Manager MUST include in the response 882 the 'gm_dh_pub_keys' parameter defined in Section 6.1.2, with the 883 same encoding. Otherwise, the Group Manager MAY include the 884 'gm_dh_pub_keys' parameter. Note that the field 'id' takes as 885 value the group name, or array of group names, for which the 886 corresponding 'gm_dh_pub_keys' applies to. 888 Note that, other than through the above parameters as defined in 889 Section 3.3 of [I-D.ietf-ace-key-groupcomm], the joining node MAY 890 have previously retrieved this information by other means. For 891 example, information conveyed in the 'sign_info' and 'ecdh_info' 892 parameters can be obtained by using the approach described in 893 [I-D.tiloca-core-oscore-discovery], to discover the OSCORE group and 894 the link to the associated group-membership resource at the Group 895 Manager (OPT1). 897 Additionally, if allowed by the used transport profile of ACE, the 898 joining node may instead provide the Access Token to the Group 899 Manager by other means, e.g., during a secure session establishment 900 (see Section 3.3.2 of [I-D.ietf-ace-dtls-authorize]). 902 6.1.1. 'ecdh_info' Parameter 904 The 'ecdh_info' parameter is an OPTIONAL parameter of the Token Post 905 response message defined in Section 5.10.1 of 906 [I-D.ietf-ace-oauth-authz]. 908 This parameter is used to require and retrieve from the Group Manager 909 information and parameters about the ECDH algorithm and about the 910 public keys to be used in the OSCORE group to compute a static-static 911 Diffie-Hellman shared secret [NIST-800-56A], in case the group uses 912 the pairwise mode of Group OSCORE [I-D.ietf-core-oscore-groupcomm]. 914 When used in the request, the 'ecdh_info' parameter encodes the CBOR 915 simple value Null, to require information and parameters on the ECDH 916 algorithm and on the public keys to be used to compute Diffie-Hellman 917 shared secrets in the OSCORE group. 919 The CDDL notation [RFC8610] of the 'ecdh_info' parameter formatted as 920 in the request is given below. 922 ecdh_info_req = nil 924 The 'ecdh_info' parameter of the 2.01 (Created) response is a CBOR 925 array of one or more elements. The number of elements is at most the 926 number of OSCORE groups the client has been authorized to join. 928 Each element contains information about ECDH parameters and about 929 public keys, for one or more OSCORE groups that use the pairwise mode 930 of Group OSCORE and that the client has been authorized to join. 931 Each element is formatted as follows. 933 * The first element 'id' is the group name of the OSCORE group or an 934 array of group names for the OSCORE groups for which the specified 935 information applies. In particular 'id' MUST NOT refer to OSCORE 936 groups that are signature-only groups. 938 * The second element 'ecdh_alg' is a CBOR integer or a CBOR text 939 string indicating the ECDH algorithm used in the OSCORE group 940 identified by 'gname'. Values are taken from the "Value" column 941 of the "COSE Algorithms" Registry [COSE.Algorithms]. 943 * The third element 'ecdh_parameters' is a CBOR array indicating the 944 parameters of the ECDH algorithm used in the OSCORE group 945 identified by 'gname'. Its format and value are the same of the 946 COSE capabilities array for the algorithm indicated in 'ecdh_alg', 947 as specified for that algorithm in the "Capabilities" column of 948 the "COSE Algorithms" Registry [COSE.Algorithms]. 950 * The fourth element 'ecdh_key_parameters' is a CBOR array 951 indicating the parameters of the keys used with the ECDH algorithm 952 in the OSCORE group identified by 'gname'. Its content depends on 953 the value of 'ecdh_alg'. In particular, its format and value are 954 the same of the COSE capabilities array for the COSE key type of 955 the keys used with the algorithm indicated in 'ecdh_alg', as 956 specified for that key type in the "Capabilities" column of the 957 "COSE Key Types" Registry [COSE.Key.Types]. 959 * The fifth element 'pub_key_enc' is a CBOR integer indicating the 960 encoding of public keys used in the OSCORE group identified by 961 'gname'. It takes value from the "Label" column of the "COSE 962 Header Parameters" Registry [COSE.Header.Parameters] (REQ6). 963 Acceptable values denote an encoding that MUST explicitly provide 964 the full set of information related to the public key algorithm, 965 including, e.g., the used elliptic curve (when applicable). The 966 same considerations and guidelines for the 'pub_key_enc' element 967 of 'sign_info' (see Section 6.1) apply. 969 The CDDL notation [RFC8610] of the 'ecdh_info' parameter formatted as 970 in the response is given below. 972 ecdh_info_res = [ + ecdh_info_entry ] 974 ecdh_info_entry = 975 [ 976 id : gname / [ + gname ], 977 ecdh_alg : int / tstr, 978 ecdh_parameters : [ any ], 979 ecdh_key_parameters : [ any ], 980 pub_key_enc = int 981 ] 983 gname = tstr 985 This format is consistent with every ECDH algorithm currently 986 considered in [I-D.ietf-cose-rfc8152bis-algs], i.e., with algorithms 987 that have only the COSE key type as their COSE capability. 988 Appendix B of this document describes how the format of each 989 'ecdh_info_entry' can be generalized for possible future registered 990 algorithms having a different set of COSE capabilities. 992 6.1.2. 'gm_dh_pub_keys' Parameter 994 The 'gm_dh_pub_keys' parameter is an OPTIONAL parameter of the Token 995 Post response message defined in Section 5.10.1 of 996 [I-D.ietf-ace-oauth-authz]. 998 This parameter is used to require and retrieve from the Group Manager 999 its Diffie-Hellman public key used in the OSCORE group. The Group 1000 Manager has specifically a Diffie-Hellman public key if and only if 1001 the OSCORE group is a pairwise-only group. In this case, the early 1002 retrieval of the Group Manager's public key is necessary in order for 1003 the joining node to prove the possession of its own private key, upon 1004 joining the group (see Section 6.2). 1006 When used in the request, the 'gm_dh_pub_keys' parameter encodes the 1007 CBOR simple value Null, to require the Diffie-Hellman public key that 1008 the Group Manager uses in the OSCORE group. 1010 The CDDL notation [RFC8610] of the 'gm_dh_pub_keys' parameter 1011 formatted as in the request is given below. 1013 gm_dh_pub_keys_req = nil 1015 The 'gm_dh_pub_keys' parameter of the 2.01 (Created) response is a 1016 CBOR array of one or more elements. The number of elements is at 1017 most the number of OSCORE groups the client has been authorized to 1018 join. 1020 Each element 'gm_dh_pub_keys_entry' contains information about the 1021 Group Manager's Diffie-Hellman public keys, for one or more OSCORE 1022 groups that are pairwise-only groups and that the client has been 1023 authorized to join. Each element is formatted as follows. 1025 * The first element 'id' is the group name of the OSCORE group or an 1026 array of group names for the OSCORE groups for which the specified 1027 information applies. In particular 'id' MUST refer exclusively to 1028 OSCORE groups that are pairwise-only groups. 1030 * The second element 'pub_key_enc' is a CBOR integer indicating the 1031 encoding of public keys used in the OSCORE group identified by 1032 'gname'. It takes value from the "Label" column of the "COSE 1033 Header Parameters" Registry [COSE.Header.Parameters] (REQ6). 1034 Acceptable values denote an encoding that MUST explicitly provide 1035 the full set of information related to the public key algorithm, 1036 including, e.g., the used elliptic curve (when applicable). The 1037 same considerations and guidelines for the 'pub_key_enc' element 1038 of 'sign_info' (see Section 6.1) apply. 1040 * The third element 'pub_key' is a CBOR byte string, which encodes 1041 the Group Manager's Diffie-Hellman public key in its original 1042 binary representation made available to other endpoints in the 1043 group. In particular, the original binary representation complies 1044 with the encoding specified by the 'pub_key_enc' parameter. Note 1045 that the public key provides the full set of information related 1046 to its public key algorithm, i.e., the ECDH algorithm used in the 1047 OSCORE group as pairwise key agreement algorithm. 1049 The CDDL notation [RFC8610] of the 'gm_dh_pub_keys' parameter 1050 formatted as in the response is given below. 1052 gm_dh_pub_keys_res = [ + gm_dh_pub_keys_entry ] 1054 gm_dh_pub_keys_entry = 1055 [ 1056 id : gname / [ + gname ], 1057 pub_key_enc = int, 1058 pub_key = bstr 1059 ] 1061 gname = tstr 1063 6.2. Sending the Joining Request 1065 The joining node requests to join the OSCORE group by sending a 1066 Joining Request message to the related group-membership resource at 1067 the Group Manager, as per Section 4.3 of 1068 [I-D.ietf-ace-key-groupcomm]. 1070 Additionally to what defined in Section 4.1.2.1 of 1071 [I-D.ietf-ace-key-groupcomm], the following applies. 1073 * The 'scope' parameter MUST be included. Its value encodes one 1074 scope entry with the format defined in Section 3, indicating the 1075 group name and the role(s) that the joining node wants to take in 1076 the group. 1078 * The 'get_pub_keys' parameter is present only if the joining node 1079 wants to retrieve the public keys of the group members from the 1080 Group Manager during the joining process (see Section 7). 1081 Otherwise, this parameter MUST NOT be present. 1083 If this parameter is present and its value is non-null, each 1084 element of the inner CBOR array 'role_filter' is encoded as a CBOR 1085 unsigned integer, with the same value of a permission set 1086 ("Tperm") indicating that role or combination of roles in a scope 1087 entry, as defined in Section 3. 1089 * 'cnonce' contains a dedicated nonce N_C generated by the joining 1090 node. For the N_C value, it is RECOMMENDED to use a 8-byte long 1091 random nonce. 1093 * The proof-of-possession (PoP) evidence included in 1094 'client_cred_verify' is computed as defined below (REQ20). In 1095 either case, the N_S used to build the PoP input is as defined in 1096 Section 6.2.1. 1098 - If the group is not a pairwise-only group, the PoP evidence 1099 MUST be a signature. The joining node computes the signature 1100 by using the same private key and signature algorithm it 1101 intends to use for signing messages in the OSCORE group. 1103 - If the group is a pairwise-only group, the PoP evidence MUST be 1104 a MAC computed as follows, by using the HKDF Algorithm HKDF 1105 SHA-256, which consists of composing the HKDF-Extract and HKDF- 1106 Expand steps [RFC5869]. 1108 MAC = HKDF(salt, IKM, info, L) 1110 The input parameters of HKDF are as follows. 1112 o salt takes as value the empty byte string. 1114 o IKM is computed as a cofactor Diffie-Hellman shared secret, 1115 see Section 5.7.1.2 of [NIST-800-56A], using the ECDH 1116 algorithm used in the OSCORE group. The joining node uses 1117 its own Diffie-Hellman private key and the Diffie-Hellman 1118 public key of the Group Manager. For X25519 and X448, the 1119 procedure is described in Section 5 of [RFC7748]. 1121 o info takes as value the PoP input. 1123 o L is equal to 8, i.e., the size of the MAC, in bytes. 1125 6.2.1. Value of the N_S Challenge 1127 The value of the N_S challenge is determined as follows. 1129 1. If the joining node has posted the Access Token to the /authz- 1130 info endpoint of the Group Manager as in Section 6.1, N_S takes 1131 the same value of the most recent 'kdcchallenge' parameter 1132 received by the joining node from the Group Manager. This can be 1133 either the one specified in the 2.01 (Created) response to the 1134 Token POST, or the one possibly specified in a 4.00 (Bad Request) 1135 response to a following Joining Request (see Section 6.3). 1137 2. If the Token posting has relied on the DTLS profile of ACE 1138 [I-D.ietf-ace-dtls-authorize] with the Access Token as content of 1139 the "psk_identity" field of the ClientKeyExchange message 1140 [RFC6347], N_S is an exporter value computed as defined in 1141 Section 7.5 of [RFC8446]. Specifically, N_S is exported from the 1142 DTLS session between the joining node and the Group Manager, 1143 using an empty 'context_value', 32 bytes as 'key_length', and the 1144 exporter label "EXPORTER-ACE-Sign-Challenge-coap-group-oscore- 1145 app" defined in Section 23.7 of this document. 1147 It is up to applications to define how N_S is computed in further 1148 alternative settings. 1150 Section 22.3 provides security considerations on the reusage of the 1151 N_S challenge. 1153 6.3. Receiving the Joining Request 1155 The Group Manager processes the Joining Request as defined in 1156 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm]. Additionally, the 1157 following applies. 1159 * The Group Manager MUST return a 5.03 (Service Unavailable) 1160 response in case the OSCORE group that the joining node has been 1161 trying to join is currently inactive (see Section 5.1). The 1162 response MUST have Content-Format set to application/ace- 1163 groupcomm+cbor and is formatted as defined in Section 4 of 1164 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST 1165 be set to 9 ("Group currently not active"). 1167 * In case the joining node is not going to join the group 1168 exclusively as monitor, the Group Manager MUST return a 5.03 1169 (Service Unavailable) response if there are currently no OSCORE 1170 Sender IDs available to assign in the OSCORE group. The response 1171 MUST have Content-Format set to application/ace-groupcomm+cbor and 1172 is formatted as defined in Section 4 of 1173 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST 1174 be set to 4 ("No available node identifiers"). 1176 * In case the joining node is not going to join the group 1177 exclusively as monitor and the Joining Request does not include 1178 the 'client_cred' parameter, the joining process fails if the 1179 Group Manager either: i) does not store a public key with an 1180 accepted format for the joining node; or ii) stores multiple 1181 public keys with an accepted format for the joining node. 1183 * In order to verify the PoP evidence contained in 1184 'client_cred_verify', the Group Manager proceeds as follows. 1186 - As PoP input, the Group Manager uses the value of the 'scope' 1187 parameter from the Joining Request as a CBOR byte string, 1188 concatenated with N_S encoded as a CBOR byte string, 1189 concatenated with N_C encoded as a CBOR byte string. In 1190 particular, N_S is determined as described in Section 6.2.1, 1191 while N_C is the nonce provided in the 'cnonce' parameter of 1192 the Joining Request; 1194 - As public key of the joining node, the Group Manager uses 1195 either the one retrieved from the 'client_cred' parameter of 1196 the Joining Request, or the one already stored as acquired from 1197 previous interactions with the joining node. 1199 - The Group Manager verifies the PoP evidence as defined below. 1201 o If the group is not a pairwise-only group, the PoP evidence 1202 is a signature. The Group Manager verifies it by using the 1203 public key of the joining node, as well as the signature 1204 algorithm used in the OSCORE group and possible 1205 corresponding parameters. 1207 o If the group is a pairwise-only group, the PoP evidence is a 1208 MAC. The Group Manager recomputes the MAC through the same 1209 process taken by the joining node when preparing the value 1210 of the 'client_cred_verify' parameter for the Joining 1211 Request (see Section 6.2), with the difference that the 1212 Group Manager uses its own Diffie-Hellman private key and 1213 the Diffie-Hellman public key of the joining node. The 1214 verification succeeds if and only if the recomputed MAC is 1215 equal to the MAC conveyed as PoP evidence in the Joining 1216 Request. 1218 * A 4.00 (Bad Request) response from the Group Manager to the 1219 joining node MUST have content format application/ace- 1220 groupcomm+cbor. The response payload is a CBOR map formatted as 1221 follows. 1223 - If the group uses (also) the group mode of Group OSCORE, the 1224 CBOR map MUST contain the 'sign_info' parameter, whose CBOR 1225 label is defined in Section 7 of [I-D.ietf-ace-key-groupcomm]. 1226 This parameter has the same format of 'sign_info_res' defined 1227 in Section 3.3.1 of [I-D.ietf-ace-key-groupcomm]. In 1228 particular, it includes a single element 'sign_info_entry' 1229 pertaining to the OSCORE group that the joining node has tried 1230 to join with the Joining Request. 1232 - If the group uses (also) the pairwise mode of Group OSCORE, the 1233 CBOR map MUST contain the 'ecdh_info' parameter, whose CBOR 1234 label is defined in Section 23.3. This parameter has the same 1235 format of 'ecdh_info_res' defined in Section 6.1.1. In 1236 particular, it includes a single element 'ecdh_info_entry' 1237 pertaining to the OSCORE group that the joining node has tried 1238 to join with the Joining Request. 1240 - If the group is a pairwise-only group, the CBOR map MUST 1241 contain the 'gm_dh_pub_keys' parameter, whose CBOR label is 1242 defined in Section 23.3. This parameter has the same format of 1243 'gm_dh_pub_keys_res' defined in Section 6.1.2. In particular, 1244 it includes a single element 'gm_dh_pub_keys_entry' pertaining 1245 to the OSCORE group that the joining node has tried to join 1246 with the Joining Request. 1248 - The CBOR map MAY include the 'kdcchallenge' parameter, whose 1249 CBOR label is defined in Section 7 of 1250 [I-D.ietf-ace-key-groupcomm]. If present, this parameter is a 1251 CBOR byte string, which encodes a newly generated 1252 'kdcchallenge' value that the Client can use when preparing a 1253 Joining Request (see Section 6.2). In such a case the Group 1254 Manager MUST store the newly generated value as the 1255 'kdcchallenge' value associated to the joining node, possibly 1256 replacing the currently stored value. 1258 * The Group Manager MUST return a 4.00 (Bad Request) response in 1259 case the 'scope' parameter is not present in the Joining Request, 1260 or if it is present and specifies any set of roles not included in 1261 the following list: "requester", "responder", "monitor", 1262 ("requester", "responder"). Future specifications that define a 1263 new role MUST define possible sets of roles including the new one 1264 and existing ones, that are acceptable to specify in the 'scope' 1265 parameter of a Joining Request. 1267 * The Group Manager MUST return a 4.00 (Bad Request) response in 1268 case the Joining Request includes the 'client_cred' parameter but 1269 does not include both the 'cnonce' and 'client_cred_verify' 1270 parameters. 1272 * The Group Manager MUST return a 4.00 (Bad Request) response in 1273 case an eligible public key for the joining node is neither 1274 present in the 'client_cred' parameter nor already stored. 1276 * The Group Manager MAY return a 4.00 (Bad Request) response in case 1277 all the following conditions hold. 1279 - The OSCORE group uses the pairwise mode of Group OSCORE. 1281 - The OSCORE group uses EdDSA public keys [RFC8032]. 1283 - The public key of the joining node from the 'client_cred' 1284 parameter: 1286 o Is for the elliptic curve Ed25519 and has its Y coordinate 1287 equal to -1 or 1 (mod p), with p = (2^255 - 19), see 1288 Section 4.1 of [RFC7748]; or 1290 o Is for the elliptic curve Ed448 and has its Y coordinate 1291 equal to -1 or 1 (mod p), with p = (2^448 - 2^224 - 1), see 1292 Section 4.2 of [RFC7748]. 1294 This prevents the acceptance of Ed25519 and Ed448 public keys that 1295 cannot be successfully converted to Montgomery coordinates, and 1296 thus cannot be used for the derivation of pairwise keys (see 1297 Section 2.3.1 of [I-D.ietf-core-oscore-groupcomm]). 1299 * When receiving a 4.00 (Bad Request) response, the joining node 1300 SHOULD send a new Joining Request to the Group Manager, where: 1302 - The 'cnonce' parameter MUST include a new dedicated nonce N_C 1303 generated by the joining node. 1305 - The 'client_cred' parameter MUST include a public key 1306 compatible with the encoding, signature or ECDH algorithm, and 1307 possible associated parameters indicated by the Group Manager. 1309 - The 'client_cred_verify' parameter MUST include a PoP evidence 1310 computed as described in Section 6.2, by using the public key 1311 indicated in the current 'client_cred' parameter, with the 1312 signature or ECDH algorithm, and possible associated parameters 1313 indicated by the Group Manager. If the error response from the 1314 Group Manager includes the 'kdcchallenge' parameter, the 1315 joining node MUST use its content as new N_S challenge to 1316 compute the PoP evidence. 1318 6.4. Sending the Joining Response 1320 If the processing of the Joining Request described in Section 6.3 is 1321 successful, the Group Manager updates the group membership by 1322 registering the joining node NODENAME as a new member of the OSCORE 1323 group GROUPNAME, as described in Section 4.1.2.1 of 1324 [I-D.ietf-ace-key-groupcomm]. 1326 If the joining node has not taken exclusively the role of monitor, 1327 the Group Manager performs also the following actions. 1329 * The Group Manager selects an available OSCORE Sender ID in the 1330 OSCORE group, and exclusively assigns it to the joining node. The 1331 Group Manager MUST NOT assign an OSCORE Sender ID to the joining 1332 node if this joins the group exclusively with the role of monitor, 1333 according to what specified in the Access Token (see Section 4.2). 1335 Consistently with Section 3.1 of [I-D.ietf-core-oscore-groupcomm], 1336 the Group Manager MUST assign an OSCORE Sender ID that has not 1337 been used in the OSCORE group since the latest time when the 1338 current Gid value was assigned to the group. 1340 If the joining node is recognized as a current group member, e.g., 1341 through the ongoing secure communication association, the 1342 following also applies. 1344 - The Group Manager MUST assign a new OSCORE Sender ID different 1345 than the one currently used by the joining node in the OSCORE 1346 group. 1348 - The Group Manager MUST add the old, relinquished OSCORE Sender 1349 ID of the joining node to the most recent set of stale Sender 1350 IDs, in the collection associated to the group (see 1351 Section 2.2.1). 1353 * The Group Manager stores the association between i) the public key 1354 of the joining node; and ii) the Group Identifier (Gid), i.e., the 1355 OSCORE ID Context, associated to the OSCORE group together with 1356 the OSCORE Sender ID assigned to the joining node in the group. 1357 The Group Manager MUST keep this association updated over time. 1359 Then, the Group Manager replies to the joining node, providing the 1360 updated security parameters and keying meterial necessary to 1361 participate in the group communication. This success Joining 1362 Response is formatted as defined in Section 4.1.2.1 of 1363 [I-D.ietf-ace-key-groupcomm], with the following additions: 1365 * The 'gkty' parameter identifies a key of type 1366 "Group_OSCORE_Input_Material object", defined in Section 23.4 of 1367 this document. 1369 * The 'key' parameter includes what the joining node needs in order 1370 to set up the Group OSCORE Security Context as per Section 2 of 1371 [I-D.ietf-core-oscore-groupcomm]. 1373 This parameter has as value a Group_OSCORE_Input_Material object, 1374 which is defined in this document and extends the 1375 OSCORE_Input_Material object encoded in CBOR as defined in 1376 Section 3.2.1 of [I-D.ietf-ace-oscore-profile]. In particular, it 1377 contains the additional parameters 'group_senderId', 1378 'pub_key_enc', 'sign_enc_alg', 'sign_alg', 'sign_params', 1379 'ecdh_alg' and 'ecdh_params' defined in Section 23.6 of this 1380 document. 1382 More specifically, the 'key' parameter is composed as follows. 1384 - The 'hkdf' parameter, if present, has as value the HKDF 1385 Algorithm used in the OSCORE group. This parameter MAY be 1386 omitted, if the HKDF Algorithm used in the group is HKDF SHA- 1387 256. Otherwise, this parameter MUST be present. 1389 - The 'salt' parameter, if present, has as value the OSCORE 1390 Master Salt used in the OSCORE group. This parameter MAY be 1391 omitted, if the Master Salt used in the group is the empty byte 1392 string. Otherwise, this parameter MUST be present. 1394 - The 'ms' parameter includes the OSCORE Master Secret value used 1395 in the OSCORE group. This parameter MUST be present. 1397 - The 'contextId' parameter MUST be present and has as value the 1398 Group Identifier (Gid), i.e., the OSCORE ID Context of the 1399 OSCORE group. This parameter MUST be present. 1401 - The 'group_senderId' parameter, if present, has as value the 1402 OSCORE Sender ID assigned to the joining node by the Group 1403 Manager, as described above. This parameter MUST NOT be 1404 present if the node joins the OSCORE group exclusively with the 1405 role of monitor, according to what specified in the Access 1406 Token (see Section 4.2). In any other case, this parameter 1407 MUST be present. 1409 - The 'pub_key_enc' parameter MUST be present and specifies the 1410 encoding of public keys used in the OSCORE group. It takes 1411 value from the "Label" column of the "COSE Header Parameters" 1412 Registry [COSE.Header.Parameters] (REQ6). Consistently with 1413 Section 2.3 of [I-D.ietf-core-oscore-groupcomm], acceptable 1414 values denote an encoding that MUST explicitly provide the full 1415 set of information related to the public key algorithm, 1416 including, e.g., the used elliptic curve (when applicable). 1418 At the time of writing this specification, acceptable public 1419 key encodings are CWTs [RFC8392], unprotected CWT claim sets 1420 [I-D.ietf-rats-uccs], X.509 certificates [RFC7925] and C509 1421 certificates [I-D.ietf-cose-cbor-encoded-cert]. Further 1422 encodings may be available in the future, and would be 1423 acceptable to use as long as they comply with the criteria 1424 defined above. 1426 [ As to CWTs and unprotected CWT claim sets, there is a pending 1427 registration requested by draft-ietf-lake-edhoc. ] 1429 [ As to C509 certificates, there is a pending registration 1430 requested by draft-ietf-cose-cbor-encoded-cert. ] 1432 - The 'sign_enc_alg' parameter MUST NOT be present if the OSCORE 1433 group is a pairwise-only group. Otherwise, it MUST be present 1434 and specifies the Signature Encryption Algorithm used in the 1435 OSCORE group to encrypt messages protected with the group mode. 1436 This parameter takes values from the "Value" column of the 1437 "COSE Algorithms" Registry [COSE.Algorithms]. 1439 - The 'sign_alg' parameter MUST NOT be present if the OSCORE 1440 group is a pairwise-only group. Otherwise, it MUST be present 1441 and specifies the Signature Algorithm used to sign messages in 1442 the OSCORE group. This parameter takes values from the "Value" 1443 column of the "COSE Algorithms" Registry [COSE.Algorithms]. 1445 - The 'sign_params' parameter MUST NOT be present if the OSCORE 1446 group is a pairwise-only group. Otherwise, it MUST be present 1447 and specifies the parameters of the Signature Algorithm. This 1448 parameter is a CBOR array, which includes the following two 1449 elements: 1451 o 'sign_alg_capab': a CBOR array, with the same format and 1452 value of the COSE capabilities array for the Signature 1453 Algorithm indicated in 'sign_alg', as specified for that 1454 algorithm in the "Capabilities" column of the "COSE 1455 Algorithms" Registry [COSE.Algorithms]. 1457 o 'sign_key_type_capab': a CBOR array, with the same format 1458 and value of the COSE capabilities array for the COSE key 1459 type of the keys used with the Signature Algorithm indicated 1460 in 'sign_alg', as specified for that key type in the 1461 "Capabilities" column of the "COSE Key Types" Registry 1462 [COSE.Key.Types]. 1464 - The 'alg' parameter MUST NOT be present if the OSCORE group is 1465 a signature-only group. Otherwise, it MUST be present and 1466 specifies the AEAD Algorithm used in the OSCORE group to 1467 encrypt messages protected with the pairwise mode. 1469 - The 'ecdh_alg' parameter MUST NOT be present if the OSCORE 1470 group is a signature-only group. Otherwise, it MUST be present 1471 and specifies the Pairwise Key Agreement Algorithm used in the 1472 OSCORE group. This parameter takes values from the "Value" 1473 column of the "COSE Algorithms" Registry [COSE.Algorithms]. 1475 - The 'ecdh_params' parameter MUST NOT be present if the OSCORE 1476 group is a signature-only group. Otherwise, it MUST be present 1477 and specifies the parameters of the Pairwise Key Agreement 1478 Algorithm. This parameter is a CBOR array, which includes the 1479 following two elements: 1481 o 'ecdh_alg_capab': a CBOR array, with the same format and 1482 value of the COSE capabilities array for the algorithm 1483 indicated in 'ecdh_alg', as specified for that algorithm in 1484 the "Capabilities" column of the "COSE Algorithms" Registry 1485 [COSE.Algorithms]. 1487 o 'ecdh_key_type_capab': a CBOR array, with the same format 1488 and value of the COSE capabilities array for the COSE key 1489 type of the keys used with the algorithm indicated in 1490 'ecdh_alg', as specified for that key type in the 1491 "Capabilities" column of the "COSE Key Types" Registry 1492 [COSE.Key.Types]. 1494 The format of 'key' defined above is consistent with every 1495 signature algorithm and ECDH algorithm currently considered in 1496 [I-D.ietf-cose-rfc8152bis-algs], i.e., with algorithms that have 1497 only the COSE key type as their COSE capability. Appendix B of 1498 this document describes how the format of the 'key' parameter can 1499 be generalized for possible future registered algorithms having a 1500 different set of COSE capabilities. 1502 * The 'exp' parameter MUST be present. 1504 * The 'ace-groupcomm-profile' parameter MUST be present and has 1505 value coap_group_oscore_app (PROFILE_TBD), which is defined in 1506 Section 23.5 of this document. 1508 * The 'pub_keys' parameter, if present, includes the public keys 1509 requested by the joining node by means of the 'get_pub_keys' 1510 parameter in the Joining Request. 1512 If the joining node has asked for the public keys of all the group 1513 members, i.e., 'get_pub_keys' had value Null in the Joining 1514 Request, then the Group Manager provides only the public keys of 1515 the group members that are relevant to the joining node. That is, 1516 in such a case, 'pub_keys' includes only: i) the public keys of 1517 the responders currently in the OSCORE group, in case the joining 1518 node is configured (also) as requester; and ii) the public keys of 1519 the requesters currently in the OSCORE group, in case the joining 1520 node is configured (also) as responder or monitor. 1522 * The 'peer_identifiers' parameter includes the OSCORE Sender ID of 1523 each group member whose public key is specified in the 'pub_keys' 1524 parameter. That is, a group member's Sender ID is used as 1525 identifier for that group member (REQ12). 1527 * The 'group_policies' parameter SHOULD be present, and SHOULD 1528 include the following elements: 1530 - "Key Update Check Interval" defined in Section 4.1.2.1 of 1531 [I-D.ietf-ace-key-groupcomm], with default value 3600; 1533 - "Expiration Delta" defined in Section 4.1.2.1 of 1534 [I-D.ietf-ace-key-groupcomm], with default value 0. 1536 Furthermore, the CBOR map in the payload of the Joining Response MUST 1537 also include the following new parameters, defined in Section 23.3 of 1538 this document. 1540 * The 'kdc_nonce' parameter, which is a CBOR byte string encoding a 1541 dedicated nonce N_KDC generated by the Group Manager. For N_KDC, 1542 it is RECOMMENDED to use a 8-byte long random nonce. 1544 * The 'kdc_cred' parameter, which is a CBOR byte string encoding the 1545 Group Manager's public key in its original binary representation. 1546 The Group Manager's public key MUST be compatible with the 1547 encoding, signature or ECDH algorithm, and possible associated 1548 parameters used in the OSCORE group. 1550 * The 'kdc_cred_verify' parameter, which is a CBOR byte string 1551 encoding a proof-of-possession (PoP) evidence computed by the 1552 Group Manager. The PoP evidence is computed over the nonce N_KDC, 1553 which is specified in the 'kdc_nonce' parameter and taken as PoP 1554 input. The PoP evidence is computed as defined below. 1556 - If the group is not a pairwise-only group, the PoP evidence 1557 MUST be a signature. The Group Manager computes the signature 1558 by using the signature algorithm used in the OSCORE group, as 1559 well as its own private key associated to the public key 1560 specified in the 'kdc_cred' parameter. 1562 - If the group is a pairwise-only group, the PoP evidence MUST be 1563 a MAC computed as follows, by using the HKDF Algorithm HKDF 1564 SHA-256, which consists of composing the HKDF-Extract and HKDF- 1565 Expand steps [RFC5869]. 1567 MAC = HKDF(salt, IKM, info, L) 1569 The input parameters of HKDF are as follows. 1571 o salt takes as value the empty byte string. 1573 o IKM is computed as a cofactor Diffie-Hellman shared secret, 1574 see Section 5.7.1.2 of [NIST-800-56A], using the ECDH 1575 algorithm used in the OSCORE group. The Group Manager uses 1576 its own Diffie-Hellman private key and the Diffie-Hellman 1577 public key of the joining node. For X25519 and X448, the 1578 procedure is described in Section 5 of [RFC7748]. 1580 o info takes as value the PoP input. 1582 o L is equal to 8, i.e., the size of the MAC, in bytes. 1584 As a last action, the Group Manager MUST store the Gid specified in 1585 the 'contextId' parameter of the 'key' parameter, as the Birth Gid of 1586 the joining node in the joined group (see Section 3.1 of 1587 [I-D.ietf-core-oscore-groupcomm]). This applies also in case the 1588 node is in fact re-joining the group; in such a case, the newly 1589 determined Birth Gid overwrites the one currently stored. 1591 6.5. Receiving the Joining Response 1593 Upon receiving the Joining Response, the joining node retrieves the 1594 Group Manager's public key from the 'kdc_cred' parameter. The 1595 joining node MUST verify the proof-of-possession (PoP) evidence 1596 specified in the 'kdc_cred_verify' parameter of the Joining Response 1597 as defined below. 1599 * If the group is not a pairwise-only group, the PoP evidence is a 1600 signature. The joining node verifies it by using the public key 1601 of the Group Manager, as well as the signature algorithm used in 1602 the OSCORE group and possible corresponding parameters. 1604 * If the group is a pairwise-only group, the PoP evidence is a MAC. 1605 The joining node recomputes the MAC through the same process taken 1606 by the Group Manager when computing the value of the 1607 'kdc_cred_verify' parameter (see Section 6.4), with the difference 1608 that the joining node uses its own Diffie-Hellman private key and 1609 the Diffie-Hellman public key of the Group Manager. The 1610 verification succeeds if and only if the recomputed MAC is equal 1611 to the MAC conveyed as PoP evidence in the Joining Response. 1613 In case of failed verification of the PoP evidence, the joining node 1614 MUST stop processing the Joining Response and MAY send a new Joining 1615 Request to the Group Manager (see Section 6.2). 1617 In case of successful verification of the PoP evidence, the joining 1618 node uses the information received in the Joining Response to set up 1619 the Group OSCORE Security Context, as described in Section 2 of 1620 [I-D.ietf-core-oscore-groupcomm]. If the following parameters were 1621 not included in the 'key' parameter of the Joining Response, the 1622 joining node considers the following default values, consistently 1623 with Section 3.2 of [RFC8613]. 1625 * Absent the 'hkdf' parameter, the joining node considers HKDF 1626 SHA-256 as HKDF Algorithm to use in the OSCORE group. 1628 * Absent the 'salt' parameter, the joining node considers the empty 1629 byte string as Master Salt to use in the OSCORE group. 1631 In addition, the joining node maintains an association between each 1632 public key retrieved from the 'pub_keys' parameter and the role(s) 1633 that the corresponding group member has in the OSCORE group. 1635 From then on, the joining node can exchange group messages secured 1636 with Group OSCORE as described in [I-D.ietf-core-oscore-groupcomm]. 1637 When doing so: 1639 * The joining node MUST NOT process an incoming request message, if 1640 protected by a group member whose public key is not associated to 1641 the role "Requester". 1643 * The joining node MUST NOT process an incoming response message, if 1644 protected by a group member whose public key is not associated to 1645 the role "Responder". 1647 * The joining node MUST NOT use the pairwise mode of Group OSCORE to 1648 process messages in the group, if the Joining Response did not 1649 include the 'ecdh_alg' parameter. 1651 If the application requires backward security, the Group Manager MUST 1652 generate updated security parameters and group keying material, and 1653 provide it to the current group members upon the new node's joining 1654 (see Section 20). As a consequence, the joining node is not able to 1655 access secure communication in the OSCORE group occurred prior its 1656 joining. 1658 7. Public Keys of Joining Nodes 1660 Source authentication of a message sent within the group and 1661 protected with Group OSCORE is ensured by means of a digital 1662 signature embedded in the message (in group mode), or by integrity- 1663 protecting the message with pairwise keying material derived from the 1664 asymmetric keys of sender and recipient (in pairwise mode). 1666 Therefore, group members must be able to retrieve each other's public 1667 key from a trusted key repository, in order to verify source 1668 authenticity of incoming group messages. 1670 As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group 1671 Manager acts as trusted repository of the public keys of the group 1672 members, and provides those public keys to group members if requested 1673 to. Upon joining an OSCORE group, a joining node is thus expected to 1674 provide its own public key to the Group Manager. 1676 In particular, one of the following four cases can occur when a new 1677 node joins an OSCORE group. 1679 * The joining node is going to join the group exclusively as 1680 monitor, i.e., it is not going to send messages to the group. In 1681 this case, the joining node is not required to provide its own 1682 public key to the Group Manager, which thus does not have to 1683 perform any check related to the public key encoding, to a 1684 signature or ECDH algorithm, and to possible associated 1685 parameters. In case that joining node still provides a public key 1686 in the 'client_cred' parameter of the Joining Request (see 1687 Section 6.2), the Group Manager silently ignores that parameter, 1688 as well as the related parameters 'cnonce' and 1689 'client_cred_verify'. 1691 * The Group Manager already acquired the public key of the joining 1692 node during a past joining process. In this case, the joining 1693 node MAY choose not to provide again its own public key to the 1694 Group Manager, in order to limit the size of the Joining Request. 1695 The joining node MUST provide its own public key again if it has 1696 provided the Group Manager with multiple public keys during past 1697 joining processes, intended for different OSCORE groups. If the 1698 joining node provides its own public key, the Group Manager 1699 performs consistency checks as per Section 6.3 and, in case of 1700 success, considers it as the public key associated to the joining 1701 node in the OSCORE group. 1703 * The joining node and the Group Manager use an asymmetric proof-of- 1704 possession key to establish a secure communication association. 1705 Then, two cases can occur. 1707 1. The proof-of-possession key is compatible with the encoding, 1708 as well as with the signature or ECDH algorithm, and with 1709 possible associated parameters used in the OSCORE group. 1710 Then, the Group Manager considers the proof-of-possession key 1711 as the public key associated to the joining node in the OSCORE 1712 group. If the joining node is aware that the proof-of- 1713 possession key is also valid for the OSCORE group, it MAY not 1714 provide it again as its own public key to the Group Manager. 1715 The joining node MUST provide its own public key again if it 1716 has provided the Group Manager with multiple public keys 1717 during past joining processes, intended for different OSCORE 1718 groups. If the joining node provides its own public key in 1719 the 'client_cred' parameter of the Joining Request (see 1720 Section 6.2), the Group Manager performs consistency checks as 1721 per Section 6.3 and, in case of success, considers it as the 1722 public key associated to the joining node in the OSCORE group. 1724 2. The proof-of-possession key is not compatible with the 1725 encoding, or with the signature or algorithm, and with 1726 possible associated parameters used in the OSCORE group. In 1727 this case, the joining node MUST provide a different 1728 compatible public key to the Group Manager in the 1729 'client_cred' parameter of the Joining Request (see 1730 Section 6.2). Then, the Group Manager performs consistency 1731 checks on this latest provided public key as per Section 6.3 1732 and, in case of success, considers it as the public key 1733 associated to the joining node in the OSCORE group. 1735 * The joining node and the Group Manager use a symmetric proof-of- 1736 possession key to establish a secure communication association. 1737 In this case, upon performing a joining process with that Group 1738 Manager for the first time, the joining node specifies its own 1739 public key in the 'client_cred' parameter of the Joining Request 1740 targeting the group-membership endpoint (see Section 6.2). 1742 8. Retrieval of Updated Keying Material 1744 At some point, a group member considers the Group OSCORE Security 1745 Context invalid and to be renewed. This happens, for instance, after 1746 a number of unsuccessful security processing of incoming messages 1747 from other group members, or when the Security Context expires as 1748 specified by the 'exp' parameter of the Joining Response. 1750 When this happens, the group member retrieves updated security 1751 parameters and group keying material. This can occur in the two 1752 different ways described below. 1754 8.1. Retrieval of Group Keying Material 1756 If the group member wants to retrieve only the latest group keying 1757 material, it sends a Key Distribution Request to the Group Manager. 1759 In particular, it sends a CoAP GET request to the endpoint /ace- 1760 group/GROUPNAME at the Group Manager. 1762 The Group Manager processes the Key Distribution Request according to 1763 Section 4.1.2.2 of [I-D.ietf-ace-key-groupcomm]. The Key 1764 Distribution Response is formatted as defined in Section 4.1.2.2 of 1765 [I-D.ietf-ace-key-groupcomm]. In addition: 1767 * The 'key' parameter is formatted as defined in Section 6.4 of this 1768 document, with the difference that it does not include the 1769 'group_SenderId' parameter. 1771 * The 'exp' parameter MUST be present. 1773 * The 'ace-groupcomm-profile' parameter MUST be present and has 1774 value coap_group_oscore_app. 1776 Upon receiving the Key Distribution Response, the group member 1777 retrieves the updated security parameters and group keying material, 1778 and, if they differ from the current ones, uses them to set up the 1779 new Group OSCORE Security Context as described in Section 2 of 1780 [I-D.ietf-core-oscore-groupcomm]. 1782 8.2. Retrieval of Group Keying Material and OSCORE Sender ID 1784 If the group member wants to retrieve the latest group keying 1785 material as well as the OSCORE Sender ID that it has in the OSCORE 1786 group, it sends a Key Distribution Request to the Group Manager. 1788 In particular, it sends a CoAP GET request to the endpoint /ace- 1789 group/GROUPNAME/nodes/NODENAME at the Group Manager. 1791 The Group Manager processes the Key Distribution Request according to 1792 Section 4.1.6.2 of [I-D.ietf-ace-key-groupcomm]. The Key 1793 Distribution Response is formatted as defined in Section 4.1.6.2 of 1794 [I-D.ietf-ace-key-groupcomm]. In addition: 1796 * The 'key' parameter is formatted as defined in Section 6.4 of this 1797 document. In particular, if the requesting group member has 1798 exclusively the role of monitor, no 'group_SenderId' is specified 1799 within the 'key' parameter. 1801 Note that, in any other case, the current Sender ID of the group 1802 member is not specified as a separate parameter, but rather 1803 specified as 'group_SenderId' within the 'key' parameter. 1805 * The 'exp' parameter MUST be present. 1807 Upon receiving the Key Distribution Response, the group member 1808 retrieves the updated security parameters, group keying material and 1809 Sender ID, and, if they differ from the current ones, uses them to 1810 set up the new Group OSCORE Security Context as described in 1811 Section 2 of [I-D.ietf-core-oscore-groupcomm]. 1813 9. Requesting a Change of Keying Material 1815 As discussed in Section 2.4.2 of [I-D.ietf-core-oscore-groupcomm], a 1816 group member may at some point exhaust its Sender Sequence Numbers in 1817 the OSCORE group. 1819 When this happens, the group member MUST send a Key Renewal Request 1820 message to the Group Manager, as per Section 4.5 of 1821 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP PUT 1822 request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME at the 1823 Group Manager. 1825 Upon receiving the Key Renewal Request, the Group Manager processes 1826 it as defined in Section 4.1.6.1 of [I-D.ietf-ace-key-groupcomm], 1827 with the following additions. 1829 The Group Manager MUST return a 5.03 (Service Unavailable) response 1830 in case the OSCORE group identified by GROUPNAME is currently 1831 inactive (see Section 5.1). The response MUST have Content-Format 1832 set to application/ace-groupcomm+cbor and is formatted as defined in 1833 Section 4 of [I-D.ietf-ace-key-groupcomm]. The value of the 'error' 1834 field MUST be set to 9 ("Group currently not active"). 1836 Otherwise, the Group Manager performs one of the following actions. 1838 1. If the requesting group member has exclusively the role of 1839 monitor, the Group Manager replies with a 4.01 (Unauthorized) 1840 error response. The response MUST have Content-Format set to 1841 application/ace-groupcomm+cbor and is formatted as defined in 1842 Section 4 of [I-D.ietf-ace-key-groupcomm]. The value of the 1843 'error' field MUST be set to 1 ("Request inconsistent with the 1844 current roles"). 1846 2. Otherwise, the Group Manager takes one of the following actions. 1848 * The Group Manager rekeys the OSCORE group. That is, the Group 1849 Manager generates new group keying material for that group 1850 (see Section 20), and replies to the group member with a group 1851 rekeying message as defined in Section 20, providing the new 1852 group keying material. Then, the Group Manager rekeys the 1853 rest of the OSCORE group, as discussed in Section 20. 1855 The Group Manager SHOULD perform a group rekeying only if 1856 already scheduled to occur shortly, e.g., according to an 1857 application-dependent rekeying period or scheduling, or as a 1858 reaction to a recent change in the group membership. In any 1859 other case, the Group Manager SHOULD NOT rekey the OSCORE 1860 group when receiving a Key Renewal Request (OPT8). 1862 * The Group Manager determines and assigns a new OSCORE Sender 1863 ID for that group member, and replies with a Key Renewal 1864 Response formatted as defined in Section 4.1.6.1 of 1865 [I-D.ietf-ace-key-groupcomm]. In particular, the CBOR Map in 1866 the response payload includes a single parameter 1867 'group_SenderId' defined in Section 23.3 of this document, 1868 specifying the new Sender ID of the group member encoded as a 1869 CBOR byte string. 1871 Consistently with Section 2.4.3.1 of 1872 [I-D.ietf-core-oscore-groupcomm], the Group Manager MUST 1873 assign a new Sender ID that has not been used in the OSCORE 1874 group since the latest time when the current Gid value was 1875 assigned to the group. 1877 Furthermore, the Group Manager MUST add the old, relinquished 1878 Sender ID of the group member to the most recent set of stale 1879 Sender IDs, in the collection associated to the group (see 1880 Section 2.2.1). 1882 The Group Manager MUST return a 5.03 (Service Unavailable) 1883 response in case there are currently no Sender IDs available 1884 to assign in the OSCORE group. The response MUST have 1885 Content-Format set to application/ace-groupcomm+cbor and is 1886 formatted as defined in Section 4 of 1887 [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field 1888 MUST be set to 4 ("No available node identifiers"). 1890 10. Retrieval of Public Keys and Roles of Group Members 1892 A group member or a signature verifier may need to retrieve the 1893 public keys of (other) group members. To this end, the group member 1894 or signature verifier sends a Public Key Request message to the Group 1895 Manager, as per Section 4.6 of [I-D.ietf-ace-key-groupcomm]. In 1896 particular, it sends the request to the endpoint /ace- 1897 group/GROUPNAME/pub-key at the Group Manager. 1899 If the Public Key Request uses the method FETCH, the Public Key 1900 Request is formatted as defined in Section 4.1.3.1 of 1901 [I-D.ietf-ace-key-groupcomm]. In particular: 1903 * Each element (if any) of the inner CBOR array 'role_filter' is 1904 formatted as in the inner CBOR array 'role_filter' of the 1905 'get_pub_keys' parameter of the Joining Request when the parameter 1906 value is non-null (see Section 6.2). 1908 * Each element (if any) of the inner CBOR array 'id_filter' is a 1909 CBOR byte string, which encodes the OSCORE Sender ID of the group 1910 member for which the associated public key is requested (REQ12). 1912 Upon receiving the Public Key Request, the Group Manager processes it 1913 as per Section 4.1.3.1 or Section 4.1.3.2 of 1914 [I-D.ietf-ace-key-groupcomm], depending on the request method being 1915 FETCH or GET, respectively. Additionally, if the Public Key Request 1916 uses the method FETCH, the Group Manager silently ignores node 1917 identifiers included in the 'get_pub_keys' parameter of the request 1918 that are not associated to any current group member. 1920 The success Public Key Response is formatted as defined in 1921 Section 4.1.3.1 or Section 4.1.3.2 of [I-D.ietf-ace-key-groupcomm], 1922 depending on the request method being FETCH or GET, respectively. 1924 11. Update of Public Key 1926 A group member may need to provide the Group Manager with its new 1927 public key to use in the group from then on, hence replacing the 1928 current one. This can be the case, for instance, if the signature or 1929 ECDH algorithm, and possible associated parameters used in the OSCORE 1930 group have been changed, and the current public key is not compatible 1931 with them. 1933 To this end, the group member sends a Public Key Update Request 1934 message to the Group Manager, as per Section 4.7 of 1935 [I-D.ietf-ace-key-groupcomm], with the following addition. 1937 * The group member computes the proof-of-possession (PoP) evidence 1938 included in 'client_cred_verify' in the same way taken when 1939 preparing a Joining Request for the OSCORE group in question, as 1940 defined in Section 6.2 (REQ20). 1942 In particular, the group member sends a CoAP POST request to the 1943 endpoint /ace-group/GROUPNAME/nodes/NODENAME/pub-key at the Group 1944 Manager. 1946 Upon receiving the Public Key Update Request, the Group Manager 1947 processes it as per Section 4.1.7.1 of [I-D.ietf-ace-key-groupcomm], 1948 with the following additions. 1950 * The N_S challenge used to build the proof-of-possession input is 1951 computed as per point (1) in Section 6.2.1 (REQ21). 1953 * The Group Manager verifies the PoP challenge included in 1954 'client_cred_verify' in the same way taken when processing a 1955 Joining Request for the OSCORE group in question, as defined in 1956 Section 6.3 (REQ20). 1958 * The Group Manager MUST return a 5.03 (Service Unavailable) 1959 response in case the OSCORE group identified by GROUPNAME is 1960 currently inactive (see Section 5.1). The response MUST have 1961 Content-Format set to application/ace-groupcomm+cbor and is 1962 formatted as defined in Section 4 of [I-D.ietf-ace-key-groupcomm]. 1963 The value of the 'error' field MUST be set to 9 ("Group currently 1964 not active"). 1966 * If the requesting group member has exclusively the role of 1967 monitor, the Group Manager replies with a 4.00 (Bad request) error 1968 response. The response MUST have Content-Format set to 1969 application/ace-groupcomm+cbor and is formatted as defined in 1970 Section 4 of [I-D.ietf-ace-key-groupcomm]. The value of the 1971 'error' field MUST be set to 1 ("Request inconsistent with the 1972 current roles"). 1974 * If the request is successfully processed, the Group Manager stores 1975 the association between i) the new public key of the group member; 1976 and ii) the Group Identifier (Gid), i.e., the OSCORE ID Context, 1977 associated to the OSCORE group together with the OSCORE Sender ID 1978 assigned to the group member in the group. The Group Manager MUST 1979 keep this association updated over time. 1981 12. Retrieval of the Group Manager's Public Key 1983 A group member or a signature verifier may need to retrieve the 1984 public key of the Group Manager. To this end, the group member or 1985 signature verifier sends a Group Manager Public Key Request message 1986 to the Group Manager. 1988 In particular, it sends a CoAP GET request to the endpoint /ace- 1989 group/GROUPNAME/gm-pub-key at the Group Manager defined in 1990 Section 5.2 of this document, where GROUPNAME is the name of the 1991 OSCORE group. 1993 The payload of the 2.05 (Content) Group Manager Public Key Response 1994 is a CBOR map, which MUST contain the following parameters defined in 1995 Section 23.3. 1997 * The 'kdc_nonce' parameter, specifying a nonce generated by the 1998 Group Manager. This parameter is encoded like the 'kdc_nonce' 1999 parameter in the Joining Response (see Section 6.4). 2001 * The 'kdc_cred' parameter, specifying the Group Manager's public 2002 key. This parameter is encoded like the 'kdc_cred' parameter in 2003 the Joining Response (see Section 6.4). 2005 * The 'kdc_cred_verify' parameter, specifying a proof-of-possession 2006 (PoP) evidence computed by the Group Manager. This parameter is 2007 encoded like the 'kdc_cred_verify' parameter in the Joining 2008 Response (see Section 6.4). 2010 The PoP evidence is computed over the nonce specified in the 2011 'kdc_nonce' parameter and taken as PoP input, by means of the same 2012 method used when preparing the Joining Response (see Section 6.4). 2013 In particular, if the group is a pairwise-only group, the Group 2014 Manager computes IKM by using its own Diffie-Hellman private key 2015 as well as the Diffie-Hellman public key of the requesting client. 2017 Upon receiving a 2.05 (Content) Group Manager Public Key Response, 2018 the group member or signature verifier retrieves the Group Manager's 2019 public key from the 'kdc_cred' parameter, and MUST verify the proof- 2020 of-possession (PoP) evidence specified in the 'kdc_cred_verify' 2021 parameter. That is: 2023 * A group member verifies the PoP evidence by means of the same 2024 method used when processing the Joining Response (see 2025 Section 6.4). In particular, if the group is a pairwise-only 2026 group, the group member computes IKM by using its own Diffie- 2027 Hellman private key as well as the Diffie-Hellman public key of 2028 the Group Manager. 2030 * A signature verifier verifies the PoP evidence as a signature, by 2031 using the public key of the Group Manager, as well as the 2032 signature algorithm used in the OSCORE group and possible 2033 corresponding parameters. Note that a signature verifier would 2034 not receive a successful response from the Group Manager, in case 2035 GROUPNAME denotes a pairwise-only group. 2037 In case of successful verification of the PoP evidence, the group 2038 member or signature verifier MUST store the obtained Group Manager's 2039 public key, possibly replacing the currently stored one. 2041 Figure 3 gives an overview of the exchange described above, while 2042 Figure 4 shows an example. 2044 Group Group 2045 Member Manager 2046 | | 2047 | Group Manager Public Key Request | 2048 |------------------------------------------------------------>| 2049 | GET ace-group/GROUPNAME/gm-pub-key | 2050 | | 2051 |<---- Group Manager Public Key Response: 2.05 (Content) -----| 2052 | | 2054 Figure 3: Message Flow of Group Manager Public Key Request-Response 2056 Request: 2058 Header: GET (Code=0.01) 2059 Uri-Host: "kdc.example.com" 2060 Uri-Path: "ace-group" 2061 Uri-Path: "g1" 2062 Uri-Path: "gm-pub-key" 2063 Payload: - 2065 Response: 2067 Header: Content (Code=2.05) 2068 Content-Format: "application/ace-groupcomm+cbor" 2069 Payload (in CBOR diagnostic notation, with PUB_KEY_GM 2070 and POP_EVIDENCE being CBOR byte strings): 2071 { 2072 "kdc_nonce": h'25a8991cd700ac01', 2073 "kdc_cred": PUB_KEY_GM, 2074 "kdc_cred_verify": POP_EVIDENCE 2075 } 2077 Figure 4: Example of Group Manager Public Key Request-Response 2079 13. Retrieval of Signature Verification Data 2081 A signature verifier may need to retrieve data required to verify 2082 signatures of messages protected with the group mode and sent to a 2083 group (see Sections 3.1 and 8.5 of [I-D.ietf-core-oscore-groupcomm]). 2084 To this end, the signature verifier sends a Signature Verification 2085 Data Request message to the Group Manager. 2087 In particular, it sends a CoAP GET request to the endpoint /ace- 2088 group/GROUPNAME/verif-data at the Group Manager defined in 2089 Section 5.3 of this document, where GROUPNAME is the name of the 2090 OSCORE group. 2092 The payload of the 2.05 (Content) Signature Verification Data 2093 Response is a CBOR map, which has the format used for the Joining 2094 Response message in Section 6.4, with the following differences. 2096 * From the Joining Response message, only the parameters 'gkty', 2097 'key', 'num', 'exp' and 'ace-groupcomm-profile' are present. In 2098 particular, the 'key' parameter includes only the following data. 2100 - The parameters 'hkdf', 'contextId', 'pub_key_enc', 2101 'sign_enc_alg', 'sign_alg', 'sign_params'. These parameters 2102 MUST be present. 2104 - The parameters 'alg' and 'ecdh_alg'. These parameter MUST NOT 2105 be present if the group is a signature-only group. Otherwise, 2106 they MUST be present. 2108 * The parameter 'group_enc_key' is also included, with CBOR label 2109 defined in Section 23.3. This parameter specifies the Group 2110 Encryption Key of the OSCORE Group, encoded as a CBOR byte string. 2111 The Group Manager derives the Group Encryption Key from the group 2112 keying material, as per Section 2.1.6 of 2113 [I-D.ietf-core-oscore-groupcomm]. This parameter MUST be present. 2115 In order to verify signatures in the group (see Section 8.5 of 2116 [I-D.ietf-core-oscore-groupcomm]), the signature verifier relies on: 2117 the data retrieved from the 2.05 (Content) Signature Verification 2118 Data Response; the public keys of the group members signing the 2119 messages to verify, that can be retrieved as defined in Section 10; 2120 and the public key of the Group Manager, which can be retrieved as 2121 defined in Section 12. 2123 Figure 5 gives an overview of the exchange described above, while 2124 Figure 6 shows an example. 2126 Signature Group 2127 Verifier Manager 2128 | | 2129 | Signature Verification Data Request | 2130 |------------------------------------------------------------>| 2131 | GET ace-group/GROUPNAME/verif-data | 2132 | | 2133 |<--- Signature Verification Data Response: 2.05 (Content) ---| 2134 | | 2136 Figure 5: Message Flow of Signature Verification Data Request- 2137 Response 2139 Request: 2141 Header: GET (Code=0.01) 2142 Uri-Host: "kdc.example.com" 2143 Uri-Path: "ace-group" 2144 Uri-Path: "g1" 2145 Uri-Path: "verif-data" 2146 Payload: - 2148 Response: 2150 Header: Content (Code=2.05) 2151 Content-Format: "application/ace-groupcomm+cbor" 2152 Payload (in CBOR diagnostic notation, with GROUPCOMM_KEY_TBD 2153 and PROFILE_TBD being CBOR integers, while GROUP_ENC_KEY 2154 being a CBOR byte string): 2155 { 2156 "gkty": GROUPCOMM_KEY_TBD, 2157 "key": { 2158 'hkdf': -10, ; HKDF SHA-256 2159 'contextId': h'37fc', 2160 'pub_key_enc': 33, ; x5chain 2161 'sign_enc_alg': 10, ; AES-CCM-16-64-128 2162 'sign_alg': -8, ; EdDSA 2163 'sign_params': [[1], [1, 6]] ; [[OKP], [OKP, Ed25519]] 2164 }, 2165 "num": 12, 2166 "exp": 1609459200, 2167 "ace_groupcomm_profile": PROFILE_TBD, 2168 "group_enc_key": GROUP_ENC_KEY 2169 } 2171 Figure 6: Example of Signature Verification Data Request-Response 2173 14. Retrieval of Group Policies 2175 A group member may request the current policies used in the OSCORE 2176 group. To this end, the group member sends a Policies Request, as 2177 per Section 4.8 of [I-D.ietf-ace-key-groupcomm]. In particular, it 2178 sends a CoAP GET request to the endpoint /ace-group/GROUPNAME/ 2179 policies at the Group Manager, where GROUPNAME is the name of the 2180 OSCORE group. 2182 Upon receiving the Policies Request, the Group Manager processes it 2183 as per Section 4.1.4.1 of [I-D.ietf-ace-key-groupcomm]. The success 2184 Policies Response is formatted as defined in Section 4.1.4.1 of 2185 [I-D.ietf-ace-key-groupcomm]. 2187 15. Retrieval of Keying Material Version 2189 A group member may request the current version of the keying material 2190 used in the OSCORE group. To this end, the group member sends a 2191 Version Request, as per Section 4.9 of [I-D.ietf-ace-key-groupcomm]. 2192 In particular, it sends a CoAP GET request to the endpoint /ace- 2193 group/GROUPNAME/num at the Group Manager, where GROUPNAME is the name 2194 of the OSCORE group. 2196 Upon receiving the Version Request, the Group Manager processes it as 2197 per Section 4.1.5.1 of [I-D.ietf-ace-key-groupcomm]. The success 2198 Version Response is formatted as defined in Section 4.1.5.1 of 2199 [I-D.ietf-ace-key-groupcomm]. 2201 16. Retrieval of Group Status 2203 A group member may request the current status of the the OSCORE 2204 group, i.e., active or inactive. To this end, the group member sends 2205 a Group Status Request to the Group Manager. 2207 In particular, the group member sends a CoAP GET request to the 2208 endpoint /ace-group/GROUPNAME/active at the Group Manager defined in 2209 Section 5.1 of this document, where GROUPNAME is the name of the 2210 OSCORE group. 2212 The payload of the 2.05 (Content) Group Status Response includes the 2213 CBOR simple value True if the group is currently active, or the CBOR 2214 simple value False otherwise. The group is considered active if it 2215 is set to allow new members to join, and if communication within the 2216 group is fine to happen. 2218 Upon learning from a 2.05 (Content) response that the group is 2219 currently inactive, the group member SHOULD stop taking part in 2220 communications within the group, until it becomes active again. 2222 Upon learning from a 2.05 (Content) response that the group has 2223 become active again, the group member can resume taking part in 2224 communications within the group. 2226 Figure 7 gives an overview of the exchange described above, while 2227 Figure 8 shows an example. 2229 Group Group 2230 Member Manager 2231 | | 2232 |--- Group Status Request: GET ace-group/GROUPNAME/active --->| 2233 | | 2234 |<---------- Group Status Response: 2.05 (Content) -----------| 2235 | | 2237 Figure 7: Message Flow of Group Status Request-Response 2239 Request: 2241 Header: GET (Code=0.01) 2242 Uri-Host: "kdc.example.com" 2243 Uri-Path: "ace-group" 2244 Uri-Path: "g1" 2245 Uri-Path: "active" 2246 Payload: - 2248 Response: 2250 Header: Content (Code=2.05) 2251 Payload (in CBOR diagnostic notation): 2252 true 2254 Figure 8: Example of Group Status Request-Response 2256 17. Retrieval of Group Names and URIs 2258 A node may want to retrieve from the Group Manager the group name and 2259 the URI of the group-membership resource of a group. This is 2260 relevant in the following cases. 2262 * Before joining a group, a joining node may know only the current 2263 Group Identifier (Gid) of that group, but not the group name and 2264 the URI to the group-membership resource. 2266 * As current group member in several groups, the node has missed a 2267 previous group rekeying in one of them (see Section 20). Hence, 2268 it retains stale keying material and fails to decrypt received 2269 messages exchanged in that group. 2271 Such messages do not provide a direct hint to the correct group 2272 name, that the node would need in order to retrieve the latest 2273 keying material and public keys from the Group Manager (see 2274 Section 8.1, Section 8.2 and Section 10). However, such messages 2275 may specify the current Gid of the group, as value of the 2276 'kid_context' field of the OSCORE CoAP option (see Section 6.1 of 2277 [RFC8613] and Section 4.2 of [I-D.ietf-core-oscore-groupcomm]). 2279 * As signature verifier, the node also refers to a group name for 2280 retrieving the required public keys from the Group Manager (see 2281 Section 10). As discussed above, intercepted messages do not 2282 provide a direct hint to the correct group name, while they may 2283 specify the current Gid of the group, as value of the 2284 'kid_context' field of the OSCORE CoAP option. In such a case, 2285 upon intercepting a message in the group, the node requires to 2286 correctly map the Gid currently used in the group with the 2287 invariant group name. 2289 Furthermore, since it is not a group member, the node does not 2290 take part to a possible group rekeying. Thus, following a group 2291 rekeying and the consequent change of Gid in a group, the node 2292 would retain the old Gid value and cannot correctly associate 2293 intercepted messages to the right group, especially if acting as 2294 signature verifier in several groups. This in turn prevents the 2295 efficient verification of signatures, and especially the retrieval 2296 of required, new public keys from the Group Manager. 2298 In either case, the node only knows the current Gid of the group, as 2299 learned from received or intercepted messages exchanged in the group. 2300 As detailed below, the node can contact the Group Manager, and 2301 request the group name and URI to the group-membership resource 2302 corresponding to that Gid. Then, it can use that information to 2303 either join the group as a candidate group member, get the latest 2304 keying material as a current group member, or retrieve public keys 2305 used in the group as a signature verifier. To this end, the node 2306 sends a Group Name and URI Retrieval Request, as per Section 4.2 of 2307 [I-D.ietf-ace-key-groupcomm]. 2309 In particular, the node sends a CoAP FETCH request to the endpoint 2310 /ace-group at the Group Manager formatted as defined in 2311 Section 4.1.1.1 of [I-D.ietf-ace-key-groupcomm]. Each element of the 2312 CBOR array 'gid' is a CBOR byte string (REQ9), which encodes the Gid 2313 of the group for which the group name and the URI to the group- 2314 membership resource are requested. 2316 Upon receiving the Group Name and URI Retrieval Request, the Group 2317 Manager processes it as per Section 4.1.1.1 of 2318 [I-D.ietf-ace-key-groupcomm]. The success Group Name and URI 2319 Retrieval Response is formatted as defined in Section 4.1.1.1 of 2320 [I-D.ietf-ace-key-groupcomm]. In particular, each element of the 2321 CBOR array 'gid' is a CBOR byte string (REQ9), which encodes the Gid 2322 of the group for which the group name and the URI to the group- 2323 membership resource are provided. 2325 For each of its groups, the Group Manager maintains an association 2326 between the group name and the URI to the group-membership resource 2327 on one hand, and only the current Gid for that group on the other 2328 hand. That is, the Group Manager MUST NOT maintain an association 2329 between the former pair and any other Gid for that group than the 2330 current, most recent one. 2332 Figure 9 gives an overview of the exchanges described above, while 2333 Figure 10 shows an example. 2335 Group 2336 Node Manager 2337 | | 2338 |---- Group Name and URI Retrieval Request: FETCH ace-group/ --->| 2339 | | 2340 |<--- Group Name and URI Retrieval Response: 2.05 (Content) -----| 2341 | | 2343 Figure 9: Message Flow of Group Name and URI Retrieval Request- 2344 Response 2346 Request: 2348 Header: FETCH (Code=0.05) 2349 Uri-Host: "kdc.example.com" 2350 Uri-Path: "ace-group" 2351 Content-Format: "application/ace-groupcomm+cbor" 2352 Payload (in CBOR diagnostic notation): 2353 { 2354 "gid": [h'37fc', h'84bd'] 2355 } 2357 Response: 2359 Header: Content (Code=2.05) 2360 Content-Format: "application/ace-groupcomm+cbor" 2361 Payload (in CBOR diagnostic notation): 2362 { 2363 "gid": [h'37fc', h'84bd'], 2364 "gname": ["g1", "g2"], 2365 "guri": ["ace-group/g1", "ace-group/g2"] 2366 } 2368 Figure 10: Example of Group Name and URI Retrieval Request-Response 2370 18. Request to Leave the Group 2372 A group member may request to leave the OSCORE group. To this end, 2373 the group member sends a Group Leaving Request, as per Section 4.10 2374 of [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP 2375 DELETE request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME at 2376 the Group Manager. 2378 Upon receiving the Group Leaving Request, the Group Manager processes 2379 it as per Section 4.1.6.3 of [I-D.ietf-ace-key-groupcomm]. 2381 19. Removal of a Group Member 2383 Other than after a spontaneous request to the Group Manager as 2384 described in Section 18, a node may be forcibly removed from the 2385 OSCORE group, e.g., due to expired or revoked authorization. 2387 In either case, the Group Manager "forgets" the Birth Gid currently 2388 associated to the leaving node in the OSCORE group. This was stored 2389 following the Joining Response sent to that node, after its latest 2390 (re-)joining of the OSCORE group (see Section 6.4). 2392 If any of the two conditions below holds, the Group Manager MUST 2393 inform the leaving node of its eviction as follows. If both 2394 conditions hold, the Group Manager MUST inform the leaving node only 2395 once, using either of the corresponding methods. 2397 * If, upon joining the group (see Section 6.2), the leaving node 2398 specified a URI in the 'control_uri' parameter defined in 2399 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm], the Group Manager 2400 sends a DELETE request targeting the URI specified in the 2401 'control_uri' parameter (OPT9). 2403 * If the leaving node has been observing the associated resource at 2404 ace-group/GROUPNAME/nodes/NODENAME, the Group Manager sends an 2405 unsolicited 4.04 (Not Found) response to the leaving node, as 2406 specified in 4.1.6.2 of [I-D.ietf-ace-key-groupcomm]. 2408 If the leaving node has not exclusively the role of monitor, the 2409 Group Manager performs the following actions. 2411 * The Group Manager frees the OSCORE Sender ID value of the leaving 2412 node. This value MUST NOT become available for possible upcoming 2413 joining nodes in the same group, until the group has been rekeyed 2414 and assigned a new Group Identifier (Gid). 2416 * The Group Manager MUST add the relinquished Sender ID of the 2417 leaving node to the most recent set of stale Sender IDs, in the 2418 collection associated to the group (see Section 2.2.1). 2420 * The Group Manager cancels the association between, on one hand, 2421 the public key of the leaving node and, on the other hand, the Gid 2422 associated to the OSCORE group together with the freed Sender ID 2423 value. The Group Manager deletes the public key of the leaving 2424 node, if that public key has no remaining association with any 2425 pair (Gid, Sender ID). 2427 Then, the Group Manager MUST generate updated security parameters and 2428 group keying material, and provide it to the remaining group members 2429 (see Section 20). As a consequence, the leaving node is not able to 2430 acquire the new security parameters and group keying material 2431 distributed after its leaving. 2433 Same considerations in Section 5 of [I-D.ietf-ace-key-groupcomm] 2434 apply here as well, considering the Group Manager acting as KDC. 2436 20. Group Rekeying Process 2438 In order to rekey the OSCORE group, the Group Manager distributes a 2439 new Group Identifier (Gid), i.e., a new OSCORE ID Context; a new 2440 OSCORE Master Secret; and, optionally, a new OSCORE Master Salt for 2441 that group. When doing so, the Group Manager MUST increment the 2442 version number of the group keying material, before starting its 2443 distribution. 2445 Consistently with Section 3.1 of [I-D.ietf-core-oscore-groupcomm]: 2447 * The Group Manager can reassign a Gid to the same group over that 2448 group's lifetime, e.g., once the whole space of Gid values has 2449 been used for the group in question. 2451 * Before rekeying the group, the Group Manager MUST check if the new 2452 Gid to be distributed coincides with the Birth Gid of any of the 2453 current group members (see Section 6.4). If any of such "elder 2454 members" is found in the group, the Group Manager MUST evict them 2455 from the group. That is, the Group Manager MUST terminate their 2456 membership and MUST rekey the group in such a way that the new 2457 keying material is not provided to those evicted elder members. 2458 This also includes adding their relinquished Sender IDs to the 2459 most recent set of stale Sender IDs, in the collection associated 2460 to the group (see Section 2.2.1), before rekeying the group. 2462 Until a further following group rekeying, the Group Manager MUST 2463 store the list of those latest-evicted elder members. If any of 2464 those nodes re-joins the group before a further following group 2465 rekeying occurs, the Group Manager MUST NOT rekey the group upon 2466 their re-joining. When one of those nodes re-joins the group, the 2467 Group Manager can rely, e.g., on the ongoing secure communication 2468 association to recognize the node as included in the stored list. 2470 Across the rekeying execution, the Group Manager MUST preserve the 2471 same unchanged OSCORE Sender IDs for all group members intended to 2472 remain in the group. This avoids affecting the retrieval of public 2473 keys from the Group Manager and the verification of group messages. 2475 The Group Manager MUST support at least the group rekeying scheme 2476 defined in Section 20.1. Future application profiles may define 2477 alternative message formats and group rekeying schemes, which MUST 2478 comply with the functional steps defined in Section 3.2 of 2479 [I-D.ietf-core-oscore-groupcomm]. 2481 It is RECOMMENDED that the Group Manager gets confirmation of 2482 successful distribution from the group members, and admits a maximum 2483 number of individual retransmissions to non-confirming group members. 2484 Once completed the group rekeying process, the Group Manager creates 2485 a new empty set X' of stale Sender IDs associated to the version of 2486 the newly distributed group keying material. Then, the Group Manager 2487 MUST add the set X' to the collection of stale Sender IDs associated 2488 to the group (see Section 2.2.1). 2490 In case the rekeying terminates and some group members have not 2491 received the new keying material, they will not be able to correctly 2492 process following secured messages exchanged in the group. These 2493 group members will eventually contact the Group Manager, in order to 2494 retrieve the current keying material and its version. 2496 Some of these group members may be in multiple groups, each 2497 associated to a different Group Manager. When failing to correctly 2498 process messages secured with the new keying material, these group 2499 members may not have sufficient information to determine which exact 2500 Group Manager they should contact, in order to retrieve the current 2501 keying material they are missing. 2503 If the Gid is formatted as described in Appendix C of 2504 [I-D.ietf-core-oscore-groupcomm], the Group Prefix can be used as a 2505 hint to determine the right Group Manager, as long as no collisions 2506 among Group Prefixes are experienced. Otherwise, a group member 2507 needs to contact the Group Manager of each group, e.g., by first 2508 requesting only the version of the current group keying material (see 2509 Section 15) and then possibly requesting the current keying material 2510 (see Section 8.1). 2512 Furthermore, some of these group members can be in multiple groups, 2513 all of which associated to the same Group Manager. In this case, 2514 these group members may also not have sufficient information to 2515 determine which exact group they should refer to, when contacting the 2516 right Group Manager. Hence, they need to contact a Group Manager 2517 multiple times, i.e., separately for each group they belong to and 2518 associated to that Group Manager. 2520 Finally, Section 20.3 discusses how a group member can realize that 2521 it has missed one or more rekeying instances, and the actions it is 2522 accordingly required to take. 2524 20.1. Sending Rekeying Messages 2526 The Group Manager MUST support at least the group rekeying scheme 2527 defined in this section. 2529 The group rekeying messages MUST have Content-Format set to 2530 application/ace-groupcomm+cbor and have the same format used for the 2531 Joining Response message in Section 6.4, with the following 2532 differences. 2534 * From the Joining Response, only the parameters 'gkty', 'key', 2535 'num', 'exp', and 'ace-groupcomm-profile' are present. In 2536 particular, the 'key' parameter includes only the following data. 2538 - The 'ms' parameter, specifying the new OSCORE Master Secret 2539 value. This parameter MUST be present. 2541 - The 'contextId' parameter, specifying the new Gid to use as 2542 OSCORE ID Context value. This parameter MUST be present. 2544 - The 'salt' value, specifying the new OSCORE Master Salt value. 2545 This parameter MAY be present. 2547 * The parameter 'stale_node_ids' MUST also be included, with CBOR 2548 label defined in Section 23.3. This parameter is encoded as a 2549 CBOR array, where each element is encoded as a CBOR byte string. 2550 The CBOR array has to be intended as a set, i.e., the order of its 2551 elements is irrelevant. The parameter is populated as follows. 2553 - The Group Manager creates an empty CBOR array ARRAY. 2555 - The Group Manager considers the collection of stale Sender IDs 2556 associated to the group (see Section 2.2.1), and takes the most 2557 recent set X, i.e., the set associated to the current version 2558 of the group keying material about to be relinquished. 2560 - For each Sender ID in X, the Group Manager encodes it as a CBOR 2561 byte string and adds the result to ARRAY. 2563 - The parameter 'stale_node_ids' takes ARRAY as value. 2565 The Group Manager separately sends a group rekeying message formatted 2566 as defined above to each group member to be rekeyed. 2568 Each rekeying message MUST be secured with the pairwise secure 2569 communication channel between the Group Manager and the group member 2570 used during the joining process. In particular, each rekeying 2571 message can target the 'control_uri' URI path defined in 2572 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm] (OPT9), if provided 2573 by the intended recipient upon joining the group (see Section 6.2). 2575 This distribution approach requires group members to act (also) as 2576 servers, in order to correctly handle unsolicited group rekeying 2577 messages from the Group Manager. In particular, if a group member 2578 and the Group Manager use OSCORE [RFC8613] to secure their pairwise 2579 communications, the group member MUST create a Replay Window in its 2580 own Recipient Context upon establishing the OSCORE Security Context 2581 with the Group Manager, e.g., by means of the OSCORE profile of ACE 2582 [I-D.ietf-ace-oscore-profile]. 2584 Group members and the Group Manager SHOULD additionally support 2585 alternative distribution approaches that do not require group members 2586 to act (also) as servers. A number of such approaches are defined in 2587 Section 4.4 of [I-D.ietf-ace-key-groupcomm]. In particular, a group 2588 member may subscribe for updates to the group-membership resource of 2589 the group, at the endpoint /ace-group/GROUPNAME/ of the Group 2590 Manager. This can rely on CoAP Observe [RFC7641] or on a full- 2591 fledged Pub-Sub model [I-D.ietf-core-coap-pubsub] with the Group 2592 Manager acting as Broker. 2594 20.2. Receiving Rekeying Messages 2596 Once received the new group keying material, a group member proceeds 2597 as follows. 2599 The group member considers the stale Sender IDs received from the 2600 Group Manager. If the group rekeying scheme defined in Section 20.1 2601 is used, the stale Sender IDs are specified by the 'stale_node_ids' 2602 parameter. 2604 After that, as per Section 3.2 of [I-D.ietf-core-oscore-groupcomm], 2605 the group member MUST remove every public key associated to a stale 2606 Sender ID from its list of group members' public keys used in the 2607 group, and MUST delete each of its Recipient Contexts used in the 2608 group whose corresponding Recipient ID is a stale Sender ID. 2610 Then, the following cases can occur, based on the version number V' 2611 of the new group keying material distributed through the rekeying 2612 process. If the group rekeying scheme defined in Section 20.1 is 2613 used, this information is specified by the 'num' parameter. 2615 * The group member has not missed any group rekeying. That is, the 2616 old keying material owned by the group member has version number 2617 V, while the received new keying material has version number V' = 2618 (V + 1). In such a case, the group member simply installs the new 2619 keying material and derives the corresponding new Security 2620 Context. 2622 * The group member has missed one or more group rekeying instances. 2623 That is, the old keying material owned by the group member has 2624 version number V, while the received new keying material has 2625 version number V' > (V + 1). In such a case, the group member 2626 MUST proceed as defined in Section 20.3. 2628 * The group member has received keying material not newer than the 2629 stored one. That is, the stored keying material owned by the 2630 group member has version number V, while the received keying 2631 material has version number V' < (V + 1). In such a case, the 2632 group member MUST ignore the received rekeying messages and MUST 2633 NOT install the received keying material. 2635 20.3. Missed Rekeying Instances 2637 A group member can realize to have missed one or more rekeying 2638 instances in one of the ways discussed below. In the following, V 2639 denotes the version number of the old keying material stored by the 2640 group member, while V' denotes the version number of the latest, 2641 possibly just distributed, keying material. 2643 a. The group member has participated to a rekeying process that has 2644 distributed new keying material with version number V' > (V + 1), as 2645 discussed in Section 20.2. 2647 b. The group member has obtained the latest keying material from the 2648 Group Manager, as a response to a Key Distribution Request (see 2649 Section 8.1) or to a Joining Request when re-joining the group (see 2650 Section 6.2). In particular, V is different than V' specified by the 2651 'num' parameter in the response. 2653 c. The group member has obtained the public keys of other group 2654 members, through a Public Key Request-Response exchange with the 2655 Group Manager (see Section 10). In particular, V is different than 2656 V' specified by the 'num' parameter in the response. 2658 d. The group member has performed a Version Request-Response 2659 exchange with the Group Manager (see Section 15). In particular, V 2660 is different than V' specified by the 'num' parameter in the 2661 response. 2663 In either case, the group member MUST delete the stored keying 2664 material with version number V. 2666 If case (a) or case (b) applies, the group member MUST perform the 2667 following actions. 2669 1. The group member MUST NOT install the latest keying material yet, 2670 in case that was already obtained. 2672 2. The group member sends a Stale Sender IDs Request to the Group 2673 Manager (see Section 20.3.1), specifying the version number V as 2674 payload of the request. 2676 If the Stale Sender IDs Response from the Group Manager has no 2677 payload, the group member MUST remove all the public keys from 2678 its list of group members' public keys used in the group, and 2679 MUST delete all its Recipient Contexts used in the group. 2681 Otherwise, the group member considers the stale Sender IDs 2682 specified in the Stale Sender IDs Response from the Group 2683 Manager. Then, the group member MUST remove every public key 2684 associated to a stale Sender ID from its list of group members' 2685 public keys used in the group, and MUST delete each of its 2686 Recipient Contexts used in the group whose corresponding 2687 Recipient ID is a stale Sender ID. 2689 3. The group member installs the latest keying material with version 2690 number V' and derives the corresponding new Security Context. 2692 If case (c) or case (d) applies, the group member SHOULD perform the 2693 following actions. 2695 1. The group member sends a Stale Sender IDs Request to the Group 2696 Manager (see Section 20.3.1), specifying the version number V as 2697 payload of the request. 2699 If the Stale Sender IDs Response from the Group Manager has no 2700 payload, the group member MUST remove all the public keys from 2701 its list of group members' public keys used in the group, and 2702 MUST delete all its Recipient Contexts used in the group. 2704 Otherwise, the group member considers the stale Sender IDs 2705 specified in the Stale Sender IDs Response from the Group 2706 Manager. Then, the group member MUST remove every public key 2707 associated to a stale Sender ID from its list of group members' 2708 public keys used in the group, and MUST delete each of its 2709 Recipient Contexts used in the group whose corresponding 2710 Recipient ID is a stale Sender ID. 2712 2. The group member obtains the latest keying material with version 2713 number V' from the Group Manager. This can happen by sending a 2714 Key Distribution Request to the Group Manager (see Section 8.1), 2715 or by re-joining the group (see Section 6.2). 2717 3. The group member installs the latest keying material with version 2718 number V' and derives the corresponding new Security Context. 2720 If case (c) or case (d) applies, the group member can alternatively 2721 perform the following actions. 2723 1. The group member re-joins the group (see Section 6.2). When 2724 doing so, the group member MUST re-join with the same roles it 2725 currently has in the group, and MUST request the Group Manager 2726 for the public keys of all the current group members. That is, 2727 the 'get_pub_keys' parameter of the Joining Request MUST be 2728 present and MUST be set to the CBOR simple value Null. 2730 2. When receiving the Joining Response (see Section 6.5 and 2731 Section 6.5), the group member retrieves the set Z of public keys 2732 specified in the 'pub_keys' parameter. 2734 Then, the group member MUST remove every public key which is not 2735 in Z from its list of group members' public keys used in the 2736 group, and MUST delete each of its Recipient Contexts used in the 2737 group that does not include any of the public keys in Z. 2739 3. The group member installs the latest keying material with version 2740 number V' and derives the corresponding new Security Context. 2742 20.3.1. Retrieval of Stale Sender IDs 2744 When realizing to have missed one or more group rekeying instances 2745 (see Section 20.3), a node needs to retrieve from the Group Manager 2746 the data required to delete some of its stored group members' public 2747 keys and Recipient Contexts (see Section 5.4.1). This data is 2748 provided as an aggregated set of stale Sender IDs, which are used as 2749 specified in Section 20.3. 2751 In particular, the node sends a CoAP FETCH request to the endpoint 2752 /ace-group/GROUPNAME/stale-sids at the Group Manager defined in 2753 Section 5.4 of this document, where GROUPNAME is the name of the 2754 OSCORE group. 2756 The payload of the Stale Sender IDs Request MUST include a CBOR 2757 unsigned integer. This encodes the version number V of the most 2758 recent group keying material owned and installed by the requesting 2759 client, which is older than the latest, possibly just distributed, 2760 keying material with version number V'. 2762 The handler MUST respond with a 4.00 (Bad Request) response, if the 2763 request is not formatted correctly. Also, the handler MUST respond 2764 with a 4.00 (Bad Request) response, if the specified version number V 2765 is greater or equal than the version number V' associated to the 2766 latest keying material in the group, i.e., if V >= V'. 2768 Otherwise, the handler responds with a 2.05 (Content) Stale Sender 2769 IDs Response. The payload of the response is formatted as defined 2770 below, where SKEW = (V' - V + 1). 2772 * The Group Manager considers ITEMS as the current number of sets 2773 stored in the collection of stale Sender IDs associated to the 2774 group (see Section 2.2.1). 2776 * If SKEW > ITEMS, the Stale Sender IDs Response MUST NOT have a 2777 payload. 2779 * Otherwise, the payload of the Stale Sender IDs Response MUST 2780 include a CBOR array, where each element is encoded as a CBOR byte 2781 string. The CBOR array has to be intended as a set, i.e., the 2782 order of its elements is irrelevant. The Group Manager populates 2783 the CBOR array as follows. 2785 - The Group Manager creates an empty CBOR array ARRAY and an 2786 empty set X. 2788 - The Group Manager considers the SKEW most recent sets stored in 2789 the collection of stale Sender IDs associated to the group. 2790 Note that the most recent set is the one associate to the 2791 latest version of the group keying material. 2793 - The Group Manager copies all the Sender IDs from the selected 2794 sets into X. When doing so, the Group Manager MUST discard 2795 duplicates. That is, the same Sender ID MUST NOT be present 2796 more than once in the final content of X. 2798 - For each Sender ID in X, the Group Manager encodes it as a CBOR 2799 byte string and adds the result to ARRAY. 2801 - Finally, ARRAY is specified as payload of the Stale Sender IDs 2802 Response. Note that ARRAY might result in the empty CBOR 2803 array. 2805 Figure 11 gives an overview of the exchange described above, while 2806 Figure 12 shows an example. 2808 Group 2809 Node Manager 2810 | | 2811 | Stale Sender IDs Request | 2812 |------------------------------------------------------------>| 2813 | FETCH ace-group/GROUPNAME/stale-sids | 2814 | | 2815 |<---------- Stale Sender IDs Response: 2.05 (Content) -------| 2816 | | 2818 Figure 11: Message Flow of Stale Sender IDs Request-Response 2820 Request: 2822 Header: FETCH (Code=0.05) 2823 Uri-Host: "kdc.example.com" 2824 Uri-Path: "ace-group" 2825 Uri-Path: "g1" 2826 Uri-Path: "stale-sids" 2827 Payload (in CBOR diagnostic notation): 2828 42 2830 Response: 2832 Header: Content (Code=2.05) 2833 Payload (in CBOR diagnostic notation): 2834 [h'01', h'fc', h'12ab', h'de44', h'ff'] 2835 Figure 12: Example of Stale Sender IDs Request-Response 2837 21. Default Values for Group Configuration Parameters 2839 This section defines the default values that the Group Manager 2840 assumes for the configuration parameters of an OSCORE group, unless 2841 differently specified when creating and configuring the group. This 2842 can be achieved as specified in [I-D.ietf-ace-oscore-gm-admin]. 2844 21.1. Common 2846 This section always applies, as related to common configuration 2847 parameters. 2849 * For the HKDF Algorithm 'hkdf', the Group Manager SHOULD use the 2850 same default value defined in Section 3.2 of [RFC8613], i.e., HKDF 2851 SHA-256 (COSE algorithm encoding: -10). 2853 * For the format 'pub_key_enc' used to encode the public keys in the 2854 group, the Group Manager SHOULD use a CBOR Web Token 2855 (CWT)[RFC8392] or an unprotected CWT Claim Set 2856 [I-D.ietf-rats-uccs]. 2858 [ This is a pending registration requested by draft-ietf-lake- 2859 edhoc. ] 2861 * For 'max_stale_sets', the Group Manager SHOULD consider N = 3 as 2862 the maximum number of stored sets of stale Sender IDs in the 2863 collection associated to the group (see Section 2.2.1). 2865 21.2. Group Mode 2867 This section applies if the group uses (also) the group mode of Group 2868 OSCORE. 2870 * For the Signature Encryption Algorithm 'sign_enc_alg' used to 2871 encrypted messages protected with the group mode, the Group 2872 Manager SHOULD use AES-CCM-16-64-128 (COSE algorithm encoding: 10) 2873 as default value. 2875 The Group Manager SHOULD use the following default values for the 2876 Signature Algorithm 'sign_alg' and related parameters 'sign_params', 2877 consistently with the "COSE Algorithms" Registry [COSE.Algorithms], 2878 the "COSE Key Types" Registry [COSE.Key.Types] and the "COSE Elliptic 2879 Curves" Registry [COSE.Elliptic.Curves]. 2881 * For the Signature Algorithm 'sign_alg' used to sign messages 2882 protected with the group mode, the signature algorithm EdDSA 2883 [RFC8032]. 2885 * For the parameters 'sign_params' of the Signature Algorithm: 2887 - The array [[OKP], [OKP, Ed25519]], in case EdDSA is assumed or 2888 specified for 'sign_alg'. In particular, this indicates to use 2889 the COSE key type OKP and the elliptic curve Ed25519 [RFC8032]. 2891 - The array [[EC2], [EC2, P-256]], in case ES256 [RFC6979] is 2892 specified for 'sign_alg'. In particular, this indicates to use 2893 the COSE key type EC2 and the elliptic curve P-256. 2895 - The array [[EC2], [EC2, P-384]], in case ES384 [RFC6979] is 2896 specified for 'sign_alg'. In particular, this indicates to use 2897 the COSE key type EC2 and the elliptic curve P-384. 2899 - The array [[EC2], [EC2, P-521]], in case ES512 [RFC6979] is 2900 specified for 'sign_alg'. In particular, this indicates to use 2901 the COSE key type EC2 and the elliptic curve P-521. 2903 - The array [[RSA], [RSA]], in case PS256, PS384 or PS512 2904 [RFC8017] is specified for 'sign_alg'. In particular, this 2905 indicates to use the COSE key type RSA. 2907 21.3. Pairwise Mode 2909 This section applies if the group uses (also) the pairwise mode of 2910 Group OSCORE. 2912 For the AEAD Algorithm 'alg' used to encrypt messages protected with 2913 the pairwise mode, the Group Manager SHOULD use the same default 2914 value defined in Section 3.2 of [RFC8613], i.e., AES-CCM-16-64-128 2915 (COSE algorithm encoding: 10). 2917 For the Pairwise Key Agreement Algorithm 'ecdh_alg' and related 2918 parameters 'ecdh_params', the Group Manager SHOULD use the following 2919 default values, consistently with the "COSE Algorithms" Registry 2920 [COSE.Algorithms], the "COSE Key Types" Registry [COSE.Key.Types] and 2921 the "COSE Elliptic Curves" Registry [COSE.Elliptic.Curves]. 2923 * For the Pairwise Key Agreement Algorithm 'ecdh_alg' used to 2924 compute static-static Diffie-Hellman shared secrets, the ECDH 2925 algorithm ECDH-SS + HKDF-256 specified in Section 6.3.1 of 2926 [I-D.ietf-cose-rfc8152bis-algs]. 2928 * For the parameters 'ecdh_params' of the Pairwise Key Agreement 2929 Algorithm: 2931 - The array [[OKP], [OKP, X25519]], in case EdDSA is assumed or 2932 specified for 'sign_alg'. In particular, this indicates to use 2933 the COSE key type OKP and the elliptic curve X25519 [RFC8032]. 2935 - The array [[EC2], [EC2, P-256]], in case ES256 [RFC6979] is 2936 specified for 'sign_alg'. In particular, this indicates to use 2937 the COSE key type EC2 and the elliptic curve P-256. 2939 - The array [[EC2], [EC2, P-384]], in case ES384 [RFC6979] is 2940 specified for 'sign_alg'. In particular, this indicates to use 2941 the COSE key type EC2 and the elliptic curve P-384. 2943 - The array [[EC2], [EC2, P-521]], in case ES512 [RFC6979] is 2944 specified for 'sign_alg'. In particular, this indicates to use 2945 the COSE key type EC2 and the elliptic curve P-521. 2947 22. Security Considerations 2949 Security considerations for this profile are inherited from 2950 [I-D.ietf-ace-key-groupcomm], the ACE framework for Authentication 2951 and Authorization [I-D.ietf-ace-oauth-authz], and the specific 2952 transport profile of ACE signalled by the AS, such as 2953 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile]. 2955 The following security considerations also apply for this profile. 2957 22.1. Management of OSCORE Groups 2959 This profile leverages the following management aspects related to 2960 OSCORE groups and discussed in the sections of 2961 [I-D.ietf-core-oscore-groupcomm] referred below. 2963 * Management of group keying material (see Section 3.1 of 2964 [I-D.ietf-core-oscore-groupcomm]). The Group Manager is 2965 responsible for the renewal and re-distribution of the keying 2966 material in the groups of its competence (rekeying). According to 2967 the specific application requirements, this can include rekeying 2968 the group upon changes in its membership. In particular, renewing 2969 the group keying material is required upon a new node's joining or 2970 a current node's leaving, in case backward security and forward 2971 security have to be preserved, respectively. 2973 * Provisioning and retrieval of public keys (see Section 2 of 2974 [I-D.ietf-core-oscore-groupcomm]). The Group Manager acts as key 2975 repository of public keys of group members, and provides them upon 2976 request. 2978 * Synchronization of sequence numbers (see Section 6.2 of 2979 [I-D.ietf-core-oscore-groupcomm]). This concerns how a responder 2980 node that has just joined an OSCORE group can synchronize with the 2981 sequence number of requesters in the same group. 2983 Before sending the Joining Response, the Group Manager MUST verify 2984 that the joining node actually owns the associated private key. To 2985 this end, the Group Manager can rely on the proof-of-possession 2986 challenge-response defined in Section 6. Alternatively, the joining 2987 node can use its own public key as asymmetric proof-of-possession key 2988 to establish a secure channel with the Group Manager, e.g., as in 2989 Section 3.2.2 of [I-D.ietf-ace-dtls-authorize]. However, this 2990 requires such proof-of-possession key to be compatible with the 2991 encoding, as well as with the signature algorithm, and possible 2992 associated parameters used in the OSCORE group. 2994 A node may have joined multiple OSCORE groups under different non- 2995 synchronized Group Managers. Therefore, it can happen that those 2996 OSCORE groups have the same Group Identifier (Gid). It follows that, 2997 upon receiving a Group OSCORE message addressed to one of those 2998 groups, the node would have multiple Security Contexts matching with 2999 the Gid in the incoming message. It is up to the application to 3000 decide how to handle such collisions of Group Identifiers, e.g., by 3001 trying to process the incoming message using one Security Context at 3002 the time until the right one is found. 3004 22.2. Size of Nonces as Proof-of-Possesion Challenge 3006 With reference to the Joining Request message in Section 6.2, the 3007 proof-of-possession (PoP) evidence included in 'client_cred_verify' 3008 is computed over an input including also N_C | N_S, where | denotes 3009 concatenation. 3011 For the N_C challenge, it is RECOMMENDED to use a 8-byte long random 3012 nonce. Furthermore, N_C is always conveyed in the 'cnonce' parameter 3013 of the Joining Request, which is always sent over the secure 3014 communication channel between the joining node and the Group Manager. 3016 As defined in Section 6.2.1, the way the N_S value is computed 3017 depends on the particular way the joining node provides the Group 3018 Manager with the Access Token, as well as on following interactions 3019 between the two. 3021 * If the Access Token is not explicitly posted to the /authz-info 3022 endpoint of the Group Manager, then N_S is computed as a 32-byte 3023 long challenge. For an example, see point (2) of Section 6.2.1. 3025 * If the Access Token has been explicitly posted to the /authz-info 3026 endpoint of the Group Manager, N_S takes the most recent value 3027 provided to the client by the Group Manager in the 'kdcchallenge' 3028 parameter, as specified in point (1) of Section 6.2.1. This is 3029 provided either in the 2.01 response to the Token Post (see 3030 Section 6.1), or in a 4.00 response to a following Joining Request 3031 (see Section 6.3). In either case, it is RECOMMENDED to use a 3032 8-byte long random challenge as value for N_S. 3034 If we consider both N_C and N_S to take 8-byte long values, the 3035 following considerations hold. 3037 * Let us consider both N_C and N_S as taking random values, and the 3038 Group Manager to never change the value of the N_S provided to a 3039 Client during the lifetime of an Access Token. Then, as per the 3040 birthday paradox, the average collision for N_S will happen after 3041 2^32 new posted Access Tokens, while the average collision for N_C 3042 will happen after 2^32 new Joining Requests. This amounts to 3043 considerably more token provisionings than the expected new 3044 joinings of OSCORE groups under a same Group Manager, as well as 3045 to considerably more requests to join OSCORE groups from a same 3046 Client using a same Access Token under a same Group Manager. 3048 * Section 7 of [I-D.ietf-ace-oscore-profile] as well Appendix B.2 of 3049 [RFC8613] recommend the use of 8-byte random values as well. 3050 Unlike in those cases, the values of N_C and N_S considered in 3051 this document are not used for as sensitive operations as the 3052 derivation of a Security Context, and thus do not have possible 3053 implications in the security of AEAD ciphers. 3055 22.3. Reusage of Nonces for Proof-of-Possession Input 3057 As long as the Group Manager preserves the same N_S value currently 3058 associated to an Access Token, i.e., the latest value provided to a 3059 Client in a 'kdcchallenge' parameter, the Client is able to 3060 successfully reuse the same proof-of-possession (PoP) input for 3061 multiple Joining Requests to that Group Manager. 3063 In particular, the Client can reuse the same N_C value for every 3064 Joining Request to the Group Manager, and combine it with the same 3065 unchanged N_S value. This results in reusing the same PoP input for 3066 producing the PoP evidence to include in the 'client_cred_verify' 3067 parameter of the Joining Requests. 3069 Unless the Group Manager maintains a list of N_C values already used 3070 by that Client since the latest update to the N_S value associated to 3071 the Access Token, the Group Manager can be forced to falsely believe 3072 that the Client possesses its own private key at that point in time, 3073 upon verifying the PoP evidence in the 'client_cred_verify' 3074 parameter. 3076 23. IANA Considerations 3078 Note to RFC Editor: Please replace all occurrences of "[[This 3079 document]]" with the RFC number of this specification and delete this 3080 paragraph. 3082 This document has the following actions for IANA. 3084 23.1. OAuth Parameters Registry 3086 The following registrations are done for the OAuth Parameters 3087 Registry following the procedure specified in Section 11.2 of 3088 [RFC6749]. 3090 * Parameter name: ecdh_info 3092 * Parameter usage location: client-rs request, rs-client response 3094 * Change Controller: IESG 3096 * Specification Document(s): [[This specification]] 3098 * Parameter name: gm_dh_pub_keys 3100 * Parameter usage location: client-rs request, rs-client response 3102 * Change Controller: IESG 3104 * Specification Document(s): [[This specification]] 3106 23.2. OAuth Parameters CBOR Mappings Registry 3108 The following registrations are done for the OAuth Parameters CBOR 3109 Mappings Registry following the procedure specified in Section 8.10 3110 of [I-D.ietf-ace-oauth-authz]. 3112 * Name: ecdh_info 3114 * CBOR Key: TBD (range -256 to 255) 3115 * Value Type: Simple value Null / array 3117 * Reference: [[This specification]] 3119 * Name: gm_dh_pub_keys 3121 * CBOR Key: TBD (range -256 to 255) 3123 * Value Type: Simple value Null / array 3125 * Reference: [[This specification]] 3127 23.3. ACE Groupcomm Parameters Registry 3129 IANA is asked to register the following entry to the "ACE Groupcomm 3130 Parameters" Registry defined in Section 10.5 of 3131 [I-D.ietf-ace-key-groupcomm]. 3133 * Name: group_senderId 3135 * CBOR Key: TBD 3137 * CBOR Type: Byte string 3139 * Reference: [[This document]] (Section 9) 3141 * Name: kdc_nonce 3143 * CBOR Key: TBD 3145 * CBOR Type: Byte string 3147 * Reference: [[This document]] (Section 6.4) 3149 * Name: kdc_cred 3151 * CBOR Key: TBD 3153 * CBOR Type: Byte string 3155 * Reference: [[This document]] (Section 6.4) 3157 * Name: kdc_cred_verify 3158 * CBOR Key: TBD 3160 * CBOR Type: Byte string 3162 * Reference: [[This document]] (Section 6.4) 3164 * Name: ecdh_info 3166 * CBOR Key: TBD 3168 * CBOR Type: Array 3170 * Reference: [[This document]] (Section 6.3) 3172 * Name: gm_dh_pub_keys 3174 * CBOR Key: TBD 3176 * CBOR Type: Array 3178 * Reference: [[This document]] (Section 6.3) 3180 * Name: group_enc_key 3182 * CBOR Key: TBD 3184 * CBOR Type: Byte String 3186 * Reference: [[This document]] (Section 5.3.1) 3188 * Name: stale_node_ids 3190 * CBOR Key: TBD 3192 * CBOR Type: Array 3194 * Reference: [[This document]] (Section 20) 3196 23.4. ACE Groupcomm Key Registry 3198 IANA is asked to register the following entry to the "ACE Groupcomm 3199 Key" Registry defined in Section 10.6 of 3200 [I-D.ietf-ace-key-groupcomm]. 3202 * Name: Group_OSCORE_Input_Material object 3204 * Key Type Value: GROUPCOMM_KEY_TBD 3206 * Profile: "coap_group_oscore_app", defined in Section 23.5 of this 3207 document. 3209 * Description: A Group_OSCORE_Input_Material object encoded as 3210 described in Section 6.4 of this document. 3212 * Reference: [[This document]] (Section 6.4) 3214 23.5. ACE Groupcomm Profile Registry 3216 IANA is asked to register the following entry to the "ACE Groupcomm 3217 Profile" Registry defined in Section 10.7 of 3218 [I-D.ietf-ace-key-groupcomm]. 3220 * Name: coap_group_oscore_app 3222 * Description: Application profile to provision keying material for 3223 participating in group communication protected with Group OSCORE 3224 as per [I-D.ietf-core-oscore-groupcomm]. 3226 * CBOR Value: PROFILE_TBD 3228 * Reference: [[This document]] (Section 6.4) 3230 23.6. OSCORE Security Context Parameters Registry 3232 IANA is asked to register the following entries in the "OSCORE 3233 Security Context Parameters" Registry defined in Section 9.4 of 3234 [I-D.ietf-ace-oscore-profile]. 3236 * Name: group_SenderId 3238 * CBOR Label: TBD 3240 * CBOR Type: bstr 3242 * Registry: - 3244 * Description: OSCORE Sender ID assigned to a member of an OSCORE 3245 group 3247 * Reference: [[This document]] (Section 6.4) 3248 * Name: pub_key_enc 3250 * CBOR Label: TBD 3252 * CBOR Type: integer 3254 * Registry: COSE Header Parameters 3256 * Description: Encoding of Public Keys to be used in the OSCORE 3257 group 3259 * Reference: [[This document]] (Section 6.4) 3261 * Name: sign_enc_alg 3263 * CBOR Label: TBD 3265 * CBOR Type: tstr / int 3267 * Registry: COSE Algorithms 3269 * Description: OSCORE Signature Encryption Algorithm Value 3271 * Reference: [[This document]] (Section 6.4) 3273 * Name: sign_alg 3275 * CBOR Label: TBD 3277 * CBOR Type: tstr / int 3279 * Registry: COSE Algorithms 3281 * Description: OSCORE Signature Algorithm Value 3283 * Reference: [[This document]] (Section 6.4) 3285 * Name: sign_params 3287 * CBOR Label: TBD 3289 * CBOR Type: array 3291 * Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves 3292 * Description: OSCORE Signature Algorithm Parameters 3294 * Reference: [[This document]] (Section 6.4) 3296 * Name: ecdh_alg 3298 * CBOR Label: TBD 3300 * CBOR Type: tstr / int 3302 * Registry: COSE Algorithms 3304 * Description: OSCORE Pairwise Key Agreement Algorithm Value 3306 * Reference: [[This document]] (Section 6.4) 3308 * Name: ecdh_params 3310 * CBOR Label: TBD 3312 * CBOR Type: array 3314 * Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves 3316 * Description: OSCORE Pairwise Key Agreement Algorithm Parameters 3318 * Reference: [[This document]] (Section 6.4) 3320 23.7. TLS Exporter Label Registry 3322 IANA is asked to register the following entry to the "TLS Exporter 3323 Label" Registry defined in Section 6 of [RFC5705] and updated in 3324 Section 12 of [RFC8447]. 3326 * Value: EXPORTER-ACE-Sign-Challenge-coap-group-oscore-app 3328 * DTLS-OK: Y 3330 * Recommended: N 3332 * Reference: [[This document]] (Section 6.2.1) 3334 23.8. AIF Registry 3336 IANA is asked to register the following entry to the "Toid" sub- 3337 registry of the "AIF" Registry defined in Section 5.2 of 3338 [I-D.ietf-ace-aif]. 3340 * Name: oscore-group-name 3342 * Description/Specification: group name of the OSCORE group, as 3343 specified in [[This document]]. 3345 IANA is asked to register the following entry to the "Tperm" sub- 3346 Registry of the "AIF" Registry defined in Section 5.2 of 3347 [I-D.ietf-ace-aif]. 3349 * Name: oscore-group-roles 3351 * Description/Specification: role(s) of the member of the OSCORE 3352 group, as specified in [[This document]]. 3354 23.9. Media Type Registrations 3356 This document registers the 'application/aif-groupcomm-oscore+cbor' 3357 media type for the AIF specific data model AIF-OSCORE-GROUPCOMM 3358 defined in Section 3 of [[This document]]. This registration follows 3359 the procedures specified in [RFC6838]. 3361 These media type has parameters for specifying the object identifier 3362 ("Toid") and set of permissions ("Tperm") defined for the AIF-generic 3363 model in [I-D.ietf-ace-aif]; default values are the values "oscore- 3364 group-name" for "Toid" and "oscore-group-roles" for "Tperm". 3366 Type name: application 3368 Subtype name: aif-groupcomm-oscore+cbor 3370 Required parameters: "Toid", "Tperm" 3372 Optional parameters: N/A 3374 Encoding considerations: Must be encoded as a CBOR array, each 3375 element of which is an array [Toid, Tperm] as defined in Section 3 of 3376 [[This document]]. 3378 Security considerations: See Section 22 of [[This document]]. 3380 Interoperability considerations: N/A 3381 Published specification: [[This document]] 3383 Applications that use this media type: The type is used by 3384 applications that want to express authorization information about 3385 joining OSCORE groups, as specified in [[This document]]. 3387 Fragment identifier considerations: N/A 3389 Additional information: N/A 3391 Person & email address to contact for further information: 3392 iesg@ietf.org (mailto:iesg@ietf.org) 3394 Intended usage: COMMON 3396 Restrictions on usage: None 3398 Author: Marco Tiloca marco.tiloca@ri.se (mailto:marco.tiloca@ri.se) 3400 Change controller: IESG 3402 Provisional registration? No 3404 23.10. CoAP Content-Format Registry 3406 IANA is asked to register the following entry to the "CoAP Content- 3407 Formats" registry, within the "CoRE Parameters" registry: 3409 Media Type: application/aif-groupcomm-oscore+cbor;Toid="oscore-group- 3410 name",Tperm"oscore-group-roles" 3412 Encoding: - 3414 ID: TBD 3416 Reference: [[This document]] 3418 23.11. Group OSCORE Roles Registry 3420 This document establishes the IANA "Group OSCORE Roles" Registry. 3421 The Registry has been created to use the "Expert Review" registration 3422 procedure [RFC8126]. Expert review guidelines are provided in 3423 Section 23.15. 3425 This registry includes the possible roles that nodes can take in an 3426 OSCORE group, each in combination with a numeric identifier. These 3427 numeric identifiers are used to express authorization information 3428 about joining OSCORE groups, as specified in Section 3 of [[This 3429 document]]. 3431 The columns of this registry are: 3433 * Name: A value that can be used in documents for easier 3434 comprehension, to identify a possible role that nodes can take in 3435 an OSCORE group. 3437 * Value: The numeric identifier for this role. Integer values 3438 greater than 65535 are marked as "Private Use", all other values 3439 use the registration policy "Expert Review" [RFC8126]. 3441 * Description: This field contains a brief description of the role. 3443 * Reference: This contains a pointer to the public specification for 3444 the role. 3446 This registry will be initially populated by the values in Figure 1. 3448 The Reference column for all of these entries will be [[This 3449 document]]. 3451 23.12. CoRE Resource Type Registry 3453 IANA is asked to register a new Resource Type (rt=) Link Target 3454 Attribute in the "Resource Type (rt=) Link Target Attribute Values" 3455 subregistry under the "Constrained Restful Environments (CoRE) 3456 Parameters" [CORE.Parameters] registry. 3458 * Value: "core.osc.gm" 3460 * Description: Group-membership resource of an OSCORE Group Manager. 3462 * Reference: [[This document]] 3464 23.13. ACE Scope Semantics Registry 3466 IANA is asked to register the following entry in the "ACE Scope 3467 Semantics" registry defined in Section 10.12 of 3468 [I-D.ietf-ace-key-groupcomm]. 3470 * Value: SEM_ID_TBD 3471 * Description: Access to OSCORE groups through the ACE Group 3472 Manager. 3474 * Reference: [[This document]] 3476 23.14. ACE Groupcomm Errors 3478 IANA is asked to register the following entry in the "ACE Groupcomm 3479 Errors" registry defined in Section 10.13 of 3480 [I-D.ietf-ace-key-groupcomm]. 3482 * Value: 7 3484 * Description: Signatures not used in the group. 3486 * Reference: [[This document]] 3488 * Value: 8 3490 * Description: Operation permitted only to signature verifiers. 3492 * Reference: [[This document]] 3494 * Value: 9 3496 * Description: Group currently not active. 3498 * Reference: [[This document]] 3500 23.15. Expert Review Instructions 3502 The IANA Registry established in this document is defined as "Expert 3503 Review". This section gives some general guidelines for what the 3504 experts should be looking for, but they are being designated as 3505 experts for a reason so they should be given substantial latitude. 3507 Expert reviewers should take into consideration the following points: 3509 * Clarity and correctness of registrations. Experts are expected to 3510 check the clarity of purpose and use of the requested entries. 3511 Experts should inspect the entry for the considered role, to 3512 verify the correctness of its description against the role as 3513 intended in the specification that defined it. Expert should 3514 consider requesting an opinion on the correctness of registered 3515 parameters from the Authentication and Authorization for 3516 Constrained Environments (ACE) Working Group and the Constrained 3517 RESTful Environments (CoRE) Working Group. 3519 Entries that do not meet these objective of clarity and 3520 completeness should not be registered. 3522 * Duplicated registration and point squatting should be discouraged. 3523 Reviewers are encouraged to get sufficient information for 3524 registration requests to ensure that the usage is not going to 3525 duplicate one that is already registered and that the point is 3526 likely to be used in deployments. 3528 * Experts should take into account the expected usage of roles when 3529 approving point assignment. Given a 'Value' V as code point, the 3530 length of the encoding of (2^(V+1) - 1) should be weighed against 3531 the usage of the entry, considering the resources and capabilities 3532 of devices it will be used on. Additionally, given a 'Value' V as 3533 code point, the length of the encoding of (2^(V+1) - 1) should be 3534 weighed against how many code points resulting in that encoding 3535 length are left, and the resources and capabilities of devices it 3536 will be used on. 3538 * Specifications are recommended. When specifications are not 3539 provided, the description provided needs to have sufficient 3540 information to verify the points above. 3542 24. References 3544 24.1. Normative References 3546 [CORE.Parameters] 3547 IANA, "Constrained RESTful Environments (CoRE) 3548 Parameters", . 3551 [COSE.Algorithms] 3552 IANA, "COSE Algorithms", 3553 . 3556 [COSE.Elliptic.Curves] 3557 IANA, "COSE Elliptic Curves", 3558 . 3561 [COSE.Header.Parameters] 3562 IANA, "COSE Header Parameters", 3563 . 3566 [COSE.Key.Types] 3567 IANA, "COSE Key Types", 3568 . 3571 [I-D.ietf-ace-aif] 3572 Bormann, C., "An Authorization Information Format (AIF) 3573 for ACE", Work in Progress, Internet-Draft, draft-ietf- 3574 ace-aif-03, 24 June 2021, 3575 . 3578 [I-D.ietf-ace-key-groupcomm] 3579 Palombini, F. and M. Tiloca, "Key Provisioning for Group 3580 Communication using ACE", Work in Progress, Internet- 3581 Draft, draft-ietf-ace-key-groupcomm-13, 12 July 2021, 3582 . 3585 [I-D.ietf-ace-oauth-authz] 3586 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 3587 H. Tschofenig, "Authentication and Authorization for 3588 Constrained Environments (ACE) using the OAuth 2.0 3589 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 3590 draft-ietf-ace-oauth-authz-43, 10 July 2021, 3591 . 3594 [I-D.ietf-ace-oscore-profile] 3595 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 3596 "OSCORE Profile of the Authentication and Authorization 3597 for Constrained Environments Framework", Work in Progress, 3598 Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May 3599 2021, . 3602 [I-D.ietf-core-oscore-groupcomm] 3603 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 3604 and J. Park, "Group OSCORE - Secure Group Communication 3605 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 3606 core-oscore-groupcomm-12, 12 July 2021, 3607 . 3610 [I-D.ietf-cose-rfc8152bis-algs] 3611 Schaad, J., "CBOR Object Signing and Encryption (COSE): 3612 Initial Algorithms", Work in Progress, Internet-Draft, 3613 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 3614 . 3617 [I-D.ietf-cose-rfc8152bis-struct] 3618 Schaad, J., "CBOR Object Signing and Encryption (COSE): 3619 Structures and Process", Work in Progress, Internet-Draft, 3620 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 3621 . 3624 [NIST-800-56A] 3625 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 3626 Davis, "Recommendation for Pair-Wise Key-Establishment 3627 Schemes Using Discrete Logarithm Cryptography - NIST 3628 Special Publication 800-56A, Revision 3", April 2018, 3629 . 3632 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3633 Requirement Levels", BCP 14, RFC 2119, 3634 DOI 10.17487/RFC2119, March 1997, 3635 . 3637 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 3638 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 3639 March 2010, . 3641 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 3642 Specifications and Registration Procedures", BCP 13, 3643 RFC 6838, DOI 10.17487/RFC6838, January 2013, 3644 . 3646 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 3647 Algorithm (DSA) and Elliptic Curve Digital Signature 3648 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 3649 2013, . 3651 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 3652 Application Protocol (CoAP)", RFC 7252, 3653 DOI 10.17487/RFC7252, June 2014, 3654 . 3656 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 3657 for Security", RFC 7748, DOI 10.17487/RFC7748, January 3658 2016, . 3660 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 3661 "PKCS #1: RSA Cryptography Specifications Version 2.2", 3662 RFC 8017, DOI 10.17487/RFC8017, November 2016, 3663 . 3665 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 3666 Signature Algorithm (EdDSA)", RFC 8032, 3667 DOI 10.17487/RFC8032, January 2017, 3668 . 3670 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3671 Writing an IANA Considerations Section in RFCs", BCP 26, 3672 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3673 . 3675 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3676 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3677 May 2017, . 3679 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3680 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3681 . 3683 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 3684 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 3685 . 3687 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 3688 Definition Language (CDDL): A Notational Convention to 3689 Express Concise Binary Object Representation (CBOR) and 3690 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 3691 June 2019, . 3693 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 3694 "Object Security for Constrained RESTful Environments 3695 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 3696 . 3698 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 3699 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 3700 . 3702 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 3703 Representation (CBOR)", STD 94, RFC 8949, 3704 DOI 10.17487/RFC8949, December 2020, 3705 . 3707 24.2. Informative References 3709 [I-D.ietf-ace-dtls-authorize] 3710 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 3711 L. Seitz, "Datagram Transport Layer Security (DTLS) 3712 Profile for Authentication and Authorization for 3713 Constrained Environments (ACE)", Work in Progress, 3714 Internet-Draft, draft-ietf-ace-dtls-authorize-18, 4 June 3715 2021, . 3718 [I-D.ietf-ace-oscore-gm-admin] 3719 Tiloca, M., Hoeglund, R., Stok, P. V. D., Palombini, F., 3720 and K. Hartke, "Admin Interface for the OSCORE Group 3721 Manager", Work in Progress, Internet-Draft, draft-ietf- 3722 ace-oscore-gm-admin-03, 12 July 2021, 3723 . 3726 [I-D.ietf-core-coap-pubsub] 3727 Koster, M., Keranen, A., and J. Jimenez, "Publish- 3728 Subscribe Broker for the Constrained Application Protocol 3729 (CoAP)", Work in Progress, Internet-Draft, draft-ietf- 3730 core-coap-pubsub-09, 30 September 2019, 3731 . 3734 [I-D.ietf-core-groupcomm-bis] 3735 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 3736 for the Constrained Application Protocol (CoAP)", Work in 3737 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 3738 04, 12 July 2021, . 3741 [I-D.ietf-cose-cbor-encoded-cert] 3742 Raza, S., Hoeglund, J., Selander, G., Mattsson, J. P., 3743 and M. Furuhed, "CBOR Encoded X.509 Certificates (C509 3744 Certificates)", Work in Progress, Internet-Draft, draft- 3745 ietf-cose-cbor-encoded-cert-01, 25 May 2021, 3746 . 3749 [I-D.ietf-rats-uccs] 3750 Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C. 3751 Bormann, "A CBOR Tag for Unprotected CWT Claims Sets", 3752 Work in Progress, Internet-Draft, draft-ietf-rats-uccs-00, 3753 19 May 2021, . 3756 [I-D.tiloca-core-oscore-discovery] 3757 Tiloca, M., Amsuess, C., and P. V. D. Stok, "Discovery of 3758 OSCORE Groups with the CoRE Resource Directory", Work in 3759 Progress, Internet-Draft, draft-tiloca-core-oscore- 3760 discovery-09, 12 July 2021, 3761 . 3764 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 3765 Key Derivation Function (HKDF)", RFC 5869, 3766 DOI 10.17487/RFC5869, May 2010, 3767 . 3769 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3770 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 3771 January 2012, . 3773 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 3774 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 3775 . 3777 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 3778 RFC 6749, DOI 10.17487/RFC6749, October 2012, 3779 . 3781 [RFC7641] Hartke, K., "Observing Resources in the Constrained 3782 Application Protocol (CoAP)", RFC 7641, 3783 DOI 10.17487/RFC7641, September 2015, 3784 . 3786 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 3787 Security (TLS) / Datagram Transport Layer Security (DTLS) 3788 Profiles for the Internet of Things", RFC 7925, 3789 DOI 10.17487/RFC7925, July 2016, 3790 . 3792 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 3793 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 3794 May 2018, . 3796 Appendix A. Profile Requirements 3798 This appendix lists the specifications on this application profile of 3799 ACE, based on the requirements defined in Appendix A of 3800 [I-D.ietf-ace-key-groupcomm]. 3802 * REQ1 - If the value of the GROUPNAME URI path and the group name 3803 in the Access Token scope (gname in Section 3.1 of 3804 [I-D.ietf-ace-key-groupcomm]) do not match, specify the mechanism 3805 to map the GROUPNAME value in the URI to the group name: not 3806 applicable, since a match is required. 3808 * REQ2 - Specify the encoding and value of roles, for scope entries 3809 of 'scope': see Section 3 and Section 4.1. 3811 * REQ3 - if used, specify the acceptable values for 'sign_alg': 3812 values from the "Value" column of the "COSE Algorithms" Registry 3813 [COSE.Algorithms]. 3815 * REQ4 - If used, specify the acceptable values for 3816 'sign_parameters': format and values from the COSE algorithm 3817 capabilities as specified in the "COSE Algorithms" Registry 3818 [COSE.Algorithms]. 3820 * REQ5 - If used, specify the acceptable values for 3821 'sign_key_parameters': format and values from the COSE key type 3822 capabilities as specified in the "COSE Key Types" Registry 3823 [COSE.Key.Types]. 3825 * REQ6 - Specify the acceptable formats for encoding public keys 3826 and, if used, the acceptable values for 'pub_key_enc': acceptable 3827 formats explicitly provide the full set of information related to 3828 the public key algorithm (see Section 6.1 and Section 6.4). 3829 Consistent acceptable values for 'pub_key_enc' are taken from the 3830 "Label" column of the "COSE Header Parameters" Registry 3831 [COSE.Header.Parameters]. 3833 * REQ7 - Register a Resource Type for the root url-path, which is 3834 used to discover the correct url to access at the KDC (see 3835 Section 4.1 of [I-D.ietf-ace-key-groupcomm]): the Resource Type 3836 (rt=) Link Target Attribute value "core.osc.gm" is registered in 3837 Section 23.12. 3839 * REQ8 - Define what operations (e.g., CoAP methods) are allowed on 3840 each resource, for each role defined in REQ2: see Section 5.5. 3842 * REQ9 - Specify the exact encoding of group identifier (see 3843 Section 4.1.1.1 of [I-D.ietf-ace-key-groupcomm]): CBOR byte string 3844 (see Section 17). 3846 * REQ10 - Format of the 'key' value: see Section 6.4. 3848 * REQ11 - Acceptable values of 'gkty': Group_OSCORE_Input_Material 3849 object (see Section 6.4). 3851 * REQ12 - Specify the format of the identifiers of group members: 3852 the Sender ID used in the OSCORE group (see Section 6.4 and 3853 Section 10). 3855 * REQ13 - Specify the communication protocol that the members of the 3856 group must use: CoAP [RFC7252], possibly over IP multicast 3857 [I-D.ietf-core-groupcomm-bis]. 3859 * REQ14 - Specify the security protocols that the group members must 3860 use to protect their communication: Group OSCORE 3861 [I-D.ietf-core-oscore-groupcomm]. 3863 * REQ15 - Specify and register the application profile identifier: 3864 coap_group_oscore_app (see Section 23.5). 3866 * REQ16 - Specify policies at the KDC to handle member ids that are 3867 not included in 'get_pub_keys': see Section 10. 3869 * REQ17 - If used, specify the format and content of 3870 'group_policies' and its entries: see Section 6.4. 3872 * REQ18 - Specify the format of newly-generated individual keying 3873 material for group members, or of the information to derive it, 3874 and corresponding CBOR label: see Section 9. 3876 * REQ19 - Specify how the communication is secured between the 3877 Client and KDC: by means of any transport profile of ACE 3878 [I-D.ietf-ace-oauth-authz] between Client and Group Manager that 3879 complies with the requirements in Appendix C of 3880 [I-D.ietf-ace-oauth-authz]. 3882 * REQ20 - Specify the exact approaches used to compute and verify 3883 the PoP evidence to include in 'client_cred_verify', and which of 3884 those approaches is used in which case: see Section 6.2 and 3885 Section 6.3. 3887 * REQ21 - Specify how the nonce N_S is generated, if the token is 3888 not being posted (e.g., if it is used directly to validate TLS 3889 instead): see Section 6.2.1. 3891 * REQ22 - Specify if 'mgt_key_material' is used, and if yes specify 3892 its format and content: not used in this version of the profile. 3894 * REQ23 - Define the initial value of the 'num' parameter: The 3895 initial value MUST be set to 0 when creating the OSCORE group, 3896 e.g., as in [I-D.ietf-ace-oscore-gm-admin]. 3898 * REQ24 - Specify and register the identifier of newly defined 3899 semantics for binary scopes: see Section 23.13. 3901 * OPT1 (Optional) - Specify the negotiation of parameter values for 3902 signature algorithm and signature keys, if 'sign_info' is not 3903 used: possible early discovery by using the approach based on the 3904 CoRE Resource Directory described in 3905 [I-D.tiloca-core-oscore-discovery]. 3907 * OPT2 (Optional) - Specify additional parameters used in the Token 3908 Post exchange: 'ecdh_info', to negotiate the ECDH algorithm, ECDH 3909 algorithm parameters, ECDH key parameters and exact encoding of 3910 public keys used in the group, in case the joining node supports 3911 the pairwise mode of Group OSCORE. 3913 * OPT3 (Optional) - Specify the encoding of 'pub_keys_repos' if the 3914 default is not used: no. 3916 * OPT4 (Optional) - Specify policies that instruct clients to retain 3917 unsuccessfully decrypted messages and for how long, so that they 3918 can be decrypted after getting updated keying material: no. 3920 * OPT5 (Optional) - Specify possible or required payload formats for 3921 specific error cases: send a 4.00 (Bad Request) response to a 3922 Joining Request (see Section 6.3). 3924 * OPT6 (Optional) - Specify the behavior of the handler in case of 3925 failure to retrieve a public key for the specific node: send a 3926 4.00 (Bad Request) response to a Joining Request (see 3927 Section 6.3). 3929 * OPT7 (Optional) - Specify CBOR values to use for abbreviating 3930 identifiers of roles in the group or topic: see Section 4.1. 3932 * OPT8 (Optional) - Specify for the KDC to perform group rekeying 3933 (together or instead of renewing individual keying material) when 3934 receiving a Key Renewal Request: the Group Manager SHOULD NOT 3935 perform a group rekeying, unless already scheduled to occur 3936 shortly (see Section 9). 3938 * OPT9 (Optional) - Specify the functionalities implemented at the 3939 'control_uri' resource hosted at the Client, including message 3940 exchange encoding and other details (see Section 4.1.2.1 of 3941 [I-D.ietf-ace-key-groupcomm]): see Section 19 for the eviction of 3942 a group member; see Section 20 for the group rekeying process. 3944 * OPT10 (Optional) - Specify how the identifier of the sender's 3945 public key is included in the group request: no. 3947 * OPT11 (Optional) - Specify additional identifiers of error types, 3948 as values of the 'error' field in an error response from the KDC: 3949 see Section 23.14. 3951 Appendix B. Extensibility for Future COSE Algorithms 3953 As defined in Section 8.1 of [I-D.ietf-cose-rfc8152bis-algs], future 3954 algorithms can be registered in the "COSE Algorithms" Registry 3955 [COSE.Algorithms] as specifying none or multiple COSE capabilities. 3957 To enable the seamless use of such future registered algorithms, this 3958 section defines a general, agile format for: 3960 * Each 'ecdh_info_entry' of the 'ecdh_info' parameter in the Token 3961 Post response, see Section 6.1 and Section 6.1.1; 3963 * The 'sign_params' and 'ecdh_params' parameters within the 'key' 3964 parameter, see Section 6.4, as part of the response payloads used 3965 in Section 6.4, Section 8.1, Section 8.2 and Section 20. 3967 Appendix B of [I-D.ietf-ace-key-groupcomm] describes the analogous 3968 general format for 'sign_info_entry' of the 'sign_info' parameter in 3969 the Token Post response, see Section 6.1. 3971 If any of the currently registered COSE algorithms is considered, 3972 using this general format yields the same structure defined in this 3973 document for the items above, thus ensuring retro-compatibility. 3975 B.1. Format of 'ecdh_info_entry' 3977 The format of each 'ecdh_info_entry' (see Section 6.1 and 3978 Section 6.1.1) is generalized as follows. Given N the number of 3979 elements of the 'ecdh_parameters' array, i.e., the number of COSE 3980 capabilities of the ECDH algorithm, then: 3982 * 'ecdh_key_parameters' is replaced by N elements 'ecdh_capab_i', 3983 each of which is a CBOR array. 3985 * The i-th array following 'ecdh_parameters', i.e., 'ecdh_capab_i' 3986 (i = 0, ..., N-1), is the array of COSE capabilities for the 3987 algorithm capability specified in 'ecdh_parameters'[i]. 3989 ecdh_info_entry = 3990 [ 3991 id : gname / [ + gname ], 3992 ecdh_alg : int / tstr, 3993 ecdh_parameters : [ alg_capab_1 : any, 3994 alg_capab_2 : any, 3995 ..., 3996 alg_capab_N : any], 3997 ecdh_capab_1 : [ any ], 3998 ecdh_capab_2 : [ any ], 3999 ..., 4000 ecdh_capab_N : [ any ], 4001 pub_key_enc = int / nil 4002 ] 4004 gname = tstr 4006 Figure 13: 'ecdh_info_entry' with general format 4008 B.2. Format of 'key' 4010 The format of 'key' (see Section 6.4) is generalized as follows. 4012 * The 'sign_params' array includes N+1 elements, whose exact 4013 structure and value depend on the value of the signature algorithm 4014 specified in 'sign_alg'. 4016 - The first element, i.e., 'sign_params'[0], is the array of the 4017 N COSE capabilities for the signature algorithm, as specified 4018 for that algorithm in the "Capabilities" column of the "COSE 4019 Algorithms" Registry [COSE.Algorithms] (see Section 8.1 of 4020 [I-D.ietf-cose-rfc8152bis-algs]). 4022 - Each following element 'sign_params'[i], i.e., with index i > 4023 0, is the array of COSE capabilities for the algorithm 4024 capability specified in 'sign_params'[0][i-1]. 4026 For example, if 'sign_params'[0][0] specifies the key type as 4027 capability of the algorithm, then 'sign_params'[1] is the array of 4028 COSE capabilities for the COSE key type associated to the 4029 signature algorithm, as specified for that key type in the 4030 "Capabilities" column of the "COSE Key Types" Registry 4031 [COSE.Key.Types] (see Section 8.2 of 4032 [I-D.ietf-cose-rfc8152bis-algs]). 4034 * The 'ecdh_params' array includes M+1 elements, whose exact 4035 structure and value depend on the value of the ECDH algorithm 4036 specified in 'ecdh_alg'. 4038 - The first element, i.e., 'ecdh_params'[0], is the array of the 4039 M COSE capabilities for the ECDH algorithm, as specified for 4040 that algorithm in the "Capabilities" column of the "COSE 4041 Algorithms" Registry [COSE.Algorithms] (see Section 8.1 of 4042 [I-D.ietf-cose-rfc8152bis-algs]). 4044 - Each following element 'ecdh_params'[i], i.e., with index i > 4045 0, is the array of COSE capabilities for the algorithm 4046 capability specified in 'ecdh_params'[0][i-1]. 4048 For example, if 'ecdh_params'[0][0] specifies the key type as 4049 capability of the algorithm, then 'ecdh_params'[1] is the array of 4050 COSE capabilities for the COSE key type associated to the ECDH 4051 algorithm, as specified for that key type in the "Capabilities" 4052 column of the "COSE Key Types" Registry [COSE.Key.Types] (see 4053 Section 8.2 of [I-D.ietf-cose-rfc8152bis-algs]). 4055 Appendix C. Document Updates 4057 RFC EDITOR: PLEASE REMOVE THIS SECTION. 4059 C.1. Version -10 to -11 4061 * Removed redundancy of key type capabilities, from 'sign_info', 4062 'ecdh_info' and 'key'. 4064 * New resource to retrieve the Group Manager's public key. 4066 * New resource to retrieve material for Signature Verifiers. 4068 * New parameter 'sign_enc_alg' related to the group mode. 4070 * 'pub_key_enc' takes value from the COSE Header Parameters 4071 registry. 4073 * Improved alignment of the Joining Response payload with the Group 4074 OSCORE Security Context parameters. 4076 * Recycling Group IDs by tracking "Birth GIDs". 4078 * Error handling in case of non available Sender IDs upon joining. 4080 * Error handling in case EdDSA public keys with invalid Y coordinate 4081 when the pairwise mode of Group OSCORE is supported. 4083 * Generalized proof-of-possession (PoP) for the joining node's 4084 private key; defined Diffie-Hellman based PoP for OSCORE groups 4085 using only the pairwise mode. 4087 * Proof-of-possession of the Group Manager's private key in the 4088 Joining Response. 4090 * Always use 'peer_identifiers' to convey Sender IDs as node 4091 identifiers. 4093 * Stale Sender IDs provided when rekeying the group. 4095 * New resource for late retrieval of stale Sender IDs. 4097 * Added examples of message exchanges. 4099 * Revised default values of group configuration parameters. 4101 * Fixes to IANA registrations. 4103 * General format of parameters related to COSE capabilities, 4104 supporting future registered COSE algorithms (new Appendix). 4106 C.2. Version -09 to -10 4108 * Updated non-recycling policy of Sender IDs. 4110 * Removed policies about Sender Sequence Number synchronization. 4112 * 'control_path' renamed to 'control_uri'. 4114 * Format of 'get_pub_keys' aligned with draft-ietf-ace-key- 4115 groupcomm. 4117 * Additional way to inform of group eviction. 4119 * Registered semantics identifier for extended scope format. 4121 * Extended error handling, with error type specified in some error 4122 responses. 4124 * Renumbered requirements. 4126 C.3. Version -08 to -09 4128 * The url-path "ace-group" is used. 4130 * Added overview of admitted methods on the Group Manager resources. 4132 * Added exchange of parameters relevant for the pairwise mode of 4133 Group OSCORE. 4135 * The signed value for 'client_cred_verify' includes also the scope. 4137 * Renamed the key material object as Group_OSCORE_Input_Material 4138 object. 4140 * Replaced 'clientId' with 'group_SenderId'. 4142 * Added message exchange for Group Names request-response. 4144 * No reassignment of Sender ID and Gid in the same OSCORE group. 4146 * Updates on group rekeying contextual with request of new Sender 4147 ID. 4149 * Signature verifiers can also retrieve Group Names and URIs. 4151 * Removed group policy about supporting Group OSCORE in pairwise 4152 mode. 4154 * Registration of the resource type rt="core.osc.gm". 4156 * Update list of requirements. 4158 * Clarifications and editorial revision. 4160 C.4. Version -07 to -08 4162 * AIF specific data model to express scope entries. 4164 * A set of roles is checked as valid when processing the Joining 4165 Request. 4167 * Updated format of 'get_pub_keys' in the Joining Request. 4169 * Payload format and default values of group policies in the Joining 4170 Response. 4172 * Updated payload format of the FETCH request to retrieve public 4173 keys. 4175 * Default values for group configuration parameters. 4177 * IANA registrations to support the AIF specific data model. 4179 C.5. Version -06 to -07 4181 * Alignments with draft-ietf-core-oscore-groupcomm. 4183 * New format of 'sign_info', using the COSE capabilities. 4185 * New format of Joining Response parameters, using the COSE 4186 capabilities. 4188 * Considerations on group rekeying. 4190 * Editorial revision. 4192 C.6. Version -05 to -06 4194 * Added role of external signature verifier. 4196 * Parameter 'rsnonce' renamed to 'kdcchallenge'. 4198 * Parameter 'kdcchallenge' may be omitted in some cases. 4200 * Clarified difference between group name and OSCORE Gid. 4202 * Removed the role combination ["requester", "monitor"]. 4204 * Admit implicit scope and audience in the Authorization Request. 4206 * New format for the 'sign_info' parameter. 4208 * Scope not mandatory to include in the Joining Request. 4210 * Group policy about supporting Group OSCORE in pairwise mode. 4212 * Possible individual rekeying of a single requesting node combined 4213 with a group rekeying. 4215 * Security considerations on reusage of signature challenges. 4217 * Addressing optional requirement OPT8 from draft-ietf-ace-key- 4218 groupcomm 4220 * Editorial improvements. 4222 C.7. Version -04 to -05 4224 * Nonce N_S also in error responses to the Joining Requests. 4226 * Supporting single Access Token for multiple groups/topics. 4228 * Supporting legal requesters/responders using the 'peer_roles' 4229 parameter. 4231 * Registered and used dedicated label for TLS Exporter. 4233 * Added method for uploading a new public key to the Group Manager. 4235 * Added resource and method for retrieving the current group status. 4237 * Fixed inconsistency in retrieving group keying material only. 4239 * Clarified retrieval of keying material for monitor-only members. 4241 * Clarification on incrementing version number when rekeying the 4242 group. 4244 * Clarification on what is re-distributed with the group rekeying. 4246 * Security considerations on the size of the nonces used for the 4247 signature challenge. 4249 * Added CBOR values to abbreviate role identifiers in the group. 4251 C.8. Version -03 to -04 4253 * New abstract. 4255 * Moved general content to draft-ietf-ace-key-groupcomm 4257 * Terminology: node name; node resource. 4259 * Creation and pointing at node resource. 4261 * Updated Group Manager API (REST methods and offered services). 4263 * Size of challenges 'cnonce' and 'rsnonce'. 4265 * Value of 'rsnonce' for reused or non-traditionally-posted tokens. 4267 * Removed reference to RFC 7390. 4269 * New requirements from draft-ietf-ace-key-groupcomm 4271 * Editorial improvements. 4273 C.9. Version -02 to -03 4275 * New sections, aligned with the interface of ace-key-groupcomm . 4277 * Exchange of information on the signature algorithm and related 4278 parameters, during the Token POST (Section 4.1). 4280 * Nonce 'rsnonce' from the Group Manager to the Client 4281 (Section 4.1). 4283 * Client PoP signature in the Key Distribution Request upon joining 4284 (Section 4.2). 4286 * Local actions on the Group Manager, upon a new node's joining 4287 (Section 4.2). 4289 * Local actions on the Group Manager, upon a node's leaving 4290 (Section 12). 4292 * IANA registration in ACE Groupcomm Parameters Registry. 4294 * More fulfilled profile requirements (Appendix A). 4296 C.10. Version -01 to -02 4298 * Editorial fixes. 4300 * Changed: "listener" to "responder"; "pure listener" to "monitor". 4302 * Changed profile name to "coap_group_oscore_app", to reflect it is 4303 an application profile. 4305 * Added the 'type' parameter for all requests to a Join Resource. 4307 * Added parameters to indicate the encoding of public keys. 4309 * Challenge-response for proof-of-possession of signature keys 4310 (Section 4). 4312 * Renamed 'key_info' parameter to 'sign_info'; updated its format; 4313 extended to include also parameters of the signature key 4314 (Section 4.1). 4316 * Code 4.00 (Bad request), in responses to joining nodes providing 4317 an invalid public key (Section 4.3). 4319 * Clarifications on provisioning and checking of public keys 4320 (Sections 4 and 6). 4322 * Extended discussion on group rekeying and possible different 4323 approaches (Section 7). 4325 * Extended security considerations: proof-of-possession of signature 4326 keys; collision of OSCORE Group Identifiers (Section 8). 4328 * Registered three entries in the IANA Registry "Sequence Number 4329 Synchronization Method Registry" (Section 9). 4331 * Registered one public key encoding in the "ACE Public Key 4332 Encoding" IANA Registry (Section 9). 4334 C.11. Version -00 to -01 4336 * Changed name of 'req_aud' to 'audience' in the Authorization 4337 Request (Section 3.1). 4339 * Added negotiation of signature algorithm/parameters between Client 4340 and Group Manager (Section 4). 4342 * Updated format of the Key Distribution Response as a whole 4343 (Section 4.3). 4345 * Added parameter 'cs_params' in the 'key' parameter of the Key 4346 Distribution Response (Section 4.3). 4348 * New IANA registrations in the "ACE Authorization Server Request 4349 Creation Hints" Registry, "ACE Groupcomm Key" Registry, "OSCORE 4350 Security Context Parameters" Registry and "ACE Groupcomm Profile" 4351 Registry (Section 9). 4353 Acknowledgments 4355 The authors sincerely thank Christian Amsuess, Santiago Aragon, 4356 Stefan Beck, Carsten Bormann, Martin Gunnarsson, Rikard Hoeglund, 4357 Daniel Migault, Jim Schaad, Ludwig Seitz, Goeran Selander and Peter 4358 van der Stok for their comments and feedback. 4360 The work on this document has been partly supported by VINNOVA and 4361 the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home 4362 (Grant agreement 952652); and by the EIT-Digital High Impact 4363 Initiative ACTIVE. 4365 Authors' Addresses 4367 Marco Tiloca 4368 RISE AB 4369 Isafjordsgatan 22 4370 SE-164 29 Stockholm Kista 4371 Sweden 4373 Email: marco.tiloca@ri.se 4375 Jiye Park 4376 Universitaet Duisburg-Essen 4377 Schuetzenbahn 70 4378 45127 Essen 4379 Germany 4381 Email: ji-ye.park@uni-due.de 4383 Francesca Palombini 4384 Ericsson AB 4385 Torshamnsgatan 23 4386 SE-16440 Stockholm Kista 4387 Sweden 4389 Email: francesca.palombini@ericsson.com