draft-tiloca-core-oscore-discovery-08.txt | draft-tiloca-core-oscore-discovery-09.txt | |||
---|---|---|---|---|
CoRE Working Group M. Tiloca | CoRE Working Group M. Tiloca | |||
Internet-Draft RISE AB | Internet-Draft RISE AB | |||
Intended status: Standards Track C. Amsuess | Intended status: Standards Track C. Amsuess | |||
Expires: August 26, 2021 | Expires: 13 January 2022 | |||
P. van der Stok | P. van der Stok | |||
Consultant | Consultant | |||
February 22, 2021 | 12 July 2021 | |||
Discovery of OSCORE Groups with the CoRE Resource Directory | Discovery of OSCORE Groups with the CoRE Resource Directory | |||
draft-tiloca-core-oscore-discovery-08 | draft-tiloca-core-oscore-discovery-09 | |||
Abstract | Abstract | |||
Group communication over the Constrained Application Protocol (CoAP) | Group communication over the Constrained Application Protocol (CoAP) | |||
can be secured by means of Group Object Security for Constrained | can be secured by means of Group Object Security for Constrained | |||
RESTful Environments (Group OSCORE). At deployment time, devices may | RESTful Environments (Group OSCORE). At deployment time, devices may | |||
not know the exact security groups to join, the respective Group | not know the exact security groups to join, the respective Group | |||
Manager, or other information required to perform the joining | Manager, or other information required to perform the joining | |||
process. This document describes how a CoAP endpoint can use | process. This document describes how a CoAP endpoint can use | |||
descriptions and links of resources registered at the CoRE Resource | descriptions and links of resources registered at the CoRE Resource | |||
Directory to discover security groups and to acquire information for | Directory to discover security groups and to acquire information for | |||
joining them through the respective Group Manager. A given security | joining them through the respective Group Manager. A given security | |||
group may protect multiple application groups, which are separately | group may protect multiple application groups, which are separately | |||
announced in the Resource Directory as sets of endpoints sharing a | announced in the Resource Directory as sets of endpoints sharing a | |||
pool of resources. This approach is consistent with, but not limited | pool of resources. This approach is consistent with, but not limited | |||
to, the joining of security groups based on the ACE framework for | to, the joining of security groups based on the ACE framework for | |||
Authentication and Authorization in constrained environments. | Authentication and Authorization in constrained environments. | |||
Discussion Venues | ||||
This note is to be removed before publishing as an RFC. | ||||
Discussion of this document takes place on the Constrained RESTful | ||||
Environments Working Group mailing list (core@ietf.org), which is | ||||
archived at https://mailarchive.ietf.org/arch/browse/core/. | ||||
Source for this draft and an issue tracker can be found at | ||||
https://gitlab.com/crimson84/draft-tiloca-core-oscore-discovery. | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on August 26, 2021. | This Internet-Draft will expire on 13 January 2022. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2021 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
(https://trustee.ietf.org/license-info) in effect on the date of | license-info) in effect on the date of publication of this document. | |||
publication of this document. Please review these documents | Please review these documents carefully, as they describe your rights | |||
carefully, as they describe your rights and restrictions with respect | and restrictions with respect to this document. Code Components | |||
to this document. Code Components extracted from this document must | extracted from this document must include Simplified BSD License text | |||
include Simplified BSD License text as described in Section 4.e of | as described in Section 4.e of the Trust Legal Provisions and are | |||
the Trust Legal Provisions and are provided without warranty as | provided without warranty as described in the Simplified BSD License. | |||
described in the Simplified BSD License. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2. Registration of Group Manager Endpoints . . . . . . . . . . . 6 | 2. Registration of Group Manager Endpoints . . . . . . . . . . . 6 | |||
2.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2.2. Relation Link to Authorization Server . . . . . . . . . . 9 | 2.2. Relation Link to Authorization Server . . . . . . . . . . 10 | |||
2.3. Registration Example . . . . . . . . . . . . . . . . . . 10 | 2.3. Registration Example . . . . . . . . . . . . . . . . . . 11 | |||
2.3.1. Example in Link Format . . . . . . . . . . . . . . . 10 | 2.3.1. Example in Link Format . . . . . . . . . . . . . . . 11 | |||
2.3.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 11 | 2.3.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 12 | |||
3. Addition and Update of Security Groups . . . . . . . . . . . 11 | 3. Addition and Update of Security Groups . . . . . . . . . . . 13 | |||
3.1. Addition Example . . . . . . . . . . . . . . . . . . . . 12 | 3.1. Addition Example . . . . . . . . . . . . . . . . . . . . 13 | |||
3.1.1. Example in Link Format . . . . . . . . . . . . . . . 12 | 3.1.1. Example in Link Format . . . . . . . . . . . . . . . 14 | |||
3.1.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 13 | 3.1.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 14 | |||
4. Discovery of Security Groups . . . . . . . . . . . . . . . . 15 | 4. Discovery of Security Groups . . . . . . . . . . . . . . . . 16 | |||
4.1. Discovery Example #1 . . . . . . . . . . . . . . . . . . 16 | 4.1. Discovery Example #1 . . . . . . . . . . . . . . . . . . 18 | |||
4.1.1. Example in Link Format . . . . . . . . . . . . . . . 16 | 4.1.1. Example in Link Format . . . . . . . . . . . . . . . 18 | |||
4.1.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 18 | 4.1.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 19 | |||
4.2. Discovery Example #2 . . . . . . . . . . . . . . . . . . 19 | 4.2. Discovery Example #2 . . . . . . . . . . . . . . . . . . 21 | |||
4.2.1. Example in Link Format . . . . . . . . . . . . . . . 19 | 4.2.1. Example in Link Format . . . . . . . . . . . . . . . 21 | |||
4.2.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 20 | 4.2.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 22 | |||
5. Use Case Example With Full Discovery . . . . . . . . . . . . 21 | 5. Use Case Example With Full Discovery . . . . . . . . . . . . 23 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 25 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 27 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 27 | 8.2. Informative References . . . . . . . . . . . . . . . . . 29 | |||
Appendix A. Use Case Example With Full Discovery (CoRAL) . . . . 28 | Appendix A. Use Case Example With Full Discovery (CoRAL) . . . . 31 | |||
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33 | Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 36 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 | |||
1. Introduction | 1. Introduction | |||
The Constrained Application Protocol (CoAP) [RFC7252] supports group | The Constrained Application Protocol (CoAP) [RFC7252] supports group | |||
communication over IP multicast [I-D.ietf-core-groupcomm-bis] to | communication over IP multicast [I-D.ietf-core-groupcomm-bis] to | |||
improve efficiency and latency of communication and reduce bandwidth | improve efficiency and latency of communication and reduce bandwidth | |||
requirements. A set of CoAP endpoints constitutes an application | requirements. A set of CoAP endpoints constitutes an application | |||
group by sharing a common pool of resources, that can be efficiently | group by sharing a common pool of resources, that can be efficiently | |||
accessed through group communication. The members of an application | accessed through group communication. The members of an application | |||
group may be members of a security group, thus sharing a common set | group may be members of a security group, thus sharing a common set | |||
skipping to change at page 3, line 36 ¶ | skipping to change at page 3, line 44 ¶ | |||
A CoAP endpoint relies on a Group Manager (GM) to join a security | A CoAP endpoint relies on a Group Manager (GM) to join a security | |||
group and get the group keying material. The joining process in | group and get the group keying material. The joining process in | |||
[I-D.ietf-ace-key-groupcomm-oscore] is based on the ACE framework for | [I-D.ietf-ace-key-groupcomm-oscore] is based on the ACE framework for | |||
Authentication and Authorization in constrained environments | Authentication and Authorization in constrained environments | |||
[I-D.ietf-ace-oauth-authz], with the joining endpoint and the GM | [I-D.ietf-ace-oauth-authz], with the joining endpoint and the GM | |||
acting as ACE Client and Resource Server, respectively. That is, the | acting as ACE Client and Resource Server, respectively. That is, the | |||
joining endpoint accesses the group-membership resource exported by | joining endpoint accesses the group-membership resource exported by | |||
the GM and associated with the security group to join. | the GM and associated with the security group to join. | |||
Typically, devices store a static X509 IDevID certificate installed | Typically, devices store a static X509 IDevID certificate installed | |||
at manufacturing time [I-D.ietf-anima-bootstrapping-keyinfra]. This | at manufacturing time [RFC8995]. This is used at deployment time | |||
is used at deployment time during an enrollment process that provides | during an enrollment process that provides the devices with an | |||
the devices with an Operational Certificate, possibly updated during | Operational Certificate, possibly updated during the device lifetime. | |||
the device lifetime. Operational Certificates may specify | Operational Certificates may specify information to join security | |||
information to join security groups, especially a reference to the | groups, especially a reference to the group-membership resources to | |||
group-membership resources to access at the respective GMs. | access at the respective GMs. | |||
However, it is usually impossible to provide such precise information | However, it is usually impossible to provide such precise information | |||
to freshly deployed devices, as part of their (early) Operational | to freshly deployed devices, as part of their (early) Operational | |||
Certificate. This can be due to a number of reasons: (1) the | Certificate. This can be due to a number of reasons: (1) the | |||
security group(s) to join and the responsible GM(s) are generally | security group(s) to join and the responsible GM(s) are generally | |||
unknown at manufacturing time; (2) a security group of interest is | unknown at manufacturing time; (2) a security group of interest is | |||
created, or the responsible GM is deployed, only after the device is | created, or the responsible GM is deployed, only after the device is | |||
enrolled and fully operative in the network; (3) information related | enrolled and fully operative in the network; (3) information related | |||
to existing security groups or to their GMs has changed. This | to existing security groups or to their GMs has changed. This | |||
requires a method for CoAP endpoints to dynamically discover security | requires a method for CoAP endpoints to dynamically discover security | |||
skipping to change at page 4, line 38 ¶ | skipping to change at page 4, line 48 ¶ | |||
specified as target attributes of the registered link, and includes | specified as target attributes of the registered link, and includes | |||
the identifiers of the application groups which use that security | the identifiers of the application groups which use that security | |||
group. This enables a lookup of those application groups at the RD, | group. This enables a lookup of those application groups at the RD, | |||
where they are separately announced by a Commissioning Tool (see | where they are separately announced by a Commissioning Tool (see | |||
Appendix A of [I-D.ietf-core-resource-directory]). | Appendix A of [I-D.ietf-core-resource-directory]). | |||
When querying the RD for security groups, a CoAP endpoint can use | When querying the RD for security groups, a CoAP endpoint can use | |||
CoAP observation [RFC7641]. This results in automatic notifications | CoAP observation [RFC7641]. This results in automatic notifications | |||
on the creation of new security groups or the update of existing | on the creation of new security groups or the update of existing | |||
groups. Thus, it facilitates the early deployment of CoAP endpoints, | groups. Thus, it facilitates the early deployment of CoAP endpoints, | |||
i.e. even before the GM is deployed and security groups are created. | i.e., even before the GM is deployed and security groups are created. | |||
Interaction examples are provided in Link Format, as well as in the | Interaction examples are provided in Link Format, as well as in the | |||
Constrained RESTful Application Language CoRAL [I-D.ietf-core-coral] | Constrained RESTful Application Language CoRAL [I-D.ietf-core-coral] | |||
with reference to a CoRAL-based RD [I-D.hartke-t2trg-coral-reef]. | with reference to a CoRAL-based RD [I-D.hartke-t2trg-coral-reef]. | |||
While all the CoRAL examples show the CoRAL textual serialization | While all the CoRAL examples show the CoRAL textual serialization | |||
format, its binary serialization format is used on the wire. | format, its binary serialization format is used on the wire. | |||
The approach in this document is consistent with, but not limited to, | The approach in this document is consistent with, but not limited to, | |||
the joining of security groups defined in | the joining of security groups defined in | |||
[I-D.ietf-ace-key-groupcomm-oscore]. | [I-D.ietf-ace-key-groupcomm-oscore]. | |||
skipping to change at page 5, line 28 ¶ | skipping to change at page 5, line 38 ¶ | |||
[I-D.ietf-core-oscore-groupcomm] and | [I-D.ietf-core-oscore-groupcomm] and | |||
[I-D.ietf-ace-key-groupcomm-oscore]. | [I-D.ietf-ace-key-groupcomm-oscore]. | |||
Terminology for constrained environments, such as "constrained | Terminology for constrained environments, such as "constrained | |||
device" and "constrained-node network", is defined in [RFC7228]. | device" and "constrained-node network", is defined in [RFC7228]. | |||
Consistently with the definitions from Section 2.1 of | Consistently with the definitions from Section 2.1 of | |||
[I-D.ietf-core-groupcomm-bis], this document also refers to the | [I-D.ietf-core-groupcomm-bis], this document also refers to the | |||
following terminology. | following terminology. | |||
o CoAP group: a set of CoAP endpoints all configured to receive CoAP | * CoAP group: a set of CoAP endpoints all configured to receive CoAP | |||
multicast messages sent to the group's associated IP multicast | multicast messages sent to the group's associated IP multicast | |||
address and UDP port. An endpoint may be a member of multiple | address and UDP port. An endpoint may be a member of multiple | |||
CoAP groups by subscribing to multiple IP multicast addresses. | CoAP groups by subscribing to multiple IP multicast addresses. | |||
o Security group: a set of CoAP endpoints that share the same | * Security group: a set of CoAP endpoints that share the same | |||
security material, and use it to protect and verify exchanged | security material, and use it to protect and verify exchanged | |||
messages. A CoAP endpoint may be a member of multiple security | messages. A CoAP endpoint may be a member of multiple security | |||
groups. There can be a one-to-one or a one-to-many relation | groups. There can be a one-to-one or a one-to-many relation | |||
between security groups and CoAP groups. | between security groups and CoAP groups. | |||
This document especially considers a security group to be an | This document especially considers a security group to be an | |||
OSCORE group, where all members share one OSCORE Security Context | OSCORE group, where all members share one OSCORE Security Context | |||
to protect group communication with Group OSCORE | to protect group communication with Group OSCORE | |||
[I-D.ietf-core-oscore-groupcomm]. However, the approach defined | [I-D.ietf-core-oscore-groupcomm]. However, the approach defined | |||
in this document can be used to support the discovery of different | in this document can be used to support the discovery of different | |||
security groups than OSCORE groups. | security groups than OSCORE groups. | |||
o Application group: a set of CoAP endpoints that share a common set | * Application group: a set of CoAP endpoints that share a common set | |||
of resources. An endpoint may be a member of multiple application | of resources. An endpoint may be a member of multiple application | |||
groups. An application group can be associated with one or more | groups. An application group can be associated with one or more | |||
security groups, and multiple application groups can use the same | security groups, and multiple application groups can use the same | |||
security group. Application groups are announced in the RD by a | security group. Application groups are announced in the RD by a | |||
Commissioning Tool, according to the RD-Groups usage pattern (see | Commissioning Tool, according to the RD-Groups usage pattern (see | |||
Appendix A of [I-D.ietf-core-resource-directory]). | Appendix A of [I-D.ietf-core-resource-directory]). | |||
2. Registration of Group Manager Endpoints | 2. Registration of Group Manager Endpoints | |||
During deployment, a Group Manager (GM) can find the CoRE Resource | During deployment, a Group Manager (GM) can find the CoRE Resource | |||
Directory (RD) as described in Section 4 of | Directory (RD) as described in Section 4 of | |||
[I-D.ietf-core-resource-directory]. | [I-D.ietf-core-resource-directory]. | |||
Afterwards, the GM registers as an endpoint with the RD, as described | Afterwards, the GM registers as an endpoint with the RD, as described | |||
in Section 5 of [I-D.ietf-core-resource-directory]. The GM SHOULD | in Section 5 of [I-D.ietf-core-resource-directory]. The GM SHOULD | |||
NOT use the Simple Registration approach described in Section 5.1 of | NOT use the Simple Registration approach described in Section 5.1 of | |||
[I-D.ietf-core-resource-directory]. | [I-D.ietf-core-resource-directory]. | |||
When registering with the RD, the GM also registers the links to all | When registering with the RD, the GM also registers the links to all | |||
the group-membership resources it has at that point in time, i.e. one | the group-membership resources it has at that point in time, i.e., | |||
for each of its security groups. | one for each of its security groups. | |||
In the registration request, each link to a group-membership resource | In the registration request, each link to a group-membership resource | |||
has as target the URI of that resource at the GM. Also, it specifies | has as target the URI of that resource at the GM. Also, it specifies | |||
a number of descriptive parameters as defined in Section 2.1. | a number of descriptive parameters as defined in Section 2.1. | |||
2.1. Parameters | 2.1. Parameters | |||
For each registered link to a group-membership resource at a GM, the | For each registered link to a group-membership resource at a GM, the | |||
following parameters are specified together with the link. | following parameters are specified together with the link. | |||
In the RD defined in [I-D.ietf-core-resource-directory] and based on | In the RD defined in [I-D.ietf-core-resource-directory] and based on | |||
Link Format, each parameter is specified in a target attribute with | Link Format, each parameter is specified in a target attribute with | |||
the same name. | the same name. | |||
In a RD based on CoRAL, such as the one defined in | In a RD based on CoRAL, such as the one defined in | |||
[I-D.hartke-t2trg-coral-reef], each parameter is specified in a | [I-D.hartke-t2trg-coral-reef], each parameter is specified in a | |||
nested element with the same name. | nested element with the same name. | |||
o 'ct', specifying the content format used with the group-membership | * 'ct', specifying the content format used with the group-membership | |||
resource at the Group Manager, with value "application/ace- | resource at the Group Manager, with value "application/ace- | |||
groupcomm+cbor" registered in Section 8.2 of | groupcomm+cbor" registered in Section 8.2 of | |||
[I-D.ietf-ace-key-groupcomm]. | [I-D.ietf-ace-key-groupcomm]. | |||
Note: The examples in this document use the provisional value | Note: The examples in this document use the provisional value | |||
65000 from the range "Reserved for Experimental Use" of the "CoAP | 65000 from the range "Reserved for Experimental Use" of the "CoAP | |||
Content-Formats" registry, within the "CoRE Parameters" registry. | Content-Formats" registry, within the "CoRE Parameters" registry. | |||
o 'rt', specifying the resource type of the group-membership | * 'rt', specifying the resource type of the group-membership | |||
resource at the Group Manager, with value "core.osc.gm" registered | resource at the Group Manager, with value "core.osc.gm" registered | |||
in Section 21.11 of [I-D.ietf-ace-key-groupcomm-oscore]. | in Section 21.11 of [I-D.ietf-ace-key-groupcomm-oscore]. | |||
o 'if', specifying the interface description for accessing the | * 'if', specifying the interface description for accessing the | |||
group-membership resource at the Group Manager, with value | group-membership resource at the Group Manager, with value | |||
"ace.group" registered in Section 8.10 of | "ace.group" registered in Section 8.10 of | |||
[I-D.ietf-ace-key-groupcomm]. | [I-D.ietf-ace-key-groupcomm]. | |||
o 'sec-gp', specifying the name of the security group of interest, | * 'sec-gp', specifying the name of the security group of interest, | |||
as a stable and invariant identifier, such as the group name used | as a stable and invariant identifier, such as the group name used | |||
in [I-D.ietf-ace-key-groupcomm-oscore]. This parameter MUST | in [I-D.ietf-ace-key-groupcomm-oscore]. This parameter MUST | |||
specify a single value. | specify a single value. | |||
o 'app-gp', specifying the name(s) of the application group(s) | * 'app-gp', specifying the name(s) of the application group(s) | |||
associated to the security group of interest indicated by 'sec- | associated to the security group of interest indicated by 'sec- | |||
gp'. This parameter MUST occur once for each application group, | gp'. This parameter MUST occur once for each application group, | |||
and MUST specify only a single application group. | and MUST specify only a single application group. | |||
When a security group is created at the GM, the names of the | When a security group is created at the GM, the names of the | |||
application groups using it are also specified as part of the | application groups using it are also specified as part of the | |||
security group configuration (see [I-D.ietf-ace-oscore-gm-admin]). | security group configuration (see [I-D.ietf-ace-oscore-gm-admin]). | |||
Thus, when registering the links to its group-membership resource, | Thus, when registering the links to its group-membership resource, | |||
the GM is aware of the application groups and their names. | the GM is aware of the application groups and their names. | |||
If a different entity than the GM registers the security groups to | If a different entity than the GM registers the security groups to | |||
the RD, e.g. a Commissioning Tool, this entity has to also be | the RD, e.g., a Commissioning Tool, this entity has to also be | |||
aware of the application groups and their names to specify. To | aware of the application groups and their names to specify. To | |||
this end, it can obtain them from the GM or from the Administator | this end, it can obtain them from the GM or from the Administator | |||
that created the security groups at the GM (see | that created the security groups at the GM (see | |||
[I-D.ietf-ace-oscore-gm-admin]). | [I-D.ietf-ace-oscore-gm-admin]). | |||
Optionally, the following parameters can also be specified. If Link | Optionally, the following parameters can also be specified. If Link | |||
Format is used, the value of each of these parameters is encoded as a | Format is used, the value of each of these parameters is encoded as a | |||
text string. | text string. | |||
o 'alg', specifying the AEAD algorithm used in the security group. | * 'hkdf', specifying the HKDF Algorithm used in the security group. | |||
If present, this parameter MUST specify a single value, which is | If present, this parameter MUST specify a single value, which is | |||
taken from the 'Value' column of the "COSE Algorithms" Registry | taken from the 'Value' column of the "COSE Algorithms" Registry | |||
[COSE.Algorithms]. | [COSE.Algorithms]. | |||
o 'hkdf', specifying the HKDF algorithm used in the security group. | * 'pub_key_enc', specifying the encoding of the public keys used in | |||
If present, this parameter MUST specify a single value, which is | ||||
taken from the 'Value' column of the "COSE Algorithms" Registry | ||||
defined in [COSE.Algorithms]. | ||||
o 'cs_alg', specifying the algorithm used to countersign messages in | ||||
the security group. If present, this parameter MUST specify a | the security group. If present, this parameter MUST specify a | |||
single value, which is taken from the 'Value' column of the "COSE | single value, which is taken from the 'Label' column of the "COSE | |||
Header Parameters" Registry [COSE.Header.Parameters]. Acceptable | ||||
values denote an encoding that MUST explicitly provide the full | ||||
set of information related to the public key algorithm, including, | ||||
e.g., the used elliptic curve (when applicable). | ||||
At the time of writing this specification, acceptable public key | ||||
encodings are CWTs [RFC8392], unprotected CWT claim sets | ||||
[I-D.ietf-rats-uccs], X.509 certificates [RFC7925] and C509 | ||||
certificates [I-D.ietf-cose-cbor-encoded-cert]. Further encodings | ||||
may be available in the future, and would be acceptable to use as | ||||
long as they comply with the criteria defined above. | ||||
[ As to CWTs and unprotected CWT claim sets, there is a pending | ||||
registration requested by draft-ietf-lake-edhoc. ] | ||||
[ As to C509 certificates, there is a pending registration | ||||
requested by draft-ietf-cose-cbor-encoded-cert. ] | ||||
* 'sign_enc_alg', specifying the encryption algorithm used to | ||||
encrypt messages in the security group, when these are also | ||||
signed, e.g., as in the group mode of Group OSCORE (see Section 8 | ||||
of [I-D.ietf-core-oscore-groupcomm]). If present, this parameter | ||||
MUST specify a single value, which is taken from the 'Value' | ||||
column of the "COSE Algorithms" Registry [COSE.Algorithms]. | ||||
* 'sign_alg', specifying the algorithm used to sign messages in the | ||||
security group. If present, this parameter MUST specify a single | ||||
value, which is taken from the 'Value' column of the "COSE | ||||
Algorithms" Registry [COSE.Algorithms]. | Algorithms" Registry [COSE.Algorithms]. | |||
o 'cs_alg_crv', specifying the elliptic curve (if applicable) for | * 'sign_alg_crv', specifying the elliptic curve (if applicable) for | |||
the algorithm used to countersign messages in the security group. | the algorithm used to sign messages in the security group. If | |||
If present, this parameter MUST specify a single value, which is | present, this parameter MUST specify a single value, which is | |||
taken from the 'Value' column of the "COSE Elliptic Curves" | taken from the 'Value' column of the "COSE Elliptic Curves" | |||
Registry [COSE.Elliptic.Curves]. | Registry [COSE.Elliptic.Curves]. | |||
o 'cs_key_kty', specifying the key type of countersignature keys | * 'sign_key_kty', specifying the key type of countersignature keys | |||
used to countersign messages in the security group. If present, | used to sign messages in the security group. If present, this | |||
this parameter MUST specify a single value, which is taken from | parameter MUST specify a single value, which is taken from the | |||
the 'Value' column of the "COSE Key Types" Registry | 'Value' column of the "COSE Key Types" Registry [COSE.Key.Types]. | |||
[COSE.Key.Types]. | ||||
o 'cs_key_crv', specifying the elliptic curve (if applicable) of | * 'sign_key_crv', specifying the elliptic curve (if applicable) of | |||
countersignature keys used to countersign messages in the security | countersignature keys used to sign messages in the security group. | |||
group. If present, this parameter MUST specify a single value, | If present, this parameter MUST specify a single value, which is | |||
which is taken from the 'Value' column of the "COSE Elliptic | taken from the 'Value' column of the "COSE Elliptic Curves" | |||
Curves" Registry defined in [COSE.Elliptic.Curves]. | Registry [COSE.Elliptic.Curves]. | |||
o 'cs_kenc', specifying the encoding of the public keys used in the | * 'alg', specifying the encryption algorithm used to encrypt | |||
security group. If present, this parameter MUST specify a single | messages in the security group, when these are encrypted with | |||
value. This specification explicitly admits the signaling of COSE | pairwise encryption keys, e.g., as in the pairwise mode of Group | |||
Keys [I-D.ietf-cose-rfc8152bis-struct] as encoding for public | OSCORE (see Section 9 of [I-D.ietf-core-oscore-groupcomm]). If | |||
keys, which is indicated with "1", as taken from the 'Confirmation | present, this parameter MUST specify a single value, which is | |||
Key' column of the "CWT Confirmation Method" Registry defined in | taken from the 'Value' column of the "COSE Algorithms" Registry | |||
[RFC8747]. Future specifications may define additional values for | [COSE.Algorithms]. | |||
this parameter. | ||||
o 'ecdh_alg', specifying the ECDH algorithm used to derive pairwise | * 'ecdh_alg', specifying the ECDH algorithm used to derive pairwise | |||
encryption keys in the security group, e.g. as for the pairwise | encryption keys in the security group, e.g., as for the pairwise | |||
mode of Group OSCORE (see Section 2.3 of | mode of Group OSCORE (see Section 2.3 of | |||
[I-D.ietf-core-oscore-groupcomm]). If present, this parameter | [I-D.ietf-core-oscore-groupcomm]). If present, this parameter | |||
MUST specify a single value, which is taken from the 'Value' | MUST specify a single value, which is taken from the 'Value' | |||
column of the "COSE Algorithms" Registry [COSE.Algorithms]. | column of the "COSE Algorithms" Registry [COSE.Algorithms]. | |||
o 'ecdh_alg_crv', specifying the elliptic curve for the ECDH | * 'ecdh_alg_crv', specifying the elliptic curve for the ECDH | |||
algorithm used to derive pairwise encryption keys in the security | algorithm used to derive pairwise encryption keys in the security | |||
group. If present, this parameter MUST specify a single value, | group. If present, this parameter MUST specify a single value, | |||
which is taken from the 'Value' column of the "COSE Elliptic | which is taken from the 'Value' column of the "COSE Elliptic | |||
Curves" Registry [COSE.Elliptic.Curves]. | Curves" Registry [COSE.Elliptic.Curves]. | |||
o 'ecdh_key_kty', specifying the key type of keys used with an ECDH | * 'ecdh_key_kty', specifying the key type of keys used with an ECDH | |||
algorithm to derive pairwise encryption keys in the security | algorithm to derive pairwise encryption keys in the security | |||
group. If present, this parameter MUST specify a single value, | group. If present, this parameter MUST specify a single value, | |||
which is taken from the 'Value' column of the "COSE Key Types" | which is taken from the 'Value' column of the "COSE Key Types" | |||
Registry [COSE.Key.Types]. | Registry [COSE.Key.Types]. | |||
o 'ecdh_key_crv', specifying the elliptic curve of keys used with an | * 'ecdh_key_crv', specifying the elliptic curve of keys used with an | |||
ECDH algorithm to derive pairwise encryption keys in the security | ECDH algorithm to derive pairwise encryption keys in the security | |||
group. If present, this parameter MUST specify a single value, | group. If present, this parameter MUST specify a single value, | |||
which is taken from the 'Value' column of the "COSE Elliptic | which is taken from the 'Value' column of the "COSE Elliptic | |||
Curves" Registry defined in [COSE.Elliptic.Curves]. | Curves" Registry [COSE.Elliptic.Curves]. | |||
If the security group does not recur to message signing, then the | ||||
parameters 'sign_enc_alg', 'sign_alg', 'sign_alg_crv', 'sign_key_kty' | ||||
and 'sign_key_crv' MUST NOT be present. For instance, this is the | ||||
case for a security group that uses Group OSCORE and uses only the | ||||
pairwise mode (see Section 9 of [I-D.ietf-core-oscore-groupcomm]). | ||||
If the security group does not recur to message encryption through | ||||
pairwise encryption keys, then the parameters 'alg', 'ecdh_alg', | ||||
'ecdh_alg_crv', 'ecdh_key_kty' and 'ecdh_key_crv' MUST NOT be | ||||
present. For instance, this is the case for a security group that | ||||
uses Group OSCORE and uses only the group mode see Section 8 of | ||||
[I-D.ietf-core-oscore-groupcomm]). | ||||
Note that the values registered in the COSE Registries | Note that the values registered in the COSE Registries | |||
[COSE.Algorithms][COSE.Elliptic.Curves][COSE.Key.Types] are strongly | [COSE.Algorithms][COSE.Elliptic.Curves][COSE.Key.Types] are strongly | |||
typed. On the contrary, Link Format is weakly typed and thus does | typed. On the contrary, Link Format is weakly typed and thus does | |||
not distinguish between, for instance, the string value "-10" and the | not distinguish between, for instance, the string value "-10" and the | |||
integer value -10. | integer value -10. | |||
Thus, in RDs that return responses in Link Format, string values | Thus, in RDs that return responses in Link Format, string values | |||
which look like an integer are not supported. Therefore, such values | which look like an integer are not supported. Therefore, such values | |||
MUST NOT be advertised through the corresponding parameters above. | MUST NOT be advertised through the corresponding parameters above. | |||
A CoAP endpoint that queries the RD to discover security groups and | A CoAP endpoint that queries the RD to discover security groups and | |||
their group-membership resource to access (see Section 4) would | their group-membership resource to access (see Section 4) would | |||
benefit from the information above as follows. | benefit from the information above as follows. | |||
o The values of 'cs_alg', 'cs_alg_crv', 'cs_key_kty', 'cs_key_crv', | * The values of 'pub_key_enc', 'sign_alg', 'sign_alg_crv', | |||
'cs_kenc', 'ecdh_alg', 'ecdh_alg_crv', 'ecdh_key_kty' and | 'sign_key_kty', 'sign_key_crv', 'ecdh_alg', 'ecdh_alg_crv', | |||
'ecdh_key_crv' related to a group-membership resource provide an | 'ecdh_key_kty' and 'ecdh_key_crv' related to a group-membership | |||
early knowledge of the format and encoding of public keys used in | resource provide an early knowledge of the format and encoding of | |||
the security group. Thus, the CoAP endpoint does not need to ask | public keys used in the security group. | |||
the GM for this information as a preliminary step before the | ||||
joining process, or to perform a trial-and-error joining 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 joining process. | ||||
o The values of 'alg', 'hkdf', 'cs_alg' and 'ecdh_alg' related to a | Thus, the CoAP endpoint does not need to ask the GM for this | |||
group-membership resource provide an early knowledge of the | information as a preliminary step before the joining process, or | |||
algorithms used in the security group. Thus, the CoAP endpoint is | to perform a trial-and-error joining exchange with the GM. Hence, | |||
able to decide whether to actually proceed with the joining | the CoAP endpoint is able to provide the GM with its own public | |||
process, depending on its support for the indicated algorithms. | key in the correct expected format and encoding at the very first | |||
step of the joining process. | ||||
* The values of 'hkdf', 'sign_enc_alg', 'sign_alg', 'alg' and | ||||
'ecdh_alg' related to a group-membership resource provide an early | ||||
knowledge of the algorithms used in the security group. | ||||
Thus, the CoAP endpoint is able to decide whether to actually | ||||
proceed with the joining process, depending on its support for the | ||||
indicated algorithms. | ||||
2.2. Relation Link to Authorization Server | 2.2. Relation Link to Authorization Server | |||
For each registered link to a group-membership resource, the GM MAY | For each registered link to a group-membership resource, the GM MAY | |||
additionally specify the link to the ACE Authorization Server (AS) | additionally specify the link to the ACE Authorization Server (AS) | |||
[I-D.ietf-ace-oauth-authz] associated to the GM, and issuing | [I-D.ietf-ace-oauth-authz] associated to the GM, and issuing | |||
authorization credentials to join the security group as described in | authorization credentials to join the security group as described in | |||
[I-D.ietf-ace-key-groupcomm-oscore]. | [I-D.ietf-ace-key-groupcomm-oscore]. | |||
The link to the AS has as target the URI of the resource where to | The link to the AS has as target the URI of the resource where to | |||
send an authorization request to. | send an authorization request to. | |||
In the RD defined in [I-D.ietf-core-resource-directory] and based on | In the RD defined in [I-D.ietf-core-resource-directory] and based on | |||
Link Format, the link to the AS is separately registered with the RD, | Link Format, the link to the AS is separately registered with the RD, | |||
and includes the following parameters as target attributes. | and includes the following parameters as target attributes. | |||
o 'rel', with value "authorization_server". | * 'rel', with value "authorization_server". | |||
o 'anchor', with value the target of the link to the group- | * 'anchor', with value the target of the link to the group- | |||
membership resource at the GM. | membership resource at the GM. | |||
In a RD based on CoRAL, such as the one defined in | In a RD based on CoRAL, such as the one defined in | |||
[I-D.hartke-t2trg-coral-reef], this is mapped (as describe there) to | [I-D.hartke-t2trg-coral-reef], this is mapped (as describe there) to | |||
a link from the registration resource to the AS, using the | a link from the registration resource to the AS, using the | |||
<http://www.iana.org/assignments/relation/authorization_server> link | <http://www.iana.org/assignments/relation/authorization_server> link | |||
relation type. | relation type. | |||
2.3. Registration Example | 2.3. Registration Example | |||
The example below shows a GM with endpoint name "gm1" and address | The example below shows a GM with endpoint name "gm1" and address | |||
2001:db8::ab that registers with the RD. | 2001:db8::ab that registers with the RD. | |||
The GM specifies the value of the 'sec-gp' parameter for accessing | The GM specifies the value of the 'sec-gp' parameter for accessing | |||
the security group with name "feedca570000", and used by the | the security group with name "feedca570000", and used by the | |||
application group with name "group1" specified with the value of the | application group with name "group1" specified with the value of the | |||
'app-gp' parameter. | 'app-gp' parameter. | |||
The countersignature algorithm used in the security group is EdDSA | The countersignature algorithm used in the security group is EdDSA | |||
(-8), with elliptic curve Ed25519 (6). Public keys used in the | (-8), with elliptic curve Ed25519 (6). Public keys used in the | |||
security group are encoded as COSE Keys (1) | security group are encoded as X.509 certificates [RFC7925], which is | |||
[I-D.ietf-cose-rfc8152bis-struct]. The ECDH algorithm used in the | signaled through the COSE Header Parameter "x5chain" (33). The ECDH | |||
security group is ECDH-SS + HKDF-256 (-27), with elliptic curve | algorithm used in the security group is ECDH-SS + HKDF-256 (-27), | |||
X25519 (4). | with elliptic curve X25519 (4). | |||
In addition, the GM specifies the link to the ACE Authorization | In addition, the GM specifies the link to the ACE Authorization | |||
Server associated to the GM, to which a CoAP endpoint should send an | Server associated to the GM, to which a CoAP endpoint should send an | |||
Authorization Request for joining the corresponding security group | Authorization Request for joining the corresponding security group | |||
(see [I-D.ietf-ace-key-groupcomm-oscore]). | (see [I-D.ietf-ace-key-groupcomm-oscore]). | |||
2.3.1. Example in Link Format | 2.3.1. Example in Link Format | |||
Request: GM -> RD | Request: GM -> RD | |||
Req: POST coap://rd.example.com/rd?ep=gm1 | Req: POST coap://rd.example.com/rd?ep=gm1 | |||
Content-Format: 40 | Content-Format: 40 | |||
Payload: | Payload: | |||
</ace-group/feedca570000>;ct=65000;rt="core.osc.gm";if="ace.group"; | </ace-group/feedca570000>;ct=65000;rt="core.osc.gm";if="ace.group"; | |||
sec-gp="feedca570000";app-gp="group1"; | sec-gp="feedca570000";app-gp="group1"; | |||
cs_alg="-8";cs_alg_crv="6"; | pub_key_enc="33";sign_enc_alg="10"; | |||
cs_kenc="1";ecdh_alg="-27"; | sign_alg="-8";sign_alg_crv="6"; | |||
ecdh_alg_crv="4", | alg="10";ecdh_alg="-27";ecdh_alg_crv="4", | |||
<coap://as.example.com/token>; | <coap://as.example.com/token>; | |||
rel="authorization-server"; | rel="authorization-server"; | |||
anchor="coap://[2001:db8::ab]/ace-group/feedca570000" | anchor="coap://[2001:db8::ab]/ace-group/feedca570000" | |||
Response: RD -> GM | Response: RD -> GM | |||
Res: 2.01 Created | Res: 2.01 Created | |||
Location-Path: /rd/4521 | Location-Path: /rd/4521 | |||
2.3.2. Example in CoRAL | 2.3.2. Example in CoRAL | |||
Request: GM -> RD | Request: GM -> RD | |||
Req: POST coap://rd.example.com/rd?ep=gm1 | Req: POST coap://rd.example.com/rd?ep=gm1 | |||
Content-Format: TBD123456 (application/coral+cbor) | Content-Format: TBD123456 (application/coral+cbor) | |||
skipping to change at page 11, line 26 ¶ | skipping to change at page 12, line 41 ¶ | |||
#using reef = <http://coreapps.org/reef#> | #using reef = <http://coreapps.org/reef#> | |||
#using iana = <http://www.iana.org/assignments/relation/> | #using iana = <http://www.iana.org/assignments/relation/> | |||
#base <coap://[2001:db8::ab]/> | #base <coap://[2001:db8::ab]/> | |||
reef:rd-item </ace-group/feedca570000> { | reef:rd-item </ace-group/feedca570000> { | |||
reef:ct 65000 | reef:ct 65000 | |||
reef:rt "core.osc.gm" | reef:rt "core.osc.gm" | |||
reef:if "ace.group" | reef:if "ace.group" | |||
sec-gp "feedca570000" | sec-gp "feedca570000" | |||
app-gp "group1" | app-gp "group1" | |||
cs_alg -8 | pub_key_enc 33 | |||
cs_alg_crv 6 | sign_enc_alg 10 | |||
cs_kenc 1 | sign_alg -8 | |||
sign_alg_crv 6 | ||||
alg 10 | ||||
ecdh_alg -27 | ecdh_alg -27 | |||
ecdh_alg_crv 4 | ecdh_alg_crv 4 | |||
iana:authorization-server <coap://as.example.com/token> | iana:authorization-server <coap://as.example.com/token> | |||
} | } | |||
Response: RD -> GM | Response: RD -> GM | |||
Res: 2.01 Created | Res: 2.01 Created | |||
Location-Path: /rd/4521 | Location-Path: /rd/4521 | |||
3. Addition and Update of Security Groups | 3. Addition and Update of Security Groups | |||
The GM is responsible to refresh the registration of all its group- | The GM is responsible to refresh the registration of all its group- | |||
membership resources in the RD. This means that the GM has to update | membership resources in the RD. This means that the GM has to update | |||
the registration within its lifetime as per Section 5.3.1 of | 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 | [I-D.ietf-core-resource-directory], and has to change the content of | |||
the registration when a group-membership resource is added/removed, | the registration when a group-membership resource is added/removed, | |||
or if its parameters have to be changed, such as in the following | or if its parameters have to be changed, such as in the following | |||
cases. | cases. | |||
o The GM creates a new security group and starts exporting the | * The GM creates a new security group and starts exporting the | |||
related group-membership resource. | related group-membership resource. | |||
o The GM dismisses a security group and stops exporting the related | * The GM dismisses a security group and stops exporting the related | |||
group-membership resource. | group-membership resource. | |||
o Information related to an existing security group changes, e.g. | * Information related to an existing security group changes, e.g., | |||
the list of associated application groups. | the list of associated application groups. | |||
To perform an update of its registrations, the GM can re-register | To perform an update of its registrations, the GM can re-register | |||
with the RD and fully specify all links to its group-membership | with the RD and fully specify all links to its group-membership | |||
resources. | resources. | |||
Alternatively, the GM can perform a PATCH/iPATCH [RFC8132] request to | 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]. | 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 | This requires new media-types to be defined in future standards, to | |||
apply a new document as a patch to an existing stored document. | apply a new document as a patch to an existing stored document. | |||
3.1. Addition Example | 3.1. Addition Example | |||
The example below shows how the GM from Section 2 re-registers with | The example below shows how the GM from Section 2 re-registers with | |||
the RD. When doing so, it specifies: | the RD. When doing so, it specifies: | |||
o The same previous group-membership resource associated to the | * The same previous group-membership resource associated to the | |||
security group with name "feedca570000". | security group with name "feedca570000". | |||
o An additional group-membership resource associated to the security | * An additional group-membership resource associated to the security | |||
group with name "ech0ech00000" and used by the application group | group with name "ech0ech00000" and used by the application group | |||
"group2". | "group2". | |||
o A third group-membership resource associated with the security | * A third group-membership resource associated with the security | |||
group with name "abcdef120000" and used by two application groups, | group with name "abcdef120000" and used by two application groups, | |||
namely "group3" and "group4". | namely "group3" and "group4". | |||
Furthermore, the GM relates the same Authorization Server also to the | Furthermore, the GM relates the same Authorization Server also to the | |||
security groups "ech0ech00000" and "abcdef120000". | security groups "ech0ech00000" and "abcdef120000". | |||
3.1.1. Example in Link Format | 3.1.1. Example in Link Format | |||
Request: GM -> RD | Request: GM -> RD | |||
Req: POST coap://rd.example.com/rd?ep=gm1 | ||||
Content-Format: 40 | Req: POST coap://rd.example.com/rd?ep=gm1 | |||
Payload: | Content-Format: 40 | |||
</ace-group/feedca570000>;ct=65000;rt="core.osc.gm";if="ace.group"; | Payload: | |||
sec-gp="feedca570000";app-gp="group1"; | </ace-group/feedca570000>;ct=65000;rt="core.osc.gm";if="ace.group"; | |||
cs_alg="-8";cs_alg_crv="6"; | sec-gp="feedca570000";app-gp="group1"; | |||
cs_kenc="1";ecdh_alg="-27"; | pub_key_enc="33";sign_enc_alg="10"; | |||
ecdh_alg_crv="4", | sign_alg="-8";sign_alg_crv="6"; | |||
</ace-group/ech0ech00000>;ct=65000;rt="core.osc.gm";if="ace.group"; | alg="10";ecdh_alg="-27";ecdh_alg_crv="4", | |||
sec-gp="ech0ech00000";app-gp="group2"; | </ace-group/ech0ech00000>;ct=65000;rt="core.osc.gm";if="ace.group"; | |||
cs_alg="-8";cs_alg_crv="6"; | sec-gp="ech0ech00000";app-gp="group2"; | |||
cs_kenc="1";ecdh_alg="-27"; | pub_key_enc="33";sign_enc_alg="10"; | |||
ecdh_alg_crv="4", | sign_alg="-8";sign_alg_crv="6"; | |||
</ace-group/abcdef120000>;ct=65000;rt="core.osc.gm";if="ace.group"; | alg="10";ecdh_alg="-27";ecdh_alg_crv="4", | |||
sec-gp="abcdef120000";app-gp="group3"; | </ace-group/abcdef120000>;ct=65000;rt="core.osc.gm";if="ace.group"; | |||
app-gp="group4";cs_alg="-8"; | sec-gp="abcdef120000";app-gp="group3"; | |||
cs_alg_crv="6";cs_kenc="1"; | app-gp="group4";pub_key_enc="33"; | |||
ecdh_alg="-27";ecdh_alg_crv="4", | sign_enc_alg="10";sign_alg="-8"; | |||
<coap://as.example.com/token>; | sign_alg_crv="6";alg="10";ecdh_alg="-27"; | |||
rel="authorization-server"; | ecdh_alg_crv="4", | |||
anchor="coap://[2001:db8::ab]/ace-group/feedca570000", | <coap://as.example.com/token>; | |||
<coap://as.example.com/token>; | rel="authorization-server"; | |||
rel="authorization-server"; | anchor="coap://[2001:db8::ab]/ace-group/feedca570000", | |||
anchor="coap://[2001:db8::ab]/ace-group/ech0ech00000", | <coap://as.example.com/token>; | |||
<coap://as.example.com/token>; | rel="authorization-server"; | |||
rel="authorization-server"; | anchor="coap://[2001:db8::ab]/ace-group/ech0ech00000", | |||
anchor="coap://[2001:db8::ab]/ace-group/abcdef120000" | <coap://as.example.com/token>; | |||
rel="authorization-server"; | ||||
anchor="coap://[2001:db8::ab]/ace-group/abcdef120000" | ||||
Response: RD -> GM | Response: RD -> GM | |||
Res: 2.04 Changed | Res: 2.04 Changed | |||
Location-Path: /rd/4521 | Location-Path: /rd/4521 | |||
3.1.2. Example in CoRAL | 3.1.2. Example in CoRAL | |||
Request: GM -> RD | Request: GM -> RD | |||
Req: POST coap://rd.example.com/rd?ep=gm1 | Req: POST coap://rd.example.com/rd?ep=gm1 | |||
Content-Format: TBD123456 (application/coral+cbor) | Content-Format: TBD123456 (application/coral+cbor) | |||
Payload: | Payload: | |||
#using <http://coreapps.org/core.oscore-discovery#> | #using <http://coreapps.org/core.oscore-discovery#> | |||
#using reef = <http://coreapps.org/reef#> | #using reef = <http://coreapps.org/reef#> | |||
#using iana = <http://www.iana.org/assignments/relation/> | #using iana = <http://www.iana.org/assignments/relation/> | |||
#base <coap://[2001:db8::ab]/> | #base <coap://[2001:db8::ab]/> | |||
reef:rd-item </ace-group/feedca570000> { | reef:rd-item </ace-group/feedca570000> { | |||
reef:ct 65000 | reef:ct 65000 | |||
reef:rt "core.osc.gm" | reef:rt "core.osc.gm" | |||
reef:if "ace.group" | reef:if "ace.group" | |||
sec-gp "feedca570000" | sec-gp "feedca570000" | |||
app-gp "group1" | app-gp "group1" | |||
cs_alg -8 | pub_key_enc 33 | |||
cs_alg_crv 6 | sign_enc_alg 10 | |||
cs_kenc 1 | sign_alg -8 | |||
sign_alg_crv 6 | ||||
alg 10 | ||||
ecdh_alg -27 | ecdh_alg -27 | |||
ecdh_alg_crv 4 | ecdh_alg_crv 4 | |||
iana:authorization-server <coap://as.example.com/token> | iana:authorization-server <coap://as.example.com/token> | |||
} | } | |||
reef:rd-item </ace-group/ech0ech00000> { | reef:rd-item </ace-group/ech0ech00000> { | |||
reef:ct 65000 | reef:ct 65000 | |||
reef:rt "core.osc.gm" | reef:rt "core.osc.gm" | |||
reef:if "ace.group" | reef:if "ace.group" | |||
sec-gp "ech0ech00000" | sec-gp "ech0ech00000" | |||
app-gp "group2" | app-gp "group2" | |||
cs_alg -8 | pub_key_enc 33 | |||
cs_alg_crv 6 | sign_enc_alg 10 | |||
cs_kenc 1 | sign_alg -8 | |||
sign_alg_crv 6 | ||||
alg 10 | ||||
ecdh_alg -27 | ecdh_alg -27 | |||
ecdh_alg_crv 4 | ecdh_alg_crv 4 | |||
iana:authorization-server <coap://as.example.com/token> | iana:authorization-server <coap://as.example.com/token> | |||
} | } | |||
reef:rd-item </ace-group/abcdef120000> { | reef:rd-item </ace-group/abcdef120000> { | |||
reef:ct 65000 | reef:ct 65000 | |||
reef:rt "core.osc.gm" | reef:rt "core.osc.gm" | |||
reef:if "ace.group" | reef:if "ace.group" | |||
sec-gp "abcdef120000" | sec-gp "abcdef120000" | |||
app-gp "group3" | app-gp "group3" | |||
app-gp "group4" | app-gp "group4" | |||
cs_alg -8 | pub_key_enc 33 | |||
cs_alg_crv 6 | sign_enc_alg 10 | |||
cs_kenc 1 | sign_alg -8 | |||
sign_alg_crv 6 | ||||
alg 10 | ||||
ecdh_alg -27 | ecdh_alg -27 | |||
ecdh_alg_crv 4 | ecdh_alg_crv 4 | |||
iana:authorization-server <coap://as.example.com/token> | iana:authorization-server <coap://as.example.com/token> | |||
} | } | |||
Response: RD -> GM | Response: RD -> GM | |||
Res: 2.04 Changed | Res: 2.04 Changed | |||
Location-Path: /rd/4521 | Location-Path: /rd/4521 | |||
skipping to change at page 15, line 21 ¶ | skipping to change at page 16, line 33 ¶ | |||
To this end, the joining node can perform a resource lookup at the RD | 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 | as per Section 6.1 of [I-D.ietf-core-resource-directory], to retrieve | |||
the missing pieces of information needed to join the security | the missing pieces of information needed to join the security | |||
group(s) of interest. The joining node can find the RD as described | group(s) of interest. The joining node can find the RD as described | |||
in Section 4 of [I-D.ietf-core-resource-directory]. | in Section 4 of [I-D.ietf-core-resource-directory]. | |||
The joining node uses the following parameter value for the lookup | The joining node uses the following parameter value for the lookup | |||
filtering. | filtering. | |||
o 'rt' = "core.osc.gm", specifying the resource type of the group- | * 'rt' = "core.osc.gm", specifying the resource type of the group- | |||
membership resource at the Group Manager, with value "core.osc.gm" | membership resource at the Group Manager, with value "core.osc.gm" | |||
registered in Section 21.11 of | registered in Section 21.11 of | |||
[I-D.ietf-ace-key-groupcomm-oscore]. | [I-D.ietf-ace-key-groupcomm-oscore]. | |||
The joining node may additionally consider the following parameters | The joining node may additionally consider the following parameters | |||
for the lookup filtering, depending on the information it has already | for the lookup filtering, depending on the information it has already | |||
available. | available. | |||
o 'sec-gp', specifying the name of the security group of interest. | * 'sec-gp', specifying the name of the security group of interest. | |||
This parameter MUST specify a single value. | This parameter MUST specify a single value. | |||
o 'ep', specifying the registered endpoint of the GM. | * 'ep', specifying the registered endpoint of the GM. | |||
o 'app-gp', specifying the name(s) of the application group(s) | * 'app-gp', specifying the name(s) of the application group(s) | |||
associated with the security group of interest. This parameter | associated with the security group of interest. This parameter | |||
MAY be included multiple times, and each occurrence MUST specify | MAY be included multiple times, and each occurrence MUST specify | |||
the name of one application group. | the name of one application group. | |||
o 'if', specifying the interface description for accessing the | * 'if', specifying the interface description for accessing the | |||
group-membership resource at the Group Manager, with value | group-membership resource at the Group Manager, with value | |||
"ace.group" registered in Section 8.10 of | "ace.group" registered in Section 8.10 of | |||
[I-D.ietf-ace-key-groupcomm]. | [I-D.ietf-ace-key-groupcomm]. | |||
The response from the RD may include links to a group-membership | The response from the RD may include links to a group-membership | |||
resource specifying multiple application groups, as all using the | resource specifying multiple application groups, as all using the | |||
same security group. In this case, the joining node is already | same security group. In this case, the joining node is already | |||
expected to know the exact application group of interest. | expected to know the exact application group of interest. | |||
Furthermore, the response from the RD may include the links to | Furthermore, the response from the RD may include the links to | |||
skipping to change at page 16, line 20 ¶ | skipping to change at page 17, line 33 ¶ | |||
groups can reflect different security algorithms to use. Hence, a | groups can reflect different security algorithms to use. Hence, a | |||
client application can take into account what the joining node | client application can take into account what the joining node | |||
supports and prefers, when selecting one particular security group | supports and prefers, when selecting one particular security group | |||
among the indicated ones, while a server application would need to | among the indicated ones, while a server application would need to | |||
join all of them. Later on, the joining node will be anyway able to | join all of them. Later on, the joining node will be anyway able to | |||
join only security groups for which it is actually authorized to be a | join only security groups for which it is actually authorized to be a | |||
member (see [I-D.ietf-ace-key-groupcomm-oscore]). | member (see [I-D.ietf-ace-key-groupcomm-oscore]). | |||
Note that, with RD-based discovery, including the 'app-gp' parameter | Note that, with RD-based discovery, including the 'app-gp' parameter | |||
multiple times would result in finding only the group-membership | multiple times would result in finding only the group-membership | |||
resource that serves all the specified application groups, i.e. not | resource that serves all the specified application groups, i.e., not | |||
any group-membership resource that serves either. Therefore, a | any group-membership resource that serves either. Therefore, a | |||
joining node needs to perform N separate queries with different | joining node needs to perform N separate queries with different | |||
values for 'app-gp', in order to safely discover the (different) | values for 'app-gp', in order to safely discover the (different) | |||
group-membership resource(s) serving the N application groups. | group-membership resource(s) serving the N application groups. | |||
The discovery of security groups as defined in this document is | The discovery of security groups as defined in this document is | |||
applicable and useful to other CoAP endpoints than the actual joining | applicable and useful to other CoAP endpoints than the actual joining | |||
nodes. In particular, other entities can be interested to discover | nodes. In particular, other entities can be interested to discover | |||
and interact with the group-membership resource at the Group Manager. | and interact with the group-membership resource at the Group Manager. | |||
These include entities acting as signature checkers, e.g. | These include entities acting as signature checkers, e.g., | |||
intermediary gateways, that do not join a security group, but can | intermediary gateways, that do not join a security group, but can | |||
retrieve public keys of group members from the Group Manager, in | retrieve public keys of group members from the Group Manager, in | |||
order to verify counter signatures of group messages (see Section 3 | order to verify counter signatures of group messages (see Section 3 | |||
of [I-D.ietf-core-oscore-groupcomm]). | of [I-D.ietf-core-oscore-groupcomm]). | |||
4.1. Discovery Example #1 | 4.1. Discovery Example #1 | |||
Consistently with the examples in Section 2 and Section 3, the | Consistently with the examples in Section 2 and Section 3, the | |||
examples below consider a joining node that wants to join the | examples below consider a joining node that wants to join the | |||
security group associated with the application group "group1", but | security group associated with the application group "group1", but | |||
skipping to change at page 17, line 4 ¶ | skipping to change at page 18, line 21 ¶ | |||
and the group-membership resource to access. | and the group-membership resource to access. | |||
4.1.1. Example in Link Format | 4.1.1. Example in Link Format | |||
Request: Joining node -> RD | Request: Joining node -> RD | |||
Req: GET coap://rd.example.com/rd-lookup/res | Req: GET coap://rd.example.com/rd-lookup/res | |||
?rt=core.osc.gm&app-gp=group1 | ?rt=core.osc.gm&app-gp=group1 | |||
Response: RD -> Joining node | Response: RD -> Joining node | |||
Res: 2.05 Content | Res: 2.05 Content | |||
Payload: | Payload: | |||
<coap://[2001:db8::ab]/ace-group/feedca570000>;ct=65000; | <coap://[2001:db8::ab]/ace-group/feedca570000>;ct=65000; | |||
rt="core.osc.gm";if="ace.group";sec-gp="feedca570000"; | rt="core.osc.gm";if="ace.group";sec-gp="feedca570000"; | |||
app-gp="group1";cs_alg="-8";cs_alg_crv="6"; | app-gp="group1";pub_key_enc="33";sign_enc_alg="10"; | |||
cs_kenc="1";ecdh_alg="-27";ecdh_alg_crv="4"; | sign_alg="-8";sign_alg_crv="6";alg="10"; | |||
ecdh_alg="-27";ecdh_alg_crv="4"; | ||||
anchor="coap://[2001:db8::ab]" | anchor="coap://[2001:db8::ab]" | |||
By performing the separate resource lookup below, the joining node | By performing the separate resource lookup below, the joining node | |||
can retrieve the link to the ACE Authorization Server associated to | can retrieve the link to the ACE Authorization Server associated to | |||
the GM, where to send an Authorization Request for joining the | the GM, where to send an Authorization Request for joining the | |||
corresponding security group (see | corresponding security group (see | |||
[I-D.ietf-ace-key-groupcomm-oscore]). | [I-D.ietf-ace-key-groupcomm-oscore]). | |||
Request: Joining node -> RD | Request: Joining node -> RD | |||
skipping to change at page 18, line 14 ¶ | skipping to change at page 20, line 4 ¶ | |||
4.1.2. Example in CoRAL | 4.1.2. Example in CoRAL | |||
Request: Joining node -> RD | Request: Joining node -> RD | |||
Req: GET coap://rd.example.com/rd-lookup/res | Req: GET coap://rd.example.com/rd-lookup/res | |||
?rt=core.osc.gm&app-gp=group1 | ?rt=core.osc.gm&app-gp=group1 | |||
Accept: TBD123456 (application/coral+cbor) | Accept: TBD123456 (application/coral+cbor) | |||
Response: RD -> Joining node | Response: RD -> Joining node | |||
Res: 2.05 Content | Res: 2.05 Content | |||
Content-Format: TBD123456 (application/coral+cbor) | Content-Format: TBD123456 (application/coral+cbor) | |||
Payload: | Payload: | |||
#using <http://coreapps.org/core.oscore-discovery#> | #using <http://coreapps.org/core.oscore-discovery#> | |||
#using reef = <http://coreapps.org/reef#> | #using reef = <http://coreapps.org/reef#> | |||
#using iana = <http://www.iana.org/assignments/relation/> | #using iana = <http://www.iana.org/assignments/relation/> | |||
#base <coap://[2001:db8::ab]/> | #base <coap://[2001:db8::ab]/> | |||
reef:rd-item </ace-group/feedca570000> { | reef:rd-item </ace-group/feedca570000> { | |||
reef:ct 65000 | reef:ct 65000 | |||
reef:rt "core.osc.gm" | reef:rt "core.osc.gm" | |||
reef:if "ace.group" | reef:if "ace.group" | |||
sec-gp "feedca570000" | sec-gp "feedca570000" | |||
app-gp "group1" | app-gp "group1" | |||
cs_alg -8 | pub_key_enc 33 | |||
cs_alg_crv 6 | sign_enc_alg 10 | |||
cs_kenc 1 | sign_alg -8 | |||
sign_alg_crv 6 | ||||
alg 10 | ||||
ecdh_alg -27 | ecdh_alg -27 | |||
ecdh_alg_crv 4 | ecdh_alg_crv 4 | |||
iana:authorization-server <coap://as.example.com/token> | iana:authorization-server <coap://as.example.com/token> | |||
} | } | |||
To retrieve the multicast IP address of the CoAP group used by the | To retrieve the multicast IP address of the CoAP group used by the | |||
application group "group1", the joining node performs an endpoint | application group "group1", the joining node performs an endpoint | |||
lookup as shown below. The following assumes that the application | lookup as shown below. The following assumes that the application | |||
group "group1" had been previously registered, with | group "group1" had been previously registered, with | |||
ff35:30:2001:db8::23 as multicast IP address of the associated CoAP | ff35:30:2001:db8::23 as multicast IP address of the associated CoAP | |||
skipping to change at page 19, line 48 ¶ | skipping to change at page 21, line 48 ¶ | |||
?rt=core.osc.gm&sec-gp=feedca570000 | ?rt=core.osc.gm&sec-gp=feedca570000 | |||
Observe: 0 | Observe: 0 | |||
Response: RD -> Joining node | Response: RD -> Joining node | |||
Res: 2.05 Content | Res: 2.05 Content | |||
Observe: 24 | Observe: 24 | |||
Payload: | Payload: | |||
<coap://[2001:db8::ab]/ace-group/feedca570000>;ct=65000; | <coap://[2001:db8::ab]/ace-group/feedca570000>;ct=65000; | |||
rt="core.osc.gm";if="ace.group";sec-gp="feedca570000"; | rt="core.osc.gm";if="ace.group";sec-gp="feedca570000"; | |||
app-gp="group1";cs_alg="-8";cs_alg_crv="6"; | app-gp="group1";pub_key_enc="33";sign_enc_alg="10"; | |||
cs_kenc="1";ecdh_alg="-27";ecdh_alg_crv="4"; | sign_alg="-8";sign_alg_crv="6";alg="10"; | |||
ecdh_alg="-27";ecdh_alg_crv="4"; | ||||
anchor="coap://[2001:db8::ab]" | anchor="coap://[2001:db8::ab]" | |||
Depending on the search criteria, the joining node performing the | Depending on the search criteria, the joining node performing the | |||
resource lookup can get large responses. This can happen, for | resource lookup can get large responses. This can happen, for | |||
instance, when the lookup request targets all the group-membership | instance, when the lookup request targets all the group-membership | |||
resources at a specified GM, or all the group-membership resources of | resources at a specified GM, or all the group-membership resources of | |||
all the registered GMs, as in the example below. | all the registered GMs, as in the example below. | |||
Request: Joining node -> RD | Request: Joining node -> RD | |||
Req: GET coap://rd.example.com/rd-lookup/res?rt=core.osc.gm | Req: GET coap://rd.example.com/rd-lookup/res?rt=core.osc.gm | |||
Response: RD -> Joining node | Response: RD -> Joining node | |||
Res: 2.05 Content | Res: 2.05 Content | |||
Payload: | Payload: | |||
<coap://[2001:db8::ab]/ace-group/feedca570000>;ct=65000; | <coap://[2001:db8::ab]/ace-group/feedca570000>;ct=65000; | |||
rt="core.osc.gm";if="ace.group";sec-gp="feedca570000"; | rt="core.osc.gm";if="ace.group";sec-gp="feedca570000"; | |||
app-gp="group1";cs_alg="-8";cs_alg_crv="6"; | app-gp="group1";pub_key_enc="33";sign_enc_alg="10"; | |||
cs_kenc="1";ecdh_alg="-27";ecdh_alg_crv="4"; | sign_alg="-8";sign_alg_crv="6";alg="10";ecdh_alg="-27"; | |||
anchor="coap://[2001:db8::ab]", | ecdh_alg_crv="4";anchor="coap://[2001:db8::ab]", | |||
<coap://[2001:db8::ab]/ace-group/ech0ech00000>;ct=65000; | <coap://[2001:db8::ab]/ace-group/ech0ech00000>;ct=65000; | |||
rt="core.osc.gm";if="ace.group";sec-gp="ech0ech00000"; | rt="core.osc.gm";if="ace.group";sec-gp="ech0ech00000"; | |||
app-gp="group2";cs_alg="-8";cs_alg_crv="6"; | app-gp="group2";pub_key_enc="33";sign_enc_alg="10"; | |||
cs_kenc="1";ecdh_alg="-27";ecdh_alg_crv="4"; | sign_alg="-8";sign_alg_crv="6";alg="10";ecdh_alg="-27"; | |||
anchor="coap://[2001:db8::ab]", | ecdh_alg_crv="4";anchor="coap://[2001:db8::ab]", | |||
<coap://[2001:db8::ab]/ace-group/abcdef120000>;ct=65000; | <coap://[2001:db8::ab]/ace-group/abcdef120000>;ct=65000; | |||
rt="core.osc.gm";if="ace.group";sec-gp="abcdef120000"; | rt="core.osc.gm";if="ace.group";sec-gp="abcdef120000"; | |||
app-gp="group3";app-gp="group4";cs_alg="-8";cs_alg_crv="6"; | app-gp="group3";app-gp="group4";pub_key_enc="33"; | |||
cs_kenc="1";ecdh_alg="-27";ecdh_alg_crv="4"; | sign_enc_alg="10";sign_alg="-8";sign_alg_crv="6";alg="10"; | |||
anchor="coap://[2001:db8::ab]" | ecdh_alg="-27";ecdh_alg_crv="4";anchor="coap://[2001:db8::ab]" | |||
Therefore, it is RECOMMENDED that a joining node which performs a | Therefore, it is RECOMMENDED that a joining node which performs a | |||
resource lookup with the CoAP Observe option specifies the value of | resource lookup with the CoAP Observe option specifies the value of | |||
the parameter 'sec-gp' in its GET request sent to the RD. | the parameter 'sec-gp' in its GET request sent to the RD. | |||
4.2.2. Example in CoRAL | 4.2.2. Example in CoRAL | |||
Request: Joining node -> RD | Request: Joining node -> RD | |||
Req: GET coap://rd.example.com/rd-lookup/res | Req: GET coap://rd.example.com/rd-lookup/res | |||
skipping to change at page 21, line 20 ¶ | skipping to change at page 23, line 20 ¶ | |||
#using reef = <http://coreapps.org/reef#> | #using reef = <http://coreapps.org/reef#> | |||
#using iana = <http://www.iana.org/assignments/relation/> | #using iana = <http://www.iana.org/assignments/relation/> | |||
#base <coap://[2001:db8::ab]/> | #base <coap://[2001:db8::ab]/> | |||
reef:rd-item </ace-group/feedca570000> { | reef:rd-item </ace-group/feedca570000> { | |||
reef:ct 65000 | reef:ct 65000 | |||
reef:rt "core.osc.gm" | reef:rt "core.osc.gm" | |||
reef:if "ace.group" | reef:if "ace.group" | |||
sec-gp "feedca570000" | sec-gp "feedca570000" | |||
app-gp "group1" | app-gp "group1" | |||
cs_alg -8 | pub_key_enc 33 | |||
cs_alg_crv 6 | sign_enc_alg 10 | |||
cs_kenc 1 | sign_alg -8 | |||
sign_alg_crv 6 | ||||
alg 10 | ||||
ecdh_alg -27 | ecdh_alg -27 | |||
ecdh_alg_crv 4 | ecdh_alg_crv 4 | |||
iana:authorization-server <coap://as.example.com/token> | iana:authorization-server <coap://as.example.com/token> | |||
} | } | |||
5. Use Case Example With Full Discovery | 5. Use Case Example With Full Discovery | |||
In this section, the discovery of security groups is described to | In this section, the discovery of security groups is described to | |||
support the installation process of a lighting installation in an | support the installation process of a lighting installation in an | |||
office building. The described process is a simplified version of | office building. The described process is a simplified version of | |||
skipping to change at page 25, line 23 ¶ | skipping to change at page 27, line 32 ¶ | |||
Content-Format: 40 | Content-Format: 40 | |||
Payload: | Payload: | |||
<coap://[2001:db8::ab]/ace-group/feedsc590000>;ct=65000; | <coap://[2001:db8::ab]/ace-group/feedsc590000>;ct=65000; | |||
rt="core.osc.gm";if="ace.group";sec-gp="feedsc590000"; | rt="core.osc.gm";if="ace.group";sec-gp="feedsc590000"; | |||
app-gp="grp_schedule";anchor="coap://[2001:db8::ab]" | app-gp="grp_schedule";anchor="coap://[2001:db8::ab]" | |||
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** | *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** | |||
After this last discovery step, the device can ask permission to join | After this last discovery step, the device can ask permission to join | |||
the security groups, and effectively join them through the Group | the security groups, and effectively join them through the Group | |||
Manager, e.g. according to [I-D.ietf-ace-key-groupcomm-oscore]. | Manager, e.g., according to [I-D.ietf-ace-key-groupcomm-oscore]. | |||
6. Security Considerations | 6. Security Considerations | |||
The security considerations as described in Section 8 of | The security considerations as described in Section 8 of | |||
[I-D.ietf-core-resource-directory] apply here as well. | [I-D.ietf-core-resource-directory] apply here as well. | |||
7. IANA Considerations | 7. IANA Considerations | |||
This document has no actions for IANA. | This document has no actions for IANA. | |||
skipping to change at page 25, line 48 ¶ | skipping to change at page 28, line 10 ¶ | |||
[COSE.Algorithms] | [COSE.Algorithms] | |||
IANA, "COSE Algorithms", | IANA, "COSE Algorithms", | |||
<https://www.iana.org/assignments/cose/ | <https://www.iana.org/assignments/cose/ | |||
cose.xhtml#algorithms>. | cose.xhtml#algorithms>. | |||
[COSE.Elliptic.Curves] | [COSE.Elliptic.Curves] | |||
IANA, "COSE Elliptic Curves", | IANA, "COSE Elliptic Curves", | |||
<https://www.iana.org/assignments/cose/ | <https://www.iana.org/assignments/cose/ | |||
cose.xhtml#elliptic-curves>. | cose.xhtml#elliptic-curves>. | |||
[COSE.Header.Parameters] | ||||
IANA, "COSE Header Parameters", | ||||
<https://www.iana.org/assignments/cose/cose.xhtml#header- | ||||
parameters>. | ||||
[COSE.Key.Types] | [COSE.Key.Types] | |||
IANA, "COSE Key Types", | IANA, "COSE Key Types", | |||
<https://www.iana.org/assignments/cose/cose.xhtml#key- | <https://www.iana.org/assignments/cose/cose.xhtml#key- | |||
type>. | type>. | |||
[I-D.ietf-core-coral] | [I-D.ietf-core-coral] | |||
Hartke, K., "The Constrained RESTful Application Language | Hartke, K., "The Constrained RESTful Application Language | |||
(CoRAL)", draft-ietf-core-coral-03 (work in progress), | (CoRAL)", Work in Progress, Internet-Draft, draft-ietf- | |||
March 2020. | core-coral-03, 9 March 2020, | |||
<https://www.ietf.org/archive/id/draft-ietf-core-coral- | ||||
03.txt>. | ||||
[I-D.ietf-core-groupcomm-bis] | [I-D.ietf-core-groupcomm-bis] | |||
Dijk, E., Wang, C., and M. Tiloca, "Group Communication | Dijk, E., Wang, C., and M. Tiloca, "Group Communication | |||
for the Constrained Application Protocol (CoAP)", draft- | for the Constrained Application Protocol (CoAP)", Work in | |||
ietf-core-groupcomm-bis-03 (work in progress), February | Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- | |||
2021. | 04, 12 July 2021, <https://www.ietf.org/archive/id/ | |||
draft-ietf-core-groupcomm-bis-04.txt>. | ||||
[I-D.ietf-core-oscore-groupcomm] | [I-D.ietf-core-oscore-groupcomm] | |||
Tiloca, M., Selander, G., Palombini, F., Mattsson, J., and | Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., | |||
J. Park, "Group OSCORE - Secure Group Communication for | and J. Park, "Group OSCORE - Secure Group Communication | |||
CoAP", draft-ietf-core-oscore-groupcomm-11 (work in | for CoAP", Work in Progress, Internet-Draft, draft-ietf- | |||
progress), February 2021. | core-oscore-groupcomm-12, 12 July 2021, | |||
<https://www.ietf.org/archive/id/draft-ietf-core-oscore- | ||||
groupcomm-12.txt>. | ||||
[I-D.ietf-core-resource-directory] | [I-D.ietf-core-resource-directory] | |||
Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P. | Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P. | |||
Stok, "CoRE Resource Directory", draft-ietf-core-resource- | V. D. Stok, "CoRE Resource Directory", Work in Progress, | |||
directory-26 (work in progress), November 2020. | Internet-Draft, draft-ietf-core-resource-directory-28, 7 | |||
March 2021, <https://www.ietf.org/archive/id/draft-ietf- | ||||
core-resource-directory-28.txt>. | ||||
[I-D.ietf-cose-rfc8152bis-algs] | [I-D.ietf-cose-rfc8152bis-algs] | |||
Schaad, J., "CBOR Object Signing and Encryption (COSE): | Schaad, J., "CBOR Object Signing and Encryption (COSE): | |||
Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-12 | Initial Algorithms", Work in Progress, Internet-Draft, | |||
(work in progress), September 2020. | draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, | |||
<https://www.ietf.org/archive/id/draft-ietf-cose- | ||||
rfc8152bis-algs-12.txt>. | ||||
[I-D.ietf-cose-rfc8152bis-struct] | [I-D.ietf-cose-rfc8152bis-struct] | |||
Schaad, J., "CBOR Object Signing and Encryption (COSE): | Schaad, J., "CBOR Object Signing and Encryption (COSE): | |||
Structures and Process", draft-ietf-cose-rfc8152bis- | Structures and Process", Work in Progress, Internet-Draft, | |||
struct-15 (work in progress), February 2021. | draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, | |||
<https://www.ietf.org/archive/id/draft-ietf-cose- | ||||
rfc8152bis-struct-15.txt>. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link | [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link | |||
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, | Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, | |||
<https://www.rfc-editor.org/info/rfc6690>. | <https://www.rfc-editor.org/info/rfc6690>. | |||
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained | [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained | |||
Application Protocol (CoAP)", RFC 7252, | Application Protocol (CoAP)", RFC 7252, | |||
DOI 10.17487/RFC7252, June 2014, | DOI 10.17487/RFC7252, June 2014, | |||
<https://www.rfc-editor.org/info/rfc7252>. | <https://www.rfc-editor.org/info/rfc7252>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. | ||||
Tschofenig, "Proof-of-Possession Key Semantics for CBOR | ||||
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March | ||||
2020, <https://www.rfc-editor.org/info/rfc8747>. | ||||
8.2. Informative References | 8.2. Informative References | |||
[Fairhair] | [Fairhair] FairHair Alliance, "Security Architecture for the Internet | |||
FairHair Alliance, "Security Architecture for the Internet | ||||
of Things (IoT) in Commercial Buildings", White Paper, ed. | of Things (IoT) in Commercial Buildings", White Paper, ed. | |||
Piotr Polak , March 2018, <https://openconnectivity.org/ | Piotr Polak , March 2018, <https://openconnectivity.org/ | |||
wp-content/uploads/2019/11/fairhair_security_wp_march- | wp-content/uploads/2019/11/fairhair_security_wp_march- | |||
2018.pdf>. | 2018.pdf>. | |||
[I-D.hartke-t2trg-coral-reef] | [I-D.hartke-t2trg-coral-reef] | |||
Hartke, K., "Resource Discovery in Constrained RESTful | Hartke, K., "Resource Discovery in Constrained RESTful | |||
Environments (CoRE) using the Constrained RESTful | Environments (CoRE) using the Constrained RESTful | |||
Application Language (CoRAL)", draft-hartke-t2trg-coral- | Application Language (CoRAL)", Work in Progress, Internet- | |||
reef-04 (work in progress), May 2020. | Draft, draft-hartke-t2trg-coral-reef-04, 9 May 2020, | |||
<https://www.ietf.org/archive/id/draft-hartke-t2trg-coral- | ||||
reef-04.txt>. | ||||
[I-D.ietf-ace-key-groupcomm] | [I-D.ietf-ace-key-groupcomm] | |||
Palombini, F. and M. Tiloca, "Key Provisioning for Group | Palombini, F. and M. Tiloca, "Key Provisioning for Group | |||
Communication using ACE", draft-ietf-ace-key-groupcomm-11 | Communication using ACE", Work in Progress, Internet- | |||
(work in progress), February 2021. | Draft, draft-ietf-ace-key-groupcomm-13, 12 July 2021, | |||
<https://www.ietf.org/archive/id/draft-ietf-ace-key- | ||||
groupcomm-13.txt>. | ||||
[I-D.ietf-ace-key-groupcomm-oscore] | [I-D.ietf-ace-key-groupcomm-oscore] | |||
Tiloca, M., Park, J., and F. Palombini, "Key Management | Tiloca, M., Park, J., and F. Palombini, "Key Management | |||
for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- | for OSCORE Groups in ACE", Work in Progress, Internet- | |||
oscore-10 (work in progress), February 2021. | Draft, draft-ietf-ace-key-groupcomm-oscore-11, 12 July | |||
2021, <https://www.ietf.org/archive/id/draft-ietf-ace-key- | ||||
groupcomm-oscore-11.txt>. | ||||
[I-D.ietf-ace-oauth-authz] | [I-D.ietf-ace-oauth-authz] | |||
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and | Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and | |||
H. Tschofenig, "Authentication and Authorization for | H. Tschofenig, "Authentication and Authorization for | |||
Constrained Environments (ACE) using the OAuth 2.0 | Constrained Environments (ACE) using the OAuth 2.0 | |||
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-37 | Framework (ACE-OAuth)", Work in Progress, Internet-Draft, | |||
(work in progress), February 2021. | draft-ietf-ace-oauth-authz-43, 10 July 2021, | |||
<https://www.ietf.org/archive/id/draft-ietf-ace-oauth- | ||||
authz-43.txt>. | ||||
[I-D.ietf-ace-oscore-gm-admin] | [I-D.ietf-ace-oscore-gm-admin] | |||
Tiloca, M., Hoeglund, R., Stok, P., Palombini, F., and K. | Tiloca, M., Hoeglund, R., Stok, P. V. D., Palombini, F., | |||
Hartke, "Admin Interface for the OSCORE Group Manager", | and K. Hartke, "Admin Interface for the OSCORE Group | |||
draft-ietf-ace-oscore-gm-admin-02 (work in progress), | Manager", Work in Progress, Internet-Draft, draft-ietf- | |||
February 2021. | ace-oscore-gm-admin-03, 12 July 2021, | |||
<https://www.ietf.org/archive/id/draft-ietf-ace-oscore-gm- | ||||
admin-03.txt>. | ||||
[I-D.ietf-anima-bootstrapping-keyinfra] | [I-D.ietf-cose-cbor-encoded-cert] | |||
Pritikin, M., Richardson, M., Eckert, T., Behringer, M., | Raza, S., Hoeglund, J., Selander, G., Mattsson, J. P., | |||
and K. Watsen, "Bootstrapping Remote Secure Key | and M. Furuhed, "CBOR Encoded X.509 Certificates (C509 | |||
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- | Certificates)", Work in Progress, Internet-Draft, draft- | |||
keyinfra-45 (work in progress), November 2020. | ietf-cose-cbor-encoded-cert-01, 25 May 2021, | |||
<https://www.ietf.org/archive/id/draft-ietf-cose-cbor- | ||||
encoded-cert-01.txt>. | ||||
[I-D.ietf-rats-uccs] | ||||
Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C. | ||||
Bormann, "A CBOR Tag for Unprotected CWT Claims Sets", | ||||
Work in Progress, Internet-Draft, draft-ietf-rats-uccs-00, | ||||
19 May 2021, <https://www.ietf.org/archive/id/draft-ietf- | ||||
rats-uccs-00.txt>. | ||||
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for | [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for | |||
Constrained-Node Networks", RFC 7228, | Constrained-Node Networks", RFC 7228, | |||
DOI 10.17487/RFC7228, May 2014, | DOI 10.17487/RFC7228, May 2014, | |||
<https://www.rfc-editor.org/info/rfc7228>. | <https://www.rfc-editor.org/info/rfc7228>. | |||
[RFC7641] Hartke, K., "Observing Resources in the Constrained | [RFC7641] Hartke, K., "Observing Resources in the Constrained | |||
Application Protocol (CoAP)", RFC 7641, | Application Protocol (CoAP)", RFC 7641, | |||
DOI 10.17487/RFC7641, September 2015, | DOI 10.17487/RFC7641, September 2015, | |||
<https://www.rfc-editor.org/info/rfc7641>. | <https://www.rfc-editor.org/info/rfc7641>. | |||
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer | ||||
Security (TLS) / Datagram Transport Layer Security (DTLS) | ||||
Profiles for the Internet of Things", RFC 7925, | ||||
DOI 10.17487/RFC7925, July 2016, | ||||
<https://www.rfc-editor.org/info/rfc7925>. | ||||
[RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and | [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and | |||
FETCH Methods for the Constrained Application Protocol | FETCH Methods for the Constrained Application Protocol | |||
(CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, | (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, | |||
<https://www.rfc-editor.org/info/rfc8132>. | <https://www.rfc-editor.org/info/rfc8132>. | |||
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, | ||||
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, | ||||
May 2018, <https://www.rfc-editor.org/info/rfc8392>. | ||||
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, | [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, | |||
"Object Security for Constrained RESTful Environments | "Object Security for Constrained RESTful Environments | |||
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, | (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, | |||
<https://www.rfc-editor.org/info/rfc8613>. | <https://www.rfc-editor.org/info/rfc8613>. | |||
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., | ||||
and K. Watsen, "Bootstrapping Remote Secure Key | ||||
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, | ||||
May 2021, <https://www.rfc-editor.org/info/rfc8995>. | ||||
Appendix A. Use Case Example With Full Discovery (CoRAL) | Appendix A. Use Case Example With Full Discovery (CoRAL) | |||
This section provides the same use case example of Section 5, but | This section provides the same use case example of Section 5, but | |||
specified in CoRAL [I-D.ietf-core-coral]. | specified in CoRAL [I-D.ietf-core-coral]. | |||
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** | *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** | |||
The CT defines the application group "grp_R2-4-015", with resource | The CT defines the application group "grp_R2-4-015", with resource | |||
/light and base address [ff05::5:1], as follows. | /light and base address [ff05::5:1], as follows. | |||
skipping to change at page 32, line 50 ¶ | skipping to change at page 35, line 50 ¶ | |||
reef:rt "core.osc.gm" | reef:rt "core.osc.gm" | |||
reef:if "ace.group" | reef:if "ace.group" | |||
sec-gp "feedsc590000" | sec-gp "feedsc590000" | |||
app-gp "grp_schedule" | app-gp "grp_schedule" | |||
} | } | |||
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** | *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** | |||
After this last discovery step, the device can ask permission to join | After this last discovery step, the device can ask permission to join | |||
the security groups, and effectively join them through the Group | the security groups, and effectively join them through the Group | |||
Manager, e.g. according to [I-D.ietf-ace-key-groupcomm-oscore]. | Manager, e.g., according to [I-D.ietf-ace-key-groupcomm-oscore]. | |||
Acknowledgments | Acknowledgments | |||
The authors sincerely thank Carsten Bormann, Klaus Hartke, Jaime | The authors sincerely thank Carsten Bormann, Klaus Hartke, Jaime | |||
Jimenez, Francesca Palombini, Dave Robin and Jim Schaad for their | Jimenez, Francesca Palombini, Dave Robin and Jim Schaad for their | |||
comments and feedback. | comments and feedback. | |||
The work on this document has been partly supported by VINNOVA and | The work on this document has been partly supported by VINNOVA and | |||
the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home | the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home | |||
(Grant agreement 952652); and by the EIT-Digital High Impact | (Grant agreement 952652); and by the EIT-Digital High Impact | |||
Initiative ACTIVE. | Initiative ACTIVE. | |||
Authors' Addresses | Authors' Addresses | |||
Marco Tiloca | Marco Tiloca | |||
RISE AB | RISE AB | |||
Isafjordsgatan 22 | Isafjordsgatan 22 | |||
Kista SE-16440 Stockholm | SE-16440 Stockholm Kista | |||
Sweden | Sweden | |||
Email: marco.tiloca@ri.se | Email: marco.tiloca@ri.se | |||
Christian Amsuess | Christian Amsuess | |||
Hollandstr. 12/4 | Hollandstr. 12/4 | |||
Vienna 1020 | 1020 Vienna | |||
Austria | Austria | |||
Email: christian@amsuess.com | Email: christian@amsuess.com | |||
Peter van der Stok | Peter van der Stok | |||
Consultant | Consultant | |||
Phone: +31-492474673 (Netherlands), +33-966015248 (France) | Phone: +31-492474673 (Netherlands), +33-966015248 (France) | |||
Email: consultancy@vanderstok.org | Email: consultancy@vanderstok.org | |||
URI: www.vanderstok.org | URI: www.vanderstok.org | |||
End of changes. 89 change blocks. | ||||
238 lines changed or deleted | 345 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |