idnits 2.17.1 draft-tiloca-core-oscore-discovery-04.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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 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 (November 04, 2019) is 1634 days in the past. Is this intentional? 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 (-16) exists of draft-ietf-ace-key-groupcomm-oscore-03 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-06 == 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 (-03) exists of draft-dijk-core-groupcomm-bis-01 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-25 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). 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: May 7, 2020 6 P. van der Stok 7 Consultant 8 November 04, 2019 10 Discovery of OSCORE Groups with the CoRE Resource Directory 11 draft-tiloca-core-oscore-discovery-04 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 May 7, 2020. 47 Copyright Notice 49 Copyright (c) 2019 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 Resource for Group Managers . . . . . . . . . . 5 67 3. Registration of Group Manager Endpoints . . . . . . . . . . . 6 68 4. Addition and Update of OSCORE Groups . . . . . . . . . . . . 8 69 5. Discovery of OSCORE Groups . . . . . . . . . . . . . . . . . 9 70 5.1. Discovery Example #1 . . . . . . . . . . . . . . . . . . 10 71 5.2. Discovery Example #2 . . . . . . . . . . . . . . . . . . 11 72 6. Use Case Example With Full Discovery . . . . . . . . . . . . 13 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 75 8.1. Resource Types . . . . . . . . . . . . . . . . . . . . . 17 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 78 9.2. Informative References . . . . . . . . . . . . . . . . . 19 79 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 82 1. Introduction 84 A set of CoAP endpoints constitutes an application group by sharing a 85 common pool of resources. The members of an application group may be 86 members of a given security group, by sharing a common set of keying 87 material to secure group communication. 89 The Constrained Application Protocol (CoAP) [RFC7252] supports group 90 communication over IP multicast 91 [RFC7390][I-D.dijk-core-groupcomm-bis] to improve efficiency and 92 latency of communication and reduce bandwidth requirements. The 93 document Object Security for Constrained RESTful Environments 94 (OSCORE) [RFC8613] describes how to achieve end-to-end security for 95 CoAP messages through CBOR Object Signing and Encryption (COSE) 96 [RFC8152]. 98 In particular, [I-D.ietf-core-oscore-groupcomm] specifies how Group 99 OSCORE protects CoAP messages in group communication contexts, so 100 enabling OSCORE groups as security groups. Typically, one 101 application group relies on exactly one OSCORE group, while a same 102 OSCORE group may be used by multiple application groups at the same 103 time. 105 A CoAP endpoint joins an OSCORE group via a Group Manager (GM), in 106 order to get the necessary group keying material. As in 107 [I-D.ietf-ace-key-groupcomm-oscore], the joining process can be based 108 on the ACE framework for Authentication and Authorization in 109 constrained environments [I-D.ietf-ace-oauth-authz], with the joining 110 endpoint and the GM acting as ACE Client and Resource Server, 111 respectively. That is, the joining endpoint accesses the group- 112 membership resource associated with the OSCORE group to join and 113 exported by the GM. 115 Typically, devices are equipped with a static X509 IDevID certificate 116 installed at manufacturing time. This certificate is used at 117 deployment time during an enrollment process that provides the device 118 with an Operational Certificate, possibly updated during the device 119 lifetime. In the presence of secure group communication for CoAP, 120 such an Operational Certificate may be accompanied by information 121 required to join OSCORE groups. This especially includes a reference 122 to the group-membership resources to access at the respective GMs. 124 However, it is usually impossible to provide such precise information 125 to freshly deployed devices as part of their (early) Operational 126 Certificate. This can be due to a number of reasons: (1) the OSCORE 127 group(s) to join and the responsible GM(s) are generally unknown at 128 manufacturing time; (2) an OSCORE group of interest is created, or 129 the responsible GM is deployed, only after the device is enrolled and 130 fully operative in the network; and (3) information related to 131 existing OSCORE groups or to their GMs has been changed. This 132 requires a method for CoAP endpoints to dynamically discover OSCORE 133 groups and their GM, and to retrieve relevant information about 134 deployed groups. 136 To this end, CoAP endpoints can use descriptions and links of group- 137 membership resources at GMs, in order to discover OSCORE groups and 138 to retrieve the information required for joining them. With the 139 discovery process of OSCORE groups expressed in terms of links to 140 resources, the remaining problem is thus the discovery of those 141 links. The CoRE Resource Directory (RD) 142 [I-D.ietf-core-resource-directory] provides such discovery in an 143 efficient way, and it is expected to be used in many setups that 144 would benefit of OSCORE group discovery. 146 This specification builds on this approach and describes how CoAP 147 endpoints can use the RD to carry out the necessary link discovery 148 steps, in order to discover OSCORE groups of interest and retrieve 149 the information required to join them through their GM. In 150 principle, the GM registers as an endpoint with the RD. The 151 corresponding registration resource includes one link for each OSCORE 152 group under that GM, specifying the path to the related group- 153 membership resource to access for joining that group. 155 More information about the OSCORE group is stored in the target 156 attributes of the respective link. This especially includes the 157 identifiers of the application groups which use that OSCORE group. 158 This enables a lookup of those application groups at the Resource 159 Directory, where they are separately announced by a Commissioning 160 Tool (see Appendix A of [I-D.ietf-core-resource-directory]). 162 When querying the RD for OSCORE groups, a CoAP endpoint can further 163 benefit of the CoAP Observe Option [RFC7641]. This enables the 164 reception of notifications about the creation of new OSCORE groups or 165 the updates concerning existing groups. Thus, it facilitates the 166 early deployment of CoAP endpoints, i.e. even before the GM is 167 deployed and OSCORE groups are created. 169 The approach in this document is consistent with, but not limited to, 170 the joining of OSCORE groups in [I-D.ietf-ace-key-groupcomm-oscore]. 172 1.1. Terminology 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 176 "OPTIONAL" in this document are to be interpreted as described in BCP 177 14 [RFC2119] [RFC8174] when, and only when, they appear in all 178 capitals, as shown here. 180 This specification requires readers to be familiar with the terms and 181 concepts discussed in [I-D.ietf-core-resource-directory] and 182 [RFC6690]. Readers should also be familiar with the terms and 183 concepts discussed in [RFC7252], [I-D.ietf-core-oscore-groupcomm] and 184 [I-D.ietf-ace-key-groupcomm-oscore]. 186 Terminology for constrained environments, such as "constrained 187 device" and "constrained-node network", is defined in [RFC7228]. 189 This document also refers to the following terminology. 191 o OSCORE group: a set of CoAP endpoints that share one OSCORE Common 192 Security Context to protect group communication as described in 193 [I-D.ietf-core-oscore-groupcomm]. Consequently, an OSCORE group 194 acts as security group for all its members. 196 o Application group: a set of CoAP endpoints that share a set of 197 common resources. Application groups are announced in the RD by a 198 Commissioning Tool, according to the RD-Groups usage pattern (see 199 Appendix A of [I-D.ietf-core-resource-directory]). An application 200 group can be associated with a single OSCORE group, while multiple 201 application groups can use the same OSCORE group. Application 202 groups share resources by definition. Any two application groups 203 associated to the same OSCORE group do not share any same 204 resource. 206 2. Registration Resource for Group Managers 208 With reference to Figure 3 of [I-D.ietf-core-resource-directory], a 209 Group Manager (GM) registers as an endpoint with the CoRE Resource 210 Directory (RD). The registration includes the links to the group- 211 membership resources located at the GM, and associated to the OSCORE 212 groups administrated by that GM. 214 In particular, each link to a group-membership resource includes: 216 o "target": URI of the group-membership resource at the GM. 218 o target attributes, including: 220 * Resource Type (rt) with the value "core.osc.mbr" defined in 221 Section 8.1 of this specification. 223 * The name of the OSCORE group, as defined in 224 [I-D.ietf-ace-key-groupcomm-oscore]. 226 * One target attribute for each application group associated with 227 the OSCORE group, specifying the name of that application 228 group. 230 * The algorithm used to countersign messages in the OSCORE group. 232 * The elliptic curve (if applicable) for the algorithm used to 233 countersign messages in the OSCORE group. 235 * The key type of countersignature keys used to countersign 236 messages in the OSCORE group. 238 * The encoding of public keys used in the OSCORE group. 240 * The AEAD algorithm used in the OSCORE group. 242 * The HKDF algorithm used in the OSCORE group. 244 3. Registration of Group Manager Endpoints 246 During deployment, a GM finds the RD as described in Section 4 of 247 [I-D.ietf-core-resource-directory]. Afterwards, the GM registers as 248 an endpoint with the RD, as described in Section 5 of 249 [I-D.ietf-core-resource-directory]. 251 When doing so, the GM also registers all the group-membership 252 resources it has at that point in time, i.e. one for each of its 253 OSCORE groups. 255 For each registered group-membership resource, the GM includes the 256 following parameters in the payload of the registration request. 258 o 'rt' = "core.osc.mbr" (see Section 8.1). 260 o 'sec-gp', specifying the name of the OSCORE group of interest. 261 This parameter MUST specify a single value. 263 o 'app-gp', specifying the name(s) of the application group(s) 264 associated to the OSCORE group of interest indicated by 'sec-gp'. 265 This parameter MAY be included multiple times, and each occurrence 266 MUST specify the name of one application group. A same 267 application group MUST NOT be specified multiple times. 269 Also, for each registered group-membership resource, the GM may 270 additionally include the following parameters in the payload of the 271 registration request. 273 o 'cs_alg', specifying the algorithm used to countersign messages in 274 the OSCORE group. If present, this parameter MUST specify a 275 single value encoded as a text string, which is taken from the 276 'Value' column of the "COSE Algorithms" Registry defined in 277 [RFC8152]. 279 o 'cs_crv', specifying the elliptic curve (if applicable) for the 280 algorithm used to countersign messages in the OSCORE group. If 281 present, this parameter MUST specify a single value encoded as a 282 text string, which is taken from the 'Value' column of the "COSE 283 Elliptic Curve" Registry defined in [RFC8152]. 285 o 'cs_kty', specifying the key type of countersignature keys used to 286 countersign messages in the OSCORE group. If present, this 287 parameter MUST specify a single value encoded as a text string, 288 which is taken from the 'Value' column of the "COSE Key Types" 289 Registry defined in [RFC8152]. 291 o 'cs_kenc', specifying the encoding of the public keys used in the 292 OSCORE group. If present, this parameter MUST specify a single 293 value encoded as a text string. This specification explicitly 294 admits the signaling of COSE Keys [RFC8152] as encoding for public 295 keys, which is indicated with "1", as taken from the 'Confirmation 296 Key' column of the "CWT Confirmation Method" Registry defined in 297 [I-D.ietf-ace-cwt-proof-of-possession]. Future specifications may 298 define additional values for this parameter. 300 o 'alg', specifying the AEAD algorithm used in the OSCORE group. If 301 present, this parameter MUST specify a single value encoded as a 302 text string, which is taken from the 'Value' column of the "COSE 303 Algorithms" Registry defined in [RFC8152]. 305 o 'hkdf', specifying the HKDF algorithm used in the OSCORE group. 306 If present, this parameter MUST specify a single value encoded as 307 a text string, which is taken from the 'Value' column of the "COSE 308 Algorithms" Registry defined in [RFC8152]. 310 Values registered as a string that looks like an integer are not 311 supported by this approach. Therefore, they MUST NOT be advertised 312 through the corresponding parameters above. 314 A CoAP endpoint that queries the RD to discover OSCORE groups and 315 their group-membership resource to access (see Section 5) would 316 benefit from the information above as follows. 318 o The values of 'cs_alg', 'cs_crv', 'cs_kty' and 'cs_kenc' related 319 to a group-membership resource provide an early knowledge of the 320 format and encoding of public keys used in the OSCORE group. 321 Thus, the CoAP endpoint does not need to ask the GM for this 322 information as a preliminary step before the joining process, or 323 to perform a trial-and-error exchange with the GM. Hence, the 324 CoAP endpoint is able to provide the GM with its own public key in 325 the correct expected format and encoding at the very first step of 326 the joining process. 328 o The values of 'cs_alg', 'alg' and 'hkdf' related to a group- 329 membership resource provide an early knowledge of the algorithms 330 used in the OSCORE group. Thus, the CoAP endpoint is able to 331 decide whether to actually proceed with the joining process, 332 depending on its support for the indicated algorithms. 334 The GM SHOULD NOT use the Simple Registration approach described in 335 Section 5.1 of [I-D.ietf-core-resource-directory]. 337 The example below shows a GM with endpoint name "gm1" and address 338 2001:db8::ab that registers with the RD. The GM specifies the value 339 of the 'sec-gp' parameter for accessing the OSCORE group with name 340 "feedca570000" and used by the application group with name "group1" 341 specified with the value of the 'app-gp' parameter. The 342 countersignature algorithm used in the OSCORE group is EdDSA, with 343 elliptic curve Ed25519 and keys of type OKP. Public keys used in the 344 OSCORE group are encoded as COSE Keys [RFC8152]. 346 Request: GM -> RD 348 Req: POST coap://rd.example.com/rd?ep=gm1 349 Content-Format: 40 350 Payload: 351 ;ct=41;rt="core.osc.mbr"; 352 sec-gp="feedca570000";app-gp="group1"; 353 cs_alg="-8";cs_crv="6";cs_kty="1"; 354 cs_kenc="1" 356 Response: RD -> GM 358 Res: 2.01 Created 359 Location-Path: /rd/4521 361 4. Addition and Update of OSCORE Groups 363 The GM is responsible to refresh the registration of all its group- 364 membership resources in the RD. This means that the GM has to update 365 the registration within its lifetime as per Section 5.3.1 of 366 [I-D.ietf-core-resource-directory], and has to change the content of 367 the registration when a group-membership resource is added/removed or 368 if its target attributes have to be changed, such as in the following 369 cases. 371 o The GM creates a new OSCORE group and starts exporting the related 372 group-membership resource. 374 o The GM dismisses an OSCORE group and stops exporting the related 375 group-membership resource. 377 o Information related to an existing OSCORE group changes, e.g. the 378 list of associated application groups. 380 To perform an update of its registrations, the GM can re-register 381 with the RD and fully specify all links to its group-membership 382 resources with their target attributes. 384 The example below shows how the GM from Section 3 re-registers with 385 the RD. When doing so, it specifies: 387 o The same previous group-membership resource associated to the 388 OSCORE group with name "feedca570000". 390 o An additional group-membership resource associated to the OSCORE 391 group with name "ech0ech00000" and used by the application group 392 "group2". 394 o A third group-membership resource associated with the OSCORE group 395 with name "abcdef120000" and used by two application groups, 396 namely "group3" and "group4". 398 Request: GM -> RD 400 Req: POST coap://rd.example.com/rd?ep=gm1 401 Content-Format: 40 402 Payload: 403 ;ct=41;rt="core.osc.mbr"; 404 sec-gp="feedca570000";app-gp="group1"; 405 cs_alg="-8";cs_crv="6";cs_kty="1"; 406 cs_kenc="1", 407 ;ct=41;rt="core.osc.mbr"; 408 sec-gp="ech0ech00000";app-gp="group2"; 409 cs_alg="-8";cs_crv="6";cs_kty="1"; 410 cs_kenc="1", 411 ;ct=41;rt="core.osc.mbr"; 412 sec-gp="abcdef120000";app-gp="group3"; 413 app-gp="group4";cs_alg="-8"; 414 cs_crv="6";cs_kty="1";cs_kenc="1" 416 Response: RD -> GM 418 Res: 2.04 Changed 419 Location-Path: /rd/4521 421 Alternatively, the GM can perform a PATCH/iPATCH [RFC8132] request to 422 the RD, as per Section 5.3.3 of [I-D.ietf-core-resource-directory]. 423 This requires new media-types to be defined in future standards, to 424 apply a link-format document as a patch to an existing stored 425 document. 427 5. Discovery of OSCORE Groups 429 A CoAP endpoint that wants to join an OSCORE group, hereafter called 430 the joining node, might not have all the necessary information at 431 deployment time. Also, it might want to know about possible new 432 OSCORE groups created afterwards by the respective Group Managers. 434 To this end, the joining node can perform a resource lookup at the RD 435 as per Section 6.1 of [I-D.ietf-core-resource-directory], to retrieve 436 the missing pieces of information needed to join the OSCORE group(s) 437 of interest. The joining node can find the RD as described in 438 Section 4 of [I-D.ietf-core-resource-directory]. 440 The joining node uses the following parameter value for the lookup 441 filtering. 443 o 'rt' = "core.osc.mbr" (see Section 8.1). 445 The joining node may additionally consider the following parameters 446 for the lookup filtering, depending on the information it has already 447 available. 449 o 'sec-gp', specifying the name of the OSCORE group of interest. 450 This parameter MUST specify a single value. 452 o 'ep', specifying the registered endpoint of the GM. 454 o 'app-gp', specifying the name(s) of the application group(s) 455 associated with the OSCORE group of interest. This parameter MAY 456 be included multiple times, and each occurrence MUST specify the 457 name of one application group. A same application group MUST NOT 458 be specified multiple times. 460 Note that, with RD-based discovery, including the 'app-gp' parameter 461 multiple times would result in finding only the group-membership 462 resource that serves all the specified application groups, i.e. not 463 any group-membership resource that serves either. Therefore, a 464 joining node needs to perform N separate queries with different 465 values for 'app-gp', in order to safely discover the (different) 466 group-membership resource(s) serving the N application groups. 468 5.1. Discovery Example #1 470 Consistently with the examples in Section 3 and Section 4, the 471 example below considers a joining node that wants to join the OSCORE 472 group associated with the application group "group1", but that does 473 not know the name of the OSCORE group, the responsible GM and the 474 group-membership resource to access. 476 Request: Joining node -> RD 477 Req: GET coap://rd.example.com/rd-lookup/res 478 ?rt=core.osc.mbr&app-gp=group1 480 Response: RD -> Joining node 482 Res: 2.05 Content 483 Payload: 484 ;rt="core.osc.mbr"; 485 sec-gp="feedca570000";app-gp="group1"; 486 cs_alg="-8";cs_crv="6";cs_kty="1"; 487 cs_kenc="1";anchor="coap://[2001:db8::ab]" 489 To retrieve the multicast IP address used in "group1", the joining 490 node performs an endpoint lookup as shown below. The following 491 assumes that the application group "group1" had been previously 492 registered as per Appendix A of [I-D.ietf-core-resource-directory], 493 with ff35:30:2001:db8::23 as associated multicast IP address. 495 Request: Joining node -> RD 497 Req: GET coap://rd.example.com/rd-lookup/ep 498 ?et=core.rd-group&ep=group1 500 Response: RD -> Joining node 502 Res: 2.05 Content 503 Payload: 504 ;ep="group1";et="core.rd-group"; 505 base="coap://[ff35:30:2001:db8::23]" 507 5.2. Discovery Example #2 509 Consistently with the examples in Section 3 and Section 4, the 510 example below considers a joining node that wants to join the OSCORE 511 group with name "feedca570000", but that does not know the 512 responsible GM, the group-membership resource to access, and the 513 associated application groups. 515 The example also shows how the joining node uses CoAP observation 516 [RFC7641], in order to be notified of possible changes to the target 517 attributes of the group-membership resource. This is also useful to 518 handle the case where the OSCORE group of interest has not been 519 created yet, so that the joining node can receive the requested 520 information when it becomes available. 522 Request: Joining node -> RD 523 Req: GET coap://rd.example.com/rd-lookup/res 524 ?rt=core.osc.mbr&sec-gp=feedca570000 525 Observe: 0 527 Response: RD -> Joining node 529 Res: 2.05 Content 530 Observe: 24 531 Payload: 532 ;rt="core.osc.mbr"; 533 sec-gp="feedca570000";app-gp="group1"; 534 cs_alg="-8";cs_crv="6";cs_kty="1"; 535 cs_kenc="1";anchor="coap://[2001:db8::ab]" 537 Depending on the search criteria, the joining node performing the 538 resource lookup can get large responses. This can happen, for 539 instance, when the lookup request targets all the group-membership 540 resources at a specified GM, or all the group-membership resources of 541 all the registered GMs, as in the example below. 543 Request: Joining node -> RD 545 Req: GET coap://rd.example.com/rd-lookup/res?rt=core.osc.mbr 547 Response: RD -> Joining node 549 Res: 2.05 Content 550 Payload: 551 ;rt="core.osc.mbr"; 552 sec-gp="feedca570000";app-gp="group1"; 553 cs_alg="-8";cs_crv="6";cs_kty="1"; 554 cs_kenc="1";anchor="coap://[2001:db8::ab]", 555 ;rt="core.osc.mbr"; 556 sec-gp="ech0ech00000";app-gp="group2"; 557 cs_alg="-8";cs_crv="6";cs_kty="1"; 558 cs_kenc="1";anchor="coap://[2001:db8::ab]", 559 ;rt="core.osc.mbr"; 560 sec-gp="abcdef120000";app-gp="group3"; 561 app-gp="group4";cs_alg="-8";cs_crv="6"; 562 cs_kty="1";cs_kenc="1";anchor="coap://[2001:db8::ab]" 564 Therefore, it is RECOMMENDED that a joining node which performs a 565 resource lookup with the CoAP Observe option specifies the value of 566 the parameter 'sec-gp' in its GET request sent to the RD. 568 6. Use Case Example With Full Discovery 570 In this section, the discovery of security groups is described to 571 support the installation process of a lighting installation in an 572 office building. The described process is a simplified version of 573 one of many processes. 575 Assume the existence of four luminaires that are members of two 576 application groups. In the first application group, the four 577 luminaires receive presence messages and light intensity messages 578 from sensors or their proxy. In the second application group, the 579 four luminaires and several other pieces of equipment receive 580 building state schedules. 582 Each of the two application groups is associated to a different 583 security group and uses its own dedicated multicast IP address. 585 The Fairhair Alliance describes how a new device is accepted and 586 commissioned in the network [Fairhair], by means of its certificate 587 stored during the manufacturing process. When commissioning the new 588 device in the installation network, the new device gets a new 589 identity defined by a newly allocated certificate, following the 590 BRSKI specification. 592 Section 7.3 of [I-D.ietf-core-resource-directory] describes how the 593 Commissioning Tool (CT) assigns an endpoint name based on the CN 594 field, (CN=ACME) and the serial number of the certificate (serial 595 number = 123x, with 3 < x < 8). Corresponding ep-names ACME-1234, 596 ACME-1235, ACME-1236 and ACME-1237 are also assumed. 598 It is common practice that locations in the building are specified 599 according to a coordinate system. After the acceptance of the 600 luminaires into the installation network, the coordinate of each 601 device is communicated to the CT. This can be done manually or 602 automatically. 604 The mapping between location and ep-name is calculated by the CT. 605 For instance, on the basis of grouping criteria, the CT assigns: i) 606 application group "grp_R2-4-015" to the four luminaires; and ii) 607 application group "grp_schedule" to all schedule requiring devices. 608 Also, the device with ep name ACME-123x has been assigned IP address: 609 [2001:db8:4::x]. The RD is assigned IP address: [2001:db8:4:ff]. 610 The used multicast addresses are: [ff05::5:1] and [ff05::5:2]. 612 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 614 The CT defines the application group "grp_R2-4-015", with resource 615 /light and base address [ff05::5:1], as follows. 617 Request: CT -> RD 619 Req: POST coap://[2001:db8:4::ff]/rd 620 ?ep=grp_R2-4-015&et=core.rd-group&base=coap://[ff05::5:1] 621 Payload: 622 ;rt="oic.d.light" 624 Response: RD -> CT 626 Res: 2.01 Created 627 Location-Path: /rd/501 629 Also, the CT defines a second application group "grp_schedule", with 630 resource /schedule and base address [ff05::5:2], as follows. 632 Request: CT -> RD 634 Req: POST coap://[2001:db8:4::ff]/rd 635 ?ep=grp_schedule&et=core.rd-group&base=coap://[ff05::5:2] 636 Payload: 637 ;rt="oic.r.time.period" 639 Response: RD -> CT 641 Res: 2.01 Created 642 Location-Path: /rd/502 644 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 646 Consecutively, the CT registers the four devices in the RD (IP 647 address: 2001:db8:4::ff), with their endpoint names and application 648 groups. 650 For the application group "grp_R2-4-015", four endpoints are 651 specified as follows, with x = 4, 5, 6, 7. 653 Request: CT -> RD 655 Req: POST coap://[2001:db8:4::ff]/rd 656 ?ep=ACME-123x&base=coap://[2001:db8:4::x]&app-gp=grp_R2-4-015 657 Payload: 658 ;rt="oic.d.light" 660 Response: RD -> CT 662 Res: 2.01 Created 663 Location-Path: /rd/452x 664 For the application group "grp_schedule", four other endpoints are 665 specified as follows, with x = 4, 5, 6, 7. 667 Request: CT -> RD 669 Req: POST coap://[2001:db8:4::ff]/rd 670 ?ep=ACME-123x&base=coap://[2001:db8:4::x]&app-gp=grp_schedule 671 Payload: 672 ;rt="oic.r.time.period" 674 Response: RD -> CT 676 Res: 2.01 Created 677 Location-Path: /rd/456x 679 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 681 Finally, the CT defines the corresponding security groups. In 682 particular, assuming a Group Manager responsible for both security 683 groups and with address [2001:db8::ab], the CT specifies: 685 Request: CT -> RD 687 Req: POST coap://[2001:db8:4::ff]/rd?ep=gm1&base=coap://[2001:db8::ab] 688 Payload: 689 ;ct=41;rt="core.osc.mbr"; 690 sec-gp="feedca570000";app-gp="grp_R2-4-015", 691 ;ct=41;rt="core.osc.mbr"; 692 sec-gp="feedsc590000";app-gp="grp_schedule" 694 Response: RD -> CT 696 Res: 2.01 Created 697 Location-Path: /rd/4521 699 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 701 The device with IP address [2001:db8:4::x] can consequently learn the 702 groups to which it belongs. In particular, it first does an ep 703 lookup to the RD to learn the application groups to which it belongs. 705 Request: Joining node -> RD 707 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 708 ?base=coap://[2001:db8:4::x] 710 Response: RD -> Joining node 711 Res: 2.05 Content 712 Payload: 713 ;base=coap://[2001:db8:4::x]&ep=ACME-123x&\ 714 app-gp=grp_R2-4-015, 715 ;base=coap://[2001:db8:4::x]&ep=ACME-123x&\ 716 app-gp=grp_schedule 718 To retrieve the multicast IP address used in "grp_R2-4-015", the 719 device performs an endpoint lookup as shown below. 721 Request: Joining node -> RD 723 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 724 ?et=core.rd-group&ep=grp_R2-4-015 726 Response: RD -> Joining node 728 Res: 2.05 Content 729 Payload: 730 ;ep="grp_R2-4-015";et="core.rd-group"; 731 base="coap://[ff05::5:1]" 733 Similarly, to retrieve the multicast IP address used in 734 "grp_schedule", the device performs an endpoint lookup as shown 735 below. 737 Request: Joining node -> RD 739 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 740 ?et=core.rd-group&ep=grp_schedule 742 Response: RD -> Joining node 744 Res: 2.05 Content 745 Payload: 746 ;ep="grp_schedule";et="core.rd-group"; 747 base="coap://[ff05::5:2]" 749 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 751 Having learnt the application groups to which the device belongs, the 752 device learns the security groups to which it belongs. In 753 particular, it does the following for app-gp="grp_R2-4-015". 755 Request: Joining node -> RD 757 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 758 ?rt=core.osc.mbr&app-gp=grp_R2-4-015 760 Response: RD -> Joining Node 762 Res: 2.05 Content 763 Payload: 764 ; 765 rt="core.osc.mbr";sec-gp="feedca570000"; 766 app-gp="grp_R2-4-015";anchor="coap://[2001:db8::ab]" 768 Similarly, the device does the following for app-gp="grp_schedule". 770 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 771 ?rt=core.osc.mbr&app-gp=grp_schedule 773 Response: RD -> Joining Node 775 Res: 2.05 Content 776 Payload: 777 ; 778 rt="core.osc.mbr";sec-gp="feedsc590000"; 779 app-gp="grp_schedule";anchor="coap://[2001:db8::ab]" 781 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 783 After this last discovery step, the device can ask permission to join 784 the security groups, and effectively join them through the Group 785 Manager, e.g. according to [I-D.ietf-ace-key-groupcomm-oscore]. 787 7. Security Considerations 789 The security considerations as described in Section 8 of 790 [I-D.ietf-core-resource-directory] apply here as well. 792 8. IANA Considerations 794 This document has the following actions for IANA. 796 8.1. Resource Types 798 IANA is asked to enter the following value into the Resource Type 799 (rt=) Link Target Attribute Values subregistry within the Constrained 800 Restful Environments (CoRE) Parameters registry defined in [RFC6690]. 802 +--------------+----------------------------+-------------------+ 803 | Value | Description | Reference | 804 +--------------+----------------------------+-------------------+ 805 | | | | 806 | core.osc.mbr | Group-membership resource | [[this document]] | 807 | | of an OSCORE Group Manager | | 808 | | | | 809 +--------------+----------------------------+-------------------| 811 9. References 813 9.1. Normative References 815 [I-D.ietf-ace-cwt-proof-of-possession] 816 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 817 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 818 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 819 possession-11 (work in progress), October 2019. 821 [I-D.ietf-ace-key-groupcomm-oscore] 822 Tiloca, M., Park, J., and F. Palombini, "Key Management 823 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 824 oscore-03 (work in progress), November 2019. 826 [I-D.ietf-core-oscore-groupcomm] 827 Tiloca, M., Selander, G., Palombini, F., and J. Park, 828 "Group OSCORE - Secure Group Communication for CoAP", 829 draft-ietf-core-oscore-groupcomm-06 (work in progress), 830 November 2019. 832 [I-D.ietf-core-resource-directory] 833 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 834 Amsuess, "CoRE Resource Directory", draft-ietf-core- 835 resource-directory-23 (work in progress), July 2019. 837 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 838 Requirement Levels", BCP 14, RFC 2119, 839 DOI 10.17487/RFC2119, March 1997, 840 . 842 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 843 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 844 . 846 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 847 Application Protocol (CoAP)", RFC 7252, 848 DOI 10.17487/RFC7252, June 2014, 849 . 851 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 852 RFC 8152, DOI 10.17487/RFC8152, July 2017, 853 . 855 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 856 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 857 May 2017, . 859 9.2. Informative References 861 [Fairhair] 862 FairHair Alliance, "Security Architecture for the Internet 863 of Things (IoT) in Commercial Buildings", White Paper, ed. 864 Piotr Polak , March 2018, . 868 [I-D.dijk-core-groupcomm-bis] 869 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 870 for the Constrained Application Protocol (CoAP)", draft- 871 dijk-core-groupcomm-bis-01 (work in progress), July 2019. 873 [I-D.ietf-ace-oauth-authz] 874 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 875 H. Tschofenig, "Authentication and Authorization for 876 Constrained Environments (ACE) using the OAuth 2.0 877 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-25 878 (work in progress), October 2019. 880 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 881 Constrained-Node Networks", RFC 7228, 882 DOI 10.17487/RFC7228, May 2014, 883 . 885 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 886 the Constrained Application Protocol (CoAP)", RFC 7390, 887 DOI 10.17487/RFC7390, October 2014, 888 . 890 [RFC7641] Hartke, K., "Observing Resources in the Constrained 891 Application Protocol (CoAP)", RFC 7641, 892 DOI 10.17487/RFC7641, September 2015, 893 . 895 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 896 FETCH Methods for the Constrained Application Protocol 897 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 898 . 900 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 901 "Object Security for Constrained RESTful Environments 902 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 903 . 905 Acknowledgments 907 The authors sincerely thank Carsten Bormann, Klaus Hartke, Francesca 908 Palombini, Dave Robin and Jim Schaad for their comments and feedback. 910 The work on this document has been partly supported by VINNOVA and 911 the Celtic-Next project CRITISEC, and by the EIT-Digital High Impact 912 Initiative ACTIVE. 914 Authors' Addresses 916 Marco Tiloca 917 RISE AB 918 Isafjordsgatan 22 919 Kista SE-16440 Stockholm 920 Sweden 922 Email: marco.tiloca@ri.se 924 Christian Amsuess 925 Hollandstr. 12/4 926 Vienna 1020 927 Austria 929 Email: christian@amsuess.com 931 Peter van der Stok 932 Consultant 934 Phone: +31-492474673 (Netherlands), +33-966015248 (France) 935 Email: consultancy@vanderstok.org 936 URI: www.vanderstok.org