CoRE Working Group M. Tiloca Internet-Draft RISE AB Intended status: Standards Track C. Amsuess Expires: January 6, 2020 P. van der Stok Consultant July 05, 2019 Discovery of OSCORE Groups with the CoRE Resource Directory draft-tiloca-core-oscore-discovery-03 Abstract Group communication over the Constrained Application Protocol (CoAP) can be secured by means of Object Security for Constrained RESTful Environments (OSCORE). At deployment time, devices may not know the exact OSCORE groups to join, the respective Group Manager, or other information required to perform the joining process. This document describes how a CoAP endpoint can use the CoRE Resource Directory to discover OSCORE groups and acquire information to join them through the respective Group Manager. A given OSCORE group may protect multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources. This approach is consistent with, but not limited to, the joining of OSCORE groups based on the ACE framework for Authentication and Authorization in constrained environments. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 6, 2020. Tiloca, et al. Expires January 6, 2020 [Page 1] Internet-Draft OSCORE group discovery with the CoRE RD July 2019 Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Registration Resource for Group Managers . . . . . . . . . . 5 3. Registration of Group Manager Endpoints . . . . . . . . . . . 6 4. Addition and Update of OSCORE Groups . . . . . . . . . . . . 8 5. Discovery of OSCORE Groups . . . . . . . . . . . . . . . . . 9 5.1. Discovery Example #1 . . . . . . . . . . . . . . . . . . 10 5.2. Discovery Example #2 . . . . . . . . . . . . . . . . . . 11 6. Use Case Example With Full Discovery . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8.1. Resource Types . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 18 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction A set of CoAP endpoints constitutes an application group by sharing a common pool of resources. The members of an application group may be members of a given security group, by sharing a common set of keying material to secure group communication. The Constrained Application Protocol (CoAP) [RFC7252] supports group communication over IP multicast [RFC7390][I-D.dijk-core-groupcomm-bis] to improve efficiency and latency of communication and reduce bandwidth requirements. The document Object Security for Constrained RESTful Environments (OSCORE) [I-D.ietf-core-object-security] describes how to achieve Tiloca, et al. Expires January 6, 2020 [Page 2] Internet-Draft OSCORE group discovery with the CoRE RD July 2019 end-to-end security for CoAP messages through CBOR Object Signing and Encryption (COSE) [RFC8152]. In particular, [I-D.ietf-core-oscore-groupcomm] specifies how OSCORE protects CoAP messages in group communication contexts, so enabling OSCORE groups as security groups. Typically, one application group relies on exactly one OSCORE group, while a same OSCORE group may be used by multiple application groups at the same time. A CoAP endpoint joins an OSCORE group via a Group Manager (GM), in order to get the necessary group keying material. As in [I-D.ietf-ace-key-groupcomm-oscore], the joining process can be based on the ACE framework for Authentication and Authorization in constrained environments [I-D.ietf-ace-oauth-authz], with the joining endpoint and the GM acting as ACE Client and Resource Server, respectively. That is, the joining endpoint accesses the join resource associated with the OSCORE group of interest and exported by the GM. Typically, devices are equipped with a static X509 IDevID certificate installed at manufacturing time. This certificate is used at deployment time during an enrollment process that provides the device with an Operational Certificate, possibly updated during the device lifetime. In the presence of secure group communication for CoAP, such an Operational Certificate may be accompanied by information required to join OSCORE groups. This especially includes a reference to the join resources to access at the respective GMs. However, it is usually impossible to provide such precise information to freshly deployed devices as part of their (early) Operational Certificate. This can be due to a number of reasons: (1) the OSCORE group(s) to join and the responsible GM(s) are generally unknown at manufacturing time; (2) an OSCORE group of interest is created, or the responsible GM is deployed, only after the device is enrolled and fully operative in the network; and (3) information related to existing OSCORE groups or to their GMs has been changed. This requires a method for CoAP endpoints to dynamically discover OSCORE groups and their GM, and to retrieve valid information about deployed groups. This specification describes how CoAP endpoints can use the CoRE Resource Directory (RD) [I-D.ietf-core-resource-directory] for discovering an OSCORE group and retrieving the information required to join that group through a given GM. In principle, the GM registers as an endpoint with the RD. The corresponding registration resource includes one link for each OSCORE group under that GM, specifying the path to the related join resource. Tiloca, et al. Expires January 6, 2020 [Page 3] Internet-Draft OSCORE group discovery with the CoRE RD July 2019 More information about the OSCORE group is stored in the target attributes of the respective link. This especially includes the identifiers of the application groups which use that OSCORE group. This enables a lookup of those application groups at the Resource Directory, where they are separately announced by a Commissioning Tool (see Appendix A of [I-D.ietf-core-resource-directory]). When querying the RD for OSCORE groups, a CoAP endpoint can further benefit of the CoAP Observe Option [RFC7641]. This enables the reception of notifications about the creation of new OSCORE groups or the updates concerning existing groups. Thus, it facilitates the early deployment of CoAP endpoints, i.e. even before the GM is deployed and OSCORE groups are created. The approach in this document is consistent with, but not limited to, the joining of OSCORE groups in [I-D.ietf-ace-key-groupcomm-oscore]. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This specification requires readers to be familiar with the terms and concepts discussed in [I-D.ietf-core-resource-directory] and [RFC6690]. Readers should also be familiar with the terms and concepts discussed in [RFC7252], [I-D.ietf-core-oscore-groupcomm] and [I-D.ietf-ace-key-groupcomm-oscore]. Terminology for constrained environments, such as "constrained device" and "constrained-node network", is defined in [RFC7228]. This document also refers to the following terminology. o OSCORE group: a set of CoAP endpoints that share one OSCORE Common Security Context to protect group communication as described in [I-D.ietf-core-oscore-groupcomm]. Consequently, an OSCORE group acts as security group for all its members. o Application group: a set of CoAP endpoints that share a set of common resources. Application groups are announced in the RD by a Commissioning Tool, according to the RD-Groups usage pattern (see Appendix A of [I-D.ietf-core-resource-directory]). An application group can be associated with a single OSCORE group, while multiple application groups can use the same OSCORE group. Application groups share resources by definition. Any two application groups Tiloca, et al. Expires January 6, 2020 [Page 4] Internet-Draft OSCORE group discovery with the CoRE RD July 2019 associated to the same OSCORE group do not share any same resource. o Zeroed-epoch Group ID: this refers to the Group ID of an OSCORE group as stored in the RD. The structure of such a stored Group ID is as per Appendix C of [I-D.ietf-core-oscore-groupcomm], with the "Group Epoch" part immutable and set to zero. 2. Registration Resource for Group Managers With reference to Figure 3 of [I-D.ietf-core-resource-directory], a Group Manager (GM) registers as an endpoint with the CoRE Resource Directory (RD). The registration includes the links to the "join resources" located at the GM, and associated to the OSCORE groups administrated by that GM. In particular, each link to a join resource includes: o "target": URI of the join resource at the GM. o target attributes, including: * Resource Type (rt) with the value "core.osc.j" defined in Section 8.1 of this specification. * The zeroed-epoch Group ID of the OSCORE group. * One target attribute for each application group associated with the OSCORE group, specifying the name of that application group. * The algorithm used to countersign messages in the OSCORE group. * The elliptic curve (if applicable) for the algorithm used to countersign messages in the OSCORE group. * The key type of countersignature keys used to countersign messages in the OSCORE group. * The encoding of public keys used in the OSCORE group. * The AEAD algorithm used in the OSCORE group. * The HKDF algorithm used in the OSCORE group. Tiloca, et al. Expires January 6, 2020 [Page 5] Internet-Draft OSCORE group discovery with the CoRE RD July 2019 3. Registration of Group Manager Endpoints During deployment, a GM finds the RD as described in Section 4 of [I-D.ietf-core-resource-directory]. Afterwards, the GM registers as an endpoint with the RD, as described in Section 5 of [I-D.ietf-core-resource-directory]. When doing so, the GM MUST also register all the join resources it has at that point in time, i.e. one for each of its OSCORE groups. For each registered join resource, the GM MUST specify the following parameters in the payload of the registration request. o 'rt' = "core.osc.j" (see Section 8.1). o 'oscore-gid', specifying the zeroed-epoch Group ID of the OSCORE group of interest. This parameter MUST specify a single value. o 'app-gp', specifying the name(s) of the application group(s) associated to the OSCORE group of interest. This parameter MAY be included multiple times, and each occurrence MUST specify the name of one application group. A same application group MUST NOT be specified multiple times. Also, for each registered join resource, the GM MAY specify the following parameters in the payload of the registration request. o 'cs_alg', specifying the algorithm used to countersign messages in the OSCORE group. If present, this parameter MUST specify a single value, which is taken from the 'Name' column of the "COSE Algorithms" Registry defined in [RFC8152]. o 'cs_crv', specifying the elliptic curve (if applicable) for the algorithm used to countersign messages in the OSCORE group. If present, this parameter MUST specify a single value, which is taken from the 'Name' column of the "COSE Elliptic Curve" Registry defined in [RFC8152]. o 'cs_kty', specifying the key type of countersignature keys used to countersign messages in the OSCORE group. If present, this parameter MUST specify a single value, which is taken from the 'Name' column of the "COSE Key Types" Registry defined in [RFC8152]. o 'cs_kenc', specifying the encoding of the public keys used in the OSCORE group. If present, this parameter MUST specify a single value, which is taken from the 'Name' column of Figure 2 in [I-D.ietf-ace-key-groupcomm-oscore], as registered in the "ACE Tiloca, et al. Expires January 6, 2020 [Page 6] Internet-Draft OSCORE group discovery with the CoRE RD July 2019 Public Key Encoding" Registry defined in [I-D.ietf-ace-key-groupcomm]. o 'alg', specifying the AEAD algorithm used in the OSCORE group. If present, this parameter MUST specify a single value, which is taken from the 'Name' column of the "COSE Algorithms" Registry defined in [RFC8152]. o 'hkdf', specifying the HKDF algorithm used in the OSCORE group. If present, this parameter MUST specify a single value, which is taken from the 'Name' column of the "COSE Algorithms" Registry defined in [RFC8152]. A CoAP endpoint that queries the RD to discover OSCORE groups and their join resource to access (see Section 5) would benefit from the link target attributes above as follows. o The values of 'cs_alg', 'cs_crv', 'cs_kty' and 'cs_kenc' related to a join resource provide an early knowledge of the format and encoding of public keys used in the OSCORE group. Thus, the CoAP endpoint does not need to ask the GM for this information as a preliminary step before the join process, or to perform a trial- and-error exchange with the GM. Hence, the CoAP endpoint is able to provide the GM with its own public key in the correct expected format and encoding at the very first step of the join process. o The values of 'cs_alg', 'alg' and 'hkdf' related to a join resource provide an early knowledge of the algorithms used in the OSCORE group. Thus, the CoAP endpoint is able to decide whether to actually proceed with the join process, depending on its support for the indicated algorithms. The GM SHOULD NOT use the Simple Registration approach described in Section 5.1 of [I-D.ietf-core-resource-directory]. The example below shows a GM with endpoint name "gm1" and address 2001:db8::ab that registers with the RD. The GM specifies the value of the 'oscore-gid' parameter for accessing the OSCORE group with zeroed-epoch Group ID "feedca570000" and used by the application group with name "group1" specified with the value of the 'app-gp' parameter. The countersignature algorithm used in the OSCORE group is EdDSA, with elliptic curve Ed25519 and keys of type OKP. Public keys used in the OSCORE group are encoded as COSE Keys [RFC8152]. Request: GM -> RD Tiloca, et al. Expires January 6, 2020 [Page 7] Internet-Draft OSCORE group discovery with the CoRE RD July 2019 Req: POST coap://rd.example.com/rd?ep=gm1 Content-Format: 40 Payload: ;ct=41;rt="core.osc.j";oscore-gid="feedca570000"; app-gp="group1";cs_alg="EdDSA";cs_crv="Ed25519"; cs_kty="OKP";cs_kenc="COSE_Key" Response: RD -> GM Res: 2.01 Created Location-Path: /rd/4521 4. Addition and Update of OSCORE Groups The GM is responsible to refresh the registration of all its join resources in the RD. This means that the GM has to update the registration within its lifetime as per Section 5.3.1 of [I-D.ietf-core-resource-directory], and has to change the content of the registration when a join resource is added/removed or if its target attributes have to be changed, such as in the following cases. o The GM creates a new OSCORE group and starts exporting the related join resource. o The GM dismisses an OSCORE group and stops exporting the related join resource. o Information related to an existing OSCORE group changes, e.g. the list of associated application groups. To perform an update of its registrations, the GM can re-register with the RD and fully specify all links to its join resources with their target attributes. The example below shows how the GM from Section 3 re-registers with the RD. When doing so, it specifies: o The same previous join resource associated to the OSCORE group with zeroed-epoch Group ID "feedca570000". o An additional join resource associated to the OSCORE group with zeroed-epoch Group ID "ech0ech00000" and used by the application group "group2". o A third join resource associated with the OSCORE group with zeroed-epoch Group ID "abcdef120000" and used by two application groups, namely "group3" and "group4". Tiloca, et al. Expires January 6, 2020 [Page 8] Internet-Draft OSCORE group discovery with the CoRE RD July 2019 Request: GM -> RD Req: POST coap://rd.example.com/rd?ep=gm1 Content-Format: 40 Payload: ;ct=41;rt="core.osc.j";oscore-gid="feedca570000"; app-gp="group1";cs_alg="EdDSA";cs_crv="Ed25519"; cs_kty="OKP";cs_kenc="COSE_Key", ;ct=41;rt="core.osc.j";oscore-gid="ech0ech00000"; app-gp="group2";cs_alg="EdDSA";cs_crv="Ed25519"; cs_kty="OKP";cs_kenc="COSE_Key", ;ct=41;rt="core.osc.j";oscore-gid="abcdef120000"; app-gp="group3";app-gp="group4";cs_alg="EdDSA"; cs_crv="Ed25519";cs_kty="OKP";cs_kenc="COSE_Key" Response: RD -> GM Res: 2.04 Changed Location-Path: /rd/4521 Alternatively, the GM can perform a PATCH/iPATCH [RFC8132] request to the RD, as per Section 5.3.3 of [I-D.ietf-core-resource-directory]. This requires new media-types to be defined in future standards, to apply a link-format document as a patch to an existing stored document. 5. Discovery of OSCORE Groups A CoAP endpoint that wants to join an OSCORE group, hereafter called the joining node, might not have all the necessary information at deployment time. Also, it might want to know about possible new OSCORE groups created afterwards by the respective Group Managers. To this end, the joining node can perform a resource lookup at the RD as per Section 6.1 of [I-D.ietf-core-resource-directory], to retrieve the missing pieces of information needed to join the OSCORE group(s) of interest. The joining node can find the RD as described in Section 4 of [I-D.ietf-core-resource-directory]. The joining node MUST use the following parameter values for the lookup filtering. o 'rt' = "core.osc.j" (see Section 8.1). The joining node MAY additionally consider the following parameters for the lookup filtering, depending on the information it has already available. Tiloca, et al. Expires January 6, 2020 [Page 9] Internet-Draft OSCORE group discovery with the CoRE RD July 2019 o 'oscore-gid', specifying the zeroed-epoch Group ID of the OSCORE group of interest. This parameter MUST specify a single value. o 'ep', specifying the registered endpoint of the GM. o 'app-gp', specifying the name(s) of the application group(s) associated with the OSCORE group of interest. This parameter MAY be included multiple times, and each occurrence MUST specify the name of one application group. An application group MUST be specified only once. 5.1. Discovery Example #1 Consistently with the examples in Section 3 and Section 4, the example below considers a joining node that wants to join the OSCORE group associated with the application group "group1", but that does not know the zeroed-epoch Group ID of the OSCORE group, the responsible GM and the join resource to access. Request: Joining node -> RD Req: GET coap://rd.example.com/rd-lookup/res ?rt=core.osc.j&app-gp=group1 Response: RD -> Joining node Res: 2.05 Content Payload: ;rt="core.osc.j"; oscore-gid="feedca570000";app-gp="group1"; cs_alg="EdDSA";cs_crv="Ed25519";cs_kty="OKP"; cs_kenc="COSE_Key";anchor="coap://[2001:db8::ab]" To retrieve the multicast IP address used in "group1", the joining node performs an endpoint lookup as shown below. The following assumes that the application group "group1" had been previously registered as per Appendix A of [I-D.ietf-core-resource-directory], with ff35:30:2001:db8::23 as associated multicast IP address. Request: Joining node -> RD Req: GET coap://rd.example.com/rd-lookup/ep ?et=core.rd-group&ep=group1 Response: RD -> Joining node Tiloca, et al. Expires January 6, 2020 [Page 10] Internet-Draft OSCORE group discovery with the CoRE RD July 2019 Res: 2.05 Content Payload: ;ep="group1";et="core.rd-group"; base="coap://[ff35:30:2001:db8::23]" 5.2. Discovery Example #2 Consistently with the examples in Section 3 and Section 4, the example below considers a joining node that wants to join the OSCORE group with zeroed-epoch Group ID "feedca570000", but that does not know the responsible GM, the join resource to access, and the associated application groups. The example also shows how the joining node uses CoAP observation [RFC7641], in order to be notified of possible changes in the join resource's target attributes. This is also useful to handle the case where the OSCORE group of interest has not been created yet, so that the joining node can receive the requested information when it becomes available. Request: Joining node -> RD Req: GET coap://rd.example.com/rd-lookup/res ?rt=osc.j&oscore-gid=feedca570000 Observe: 0 Response: RD -> Joining node Res: 2.05 Content Observe: 24 Payload: ;rt="osc.j"; oscore-gid="feedca570000";app-gp="group1"; cs_alg="EdDSA";cs_crv="Ed25519";cs_kty="OKP"; cs_kenc="COSE_Key";anchor="coap://[2001:db8::ab]" Depending on the search criteria, the joining node performing the resource lookup can get large responses. This can happen, for instance, when the lookup request targets all the join resources at a specified GM, or all the join resources of all the registered GMs, as in the example below. Request: Joining node -> RD Req: GET coap://rd.example.com/rd-lookup/res?rt=osc.j Response: RD -> Joining node Tiloca, et al. Expires January 6, 2020 [Page 11] Internet-Draft OSCORE group discovery with the CoRE RD July 2019 Res: 2.05 Content Payload: ;rt="osc.j"; oscore-gid="feedca570000";app-gp="group1"; cs_alg="EdDSA";cs_crv="Ed25519";cs_kty="OKP"; cs_kenc="COSE_Key";anchor="coap://[2001:db8::ab]", ;rt="osc.j"; oscore-gid="ech0ech00000";app-gp="group2"; cs_alg="EdDSA";cs_crv="Ed25519";cs_kty="OKP"; cs_kenc="COSE_Key";anchor="coap://[2001:db8::ab]", ;rt="osc.j"; oscore-gid="abcdef120000";app-gp="group3"; app-gp="group4";cs_alg="EdDSA";cs_crv="Ed25519"; cs_kty="OKP";cs_kenc="COSE_Key";anchor="coap://[2001:db8::ab]" Therefore, it is RECOMMENDED that a joining node which performs a resource lookup with the CoAP Observe option specifies the value of the parameter 'oscore-gid' in its GET request sent to the RD. 6. Use Case Example With Full Discovery In this section, the discovery of security groups is described to support the installation process of a lighting installation in an office building. The described process is a simplified version of one of many processes. Assume the existence of four luminaires that are members of two application groups. In the first application group, the four luminaires receive presence messages and light intensity messages from sensors or their proxy. In the second application group, the four luminaires and several other pieces of equipment receive building state schedules. Each of the two application groups is associated to a different security group and uses its own dedicated multicast IP address. The Fairhair Alliance describes how a new device is accepted and commissioned in the network [Fairhair], by means of its certificate stored during the manufacturing process. When commissioning the new device in the installation network, the new device gets a new identity defined by a newly allocated certificate, following the BRSKI specification. Section 7.3 of [I-D.ietf-core-resource-directory] describes how the Commissioning Tool (CT) assigns an endpoint name based on the CN field, (CN=ACME) and the serial number of the certificate (serial number = 123x, with 3 < x < 8). Corresponding ep-names ACME-1234, ACME-1235, ACME-1236 and ACME-1237 are also assumed. Tiloca, et al. Expires January 6, 2020 [Page 12] Internet-Draft OSCORE group discovery with the CoRE RD July 2019 It is common practice that locations in the building are specified according to a coordinate system. After the acceptance of the luminaires into the installation network, the coordinate of each device is communicated to the CT. This can be done manually or automatically. The mapping between location and ep-name is calculated by the CT. For instance, on the basis of grouping criteria, the CT assigns: i) group "grp_R2-4-015" to the four luminaires; and ii) group "grp_schedule" to all schedule requiring devices. Also, the device with ep name ACME-123x has been assigned IP address: [2001:db8:4::x]. The RD is assigned IP address: [2001:db8:4:ff]. The used multicast addresses are: [ff05::5:1] and [ff05::5:2]. *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** The CT defines the application group "grp_R2-4-015", with resource /light and base address [ff05::5:1], as follows. Request: CT -> RD Req: POST coap://[2001:db8:4::ff]/rd ?ep=grp_R2-4-015&et=core.rd-group&base=coap://[ff05::5:1] Payload: ;rt="oic.d.light" Response: RD -> CT Res: 2.01 Created Location-Path: /rd/501 Also, the CT defines a second application group "grp_schedule", with resource /schedule and base address [ff05::5:2], as follows. Request: CT -> RD Req: POST coap://[2001:db8:4::ff]/rd ?ep=grp_schedule&et=core.rd-group&base=coap://[ff05::5:2] Payload: ;rt="oic.r.time.period" Response: RD -> CT Res: 2.01 Created Location-Path: /rd/502 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Tiloca, et al. Expires January 6, 2020 [Page 13] Internet-Draft OSCORE group discovery with the CoRE RD July 2019 Consecutively, the CT registers the four devices in the RD (IP address: 2001:db8:4::ff), with their endpoint names and application groups. For group "grp_R2-4-015", four endpoints are specified as follows, with x = 4, 5, 6, 7. Request: CT -> RD Req: POST coap://[2001:db8:4::ff]/rd ?ep=ACME-123x&base=coap://[2001:db8:4::x]&app-gp=grp_R2-4-015 Payload: ;rt="oic.d.light" Response: RD -> CT Res: 2.01 Created Location-Path: /rd/452x For group "grp_schedule", four other endpoints are specified as follows, with x = 4, 5, 6, 7. Request: CT -> RD Req: POST coap://[2001:db8:4::ff]/rd ?ep=ACME-123x&base=coap://[2001:db8:4::x]&app-gp=grp_schedule Payload: ;rt="oic.r.time.period" Response: RD -> CT Res: 2.01 Created Location-Path: /rd/456x *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Finally, the CT defines the corresponding security groups. In particular, assuming a Group Manager responsible for both security groups and with address [2001:db8::ab], the CT specifies: Request: CT -> RD Req: POST coap://[2001:db8:4::ff]/rd?ep=gm1&base=coap://[2001:db8::ab] Payload: ;ct=41;rt="core.osc.j"; oscore-gid="feedca570000";app-gp="grp_R2-4-015", ;ct=41;rt="core.osc.j"; oscore-gid="feedsc590000";app-gp="grp_schedule" Tiloca, et al. Expires January 6, 2020 [Page 14] Internet-Draft OSCORE group discovery with the CoRE RD July 2019 Response: RD -> CT Res: 2.01 Created Location-Path: /rd/4521 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** The device with IP address [2001:db8:4::x] can consequently learn the groups to which it belongs. In particular, it first does an ep lookup to the RD to learn the application groups to which it belongs. Request: Joining node -> RD Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep ?base=coap://[2001:db8:4::x] Response: RD -> Joining node Res: 2.05 Content Payload: ;base=coap://[2001:db8:4::x]&ep=ACME-123x&\ app-gp=grp_R2-4-015, ;base=coap://[2001:db8:4::x]&ep=ACME-123x&\ app-gp=grp_schedule To retrieve the multicast IP address used in "grp_R2-4-015", the device performs an endpoint lookup as shown below. Request: Joining node -> RD Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep ?et=core.rd-group&ep=grp_R2-4-015 Response: RD -> Joining node Res: 2.05 Content Payload: ;ep="grp_R2-4-015";et="core.rd-group"; base="coap://[ff05::5:1]" Similarly, to retrieve the multicast IP address used in "grp_schedule", the device performs an endpoint lookup as shown below. Request: Joining node -> RD Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep ?et=core.rd-group&ep=grp_schedule Tiloca, et al. Expires January 6, 2020 [Page 15] Internet-Draft OSCORE group discovery with the CoRE RD July 2019 Response: RD -> Joining node Res: 2.05 Content Payload: ;ep="grp_schedule";et="core.rd-group"; base="coap://[ff05::5:2]" *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Having learnt the application groups to which the device belongs, the device learns the security groups to which it belongs. In particular, it does the following for app-gp="grp_R2-4-015". Request: Joining node -> RD Req: GET coap://[2001:db8:4::ff]/rd-lookup/res ?rt=core.osc.j&app-gp=grp_R2-4-015 Response: RD -> Joining Node Res: 2.05 Content Payload: ; rt="core.osc.j";oscore-gid="feedca570000"; app-gp="grp_R2-4-015";anchor="coap://[2001:db8::ab]" Similarly, the device does the following for app-gp="grp_schedule". Req: GET coap://[2001:db8:4::ff]/rd-lookup/res ?rt=core.osc.j&app-gp=grp_schedule Response: RD -> Joining Node Res: 2.05 Content Payload: ; rt="core.osc.j";oscore-gid="feedsc590000"; app-gp="grp_schedule";anchor="coap://[2001:db8::ab]" *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** After this last discovery step, the device can ask permission to join the security groups, and effectively join them through the Group Manager, e.g. according to [I-D.ietf-ace-key-groupcomm-oscore]. Tiloca, et al. Expires January 6, 2020 [Page 16] Internet-Draft OSCORE group discovery with the CoRE RD July 2019 7. Security Considerations The security considerations as described in Section 8 of [I-D.ietf-core-resource-directory] apply here as well. 8. IANA Considerations This document has the following actions for IANA. 8.1. Resource Types IANA is asked to enter the following value into the Resource Type (rt=) Link Target Attribute Values subregistry within the Constrained Restful Environments (CoRE) Parameters registry defined in [RFC6690]. +------------+----------------------+-------------------+ | Value | Description | Reference | +------------+----------------------+-------------------+ | | | | | core.osc.j | Join resource of an | [[this document]] | | | OSCORE Group Manager | | | | | | +------------+----------------------+-------------------| 9. References 9.1. Normative References [I-D.ietf-ace-key-groupcomm] Palombini, F. and M. Tiloca, "Key Provisioning for Group Communication using ACE", draft-ietf-ace-key-groupcomm-02 (work in progress), July 2019. [I-D.ietf-ace-key-groupcomm-oscore] Tiloca, M., Park, J., and F. Palombini, "Key Management for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- oscore-02 (work in progress), July 2019. [I-D.ietf-core-oscore-groupcomm] Tiloca, M., Selander, G., Palombini, F., and J. Park, "Group OSCORE - Secure Group Communication for CoAP", draft-ietf-core-oscore-groupcomm-05 (work in progress), July 2019. [I-D.ietf-core-resource-directory] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Amsuess, "CoRE Resource Directory", draft-ietf-core- resource-directory-22 (work in progress), July 2019. Tiloca, et al. Expires January 6, 2020 [Page 17] Internet-Draft OSCORE group discovery with the CoRE RD July 2019 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [Fairhair] FairHair Alliance, "Security Architecture for the Internet of Things (IoT) in Commercial Buildings", White Paper, ed. Piotr Polak , March 2018, . [I-D.dijk-core-groupcomm-bis] Dijk, E., Wang, C., and M. Tiloca, "Group Communication for the Constrained Application Protocol (CoAP)", draft- dijk-core-groupcomm-bis-00 (work in progress), March 2019. [I-D.ietf-ace-oauth-authz] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24 (work in progress), March 2019. [I-D.ietf-core-object-security] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", draft-ietf-core-object-security-16 (work in progress), March 2019. Tiloca, et al. Expires January 6, 2020 [Page 18] Internet-Draft OSCORE group discovery with the CoRE RD July 2019 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, . [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, . [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, . Acknowledgments The authors sincerely thank Carsten Bormann, Francesca Palombini, Dave Robin and Jim Schaad for their comments and feedback. The work on this document has been partly supported by VINNOVA and the Celtic-Next project CRITISEC, and by the EIT-Digital High Impact Initiative ACTIVE. Authors' Addresses Marco Tiloca RISE AB Isafjordsgatan 22 Kista SE-16440 Stockholm Sweden Email: marco.tiloca@ri.se Christian Amsuess Hollandstr. 12/4 Vienna 1020 Austria Email: christian@amsuess.com Tiloca, et al. Expires January 6, 2020 [Page 19] Internet-Draft OSCORE group discovery with the CoRE RD July 2019 Peter van der Stok Consultant Phone: +31-492474673 (Netherlands), +33-966015248 (France) Email: consultancy@vanderstok.org URI: www.vanderstok.org Tiloca, et al. Expires January 6, 2020 [Page 20]