idnits 2.17.1 draft-tiloca-core-oscore-discovery-11.txt: -(1307): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1391): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 5 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2022) is 781 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) == Outdated reference: A later version (-06) exists of draft-ietf-core-coral-04 == Outdated reference: A later version (-11) exists of draft-ietf-core-groupcomm-bis-06 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-14 ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' == Outdated reference: A later version (-08) exists of draft-amsuess-core-cachable-oscore-04 == Outdated reference: A later version (-18) exists of draft-ietf-ace-key-groupcomm-15 == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-13 == Outdated reference: A later version (-11) exists of draft-ietf-ace-oscore-gm-admin-05 == Outdated reference: A later version (-09) exists of draft-ietf-cose-cbor-encoded-cert-03 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group M. Tiloca 3 Internet-Draft RISE AB 4 Intended status: Standards Track C. Amsuess 5 Expires: 8 September 2022 6 P. van der Stok 7 Consultant 8 7 March 2022 10 Discovery of OSCORE Groups with the CoRE Resource Directory 11 draft-tiloca-core-oscore-discovery-11 13 Abstract 15 Group communication over the Constrained Application Protocol (CoAP) 16 can be secured by means of Group Object Security for Constrained 17 RESTful Environments (Group OSCORE). At deployment time, devices may 18 not know the exact security groups to join, the respective Group 19 Manager, or other information required to perform the joining 20 process. This document describes how a CoAP endpoint can use 21 descriptions and links of resources registered at the CoRE Resource 22 Directory to discover security groups and to acquire information for 23 joining them through the respective Group Manager. A given security 24 group may protect multiple application groups, which are separately 25 announced in the Resource Directory as sets of endpoints sharing a 26 pool of resources. This approach is consistent with, but not limited 27 to, the joining of security groups based on the ACE framework for 28 Authentication and Authorization in constrained environments. 30 Discussion Venues 32 This note is to be removed before publishing as an RFC. 34 Discussion of this document takes place on the Constrained RESTful 35 Environments Working Group mailing list (core@ietf.org), which is 36 archived at https://mailarchive.ietf.org/arch/browse/core/. 38 Source for this draft and an issue tracker can be found at 39 https://gitlab.com/crimson84/draft-tiloca-core-oscore-discovery. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on 8 September 2022. 58 Copyright Notice 60 Copyright (c) 2022 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 65 license-info) in effect on the date of publication of this document. 66 Please review these documents carefully, as they describe your rights 67 and restrictions with respect to this document. Code Components 68 extracted from this document must include Revised BSD License text as 69 described in Section 4.e of the Trust Legal Provisions and are 70 provided without warranty as described in the Revised BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 76 2. Registration of Group Manager Endpoints . . . . . . . . . . . 6 77 2.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . 7 78 2.2. Relation Link to Authorization Server . . . . . . . . . . 12 79 2.3. Registration Example . . . . . . . . . . . . . . . . . . 12 80 2.3.1. Example in Link Format . . . . . . . . . . . . . . . 13 81 2.3.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 13 82 3. Addition and Update of Security Groups . . . . . . . . . . . 14 83 3.1. Addition Example . . . . . . . . . . . . . . . . . . . . 14 84 3.1.1. Example in Link Format . . . . . . . . . . . . . . . 15 85 3.1.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 15 86 4. Discovery of Security Groups . . . . . . . . . . . . . . . . 17 87 4.1. Discovery Example #1 . . . . . . . . . . . . . . . . . . 18 88 4.1.1. Example in Link Format . . . . . . . . . . . . . . . 19 89 4.1.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 20 90 4.2. Discovery Example #2 . . . . . . . . . . . . . . . . . . 21 91 4.2.1. Example in Link Format . . . . . . . . . . . . . . . 21 92 4.2.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 22 93 5. Use Case Example With Full Discovery . . . . . . . . . . . . 23 94 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 96 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 97 8.1. Normative References . . . . . . . . . . . . . . . . . . 28 98 8.2. Informative References . . . . . . . . . . . . . . . . . 29 99 Appendix A. Use Case Example With Full Discovery (CoRAL) . . . . 32 100 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 36 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 103 1. Introduction 105 The Constrained Application Protocol (CoAP) [RFC7252] supports group 106 communication over IP multicast [I-D.ietf-core-groupcomm-bis] to 107 improve efficiency and latency of communication and reduce bandwidth 108 requirements. A set of CoAP endpoints constitutes an application 109 group by sharing a common pool of resources, that can be efficiently 110 accessed through group communication. The members of an application 111 group may be members of a security group, thus sharing a common set 112 of keying material to secure group communication. 114 The security protocol Group Object Security for Constrained RESTful 115 Environments (Group OSCORE) [I-D.ietf-core-oscore-groupcomm] builds 116 on OSCORE [RFC8613] and protects CoAP messages end-to-end in group 117 communication contexts through CBOR Object Signing and Encryption 118 (COSE) 119 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs]. An 120 application group may rely on one or more security groups, and a same 121 security group may be used by multiple application groups at the same 122 time. 124 A CoAP endpoint relies on a Group Manager (GM) to join a security 125 group and get the group keying material. The joining process in 126 [I-D.ietf-ace-key-groupcomm-oscore] is based on the ACE framework for 127 Authentication and Authorization in constrained environments 128 [I-D.ietf-ace-oauth-authz], with the joining endpoint and the GM 129 acting as ACE Client and Resource Server, respectively. That is, the 130 joining endpoint accesses the group-membership resource exported by 131 the GM and associated with the security group to join. 133 Typically, devices store a static X509 IDevID certificate installed 134 at manufacturing time [RFC8995]. This is used at deployment time 135 during an enrollment process that provides the devices with an 136 Operational Certificate, possibly updated during the device lifetime. 137 Operational Certificates may specify information to join security 138 groups, especially a reference to the group-membership resources to 139 access at the respective GMs. 141 However, it is usually impossible to provide such precise information 142 to freshly deployed devices, as part of their (early) Operational 143 Certificate. This can be due to a number of reasons: (1) the 144 security group(s) to join and the responsible GM(s) are generally 145 unknown at manufacturing time; (2) a security group of interest is 146 created, or the responsible GM is deployed, only after the device is 147 enrolled and fully operative in the network; (3) information related 148 to existing security groups or to their GMs has changed. This 149 requires a method for CoAP endpoints to dynamically discover security 150 groups and their GM, and to retrieve relevant information about 151 deployed groups. 153 To this end, CoAP endpoints can use descriptions and links of group- 154 membership resources at GMs, to discover security groups and retrieve 155 the information required for joining them. With the discovery 156 process of security groups expressed in terms of links to resources, 157 the remaining problem is the discovery of those links. The CoRE 158 Resource Directory (RD) [I-D.ietf-core-resource-directory] allows 159 such discovery in an efficient way, and it is expected to be used in 160 many setups that would benefit of security group discovery. 162 This specification builds on this approach and describes how CoAP 163 endpoints can use the RD to perform the link discovery steps, in 164 order to discover security groups and retrieve the information 165 required to join them through their GM. In short, the GM registers 166 as an endpoint with the RD. The resulting registration resource 167 includes one link per security group under that GM, specifying the 168 path to the related group-membership resource to access for joining 169 that group. 171 Additional descriptive information about the security group is stored 172 with the registered link. In a RD based on Link Format [RFC6690] as 173 defined in [I-D.ietf-core-resource-directory], this information is 174 specified as target attributes of the registered link, and includes 175 the identifiers of the application groups which use that security 176 group. This enables a lookup of those application groups at the RD, 177 where they are separately announced by a Commissioning Tool (see 178 Appendix A of [I-D.ietf-core-resource-directory]). 180 When querying the RD for security groups, a CoAP endpoint can use 181 CoAP observation [RFC7641]. This results in automatic notifications 182 on the creation of new security groups or the update of existing 183 groups. Thus, it facilitates the early deployment of CoAP endpoints, 184 i.e., even before the GM is deployed and security groups are created. 186 Interaction examples are provided in Link Format, as well as in the 187 Constrained RESTful Application Language CoRAL [I-D.ietf-core-coral] 188 with reference to a CoRAL-based RD [I-D.hartke-t2trg-coral-reef]. 189 While all the CoRAL examples show the CoRAL textual serialization 190 format, its binary serialization format is used on the wire. 192 [ NOTE: 194 The reported CoRAL examples are based on the textual representation 195 used until version -03 of [I-D.ietf-core-coral]. These will be 196 revised to use the CBOR diagnostic notation instead. 198 ] 200 The approach in this document is consistent with, but not limited to, 201 the joining of security groups defined in 202 [I-D.ietf-ace-key-groupcomm-oscore]. 204 1.1. Terminology 206 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 207 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 208 "OPTIONAL" in this document are to be interpreted as described in BCP 209 14 [RFC2119] [RFC8174] when, and only when, they appear in all 210 capitals, as shown here. 212 This specification requires readers to be familiar with the terms and 213 concepts discussed in [I-D.ietf-core-resource-directory] and 214 [RFC6690], as well as in [I-D.ietf-core-coral]. Readers should also 215 be familiar with the terms and concepts discussed in 216 [RFC7252][I-D.ietf-core-groupcomm-bis], 217 [I-D.ietf-core-oscore-groupcomm] and 218 [I-D.ietf-ace-key-groupcomm-oscore]. 220 Terminology for constrained environments, such as "constrained 221 device" and "constrained-node network", is defined in [RFC7228]. 223 Consistently with the definitions from Section 2.1 of 224 [I-D.ietf-core-groupcomm-bis], this document also refers to the 225 following terminology. 227 * CoAP group: a set of CoAP endpoints all configured to receive CoAP 228 multicast messages sent to the group's associated IP multicast 229 address and UDP port. An endpoint may be a member of multiple 230 CoAP groups by subscribing to multiple IP multicast addresses. 232 * Security group: a set of CoAP endpoints that share the same 233 security material, and use it to protect and verify exchanged 234 messages. A CoAP endpoint may be a member of multiple security 235 groups. There can be a one-to-one or a one-to-many relation 236 between security groups and CoAP groups. 238 This document especially considers a security group to be an 239 OSCORE group, where all members share one OSCORE Security Context 240 to protect group communication with Group OSCORE 241 [I-D.ietf-core-oscore-groupcomm]. However, the approach defined 242 in this document can be used to support the discovery of different 243 security groups than OSCORE groups. 245 * Application group: a set of CoAP endpoints that share a common set 246 of resources. An endpoint may be a member of multiple application 247 groups. An application group can be associated with one or more 248 security groups, and multiple application groups can use the same 249 security group. Application groups are announced in the RD by a 250 Commissioning Tool, according to the RD-Groups usage pattern (see 251 Appendix A of [I-D.ietf-core-resource-directory]). 253 Like [I-D.ietf-core-oscore-groupcomm], this document also uses the 254 following term. 256 * Authentication credential: set of information associated with an 257 entity, including that entity's public key and parameters 258 associated with the public key. Examples of authentication 259 credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) 260 [RFC8392], X.509 certificates [RFC7925] and C509 certificates 261 [I-D.ietf-cose-cbor-encoded-cert]. 263 2. Registration of Group Manager Endpoints 265 During deployment, a Group Manager (GM) can find the CoRE Resource 266 Directory (RD) as described in Section 4 of 267 [I-D.ietf-core-resource-directory]. 269 Afterwards, the GM registers as an endpoint with the RD, as described 270 in Section 5 of [I-D.ietf-core-resource-directory]. The GM SHOULD 271 NOT use the Simple Registration approach described in Section 5.1 of 272 [I-D.ietf-core-resource-directory]. 274 When registering with the RD, the GM also registers the links to all 275 the group-membership resources it has at that point in time, i.e., 276 one for each of its security groups. 278 In the registration request, each link to a group-membership resource 279 has as target the URI of that resource at the GM. Also, it specifies 280 a number of descriptive parameters as defined in Section 2.1. 282 Furthermore, the GM MAY additionally register the link to its 283 resource implementing the ACE authorization information endpoint (see 284 Section 5.10.1 of [I-D.ietf-ace-oauth-authz]). A joining node can 285 provide the GM with its own access token by sending it in a request 286 targeting that resource, thus proving to be authorized to join 287 certain security groups (see Section 6.1 of 288 [I-D.ietf-ace-key-groupcomm-oscore]). In such a case, the link MUST 289 include the parameter 'rt' with value "ace.ai", defined in 290 Section 8.2 of [I-D.ietf-ace-oauth-authz]. 292 2.1. Parameters 294 For each registered link to a group-membership resource at a GM, the 295 following parameters are specified together with the link. 297 In the RD defined in [I-D.ietf-core-resource-directory] and based on 298 Link Format, each parameter is specified in a target attribute with 299 the same name. 301 In a RD based on CoRAL, such as the one defined in 302 [I-D.hartke-t2trg-coral-reef], each parameter is specified in a 303 nested element with the same name. 305 * 'ct', specifying the content format used with the group-membership 306 resource at the Group Manager, with value "application/ace- 307 groupcomm+cbor" registered in Section 8.2 of 308 [I-D.ietf-ace-key-groupcomm]. 310 Note: The examples in this document use the provisional value 311 65000 from the range "Reserved for Experimental Use" of the "CoAP 312 Content-Formats" registry, within the "CoRE Parameters" registry. 314 * 'rt', specifying the resource type of the group-membership 315 resource at the Group Manager, with value "core.osc.gm" registered 316 in Section 25.11 of [I-D.ietf-ace-key-groupcomm-oscore]. 318 * 'if', specifying the interface description for accessing the 319 group-membership resource at the Group Manager, with value 320 "ace.group" registered in Section 8.10 of 321 [I-D.ietf-ace-key-groupcomm]. 323 * 'sec-gp', specifying the name of the security group of interest, 324 as a stable and invariant identifier, such as the group name used 325 in [I-D.ietf-ace-key-groupcomm-oscore]. This parameter MUST 326 specify a single value. 328 * 'app-gp', specifying the name(s) of the application group(s) 329 associated with the security group of interest indicated by 'sec- 330 gp'. This parameter MUST occur once for each application group, 331 and MUST specify only a single application group. 333 When a security group is created at the GM, the names of the 334 application groups using it are also specified as part of the 335 security group configuration (see [I-D.ietf-ace-oscore-gm-admin]). 336 Thus, when registering the links to its group-membership resource, 337 the GM is aware of the application groups and their names. 339 If a different entity than the GM registers the security groups to 340 the RD, e.g., a Commissioning Tool, this entity has to also be 341 aware of the application groups and their names to specify. To 342 this end, it can obtain them from the GM or from the Administator 343 that created the security groups at the GM (see 344 [I-D.ietf-ace-oscore-gm-admin]). 346 Optionally, the following parameters can also be specified. If Link 347 Format is used, the value of each of these parameters is encoded as a 348 text string. 350 * 'hkdf', specifying the HKDF Algorithm used in the security group. 351 If present, this parameter MUST specify a single value, which is 352 taken from the 'Value' column of the "COSE Algorithms" Registry 353 [COSE.Algorithms]. 355 * 'cred_fmt', specifying the format of the authentication 356 credentials used in the security group. If present, this 357 parameter MUST specify a single value, which is taken from the 358 'Label' column of the "COSE Header Parameters" Registry 359 [COSE.Header.Parameters]. Acceptable values denote a format that 360 MUST explicitly provide the public key as well as the 361 comprehensive set of information related to the public key 362 algorithm, including, e.g., the used elliptic curve (when 363 applicable). 365 At the time of writing this specification, acceptable formats of 366 authentication credentials are CBOR Web Tokens (CWTs) and CWT 367 Claim Sets (CCSs) [RFC8392], X.509 certificates [RFC7925] and C509 368 certificates [I-D.ietf-cose-cbor-encoded-cert]. Further formats 369 may be available in the future, and would be acceptable to use as 370 long as they comply with the criteria defined above. 372 [ As to CWTs and unprotected CWT claim sets, there is a pending 373 registration requested by draft-ietf-lake-edhoc. ] 375 [ As to C509 certificates, there is a pending registration 376 requested by draft-ietf-cose-cbor-encoded-cert. ] 378 * 'sign_enc_alg', specifying the encryption algorithm used to 379 encrypt messages in the security group, when these are also 380 signed, e.g., as in the group mode of Group OSCORE (see Section 8 381 of [I-D.ietf-core-oscore-groupcomm]). If present, this parameter 382 MUST specify a single value, which is taken from the 'Value' 383 column of the "COSE Algorithms" Registry [COSE.Algorithms]. 385 * 'sign_alg', specifying the algorithm used to sign messages in the 386 security group. If present, this parameter MUST specify a single 387 value, which is taken from the 'Value' column of the "COSE 388 Algorithms" Registry [COSE.Algorithms]. 390 * 'sign_alg_crv', specifying the elliptic curve (if applicable) for 391 the algorithm used to sign messages in the security group. If 392 present, this parameter MUST specify a single value, which is 393 taken from the 'Value' column of the "COSE Elliptic Curves" 394 Registry [COSE.Elliptic.Curves]. 396 * 'sign_key_kty', specifying the key type of countersignature keys 397 used to sign messages in the security group. If present, this 398 parameter MUST specify a single value, which is taken from the 399 'Value' column of the "COSE Key Types" Registry [COSE.Key.Types]. 401 * 'sign_key_crv', specifying the elliptic curve (if applicable) of 402 countersignature keys used to sign messages in the security group. 403 If present, this parameter MUST specify a single value, which is 404 taken from the 'Value' column of the "COSE Elliptic Curves" 405 Registry [COSE.Elliptic.Curves]. 407 * 'alg', specifying the encryption algorithm used to encrypt 408 messages in the security group, when these are encrypted with 409 pairwise encryption keys, e.g., as in the pairwise mode of Group 410 OSCORE (see Section 9 of [I-D.ietf-core-oscore-groupcomm]). If 411 present, this parameter MUST specify a single value, which is 412 taken from the 'Value' column of the "COSE Algorithms" Registry 413 [COSE.Algorithms]. 415 * 'ecdh_alg', specifying the ECDH algorithm used to derive pairwise 416 encryption keys in the security group, e.g., as for the pairwise 417 mode of Group OSCORE (see Section 2.4 of 418 [I-D.ietf-core-oscore-groupcomm]). If present, this parameter 419 MUST specify a single value, which is taken from the 'Value' 420 column of the "COSE Algorithms" Registry [COSE.Algorithms]. 422 * 'ecdh_alg_crv', specifying the elliptic curve for the ECDH 423 algorithm used to derive pairwise encryption keys in the security 424 group. If present, this parameter MUST specify a single value, 425 which is taken from the 'Value' column of the "COSE Elliptic 426 Curves" Registry [COSE.Elliptic.Curves]. 428 * 'ecdh_key_kty', specifying the key type of keys used with an ECDH 429 algorithm to derive pairwise encryption keys in the security 430 group. If present, this parameter MUST specify a single value, 431 which is taken from the 'Value' column of the "COSE Key Types" 432 Registry [COSE.Key.Types]. 434 * 'ecdh_key_crv', specifying the elliptic curve of keys used with an 435 ECDH algorithm to derive pairwise encryption keys in the security 436 group. If present, this parameter MUST specify a single value, 437 which is taken from the 'Value' column of the "COSE Elliptic 438 Curves" Registry [COSE.Elliptic.Curves]. 440 * 'det_hash_alg', specifying the hash algorithm used in the security 441 group when producing deterministic requests, as defined in 442 [I-D.amsuess-core-cachable-oscore]. If present, this parameter 443 MUST specify a single value, which is taken from the 'Value' 444 column of the "COSE Algorithms" Registry [COSE.Algorithms]. This 445 parameter MUST NOT be present if the security group does not use 446 deterministic requests. 448 * 'rekeying_scheme', specifying the rekeying scheme used in the 449 security group for distributing new group keying meterial to the 450 group members. If present, this parameter MUST specify a single 451 value, which is taken from the 'Value' column of the "ACE 452 Groupcomm Rekeying Schemes" registry defined in Section 11.14 of 453 [I-D.ietf-ace-key-groupcomm]. 455 If the security group does not recur to message signing, then the 456 parameters 'sign_enc_alg', 'sign_alg', 'sign_alg_crv', 'sign_key_kty' 457 and 'sign_key_crv' MUST NOT be present. For instance, this is the 458 case for a security group that uses Group OSCORE and uses only the 459 pairwise mode (see Section 9 of [I-D.ietf-core-oscore-groupcomm]). 461 If the security group does not recur to message encryption through 462 pairwise encryption keys, then the parameters 'alg', 'ecdh_alg', 463 'ecdh_alg_crv', 'ecdh_key_kty' and 'ecdh_key_crv' MUST NOT be 464 present. For instance, this is the case for a security group that 465 uses Group OSCORE and uses only the group mode see Section 8 of 466 [I-D.ietf-core-oscore-groupcomm]). 468 Note that the values registered in the COSE Registries 469 [COSE.Algorithms][COSE.Elliptic.Curves][COSE.Key.Types] are strongly 470 typed. On the contrary, Link Format is weakly typed and thus does 471 not distinguish between, for instance, the string value "-10" and the 472 integer value -10. 474 Thus, in RDs that return responses in Link Format, string values 475 which look like an integer are not supported. Therefore, such values 476 MUST NOT be advertised through the corresponding parameters above. 478 A CoAP endpoint that queries the RD to discover security groups and 479 their group-membership resource to access (see Section 4) would 480 benefit from the information above as follows. 482 * The values of 'cred_fmt', 'sign_alg', 'sign_alg_crv', 483 'sign_key_kty', 'sign_key_crv', 'ecdh_alg', 'ecdh_alg_crv', 484 'ecdh_key_kty' and 'ecdh_key_crv' related to a group-membership 485 resource provide an early knowledge of the format of 486 authentication credentials as well as of the type of public keys 487 used in the security group. 489 Thus, the CoAP endpoint does not need to ask the GM for this 490 information as a preliminary step before the joining process, or 491 to perform a trial-and-error joining exchange with the GM. Hence, 492 at the very first step of the joining process, the CoAP endpoint 493 is able to provide the GM with its own authentication credential 494 in the correct expected format and including a public key of the 495 correct expected type. 497 * The values of 'hkdf', 'sign_enc_alg', 'sign_alg', 'alg' and 498 'ecdh_alg' related to a group-membership resource provide an early 499 knowledge of the algorithms used in the security group. 501 Thus, the CoAP endpoint is able to decide whether to actually 502 proceed with the joining process, depending on its support for the 503 indicated algorithms. 505 2.2. Relation Link to Authorization Server 507 For each registered link to a group-membership resource, the GM MAY 508 additionally specify the link to the ACE Authorization Server (AS) 509 [I-D.ietf-ace-oauth-authz] associated with the GM, and issuing 510 authorization credentials to join the security group as described in 511 [I-D.ietf-ace-key-groupcomm-oscore]. 513 The link to the AS has as target the URI of the resource where to 514 send an authorization request to. 516 In the RD defined in [I-D.ietf-core-resource-directory] and based on 517 Link Format, the link to the AS is separately registered with the RD, 518 and includes the following parameters as target attributes. 520 * 'rel', with value "authorization_server". 522 * 'anchor', with value the target of the link to the group- 523 membership resource at the GM. 525 In a RD based on CoRAL, such as the one defined in 526 [I-D.hartke-t2trg-coral-reef], this is mapped (as describe there) to 527 a link from the registration resource to the AS, using the 528 link 529 relation type. 531 2.3. Registration Example 533 The example below shows a GM with endpoint name "gm1" and address 534 2001:db8::ab that registers with the RD. 536 The GM specifies the value of the 'sec-gp' parameter for accessing 537 the security group with name "feedca570000", and used by the 538 application group with name "group1" specified with the value of the 539 'app-gp' parameter. 541 The countersignature algorithm used in the security group is EdDSA 542 (-8), with elliptic curve Ed25519 (6). Authentication credentials 543 used in the security group are X.509 certificates [RFC7925], which is 544 signaled through the COSE Header Parameter "x5chain" (33). The ECDH 545 algorithm used in the security group is ECDH-SS + HKDF-256 (-27), 546 with elliptic curve X25519 (4). 548 In addition, the GM specifies the link to the ACE Authorization 549 Server associated with the GM, to which a CoAP endpoint should send 550 an Authorization Request for joining the corresponding security group 551 (see [I-D.ietf-ace-key-groupcomm-oscore]). 553 2.3.1. Example in Link Format 555 Request: GM -> RD 557 Req: POST coap://rd.example.com/rd?ep=gm1 558 Content-Format: 40 559 Payload: 560 ;ct=65000;rt="core.osc.gm";if="ace.group"; 561 sec-gp="feedca570000";app-gp="group1"; 562 cred_fmt="33";sign_enc_alg="10"; 563 sign_alg="-8";sign_alg_crv="6"; 564 alg="10";ecdh_alg="-27";ecdh_alg_crv="4", 565 ;rel="authorization-server"; 566 anchor="coap://[2001:db8::ab]/ace-group/feedca570000" 568 Response: RD -> GM 570 Res: 2.01 Created 571 Location-Path: /rd/4521 573 2.3.2. Example in CoRAL 575 Request: GM -> RD 577 Req: POST coap://rd.example.com/rd?ep=gm1 578 Content-Format: TBD123456 (application/coral+cbor) 580 Payload: 581 #using 582 #using reef = 583 #using iana = 585 #base 586 reef:rd-item { 587 reef:ct 65000 588 reef:rt "core.osc.gm" 589 reef:if "ace.group" 590 sec-gp "feedca570000" 591 app-gp "group1" 592 cred_fmt 33 593 sign_enc_alg 10 594 sign_alg -8 595 sign_alg_crv 6 596 alg 10 597 ecdh_alg -27 598 ecdh_alg_crv 4 599 iana:authorization-server 600 } 601 Response: RD -> GM 603 Res: 2.01 Created 604 Location-Path: /rd/4521 606 3. Addition and Update of Security Groups 608 The GM is responsible to refresh the registration of all its group- 609 membership resources in the RD. This means that the GM has to update 610 the registration within its lifetime as per Section 5.3.1 of 611 [I-D.ietf-core-resource-directory], and has to change the content of 612 the registration when a group-membership resource is added/removed, 613 or if its parameters have to be changed, such as in the following 614 cases. 616 * The GM creates a new security group and starts exporting the 617 related group-membership resource. 619 * The GM dismisses a security group and stops exporting the related 620 group-membership resource. 622 * Information related to an existing security group changes, e.g., 623 the list of associated application groups. 625 To perform an update of its registrations, the GM can re-register 626 with the RD and fully specify all links to its group-membership 627 resources. 629 Alternatively, the GM can perform a PATCH/iPATCH [RFC8132] request to 630 the RD, as per Section 5.3.3 of [I-D.ietf-core-resource-directory]. 631 This requires new media-types to be defined in future standards, to 632 apply a new document as a patch to an existing stored document. 634 3.1. Addition Example 636 The example below shows how the GM from Section 2 re-registers with 637 the RD. When doing so, it specifies: 639 * The same previous group-membership resource associated with the 640 security group with name "feedca570000". 642 * An additional group-membership resource associated with the 643 security group with name "ech0ech00000" and used by the 644 application group "group2". 646 * A third group-membership resource associated with the security 647 group with name "abcdef120000" and used by two application groups, 648 namely "group3" and "group4". 650 Furthermore, the GM relates the same Authorization Server also to the 651 security groups "ech0ech00000" and "abcdef120000". 653 3.1.1. Example in Link Format 655 Request: GM -> RD 657 Req: POST coap://rd.example.com/rd?ep=gm1 658 Content-Format: 40 659 Payload: 660 ;ct=65000;rt="core.osc.gm";if="ace.group"; 661 sec-gp="feedca570000";app-gp="group1"; 662 cred_fmt="33";sign_enc_alg="10"; 663 sign_alg="-8";sign_alg_crv="6"; 664 alg="10";ecdh_alg="-27";ecdh_alg_crv="4", 665 ;ct=65000;rt="core.osc.gm";if="ace.group"; 666 sec-gp="ech0ech00000";app-gp="group2"; 667 cred_fmt="33";sign_enc_alg="10"; 668 sign_alg="-8";sign_alg_crv="6"; 669 alg="10";ecdh_alg="-27";ecdh_alg_crv="4", 670 ;ct=65000;rt="core.osc.gm";if="ace.group"; 671 sec-gp="abcdef120000";app-gp="group3"; 672 app-gp="group4";cred_fmt="33"; 673 sign_enc_alg="10";sign_alg="-8"; 674 sign_alg_crv="6";alg="10";ecdh_alg="-27"; 675 ecdh_alg_crv="4", 676 ;rel="authorization-server"; 677 anchor="coap://[2001:db8::ab]/ace-group/feedca570000", 678 ;rel="authorization-server"; 679 anchor="coap://[2001:db8::ab]/ace-group/ech0ech00000", 680 ;rel="authorization-server"; 681 anchor="coap://[2001:db8::ab]/ace-group/abcdef120000" 683 Response: RD -> GM 685 Res: 2.04 Changed 686 Location-Path: /rd/4521 688 3.1.2. Example in CoRAL 690 Request: GM -> RD 692 Req: POST coap://rd.example.com/rd?ep=gm1 693 Content-Format: TBD123456 (application/coral+cbor) 695 Payload: 696 #using 697 #using reef = 698 #using iana = 700 #base 701 reef:rd-item { 702 reef:ct 65000 703 reef:rt "core.osc.gm" 704 reef:if "ace.group" 705 sec-gp "feedca570000" 706 app-gp "group1" 707 cred_fmt 33 708 sign_enc_alg 10 709 sign_alg -8 710 sign_alg_crv 6 711 alg 10 712 ecdh_alg -27 713 ecdh_alg_crv 4 714 iana:authorization-server 715 } 716 reef:rd-item { 717 reef:ct 65000 718 reef:rt "core.osc.gm" 719 reef:if "ace.group" 720 sec-gp "ech0ech00000" 721 app-gp "group2" 722 cred_fmt 33 723 sign_enc_alg 10 724 sign_alg -8 725 sign_alg_crv 6 726 alg 10 727 ecdh_alg -27 728 ecdh_alg_crv 4 729 iana:authorization-server 730 } 731 reef:rd-item { 732 reef:ct 65000 733 reef:rt "core.osc.gm" 734 reef:if "ace.group" 735 sec-gp "abcdef120000" 736 app-gp "group3" 737 app-gp "group4" 738 cred_fmt 33 739 sign_enc_alg 10 740 sign_alg -8 741 sign_alg_crv 6 742 alg 10 743 ecdh_alg -27 744 ecdh_alg_crv 4 745 iana:authorization-server 747 } 749 Response: RD -> GM 751 Res: 2.04 Changed 752 Location-Path: /rd/4521 754 4. Discovery of Security Groups 756 A CoAP endpoint that wants to join a security group, hereafter called 757 the joining node, might not have all the necessary information at 758 deployment time. Also, it might want to know about possible new 759 security groups created afterwards by the respective Group Managers. 761 To this end, the joining node can perform a resource lookup at the RD 762 as per Section 6.1 of [I-D.ietf-core-resource-directory], to retrieve 763 the missing pieces of information needed to join the security 764 group(s) of interest. The joining node can find the RD as described 765 in Section 4 of [I-D.ietf-core-resource-directory]. 767 The joining node uses the following parameter value for the lookup 768 filtering. 770 * 'rt' = "core.osc.gm", specifying the resource type of the group- 771 membership resource at the Group Manager, with value "core.osc.gm" 772 registered in Section 25.11 of 773 [I-D.ietf-ace-key-groupcomm-oscore]. 775 The joining node may additionally consider the following parameters 776 for the lookup filtering, depending on the information it has already 777 available. 779 * 'sec-gp', specifying the name of the security group of interest. 780 This parameter MUST specify a single value. 782 * 'ep', specifying the registered endpoint of the GM. 784 * 'app-gp', specifying the name(s) of the application group(s) 785 associated with the security group of interest. This parameter 786 MAY be included multiple times, and each occurrence MUST specify 787 the name of one application group. 789 * 'if', specifying the interface description for accessing the 790 group-membership resource at the Group Manager, with value 791 "ace.group" registered in Section 8.10 of 792 [I-D.ietf-ace-key-groupcomm]. 794 The response from the RD may include links to a group-membership 795 resource specifying multiple application groups, as all using the 796 same security group. In this case, the joining node is already 797 expected to know the exact application group of interest. 799 Furthermore, the response from the RD may include the links to 800 different group-membership resources, all specifying a same 801 application group of interest for the joining node, if the 802 corresponding security groups are all used by that application group. 804 In this case, application policies on the joining node should define 805 how to determine the exact security group to join (see Section 2.1 of 806 [I-D.ietf-core-groupcomm-bis]). For example, different security 807 groups can reflect different security algorithms to use. Hence, a 808 client application can take into account what the joining node 809 supports and prefers, when selecting one particular security group 810 among the indicated ones, while a server application would need to 811 join all of them. Later on, the joining node will be anyway able to 812 join only security groups for which it is actually authorized to be a 813 member (see [I-D.ietf-ace-key-groupcomm-oscore]). 815 Note that, with RD-based discovery, including the 'app-gp' parameter 816 multiple times would result in finding only the group-membership 817 resource that serves all the specified application groups, i.e., not 818 any group-membership resource that serves either. Therefore, a 819 joining node needs to perform N separate queries with different 820 values for 'app-gp', in order to safely discover the (different) 821 group-membership resource(s) serving the N application groups. 823 The discovery of security groups as defined in this document is 824 applicable and useful to other CoAP endpoints than the actual joining 825 nodes. In particular, other entities can be interested to discover 826 and interact with the group-membership resource at the Group Manager. 827 These include entities acting as signature checkers, e.g., 828 intermediary gateways, that do not join a security group, but can 829 retrieve authentication credentials of group members from the Group 830 Manager, in order to verify counter signatures of group messages (see 831 Section 3 of [I-D.ietf-core-oscore-groupcomm]). 833 4.1. Discovery Example #1 835 Consistently with the examples in Section 2 and Section 3, the 836 examples below consider a joining node that wants to join the 837 security group associated with the application group "group1", but 838 that does not know the name of the security group, the responsible GM 839 and the group-membership resource to access. 841 4.1.1. Example in Link Format 843 Request: Joining node -> RD 845 Req: GET coap://rd.example.com/rd-lookup/res 846 ?rt=core.osc.gm&app-gp=group1 848 Response: RD -> Joining node 850 Res: 2.05 Content 851 Payload: 852 ;ct=65000; 853 rt="core.osc.gm";if="ace.group";sec-gp="feedca570000"; 854 app-gp="group1";cred_fmt="33";sign_enc_alg="10"; 855 sign_alg="-8";sign_alg_crv="6";alg="10"; 856 ecdh_alg="-27";ecdh_alg_crv="4" 858 By performing the separate resource lookup below, the joining node 859 can retrieve the link to the ACE Authorization Server associated with 860 the GM, where to send an Authorization Request for joining the 861 corresponding security group (see 862 [I-D.ietf-ace-key-groupcomm-oscore]). 864 Request: Joining node -> RD 866 Req: GET coap://rd.example.com/rd-lookup/res 867 ?rel=authorization-server& 868 anchor=coap://[2001:db8::ab]/ace-group/feedca570000 870 Response: RD -> Joining node 872 Res: 2.05 Content 873 Payload: 874 ;rel=authorization-server; 875 anchor="coap://[2001:db8::ab]/ace-group/feedca570000" 877 To retrieve the multicast IP address of the CoAP group used by the 878 application group "group1", the joining node performs an endpoint 879 lookup as shown below. The following assumes that the application 880 group "group1" had been previously registered as per Appendix A of 881 [I-D.ietf-core-resource-directory], with ff35:30:2001:db8::23 as 882 multicast IP address of the associated CoAP group. 884 Request: Joining node -> RD 886 Req: GET coap://rd.example.com/rd-lookup/ep 887 ?et=core.rd-group&ep=group1 889 Response: RD -> Joining node 891 Res: 2.05 Content 892 Payload: 893 ;ep="group1";et="core.rd-group"; 894 base="coap://[ff35:30:2001:db8::23]";rt="core.rd-ep" 896 4.1.2. Example in CoRAL 898 Request: Joining node -> RD 900 Req: GET coap://rd.example.com/rd-lookup/res 901 ?rt=core.osc.gm&app-gp=group1 902 Accept: TBD123456 (application/coral+cbor) 904 Response: RD -> Joining node 906 Res: 2.05 Content 907 Content-Format: TBD123456 (application/coral+cbor) 909 Payload: 910 #using 911 #using reef = 912 #using iana = 914 #base 915 reef:rd-item { 916 reef:ct 65000 917 reef:rt "core.osc.gm" 918 reef:if "ace.group" 919 sec-gp "feedca570000" 920 app-gp "group1" 921 cred_fmt 33 922 sign_enc_alg 10 923 sign_alg -8 924 sign_alg_crv 6 925 alg 10 926 ecdh_alg -27 927 ecdh_alg_crv 4 928 iana:authorization-server 929 } 931 To retrieve the multicast IP address of the CoAP group used by the 932 application group "group1", the joining node performs an endpoint 933 lookup as shown below. The following assumes that the application 934 group "group1" had been previously registered, with 935 ff35:30:2001:db8::23 as multicast IP address of the associated CoAP 936 group. 938 Request: Joining node -> RD 940 Req: GET coap://rd.example.com/rd-lookup/ep 941 ?et=core.rd-group&ep=group1 942 Accept: TBD123456 (application/coral+cbor) 944 Response: RD -> Joining node 946 Res: 2.05 Content 947 Content-Format: TBD123456 (application/coral+cbor) 949 Payload: 950 #using 951 #using reef = 953 reef:rd-unit <./rd/501> { 954 reef:ep "group1" 955 reef:et "core.rd-group" 956 reef:base 957 reef:rt "core.rd-ep" 958 } 960 4.2. Discovery Example #2 962 Consistently with the examples in Section 2 and Section 3, the 963 examples below consider a joining node that wants to join the 964 security group with name "feedca570000", but that does not know the 965 responsible GM, the group-membership resource to access, and the 966 associated application groups. 968 The examples also show how the joining node uses CoAP observation 969 [RFC7641], in order to be notified of possible changes to the 970 parameters of the group-membership resource. This is also useful to 971 handle the case where the security group of interest has not been 972 created yet, so that the joining node can receive the requested 973 information when it becomes available. 975 4.2.1. Example in Link Format 977 Request: Joining node -> RD 979 Req: GET coap://rd.example.com/rd-lookup/res 980 ?rt=core.osc.gm&sec-gp=feedca570000 981 Observe: 0 983 Response: RD -> Joining node 984 Res: 2.05 Content 985 Observe: 24 986 Payload: 987 ;ct=65000; 988 rt="core.osc.gm";if="ace.group";sec-gp="feedca570000"; 989 app-gp="group1";cred_fmt="33";sign_enc_alg="10"; 990 sign_alg="-8";sign_alg_crv="6";alg="10"; 991 ecdh_alg="-27";ecdh_alg_crv="4" 993 Depending on the search criteria, the joining node performing the 994 resource lookup can get large responses. This can happen, for 995 instance, when the lookup request targets all the group-membership 996 resources at a specified GM, or all the group-membership resources of 997 all the registered GMs, as in the example below. 999 Request: Joining node -> RD 1001 Req: GET coap://rd.example.com/rd-lookup/res?rt=core.osc.gm 1003 Response: RD -> Joining node 1005 Res: 2.05 Content 1006 Payload: 1007 ;ct=65000; 1008 rt="core.osc.gm";if="ace.group";sec-gp="feedca570000"; 1009 app-gp="group1";cred_fmt="33";sign_enc_alg="10"; 1010 sign_alg="-8";sign_alg_crv="6";alg="10";ecdh_alg="-27"; 1011 ecdh_alg_crv="4", 1012 ;ct=65000; 1013 rt="core.osc.gm";if="ace.group";sec-gp="ech0ech00000"; 1014 app-gp="group2";cred_fmt="33";sign_enc_alg="10"; 1015 sign_alg="-8";sign_alg_crv="6";alg="10";ecdh_alg="-27"; 1016 ecdh_alg_crv="4", 1017 ;ct=65000; 1018 rt="core.osc.gm";if="ace.group";sec-gp="abcdef120000"; 1019 app-gp="group3";app-gp="group4";cred_fmt="33"; 1020 sign_enc_alg="10";sign_alg="-8";sign_alg_crv="6";alg="10"; 1021 ecdh_alg="-27";ecdh_alg_crv="4" 1023 Therefore, it is RECOMMENDED that a joining node which performs a 1024 resource lookup with the CoAP Observe option specifies the value of 1025 the parameter 'sec-gp' in its GET request sent to the RD. 1027 4.2.2. Example in CoRAL 1029 Request: Joining node -> RD 1030 Req: GET coap://rd.example.com/rd-lookup/res 1031 ?rt=core.osc.gm&sec-gp=feedca570000 1032 Accept: TBD123456 (application/coral+cbor) 1033 Observe: 0 1035 Response: RD -> Joining node 1037 Res: 2.05 Content 1038 Observe: 24 1039 Content-Format: TBD123456 (application/coral+cbor) 1041 Payload: 1042 #using 1043 #using reef = 1044 #using iana = 1046 #base 1047 reef:rd-item { 1048 reef:ct 65000 1049 reef:rt "core.osc.gm" 1050 reef:if "ace.group" 1051 sec-gp "feedca570000" 1052 app-gp "group1" 1053 cred_fmt 33 1054 sign_enc_alg 10 1055 sign_alg -8 1056 sign_alg_crv 6 1057 alg 10 1058 ecdh_alg -27 1059 ecdh_alg_crv 4 1060 iana:authorization-server 1061 } 1063 5. Use Case Example With Full Discovery 1065 In this section, the discovery of security groups is described to 1066 support the installation process of a lighting installation in an 1067 office building. The described process is a simplified version of 1068 one of many processes. 1070 The process described in this section is intended as an example and 1071 does not have any particular ambition to serve as recommendation or 1072 best practice to adopt. That is, it shows a possible workflow 1073 involving a Commissioning Tool (CT) used in a certain way, while it 1074 is not meant to prescribe how the workflow should necessarily be. 1076 Assume the existence of four luminaires that are members of two 1077 application groups. In the first application group, the four 1078 luminaires receive presence messages and light intensity messages 1079 from sensors or their proxy. In the second application group, the 1080 four luminaires and several other pieces of equipment receive 1081 building state schedules. 1083 Each of the two application groups is associated with a different 1084 security group and to a different CoAP group with its own dedicated 1085 multicast IP address. 1087 The Fairhair Alliance describes how a new device is accepted and 1088 commissioned in the network [Fairhair], by means of its certificate 1089 stored during the manufacturing process. When commissioning the new 1090 device in the installation network, the new device gets a new 1091 identity defined by a newly allocated certificate, following the 1092 BRSKI specification. 1094 Section 7.3 of [I-D.ietf-core-resource-directory] describes how the 1095 CT assigns an endpoint name based on the CN field, (CN=ACME) and the 1096 serial number of the certificate (serial number = 123x, with 3 < x < 1097 8). Corresponding ep-names ACME-1234, ACME-1235, ACME-1236 and 1098 ACME-1237 are also assumed. 1100 It is common practice that locations in the building are specified 1101 according to a coordinate system. After the acceptance of the 1102 luminaires into the installation network, the coordinate of each 1103 device is communicated to the CT. This can be done manually or 1104 automatically. 1106 The mapping between location and ep-name is calculated by the CT. 1107 For instance, on the basis of grouping criteria, the CT assigns: i) 1108 application group "grp_R2-4-015" to the four luminaires; and ii) 1109 application group "grp_schedule" to all schedule requiring devices. 1110 Also, the device with ep name ACME-123x has been assigned IP address: 1111 [2001:db8:4::x]. The RD is assigned IP address: [2001:db8:4:ff]. 1112 The used multicast addresses are: [ff05::5:1] and [ff05::5:2]. 1114 The following assumes that each device is pre-configured with the 1115 name of the two application groups it belongs to. Additional 1116 mechanisms can be defined in the RD, for supporting devices to 1117 discover the application groups they belong to. 1119 Appendix A provides this same use case example in CoRAL. 1121 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1122 The CT defines the application group "grp_R2-4-015", with resource 1123 /light and base address [ff05::5:1], as follows. 1125 Request: CT -> RD 1127 Req: POST coap://[2001:db8:4::ff]/rd 1128 ?ep=grp_R2-4-015&et=core.rd-group&base=coap://[ff05::5:1] 1129 Content-Format: 40 1130 Payload: 1131 ;rt="oic.d.light" 1133 Response: RD -> CT 1135 Res: 2.01 Created 1136 Location-Path: /rd/501 1138 Also, the CT defines a second application group "grp_schedule", with 1139 resource /schedule and base address [ff05::5:2], as follows. 1141 Request: CT -> RD 1143 Req: POST coap://[2001:db8:4::ff]/rd 1144 ?ep=grp_schedule&et=core.rd-group&base=coap://[ff05::5:2] 1145 Content-Format: 40 1146 Payload: 1147 ;rt="oic.r.time.period" 1149 Response: RD -> CT 1151 Res: 2.01 Created 1152 Location-Path: /rd/502 1154 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1156 Finally, the CT defines the corresponding security groups. In 1157 particular, assuming a Group Manager responsible for both security 1158 groups and with address [2001:db8::ab], the CT specifies: 1160 Request: CT -> RD 1161 Req: POST coap://[2001:db8:4::ff]/rd 1162 ?ep=gm1&base=coap://[2001:db8::ab] 1163 Content-Format: 40 1164 Payload: 1165 ;ct=65000;rt="core.osc.gm";if="ace.group"; 1166 sec-gp="feedca570000"; 1167 app-gp="grp_R2-4-015", 1168 ;ct=65000;rt="core.osc.gm";if="ace.group"; 1169 sec-gp="feedsc590000"; 1170 app-gp="grp_schedule" 1172 Response: RD -> CT 1174 Res: 2.01 Created 1175 Location-Path: /rd/4521 1177 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1179 The device with IP address [2001:db8:4::x] can retrieve the multicast 1180 IP address of the CoAP group used by the application group 1181 "grp_R2-4-015", by performing an endpoint lookup as shown below. 1183 Request: Joining node -> RD 1185 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 1186 ?et=core.rd-group&ep=grp_R2-4-015 1188 Response: RD -> Joining node 1190 Res: 2.05 Content 1191 Content-Format: 40 1192 Payload: 1193 ;ep="grp_R2-4-015";et="core.rd-group"; 1194 base="coap://[ff05::5:1]";rt="core.rd-ep" 1196 Similarly, to retrieve the multicast IP address of the CoAP group 1197 used by the application group "grp_schedule", the device performs an 1198 endpoint lookup as shown below. 1200 Request: Joining node -> RD 1202 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 1203 ?et=core.rd-group&ep=grp_schedule 1205 Response: RD -> Joining node 1206 Res: 2.05 Content 1207 Content-Format: 40 1208 Payload: 1209 ;ep="grp_schedule";et="core.rd-group"; 1210 base="coap://[ff05::5:2]";rt="core.rd-ep" 1212 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1214 Consequently, the device learns the security groups it has to join. 1215 In particular, it does the following for app-gp="grp_R2-4-015". 1217 Request: Joining node -> RD 1219 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 1220 ?rt=core.osc.gm&app-gp=grp_R2-4-015 1222 Response: RD -> Joining Node 1224 Res: 2.05 Content 1225 Content-Format: 40 1226 Payload: 1227 ;ct=65000; 1228 rt="core.osc.gm";if="ace.group";sec-gp="feedca570000"; 1229 app-gp="grp_R2-4-015" 1231 Similarly, the device does the following for app-gp="grp_schedule". 1233 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 1234 ?rt=core.osc.gm&app-gp=grp_schedule 1236 Response: RD -> Joining Node 1238 Res: 2.05 Content 1239 Content-Format: 40 1240 Payload: 1241 ;ct=65000; 1242 rt="core.osc.gm";if="ace.group";sec-gp="feedsc590000"; 1243 app-gp="grp_schedule" 1245 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1247 After this last discovery step, the device can ask permission to join 1248 the security groups, and effectively join them through the Group 1249 Manager, e.g., according to [I-D.ietf-ace-key-groupcomm-oscore]. 1251 6. Security Considerations 1253 The security considerations as described in Section 8 of 1254 [I-D.ietf-core-resource-directory] apply here as well. 1256 7. IANA Considerations 1258 This document has no actions for IANA. 1260 8. References 1262 8.1. Normative References 1264 [COSE.Algorithms] 1265 IANA, "COSE Algorithms", 1266 . 1269 [COSE.Elliptic.Curves] 1270 IANA, "COSE Elliptic Curves", 1271 . 1274 [COSE.Header.Parameters] 1275 IANA, "COSE Header Parameters", 1276 . 1279 [COSE.Key.Types] 1280 IANA, "COSE Key Types", 1281 . 1284 [I-D.ietf-core-coral] 1285 Amsüss, C. and T. Fossati, "The Constrained RESTful 1286 Application Language (CoRAL)", Work in Progress, Internet- 1287 Draft, draft-ietf-core-coral-04, 25 October 2021, 1288 . 1291 [I-D.ietf-core-groupcomm-bis] 1292 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1293 for the Constrained Application Protocol (CoAP)", Work in 1294 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 1295 06, 7 March 2022, . 1298 [I-D.ietf-core-oscore-groupcomm] 1299 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 1300 and J. Park, "Group OSCORE - Secure Group Communication 1301 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 1302 core-oscore-groupcomm-14, 7 March 2022, 1303 . 1306 [I-D.ietf-core-resource-directory] 1307 Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V. 1308 D. Stok, "CoRE Resource Directory", Work in Progress, 1309 Internet-Draft, draft-ietf-core-resource-directory-28, 7 1310 March 2021, . 1313 [I-D.ietf-cose-rfc8152bis-algs] 1314 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1315 Initial Algorithms", Work in Progress, Internet-Draft, 1316 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 1317 . 1320 [I-D.ietf-cose-rfc8152bis-struct] 1321 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1322 Structures and Process", Work in Progress, Internet-Draft, 1323 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 1324 . 1327 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1328 Requirement Levels", BCP 14, RFC 2119, 1329 DOI 10.17487/RFC2119, March 1997, 1330 . 1332 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1333 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1334 . 1336 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1337 Application Protocol (CoAP)", RFC 7252, 1338 DOI 10.17487/RFC7252, June 2014, 1339 . 1341 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1342 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1343 May 2017, . 1345 8.2. Informative References 1347 [Fairhair] FairHair Alliance, "Security Architecture for the Internet 1348 of Things (IoT) in Commercial Buildings", White Paper, ed. 1349 Piotr Polak , March 2018, . 1353 [I-D.amsuess-core-cachable-oscore] 1354 Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in 1355 Progress, Internet-Draft, draft-amsuess-core-cachable- 1356 oscore-04, 6 March 2022, . 1359 [I-D.hartke-t2trg-coral-reef] 1360 Hartke, K., "Resource Discovery in Constrained RESTful 1361 Environments (CoRE) using the Constrained RESTful 1362 Application Language (CoRAL)", Work in Progress, Internet- 1363 Draft, draft-hartke-t2trg-coral-reef-04, 9 May 2020, 1364 . 1367 [I-D.ietf-ace-key-groupcomm] 1368 Palombini, F. and M. Tiloca, "Key Provisioning for Group 1369 Communication using ACE", Work in Progress, Internet- 1370 Draft, draft-ietf-ace-key-groupcomm-15, 23 December 2021, 1371 . 1374 [I-D.ietf-ace-key-groupcomm-oscore] 1375 Tiloca, M., Park, J., and F. Palombini, "Key Management 1376 for OSCORE Groups in ACE", Work in Progress, Internet- 1377 Draft, draft-ietf-ace-key-groupcomm-oscore-13, 7 March 1378 2022, . 1381 [I-D.ietf-ace-oauth-authz] 1382 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1383 H. Tschofenig, "Authentication and Authorization for 1384 Constrained Environments (ACE) using the OAuth 2.0 1385 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 1386 draft-ietf-ace-oauth-authz-46, 8 November 2021, 1387 . 1390 [I-D.ietf-ace-oscore-gm-admin] 1391 Tiloca, M., Höglund, R., Stok, P. V. D., and F. Palombini, 1392 "Admin Interface for the OSCORE Group Manager", Work in 1393 Progress, Internet-Draft, draft-ietf-ace-oscore-gm-admin- 1394 05, 7 March 2022, . 1397 [I-D.ietf-cose-cbor-encoded-cert] 1398 Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and 1399 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 1400 Certificates)", Work in Progress, Internet-Draft, draft- 1401 ietf-cose-cbor-encoded-cert-03, 10 January 2022, 1402 . 1405 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1406 Constrained-Node Networks", RFC 7228, 1407 DOI 10.17487/RFC7228, May 2014, 1408 . 1410 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1411 Application Protocol (CoAP)", RFC 7641, 1412 DOI 10.17487/RFC7641, September 2015, 1413 . 1415 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 1416 Security (TLS) / Datagram Transport Layer Security (DTLS) 1417 Profiles for the Internet of Things", RFC 7925, 1418 DOI 10.17487/RFC7925, July 2016, 1419 . 1421 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 1422 FETCH Methods for the Constrained Application Protocol 1423 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 1424 . 1426 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1427 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1428 May 2018, . 1430 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1431 "Object Security for Constrained RESTful Environments 1432 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1433 . 1435 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 1436 and K. Watsen, "Bootstrapping Remote Secure Key 1437 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 1438 May 2021, . 1440 Appendix A. Use Case Example With Full Discovery (CoRAL) 1442 This section provides the same use case example of Section 5, but 1443 specified in CoRAL [I-D.ietf-core-coral]. 1445 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1447 The CT defines the application group "grp_R2-4-015", with resource 1448 /light and base address [ff05::5:1], as follows. 1450 Request: CT -> RD 1452 Req: POST coap://[2001:db8:4::ff]/rd 1453 Content-Format: TBD123456 (application/coral+cbor) 1455 Payload: 1456 #using reef = 1458 #base 1459 reef:ep "grp_R2-4-015" 1460 reef:et "core.rd-group" 1461 reef:rd-item { 1462 reef:rt "oic.d.light" 1463 } 1465 Response: RD -> CT 1467 Res: 2.01 Created 1468 Location-Path: /rd/501 1470 Also, the CT defines a second application group "grp_schedule", with 1471 resource /schedule and base address [ff05::5:2], as follows. 1473 Request: CT -> RD 1474 Req: POST coap://[2001:db8:4::ff]/rd?ep=grp_schedule&et=core.rd-group 1475 Content-Format: TBD123456 (application/coral+cbor) 1477 Payload: 1478 #using reef = 1480 #base 1481 reef:rd-item { 1482 reef:rt "oic.r.time.period" 1483 } 1485 Response: RD -> CT 1487 Res: 2.01 Created 1488 Location-Path: /rd/502 1490 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1492 Finally, the CT defines the corresponding security groups. In 1493 particular, assuming a Group Manager responsible for both security 1494 groups and with address [2001:db8::ab], the CT specifies: 1496 Request: CT -> RD 1498 Req: POST coap://[2001:db8:4::ff]/rd?ep=gm1 1499 Content-Format: TBD123456 (application/coral+cbor) 1501 Payload: 1502 #using 1503 #using reef = 1505 #base 1506 reef:rd-item { 1507 reef:ct 65000 1508 reef:ct 41 1509 reef:rt "core.osc.gm" 1510 reef:if "ace.group" 1511 sec-gp "feedca570000" 1512 app-gp "grp_R2-4-015" 1513 } 1514 reef:rd-item { 1515 reef:ct 65000 1516 reef:ct 41 1517 reef:rt "core.osc.gm" 1518 reef:if "ace.group" 1519 sec-gp "feedsc590000" 1520 app-gp "grp_schedule" 1521 } 1522 Response: RD -> CT 1524 Res: 2.01 Created 1525 Location-Path: /rd/4521 1527 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1529 The device with IP address [2001:db8:4::x] can retrieve the multicast 1530 IP address of the CoAP group used by the application group 1531 "grp_R2-4-015", by performing an endpoint lookup as shown below. 1533 Request: Joining node -> RD 1535 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 1536 ?et=core.rd-group&ep=grp_R2-4-015 1538 Response: RD -> Joining node 1540 Res: 2.05 Content 1541 Content-Format: TBD123456 (application/coral+cbor) 1543 Payload: 1544 #using reef = 1546 #base 1547 reef:rd-unit <501> { 1548 reef:ep "grp_R2-4-015" 1549 reef:et "core.rd-group" 1550 reef:base 1551 reef:rt "core.rd-ep" 1552 } 1554 Similarly, to retrieve the multicast IP address of the CoAP group 1555 used by the application group "grp_schedule", the device performs an 1556 endpoint lookup as shown below. 1558 Request: Joining node -> RD 1560 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 1561 ?et=core.rd-group&ep=grp_schedule 1563 Response: RD -> Joining node 1564 Res: 2.05 Content 1565 Content-Format: TBD123456 (application/coral+cbor) 1567 Payload: 1568 #using reef = 1570 #base 1571 reef:rd-unit <502> { 1572 reef:ep "grp_schedule" 1573 reef:et "core.rd-group" 1574 reef:base 1575 reef:rt "core.rd-ep" 1576 } 1578 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1580 Consequently, the device learns the security groups it has to join. 1581 In particular, it does the following for app-gp="grp_R2-4-015". 1583 Request: Joining node -> RD 1585 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 1586 ?rt=core.osc.gm&app-gp=grp_R2-4-015 1588 Response: RD -> Joining Node 1590 Res: 2.05 Content 1591 Content-Format: TBD123456 (application/coral+cbor) 1593 Payload: 1594 #using 1595 #using reef = 1597 #base 1598 reef:rd-item { 1599 reef:ct 65000 1600 reef:rt "core.osc.gm" 1601 reef:if "ace.group" 1602 sec-gp "feedca570000" 1603 app-gp "grp_R2-4-015" 1604 } 1606 Similarly, the device does the following for app-gp="grp_schedule". 1608 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 1609 ?rt=core.osc.gm&app-gp=grp_schedule 1611 Response: RD -> Joining Node 1612 Res: 2.05 Content 1613 Content-Format: TBD123456 (application/coral+cbor) 1615 Payload: 1616 #using 1617 #using reef = 1619 #base 1620 reef:rd-item { 1621 reef:ct 65000 1622 reef:rt "core.osc.gm" 1623 reef:if "ace.group" 1624 sec-gp "feedsc590000" 1625 app-gp "grp_schedule" 1626 } 1628 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1630 After this last discovery step, the device can ask permission to join 1631 the security groups, and effectively join them through the Group 1632 Manager, e.g., according to [I-D.ietf-ace-key-groupcomm-oscore]. 1634 Acknowledgments 1636 The authors sincerely thank Carsten Bormann, Klaus Hartke, Jaime 1637 Jimenez, Francesca Palombini, Dave Robin and Jim Schaad for their 1638 comments and feedback. 1640 The work on this document has been partly supported by VINNOVA and 1641 the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home 1642 (Grant agreement 952652); and by the EIT-Digital High Impact 1643 Initiative ACTIVE. 1645 Authors' Addresses 1647 Marco Tiloca 1648 RISE AB 1649 Isafjordsgatan 22 1650 SE-16440 Stockholm Kista 1651 Sweden 1652 Email: marco.tiloca@ri.se 1654 Christian Amsuess 1655 Hollandstr. 12/4 1656 1020 Vienna 1657 Austria 1658 Email: christian@amsuess.com 1659 Peter van der Stok 1660 Consultant 1661 Phone: +31-492474673 (Netherlands), +33-966015248 (France) 1662 Email: stokcons@bbhmail.nl