idnits 2.17.1 draft-tiloca-core-oscore-discovery-00.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 1 instance 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 (October 09, 2018) is 2018 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 (-21) exists of draft-ietf-core-oscore-groupcomm-02 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-15 == Outdated reference: A later version (-05) exists of draft-tiloca-ace-oscoap-joining-04 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-16 == 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: April 12, 2019 6 P. van der Stok 7 Consultant 8 October 09, 2018 10 Discovery of OSCORE groups with the CoRE Resource Directory 11 draft-tiloca-core-oscore-discovery-00 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 April 12, 2019. 43 Copyright Notice 45 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Registration Resource for Group Managers . . . . . . . . . . 4 63 3. Registration of Group Manager Endpoints . . . . . . . . . . . 4 64 4. Addition and Update of OSCORE Groups . . . . . . . . . . . . 5 65 5. Discovery of OSCORE Groups . . . . . . . . . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 7.1. Resource Types . . . . . . . . . . . . . . . . . . . . . 8 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 8.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 The Constrained Application Protocol (CoAP) [RFC7252] supports group 78 communication over IP multicast [RFC7390] to improve efficiency and 79 latency of communication and reduce bandwidth requirements. The 80 method Object Security for Constrained RESTful Environments (OSCORE) 81 [I-D.ietf-core-object-security] enables end-to-end security of CoAP 82 payload and options through CBOR Object Signing and Encryption (COSE) 83 [RFC8152]. In addition, [I-D.ietf-core-oscore-groupcomm] specifies 84 how OSCORE protects CoAP messages in group communication contexts. 86 A CoAP endpoint joins an OSCORE group by interacting with the 87 responsible Group Manager (GM) to get the required keying material. 88 As described in [I-D.tiloca-ace-oscoap-joining], the joining process 89 can be based on the ACE framework for Authentication and 90 Authorization in constrained environments [I-D.ietf-ace-oauth-authz], 91 with the joining endpoint and the GM as ACE Client and ACE Resource 92 Server, respectively. That is, the joining endpoint accesses the 93 join resource associated to the OSCORE group of interest and exported 94 by the GM. 96 Devices are typically equipped with a static Manufacturer Identity 97 installed at manufacturing time. This identity is used at deployment 98 time during an enrollment process which provides the device with an 99 Operational Identity, possibly updated during the device lifetime. 100 In the presence of secure group communication for CoAP, such an 101 Operational Identity should also comprise information required for 102 the device to join OSCORE groups. This especially includes a 103 reference to the join resources to access at the respective GMs. 105 However, it can be infeasible or inconvenient to provide such precise 106 information to freshly deployed devices as part of their (early) 107 Operational Identity. This can be due to a number of reasons: the 108 Manufacturer Identity has to be minimal and as small as possible in 109 size; the OSCORE group(s) to join and the responsible GM(s) are 110 unknown at manufacturing time; an OSCORE group of interest is 111 created, or the responsible GM is deployed, only after the device is 112 enrolled and fully operative in the network; information related to 113 existing OSCORE groups or their GMs has been changed. This requires 114 a method for CoAP endpoints to dynamically discover OSCORE groups and 115 their GM, and to retrieve updated information about those groups. 117 This specification describes how CoAP endpoints use the CoRE Resource 118 Directory (RD) [I-D.ietf-core-resource-directory] for discovering an 119 OSCORE group and retrieving the information required to join that 120 group through the responsible GM. In principle, the GM registers as 121 an endpoint with the RD. The corresponding registration resource 122 includes one link for each OSCORE group under that GM, specifying the 123 path to the related join resource. More information about the OSCORE 124 group is stored in the target attributes of the respective link. 126 When querying the RD for OSCORE groups, a CoAP endpoint can further 127 benefit of observation [RFC7641]. This enables convenient 128 notifications about the creation of new OSCORE groups or the updates 129 of information concerning existing ones. As a consequence, it 130 facilitates the early deployment of CoAP endpoints, i.e. even before 131 the GM is deployed and the OSCORE groups of interest are created. 133 The approach described in this specification is consistent with, 134 although not limited to, the joining of OSCORE groups described in 135 [I-D.tiloca-ace-oscoap-joining]. 137 1.1. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 This specification requires readers to be familiar with the terms and 146 concepts discussed in [I-D.ietf-core-resource-directory] and 147 [RFC6690]. Readers should also be familiar with the terms and 148 concepts discussed in [RFC7252], [I-D.ietf-core-oscore-groupcomm] and 149 [I-D.tiloca-ace-oscoap-joining]. 151 Terminology for constrained environments, such as "constrained 152 device", "constrained-node network", is defined in [RFC7228]. 154 This document refers also to the following terminology. 156 o Zeroed-epoch Group ID: this refers to the Group ID of an OSCORE 157 group as stored in the RD. The structure of such a stored Group 158 ID is as per Appendix C of [I-D.ietf-core-oscore-groupcomm], with 159 the "Group Epoch" immutable and set to zero. 161 2. Registration Resource for Group Managers 163 With reference to Figure 4 of [I-D.ietf-core-resource-directory], a 164 Group Manager (GM) registers as an endpoint with the CoRE Resource 165 Directory (RD). The registration includes the links to the join 166 resources at the GM, associated to the OSCORE groups under that GM. 168 In particular, each link to a join resource includes: 170 o "target": URI of the join resource at the GM. 172 o target attributes, including: 174 * Resource Type (rt) with the value "core.osc.j" defined in 175 Section 7.1 of this specification. 177 * The zeroed-epoch Group ID of the OSCORE group. 179 * One target attribute for each multicast IP address associated 180 to the OSCORE group. 182 3. Registration of Group Manager Endpoints 184 Upon deployment, a GM finds the RD as described in Section 4 of 185 [I-D.ietf-core-resource-directory]. After that, a GM registers as an 186 endpoint with the RD, as described in Section 5.3 of 187 [I-D.ietf-core-resource-directory]. When doing so, the GM MUST also 188 register all the join resources it is exporting at that point in 189 time, i.e. one for each of its OSCORE groups. The GM SHOULD NOT use 190 the Simple Registration approach described in Section 5.3.1 of 191 [I-D.ietf-core-resource-directory]. 193 The example below shows a GM with endpoint name "gm1" and address 194 2001:db8::ab that registers with the RD. The GM specifies the link 195 to one join resource for accessing the OSCORE group with zeroed-epoch 196 Group ID "feedca570000" and one associated multicast IP address 197 ff35:30:2001:db8::23. 199 Interaction: GM -> RD 201 Req: POST coap://rd.example.com/rd?ep=gm1 202 Content-Format: 40 203 Payload: 204 ;ct=41;rt="osc.j"; 205 oscore-gid="feedca570000";oscore-group-ip="ff35:30:2001:db8::23" 207 Interaction: RD -> GM 209 Res: 2.01 Created 210 Location-Path: /rd/4521 212 4. Addition and Update of OSCORE Groups 214 The GM is responsible to keep its registration with the RD up to date 215 with links to all its join resources. This means that the GM has to 216 update the registration within its lifetime as per Appendix A.1 of 217 [I-D.ietf-core-resource-directory], and has to change the content of 218 the registration when a join resource is added/removed or if its 219 target attributes have to be changed, such as in the following cases. 221 o The GM creates a new OSCORE group and starts exporting the related 222 join resource. 224 o The GM dismisses an OSCORE group and stops exporting the related 225 join resource. 227 o Information related to an existing OSCORE group changes, e.g. the 228 list of associated multicast IP addresses. 230 In order to perform an update to the set of links in its 231 registration, the GM can re-register with the RD and fully specify 232 all links to its join resources and their target attributes in the 233 payload of the POST request. 235 The example below shows the same GM from Section 3 that re-registers 236 with the RD, including the same join resource associated to the 237 OSCORE group with zeroed-epoch Group ID "feedca570000", plus a second 238 join resource associated to the OSCORE group with zeroed-epoch Group 239 ID "ech0ech00000" and one multicast IP address ff35:30:2001:db8::45. 241 Interaction: GM -> RD 243 Req: POST coap://rd.example.com/rd?ep=gm1 244 Content-Format: 40 245 Payload: 246 ;ct=41;rt="osc.j"; 247 oscore-gid="feedca570000";oscore-group-ip="ff35:30:2001:db8::23", 248 ;ct=41;rt="osc.j"; 249 oscore-gid="ech0ech00000";oscore-group-ip="ff35:30:2001:db8::45" 251 Interaction: RD -> GM 253 Res: 2.04 Changed 254 Location-Path: /rd/4521 256 Alternatively, the GM can perform a PATCH/iPATCH [RFC8132] request to 257 the RD, as per Appendix A.4 of [I-D.ietf-core-resource-directory]. 258 This requires semantics to be defined in future standards, in order 259 to apply a link-format document as a patch to a different one. 261 5. Discovery of OSCORE Groups 263 A CoAP endpoint that wants to join an OSCORE group might not have all 264 the necessary information at deployment time. Also, it might want to 265 know about possible new OSCORE groups created afterwards by the 266 respective Group Managers. 268 To this end, the CoAP endpoint can perform a resource lookup at the 269 RD as per Section 7.1 of [I-D.ietf-core-resource-directory], in order 270 to retrieve the missing pieces of information needed to join the 271 OSCORE group(s) of interest. The CoAP endpoint can find the RD as 272 described in Section 4 of [I-D.ietf-core-resource-directory]. 274 The lookup filtering MUST consider the following search criteria. 276 o 'rt' = "osc.j" (see Section 7.1). 278 The lookup filtering MAY additionally consider the following search 279 criteria, depending on the information already available to the CoAP 280 endpoint. 282 o 'oscore-gid', specifying the zeroed-epoch Group ID of the OSCORE 283 group of interest. 285 o 'ep', specifying the identifier of the GM as endpoint registered 286 with the RD. 288 Consistently with the examples in Section 3 and Section 4, the 289 example below shows a CoAP endpoint that wants to join the OSCORE 290 group with zeroed-epoch Group ID "feedca570000", but that does not 291 know the responsible GM and the join resource to access. 293 The example below also shows how the CoAP endpoint uses observation 294 [RFC7641], in order to be notified of possible changes in the join 295 resource's target attributes. This is also useful to handle the case 296 where the OSCORE group of interest has not been created yet, so that 297 the CoAP endpoint can receive the requested information when 298 available at a later point in time. 300 Interaction: Joining node -> RD 302 Req: GET coap://rd.example.com/lookup/res?rt=osc.j&\ 303 oscore-gid=feedca570000 304 Observe: 0 306 Interaction: RD -> Joining node 308 Res: 2.05 Content 309 Observe: 24 310 Payload: 311 ;rt="osc.j"; 312 oscore-gid="feedca570000";oscore-group-ip="ff35:30:2001:db8::23"; 313 anchor="coap://[2001:db8::ab]" 315 Depending on the used search criteria, the CoAP endpoint performing 316 the resource lookup can get a response whose payload is quite large 317 in size. This can happen, for instance, in case the lookup request 318 targets all the join resources at a specified GM, or all the join 319 resources of all the registered GMs, as in the example below. 321 Interaction: Joining node -> RD 323 Req: GET coap://rd.example.com/lookup/res?rt=osc.j 325 Interaction: RD -> Joining node 326 Res: 2.05 Content 327 Payload: 328 ;rt="osc.j"; 329 oscore-gid="feedca570000";oscore-group-ip="ff35:30:2001:db8::23"; 330 anchor="coap://[2001:db8::ab]", 331 ;rt="osc.j"; 332 oscore-gid="ech0ech00000";oscore-group-ip="ff35:30:2001:db8::45"; 333 anchor="coap://[2001:db8::ab]", 334 ;rt="osc.j"; 335 oscore-gid="abcdef120000";oscore-group-ip="ff35:30:2001:db8::67"; 336 anchor="coap://[2001:db8::cd]" 338 Therefore, it is RECOMMENDED that a CoAP endpoint performing a 339 resource lookup to discover OSCORE groups uses observation only when 340 including the fine-grained seach criterion 'oscore-gid' in its GET 341 request sent to the RD. 343 6. Security Considerations 345 The security considerations as described in Section 8 of 346 [I-D.ietf-core-resource-directory] apply here as well. 348 7. IANA Considerations 350 This document has the following actions for IANA. 352 7.1. Resource Types 354 IANA is asked to enter the following value into the Resource Type 355 (rt=) Link Target Attribute Values subregistry within the Constrained 356 Restful Environments (CoRE) Parameters registry defined in [RFC6690]. 358 +------------+----------------------+-------------------+ 359 | Value | Description | Reference | 360 +------------+----------------------+-------------------+ 361 | | | | 362 | core.osc.j | Join resource of an | [[this document]] | 363 | | OSCORE Group Manager | | 364 | | | | 365 +------------+----------------------+-------------------| 367 8. References 369 8.1. Normative References 371 [I-D.ietf-core-oscore-groupcomm] 372 Tiloca, M., Selander, G., Palombini, F., and J. Park, 373 "Secure group communication for CoAP", draft-ietf-core- 374 oscore-groupcomm-02 (work in progress), June 2018. 376 [I-D.ietf-core-resource-directory] 377 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 378 Amsuess, "CoRE Resource Directory", draft-ietf-core- 379 resource-directory-15 (work in progress), October 2018. 381 [I-D.tiloca-ace-oscoap-joining] 382 Tiloca, M. and J. Park, "Joining OSCORE groups in ACE", 383 draft-tiloca-ace-oscoap-joining-04 (work in progress), 384 June 2018. 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, 388 DOI 10.17487/RFC2119, March 1997, 389 . 391 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 392 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 393 . 395 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 396 Application Protocol (CoAP)", RFC 7252, 397 DOI 10.17487/RFC7252, June 2014, 398 . 400 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 401 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 402 May 2017, . 404 8.2. Informative References 406 [I-D.ietf-ace-oauth-authz] 407 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 408 H. Tschofenig, "Authentication and Authorization for 409 Constrained Environments (ACE) using the OAuth 2.0 410 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-16 411 (work in progress), October 2018. 413 [I-D.ietf-core-object-security] 414 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 415 "Object Security for Constrained RESTful Environments 416 (OSCORE)", draft-ietf-core-object-security-15 (work in 417 progress), August 2018. 419 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 420 Constrained-Node Networks", RFC 7228, 421 DOI 10.17487/RFC7228, May 2014, 422 . 424 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 425 the Constrained Application Protocol (CoAP)", RFC 7390, 426 DOI 10.17487/RFC7390, October 2014, 427 . 429 [RFC7641] Hartke, K., "Observing Resources in the Constrained 430 Application Protocol (CoAP)", RFC 7641, 431 DOI 10.17487/RFC7641, September 2015, 432 . 434 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 435 FETCH Methods for the Constrained Application Protocol 436 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 437 . 439 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 440 RFC 8152, DOI 10.17487/RFC8152, July 2017, 441 . 443 Acknowledgments 445 The work on this document has been partly supported by the EIT- 446 Digital High Impact Initiative ACTIVE. 448 Authors' Addresses 450 Marco Tiloca 451 RISE AB 452 Isafjordsgatan 22 453 Kista SE-16440 Stockholm 454 Sweden 456 Email: marco.tiloca@ri.se 458 Christian Amsuess 459 Hollandstr. 12/4 460 Vienna 1020 461 Austria 463 Email: christian@amsuess.com 464 Peter van der Stok 465 Consultant 467 Phone: +31-492474673 (Netherlands), +33-966015248 (France) 468 Email: consultancy@vanderstok.org 469 URI: www.vanderstok.org