idnits 2.17.1 draft-tiloca-core-oscore-discovery-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 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 (January 23, 2019) is 1920 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-00 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-03 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-19 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-18 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-15 -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 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: July 27, 2019 6 P. van der Stok 7 Consultant 8 January 23, 2019 10 Discovery of OSCORE Groups with the CoRE Resource Directory 11 draft-tiloca-core-oscore-discovery-01 13 Abstract 15 Group communication over the Constrained Application Protocol (CoAP) 16 can be secured by means of Object Security for Constrained RESTful 17 Environments (OSCORE). At deployment time, devices may not know the 18 exact OSCORE groups to join, the respective Group Manager, or other 19 information required to perform the joining process. This document 20 describes how CoAP endpoints can use the CoRE Resource Directory to 21 discover OSCORE groups and acquire information to join them through 22 their respective Group Manager. This approach is consistent with, 23 but not limited to, the joining of OSCORE groups based on the ACE 24 framework for Authentication and Authorization. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 27, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Registration Resource for Group Managers . . . . . . . . . . 4 63 3. Registration of Group Manager Endpoints . . . . . . . . . . . 5 64 4. Addition and Update of OSCORE Groups . . . . . . . . . . . . 5 65 5. Discovery of OSCORE Groups . . . . . . . . . . . . . . . . . 7 66 5.1. Discovery Example #1 . . . . . . . . . . . . . . . . . . 7 67 5.2. Discovery Example #2 . . . . . . . . . . . . . . . . . . 8 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 7.1. Resource Types . . . . . . . . . . . . . . . . . . . . . 10 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 8.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 The Constrained Application Protocol (CoAP) [RFC7252] supports group 80 communication over IP multicast [RFC7390] to improve efficiency and 81 latency of communication and reduce bandwidth requirements. The 82 method Object Security for Constrained RESTful Environments (OSCORE) 83 [I-D.ietf-core-object-security] enables end-to-end security of CoAP 84 payload and options through CBOR Object Signing and Encryption (COSE) 85 [RFC8152]. In addition, [I-D.ietf-core-oscore-groupcomm] specifies 86 how OSCORE protects CoAP messages in group communication contexts. 88 A CoAP endpoint joins an OSCORE group by interacting with the 89 responsible Group Manager (GM) to get the required keying material. 90 As described in [I-D.ietf-ace-key-groupcomm-oscore], the joining 91 process can be based on the ACE framework for Authentication and 92 Authorization in constrained environments [I-D.ietf-ace-oauth-authz], 93 with the joining endpoint and the GM as ACE Client and ACE Resource 94 Server, respectively. That is, the joining endpoint accesses the 95 join resource associated to the OSCORE group of interest and exported 96 by the GM. 98 Devices are typically equipped with a static X509 IDevID certificate 99 installed at manufacturing time. This certificate is used at 100 deployment time during an enrollment process which provides the 101 device with an Operational Certificate, possibly updated during the 102 device lifetime. In the presence of secure group communication for 103 CoAP, such an Operational Certificate MAY be accompanied by 104 information required for the device to join OSCORE groups. This 105 especially includes a reference to the join resources to access at 106 the respective GMs. 108 However, it is usually impossible to provide such precise information 109 to freshly deployed devices as part of their (early) Operational 110 Certificate. This can be due to a number of reasons: the OSCORE 111 group(s) to join and the responsible GM(s) are generally unknown at 112 manufacturing time; an OSCORE group of interest is created, or the 113 responsible GM is deployed, only after the device is enrolled and 114 fully operative in the network; information related to existing 115 OSCORE groups or their GMs has been changed. This requires a method 116 for CoAP endpoints to dynamically discover OSCORE groups and their 117 GM, and to retrieve updated information about those groups. 119 This specification describes how CoAP endpoints use the CoRE Resource 120 Directory (RD) [I-D.ietf-core-resource-directory] for discovering an 121 OSCORE group and retrieving the information required to join that 122 group through the responsible GM. In principle, the GM registers as 123 an endpoint with the RD. The corresponding registration resource 124 includes one link for each OSCORE group under that GM, specifying the 125 path to the related join resource. More information about the OSCORE 126 group is stored in the target attributes of the respective link. 128 When querying the RD for OSCORE groups, a CoAP endpoint can further 129 benefit of the CoAP Observe Option [RFC7641]. This enables 130 convenient notifications about the creation of new OSCORE groups or 131 the updates of information concerning existing ones. As a 132 consequence, it facilitates the early deployment of CoAP endpoints, 133 i.e. even before the GM is deployed and the OSCORE groups of interest 134 are created. 136 The approach described in this specification is consistent with, 137 although not limited to, the joining of OSCORE groups described in 138 [I-D.ietf-ace-key-groupcomm-oscore]. 140 1.1. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119] [RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 This specification requires readers to be familiar with the terms and 149 concepts discussed in [I-D.ietf-core-resource-directory] and 150 [RFC6690]. Readers should also be familiar with the terms and 151 concepts discussed in [RFC7252], [I-D.ietf-core-oscore-groupcomm] and 152 [I-D.ietf-ace-key-groupcomm-oscore]. 154 Terminology for constrained environments, such as "constrained 155 device" and "constrained-node network", is defined in [RFC7228]. 157 This document refers also to the following terminology. 159 o Application group: a set of CoAP endpoints that share a set of 160 common resources, and announced in the RD as described in 161 Appendix A of [I-D.ietf-core-resource-directory]. An application 162 group is associated to a single OSCORE group. Application groups 163 MAY share resources. Any two application groups associated to the 164 same OSCORE group do not share any resource. 166 o Zeroed-epoch Group ID: this refers to the Group ID of an OSCORE 167 group as stored in the RD. The structure of such a stored Group 168 ID is as per Appendix C of [I-D.ietf-core-oscore-groupcomm], with 169 the "Group Epoch" part immutable and set to zero. 171 2. Registration Resource for Group Managers 173 With reference to Figure 3 of [I-D.ietf-core-resource-directory], a 174 Group Manager (GM) registers as an endpoint with the CoRE Resource 175 Directory (RD). The registration includes the links to the join 176 resources at the GM, associated to the OSCORE groups under that GM. 178 In particular, each link to a join resource includes: 180 o "target": URI of the join resource at the GM. 182 o target attributes, including: 184 * Resource Type (rt) with the value "core.osc.j" defined in 185 Section 7.1 of this specification. 187 * The zeroed-epoch Group ID of the OSCORE group. 189 * One target attribute for each application group associated to 190 the OSCORE group, specifying the name of that application 191 group. 193 3. Registration of Group Manager Endpoints 195 Upon deployment, a GM finds the RD as described in Section 4 of 196 [I-D.ietf-core-resource-directory]. After that, a GM registers as an 197 endpoint with the RD, as described in Section 5.3 of 198 [I-D.ietf-core-resource-directory]. When doing so, the GM MUST also 199 register all the join resources it is exporting at that point in 200 time, i.e. one for each of its OSCORE groups. The GM SHOULD NOT use 201 the Simple Registration approach described in Section 5.3.1 of 202 [I-D.ietf-core-resource-directory]. 204 The example below shows a GM with endpoint name "gm1" and address 205 2001:db8::ab that registers with the RD. The GM specifies the link 206 to one join resource for accessing the OSCORE group with zeroed-epoch 207 Group ID "feedca570000" and used by one application group with name 208 "group1". 210 Request: GM -> RD 212 Req: POST coap://rd.example.com/rd?ep=gm1 213 Content-Format: 40 214 Payload: 215 ;ct=41;rt="core.osc.j"; 216 oscore-gid="feedca570000";oscore-gp="group1" 218 Response: RD -> GM 220 Res: 2.01 Created 221 Location-Path: /rd/4521 223 4. Addition and Update of OSCORE Groups 225 The GM is responsible to keep its registration with the RD up to date 226 with links to all its join resources. This means that the GM has to 227 update the registration within its lifetime as per Section 5.4.1 of 228 [I-D.ietf-core-resource-directory], and has to change the content of 229 the registration when a join resource is added/removed or if its 230 target attributes have to be changed, such as in the following cases. 232 o The GM creates a new OSCORE group and starts exporting the related 233 join resource. 235 o The GM dismisses an OSCORE group and stops exporting the related 236 join resource. 238 o Information related to an existing OSCORE group changes, e.g. the 239 list of associated application groups. 241 In order to perform an update to the set of links in its 242 registration, the GM can re-register with the RD and fully specify 243 all links to its join resources and their target attributes in the 244 payload of the POST request. 246 The example below shows the same GM from Section 3 that re-registers 247 with the RD. When doing so, it specifies: 249 o The same previous join resource associated to the OSCORE group 250 with zeroed-epoch Group ID "feedca570000". 252 o A second join resource associated to the OSCORE group with zeroed- 253 epoch Group ID "ech0ech00000" and used by one application group, 254 namely "group2". 256 o A third join resource associated to the OSCORE group with zeroed- 257 epoch Group ID "abcdef120000" and used by two application groups, 258 namely "group3" and "group4". 260 Request: GM -> RD 262 Req: POST coap://rd.example.com/rd?ep=gm1 263 Content-Format: 40 264 Payload: 265 ;ct=41;rt="core.osc.j"; 266 oscore-gid="feedca570000";oscore-gp="group1", 267 ;ct=41;rt="core.osc.j"; 268 oscore-gid="ech0ech00000";oscore-gp="group2", 269 ;ct=41;rt="core.osc.j"; 270 oscore-gid="abcdef120000";oscore-gp="group3";oscore-gp="group4" 272 Response: RD -> GM 274 Res: 2.04 Changed 275 Location-Path: /rd/4521 277 Alternatively, the GM can perform a PATCH/iPATCH [RFC8132] request to 278 the RD, as per Section 5.4.3 of [I-D.ietf-core-resource-directory]. 279 This requires semantics to be defined in future standards, in order 280 to apply a link-format document as a patch to a different one. 282 5. Discovery of OSCORE Groups 284 A CoAP endpoint that wants to join an OSCORE group, hereafter called 285 the joining node, might not have all the necessary information at 286 deployment time. Also, it might want to know about possible new 287 OSCORE groups created afterwards by the respective Group Managers. 289 To this end, the joining node can perform a resource lookup at the RD 290 as per Section 6.1 of [I-D.ietf-core-resource-directory], in order to 291 retrieve the missing pieces of information needed to join the OSCORE 292 group(s) of interest. The joining node can find the RD as described 293 in Section 4 of [I-D.ietf-core-resource-directory]. 295 The joining node MUST consider the following search criteria for the 296 lookup filtering. 298 o 'rt' = "core.osc.j" (see Section 7.1). 300 The joining node MAY additionally consider the following search 301 criteria for the lookup filtering, depending on the information it 302 has already available. 304 o 'oscore-gid', specifying the zeroed-epoch Group ID of the OSCORE 305 group of interest. 307 o 'ep', specifying the identifier of the GM as endpoint registered 308 with the RD. 310 o 'oscore-gp', specifying the name(s) of the application group(s) 311 associated to the OSCORE group of interest. 313 5.1. Discovery Example #1 315 Consistently with the examples in Section 3 and Section 4, the 316 example below considers a joining node that wants to join the OSCORE 317 group associated to the application group "group1", but that does not 318 know the zeroed-epoch Group ID, the responsible GM and the join 319 resource to access. 321 Request: Joining node -> RD 323 Req: GET coap://rd.example.com/lookup/res?rt=core.osc.j&oscore-gp=group1 325 Response: RD -> Joining node 326 Res: 2.05 Content 327 Payload: 328 ;rt="core.osc.j"; 329 oscore-gid="feedca570000";oscore-gp="group1"; 330 anchor="coap://[2001:db8::ab]" 332 If it does not know the multicast IP address used in "group1", the 333 joining node can retrieve it by performing an endpoint lookup as 334 shown below. The following assumes that the application group had 335 been previously registered as per Appendix A of 336 [I-D.ietf-core-resource-directory], with ff35:30:2001:db8::23 as 337 associated multicast IP address. 339 Request: Joining node -> RD 341 Req: GET coap://rd.example.com/lookup/ep?et=core.rd-group&ep=group1 343 Response: RD -> Joining node 345 Res: 2.05 Content 346 Payload: 347 ;ep="group1";et="core.rd-group";\ 348 base="coap://[ff35:30:2001:db8::23]" 350 5.2. Discovery Example #2 352 Consistently with the examples in Section 3 and Section 4, the 353 example below considers a joining node that wants to join the OSCORE 354 group with zeroed-epoch Group ID "feedca570000", but that does not 355 know the responsible GM, the join resource to access, and the 356 associated application groups. 358 The example also shows how the joining node uses observation 359 [RFC7641], in order to be notified of possible changes in the join 360 resource's target attributes. This is also useful to handle the case 361 where the OSCORE group of interest has not been created yet, so that 362 the joining node can receive the requested information when available 363 at a later point in time. 365 Request: Joining node -> RD 367 Req: GET coap://rd.example.com/lookup/res?rt=osc.j&\ 368 oscore-gid=feedca570000 369 Observe: 0 371 Response: RD -> Joining node 372 Res: 2.05 Content 373 Observe: 24 374 Payload: 375 ;rt="osc.j"; 376 oscore-gid="feedca570000";oscore-gp="group1"; 377 anchor="coap://[2001:db8::ab]" 379 Depending on the used search criteria, the joining node performing 380 the resource lookup can get a response whose payload is quite large 381 in size. This can happen, for instance, in case the lookup request 382 targets all the join resources at a specified GM, or all the join 383 resources of all the registered GMs, as in the example below. 385 Request: Joining node -> RD 387 Req: GET coap://rd.example.com/lookup/res?rt=osc.j 389 Response: RD -> Joining node 391 Res: 2.05 Content 392 Payload: 393 ;rt="osc.j"; 394 oscore-gid="feedca570000";oscore-gp="group1"; 395 anchor="coap://[2001:db8::ab]", 396 ;rt="osc.j"; 397 oscore-gid="ech0ech00000";oscore-gp="group2"; 398 anchor="coap://[2001:db8::ab]", 399 ;rt="osc.j"; 400 oscore-gid="abcdef120000";oscore-gp="group3";oscore-gp="group4"; 401 anchor="coap://[2001:db8::cd]" 403 Therefore, it is RECOMMENDED that a joining node performing a 404 resource lookup to discover OSCORE groups uses observation only when 405 including the fine-grained seach criterion 'oscore-gid' in its GET 406 request sent to the RD. 408 6. Security Considerations 410 The security considerations as described in Section 8 of 411 [I-D.ietf-core-resource-directory] apply here as well. 413 7. IANA Considerations 415 This document has the following actions for IANA. 417 7.1. Resource Types 419 IANA is asked to enter the following value into the Resource Type 420 (rt=) Link Target Attribute Values subregistry within the Constrained 421 Restful Environments (CoRE) Parameters registry defined in [RFC6690]. 423 +------------+----------------------+-------------------+ 424 | Value | Description | Reference | 425 +------------+----------------------+-------------------+ 426 | | | | 427 | core.osc.j | Join resource of an | [[this document]] | 428 | | OSCORE Group Manager | | 429 | | | | 430 +------------+----------------------+-------------------| 432 8. References 434 8.1. Normative References 436 [I-D.ietf-ace-key-groupcomm-oscore] 437 Tiloca, M., Park, J., and F. Palombini, "Key Management 438 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 439 oscore-00 (work in progress), December 2018. 441 [I-D.ietf-core-oscore-groupcomm] 442 Tiloca, M., Selander, G., Palombini, F., and J. Park, 443 "Group OSCORE - Secure Group Communication for CoAP", 444 draft-ietf-core-oscore-groupcomm-03 (work in progress), 445 October 2018. 447 [I-D.ietf-core-resource-directory] 448 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 449 Amsuess, "CoRE Resource Directory", draft-ietf-core- 450 resource-directory-19 (work in progress), January 2019. 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, 454 DOI 10.17487/RFC2119, March 1997, 455 . 457 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 458 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 459 . 461 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 462 Application Protocol (CoAP)", RFC 7252, 463 DOI 10.17487/RFC7252, June 2014, 464 . 466 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 467 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 468 May 2017, . 470 8.2. Informative References 472 [I-D.ietf-ace-oauth-authz] 473 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 474 H. Tschofenig, "Authentication and Authorization for 475 Constrained Environments (ACE) using the OAuth 2.0 476 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-18 477 (work in progress), January 2019. 479 [I-D.ietf-core-object-security] 480 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 481 "Object Security for Constrained RESTful Environments 482 (OSCORE)", draft-ietf-core-object-security-15 (work in 483 progress), August 2018. 485 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 486 Constrained-Node Networks", RFC 7228, 487 DOI 10.17487/RFC7228, May 2014, 488 . 490 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 491 the Constrained Application Protocol (CoAP)", RFC 7390, 492 DOI 10.17487/RFC7390, October 2014, 493 . 495 [RFC7641] Hartke, K., "Observing Resources in the Constrained 496 Application Protocol (CoAP)", RFC 7641, 497 DOI 10.17487/RFC7641, September 2015, 498 . 500 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 501 FETCH Methods for the Constrained Application Protocol 502 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 503 . 505 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 506 RFC 8152, DOI 10.17487/RFC8152, July 2017, 507 . 509 Acknowledgments 511 The work on this document has been partly supported by VINNOVA and by 512 the EIT-Digital High Impact Initiative ACTIVE. 514 Authors' Addresses 516 Marco Tiloca 517 RISE AB 518 Isafjordsgatan 22 519 Kista SE-16440 Stockholm 520 Sweden 522 Email: marco.tiloca@ri.se 524 Christian Amsuess 525 Hollandstr. 12/4 526 Vienna 1020 527 Austria 529 Email: christian@amsuess.com 531 Peter van der Stok 532 Consultant 534 Phone: +31-492474673 (Netherlands), +33-966015248 (France) 535 Email: consultancy@vanderstok.org 536 URI: www.vanderstok.org