draft-ietf-6tisch-minimal-security-12.txt   draft-ietf-6tisch-minimal-security-13.txt 
6TiSCH Working Group M. Vucinic, Ed. 6TiSCH Working Group M. Vucinic, Ed.
Internet-Draft Inria Internet-Draft Inria
Intended status: Standards Track J. Simon Intended status: Standards Track J. Simon
Expires: January 30, 2020 Analog Devices Expires: April 30, 2020 Analog Devices
K. Pister K. Pister
University of California Berkeley University of California Berkeley
M. Richardson M. Richardson
Sandelman Software Works Sandelman Software Works
July 29, 2019 October 28, 2019
Minimal Security Framework for 6TiSCH Minimal Security Framework for 6TiSCH
draft-ietf-6tisch-minimal-security-12 draft-ietf-6tisch-minimal-security-13
Abstract Abstract
This document describes the minimal framework required for a new This document describes the minimal framework required for a new
device, called "pledge", to securely join a 6TiSCH (IPv6 over the device, called "pledge", to securely join a 6TiSCH (IPv6 over the
TSCH mode of IEEE 802.15.4e) network. The framework requires that TSCH mode of IEEE 802.15.4e) network. The framework requires that
the pledge and the JRC (join registrar/coordinator, a central the pledge and the JRC (join registrar/coordinator, a central
entity), share a symmetric key. How this key is provisioned is out entity), share a symmetric key. How this key is provisioned is out
of scope of this document. Through a single CoAP (Constrained of scope of this document. Through a single CoAP (Constrained
Application Protocol) request-response exchange secured by OSCORE Application Protocol) request-response exchange secured by OSCORE
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 January 30, 2020. This Internet-Draft will expire on April 30, 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 3, line 16 skipping to change at page 3, line 16
13.2. Informative References . . . . . . . . . . . . . . . . . 44 13.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 45 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 45
Appendix B. Lightweight Implementation Option . . . . . . . . . 48 Appendix B. Lightweight Implementation Option . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
This document defines a "secure join" solution for a new device, This document defines a "secure join" solution for a new device,
called "pledge", to securely join a 6TiSCH network. The term "secure called "pledge", to securely join a 6TiSCH network. The term "secure
join" refers to network access authentication, authorization and join" refers to network access authentication, authorization and
parameter distribution, as defined in [I-D.ietf-6tisch-terminology]. parameter distribution, as defined in [I-D.ietf-6tisch-architecture].
The Constrained Join Protocol (CoJP) defined in this document handles The Constrained Join Protocol (CoJP) defined in this document handles
parameter distribution needed for a pledge to become a joined node. parameter distribution needed for a pledge to become a joined node.
Authorization mechanisms are considered out of scope. Mutual Authorization mechanisms are considered out of scope. Mutual
authentication during network access is achieved through the use of a authentication during network access is achieved through the use of a
secure channel, as configured by this document. This document also secure channel, as configured by this document. This document also
specifies a configuration of different layers of the 6TiSCH protocol specifies a configuration of different layers of the 6TiSCH protocol
stack that reduces the Denial of Service (DoS) attack surface during stack that reduces the Denial of Service (DoS) attack surface during
the join process. the join process.
This document presumes a 6TiSCH network as described by [RFC7554] and This document presumes a 6TiSCH network as described by [RFC7554] and
skipping to change at page 3, line 38 skipping to change at page 3, line 38
radio turned off most of the time, to conserve energy. As a radio turned off most of the time, to conserve energy. As a
consequence, the link used by a new device for joining the network consequence, the link used by a new device for joining the network
has limited bandwidth [RFC8180]. The secure join solution defined in has limited bandwidth [RFC8180]. The secure join solution defined in
this document therefore keeps the number of over-the-air exchanges to this document therefore keeps the number of over-the-air exchanges to
a minimum. a minimum.
The micro-controllers at the heart of 6TiSCH nodes have a small The micro-controllers at the heart of 6TiSCH nodes have a small
amount of code memory. It is therefore paramount to reuse existing amount of code memory. It is therefore paramount to reuse existing
protocols available as part of the 6TiSCH stack. At the application protocols available as part of the 6TiSCH stack. At the application
layer, the 6TiSCH stack already relies on CoAP [RFC7252] for web layer, the 6TiSCH stack already relies on CoAP [RFC7252] for web
transfer, and on OSCORE [I-D.ietf-core-object-security] for its end- transfer, and on OSCORE [RFC8613] for its end-to-end security. The
to-end security. The secure join solution defined in this document secure join solution defined in this document therefore reuses those
therefore reuses those two protocols as its building blocks. two protocols as its building blocks.
CoJP is a generic protocol that can be used as-is in all modes of CoJP is a generic protocol that can be used as-is in all modes of
IEEE Std 802.15.4, including the Time-Slotted Channel Hopping (TSCH) IEEE Std 802.15.4, including the Time-Slotted Channel Hopping (TSCH)
mode 6TiSCH is based on. CoJP may as well be used in other (low- mode 6TiSCH is based on. CoJP may as well be used in other (low-
power) networking technologies where efficiency in terms of power) networking technologies where efficiency in terms of
communication overhead and code footprint is important. In such a communication overhead and code footprint is important. In such a
case, it may be necessary to define configuration parameters specific case, it may be necessary to define configuration parameters specific
to the technology in question, through companion documents. The to the technology in question, through companion documents. The
overall process described in Section 4 and the configuration of the overall process described in Section 4 and the configuration of the
stack is specific to 6TiSCH. stack is specific to 6TiSCH.
skipping to change at page 4, line 35 skipping to change at page 4, line 35
2. Terminology 2. 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 "OPTIONAL" in this document are to be interpreted as described in
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The reader is expected to be familiar with the terms and concepts The reader is expected to be familiar with the terms and concepts
defined in [I-D.ietf-6tisch-terminology], [RFC7252], defined in [I-D.ietf-6tisch-architecture], [RFC7252], [RFC8613], and
[I-D.ietf-core-object-security], and [RFC8152]. [RFC8152].
The specification also includes a set of informative specifications The specification also includes a set of informative specifications
using the Concise data definition language (CDDL) using the Concise data definition language (CDDL)
[I-D.ietf-cbor-cddl]. [I-D.ietf-cbor-cddl].
The following terms defined in [I-D.ietf-6tisch-terminology] are used The following terms defined in [I-D.ietf-6tisch-architecture] are
extensively throughout this document: used extensively throughout this document:
o pledge o pledge
o joined node o joined node
o join proxy (JP) o join proxy (JP)
o join registrar/coordinator (JRC) o join registrar/coordinator (JRC)
o enhanced beacon (EB) o enhanced beacon (EB)
skipping to change at page 6, line 30 skipping to change at page 6, line 30
o Pre-Shared Key (PSK). A secret cryptographic key shared between o Pre-Shared Key (PSK). A secret cryptographic key shared between
the (6LBR) pledge and the JRC. The JRC additionally needs to the (6LBR) pledge and the JRC. The JRC additionally needs to
store the pledge identifier bound to the given PSK. Each (6LBR) store the pledge identifier bound to the given PSK. Each (6LBR)
pledge MUST be provisioned with a unique PSK. The PSK SHOULD be a pledge MUST be provisioned with a unique PSK. The PSK SHOULD be a
cryptographically strong key, at least 128 bits in length, cryptographically strong key, at least 128 bits in length,
indistinguishable by feasible computation from a random uniform indistinguishable by feasible computation from a random uniform
string of the same length. How the PSK is generated and/or string of the same length. How the PSK is generated and/or
provisioned is out of scope of this specification. This could be provisioned is out of scope of this specification. This could be
done during a provisioning step or companion documents can specify done during a provisioning step or companion documents can specify
the use of a key agreement protocol. Common pitfalls when the use of a key agreement protocol. Common pitfalls when
generating PSKs are discussed in Section 9. generating PSKs are discussed in Section 9. In case of device re-
commissioning to a new owner, the PSK MUST be changed.
o Optionally, a network identifier. The network identifier o Optionally, a network identifier. The network identifier
identifies the 6TiSCH network. The network identifier MUST be identifies the 6TiSCH network. The network identifier MUST be
carried within Enhanced Beacon (EB) frames. Typically, the 16-bit carried within Enhanced Beacon (EB) frames. Typically, the 16-bit
Personal Area Network Identifier (PAN ID) defined in Personal Area Network Identifier (PAN ID) defined in
[IEEE802.15.4] is used as the network identifier. However, PAN ID [IEEE802.15.4] is used as the network identifier. However, PAN ID
is not considered a stable network identifier as it may change is not considered a stable network identifier as it may change
during network lifetime if a collision with another network is during network lifetime if a collision with another network is
detected. Companion documents can specify the use of a different detected. Companion documents can specify the use of a different
network identifier for join purposes, but this is out of scope of network identifier for join purposes, but this is out of scope of
skipping to change at page 11, line 8 skipping to change at page 11, line 8
specification. specification.
When the pledge initially synchronizes to the network, it has no When the pledge initially synchronizes to the network, it has no
means of verifying the authenticity of EB frames. As an attacker can means of verifying the authenticity of EB frames. As an attacker can
craft a frame that looks like a legitimate EB frame, this opens up a craft a frame that looks like a legitimate EB frame, this opens up a
DoS vector, as discussed in Section 9. DoS vector, as discussed in Section 9.
5.1. Distribution of Time 5.1. Distribution of Time
Nodes in a 6TiSCH network keep a global notion of time known as the Nodes in a 6TiSCH network keep a global notion of time known as the
absolute slot number (ASN). ASN is used in the construction of the absolute slot number. Absolute slot number is used in the
link-layer nonce, as defined in [IEEE802.15.4]. The pledge initially construction of the link-layer nonce, as defined in [IEEE802.15.4].
synchronizes to the EB frame sent by the JP, and uses the value of The pledge initially synchronizes to the EB frame sent by the JP, and
the ASN found in the TSCH Synchronization Information Element. At uses the value of the absolute slot number found in the TSCH
the time of the synchronization, the EB frame can neither be Synchronization Information Element. At the time of the
authenticated nor its freshness verified. During the join process, synchronization, the EB frame can neither be authenticated nor its
the pledge sends frames that are unprotected at the link-layer and freshness verified. During the join process, the pledge sends frames
protected end-to-end instead. The pledge does not obtain the time that are unprotected at the link-layer and protected end-to-end
information as the output of the join process as this information is instead. The pledge does not obtain the time information as the
local to the network and may not be known at the JRC. output of the join process as this information is local to the
network and may not be known at the JRC.
This enables an attack on the pledge where the attacker replays to This enables an attack on the pledge where the attacker replays to
the pledge legitimate EB frames obtained from the network and acts as the pledge legitimate EB frames obtained from the network and acts as
a man-in-the-middle between the pledge and the JP. The EB frames a man-in-the-middle between the pledge and the JP. The EB frames
will make the pledge believe that the replayed ASN value is the will make the pledge believe that the replayed absolute slot number
current notion of time in the network. By forwarding the join value is the current notion of time in the network. By forwarding
traffic to the legitimate JP, the attacker enables the pledge to join the join traffic to the legitimate JP, the attacker enables the
the network. Under different conditions relating to the reuse of the pledge to join the network. Under different conditions relating to
pledge's short address by the JRC or its attempt to rejoin the the reuse of the pledge's short address by the JRC or its attempt to
network, this may cause the pledge to reuse the link-layer nonce in rejoin the network, this may cause the pledge to reuse the link-layer
the first frame it sends protected after the join process is nonce in the first frame it sends protected after the join process is
completed. completed.
For this reason, all frames originated at the JP and destined to the For this reason, all frames originated at the JP and destined to the
pledge during the join process MUST be authenticated at the link- pledge during the join process MUST be authenticated at the link-
layer using the key that is normally in use in the network. Link- layer using the key that is normally in use in the network. Link-
layer security processing at the pledge for these frames will fail as layer security processing at the pledge for these frames will fail as
the pledge is not yet in possession of the key. The pledge the pledge is not yet in possession of the key. The pledge
acknowledges these frames without link-layer security, and JP accepts acknowledges these frames without link-layer security, and JP accepts
the unsecured acknowledgment due to the secExempt attribute set for the unsecured acknowledgment due to the secExempt attribute set for
the pledge. The frames should be passed to the upper layer for the pledge. The frames should be passed to the upper layer for
processing using the promiscuous mode of [IEEE802.15.4] or another processing using the promiscuous mode of [IEEE802.15.4] or another
appropriate mechanism. When the upper layer processing is completed appropriate mechanism. When the upper layer processing is completed
and the link-layer keys are configured, the upper layer MUST trigger and the link-layer keys are configured, the upper layer MUST trigger
the security processing of the corresponding frame. Once the the security processing of the corresponding frame. Once the
security processing of the frame carrying the Join Response message security processing of the frame carrying the Join Response message
is successful, the current ASN kept locally at the pledge SHALL be is successful, the current absolute slot number kept locally at the
declared as valid. pledge SHALL be declared as valid.
6. Network-layer Configuration 6. Network-layer Configuration
The pledge and the JP SHOULD keep a separate neighbor cache for The pledge and the JP SHOULD keep a separate neighbor cache for
untrusted entries and use it to store each other's information during untrusted entries and use it to store each other's information during
the join process. Mixing neighbor entries belonging to pledges and the join process. Mixing neighbor entries belonging to pledges and
nodes that are part of the network opens up the JP to a DoS attack, nodes that are part of the network opens up the JP to a DoS attack,
as the attacker may fill JP's neighbor table and prevent the as the attacker may fill JP's neighbor table and prevent the
discovery of legitimate neighbors. discovery of legitimate neighbors.
skipping to change at page 14, line 13 skipping to change at page 14, line 13
buffers in order to satisfy the Assured Forwarding behavior. buffers in order to satisfy the Assured Forwarding behavior.
Companion SF documents SHOULD specify how traffic with code point Companion SF documents SHOULD specify how traffic with code point
AF42 is handled with respect to cell allocation. In case the AF42 is handled with respect to cell allocation. In case the
recommended behavior described in this section is not followed, the recommended behavior described in this section is not followed, the
network may become prone to the attack discussed in Section 6.1. network may become prone to the attack discussed in Section 6.1.
7. Application-level Configuration 7. Application-level Configuration
The CoJP join exchange in Figure 1 is carried over CoAP [RFC7252] and The CoJP join exchange in Figure 1 is carried over CoAP [RFC7252] and
the secure channel provided by OSCORE the secure channel provided by OSCORE [RFC8613]. The (6LBR) pledge
[I-D.ietf-core-object-security]. The (6LBR) pledge acts as a CoAP acts as a CoAP client; the JRC acts as a CoAP server. The JP
client; the JRC acts as a CoAP server. The JP implements CoAP implements CoAP forward proxy functionality [RFC7252]. Because the
forward proxy functionality [RFC7252]. Because the JP can also be a JP can also be a constrained device, it cannot implement a cache.
constrained device, it cannot implement a cache.
The pledge designates a JP as a proxy by including the Proxy-Scheme The pledge designates a JP as a proxy by including the Proxy-Scheme
option in CoAP requests it sends to the JP. The pledge also includes option in CoAP requests it sends to the JP. The pledge also includes
in the requests the Uri-Host option with its value set to the well- in the requests the Uri-Host option with its value set to the well-
known JRC's alias, as specified in Section 8.1.1. known JRC's alias, as specified in Section 8.1.1.
The JP resolves the alias to the IPv6 address of the JRC that it The JP resolves the alias to the IPv6 address of the JRC that it
learned when it acted as a pledge, and joined the network. This learned when it acted as a pledge, and joined the network. This
allows the JP to reach the JRC at the network layer and forward the allows the JP to reach the JRC at the network layer and forward the
requests on behalf of the pledge. requests on behalf of the pledge.
skipping to change at page 14, line 47 skipping to change at page 14, line 46
attack. attack.
This DoS vector on the JP can be mitigated by making the JP act as a This DoS vector on the JP can be mitigated by making the JP act as a
stateless CoAP proxy, where "state" encompasses the information stateless CoAP proxy, where "state" encompasses the information
related individual pledges. The JP can wrap the state it needs to related individual pledges. The JP can wrap the state it needs to
keep for a given pledge throughout the network stack in a "state keep for a given pledge throughout the network stack in a "state
object" and include it as a CoAP token in the forwarded request to object" and include it as a CoAP token in the forwarded request to
the JRC. The JP may use the CoAP token as defined in [RFC7252], if the JRC. The JP may use the CoAP token as defined in [RFC7252], if
the size of the serialized state object permits, or use the extended the size of the serialized state object permits, or use the extended
CoAP token defined in [I-D.ietf-core-stateless], to transport the CoAP token defined in [I-D.ietf-core-stateless], to transport the
state object. Since the CoAP token is echoed back in the response, state object. The JRC MUST support extended token lengths, as
the JP is able to decode the state object and configure the state defined in [I-D.ietf-core-stateless]. Since the CoAP token is echoed
needed to forward the response to the pledge. The information that back in the response, the JP is able to decode the state object and
the JP needs to encode in the state object to operate in a fully configure the state needed to forward the response to the pledge.
stateless manner with respect to a given pledge is implementation The information that the JP needs to encode in the state object to
specific. operate in a fully stateless manner with respect to a given pledge is
implementation specific.
It is RECOMMENDED that the JP operates in a stateless manner and It is RECOMMENDED that the JP operates in a stateless manner and
signals the per-pledge state within the CoAP token, for every request signals the per-pledge state within the CoAP token, for every request
it forwards into the network on behalf of unauthenticated pledges. it forwards into the network on behalf of unauthenticated pledges.
When operating in a stateless manner, the security considerations When the JP is operating in a stateless manner, the security
from [I-D.ietf-core-stateless] apply and the type of the CoAP message considerations from [I-D.ietf-core-stateless] apply and the type of
that the JP forwards on behalf of the pledge MUST be non-confirmable the CoAP message that the JP forwards on behalf of the pledge MUST be
(NON), regardless of the message type received from the pledge. The non-confirmable (NON), regardless of the message type received from
use of a non-confirmable message by the JP alleviates the JP from the pledge. The use of a non-confirmable message by the JP
keeping CoAP message exchange state. The retransmission burden is alleviates the JP from keeping CoAP message exchange state. The
then entirely shifted to the pledge. A JP that operates in a retransmission burden is then entirely shifted to the pledge. A JP
stateless manner still needs to keep congestion control state with that operates in a stateless manner still needs to keep congestion
the JRC, see Section 9. Recommended values of CoAP settings for use control state with the JRC, see Section 9. Recommended values of
during the join process, both by the pledge and the JP, are given in CoAP settings for use during the join process, both by the pledge and
Section 7.2. the JP, are given in Section 7.2.
Note that in some networking stack implementations, a fully (per- Note that in some networking stack implementations, a fully (per-
pledge) stateless operation of the JP may be challenging from the pledge) stateless operation of the JP may be challenging from the
implementation's point of view. In those cases, the JP may operate implementation's point of view. In those cases, the JP may operate
as a statefull proxy that stores the per-pledge state until the as a statefull proxy that stores the per-pledge state until the
response is received or timed out, but this comes at a price of a DoS response is received or timed out, but this comes at a price of a DoS
vector. vector.
7.2. Recommended Settings 7.2. Recommended Settings
skipping to change at page 16, line 14 skipping to change at page 16, line 14
security reasons, the average data rate SHOULD be measured over a security reasons, the average data rate SHOULD be measured over a
rather short window, e.g. ACK_TIMEOUT, see Section 9. rather short window, e.g. ACK_TIMEOUT, see Section 9.
7.3. OSCORE 7.3. OSCORE
Before the (6LBR) pledge and the JRC start exchanging CoAP messages Before the (6LBR) pledge and the JRC start exchanging CoAP messages
protected with OSCORE, they need to derive the OSCORE security protected with OSCORE, they need to derive the OSCORE security
context from the provisioned parameters, as discussed in Section 3. context from the provisioned parameters, as discussed in Section 3.
The OSCORE security context MUST be derived as per Section 3 of The OSCORE security context MUST be derived as per Section 3 of
[I-D.ietf-core-object-security]. [RFC8613].
o the Master Secret MUST be the PSK. o the Master Secret MUST be the PSK.
o the Master Salt MUST be the empty byte string. o the Master Salt MUST be the empty byte string.
o the ID Context MUST be set to the pledge identifier. o the ID Context MUST be set to the pledge identifier.
o the ID of the pledge MUST be set to the empty byte string. This o the ID of the pledge MUST be set to the empty byte string. This
identifier is used as the OSCORE Sender ID of the pledge in the identifier is used as the OSCORE Sender ID of the pledge in the
security context derivation, since the pledge initially acts as a security context derivation, since the pledge initially acts as a
skipping to change at page 16, line 44 skipping to change at page 16, line 44
default is AES-CCM-16-64-128. default is AES-CCM-16-64-128.
o the Key Derivation Function MUST be agreed out-of-band by the same o the Key Derivation Function MUST be agreed out-of-band by the same
mechanism used to provision the PSK. Default is HKDF SHA-256 mechanism used to provision the PSK. Default is HKDF SHA-256
[RFC5869]. [RFC5869].
Since the pledge's OSCORE Sender ID is the empty byte string, when Since the pledge's OSCORE Sender ID is the empty byte string, when
constructing the OSCORE option, the pledge sets the k bit in the constructing the OSCORE option, the pledge sets the k bit in the
OSCORE flag byte, but indicates a 0-length kid. The pledge OSCORE flag byte, but indicates a 0-length kid. The pledge
transports its pledge identifier within the kid context field of the transports its pledge identifier within the kid context field of the
OSCORE option. The derivation in [I-D.ietf-core-object-security] OSCORE option. The derivation in [RFC8613] results in OSCORE keys
results in OSCORE keys and a common IV for each side of the and a common IV for each side of the conversation. Nonces are
conversation. Nonces are constructed by XOR'ing the common IV with constructed by XOR'ing the common IV with the current sequence
the current sequence number. For details on nonce and OSCORE option number. For details on nonce and OSCORE option construction, refer
construction, refer to [I-D.ietf-core-object-security]. to [RFC8613].
Implementations MUST ensure that multiple CoAP requests, including to Implementations MUST ensure that multiple CoAP requests, including to
different JRCs, are properly incrementing the sequence numbers, so different JRCs, are properly incrementing the sequence numbers, so
that the same sequence number is never reused in distinct requests. that the same sequence number is never reused in distinct requests.
The pledge typically sends requests to different JRCs if it is not The pledge typically sends requests to different JRCs if it is not
provisioned with the network identifier and attempts to join one provisioned with the network identifier and attempts to join one
network at a time. Failure to comply will break the security network at a time. Failure to comply will break the security
guarantees of the Authenticated Encryption with Associated Data guarantees of the Authenticated Encryption with Associated Data
(AEAD) algorithm because of nonce reuse. (AEAD) algorithm because of nonce reuse.
This OSCORE security context is used for initial joining of the This OSCORE security context is used for initial joining of the
(6LBR) pledge, where the (6LBR) pledge acts as a CoAP client, as well (6LBR) pledge, where the (6LBR) pledge acts as a CoAP client, as well
as for any later parameter updates, where the JRC acts as a CoAP as for any later parameter updates, where the JRC acts as a CoAP
client and the joined node as a CoAP server, as discussed in client and the joined node as a CoAP server, as discussed in
Section 8.2. Note that when the (6LBR) pledge and the JRC change Section 8.2. Note that when the (6LBR) pledge and the JRC change
roles between CoAP client and CoAP server, the same OSCORE security roles between CoAP client and CoAP server, the same OSCORE security
context as initially derived remains in use and the derived context as initially derived remains in use and the derived
parameters are unchanged, for example Sender ID when sending and parameters are unchanged, for example Sender ID when sending and
Recipient ID when receiving (see Section 3.1 of Recipient ID when receiving (see Section 3.1 of [RFC8613]). A (6LBR)
[I-D.ietf-core-object-security]). A (6LBR) pledge is expected to pledge is expected to have exactly one OSCORE security context with
have exactly one OSCORE security context with the JRC. the JRC.
7.3.1. Replay Window and Persistency 7.3.1. Replay Window and Persistency
Both (6LBR) pledge and the JRC MUST implement a replay protection Both (6LBR) pledge and the JRC MUST implement a replay protection
mechanism. The use of the default OSCORE replay protection mechanism mechanism. The use of the default OSCORE replay protection mechanism
specified in Section 3.2.2 of [I-D.ietf-core-object-security] is specified in Section 3.2.2 of [RFC8613] is RECOMMENDED.
RECOMMENDED.
Implementations MUST ensure that mutable OSCORE context parameters Implementations MUST ensure that mutable OSCORE context parameters
(Sender Sequence Number, Replay Window) are stored in persistent (Sender Sequence Number, Replay Window) are stored in persistent
memory. A technique that prevents reuse of sequence numbers, memory. A technique that prevents reuse of sequence numbers,
detailed in Appendix B.1.1 of [I-D.ietf-core-object-security], MUST detailed in Appendix B.1.1 of [RFC8613], MUST be implemented. Each
be implemented. Each update of the OSCORE Replay Window MUST be update of the OSCORE Replay Window MUST be written to persistent
written to persistent memory. memory.
This is an important security requirement in order to guarantee nonce This is an important security requirement in order to guarantee nonce
uniqueness and resistance to replay attacks across reboots and uniqueness and resistance to replay attacks across reboots and
rejoins. Traffic between the (6LBR) pledge and the JRC is rare, rejoins. Traffic between the (6LBR) pledge and the JRC is rare,
making security outweigh the cost of writing to persistent memory. making security outweigh the cost of writing to persistent memory.
7.3.2. OSCORE Error Handling 7.3.2. OSCORE Error Handling
Errors raised by OSCORE during the join process MUST be silently Errors raised by OSCORE during the join process MUST be silently
dropped, with no error response being signaled. The pledge MUST dropped, with no error response being signaled. The pledge MUST
skipping to change at page 18, line 27 skipping to change at page 18, line 26
and the algorithm uses 13-byte long nonces. and the algorithm uses 13-byte long nonces.
The mandatory to implement hash algorithm is SHA-256 [RFC4231]. The The mandatory to implement hash algorithm is SHA-256 [RFC4231]. The
mandatory to implement key derivation function is HKDF [RFC5869], mandatory to implement key derivation function is HKDF [RFC5869],
instantiated with a SHA-256 hash. See Appendix B for implementation instantiated with a SHA-256 hash. See Appendix B for implementation
guidance when code footprint is important. guidance when code footprint is important.
8. Constrained Join Protocol (CoJP) 8. Constrained Join Protocol (CoJP)
The Constrained Join Protocol (CoJP) is a lightweight protocol over The Constrained Join Protocol (CoJP) is a lightweight protocol over
CoAP [RFC7252] and a secure channel provided by OSCORE CoAP [RFC7252] and a secure channel provided by OSCORE [RFC8613].
[I-D.ietf-core-object-security]. CoJP allows the (6LBR) pledge to CoJP allows the (6LBR) pledge to request admission into a network
request admission into a network managed by the JRC, and for the JRC managed by the JRC, and for the JRC to configure the pledge with the
to configure the pledge with the parameters necessary for joining the parameters necessary for joining the network, or advertising it in
network, or advertising it in the case of 6LBR pledge. The JRC may the case of 6LBR pledge. The JRC may update the parameters at any
update the parameters at any time, by reaching out to the joined node time, by reaching out to the joined node that formerly acted as a
that formerly acted as a (6LBR) pledge. For example, network-wide (6LBR) pledge. For example, network-wide rekeying can be implemented
rekeying can be implemented by updating the keying material on each by updating the keying material on each node.
node.
This section specifies how the CoJP messages are mapped to CoAP and This section specifies how the CoJP messages are mapped to CoAP and
OSCORE, CBOR data structures carrying different parameters, OSCORE, CBOR data structures carrying different parameters,
transported within CoAP payload, and the parameter semantics and transported within CoAP payload, and the parameter semantics and
processing rules. processing rules.
CoJP relies on the security properties provided by OSCORE. This CoJP relies on the security properties provided by OSCORE. This
includes end-to-end confidentiality, data authenticity, replay includes end-to-end confidentiality, data authenticity, replay
protection, and a secure binding of responses to requests. protection, and a secure binding of responses to requests.
skipping to change at page 20, line 27 skipping to change at page 20, line 27
o The type is Confirmable (CON). o The type is Confirmable (CON).
o The Proxy-Scheme option is set to "coap". o The Proxy-Scheme option is set to "coap".
o The Uri-Host option is set to "6tisch.arpa". This is an anycast o The Uri-Host option is set to "6tisch.arpa". This is an anycast
type of identifier of the JRC that is resolved to its IPv6 address type of identifier of the JRC that is resolved to its IPv6 address
by the JP or the 6LBR pledge. by the JP or the 6LBR pledge.
o The Uri-Path option is set to "j". o The Uri-Path option is set to "j".
o The OSCORE option SHALL be set according to o The OSCORE option SHALL be set according to [RFC8613]. The OSCORE
[I-D.ietf-core-object-security]. The OSCORE security context used security context used is the one derived in Section 7.3. The
is the one derived in Section 7.3. The OSCORE kid context allows OSCORE kid context allows the JRC to retrieve the security context
the JRC to retrieve the security context for a given pledge. for a given pledge.
o The payload is a Join_Request CBOR object, as defined in o The payload is a Join_Request CBOR object, as defined in
Section 8.4.1. Section 8.4.1.
Since the Join Request is a confirmable message, the transmission at Since the Join Request is a confirmable message, the transmission at
(6LBR) pledge will be controlled by CoAP's retransmission mechanism. (6LBR) pledge will be controlled by CoAP's retransmission mechanism.
The JP, when operating in a stateless manner, forwards this Join The JP, when operating in a stateless manner, forwards this Join
Request as a non-confirmable (NON) CoAP message, as specified in Request as a non-confirmable (NON) CoAP message, as specified in
Section 7. If the CoAP at (6LBR) pledge declares the message Section 7. If the CoAP at (6LBR) pledge declares the message
transmission as failure, the (6LBR) pledge SHOULD attempt to join the transmission as failure, the (6LBR) pledge SHOULD attempt to join the
next advertised 6TiSCH network. See Section 7.2 for recommended next advertised 6TiSCH network. See Section 7.2 for recommended
values of CoAP settings to use during the join exchange. values of CoAP settings to use during the join exchange.
If all join attempts to advertised networks have failed, the (6LBR) If all join attempts to advertised networks have failed, the (6LBR)
pledge SHOULD signal to the user the presence of an error condition, pledge SHOULD signal the presence of an error condition, through some
through some out-of-band mechanism. out-of-band mechanism.
8.1.2. Join Response Message 8.1.2. Join Response Message
The Join Response message that the JRC sends SHALL be mapped to a The Join Response message that the JRC sends SHALL be mapped to a
CoAP response: CoAP response:
o The response Code is 2.04 (Changed). o The response Code is 2.04 (Changed).
o The payload is a Configuration CBOR object, as defined in o The payload is a Configuration CBOR object, as defined in
Section 8.4.2. Section 8.4.2.
skipping to change at page 21, line 45 skipping to change at page 21, line 45
The Parameter Update message that the JRC sends to the joined node The Parameter Update message that the JRC sends to the joined node
SHALL be mapped to a CoAP request: SHALL be mapped to a CoAP request:
o The request method is POST. o The request method is POST.
o The type is Confirmable (CON). o The type is Confirmable (CON).
o The Uri-Path option is set to "j". o The Uri-Path option is set to "j".
o The OSCORE option SHALL be set according to o The OSCORE option SHALL be set according to [RFC8613]. The OSCORE
[I-D.ietf-core-object-security]. The OSCORE security context used security context used is the one derived in Section 7.3. When a
is the one derived in Section 7.3. When a joined node receives a joined node receives a request with the Sender ID set to 0x4a5243
request with the Sender ID set to 0x4a5243 (ID of the JRC), it is (ID of the JRC), it is able to correctly retrieve the security
able to correctly retrieve the security context with the JRC. context with the JRC.
o The payload is a Configuration CBOR object, as defined in o The payload is a Configuration CBOR object, as defined in
Section 8.4.2. Section 8.4.2.
The JRC has implicit knowledge on the global IPv6 address of the The JRC has implicit knowledge on the global IPv6 address of the
joined node, as it knows the pledge identifier that the joined node joined node, as it knows the pledge identifier that the joined node
used when it acted as a pledge, and the IPv6 network prefix. The JRC used when it acted as a pledge, and the IPv6 network prefix. The JRC
uses this implicitly derived IPv6 address of the joined node to uses this implicitly derived IPv6 address of the joined node to
directly address CoAP messages to it. directly address CoAP messages to it.
skipping to change at page 23, line 7 skipping to change at page 23, line 7
processing a CoJP object in a CoAP response (Join Response message), processing a CoJP object in a CoAP response (Join Response message),
a (6LBR) pledge SHOULD reattempt to join. In this case, the (6LBR) a (6LBR) pledge SHOULD reattempt to join. In this case, the (6LBR)
pledge SHOULD include the Unsupported Configuration CBOR object pledge SHOULD include the Unsupported Configuration CBOR object
within the Join Request object in the following Join Request message. within the Join Request object in the following Join Request message.
The Unsupported Configuration CBOR object is self-contained and The Unsupported Configuration CBOR object is self-contained and
enables the (6LBR) pledge to signal any parameters that the enables the (6LBR) pledge to signal any parameters that the
implementation of the networking stack may not support. A (6LBR) implementation of the networking stack may not support. A (6LBR)
pledge MUST NOT attempt more than MAX_RETRANSMIT number of attempts pledge MUST NOT attempt more than MAX_RETRANSMIT number of attempts
to join if the processing of the Join Response message fails each to join if the processing of the Join Response message fails each
time. If COJP_MAX_JOIN_ATTEMPTS number of attempts is reached time. If COJP_MAX_JOIN_ATTEMPTS number of attempts is reached
without success, the (6LBR) pledge SHOULD signal to the user the without success, the (6LBR) pledge SHOULD signal the presence of an
presence of an error condition, through some out-of-band mechanism. error condition, through some out-of-band mechanism.
8.3.2. Diagnostic Response Message 8.3.2. Diagnostic Response Message
The Diagnostic Response message is returned for any CoJP request when The Diagnostic Response message is returned for any CoJP request when
the processing of the payload failed. The Diagnostic Response the processing of the payload failed. The Diagnostic Response
message is protected by OSCORE as any other CoJP protocol message. message is protected by OSCORE as any other CoJP protocol message.
The Diagnostic Response message SHALL be mapped to a CoAP response: The Diagnostic Response message SHALL be mapped to a CoAP response:
o The response Code is 4.00 (Bad Request). o The response Code is 4.00 (Bad Request).
skipping to change at page 24, line 15 skipping to change at page 24, line 15
joined nodes, their assigned short identifiers and mutable security joined nodes, their assigned short identifiers and mutable security
context parameters is lost. If this is the case, during the process context parameters is lost. If this is the case, during the process
of JRC reinitialization, the network administrator MUST force through of JRC reinitialization, the network administrator MUST force through
out-of-band means all the networks managed by the failed JRC to out-of-band means all the networks managed by the failed JRC to
rejoin, through e.g. the reinitialization of the 6LBR nodes and rejoin, through e.g. the reinitialization of the 6LBR nodes and
freshly generated dynamic cryptographic keys and other parameters freshly generated dynamic cryptographic keys and other parameters
that have influence on the security properties of the network. that have influence on the security properties of the network.
In order to recover from such a failure event, the reinitialized JRC In order to recover from such a failure event, the reinitialized JRC
can trigger the renegotiation of the OSCORE security context through can trigger the renegotiation of the OSCORE security context through
the procedure described in Appendix B.2 of the procedure described in Appendix B.2 of [RFC8613]. Aware of the
[I-D.ietf-core-object-security]. Aware of the failure event, the failure event, the reinitialized JRC responds to the first join
reinitialized JRC responds to the first join request of each pledge request of each pledge it is managing with a 4.01 Unauthorized error
it is managing with a 4.01 Unauthorized error and a random nonce. and a random nonce. The pledge verifies the error response and then
The pledge verifies the error response and then initiates the CoJP initiates the CoJP join exchange using a new OSCORE security context
join exchange using a new OSCORE security context derived from an ID derived from an ID Context consisting of the concatenation of two
Context consisting of the concatenation of two nonces, one that it nonces, one that it received from the JRC and the other that the
received from the JRC and the other that the pledge generates pledge generates locally. After verifying the join request with the
locally. After verifying the join request with the new ID Context new ID Context and the derived OSCORE security context, the JRC
and the derived OSCORE security context, the JRC should consequently should consequently take action in mapping the new ID Context with
take action in mapping the new ID Context with the previously used the previously used pledge identifier. How JRC handles this mapping
pledge identifier. How JRC handles this mapping is implementation is implementation specific.
specific.
The described procedure is specified in Appendix B.2 of The described procedure is specified in Appendix B.2 of [RFC8613] and
[I-D.ietf-core-object-security] and is RECOMMENDED in order to handle is RECOMMENDED in order to handle the failure events or any other
the failure events or any other event that may lead to the loss of event that may lead to the loss of mutable security context
mutable security context parameters. The length of nonces exchanged parameters. The length of nonces exchanged using this procedure
using this procedure SHOULD be at least 8 bytes. SHOULD be at least 8 bytes.
The procedure does require both the pledge and the JRC to have good The procedure does require both the pledge and the JRC to have good
sources of randomness. While this is typically not an issue at the sources of randomness. While this is typically not an issue at the
JRC side, the constrained device hosting the pledge may pose JRC side, the constrained device hosting the pledge may pose
limitations in this regard. If the procedure outlined in limitations in this regard. If the procedure outlined in
Appendix B.2 of [I-D.ietf-core-object-security] is not supported by Appendix B.2 of [RFC8613] is not supported by the pledge, the network
the pledge, the network administrator MUST take action in administrator MUST take action in reprovisioning the concerned
reprovisioning the concerned devices with freshly generated devices with freshly generated parameters, through out-of-band means.
parameters, through out-of-band means.
8.4. CoJP Objects 8.4. CoJP Objects
This section specifies the structure of CoJP CBOR objects that may be This section specifies the structure of CoJP CBOR objects that may be
carried as the payload of CoJP messages. Some of these objects may carried as the payload of CoJP messages. Some of these objects may
be received both as part of the CoJP join exchange when the device be received both as part of the CoJP join exchange when the device
operates as a (CoJP) pledge, or the parameter update exchange, when operates as a (CoJP) pledge, or the parameter update exchange, when
the device operates as a joined (6LBR) node. the device operates as a joined (6LBR) node.
8.4.1. Join Request Object 8.4.1. Join Request Object
skipping to change at page 36, line 13 skipping to change at page 36, line 13
corresponding to the identifier parameter is different than 2, the corresponding to the identifier parameter is different than 2, the
identifier is considered invalid. The values 0xfffe and 0xffff are identifier is considered invalid. The values 0xfffe and 0xffff are
reserved by [IEEE802.15.4] and their use is considered invalid. reserved by [IEEE802.15.4] and their use is considered invalid.
The security properties offered by the [IEEE802.15.4] link-layer in The security properties offered by the [IEEE802.15.4] link-layer in
TSCH mode are conditioned on the uniqueness requirement of the short TSCH mode are conditioned on the uniqueness requirement of the short
identifier (i.e. short address). The short address is one of the identifier (i.e. short address). The short address is one of the
inputs in the construction of the nonce, which is used to protect inputs in the construction of the nonce, which is used to protect
link-layer frames. If a misconfiguration occurs, and the same short link-layer frames. If a misconfiguration occurs, and the same short
address is assigned twice under the same link-layer key, the loss of address is assigned twice under the same link-layer key, the loss of
security properties is eminent. For this reason, practices where the security properties is imminent. For this reason, practices where
pledge generates the short identifier locally are not safe and are the pledge generates the short identifier locally are not safe and
likely to result in the loss of link-layer security properties. are likely to result in the loss of link-layer security properties.
The JRC MUST ensure that at any given time there are never two same The JRC MUST ensure that at any given time there are never two same
short identifiers being used under the same link-layer key. If the short identifiers being used under the same link-layer key. If the
lease_time parameter of a given Short_Identifier object is set to lease_time parameter of a given Short_Identifier object is set to
positive infinity, care needs to be taken that the corresponding positive infinity, care needs to be taken that the corresponding
identifier is not assigned to another node until the JRC is certain identifier is not assigned to another node until the JRC is certain
that it is no longer in use, potentially through out-of-band that it is no longer in use, potentially through out-of-band
signaling. If the lease_time parameter expires for any reason, the signaling. If the lease_time parameter expires for any reason, the
JRC should take into consideration potential ongoing transmissions by JRC should take into consideration potential ongoing transmissions by
the joined node, which may be hanging in the queues, before assigning the joined node, which may be hanging in the queues, before assigning
skipping to change at page 38, line 43 skipping to change at page 38, line 43
process results in OSCORE keys that are important for mutual process results in OSCORE keys that are important for mutual
authentication of the (6LBR) pledge and the JRC. Should an attacker authentication of the (6LBR) pledge and the JRC. Should an attacker
come to know the PSK, then a man-in-the-middle attack is possible. come to know the PSK, then a man-in-the-middle attack is possible.
Many vendors are known to use unsafe practices when generating and Many vendors are known to use unsafe practices when generating and
provisioning PSKs. The use of a single PSK shared among a group of provisioning PSKs. The use of a single PSK shared among a group of
devices is a common pitfall that results in poor security. In this devices is a common pitfall that results in poor security. In this
case, the compromise of a single device is likely to lead to a case, the compromise of a single device is likely to lead to a
compromise of the entire batch, with the attacker having the ability compromise of the entire batch, with the attacker having the ability
to impersonate a legitimate device and join the network, generate to impersonate a legitimate device and join the network, generate
bogus data and disturb the network operation. As a reminder, recall bogus data and disturb the network operation. Additionally, some
the well-known problem with Bluetooth headsets with a "0000" pin. vendors use methods such as scrambling or hashing of device serial
Additionally, some vendors use methods such as scrambling or hashing numbers or their EUI-64 to generate "unique" PSKs. Without any
of device serial numbers or their EUI-64 to generate "unique" PSKs. secret information involved, the effort that the attacker needs to
Without any secret information involved, the effort that the attacker invest into breaking these unsafe derivation methods is quite low,
needs to invest into breaking these unsafe derivation methods is resulting in the possible impersonation of any device from the batch,
quite low, resulting in the possible impersonation of any device from without even needing to compromise a single device. The use of
the batch, without even needing to compromise a single device. The cryptographically secure random number generators to generate the PSK
use of cryptographically secure random number generators to generate is RECOMMENDED, see [NIST800-90A] for different mechanisms using
the PSK is RECOMMENDED, see [NIST800-90A] for different mechanisms deterministic methods.
using deterministic methods.
The JP forwards the unauthenticated join traffic into the network. A The JP forwards the unauthenticated join traffic into the network. A
data cap on the JP prevents it from forwarding more traffic than the data cap on the JP prevents it from forwarding more traffic than the
network can handle. The data cap can be configured by the JRC by network can handle and enables throttling in case of an attack. The
including a join rate parameter in the Join Response and it is data cap can be configured by the JRC by including a join rate
implemented through the CoAP's PROBING_RATE setting. The use of a parameter in the Join Response and it is implemented through the
data cap at a JP forces attackers to use more than one JP if they CoAP's PROBING_RATE setting. The use of a data cap at a JP forces
wish to overwhelm the network. Marking the join traffic packets with attackers to use more than one JP if they wish to overwhelm the
a non-zero DSCP allows the network to carry the traffic if it has network. Marking the join traffic packets with a non-zero DSCP
capacity, but encourages the network to drop the extra traffic rather allows the network to carry the traffic if it has capacity, but
than add bandwidth due to that traffic. encourages the network to drop the extra traffic rather than add
bandwidth due to that traffic.
The shared nature of the "minimal" cell used for the join traffic The shared nature of the "minimal" cell used for the join traffic
makes the network prone to a DoS attack by congesting the JP with makes the network prone to a DoS attack by congesting the JP with
bogus traffic. Such an attacker is limited by its maximum transmit bogus traffic. Such an attacker is limited by its maximum transmit
power. The redundancy in the number of deployed JPs alleviates the power. The redundancy in the number of deployed JPs alleviates the
issue and also gives the pledge a possibility to use the best issue and also gives the pledge a possibility to use the best
available link for joining. How a network node decides to become a available link for joining. How a network node decides to become a
JP is out of scope of this specification. JP is out of scope of this specification.
At the beginning of the join process, the pledge has no means of At the beginning of the join process, the pledge has no means of
skipping to change at page 43, line 6 skipping to change at page 43, line 6
SPOTS; No 732638, project Fed4FIRE+ and open-call project SODA. SPOTS; No 732638, project Fed4FIRE+ and open-call project SODA.
The following individuals provided input to this document (in The following individuals provided input to this document (in
alphabetic order): Christian Amsuss, Tengfei Chang, Klaus Hartke, alphabetic order): Christian Amsuss, Tengfei Chang, Klaus Hartke,
Tero Kivinen, Jim Schaad, Goeran Selander, Yasuyuki Tanaka, Pascal Tero Kivinen, Jim Schaad, Goeran Selander, Yasuyuki Tanaka, Pascal
Thubert, William Vignat, Xavier Vilajosana, Thomas Watteyne. Thubert, William Vignat, Xavier Vilajosana, Thomas Watteyne.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-16 (work in
progress), March 2019.
[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>.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, "Assured Forwarding PHB Group", RFC 2597,
DOI 10.17487/RFC2597, June 1999, DOI 10.17487/RFC2597, June 1999,
<https://www.rfc-editor.org/info/rfc2597>. <https://www.rfc-editor.org/info/rfc2597>.
skipping to change at page 44, line 5 skipping to change at page 43, line 43
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <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>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-24 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-27 (work
in progress), July 2019. in progress), October 2019.
[I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e",
draft-ietf-6tisch-terminology-10 (work in progress), March
2018.
[I-D.ietf-cbor-cddl] [I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to definition language (CDDL): a notational convention to
express CBOR and JSON data structures", draft-ietf-cbor- express CBOR and JSON data structures", draft-ietf-cbor-
cddl-08 (work in progress), March 2019. cddl-08 (work in progress), March 2019.
[I-D.ietf-core-stateless] [I-D.ietf-core-stateless]
Hartke, K., "Extended Tokens and Stateless Clients in the Hartke, K., "Extended Tokens and Stateless Clients in the
Constrained Application Protocol (CoAP)", draft-ietf-core- Constrained Application Protocol (CoAP)", draft-ietf-core-
stateless-01 (work in progress), March 2019. stateless-02 (work in progress), October 2019.
[IEEE802.15.4] [IEEE802.15.4]
IEEE standard for Information Technology, ., "IEEE Std IEEE standard for Information Technology, ., "IEEE Std
802.15.4 Standard for Low-Rate Wireless Networks", n.d.. 802.15.4 Standard for Low-Rate Wireless Networks", n.d..
[NIST800-90A] [NIST800-90A]
NIST Special Publication 800-90A, Revision 1, ., Barker, NIST Special Publication 800-90A, Revision 1, ., Barker,
E., and J. Kelsey, "Recommendation for Random Number E., and J. Kelsey, "Recommendation for Random Number
Generation Using Deterministic Random Bit Generators", Generation Using Deterministic Random Bit Generators",
2015. 2015.
 End of changes. 35 change blocks. 
149 lines changed or deleted 140 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/