idnits 2.17.1 draft-tiloca-core-oscore-discovery-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 02, 2020) is 1268 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-02 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-10 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-25 ** 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-14 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' == Outdated reference: A later version (-18) exists of draft-ietf-ace-key-groupcomm-10 == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-09 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-35 == Outdated reference: A later version (-11) exists of draft-ietf-ace-oscore-gm-admin-01 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-44 Summary: 1 error (**), 0 flaws (~~), 12 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: May 6, 2021 6 P. van der Stok 7 Consultant 8 November 02, 2020 10 Discovery of OSCORE Groups with the CoRE Resource Directory 11 draft-tiloca-core-oscore-discovery-07 13 Abstract 15 Group communication over the Constrained Application Protocol (CoAP) 16 can be secured by means of Group Object Security for Constrained 17 RESTful Environments (Group OSCORE). At deployment time, devices may 18 not know the exact security groups to join, the respective Group 19 Manager, or other information required to perform the joining 20 process. This document describes how a CoAP endpoint can use 21 descriptions and links of resources registered at the CoRE Resource 22 Directory to discover security groups and to acquire information for 23 joining them through the respective Group Manager. A given security 24 group may protect multiple application groups, which are separately 25 announced in the Resource Directory as sets of endpoints sharing a 26 pool of resources. This approach is consistent with, but not limited 27 to, the joining of security groups based on the ACE framework for 28 Authentication and Authorization in constrained environments. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 6, 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 . . . . . . . . . . . . . . . . . . . . . . . 5 66 2. Registration of Group Manager Endpoints . . . . . . . . . . . 6 67 2.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.2. Relation Link to Authorization Server . . . . . . . . . . 9 69 2.3. Registration Example . . . . . . . . . . . . . . . . . . 9 70 2.3.1. Example in Link Format . . . . . . . . . . . . . . . 10 71 2.3.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 10 72 3. Addition and Update of Security Groups . . . . . . . . . . . 11 73 3.1. Addition Example . . . . . . . . . . . . . . . . . . . . 11 74 3.1.1. Example in Link Format . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . 18 81 4.2.1. Example in Link Format . . . . . . . . . . . . . . . 18 82 4.2.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 19 83 5. Use Case Example With Full Discovery . . . . . . . . . . . . 20 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 24 88 8.2. Informative References . . . . . . . . . . . . . . . . . 26 89 Appendix A. Use Case Example With Full Discovery (CoRAL) . . . . 27 90 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 93 1. Introduction 95 The Constrained Application Protocol (CoAP) [RFC7252] supports group 96 communication over IP multicast [I-D.ietf-core-groupcomm-bis] to 97 improve efficiency and latency of communication and reduce bandwidth 98 requirements. A set of CoAP endpoints constitutes an application 99 group by sharing a common pool of resources, that can be efficiently 100 accessed through group communication. The members of an application 101 group may be members of a security group, thus sharing a common set 102 of keying material to secure group communication. 104 The security protocol Group Object Security for Constrained RESTful 105 Environments (Group OSCORE) [I-D.ietf-core-oscore-groupcomm] builds 106 on OSCORE [RFC8613] and protects CoAP messages end-to-end in group 107 communication contexts through CBOR Object Signing and Encryption 108 (COSE) 109 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs]. An 110 application group may rely on one or more security groups, and a same 111 security group may be used by multiple application groups at the same 112 time. 114 A CoAP endpoint relies on a Group Manager (GM) to join a security 115 group and get the group keying material. The joining process in 116 [I-D.ietf-ace-key-groupcomm-oscore] is based on the ACE framework for 117 Authentication and Authorization in constrained environments 118 [I-D.ietf-ace-oauth-authz], with the joining endpoint and the GM 119 acting as ACE Client and Resource Server, respectively. That is, the 120 joining endpoint accesses the group-membership resource exported by 121 the GM and associated with the security group to join. 123 Typically, devices store a static X509 IDevID certificate installed 124 at manufacturing time [I-D.ietf-anima-bootstrapping-keyinfra]. This 125 is used at deployment time during an enrollment process that provides 126 the devices with an Operational Certificate, possibly updated during 127 the device lifetime. Operational Certificates may specify 128 information to join security groups, especially a reference to the 129 group-membership resources to access at the respective GMs. 131 However, it is usually impossible to provide such precise information 132 to freshly deployed devices, as part of their (early) Operational 133 Certificate. This can be due to a number of reasons: (1) the 134 security group(s) to join and the responsible GM(s) are generally 135 unknown at manufacturing time; (2) a security group of interest is 136 created, or the responsible GM is deployed, only after the device is 137 enrolled and fully operative in the network; (3) information related 138 to existing security groups or to their GMs has changed. This 139 requires a method for CoAP endpoints to dynamically discover security 140 groups and their GM, and to retrieve relevant information about 141 deployed groups. 143 To this end, CoAP endpoints can use descriptions and links of group- 144 membership resources at GMs, to discover security groups and retrieve 145 the information required for joining them. With the discovery 146 process of security groups expressed in terms of links to resources, 147 the remaining problem is the discovery of those links. The CoRE 148 Resource Directory (RD) [I-D.ietf-core-resource-directory] allows 149 such discovery in an efficient way, and it is expected to be used in 150 many setups that would benefit of security group discovery. 152 This specification builds on this approach and describes how CoAP 153 endpoints can use the RD to perform the link discovery steps, in 154 order to discover security groups and retrieve the information 155 required to join them through their GM. In short, the GM registers 156 as an endpoint with the RD. The resulting registration resource 157 includes one link per security group under that GM, specifying the 158 path to the related group-membership resource to access for joining 159 that group. 161 Additional descriptive information about the security group is stored 162 with the registered link. In a RD based on Link Format [RFC6690] as 163 defined in [I-D.ietf-core-resource-directory], this information is 164 specified as target attributes of the registered link, and includes 165 the identifiers of the application groups which use that security 166 group. This enables a lookup of those application groups at the RD, 167 where they are separately announced by a Commissioning Tool (see 168 Appendix A of [I-D.ietf-core-resource-directory]). 170 When querying the RD for security groups, a CoAP endpoint can use 171 CoAP observation [RFC7641]. This results in automatic notifications 172 on the creation of new security groups or the update of existing 173 groups. Thus, it facilitates the early deployment of CoAP endpoints, 174 i.e. even before the GM is deployed and security groups are created. 176 Interaction examples are provided in Link Format, as well as in the 177 Constrained RESTful Application Language CoRAL [I-D.ietf-core-coral] 178 with reference to a CoRAL-based RD [I-D.hartke-t2trg-coral-reef]. 179 While all the CoRAL examples use the CoRAL textual serialization 180 format, the CBOR [I-D.ietf-cbor-7049bis] or JSON [RFC8259] binary 181 serialization format is used when sending such messages on the wire. 183 The approach in this document is consistent with, but not limited to, 184 the joining of security groups defined in 185 [I-D.ietf-ace-key-groupcomm-oscore]. 187 1.1. Terminology 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 191 "OPTIONAL" in this document are to be interpreted as described in BCP 192 14 [RFC2119] [RFC8174] when, and only when, they appear in all 193 capitals, as shown here. 195 This specification requires readers to be familiar with the terms and 196 concepts discussed in [I-D.ietf-core-resource-directory] and 197 [RFC6690], as well as in [I-D.ietf-core-coral]. Readers should also 198 be familiar with the terms and concepts discussed in 199 [RFC7252][I-D.ietf-core-groupcomm-bis], 200 [I-D.ietf-core-oscore-groupcomm] and 201 [I-D.ietf-ace-key-groupcomm-oscore]. 203 Terminology for constrained environments, such as "constrained 204 device" and "constrained-node network", is defined in [RFC7228]. 206 Consistently with the definitions from Section 2.1 of 207 [I-D.ietf-core-groupcomm-bis], this document also refers to the 208 following terminology. 210 o CoAP group: a set of CoAP endpoints all configured to receive CoAP 211 multicast messages sent to the group's associated IP multicast 212 address and UDP port. An endpoint may be a member of multiple 213 CoAP groups by subscribing to multiple IP multicast addresses. 215 o Security group: a set of CoAP endpoints that share the same 216 security material, and use it to protect and verify exchanged 217 messages. A CoAP endpoint may be a member of multiple security 218 groups. There can be a one-to-one or a one-to-many relation 219 between security groups and CoAP groups. 221 This document especially considers a security group to be an 222 OSCORE group, where all members share one OSCORE Security Context 223 to protect group communication with Group OSCORE 224 [I-D.ietf-core-oscore-groupcomm]. However, the approach defined 225 in this document can be used to support the discovery of different 226 security groups than OSCORE groups. 228 o Application group: a set of CoAP endpoints that share a common set 229 of resources. An endpoint may be a member of multiple application 230 groups. An application group can be associated with one or more 231 security groups, and multiple application groups can use the same 232 security group. Application groups are announced in the RD by a 233 Commissioning Tool, according to the RD-Groups usage pattern (see 234 Appendix A of [I-D.ietf-core-resource-directory]). 236 2. Registration of Group Manager Endpoints 238 During deployment, a Group Manager (GM) can find the CoRE Resource 239 Directory (RD) as described in Section 4 of 240 [I-D.ietf-core-resource-directory]. 242 Afterwards, the GM registers as an endpoint with the RD, as described 243 in Section 5 of [I-D.ietf-core-resource-directory]. The GM SHOULD 244 NOT use the Simple Registration approach described in Section 5.1 of 245 [I-D.ietf-core-resource-directory]. 247 When registering with the RD, the GM also registers the links to all 248 the group-membership resources it has at that point in time, i.e. one 249 for each of its security groups. 251 In the registration request, each link to a group-membership resource 252 has as target the URI of that resource at the GM. Also, it specifies 253 a number of descriptive parameters as defined in Section 2.1. 255 2.1. Parameters 257 For each registered link to a group-membership resource at a GM, the 258 following parameters are specified together with the link. 260 In the RD defined in [I-D.ietf-core-resource-directory] and based on 261 Link Format, each parameter is specified in a target attribute with 262 the same name. 264 In a RD based on CoRAL, such as the one defined in 265 [I-D.hartke-t2trg-coral-reef], each parameter is specified in a 266 nested element with the same name. 268 o 'rt', specifying the resource type of the group-membership 269 resource at the Group Manager, with value "core.osc.gm" registered 270 in Section 21.11 of [I-D.ietf-ace-key-groupcomm-oscore]. 272 o 'if', specifying the interface description for accessing the 273 group-membership resource at the Group Manager, with value 274 "ace.group" registered in Section 8.10 of 275 [I-D.ietf-ace-key-groupcomm]. 277 o 'sec-gp', specifying the name of the security group of interest, 278 as a stable and invariant identifier, such as the group name used 279 in [I-D.ietf-ace-key-groupcomm-oscore]. This parameter MUST 280 specify a single value. 282 o 'app-gp', specifying the name(s) of the application group(s) 283 associated to the security group of interest indicated by 'sec- 284 gp'. This parameter MUST occur once for each application group, 285 and MUST specify only a single application group. 287 When a security group is created at the GM, the names of the 288 application groups using it are also specified as part of the 289 security group configuration (see [I-D.ietf-ace-oscore-gm-admin]). 290 Thus, when registering the links to its group-membership resource, 291 the GM is aware of the application groups and their names. 293 If a different entity than the GM registers the security groups to 294 the RD, e.g. a Commissioning Tool, this entity has to also be 295 aware of the application groups and their names to specify. To 296 this end, it can obtain them from the GM or from the Administator 297 that created the security groups at the GM (see 298 [I-D.ietf-ace-oscore-gm-admin]). 300 Optionally, the following parameters can also be specified. 302 o 'cs_alg', specifying the algorithm used to countersign messages in 303 the security group. If present, this parameter MUST specify a 304 single value encoded as a text string, which is taken from the 305 'Value' column of the "COSE Algorithms" Registry 306 [COSE.Algorithms]. 308 o 'cs_alg_crv', specifying the elliptic curve (if applicable) for 309 the algorithm used to countersign messages in the security group. 310 If present, this parameter MUST specify a single value encoded as 311 a text string, which is taken from the 'Value' column of the "COSE 312 Elliptic Curves" Registry [COSE.Elliptic.Curves]. 314 o 'cs_key_kty', specifying the key type of countersignature keys 315 used to countersign messages in the security group. If present, 316 this parameter MUST specify a single value encoded as a text 317 string, which is taken from the 'Value' column of the "COSE Key 318 Types" Registry [COSE.Key.Types]. 320 o 'cs_key_crv', specifying the elliptic curve (if applicable) of 321 countersignature keys used to countersign messages in the security 322 group. If present, this parameter MUST specify a single value 323 encoded as a text string, which is taken from the 'Value' column 324 of the "COSE Elliptic Curves" Registry defined in 325 [COSE.Elliptic.Curves]. 327 o 'cs_kenc', specifying the encoding of the public keys used in the 328 security group. If present, this parameter MUST specify a single 329 value encoded as a text string. This specification explicitly 330 admits the signaling of COSE Keys 331 [I-D.ietf-cose-rfc8152bis-struct] as encoding for public keys, 332 which is indicated with "1", as taken from the 'Confirmation Key' 333 column of the "CWT Confirmation Method" Registry defined in 334 [RFC8747]. Future specifications may define additional values for 335 this parameter. 337 o 'alg', specifying the AEAD algorithm used in the security group. 338 If present, this parameter MUST specify a single value encoded as 339 a text string, which is taken from the 'Value' column of the "COSE 340 Algorithms" Registry [COSE.Algorithms]. 342 o 'hkdf', specifying the HKDF algorithm used in the security group. 343 If present, this parameter MUST specify a single value encoded as 344 a text string, which is taken from the 'Value' column of the "COSE 345 Algorithms" Registry defined in [COSE.Algorithms]. 347 Note that the values registered in the COSE Registries 348 [COSE.Algorithms][COSE.Elliptic.Curves][COSE.Key.Types] are strongly 349 typed. On the contrary, Link Format is weakly typed and thus does 350 not distinguish between, for instance, the string value "-10" and the 351 integer value -10. 353 Thus, in RDs that return responses in Link Format, string values 354 which look like an integer are not supported. Therefore, such values 355 MUST NOT be advertised through the corresponding parameters above. 357 A CoAP endpoint that queries the RD to discover security groups and 358 their group-membership resource to access (see Section 4) would 359 benefit from the information above as follows. 361 o The values of 'cs_alg', 'cs_alg_crv', 'cs_key_kty', 'cs_key_crv' 362 and 'cs_kenc' related to a group-membership resource provide an 363 early knowledge of the format and encoding of public keys used in 364 the security group. Thus, the CoAP endpoint does not need to ask 365 the GM for this information as a preliminary step before the 366 joining process, or to perform a trial-and-error joining exchange 367 with the GM. Hence, the CoAP endpoint is able to provide the GM 368 with its own public key in the correct expected format and 369 encoding at the very first step of the joining process. 371 o The values of 'cs_alg', 'alg' and 'hkdf' related to a group- 372 membership resource provide an early knowledge of the algorithms 373 used in the security group. Thus, the CoAP endpoint is able to 374 decide whether to actually proceed with the joining process, 375 depending on its support for the indicated algorithms. 377 2.2. Relation Link to Authorization Server 379 For each registered link to a group-membership resource, the GM MAY 380 additionally specify the link to the ACE Authorization Server (AS) 381 [I-D.ietf-ace-oauth-authz] associated to the GM, and issuing 382 authorization credentials to join the security group as described in 383 [I-D.ietf-ace-key-groupcomm-oscore]. 385 The link to the AS has as target the URI of the resource where to 386 send an authorization request to. 388 In the RD defined in [I-D.ietf-core-resource-directory] and based on 389 Link Format, the link to the AS is separately registered with the RD, 390 and includes the following parameters as target attributes. 392 o 'rel', with value "authorization_server". 394 o 'anchor', with value the target of the link to the group- 395 membership resource at the GM. 397 In a RD based on CoRAL, such as the one defined in 398 [I-D.hartke-t2trg-coral-reef], this is mapped (as describe there) to 399 a link from the registration resource to the AS, using the 400 link 401 relation type. 403 2.3. Registration Example 405 The example below shows a GM with endpoint name "gm1" and address 406 2001:db8::ab that registers with the RD. 408 The GM specifies the value of the 'sec-gp' parameter for accessing 409 the security group with name "feedca570000", and used by the 410 application group with name "group1" specified with the value of the 411 'app-gp' parameter. The countersignature algorithm used in the 412 security group is EdDSA, with elliptic curve Ed25519 and keys of type 413 OKP. Public keys used in the security group are encoded as COSE Keys 414 [I-D.ietf-cose-rfc8152bis-struct]. 416 In addition, the GM specifies the link to the ACE Authorization 417 Server associated to the GM, to which a CoAP endpoint should send an 418 Authorization Request for joining the corresponding security group 419 (see [I-D.ietf-ace-key-groupcomm-oscore]). 421 2.3.1. Example in Link Format 423 Request: GM -> RD 425 Req: POST coap://rd.example.com/rd?ep=gm1 426 Content-Format: 40 427 Payload: 428 ;ct=41;rt="core.osc.gm";if="ace.group"; 429 sec-gp="feedca570000";app-gp="group1"; 430 cs_alg="-8";cs_alg_crv="6"; 431 cs_key_kty="1";cs_key_crv=6"; 432 cs_kenc="1", 433 ; 434 rel="authorization-server"; 435 anchor="coap://[2001:db8::ab]/ace-group/feedca570000" 437 Response: RD -> GM 439 Res: 2.01 Created 440 Location-Path: /rd/4521 442 2.3.2. Example in CoRAL 444 Request: GM -> RD 446 Req: POST coap://rd.example.com/rd?ep=gm1 447 Content-Format: TBD123456 (application/coral+cbor) 449 Payload: 450 #using 451 #using reef = 452 #using iana = 454 #base 455 reef:rd-item { 456 reef:rt "core.osc.gm" 457 reef:if "ace.group" 458 sec-gp "feedca570000" 459 app-gp "group1" 460 cs_alg -8 461 cs_alg_crv 6 462 cs_key_kty 1 463 cs_key_crv 6 464 cs_kenc 1 465 iana:authorization-server 466 } 468 Response: RD -> GM 469 Res: 2.01 Created 470 Location-Path: /rd/4521 472 3. Addition and Update of Security Groups 474 The GM is responsible to refresh the registration of all its group- 475 membership resources in the RD. This means that the GM has to update 476 the registration within its lifetime as per Section 5.3.1 of 477 [I-D.ietf-core-resource-directory], and has to change the content of 478 the registration when a group-membership resource is added/removed, 479 or if its parameters have to be changed, such as in the following 480 cases. 482 o The GM creates a new security group and starts exporting the 483 related group-membership resource. 485 o The GM dismisses a security group and stops exporting the related 486 group-membership resource. 488 o Information related to an existing security group changes, e.g. 489 the list of associated application groups. 491 To perform an update of its registrations, the GM can re-register 492 with the RD and fully specify all links to its group-membership 493 resources. 495 Alternatively, the GM can perform a PATCH/iPATCH [RFC8132] request to 496 the RD, as per Section 5.3.3 of [I-D.ietf-core-resource-directory]. 497 This requires new media-types to be defined in future standards, to 498 apply a new document as a patch to an existing stored document. 500 3.1. Addition Example 502 The example below shows how the GM from Section 2 re-registers with 503 the RD. When doing so, it specifies: 505 o The same previous group-membership resource associated to the 506 security group with name "feedca570000". 508 o An additional group-membership resource associated to the security 509 group with name "ech0ech00000" and used by the application group 510 "group2". 512 o A third group-membership resource associated with the security 513 group with name "abcdef120000" and used by two application groups, 514 namely "group3" and "group4". 516 Furthermore, the GM relates the same Authorization Server also to the 517 security groups "ech0ech00000" and "abcdef120000". 519 3.1.1. Example in Link Format 521 Request: GM -> RD 523 Req: POST coap://rd.example.com/rd?ep=gm1 524 Content-Format: 40 525 Payload: 526 ;ct=41;rt="core.osc.gm";if="ace.group"; 527 sec-gp="feedca570000";app-gp="group1"; 528 cs_alg="-8";cs_alg_crv="6"; 529 cs_key_kty="1";cs_key_crv=6"; 530 cs_kenc="1", 531 ;ct=41;rt="core.osc.gm";if="ace.group"; 532 sec-gp="ech0ech00000";app-gp="group2"; 533 cs_alg="-8";cs_alg_crv="6"; 534 cs_key_kty="1";cs_key_crv=6"; 535 cs_kenc="1", 536 ;ct=41;rt="core.osc.gm";if="ace.group"; 537 sec-gp="abcdef120000";app-gp="group3"; 538 app-gp="group4";cs_alg="-8"; 539 cs_alg_crv="6";cs_key_kty="1"; 540 cs_key_crv=6";cs_kenc="1", 541 ; 542 rel="authorization-server"; 543 anchor="coap://[2001:db8::ab]/ace-group/feedca570000", 544 ; 545 rel="authorization-server"; 546 anchor="coap://[2001:db8::ab]/ace-group/ech0ech00000", 547 ; 548 rel="authorization-server"; 549 anchor="coap://[2001:db8::ab]/ace-group/abcdef120000" 551 Response: RD -> GM 553 Res: 2.04 Changed 554 Location-Path: /rd/4521 556 3.1.2. Example in CoRAL 558 Request: GM -> RD 559 Req: POST coap://rd.example.com/rd?ep=gm1 560 Content-Format: TBD123456 (application/coral+cbor) 562 Payload: 563 #using 564 #using reef = 565 #using iana = 567 #base 568 reef:rd-item { 569 reef:rt "core.osc.gm" 570 reef:if "ace.group" 571 sec-gp "feedca570000" 572 app-gp "group1" 573 cs_alg -8 574 cs_alg_crv 6 575 cs_key_kty 1 576 cs_key_crv 6 577 cs_kenc 1 578 iana:authorization-server 579 } 580 reef:rd-item { 581 reef:rt "core.osc.gm" 582 reef:if "ace.group" 583 sec-gp "ech0ech00000" 584 app-gp "group2" 585 cs_alg -8 586 cs_alg_crv 6 587 cs_key_kty 1 588 cs_key_crv 6 589 cs_kenc 1 590 iana:authorization-server 591 } 592 reef:rd-item { 593 reef:rt "core.osc.gm" 594 reef:if "ace.group" 595 sec-gp "abcdef120000" 596 app-gp "group3" 597 app-gp "group4" 598 cs_alg -8 599 cs_alg_crv 6 600 cs_key_kty 1 601 cs_key_crv 6 602 cs_kenc 1 603 iana:authorization-server 604 } 606 Response: RD -> GM 607 Res: 2.04 Changed 608 Location-Path: /rd/4521 610 4. Discovery of Security Groups 612 A CoAP endpoint that wants to join a security group, hereafter called 613 the joining node, might not have all the necessary information at 614 deployment time. Also, it might want to know about possible new 615 security groups created afterwards by the respective Group Managers. 617 To this end, the joining node can perform a resource lookup at the RD 618 as per Section 6.1 of [I-D.ietf-core-resource-directory], to retrieve 619 the missing pieces of information needed to join the security 620 group(s) of interest. The joining node can find the RD as described 621 in Section 4 of [I-D.ietf-core-resource-directory]. 623 The joining node uses the following parameter value for the lookup 624 filtering. 626 o 'rt' = "core.osc.gm", specifying the resource type of the group- 627 membership resource at the Group Manager, with value "core.osc.gm" 628 registered in Section 21.11 of 629 [I-D.ietf-ace-key-groupcomm-oscore]. 631 The joining node may additionally consider the following parameters 632 for the lookup filtering, depending on the information it has already 633 available. 635 o 'sec-gp', specifying the name of the security group of interest. 636 This parameter MUST specify a single value. 638 o 'ep', specifying the registered endpoint of the GM. 640 o 'app-gp', specifying the name(s) of the application group(s) 641 associated with the security group of interest. This parameter 642 MAY be included multiple times, and each occurrence MUST specify 643 the name of one application group. 645 o 'if', specifying the interface description for accessing the 646 group-membership resource at the Group Manager, with value 647 "ace.group" registered in Section 8.10 of 648 [I-D.ietf-ace-key-groupcomm]. 650 The response from the RD may include links to a group-membership 651 resource specifying multiple application groups, as all using the 652 same security group. In this case, the joining node is already 653 expected to know the exact application group of interest. 655 Furthermore, the response from the RD may include the links to 656 different group-membership resources, all specifying a same 657 application group of interest for the joining node, if the 658 corresponding security groups are all used by that application group. 660 In this case, application policies on the joining node should define 661 how to determine the exact security group to join (see Section 2.1 of 662 [I-D.ietf-core-groupcomm-bis]). For example, different security 663 groups can reflect different security algorithms to use. Hence, a 664 client application can take into account what the joining node 665 supports and prefers, when selecting one particular security group 666 among the indicated ones, while a server application would need to 667 join all of them. Later on, the joining node will be anyway able to 668 join only security groups for which it is actually authorized to be a 669 member (see [I-D.ietf-ace-key-groupcomm-oscore]). 671 Note that, with RD-based discovery, including the 'app-gp' parameter 672 multiple times would result in finding only the group-membership 673 resource that serves all the specified application groups, i.e. not 674 any group-membership resource that serves either. Therefore, a 675 joining node needs to perform N separate queries with different 676 values for 'app-gp', in order to safely discover the (different) 677 group-membership resource(s) serving the N application groups. 679 4.1. Discovery Example #1 681 Consistently with the examples in Section 2 and Section 3, the 682 examples below consider a joining node that wants to join the 683 security group associated with the application group "group1", but 684 that does not know the name of the security group, the responsible GM 685 and the group-membership resource to access. 687 4.1.1. Example in Link Format 689 Request: Joining node -> RD 691 Req: GET coap://rd.example.com/rd-lookup/res 692 ?rt=core.osc.gm&app-gp=group1 694 Response: RD -> Joining node 696 Res: 2.05 Content 697 Payload: 698 ;rt="core.osc.gm"; 699 if="ace.group";sec-gp="feedca570000";app-gp="group1"; 700 cs_alg="-8";cs_alg_crv="6";cs_key_kty="1";cs_key_crv=6"; 701 cs_kenc="1";anchor="coap://[2001:db8::ab]" 703 By performing the separate resource lookup below, the joining node 704 can retrieve the link to the ACE Authorization Server associated to 705 the GM, where to send an Authorization Request for joining the 706 corresponding security group (see 707 [I-D.ietf-ace-key-groupcomm-oscore]). 709 Request: Joining node -> RD 711 Req: GET coap://rd.example.com/rd-lookup/res 712 ?rel="authorization-server"& 713 anchor="coap://[2001:db8::ab]/ace-group/feedca570000" 715 Response: RD -> Joining node 717 Res: 2.05 Content 718 Payload: 719 721 To retrieve the multicast IP address of the CoAP group used by the 722 application group "group1", the joining node performs an endpoint 723 lookup as shown below. The following assumes that the application 724 group "group1" had been previously registered as per Appendix A of 725 [I-D.ietf-core-resource-directory], with ff35:30:2001:db8::23 as 726 multicast IP address of the associated CoAP group. 728 Request: Joining node -> RD 730 Req: GET coap://rd.example.com/rd-lookup/ep 731 ?et=core.rd-group&ep=group1 733 Response: RD -> Joining node 735 Res: 2.05 Content 736 Payload: 737 ;ep="group1";et="core.rd-group"; 738 base="coap://[ff35:30:2001:db8::23]" 740 4.1.2. Example in CoRAL 742 Request: Joining node -> RD 744 Req: GET coap://rd.example.com/rd-lookup/res 745 ?rt=core.osc.gm&app-gp=group1 746 Accept: TBD123456 (application/coral+cbor) 748 Response: RD -> Joining node 749 Res: 2.05 Content 750 Content-Format: TBD123456 (application/coral+cbor) 752 Payload: 753 #using 754 #using reef = 755 #using iana = 757 #base 758 reef:rd-item { 759 reef:rt "core.osc.gm" 760 reef:if "ace.group" 761 sec-gp "feedca570000" 762 app-gp "group1" 763 cs_alg -8 764 cs_alg_crv 6 765 cs_key_kty 1 766 cs_key_crv 6 767 cs_kenc 1 768 iana:authorization-server 769 } 771 To retrieve the multicast IP address of the CoAP group used by the 772 application group "group1", the joining node performs an endpoint 773 lookup as shown below. The following assumes that the application 774 group "group1" had been previously registered, with 775 ff35:30:2001:db8::23 as multicast IP address of the associated CoAP 776 group. 778 Request: Joining node -> RD 780 Req: GET coap://rd.example.com/rd-lookup/ep 781 ?et=core.rd-group&ep=group1 782 Accept: TBD123456 (application/coral+cbor) 784 Response: RD -> Joining node 785 Res: 2.05 Content 786 Content-Format: TBD123456 (application/coral+cbor) 788 Payload: 789 #using 790 #using reef = 792 reef:rd-unit <./rd/501> { 793 reef:ep="group1" 794 reef:et="core.rd-group" 795 reef:base 796 } 798 4.2. Discovery Example #2 800 Consistently with the examples in Section 2 and Section 3, the 801 examples below consider a joining node that wants to join the 802 security group with name "feedca570000", but that does not know the 803 responsible GM, the group-membership resource to access, and the 804 associated application groups. 806 The examples also show how the joining node uses CoAP observation 807 [RFC7641], in order to be notified of possible changes to the 808 parameters of the group-membership resource. This is also useful to 809 handle the case where the security group of interest has not been 810 created yet, so that the joining node can receive the requested 811 information when it becomes available. 813 4.2.1. Example in Link Format 815 Request: Joining node -> RD 817 Req: GET coap://rd.example.com/rd-lookup/res 818 ?rt=core.osc.gm&sec-gp=feedca570000 819 Observe: 0 821 Response: RD -> Joining node 823 Res: 2.05 Content 824 Observe: 24 825 Payload: 826 ;rt="core.osc.gm"; 827 if="ace.group";sec-gp="feedca570000";app-gp="group1"; 828 cs_alg="-8";cs_alg_crv="6";cs_key_kty="1";cs_key_crv=6"; 829 cs_kenc="1";anchor="coap://[2001:db8::ab]" 831 Depending on the search criteria, the joining node performing the 832 resource lookup can get large responses. This can happen, for 833 instance, when the lookup request targets all the group-membership 834 resources at a specified GM, or all the group-membership resources of 835 all the registered GMs, as in the example below. 837 Request: Joining node -> RD 839 Req: GET coap://rd.example.com/rd-lookup/res?rt=core.osc.gm 841 Response: RD -> Joining node 843 Res: 2.05 Content 844 Payload: 845 ;rt="core.osc.gm"; 846 if="ace.group";sec-gp="feedca570000";app-gp="group1"; 847 cs_alg="-8";cs_alg_crv="6";cs_key_kty="1";cs_key_crv=6"; 848 cs_kenc="1";anchor="coap://[2001:db8::ab]", 849 ;rt="core.osc.gm"; 850 if="ace.group";sec-gp="ech0ech00000";app-gp="group2"; 851 cs_alg="-8";cs_alg_crv="6";cs_key_kty="1";cs_key_crv=6"; 852 cs_kenc="1";anchor="coap://[2001:db8::ab]", 853 ;rt="core.osc.gm"; 854 if="ace.group";sec-gp="abcdef120000";app-gp="group3"; 855 app-gp="group4";cs_alg="-8";cs_alg_crv="6";cs_key_kty="1"; 856 cs_key_crv=6";cs_kenc="1";anchor="coap://[2001:db8::ab]" 858 Therefore, it is RECOMMENDED that a joining node which performs a 859 resource lookup with the CoAP Observe option specifies the value of 860 the parameter 'sec-gp' in its GET request sent to the RD. 862 4.2.2. Example in CoRAL 864 Request: Joining node -> RD 866 Req: GET coap://rd.example.com/rd-lookup/res 867 ?rt=core.osc.gm&sec-gp=feedca570000 868 Accept: TBD123456 (application/coral+cbor) 869 Observe: 0 871 Response: RD -> Joining node 872 Res: 2.05 Content 873 Observe: 24 874 Content-Format: TBD123456 (application/coral+cbor) 876 Payload: 877 #using 878 #using reef = 879 #using iana = 881 #base 882 reef:rd-item { 883 reef:rt "core.osc.gm" 884 reef:if "ace.group" 885 sec-gp "feedca570000" 886 app-gp "group1" 887 cs_alg -8 888 cs_alg_crv 6 889 cs_key_kty 1 890 cs_key_crv 6 891 cs_kenc 1 892 iana:authorization-server 893 } 895 5. Use Case Example With Full Discovery 897 In this section, the discovery of security groups is described to 898 support the installation process of a lighting installation in an 899 office building. The described process is a simplified version of 900 one of many processes. 902 The process described in this section is intended as an example and 903 does not have any particular ambition to serve as recommendation or 904 best practice to adopt. That is, it shows a possible workflow 905 involving a Commissioning Tool (CT) used in a certain way, while it 906 is not meant to prescribe how the workflow should necessarily be. 908 Assume the existence of four luminaires that are members of two 909 application groups. In the first application group, the four 910 luminaires receive presence messages and light intensity messages 911 from sensors or their proxy. In the second application group, the 912 four luminaires and several other pieces of equipment receive 913 building state schedules. 915 Each of the two application groups is associated to a different 916 security group and to a different CoAP group with its own dedicated 917 multicast IP address. 919 The Fairhair Alliance describes how a new device is accepted and 920 commissioned in the network [Fairhair], by means of its certificate 921 stored during the manufacturing process. When commissioning the new 922 device in the installation network, the new device gets a new 923 identity defined by a newly allocated certificate, following the 924 BRSKI specification. 926 Section 7.3 of [I-D.ietf-core-resource-directory] describes how the 927 CT assigns an endpoint name based on the CN field, (CN=ACME) and the 928 serial number of the certificate (serial number = 123x, with 3 < x < 929 8). Corresponding ep-names ACME-1234, ACME-1235, ACME-1236 and 930 ACME-1237 are also assumed. 932 It is common practice that locations in the building are specified 933 according to a coordinate system. After the acceptance of the 934 luminaires into the installation network, the coordinate of each 935 device is communicated to the CT. This can be done manually or 936 automatically. 938 The mapping between location and ep-name is calculated by the CT. 939 For instance, on the basis of grouping criteria, the CT assigns: i) 940 application group "grp_R2-4-015" to the four luminaires; and ii) 941 application group "grp_schedule" to all schedule requiring devices. 942 Also, the device with ep name ACME-123x has been assigned IP address: 943 [2001:db8:4::x]. The RD is assigned IP address: [2001:db8:4:ff]. 944 The used multicast addresses are: [ff05::5:1] and [ff05::5:2]. 946 The following assumes that each device is pre-configured with the 947 name of the two application groups it belongs to. Additional 948 mechanisms can be defined in the RD, for supporting devices to 949 discover the application groups they belong to. 951 Appendix A provides this same use case example in CoRAL. 953 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 955 The CT defines the application group "grp_R2-4-015", with resource 956 /light and base address [ff05::5:1], as follows. 958 Request: CT -> RD 960 Req: POST coap://[2001:db8:4::ff]/rd 961 ?ep=grp_R2-4-015&et=core.rd-group&base=coap://[ff05::5:1] 962 Content-Format: 40 963 Payload: 964 ;rt="oic.d.light" 966 Response: RD -> CT 967 Res: 2.01 Created 968 Location-Path: /rd/501 970 Also, the CT defines a second application group "grp_schedule", with 971 resource /schedule and base address [ff05::5:2], as follows. 973 Request: CT -> RD 975 Req: POST coap://[2001:db8:4::ff]/rd 976 ?ep=grp_schedule&et=core.rd-group&base=coap://[ff05::5:2] 977 Content-Format: 40 978 Payload: 979 ;rt="oic.r.time.period" 981 Response: RD -> CT 983 Res: 2.01 Created 984 Location-Path: /rd/502 986 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 988 Finally, the CT defines the corresponding security groups. In 989 particular, assuming a Group Manager responsible for both security 990 groups and with address [2001:db8::ab], the CT specifies: 992 Request: CT -> RD 994 Req: POST coap://[2001:db8:4::ff]/rd 995 ?ep=gm1&base=coap://[2001:db8::ab] 996 Content-Format: 40 997 Payload: 998 ;ct=41;rt="core.osc.gm";if="ace.group"; 999 sec-gp="feedca570000"; 1000 app-gp="grp_R2-4-015", 1001 ;ct=41;rt="core.osc.gm";if="ace.group"; 1002 sec-gp="feedsc590000"; 1003 app-gp="grp_schedule" 1005 Response: RD -> CT 1007 Res: 2.01 Created 1008 Location-Path: /rd/4521 1010 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1012 The device with IP address [2001:db8:4::x] can retrieve the multicast 1013 IP address of the CoAP group used by the application group 1014 "grp_R2-4-015", by performing an endpoint lookup as shown below. 1016 Request: Joining node -> RD 1018 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 1019 ?et=core.rd-group&ep=grp_R2-4-015 1021 Response: RD -> Joining node 1023 Res: 2.05 Content 1024 Content-Format: 40 1025 Payload: 1026 ;ep="grp_R2-4-015";et="core.rd-group"; 1027 base="coap://[ff05::5:1]" 1029 Similarly, to retrieve the multicast IP address of the CoAP group 1030 used by the application group "grp_schedule", the device performs an 1031 endpoint lookup as shown below. 1033 Request: Joining node -> RD 1035 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 1036 ?et=core.rd-group&ep=grp_schedule 1038 Response: RD -> Joining node 1040 Res: 2.05 Content 1041 Content-Format: 40 1042 Payload: 1043 ;ep="grp_schedule";et="core.rd-group"; 1044 base="coap://[ff05::5:2]" 1046 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1048 Consequently, the device learns the security groups it has to join. 1049 In particular, it does the following for app-gp="grp_R2-4-015". 1051 Request: Joining node -> RD 1053 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 1054 ?rt=core.osc.gm&app-gp=grp_R2-4-015 1056 Response: RD -> Joining Node 1058 Res: 2.05 Content 1059 Content-Format: 40 1060 Payload: 1061 ; 1062 rt="core.osc.gm";if="ace.group";sec-gp="feedca570000"; 1063 app-gp="grp_R2-4-015";anchor="coap://[2001:db8::ab]" 1065 Similarly, the device does the following for app-gp="grp_schedule". 1067 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 1068 ?rt=core.osc.gm&app-gp=grp_schedule 1070 Response: RD -> Joining Node 1072 Res: 2.05 Content 1073 Content-Format: 40 1074 Payload: 1075 ; 1076 rt="core.osc.gm";if="ace.group";sec-gp="feedsc590000"; 1077 app-gp="grp_schedule";anchor="coap://[2001:db8::ab]" 1079 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1081 After this last discovery step, the device can ask permission to join 1082 the security groups, and effectively join them through the Group 1083 Manager, e.g. according to [I-D.ietf-ace-key-groupcomm-oscore]. 1085 6. Security Considerations 1087 The security considerations as described in Section 8 of 1088 [I-D.ietf-core-resource-directory] apply here as well. 1090 7. IANA Considerations 1092 This document has no actions for IANA. 1094 8. References 1096 8.1. Normative References 1098 [COSE.Algorithms] 1099 IANA, "COSE Algorithms", 1100 . 1103 [COSE.Elliptic.Curves] 1104 IANA, "COSE Elliptic Curves", 1105 . 1108 [COSE.Key.Types] 1109 IANA, "COSE Key Types", 1110 . 1113 [I-D.ietf-core-coral] 1114 Hartke, K., "The Constrained RESTful Application Language 1115 (CoRAL)", draft-ietf-core-coral-03 (work in progress), 1116 March 2020. 1118 [I-D.ietf-core-groupcomm-bis] 1119 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1120 for the Constrained Application Protocol (CoAP)", draft- 1121 ietf-core-groupcomm-bis-02 (work in progress), November 1122 2020. 1124 [I-D.ietf-core-oscore-groupcomm] 1125 Tiloca, M., Selander, G., Palombini, F., and J. Park, 1126 "Group OSCORE - Secure Group Communication for CoAP", 1127 draft-ietf-core-oscore-groupcomm-10 (work in progress), 1128 November 2020. 1130 [I-D.ietf-core-resource-directory] 1131 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 1132 Amsuess, "CoRE Resource Directory", draft-ietf-core- 1133 resource-directory-25 (work in progress), July 2020. 1135 [I-D.ietf-cose-rfc8152bis-algs] 1136 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1137 Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-12 1138 (work in progress), September 2020. 1140 [I-D.ietf-cose-rfc8152bis-struct] 1141 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1142 Structures and Process", draft-ietf-cose-rfc8152bis- 1143 struct-14 (work in progress), September 2020. 1145 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1146 Requirement Levels", BCP 14, RFC 2119, 1147 DOI 10.17487/RFC2119, March 1997, 1148 . 1150 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1151 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1152 . 1154 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1155 Application Protocol (CoAP)", RFC 7252, 1156 DOI 10.17487/RFC7252, June 2014, 1157 . 1159 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1160 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1161 May 2017, . 1163 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 1164 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 1165 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 1166 2020, . 1168 8.2. Informative References 1170 [Fairhair] 1171 FairHair Alliance, "Security Architecture for the Internet 1172 of Things (IoT) in Commercial Buildings", White Paper, ed. 1173 Piotr Polak , March 2018, . 1177 [I-D.hartke-t2trg-coral-reef] 1178 Hartke, K., "Resource Discovery in Constrained RESTful 1179 Environments (CoRE) using the Constrained RESTful 1180 Application Language (CoRAL)", draft-hartke-t2trg-coral- 1181 reef-04 (work in progress), May 2020. 1183 [I-D.ietf-ace-key-groupcomm] 1184 Palombini, F. and M. Tiloca, "Key Provisioning for Group 1185 Communication using ACE", draft-ietf-ace-key-groupcomm-10 1186 (work in progress), November 2020. 1188 [I-D.ietf-ace-key-groupcomm-oscore] 1189 Tiloca, M., Park, J., and F. Palombini, "Key Management 1190 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 1191 oscore-09 (work in progress), November 2020. 1193 [I-D.ietf-ace-oauth-authz] 1194 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1195 H. Tschofenig, "Authentication and Authorization for 1196 Constrained Environments (ACE) using the OAuth 2.0 1197 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35 1198 (work in progress), June 2020. 1200 [I-D.ietf-ace-oscore-gm-admin] 1201 Tiloca, M., Hoeglund, R., Stok, P., Palombini, F., and K. 1202 Hartke, "Admin Interface for the OSCORE Group Manager", 1203 draft-ietf-ace-oscore-gm-admin-01 (work in progress), 1204 November 2020. 1206 [I-D.ietf-anima-bootstrapping-keyinfra] 1207 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 1208 and K. Watsen, "Bootstrapping Remote Secure Key 1209 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1210 keyinfra-44 (work in progress), September 2020. 1212 [I-D.ietf-cbor-7049bis] 1213 Bormann, C. and P. Hoffman, "Concise Binary Object 1214 Representation (CBOR)", draft-ietf-cbor-7049bis-16 (work 1215 in progress), September 2020. 1217 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1218 Constrained-Node Networks", RFC 7228, 1219 DOI 10.17487/RFC7228, May 2014, 1220 . 1222 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1223 Application Protocol (CoAP)", RFC 7641, 1224 DOI 10.17487/RFC7641, September 2015, 1225 . 1227 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 1228 FETCH Methods for the Constrained Application Protocol 1229 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 1230 . 1232 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1233 Interchange Format", STD 90, RFC 8259, 1234 DOI 10.17487/RFC8259, December 2017, 1235 . 1237 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1238 "Object Security for Constrained RESTful Environments 1239 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1240 . 1242 Appendix A. Use Case Example With Full Discovery (CoRAL) 1244 This section provides the same use case example of Section 5, but 1245 specified in CoRAL [I-D.ietf-core-coral]. 1247 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1249 The CT defines the application group "grp_R2-4-015", with resource 1250 /light and base address [ff05::5:1], as follows. 1252 Request: CT -> RD 1253 Req: POST coap://[2001:db8:4::ff]/rd 1254 Content-Format: TBD123456 (application/coral+cbor) 1256 Payload: 1257 #using reef = 1259 #base 1260 reef:ep "grp_R2-4-015" 1261 reef:et "core.rd-group" 1262 reef:rd-item { 1263 reef:rt "oic.d.light" 1264 } 1266 Response: RD -> CT 1268 Res: 2.01 Created 1269 Location-Path: /rd/501 1271 Also, the CT defines a second application group "grp_schedule", with 1272 resource /schedule and base address [ff05::5:2], as follows. 1274 Request: CT -> RD 1276 Req: POST coap://[2001:db8:4::ff]/rd?ep=grp_schedule&et=core.rd-group 1277 Content-Format: TBD123456 (application/coral+cbor) 1279 Payload: 1280 #using reef = 1282 #base 1283 reef:rd-item { 1284 reef:rt "oic.r.time.period" 1285 } 1287 Response: RD -> CT 1289 Res: 2.01 Created 1290 Location-Path: /rd/502 1292 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1294 Finally, the CT defines the corresponding security groups. In 1295 particular, assuming a Group Manager responsible for both security 1296 groups and with address [2001:db8::ab], the CT specifies: 1298 Request: CT -> RD 1299 Req: POST coap://[2001:db8:4::ff]/rd?ep=gm1 1300 Content-Format: TBD123456 (application/coral+cbor) 1302 Payload: 1303 #using 1304 #using reef = 1306 #base 1307 reef:rd-item { 1308 reef:ct 41 1309 reef:rt "core.osc.gm" 1310 reef:if "ace.group" 1311 sec-gp "feedca570000" 1312 app-gp "grp_R2-4-015" 1313 } 1314 reef:rd-item { 1315 reef:ct 41 1316 reef:rt "core.osc.gm" 1317 reef:if "ace.group" 1318 sec-gp "feedsc590000" 1319 app-gp "grp_schedule" 1320 } 1322 Response: RD -> CT 1324 Res: 2.01 Created 1325 Location-Path: /rd/4521 1327 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1329 The device with IP address [2001:db8:4::x] can retrieve the multicast 1330 IP address of the CoAP group used by the application group 1331 "grp_R2-4-015", by performing an endpoint lookup as shown below. 1333 Request: Joining node -> RD 1335 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 1336 ?et=core.rd-group&ep=grp_R2-4-015 1338 Response: RD -> Joining node 1339 Res: 2.05 Content 1340 Content-Format: TBD123456 (application/coral+cbor) 1342 Payload: 1343 #using reef = 1345 #base 1346 reef:rd-unit <501> { 1347 reef:ep "grp_R2-4-015" 1348 reef:et "core.rd-group" 1349 reef:base 1350 } 1352 Similarly, to retrieve the multicast IP address of the CoAP group 1353 used by the application group "grp_schedule", the device performs an 1354 endpoint lookup as shown below. 1356 Request: Joining node -> RD 1358 Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep 1359 ?et=core.rd-group&ep=grp_schedule 1361 Response: RD -> Joining node 1363 Res: 2.05 Content 1364 Content-Format: TBD123456 (application/coral+cbor) 1366 Payload: 1367 #using reef = 1369 #base 1370 reef:rd-unit <501> { 1371 reef:ep "grp_schedule" 1372 reef:et "core.rd-group" 1373 reef:base 1374 } 1376 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1378 Consequently, the device learns the security groups it has to join. 1379 In particular, it does the following for app-gp="grp_R2-4-015". 1381 Request: Joining node -> RD 1383 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 1384 ?rt=core.osc.gm&app-gp=grp_R2-4-015 1386 Response: RD -> Joining Node 1387 Res: 2.05 Content 1388 Content-Format: TBD123456 (application/coral+cbor) 1390 Payload: 1391 #using 1392 #using reef = 1394 #base 1395 reef:rd-item { 1396 reef:rt "core.osc.gm" 1397 reef:if "ace.group" 1398 sec-gp "feedca570000" 1399 app-gp "grp_R2-4-015" 1400 } 1402 Similarly, the device does the following for app-gp="grp_schedule". 1404 Req: GET coap://[2001:db8:4::ff]/rd-lookup/res 1405 ?rt=core.osc.gm&app-gp=grp_schedule 1407 Response: RD -> Joining Node 1409 Res: 2.05 Content 1410 Content-Format: TBD123456 (application/coral+cbor) 1412 Payload: 1413 #using 1414 #using reef = 1416 #base 1417 reef:rd-item { 1418 reef:rt "core.osc.gm" 1419 reef:if "ace.group" 1420 sec-gp "feedsc590000" 1421 app-gp "grp_schedule" 1422 } 1424 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 1426 After this last discovery step, the device can ask permission to join 1427 the security groups, and effectively join them through the Group 1428 Manager, e.g. according to [I-D.ietf-ace-key-groupcomm-oscore]. 1430 Acknowledgments 1432 The authors sincerely thank Carsten Bormann, Klaus Hartke, Jaime 1433 Jimenez, Francesca Palombini, Dave Robin and Jim Schaad for their 1434 comments and feedback. 1436 The work on this document has been partly supported by VINNOVA and 1437 the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home 1438 (Grant agreement 952652); and by the EIT-Digital High Impact 1439 Initiative ACTIVE. 1441 Authors' Addresses 1443 Marco Tiloca 1444 RISE AB 1445 Isafjordsgatan 22 1446 Kista SE-16440 Stockholm 1447 Sweden 1449 Email: marco.tiloca@ri.se 1451 Christian Amsuess 1452 Hollandstr. 12/4 1453 Vienna 1020 1454 Austria 1456 Email: christian@amsuess.com 1458 Peter van der Stok 1459 Consultant 1461 Phone: +31-492474673 (Netherlands), +33-966015248 (France) 1462 Email: consultancy@vanderstok.org 1463 URI: www.vanderstok.org