idnits 2.17.1 draft-tiloca-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 4 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 (July 13, 2020) is 1381 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 765 -- Looks like a reference, but probably isn't: '6' on line 765 == Outdated reference: A later version (-18) exists of draft-ietf-ace-key-groupcomm-08 == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-08 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-35 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-11 == Outdated reference: A later version (-06) exists of draft-ietf-core-coral-03 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-09 == Outdated reference: A later version (-12) exists of draft-ietf-cose-rfc8152bis-algs-11 ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') == Outdated reference: A later version (-15) exists of draft-ietf-cose-rfc8152bis-struct-11 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-12 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-24 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-38 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-05 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 14 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: January 14, 2021 P. van der Stok 6 Consultant 7 F. Palombini 8 K. Hartke 9 Ericsson AB 10 July 13, 2020 12 Admin Interface for the OSCORE Group Manager 13 draft-tiloca-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 January 14, 2021. 47 Copyright Notice 49 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . 5 67 2.1. Getting Access to the Group Manager . . . . . . . . . . . 6 68 2.2. Managing OSCORE Groups . . . . . . . . . . . . . . . . . 7 69 2.3. Group Configurations . . . . . . . . . . . . . . . . . . 8 70 2.3.1. Group Configuration Representation . . . . . . . . . 8 71 2.3.2. Default Values . . . . . . . . . . . . . . . . . . . 10 72 2.4. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10 73 2.5. Collection Representation . . . . . . . . . . . . . . . . 10 74 2.6. Interactions . . . . . . . . . . . . . . . . . . . . . . 11 75 2.6.1. Get All Groups Configurations . . . . . . . . . . . . 11 76 2.6.2. Fetch Group Configurations By Filters . . . . . . . . 12 77 2.6.3. Create a New Group Configuration . . . . . . . . . . 13 78 2.6.4. Retrieve a Group Configuration . . . . . . . . . . . 17 79 2.6.5. Update a Group Configuration . . . . . . . . . . . . 18 80 2.6.6. Delete a Group Configuration . . . . . . . . . . . . 21 81 3. Security Considerations . . . . . . . . . . . . . . . . . . . 23 82 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 83 4.1. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 23 84 4.2. Resource Types . . . . . . . . . . . . . . . . . . . . . 24 85 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 86 5.1. Normative References . . . . . . . . . . . . . . . . . . 25 87 5.2. Informative References . . . . . . . . . . . . . . . . . 27 88 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 91 1. Introduction 93 The Constrained Application Protocol (CoAP) [RFC7252] can be used in 94 group communication environments where messages are also exchanged 95 over IP multicast [I-D.dijk-core-groupcomm-bis]. Applications 96 relying on CoAP can achieve end-to-end security at the application 97 layer by using Object Security for Constrained RESTful Environments 98 (OSCORE) [RFC8613], and especially Group OSCORE 99 [I-D.ietf-core-oscore-groupcomm] in group communication scenarios. 101 When group communication for CoAP is protected with Group OSCORE, 102 nodes are required to explicitly join the correct OSCORE group. To 103 this end, a joining node interacts with a Group Manager (GM) entity 104 responsible for that group, and retrieves the required key material 105 to securely communicate with other group members using Group OSCORE. 107 The method in [I-D.ietf-ace-key-groupcomm-oscore] specifies how nodes 108 can join an OSCORE group through the respective Group Manager. Such 109 a method builds on the ACE framework for Authentication and 110 Authorization [I-D.ietf-ace-oauth-authz], so ensuring a secure 111 joining process as well as authentication and authorization of 112 joining nodes (clients) at the Group Manager (resource server). 114 In some deployments, the application running on the Group Manager may 115 know when a new OSCORE group has to be created, as well as how it 116 should be configured and later on updated or deleted, e.g. based on 117 the current application state or on pre-installed policies. In this 118 case, the Group Manager application can create and configure OSCORE 119 groups when needed, by using a local application interface. However, 120 this requires the Group Manager to be application-specific, which in 121 turn leads to error prone deployments and is poorly flexible. 123 In other deployments, a separate Administrator entity, such as a 124 Commissioning Tool, is directly responsible for creating and 125 configuring the OSCORE groups at a Group Manager, as well as for 126 maintaining them during their whole lifetime until their deletion. 127 This allows the Group Manager to be agnostic of the specific 128 applications using secure group communication. 130 This document specifies a RESTful admin interface at the Group 131 Manager, intended for an Administrator, as a separate entity external 132 to the Group Manager and its application. The interface allows the 133 Administrator to create and delete OSCORE groups, as well as to 134 configure and update their configuration. 136 Interaction examples are provided, in Link Format [RFC6690] and CBOR 137 [RFC7049], as well as in CoRAL [I-D.ietf-core-coral]. While all the 138 CoRAL examples use the CoRAL textual serialization format, the CBOR 139 or JSON [RFC8259] binary serialization format is used when sending 140 such messages on the wire. 142 The ACE framework is used to ensure authentication and authorization 143 of the Administrator (client) at the Group Manager (resource server). 144 In order to achieve communication security, proof-of-possession and 145 server authentication, the Administrator and the Group Manager 146 leverage protocol-specific transport profiles of ACE, such as 147 [I-D.ietf-ace-oscore-profile][I-D.ietf-ace-dtls-authorize]. These 148 include also possible forthcoming transport profiles that comply with 149 the requirements in Appendix C of [I-D.ietf-ace-oauth-authz]. 151 1.1. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in BCP 156 14 [RFC2119] [RFC8174] when, and only when, they appear in all 157 capitals, as shown here. 159 Readers are expected to be familiar with the terms and concepts 160 related to CBOR [RFC7049] and COSE 161 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs], the 162 CoAP protocol [RFC7252], as well as the protection and processing of 163 CoAP messages using OSCORE [RFC8613], also in group communication 164 scenarios using Group OSCORE [I-D.ietf-core-oscore-groupcomm]. These 165 include the concept of Group Manager, as the entity responsible for a 166 set of groups where communications among members are secured using 167 Group OSCORE. 169 Readers are also expected to be familiar with the terms and concept 170 related to the management of keying material for groups in ACE 171 defined in [I-D.ietf-ace-key-groupcomm], and in particular to the 172 joining process for OSCORE groups defined in 173 [I-D.ietf-ace-key-groupcomm-oscore]. These include the concept of 174 group-membership resource hosted by the Group Manager, that new 175 members access to join the OSCORE group, while current members can 176 access to retrieve updated keying material. 178 Readers are also expected to be familiar with the terms and concepts 179 described in the ACE framework for authentication and authorization 180 [I-D.ietf-ace-oauth-authz]. The terminology for entities in the 181 considered architecture is defined in OAuth 2.0 [RFC6749]. In 182 particular, this includes Client (C), Resource Server (RS), and 183 Authorization Server (AS). 185 Note that, unless otherwise indicated, the term "endpoint" is used 186 here following its OAuth definition, aimed at denoting resources such 187 as /token and /introspect at the AS, and /authz-info at the RS. This 188 document does not use the CoAP definition of "endpoint", which is "An 189 entity participating in the CoAP protocol". 191 This document also refers to the following terminology. 193 o Administrator: entity responsible to create, configure and delete 194 OSCORE groups at a Group Manager. 196 o Group name: stable and invariant name of an OSCORE group. The 197 group name MUST be unique under the same Group Manager, and MUST 198 include only characters that are valid for a URI path segment, 199 namely unreserved and pct-encoded characters [RFC3986]. 201 o Group-collection resource: a single-instance resource hosted by 202 the Group Manager. An Administrator accesses a group-collection 203 resource to create a new OSCORE group, or to retrieve the list of 204 existing OSCORE groups, under that Group Manager. As an example, 205 this document uses /manage as the url-path of the group-collection 206 resource; implementations are not required to use this name, and 207 can define their own instead. 209 o Group-configuration resource: a resource hosted by the Group 210 Manager, associated to an OSCORE group under that Group Manager. 211 A group-configuration resource is identifiable with the invariant 212 group name of the respective group. An Administrator accesses a 213 group-configuration resource to retrieve or update the 214 configuration of the respective OSCORE group, or to delete that 215 group. The url-path to a group-configuration resource has NAME as 216 last segment, with NAME the invariant group name assigned upon its 217 creation. Building on the considered url-path of the group- 218 collection resource, this document uses /manage/NAME as the url- 219 path of a group-configuration resource; implementations are not 220 required to use this name, and can define their own instead. 222 o Admin endpoint: an endpoint at the Group Manager associated to the 223 group-collection resource or to a group-configuration resource 224 hosted by that Group Manager. 226 2. Group Administration 228 With reference to the ACE framework and the terminology defined in 229 OAuth 2.0 [RFC6749]: 231 o The Group Manager acts as Resource Server (RS). It provides one 232 single group-collection resource, and one group-configuration 233 resource per existing OSCORE group. Each of those is exported by 234 a distinct admin endpoint. 236 o The Administrator acts as Client (C), and requests to access the 237 group-collection resource and group-configuration resources, by 238 accessing the respective admin endpoint at the Group Manager. 240 o The Authorization Server (AS) authorizes the Administrator to 241 access the group-collection resource and group-configuration 242 resources at a Group Manager. Multiple Group Managers can be 243 associated to the same AS. The AS MAY release Access Tokens to 244 the Administrator for other purposes than accessing admin 245 endpoints of registered Group Managers. 247 2.1. Getting Access to the Group Manager 249 All communications between the involved entities rely on the CoAP 250 protocol and MUST be secured. 252 In particular, communications between the Administrator and the Group 253 Manager leverage protocol-specific transport profiles of ACE to 254 achieve communication security, proof-of-possession and server 255 authentication. To this end, the AS may explicitly signal the 256 specific transport profile to use, consistently with requirements and 257 assumptions defined in the ACE framework [I-D.ietf-ace-oauth-authz]. 259 With reference to the AS, communications between the Administrator 260 and the AS (/token endpoint) as well as between the Group Manager and 261 the AS (/introspect endpoint) can be secured by different means, for 262 instance using DTLS [RFC6347][I-D.ietf-tls-dtls13] or OSCORE 263 [RFC8613]. Further details on how the AS secures communications 264 (with the Administrator and the Group Manager) depend on the 265 specifically used transport profile of ACE, and are out of the scope 266 of this specification. 268 In order to get access to the Group Manager for managing OSCORE 269 groups, an Administrator performs the following steps. 271 1. The Administrator requests an Access Token from the AS, in order 272 to access the group-collection and group-configuration resources 273 on the Group Manager. The Administrator will start or continue 274 using secure communications with the Group Manager, according to 275 the response from the AS. 277 2. The Administrator transfers authentication and authorization 278 information to the Group Manager by posting the obtained Access 279 Token, according to the used profile of ACE, such as 280 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile]. 281 After that, the Administrator must have secure communication 282 established with the Group Manager, before performing any admin 283 operation on that Group Manager. Possible ways to provide secure 284 communication are DTLS [RFC6347][I-D.ietf-tls-dtls13] and OSCORE 285 [RFC8613]. The Administrator and the Group Manager maintain the 286 secure association, to support possible future communications. 288 3. The Administrator performs admin operations at the Group Manager, 289 as described in the following sections. These include the 290 retrieval of the existing OSCORE groups, the creation of new 291 OSCORE groups, the update and retrieval of group configurations, 292 and the removal of OSCORE groups. Messages exchanged among the 293 Administrator and the Group Manager are specified in Section 2.6. 295 2.2. Managing OSCORE Groups 297 Figure 1 shows the resources of a Group Manager available to an 298 Administrator. 300 ___ 301 Group / \ 302 Collection \___/ 303 \ 304 \____________________ 305 \___ \___ \___ 306 / \ / \ ... / \ Group 307 \___/ \___/ \___/ Configurations 309 Figure 1: Resources of a Group Manager 311 The Group Manager exports a single group-collection resource. The 312 full interface for the group-collection resource allows the 313 Administrator to: 315 o Retrieve the list of existing OSCORE groups, possibly by filters. 317 o Create a new OSCORE group, specifying its invariant group name 318 and, optionally, its configuration. 320 The Group Manager exports one group-configuration resource for each 321 of its OSCORE groups. Each group-configuration resource is 322 identified by the group name specified upon creating the group. The 323 full interface for a group-configuration resource allows the 324 Administrator to: 326 o Retrieve the current configuration of the OSCORE group. 328 o Update the current configuration of the OSCORE group. 330 o Delete the OSCORE group. 332 2.3. Group Configurations 334 A group configuration consists of a set of parameters. 336 2.3.1. Group Configuration Representation 338 The group configuration representation is a CBOR map which MUST 339 include configuration properties and status properties. 341 2.3.1.1. Configuration Properties 343 The CBOR map MUST include the following configuration parameters: 345 o 'hkdf', defined in Section 4.1 of this document, specifies the 346 HKDF algorithm used in the OSCORE group, encoded as a CBOR text 347 string. Possible values are the same ones admitted for the 'hkdf' 348 parameter of the "OSCORE Security Context Parameters" registry, 349 defined in Section 3.2.1 of [I-D.ietf-ace-oscore-profile]. 351 o 'alg', defined in Section 4.1 of this document, specifies the AEAD 352 algorithm used in the OSCORE group, encoded as a CBOR text string. 353 Possible values are the same ones admitted for the 'alg' parameter 354 of the "OSCORE Security Context Parameters" registry, defined in 355 Section 3.2.1 of [I-D.ietf-ace-oscore-profile]. 357 o 'cs_alg', defined in Section 4.1 of this document, specifies the 358 countersignature algorithm used in the OSCORE group, encoded as a 359 CBOR text string or integer. Possible values are the same ones 360 admitted for the 'cs_alg' parameter of the "OSCORE Security 361 Context Parameters" registry, defined in Section 6.4 of 362 [I-D.ietf-ace-key-groupcomm-oscore]. 364 o 'cs_params', defined in Section 4.1 of this document, specifies 365 the additional parameters for the countersignature algorithm used 366 in the OSCORE group, encoded as a CBOR array. Possible formats 367 and values are the same ones admitted for the 'cs_params' 368 parameter of the "OSCORE Security Context Parameters" registry, 369 defined in Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore]. 371 o 'cs_key_params', defined in Section 4.1 of this document, 372 specifies the additional parameters for the key used with the 373 countersignature algorithm in the OSCORE group, encoded as a CBOR 374 array. Possible formats and values are the same ones admitted for 375 the 'cs_key_params' parameter of the "OSCORE Security Context 376 Parameters" registry, defined in Section 6.4 of 377 [I-D.ietf-ace-key-groupcomm-oscore]. 379 o 'cs_key_enc', defined in Section 4.1 of this document, specifies 380 the encoding of the public keys of group members, encoded as a 381 CBOR integer. Possible values are the same ones admitted for the 382 'cs_key_enc' parameter of the "OSCORE Security Context Parameters" 383 registry, defined in Section 6.4 of 384 [I-D.ietf-ace-key-groupcomm-oscore]. 386 2.3.1.2. Status Properties 388 The CBOR map MUST include the following status parameters: 390 o 'active', encoding the CBOR simple value True if the group is 391 currently active, or the CBOR simple value False otherwise. This 392 parameter is defined in Section 4.1 of this specification. 394 o 'group_name', with value the group name of the OSCORE group 395 encoded as a CBOR text string. This parameter is defined in 396 Section 4.1 of this specification. 398 o 'group_title', with value either a human-readable description of 399 the group encoded as a CBOR text string, or the CBOR simple value 400 Null if no description is specified. This parameter is defined in 401 Section 4.1 of this specification. 403 o 'ace-groupcomm-profile', defined in Section 4.1.2.1 of 404 [I-D.ietf-ace-key-groupcomm], with value "coap_group_oscore_app". 406 o 'exp', defined in Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm]. 408 o 'joining_uri', with value the URI of the group-membership resource 409 for joining the newly created OSCORE group, encoded as a CBOR text 410 string. This parameter is defined in Section 4.1 of this 411 specification. 413 The CBOR map MAY include the following status parameters: 415 o 'group_policies', defined in Section 4.1.2.1 of 416 [I-D.ietf-ace-key-groupcomm], and consistent with the format and 417 content defined in Section 6.4 of 418 [I-D.ietf-ace-key-groupcomm-oscore]. 420 o 'as_uri', defined in Section 4.1 of this document, specifies the 421 URI of the Authorization Server associated to the Group Manager 422 for the OSCORE group, encoded as a CBOR text string. Candidate 423 group members will have to obtain an Access Token from that 424 Authorization Server, before starting the joining process with the 425 Group Manager to join the OSCORE group (see 426 [I-D.ietf-ace-key-groupcomm-oscore]). 428 2.3.2. Default Values 430 This section defines the default values that the Group Manager 431 assumes for configuration and status parameters. 433 2.3.2.1. Configuration Parameters 435 For each configuration parameter, the Group Manager MUST assume a 436 pre-configured default value, if none is specified by the 437 Administrator. 439 In particular, the Group Manager SHOULD use the same default values 440 defined in Section 18 of [I-D.ietf-ace-key-groupcomm-oscore]. 442 2.3.2.2. Status Parameters 444 For the following status parameters, the Group Manager MUST assume a 445 pre-configured default value, if none is specified by the 446 Administrator. 448 o For 'active', the CBOR simple value False. 450 o For 'group_title', the CBOR simple value Null. 452 2.4. Discovery 454 The Administrator can discover the group-collection resource from a 455 resource directory, for instance [I-D.ietf-core-resource-directory] 456 and [I-D.hartke-t2trg-coral-reef], or from .well-known/core , by 457 using the resource type "ace.oscore.gm" defined in Section 4.2 of 458 this specification. 460 The Administrator can discover group-configuration resources for the 461 group-collection resource as specified below in Section 2.6.1 and 462 Section 2.6.2. 464 2.5. Collection Representation 466 A list of group configurations is represented as a document 467 containing the corresponding group-configuration resources in the 468 list. Each group-configuration is represented as a link, where the 469 link target is the URI of the group-configuration resource. 471 The list can be represented as a Link Format document [RFC6690] or a 472 CoRAL document [I-D.ietf-core-coral]. In the latter case, the CoRAL 473 document contains the group-configuration resources in the list as 474 top-level elements. In particular, the link to each group- 475 configuration resource has http://coreapps.org/ace.oscore.gm#item as 476 relation type. 478 2.6. Interactions 480 This section describes the operations available on the group- 481 collection resource and the group-configuration resources. 483 When custom CBOR is used, the Content-Format in messages containing a 484 payload is set to application/ace-groupcomm+cbor, defined in 485 Section 8.2 of [I-D.ietf-ace-key-groupcomm]. Furthermore, the entry 486 labels defined in Section 4.1 MUST be used, when specifying the 487 corresponding configuration and status parameters. 489 2.6.1. Get All Groups Configurations 491 The Administrator can send a GET request to the group-collection 492 resource, in order to retrieve the list of the existing OSCORE groups 493 at the Group Manager. This is returned as a list of links to the 494 corresponding group-configuration resources. 496 Example in Link Format: 498 => 0.01 GET 499 Uri-Path: manage 501 <= 2.05 Content 502 Content-Format: 40 (application/link-format) 504 , 505 , 506 508 Example in CoRAL: 510 => 0.01 GET 511 Uri-Path: manage 513 <= 2.05 Content 514 Content-Format: TBD1 (application/coral+cbor) 516 #using 517 #base 518 item 519 item 520 item 522 2.6.2. Fetch Group Configurations By Filters 524 The Administrator can send a FETCH request to the group-collection 525 resource, in order to retrieve the list of the existing OSCORE groups 526 at the Group Manager that fully match a set of specified filter 527 criteria. This is returned as a list of links to the corresponding 528 group-configuration resources. 530 The set of filter criteria is specified in the request payload as a 531 CBOR map, where possible entry labels are all the ones used for 532 configuration properties (see Section 2.3.1.1), as well as 533 "group_name" and "active" for the corresponding status property (see 534 Section 2.3.1.2). 536 Entry values are the ones admitted for the corresponding labels in 537 the POST request for creating a group configuration (see 538 Section 2.6.3). A valid request MUST NOT include the same entry 539 multiple times. 541 Example in custom CBOR and Link Format: 543 => 0.05 FETCH 544 Uri-Path: manage 545 Content-Format: TBD2 (application/ace-groupcomm+cbor) 547 { 548 "alg" : 10, 549 "hkdf" : 5 550 } 552 <= 2.05 Content 553 Content-Format: 40 (application/link-format) 555 , 556 , 557 559 Example in CoRAL: 561 => 0.05 FETCH 562 Uri-Path: manage 563 Content-Format: TBD1 (application/coral+cbor) 565 alg 10 566 hkdf 5 568 <= 2.05 Content 569 Content-Format: TBD1 (application/coral+cbor) 571 #using 572 #base 573 item 574 item 575 item 577 2.6.3. Create a New Group Configuration 579 The Administrator can send a POST request to the group-collection 580 resource, in order to create a new OSCORE group at the Group Manager. 581 The request MAY specify the intended group name NAME and group title, 582 and MAY specify pieces of information concerning the group 583 configuration. 585 The request payload is a CBOR map, whose possible entries are 586 specified in Section 2.3.1. In particular: 588 o The CBOR map MAY include any of the configuration parameter 589 defined in Section 2.3.1.1. 591 o The CBOR map MAY include any of the status parameter 'group_name', 592 'group_title', 'exp', 'group_policies', 'as_uri' and 'active' 593 defined in Section 2.3.1.2. 595 o The CBOR map MUST NOT include any of the status parameter 'ace- 596 groupcomm-profile' and 'joining_uri' defined in Section 2.3.1.2. 598 If any of the following occurs, the Group Manager MUST respond with a 599 4.00 (Bad Request) response, which MAY include additional information 600 to clarify what went wrong. 602 o Any of the received parameters is specified multiple times. 604 o Any of the received parameters is not recognized, or not valid, or 605 not consistent with respect to other related parameters. 607 o The 'group_name' parameter specifies the group name of an already 608 existing OSCORE group. 610 o The Group Manager does not trust the Authorization Server with URI 611 specified in the 'as_uri' parameter, and has no alternative 612 Authorization Server to consider for the OSCORE group to create. 614 After a successful processing of the request above, the Group Manager 615 performs the following actions. 617 First, the Group Manager creates a new group-configuration resource, 618 accessible to the administrator at /manage/NAME , where NAME is the 619 group name as either indicated in the parameter 'group_name' of the 620 request or uniquely assigned by the Group Manager. The values 621 specified in the request are used as group configuration information 622 for the newly created OSCORE group. For each configuration parameter 623 not specified in the request, the Group Manager MUST assume the 624 default value specified in Section 2.3.2. 626 After that, the Group Manager creates a new group-membership 627 resource, accessible to joining nodes and future group members at 628 group-oscore/NAME , as specified in 629 [I-D.ietf-ace-key-groupcomm-oscore]. In particular, the Group 630 Manager will rely on the current group configuration to build the 631 Joining Response message defined in Section 5.4 of 632 [I-D.ietf-ace-key-groupcomm-oscore], when handling the joining of a 633 new group member. Furthermore, the Group Manager generates the 634 following pieces of information, and assigns them to the newly 635 created OSCORE group: 637 o The OSCORE Master Secret. 639 o The OSCORE Master Salt (optionally). 641 o The OSCORE ID Context, acting as Group ID, which MUST be unique 642 within the set of OSCORE groups under the Group Manager. 644 Finally, the Group Manager replies to the Administrator with a 2.01 645 (Created) response. The Location-Path option MUST be included in the 646 response, indicating the location of the just created group- 647 configuration resource. The response MUST NOT include a Location- 648 Query option. The response payload is a CBOR map, which MUST include 649 the following parameters: 651 o 'group_name', with value the group name of the OSCORE group 652 encoded as a CBOR text string. This value can be different from 653 the group name possibly specified by the Administrator in the POST 654 request, and reflects the final choice of the Group Manager as 655 'group_name' status property for the OSCORE group. 657 o 'joining_uri', with value the URI of the group-membership resource 658 for joining the newly created OSCORE group, encoded as a CBOR text 659 string. 661 o 'as_uri', with value the URI of the Authorization Server 662 associated to the Group Manager for the newly created OSCORE 663 group, encoded as a CBOR text string. This value can be different 664 from the URI possibly specified by the Administrator in the POST 665 request, and reflects the final choice of the Group Manager as 666 'as_uri' status property for the OSCORE group. 668 At this point, the Group Manager can register the link to the group- 669 membership resource with URI specified in 'joining_uri' to the CoRE 670 Resource Directory [I-D.ietf-core-resource-directory], as defined in 671 Section 2 of [I-D.tiloca-core-oscore-discovery]. 673 Alternatively, the Administrator can perform the registration to the 674 Resource Directory on behalf of the Group Manager, acting as 675 Commissioning Tool. The Administrator considers the following when 676 specifying additional information for the link to register. 678 o The name of the OSCORE group MUST take the value specified in 679 'group_name' from the 2.01 (Created) response above. 681 o If present, parameters describing the cryptographic algorithms 682 used in the group MUST follow the values that the Administrator 683 specified in the POST request above, or the corresponding default 684 values specified in Section 2.3.2.1 otherwise. 686 o If also registering a related link to the Authorization Server 687 associated to the OSCORE group, the related link MUST have the URI 688 specified in 'as_uri' from the 2.01 (Created) response above. 690 Example in custom CBOR: 692 => 0.02 POST 693 Uri-Path: manage 694 Content-Format: TBD2 (application/ace-groupcomm+cbor) 696 { 697 "alg" : 10, 698 "hkdf" : 5, 699 "active" : True, 700 "group_title" : "rooms 1 and 2", 701 "as_uri" : "coap://as.example.com/token" 702 } 704 <= 2.01 Created 705 Location-Path: manage 706 Location-Path: gp4 707 Content-Format: TBD2 (application/ace-groupcomm+cbor) 709 { 710 "group_name" : "gp4", 711 "joining_uri" : "coap://[2001:db8::ab]/group-oscore/gp4/", 712 "as_uri" : "coap://as.example.com/token" 713 } 715 Example in CoRAL: 717 => 0.02 POST 718 Uri-Path: manage 719 Content-Format: TBD1 (application/coral+cbor) 721 #using 722 alg 10 723 hkdf 5 724 active True 725 group_title "rooms 1 and 2" 726 as_uri 728 <= 2.01 Created 729 Location-Path: manage 730 Location-Path: gp4 731 Content-Format: TBD1 (application/coral+cbor) 733 #using 734 group_name "gp4" 735 joining_uri 736 as_uri 738 2.6.4. Retrieve a Group Configuration 740 The Administrator can send a GET request to the group-configuration 741 resource manage/NAME associated to an OSCORE group with group name 742 NAME, in order to retrieve the current configuration of that group. 744 After a successful processing of the request above, the Group Manager 745 replies to the Administrator with a 2.05 (Content) response. The 746 response has as payload the representation of the group configuration 747 as specified in Section 2.3.1. The exact content of the payload 748 reflects the current configuration of the OSCORE group. This 749 includes both configuration properties and status properties. 751 Example in custom CBOR: 753 => 0.01 GET 754 Uri-Path: manage 755 Uri-Path: gp4 757 <= 2.05 Content 758 Content-Format: TBD2 (application/ace-groupcomm+cbor) 760 { 761 "alg" : 10, 762 "hkdf" : 5, 763 "cs_alg" : -8, 764 "cs_params" : [[1], [1, 6]], 765 "cs_key_params" : [1, 6], 766 "cs_key_enc" : 1, 767 "active" : True, 768 "group_name" : "gp4", 769 "group_title" : "rooms 1 and 2", 770 "ace-groupcomm-profile" : "coap_group_oscore_app", 771 "exp" : "1360289224", 772 "joining_uri" : "coap://[2001:db8::ab]/group-oscore/gp4/", 773 "as_uri" : "coap://as.example.com/token" 774 } 776 Example in CoRAL: 778 => 0.01 GET 779 Uri-Path: manage 780 Uri-Path: gp4 782 <= 2.05 Content 783 Content-Format: TBD1 (application/coral+cbor) 785 #using 786 alg 10 787 hkdf 5 788 cs_alg -8 789 cs_params.alg_capab.key_type 1 790 cs_params.key_type_capab.key_type 1 791 cs_params.key_type_capab.curve 6 792 cs_key_params.key_type 1 793 cs_key_params.curve 6 794 cs_key_enc 1 795 active True 796 group_name "gp4" 797 group_title "rooms 1 and 2" 798 ace-groupcomm-profile "coap_group_oscore_app" 799 exp "1360289224" 800 joining_uri 801 as_uri 803 2.6.5. Update a Group Configuration 805 The Administrator can send a PUT request to the group-configuration 806 resource associated to an OSCORE group, in order to update the 807 current configuration of that group. The payload of the request has 808 the same format of the POST request defined in Section 2.6.3, with 809 the exception of the status parameter 'group_name' that MUST NOT be 810 included. 812 The error handling for the PUT request is the same as for the POST 813 request defined in Section 2.6.3. If no error occurs, the Group 814 Manager performs the following actions. 816 First, the Group Manager updates the configuration of the OSCORE 817 group, consistently with the values indicated in the PUT request from 818 the Administrator. For each configuration parameter not specified in 819 the PUT request, the Group Manager MUST use the default value 820 specified in Section 2.3.2. From then on, the Group Manager relies 821 on the latest update configuration to build the Joining Response 822 message defined in Section 5.4 of 823 [I-D.ietf-ace-key-groupcomm-oscore], when handling the joining of a 824 new group member. 826 Then, the Group Manager replies to the Administrator with a 2.04 827 (Changed) response. The payload of the response has the same format 828 of the 2.01 (Created) response defined in Section 2.6.3. 830 If the link to the group-membership resource was registered in the 831 Resource Directory (see [I-D.ietf-core-resource-directory]), the GM 832 is responsible to refresh the registration, as defined in Section 3 833 of [I-D.tiloca-core-oscore-discovery]. 835 Alternatively, the Administrator can update the registration to the 836 Resource Directory on behalf of the Group Manager, acting as 837 Commissioning Tool. The Administrator considers the following when 838 specifying additional information for the link to update. 840 o The name of the OSCORE group MUST take the value specified in 841 'group_name' from the 2.04 (Changed) response above. 843 o If present, parameters describing the cryptographic algorithms 844 used in the group MUST follow the values that the Administrator 845 specified in the POST request above, or the corresponding default 846 values specified in Section 2.3.2.1 otherwise. 848 o If also registering a related link to the Authorization Server 849 associated to the OSCORE group, the related link MUST have the URI 850 specified in 'as_uri' from the 2.04 (Changed) response above. 852 Example in custom CBOR: 854 => PUT 855 Uri-Path: manage 856 Uri-Path: gp4 857 Content-Format: TBD2 (application/ace-groupcomm+cbor) 859 { 860 "alg" : 11 , 861 "hkdf" : 5 862 } 864 <= 2.04 Changed 865 Content-Format: TBD2 (application/ace-groupcomm+cbor) 867 { 868 "group_name" : "gp4", 869 "joining_uri" : "coap://[2001:db8::ab]/group-oscore/gp4/", 870 "as_uri" : "coap://as.example.com/token" 871 } 873 Example in CoRAL: 875 => PUT 876 Uri-Path: manage 877 Uri-Path: gp4 878 Content-Format: TBD1 (application/coral+cbor) 880 #using 881 alg 11 882 hkdf 5 884 <= 2.04 Changed 885 Content-Format: TBD1 (application/coral+cbor) 887 #using 888 group_name "gp4" 889 joining_uri 890 as_uri 892 2.6.5.1. Effects on Joining Nodes 894 If the value of the status parameter 'active' is changed from True to 895 False, the Group Manager MUST stop admitting new members in the 896 group. In particular, upon receiving a Joining Request (see 897 Section 5.3 of [I-D.ietf-ace-key-groupcomm-oscore]), the Group 898 Manager MUST respond with a 5.03 (Service Unavailable) response to 899 the joining node, and MAY include additional information to clarify 900 what went wrong. 902 If the value of the status parameter 'active' is changed from False 903 to True, the Group Manager resumes admitting new members in the 904 group, by processing their Joining Requests (see Section 5.3 of 905 [I-D.ietf-ace-key-groupcomm-oscore]). 907 2.6.5.2. Effects on the Group Members 909 After having updated a group configuration, the Group Manager informs 910 the group members, over the pairwise secure communication channels 911 established when joining the OSCORE group (see Section 5 of 912 [I-D.ietf-ace-key-groupcomm-oscore]). 914 To this end, the Group Manager can individually target the 915 'control_path' URI path of each group member (see Section 4.1.2.1 of 916 [I-D.ietf-ace-key-groupcomm]), if provided by the intended recipient 917 upon joining the group (see Section 5 of 918 [I-D.ietf-ace-key-groupcomm-oscore]). Alternatively, group members 919 can subscribe for updates to the group-membership resource of the 920 OSCORE group, e.g. by using CoAP Observe [RFC7641]. 922 Every group member, upon learning that the group has been deactivated 923 (i.e. 'active' has value False), SHOULD stop communicating in the 924 OSCORE group. 926 Every group member, upon learning that the group has been reactivated 927 (i.e. 'active' has value True again), can resume communicating in the 928 OSCORE group. 930 Every group member, upon receiving updated values for 'alg' and 931 'hkdf', MUST either: 933 o Leave the group (see Section 14 of 934 [I-D.ietf-ace-key-groupcomm-oscore]), e.g. if not supporting the 935 indicated new algorithms; or 937 o Use the new parameter values, and accordingly re-derive the OSCORE 938 Security Context for the group (see Section 2 of 939 [I-D.ietf-core-oscore-groupcomm]). 941 Every group member, upon receiving updated values for 'cs_alg', 942 'cs_params', 'cs_key_params' and 'cs_key_enc', MUST either: 944 o Leave the group, e.g. if not supporting the indicated new 945 algorithm, parameters and encoding; or 947 o Leave the group and rejoin it (see Section 5 of 948 [I-D.ietf-ace-key-groupcomm-oscore]), providing the Group Manager 949 with a public key which is compatible with the indicated new 950 algorithm, parameters and encoding; or 952 o Use the new parameter values, and, if required, provide the Group 953 Manager with a new public key to use in the group, as compatible 954 with the indicated parameters (see Section 10 of 955 [I-D.ietf-ace-key-groupcomm-oscore]). 957 2.6.6. Delete a Group Configuration 959 The Administrator can send a DELETE request to the group- 960 configuration resource, in order to delete that group. A group 961 deletion would be successful only on an inactive group. 963 That is, the DELETE request actually yields a successful deletion of 964 the group, only if the corresponding status parameter 'active' has 965 current value False. The administrator can ensure that, by first 966 performing an update of the group-configuration resource associated 967 to the group (see Section 2.6.5), and setting the corresponding 968 status parameter 'active' to False. 970 If, upon receiving the DELETE request, the current value of the 971 status parameter 'active' is True, the Group Manager MUST respond 972 with a 4.09 (Conflict) response, which MAY include additional 973 information to clarify what went wrong. 975 After a successful processing of the request above, the Group Manager 976 performs the following actions. 978 First, the Group Manager deletes the OSCORE group and deallocates 979 both the group-configuration resource as well as the group-membership 980 resource. 982 Then, the Group Manager replies to the Administrator with a 2.02 983 (Deleted) response. 985 Example: 987 => DELETE 988 Uri-Path: manage 989 Uri-Path: gp4 991 <= 2.02 Deleted 993 2.6.6.1. Effects on the Group Members 995 After having deleted a group, the Group Manager can inform the group 996 members by means of the following two methods. When contacting a 997 group member, the Group Manager uses the pairwise secure 998 communication channel established with that member during its joining 999 process (see Section 5 of [I-D.ietf-ace-key-groupcomm-oscore]). 1001 o The Group Manager sends an individual request message to each 1002 group member, targeting the respective resource used to perform 1003 the group rekeying process (see Section 16 of 1004 [I-D.ietf-ace-key-groupcomm-oscore]). The Group Manager uses the 1005 same format of the Joining Response message in Section 5.4 of 1006 [I-D.ietf-ace-key-groupcomm-oscore], where only the parameters 1007 'gkty', 'key', and 'ace-groupcomm-profile' are present, and the 1008 'key' parameter is empty. 1010 o A group member may subscribe for updates to the group-membership 1011 resource of the group. In particular, if this relies on CoAP 1012 Observe [RFC7641], a group member would receive a 4.04 (Not Found) 1013 notification response from the Group Manager, since the group- 1014 configuration resource has been deallocated upon deleting the 1015 group. 1017 When being informed about the group deletion, a group member deletes 1018 the OSCORE Security Context that it stores as associated to that 1019 group, and possibly deallocates any dedicated control resource 1020 intended for the Group Manager that it has for that group. 1022 3. Security Considerations 1024 Security considerations are inherited from the ACE framework for 1025 Authentication and Authorization [I-D.ietf-ace-oauth-authz], and from 1026 the specific transport ace-groupcomm-profile of ACE used between the 1027 Administrator and the Group Manager, such as 1028 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile]. 1030 4. IANA Considerations 1032 This document has the following actions for IANA. 1034 4.1. ACE Groupcomm Parameters Registry 1036 IANA is asked to register the following entries in the "ACE Groupcomm 1037 Parameters" Registry defined in Section 8.5 of 1038 [I-D.ietf-ace-key-groupcomm]. 1040 +---------------+----------+--------------------+-------------------+ 1041 | Name | CBOR Key | CBOR Type | Reference | 1042 +---------------+----------+--------------------+-------------------+ 1043 | | | | | 1044 | hkdf | TBD3 | tstr | [[this document]] | 1045 | | | | | 1046 | alg | TBD4 | tstr | [[this document]] | 1047 | | | | | 1048 | cs_alg | TBD5 | tstr / int | [[this document]] | 1049 | | | | | 1050 | cs_params | TBD6 | array | [[this document]] | 1051 | | | | | 1052 | cs_key_params | TBD7 | array | [[this document]] | 1053 | | | | | 1054 | cs_key_enc | TBD8 | int | [[this document]] | 1055 | | | | | 1056 | active | TBD9 | simple type | [[this document]] | 1057 | | | | | 1058 | group_name | TBD10 | tstr | [[this document]] | 1059 | | | | | 1060 | group_title | TBD11 | tstr / simple type | [[this document]] | 1061 | | | | | 1062 | joining_uri | TBD12 | tstr | [[this document]] | 1063 | | | | | 1064 | as_uri | TBD13 | tstr | [[this document]] | 1065 | | | | | 1066 +---------------+----------+--------------------+-------------------+ 1068 4.2. Resource Types 1070 IANA is asked to enter the following value into the Resource Type 1071 (rt=) Link Target Attribute Values subregistry within the Constrained 1072 Restful Environments (CoRE) Parameters registry defined in [RFC6690]. 1074 +---------------+----------------------------+-------------------+ 1075 | Value | Description | Reference | 1076 +---------------+----------------------------+-------------------+ 1077 | | | | 1078 | ace.oscore.gm | Group-collection resource | [[this document]] | 1079 | | of an OSCORE Group Manager | | 1080 | | | | 1081 +---------------+----------------------------+-------------------+ 1083 5. References 1084 5.1. Normative References 1086 [COSE.Algorithms] 1087 IANA, "COSE Algorithms", 1088 . 1091 [COSE.Elliptic.Curves] 1092 IANA, "COSE Elliptic Curves", 1093 . 1096 [COSE.Key.Types] 1097 IANA, "COSE Key Types", 1098 . 1101 [I-D.ietf-ace-key-groupcomm] 1102 Palombini, F. and M. Tiloca, "Key Provisioning for Group 1103 Communication using ACE", draft-ietf-ace-key-groupcomm-08 1104 (work in progress), July 2020. 1106 [I-D.ietf-ace-key-groupcomm-oscore] 1107 Tiloca, M., Park, J., and F. Palombini, "Key Management 1108 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 1109 oscore-08 (work in progress), July 2020. 1111 [I-D.ietf-ace-oauth-authz] 1112 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1113 H. Tschofenig, "Authentication and Authorization for 1114 Constrained Environments (ACE) using the OAuth 2.0 1115 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35 1116 (work in progress), June 2020. 1118 [I-D.ietf-ace-oscore-profile] 1119 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 1120 "OSCORE profile of the Authentication and Authorization 1121 for Constrained Environments Framework", draft-ietf-ace- 1122 oscore-profile-11 (work in progress), June 2020. 1124 [I-D.ietf-core-coral] 1125 Hartke, K., "The Constrained RESTful Application Language 1126 (CoRAL)", draft-ietf-core-coral-03 (work in progress), 1127 March 2020. 1129 [I-D.ietf-core-oscore-groupcomm] 1130 Tiloca, M., Selander, G., Palombini, F., and J. Park, 1131 "Group OSCORE - Secure Group Communication for CoAP", 1132 draft-ietf-core-oscore-groupcomm-09 (work in progress), 1133 June 2020. 1135 [I-D.ietf-cose-rfc8152bis-algs] 1136 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1137 Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-11 1138 (work in progress), July 2020. 1140 [I-D.ietf-cose-rfc8152bis-struct] 1141 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1142 Structures and Process", draft-ietf-cose-rfc8152bis- 1143 struct-11 (work in progress), July 2020. 1145 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1146 Requirement Levels", BCP 14, RFC 2119, 1147 DOI 10.17487/RFC2119, March 1997, 1148 . 1150 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1151 Resource Identifier (URI): Generic Syntax", STD 66, 1152 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1153 . 1155 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1156 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1157 . 1159 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1160 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1161 . 1163 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1164 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1165 October 2013, . 1167 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1168 Application Protocol (CoAP)", RFC 7252, 1169 DOI 10.17487/RFC7252, June 2014, 1170 . 1172 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1173 Application Protocol (CoAP)", RFC 7641, 1174 DOI 10.17487/RFC7641, September 2015, 1175 . 1177 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1178 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1179 May 2017, . 1181 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1182 "Object Security for Constrained RESTful Environments 1183 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1184 . 1186 5.2. Informative References 1188 [I-D.dijk-core-groupcomm-bis] 1189 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1190 for the Constrained Application Protocol (CoAP)", draft- 1191 dijk-core-groupcomm-bis-03 (work in progress), March 2020. 1193 [I-D.hartke-t2trg-coral-reef] 1194 Hartke, K., "Resource Discovery in Constrained RESTful 1195 Environments (CoRE) using the Constrained RESTful 1196 Application Language (CoRAL)", draft-hartke-t2trg-coral- 1197 reef-04 (work in progress), May 2020. 1199 [I-D.ietf-ace-dtls-authorize] 1200 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 1201 L. Seitz, "Datagram Transport Layer Security (DTLS) 1202 Profile for Authentication and Authorization for 1203 Constrained Environments (ACE)", draft-ietf-ace-dtls- 1204 authorize-12 (work in progress), July 2020. 1206 [I-D.ietf-core-resource-directory] 1207 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 1208 Amsuess, "CoRE Resource Directory", draft-ietf-core- 1209 resource-directory-24 (work in progress), March 2020. 1211 [I-D.ietf-tls-dtls13] 1212 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1213 Datagram Transport Layer Security (DTLS) Protocol Version 1214 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 1215 2020. 1217 [I-D.tiloca-core-oscore-discovery] 1218 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 1219 Groups with the CoRE Resource Directory", draft-tiloca- 1220 core-oscore-discovery-05 (work in progress), March 2020. 1222 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1223 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1224 January 2012, . 1226 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1227 Interchange Format", STD 90, RFC 8259, 1228 DOI 10.17487/RFC8259, December 2017, 1229 . 1231 Acknowledgments 1233 The authors sincerely thank Christian Amsuess, Carsten Bormann and 1234 Jim Schaad for their comments and feedback. 1236 The work on this document has been partly supported by VINNOVA and 1237 the Celtic-Next project CRITISEC. 1239 Authors' Addresses 1241 Marco Tiloca 1242 RISE AB 1243 Isafjordsgatan 22 1244 Kista SE-16440 Stockholm 1245 Sweden 1247 Email: marco.tiloca@ri.se 1249 Rikard Hoeglund 1250 RISE AB 1251 Isafjordsgatan 22 1252 Kista SE-16440 Stockholm 1253 Sweden 1255 Email: rikard.hoglund@ri.se 1257 Peter van der Stok 1258 Consultant 1260 Phone: +31-492474673 (Netherlands), +33-966015248 (France) 1261 Email: consultancy@vanderstok.org 1262 URI: www.vanderstok.org 1264 Francesca Palombini 1265 Ericsson AB 1266 Torshamnsgatan 23 1267 Kista SE-16440 Stockholm 1268 Sweden 1270 Email: francesca.palombini@ericsson.com 1271 Klaus Hartke 1272 Ericsson AB 1273 Torshamnsgatan 23 1274 Kista SE-16440 Stockholm 1275 Sweden 1277 Email: klaus.hartke@ericsson.com