idnits 2.17.1 draft-tiloca-core-oscore-discovery-09.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-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 (12 July 2021) is 1018 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-03 == Outdated reference: A later version (-11) exists of draft-ietf-core-groupcomm-bis-04 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-12 ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' == Outdated reference: A later version (-18) exists of draft-ietf-ace-key-groupcomm-13 == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-11 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-43 == Outdated reference: A later version (-11) exists of draft-ietf-ace-oscore-gm-admin-03 == Outdated reference: A later version (-09) exists of draft-ietf-cose-cbor-encoded-cert-01 == Outdated reference: A later version (-09) exists of draft-ietf-rats-uccs-00 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: 13 January 2022 6 P. van der Stok 7 Consultant 8 12 July 2021 10 Discovery of OSCORE Groups with the CoRE Resource Directory 11 draft-tiloca-core-oscore-discovery-09 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 13 January 2022. 58 Copyright Notice 60 Copyright (c) 2021 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 Simplified BSD License text 69 as described in Section 4.e of the Trust Legal Provisions and are 70 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . . . . . . . . 6 78 2.2. Relation Link to Authorization Server . . . . . . . . . . 10 79 2.3. Registration Example . . . . . . . . . . . . . . . . . . 11 80 2.3.1. Example in Link Format . . . . . . . . . . . . . . . 11 81 2.3.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 12 82 3. Addition and Update of Security Groups . . . . . . . . . . . 13 83 3.1. Addition Example . . . . . . . . . . . . . . . . . . . . 13 84 3.1.1. Example in Link Format . . . . . . . . . . . . . . . 14 85 3.1.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 14 86 4. Discovery of Security Groups . . . . . . . . . . . . . . . . 16 87 4.1. Discovery Example #1 . . . . . . . . . . . . . . . . . . 18 88 4.1.1. Example in Link Format . . . . . . . . . . . . . . . 18 89 4.1.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . 27 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 96 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 97 8.1. Normative References . . . . . . . . . . . . . . . . . . 27 98 8.2. Informative References . . . . . . . . . . . . . . . . . 29 99 Appendix A. Use Case Example With Full Discovery (CoRAL) . . . . 31 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 The approach in this document is consistent with, but not limited to, 193 the joining of security groups defined in 194 [I-D.ietf-ace-key-groupcomm-oscore]. 196 1.1. Terminology 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 200 "OPTIONAL" in this document are to be interpreted as described in BCP 201 14 [RFC2119] [RFC8174] when, and only when, they appear in all 202 capitals, as shown here. 204 This specification requires readers to be familiar with the terms and 205 concepts discussed in [I-D.ietf-core-resource-directory] and 206 [RFC6690], as well as in [I-D.ietf-core-coral]. Readers should also 207 be familiar with the terms and concepts discussed in 208 [RFC7252][I-D.ietf-core-groupcomm-bis], 209 [I-D.ietf-core-oscore-groupcomm] and 210 [I-D.ietf-ace-key-groupcomm-oscore]. 212 Terminology for constrained environments, such as "constrained 213 device" and "constrained-node network", is defined in [RFC7228]. 215 Consistently with the definitions from Section 2.1 of 216 [I-D.ietf-core-groupcomm-bis], this document also refers to the 217 following terminology. 219 * CoAP group: a set of CoAP endpoints all configured to receive CoAP 220 multicast messages sent to the group's associated IP multicast 221 address and UDP port. An endpoint may be a member of multiple 222 CoAP groups by subscribing to multiple IP multicast addresses. 224 * Security group: a set of CoAP endpoints that share the same 225 security material, and use it to protect and verify exchanged 226 messages. A CoAP endpoint may be a member of multiple security 227 groups. There can be a one-to-one or a one-to-many relation 228 between security groups and CoAP groups. 230 This document especially considers a security group to be an 231 OSCORE group, where all members share one OSCORE Security Context 232 to protect group communication with Group OSCORE 233 [I-D.ietf-core-oscore-groupcomm]. However, the approach defined 234 in this document can be used to support the discovery of different 235 security groups than OSCORE groups. 237 * Application group: a set of CoAP endpoints that share a common set 238 of resources. An endpoint may be a member of multiple application 239 groups. An application group can be associated with one or more 240 security groups, and multiple application groups can use the same 241 security group. Application groups are announced in the RD by a 242 Commissioning Tool, according to the RD-Groups usage pattern (see 243 Appendix A of [I-D.ietf-core-resource-directory]). 245 2. Registration of Group Manager Endpoints 247 During deployment, a Group Manager (GM) can find the CoRE Resource 248 Directory (RD) as described in Section 4 of 249 [I-D.ietf-core-resource-directory]. 251 Afterwards, the GM registers as an endpoint with the RD, as described 252 in Section 5 of [I-D.ietf-core-resource-directory]. The GM SHOULD 253 NOT use the Simple Registration approach described in Section 5.1 of 254 [I-D.ietf-core-resource-directory]. 256 When registering with the RD, the GM also registers the links to all 257 the group-membership resources it has at that point in time, i.e., 258 one for each of its security groups. 260 In the registration request, each link to a group-membership resource 261 has as target the URI of that resource at the GM. Also, it specifies 262 a number of descriptive parameters as defined in Section 2.1. 264 2.1. Parameters 266 For each registered link to a group-membership resource at a GM, the 267 following parameters are specified together with the link. 269 In the RD defined in [I-D.ietf-core-resource-directory] and based on 270 Link Format, each parameter is specified in a target attribute with 271 the same name. 273 In a RD based on CoRAL, such as the one defined in 274 [I-D.hartke-t2trg-coral-reef], each parameter is specified in a 275 nested element with the same name. 277 * 'ct', specifying the content format used with the group-membership 278 resource at the Group Manager, with value "application/ace- 279 groupcomm+cbor" registered in Section 8.2 of 280 [I-D.ietf-ace-key-groupcomm]. 282 Note: The examples in this document use the provisional value 283 65000 from the range "Reserved for Experimental Use" of the "CoAP 284 Content-Formats" registry, within the "CoRE Parameters" registry. 286 * 'rt', specifying the resource type of the group-membership 287 resource at the Group Manager, with value "core.osc.gm" registered 288 in Section 21.11 of [I-D.ietf-ace-key-groupcomm-oscore]. 290 * 'if', specifying the interface description for accessing the 291 group-membership resource at the Group Manager, with value 292 "ace.group" registered in Section 8.10 of 293 [I-D.ietf-ace-key-groupcomm]. 295 * 'sec-gp', specifying the name of the security group of interest, 296 as a stable and invariant identifier, such as the group name used 297 in [I-D.ietf-ace-key-groupcomm-oscore]. This parameter MUST 298 specify a single value. 300 * 'app-gp', specifying the name(s) of the application group(s) 301 associated to the security group of interest indicated by 'sec- 302 gp'. This parameter MUST occur once for each application group, 303 and MUST specify only a single application group. 305 When a security group is created at the GM, the names of the 306 application groups using it are also specified as part of the 307 security group configuration (see [I-D.ietf-ace-oscore-gm-admin]). 308 Thus, when registering the links to its group-membership resource, 309 the GM is aware of the application groups and their names. 311 If a different entity than the GM registers the security groups to 312 the RD, e.g., a Commissioning Tool, this entity has to also be 313 aware of the application groups and their names to specify. To 314 this end, it can obtain them from the GM or from the Administator 315 that created the security groups at the GM (see 316 [I-D.ietf-ace-oscore-gm-admin]). 318 Optionally, the following parameters can also be specified. If Link 319 Format is used, the value of each of these parameters is encoded as a 320 text string. 322 * 'hkdf', specifying the HKDF Algorithm used in the security group. 323 If present, this parameter MUST specify a single value, which is 324 taken from the 'Value' column of the "COSE Algorithms" Registry 325 [COSE.Algorithms]. 327 * 'pub_key_enc', specifying the encoding of the public keys used in 328 the security group. If present, this parameter MUST specify a 329 single value, which is taken from the 'Label' column of the "COSE 330 Header Parameters" Registry [COSE.Header.Parameters]. Acceptable 331 values denote an encoding that MUST explicitly provide the full 332 set of information related to the public key algorithm, including, 333 e.g., the used elliptic curve (when applicable). 335 At the time of writing this specification, acceptable public key 336 encodings are CWTs [RFC8392], unprotected CWT claim sets 337 [I-D.ietf-rats-uccs], X.509 certificates [RFC7925] and C509 338 certificates [I-D.ietf-cose-cbor-encoded-cert]. Further encodings 339 may be available in the future, and would be acceptable to use as 340 long as they comply with the criteria defined above. 342 [ As to CWTs and unprotected CWT claim sets, there is a pending 343 registration requested by draft-ietf-lake-edhoc. ] 345 [ As to C509 certificates, there is a pending registration 346 requested by draft-ietf-cose-cbor-encoded-cert. ] 348 * 'sign_enc_alg', specifying the encryption algorithm used to 349 encrypt messages in the security group, when these are also 350 signed, e.g., as in the group mode of Group OSCORE (see Section 8 351 of [I-D.ietf-core-oscore-groupcomm]). If present, this parameter 352 MUST specify a single value, which is taken from the 'Value' 353 column of the "COSE Algorithms" Registry [COSE.Algorithms]. 355 * 'sign_alg', specifying the algorithm used to sign messages in the 356 security group. If present, this parameter MUST specify a single 357 value, which is taken from the 'Value' column of the "COSE 358 Algorithms" Registry [COSE.Algorithms]. 360 * 'sign_alg_crv', specifying the elliptic curve (if applicable) for 361 the algorithm used to sign messages in the security group. If 362 present, this parameter MUST specify a single value, which is 363 taken from the 'Value' column of the "COSE Elliptic Curves" 364 Registry [COSE.Elliptic.Curves]. 366 * 'sign_key_kty', specifying the key type of countersignature keys 367 used to sign messages in the security group. If present, this 368 parameter MUST specify a single value, which is taken from the 369 'Value' column of the "COSE Key Types" Registry [COSE.Key.Types]. 371 * 'sign_key_crv', specifying the elliptic curve (if applicable) of 372 countersignature keys used to sign messages in the security group. 373 If present, this parameter MUST specify a single value, which is 374 taken from the 'Value' column of the "COSE Elliptic Curves" 375 Registry [COSE.Elliptic.Curves]. 377 * 'alg', specifying the encryption algorithm used to encrypt 378 messages in the security group, when these are encrypted with 379 pairwise encryption keys, e.g., as in the pairwise mode of Group 380 OSCORE (see Section 9 of [I-D.ietf-core-oscore-groupcomm]). If 381 present, this parameter MUST specify a single value, which is 382 taken from the 'Value' column of the "COSE Algorithms" Registry 383 [COSE.Algorithms]. 385 * 'ecdh_alg', specifying the ECDH algorithm used to derive pairwise 386 encryption keys in the security group, e.g., as for the pairwise 387 mode of Group OSCORE (see Section 2.3 of 388 [I-D.ietf-core-oscore-groupcomm]). If present, this parameter 389 MUST specify a single value, which is taken from the 'Value' 390 column of the "COSE Algorithms" Registry [COSE.Algorithms]. 392 * 'ecdh_alg_crv', specifying the elliptic curve for the ECDH 393 algorithm used to derive pairwise encryption keys in the security 394 group. If present, this parameter MUST specify a single value, 395 which is taken from the 'Value' column of the "COSE Elliptic 396 Curves" Registry [COSE.Elliptic.Curves]. 398 * 'ecdh_key_kty', specifying the key type of keys used with an ECDH 399 algorithm to derive pairwise encryption keys in the security 400 group. If present, this parameter MUST specify a single value, 401 which is taken from the 'Value' column of the "COSE Key Types" 402 Registry [COSE.Key.Types]. 404 * 'ecdh_key_crv', specifying the elliptic curve of keys used with an 405 ECDH algorithm to derive pairwise encryption keys in the security 406 group. If present, this parameter MUST specify a single value, 407 which is taken from the 'Value' column of the "COSE Elliptic 408 Curves" Registry [COSE.Elliptic.Curves]. 410 If the security group does not recur to message signing, then the 411 parameters 'sign_enc_alg', 'sign_alg', 'sign_alg_crv', 'sign_key_kty' 412 and 'sign_key_crv' MUST NOT be present. For instance, this is the 413 case for a security group that uses Group OSCORE and uses only the 414 pairwise mode (see Section 9 of [I-D.ietf-core-oscore-groupcomm]). 416 If the security group does not recur to message encryption through 417 pairwise encryption keys, then the parameters 'alg', 'ecdh_alg', 418 'ecdh_alg_crv', 'ecdh_key_kty' and 'ecdh_key_crv' MUST NOT be 419 present. For instance, this is the case for a security group that 420 uses Group OSCORE and uses only the group mode see Section 8 of 421 [I-D.ietf-core-oscore-groupcomm]). 423 Note that the values registered in the COSE Registries 424 [COSE.Algorithms][COSE.Elliptic.Curves][COSE.Key.Types] are strongly 425 typed. On the contrary, Link Format is weakly typed and thus does 426 not distinguish between, for instance, the string value "-10" and the 427 integer value -10. 429 Thus, in RDs that return responses in Link Format, string values 430 which look like an integer are not supported. Therefore, such values 431 MUST NOT be advertised through the corresponding parameters above. 433 A CoAP endpoint that queries the RD to discover security groups and 434 their group-membership resource to access (see Section 4) would 435 benefit from the information above as follows. 437 * The values of 'pub_key_enc', 'sign_alg', 'sign_alg_crv', 438 'sign_key_kty', 'sign_key_crv', 'ecdh_alg', 'ecdh_alg_crv', 439 'ecdh_key_kty' and 'ecdh_key_crv' related to a group-membership 440 resource provide an early knowledge of the format and encoding of 441 public keys used in the security group. 443 Thus, the CoAP endpoint does not need to ask the GM for this 444 information as a preliminary step before the joining process, or 445 to perform a trial-and-error joining exchange with the GM. Hence, 446 the CoAP endpoint is able to provide the GM with its own public 447 key in the correct expected format and encoding at the very first 448 step of the joining process. 450 * The values of 'hkdf', 'sign_enc_alg', 'sign_alg', 'alg' and 451 'ecdh_alg' related to a group-membership resource provide an early 452 knowledge of the algorithms used in the security group. 454 Thus, the CoAP endpoint is able to decide whether to actually 455 proceed with the joining process, depending on its support for the 456 indicated algorithms. 458 2.2. Relation Link to Authorization Server 460 For each registered link to a group-membership resource, the GM MAY 461 additionally specify the link to the ACE Authorization Server (AS) 462 [I-D.ietf-ace-oauth-authz] associated to the GM, and issuing 463 authorization credentials to join the security group as described in 464 [I-D.ietf-ace-key-groupcomm-oscore]. 466 The link to the AS has as target the URI of the resource where to 467 send an authorization request to. 469 In the RD defined in [I-D.ietf-core-resource-directory] and based on 470 Link Format, the link to the AS is separately registered with the RD, 471 and includes the following parameters as target attributes. 473 * 'rel', with value "authorization_server". 475 * 'anchor', with value the target of the link to the group- 476 membership resource at the GM. 478 In a RD based on CoRAL, such as the one defined in 479 [I-D.hartke-t2trg-coral-reef], this is mapped (as describe there) to 480 a link from the registration resource to the AS, using the 481 link 482 relation type. 484 2.3. Registration Example 486 The example below shows a GM with endpoint name "gm1" and address 487 2001:db8::ab that registers with the RD. 489 The GM specifies the value of the 'sec-gp' parameter for accessing 490 the security group with name "feedca570000", and used by the 491 application group with name "group1" specified with the value of the 492 'app-gp' parameter. 494 The countersignature algorithm used in the security group is EdDSA 495 (-8), with elliptic curve Ed25519 (6). Public keys used in the 496 security group are encoded as X.509 certificates [RFC7925], which is 497 signaled through the COSE Header Parameter "x5chain" (33). The ECDH 498 algorithm used in the security group is ECDH-SS + HKDF-256 (-27), 499 with elliptic curve X25519 (4). 501 In addition, the GM specifies the link to the ACE Authorization 502 Server associated to the GM, to which a CoAP endpoint should send an 503 Authorization Request for joining the corresponding security group 504 (see [I-D.ietf-ace-key-groupcomm-oscore]). 506 2.3.1. Example in Link Format 508 Request: GM -> RD 510 Req: POST coap://rd.example.com/rd?ep=gm1 511 Content-Format: 40 512 Payload: 513 ;ct=65000;rt="core.osc.gm";if="ace.group"; 514 sec-gp="feedca570000";app-gp="group1"; 515 pub_key_enc="33";sign_enc_alg="10"; 516 sign_alg="-8";sign_alg_crv="6"; 517 alg="10";ecdh_alg="-27";ecdh_alg_crv="4", 518 ; 519 rel="authorization-server"; 520 anchor="coap://[2001:db8::ab]/ace-group/feedca570000" 522 Response: RD -> GM 524 Res: 2.01 Created 525 Location-Path: /rd/4521 527 2.3.2. Example in CoRAL 529 Request: GM -> RD 531 Req: POST coap://rd.example.com/rd?ep=gm1 532 Content-Format: TBD123456 (application/coral+cbor) 534 Payload: 535 #using 536 #using reef = 537 #using iana = 539 #base 540 reef:rd-item { 541 reef:ct 65000 542 reef:rt "core.osc.gm" 543 reef:if "ace.group" 544 sec-gp "feedca570000" 545 app-gp "group1" 546 pub_key_enc 33 547 sign_enc_alg 10 548 sign_alg -8 549 sign_alg_crv 6 550 alg 10 551 ecdh_alg -27 552 ecdh_alg_crv 4 553 iana:authorization-server 554 } 556 Response: RD -> GM 557 Res: 2.01 Created 558 Location-Path: /rd/4521 560 3. Addition and Update of Security Groups 562 The GM is responsible to refresh the registration of all its group- 563 membership resources in the RD. This means that the GM has to update 564 the registration within its lifetime as per Section 5.3.1 of 565 [I-D.ietf-core-resource-directory], and has to change the content of 566 the registration when a group-membership resource is added/removed, 567 or if its parameters have to be changed, such as in the following 568 cases. 570 * The GM creates a new security group and starts exporting the 571 related group-membership resource. 573 * The GM dismisses a security group and stops exporting the related 574 group-membership resource. 576 * Information related to an existing security group changes, e.g., 577 the list of associated application groups. 579 To perform an update of its registrations, the GM can re-register 580 with the RD and fully specify all links to its group-membership 581 resources. 583 Alternatively, the GM can perform a PATCH/iPATCH [RFC8132] request to 584 the RD, as per Section 5.3.3 of [I-D.ietf-core-resource-directory]. 585 This requires new media-types to be defined in future standards, to 586 apply a new document as a patch to an existing stored document. 588 3.1. Addition Example 590 The example below shows how the GM from Section 2 re-registers with 591 the RD. When doing so, it specifies: 593 * The same previous group-membership resource associated to the 594 security group with name "feedca570000". 596 * An additional group-membership resource associated to the security 597 group with name "ech0ech00000" and used by the application group 598 "group2". 600 * A third group-membership resource associated with the security 601 group with name "abcdef120000" and used by two application groups, 602 namely "group3" and "group4". 604 Furthermore, the GM relates the same Authorization Server also to the 605 security groups "ech0ech00000" and "abcdef120000". 607 3.1.1. Example in Link Format 609 Request: GM -> RD 611 Req: POST coap://rd.example.com/rd?ep=gm1 612 Content-Format: 40 613 Payload: 614 ;ct=65000;rt="core.osc.gm";if="ace.group"; 615 sec-gp="feedca570000";app-gp="group1"; 616 pub_key_enc="33";sign_enc_alg="10"; 617 sign_alg="-8";sign_alg_crv="6"; 618 alg="10";ecdh_alg="-27";ecdh_alg_crv="4", 619 ;ct=65000;rt="core.osc.gm";if="ace.group"; 620 sec-gp="ech0ech00000";app-gp="group2"; 621 pub_key_enc="33";sign_enc_alg="10"; 622 sign_alg="-8";sign_alg_crv="6"; 623 alg="10";ecdh_alg="-27";ecdh_alg_crv="4", 624 ;ct=65000;rt="core.osc.gm";if="ace.group"; 625 sec-gp="abcdef120000";app-gp="group3"; 626 app-gp="group4";pub_key_enc="33"; 627 sign_enc_alg="10";sign_alg="-8"; 628 sign_alg_crv="6";alg="10";ecdh_alg="-27"; 629 ecdh_alg_crv="4", 630 ; 631 rel="authorization-server"; 632 anchor="coap://[2001:db8::ab]/ace-group/feedca570000", 633 ; 634 rel="authorization-server"; 635 anchor="coap://[2001:db8::ab]/ace-group/ech0ech00000", 636 ; 637 rel="authorization-server"; 638 anchor="coap://[2001:db8::ab]/ace-group/abcdef120000" 640 Response: RD -> GM 642 Res: 2.04 Changed 643 Location-Path: /rd/4521 645 3.1.2. Example in CoRAL 647 Request: GM -> RD 648 Req: POST coap://rd.example.com/rd?ep=gm1 649 Content-Format: TBD123456 (application/coral+cbor) 651 Payload: 652 #using 653 #using reef = 654 #using iana = 656 #base 657 reef:rd-item { 658 reef:ct 65000 659 reef:rt "core.osc.gm" 660 reef:if "ace.group" 661 sec-gp "feedca570000" 662 app-gp "group1" 663 pub_key_enc 33 664 sign_enc_alg 10 665 sign_alg -8 666 sign_alg_crv 6 667 alg 10 668 ecdh_alg -27 669 ecdh_alg_crv 4 670 iana:authorization-server 671 } 672 reef:rd-item { 673 reef:ct 65000 674 reef:rt "core.osc.gm" 675 reef:if "ace.group" 676 sec-gp "ech0ech00000" 677 app-gp "group2" 678 pub_key_enc 33 679 sign_enc_alg 10 680 sign_alg -8 681 sign_alg_crv 6 682 alg 10 683 ecdh_alg -27 684 ecdh_alg_crv 4 685 iana:authorization-server 686 } 687 reef:rd-item { 688 reef:ct 65000 689 reef:rt "core.osc.gm" 690 reef:if "ace.group" 691 sec-gp "abcdef120000" 692 app-gp "group3" 693 app-gp "group4" 694 pub_key_enc 33 695 sign_enc_alg 10 696 sign_alg -8 697 sign_alg_crv 6 698 alg 10 699 ecdh_alg -27 700 ecdh_alg_crv 4 701 iana:authorization-server 702 } 704 Response: RD -> GM 706 Res: 2.04 Changed 707 Location-Path: /rd/4521 709 4. Discovery of Security Groups 711 A CoAP endpoint that wants to join a security group, hereafter called 712 the joining node, might not have all the necessary information at 713 deployment time. Also, it might want to know about possible new 714 security groups created afterwards by the respective Group Managers. 716 To this end, the joining node can perform a resource lookup at the RD 717 as per Section 6.1 of [I-D.ietf-core-resource-directory], to retrieve 718 the missing pieces of information needed to join the security 719 group(s) of interest. The joining node can find the RD as described 720 in Section 4 of [I-D.ietf-core-resource-directory]. 722 The joining node uses the following parameter value for the lookup 723 filtering. 725 * 'rt' = "core.osc.gm", specifying the resource type of the group- 726 membership resource at the Group Manager, with value "core.osc.gm" 727 registered in Section 21.11 of 728 [I-D.ietf-ace-key-groupcomm-oscore]. 730 The joining node may additionally consider the following parameters 731 for the lookup filtering, depending on the information it has already 732 available. 734 * 'sec-gp', specifying the name of the security group of interest. 735 This parameter MUST specify a single value. 737 * 'ep', specifying the registered endpoint of the GM. 739 * 'app-gp', specifying the name(s) of the application group(s) 740 associated with the security group of interest. This parameter 741 MAY be included multiple times, and each occurrence MUST specify 742 the name of one application group. 744 * 'if', specifying the interface description for accessing the 745 group-membership resource at the Group Manager, with value 746 "ace.group" registered in Section 8.10 of 747 [I-D.ietf-ace-key-groupcomm]. 749 The response from the RD may include links to a group-membership 750 resource specifying multiple application groups, as all using the 751 same security group. In this case, the joining node is already 752 expected to know the exact application group of interest. 754 Furthermore, the response from the RD may include the links to 755 different group-membership resources, all specifying a same 756 application group of interest for the joining node, if the 757 corresponding security groups are all used by that application group. 759 In this case, application policies on the joining node should define 760 how to determine the exact security group to join (see Section 2.1 of 761 [I-D.ietf-core-groupcomm-bis]). For example, different security 762 groups can reflect different security algorithms to use. Hence, a 763 client application can take into account what the joining node 764 supports and prefers, when selecting one particular security group 765 among the indicated ones, while a server application would need to 766 join all of them. Later on, the joining node will be anyway able to 767 join only security groups for which it is actually authorized to be a 768 member (see [I-D.ietf-ace-key-groupcomm-oscore]). 770 Note that, with RD-based discovery, including the 'app-gp' parameter 771 multiple times would result in finding only the group-membership 772 resource that serves all the specified application groups, i.e., not 773 any group-membership resource that serves either. Therefore, a 774 joining node needs to perform N separate queries with different 775 values for 'app-gp', in order to safely discover the (different) 776 group-membership resource(s) serving the N application groups. 778 The discovery of security groups as defined in this document is 779 applicable and useful to other CoAP endpoints than the actual joining 780 nodes. In particular, other entities can be interested to discover 781 and interact with the group-membership resource at the Group Manager. 782 These include entities acting as signature checkers, e.g., 783 intermediary gateways, that do not join a security group, but can 784 retrieve public keys of group members from the Group Manager, in 785 order to verify counter signatures of group messages (see Section 3 786 of [I-D.ietf-core-oscore-groupcomm]). 788 4.1. Discovery Example #1 790 Consistently with the examples in Section 2 and Section 3, the 791 examples below consider a joining node that wants to join the 792 security group associated with the application group "group1", but 793 that does not know the name of the security group, the responsible GM 794 and the group-membership resource to access. 796 4.1.1. Example in Link Format 798 Request: Joining node -> RD 800 Req: GET coap://rd.example.com/rd-lookup/res 801 ?rt=core.osc.gm&app-gp=group1 803 Response: RD -> Joining node 805 Res: 2.05 Content 806 Payload: 807 ;ct=65000; 808 rt="core.osc.gm";if="ace.group";sec-gp="feedca570000"; 809 app-gp="group1";pub_key_enc="33";sign_enc_alg="10"; 810 sign_alg="-8";sign_alg_crv="6";alg="10"; 811 ecdh_alg="-27";ecdh_alg_crv="4"; 812 anchor="coap://[2001:db8::ab]" 814 By performing the separate resource lookup below, the joining node 815 can retrieve the link to the ACE Authorization Server associated to 816 the GM, where to send an Authorization Request for joining the 817 corresponding security group (see 818 [I-D.ietf-ace-key-groupcomm-oscore]). 820 Request: Joining node -> RD 822 Req: GET coap://rd.example.com/rd-lookup/res 823 ?rel=authorization-server& 824 anchor=coap://[2001:db8::ab]/ace-group/feedca570000 826 Response: RD -> Joining node 828 Res: 2.05 Content 829 Payload: 830 831 To retrieve the multicast IP address of the CoAP group used by the 832 application group "group1", the joining node performs an endpoint 833 lookup as shown below. The following assumes that the application 834 group "group1" had been previously registered as per Appendix A of 835 [I-D.ietf-core-resource-directory], with ff35:30:2001:db8::23 as 836 multicast IP address of the associated CoAP group. 838 Request: Joining node -> RD 840 Req: GET coap://rd.example.com/rd-lookup/ep 841 ?et=core.rd-group&ep=group1 843 Response: RD -> Joining node 845 Res: 2.05 Content 846 Payload: 847 ;ep="group1";et="core.rd-group"; 848 base="coap://[ff35:30:2001:db8::23]";rt="core.rd-ep" 850 4.1.2. Example in CoRAL 852 Request: Joining node -> RD 854 Req: GET coap://rd.example.com/rd-lookup/res 855 ?rt=core.osc.gm&app-gp=group1 856 Accept: TBD123456 (application/coral+cbor) 858 Response: RD -> Joining node 859 Res: 2.05 Content 860 Content-Format: TBD123456 (application/coral+cbor) 862 Payload: 863 #using 864 #using reef = 865 #using iana = 867 #base 868 reef:rd-item { 869 reef:ct 65000 870 reef:rt "core.osc.gm" 871 reef:if "ace.group" 872 sec-gp "feedca570000" 873 app-gp "group1" 874 pub_key_enc 33 875 sign_enc_alg 10 876 sign_alg -8 877 sign_alg_crv 6 878 alg 10 879 ecdh_alg -27 880 ecdh_alg_crv 4 881 iana:authorization-server 882 } 884 To retrieve the multicast IP address of the CoAP group used by the 885 application group "group1", the joining node performs an endpoint 886 lookup as shown below. The following assumes that the application 887 group "group1" had been previously registered, with 888 ff35:30:2001:db8::23 as multicast IP address of the associated CoAP 889 group. 891 Request: Joining node -> RD 893 Req: GET coap://rd.example.com/rd-lookup/ep 894 ?et=core.rd-group&ep=group1 895 Accept: TBD123456 (application/coral+cbor) 897 Response: RD -> Joining node 898 Res: 2.05 Content 899 Content-Format: TBD123456 (application/coral+cbor) 901 Payload: 902 #using 903 #using reef = 905 reef:rd-unit <./rd/501> { 906 reef:ep "group1" 907 reef:et "core.rd-group" 908 reef:base 909 reef:rt "core.rd-ep" 910 } 912 4.2. Discovery Example #2 914 Consistently with the examples in Section 2 and Section 3, the 915 examples below consider a joining node that wants to join the 916 security group with name "feedca570000", but that does not know the 917 responsible GM, the group-membership resource to access, and the 918 associated application groups. 920 The examples also show how the joining node uses CoAP observation 921 [RFC7641], in order to be notified of possible changes to the 922 parameters of the group-membership resource. This is also useful to 923 handle the case where the security group of interest has not been 924 created yet, so that the joining node can receive the requested 925 information when it becomes available. 927 4.2.1. Example in Link Format 929 Request: Joining node -> RD 931 Req: GET coap://rd.example.com/rd-lookup/res 932 ?rt=core.osc.gm&sec-gp=feedca570000 933 Observe: 0 935 Response: RD -> Joining node 937 Res: 2.05 Content 938 Observe: 24 939 Payload: 940 ;ct=65000; 941 rt="core.osc.gm";if="ace.group";sec-gp="feedca570000"; 942 app-gp="group1";pub_key_enc="33";sign_enc_alg="10"; 943 sign_alg="-8";sign_alg_crv="6";alg="10"; 944 ecdh_alg="-27";ecdh_alg_crv="4"; 945 anchor="coap://[2001:db8::ab]" 947 Depending on the search criteria, the joining node performing the 948 resource lookup can get large responses. This can happen, for 949 instance, when the lookup request targets all the group-membership 950 resources at a specified GM, or all the group-membership resources of 951 all the registered GMs, as in the example below. 953 Request: Joining node -> RD 955 Req: GET coap://rd.example.com/rd-lookup/res?rt=core.osc.gm 957 Response: RD -> Joining node 959 Res: 2.05 Content 960 Payload: 961 ;ct=65000; 962 rt="core.osc.gm";if="ace.group";sec-gp="feedca570000"; 963 app-gp="group1";pub_key_enc="33";sign_enc_alg="10"; 964 sign_alg="-8";sign_alg_crv="6";alg="10";ecdh_alg="-27"; 965 ecdh_alg_crv="4";anchor="coap://[2001:db8::ab]", 966 ;ct=65000; 967 rt="core.osc.gm";if="ace.group";sec-gp="ech0ech00000"; 968 app-gp="group2";pub_key_enc="33";sign_enc_alg="10"; 969 sign_alg="-8";sign_alg_crv="6";alg="10";ecdh_alg="-27"; 970 ecdh_alg_crv="4";anchor="coap://[2001:db8::ab]", 971 ;ct=65000; 972 rt="core.osc.gm";if="ace.group";sec-gp="abcdef120000"; 973 app-gp="group3";app-gp="group4";pub_key_enc="33"; 974 sign_enc_alg="10";sign_alg="-8";sign_alg_crv="6";alg="10"; 975 ecdh_alg="-27";ecdh_alg_crv="4";anchor="coap://[2001:db8::ab]" 977 Therefore, it is RECOMMENDED that a joining node which performs a 978 resource lookup with the CoAP Observe option specifies the value of 979 the parameter 'sec-gp' in its GET request sent to the RD. 981 4.2.2. Example in CoRAL 983 Request: Joining node -> RD 985 Req: GET coap://rd.example.com/rd-lookup/res 986 ?rt=core.osc.gm&sec-gp=feedca570000 987 Accept: TBD123456 (application/coral+cbor) 988 Observe: 0 990 Response: RD -> Joining node 991 Res: 2.05 Content 992 Observe: 24 993 Content-Format: TBD123456 (application/coral+cbor) 995 Payload: 996 #using 997 #using reef = 998 #using iana = 1000 #base 1001 reef:rd-item { 1002 reef:ct 65000 1003 reef:rt "core.osc.gm" 1004 reef:if "ace.group" 1005 sec-gp "feedca570000" 1006 app-gp "group1" 1007 pub_key_enc 33 1008 sign_enc_alg 10 1009 sign_alg -8 1010 sign_alg_crv 6 1011 alg 10 1012 ecdh_alg -27 1013 ecdh_alg_crv 4 1014 iana:authorization-server 1015 } 1017 5. Use Case Example With Full Discovery 1019 In this section, the discovery of security groups is described to 1020 support the installation process of a lighting installation in an 1021 office building. The described process is a simplified version of 1022 one of many processes. 1024 The process described in this section is intended as an example and 1025 does not have any particular ambition to serve as recommendation or 1026 best practice to adopt. That is, it shows a possible workflow 1027 involving a Commissioning Tool (CT) used in a certain way, while it 1028 is not meant to prescribe how the workflow should necessarily be. 1030 Assume the existence of four luminaires that are members of two 1031 application groups. In the first application group, the four 1032 luminaires receive presence messages and light intensity messages 1033 from sensors or their proxy. In the second application group, the 1034 four luminaires and several other pieces of equipment receive 1035 building state schedules. 1037 Each of the two application groups is associated to a different 1038 security group and to a different CoAP group with its own dedicated 1039 multicast IP address. 1041 The Fairhair Alliance describes how a new device is accepted and 1042 commissioned in the network [Fairhair], by means of its certificate 1043 stored during the manufacturing process. When commissioning the new 1044 device in the installation network, the new device gets a new 1045 identity defined by a newly allocated certificate, following the 1046 BRSKI specification. 1048 Section 7.3 of [I-D.ietf-core-resource-directory] describes how the 1049 CT assigns an endpoint name based on the CN field, (CN=ACME) and the 1050 serial number of the certificate (serial number = 123x, with 3 < x < 1051 8). Corresponding ep-names ACME-1234, ACME-1235, ACME-1236 and 1052 ACME-1237 are also assumed. 1054 It is common practice that locations in the building are specified 1055 according to a coordinate system. After the acceptance of the 1056 luminaires into the installation network, the coordinate of each 1057 device is communicated to the CT. This can be done manually or 1058 automatically. 1060 The mapping between location and ep-name is calculated by the CT. 1061 For instance, on the basis of grouping criteria, the CT assigns: i) 1062 application group "grp_R2-4-015" to the four luminaires; and ii) 1063 application group "grp_schedule" to all schedule requiring devices. 1064 Also, the device with ep name ACME-123x has been assigned IP address: 1065 [2001:db8:4::x]. The RD is assigned IP address: [2001:db8:4:ff]. 1066 The used multicast addresses are: [ff05::5:1] and [ff05::5:2]. 1068 The following assumes that each device is pre-configured with the 1069 name of the two application groups it belongs to. Additional 1070 mechanisms can be defined in the RD, for supporting devices to 1071 discover the application groups they belong to. 1073 Appendix A provides this same use case example in CoRAL. 1075 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1077 The CT defines the application group "grp_R2-4-015", with resource 1078 /light and base address [ff05::5:1], as follows. 1080 Request: CT -> RD 1081 Req: POST coap://[2001:db8:4::ff]/rd 1082 ?ep=grp_R2-4-015&et=core.rd-group&base=coap://[ff05::5:1] 1083 Content-Format: 40 1084 Payload: 1085 ;rt="oic.d.light" 1087 Response: RD -> CT 1089 Res: 2.01 Created 1090 Location-Path: /rd/501 1092 Also, the CT defines a second application group "grp_schedule", with 1093 resource /schedule and base address [ff05::5:2], as follows. 1095 Request: CT -> RD 1097 Req: POST coap://[2001:db8:4::ff]/rd 1098 ?ep=grp_schedule&et=core.rd-group&base=coap://[ff05::5:2] 1099 Content-Format: 40 1100 Payload: 1101 ;rt="oic.r.time.period" 1103 Response: RD -> CT 1105 Res: 2.01 Created 1106 Location-Path: /rd/502 1108 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1110 Finally, the CT defines the corresponding security groups. In 1111 particular, assuming a Group Manager responsible for both security 1112 groups and with address [2001:db8::ab], the CT specifies: 1114 Request: CT -> RD 1116 Req: POST coap://[2001:db8:4::ff]/rd 1117 ?ep=gm1&base=coap://[2001:db8::ab] 1118 Content-Format: 40 1119 Payload: 1120 ;ct=65000;rt="core.osc.gm";if="ace.group"; 1121 sec-gp="feedca570000"; 1122 app-gp="grp_R2-4-015", 1123 ;ct=65000;rt="core.osc.gm";if="ace.group"; 1124 sec-gp="feedsc590000"; 1125 app-gp="grp_schedule" 1127 Response: RD -> CT 1128 Res: 2.01 Created 1129 Location-Path: /rd/4521 1131 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1133 The device with IP address [2001:db8:4::x] can retrieve the multicast 1134 IP address of the CoAP group used by the application group 1135 "grp_R2-4-015", by performing an endpoint lookup as shown below. 1137 Request: Joining node -> RD 1139 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 1140 ?et=core.rd-group&ep=grp_R2-4-015 1142 Response: RD -> Joining node 1144 Res: 2.05 Content 1145 Content-Format: 40 1146 Payload: 1147 ;ep="grp_R2-4-015";et="core.rd-group"; 1148 base="coap://[ff05::5:1]";rt="core.rd-ep" 1150 Similarly, to retrieve the multicast IP address of the CoAP group 1151 used by the application group "grp_schedule", the device performs an 1152 endpoint lookup as shown below. 1154 Request: Joining node -> RD 1156 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 1157 ?et=core.rd-group&ep=grp_schedule 1159 Response: RD -> Joining node 1161 Res: 2.05 Content 1162 Content-Format: 40 1163 Payload: 1164 ;ep="grp_schedule";et="core.rd-group"; 1165 base="coap://[ff05::5:2]";rt="core.rd-ep" 1167 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1169 Consequently, the device learns the security groups it has to join. 1170 In particular, it does the following for app-gp="grp_R2-4-015". 1172 Request: Joining node -> RD 1174 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 1175 ?rt=core.osc.gm&app-gp=grp_R2-4-015 1177 Response: RD -> Joining Node 1179 Res: 2.05 Content 1180 Content-Format: 40 1181 Payload: 1182 ;ct=65000; 1183 rt="core.osc.gm";if="ace.group";sec-gp="feedca570000"; 1184 app-gp="grp_R2-4-015";anchor="coap://[2001:db8::ab]" 1186 Similarly, the device does the following for app-gp="grp_schedule". 1188 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 1189 ?rt=core.osc.gm&app-gp=grp_schedule 1191 Response: RD -> Joining Node 1193 Res: 2.05 Content 1194 Content-Format: 40 1195 Payload: 1196 ;ct=65000; 1197 rt="core.osc.gm";if="ace.group";sec-gp="feedsc590000"; 1198 app-gp="grp_schedule";anchor="coap://[2001:db8::ab]" 1200 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1202 After this last discovery step, the device can ask permission to join 1203 the security groups, and effectively join them through the Group 1204 Manager, e.g., according to [I-D.ietf-ace-key-groupcomm-oscore]. 1206 6. Security Considerations 1208 The security considerations as described in Section 8 of 1209 [I-D.ietf-core-resource-directory] apply here as well. 1211 7. IANA Considerations 1213 This document has no actions for IANA. 1215 8. References 1217 8.1. Normative References 1219 [COSE.Algorithms] 1220 IANA, "COSE Algorithms", 1221 . 1224 [COSE.Elliptic.Curves] 1225 IANA, "COSE Elliptic Curves", 1226 . 1229 [COSE.Header.Parameters] 1230 IANA, "COSE Header Parameters", 1231 . 1234 [COSE.Key.Types] 1235 IANA, "COSE Key Types", 1236 . 1239 [I-D.ietf-core-coral] 1240 Hartke, K., "The Constrained RESTful Application Language 1241 (CoRAL)", Work in Progress, Internet-Draft, draft-ietf- 1242 core-coral-03, 9 March 2020, 1243 . 1246 [I-D.ietf-core-groupcomm-bis] 1247 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1248 for the Constrained Application Protocol (CoAP)", Work in 1249 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 1250 04, 12 July 2021, . 1253 [I-D.ietf-core-oscore-groupcomm] 1254 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 1255 and J. Park, "Group OSCORE - Secure Group Communication 1256 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 1257 core-oscore-groupcomm-12, 12 July 2021, 1258 . 1261 [I-D.ietf-core-resource-directory] 1262 Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P. 1263 V. D. Stok, "CoRE Resource Directory", Work in Progress, 1264 Internet-Draft, draft-ietf-core-resource-directory-28, 7 1265 March 2021, . 1268 [I-D.ietf-cose-rfc8152bis-algs] 1269 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1270 Initial Algorithms", Work in Progress, Internet-Draft, 1271 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 1272 . 1275 [I-D.ietf-cose-rfc8152bis-struct] 1276 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1277 Structures and Process", Work in Progress, Internet-Draft, 1278 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 1279 . 1282 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1283 Requirement Levels", BCP 14, RFC 2119, 1284 DOI 10.17487/RFC2119, March 1997, 1285 . 1287 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1288 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1289 . 1291 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1292 Application Protocol (CoAP)", RFC 7252, 1293 DOI 10.17487/RFC7252, June 2014, 1294 . 1296 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1297 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1298 May 2017, . 1300 8.2. Informative References 1302 [Fairhair] FairHair Alliance, "Security Architecture for the Internet 1303 of Things (IoT) in Commercial Buildings", White Paper, ed. 1304 Piotr Polak , March 2018, . 1308 [I-D.hartke-t2trg-coral-reef] 1309 Hartke, K., "Resource Discovery in Constrained RESTful 1310 Environments (CoRE) using the Constrained RESTful 1311 Application Language (CoRAL)", Work in Progress, Internet- 1312 Draft, draft-hartke-t2trg-coral-reef-04, 9 May 2020, 1313 . 1316 [I-D.ietf-ace-key-groupcomm] 1317 Palombini, F. and M. Tiloca, "Key Provisioning for Group 1318 Communication using ACE", Work in Progress, Internet- 1319 Draft, draft-ietf-ace-key-groupcomm-13, 12 July 2021, 1320 . 1323 [I-D.ietf-ace-key-groupcomm-oscore] 1324 Tiloca, M., Park, J., and F. Palombini, "Key Management 1325 for OSCORE Groups in ACE", Work in Progress, Internet- 1326 Draft, draft-ietf-ace-key-groupcomm-oscore-11, 12 July 1327 2021, . 1330 [I-D.ietf-ace-oauth-authz] 1331 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1332 H. Tschofenig, "Authentication and Authorization for 1333 Constrained Environments (ACE) using the OAuth 2.0 1334 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 1335 draft-ietf-ace-oauth-authz-43, 10 July 2021, 1336 . 1339 [I-D.ietf-ace-oscore-gm-admin] 1340 Tiloca, M., Hoeglund, R., Stok, P. V. D., Palombini, F., 1341 and K. Hartke, "Admin Interface for the OSCORE Group 1342 Manager", Work in Progress, Internet-Draft, draft-ietf- 1343 ace-oscore-gm-admin-03, 12 July 2021, 1344 . 1347 [I-D.ietf-cose-cbor-encoded-cert] 1348 Raza, S., Hoeglund, J., Selander, G., Mattsson, J. P., 1349 and M. Furuhed, "CBOR Encoded X.509 Certificates (C509 1350 Certificates)", Work in Progress, Internet-Draft, draft- 1351 ietf-cose-cbor-encoded-cert-01, 25 May 2021, 1352 . 1355 [I-D.ietf-rats-uccs] 1356 Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C. 1357 Bormann, "A CBOR Tag for Unprotected CWT Claims Sets", 1358 Work in Progress, Internet-Draft, draft-ietf-rats-uccs-00, 1359 19 May 2021, . 1362 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1363 Constrained-Node Networks", RFC 7228, 1364 DOI 10.17487/RFC7228, May 2014, 1365 . 1367 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1368 Application Protocol (CoAP)", RFC 7641, 1369 DOI 10.17487/RFC7641, September 2015, 1370 . 1372 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 1373 Security (TLS) / Datagram Transport Layer Security (DTLS) 1374 Profiles for the Internet of Things", RFC 7925, 1375 DOI 10.17487/RFC7925, July 2016, 1376 . 1378 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 1379 FETCH Methods for the Constrained Application Protocol 1380 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 1381 . 1383 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1384 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1385 May 2018, . 1387 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1388 "Object Security for Constrained RESTful Environments 1389 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1390 . 1392 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 1393 and K. Watsen, "Bootstrapping Remote Secure Key 1394 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 1395 May 2021, . 1397 Appendix A. Use Case Example With Full Discovery (CoRAL) 1399 This section provides the same use case example of Section 5, but 1400 specified in CoRAL [I-D.ietf-core-coral]. 1402 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1404 The CT defines the application group "grp_R2-4-015", with resource 1405 /light and base address [ff05::5:1], as follows. 1407 Request: CT -> RD 1408 Req: POST coap://[2001:db8:4::ff]/rd 1409 Content-Format: TBD123456 (application/coral+cbor) 1411 Payload: 1412 #using reef = 1414 #base 1415 reef:ep "grp_R2-4-015" 1416 reef:et "core.rd-group" 1417 reef:rd-item { 1418 reef:rt "oic.d.light" 1419 } 1421 Response: RD -> CT 1423 Res: 2.01 Created 1424 Location-Path: /rd/501 1426 Also, the CT defines a second application group "grp_schedule", with 1427 resource /schedule and base address [ff05::5:2], as follows. 1429 Request: CT -> RD 1431 Req: POST coap://[2001:db8:4::ff]/rd?ep=grp_schedule&et=core.rd-group 1432 Content-Format: TBD123456 (application/coral+cbor) 1434 Payload: 1435 #using reef = 1437 #base 1438 reef:rd-item { 1439 reef:rt "oic.r.time.period" 1440 } 1442 Response: RD -> CT 1444 Res: 2.01 Created 1445 Location-Path: /rd/502 1447 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1449 Finally, the CT defines the corresponding security groups. In 1450 particular, assuming a Group Manager responsible for both security 1451 groups and with address [2001:db8::ab], the CT specifies: 1453 Request: CT -> RD 1454 Req: POST coap://[2001:db8:4::ff]/rd?ep=gm1 1455 Content-Format: TBD123456 (application/coral+cbor) 1457 Payload: 1458 #using 1459 #using reef = 1461 #base 1462 reef:rd-item { 1463 reef:ct 65000 1464 reef:ct 41 1465 reef:rt "core.osc.gm" 1466 reef:if "ace.group" 1467 sec-gp "feedca570000" 1468 app-gp "grp_R2-4-015" 1469 } 1470 reef:rd-item { 1471 reef:ct 65000 1472 reef:ct 41 1473 reef:rt "core.osc.gm" 1474 reef:if "ace.group" 1475 sec-gp "feedsc590000" 1476 app-gp "grp_schedule" 1477 } 1479 Response: RD -> CT 1481 Res: 2.01 Created 1482 Location-Path: /rd/4521 1484 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1486 The device with IP address [2001:db8:4::x] can retrieve the multicast 1487 IP address of the CoAP group used by the application group 1488 "grp_R2-4-015", by performing an endpoint lookup as shown below. 1490 Request: Joining node -> RD 1492 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 1493 ?et=core.rd-group&ep=grp_R2-4-015 1495 Response: RD -> Joining node 1496 Res: 2.05 Content 1497 Content-Format: TBD123456 (application/coral+cbor) 1499 Payload: 1500 #using reef = 1502 #base 1503 reef:rd-unit <501> { 1504 reef:ep "grp_R2-4-015" 1505 reef:et "core.rd-group" 1506 reef:base 1507 reef:rt "core.rd-ep" 1508 } 1510 Similarly, to retrieve the multicast IP address of the CoAP group 1511 used by the application group "grp_schedule", the device performs an 1512 endpoint lookup as shown below. 1514 Request: Joining node -> RD 1516 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 1517 ?et=core.rd-group&ep=grp_schedule 1519 Response: RD -> Joining node 1521 Res: 2.05 Content 1522 Content-Format: TBD123456 (application/coral+cbor) 1524 Payload: 1525 #using reef = 1527 #base 1528 reef:rd-unit <502> { 1529 reef:ep "grp_schedule" 1530 reef:et "core.rd-group" 1531 reef:base 1532 reef:rt "core.rd-ep" 1533 } 1535 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1537 Consequently, the device learns the security groups it has to join. 1538 In particular, it does the following for app-gp="grp_R2-4-015". 1540 Request: Joining node -> RD 1542 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 1543 ?rt=core.osc.gm&app-gp=grp_R2-4-015 1545 Response: RD -> Joining Node 1547 Res: 2.05 Content 1548 Content-Format: TBD123456 (application/coral+cbor) 1550 Payload: 1551 #using 1552 #using reef = 1554 #base 1555 reef:rd-item { 1556 reef:ct 65000 1557 reef:rt "core.osc.gm" 1558 reef:if "ace.group" 1559 sec-gp "feedca570000" 1560 app-gp "grp_R2-4-015" 1561 } 1563 Similarly, the device does the following for app-gp="grp_schedule". 1565 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 1566 ?rt=core.osc.gm&app-gp=grp_schedule 1568 Response: RD -> Joining Node 1570 Res: 2.05 Content 1571 Content-Format: TBD123456 (application/coral+cbor) 1573 Payload: 1574 #using 1575 #using reef = 1577 #base 1578 reef:rd-item { 1579 reef:ct 65000 1580 reef:rt "core.osc.gm" 1581 reef:if "ace.group" 1582 sec-gp "feedsc590000" 1583 app-gp "grp_schedule" 1584 } 1586 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1588 After this last discovery step, the device can ask permission to join 1589 the security groups, and effectively join them through the Group 1590 Manager, e.g., according to [I-D.ietf-ace-key-groupcomm-oscore]. 1592 Acknowledgments 1594 The authors sincerely thank Carsten Bormann, Klaus Hartke, Jaime 1595 Jimenez, Francesca Palombini, Dave Robin and Jim Schaad for their 1596 comments and feedback. 1598 The work on this document has been partly supported by VINNOVA and 1599 the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home 1600 (Grant agreement 952652); and by the EIT-Digital High Impact 1601 Initiative ACTIVE. 1603 Authors' Addresses 1605 Marco Tiloca 1606 RISE AB 1607 Isafjordsgatan 22 1608 SE-16440 Stockholm Kista 1609 Sweden 1611 Email: marco.tiloca@ri.se 1613 Christian Amsuess 1614 Hollandstr. 12/4 1615 1020 Vienna 1616 Austria 1618 Email: christian@amsuess.com 1620 Peter van der Stok 1621 Consultant 1623 Phone: +31-492474673 (Netherlands), +33-966015248 (France) 1624 Email: consultancy@vanderstok.org 1625 URI: www.vanderstok.org