idnits 2.17.1 draft-ietf-ace-oscore-gm-admin-02.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 8 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2021) is 1159 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1008 -- Looks like a reference, but probably isn't: '6' on line 1008 == Outdated reference: A later version (-18) exists of draft-ietf-ace-key-groupcomm-11 == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-10 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-37 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-16 == Outdated reference: A later version (-06) exists of draft-ietf-core-coral-03 == Outdated reference: A later version (-11) exists of draft-ietf-core-groupcomm-bis-03 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-11 ** 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' == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-15 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-26 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-41 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-08 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group M. Tiloca 3 Internet-Draft R. Hoeglund 4 Intended status: Standards Track RISE AB 5 Expires: August 26, 2021 P. van der Stok 6 Consultant 7 F. Palombini 8 K. Hartke 9 Ericsson AB 10 February 22, 2021 12 Admin Interface for the OSCORE Group Manager 13 draft-ietf-ace-oscore-gm-admin-02 15 Abstract 17 Group communication for CoAP can be secured using Group Object 18 Security for Constrained RESTful Environments (Group OSCORE). A 19 Group Manager is responsible to handle the joining of new group 20 members, as well as to manage and distribute the group key material. 21 This document defines a RESTful admin interface at the Group Manager, 22 that allows an Administrator entity to create and delete OSCORE 23 groups, as well as to retrieve and update their configuration. The 24 ACE framework for Authentication and Authorization is used to enforce 25 authentication and authorization of the Administrator at the Group 26 Manager. Protocol-specific transport profiles of ACE are used to 27 achieve communication security, proof-of-possession and server 28 authentication. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 26, 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Group Administration . . . . . . . . . . . . . . . . . . . . 6 67 2.1. Getting Access to the Group Manager . . . . . . . . . . . 7 68 2.1.1. Format of Scope . . . . . . . . . . . . . . . . . . . 8 69 2.2. Managing OSCORE Groups . . . . . . . . . . . . . . . . . 9 70 2.3. Collection Representation . . . . . . . . . . . . . . . . 10 71 2.4. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10 72 3. Group Configurations . . . . . . . . . . . . . . . . . . . . 10 73 3.1. Group Configuration Representation . . . . . . . . . . . 10 74 3.1.1. Configuration Properties . . . . . . . . . . . . . . 10 75 3.1.2. Status Properties . . . . . . . . . . . . . . . . . . 12 76 3.2. Default Values . . . . . . . . . . . . . . . . . . . . . 13 77 3.2.1. Configuration Parameters . . . . . . . . . . . . . . 13 78 3.2.2. Status Parameters . . . . . . . . . . . . . . . . . . 14 79 4. Interactions with the Group Manager . . . . . . . . . . . . . 14 80 4.1. Retrieve the Full List of Groups Configurations . . . . . 14 81 4.2. Retrieve a List of Group Configurations by Filters . . . 15 82 4.3. Create a New Group Configuration . . . . . . . . . . . . 16 83 4.4. Retrieve a Group Configuration . . . . . . . . . . . . . 21 84 4.5. Retrieve Part of a Group Configuration by Filters . . . . 23 85 4.6. Overwrite a Group Configuration . . . . . . . . . . . . . 25 86 4.6.1. Effects on Joining Nodes . . . . . . . . . . . . . . 27 87 4.6.2. Effects on the Group Members . . . . . . . . . . . . 28 88 4.7. Selective Update of a Group Configuration . . . . . . . . 29 89 4.7.1. Effects on Joining Nodes . . . . . . . . . . . . . . 34 90 4.7.2. Effects on the Group Members . . . . . . . . . . . . 34 91 4.8. Delete a Group Configuration . . . . . . . . . . . . . . 34 92 4.8.1. Effects on the Group Members . . . . . . . . . . . . 35 93 5. Security Considerations . . . . . . . . . . . . . . . . . . . 35 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 95 6.1. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 36 96 6.2. Resource Types . . . . . . . . . . . . . . . . . . . . . 38 97 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 98 7.1. Normative References . . . . . . . . . . . . . . . . . . 38 99 7.2. Informative References . . . . . . . . . . . . . . . . . 40 100 Appendix A. Document Updates . . . . . . . . . . . . . . . . . . 41 101 A.1. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 41 102 A.2. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 42 103 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 42 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 106 1. Introduction 108 The Constrained Application Protocol (CoAP) [RFC7252] can be used in 109 group communication environments where messages are also exchanged 110 over IP multicast [I-D.ietf-core-groupcomm-bis]. Applications 111 relying on CoAP can achieve end-to-end security at the application 112 layer by using Object Security for Constrained RESTful Environments 113 (OSCORE) [RFC8613], and especially Group OSCORE 114 [I-D.ietf-core-oscore-groupcomm] in group communication scenarios. 116 When group communication for CoAP is protected with Group OSCORE, 117 nodes are required to explicitly join the correct OSCORE group. To 118 this end, a joining node interacts with a Group Manager (GM) entity 119 responsible for that group, and retrieves the required key material 120 to securely communicate with other group members using Group OSCORE. 122 The method in [I-D.ietf-ace-key-groupcomm-oscore] specifies how nodes 123 can join an OSCORE group through the respective Group Manager. Such 124 a method builds on the ACE framework for Authentication and 125 Authorization [I-D.ietf-ace-oauth-authz], so ensuring a secure 126 joining process as well as authentication and authorization of 127 joining nodes (clients) at the Group Manager (resource server). 129 In some deployments, the application running on the Group Manager may 130 know when a new OSCORE group has to be created, as well as how it 131 should be configured and later on updated or deleted, e.g. based on 132 the current application state or on pre-installed policies. In this 133 case, the Group Manager application can create and configure OSCORE 134 groups when needed, by using a local application interface. However, 135 this requires the Group Manager to be application-specific, which in 136 turn leads to error prone deployments and is poorly flexible. 138 In other deployments, a separate Administrator entity, such as a 139 Commissioning Tool, is directly responsible for creating and 140 configuring the OSCORE groups at a Group Manager, as well as for 141 maintaining them during their whole lifetime until their deletion. 143 This allows the Group Manager to be agnostic of the specific 144 applications using secure group communication. 146 This document specifies a RESTful admin interface at the Group 147 Manager, intended for an Administrator as a separate entity external 148 to the Group Manager and its application. The interface allows the 149 Administrator to create and delete OSCORE groups, as well as to 150 configure and update their configuration. 152 Interaction examples are provided, in Link Format [RFC6690] and CBOR 153 [RFC8949], as well as in CoRAL [I-D.ietf-core-coral]. While all the 154 CoRAL examples show the CoRAL textual serialization format, its 155 binary serialization format is used on the wire. 157 The ACE framework is used to ensure authentication and authorization 158 of the Administrator (client) at the Group Manager (resource server). 159 In order to achieve communication security, proof-of-possession and 160 server authentication, the Administrator and the Group Manager 161 leverage protocol-specific transport profiles of ACE, such as 162 [I-D.ietf-ace-oscore-profile][I-D.ietf-ace-dtls-authorize]. These 163 include also possible forthcoming transport profiles that comply with 164 the requirements in Appendix C of [I-D.ietf-ace-oauth-authz]. 166 1.1. Terminology 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 170 "OPTIONAL" in this document are to be interpreted as described in BCP 171 14 [RFC2119] [RFC8174] when, and only when, they appear in all 172 capitals, as shown here. 174 Readers are expected to be familiar with the terms and concepts from 175 the following specifications: 177 o CBOR [RFC8949] and COSE 178 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs]. 180 o The CoAP protocol [RFC7252], also in group communication scenarios 181 [I-D.ietf-core-groupcomm-bis]. These include the concepts of: 183 * "application group", as a set of CoAP nodes that share a common 184 set of resources; and of 186 * "security group", as a set of CoAP nodes that share the same 187 security material, and use it to protect and verify exchanged 188 messages. 190 o The OSCORE [RFC8613] and Group OSCORE 191 [I-D.ietf-core-oscore-groupcomm] security protocols. These 192 include the concept of Group Manager, as the entity responsible 193 for a set of OSCORE groups where communications among members are 194 secured using Group OSCORE. An OSCORE group is used as security 195 group for one or many application groups. 197 o The ACE framework for authentication and authorization 198 [I-D.ietf-ace-oauth-authz]. The terminology for entities in the 199 considered architecture is defined in OAuth 2.0 [RFC6749]. In 200 particular, this includes Client (C), Resource Server (RS), and 201 Authorization Server (AS). 203 o The management of keying material for groups in ACE 204 [I-D.ietf-ace-key-groupcomm] and specifically for OSCORE groups 205 [I-D.ietf-ace-key-groupcomm-oscore]. These include the concept of 206 group-membership resource hosted by the Group Manager, that new 207 members access to join the OSCORE group, while current members can 208 access to retrieve updated keying material. 210 Note that, unless otherwise indicated, the term "endpoint" is used 211 here following its OAuth definition, aimed at denoting resources such 212 as /token and /introspect at the AS, and /authz-info at the RS. This 213 document does not use the CoAP definition of "endpoint", which is "An 214 entity participating in the CoAP protocol". 216 This document also refers to the following terminology. 218 o Administrator: entity responsible to create, configure and delete 219 OSCORE groups at a Group Manager. 221 o Group name: stable and invariant name of an OSCORE group. The 222 group name MUST be unique under the same Group Manager, and MUST 223 include only characters that are valid for a URI path segment. 225 o Group-collection resource: a single-instance resource hosted by 226 the Group Manager. An Administrator accesses a group-collection 227 resource to create a new OSCORE group, or to retrieve the list of 228 existing OSCORE groups, under that Group Manager. As an example, 229 this document uses /manage as the url-path of the group-collection 230 resource; implementations are not required to use this name, and 231 can define their own instead. 233 o Group-configuration resource: a resource hosted by the Group 234 Manager, associated to an OSCORE group under that Group Manager. 235 A group-configuration resource is identifiable with the invariant 236 group name of the respective OSCORE group. An Administrator 237 accesses a group-configuration resource to retrieve or update the 238 configuration of the respective OSCORE group, or to delete that 239 group. The url-path to a group-configuration resource has 240 GROUPNAME as last segment, with GROUPNAME the invariant group name 241 assigned upon its creation. Building on the considered url-path 242 of the group-collection resource, this document uses /manage/ 243 GROUPNAME as the url-path of a group-configuration resource; 244 implementations are not required to use this name, and can define 245 their own instead. 247 o Admin endpoint: an endpoint at the Group Manager associated to the 248 group-collection resource or to a group-configuration resource 249 hosted by that Group Manager. 251 2. Group Administration 253 With reference to the ACE framework and the terminology defined in 254 OAuth 2.0 [RFC6749]: 256 o The Group Manager acts as Resource Server (RS). It provides one 257 single group-collection resource, and one group-configuration 258 resource per existing OSCORE group. Each of those is exported by 259 a distinct admin endpoint. 261 o The Administrator acts as Client (C), and requests to access the 262 group-collection resource and group-configuration resources, by 263 accessing the respective admin endpoint at the Group Manager. 265 o The Authorization Server (AS) authorizes the Administrator to 266 access the group-collection resource and group-configuration 267 resources at a Group Manager. Multiple Group Managers can be 268 associated to the same AS. 270 The authorized access for an Administrator can be limited to 271 performing only a subset of operations. The AS can authorize 272 multiple Administrators to access the collection resource and the 273 (same) group-configuration resources at the Group Manager. 275 [ NOTE: This will be enabled by defining the format to use for the 276 'scope' claim in the Access Token, as encoding permitted actions 277 on groups whose name matches with a name pattern. ] 279 The AS MAY release Access Tokens to the Administrator for other 280 purposes than accessing admin endpoints of registered Group 281 Managers. 283 2.1. Getting Access to the Group Manager 285 All communications between the involved entities rely on the CoAP 286 protocol and MUST be secured. 288 In particular, communications between the Administrator and the Group 289 Manager leverage protocol-specific transport profiles of ACE to 290 achieve communication security, proof-of-possession and server 291 authentication. To this end, the AS may explicitly signal the 292 specific transport profile to use, consistently with requirements and 293 assumptions defined in the ACE framework [I-D.ietf-ace-oauth-authz]. 295 With reference to the AS, communications between the Administrator 296 and the AS (/token endpoint) as well as between the Group Manager and 297 the AS (/introspect endpoint) can be secured by different means, for 298 instance using DTLS [RFC6347][I-D.ietf-tls-dtls13] or OSCORE 299 [RFC8613]. Further details on how the AS secures communications 300 (with the Administrator and the Group Manager) depend on the 301 specifically used transport profile of ACE, and are out of the scope 302 of this specification. 304 In order to get access to the Group Manager for managing OSCORE 305 groups, an Administrator performs the following steps. 307 The format and encoding of scope defined in Section 2.1.1 of this 308 specification MUST be used, for both the 'scope' claim in the Access 309 Token, as well as for the 'scope' parameter in the Authorization 310 Request and Authorization Response exchanged with the AS (see 311 Sections 5.8.1 and Section 5.8.2 [I-D.ietf-ace-oauth-authz]). 313 1. The Administrator requests an Access Token from the AS, in order 314 to access the group-collection and group-configuration resources 315 on the Group Manager. The Administrator will start or continue 316 using secure communications with the Group Manager, according to 317 the response from the AS. 319 2. The Administrator transfers authentication and authorization 320 information to the Group Manager by posting the obtained Access 321 Token, according to the used profile of ACE, such as 322 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile]. 323 After that, the Administrator must have secure communication 324 established with the Group Manager, before performing any admin 325 operation on that Group Manager. Possible ways to provide secure 326 communication are DTLS [RFC6347][I-D.ietf-tls-dtls13] and OSCORE 327 [RFC8613]. The Administrator and the Group Manager maintain the 328 secure association, to support possible future communications. 330 3. Consistently with what allowed by the authorization information 331 in the Access Token, the Administrator performs admin operations 332 at the Group Manager, as described in the following sections. 333 These include the retrieval of the existing OSCORE groups, the 334 creation of new OSCORE groups, the update and retrieval of OSCORE 335 group configurations, and the removal of OSCORE groups. Messages 336 exchanged among the Administrator and the Group Manager are 337 specified in Section 4. 339 2.1.1. Format of Scope 341 This section defines the exact format and encoding of scope to use, 342 in order to express authorization information for the Administrator 343 (see Section 2.1). 345 TODO 347 [ 349 DESIGN CONSIDERATIONS 351 o Define a new AIF specific data model, as loosely aligned with the 352 data model AIF-OSCORE-GROUPCOMM defined in Section 3 353 [I-D.ietf-ace-key-groupcomm-oscore]. 355 * The overall scope is an array of scope entries, each as a pair 356 (Toid, Tperm). 358 * Toid is a text string, i.e. a wildcard pattern against which 359 group names can be matched. 361 * Tperm is a set of specific permissions encoded as a bitmap, 362 applied to groups whose name matches with the wildcard pattern. 364 o A valid Access Token should always allow to at least retrieve the 365 list of existing group configurations. 367 o An Administrator authorized to create a group, should later be 368 able to perform any possible operation on it. 370 o An Administrator can be authorized to perform selected operations 371 on a group earlier created by a different Administrator, still 372 barring the group name matching with the wildcard pattern. 374 ] 376 2.2. Managing OSCORE Groups 378 Figure 1 shows the resources of a Group Manager available to an 379 Administrator. 381 ___ 382 Group / \ 383 Collection \___/ 384 \ 385 \____________________ 386 \___ \___ \___ 387 / \ / \ ... / \ Group 388 \___/ \___/ \___/ Configurations 390 Figure 1: Resources of a Group Manager 392 The Group Manager exports a single group-collection resource, with 393 resource type "core.osc.gcoll" defined in Section 6.2 of this 394 specification. The interface for the group-collection resource 395 defined in Section 4 allows the Administrator to: 397 o Retrieve the complete list of existing OSCORE groups. 399 o Retrieve a partial list of existing OSCORE groups, by applying 400 filter criteria. 402 o Create a new OSCORE group, specifying its invariant group name 403 and, optionally, its configuration. 405 The Group Manager exports one group-configuration resource for each 406 of its OSCORE groups. Each group-configuration resource has resource 407 type "core.osc.gconf" defined in Section 6.2 of this specification, 408 and is identified by the group name specified upon creating the 409 OSCORE group. The interface for a group-configuration resource 410 defined in Section 4 allows the Administrator to: 412 o Retrieve the complete current configuration of the OSCORE group. 414 o Retrieve part of the current configuration of the OSCORE group, by 415 applying filter criteria. 417 o Overwrite the current configuration of the OSCORE group. 419 o Selectively update only part of the current configuration of the 420 OSCORE group. 422 o Delete the OSCORE group. 424 2.3. Collection Representation 426 A list of group configurations is represented as a document 427 containing the corresponding group-configuration resources in the 428 list. Each group-configuration is represented as a link, where the 429 link target is the URI of the group-configuration resource. 431 The list can be represented as a Link Format document [RFC6690] or a 432 CoRAL document [I-D.ietf-core-coral]. 434 In the former case, the link to each group-configuration resource 435 specifies the link target attribute 'rt' (Resource Type), with value 436 "core.osc.gconf" defined in Section 6.2 of this specification. 438 In the latter case, the CoRAL document specifies the group- 439 configuration resources in the list as top-level elements. In 440 particular, the link to each group-configuration resource has 441 http://coreapps.org/core.osc.gcoll#item as relation type. 443 2.4. Discovery 445 The Administrator can discover the group-collection resource from a 446 Resource Directory, for instance [I-D.ietf-core-resource-directory] 447 and [I-D.hartke-t2trg-coral-reef], or from .well-known/core, by using 448 the resource type "core.osc.gcoll" defined in Section 6.2 of this 449 specification. 451 The Administrator can discover group-configuration resources for the 452 group-collection resource as specified in Section 4.1 and 453 Section 4.2. 455 3. Group Configurations 457 A group configuration consists of a set of parameters. 459 3.1. Group Configuration Representation 461 The group configuration representation is a CBOR map which MUST 462 include configuration properties and status properties. 464 3.1.1. Configuration Properties 466 The CBOR map MUST include the following configuration parameters: 468 o 'hkdf', defined in Section 6.1 of this document, specifies the 469 HKDF algorithm used in the OSCORE group, encoded as a CBOR text 470 string or a CBOR integer. Possible values are the same ones 471 admitted for the 'hkdf' parameter of the "OSCORE Security Context 472 Parameters" registry, defined in Section 3.2.1 of 473 [I-D.ietf-ace-oscore-profile]. 475 o 'alg', defined in Section 6.1 of this document, specifies the AEAD 476 algorithm used in the OSCORE group, encoded as a CBOR text string 477 or a CBOR integer. Possible values are the same ones admitted for 478 the 'alg' parameter of the "OSCORE Security Context Parameters" 479 registry, defined in Section 3.2.1 of 480 [I-D.ietf-ace-oscore-profile]. 482 o 'cs_alg', defined in Section 6.1 of this document, specifies the 483 countersignature algorithm used in the OSCORE group, encoded as a 484 CBOR text string or a CBOR integer. Possible values are the same 485 ones admitted for the 'cs_alg' parameter of the "OSCORE Security 486 Context Parameters" registry, defined in Section 6.4 of 487 [I-D.ietf-ace-key-groupcomm-oscore]. 489 o 'cs_params', defined in Section 6.1 of this document, specifies 490 the additional parameters for the countersignature algorithm used 491 in the OSCORE group, encoded as a CBOR array. Possible formats 492 and values are the same ones admitted for the 'cs_params' 493 parameter of the "OSCORE Security Context Parameters" registry, 494 defined in Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore]. 496 o 'cs_key_params', defined in Section 6.1 of this document, 497 specifies the additional parameters for the key used with the 498 countersignature algorithm in the OSCORE group, encoded as a CBOR 499 array. Possible formats and values are the same ones admitted for 500 the 'cs_key_params' parameter of the "OSCORE Security Context 501 Parameters" registry, defined in Section 6.4 of 502 [I-D.ietf-ace-key-groupcomm-oscore]. 504 o 'cs_key_enc', defined in Section 6.1 of this document, specifies 505 the encoding of the public keys of group members, encoded as a 506 CBOR integer. Possible values are the same ones admitted for the 507 'cs_key_enc' parameter of the "OSCORE Security Context Parameters" 508 registry, defined in Section 6.4 of 509 [I-D.ietf-ace-key-groupcomm-oscore]. 511 o 'pairwise_mode', defined in Section 6.1 of this document and 512 encoded as a CBOR simple value. Its value is True if the OSCORE 513 group supports the pairwise mode of Group OSCORE 514 [I-D.ietf-core-oscore-groupcomm], or False otherwise. 516 o 'ecdh_alg', defined in Section 6.1 of this document and formatted 517 as follows. If the configuration parameter 'pairwise_mode' has 518 value False, this parameter has as value the CBOR simple value 519 Null. Otherwise, this parameter specifies the ECDH algorithm used 520 in the OSCORE group, encoded as a CBOR text string or a CBOR 521 integer. Possible values are the same ones admitted for the 522 'ecdh_alg' parameter of the "OSCORE Security Context Parameters" 523 registry, defined in Section 6.4 of 524 [I-D.ietf-ace-key-groupcomm-oscore]. 526 o 'ecdh_params', defined in Section 6.1 of this document and 527 formatted as follows. If the configuration parameter 528 'pairwise_mode' has value False, this parameter has as value the 529 CBOR simple value Null. Otherwise, this parameter specifies the 530 parameters for the ECDH algorithm used in the OSCORE group, 531 encoded as a CBOR array. Possible formats and values are the same 532 ones admitted for the 'ecdh_params' parameter of the "OSCORE 533 Security Context Parameters" registry, defined in Section 6.4 of 534 [I-D.ietf-ace-key-groupcomm-oscore]. 536 o 'ecdh_key_params', defined in Section 6.1 of this document and 537 formatted as follows. If the configuration parameter 538 'pairwise_mode' has value False, this parameter has as value the 539 CBOR simple value Null. Otherwise, this parameter specifies the 540 additional parameters for the key used with the ECDH algorithm in 541 the OSCORE group, encoded as a CBOR array. Possible formats and 542 values are the same ones admitted for the 'ecdh_key_params' 543 parameter of the "OSCORE Security Context Parameters" registry, 544 defined in Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore]. 546 3.1.2. Status Properties 548 The CBOR map MUST include the following status parameters: 550 o 'rt', with value the resource type "core.osc.gconf" associated to 551 group-configuration resources, encoded as a CBOR text string. 553 o 'active', encoding the CBOR simple value True if the OSCORE group 554 is currently active, or the CBOR simple value False otherwise. 555 This parameter is defined in Section 6.1 of this specification. 557 o 'group_name', with value the group name of the OSCORE group 558 encoded as a CBOR text string. This parameter is defined in 559 Section 6.1 of this specification. 561 o 'group_title', with value either a human-readable description of 562 the OSCORE group encoded as a CBOR text string, or the CBOR simple 563 value Null if no description is specified. This parameter is 564 defined in Section 6.1 of this specification. 566 o 'ace-groupcomm-profile', defined in Section 4.1.2.1 of 567 [I-D.ietf-ace-key-groupcomm], with value "coap_group_oscore_app" 568 defined in Section 21.3 of [I-D.ietf-ace-key-groupcomm-oscore] 569 encoded as a CBOR integer. 571 o 'exp', defined in Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm]. 573 o 'app_groups', with value a list of names of application groups, 574 encoded as a CBOR array. Each element of the array is a CBOR text 575 string, specifying the name of an application group using the 576 OSCORE group as security group (see Section 2.1 of 577 [I-D.ietf-core-groupcomm-bis]). 579 o 'joining_uri', with value the URI of the group-membership resource 580 for joining the newly created OSCORE group as per Section 6.2 of 581 [I-D.ietf-ace-key-groupcomm-oscore], encoded as a CBOR text 582 string. This parameter is defined in Section 6.1 of this 583 specification. 585 The CBOR map MAY include the following status parameters: 587 o 'group_policies', defined in Section 4.1.2.1 of 588 [I-D.ietf-ace-key-groupcomm], and consistent with the format and 589 content defined in Section 6.4 of 590 [I-D.ietf-ace-key-groupcomm-oscore]. 592 o 'as_uri', defined in Section 6.1 of this document, specifies the 593 URI of the Authorization Server associated to the Group Manager 594 for the OSCORE group, encoded as a CBOR text string. Candidate 595 group members will have to obtain an Access Token from that 596 Authorization Server, before starting the joining process with the 597 Group Manager to join the OSCORE group (see Section 4 and 598 Section 6 of [I-D.ietf-ace-key-groupcomm-oscore]). 600 3.2. Default Values 602 This section defines the default values that the Group Manager 603 assumes for configuration and status parameters. 605 3.2.1. Configuration Parameters 607 For each configuration parameter, the Group Manager MUST use a pre- 608 configured default value, if none is specified by the Administrator. 609 In particular: 611 o For 'pairwise_mode', the Group Manager SHOULD use the CBOR simple 612 value False. 614 o If 'pairwise_mode' has value True, the Group Manager SHOULD use 615 the same default values defined in Section 19 of 617 [I-D.ietf-ace-key-groupcomm-oscore] for the parameters 'ecdh_alg', 618 'ecdh_params' and 'ecdh_key_params'. 620 o For any other configuration parameter, the Group Manager SHOULD 621 use the same default values defined in Section 19 of 622 [I-D.ietf-ace-key-groupcomm-oscore]. 624 3.2.2. Status Parameters 626 For the following status parameters, the Group Manager MUST use a 627 pre-configured default value, if none is specified by the 628 Administrator. In particular: 630 o For 'active', the Group Manager SHOULD use the CBOR simple value 631 False. 633 o For 'group_title', the Group Manager SHOULD use the CBOR simple 634 value Null. 636 o For 'app_groups', the Group Manager SHOULD use the empty CBOR 637 array. 639 4. Interactions with the Group Manager 641 This section describes the operations available on the group- 642 collection resource and the group-configuration resources. 644 When custom CBOR is used, the Content-Format in messages containing a 645 payload is set to application/ace-groupcomm+cbor, defined in 646 Section 10.2 of [I-D.ietf-ace-key-groupcomm]. Furthermore, the entry 647 labels defined in Section 6.1 of this document MUST be used, when 648 specifying the corresponding configuration and status parameters. 650 4.1. Retrieve the Full List of Groups Configurations 652 The Administrator can send a GET request to the group-collection 653 resource, in order to retrieve the complete list of the existing 654 OSCORE groups at the Group Manager. This is returned as a list of 655 links to the corresponding group-configuration resources. 657 Example in Link Format: 659 => 0.01 GET 660 Uri-Path: manage 662 <= 2.05 Content 663 Content-Format: 40 (application/link-format) 665 ;rt="core.osc.gconf", 666 ;rt="core.osc.gconf", 667 ;rt="core.osc.gconf" 669 Example in CoRAL: 671 => 0.01 GET 672 Uri-Path: manage 674 <= 2.05 Content 675 Content-Format: TBD1 (application/coral+cbor) 677 #using 678 #base 679 item 680 item 681 item 683 4.2. Retrieve a List of Group Configurations by Filters 685 The Administrator can send a FETCH request to the group-collection 686 resource, in order to retrieve the list of the existing OSCORE groups 687 that fully match a set of specified filter criteria. This is 688 returned as a list of links to the corresponding group-configuration 689 resources. 691 When custom CBOR is used, the set of filter criteria is specified in 692 the request payload as a CBOR map, whose possible entries are 693 specified in Section 3.1 and use the same abbreviations defined in 694 Section 6.1. Entry values are the ones admitted for the 695 corresponding labels in the POST request for creating a group 696 configuration (see Section 4.3). A valid request MUST NOT include 697 the same entry multiple times. 699 When CoRAL is used, the filter criteria are specified in the request 700 payload with top-level elements, each of which corresponds to an 701 entry specified in Section 3.1, with the exception of the 702 'app_groups' status parameter. If names of application groups are 703 used as filter criteria, each element of the 'app_groups' array from 704 the status properties is included as a separate element with name 705 'app_group'. With the exception of the 'app_group' element, a valid 706 request MUST NOT include the same element multiple times. Element 707 values are the ones admitted for the corresponding labels in the POST 708 request for creating a group configuration (see Section 4.3). 710 Example in custom CBOR and Link Format: 712 => 0.05 FETCH 713 Uri-Path: manage 714 Content-Format: TBD2 (application/ace-groupcomm+cbor) 716 { 717 "alg" : 10, 718 "hkdf" : 5 719 } 721 <= 2.05 Content 722 Content-Format: 40 (application/link-format) 724 ;rt="core.osc.gconf", 725 ;rt="core.osc.gconf", 726 ;rt="core.osc.gconf" 728 Example in CoRAL: 730 => 0.05 FETCH 731 Uri-Path: manage 732 Content-Format: TBD1 (application/coral+cbor) 734 alg 10 735 hkdf 5 737 <= 2.05 Content 738 Content-Format: TBD1 (application/coral+cbor) 740 #using 741 #base 742 item 743 item 744 item 746 4.3. Create a New Group Configuration 748 The Administrator can send a POST request to the group-collection 749 resource, in order to create a new OSCORE group at the Group Manager. 750 The request MAY specify the intended group name GROUPNAME and group 751 title, and MAY specify pieces of information concerning the group 752 configuration. 754 When custom CBOR is used, the request payload is a CBOR map, whose 755 possible entries are specified in Section 3.1 and use the same 756 abbreviations defined in Section 6.1. 758 When CoRAL is used, each element of the request payload corresponds 759 to an entry specified in Section 3.1, with the exception of the 760 'app_groups' status parameter (see below). 762 In particular: 764 o The payload MAY include any of the configuration parameter defined 765 in Section 3.1.1. 767 o The payload MAY include any of the status parameter 'group_name', 768 'group_title', 'exp', 'app_groups, 'group_policies', 'as_uri' and 769 'active' defined in Section 3.1.2. 771 * When CoRAL is used, each element of the 'app_groups' array from 772 the status properties is included as a separate element with 773 name 'app_group'. 775 o The payload MUST NOT include any of the status parameter 'rt', 776 'ace-groupcomm-profile' and 'joining_uri' defined in 777 Section 3.1.2. 779 If any of the following occurs, the Group Manager MUST respond with a 780 4.00 (Bad Request) response. 782 o Any of the received parameters is specified multiple times, with 783 the exception of the 'app_group' element when using CoRAL. 785 o Any of the received parameters is not recognized, or not valid, or 786 not consistent with respect to other related parameters. 788 o The 'group_name' parameter specifies the group name of an already 789 existing OSCORE group. 791 o The Group Manager does not trust the Authorization Server with URI 792 specified in the 'as_uri' parameter, and has no alternative 793 Authorization Server to consider for the OSCORE group to create. 795 After a successful processing of the request above, the Group Manager 796 performs the following actions. 798 First, the Group Manager creates a new group-configuration resource, 799 accessible to the Administrator at /manage/GROUPNAME, where GROUPNAME 800 is the name of the OSCORE group as either indicated in the parameter 801 'group_name' of the request or uniquely assigned by the Group 802 Manager. Note that the final decision about the name assigned to the 803 OSCORE group is of the Group Manager, which may have more constraints 804 than the Administrator can be aware of, possibly beyond the 805 availability of suggested names. 807 The value of the status parameter 'rt' is set to "core.osc.gconf". 808 The values of other parameters specified in the request are used as 809 group configuration information for the newly created OSCORE group. 810 For each configuration parameter not specified in the request, the 811 Group Manager MUST use default values as specified in Section 3.2. 813 After that, the Group Manager creates a new group-membership resource 814 accessible at ace-group/GROUPNAME to nodes that want to join the 815 OSCORE group, as specified in Section 6.2 of 816 [I-D.ietf-ace-key-groupcomm-oscore]. Note that such group 817 membership-resource comprises a number of sub-resources intended to 818 current group members, as defined in Section 4.1 of 819 [I-D.ietf-ace-key-groupcomm] and Section 5 of 820 [I-D.ietf-ace-key-groupcomm-oscore]. 822 From then on, the Group Manager will rely on the current group 823 configuration to build the Joining Response message defined in 824 Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore], when handling the 825 joining of a new group member. Furthermore, the Group Manager 826 generates the following pieces of information, and assigns them to 827 the newly created OSCORE group. 829 o The OSCORE Master Secret. 831 o The OSCORE Master Salt (optionally). 833 o The Group ID, used as OSCORE ID Context, which MUST be unique 834 within the set of OSCORE groups under the Group Manager. 836 Finally, the Group Manager replies to the Administrator with a 2.01 837 (Created) response. The Location-Path option MUST be included in the 838 response, indicating the location of the just created group- 839 configuration resource. The response MUST NOT include a Location- 840 Query option. 842 The response payload specifies the parameters 'group_name', 843 'joining_uri' and 'as_uri', from the status properties of the newly 844 created OSCORE group (see Section 3.1), as detailed below. 846 When custom CBOR is used, the response payload is a CBOR map, where 847 entries use the same abbreviations defined in Section 6.1. When 848 CoRAL is used, the response payload includes one element for each 849 specified parameter. 851 o 'group_name', with value the group name of the OSCORE group. This 852 value can be different from the group name possibly specified by 853 the Administrator in the POST request, and reflects the final 854 choice of the Group Manager as 'group_name' status property for 855 the OSCORE group. This parameter MUST be included. 857 o 'joining_uri', with value the URI of the group-membership resource 858 for joining the newly created OSCORE group. This parameter MUST 859 be included. 861 o 'as_uri', with value the URI of the Authorization Server 862 associated to the Group Manager for the newly created OSCORE 863 group. This parameter MUST be included if specified in the status 864 properties of the group. This value can be different from the URI 865 possibly specified by the Administrator in the POST request, and 866 reflects the final choice of the Group Manager as 'as_uri' status 867 property for the OSCORE group. 869 The Group Manager can register the link to the group-membership 870 resource with URI specified in 'joining_uri' to a Resource Directory 871 [I-D.ietf-core-resource-directory][I-D.hartke-t2trg-coral-reef], as 872 defined in Section 2 of [I-D.tiloca-core-oscore-discovery]. The 873 Group Manager considers the current group configuration when 874 specifying additional information for the link to register. 876 Alternatively, the Administrator can perform the registration in the 877 Resource Directory on behalf of the Group Manager, acting as 878 Commissioning Tool. The Administrator considers the following when 879 specifying additional information for the link to register. 881 o The name of the OSCORE group MUST take the value specified in 882 'group_name' from the 2.01 (Created) response above. 884 o The names of the application groups using the OSCORE group MUST 885 take the values possibly specified by the elements of the 886 'app_groups' parameter (when custom CBOR is used) or by the 887 different 'app_group' elements (when CoRAL is used) in the POST 888 request above. 890 o If present, parameters describing the cryptographic algorithms 891 used in the OSCORE group MUST follow the values that the 892 Administrator specified in the POST request above, or the 893 corresponding default values specified in Section 3.2.1 otherwise. 895 o If also registering a related link to the Authorization Server 896 associated to the OSCORE group, the related link MUST have as link 897 target the URI in 'as_uri' from the 2.01 (Created) response above, 898 if the 'as_uri' parameter was included in the response. 900 Note that, compared to the Group Manager, the Administrator is less 901 likely to remain closely aligned with possible changes and updates 902 that would require a prompt update to the registration in the 903 Resource Directory. This applies especially to the address of the 904 Group Manager, as well as the URI of the group-membership resource or 905 of the Authorization Server associated to the Group Manager. 907 Therefore, it is RECOMMENDED that registrations of links to group- 908 membership resources in the Resource Directory are made (and possibly 909 updated) directly by the Group Manager, rather than by the 910 Administrator. 912 Example in custom CBOR: 914 => 0.02 POST 915 Uri-Path: manage 916 Content-Format: TBD2 (application/ace-groupcomm+cbor) 918 { 919 "alg" : 10, 920 "hkdf" : 5, 921 "pairwise_mode" : True, 922 "active" : True, 923 "group_title" : "rooms 1 and 2", 924 "app_groups": : ["room1", "room2"], 925 "as_uri" : "coap://as.example.com/token" 926 } 928 <= 2.01 Created 929 Location-Path: manage 930 Location-Path: gp4 931 Content-Format: TBD2 (application/ace-groupcomm+cbor) 933 { 934 "group_name" : "gp4", 935 "joining_uri" : "coap://[2001:db8::ab]/ace-group/gp4/", 936 "as_uri" : "coap://as.example.com/token" 937 } 939 Example in CoRAL: 941 => 0.02 POST 942 Uri-Path: manage 943 Content-Format: TBD1 (application/coral+cbor) 945 #using 946 alg 10 947 hkdf 5 948 pairwise_mode True 949 active True 950 group_title "rooms 1 and 2" 951 app_group "room1" 952 app_group "room2" 953 as_uri 955 <= 2.01 Created 956 Location-Path: manage 957 Location-Path: gp4 958 Content-Format: TBD1 (application/coral+cbor) 960 #using 961 group_name "gp4" 962 joining_uri 963 as_uri 965 4.4. Retrieve a Group Configuration 967 The Administrator can send a GET request to the group-configuration 968 resource manage/GROUPNAME associated to an OSCORE group with group 969 name GROUPNAME, in order to retrieve the complete current 970 configuration of that group. 972 After a successful processing of the request above, the Group Manager 973 replies to the Administrator with a 2.05 (Content) response. The 974 response has as payload the representation of the group configuration 975 as specified in Section 3.1. The exact content of the payload 976 reflects the current configuration of the OSCORE group. This 977 includes both configuration properties and status properties. 979 When custom CBOR is used, the response payload is a CBOR map, whose 980 possible entries are specified in Section 3.1 and use the same 981 abbreviations defined in Section 6.1. 983 When CoRAL is used, the response payload includes one element for 984 each entry specified in Section 3.1, with the exception of the 985 'app_groups' status parameter. That is, each element of the 986 'app_groups' array from the status properties is included as a 987 separate element with name 'app_group'. 989 Example in custom CBOR: 991 => 0.01 GET 992 Uri-Path: manage 993 Uri-Path: gp4 995 <= 2.05 Content 996 Content-Format: TBD2 (application/ace-groupcomm+cbor) 998 { 999 "alg" : 10, 1000 "hkdf" : 5, 1001 "cs_alg" : -8, 1002 "cs_params" : [[1], [1, 6]], 1003 "cs_key_params" : [1, 6], 1004 "cs_key_enc" : 1, 1005 "pairwise_mode" : True, 1006 "ecdh_alg" : -27, 1007 "ecdh_params" : [[1], [1, 6]], 1008 "ecdh_key_params" : [1, 6], 1009 "rt" : "core.osc.gconf", 1010 "active" : True, 1011 "group_name" : "gp4", 1012 "group_title" : "rooms 1 and 2", 1013 "ace-groupcomm-profile" : "coap_group_oscore_app", 1014 "exp" : "1360289224", 1015 "app_groups": : ["room1", "room2"], 1016 "joining_uri" : "coap://[2001:db8::ab]/ace-group/gp4/", 1017 "as_uri" : "coap://as.example.com/token" 1018 } 1020 Example in CoRAL: 1022 => 0.01 GET 1023 Uri-Path: manage 1024 Uri-Path: gp4 1026 <= 2.05 Content 1027 Content-Format: TBD1 (application/coral+cbor) 1029 #using 1030 alg 10 1031 hkdf 5 1032 cs_alg -8 1033 cs_params.alg_capab.key_type 1 1034 cs_params.key_type_capab.key_type 1 1035 cs_params.key_type_capab.curve 6 1036 cs_key_params.key_type 1 1037 cs_key_params.curve 6 1038 cs_key_enc 1 1039 pairwise_mode True 1040 ecdh_alg -27 1041 ecdh_params.alg_capab.key_type 1 1042 ecdh_params.key_type_capab.key_type 1 1043 ecdh_params.key_type_capab.curve 6 1044 ecdh_key_params.key_type 1 1045 ecdh_key_params.curve 6 1046 rt "core.osc.gconf", 1047 active True 1048 group_name "gp4" 1049 group_title "rooms 1 and 2" 1050 ace-groupcomm-profile "coap_group_oscore_app" 1051 exp "1360289224" 1052 app_group "room1" 1053 app_group "room2" 1054 joining_uri 1055 as_uri 1057 4.5. Retrieve Part of a Group Configuration by Filters 1059 The Administrator can send a FETCH request to the group-configuration 1060 resource manage/GROUPNAME associated to an OSCORE group with group 1061 name GROUPNAME, in order to retrieve part of the current 1062 configuration of that group. 1064 When custom CBOR is used, the request payload is a CBOR map, which 1065 contains the following fields: 1067 o 'conf_filter', defined in Section 6.1 of this document and encoded 1068 as a CBOR array. Each element of the array specifies one 1069 requested configuration parameter or status parameter of the 1070 current group configuration (see Section 3.1), using the 1071 corresponding abbreviation defined in Section 6.1. 1073 When CoRAL is used, the request payload includes one element for each 1074 requested configuration parameter or status parameter of the current 1075 group configuration (see Section 3.1). All the specified elements 1076 have no value. 1078 After a successful processing of the request above, the Group Manager 1079 replies to the Administrator with a 2.05 (Content) response. The 1080 response has as payload a partial representation of the group 1081 configuration (see Section 3.1). The exact content of the payload 1082 reflects the current configuration of the OSCORE group, and is 1083 limited to the configuration properties and status properties 1084 requested by the Administrator in the FETCH request. 1086 The response payload includes the requested configuration parameters 1087 and status parameters, and is formatted as in the response payload of 1088 a GET request to a group-configuration resource (see Section 4.4). 1090 Example in custom CBOR: 1092 => 0.05 FETCH 1093 Uri-Path: manage 1094 Uri-Path: gp4 1095 Content-Format: TBD2 (application/ace-groupcomm+cbor) 1097 { 1098 "conf_filter" : ["alg", 1099 "hkdf", 1100 "pairwise_mode", 1101 "active", 1102 "group_title", 1103 "app_groups"] 1104 } 1106 <= 2.05 Content 1107 Content-Format: TBD2 (application/ace-groupcomm+cbor) 1109 { 1110 "alg" : 10, 1111 "hkdf" : 5, 1112 "pairwise_mode" : True, 1113 "active" : True, 1114 "group_title" : "rooms 1 and 2", 1115 "app_groups": : ["room1", "room2"] 1116 } 1118 Example in CoRAL: 1120 => 0.05 FETCH 1121 Uri-Path: manage 1122 Uri-Path: gp4 1123 Content-Format: TBD1 (application/coral+cbor) 1125 #using 1126 alg 1127 hkdf 1128 pairwise_mode 1129 active 1130 group_title 1131 app_groups 1133 <= 2.05 Content 1134 Content-Format: TBD1 (application/coral+cbor) 1136 #using 1137 alg 10 1138 hkdf 5 1139 pairwise_mode True 1140 active True 1141 group_title "rooms 1 and 2" 1142 app_group "room1" 1143 app_group "room2" 1145 4.6. Overwrite a Group Configuration 1147 The Administrator can send a PUT request to the group-configuration 1148 resource associated to an OSCORE group, in order to overwrite the 1149 current configuration of that group with a new one. The payload of 1150 the request has the same format of the POST request defined in 1151 Section 4.3, with the exception of the status parameter 'group_name' 1152 that MUST NOT be included. 1154 The error handling for the PUT request is the same as for the POST 1155 request defined in Section 4.3. If no error occurs, the Group 1156 Manager performs the following actions. 1158 First, the Group Manager updates the group-configuration resource, 1159 consistently with the values indicated in the PUT request from the 1160 Administrator. For each parameter not specified in the PUT request, 1161 the Group Manager MUST use the default value as specified in 1162 Section 3.2. From then on, the Group Manager relies on the latest 1163 updated configuration to build the Joining Response message defined 1164 in Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore], when handling 1165 the joining of a new group member. 1167 Then, the Group Manager replies to the Administrator with a 2.04 1168 (Changed) response. The payload of the response has the same format 1169 of the 2.01 (Created) response defined in Section 4.3. 1171 If the link to the group-membership resource was registered in the 1172 Resource Directory [I-D.ietf-core-resource-directory], the GM is 1173 responsible to refresh the registration, as defined in Section 3 of 1174 [I-D.tiloca-core-oscore-discovery]. 1176 Alternatively, the Administrator can update the registration in the 1177 Resource Directory on behalf of the Group Manager, acting as 1178 Commissioning Tool. The Administrator considers the following when 1179 specifying additional information for the link to update. 1181 o The name of the OSCORE group MUST take the value specified in 1182 'group_name' from the 2.04 (Changed) response above. 1184 o The names of the application groups using the OSCORE group MUST 1185 take the values possibly specified by the elements of the 1186 'app_groups' parameter (when custom CBOR is used) or by the 1187 different 'app_group' elements (when CoRAL is used) in the PUT 1188 request above. 1190 o If present, parameters describing the cryptographic algorithms 1191 used in the OSCORE group MUST follow the values that the 1192 Administrator specified in the PUT request above, or the 1193 corresponding default values as specified in Section 3.2.1 1194 otherwise. 1196 o If also registering a related link to the Authorization Server 1197 associated to the OSCORE group, the related link MUST have as link 1198 target the URI in 'as_uri' from the 2.04 (Changed) response above, 1199 if the 'as_uri' parameter was included in the response. 1201 As discussed in Section 4.3, it is RECOMMENDED that registrations of 1202 links to group-membership resources in the Resource Directory are 1203 made (and possibly updated) directly by the Group Manager, rather 1204 than by the Administrator. 1206 Example in custom CBOR: 1208 => 0.03 PUT 1209 Uri-Path: manage 1210 Uri-Path: gp4 1211 Content-Format: TBD2 (application/ace-groupcomm+cbor) 1213 { 1214 "alg" : 11, 1215 "hkdf" : 5 1216 } 1218 <= 2.04 Changed 1219 Content-Format: TBD2 (application/ace-groupcomm+cbor) 1221 { 1222 "group_name" : "gp4", 1223 "joining_uri" : "coap://[2001:db8::ab]/ace-group/gp4/", 1224 "as_uri" : "coap://as.example.com/token" 1225 } 1227 Example in CoRAL: 1229 => 0.03 PUT 1230 Uri-Path: manage 1231 Uri-Path: gp4 1232 Content-Format: TBD1 (application/coral+cbor) 1234 #using 1235 alg 11 1236 hkdf 5 1238 <= 2.04 Changed 1239 Content-Format: TBD1 (application/coral+cbor) 1241 #using 1242 group_name "gp4" 1243 joining_uri 1244 as_uri 1246 4.6.1. Effects on Joining Nodes 1248 After having overwritten a group configuration, if the value of the 1249 status parameter 'active' is changed from True to False, the Group 1250 Manager MUST stop admitting new members in the OSCORE group. In 1251 particular, until the status parameter 'active' is changed back to 1252 True, the Group Manager MUST respond to a Joining Request with a 5.03 1253 (Service Unavailable) response, as defined in Section 6.3 of 1254 [I-D.ietf-ace-key-groupcomm-oscore]. 1256 If the value of the status parameter 'active' is changed from False 1257 to True, the Group Manager resumes admitting new members in the 1258 OSCORE group, by processing their Joining Requests (see Section 6.3 1259 of [I-D.ietf-ace-key-groupcomm-oscore]). 1261 4.6.2. Effects on the Group Members 1263 After having overwritten a group configuration, the Group Manager 1264 informs the members of the OSCORE group, over the pairwise secure 1265 communication channels established when joining the group (see 1266 Section 6 of [I-D.ietf-ace-key-groupcomm-oscore]). 1268 To this end, the Group Manager can individually target the 1269 'control_uri' URI of each group member (see Section 4.1.2.1 of 1270 [I-D.ietf-ace-key-groupcomm]), if provided by the intended recipient 1271 upon joining the OSCORE group (see Section 6.2 of 1272 [I-D.ietf-ace-key-groupcomm-oscore]). Alternatively, group members 1273 can subscribe for updates to the group-membership resource of the 1274 OSCORE group, e.g. by using CoAP Observe [RFC7641]. 1276 If the value of the status parameter 'active' is changed from True to 1277 False: 1279 o The Group Manager MUST stop accepting requests for new keying 1280 material from current group members (see Section 9 of 1281 [I-D.ietf-ace-key-groupcomm-oscore]). In particular, until the 1282 status parameter 'active' is changed back to True, the Group 1283 Manager MUST respond to a Key Renewal Request with a 5.03 (Service 1284 Unavailable) response, as defined in Section 9 of 1285 [I-D.ietf-ace-key-groupcomm-oscore]. 1287 o The Group Manager MUST stop accepting updated public keys uploaded 1288 by current group members (see Section 11 of 1289 [I-D.ietf-ace-key-groupcomm-oscore]). In particular, until the 1290 status parameter 'active' is changed back to True, the Group 1291 Manager MUST respond to a Public Key Update Request with a 5.03 1292 (Service Unavailable) response, as defined in Section 11 of 1293 [I-D.ietf-ace-key-groupcomm-oscore]. 1295 Every group member, upon learning that the OSCORE group has been 1296 deactivated (i.e. 'active' has value False), SHOULD stop 1297 communicating in the group. 1299 Every group member, upon learning that the OSCORE group has been 1300 reactivated (i.e. 'active' has value True again), can resume 1301 communicating in the group. 1303 Every group member, upon learning that the OSCORE group has stopped 1304 supporting the pairwise mode of Group OSCORE (i.e. 'pairwise_mode' 1305 has value False), SHOULD stop using the pairwise mode to process 1306 messages in the group. 1308 Every group member, upon learning that the OSCORE group has resumed 1309 supporting the pairwise mode of Group OSCORE (i.e. 'pairwise_mode' 1310 has value True again), can resume using the pairwise mode to process 1311 messages in the group. 1313 Every group member, upon receiving updated values for 'alg' and 1314 'hkdf', MUST either: 1316 o Leave the OSCORE group (see Section 16 of 1317 [I-D.ietf-ace-key-groupcomm-oscore]), e.g. if not supporting the 1318 indicated new algorithms; or 1320 o Use the new parameter values, and accordingly re-derive the OSCORE 1321 Security Context for the OSCORE group (see Section 2 of 1322 [I-D.ietf-core-oscore-groupcomm]). 1324 Every group member, upon receiving updated values for 'cs_alg', 1325 'cs_params', 'cs_key_params', 'cs_key_enc', 'ecdh_alg', 'ecdh_params' 1326 and 'ecdh_key_params' MUST either: 1328 o Leave the OSCORE group, e.g. if not supporting the indicated new 1329 algorithm, parameters and encoding; or 1331 o Leave the OSCORE group and rejoin it (see Section 6 of 1332 [I-D.ietf-ace-key-groupcomm-oscore]), providing the Group Manager 1333 with a public key which is compatible with the indicated new 1334 algorithm, parameters and encoding; or 1336 o Use the new parameter values, and, if required, provide the Group 1337 Manager with a new public key to use in the OSCORE group, as 1338 compatible with the indicated parameters (see Section 11 of 1339 [I-D.ietf-ace-key-groupcomm-oscore]). 1341 4.7. Selective Update of a Group Configuration 1343 The Administrator can send a PATCH/iPATCH request [RFC8132] to the 1344 group-configuration resource associated to an OSCORE group, in order 1345 to update the value of only part of the group configuration. 1347 The request payload has the same format of the PUT request defined in 1348 Section 4.6, with the difference that it MAY also specify names of 1349 application groups to be removed from or added to the 'app_groups' 1350 status parameter. The names of such application groups are provided 1351 as defined below. 1353 o When custom CBOR is used, the CBOR map in the request payload 1354 includes the field 'app_groups_diff'. This field MUST NOT be 1355 present multiple times, and it is encoded as a CBOR array 1356 including the following two elements. 1358 * The first element is a CBOR array, namely 'app_groups_del'. 1359 Each of its elements is a CBOR text string, with value the name 1360 of an application group to remove from the 'app_groups' status 1361 parameter. 1363 * The second element is a CBOR array, namely 'app_groups_add'. 1364 Each of its elements is a CBOR text string, with value the name 1365 of an application group to add to the 'app_groups' status 1366 parameter. 1368 The CDDL definition [RFC8610] of the CBOR array 'app_groups_diff' 1369 formatted as in the response from the Group Manager is provided 1370 below. 1372 app-group-name = tstr 1373 name-patch = [* app-group-name] 1374 app_groups_diff = [app_groups_del: name-patch, 1375 app_groups_add: name-patch] 1377 Figure 2: CDDL definition of the 'app_groups_diff' field 1379 The Group Manager MUST respond with a 4.00 (Bad Request) response, in 1380 case both the inner CBOR arrays 'app_groups_del' and 'app_groups_add' 1381 are empty, or in case the 'app_groups_diff' field occurs more than 1382 once. 1384 The Group Manager MUST respond with a 4.00 (Bad Request) response, in 1385 case the CBOR map in the request payload includes both the 1386 'app_groups' field and the 'app_groups_diff' field. 1388 o When CoRAL is used, the request payload includes the following 1389 top-level elements. 1391 * 'app_group_del', with value a text string specifying the name 1392 of an application group to remove from the 'app_groups' status 1393 parameter. This element can be included multiple times. 1395 * 'app_group_add', with value a text string specifying the name 1396 of an application group to add to the 'app_groups' status 1397 parameter. This element can be included multiple times. 1399 The Group Manager MUST respond with a 4.00 (Bad Request) response, 1400 in case the request payload includes both any 'app_group' element 1401 as well as any 'app_group_del' and/or 'app_group_add' element. 1403 The error handling for the PATCH/iPATCH request is the same as for 1404 the PUT request defined in Section 4.6, with the following additions. 1406 o The set of group configuration parameters to update MUST NOT be 1407 empty. That is, the Group Manager MUST respond with a 4.00 (Bad 1408 Request) response, if the request payload includes an empty CBOR 1409 map (when custom CBOR is used) or no elements (when CoRAL is 1410 used). 1412 o If the Request-URI does not point to an existing group- 1413 configuration resource, the Group Manager MUST NOT create a new 1414 resource, and MUST respond with a 4.04 (Not Found) response. 1416 o When applying the specified updated values would yield an 1417 inconsistent group configuration, the Group Manager MUST respond 1418 with a 4.09 (Conflict) response. 1420 The response, MAY include the current representation of the group 1421 configuration resource, like when responding to a GET request as 1422 defined in Section 4.4. Otherwise, the response SHOULD include a 1423 diagnostic payload with additional information for the 1424 Administrator to recognize the source of the conflict. 1426 o When the request uses specifically the iPATCH method, the Group 1427 Manager MUST respond with a 4.00 (Bad Request) response, in case: 1429 * When custom CBOR is used, the CBOR map includes the parameter 1430 'app_groups'diffs'; or 1432 * When CoRAL is used, any element 'app_group_del' and/or 1433 'app_group_add' is included. 1435 If no error occurs, the Group Manager performs the following actions. 1437 First, the Group Manager updates the group-configuration resource, 1438 consistently with the values indicated in the PATCH/iPATCH request 1439 from the Administrator. 1441 Unlike for the PUT request defined in Section 4.6, the Group Manager 1442 does not alter the value of configuration parameters and status 1443 parameters for which updated values are not specified in the request 1444 payload. In particular, the Group Manager does not assign possible 1445 default values to those parameters. 1447 Special processing occurs when updating the 'app_groups' status 1448 parameter by difference, as defined below. The Administrator should 1449 not expect the Group Manager to add or delete names of application 1450 group names according to any particular order. 1452 o If the name of an application group to add (delete) is specified 1453 multiple times, the Group Manager considers it only once for 1454 addition to (deletion from) the 'app_groups' status parameter. 1456 o If the name of an application group to delete is not present in 1457 the 'app_groups' status parameter before any change is applied, 1458 the Group Manager ignores that name. 1460 o If the name of an application group to add is already present in 1461 the 'app_groups' status parameter before any change is applied, 1462 the Group Manager ignores that name. 1464 o When custom CBOR is used, the Group Manager: 1466 * Deletes from the 'app_groups' status parameter the names of the 1467 application groups specified in the inner 'app_groups_del' CBOR 1468 array of the 'app_groups_diff' field. 1470 * Adds to the 'app_groups' status parameter the names of the 1471 application groups specified in the inner 'app_groups_add' CBOR 1472 array of the 'app_groups_diff' field. 1474 o When CoRAL is used, the Group Manager: 1476 * Deletes from the 'app_groups' status parameter the names of the 1477 application groups specified in the different 'app_group_del' 1478 elements. 1480 * Adds to the 'app_groups' status parameter the names of the 1481 application groups specified in the different 'app_group_add' 1482 elements. 1484 After having updated the group-configuration resource, from then on 1485 the Group Manager relies on the new group configuration to build the 1486 Joining Response message defined in Section 6.4 of 1487 [I-D.ietf-ace-key-groupcomm-oscore], when handling the joining of a 1488 new group member. 1490 Finally, the Group Manager replies to the Administrator with a 2.04 1491 (Changed) response. The payload of the response has the same format 1492 of the 2.01 (Created) response defined in Section 4.3. 1494 The same considerations as for the PUT request defined in Section 4.6 1495 hold also in this case, with respect to refreshing a possible 1496 registration of the link to the group-membership resource in the 1497 Resource Directory [I-D.ietf-core-resource-directory]. 1499 Example in custom CBOR: 1501 => 0.06 PATCH 1502 Uri-Path: manage 1503 Uri-Path: gp4 1504 Content-Format: TBD2 (application/ace-groupcomm+cbor) 1506 { 1507 "alg" : 10, 1508 "app_groups_diff" : [["room1"], 1509 ["room3", "room4"]] 1510 } 1512 <= 2.04 Changed 1513 Content-Format: TBD2 (application/ace-groupcomm+cbor) 1515 { 1516 "group_name" : "gp4", 1517 "joining_uri" : "coap://[2001:db8::ab]/ace-group/gp4/", 1518 "as_uri" : "coap://as.example.com/token" 1519 } 1521 Example in CoRAL: 1523 => 0.06 PATCH 1524 Uri-Path: manage 1525 Uri-Path: gp4 1526 Content-Format: TBD1 (application/coral+cbor) 1528 #using 1529 alg 10 1530 app_group_del "room1" 1531 app_group_add "room3" 1532 app_group_add "room4" 1534 <= 2.04 Changed 1535 Content-Format: TBD1 (application/coral+cbor) 1537 #using 1538 group_name "gp4" 1539 joining_uri 1540 as_uri 1542 4.7.1. Effects on Joining Nodes 1544 After having selectively updated part of a group configuration, the 1545 effects on candidate joining nodes are the same as defined in 1546 Section 4.6.1 for the case of group configuration overwriting. 1548 4.7.2. Effects on the Group Members 1550 After having selectively updated part of a group configuration, the 1551 effects on the current group members are the same as defined in 1552 Section 4.6.2 for the case of group configuration overwriting. 1554 4.8. Delete a Group Configuration 1556 The Administrator can send a DELETE request to the group- 1557 configuration resource, in order to delete that OSCORE group. The 1558 deletion would be successful only on an inactive OSCORE group. 1560 That is, the DELETE request actually yields a successful deletion of 1561 the OSCORE group, only if the corresponding status parameter 'active' 1562 has current value False. The Administrator can ensure that, by first 1563 performing an update of the group-configuration resource associated 1564 to the OSCORE group (see Section 4.6), and setting the corresponding 1565 status parameter 'active' to False. 1567 If, upon receiving the DELETE request, the current value of the 1568 status parameter 'active' is True, the Group Manager MUST respond 1569 with a 4.09 (Conflict) response. The response MUST have Content- 1570 Format set to application/ace-groupcomm+cbor and is formatted as 1571 defined in Section 4 of [I-D.ietf-ace-key-groupcomm]. The value of 1572 the 'error' field MUST be set to 6 ("The group is currently not 1573 active"). 1575 After a successful processing of the request above, the Group Manager 1576 performs the following actions. 1578 First, the Group Manager deletes the OSCORE group and deallocates 1579 both the group-configuration resource as well as the group-membership 1580 resource associated to that group. 1582 Then, the Group Manager replies to the Administrator with a 2.02 1583 (Deleted) response. 1585 Example: 1587 => 0.04 DELETE 1588 Uri-Path: manage 1589 Uri-Path: gp4 1591 <= 2.02 Deleted 1593 4.8.1. Effects on the Group Members 1595 After having deleted an OSCORE group, the Group Manager can inform 1596 the group members by means of the following two methods. When 1597 contacting a group member, the Group Manager uses the pairwise secure 1598 communication association established with that member during its 1599 joining process (see Section 6 of 1600 [I-D.ietf-ace-key-groupcomm-oscore]). 1602 o The Group Manager sends an individual request message to each 1603 group member, targeting the respective resource used to perform 1604 the group rekeying process (see Section 18 of 1605 [I-D.ietf-ace-key-groupcomm-oscore]). The Group Manager uses the 1606 same format of the Joining Response message in Section 6.4 of 1607 [I-D.ietf-ace-key-groupcomm-oscore], where only the parameters 1608 'gkty', 'key', and 'ace-groupcomm-profile' are present, and the 1609 'key' parameter is empty. 1611 o A group member may subscribe for updates to the group-membership 1612 resource associated to the OSCORE group. In particular, if this 1613 relies on CoAP Observe [RFC7641], a group member would receive a 1614 4.04 (Not Found) notification response from the Group Manager, 1615 since the group-configuration resource has been deallocated upon 1616 deleting the OSCORE group (see Section 4.4 of 1617 [I-D.ietf-ace-key-groupcomm]). The response MUST have Content- 1618 Format set to application/ace-groupcomm+cbor and is formatted as 1619 defined in Section 4 of [I-D.ietf-ace-key-groupcomm]. The value 1620 of the 'error' field MUST be set to 5 ("Group deleted"). 1622 When being informed about the deletion of the OSCORE group, a group 1623 member deletes the OSCORE Security Context that it stores as 1624 associated to that group, and possibly deallocates any dedicated 1625 control resource intended for the Group Manager that it has for that 1626 group. 1628 5. Security Considerations 1630 Security considerations are inherited from the ACE framework for 1631 Authentication and Authorization [I-D.ietf-ace-oauth-authz], and from 1632 the specific transport profile of ACE used between the Administrator 1633 and the Group Manager, such as [I-D.ietf-ace-dtls-authorize] and 1634 [I-D.ietf-ace-oscore-profile]. 1636 6. IANA Considerations 1638 This document has the following actions for IANA. 1640 6.1. ACE Groupcomm Parameters Registry 1642 IANA is asked to register the following entries in the "ACE Groupcomm 1643 Parameters" Registry defined in Section 10.5 of 1644 [I-D.ietf-ace-key-groupcomm]. 1646 +-----------------+----------+--------------+-------------------+ 1647 | Name | CBOR Key | CBOR Type | Reference | 1648 +-----------------+----------+--------------+-------------------+ 1649 | hkdf | TBD | tstr / int | [[this document]] | 1650 | | | | | 1651 | alg | TBD | tstr / int | [[this document]] | 1652 | | | | | 1653 | cs_alg | TBD | tstr / int | [[this document]] | 1654 | | | | | 1655 | cs_params | TBD | array | [[this document]] | 1656 | | | | | 1657 | cs_key_params | TBD | array | [[this document]] | 1658 | | | | | 1659 | cs_key_enc | TBD | int | [[this document]] | 1660 | | | | | 1661 | pairwise_mode | TBD | simple value | [[this document]] | 1662 | | | | | 1663 | ecdh_alg | TBD | tstr / int / | [[this document]] | 1664 | | | simple value | | 1665 | | | | | 1666 | ecdh_params | TBD | array / | [[this document]] | 1667 | | | simple value | | 1668 | | | | | 1669 | ecdh_key_params | TBD | array / | [[this document]] | 1670 | | | simple value | | 1671 | | | | | 1672 | active | TBD | simple value | [[this document]] | 1673 | | | | | 1674 | group_name | TBD | tstr | [[this document]] | 1675 | | | | | 1676 | group_title | TBD | tstr / | [[this document]] | 1677 | | | simple value | | 1678 | | | | | 1679 | app_groups | TBD | array | [[this document]] | 1680 | | | | | 1681 | joining_uri | TBD | tstr | [[this document]] | 1682 | | | | | 1683 | as_uri | TBD | tstr | [[this document]] | 1684 | | | | | 1685 | conf_filter | TBD | array | [[this document]] | 1686 | | | | | 1687 | app_groups_diff | TBD | array | [[this document]] | 1688 +-----------------+----------+--------------+-------------------+ 1690 6.2. Resource Types 1692 IANA is asked to enter the following values into the Resource Type 1693 (rt=) Link Target Attribute Values subregistry within the Constrained 1694 Restful Environments (CoRE) Parameters registry defined in [RFC6690]. 1696 +----------------+------------------------------+-------------------+ 1697 | Value | Description | Reference | 1698 +----------------+------------------------------+-------------------+ 1699 | core.osc.gcoll | Group-collection resource | [[this document]] | 1700 | | of an OSCORE Group Manager | | 1701 | | | | 1702 | core.osc.gconf | Group-configuration resource | [[this document]] | 1703 | | of an OSCORE Group Manager | | 1704 +----------------+------------------------------+-------------------+ 1706 7. References 1708 7.1. Normative References 1710 [COSE.Algorithms] 1711 IANA, "COSE Algorithms", 1712 . 1715 [COSE.Elliptic.Curves] 1716 IANA, "COSE Elliptic Curves", 1717 . 1720 [COSE.Key.Types] 1721 IANA, "COSE Key Types", 1722 . 1725 [I-D.ietf-ace-key-groupcomm] 1726 Palombini, F. and M. Tiloca, "Key Provisioning for Group 1727 Communication using ACE", draft-ietf-ace-key-groupcomm-11 1728 (work in progress), February 2021. 1730 [I-D.ietf-ace-key-groupcomm-oscore] 1731 Tiloca, M., Park, J., and F. Palombini, "Key Management 1732 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 1733 oscore-10 (work in progress), February 2021. 1735 [I-D.ietf-ace-oauth-authz] 1736 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1737 H. Tschofenig, "Authentication and Authorization for 1738 Constrained Environments (ACE) using the OAuth 2.0 1739 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-37 1740 (work in progress), February 2021. 1742 [I-D.ietf-ace-oscore-profile] 1743 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 1744 "OSCORE Profile of the Authentication and Authorization 1745 for Constrained Environments Framework", draft-ietf-ace- 1746 oscore-profile-16 (work in progress), January 2021. 1748 [I-D.ietf-core-coral] 1749 Hartke, K., "The Constrained RESTful Application Language 1750 (CoRAL)", draft-ietf-core-coral-03 (work in progress), 1751 March 2020. 1753 [I-D.ietf-core-groupcomm-bis] 1754 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1755 for the Constrained Application Protocol (CoAP)", draft- 1756 ietf-core-groupcomm-bis-03 (work in progress), February 1757 2021. 1759 [I-D.ietf-core-oscore-groupcomm] 1760 Tiloca, M., Selander, G., Palombini, F., Mattsson, J., and 1761 J. Park, "Group OSCORE - Secure Group Communication for 1762 CoAP", draft-ietf-core-oscore-groupcomm-11 (work in 1763 progress), February 2021. 1765 [I-D.ietf-cose-rfc8152bis-algs] 1766 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1767 Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-12 1768 (work in progress), September 2020. 1770 [I-D.ietf-cose-rfc8152bis-struct] 1771 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1772 Structures and Process", draft-ietf-cose-rfc8152bis- 1773 struct-15 (work in progress), February 2021. 1775 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1776 Requirement Levels", BCP 14, RFC 2119, 1777 DOI 10.17487/RFC2119, March 1997, 1778 . 1780 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1781 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1782 . 1784 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1785 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1786 . 1788 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1789 Application Protocol (CoAP)", RFC 7252, 1790 DOI 10.17487/RFC7252, June 2014, 1791 . 1793 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1794 Application Protocol (CoAP)", RFC 7641, 1795 DOI 10.17487/RFC7641, September 2015, 1796 . 1798 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 1799 FETCH Methods for the Constrained Application Protocol 1800 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 1801 . 1803 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1804 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1805 May 2017, . 1807 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1808 Definition Language (CDDL): A Notational Convention to 1809 Express Concise Binary Object Representation (CBOR) and 1810 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1811 June 2019, . 1813 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1814 "Object Security for Constrained RESTful Environments 1815 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1816 . 1818 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1819 Representation (CBOR)", STD 94, RFC 8949, 1820 DOI 10.17487/RFC8949, December 2020, 1821 . 1823 7.2. Informative References 1825 [I-D.hartke-t2trg-coral-reef] 1826 Hartke, K., "Resource Discovery in Constrained RESTful 1827 Environments (CoRE) using the Constrained RESTful 1828 Application Language (CoRAL)", draft-hartke-t2trg-coral- 1829 reef-04 (work in progress), May 2020. 1831 [I-D.ietf-ace-dtls-authorize] 1832 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 1833 L. Seitz, "Datagram Transport Layer Security (DTLS) 1834 Profile for Authentication and Authorization for 1835 Constrained Environments (ACE)", draft-ietf-ace-dtls- 1836 authorize-15 (work in progress), January 2021. 1838 [I-D.ietf-core-resource-directory] 1839 Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P. 1840 Stok, "CoRE Resource Directory", draft-ietf-core-resource- 1841 directory-26 (work in progress), November 2020. 1843 [I-D.ietf-tls-dtls13] 1844 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1845 Datagram Transport Layer Security (DTLS) Protocol Version 1846 1.3", draft-ietf-tls-dtls13-41 (work in progress), 1847 February 2021. 1849 [I-D.tiloca-core-oscore-discovery] 1850 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 1851 Groups with the CoRE Resource Directory", draft-tiloca- 1852 core-oscore-discovery-08 (work in progress), February 1853 2021. 1855 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1856 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1857 January 2012, . 1859 Appendix A. Document Updates 1861 RFC EDITOR: PLEASE REMOVE THIS SECTION. 1863 A.1. Version -01 to -02 1865 o Admit multiple Administrators and limited access to admin 1866 resources. 1868 o Early design considerations for defining the format of scope. 1870 o Additional error handling, using also error types. 1872 o Selective update of group-configuration resources with PATCH/ 1873 iPATCH. 1875 o Editorial improvements. 1877 A.2. Version -00 to -01 1879 o Names of application groups as status parameter. 1881 o Parameters related to the pairwise mode of Group OSCORE. 1883 o Defined FETCH for group-configuration resources. 1885 o Policies on registration of links to the Resource Directory. 1887 o Added resource type for group-configuration resources. 1889 o Fixes, clarifications and editorial improvements. 1891 Acknowledgments 1893 The authors sincerely thank Christian Amsuess, Carsten Bormann and 1894 Jim Schaad for their comments and feedback. 1896 The work on this document has been partly supported by VINNOVA and 1897 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 1898 (Grant agreement 952652). 1900 Authors' Addresses 1902 Marco Tiloca 1903 RISE AB 1904 Isafjordsgatan 22 1905 Kista SE-16440 Stockholm 1906 Sweden 1908 Email: marco.tiloca@ri.se 1910 Rikard Hoeglund 1911 RISE AB 1912 Isafjordsgatan 22 1913 Kista SE-16440 Stockholm 1914 Sweden 1916 Email: rikard.hoglund@ri.se 1917 Peter van der Stok 1918 Consultant 1920 Phone: +31-492474673 (Netherlands), +33-966015248 (France) 1921 Email: consultancy@vanderstok.org 1922 URI: www.vanderstok.org 1924 Francesca Palombini 1925 Ericsson AB 1926 Torshamnsgatan 23 1927 Kista SE-16440 Stockholm 1928 Sweden 1930 Email: francesca.palombini@ericsson.com 1932 Klaus Hartke 1933 Ericsson AB 1934 Torshamnsgatan 23 1935 Kista SE-16440 Stockholm 1936 Sweden 1938 Email: klaus.hartke@ericsson.com