idnits 2.17.1 draft-tiloca-core-oscore-discovery-08.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 (February 22, 2021) is 1160 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-03 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-11 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-26 ** 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-11 == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-10 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-37 == Outdated reference: A later version (-11) exists of draft-ietf-ace-oscore-gm-admin-02 Summary: 1 error (**), 0 flaws (~~), 10 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: August 26, 2021 6 P. van der Stok 7 Consultant 8 February 22, 2021 10 Discovery of OSCORE Groups with the CoRE Resource Directory 11 draft-tiloca-core-oscore-discovery-08 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 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 26, 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 66 2. Registration of Group Manager Endpoints . . . . . . . . . . . 6 67 2.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.2. Relation Link to Authorization Server . . . . . . . . . . 9 69 2.3. Registration Example . . . . . . . . . . . . . . . . . . 10 70 2.3.1. Example in Link Format . . . . . . . . . . . . . . . 10 71 2.3.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 11 72 3. Addition and Update of Security Groups . . . . . . . . . . . 11 73 3.1. Addition Example . . . . . . . . . . . . . . . . . . . . 12 74 3.1.1. Example in Link Format . . . . . . . . . . . . . . . 12 75 3.1.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 13 76 4. Discovery of Security Groups . . . . . . . . . . . . . . . . 15 77 4.1. Discovery Example #1 . . . . . . . . . . . . . . . . . . 16 78 4.1.1. Example in Link Format . . . . . . . . . . . . . . . 16 79 4.1.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 18 80 4.2. Discovery Example #2 . . . . . . . . . . . . . . . . . . 19 81 4.2.1. Example in Link Format . . . . . . . . . . . . . . . 19 82 4.2.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 20 83 5. Use Case Example With Full Discovery . . . . . . . . . . . . 21 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 25 88 8.2. Informative References . . . . . . . . . . . . . . . . . 27 89 Appendix A. Use Case Example With Full Discovery (CoRAL) . . . . 28 90 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 93 1. Introduction 95 The Constrained Application Protocol (CoAP) [RFC7252] supports group 96 communication over IP multicast [I-D.ietf-core-groupcomm-bis] to 97 improve efficiency and latency of communication and reduce bandwidth 98 requirements. A set of CoAP endpoints constitutes an application 99 group by sharing a common pool of resources, that can be efficiently 100 accessed through group communication. The members of an application 101 group may be members of a security group, thus sharing a common set 102 of keying material to secure group communication. 104 The security protocol Group Object Security for Constrained RESTful 105 Environments (Group OSCORE) [I-D.ietf-core-oscore-groupcomm] builds 106 on OSCORE [RFC8613] and protects CoAP messages end-to-end in group 107 communication contexts through CBOR Object Signing and Encryption 108 (COSE) 109 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs]. An 110 application group may rely on one or more security groups, and a same 111 security group may be used by multiple application groups at the same 112 time. 114 A CoAP endpoint relies on a Group Manager (GM) to join a security 115 group and get the group keying material. The joining process in 116 [I-D.ietf-ace-key-groupcomm-oscore] is based on the ACE framework for 117 Authentication and Authorization in constrained environments 118 [I-D.ietf-ace-oauth-authz], with the joining endpoint and the GM 119 acting as ACE Client and Resource Server, respectively. That is, the 120 joining endpoint accesses the group-membership resource exported by 121 the GM and associated with the security group to join. 123 Typically, devices store a static X509 IDevID certificate installed 124 at manufacturing time [I-D.ietf-anima-bootstrapping-keyinfra]. This 125 is used at deployment time during an enrollment process that provides 126 the devices with an Operational Certificate, possibly updated during 127 the device lifetime. Operational Certificates may specify 128 information to join security groups, especially a reference to the 129 group-membership resources to access at the respective GMs. 131 However, it is usually impossible to provide such precise information 132 to freshly deployed devices, as part of their (early) Operational 133 Certificate. This can be due to a number of reasons: (1) the 134 security group(s) to join and the responsible GM(s) are generally 135 unknown at manufacturing time; (2) a security group of interest is 136 created, or the responsible GM is deployed, only after the device is 137 enrolled and fully operative in the network; (3) information related 138 to existing security groups or to their GMs has changed. This 139 requires a method for CoAP endpoints to dynamically discover security 140 groups and their GM, and to retrieve relevant information about 141 deployed groups. 143 To this end, CoAP endpoints can use descriptions and links of group- 144 membership resources at GMs, to discover security groups and retrieve 145 the information required for joining them. With the discovery 146 process of security groups expressed in terms of links to resources, 147 the remaining problem is the discovery of those links. The CoRE 148 Resource Directory (RD) [I-D.ietf-core-resource-directory] allows 149 such discovery in an efficient way, and it is expected to be used in 150 many setups that would benefit of security group discovery. 152 This specification builds on this approach and describes how CoAP 153 endpoints can use the RD to perform the link discovery steps, in 154 order to discover security groups and retrieve the information 155 required to join them through their GM. In short, the GM registers 156 as an endpoint with the RD. The resulting registration resource 157 includes one link per security group under that GM, specifying the 158 path to the related group-membership resource to access for joining 159 that group. 161 Additional descriptive information about the security group is stored 162 with the registered link. In a RD based on Link Format [RFC6690] as 163 defined in [I-D.ietf-core-resource-directory], this information is 164 specified as target attributes of the registered link, and includes 165 the identifiers of the application groups which use that security 166 group. This enables a lookup of those application groups at the RD, 167 where they are separately announced by a Commissioning Tool (see 168 Appendix A of [I-D.ietf-core-resource-directory]). 170 When querying the RD for security groups, a CoAP endpoint can use 171 CoAP observation [RFC7641]. This results in automatic notifications 172 on the creation of new security groups or the update of existing 173 groups. Thus, it facilitates the early deployment of CoAP endpoints, 174 i.e. even before the GM is deployed and security groups are created. 176 Interaction examples are provided in Link Format, as well as in the 177 Constrained RESTful Application Language CoRAL [I-D.ietf-core-coral] 178 with reference to a CoRAL-based RD [I-D.hartke-t2trg-coral-reef]. 179 While all the CoRAL examples show the CoRAL textual serialization 180 format, its binary serialization format is used on the wire. 182 The approach in this document is consistent with, but not limited to, 183 the joining of security groups defined in 184 [I-D.ietf-ace-key-groupcomm-oscore]. 186 1.1. Terminology 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 190 "OPTIONAL" in this document are to be interpreted as described in BCP 191 14 [RFC2119] [RFC8174] when, and only when, they appear in all 192 capitals, as shown here. 194 This specification requires readers to be familiar with the terms and 195 concepts discussed in [I-D.ietf-core-resource-directory] and 196 [RFC6690], as well as in [I-D.ietf-core-coral]. Readers should also 197 be familiar with the terms and concepts discussed in 198 [RFC7252][I-D.ietf-core-groupcomm-bis], 199 [I-D.ietf-core-oscore-groupcomm] and 200 [I-D.ietf-ace-key-groupcomm-oscore]. 202 Terminology for constrained environments, such as "constrained 203 device" and "constrained-node network", is defined in [RFC7228]. 205 Consistently with the definitions from Section 2.1 of 206 [I-D.ietf-core-groupcomm-bis], this document also refers to the 207 following terminology. 209 o CoAP group: a set of CoAP endpoints all configured to receive CoAP 210 multicast messages sent to the group's associated IP multicast 211 address and UDP port. An endpoint may be a member of multiple 212 CoAP groups by subscribing to multiple IP multicast addresses. 214 o Security group: a set of CoAP endpoints that share the same 215 security material, and use it to protect and verify exchanged 216 messages. A CoAP endpoint may be a member of multiple security 217 groups. There can be a one-to-one or a one-to-many relation 218 between security groups and CoAP groups. 220 This document especially considers a security group to be an 221 OSCORE group, where all members share one OSCORE Security Context 222 to protect group communication with Group OSCORE 223 [I-D.ietf-core-oscore-groupcomm]. However, the approach defined 224 in this document can be used to support the discovery of different 225 security groups than OSCORE groups. 227 o Application group: a set of CoAP endpoints that share a common set 228 of resources. An endpoint may be a member of multiple application 229 groups. An application group can be associated with one or more 230 security groups, and multiple application groups can use the same 231 security group. Application groups are announced in the RD by a 232 Commissioning Tool, according to the RD-Groups usage pattern (see 233 Appendix A of [I-D.ietf-core-resource-directory]). 235 2. Registration of Group Manager Endpoints 237 During deployment, a Group Manager (GM) can find the CoRE Resource 238 Directory (RD) as described in Section 4 of 239 [I-D.ietf-core-resource-directory]. 241 Afterwards, the GM registers as an endpoint with the RD, as described 242 in Section 5 of [I-D.ietf-core-resource-directory]. The GM SHOULD 243 NOT use the Simple Registration approach described in Section 5.1 of 244 [I-D.ietf-core-resource-directory]. 246 When registering with the RD, the GM also registers the links to all 247 the group-membership resources it has at that point in time, i.e. one 248 for each of its security groups. 250 In the registration request, each link to a group-membership resource 251 has as target the URI of that resource at the GM. Also, it specifies 252 a number of descriptive parameters as defined in Section 2.1. 254 2.1. Parameters 256 For each registered link to a group-membership resource at a GM, the 257 following parameters are specified together with the link. 259 In the RD defined in [I-D.ietf-core-resource-directory] and based on 260 Link Format, each parameter is specified in a target attribute with 261 the same name. 263 In a RD based on CoRAL, such as the one defined in 264 [I-D.hartke-t2trg-coral-reef], each parameter is specified in a 265 nested element with the same name. 267 o 'ct', specifying the content format used with the group-membership 268 resource at the Group Manager, with value "application/ace- 269 groupcomm+cbor" registered in Section 8.2 of 270 [I-D.ietf-ace-key-groupcomm]. 272 Note: The examples in this document use the provisional value 273 65000 from the range "Reserved for Experimental Use" of the "CoAP 274 Content-Formats" registry, within the "CoRE Parameters" registry. 276 o 'rt', specifying the resource type of the group-membership 277 resource at the Group Manager, with value "core.osc.gm" registered 278 in Section 21.11 of [I-D.ietf-ace-key-groupcomm-oscore]. 280 o 'if', specifying the interface description for accessing the 281 group-membership resource at the Group Manager, with value 282 "ace.group" registered in Section 8.10 of 283 [I-D.ietf-ace-key-groupcomm]. 285 o 'sec-gp', specifying the name of the security group of interest, 286 as a stable and invariant identifier, such as the group name used 287 in [I-D.ietf-ace-key-groupcomm-oscore]. This parameter MUST 288 specify a single value. 290 o 'app-gp', specifying the name(s) of the application group(s) 291 associated to the security group of interest indicated by 'sec- 292 gp'. This parameter MUST occur once for each application group, 293 and MUST specify only a single application group. 295 When a security group is created at the GM, the names of the 296 application groups using it are also specified as part of the 297 security group configuration (see [I-D.ietf-ace-oscore-gm-admin]). 298 Thus, when registering the links to its group-membership resource, 299 the GM is aware of the application groups and their names. 301 If a different entity than the GM registers the security groups to 302 the RD, e.g. a Commissioning Tool, this entity has to also be 303 aware of the application groups and their names to specify. To 304 this end, it can obtain them from the GM or from the Administator 305 that created the security groups at the GM (see 306 [I-D.ietf-ace-oscore-gm-admin]). 308 Optionally, the following parameters can also be specified. If Link 309 Format is used, the value of each of these parameters is encoded as a 310 text string. 312 o 'alg', specifying the AEAD algorithm used in the security group. 313 If present, this parameter MUST specify a single value, which is 314 taken from the 'Value' column of the "COSE Algorithms" Registry 315 [COSE.Algorithms]. 317 o 'hkdf', specifying the HKDF algorithm used in the security group. 318 If present, this parameter MUST specify a single value, which is 319 taken from the 'Value' column of the "COSE Algorithms" Registry 320 defined in [COSE.Algorithms]. 322 o 'cs_alg', specifying the algorithm used to countersign messages in 323 the security group. If present, this parameter MUST specify a 324 single value, which is taken from the 'Value' column of the "COSE 325 Algorithms" Registry [COSE.Algorithms]. 327 o 'cs_alg_crv', specifying the elliptic curve (if applicable) for 328 the algorithm used to countersign messages in the security group. 329 If present, this parameter MUST specify a single value, which is 330 taken from the 'Value' column of the "COSE Elliptic Curves" 331 Registry [COSE.Elliptic.Curves]. 333 o 'cs_key_kty', specifying the key type of countersignature keys 334 used to countersign messages in the security group. If present, 335 this parameter MUST specify a single value, which is taken from 336 the 'Value' column of the "COSE Key Types" Registry 337 [COSE.Key.Types]. 339 o 'cs_key_crv', specifying the elliptic curve (if applicable) of 340 countersignature keys used to countersign messages in the security 341 group. If present, this parameter MUST specify a single value, 342 which is taken from the 'Value' column of the "COSE Elliptic 343 Curves" Registry defined in [COSE.Elliptic.Curves]. 345 o 'cs_kenc', specifying the encoding of the public keys used in the 346 security group. If present, this parameter MUST specify a single 347 value. This specification explicitly admits the signaling of COSE 348 Keys [I-D.ietf-cose-rfc8152bis-struct] as encoding for public 349 keys, which is indicated with "1", as taken from the 'Confirmation 350 Key' column of the "CWT Confirmation Method" Registry defined in 351 [RFC8747]. Future specifications may define additional values for 352 this parameter. 354 o 'ecdh_alg', specifying the ECDH algorithm used to derive pairwise 355 encryption keys in the security group, e.g. as for the pairwise 356 mode of Group OSCORE (see Section 2.3 of 357 [I-D.ietf-core-oscore-groupcomm]). If present, this parameter 358 MUST specify a single value, which is taken from the 'Value' 359 column of the "COSE Algorithms" Registry [COSE.Algorithms]. 361 o 'ecdh_alg_crv', specifying the elliptic curve for the ECDH 362 algorithm used to derive pairwise encryption keys in the security 363 group. If present, this parameter MUST specify a single value, 364 which is taken from the 'Value' column of the "COSE Elliptic 365 Curves" Registry [COSE.Elliptic.Curves]. 367 o 'ecdh_key_kty', specifying the key type of keys used with an ECDH 368 algorithm to derive pairwise encryption keys in the security 369 group. If present, this parameter MUST specify a single value, 370 which is taken from the 'Value' column of the "COSE Key Types" 371 Registry [COSE.Key.Types]. 373 o 'ecdh_key_crv', specifying the elliptic curve of keys used with an 374 ECDH algorithm to derive pairwise encryption keys in the security 375 group. If present, this parameter MUST specify a single value, 376 which is taken from the 'Value' column of the "COSE Elliptic 377 Curves" Registry defined in [COSE.Elliptic.Curves]. 379 Note that the values registered in the COSE Registries 380 [COSE.Algorithms][COSE.Elliptic.Curves][COSE.Key.Types] are strongly 381 typed. On the contrary, Link Format is weakly typed and thus does 382 not distinguish between, for instance, the string value "-10" and the 383 integer value -10. 385 Thus, in RDs that return responses in Link Format, string values 386 which look like an integer are not supported. Therefore, such values 387 MUST NOT be advertised through the corresponding parameters above. 389 A CoAP endpoint that queries the RD to discover security groups and 390 their group-membership resource to access (see Section 4) would 391 benefit from the information above as follows. 393 o The values of 'cs_alg', 'cs_alg_crv', 'cs_key_kty', 'cs_key_crv', 394 'cs_kenc', 'ecdh_alg', 'ecdh_alg_crv', 'ecdh_key_kty' and 395 'ecdh_key_crv' related to a group-membership resource provide an 396 early knowledge of the format and encoding of public keys used in 397 the security group. Thus, the CoAP endpoint does not need to ask 398 the GM for this information as a preliminary step before the 399 joining process, or to perform a trial-and-error joining exchange 400 with the GM. Hence, the CoAP endpoint is able to provide the GM 401 with its own public key in the correct expected format and 402 encoding at the very first step of the joining process. 404 o The values of 'alg', 'hkdf', 'cs_alg' and 'ecdh_alg' related to a 405 group-membership resource provide an early knowledge of the 406 algorithms used in the security group. Thus, the CoAP endpoint is 407 able to decide whether to actually proceed with the joining 408 process, depending on its support for the indicated algorithms. 410 2.2. Relation Link to Authorization Server 412 For each registered link to a group-membership resource, the GM MAY 413 additionally specify the link to the ACE Authorization Server (AS) 414 [I-D.ietf-ace-oauth-authz] associated to the GM, and issuing 415 authorization credentials to join the security group as described in 416 [I-D.ietf-ace-key-groupcomm-oscore]. 418 The link to the AS has as target the URI of the resource where to 419 send an authorization request to. 421 In the RD defined in [I-D.ietf-core-resource-directory] and based on 422 Link Format, the link to the AS is separately registered with the RD, 423 and includes the following parameters as target attributes. 425 o 'rel', with value "authorization_server". 427 o 'anchor', with value the target of the link to the group- 428 membership resource at the GM. 430 In a RD based on CoRAL, such as the one defined in 431 [I-D.hartke-t2trg-coral-reef], this is mapped (as describe there) to 432 a link from the registration resource to the AS, using the 433 link 434 relation type. 436 2.3. Registration Example 438 The example below shows a GM with endpoint name "gm1" and address 439 2001:db8::ab that registers with the RD. 441 The GM specifies the value of the 'sec-gp' parameter for accessing 442 the security group with name "feedca570000", and used by the 443 application group with name "group1" specified with the value of the 444 'app-gp' parameter. 446 The countersignature algorithm used in the security group is EdDSA 447 (-8), with elliptic curve Ed25519 (6). Public keys used in the 448 security group are encoded as COSE Keys (1) 449 [I-D.ietf-cose-rfc8152bis-struct]. The ECDH algorithm used in the 450 security group is ECDH-SS + HKDF-256 (-27), with elliptic curve 451 X25519 (4). 453 In addition, the GM specifies the link to the ACE Authorization 454 Server associated to the GM, to which a CoAP endpoint should send an 455 Authorization Request for joining the corresponding security group 456 (see [I-D.ietf-ace-key-groupcomm-oscore]). 458 2.3.1. Example in Link Format 460 Request: GM -> RD 462 Req: POST coap://rd.example.com/rd?ep=gm1 463 Content-Format: 40 464 Payload: 465 ;ct=65000;rt="core.osc.gm";if="ace.group"; 466 sec-gp="feedca570000";app-gp="group1"; 467 cs_alg="-8";cs_alg_crv="6"; 468 cs_kenc="1";ecdh_alg="-27"; 469 ecdh_alg_crv="4", 470 ; 471 rel="authorization-server"; 472 anchor="coap://[2001:db8::ab]/ace-group/feedca570000" 474 Response: RD -> GM 475 Res: 2.01 Created 476 Location-Path: /rd/4521 478 2.3.2. Example in CoRAL 480 Request: GM -> RD 482 Req: POST coap://rd.example.com/rd?ep=gm1 483 Content-Format: TBD123456 (application/coral+cbor) 485 Payload: 486 #using 487 #using reef = 488 #using iana = 490 #base 491 reef:rd-item { 492 reef:ct 65000 493 reef:rt "core.osc.gm" 494 reef:if "ace.group" 495 sec-gp "feedca570000" 496 app-gp "group1" 497 cs_alg -8 498 cs_alg_crv 6 499 cs_kenc 1 500 ecdh_alg -27 501 ecdh_alg_crv 4 502 iana:authorization-server 503 } 505 Response: RD -> GM 507 Res: 2.01 Created 508 Location-Path: /rd/4521 510 3. Addition and Update of Security Groups 512 The GM is responsible to refresh the registration of all its group- 513 membership resources in the RD. This means that the GM has to update 514 the registration within its lifetime as per Section 5.3.1 of 515 [I-D.ietf-core-resource-directory], and has to change the content of 516 the registration when a group-membership resource is added/removed, 517 or if its parameters have to be changed, such as in the following 518 cases. 520 o The GM creates a new security group and starts exporting the 521 related group-membership resource. 523 o The GM dismisses a security group and stops exporting the related 524 group-membership resource. 526 o Information related to an existing security group changes, e.g. 527 the list of associated application groups. 529 To perform an update of its registrations, the GM can re-register 530 with the RD and fully specify all links to its group-membership 531 resources. 533 Alternatively, the GM can perform a PATCH/iPATCH [RFC8132] request to 534 the RD, as per Section 5.3.3 of [I-D.ietf-core-resource-directory]. 535 This requires new media-types to be defined in future standards, to 536 apply a new document as a patch to an existing stored document. 538 3.1. Addition Example 540 The example below shows how the GM from Section 2 re-registers with 541 the RD. When doing so, it specifies: 543 o The same previous group-membership resource associated to the 544 security group with name "feedca570000". 546 o An additional group-membership resource associated to the security 547 group with name "ech0ech00000" and used by the application group 548 "group2". 550 o A third group-membership resource associated with the security 551 group with name "abcdef120000" and used by two application groups, 552 namely "group3" and "group4". 554 Furthermore, the GM relates the same Authorization Server also to the 555 security groups "ech0ech00000" and "abcdef120000". 557 3.1.1. Example in Link Format 559 Request: GM -> RD 560 Req: POST coap://rd.example.com/rd?ep=gm1 561 Content-Format: 40 562 Payload: 563 ;ct=65000;rt="core.osc.gm";if="ace.group"; 564 sec-gp="feedca570000";app-gp="group1"; 565 cs_alg="-8";cs_alg_crv="6"; 566 cs_kenc="1";ecdh_alg="-27"; 567 ecdh_alg_crv="4", 568 ;ct=65000;rt="core.osc.gm";if="ace.group"; 569 sec-gp="ech0ech00000";app-gp="group2"; 570 cs_alg="-8";cs_alg_crv="6"; 571 cs_kenc="1";ecdh_alg="-27"; 572 ecdh_alg_crv="4", 573 ;ct=65000;rt="core.osc.gm";if="ace.group"; 574 sec-gp="abcdef120000";app-gp="group3"; 575 app-gp="group4";cs_alg="-8"; 576 cs_alg_crv="6";cs_kenc="1"; 577 ecdh_alg="-27";ecdh_alg_crv="4", 578 ; 579 rel="authorization-server"; 580 anchor="coap://[2001:db8::ab]/ace-group/feedca570000", 581 ; 582 rel="authorization-server"; 583 anchor="coap://[2001:db8::ab]/ace-group/ech0ech00000", 584 ; 585 rel="authorization-server"; 586 anchor="coap://[2001:db8::ab]/ace-group/abcdef120000" 588 Response: RD -> GM 590 Res: 2.04 Changed 591 Location-Path: /rd/4521 593 3.1.2. Example in CoRAL 595 Request: GM -> RD 597 Req: POST coap://rd.example.com/rd?ep=gm1 598 Content-Format: TBD123456 (application/coral+cbor) 600 Payload: 601 #using 602 #using reef = 603 #using iana = 605 #base 606 reef:rd-item { 607 reef:ct 65000 608 reef:rt "core.osc.gm" 609 reef:if "ace.group" 610 sec-gp "feedca570000" 611 app-gp "group1" 612 cs_alg -8 613 cs_alg_crv 6 614 cs_kenc 1 615 ecdh_alg -27 616 ecdh_alg_crv 4 617 iana:authorization-server 618 } 619 reef:rd-item { 620 reef:ct 65000 621 reef:rt "core.osc.gm" 622 reef:if "ace.group" 623 sec-gp "ech0ech00000" 624 app-gp "group2" 625 cs_alg -8 626 cs_alg_crv 6 627 cs_kenc 1 628 ecdh_alg -27 629 ecdh_alg_crv 4 630 iana:authorization-server 631 } 632 reef:rd-item { 633 reef:ct 65000 634 reef:rt "core.osc.gm" 635 reef:if "ace.group" 636 sec-gp "abcdef120000" 637 app-gp "group3" 638 app-gp "group4" 639 cs_alg -8 640 cs_alg_crv 6 641 cs_kenc 1 642 ecdh_alg -27 643 ecdh_alg_crv 4 644 iana:authorization-server 645 } 647 Response: RD -> GM 649 Res: 2.04 Changed 650 Location-Path: /rd/4521 652 4. Discovery of Security Groups 654 A CoAP endpoint that wants to join a security group, hereafter called 655 the joining node, might not have all the necessary information at 656 deployment time. Also, it might want to know about possible new 657 security groups created afterwards by the respective Group Managers. 659 To this end, the joining node can perform a resource lookup at the RD 660 as per Section 6.1 of [I-D.ietf-core-resource-directory], to retrieve 661 the missing pieces of information needed to join the security 662 group(s) of interest. The joining node can find the RD as described 663 in Section 4 of [I-D.ietf-core-resource-directory]. 665 The joining node uses the following parameter value for the lookup 666 filtering. 668 o 'rt' = "core.osc.gm", specifying the resource type of the group- 669 membership resource at the Group Manager, with value "core.osc.gm" 670 registered in Section 21.11 of 671 [I-D.ietf-ace-key-groupcomm-oscore]. 673 The joining node may additionally consider the following parameters 674 for the lookup filtering, depending on the information it has already 675 available. 677 o 'sec-gp', specifying the name of the security group of interest. 678 This parameter MUST specify a single value. 680 o 'ep', specifying the registered endpoint of the GM. 682 o 'app-gp', specifying the name(s) of the application group(s) 683 associated with the security group of interest. This parameter 684 MAY be included multiple times, and each occurrence MUST specify 685 the name of one application group. 687 o 'if', specifying the interface description for accessing the 688 group-membership resource at the Group Manager, with value 689 "ace.group" registered in Section 8.10 of 690 [I-D.ietf-ace-key-groupcomm]. 692 The response from the RD may include links to a group-membership 693 resource specifying multiple application groups, as all using the 694 same security group. In this case, the joining node is already 695 expected to know the exact application group of interest. 697 Furthermore, the response from the RD may include the links to 698 different group-membership resources, all specifying a same 699 application group of interest for the joining node, if the 700 corresponding security groups are all used by that application group. 702 In this case, application policies on the joining node should define 703 how to determine the exact security group to join (see Section 2.1 of 704 [I-D.ietf-core-groupcomm-bis]). For example, different security 705 groups can reflect different security algorithms to use. Hence, a 706 client application can take into account what the joining node 707 supports and prefers, when selecting one particular security group 708 among the indicated ones, while a server application would need to 709 join all of them. Later on, the joining node will be anyway able to 710 join only security groups for which it is actually authorized to be a 711 member (see [I-D.ietf-ace-key-groupcomm-oscore]). 713 Note that, with RD-based discovery, including the 'app-gp' parameter 714 multiple times would result in finding only the group-membership 715 resource that serves all the specified application groups, i.e. not 716 any group-membership resource that serves either. Therefore, a 717 joining node needs to perform N separate queries with different 718 values for 'app-gp', in order to safely discover the (different) 719 group-membership resource(s) serving the N application groups. 721 The discovery of security groups as defined in this document is 722 applicable and useful to other CoAP endpoints than the actual joining 723 nodes. In particular, other entities can be interested to discover 724 and interact with the group-membership resource at the Group Manager. 725 These include entities acting as signature checkers, e.g. 726 intermediary gateways, that do not join a security group, but can 727 retrieve public keys of group members from the Group Manager, in 728 order to verify counter signatures of group messages (see Section 3 729 of [I-D.ietf-core-oscore-groupcomm]). 731 4.1. Discovery Example #1 733 Consistently with the examples in Section 2 and Section 3, the 734 examples below consider a joining node that wants to join the 735 security group associated with the application group "group1", but 736 that does not know the name of the security group, the responsible GM 737 and the group-membership resource to access. 739 4.1.1. Example in Link Format 741 Request: Joining node -> RD 743 Req: GET coap://rd.example.com/rd-lookup/res 744 ?rt=core.osc.gm&app-gp=group1 746 Response: RD -> Joining node 747 Res: 2.05 Content 748 Payload: 749 ;ct=65000; 750 rt="core.osc.gm";if="ace.group";sec-gp="feedca570000"; 751 app-gp="group1";cs_alg="-8";cs_alg_crv="6"; 752 cs_kenc="1";ecdh_alg="-27";ecdh_alg_crv="4"; 753 anchor="coap://[2001:db8::ab]" 755 By performing the separate resource lookup below, the joining node 756 can retrieve the link to the ACE Authorization Server associated to 757 the GM, where to send an Authorization Request for joining the 758 corresponding security group (see 759 [I-D.ietf-ace-key-groupcomm-oscore]). 761 Request: Joining node -> RD 763 Req: GET coap://rd.example.com/rd-lookup/res 764 ?rel=authorization-server& 765 anchor=coap://[2001:db8::ab]/ace-group/feedca570000 767 Response: RD -> Joining node 769 Res: 2.05 Content 770 Payload: 771 773 To retrieve the multicast IP address of the CoAP group used by the 774 application group "group1", the joining node performs an endpoint 775 lookup as shown below. The following assumes that the application 776 group "group1" had been previously registered as per Appendix A of 777 [I-D.ietf-core-resource-directory], with ff35:30:2001:db8::23 as 778 multicast IP address of the associated CoAP group. 780 Request: Joining node -> RD 782 Req: GET coap://rd.example.com/rd-lookup/ep 783 ?et=core.rd-group&ep=group1 785 Response: RD -> Joining node 787 Res: 2.05 Content 788 Payload: 789 ;ep="group1";et="core.rd-group"; 790 base="coap://[ff35:30:2001:db8::23]";rt="core.rd-ep" 792 4.1.2. Example in CoRAL 794 Request: Joining node -> RD 796 Req: GET coap://rd.example.com/rd-lookup/res 797 ?rt=core.osc.gm&app-gp=group1 798 Accept: TBD123456 (application/coral+cbor) 800 Response: RD -> Joining node 802 Res: 2.05 Content 803 Content-Format: TBD123456 (application/coral+cbor) 805 Payload: 806 #using 807 #using reef = 808 #using iana = 810 #base 811 reef:rd-item { 812 reef:ct 65000 813 reef:rt "core.osc.gm" 814 reef:if "ace.group" 815 sec-gp "feedca570000" 816 app-gp "group1" 817 cs_alg -8 818 cs_alg_crv 6 819 cs_kenc 1 820 ecdh_alg -27 821 ecdh_alg_crv 4 822 iana:authorization-server 823 } 825 To retrieve the multicast IP address of the CoAP group used by the 826 application group "group1", the joining node performs an endpoint 827 lookup as shown below. The following assumes that the application 828 group "group1" had been previously registered, with 829 ff35:30:2001:db8::23 as multicast IP address of the associated CoAP 830 group. 832 Request: Joining node -> RD 834 Req: GET coap://rd.example.com/rd-lookup/ep 835 ?et=core.rd-group&ep=group1 836 Accept: TBD123456 (application/coral+cbor) 838 Response: RD -> Joining node 839 Res: 2.05 Content 840 Content-Format: TBD123456 (application/coral+cbor) 842 Payload: 843 #using 844 #using reef = 846 reef:rd-unit <./rd/501> { 847 reef:ep "group1" 848 reef:et "core.rd-group" 849 reef:base 850 reef:rt "core.rd-ep" 851 } 853 4.2. Discovery Example #2 855 Consistently with the examples in Section 2 and Section 3, the 856 examples below consider a joining node that wants to join the 857 security group with name "feedca570000", but that does not know the 858 responsible GM, the group-membership resource to access, and the 859 associated application groups. 861 The examples also show how the joining node uses CoAP observation 862 [RFC7641], in order to be notified of possible changes to the 863 parameters of the group-membership resource. This is also useful to 864 handle the case where the security group of interest has not been 865 created yet, so that the joining node can receive the requested 866 information when it becomes available. 868 4.2.1. Example in Link Format 870 Request: Joining node -> RD 872 Req: GET coap://rd.example.com/rd-lookup/res 873 ?rt=core.osc.gm&sec-gp=feedca570000 874 Observe: 0 876 Response: RD -> Joining node 878 Res: 2.05 Content 879 Observe: 24 880 Payload: 881 ;ct=65000; 882 rt="core.osc.gm";if="ace.group";sec-gp="feedca570000"; 883 app-gp="group1";cs_alg="-8";cs_alg_crv="6"; 884 cs_kenc="1";ecdh_alg="-27";ecdh_alg_crv="4"; 885 anchor="coap://[2001:db8::ab]" 887 Depending on the search criteria, the joining node performing the 888 resource lookup can get large responses. This can happen, for 889 instance, when the lookup request targets all the group-membership 890 resources at a specified GM, or all the group-membership resources of 891 all the registered GMs, as in the example below. 893 Request: Joining node -> RD 895 Req: GET coap://rd.example.com/rd-lookup/res?rt=core.osc.gm 897 Response: RD -> Joining node 899 Res: 2.05 Content 900 Payload: 901 ;ct=65000; 902 rt="core.osc.gm";if="ace.group";sec-gp="feedca570000"; 903 app-gp="group1";cs_alg="-8";cs_alg_crv="6"; 904 cs_kenc="1";ecdh_alg="-27";ecdh_alg_crv="4"; 905 anchor="coap://[2001:db8::ab]", 906 ;ct=65000; 907 rt="core.osc.gm";if="ace.group";sec-gp="ech0ech00000"; 908 app-gp="group2";cs_alg="-8";cs_alg_crv="6"; 909 cs_kenc="1";ecdh_alg="-27";ecdh_alg_crv="4"; 910 anchor="coap://[2001:db8::ab]", 911 ;ct=65000; 912 rt="core.osc.gm";if="ace.group";sec-gp="abcdef120000"; 913 app-gp="group3";app-gp="group4";cs_alg="-8";cs_alg_crv="6"; 914 cs_kenc="1";ecdh_alg="-27";ecdh_alg_crv="4"; 915 anchor="coap://[2001:db8::ab]" 917 Therefore, it is RECOMMENDED that a joining node which performs a 918 resource lookup with the CoAP Observe option specifies the value of 919 the parameter 'sec-gp' in its GET request sent to the RD. 921 4.2.2. Example in CoRAL 923 Request: Joining node -> RD 925 Req: GET coap://rd.example.com/rd-lookup/res 926 ?rt=core.osc.gm&sec-gp=feedca570000 927 Accept: TBD123456 (application/coral+cbor) 928 Observe: 0 930 Response: RD -> Joining node 931 Res: 2.05 Content 932 Observe: 24 933 Content-Format: TBD123456 (application/coral+cbor) 935 Payload: 936 #using 937 #using reef = 938 #using iana = 940 #base 941 reef:rd-item { 942 reef:ct 65000 943 reef:rt "core.osc.gm" 944 reef:if "ace.group" 945 sec-gp "feedca570000" 946 app-gp "group1" 947 cs_alg -8 948 cs_alg_crv 6 949 cs_kenc 1 950 ecdh_alg -27 951 ecdh_alg_crv 4 952 iana:authorization-server 953 } 955 5. Use Case Example With Full Discovery 957 In this section, the discovery of security groups is described to 958 support the installation process of a lighting installation in an 959 office building. The described process is a simplified version of 960 one of many processes. 962 The process described in this section is intended as an example and 963 does not have any particular ambition to serve as recommendation or 964 best practice to adopt. That is, it shows a possible workflow 965 involving a Commissioning Tool (CT) used in a certain way, while it 966 is not meant to prescribe how the workflow should necessarily be. 968 Assume the existence of four luminaires that are members of two 969 application groups. In the first application group, the four 970 luminaires receive presence messages and light intensity messages 971 from sensors or their proxy. In the second application group, the 972 four luminaires and several other pieces of equipment receive 973 building state schedules. 975 Each of the two application groups is associated to a different 976 security group and to a different CoAP group with its own dedicated 977 multicast IP address. 979 The Fairhair Alliance describes how a new device is accepted and 980 commissioned in the network [Fairhair], by means of its certificate 981 stored during the manufacturing process. When commissioning the new 982 device in the installation network, the new device gets a new 983 identity defined by a newly allocated certificate, following the 984 BRSKI specification. 986 Section 7.3 of [I-D.ietf-core-resource-directory] describes how the 987 CT assigns an endpoint name based on the CN field, (CN=ACME) and the 988 serial number of the certificate (serial number = 123x, with 3 < x < 989 8). Corresponding ep-names ACME-1234, ACME-1235, ACME-1236 and 990 ACME-1237 are also assumed. 992 It is common practice that locations in the building are specified 993 according to a coordinate system. After the acceptance of the 994 luminaires into the installation network, the coordinate of each 995 device is communicated to the CT. This can be done manually or 996 automatically. 998 The mapping between location and ep-name is calculated by the CT. 999 For instance, on the basis of grouping criteria, the CT assigns: i) 1000 application group "grp_R2-4-015" to the four luminaires; and ii) 1001 application group "grp_schedule" to all schedule requiring devices. 1002 Also, the device with ep name ACME-123x has been assigned IP address: 1003 [2001:db8:4::x]. The RD is assigned IP address: [2001:db8:4:ff]. 1004 The used multicast addresses are: [ff05::5:1] and [ff05::5:2]. 1006 The following assumes that each device is pre-configured with the 1007 name of the two application groups it belongs to. Additional 1008 mechanisms can be defined in the RD, for supporting devices to 1009 discover the application groups they belong to. 1011 Appendix A provides this same use case example in CoRAL. 1013 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1015 The CT defines the application group "grp_R2-4-015", with resource 1016 /light and base address [ff05::5:1], as follows. 1018 Request: CT -> RD 1020 Req: POST coap://[2001:db8:4::ff]/rd 1021 ?ep=grp_R2-4-015&et=core.rd-group&base=coap://[ff05::5:1] 1022 Content-Format: 40 1023 Payload: 1024 ;rt="oic.d.light" 1026 Response: RD -> CT 1027 Res: 2.01 Created 1028 Location-Path: /rd/501 1030 Also, the CT defines a second application group "grp_schedule", with 1031 resource /schedule and base address [ff05::5:2], as follows. 1033 Request: CT -> RD 1035 Req: POST coap://[2001:db8:4::ff]/rd 1036 ?ep=grp_schedule&et=core.rd-group&base=coap://[ff05::5:2] 1037 Content-Format: 40 1038 Payload: 1039 ;rt="oic.r.time.period" 1041 Response: RD -> CT 1043 Res: 2.01 Created 1044 Location-Path: /rd/502 1046 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1048 Finally, the CT defines the corresponding security groups. In 1049 particular, assuming a Group Manager responsible for both security 1050 groups and with address [2001:db8::ab], the CT specifies: 1052 Request: CT -> RD 1054 Req: POST coap://[2001:db8:4::ff]/rd 1055 ?ep=gm1&base=coap://[2001:db8::ab] 1056 Content-Format: 40 1057 Payload: 1058 ;ct=65000;rt="core.osc.gm";if="ace.group"; 1059 sec-gp="feedca570000"; 1060 app-gp="grp_R2-4-015", 1061 ;ct=65000;rt="core.osc.gm";if="ace.group"; 1062 sec-gp="feedsc590000"; 1063 app-gp="grp_schedule" 1065 Response: RD -> CT 1067 Res: 2.01 Created 1068 Location-Path: /rd/4521 1070 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1072 The device with IP address [2001:db8:4::x] can retrieve the multicast 1073 IP address of the CoAP group used by the application group 1074 "grp_R2-4-015", by performing an endpoint lookup as shown below. 1076 Request: Joining node -> RD 1078 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 1079 ?et=core.rd-group&ep=grp_R2-4-015 1081 Response: RD -> Joining node 1083 Res: 2.05 Content 1084 Content-Format: 40 1085 Payload: 1086 ;ep="grp_R2-4-015";et="core.rd-group"; 1087 base="coap://[ff05::5:1]";rt="core.rd-ep" 1089 Similarly, to retrieve the multicast IP address of the CoAP group 1090 used by the application group "grp_schedule", the device performs an 1091 endpoint lookup as shown below. 1093 Request: Joining node -> RD 1095 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 1096 ?et=core.rd-group&ep=grp_schedule 1098 Response: RD -> Joining node 1100 Res: 2.05 Content 1101 Content-Format: 40 1102 Payload: 1103 ;ep="grp_schedule";et="core.rd-group"; 1104 base="coap://[ff05::5:2]";rt="core.rd-ep" 1106 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1108 Consequently, the device learns the security groups it has to join. 1109 In particular, it does the following for app-gp="grp_R2-4-015". 1111 Request: Joining node -> RD 1113 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 1114 ?rt=core.osc.gm&app-gp=grp_R2-4-015 1116 Response: RD -> Joining Node 1118 Res: 2.05 Content 1119 Content-Format: 40 1120 Payload: 1121 ;ct=65000; 1122 rt="core.osc.gm";if="ace.group";sec-gp="feedca570000"; 1123 app-gp="grp_R2-4-015";anchor="coap://[2001:db8::ab]" 1125 Similarly, the device does the following for app-gp="grp_schedule". 1127 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 1128 ?rt=core.osc.gm&app-gp=grp_schedule 1130 Response: RD -> Joining Node 1132 Res: 2.05 Content 1133 Content-Format: 40 1134 Payload: 1135 ;ct=65000; 1136 rt="core.osc.gm";if="ace.group";sec-gp="feedsc590000"; 1137 app-gp="grp_schedule";anchor="coap://[2001:db8::ab]" 1139 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1141 After this last discovery step, the device can ask permission to join 1142 the security groups, and effectively join them through the Group 1143 Manager, e.g. according to [I-D.ietf-ace-key-groupcomm-oscore]. 1145 6. Security Considerations 1147 The security considerations as described in Section 8 of 1148 [I-D.ietf-core-resource-directory] apply here as well. 1150 7. IANA Considerations 1152 This document has no actions for IANA. 1154 8. References 1156 8.1. Normative References 1158 [COSE.Algorithms] 1159 IANA, "COSE Algorithms", 1160 . 1163 [COSE.Elliptic.Curves] 1164 IANA, "COSE Elliptic Curves", 1165 . 1168 [COSE.Key.Types] 1169 IANA, "COSE Key Types", 1170 . 1173 [I-D.ietf-core-coral] 1174 Hartke, K., "The Constrained RESTful Application Language 1175 (CoRAL)", draft-ietf-core-coral-03 (work in progress), 1176 March 2020. 1178 [I-D.ietf-core-groupcomm-bis] 1179 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1180 for the Constrained Application Protocol (CoAP)", draft- 1181 ietf-core-groupcomm-bis-03 (work in progress), February 1182 2021. 1184 [I-D.ietf-core-oscore-groupcomm] 1185 Tiloca, M., Selander, G., Palombini, F., Mattsson, J., and 1186 J. Park, "Group OSCORE - Secure Group Communication for 1187 CoAP", draft-ietf-core-oscore-groupcomm-11 (work in 1188 progress), February 2021. 1190 [I-D.ietf-core-resource-directory] 1191 Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P. 1192 Stok, "CoRE Resource Directory", draft-ietf-core-resource- 1193 directory-26 (work in progress), November 2020. 1195 [I-D.ietf-cose-rfc8152bis-algs] 1196 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1197 Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-12 1198 (work in progress), September 2020. 1200 [I-D.ietf-cose-rfc8152bis-struct] 1201 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1202 Structures and Process", draft-ietf-cose-rfc8152bis- 1203 struct-15 (work in progress), February 2021. 1205 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1206 Requirement Levels", BCP 14, RFC 2119, 1207 DOI 10.17487/RFC2119, March 1997, 1208 . 1210 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1211 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1212 . 1214 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1215 Application Protocol (CoAP)", RFC 7252, 1216 DOI 10.17487/RFC7252, June 2014, 1217 . 1219 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1220 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1221 May 2017, . 1223 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 1224 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 1225 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 1226 2020, . 1228 8.2. Informative References 1230 [Fairhair] 1231 FairHair Alliance, "Security Architecture for the Internet 1232 of Things (IoT) in Commercial Buildings", White Paper, ed. 1233 Piotr Polak , March 2018, . 1237 [I-D.hartke-t2trg-coral-reef] 1238 Hartke, K., "Resource Discovery in Constrained RESTful 1239 Environments (CoRE) using the Constrained RESTful 1240 Application Language (CoRAL)", draft-hartke-t2trg-coral- 1241 reef-04 (work in progress), May 2020. 1243 [I-D.ietf-ace-key-groupcomm] 1244 Palombini, F. and M. Tiloca, "Key Provisioning for Group 1245 Communication using ACE", draft-ietf-ace-key-groupcomm-11 1246 (work in progress), February 2021. 1248 [I-D.ietf-ace-key-groupcomm-oscore] 1249 Tiloca, M., Park, J., and F. Palombini, "Key Management 1250 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 1251 oscore-10 (work in progress), February 2021. 1253 [I-D.ietf-ace-oauth-authz] 1254 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1255 H. Tschofenig, "Authentication and Authorization for 1256 Constrained Environments (ACE) using the OAuth 2.0 1257 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-37 1258 (work in progress), February 2021. 1260 [I-D.ietf-ace-oscore-gm-admin] 1261 Tiloca, M., Hoeglund, R., Stok, P., Palombini, F., and K. 1262 Hartke, "Admin Interface for the OSCORE Group Manager", 1263 draft-ietf-ace-oscore-gm-admin-02 (work in progress), 1264 February 2021. 1266 [I-D.ietf-anima-bootstrapping-keyinfra] 1267 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 1268 and K. Watsen, "Bootstrapping Remote Secure Key 1269 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1270 keyinfra-45 (work in progress), November 2020. 1272 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1273 Constrained-Node Networks", RFC 7228, 1274 DOI 10.17487/RFC7228, May 2014, 1275 . 1277 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1278 Application Protocol (CoAP)", RFC 7641, 1279 DOI 10.17487/RFC7641, September 2015, 1280 . 1282 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 1283 FETCH Methods for the Constrained Application Protocol 1284 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 1285 . 1287 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1288 "Object Security for Constrained RESTful Environments 1289 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1290 . 1292 Appendix A. Use Case Example With Full Discovery (CoRAL) 1294 This section provides the same use case example of Section 5, but 1295 specified in CoRAL [I-D.ietf-core-coral]. 1297 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1299 The CT defines the application group "grp_R2-4-015", with resource 1300 /light and base address [ff05::5:1], as follows. 1302 Request: CT -> RD 1303 Req: POST coap://[2001:db8:4::ff]/rd 1304 Content-Format: TBD123456 (application/coral+cbor) 1306 Payload: 1307 #using reef = 1309 #base 1310 reef:ep "grp_R2-4-015" 1311 reef:et "core.rd-group" 1312 reef:rd-item { 1313 reef:rt "oic.d.light" 1314 } 1316 Response: RD -> CT 1318 Res: 2.01 Created 1319 Location-Path: /rd/501 1321 Also, the CT defines a second application group "grp_schedule", with 1322 resource /schedule and base address [ff05::5:2], as follows. 1324 Request: CT -> RD 1326 Req: POST coap://[2001:db8:4::ff]/rd?ep=grp_schedule&et=core.rd-group 1327 Content-Format: TBD123456 (application/coral+cbor) 1329 Payload: 1330 #using reef = 1332 #base 1333 reef:rd-item { 1334 reef:rt "oic.r.time.period" 1335 } 1337 Response: RD -> CT 1339 Res: 2.01 Created 1340 Location-Path: /rd/502 1342 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1344 Finally, the CT defines the corresponding security groups. In 1345 particular, assuming a Group Manager responsible for both security 1346 groups and with address [2001:db8::ab], the CT specifies: 1348 Request: CT -> RD 1349 Req: POST coap://[2001:db8:4::ff]/rd?ep=gm1 1350 Content-Format: TBD123456 (application/coral+cbor) 1352 Payload: 1353 #using 1354 #using reef = 1356 #base 1357 reef:rd-item { 1358 reef:ct 65000 1359 reef:ct 41 1360 reef:rt "core.osc.gm" 1361 reef:if "ace.group" 1362 sec-gp "feedca570000" 1363 app-gp "grp_R2-4-015" 1364 } 1365 reef:rd-item { 1366 reef:ct 65000 1367 reef:ct 41 1368 reef:rt "core.osc.gm" 1369 reef:if "ace.group" 1370 sec-gp "feedsc590000" 1371 app-gp "grp_schedule" 1372 } 1374 Response: RD -> CT 1376 Res: 2.01 Created 1377 Location-Path: /rd/4521 1379 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1381 The device with IP address [2001:db8:4::x] can retrieve the multicast 1382 IP address of the CoAP group used by the application group 1383 "grp_R2-4-015", by performing an endpoint lookup as shown below. 1385 Request: Joining node -> RD 1387 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 1388 ?et=core.rd-group&ep=grp_R2-4-015 1390 Response: RD -> Joining node 1391 Res: 2.05 Content 1392 Content-Format: TBD123456 (application/coral+cbor) 1394 Payload: 1395 #using reef = 1397 #base 1398 reef:rd-unit <501> { 1399 reef:ep "grp_R2-4-015" 1400 reef:et "core.rd-group" 1401 reef:base 1402 reef:rt "core.rd-ep" 1403 } 1405 Similarly, to retrieve the multicast IP address of the CoAP group 1406 used by the application group "grp_schedule", the device performs an 1407 endpoint lookup as shown below. 1409 Request: Joining node -> RD 1411 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 1412 ?et=core.rd-group&ep=grp_schedule 1414 Response: RD -> Joining node 1416 Res: 2.05 Content 1417 Content-Format: TBD123456 (application/coral+cbor) 1419 Payload: 1420 #using reef = 1422 #base 1423 reef:rd-unit <502> { 1424 reef:ep "grp_schedule" 1425 reef:et "core.rd-group" 1426 reef:base 1427 reef:rt "core.rd-ep" 1428 } 1430 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1432 Consequently, the device learns the security groups it has to join. 1433 In particular, it does the following for app-gp="grp_R2-4-015". 1435 Request: Joining node -> RD 1437 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 1438 ?rt=core.osc.gm&app-gp=grp_R2-4-015 1440 Response: RD -> Joining Node 1442 Res: 2.05 Content 1443 Content-Format: TBD123456 (application/coral+cbor) 1445 Payload: 1446 #using 1447 #using reef = 1449 #base 1450 reef:rd-item { 1451 reef:ct 65000 1452 reef:rt "core.osc.gm" 1453 reef:if "ace.group" 1454 sec-gp "feedca570000" 1455 app-gp "grp_R2-4-015" 1456 } 1458 Similarly, the device does the following for app-gp="grp_schedule". 1460 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 1461 ?rt=core.osc.gm&app-gp=grp_schedule 1463 Response: RD -> Joining Node 1465 Res: 2.05 Content 1466 Content-Format: TBD123456 (application/coral+cbor) 1468 Payload: 1469 #using 1470 #using reef = 1472 #base 1473 reef:rd-item { 1474 reef:ct 65000 1475 reef:rt "core.osc.gm" 1476 reef:if "ace.group" 1477 sec-gp "feedsc590000" 1478 app-gp "grp_schedule" 1479 } 1481 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1483 After this last discovery step, the device can ask permission to join 1484 the security groups, and effectively join them through the Group 1485 Manager, e.g. according to [I-D.ietf-ace-key-groupcomm-oscore]. 1487 Acknowledgments 1489 The authors sincerely thank Carsten Bormann, Klaus Hartke, Jaime 1490 Jimenez, Francesca Palombini, Dave Robin and Jim Schaad for their 1491 comments and feedback. 1493 The work on this document has been partly supported by VINNOVA and 1494 the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home 1495 (Grant agreement 952652); and by the EIT-Digital High Impact 1496 Initiative ACTIVE. 1498 Authors' Addresses 1500 Marco Tiloca 1501 RISE AB 1502 Isafjordsgatan 22 1503 Kista SE-16440 Stockholm 1504 Sweden 1506 Email: marco.tiloca@ri.se 1508 Christian Amsuess 1509 Hollandstr. 12/4 1510 Vienna 1020 1511 Austria 1513 Email: christian@amsuess.com 1515 Peter van der Stok 1516 Consultant 1518 Phone: +31-492474673 (Netherlands), +33-966015248 (France) 1519 Email: consultancy@vanderstok.org 1520 URI: www.vanderstok.org