idnits 2.17.1 draft-tiloca-core-oscore-discovery-06.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 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == 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 (July 13, 2020) is 1354 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 (-10) exists of draft-ietf-core-groupcomm-bis-00 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-09 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-24 == Outdated reference: A later version (-12) exists of draft-ietf-cose-rfc8152bis-algs-11 ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') == Outdated reference: A later version (-15) exists of draft-ietf-cose-rfc8152bis-struct-11 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-07 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-35 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-41 -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 4 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: January 14, 2021 6 P. van der Stok 7 Consultant 8 July 13, 2020 10 Discovery of OSCORE Groups with the CoRE Resource Directory 11 draft-tiloca-core-oscore-discovery-06 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 OSCORE 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 OSCORE groups and to acquire information for 23 joining them through the respective Group Manager. A given OSCORE 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 OSCORE 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 January 14, 2021. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Registration of Group Manager Endpoints . . . . . . . . . . . 6 67 2.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.2. Relation Link to Authorization Server . . . . . . . . . . 8 69 2.3. Registration Example . . . . . . . . . . . . . . . . . . 9 70 2.3.1. Example in Link Format . . . . . . . . . . . . . . . 9 71 2.3.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 10 72 3. Addition and Update of Security Groups . . . . . . . . . . . 10 73 3.1. Addition Example . . . . . . . . . . . . . . . . . . . . 11 74 3.1.1. Example in Link Format . . . . . . . . . . . . . . . 11 75 3.1.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 12 76 4. Discovery of Security Groups . . . . . . . . . . . . . . . . 14 77 4.1. Discovery Example #1 . . . . . . . . . . . . . . . . . . 15 78 4.1.1. Example in Link Format . . . . . . . . . . . . . . . 15 79 4.1.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 16 80 4.2. Discovery Example #2 . . . . . . . . . . . . . . . . . . 17 81 4.2.1. Example in Link Format . . . . . . . . . . . . . . . 17 82 4.2.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 18 83 5. Use Case Example With Full Discovery . . . . . . . . . . . . 19 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 86 7.1. Resource Types . . . . . . . . . . . . . . . . . . . . . 23 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 24 89 8.2. Informative References . . . . . . . . . . . . . . . . . 25 90 Appendix A. Use Case Example With Full Discovery (CoRAL) . . . . 26 91 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 94 1. Introduction 96 The Constrained Application Protocol (CoAP) [RFC7252] supports group 97 communication over IP multicast [I-D.ietf-core-groupcomm-bis] to 98 improve efficiency and latency of communication and reduce bandwidth 99 requirements. A set of CoAP endpoints constitutes an application 100 group by sharing a common pool of resources, that can be efficiently 101 accessed through group communication. The members of an application 102 group may be members of a security group, thus sharing a common set 103 of keying material to secure group communication. 105 The security protocol Group Object Security for Constrained RESTful 106 Environments (Group OSCORE) [I-D.ietf-core-oscore-groupcomm] builds 107 on OSCORE [RFC8613] and protects CoAP messages end-to-end in group 108 communication contexts through CBOR Object Signing and Encryption 109 (COSE) 110 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs]. An 111 application group may rely on one or more OSCORE groups as security 112 groups, and a same OSCORE group may be used by multiple application 113 groups at the same time. 115 A CoAP endpoint relies on a Group Manager (GM) to join an OSCORE 116 group and get the group keying material. The joining process in 117 [I-D.ietf-ace-key-groupcomm-oscore] is based on the ACE framework for 118 Authentication and Authorization in constrained environments 119 [I-D.ietf-ace-oauth-authz], with the joining endpoint and the GM 120 acting as ACE Client and Resource Server, respectively. That is, the 121 joining endpoint accesses the group-membership resource exported by 122 the GM and associated with the OSCORE group to join. 124 Typically, devices store a static X509 IDevID certificate installed 125 at manufacturing time [I-D.ietf-anima-bootstrapping-keyinfra]. This 126 is used at deployment time during an enrollment process that provides 127 the devices with an Operational Certificate, possibly updated during 128 the device lifetime. Operational Certificates may specify 129 information to join OSCORE groups, especially a reference to the 130 group-membership resources to access at the respective GMs. 132 However, it is usually impossible to provide such precise information 133 to freshly deployed devices, as part of their (early) Operational 134 Certificate. This can be due to a number of reasons: (1) the OSCORE 135 group(s) to join and the responsible GM(s) are generally unknown at 136 manufacturing time; (2) an OSCORE group of interest is created, or 137 the responsible GM is deployed, only after the device is enrolled and 138 fully operative in the network; (3) information related to existing 139 OSCORE groups or to their GMs has changed. This requires a method 140 for CoAP endpoints to dynamically discover OSCORE groups and their 141 GM, and to retrieve relevant information about deployed groups. 143 To this end, CoAP endpoints can use descriptions and links of group- 144 membership resources at GMs, to discover OSCORE groups and retrieve 145 the information required for joining them. With the discovery 146 process of OSCORE 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 OSCORE 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 OSCORE groups and retrieve the information required 155 to join them through their GM. In short, the GM registers as an 156 endpoint with the RD. The resulting registration resource includes 157 one link per OSCORE group under that GM, specifying the path to the 158 related group-membership resource to access for joining that group. 160 Additional descriptive information about the OSCORE group is stored 161 with the registered link. In the RD based on Link Format [RFC6690] 162 and defined in [I-D.ietf-core-resource-directory], this information 163 is specified as target attributes of the registered link, and 164 includes the identifiers of the application groups which use that 165 OSCORE group. This enables a lookup of those application groups at 166 the RD, where they are separately announced by a Commissioning Tool 167 (see Appendix A of [I-D.ietf-core-resource-directory]). 169 When querying the RD for OSCORE groups, a CoAP endpoint can use CoAP 170 observation [RFC7641]. This results in automatic notifications on 171 the creation of new OSCORE groups or the update of existing groups. 172 Thus, it facilitates the early deployment of CoAP endpoints, i.e. 173 even before the GM is deployed and OSCORE groups are created. 175 Interaction examples are provided in Link Format, as well as in the 176 Constrained RESTful Application Language CoRAL [I-D.ietf-core-coral] 177 with reference to a CoRAL-based RD [I-D.hartke-t2trg-coral-reef]. 178 While all the CoRAL examples use the CoRAL textual serialization 179 format, the CBOR [RFC7049] or JSON [RFC8259] binary serialization 180 format is used when sending such messages on the wire. 182 The approach in this document is consistent with, but not limited to, 183 the joining of OSCORE groups in [I-D.ietf-ace-key-groupcomm-oscore]. 185 1.1. Terminology 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 189 "OPTIONAL" in this document are to be interpreted as described in BCP 190 14 [RFC2119] [RFC8174] when, and only when, they appear in all 191 capitals, as shown here. 193 This specification requires readers to be familiar with the terms and 194 concepts discussed in [I-D.ietf-core-resource-directory] and 195 [RFC6690], as well as in [I-D.ietf-core-coral]. Readers should also 196 be familiar with the terms and concepts discussed in 197 [RFC7252][I-D.ietf-core-groupcomm-bis], 198 [I-D.ietf-core-oscore-groupcomm] and 199 [I-D.ietf-ace-key-groupcomm-oscore]. 201 Terminology for constrained environments, such as "constrained 202 device" and "constrained-node network", is defined in [RFC7228]. 204 Consistently with the definitions from Section 2.1 of 205 [I-D.ietf-core-groupcomm-bis], this document also refers to the 206 following terminology. 208 o CoAP group: a set of CoAP endpoints all configured to receive CoAP 209 multicast messages sent to the group's associated IP multicast 210 address and UDP port. An endpoint may be a member of multiple 211 CoAP groups by subscribing to multiple IP multicast addresses. 213 o Security group: a set of CoAP endpoints that share the same 214 security material, and use it to protect and verify exchanged 215 messages. A CoAP endpoint may be a member of multiple security 216 groups. There can be a one-to-one or a one-to-many relation 217 between security groups and CoAP groups. 219 This document especially considers a security group to be an 220 OSCORE group, where all members share one OSCORE Security Context 221 to protect group communication with Group OSCORE 222 [I-D.ietf-core-oscore-groupcomm]. However, the approach defined 223 in this document can be used to support the discovery of different 224 security groups than OSCORE groups. 226 o Application group: a set of CoAP endpoints that share a common set 227 of resources. An endpoint may be a member of multiple application 228 groups. An application group can be associated with one or more 229 security groups, and multiple application groups can use the same 230 security group. Application groups are announced in the RD by a 231 Commissioning Tool, according to the RD-Groups usage pattern (see 232 Appendix A of [I-D.ietf-core-resource-directory]). 234 2. Registration of Group Manager Endpoints 236 During deployment, a Group Manager (GM) can find the CoRE Resource 237 Directory (RD) as described in Section 4 of 238 [I-D.ietf-core-resource-directory]. 240 Afterwards, the GM registers as an endpoint with the RD, as described 241 in Section 5 of [I-D.ietf-core-resource-directory]. The GM SHOULD 242 NOT use the Simple Registration approach described in Section 5.1 of 243 [I-D.ietf-core-resource-directory]. 245 When registering with the RD, the GM also registers the links to all 246 the group-membership resources it has at that point in time, i.e. one 247 for each of its security groups. 249 In the registration request, each link to a group-membership resource 250 has as target the URI of that resource at the GM. Also, it specifies 251 a number of descriptive parameters as defined in Section 2.1. 253 2.1. Parameters 255 For each registered link to a group-membership resource at a GM, the 256 following parameters are specified together with the link. 258 In the RD defined in [I-D.ietf-core-resource-directory] and based on 259 Link Format, each parameter is specified in a target attribute with 260 the same name. 262 In an RD based on CoRAL, such as the one defined in 263 [I-D.hartke-t2trg-coral-reef], each parameter is specified in a 264 nested element with the same name. 266 o 'rt', with value "core.osc.mbr" (see Section 7.1). 268 o 'sec-gp', specifying the name of the security group of interest, 269 as a stable and invariant identifier, such as the group name used 270 in [I-D.ietf-ace-key-groupcomm-oscore]. This parameter MUST 271 specify a single value. 273 o 'app-gp', specifying the name(s) of the application group(s) 274 associated to the security group of interest indicated by 'sec- 275 gp'. This parameter MUST occur once for each application group, 276 and MUST specify only a single application group. 278 Optionally, the following parameters can also be specified. 280 o 'cs_alg', specifying the algorithm used to countersign messages in 281 the security group. If present, this parameter MUST specify a 282 single value encoded as a text string, which is taken from the 283 'Value' column of the "COSE Algorithms" Registry 284 [COSE.Algorithms]. 286 o 'cs_alg_crv', specifying the elliptic curve (if applicable) for 287 the algorithm used to countersign messages in the security group. 288 If present, this parameter MUST specify a single value encoded as 289 a text string, which is taken from the 'Value' column of the "COSE 290 Elliptic Curves" Registry [COSE.Elliptic.Curves]. 292 o 'cs_key_kty', specifying the key type of countersignature keys 293 used to countersign messages in the security group. If present, 294 this parameter MUST specify a single value encoded as a text 295 string, which is taken from the 'Value' column of the "COSE Key 296 Types" Registry [COSE.Key.Types]. 298 o 'cs_key_crv', specifying the elliptic curve (if applicable) of 299 countersignature keys used to countersign messages in the security 300 group. If present, this parameter MUST specify a single value 301 encoded as a text string, which is taken from the 'Value' column 302 of the "COSE Elliptic Curves" Registry defined in 303 [COSE.Elliptic.Curves]. 305 o 'cs_kenc', specifying the encoding of the public keys used in the 306 security group. If present, this parameter MUST specify a single 307 value encoded as a text string. This specification explicitly 308 admits the signaling of COSE Keys 309 [I-D.ietf-cose-rfc8152bis-struct] as encoding for public keys, 310 which is indicated with "1", as taken from the 'Confirmation Key' 311 column of the "CWT Confirmation Method" Registry defined in 312 [RFC8747]. Future specifications may define additional values for 313 this parameter. 315 o 'alg', specifying the AEAD algorithm used in the security group. 316 If present, this parameter MUST specify a single value encoded as 317 a text string, which is taken from the 'Value' column of the "COSE 318 Algorithms" Registry [COSE.Algorithms]. 320 o 'hkdf', specifying the HKDF algorithm used in the security group. 321 If present, this parameter MUST specify a single value encoded as 322 a text string, which is taken from the 'Value' column of the "COSE 323 Algorithms" Registry defined in [COSE.Algorithms]. 325 Note that the values registered in the COSE Registries 326 [COSE.Algorithms][COSE.Elliptic.Curves][COSE.Key.Types] are strongly 327 typed. On the contrary, Link Format is weakly typed and thus does 328 not distinguish between, for instance, the string value "-10" and the 329 integer value -10. 331 Therefore, in the RD defined in [I-D.ietf-core-resource-directory] 332 and based on Link Format, possible values registered as a string that 333 looks like an integer, e.g. the string "-10" in the 'Value' column of 334 the "COSE Algorithms" Registry [COSE.Algorithms], are not supported 335 by this approach. Therefore, they MUST NOT be advertised through the 336 corresponding parameters above. 338 A CoAP endpoint that queries the RD to discover security groups and 339 their group-membership resource to access (see Section 4) would 340 benefit from the information above as follows. 342 o The values of 'cs_alg', 'cs_alg_crv', 'cs_key_kty', 'cs_key_crv' 343 and 'cs_kenc' related to a group-membership resource provide an 344 early knowledge of the format and encoding of public keys used in 345 the security group. Thus, the CoAP endpoint does not need to ask 346 the GM for this information as a preliminary step before the 347 joining process, or to perform a trial-and-error joining exchange 348 with the GM. Hence, the CoAP endpoint is able to provide the GM 349 with its own public key in the correct expected format and 350 encoding at the very first step of the joining process. 352 o The values of 'cs_alg', 'alg' and 'hkdf' related to a group- 353 membership resource provide an early knowledge of the algorithms 354 used in the security group. Thus, the CoAP endpoint is able to 355 decide whether to actually proceed with the joining process, 356 depending on its support for the indicated algorithms. 358 2.2. Relation Link to Authorization Server 360 For each registered link to a group-membership resource, the GM MAY 361 additionally specify the link to the ACE Authorization Server (AS) 362 [I-D.ietf-ace-oauth-authz] associated to the GM, and issuing 363 authorization credentials to join the security group as described in 364 [I-D.ietf-ace-key-groupcomm-oscore]. 366 The link to the AS has as target the URI of the resource where to 367 send an authorization request to. 369 In the RD defined in [I-D.ietf-core-resource-directory] and based on 370 Link Format, the link to the AS is separately registered with the RD, 371 and includes the following parameters as target attributes. 373 o 'rel', with value "authorization_server". 375 o 'anchor', with value the target of the link to the group- 376 membership resource at the GM. 378 In an RD based on CoRAL, such as the one defined in 379 [I-D.hartke-t2trg-coral-reef], this is mapped (as describe there) to 380 a link from the registration resource to the AS, using the 381 link 382 relation type. 384 2.3. Registration Example 386 The example below shows a GM with endpoint name "gm1" and address 387 2001:db8::ab that registers with the RD. 389 The GM specifies the value of the 'sec-gp' parameter for accessing 390 the security group with name "feedca570000", and used by the 391 application group with name "group1" specified with the value of the 392 'app-gp' parameter. The countersignature algorithm used in the 393 security group is EdDSA, with elliptic curve Ed25519 and keys of type 394 OKP. Public keys used in the security group are encoded as COSE Keys 395 [I-D.ietf-cose-rfc8152bis-struct]. 397 In addition, the GM specifies the link to the ACE Authorization 398 Server associated to the GM, to which a CoAP endpoint should send an 399 Authorization Request for joining the corresponding security group 400 [I-D.ietf-ace-key-groupcomm-oscore]. 402 2.3.1. Example in Link Format 404 Request: GM -> RD 406 Req: POST coap://rd.example.com/rd?ep=gm1 407 Content-Format: 40 408 Payload: 409 ;ct=41;rt="core.osc.mbr"; 410 sec-gp="feedca570000";app-gp="group1"; 411 cs_alg="-8";cs_alg_crv="6"; 412 cs_key_kty="1";cs_key_crv=6"; 413 cs_kenc="1", 414 ; 415 rel="authorization-server"; 416 anchor="coap://[2001:db8::ab]/group-oscore/feedca570000" 418 Response: RD -> GM 420 Res: 2.01 Created 421 Location-Path: /rd/4521 423 2.3.2. Example in CoRAL 425 Request: GM -> RD 427 Req: POST coap://rd.example.com/rd?ep=gm1 428 Content-Format: TBD123456 (application/coral+cbor) 430 Payload: 431 #using 432 #using reef = 433 #using iana = 435 #base 436 reef:rd-item { 437 reef:rt "core.osc.mbr" 438 sec-gp "feedca570000" 439 app-gp "group1" 440 cs_alg -8 441 cs_alg_crv 6 442 cs_key_kty 1 443 cs_key_crv 6 444 cs_kenc 1 445 iana:authorization-server 446 } 448 Response: RD -> GM 450 Res: 2.01 Created 451 Location-Path: /rd/4521 453 3. Addition and Update of Security Groups 455 The GM is responsible to refresh the registration of all its group- 456 membership resources in the RD. This means that the GM has to update 457 the registration within its lifetime as per Section 5.3.1 of 458 [I-D.ietf-core-resource-directory], and has to change the content of 459 the registration when a group-membership resource is added/removed, 460 or if its parameters have to be changed, such as in the following 461 cases. 463 o The GM creates a new security group and starts exporting the 464 related group-membership resource. 466 o The GM dismisses an security group and stops exporting the related 467 group-membership resource. 469 o Information related to an existing security group changes, e.g. 470 the list of associated application groups. 472 To perform an update of its registrations, the GM can re-register 473 with the RD and fully specify all links to its group-membership 474 resources. 476 Alternatively, the GM can perform a PATCH/iPATCH [RFC8132] request to 477 the RD, as per Section 5.3.3 of [I-D.ietf-core-resource-directory]. 478 This requires new media-types to be defined in future standards, to 479 apply a new document as a patch to an existing stored document. 481 3.1. Addition Example 483 The example below shows how the GM from Section 2 re-registers with 484 the RD. When doing so, it specifies: 486 o The same previous group-membership resource associated to the 487 security group with name "feedca570000". 489 o An additional group-membership resource associated to the security 490 group with name "ech0ech00000" and used by the application group 491 "group2". 493 o A third group-membership resource associated with the security 494 group with name "abcdef120000" and used by two application groups, 495 namely "group3" and "group4". 497 Furthermore, the GM relates the same Authorization Server also to the 498 security groups "ech0ech00000" and "abcdef120000". 500 3.1.1. Example in Link Format 502 Request: GM -> RD 503 Req: POST coap://rd.example.com/rd?ep=gm1 504 Content-Format: 40 505 Payload: 506 ;ct=41;rt="core.osc.mbr"; 507 sec-gp="feedca570000";app-gp="group1"; 508 cs_alg="-8";cs_alg_crv="6"; 509 cs_key_kty="1";cs_key_crv=6"; 510 cs_kenc="1", 511 ;ct=41;rt="core.osc.mbr"; 512 sec-gp="ech0ech00000";app-gp="group2"; 513 cs_alg="-8";cs_alg_crv="6"; 514 cs_key_kty="1";cs_key_crv=6"; 515 cs_kenc="1", 516 ;ct=41;rt="core.osc.mbr"; 517 sec-gp="abcdef120000";app-gp="group3"; 518 app-gp="group4";cs_alg="-8"; 519 cs_alg_crv="6";cs_key_kty="1"; 520 cs_key_crv=6";cs_kenc="1", 521 ; 522 rel="authorization-server"; 523 anchor="coap://[2001:db8::ab]/group-oscore/feedca570000", 524 ; 525 rel="authorization-server"; 526 anchor="coap://[2001:db8::ab]/group-oscore/ech0ech00000", 527 ; 528 rel="authorization-server"; 529 anchor="coap://[2001:db8::ab]/group-oscore/abcdef120000" 531 Response: RD -> GM 533 Res: 2.04 Changed 534 Location-Path: /rd/4521 536 3.1.2. Example in CoRAL 538 Request: GM -> RD 539 Req: POST coap://rd.example.com/rd?ep=gm1 540 Content-Format: TBD123456 (application/coral+cbor) 542 Payload: 543 #using 544 #using reef = 545 #using iana = 547 #base 548 reef:rd-item { 549 reef:rt "core.osc.mbr" 550 sec-gp "feedca570000" 551 app-gp "group1" 552 cs_alg -8 553 cs_alg_crv 6 554 cs_key_kty 1 555 cs_key_crv 6 556 cs_kenc 1 557 iana:authorization-server 558 } 559 reef:rd-item { 560 reef:rt "core.osc.mbr" 561 sec-gp "ech0ech00000" 562 app-gp "group2" 563 cs_alg -8 564 cs_alg_crv 6 565 cs_key_kty 1 566 cs_key_crv 6 567 cs_kenc 1 568 iana:authorization-server 569 } 570 reef:rd-item { 571 reef:rt "core.osc.mbr" 572 sec-gp "abcdef120000" 573 app-gp "group3" 574 app-gp "group4" 575 cs_alg -8 576 cs_alg_crv 6 577 cs_key_kty 1 578 cs_key_crv 6 579 cs_kenc 1 580 iana:authorization-server 581 } 583 Response: RD -> GM 585 Res: 2.04 Changed 586 Location-Path: /rd/4521 588 4. Discovery of Security Groups 590 A CoAP endpoint that wants to join a security group, hereafter called 591 the joining node, might not have all the necessary information at 592 deployment time. Also, it might want to know about possible new 593 security groups created afterwards by the respective Group Managers. 595 To this end, the joining node can perform a resource lookup at the RD 596 as per Section 6.1 of [I-D.ietf-core-resource-directory], to retrieve 597 the missing pieces of information needed to join the security 598 group(s) of interest. The joining node can find the RD as described 599 in Section 4 of [I-D.ietf-core-resource-directory]. 601 The joining node uses the following parameter value for the lookup 602 filtering. 604 o 'rt' = "core.osc.mbr" (see Section 7.1). 606 The joining node may additionally consider the following parameters 607 for the lookup filtering, depending on the information it has already 608 available. 610 o 'sec-gp', specifying the name of the security group of interest. 611 This parameter MUST specify a single value. 613 o 'ep', specifying the registered endpoint of the GM. 615 o 'app-gp', specifying the name(s) of the application group(s) 616 associated with the security group of interest. This parameter 617 MAY be included multiple times, and each occurrence MUST specify 618 the name of one application group. 620 The response from the RD may include links to a group-membership 621 resource specifying multiple application groups, as all using the 622 same security group. In this case, the joining node is already 623 expected to know the exact application group of interest. 625 Furthermore, the response from the RD may include the links to 626 different group-membership resources, all specifying a same 627 application group of interest for the joining node, if the 628 corresponding security groups are all used by that application group. 630 In this case, application policies on the joining node should define 631 how to determine the exact security group to join, depending on what 632 exactly the endpoint is intended to do in the application group of 633 interest. Later on, the joining node will be anyway able to join 634 only security groups for which it is actually authorized to be a 635 member (see [I-D.ietf-ace-key-groupcomm-oscore]). 637 Note that, with RD-based discovery, including the 'app-gp' parameter 638 multiple times would result in finding only the group-membership 639 resource that serves all the specified application groups, i.e. not 640 any group-membership resource that serves either. Therefore, a 641 joining node needs to perform N separate queries with different 642 values for 'app-gp', in order to safely discover the (different) 643 group-membership resource(s) serving the N application groups. 645 4.1. Discovery Example #1 647 Consistently with the examples in Section 2 and Section 3, the 648 examples below consider a joining node that wants to join the 649 security group associated with the application group "group1", but 650 that does not know the name of the security group, the responsible GM 651 and the group-membership resource to access. 653 4.1.1. Example in Link Format 655 Request: Joining node -> RD 657 Req: GET coap://rd.example.com/rd-lookup/res 658 ?rt=core.osc.mbr&app-gp=group1 660 Response: RD -> Joining node 662 Res: 2.05 Content 663 Payload: 664 ;rt="core.osc.mbr"; 665 sec-gp="feedca570000";app-gp="group1"; 666 cs_alg="-8";cs_alg_crv="6";cs_key_kty="1"; 667 cs_key_crv=6";cs_kenc="1";anchor="coap://[2001:db8::ab]" 669 To retrieve the multicast IP address of the CoAP group used by the 670 application group "group1", the joining node performs an endpoint 671 lookup as shown below. The following assumes that the application 672 group "group1" had been previously registered as per Appendix A of 673 [I-D.ietf-core-resource-directory], with ff35:30:2001:db8::23 as 674 multicast IP address of the associated CoAP group. 676 Request: Joining node -> RD 678 Req: GET coap://rd.example.com/rd-lookup/ep 679 ?et=core.rd-group&ep=group1 681 Response: RD -> Joining node 682 Res: 2.05 Content 683 Payload: 684 ;ep="group1";et="core.rd-group"; 685 base="coap://[ff35:30:2001:db8::23]" 687 4.1.2. Example in CoRAL 689 Request: Joining node -> RD 691 Req: GET coap://rd.example.com/rd-lookup/res 692 ?rt=core.osc.mbr&app-gp=group1 693 Accept: TBD123456 (application/coral+cbor) 695 Response: RD -> Joining node 697 Res: 2.05 Content 698 Content-Format: TBD123456 (application/coral+cbor) 700 Payload: 701 #using 702 #using reef = 703 #using iana = 705 #base 706 reef:rd-item { 707 reef:rt "core.osc.mbr" 708 sec-gp "feedca570000" 709 app-gp "group1" 710 cs_alg -8 711 cs_alg_crv 6 712 cs_key_kty 1 713 cs_key_crv 6 714 cs_kenc 1 715 iana:authorization-server 716 } 718 To retrieve the multicast IP address of the CoAP group used by the 719 application group "group1", the joining node performs an endpoint 720 lookup as shown below. The following assumes that the application 721 group "group1" had been previously registered, with 722 ff35:30:2001:db8::23 as multicast IP address of the associated CoAP 723 group. 725 Request: Joining node -> RD 727 Req: GET coap://rd.example.com/rd-lookup/ep 728 ?et=core.rd-group&ep=group1 729 Accept: TBD123456 (application/coral+cbor) 730 Response: RD -> Joining node 732 Res: 2.05 Content 733 Content-Format: TBD123456 (application/coral+cbor) 735 Payload: 736 #using 737 #using reef = 739 reef:rd-unit <./rd/501> { 740 reef:ep="group1" 741 reef:et="core.rd-group" 742 reef:base 743 } 745 4.2. Discovery Example #2 747 Consistently with the examples in Section 2 and Section 3, the 748 examples below consider a joining node that wants to join the 749 security group with name "feedca570000", but that does not know the 750 responsible GM, the group-membership resource to access, and the 751 associated application groups. 753 The examples also show how the joining node uses CoAP observation 754 [RFC7641], in order to be notified of possible changes to the 755 parameters of the group-membership resource. This is also useful to 756 handle the case where the security group of interest has not been 757 created yet, so that the joining node can receive the requested 758 information when it becomes available. 760 4.2.1. Example in Link Format 762 Request: Joining node -> RD 764 Req: GET coap://rd.example.com/rd-lookup/res 765 ?rt=core.osc.mbr&sec-gp=feedca570000 766 Observe: 0 768 Response: RD -> Joining node 770 Res: 2.05 Content 771 Observe: 24 772 Payload: 773 ;rt="core.osc.mbr"; 774 sec-gp="feedca570000";app-gp="group1"; 775 cs_alg="-8";cs_alg_crv="6";cs_key_kty="1"; 776 cs_key_crv=6";cs_kenc="1";anchor="coap://[2001:db8::ab]" 778 Depending on the search criteria, the joining node performing the 779 resource lookup can get large responses. This can happen, for 780 instance, when the lookup request targets all the group-membership 781 resources at a specified GM, or all the group-membership resources of 782 all the registered GMs, as in the example below. 784 Request: Joining node -> RD 786 Req: GET coap://rd.example.com/rd-lookup/res?rt=core.osc.mbr 788 Response: RD -> Joining node 790 Res: 2.05 Content 791 Payload: 792 ;rt="core.osc.mbr"; 793 sec-gp="feedca570000";app-gp="group1"; 794 cs_alg="-8";cs_alg_crv="6";cs_key_kty="1"; 795 cs_key_crv=6";cs_kenc="1";anchor="coap://[2001:db8::ab]", 796 ;rt="core.osc.mbr"; 797 sec-gp="ech0ech00000";app-gp="group2"; 798 cs_alg="-8";cs_alg_crv="6";cs_key_kty="1"; 799 cs_key_crv=6";cs_kenc="1";anchor="coap://[2001:db8::ab]", 800 ;rt="core.osc.mbr"; 801 sec-gp="abcdef120000";app-gp="group3"; 802 app-gp="group4";cs_alg="-8";cs_alg_crv="6"; 803 cs_key_kty="1";cs_key_crv=6";cs_kenc="1"; 804 anchor="coap://[2001:db8::ab]" 806 Therefore, it is RECOMMENDED that a joining node which performs a 807 resource lookup with the CoAP Observe option specifies the value of 808 the parameter 'sec-gp' in its GET request sent to the RD. 810 4.2.2. Example in CoRAL 812 Request: Joining node -> RD 814 Req: GET coap://rd.example.com/rd-lookup/res 815 ?rt=core.osc.mbr&sec-gp=feedca570000 816 Accept: TBD123456 (application/coral+cbor) 817 Observe: 0 819 Response: RD -> Joining node 820 Res: 2.05 Content 821 Observe: 24 822 Content-Format: TBD123456 (application/coral+cbor) 824 Payload: 825 #using 826 #using reef = 827 #using iana = 829 #base 830 reef:rd-item { 831 reef:rt "core.osc.mbr" 832 sec-gp "feedca570000" 833 app-gp "group1" 834 cs_alg -8 835 cs_alg_crv 6 836 cs_key_kty 1 837 cs_key_crv 6 838 cs_kenc 1 839 iana:authorization-server 840 } 842 5. Use Case Example With Full Discovery 844 In this section, the discovery of security groups is described to 845 support the installation process of a lighting installation in an 846 office building. The described process is a simplified version of 847 one of many processes. 849 The process described in this section is intended as an example and 850 does not have any particular ambition to serve as recommendation or 851 best practice to adopt. That is, it shows a possible workflow 852 involving a Commissioning Tool (CT) used in a certain way, while it 853 is not meant to prescribe how the workflow should necessarily be. 855 Assume the existence of four luminaires that are members of two 856 application groups. In the first application group, the four 857 luminaires receive presence messages and light intensity messages 858 from sensors or their proxy. In the second application group, the 859 four luminaires and several other pieces of equipment receive 860 building state schedules. 862 Each of the two application groups is associated to a different 863 security group and to a different CoAP group with its own dedicated 864 multicast IP address. 866 The Fairhair Alliance describes how a new device is accepted and 867 commissioned in the network [Fairhair], by means of its certificate 868 stored during the manufacturing process. When commissioning the new 869 device in the installation network, the new device gets a new 870 identity defined by a newly allocated certificate, following the 871 BRSKI specification. 873 Section 7.3 of [I-D.ietf-core-resource-directory] describes how the 874 CT assigns an endpoint name based on the CN field, (CN=ACME) and the 875 serial number of the certificate (serial number = 123x, with 3 < x < 876 8). Corresponding ep-names ACME-1234, ACME-1235, ACME-1236 and 877 ACME-1237 are also assumed. 879 It is common practice that locations in the building are specified 880 according to a coordinate system. After the acceptance of the 881 luminaires into the installation network, the coordinate of each 882 device is communicated to the CT. This can be done manually or 883 automatically. 885 The mapping between location and ep-name is calculated by the CT. 886 For instance, on the basis of grouping criteria, the CT assigns: i) 887 application group "grp_R2-4-015" to the four luminaires; and ii) 888 application group "grp_schedule" to all schedule requiring devices. 889 Also, the device with ep name ACME-123x has been assigned IP address: 890 [2001:db8:4::x]. The RD is assigned IP address: [2001:db8:4:ff]. 891 The used multicast addresses are: [ff05::5:1] and [ff05::5:2]. 893 The following assumes that each device is pre-configured with the 894 name of the two application groups it belongs to. Additional 895 mechanisms can be defined in the RD, for supporting devices to 896 discover the application groups they belong to. 898 Appendix A provides this same use case example in CoRAL. 900 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 902 The CT defines the application group "grp_R2-4-015", with resource 903 /light and base address [ff05::5:1], as follows. 905 Request: CT -> RD 907 Req: POST coap://[2001:db8:4::ff]/rd 908 ?ep=grp_R2-4-015&et=core.rd-group&base=coap://[ff05::5:1] 909 Content-Format: 40 910 Payload: 911 ;rt="oic.d.light" 913 Response: RD -> CT 914 Res: 2.01 Created 915 Location-Path: /rd/501 917 Also, the CT defines a second application group "grp_schedule", with 918 resource /schedule and base address [ff05::5:2], as follows. 920 Request: CT -> RD 922 Req: POST coap://[2001:db8:4::ff]/rd 923 ?ep=grp_schedule&et=core.rd-group&base=coap://[ff05::5:2] 924 Content-Format: 40 925 Payload: 926 ;rt="oic.r.time.period" 928 Response: RD -> CT 930 Res: 2.01 Created 931 Location-Path: /rd/502 933 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 935 Finally, the CT defines the corresponding security groups. In 936 particular, assuming a Group Manager responsible for both security 937 groups and with address [2001:db8::ab], the CT specifies: 939 Request: CT -> RD 941 Req: POST coap://[2001:db8:4::ff]/rd 942 ?ep=gm1&base=coap://[2001:db8::ab] 943 Content-Format: 40 944 Payload: 945 ;ct=41;rt="core.osc.mbr"; 946 sec-gp="feedca570000"; 947 app-gp="grp_R2-4-015", 948 ;ct=41;rt="core.osc.mbr"; 949 sec-gp="feedsc590000"; 950 app-gp="grp_schedule" 952 Response: RD -> CT 954 Res: 2.01 Created 955 Location-Path: /rd/4521 957 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 959 The device with IP address [2001:db8:4::x] can retrieve the multicast 960 IP address of the CoAP group used by the application group 961 "grp_R2-4-015", by performing an endpoint lookup as shown below. 963 Request: Joining node -> RD 965 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 966 ?et=core.rd-group&ep=grp_R2-4-015 968 Response: RD -> Joining node 970 Res: 2.05 Content 971 Content-Format: 40 972 Payload: 973 ;ep="grp_R2-4-015";et="core.rd-group"; 974 base="coap://[ff05::5:1]" 976 Similarly, to retrieve the multicast IP address of the CoAP group 977 used by the application group "grp_schedule", the device performs an 978 endpoint lookup as shown below. 980 Request: Joining node -> RD 982 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 983 ?et=core.rd-group&ep=grp_schedule 985 Response: RD -> Joining node 987 Res: 2.05 Content 988 Content-Format: 40 989 Payload: 990 ;ep="grp_schedule";et="core.rd-group"; 991 base="coap://[ff05::5:2]" 993 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 995 Consequently, the device learns the security groups it has to join. 996 In particular, it does the following for app-gp="grp_R2-4-015". 998 Request: Joining node -> RD 1000 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 1001 ?rt=core.osc.mbr&app-gp=grp_R2-4-015 1003 Response: RD -> Joining Node 1005 Res: 2.05 Content 1006 Content-Format: 40 1007 Payload: 1008 ; 1009 rt="core.osc.mbr";sec-gp="feedca570000"; 1010 app-gp="grp_R2-4-015";anchor="coap://[2001:db8::ab]" 1012 Similarly, the device does the following for app-gp="grp_schedule". 1014 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 1015 ?rt=core.osc.mbr&app-gp=grp_schedule 1017 Response: RD -> Joining Node 1019 Res: 2.05 Content 1020 Content-Format: 40 1021 Payload: 1022 ; 1023 rt="core.osc.mbr";sec-gp="feedsc590000"; 1024 app-gp="grp_schedule";anchor="coap://[2001:db8::ab]" 1026 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1028 After this last discovery step, the device can ask permission to join 1029 the security groups, and effectively join them through the Group 1030 Manager, e.g. according to [I-D.ietf-ace-key-groupcomm-oscore]. 1032 6. Security Considerations 1034 The security considerations as described in Section 8 of 1035 [I-D.ietf-core-resource-directory] apply here as well. 1037 7. IANA Considerations 1039 This document has the following actions for IANA. 1041 7.1. Resource Types 1043 IANA is asked to enter the following value into the Resource Type 1044 (rt=) Link Target Attribute Values subregistry within the Constrained 1045 Restful Environments (CoRE) Parameters registry defined in [RFC6690]. 1047 +--------------+----------------------------+-------------------+ 1048 | Value | Description | Reference | 1049 +--------------+----------------------------+-------------------+ 1050 | | | | 1051 | core.osc.mbr | Group-membership resource | [[this document]] | 1052 | | of an OSCORE Group Manager | | 1053 | | | | 1054 +--------------+----------------------------+-------------------+ 1056 8. References 1058 8.1. Normative References 1060 [COSE.Algorithms] 1061 IANA, "COSE Algorithms", 1062 . 1065 [COSE.Elliptic.Curves] 1066 IANA, "COSE Elliptic Curves", 1067 . 1070 [COSE.Key.Types] 1071 IANA, "COSE Key Types", 1072 . 1075 [I-D.ietf-core-coral] 1076 Hartke, K., "The Constrained RESTful Application Language 1077 (CoRAL)", draft-ietf-core-coral-03 (work in progress), 1078 March 2020. 1080 [I-D.ietf-core-groupcomm-bis] 1081 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1082 for the Constrained Application Protocol (CoAP)", draft- 1083 ietf-core-groupcomm-bis-00 (work in progress), March 2020. 1085 [I-D.ietf-core-oscore-groupcomm] 1086 Tiloca, M., Selander, G., Palombini, F., and J. Park, 1087 "Group OSCORE - Secure Group Communication for CoAP", 1088 draft-ietf-core-oscore-groupcomm-09 (work in progress), 1089 June 2020. 1091 [I-D.ietf-core-resource-directory] 1092 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 1093 Amsuess, "CoRE Resource Directory", draft-ietf-core- 1094 resource-directory-24 (work in progress), March 2020. 1096 [I-D.ietf-cose-rfc8152bis-algs] 1097 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1098 Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-11 1099 (work in progress), July 2020. 1101 [I-D.ietf-cose-rfc8152bis-struct] 1102 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1103 Structures and Process", draft-ietf-cose-rfc8152bis- 1104 struct-11 (work in progress), July 2020. 1106 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1107 Requirement Levels", BCP 14, RFC 2119, 1108 DOI 10.17487/RFC2119, March 1997, 1109 . 1111 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1112 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1113 . 1115 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1116 Application Protocol (CoAP)", RFC 7252, 1117 DOI 10.17487/RFC7252, June 2014, 1118 . 1120 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1121 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1122 May 2017, . 1124 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 1125 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 1126 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 1127 2020, . 1129 8.2. Informative References 1131 [Fairhair] 1132 FairHair Alliance, "Security Architecture for the Internet 1133 of Things (IoT) in Commercial Buildings", White Paper, ed. 1134 Piotr Polak , March 2018, . 1138 [I-D.hartke-t2trg-coral-reef] 1139 Hartke, K., "Resource Discovery in Constrained RESTful 1140 Environments (CoRE) using the Constrained RESTful 1141 Application Language (CoRAL)", draft-hartke-t2trg-coral- 1142 reef-04 (work in progress), May 2020. 1144 [I-D.ietf-ace-key-groupcomm-oscore] 1145 Tiloca, M., Park, J., and F. Palombini, "Key Management 1146 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 1147 oscore-07 (work in progress), June 2020. 1149 [I-D.ietf-ace-oauth-authz] 1150 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1151 H. Tschofenig, "Authentication and Authorization for 1152 Constrained Environments (ACE) using the OAuth 2.0 1153 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35 1154 (work in progress), June 2020. 1156 [I-D.ietf-anima-bootstrapping-keyinfra] 1157 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 1158 and K. Watsen, "Bootstrapping Remote Secure Key 1159 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1160 keyinfra-41 (work in progress), April 2020. 1162 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1163 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1164 October 2013, . 1166 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1167 Constrained-Node Networks", RFC 7228, 1168 DOI 10.17487/RFC7228, May 2014, 1169 . 1171 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1172 Application Protocol (CoAP)", RFC 7641, 1173 DOI 10.17487/RFC7641, September 2015, 1174 . 1176 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 1177 FETCH Methods for the Constrained Application Protocol 1178 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 1179 . 1181 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1182 Interchange Format", STD 90, RFC 8259, 1183 DOI 10.17487/RFC8259, December 2017, 1184 . 1186 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1187 "Object Security for Constrained RESTful Environments 1188 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1189 . 1191 Appendix A. Use Case Example With Full Discovery (CoRAL) 1193 This section provides the same use case example of Section 5, but 1194 specified in CoRAL [I-D.ietf-core-coral]. 1196 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1197 The CT defines the application group "grp_R2-4-015", with resource 1198 /light and base address [ff05::5:1], as follows. 1200 Request: CT -> RD 1202 Req: POST coap://[2001:db8:4::ff]/rd 1203 Content-Format: TBD123456 (application/coral+cbor) 1205 Payload: 1206 #using reef = 1208 #base 1209 reef:ep "grp_R2-4-015" 1210 reef:et "core.rd-group" 1211 reef:rd-item { 1212 reef:rt "oic.d.light" 1213 } 1215 Response: RD -> CT 1217 Res: 2.01 Created 1218 Location-Path: /rd/501 1220 Also, the CT defines a second application group "grp_schedule", with 1221 resource /schedule and base address [ff05::5:2], as follows. 1223 Request: CT -> RD 1225 Req: POST coap://[2001:db8:4::ff]/rd?ep=grp_schedule&et=core.rd-group 1226 Content-Format: TBD123456 (application/coral+cbor) 1228 Payload: 1229 #using reef = 1231 #base 1232 reef:rd-item { 1233 reef:rt "oic.r.time.period" 1234 } 1236 Response: RD -> CT 1238 Res: 2.01 Created 1239 Location-Path: /rd/502 1241 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1242 Finally, the CT defines the corresponding security groups. In 1243 particular, assuming a Group Manager responsible for both security 1244 groups and with address [2001:db8::ab], the CT specifies: 1246 Request: CT -> RD 1248 Req: POST coap://[2001:db8:4::ff]/rd?ep=gm1 1249 Content-Format: TBD123456 (application/coral+cbor) 1251 Payload: 1252 #using 1253 #using reef = 1255 #base 1256 reef:rd-item { 1257 reef:ct 41 1258 reef:rt "core.osc.mbr" 1259 sec-gp "feedca570000" 1260 app-gp "grp_R2-4-015" 1261 } 1262 reef:rd-item { 1263 reef:ct 41 1264 reef:rt "core.osc.mbr" 1265 sec-gp "feedsc590000" 1266 app-gp "grp_schedule" 1267 } 1269 Response: RD -> CT 1271 Res: 2.01 Created 1272 Location-Path: /rd/4521 1274 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1276 The device with IP address [2001:db8:4::x] can retrieve the multicast 1277 IP address of the CoAP group used by the application group 1278 "grp_R2-4-015", by performing an endpoint lookup as shown below. 1280 Request: Joining node -> RD 1282 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 1283 ?et=core.rd-group&ep=grp_R2-4-015 1285 Response: RD -> Joining node 1286 Res: 2.05 Content 1287 Content-Format: TBD123456 (application/coral+cbor) 1289 Payload: 1290 #using reef = 1292 #base 1293 reef:rd-unit <501> { 1294 reef:ep "grp_R2-4-015" 1295 reef:et "core.rd-group" 1296 reef:base 1297 } 1299 Similarly, to retrieve the multicast IP address of the CoAP group 1300 used by the application group "grp_schedule", the device performs an 1301 endpoint lookup as shown below. 1303 Request: Joining node -> RD 1305 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 1306 ?et=core.rd-group&ep=grp_schedule 1308 Response: RD -> Joining node 1310 Res: 2.05 Content 1311 Content-Format: TBD123456 (application/coral+cbor) 1313 Payload: 1314 #using reef = 1316 #base 1317 reef:rd-unit <501> { 1318 reef:ep "grp_schedule" 1319 reef:et "core.rd-group" 1320 reef:base 1321 } 1323 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1325 Consequently, the device learns the security groups it has to join. 1326 In particular, it does the following for app-gp="grp_R2-4-015". 1328 Request: Joining node -> RD 1330 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 1331 ?rt=core.osc.mbr&app-gp=grp_R2-4-015 1333 Response: RD -> Joining Node 1334 Res: 2.05 Content 1335 Content-Format: TBD123456 (application/coral+cbor) 1337 Payload: 1338 #using 1339 #using reef = 1341 #base 1342 reef:rd-item { 1343 reef:rt "core.osc.mbr" 1344 sec-gp "feedca570000" 1345 app-gp "grp_R2-4-015" 1346 } 1348 Similarly, the device does the following for app-gp="grp_schedule". 1350 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 1351 ?rt=core.osc.mbr&app-gp=grp_schedule 1353 Response: RD -> Joining Node 1355 Res: 2.05 Content 1356 Content-Format: TBD123456 (application/coral+cbor) 1358 Payload: 1359 #using 1360 #using reef = 1362 #base 1363 reef:rd-item { 1364 reef:rt "core.osc.mbr" 1365 sec-gp "feedsc590000" 1366 app-gp "grp_schedule" 1367 } 1369 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1371 After this last discovery step, the device can ask permission to join 1372 the security groups, and effectively join them through the Group 1373 Manager, e.g. according to [I-D.ietf-ace-key-groupcomm-oscore]. 1375 Acknowledgments 1377 The authors sincerely thank Carsten Bormann, Klaus Hartke, Jaime 1378 Jimenez, Francesca Palombini, Dave Robin and Jim Schaad for their 1379 comments and feedback. 1381 The work on this document has been partly supported by VINNOVA and 1382 the Celtic-Next project CRITISEC, and by the EIT-Digital High Impact 1383 Initiative ACTIVE. 1385 Authors' Addresses 1387 Marco Tiloca 1388 RISE AB 1389 Isafjordsgatan 22 1390 Kista SE-16440 Stockholm 1391 Sweden 1393 Email: marco.tiloca@ri.se 1395 Christian Amsuess 1396 Hollandstr. 12/4 1397 Vienna 1020 1398 Austria 1400 Email: christian@amsuess.com 1402 Peter van der Stok 1403 Consultant 1405 Phone: +31-492474673 (Netherlands), +33-966015248 (France) 1406 Email: consultancy@vanderstok.org 1407 URI: www.vanderstok.org