idnits 2.17.1 draft-tiloca-core-oscore-discovery-05.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 3 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 (March 09, 2020) is 1509 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 (-21) exists of draft-ietf-core-oscore-groupcomm-07 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-23 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-04) exists of draft-hartke-t2trg-coral-reef-03 == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-05 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-33 == Outdated reference: A later version (-06) exists of draft-ietf-core-coral-02 -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 1 error (**), 0 flaws (~~), 9 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: September 10, 2020 6 P. van der Stok 7 Consultant 8 March 09, 2020 10 Discovery of OSCORE Groups with the CoRE Resource Directory 11 draft-tiloca-core-oscore-discovery-05 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 September 10, 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Registration of Group Manager Endpoints . . . . . . . . . . . 5 67 2.1. Target Attributes . . . . . . . . . . . . . . . . . . . . 6 68 2.2. Relation Link to Authorization Server . . . . . . . . . . 7 69 2.3. Registration Example . . . . . . . . . . . . . . . . . . 8 70 3. Addition and Update of OSCORE Groups . . . . . . . . . . . . 9 71 3.1. Addition Example . . . . . . . . . . . . . . . . . . . . 9 72 4. Discovery of OSCORE Groups . . . . . . . . . . . . . . . . . 10 73 4.1. Discovery Example #1 . . . . . . . . . . . . . . . . . . 11 74 4.2. Discovery Example #2 . . . . . . . . . . . . . . . . . . 12 75 5. Use Case Example With Full Discovery . . . . . . . . . . . . 14 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 78 7.1. Resource Types . . . . . . . . . . . . . . . . . . . . . 18 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 81 8.2. Informative References . . . . . . . . . . . . . . . . . 20 82 Appendix A. Examples in CoRAL . . . . . . . . . . . . . . . . . 21 83 A.1. Registration Example . . . . . . . . . . . . . . . . . . 21 84 A.2. Addition Example . . . . . . . . . . . . . . . . . . . . 22 85 A.3. Discovery Example #1 . . . . . . . . . . . . . . . . . . 24 86 A.4. Discovery Example #2 . . . . . . . . . . . . . . . . . . 25 87 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 90 1. Introduction 92 A set of CoAP endpoints constitutes an application group by sharing a 93 common pool of resources. The members of an application group may be 94 members of a given security group, by sharing a common set of keying 95 material to secure group communication. 97 The Constrained Application Protocol (CoAP) [RFC7252] supports group 98 communication over IP multicast [I-D.dijk-core-groupcomm-bis] to 99 improve efficiency and latency of communication and reduce bandwidth 100 requirements. The document Object Security for Constrained RESTful 101 Environments (OSCORE) [RFC8613] describes how to achieve end-to-end 102 security for CoAP messages through CBOR Object Signing and Encryption 103 (COSE) [RFC8152]. 105 In particular, [I-D.ietf-core-oscore-groupcomm] specifies how Group 106 OSCORE protects CoAP messages in group communication contexts, so 107 enabling OSCORE groups as security groups. An application group may 108 rely on one or more OSCORE groups, and a same OSCORE group may be 109 used by multiple application groups at the same time. 111 A CoAP endpoint joins an OSCORE group via a Group Manager (GM), in 112 order to get the necessary group keying material. As in 113 [I-D.ietf-ace-key-groupcomm-oscore], the joining process can be based 114 on the ACE framework for Authentication and Authorization in 115 constrained environments [I-D.ietf-ace-oauth-authz], with the joining 116 endpoint and the GM acting as ACE Client and Resource Server, 117 respectively. That is, the joining endpoint accesses the group- 118 membership resource associated with the OSCORE group to join and 119 exported by the GM. 121 Typically, devices are equipped with a static X509 IDevID certificate 122 installed at manufacturing time. This certificate is used at 123 deployment time during an enrollment process that provides the device 124 with an Operational Certificate, possibly updated during the device 125 lifetime. In the presence of secure group communication for CoAP, 126 such an Operational Certificate may be accompanied by information 127 required to join OSCORE groups. This especially includes a reference 128 to the group-membership resources to access at the respective GMs. 130 However, it is usually impossible to provide such precise information 131 to freshly deployed devices as part of their (early) Operational 132 Certificate. This can be due to a number of reasons: (1) the OSCORE 133 group(s) to join and the responsible GM(s) are generally unknown at 134 manufacturing time; (2) an OSCORE group of interest is created, or 135 the responsible GM is deployed, only after the device is enrolled and 136 fully operative in the network; and (3) information related to 137 existing OSCORE groups or to their GMs has been changed. This 138 requires a method for CoAP endpoints to dynamically discover OSCORE 139 groups and their GM, and to retrieve relevant information about 140 deployed groups. 142 To this end, CoAP endpoints can use descriptions and links of group- 143 membership resources at GMs, in order to discover OSCORE groups and 144 to retrieve the information required for joining them. With the 145 discovery process of OSCORE groups expressed in terms of links to 146 resources, the remaining problem is thus the discovery of those 147 links. The CoRE Resource Directory (RD) 148 [I-D.ietf-core-resource-directory] provides such discovery in an 149 efficient way, and it is expected to be used in many setups that 150 would benefit of OSCORE group discovery. 152 This specification builds on this approach and describes how CoAP 153 endpoints can use the RD to carry out the necessary link discovery 154 steps, in order to discover OSCORE groups of interest and retrieve 155 the information required to join them through their GM. In 156 principle, the GM registers as an endpoint with the RD. The 157 corresponding registration resource includes one link for each OSCORE 158 group under that GM, specifying the path to the related group- 159 membership resource to access for joining that group. 161 More information about the OSCORE group is stored in the target 162 attributes of the respective link. This especially includes the 163 identifiers of the application groups which use that OSCORE group. 164 This enables a lookup of those application groups at the Resource 165 Directory, where they are separately announced by a Commissioning 166 Tool (see Appendix A of [I-D.ietf-core-resource-directory]). 168 When querying the RD for OSCORE groups, a CoAP endpoint can further 169 benefit of the CoAP Observe Option [RFC7641]. This enables the 170 reception of notifications about the creation of new OSCORE groups or 171 the updates concerning existing groups. Thus, it facilitates the 172 early deployment of CoAP endpoints, i.e. even before the GM is 173 deployed and OSCORE groups are created. 175 Interaction examples are provided in Link Format [RFC6690]. In 176 addition, Appendix A provides analogous examples in the Constrained 177 RESTful Application Language CoRAL [I-D.ietf-core-coral], with 178 reference to a CoRAL-based Resource Directory as described in 179 [I-D.hartke-t2trg-coral-reef]. 181 The approach in this document is consistent with, but not limited to, 182 the joining of OSCORE groups in [I-D.ietf-ace-key-groupcomm-oscore]. 184 1.1. Terminology 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 188 "OPTIONAL" in this document are to be interpreted as described in BCP 189 14 [RFC2119] [RFC8174] when, and only when, they appear in all 190 capitals, as shown here. 192 This specification requires readers to be familiar with the terms and 193 concepts discussed in [I-D.ietf-core-resource-directory] and 194 [RFC6690]. Readers should also be familiar with the terms and 195 concepts discussed in [RFC7252], [I-D.ietf-core-oscore-groupcomm] and 196 [I-D.ietf-ace-key-groupcomm-oscore]. 198 Terminology for constrained environments, such as "constrained 199 device" and "constrained-node network", is defined in [RFC7228]. 201 This document also refers to the following terminology. 203 o OSCORE group: a set of CoAP endpoints that share one OSCORE Common 204 Security Context to protect group communication as described in 205 [I-D.ietf-core-oscore-groupcomm]. Consequently, an OSCORE group 206 acts as security group for all its members. 208 o Application group: a set of CoAP endpoints that share a set of 209 common resources. Application groups are announced in the RD by a 210 Commissioning Tool, according to the RD-Groups usage pattern (see 211 Appendix A of [I-D.ietf-core-resource-directory]). An application 212 group can be associated with one or more OSCORE groups, and 213 multiple application groups can use the same OSCORE group. 214 Application groups share resources by definition. Any two 215 application groups associated to the same OSCORE group do not 216 share any resource. 218 2. Registration of Group Manager Endpoints 220 During deployment, a Group Manager (GM) can find the CoRE Resource 221 Directory (RD) as described in Section 4 of 222 [I-D.ietf-core-resource-directory]. 224 Afterwards, the GM registers as an endpoint with the RD, as described 225 in Section 5 of [I-D.ietf-core-resource-directory]. The GM SHOULD 226 NOT use the Simple Registration approach described in Section 5.1 of 227 [I-D.ietf-core-resource-directory]. 229 When registering with the RD, the GM also registers the links to all 230 the group-membership resources it has at that point in time, i.e. one 231 for each of its OSCORE groups. 233 In the registration request, each link to a group-membership resource 234 has as target the URI of that resource at the GM. Also, it includes 235 parameters as target attributes, as defined in Section 2.1. 237 2.1. Target Attributes 239 For registered links to group-membership resources at a GM, the 240 following target attributes are specified. 242 o 'rt', with value "core.osc.mbr" (see Section 7.1). 244 o 'sec-gp', specifying the name of the OSCORE group of interest, as 245 a stable and invariant identifier, such as the group name used in 246 [I-D.ietf-ace-key-groupcomm-oscore]. This parameter MUST specify 247 a single value. 249 o 'app-gp', specifying the name(s) of the application group(s) 250 associated to the OSCORE group of interest indicated by 'sec-gp'. 251 This parameter MUST occur once for each application group, and 252 MUST specify only a single application group. 254 Optionally, the following target attributes can also be specified. 256 o 'cs_alg', specifying the algorithm used to countersign messages in 257 the OSCORE group. If present, this parameter MUST specify a 258 single value encoded as a text string, which is taken from the 259 'Value' column of the "COSE Algorithms" Registry defined in 260 [RFC8152]. 262 o 'cs_alg_crv', specifying the elliptic curve (if applicable) for 263 the algorithm used to countersign messages in the OSCORE group. 264 If present, this parameter MUST specify a single value encoded as 265 a text string, which is taken from the 'Value' column of the "COSE 266 Elliptic Curve" Registry defined in [RFC8152]. 268 o 'cs_key_kty', specifying the key type of countersignature keys 269 used to countersign messages in the OSCORE group. If present, 270 this parameter MUST specify a single value encoded as a text 271 string, which is taken from the 'Value' column of the "COSE Key 272 Types" Registry defined in [RFC8152]. 274 o 'cs_key_crv', specifying the elliptic curve (if applicable) of 275 countersignature keys used to countersign messages in the OSCORE 276 group. If present, this parameter MUST specify a single value 277 encoded as a text string, which is taken from the 'Value' column 278 of the "COSE Elliptic Curve" Registry defined in [RFC8152]. 280 o 'cs_kenc', specifying the encoding of the public keys used in the 281 OSCORE group. If present, this parameter MUST specify a single 282 value encoded as a text string. This specification explicitly 283 admits the signaling of COSE Keys [RFC8152] as encoding for public 284 keys, which is indicated with "1", as taken from the 'Confirmation 285 Key' column of the "CWT Confirmation Method" Registry defined in 286 [I-D.ietf-ace-cwt-proof-of-possession]. Future specifications may 287 define additional values for this parameter. 289 o 'alg', specifying the AEAD algorithm used in the OSCORE group. If 290 present, this parameter MUST specify a single value encoded as a 291 text string, which is taken from the 'Value' column of the "COSE 292 Algorithms" Registry defined in [RFC8152]. 294 o 'hkdf', specifying the HKDF algorithm used in the OSCORE group. 295 If present, this parameter MUST specify a single value encoded as 296 a text string, which is taken from the 'Value' column of the "COSE 297 Algorithms" Registry defined in [RFC8152]. 299 Values registered as a string that looks like an integer are not 300 supported by this approach. Therefore, they MUST NOT be advertised 301 through the corresponding parameters above. 303 A CoAP endpoint that queries the RD to discover OSCORE groups and 304 their group-membership resource to access (see Section 4) would 305 benefit from the information above as follows. 307 o The values of 'cs_alg', 'cs_alg_crv', 'cs_key_kty', 'cs_key_crv' 308 and 'cs_kenc' related to a group-membership resource provide an 309 early knowledge of the format and encoding of public keys used in 310 the OSCORE group. Thus, the CoAP endpoint does not need to ask 311 the GM for this information as a preliminary step before the 312 joining process, or to perform a trial-and-error exchange with the 313 GM. Hence, the CoAP endpoint is able to provide the GM with its 314 own public key in the correct expected format and encoding at the 315 very first step of the joining process. 317 o The values of 'cs_alg', 'alg' and 'hkdf' related to a group- 318 membership resource provide an early knowledge of the algorithms 319 used in the OSCORE group. Thus, the CoAP endpoint is able to 320 decide whether to actually proceed with the joining process, 321 depending on its support for the indicated algorithms. 323 2.2. Relation Link to Authorization Server 325 For each registered link to a group-membership resource, the GM MAY 326 additionally register the link to the ACE Authorization Server 327 [I-D.ietf-ace-oauth-authz] associated to the GM, and issuing 328 authorization credentials to join the OSCORE group as described in 329 [I-D.ietf-ace-key-groupcomm-oscore]. 331 This registered link to an Authorization Server has as target the URI 332 of the resource at the Authorization Server where to send an 333 authorization request to. Also, it includes the following parameters 334 as target attributes. 336 o 'rel', with value "authorization_server". 338 o 'anchor', with value the target of the link to the group- 339 membership resource at the GM. 341 2.3. Registration Example 343 The example below shows a GM with endpoint name "gm1" and address 344 2001:db8::ab that registers with the RD. 346 The GM specifies the value of the 'sec-gp' parameter for accessing 347 the OSCORE group with name "feedca570000", and used by the 348 application group with name "group1" specified with the value of the 349 'app-gp' parameter. The countersignature algorithm used in the 350 OSCORE group is EdDSA, with elliptic curve Ed25519 and keys of type 351 OKP. Public keys used in the OSCORE group are encoded as COSE Keys 352 [RFC8152]. 354 In addition, the GM registers the link to the ACE Authorization 355 Server associated to the GM, to which a CoAP endpoint should send an 356 Authorization Request for joining the corresponding OSCORE group 357 [I-D.ietf-ace-key-groupcomm-oscore]. 359 Request: GM -> RD 361 Req: POST coap://rd.example.com/rd?ep=gm1 362 Content-Format: 40 363 Payload: 364 ;ct=41;rt="core.osc.mbr"; 365 sec-gp="feedca570000";app-gp="group1"; 366 cs_alg="-8";cs_alg_crv="6"; 367 cs_key_kty="1";cs_key_crv=6"; 368 cs_kenc="1", 369 ; 370 rel="authorization-server"; 371 anchor="coap://[2001:db8::ab]/group-oscore/feedca570000" 373 Response: RD -> GM 375 Res: 2.01 Created 376 Location-Path: /rd/4521 378 An analogous example in CoRAL is provided in Appendix A.1. 380 3. Addition and Update of OSCORE Groups 382 The GM is responsible to refresh the registration of all its group- 383 membership resources in the RD. This means that the GM has to update 384 the registration within its lifetime as per Section 5.3.1 of 385 [I-D.ietf-core-resource-directory], and has to change the content of 386 the registration when a group-membership resource is added/removed, 387 or if its target attributes have to be changed, such as in the 388 following cases. 390 o The GM creates a new OSCORE group and starts exporting the related 391 group-membership resource. 393 o The GM dismisses an OSCORE group and stops exporting the related 394 group-membership resource. 396 o Information related to an existing OSCORE group changes, e.g. the 397 list of associated application groups. 399 To perform an update of its registrations, the GM can re-register 400 with the RD and fully specify all links to its group-membership 401 resources with their target attributes. 403 Alternatively, the GM can perform a PATCH/iPATCH [RFC8132] request to 404 the RD, as per Section 5.3.3 of [I-D.ietf-core-resource-directory]. 405 This requires new media-types to be defined in future standards, to 406 apply a link-format document as a patch to an existing stored 407 document. 409 3.1. Addition Example 411 The example below shows how the GM from Section 2 re-registers with 412 the RD. When doing so, it specifies: 414 o The same previous group-membership resource associated to the 415 OSCORE group with name "feedca570000". 417 o An additional group-membership resource associated to the OSCORE 418 group with name "ech0ech00000" and used by the application group 419 "group2". 421 o A third group-membership resource associated with the OSCORE group 422 with name "abcdef120000" and used by two application groups, 423 namely "group3" and "group4". 425 Furthermore, the GM relates the same Authorization Server also to the 426 OSCORE groups "ech0ech00000" and "abcdef120000". 428 Request: GM -> RD 430 Req: POST coap://rd.example.com/rd?ep=gm1 431 Content-Format: 40 432 Payload: 433 ;ct=41;rt="core.osc.mbr"; 434 sec-gp="feedca570000";app-gp="group1"; 435 cs_alg="-8";cs_alg_crv="6"; 436 cs_key_kty="1";cs_key_crv=6"; 437 cs_kenc="1", 438 ;ct=41;rt="core.osc.mbr"; 439 sec-gp="ech0ech00000";app-gp="group2"; 440 cs_alg="-8";cs_alg_crv="6"; 441 cs_key_kty="1";cs_key_crv=6"; 442 cs_kenc="1", 443 ;ct=41;rt="core.osc.mbr"; 444 sec-gp="abcdef120000";app-gp="group3"; 445 app-gp="group4";cs_alg="-8"; 446 cs_alg_crv="6";cs_key_kty="1"; 447 cs_key_crv=6";cs_kenc="1", 448 ; 449 rel="authorization-server"; 450 anchor="coap://[2001:db8::ab]/group-oscore/feedca570000", 451 ; 452 rel="authorization-server"; 453 anchor="coap://[2001:db8::ab]/group-oscore/ech0ech00000", 454 ; 455 rel="authorization-server"; 456 anchor="coap://[2001:db8::ab]/group-oscore/abcdef120000" 458 Response: RD -> GM 460 Res: 2.04 Changed 461 Location-Path: /rd/4521 463 An analogous example in CoRAL is provided in Appendix A.2. 465 4. Discovery of OSCORE Groups 467 A CoAP endpoint that wants to join an OSCORE group, hereafter called 468 the joining node, might not have all the necessary information at 469 deployment time. Also, it might want to know about possible new 470 OSCORE groups created afterwards by the respective Group Managers. 472 To this end, the joining node can perform a resource lookup at the RD 473 as per Section 6.1 of [I-D.ietf-core-resource-directory], to retrieve 474 the missing pieces of information needed to join the OSCORE group(s) 475 of interest. The joining node can find the RD as described in 476 Section 4 of [I-D.ietf-core-resource-directory]. 478 The joining node uses the following parameter value for the lookup 479 filtering. 481 o 'rt' = "core.osc.mbr" (see Section 7.1). 483 The joining node may additionally consider the following parameters 484 for the lookup filtering, depending on the information it has already 485 available. 487 o 'sec-gp', specifying the name of the OSCORE group of interest. 488 This parameter MUST specify a single value. 490 o 'ep', specifying the registered endpoint of the GM. 492 o 'app-gp', specifying the name(s) of the application group(s) 493 associated with the OSCORE group of interest. This parameter MAY 494 be included multiple times, and each occurrence MUST specify the 495 name of one application group. 497 Note that, with RD-based discovery, including the 'app-gp' parameter 498 multiple times would result in finding only the group-membership 499 resource that serves all the specified application groups, i.e. not 500 any group-membership resource that serves either. Therefore, a 501 joining node needs to perform N separate queries with different 502 values for 'app-gp', in order to safely discover the (different) 503 group-membership resource(s) serving the N application groups. 505 4.1. Discovery Example #1 507 Consistently with the examples in Section 2 and Section 3, the 508 example below considers a joining node that wants to join the OSCORE 509 group associated with the application group "group1", but that does 510 not know the name of the OSCORE group, the responsible GM and the 511 group-membership resource to access. 513 Request: Joining node -> RD 515 Req: GET coap://rd.example.com/rd-lookup/res 516 ?rt=core.osc.mbr&app-gp=group1 518 Response: RD -> Joining node 519 Res: 2.05 Content 520 Payload: 521 ;rt="core.osc.mbr"; 522 sec-gp="feedca570000";app-gp="group1"; 523 cs_alg="-8";cs_alg_crv="6";cs_key_kty="1"; 524 cs_key_crv=6";cs_kenc="1";anchor="coap://[2001:db8::ab]" 526 To retrieve the multicast IP address used in "group1", the joining 527 node performs an endpoint lookup as shown below. The following 528 assumes that the application group "group1" had been previously 529 registered as per Appendix A of [I-D.ietf-core-resource-directory], 530 with ff35:30:2001:db8::23 as associated multicast IP address. 532 Request: Joining node -> RD 534 Req: GET coap://rd.example.com/rd-lookup/ep 535 ?et=core.rd-group&ep=group1 537 Response: RD -> Joining node 539 Res: 2.05 Content 540 Payload: 541 ;ep="group1";et="core.rd-group"; 542 base="coap://[ff35:30:2001:db8::23]" 544 An analogous example in CoRAL is provided in Appendix A.3. 546 4.2. Discovery Example #2 548 Consistently with the examples in Section 2 and Section 3, the 549 example below considers a joining node that wants to join the OSCORE 550 group with name "feedca570000", but that does not know the 551 responsible GM, the group-membership resource to access, and the 552 associated application groups. 554 The example also shows how the joining node uses CoAP observation 555 [RFC7641], in order to be notified of possible changes to the target 556 attributes of the group-membership resource. This is also useful to 557 handle the case where the OSCORE group of interest has not been 558 created yet, so that the joining node can receive the requested 559 information when it becomes available. 561 Request: Joining node -> RD 563 Req: GET coap://rd.example.com/rd-lookup/res 564 ?rt=core.osc.mbr&sec-gp=feedca570000 565 Observe: 0 566 Response: RD -> Joining node 568 Res: 2.05 Content 569 Observe: 24 570 Payload: 571 ;rt="core.osc.mbr"; 572 sec-gp="feedca570000";app-gp="group1"; 573 cs_alg="-8";cs_alg_crv="6";cs_key_kty="1"; 574 cs_key_crv=6";cs_kenc="1";anchor="coap://[2001:db8::ab]" 576 An analogous example in CoRAL is provided in Appendix A.4. 578 Depending on the search criteria, the joining node performing the 579 resource lookup can get large responses. This can happen, for 580 instance, when the lookup request targets all the group-membership 581 resources at a specified GM, or all the group-membership resources of 582 all the registered GMs, as in the example below. 584 Request: Joining node -> RD 586 Req: GET coap://rd.example.com/rd-lookup/res?rt=core.osc.mbr 588 Response: RD -> Joining node 590 Res: 2.05 Content 591 Payload: 592 ;rt="core.osc.mbr"; 593 sec-gp="feedca570000";app-gp="group1"; 594 cs_alg="-8";cs_alg_crv="6";cs_key_kty="1"; 595 cs_key_crv=6";cs_kenc="1";anchor="coap://[2001:db8::ab]", 596 ;rt="core.osc.mbr"; 597 sec-gp="ech0ech00000";app-gp="group2"; 598 cs_alg="-8";cs_alg_crv="6";cs_key_kty="1"; 599 cs_key_crv=6";cs_kenc="1";anchor="coap://[2001:db8::ab]", 600 ;rt="core.osc.mbr"; 601 sec-gp="abcdef120000";app-gp="group3"; 602 app-gp="group4";cs_alg="-8";cs_alg_crv="6"; 603 cs_key_kty="1";cs_key_crv=6";cs_kenc="1"; 604 anchor="coap://[2001:db8::ab]" 606 Therefore, it is RECOMMENDED that a joining node which performs a 607 resource lookup with the CoAP Observe option specifies the value of 608 the parameter 'sec-gp' in its GET request sent to the RD. 610 5. Use Case Example With Full Discovery 612 In this section, the discovery of security groups is described to 613 support the installation process of a lighting installation in an 614 office building. The described process is a simplified version of 615 one of many processes. 617 Assume the existence of four luminaires that are members of two 618 application groups. In the first application group, the four 619 luminaires receive presence messages and light intensity messages 620 from sensors or their proxy. In the second application group, the 621 four luminaires and several other pieces of equipment receive 622 building state schedules. 624 Each of the two application groups is associated to a different 625 security group and uses its own dedicated multicast IP address. 627 The Fairhair Alliance describes how a new device is accepted and 628 commissioned in the network [Fairhair], by means of its certificate 629 stored during the manufacturing process. When commissioning the new 630 device in the installation network, the new device gets a new 631 identity defined by a newly allocated certificate, following the 632 BRSKI specification. 634 Section 7.3 of [I-D.ietf-core-resource-directory] describes how the 635 Commissioning Tool (CT) assigns an endpoint name based on the CN 636 field, (CN=ACME) and the serial number of the certificate (serial 637 number = 123x, with 3 < x < 8). Corresponding ep-names ACME-1234, 638 ACME-1235, ACME-1236 and ACME-1237 are also assumed. 640 It is common practice that locations in the building are specified 641 according to a coordinate system. After the acceptance of the 642 luminaires into the installation network, the coordinate of each 643 device is communicated to the CT. This can be done manually or 644 automatically. 646 The mapping between location and ep-name is calculated by the CT. 647 For instance, on the basis of grouping criteria, the CT assigns: i) 648 application group "grp_R2-4-015" to the four luminaires; and ii) 649 application group "grp_schedule" to all schedule requiring devices. 650 Also, the device with ep name ACME-123x has been assigned IP address: 651 [2001:db8:4::x]. The RD is assigned IP address: [2001:db8:4:ff]. 652 The used multicast addresses are: [ff05::5:1] and [ff05::5:2]. 654 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 656 The CT defines the application group "grp_R2-4-015", with resource 657 /light and base address [ff05::5:1], as follows. 659 Request: CT -> RD 661 Req: POST coap://[2001:db8:4::ff]/rd 662 ?ep=grp_R2-4-015&et=core.rd-group&base=coap://[ff05::5:1] 663 Payload: 664 ;rt="oic.d.light" 666 Response: RD -> CT 668 Res: 2.01 Created 669 Location-Path: /rd/501 671 Also, the CT defines a second application group "grp_schedule", with 672 resource /schedule and base address [ff05::5:2], as follows. 674 Request: CT -> RD 676 Req: POST coap://[2001:db8:4::ff]/rd 677 ?ep=grp_schedule&et=core.rd-group&base=coap://[ff05::5:2] 678 Payload: 679 ;rt="oic.r.time.period" 681 Response: RD -> CT 683 Res: 2.01 Created 684 Location-Path: /rd/502 686 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 688 Consecutively, the CT registers the four devices in the RD (IP 689 address: 2001:db8:4::ff), with their endpoint names and application 690 groups. 692 For the application group "grp_R2-4-015", four endpoints are 693 specified as follows, with x = 4, 5, 6, 7. 695 Request: CT -> RD 697 Req: POST coap://[2001:db8:4::ff]/rd 698 ?ep=ACME-123x&base=coap://[2001:db8:4::x]&in-app-gp=grp_R2-4-015 699 Payload: 700 ;rt="oic.d.light" 702 Response: RD -> CT 704 Res: 2.01 Created 705 Location-Path: /rd/452x 706 For the application group "grp_schedule", four other endpoints are 707 specified as follows, with x = 4, 5, 6, 7. 709 Request: CT -> RD 711 Req: POST coap://[2001:db8:4::ff]/rd 712 ?ep=ACME-123x&base=coap://[2001:db8:4::x]&in-app-gp=grp_schedule 713 Payload: 714 ;rt="oic.r.time.period" 716 Response: RD -> CT 718 Res: 2.01 Created 719 Location-Path: /rd/456x 721 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 723 Finally, the CT defines the corresponding security groups. In 724 particular, assuming a Group Manager responsible for both security 725 groups and with address [2001:db8::ab], the CT specifies: 727 Request: CT -> RD 729 Req: POST coap://[2001:db8:4::ff]/rd 730 ?ep=gm1&base=coap://[2001:db8::ab] 731 Payload: 732 ;ct=41;rt="core.osc.mbr"; 733 sec-gp="feedca570000"; 734 app-gp="grp_R2-4-015", 735 ;ct=41;rt="core.osc.mbr"; 736 sec-gp="feedsc590000"; 737 app-gp="grp_schedule" 739 Response: RD -> CT 741 Res: 2.01 Created 742 Location-Path: /rd/4521 744 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 746 The device with IP address [2001:db8:4::x] can consequently learn the 747 groups to which it belongs. In particular, it first does an ep 748 lookup to the RD to learn the application groups to which it belongs. 750 Request: Joining node -> RD 752 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 753 ?base=coap://[2001:db8:4::x] 755 Response: RD -> Joining node 757 Res: 2.05 Content 758 Payload: 759 ;base=coap://[2001:db8:4::x]&ep=ACME-123x&\ 760 in-app-gp=grp_R2-4-015, 761 ;base=coap://[2001:db8:4::x]&ep=ACME-123x&\ 762 in-app-gp=grp_schedule 764 To retrieve the multicast IP address used in "grp_R2-4-015", the 765 device performs an endpoint lookup as shown below. 767 Request: Joining node -> RD 769 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 770 ?et=core.rd-group&ep=grp_R2-4-015 772 Response: RD -> Joining node 774 Res: 2.05 Content 775 Payload: 776 ;ep="grp_R2-4-015";et="core.rd-group"; 777 base="coap://[ff05::5:1]" 779 Similarly, to retrieve the multicast IP address used in 780 "grp_schedule", the device performs an endpoint lookup as shown 781 below. 783 Request: Joining node -> RD 785 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 786 ?et=core.rd-group&ep=grp_schedule 788 Response: RD -> Joining node 790 Res: 2.05 Content 791 Payload: 792 ;ep="grp_schedule";et="core.rd-group"; 793 base="coap://[ff05::5:2]" 795 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 797 Having learnt the application groups to which the device belongs, the 798 device learns the security groups to which it belongs. In 799 particular, it does the following for app-gp="grp_R2-4-015". 801 Request: Joining node -> RD 802 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 803 ?rt=core.osc.mbr&app-gp=grp_R2-4-015 805 Response: RD -> Joining Node 807 Res: 2.05 Content 808 Payload: 809 ; 810 rt="core.osc.mbr";sec-gp="feedca570000"; 811 app-gp="grp_R2-4-015";anchor="coap://[2001:db8::ab]" 813 Similarly, the device does the following for app-gp="grp_schedule". 815 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 816 ?rt=core.osc.mbr&app-gp=grp_schedule 818 Response: RD -> Joining Node 820 Res: 2.05 Content 821 Payload: 822 ; 823 rt="core.osc.mbr";sec-gp="feedsc590000"; 824 app-gp="grp_schedule";anchor="coap://[2001:db8::ab]" 826 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 828 After this last discovery step, the device can ask permission to join 829 the security groups, and effectively join them through the Group 830 Manager, e.g. according to [I-D.ietf-ace-key-groupcomm-oscore]. 832 6. Security Considerations 834 The security considerations as described in Section 8 of 835 [I-D.ietf-core-resource-directory] apply here as well. 837 7. IANA Considerations 839 This document has the following actions for IANA. 841 7.1. Resource Types 843 IANA is asked to enter the following value into the Resource Type 844 (rt=) Link Target Attribute Values subregistry within the Constrained 845 Restful Environments (CoRE) Parameters registry defined in [RFC6690]. 847 +--------------+----------------------------+-------------------+ 848 | Value | Description | Reference | 849 +--------------+----------------------------+-------------------+ 850 | | | | 851 | core.osc.mbr | Group-membership resource | [[this document]] | 852 | | of an OSCORE Group Manager | | 853 | | | | 854 +--------------+----------------------------+-------------------+ 856 8. References 858 8.1. Normative References 860 [I-D.ietf-ace-cwt-proof-of-possession] 861 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 862 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 863 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 864 possession-11 (work in progress), October 2019. 866 [I-D.ietf-core-oscore-groupcomm] 867 Tiloca, M., Selander, G., Palombini, F., and J. Park, 868 "Group OSCORE - Secure Group Communication for CoAP", 869 draft-ietf-core-oscore-groupcomm-07 (work in progress), 870 March 2020. 872 [I-D.ietf-core-resource-directory] 873 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 874 Amsuess, "CoRE Resource Directory", draft-ietf-core- 875 resource-directory-23 (work in progress), July 2019. 877 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 878 Requirement Levels", BCP 14, RFC 2119, 879 DOI 10.17487/RFC2119, March 1997, 880 . 882 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 883 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 884 . 886 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 887 Application Protocol (CoAP)", RFC 7252, 888 DOI 10.17487/RFC7252, June 2014, 889 . 891 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 892 RFC 8152, DOI 10.17487/RFC8152, July 2017, 893 . 895 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 896 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 897 May 2017, . 899 8.2. Informative References 901 [Fairhair] 902 FairHair Alliance, "Security Architecture for the Internet 903 of Things (IoT) in Commercial Buildings", White Paper, ed. 904 Piotr Polak , March 2018, . 908 [I-D.dijk-core-groupcomm-bis] 909 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 910 for the Constrained Application Protocol (CoAP)", draft- 911 dijk-core-groupcomm-bis-03 (work in progress), March 912 2020. 914 [I-D.hartke-t2trg-coral-reef] 915 Hartke, K., "Resource Discovery in Constrained RESTful 916 Environments (CoRE) using the Constrained RESTful 917 Application Language (CoRAL)", draft-hartke-t2trg-coral- 918 reef-03 (work in progress), November 2019. 920 [I-D.ietf-ace-key-groupcomm-oscore] 921 Tiloca, M., Park, J., and F. Palombini, "Key Management 922 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 923 oscore-05 (work in progress), March 2020. 925 [I-D.ietf-ace-oauth-authz] 926 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 927 H. Tschofenig, "Authentication and Authorization for 928 Constrained Environments (ACE) using the OAuth 2.0 929 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33 930 (work in progress), February 2020. 932 [I-D.ietf-core-coral] 933 Hartke, K., "The Constrained RESTful Application Language 934 (CoRAL)", draft-ietf-core-coral-02 (work in progress), 935 January 2020. 937 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 938 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 939 October 2013, . 941 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 942 Constrained-Node Networks", RFC 7228, 943 DOI 10.17487/RFC7228, May 2014, 944 . 946 [RFC7641] Hartke, K., "Observing Resources in the Constrained 947 Application Protocol (CoAP)", RFC 7641, 948 DOI 10.17487/RFC7641, September 2015, 949 . 951 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 952 FETCH Methods for the Constrained Application Protocol 953 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 954 . 956 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 957 Interchange Format", STD 90, RFC 8259, 958 DOI 10.17487/RFC8259, December 2017, 959 . 961 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 962 "Object Security for Constrained RESTful Environments 963 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 964 . 966 Appendix A. Examples in CoRAL 968 This section provides interaction examples in the Constrained RESTful 969 Application Language CoRAL [I-D.ietf-core-coral], with reference to a 970 CoRAL-based Resource Directory as described in 971 [I-D.hartke-t2trg-coral-reef]. 973 While all the following examples use the CoRAL textual serialization 974 format, the CBOR [RFC7049] or JSON [RFC8259] binary serialization 975 format is used when sending such messages on the wire. 977 A.1. Registration Example 979 The following example in CoRAL is analogous to the example in 980 Section 2.3. 982 Request: GM -> RD 983 Req: POST coap://rd.example.com/rd?ep=gm1 984 Content-Format: TBD123456 (application/coral+cbor) 986 Payload: 987 #using 988 #using 990 #base 991 rd-item { 992 rt "core.osc.mbr" 993 sec-gp "feedca570000" 994 app-gp "group1" 995 cs_alg -8 996 cs_alg_crv 6 997 cs_key_kty 1 998 cs_key_crv 6 999 cs_kenc 1 1000 authorization-server 1001 } 1003 Response: RD -> GM 1005 Res: 2.01 Created 1006 Location-Path: /rd/4521 1008 A.2. Addition Example 1010 The following example in CoRAL is analogous to the example in 1011 Section 3.1. 1013 Request: GM -> RD 1014 Req: POST coap://rd.example.com/rd?ep=gm1 1015 Content-Format: TBD123456 (application/coral+cbor) 1017 Payload: 1018 #using 1019 #using 1021 #base 1022 rd-item { 1023 rt "core.osc.mbr" 1024 sec-gp "feedca570000" 1025 app-gp "group1" 1026 cs_alg -8 1027 cs_alg_crv 6 1028 cs_key_kty 1 1029 cs_key_crv 6 1030 cs_kenc 1 1031 as-uri 1032 } 1033 rd-item { 1034 rt "core.osc.mbr" 1035 sec-gp "ech0ech00000" 1036 app-gp "group2" 1037 cs_alg -8 1038 cs_alg_crv 6 1039 cs_key_kty 1 1040 cs_key_crv 6 1041 cs_kenc 1 1042 as-uri 1043 } 1044 rd-item { 1045 rt "core.osc.mbr" 1046 sec-gp "abcdef120000" 1047 app-gp "group3" 1048 app-gp "group4" 1049 cs_alg -8 1050 cs_alg_crv 6 1051 cs_key_kty 1 1052 cs_key_crv 6 1053 cs_kenc 1 1054 as-uri 1055 } 1057 Response: RD -> GM 1059 Res: 2.04 Changed 1060 Location-Path: /rd/4521 1062 A.3. Discovery Example #1 1064 The following example in CoRAL is analogous to the example in 1065 Section 4.1. 1067 Request: Joining node -> RD 1069 Req: GET coap://rd.example.com/rd-lookup/res 1070 ?rt=core.osc.mbr&app-gp=group1 1071 Accept: TBD123456 (application/coral+cbor) 1073 Response: RD -> Joining node 1075 Res: 2.05 Content 1076 Content-Format: TBD123456 (application/coral+cbor) 1078 Payload: 1079 #using 1080 #using 1082 #base 1083 rd-item { 1084 rt "core.osc.mbr" 1085 sec-gp "feedca570000" 1086 app-gp "group1" 1087 cs_alg -8 1088 cs_alg_crv 6 1089 cs_key_kty 1 1090 cs_key_crv 6 1091 cs_kenc 1 1092 as-uri 1093 } 1095 Request: Joining node -> RD 1097 Req: GET coap://rd.example.com/rd-lookup/ep 1098 ?et=core.rd-group&ep=group1 1099 Accept: TBD123456 (application/coral+cbor) 1101 Response: RD -> Joining node 1102 Res: 2.05 Content 1103 Content-Format: TBD123456 (application/coral+cbor) 1105 Payload: 1106 rd-unit <./rd/501> { 1107 ep="group1" 1108 et="core.rd-group 1109 multicast_address 1110 } 1112 A.4. Discovery Example #2 1114 The following example in CoRAL is analogous to the example in 1115 Section 4.2. 1117 Request: Joining node -> RD 1119 Req: GET coap://rd.example.com/rd-lookup/res 1120 ?rt=core.osc.mbr&sec-gp=feedca570000 1121 Accept: TBD123456 (application/coral+cbor) 1122 Observe: 0 1124 Response: RD -> Joining node 1126 Res: 2.05 Content 1127 Observe: 24 1128 Content-Format: TBD123456 (application/coral+cbor) 1130 Payload: 1131 #base 1132 rd-item { 1133 rt "core.osc.mbr" 1134 sec-gp "feedca570000" 1135 app-gp "group1" 1136 cs_alg -8 1137 cs_alg_crv 6 1138 cs_key_kty 1 1139 cs_key_crv 6 1140 cs_kenc 1 1141 } 1143 Acknowledgments 1145 The authors sincerely thank Carsten Bormann, Klaus Hartke, Francesca 1146 Palombini, Dave Robin and Jim Schaad for their comments and feedback. 1148 The work on this document has been partly supported by VINNOVA and 1149 the Celtic-Next project CRITISEC, and by the EIT-Digital High Impact 1150 Initiative ACTIVE. 1152 Authors' Addresses 1154 Marco Tiloca 1155 RISE AB 1156 Isafjordsgatan 22 1157 Kista SE-16440 Stockholm 1158 Sweden 1160 Email: marco.tiloca@ri.se 1162 Christian Amsuess 1163 Hollandstr. 12/4 1164 Vienna 1020 1165 Austria 1167 Email: christian@amsuess.com 1169 Peter van der Stok 1170 Consultant 1172 Phone: +31-492474673 (Netherlands), +33-966015248 (France) 1173 Email: consultancy@vanderstok.org 1174 URI: www.vanderstok.org