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/