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

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/