draft-ietf-6tisch-minimal-security-13.txt   draft-ietf-6tisch-minimal-security-14.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: April 30, 2020 Analog Devices Expires: June 7, 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
October 28, 2019 December 05, 2019
Minimal Security Framework for 6TiSCH Constrained Join Protocol (CoJP) for 6TiSCH
draft-ietf-6tisch-minimal-security-13 draft-ietf-6tisch-minimal-security-14
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
(Object Security for Constrained RESTful Environments), the pledge (Object Security for Constrained RESTful Environments), the pledge
requests admission into the network and the JRC configures it with requests admission into the network and the JRC configures it with
link-layer keying material and other parameters. The JRC may at any link-layer keying material and other parameters. The JRC may at any
time update the parameters through another request-response exchange time update the parameters through another request-response exchange
secured by OSCORE. This specification defines the Constrained Join secured by OSCORE. This specification defines the Constrained Join
Protocol and its CBOR (Concise Binary Object Representation) data Protocol and its CBOR (Concise Binary Object Representation) data
structures, and configures the rest of the 6TiSCH communication stack structures, and describes how to configure the rest of the 6TiSCH
for this join process to occur in a secure manner. Additional communication stack for this join process to occur in a secure
security mechanisms may be added on top of this minimal framework. manner. Additional security mechanisms may be added on top of this
minimal framework.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2020. This Internet-Draft will expire on June 7, 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 33 skipping to change at page 2, line 33
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Provisioning Phase . . . . . . . . . . . . . . . . . . . . . 5 3. Provisioning Phase . . . . . . . . . . . . . . . . . . . . . 5
4. Join Process Overview . . . . . . . . . . . . . . . . . . . . 7 4. Join Process Overview . . . . . . . . . . . . . . . . . . . . 7
4.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 8 4.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 8
4.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 9 4.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 9
4.3. Step 3 - Constrained Join Protocol (CoJP) Execution . . . 9 4.3. Step 3 - Constrained Join Protocol (CoJP) Execution . . . 9
4.4. The Special Case of the 6LBR Pledge Joining . . . . . . . 10 4.4. The Special Case of the 6LBR Pledge Joining . . . . . . . 10
5. Link-layer Configuration . . . . . . . . . . . . . . . . . . 10 5. Link-layer Configuration . . . . . . . . . . . . . . . . . . 10
5.1. Distribution of Time . . . . . . . . . . . . . . . . . . 11 5.1. Distribution of Time . . . . . . . . . . . . . . . . . . 11
6. Network-layer Configuration . . . . . . . . . . . . . . . . . 11 6. Network-layer Configuration . . . . . . . . . . . . . . . . . 12
6.1. Identification of Unauthenticated Traffic . . . . . . . . 12 6.1. Identification of Unauthenticated Traffic . . . . . . . . 13
7. Application-level Configuration . . . . . . . . . . . . . . . 14 7. Application-level Configuration . . . . . . . . . . . . . . . 14
7.1. Statelessness of the JP . . . . . . . . . . . . . . . . . 14 7.1. Statelessness of the JP . . . . . . . . . . . . . . . . . 15
7.2. Recommended Settings . . . . . . . . . . . . . . . . . . 15 7.2. Recommended Settings . . . . . . . . . . . . . . . . . . 16
7.3. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.3. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Constrained Join Protocol (CoJP) . . . . . . . . . . . . . . 18 8. Constrained Join Protocol (CoJP) . . . . . . . . . . . . . . 19
8.1. Join Exchange . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Join Exchange . . . . . . . . . . . . . . . . . . . . . . 20
8.2. Parameter Update Exchange . . . . . . . . . . . . . . . . 21 8.2. Parameter Update Exchange . . . . . . . . . . . . . . . . 21
8.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 22 8.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 23
8.4. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 24 8.4. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 25
8.5. Recommended Settings . . . . . . . . . . . . . . . . . . 37 8.5. Recommended Settings . . . . . . . . . . . . . . . . . . 39
9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 39 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 41
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
11.1. CoJP Parameters Registry . . . . . . . . . . . . . . . . 40 11.1. CoJP Parameters Registry . . . . . . . . . . . . . . . . 42
11.2. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 41 11.2. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 43
11.3. CoJP Unsupported Configuration Code Registry . . . . . . 42 11.3. CoJP Unsupported Configuration Code Registry . . . . . . 44
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
13.1. Normative References . . . . . . . . . . . . . . . . . . 43 13.1. Normative References . . . . . . . . . . . . . . . . . . 45
13.2. Informative References . . . . . . . . . . . . . . . . . 44 13.2. Informative References . . . . . . . . . . . . . . . . . 46
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 45 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 48
Appendix B. Lightweight Implementation Option . . . . . . . . . 48 Appendix B. Lightweight Implementation Option . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
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-architecture]. 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 Mutual authentication during network access and implicit
authentication during network access is achieved through the use of a authorization are achieved through the use of a secure channel, as
secure channel, as configured by this document. This document also configured by this document. This document also specifies a
specifies a configuration of different layers of the 6TiSCH protocol configuration of different layers of the 6TiSCH protocol stack that
stack that reduces the Denial of Service (DoS) attack surface during reduces the Denial of Service (DoS) attack surface during the join
the join process. process.
This document presumes a 6TiSCH network as described by [RFC7554] and This document presumes a 6TiSCH network as described by [RFC7554] and
[RFC8180]. By design, nodes in a 6TiSCH network [RFC7554] have their [RFC8180]. By design, nodes in a 6TiSCH network [RFC7554] have their
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 [RFC8613] for its end-to-end security. The transfer, and on OSCORE [RFC8613] for its end-to-end security. The
secure join solution defined in this document therefore reuses those secure join solution defined in this document 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 [IEEE802.15.4], including the Time-Slotted Channel
mode 6TiSCH is based on. CoJP may as well be used in other (low- Hopping (TSCH) mode 6TiSCH is based on. CoJP may as well be used in
power) networking technologies where efficiency in terms of other (low-power) networking technologies where efficiency in terms
communication overhead and code footprint is important. In such a of 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.
CoJP assumes the presence of a Join Registrar/Coordinator (JRC), a CoJP assumes the presence of a Join Registrar/Coordinator (JRC), a
central entity. The configuration defined in this document assumes central entity. The configuration defined in this document assumes
that the pledge and the JRC share a secret cryptographic key, called that the pledge and the JRC share a unique symmetric cryptographic
PSK (pre-shared key). The PSK is used to configure OSCORE to provide key, called PSK (pre-shared key). The PSK is used to configure
a secure channel to CoJP. How the PSK is installed is out of scope OSCORE to provide a secure channel to CoJP. How the PSK is installed
of this document: this may happen during the provisioning phase or by is out of scope of this document: this may happen during the
a key exchange protocol that may precede the execution of CoJP. provisioning phase or by a key exchange protocol that may precede the
execution of CoJP.
When the pledge seeks admission to a 6TiSCH network, it first When the pledge seeks admission to a 6TiSCH network, it first
synchronizes to it, by initiating the passive scan defined in synchronizes to it, by initiating the passive scan defined in
[IEEE802.15.4]. The pledge then exchanges CoJP messages with the [IEEE802.15.4]. The pledge then exchanges CoJP messages with the
JRC; these messages can be forwarded by nodes already part of the JRC; for this end-to-end communication to happen, messages are
6TiSCH network, called Join Proxies. The messages exchanged allow forwarded by nodes already part of the 6TiSCH network, called Join
the JRC and the pledge to mutually authenticate, based on the Proxies. The messages exchanged allow the JRC and the pledge to
properties provided by OSCORE. They also allow the JRC to configure mutually authenticate, based on the properties provided by OSCORE.
the pledge with link-layer keying material, short identifier and They also allow the JRC to configure the pledge with link-layer
other parameters. After this secure join process successfully keying material, short identifier and other parameters. After this
completes, the joined node can interact with its neighbors to request secure join process successfully completes, the joined node can
additional bandwidth using the 6top Protocol [RFC8480] and start interact with its neighbors to request additional bandwidth using the
sending application traffic. 6top Protocol [RFC8480] and start sending application traffic.
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
skipping to change at page 5, line 18 skipping to change at page 5, line 18
o join process o join process
The following terms defined in [RFC8505] are also used throughout The following terms defined in [RFC8505] are also used throughout
this document: this document:
o 6LoWPAN Border Router (6LBR) o 6LoWPAN Border Router (6LBR)
o 6LoWPAN Node (6LN) o 6LoWPAN Node (6LN)
The term "6LBR" is used interchangeably with the term "DODAG root" The term "6LBR" is used interchangeably with the term "DODAG root"
defined in [RFC6550], assuming the two entities are co-located, as defined in [RFC6550], on the assumption that the two entities are co-
recommended by [I-D.ietf-6tisch-architecture]. located, as recommended by [I-D.ietf-6tisch-architecture].
The term "pledge", as used throughout the document, explicitly The term "pledge", as used throughout the document, explicitly
denotes non-6LBR devices attempting to join the network using their denotes non-6LBR devices attempting to join the network using their
IEEE Std 802.15.4 network interface. The device that attempts to IEEE Std 802.15.4 network interface. The device that attempts to
join as the 6LBR of the network and does so over another network join as the 6LBR of the network and does so over another network
interface is explicitly denoted as the "6LBR pledge". When the text interface is explicitly denoted as the "6LBR pledge". When the text
equally applies to the pledge and the 6LBR pledge, the "(6LBR) equally applies to the pledge and the 6LBR pledge, the "(6LBR)
pledge" form is used. pledge" form is used.
In addition, we use generic terms "pledge identifier" and "network In addition, we use generic terms "pledge identifier" and "network
identifier". See Section 3. identifier". See Section 3.
The terms "secret key" and "symmetric key" are used interchangeably.
3. Provisioning Phase 3. Provisioning Phase
The (6LBR) pledge is provisioned with certain parameters before The (6LBR) pledge is provisioned with certain parameters before
attempting to join the network, and the same parameters are attempting to join the network, and the same parameters are
provisioned to the JRC. There are many ways by which this provisioned to the JRC. There are many ways by which this
provisioning can be done. Physically, the parameters can be written provisioning can be done. Physically, the parameters can be written
into the (6LBR) pledge using a number of mechanisms, such as a JTAG into the (6LBR) pledge using a number of mechanisms, such as a JTAG
interface, a serial (craft) console interface, pushing buttons interface, a serial (craft) console interface, pushing buttons
simultaneously on different devices, over-the-air configuration in a simultaneously on different devices, over-the-air configuration in a
Faraday cage, etc. The provisioning can be done by the vendor, the Faraday cage, etc. The provisioning can be done by the vendor, the
skipping to change at page 6, line 14 skipping to change at page 6, line 14
o pledge identifier. The pledge identifier identifies the (6LBR) o pledge identifier. The pledge identifier identifies the (6LBR)
pledge. The pledge identifier MUST be unique in the set of all pledge. The pledge identifier MUST be unique in the set of all
pledge identifiers managed by a JRC. The pledge identifier pledge identifiers managed by a JRC. The pledge identifier
uniqueness is an important security requirement, as discussed in uniqueness is an important security requirement, as discussed in
Section 9. The pledge identifier is typically the globally unique Section 9. The pledge identifier is typically the globally unique
64-bit Extended Unique Identifier (EUI-64) of the IEEE Std 64-bit Extended Unique Identifier (EUI-64) of the IEEE Std
802.15.4 device, in which case it is provisioned by the hardware 802.15.4 device, in which case it is provisioned by the hardware
manufacturer. The pledge identifier is used to generate the IPv6 manufacturer. The pledge identifier is used to generate the IPv6
addresses of the (6LBR) pledge and to identify it during the addresses of the (6LBR) pledge and to identify it during the
execution of the join protocol. For privacy reasons (see execution of the join protocol. Depending on the configuration,
Section 10), it is possible to use a pledge identifier different the pledge identifier may also be used after the join process to
from the EUI-64. For example, a pledge identifier may be a random identify the joined node. For privacy reasons (see Section 10),
byte string, but care needs to be taken that such a string meets it is possible to use a pledge identifier different from the EUI-
the uniqueness requirement. 64. For example, a pledge identifier may be a random byte string,
but care needs to be taken that such a string meets the uniqueness
requirement.
o Pre-Shared Key (PSK). A secret cryptographic key shared between o Pre-Shared Key (PSK). A symmetric cryptographic key shared
the (6LBR) pledge and the JRC. The JRC additionally needs to between the (6LBR) pledge and the JRC. To look up the PSK for a
store the pledge identifier bound to the given PSK. Each (6LBR) given pledge, the JRC additionally needs to store the
pledge MUST be provisioned with a unique PSK. The PSK SHOULD be a corresponding pledge identifier. Each (6LBR) pledge MUST be
cryptographically strong key, at least 128 bits in length, provisioned with a unique PSK. The PSK MUST be a
cryptographically strong key, with at least 128 bits of entropy,
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. In case of device re- generating PSKs are discussed in Section 9. In case of device re-
commissioning to a new owner, the PSK MUST be changed. commissioning to a new owner, the PSK MUST be changed. Note that
the PSK is different from the link-layer keys K1 and K2 specified
in [RFC8180]. The PSK is a long-term secret used to protect the
execution of the secure join protocol specified in this document
whose one output are link-layer keys.
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
this specification. Provisioning the network identifier is this specification. Provisioning the network identifier to a
RECOMMENDED. However, due to operational constraints, the network pledge is RECOMMENDED. However, due to operational constraints,
identifier may not be known at the time when the provisioning is the network identifier may not be known at the time when the
done. In case this parameter is not provisioned to the pledge, provisioning is done. In case this parameter is not provisioned
the pledge attempts to join one advertised network at a time, to the pledge, the pledge attempts to join one advertised network
which significantly prolongs the join process. This parameter at a time, which significantly prolongs the join process. This
MUST be provisioned to the 6LBR pledge. parameter MUST be provisioned to the 6LBR pledge.
o Optionally, any non-default algorithms. The default algorithms o Optionally, any non-default algorithms. The default algorithms
are specified in Section 7.3.3. When algorithm identifiers are are specified in Section 7.3.3. When algorithm identifiers are
not exchanged, the use of these default algorithms is implied. not provisioned, the use of these default algorithms is implied.
Additionally, the 6LBR pledge that is not co-located with the JRC Additionally, the 6LBR pledge that is not co-located with the JRC
needs to be provisioned with: needs to be provisioned with:
o Global IPv6 address of the JRC. This address is used by the 6LBR o Global IPv6 address of the JRC. This address is used by the 6LBR
pledge to address the JRC during the join process. The 6LBR pledge to address the JRC during the join process. The 6LBR
pledge may also obtain the IPv6 address of the JRC through other pledge may also obtain the IPv6 address of the JRC through other
available mechanisms, such as DHCPv6, GRASP, mDNS, the use of available mechanisms, such as DHCPv6 [RFC8415], GRASP
which is out of scope of this document. Pledges do not need to be [I-D.ietf-anima-grasp], mDNS [RFC6762], the use of which is out of
provisioned with this address as they discover it dynamically scope of this document. Pledges do not need to be provisioned
through CoJP. with this address as they discover it dynamically through CoJP.
4. Join Process Overview 4. Join Process Overview
This section describes the steps taken by a pledge in a 6TiSCH This section describes the steps taken by a pledge in a 6TiSCH
network. When a pledge seeks admission to a 6TiSCH network, the network. When a pledge seeks admission to a 6TiSCH network, the
following exchange occurs: following exchange occurs:
1. The pledge listens for an Enhanced Beacon (EB) frame 1. The pledge listens for an Enhanced Beacon (EB) frame
[IEEE802.15.4]. This frame provides network synchronization [IEEE802.15.4]. This frame provides network synchronization
information, and tells the device when it can send a frame to the information, and tells the device when it can send a frame to the
node sending the beacons, which acts as a Join Proxy (JP) for the node sending the beacons, which acts as a Join Proxy (JP) for the
pledge, and when it can expect to receive a frame. The Enhanced pledge, and when it can expect to receive a frame. The Enhanced
Beacon provides the L2 address of the JP and it may also provide Beacon provides the link-layer address of the JP and it may also
its link-local IPv6 address. provide its link-local IPv6 address.
2. The pledge configures its link-local IPv6 address and advertises 2. The pledge configures its link-local IPv6 address and advertises
it to the JP using Neighbor Discovery. This step may be omitted it to the JP using Neighbor Discovery. The advertisement step
if the link-local address has been derived from a known unique may be omitted if the link-local address has been derived from a
interface identifier, such as an EUI-64 address. known unique interface identifier, such as an EUI-64 address.
3. The pledge sends a Join Request to the JP in order to securely 3. The pledge sends a Join Request to the JP in order to securely
identify itself to the network. The Join Request is forwarded to identify itself to the network. The Join Request is forwarded to
the JRC. the JRC.
4. In case of successful processing of the request, the pledge 4. In case of successful processing of the request, the pledge
receives a Join Response from the JRC (via the JP). The Join receives a Join Response from the JRC (via the JP). The Join
Response contains configuration parameters necessary for the Response contains configuration parameters necessary for the
pledge to join the network. pledge to join the network.
skipping to change at page 8, line 21 skipping to change at page 8, line 29
| | | | | |
|<-Neighbor Discovery (2)->| | |<-Neighbor Discovery (2)->| |
| | | | | |
|-----Join Request (3a)----|----Join Request (3a)---->| \ |-----Join Request (3a)----|----Join Request (3a)---->| \
| | | | CoJP | | | | CoJP
|<----Join Response (3b)---|----Join Response (3b)----| / |<----Join Response (3b)---|----Join Response (3b)----| /
| | | | | |
Figure 1: Overview of a successful join process. Figure 1: Overview of a successful join process.
As other nodes in the network, the 6LBR node may act as the JP. The As for other nodes in the network, the 6LBR node may act as the JP.
6LBR may in addition be co-located with the JRC. The 6LBR may in addition be co-located with the JRC.
The details of each step are described in the following sections. The details of each step are described in the following sections.
4.1. Step 1 - Enhanced Beacon 4.1. Step 1 - Enhanced Beacon
The pledge synchronizes to the network by listening for, and The pledge synchronizes to the network by listening for, and
receiving, an Enhanced Beacon (EB) sent by a node already in the receiving, an Enhanced Beacon (EB) sent by a node already in the
network. This process is entirely defined by [IEEE802.15.4], and network. This process is entirely defined by [IEEE802.15.4], and
described in [RFC7554]. described in [RFC7554].
skipping to change at page 9, line 13 skipping to change at page 9, line 23
that has sent the EB to the pledge acts as the JP. that has sent the EB to the pledge acts as the JP.
At this point, the pledge may proceed to step 2, or continue to At this point, the pledge may proceed to step 2, or continue to
listen for additional EBs. listen for additional EBs.
4.2. Step 2 - Neighbor Discovery 4.2. Step 2 - Neighbor Discovery
The pledge forms its link-local IPv6 address based on the interface The pledge forms its link-local IPv6 address based on the interface
identifier, as per [RFC4944]. The pledge MAY perform the Neighbor identifier, as per [RFC4944]. The pledge MAY perform the Neighbor
Solicitation / Neighbor Advertisement exchange with the JP, as per Solicitation / Neighbor Advertisement exchange with the JP, as per
Section 5.6 of [RFC8505]. The pledge and the JP use their link-local Section 5.6 of [RFC8505]. As per [RFC8505], there is no need to
IPv6 addresses for all subsequent communication during the join perform duplicate address detection for the link-local address. The
process. pledge and the JP use their link-local IPv6 addresses for all
subsequent communication during the join process.
Note that Neighbor Discovery exchanges at this point are not Note that Neighbor Discovery exchanges at this point are not
protected with link-layer security as the pledge is not in possession protected with link-layer security as the pledge is not in possession
of the keys. How JP accepts these unprotected frames is discussed in of the keys. How the JP accepts these unprotected frames is
Section 5. discussed in Section 5.
4.3. Step 3 - Constrained Join Protocol (CoJP) Execution 4.3. Step 3 - Constrained Join Protocol (CoJP) Execution
The pledge triggers the join exchange of the Constrained Join The pledge triggers the join exchange of the Constrained Join
Protocol (CoJP). The join exchange consists of two messages: the Protocol (CoJP). The join exchange consists of two messages: the
Join Request message (Step 3a), and the Join Response message Join Request message (Step 3a), and the Join Response message
conditioned on the successful security processing of the request conditioned on the successful security processing of the request
(Step 3b). (Step 3b).
All CoJP messages are exchanged over a secure end-to-end channel that All CoJP messages are exchanged over a secure end-to-end channel that
skipping to change at page 10, line 10 skipping to change at page 10, line 20
identifier of the network it requests to join. The JP forwards the identifier of the network it requests to join. The JP forwards the
Join Request to the JRC on the existing links. How exactly this Join Request to the JRC on the existing links. How exactly this
happens is out of scope of this document; some networks may wish to happens is out of scope of this document; some networks may wish to
dedicate specific link layer resources for this join traffic. dedicate specific link layer resources for this join traffic.
4.3.2. Step 3b - Join Response 4.3.2. Step 3b - Join Response
The Join Response is sent by the JRC to the pledge, and is forwarded The Join Response is sent by the JRC to the pledge, and is forwarded
through the JP. The packet containing the Join Response travels from through the JP. The packet containing the Join Response travels from
the JRC to the JP using the operating routes in the network. The JP the JRC to the JP using the operating routes in the network. The JP
delivers it to the pledge. The JP operates as the application-layer delivers it to the pledge. The JP operates as an application-layer
proxy. proxy, see Section 7.
The Join Response contains different parameters needed by the pledge The Join Response contains different parameters needed by the pledge
to become a fully operational network node. These parameters include to become a fully operational network node. These parameters include
the link-layer key(s) currently in use in the network, the short the link-layer key(s) currently in use in the network, the short
address assigned to the pledge, the IPv6 address of the JRC needed by address assigned to the pledge, the IPv6 address of the JRC needed by
the pledge to operate as the JP, among others. the pledge to operate as the JP, among others.
4.4. The Special Case of the 6LBR Pledge Joining 4.4. The Special Case of the 6LBR Pledge Joining
The 6LBR pledge performs Section 4.3 of the join process described The 6LBR pledge performs Section 4.3 of the join process described
above, just as any other pledge, albeit over a different network above, just as any other pledge, albeit over a different network
interface. There is no JP intermediating the communication between interface. There is no JP intermediating the communication between
the 6LBR pledge and the JRC, as described in Section 6. The other the 6LBR pledge and the JRC, as described in Section 6. The other
steps of the described join process do not apply to the 6LBR pledge. steps of the described join process do not apply to the 6LBR pledge.
How the 6LBR pledge obtains an IPv6 address and triggers the How the 6LBR pledge obtains an IPv6 address and triggers the
execution of the CoJP protocol is out of scope of this document. execution of the CoJP protocol is out of scope of this document.
5. Link-layer Configuration 5. Link-layer Configuration
In an operational 6TiSCH network, all frames MUST use link-layer In an operational 6TiSCH network, all frames use link-layer frame
frame security [RFC8180]. The IEEE Std 802.15.4 security attributes security [RFC8180]. The IEEE Std 802.15.4 security attributes
MUST include frame authenticity, and MAY include frame include frame authenticity, and optionally frame confidentiality
confidentiality (i.e. encryption). (i.e. encryption).
Any node sending EB frames MUST be prepared to act as a JP for
potential pledges.
The pledge does not initially do any authenticity check of the EB The pledge does not initially do any authenticity check of the EB
frames, as it does not possess the link-layer key(s) in use. The frames, as it does not possess the link-layer key(s) in use. The
pledge is still able to parse the contents of the received EBs and pledge is still able to parse the contents of the received EBs and
synchronize to the network, as EBs are not encrypted [RFC8180]. synchronize to the network, as EBs are not encrypted [RFC8180].
When sending frames during the join process, the pledge sends When sending frames during the join process, the pledge sends
unencrypted and unauthenticated frames. The JP accepts these unencrypted and unauthenticated frames at the link layer. In order
for the join process to be possible, the JP must accept these
unsecured frames for the duration of the join process. This behavior unsecured frames for the duration of the join process. This behavior
may be implemented by setting the "secExempt" attribute in the IEEE may be implemented by setting the "secExempt" attribute in the IEEE
Std 802.15.4 security configuration tables. How the JP learns Std 802.15.4 security configuration tables. It is expected that the
whether the join process is ongoing is out of scope of this lower layer provides an interface to indicate to the upper layer that
specification. unsecured frames are being received from a device, and that the upper
layer can use that information to make a determination that a join
process is in place and the unsecured frames should be processed.
How the JP makes such a determination and interacts with the lower
layer is out of scope of this specification. The JP can additionally
make use of information such as the value of the join rate parameter
(Section 8.4.2) set by the JRC, physical button press, etc.
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. Absolute slot number is used in the absolute slot number. Absolute slot number is used in the
construction of the link-layer nonce, as defined in [IEEE802.15.4]. construction of the link-layer nonce, as defined in [IEEE802.15.4].
The pledge initially synchronizes to the EB frame sent by the JP, and The pledge initially synchronizes to the EB frame sent by the JP, and
uses the value of the absolute slot number found in the TSCH uses the value of the absolute slot number found in the TSCH
Synchronization Information Element. At the time of the Synchronization Information Element. At the time of the
skipping to change at page 11, line 41 skipping to change at page 12, line 14
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 on the pledge
and the link-layer keys are configured, the upper layer MUST trigger is completed and the link-layer keys are configured, the upper layer
the security processing of the corresponding frame. Once the MUST trigger the security processing of the corresponding frame.
security processing of the frame carrying the Join Response message Once the security processing of the frame carrying the Join Response
is successful, the current absolute slot number kept locally at the message is successful, the current absolute slot number kept locally
pledge SHALL be declared as valid. at the 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 12, line 30 skipping to change at page 13, line 5
layer using link-local addressing, and with the JRC at the layer using link-local addressing, and with the JRC at the
application layer, as specified in Section 7. application layer, as specified in Section 7.
The JP communicates with the JRC over global IPv6 addresses. The JP The JP communicates with the JRC over global IPv6 addresses. The JP
discovers the network IPv6 prefix and configures its global IPv6 discovers the network IPv6 prefix and configures its global IPv6
address upon successful completion of the join process and the address upon successful completion of the join process and the
obtention of link-layer keys. The pledge learns the IPv6 address of obtention of link-layer keys. The pledge learns the IPv6 address of
the JRC from the Join Response, as specified in Section 8.1.2; it the JRC from the Join Response, as specified in Section 8.1.2; it
uses it once joined in order to operate as a JP. uses it once joined in order to operate as a JP.
As a special case, the 6LBR pledge is expected to have an additional As a special case, the 6LBR pledge may have an additional network
network interface that it uses in order to obtain the configuration interface that it uses in order to obtain the configuration
parameters from the JRC and start advertising the 6TiSCH network. parameters from the JRC and start advertising the 6TiSCH network.
This additional interface needs to be configured with a global IPv6 This additional interface needs to be configured with a global IPv6
address, by a mechanism that is out of scope of this document. The address, by a mechanism that is out of scope of this document. The
6LBR pledge uses this interface to directly communicate with the JRC 6LBR pledge uses this interface to directly communicate with the JRC
using global IPv6 addressing. using global IPv6 addressing.
The JRC can be co-located on the 6LBR. In this special case, the The JRC can be co-located on the 6LBR. In this special case, the
IPv6 address of the JRC can be omitted from the Join Response message IPv6 address of the JRC can be omitted from the Join Response message
for space optimization. The 6LBR then MUST set the DODAGID field in for space optimization. The 6LBR then MUST set the DODAGID field in
the RPL DIOs [RFC6550] to its IPv6 address. The pledge learns the the RPL DIOs [RFC6550] to its IPv6 address. The pledge learns the
skipping to change at page 13, line 14 skipping to change at page 13, line 36
When operating as part of a [RFC8180] 6TiSCH minimal network using When operating as part of a [RFC8180] 6TiSCH minimal network using
distributed scheduling algorithms, the traffic from unauthenticated distributed scheduling algorithms, the traffic from unauthenticated
pledges may cause intermediate nodes to request additional bandwidth. pledges may cause intermediate nodes to request additional bandwidth.
An attacker could use this property to cause the network to An attacker could use this property to cause the network to
overcommit bandwidth (and energy) to the join process. overcommit bandwidth (and energy) to the join process.
The Join Proxy is aware of what traffic originates from The Join Proxy is aware of what traffic originates from
unauthenticated pledges, and so can avoid allocating additional unauthenticated pledges, and so can avoid allocating additional
bandwidth itself. The Join Proxy implements a data cap on outgoing bandwidth itself. The Join Proxy implements a data cap on outgoing
join traffic through CoAP's congestion control mechanism. This cap join traffic by implementing the recommendation of 1 packet per 3
will not protect intermediate nodes as they can not tell join traffic seconds in Section 3.1.3 of [RFC8085]. This can be achieved with the
from regular traffic. Despite the data cap implemented separately on congestion control mechanism specified in Section 4.7 of [RFC7252].
each Join Proxy, the aggregate join traffic from many Join Proxies This cap will not protect intermediate nodes as they can not tell
may cause intermediate nodes to decide to allocate additional cells. join traffic from regular traffic. Despite the data cap implemented
It is undesirable to do so in response to the traffic originated at separately on each Join Proxy, the aggregate join traffic from many
unauthenticated pledges. In order to permit the intermediate nodes Join Proxies may cause intermediate nodes to decide to allocate
to avoid this, the traffic needs to be tagged. [RFC2597] defines a additional cells. It is undesirable to do so in response to the
set of per-hop behaviors that may be encoded into the Diffserv Code traffic originated at unauthenticated pledges. In order to permit
Points (DSCPs). Based on the DSCP, intermediate nodes can decide the intermediate nodes to avoid this, the traffic needs to be tagged.
whether to act on a given packet. [RFC2597] defines a set of per-hop behaviors that may be encoded into
the Diffserv Code Points (DSCPs). Based on the DSCP, intermediate
nodes can decide whether to act on a given packet.
6.1.1. Traffic from JP to JRC 6.1.1. Traffic from JP to JRC
The Join Proxy SHOULD set the DSCP of packets that it produces as The Join Proxy SHOULD set the DSCP of packets that it produces as
part of the forwarding process to AF43 code point (See Section 6 of part of the forwarding process to AF43 code point (See Section 6 of
[RFC2597]). A Join Proxy that does not set the DSCP on traffic [RFC2597]). A Join Proxy that does not require a specific DSCP value
forwarded should set it to zero so that it is compressed out. on traffic forwarded should set it to zero so that it is compressed
out.
A Scheduling Function (SF) running on 6TiSCH nodes SHOULD NOT A Scheduling Function (SF) running on 6TiSCH nodes SHOULD NOT
allocate additional cells as a result of traffic with code point allocate additional cells as a result of traffic with code point
AF43. Companion SF documents SHOULD specify how this recommended AF43. Companion SF documents SHOULD specify how this recommended
behavior is achieved. behavior is achieved.
6.1.2. Traffic from JRC to JP 6.1.2. Traffic from JRC to JP
The JRC SHOULD set the DSCP of join response packets addressed to the The JRC SHOULD set the DSCP of join response packets addressed to the
Join Proxy to AF42 code point. AF42 has lower drop probability than Join Proxy to AF42 code point. AF42 has lower drop probability than
AF43, giving this traffic priority in buffers over the traffic going AF43, giving this traffic priority in buffers over the traffic going
towards the JRC. towards the JRC.
Due to the convergecast nature of the DODAG, the 6LBR links are often The 6LBR links are often the most congested within a DODAG, and from
the most congested, and from that point down there is progressively that point down there is progressively less (or equal) congestion.
less (or equal) congestion. If the 6LBR paces itself when sending If the 6LBR paces itself when sending join response traffic then it
join response traffic then it ought to never exceed the bandwidth ought to never exceed the bandwidth allocated to the best effort
allocated to the best effort traffic cells. If the 6LBR has the traffic cells. If the 6LBR has the capacity (if it is not
capacity (if it is not constrained) then it should provide some constrained) then it should provide some buffers in order to satisfy
buffers in order to satisfy the Assured Forwarding behavior. 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 [RFC8613]. The (6LBR) pledge the secure channel provided by OSCORE [RFC8613]. The (6LBR) pledge
skipping to change at page 14, line 40 skipping to change at page 15, line 19
The CoAP proxy defined in [RFC7252] keeps per-client state The CoAP proxy defined in [RFC7252] keeps per-client state
information in order to forward the response towards the originator information in order to forward the response towards the originator
of the request. This state information includes at least the CoAP of the request. This state information includes at least the CoAP
token, the IPv6 address of the client, and the UDP source port token, the IPv6 address of the client, and the UDP source port
number. Since the JP can be a constrained device that acts as a CoAP number. Since the JP can be a constrained device that acts as a CoAP
proxy, memory limitations make it prone to a Denial-of-Service (DoS) proxy, memory limitations make it prone to a Denial-of-Service (DoS)
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 to 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. The JRC MUST support extended token lengths, as state object. The JRC and any other potential proxy on the JP - JRC
defined in [I-D.ietf-core-stateless]. Since the CoAP token is echoed path MUST support extended token lengths, as defined in
back in the response, the JP is able to decode the state object and [I-D.ietf-core-stateless]. Since the CoAP token is echoed back in
configure the state needed to forward the response to the pledge. the response, the JP is able to decode the state object and configure
The information that the JP needs to encode in the state object to the state needed to forward the response to the pledge. The
information that the JP needs to encode in the state object to
operate in a fully stateless manner with respect to a given pledge is operate in a fully stateless manner with respect to a given pledge is
implementation specific. 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 the JP is operating in a stateless manner, the security When the JP is operating in a stateless manner, the security
considerations from [I-D.ietf-core-stateless] apply and the type of considerations from [I-D.ietf-core-stateless] apply and the type of
the CoAP message that the JP forwards on behalf of the pledge MUST be the CoAP message that the JP forwards on behalf of the pledge MUST be
non-confirmable (NON), regardless of the message type received from non-confirmable (NON), regardless of the message type received from
skipping to change at page 15, line 32 skipping to change at page 16, line 13
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
This section gives RECOMMENDED values of CoAP settings during the This section gives RECOMMENDED values of CoAP settings during the
join process. join process.
+-------------------+-----------------------+-------------------+ +-------------------+---------------+
| Name | Default Value: Pledge | Default Value: JP | | Name | Default Value |
+-------------------+-----------------------+-------------------+ +-------------------+---------------+
| ACK_TIMEOUT | 10 seconds | (10 seconds) | | ACK_TIMEOUT | 10 seconds |
| | | | | | |
| ACK_RANDOM_FACTOR | 1.5 | (1.5) | | ACK_RANDOM_FACTOR | 1.5 |
| | | | | | |
| MAX_RETRANSMIT | 4 | (4) | | MAX_RETRANSMIT | 4 |
+-------------------+-----------------------+-------------------+ | | |
| NSTART | 1 |
| | |
| DEFAULT_LEISURE | 5 seconds |
| | |
| PROBING_RATE | 1 byte/second |
+-------------------+---------------+
Recommended CoAP settings. Values enclosed in () have no effect when Recommended CoAP settings.
JP operates in a stateless manner.
These values may be configured to values specific to the deployment. These values may be configured to values specific to the deployment.
The default values have been chosen to accommodate a wide range of The default values have been chosen to accommodate a wide range of
deployments, taking into account dense networks. deployments, taking into account dense networks.
The PROBING_RATE value at the JP is controlled by the join rate The PROBING_RATE value at the JP is controlled by the join rate
parameter, see Section 8.4.2. Following [RFC7252], the average data parameter, see Section 8.4.2. Following [RFC7252], the average data
rate in sending to the JRC must not exceed PROBING_RATE. For rate in sending to the JRC must not exceed PROBING_RATE. For
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.
skipping to change at page 17, line 4 skipping to change at page 17, line 39
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 [RFC8613] results in OSCORE keys OSCORE option. The derivation in [RFC8613] results in OSCORE keys
and a common IV for each side of the conversation. Nonces are and a common IV for each side of the conversation. Nonces are
constructed by XOR'ing the common IV with the current sequence constructed by XOR'ing the common IV with the current sequence
number. For details on nonce and OSCORE option construction, refer number. For details on nonce and OSCORE option construction, refer
to [RFC8613]. 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 protected under the same PSK. The pledge typically sends requests to
provisioned with the network identifier and attempts to join one different JRCs if it is not provisioned with the network identifier
network at a time. Failure to comply will break the security and attempts to join one network at a time. Failure to comply will
guarantees of the Authenticated Encryption with Associated Data break the security guarantees of the Authenticated Encryption with
(AEAD) algorithm because of nonce reuse. Associated Data (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 [RFC8613]). A (6LBR) Recipient ID when receiving (see Section 3.1 of [RFC8613]). A (6LBR)
skipping to change at page 17, line 31 skipping to change at page 18, line 17
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 [RFC8613] is RECOMMENDED. specified in Section 3.2.2 of [RFC8613] is 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 detailed in Appendix B.1.1 of [RFC8613] that
detailed in Appendix B.1.1 of [RFC8613], MUST be implemented. Each prevents reuse of sequence numbers MUST be implemented. Each update
update of the OSCORE Replay Window MUST be written to persistent of the OSCORE Replay Window MUST be 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 19, line 14
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 [RFC8613]. CoAP [RFC7252] and a secure channel provided by OSCORE [RFC8613].
CoJP allows the (6LBR) pledge to request admission into a network CoJP allows a (6LBR) pledge to request admission into a network
managed by the JRC, and for the JRC to configure the pledge with the managed by the JRC. It enables the JRC to configure the pledge with
parameters necessary for joining the network, or advertising it in the necessary parameters. The JRC may update the parameters at any
the case of 6LBR pledge. The JRC may update the parameters at any
time, by reaching out to the joined node that formerly acted as a time, by reaching out to the joined node that formerly acted as a
(6LBR) pledge. For example, network-wide rekeying can be implemented (6LBR) pledge. For example, network-wide rekeying can be implemented
by updating the keying material on each node. by updating the keying material on each node.
This section specifies how the CoJP messages are mapped to CoAP and
OSCORE, CBOR data structures carrying different parameters,
transported within CoAP payload, and the parameter semantics and
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.
+-----------------------------------+ +-----------------------------------+
| Constrained Join Protocol (CoJP) | | Constrained Join Protocol (CoJP) |
+-----------------------------------+ +-----------------------------------+
+-----------------------------------+ \ +-----------------------------------+ \
| Requests / Responses | | | Requests / Responses | |
|-----------------------------------| | |-----------------------------------| |
skipping to change at page 19, line 44 skipping to change at page 20, line 15
specified in Section 8.1.2. specified in Section 8.1.2.
When the JRC needs to update the parameters of a joined node that When the JRC needs to update the parameters of a joined node that
formerly acted as a (6LBR) pledge, it executes the CoJP parameter formerly acted as a (6LBR) pledge, it executes the CoJP parameter
update exchange that consists of: update exchange that consists of:
o the Parameter Update message, sent by the JRC to the joined node o the Parameter Update message, sent by the JRC to the joined node
that formerly acted as a (6LBR) pledge. The Parameter Update that formerly acted as a (6LBR) pledge. The Parameter Update
message and its mapping to CoAP is specified in Section 8.2.1. message and its mapping to CoAP is specified in Section 8.2.1.
o the Parameter Update Response message, sent by the joined node to
the JRC in response to the Parameter Update message to signal
successful reception of the updated parameters. The Parameter
Update Response message and its mapping to CoAP is specified in
Section 8.2.2.
The payload of CoJP messages is encoded with CBOR [RFC7049]. The The payload of CoJP messages is encoded with CBOR [RFC7049]. The
CBOR data structures that may appear as the payload of different CoJP CBOR data structures that may appear as the payload of different CoJP
messages are specified in Section 8.4. messages are specified in Section 8.4.
8.1. Join Exchange 8.1. Join Exchange
This section specifies the messages exchanged when the (6LBR) pledge This section specifies the messages exchanged when the (6LBR) pledge
requests admission and configuration parameters from the JRC. requests admission and configuration parameters from the JRC.
8.1.1. Join Request Message 8.1.1. Join Request Message
skipping to change at page 20, line 39 skipping to change at page 21, line 5
OSCORE kid context allows the JRC to retrieve the security context OSCORE kid context allows 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 implementation at (6LBR) pledge declares the
transmission as failure, the (6LBR) pledge SHOULD attempt to join the message transmission as failure, the (6LBR) pledge SHOULD attempt to
next advertised 6TiSCH network. See Section 7.2 for recommended join a 6TiSCH network advertised with a different network identifier.
values of CoAP settings to use during the join exchange. See Section 7.2 for recommended 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 the presence of an error condition, through some pledge SHOULD signal the presence of an error condition, through some
out-of-band mechanism. out-of-band mechanism.
BCP190 [RFC7320] provides guidelines on URI design and ownership. It
recommends that whenever a third party wants to mandate a URL to web
authority that it SHOULD go under "/.well-known" (as per [RFC5785]).
In the case of CoJP, the Uri-Host option is always set to
"6tisch.arpa", and based upon the recommendations in the Introduction
of [RFC7320], it is asserted that this document is the owner of the
CoJP service. As such, the concerns of [RFC7320] do not apply, and
thus the Uri-Path is only "/j".
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 28 skipping to change at page 22, line 4
At the time of the join, the (6LBR) pledge acts as a CoAP client and At the time of the join, the (6LBR) pledge acts as a CoAP client and
requests the network parameters through a representation of the "/j" requests the network parameters through a representation of the "/j"
resource, exposed by the JRC. In order for the update of these resource, exposed by the JRC. In order for the update of these
parameters to happen, the JRC needs to asynchronously contact the parameters to happen, the JRC needs to asynchronously contact the
joined node. The use of the CoAP Observe option for this purpose is joined node. The use of the CoAP Observe option for this purpose is
not feasible due to the change in the IPv6 address when the pledge not feasible due to the change in the IPv6 address when the pledge
becomes the joined node and obtains a global address. becomes the joined node and obtains a global address.
Instead, once the (6LBR) pledge receives and successfully validates Instead, once the (6LBR) pledge receives and successfully validates
the Join Response and so becomes a joined node, it becomes a CoAP the Join Response and so becomes a joined node, it becomes a CoAP
server. The joined node exposes the "/j" resource that is used by server. The joined node creates a CoAP service at the Uri-Host value
the JRC to update the parameters. Consequently, the JRC operates as of "6tisch.arpa", and the joined node exposes the "/j" resource that
a CoAP client when updating the parameters. The request/response is used by the JRC to update the parameters. Consequently, the JRC
exchange between the JRC and the (6LBR) pledge happens over the operates as a CoAP client when updating the parameters. The request/
already-established OSCORE secure channel. response exchange between the JRC and the (6LBR) pledge happens over
the already-established OSCORE secure channel.
8.2.1. Parameter Update Message 8.2.1. Parameter Update Message
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-Host option is set to "6tisch.arpa".
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 [RFC8613]. The OSCORE o The OSCORE option SHALL be set according to [RFC8613]. The OSCORE
security context used is the one derived in Section 7.3. When a security context used is the one derived in Section 7.3. When a
joined node receives a request with the Sender ID set to 0x4a5243 joined node receives a request with the Sender ID set to 0x4a5243
(ID of the JRC), it is able to correctly retrieve the security (ID of the JRC), it is 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.
skipping to change at page 22, line 21 skipping to change at page 23, line 5
In case the JRC does not receive a response to a Parameter Update In case the JRC does not receive a response to a Parameter Update
message, it attempts multiple retransmissions, as configured by the message, it attempts multiple retransmissions, as configured by the
underlying CoAP retransmission mechanism triggered for confirmable underlying CoAP retransmission mechanism triggered for confirmable
messages. Finally, if the CoAP implementation declares the messages. Finally, if the CoAP implementation declares the
transmission as failure, the JRC may consider this as a hint that the transmission as failure, the JRC may consider this as a hint that the
joined node is no longer in the network. How the JRC decides when to joined node is no longer in the network. How the JRC decides when to
stop attempting to contact a previously joined node is out of scope stop attempting to contact a previously joined node is out of scope
of this specification but security considerations on the reuse of of this specification but security considerations on the reuse of
assigned resources apply, as discussed in Section 9. assigned resources apply, as discussed in Section 9.
8.2.2. Parameter Update Response Message
The Parameter Update Response message that the joined node sends to
the JRC SHALL be mapped to a CoAP response:
o The response Code is 2.04 (Changed).
o The payload is empty.
8.3. Error Handling 8.3. Error Handling
8.3.1. CoJP CBOR Object Processing 8.3.1. CoJP CBOR Object Processing
CoJP CBOR objects are transported within both CoAP requests and CoJP CBOR objects are transported within both CoAP requests and
responses. This section describes handling in case certain CoJP CBOR responses. This section describes handling in case certain CoJP CBOR
object parameters are not supported by the implementation or their object parameters are not supported by the implementation or their
processing fails. See Section 7.3.2 for the handling of errors that processing fails. See Section 7.3.2 for the handling of errors that
may be raised by the underlying OSCORE implementation. may be raised by the underlying OSCORE implementation.
skipping to change at page 23, line 4 skipping to change at page 23, line 28
response and is specified in Section 8.3.2. response and is specified in Section 8.3.2.
When a parameter that cannot be acted upon is encountered while When a parameter that cannot be acted upon is encountered while
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 COJP_MAX_JOIN_ATTEMPTS number of
to join if the processing of the Join Response message fails each attempts to join if the processing of the Join Response message fails
time. If COJP_MAX_JOIN_ATTEMPTS number of attempts is reached each time. If COJP_MAX_JOIN_ATTEMPTS number of attempts is reached
without success, the (6LBR) pledge SHOULD signal the presence of an without success, the (6LBR) pledge SHOULD signal the presence of an
error condition, through some out-of-band mechanism. error condition, through some out-of-band mechanism.
Note that COJP_MAX_JOIN_ATTEMPTS relates to the application-level
handling of the CoAP response and is different from CoAP's
MAX_RETRANSMIT setting that drives the retransmission mechanism of
the underlying CoAP message.
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 26 skipping to change at page 25, line 6
failure event, the reinitialized JRC responds to the first join failure event, the reinitialized JRC responds to the first join
request of each pledge it is managing with a 4.01 Unauthorized error request of each pledge it is managing with a 4.01 Unauthorized error
and a random nonce. The pledge verifies the error response and then and a random nonce. The pledge verifies the error response and then
initiates the CoJP join exchange using a new OSCORE security context initiates the CoJP join exchange using a new OSCORE security context
derived from an ID Context consisting of the concatenation of two derived from an ID Context consisting of the concatenation of two
nonces, one that it received from the JRC and the other that the nonces, one that it received from the JRC and the other that the
pledge generates locally. After verifying the join request with the pledge generates locally. After verifying the join request with the
new ID Context and the derived OSCORE security context, the JRC new ID Context and the derived OSCORE security context, the JRC
should consequently take action in mapping the new ID Context with should consequently take action in mapping the new ID Context with
the previously used pledge identifier. How JRC handles this mapping the previously used pledge identifier. How JRC handles this mapping
is implementation specific. is out of scope of this document.
The described procedure is specified in Appendix B.2 of [RFC8613] and The described procedure is specified in Appendix B.2 of [RFC8613] and
is RECOMMENDED in order to handle the failure events or any other is RECOMMENDED in order to handle the failure events or any other
event that may lead to the loss of mutable security context event that may lead to the loss of mutable security context
parameters. The length of nonces exchanged using this procedure parameters. The length of nonces exchanged using this procedure MUST
SHOULD be at least 8 bytes. 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 [RFC8613] is not supported by the pledge, the network Appendix B.2 of [RFC8613] is not supported by the pledge, the network
administrator MUST take action in reprovisioning the concerned administrator MUST take action in reprovisioning the concerned
devices with freshly generated parameters, through out-of-band means. devices with freshly generated parameters, through out-of-band means.
8.4. CoJP Objects 8.4. CoJP Objects
skipping to change at page 25, line 15 skipping to change at page 25, line 40
8.4.1. Join Request Object 8.4.1. Join Request Object
The Join_Request structure is built on a CBOR map object. The Join_Request structure is built on a CBOR map object.
The set of parameters that can appear in a Join_Request object is The set of parameters that can appear in a Join_Request object is
summarized below. The labels can be found in the "CoJP Parameters" summarized below. The labels can be found in the "CoJP Parameters"
registry Section 11.1. registry Section 11.1.
o role: The identifier of the role that the pledge requests to play o role: The identifier of the role that the pledge requests to play
in the network once it joins, encoded as an unsigned integer. in the network once it joins, encoded as an unsigned integer.
Possible values are specified in Table 1. This parameter MAY be Possible values are specified in Table 2. This parameter MAY be
included. In case the parameter is omitted, the default value of included. In case the parameter is omitted, the default value of
0, i.e. the role "6TiSCH Node", MUST be assumed. 0, i.e. the role "6TiSCH Node", MUST be assumed.
o network identifier: The identifier of the network, as discussed in o network identifier: The identifier of the network, as discussed in
Section 3, encoded as a CBOR byte string. When present in the Section 3, encoded as a CBOR byte string. When present in the
Join_Request, it hints to the JRC the network that the pledge is Join_Request, it hints to the JRC the network that the pledge is
requesting to join, enabling the JRC to manage multiple networks. requesting to join, enabling the JRC to manage multiple networks.
The pledge obtains the value of the network identifier from the The pledge obtains the value of the network identifier from the
received EB frames. This parameter MUST be included in a received EB frames. This parameter MUST be included in a
Join_Request object regardless of the role parameter value. Join_Request object regardless of the role parameter value.
o unsupported configuration: The identifier of the parameters that o unsupported configuration: The identifier of the parameters that
are not supported by the implementation, encoded as an are not supported by the implementation, encoded as an
Unsupported_Configuration object described in Section 8.4.5. This Unsupported_Configuration object described in Section 8.4.5. This
parameter MAY be included. If a (6LBR) pledge previously parameter MAY be included. If a (6LBR) pledge previously
attempted to join and received a valid Join Response message over attempted to join and received a valid Join Response message over
OSCORE, but failed to act on its payload (Configuration object), OSCORE, but failed to act on its payload (Configuration object),
it SHOULD include this parameter to facilitate the recovery and it SHOULD include this parameter to facilitate the recovery and
debugging. debugging.
Table 1 summarizes the parameters that may appear in a Join_Request
object.
+---------------------------+-------+------------------+
| Name | Label | CBOR Type |
+---------------------------+-------+------------------+
| role | 1 | unsigned integer |
| | | |
| network identifier | 5 | byte string |
| | | |
| unsupported configuration | 8 | array |
+---------------------------+-------+------------------+
Table 1: Summary of Join_Request parameters.
The CDDL fragment that represents the text above for the Join_Request The CDDL fragment that represents the text above for the Join_Request
follows. follows.
Join_Request = { Join_Request = {
? 1 : uint, ; role ? 1 : uint, ; role
? 5 : bstr, ; network identifier 5 : bstr, ; network identifier
? 8 : Unsupported_Configuration ; unsupported configuration ? 8 : Unsupported_Configuration ; unsupported configuration
} }
+--------+-------+-------------------------------------+------------+ +--------+-------+-------------------------------------+------------+
| Name | Value | Description | Reference | | Name | Value | Description | Reference |
+--------+-------+-------------------------------------+------------+ +--------+-------+-------------------------------------+------------+
| 6TiSCH | 0 | The pledge requests to play the | [[this | | 6TiSCH | 0 | The pledge requests to play the | [[this |
| Node | | role of a regular 6TiSCH node, i.e. | document]] | | Node | | role of a regular 6TiSCH node, i.e. | document]] |
| | | non-6LBR node. | | | | | non-6LBR node. | |
| | | | | | | | | |
| 6LBR | 1 | The pledge requests to play the | [[this | | 6LBR | 1 | The pledge requests to play the | [[this |
| | | role of 6LoWPAN Border Router | document]] | | | | role of 6LoWPAN Border Router | document]] |
| | | (6LBR). | | | | | (6LBR). | |
skipping to change at page 26, line 16 skipping to change at page 26, line 50
+--------+-------+-------------------------------------+------------+ +--------+-------+-------------------------------------+------------+
| 6TiSCH | 0 | The pledge requests to play the | [[this | | 6TiSCH | 0 | The pledge requests to play the | [[this |
| Node | | role of a regular 6TiSCH node, i.e. | document]] | | Node | | role of a regular 6TiSCH node, i.e. | document]] |
| | | non-6LBR node. | | | | | non-6LBR node. | |
| | | | | | | | | |
| 6LBR | 1 | The pledge requests to play the | [[this | | 6LBR | 1 | The pledge requests to play the | [[this |
| | | role of 6LoWPAN Border Router | document]] | | | | role of 6LoWPAN Border Router | document]] |
| | | (6LBR). | | | | | (6LBR). | |
+--------+-------+-------------------------------------+------------+ +--------+-------+-------------------------------------+------------+
Table 1: Role values. Table 2: Role values.
8.4.2. Configuration Object 8.4.2. Configuration Object
The Configuration structure is built on a CBOR map object. The set The Configuration structure is built on a CBOR map object. The set
of parameters that can appear in a Configuration object is summarized of parameters that can appear in a Configuration object is summarized
below. The labels can be found in "CoJP Parameters" registry below. The labels can be found in "CoJP Parameters" registry
Section 11.1. Section 11.1.
o link-layer key set: An array encompassing a set of cryptographic o link-layer key set: An array encompassing a set of cryptographic
keys and their identifiers that are currently in use in the keys and their identifiers that are currently in use in the
network, or that are scheduled to be used in the future. The network, or that are scheduled to be used in the future. The
encoding of individual keys is described in Section 8.4.3. The encoding of individual keys is described in Section 8.4.3. The
link-layer key set parameter MAY be included in a Configuration link-layer key set parameter MAY be included in a Configuration
object. When present, the link-layer key set parameter MUST object. When present, the link-layer key set parameter MUST
contain at least one key. When a pledge is joining for the first contain at least one key. This parameter is also used to
time and receives this parameter, before sending the first implement rekeying in the network. How the keys are installed and
outgoing frame secured with a received key, the pledge needs to used differs for the 6LBR and other (regular) nodes, and this is
successfully complete the security processing of an incoming explained in Section 8.4.3.1 and Section 8.4.3.2.
frame. To do so, the pledge can wait to receive a new frame, or
it can store an EB frame that it used to find the JP and use it
for immediate security processing upon reception of the key set.
This parameter is also used to implement rekeying in the network.
How the keys are installed and used differs for the 6LBR and other
(regular) nodes, and this is explained in Section 8.4.3.1 and
Section 8.4.3.2.
o short identifier: a compact identifier assigned to the pledge. o short identifier: a compact identifier assigned to the pledge.
The short identifier structure is described in Section 8.4.4. The The short identifier structure is described in Section 8.4.4. The
short identifier parameter MAY be included in a Configuration short identifier parameter MAY be included in a Configuration
object. object.
o JRC address: the IPv6 address of the JRC, encoded as a byte o JRC address: the IPv6 address of the JRC, encoded as a byte
string, with the length of 16 bytes. If the length of the byte string, with the length of 16 bytes. If the length of the byte
string is different from 16, the parameter MUST be discarded. If string is different from 16, the parameter MUST be discarded. If
the JRC is not co-located with the 6LBR and has a different IPv6 the JRC is not co-located with the 6LBR and has a different IPv6
skipping to change at page 27, line 25 skipping to change at page 28, line 4
Configuration object. When present, the array MUST contain zero Configuration object. When present, the array MUST contain zero
or more byte strings encoding pledge identifiers. The joined node or more byte strings encoding pledge identifiers. The joined node
MUST silently drop any link-layer frames originating from the MUST silently drop any link-layer frames originating from the
pledge identifiers enclosed in the blacklist parameter. When this pledge identifiers enclosed in the blacklist parameter. When this
parameter is received, its value MUST overwrite any previously set parameter is received, its value MUST overwrite any previously set
values. This parameter allows the JRC to configure the node values. This parameter allows the JRC to configure the node
acting as a JP to filter out traffic from misconfigured or acting as a JP to filter out traffic from misconfigured or
malicious pledges before their traffic is forwarded into the malicious pledges before their traffic is forwarded into the
network. If the JRC decides to remove a given pledge identifier network. If the JRC decides to remove a given pledge identifier
from a blacklist, it omits the pledge identifier in the blacklist from a blacklist, it omits the pledge identifier in the blacklist
parameter value it sends next. parameter value it sends next. Since the blacklist parameter
carries the pledge identifiers, privacy considerations apply. See
Section 10.
o join rate: Average data rate of join traffic forwarded into the o join rate: Average data rate (in units of bytes/second) of join
network that should not be exceeded when a joined node operates as traffic forwarded into the network that should not be exceeded
a JP, encoded as an unsigned integer in bytes per second. The when a joined node operates as a JP, encoded as an unsigned
join rate parameter MAY be included in a Configuration object. integer. The join rate parameter MAY be included in a
This parameter allows the JRC to configure different nodes in the Configuration object. This parameter allows the JRC to configure
network to operate as JP, and act in case of an attack by different nodes in the network to operate as JP, and act in case
throttling the rate at which JP forwards unauthenticated traffic of an attack by throttling the rate at which JP forwards
into the network. When this parameter is present in a unauthenticated traffic into the network. When this parameter is
Configuration object, the value MUST be used to set the present in a Configuration object, the value MUST be used to set
PROBING_RATE of CoAP at the joined node for communication with the the PROBING_RATE of CoAP at the joined node for communication with
JRC. In case this parameter is set to zero, a joined node MUST the JRC. In case this parameter is set to zero, a joined node
silently drop any join traffic coming from unauthenticated MUST silently drop any join traffic coming from unauthenticated
pledges. In case this parameter is omitted, the value of positive pledges. In case this parameter is omitted, the value of positive
infinity SHOULD be assumed. Node operating as a JP MAY use infinity SHOULD be assumed. Node operating as a JP MAY use
another mechanism that is out of scope of this specification to another mechanism that is out of scope of this specification to
configure PROBING_RATE of CoAP in the absence of join rate configure PROBING_RATE of CoAP in the absence of a join rate
parameter from the Configuration object. parameter from the Configuration object.
Table 3 summarizes the parameters that may appear in a Configuration
object.
+--------------------+-------+------------------+
| Name | Label | CBOR Type |
+--------------------+-------+------------------+
| link-layer key set | 2 | array |
| | | |
| short identifier | 3 | array |
| | | |
| JRC address | 4 | byte string |
| | | |
| blacklist | 6 | array |
| | | |
| join rate | 7 | unsigned integer |
+--------------------+-------+------------------+
Table 3: Summary of Configuration parameters.
The CDDL fragment that represents the text above for the The CDDL fragment that represents the text above for the
Configuration follows. Structures Link_Layer_Key and Configuration follows. Structures Link_Layer_Key and
Short_Identifier are specified in Section 8.4.3 and Section 8.4.4. Short_Identifier are specified in Section 8.4.3 and Section 8.4.4.
Configuration = { Configuration = {
? 2 : [ +Link_Layer_Key ], ; link-layer key set ? 2 : [ +Link_Layer_Key ], ; link-layer key set
? 3 : Short_Identifier, ; short identifier ? 3 : Short_Identifier, ; short identifier
? 4 : bstr, ; JRC address ? 4 : bstr, ; JRC address
? 6 : [ *bstr ], ; blacklist ? 6 : [ *bstr ], ; blacklist
? 7 : uint ; join rate ? 7 : uint ; join rate
skipping to change at page 29, line 45 skipping to change at page 30, line 45
| join rate | 7 | unsigned | Identifier the | [[this | | join rate | 7 | unsigned | Identifier the | [[this |
| | | integer | join rate | document]] | | | | integer | join rate | document]] |
| | | | parameter | | | | | | parameter | |
| | | | | | | | | | | |
| unsupported | 8 | array | Identifies the | [[this | | unsupported | 8 | array | Identifies the | [[this |
| configuration | | | unsupported | document]] | | configuration | | | unsupported | document]] |
| | | | configuration | | | | | | configuration | |
| | | | parameter | | | | | | parameter | |
+---------------+-------+----------+-------------------+------------+ +---------------+-------+----------+-------------------+------------+
Table 2: CoJP parameters map labels. Table 4: CoJP parameters map labels.
8.4.3. Link-Layer Key 8.4.3. Link-Layer Key
The Link_Layer_Key structure encompasses the parameters needed to The Link_Layer_Key structure encompasses the parameters needed to
configure the link-layer security module: the key identifier; the configure the link-layer security module: the key identifier; the
value of the cryptographic key; the link-layer algorithm identifier value of the cryptographic key; the link-layer algorithm identifier
and the security level and the frame types that it should be used and the security level and the frame types that it should be used
with, both for outgoing and incoming security operations; and any with, both for outgoing and incoming security operations; and any
additional information that may be needed to configure the key. additional information that may be needed to configure the key.
For encoding compactness, the Link_Layer_Key object is not enclosed For encoding compactness, the Link_Layer_Key object is not enclosed
in a top-level CBOR object. Rather, it is transported as a sequence in a top-level CBOR object. Rather, it is transported as a sequence
of CBOR elements, some being optional. of CBOR elements [I-D.ietf-cbor-sequence], some being optional.
The set of parameters that can appear in a Link_Layer_Key object is The set of parameters that can appear in a Link_Layer_Key object is
summarized below, in order: summarized below, in order:
o key_id: The identifier of the key, encoded as a CBOR unsigned o key_id: The identifier of the key, encoded as a CBOR unsigned
integer. This parameter MUST be included. If the decoded CBOR integer. This parameter MUST be included. If the decoded CBOR
unsigned integer value is larger than the maximum link-layer key unsigned integer value is larger than the maximum link-layer key
identifier, the key is considered invalid. In case the key is identifier, the key is considered invalid. In case the key is
considered invalid, the key MUST be discarded and the considered invalid, the key MUST be discarded and the
implementation MUST signal the error as specified in implementation MUST signal the error as specified in
Section 8.3.1. Section 8.3.1.
o key_usage: The identifier of the link-layer algorithm, security o key_usage: The identifier of the link-layer algorithm, security
level and link-layer frame types that can be used with the key, level and link-layer frame types that can be used with the key,
encoded as an integer. This parameter MAY be included. Possible encoded as an integer. This parameter MAY be included. Possible
values and the corresponding link-layer settings are specified in values and the corresponding link-layer settings are specified in
IANA "CoJP Key Usage" registry (Section 11.2). In case the IANA "CoJP Key Usage" registry (Section 11.2). In case the
parameter is omitted, the default value of 0 from Table 3 MUST be parameter is omitted, the default value of 0 (6TiSCH-K1K2-ENC-
assumed. MIC32) from Table 5 MUST be assumed. This default value has been
chosen such that it results in byte savings in the most
constrained settings but does not imply a recommendation for its
general usage.
o key_value: The value of the cryptographic key, encoded as a byte o key_value: The value of the cryptographic key, encoded as a byte
string. This parameter MUST be included. If the length of the string. This parameter MUST be included. If the length of the
byte string is different than the corresponding key length for a byte string is different than the corresponding key length for a
given algorithm specified by the key_usage parameter, the key MUST given algorithm specified by the key_usage parameter, the key MUST
be discarded and the implementation MUST signal the error as be discarded and the implementation MUST signal the error as
specified in Section 8.3.1. specified in Section 8.3.1.
o key_addinfo: Additional information needed to configure the link- o key_addinfo: Additional information needed to configure the link-
layer key, encoded as a byte string. This parameter MAY be layer key, encoded as a byte string. This parameter MAY be
skipping to change at page 33, line 4 skipping to change at page 34, line 6
| | | | DATA and AC | ] | | | | | DATA and AC | ] |
| | | | KNOWLEDGMEN | | | | | | KNOWLEDGMEN | |
| | | | T. | | | | | | T. | |
| | | | | | | | | | | |
| 6TiSCH-K2-ENC- | 14 | IEEE802154-AES- | Use ENC- | [[this d | | 6TiSCH-K2-ENC- | 14 | IEEE802154-AES- | Use ENC- | [[this d |
| MIC128 | | CCM-128 | MIC-128 for | ocument] | | MIC128 | | CCM-128 | MIC-128 for | ocument] |
| | | | DATA and AC | ] | | | | | DATA and AC | ] |
| | | | KNOWLEDGMEN | | | | | | KNOWLEDGMEN | |
| | | | T. | | | | | | T. | |
+-----------------+-----+------------------+-------------+----------+ +-----------------+-----+------------------+-------------+----------+
Table 3: Key Usage values.
Table 5: Key Usage values.
8.4.3.1. Rekeying of (6LoWPAN) Border Routers (6LBR) 8.4.3.1. Rekeying of (6LoWPAN) Border Routers (6LBR)
When the 6LoWPAN Border Router (6LBR) receives the Configuration When the 6LoWPAN Border Router (6LBR) receives the Configuration
object containing a link-layer key set, it MUST immediately install object containing a link-layer key set, it MUST immediately install
and start using the new keys for all outgoing traffic, and remove any and start using the new keys for all outgoing traffic, and remove any
old keys it has installed from the previous key set after a delay of old keys it has installed from the previous key set after a delay of
COJP_REKEYING_GUARD_TIME has passed. This mechanism is used by the COJP_REKEYING_GUARD_TIME has passed. This mechanism is used by the
JRC to force the 6LBR to start sending traffic with the new key. The JRC to force the 6LBR to start sending traffic with the new key. The
decision is taken by the JRC when it has determined that the new key decision is taken by the JRC when it has determined that the new key
skipping to change at page 33, line 41 skipping to change at page 34, line 44
The detection of network switch is based upon the receipt of traffic The detection of network switch is based upon the receipt of traffic
secured with the new keys. Upon reception and successful security secured with the new keys. Upon reception and successful security
processing of a link-layer frame secured with a key from the new key processing of a link-layer frame secured with a key from the new key
set, a 6LN node MUST then switch to sending outgoing traffic using set, a 6LN node MUST then switch to sending outgoing traffic using
the keys from the new set for all outgoing traffic. The 6LN node the keys from the new set for all outgoing traffic. The 6LN node
MUST remove any old keys it has installed from the previous key set MUST remove any old keys it has installed from the previous key set
after a delay of COJP_REKEYING_GUARD_TIME has passed after it starts after a delay of COJP_REKEYING_GUARD_TIME has passed after it starts
using the new key set. using the new key set.
Sending of traffic with the new keys signals to other downstream Sending of traffic with the new keys signals to other downstream
nodes to switch to their new key, and the affect is that there is a nodes to switch to their new key, and the effect is that there is a
ripple of key updates in outward concentric circles around each 6LBR. ripple of key updates around each 6LBR.
8.4.3.3. Use in IEEE Std 802.15.4 8.4.3.3. Use in IEEE Std 802.15.4
When Link_Layer_Key is used in the context of [IEEE802.15.4], the When Link_Layer_Key is used in the context of [IEEE802.15.4], the
following considerations apply. following considerations apply.
Signaling of different keying modes of [IEEE802.15.4] is done based Signaling of different keying modes of [IEEE802.15.4] is done based
on the parameter values present in a Link_Layer_Key object. on the parameter values present in a Link_Layer_Key object. For
instance, the value of the key_id parameter in combination with
key_addinfo denotes which of the four Key ID modes of [IEEE802.15.4]
is used and how.
o Key ID Mode 0x00 (Implicit, pairwise): key_id parameter MUST be o Key ID Mode 0x00 (Implicit, pairwise): key_id parameter MUST be
set to 0. key_addinfo parameter MUST be present. key_addinfo set to 0. key_addinfo parameter MUST be present. key_addinfo
parameter MUST be set to the link-layer address(es) of a single parameter MUST be set to the link-layer address(es) of a single
peer with whom the key should be used. Depending on the peer with whom the key should be used. Depending on the
configuration of the network, key_addinfo may carry the peer's configuration of the network, key_addinfo may carry the peer's
long link-layer address (i.e. pledge identifier), short link-layer long link-layer address (i.e. pledge identifier), short link-layer
address, or their concatenation with the long address being address, or their concatenation with the long address being
encoded first. Which address is carried is determined from the encoded first. Which address type(s) is carried is determined
length of the byte string. from the length of the byte string.
o Key ID Mode 0x01 (Key Index): key_id parameter MUST be set to a o Key ID Mode 0x01 (Key Index): key_id parameter MUST be set to a
value different than 0. key_addinfo parameter MUST NOT be value different than 0. key_addinfo parameter MUST NOT be present.
present.
o Key ID Mode 0x02 (4-byte Explicit Key Source): key_id parameter o Key ID Mode 0x02 (4-byte Explicit Key Source): key_id parameter
MUST be set to a value different than 0. key_addinfo parameter MUST be set to a value different than 0. key_addinfo parameter
MUST be present. key_addinfo parameter MUST be set to a byte MUST be present. key_addinfo parameter MUST be set to a byte
string, exactly 4 bytes long. key_addinfo parameter carries the string, exactly 4 bytes long. key_addinfo parameter carries the
Key Source parameter used to configure [IEEE802.15.4]. Key Source parameter used to configure [IEEE802.15.4].
o Key ID Mode 0x03 (8-byte Explicit Key Source): key_id parameter o Key ID Mode 0x03 (8-byte Explicit Key Source): key_id parameter
MUST be set to a value different than 0. key_addinfo parameter MUST be set to a value different than 0. key_addinfo parameter
MUST be present. key_addinfo parameter MUST be set to a byte MUST be present. key_addinfo parameter MUST be set to a byte
string, exactly 8 bytes long. key_addinfo parameter carries the string, exactly 8 bytes long. key_addinfo parameter carries the
Key Source parameter used to configure [IEEE802.15.4]. Key Source parameter used to configure [IEEE802.15.4].
In all cases, key_usage parameter determines how a particular key In all cases, key_usage parameter determines how a particular key
should be used in respect to incoming and outgoing security policies. should be used in respect to incoming and outgoing security policies.
For Key ID Modes 0x01 - 0x03, parameter key_id sets the "secKeyIndex" For Key ID Modes 0x01 - 0x03, parameter key_id sets the "secKeyIndex"
parameter of [IEEE802.15.4] that is signaled in all outgoing frames parameter of [IEEE802.15.4] that is signaled in all outgoing frames
secured with a given key. The maximum value key_id can have is 254. secured with a given key. The maximum value key_id can have is 254.
The value of 255 is reserved in [IEEE802.15.4] and is therefore The value of 255 is reserved in [IEEE802.15.4] and is therefore
considered invalid. considered invalid.
skipping to change at page 36, line 28 skipping to change at page 37, line 39
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
the same identifier to another node. the same identifier to another node.
Care needs to be taken on how the pledge (joined node) configures the
expiration of the lease. Since units of the lease_time parameter are
in hours after the reception of the CBOR object, the pledge needs to
convert the received time to the corresponding absolute slot number
in the network. The joined node (pledge) MUST only use the absolute
slot number as the appropriate reference of time to determine whether
the assigned short identifier is still valid.
8.4.5. Unsupported Configuration Object 8.4.5. Unsupported Configuration Object
The Unsupported_Configuration object is encoded as a CBOR array, The Unsupported_Configuration object is encoded as a CBOR array,
containing at least one Unsupported_Parameter object. Each containing at least one Unsupported_Parameter object. Each
Unsupported_Parameter object is a sequence of CBOR elements without Unsupported_Parameter object is a sequence of CBOR elements without
an enclosing top-level CBOR object for compactness. The set of an enclosing top-level CBOR object for compactness. The set of
parameters that appear in an Unsupported_Parameter object is parameters that appear in an Unsupported_Parameter object is
summarized below, in order: summarized below, in order:
o code: Indicates the capability of acting on the parameter signaled o code: Indicates the capability of acting on the parameter signaled
skipping to change at page 37, line 12 skipping to change at page 38, line 30
the code is set to "Unsupported", parameter_addinfo gives the code is set to "Unsupported", parameter_addinfo gives
additional information to the JRC. If the parameter indicated by additional information to the JRC. If the parameter indicated by
parameter_label cannot be acted upon regardless of its value, parameter_label cannot be acted upon regardless of its value,
parameter_addinfo MUST be set to null, signaling to the JRC that parameter_addinfo MUST be set to null, signaling to the JRC that
it SHOULD NOT attempt to configure the parameter again. If the it SHOULD NOT attempt to configure the parameter again. If the
pledge can act on the parameter, but cannot configure the setting pledge can act on the parameter, but cannot configure the setting
indicated by the parameter value, the pledge can hint this to the indicated by the parameter value, the pledge can hint this to the
JRC. In this case, parameter_addinfo MUST be set to the value of JRC. In this case, parameter_addinfo MUST be set to the value of
the parameter that cannot be acted upon following the normative the parameter that cannot be acted upon following the normative
parameter structure specified in this document. For example, it parameter structure specified in this document. For example, it
is possible to include only a subset of the link-layer key set is possible to include the link-layer key set object, signaling a
object, signaling the keys that cannot be acted upon, or the subset of keys that cannot be acted upon, or the entire key set
entire key set that was received. In case the code is set to that was received. In that case, the value of the
"Malformed", parameter_addinfo MUST be set to null, signaling to parameter_addinfo follows the link-layer key set structure defined
the JRC that it SHOULD NOT attempt to configure the parameter in Section 8.4.2. In case the code is set to "Malformed",
again. parameter_addinfo MUST be set to null, signaling to the JRC that
it SHOULD NOT attempt to configure the parameter again.
The CDDL fragment that represents the text above for The CDDL fragment that represents the text above for
Unsupported_Configuration and Unsupported_Parameter objects follows. Unsupported_Configuration and Unsupported_Parameter objects follows.
Unsupported_Configuration = [ Unsupported_Configuration = [
+ parameter : Unsupported_Parameter + parameter : Unsupported_Parameter
] ]
Unsupported_Parameter = ( Unsupported_Parameter = (
code : int, code : int,
skipping to change at page 37, line 43 skipping to change at page 39, line 15
| Name | Value | Description | Reference | | Name | Value | Description | Reference |
+-------------+-------+--------------------------------+------------+ +-------------+-------+--------------------------------+------------+
| Unsupported | 0 | The indicated setting is not | [[this | | Unsupported | 0 | The indicated setting is not | [[this |
| | | supported by the networking | document]] | | | | supported by the networking | document]] |
| | | stack implementation. | | | | | stack implementation. | |
| | | | | | | | | |
| Malformed | 1 | The indicated parameter value | [[this | | Malformed | 1 | The indicated parameter value | [[this |
| | | is malformed. | document]] | | | | is malformed. | document]] |
+-------------+-------+--------------------------------+------------+ +-------------+-------+--------------------------------+------------+
Table 4: Unsupported Configuration code values. Table 6: Unsupported Configuration code values.
8.5. Recommended Settings 8.5. Recommended Settings
This section gives RECOMMENDED values of CoJP settings. This section gives RECOMMENDED values of CoJP settings.
+--------------------------+---------------+ +--------------------------+---------------+
| Name | Default Value | | Name | Default Value |
+--------------------------+---------------+ +--------------------------+---------------+
| COJP_MAX_JOIN_ATTEMPTS | 4 | | COJP_MAX_JOIN_ATTEMPTS | 4 |
| | | | | |
skipping to change at page 38, line 31 skipping to change at page 39, line 47
parameter of OSCORE, an important security requirement is that the parameter of OSCORE, an important security requirement is that the
pledge identifier is unique in the set of all pledge identifiers pledge identifier is unique in the set of all pledge identifiers
managed by a JRC. The uniqueness of the pledge identifier ensures managed by a JRC. The uniqueness of the pledge identifier ensures
unique (key, nonce) pairs for AEAD algorithm used by OSCORE. It also unique (key, nonce) pairs for AEAD algorithm used by OSCORE. It also
allows the JRC to retrieve the correct security context, upon the allows the JRC to retrieve the correct security context, upon the
reception of a Join Request message. The management of pledge reception of a Join Request message. The management of pledge
identifiers is simplified if the globally unique EUI-64 is used, but identifiers is simplified if the globally unique EUI-64 is used, but
this comes with privacy risks, as discussed in Section 10. this comes with privacy risks, as discussed in Section 10.
This document further mandates that the (6LBR) pledge and the JRC are This document further mandates that the (6LBR) pledge and the JRC are
provisioned with unique PSKs. The PSK is used to set the OSCORE provisioned with unique PSKs. While the process of provisioning PSKs
Master Secret during security context derivation. This derivation to all pledges can result in a substantial operational overhead, it
process results in OSCORE keys that are important for mutual is vital to do so for the security properties of the network. The
authentication of the (6LBR) pledge and the JRC. Should an attacker PSK is used to set the OSCORE Master Secret during security context
come to know the PSK, then a man-in-the-middle attack is possible. derivation. This derivation process results in OSCORE keys that are
important for mutual authentication of the (6LBR) pledge and the JRC.
The resulting security context shared between the pledge (joined
node) and the JRC is used for the purpose of joining and is long-
lived in that it can be used throughout the lifetime of a joined node
for parameter update exchanges. Should an attacker 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 Note that while OSCORE provides replay protection, it does not
provisioning PSKs. The use of a single PSK shared among a group of provide an indication of freshness in the presence of an attacker
devices is a common pitfall that results in poor security. In this that can drop/reorder traffic. Since the join request contains no
case, the compromise of a single device is likely to lead to a randomness, and the sequence number is predictable, the JRC could in
principle anticipate a join request from a particular pledge and pre-
calculate the response. In such a scenario, the JRC does not have to
be alive at the time when the request is received. This could be
relevant in case the JRC was temporarily compromised and control
subsequently regained by the legitimate owner.
It is of utmost importance to avoid unsafe practices when generating
and 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 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. Additionally, some bogus data and disturb the network operation. Additionally, some
vendors use methods such as scrambling or hashing of device serial vendors use methods such as scrambling or hashing of device serial
numbers or their EUI-64 to generate "unique" PSKs. Without any numbers or their EUI-64 to generate "unique" PSKs. Without any
secret information involved, the effort that the attacker needs to secret information involved, the effort that the attacker needs to
invest into breaking these unsafe derivation methods is quite low, invest into breaking these unsafe derivation methods is quite low,
resulting in the possible impersonation of any device from the batch, resulting in the possible impersonation of any device from the batch,
without even needing to compromise a single device. The use of without even needing to compromise a single device. The use of
cryptographically secure random number generators to generate the PSK cryptographically secure random number generators to generate the PSK
is RECOMMENDED, see [NIST800-90A] for different mechanisms using is RECOMMENDED, see [NIST800-90A] for different mechanisms using
deterministic methods. 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 and enables throttling in case of an attack. The network can handle and enables throttling in case of an attack. Note
data cap can be configured by the JRC by including a join rate that this traffic can only be directed at the JRC so that the JRC
parameter in the Join Response and it is implemented through the needs to be prepared to handle such unsanitized inputs. The data cap
CoAP's PROBING_RATE setting. The use of a data cap at a JP forces can be configured by the JRC by including a join rate parameter in
attackers to use more than one JP if they wish to overwhelm the the Join Response and it is implemented through the CoAP's
network. Marking the join traffic packets with a non-zero DSCP PROBING_RATE setting. The use of a data cap at a JP forces attackers
allows the network to carry the traffic if it has capacity, but to use more than one JP if they wish to overwhelm the network.
encourages the network to drop the extra traffic rather than add Marking the join traffic packets with a non-zero DSCP allows the
bandwidth due to that traffic. network to carry the traffic if it has capacity, but 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
verifying the content in the EB, and has to accept it at "face verifying the content in the EB, and has to accept it at "face
value". In case the pledge tries to join an attacker's network, the value". In case the pledge tries to join an attacker's network, the
Join Response message will either fail the security check or time Join Response message will either fail the security check or time
out. The pledge may implement a temporary blacklist in order to out. The pledge may implement a temporary blacklist in order to
filter out undesired EBs and try to join using the next seemingly filter out undesired EBs and try to join using the next seemingly
valid EB. This blacklist alleviates the issue, but is effectively valid EB. This blacklist alleviates the issue, but is effectively
limited by the node's available memory. Note that this temporary limited by the node's available memory. Note that this temporary
blacklist is different from the one communicated as part of the CoJP blacklist is different from the one communicated as part of the CoJP
Configuration object as it helps pledge fight a DoS attack. These Configuration object as it helps pledge fight a DoS attack. The
bogus beacons prolong the join time of the pledge, and so the time bogus beacons prolong the join time of the pledge, and so the time
spent in "minimal" [RFC8180] duty cycle mode. The blacklist spent in "minimal" [RFC8180] duty cycle mode. The blacklist
communicated as part of the CoJP Configuration object helps JP fight communicated as part of the CoJP Configuration object helps JP fight
a DoS attack by a malicious pledge. a DoS attack by a malicious pledge.
During the network lifetime, the JRC may at any time initiate a
Parameter Update exchange with a joined node. The Parameter Update
message uses the same OSCORE security context as is used for the join
exchange, except that the server/client roles are interchanged. As a
consequence, each Parameter Update message carries the well-known
OSCORE Sender ID of the JRC. A passive attacker may use the OSCORE
Sender ID to identify the Parameter Update traffic in case the link-
layer protection does not provide confidentiality. A countermeasure
against such traffic analysis attack is to use encryption at the
link-layer. Note that the join traffic does not undergo link-layer
protection at the first hop, as the pledge is not yet in possession
of cryptographic keys. Similarly, enhanced beacon traffic in the
network is not encrypted. This makes it easy for a passive attacker
to identify these types of traffic.
10. Privacy Considerations 10. Privacy Considerations
The join solution specified in this document relies on the uniqueness The join solution specified in this document relies on the uniqueness
of the pledge identifier in the set of all pledge identifiers managed of the pledge identifier in the set of all pledge identifiers managed
by a JRC. This identifier is transferred in clear as an OSCORE kid by a JRC. This identifier is transferred in clear as an OSCORE kid
context. The use of the globally unique EUI-64 as pledge identifier context. The use of the globally unique EUI-64 as pledge identifier
simplifies the management but comes with certain privacy risks. The simplifies the management but comes with certain privacy risks. The
implications are thoroughly discussed in [RFC7721] and comprise implications are thoroughly discussed in [RFC7721] and comprise
correlation of activities over time, location tracking, address correlation of activities over time, location tracking, address
scanning and device-specific vulnerability exploitation. Since the scanning and device-specific vulnerability exploitation. Since the
skipping to change at page 40, line 25 skipping to change at page 42, line 28
non-negligible probability. This probability decreases with an non-negligible probability. This probability decreases with an
increasing number of pledges joining concurrently. increasing number of pledges joining concurrently.
11. IANA Considerations 11. IANA Considerations
Note to RFC Editor: Please replace all occurrences of "[[this Note to RFC Editor: Please replace all occurrences of "[[this
document]]" with the RFC number of this specification. document]]" with the RFC number of this specification.
This document allocates a well-known name under the .arpa name space This document allocates a well-known name under the .arpa name space
according to the rules given in [RFC3172]. The name "6tisch.arpa" is according to the rules given in [RFC3172]. The name "6tisch.arpa" is
requested. No subdomains are expected. No A, AAAA or PTR record is requested. No subdomains are expected, and addition of any such
requested. subdomains requires the publication of an IETF standards-track RFC.
No A, AAAA or PTR record is requested.
11.1. CoJP Parameters Registry 11.1. CoJP Parameters Registry
This section defines a sub-registry within the "IPv6 over the TSCH This section defines a sub-registry within the "IPv6 over the TSCH
mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name
"Constrained Join Protocol Parameters Registry". "Constrained Join Protocol Parameters Registry".
The columns of the registry are: The columns of the registry are:
Name: This is a descriptive name that enables an easier reference to Name: This is a descriptive name that enables an easier reference to
skipping to change at page 40, line 49 skipping to change at page 43, line 5
Label: The value to be used to identify this parameter. The label is Label: The value to be used to identify this parameter. The label is
an integer. an integer.
CBOR type: This field contains the CBOR type for the field. CBOR type: This field contains the CBOR type for the field.
Description: This field contains a brief description for the field. Description: This field contains a brief description for the field.
Reference: This field contains a pointer to the public specification Reference: This field contains a pointer to the public specification
for the field, if one exists. for the field, if one exists.
This registry is to be populated with the values in Table 2. This registry is to be populated with the values in Table 4.
The amending formula for this sub-registry is: Different ranges of The amending formula for this sub-registry is: Different ranges of
values use different registration policies [RFC8126]. Integer values values use different registration policies [RFC8126]. Integer values
from -256 to 255 are designated as Standards Action. Integer values from -256 to 255 are designated as Standards Action. Integer values
from -65536 to -257 and from 256 to 65535 are designated as from -65536 to -257 and from 256 to 65535 are designated as
Specification Required. Integer values greater than 65535 are Specification Required. Integer values greater than 65535 are
designated as Expert Review. Integer values less than -65536 are designated as Expert Review. Integer values less than -65536 are
marked as Private Use. marked as Private Use.
11.2. CoJP Key Usage Registry 11.2. CoJP Key Usage Registry
skipping to change at page 41, line 39 skipping to change at page 43, line 41
the encoding. the encoding.
Description: This field contains a description of the key usage Description: This field contains a description of the key usage
setting. The field should describe in enough detail how the key is setting. The field should describe in enough detail how the key is
to be used with different frame types, specific for the link-layer to be used with different frame types, specific for the link-layer
technology in question. technology in question.
Reference: This contains a pointer to the public specification for Reference: This contains a pointer to the public specification for
the field, if one exists. the field, if one exists.
This registry is to be populated with the values in Table 3. This registry is to be populated with the values in Table 5.
The amending formula for this sub-registry is: Different ranges of The amending formula for this sub-registry is: Different ranges of
values use different registration policies [RFC8126]. Integer values values use different registration policies [RFC8126]. Integer values
from -256 to 255 are designated as Standards Action. Integer values from -256 to 255 are designated as Standards Action. Integer values
from -65536 to -257 and from 256 to 65535 are designated as from -65536 to -257 and from 256 to 65535 are designated as
Specification Required. Integer values greater than 65535 are Specification Required. Integer values greater than 65535 are
designated as Expert Review. Integer values less than -65536 are designated as Expert Review. Integer values less than -65536 are
marked as Private Use. marked as Private Use.
11.3. CoJP Unsupported Configuration Code Registry 11.3. CoJP Unsupported Configuration Code Registry
skipping to change at page 42, line 25 skipping to change at page 44, line 25
Value: This is the value used to identify the diagnostic code. These Value: This is the value used to identify the diagnostic code. These
values MUST be unique. The value is an integer. values MUST be unique. The value is an integer.
Description: This is a descriptive human-readable name. The Description: This is a descriptive human-readable name. The
description MUST be unique. It is not used in the encoding. description MUST be unique. It is not used in the encoding.
Reference: This contains a pointer to the public specification for Reference: This contains a pointer to the public specification for
the field, if one exists. the field, if one exists.
This registry is to be populated with the values in Table 4. This registry is to be populated with the values in Table 6.
The amending formula for this sub-registry is: Different ranges of The amending formula for this sub-registry is: Different ranges of
values use different registration policies [RFC8126]. Integer values values use different registration policies [RFC8126]. Integer values
from -256 to 255 are designated as Standards Action. Integer values from -256 to 255 are designated as Standards Action. Integer values
from -65536 to -257 and from 256 to 65535 are designated as from -65536 to -257 and from 256 to 65535 are designated as
Specification Required. Integer values greater than 65535 are Specification Required. Integer values greater than 65535 are
designated as Expert Review. Integer values less than -65536 are designated as Expert Review. Integer values less than -65536 are
marked as Private Use. marked as Private Use.
12. Acknowledgments 12. Acknowledgments
skipping to change at page 43, line 6 skipping to change at page 45, 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-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-28 (work
in progress), October 2019.
[I-D.ietf-core-stateless]
Hartke, K., "Extended Tokens and Stateless Clients in the
Constrained Application Protocol (CoAP)", draft-ietf-core-
stateless-03 (work in progress), October 2019.
[IEEE802.15.4]
IEEE standard for Information Technology, ., "IEEE Std
802.15.4 Standard for Low-Rate Wireless Networks", n.d..
[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 43, line 30 skipping to change at page 45, line 44
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[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>.
[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190,
RFC 7320, DOI 10.17487/RFC7320, July 2014,
<https://www.rfc-editor.org/info/rfc7320>.
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement", RFC 7554,
DOI 10.17487/RFC7554, May 2015,
<https://www.rfc-editor.org/info/rfc7554>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<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>.
[RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal
IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH)
Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180,
May 2017, <https://www.rfc-editor.org/info/rfc8180>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-6tisch-architecture] [I-D.ietf-anima-grasp]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Bormann, C., Carpenter, B., and B. Liu, "A Generic
of IEEE 802.15.4", draft-ietf-6tisch-architecture-27 (work Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
in progress), October 2019. grasp-15 (work in progress), July 2017.
[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-cbor-sequence]
Hartke, K., "Extended Tokens and Stateless Clients in the Bormann, C., "Concise Binary Object Representation (CBOR)
Constrained Application Protocol (CoAP)", draft-ietf-core- Sequences", draft-ietf-cbor-sequence-02 (work in
stateless-02 (work in progress), October 2019. progress), September 2019.
[IEEE802.15.4]
IEEE standard for Information Technology, ., "IEEE Std
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.
[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
RFC 4231, DOI 10.17487/RFC4231, December 2005, RFC 4231, DOI 10.17487/RFC4231, December 2005,
<https://www.rfc-editor.org/info/rfc4231>. <https://www.rfc-editor.org/info/rfc4231>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>. <https://www.rfc-editor.org/info/rfc4944>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785,
DOI 10.17487/RFC5785, April 2010,
<https://www.rfc-editor.org/info/rfc5785>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>. <https://www.rfc-editor.org/info/rfc5869>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the DOI 10.17487/RFC6762, February 2013,
Internet of Things (IoT): Problem Statement", RFC 7554, <https://www.rfc-editor.org/info/rfc6762>.
DOI 10.17487/RFC7554, May 2015,
<https://www.rfc-editor.org/info/rfc7554>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>. <https://www.rfc-editor.org/info/rfc7721>.
[RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Richardson, M., Jiang, S., Lemon, T., and T. Winters,
Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
May 2017, <https://www.rfc-editor.org/info/rfc8180>. RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH
Operation Sublayer (6top) Protocol (6P)", RFC 8480, Operation Sublayer (6top) Protocol (6P)", RFC 8480,
DOI 10.17487/RFC8480, November 2018, DOI 10.17487/RFC8480, November 2018,
<https://www.rfc-editor.org/info/rfc8480>. <https://www.rfc-editor.org/info/rfc8480>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>.
Appendix A. Example Appendix A. Example
Figure 3 illustrates a successful join protocol exchange. The pledge Figure 3 illustrates a successful join protocol exchange. The pledge
instantiates the OSCORE context and derives the OSCORE keys and instantiates the OSCORE context and derives the OSCORE keys and
nonces from the PSK. It uses the instantiated context to protect the nonces from the PSK. It uses the instantiated context to protect the
Join Request addressed with a Proxy-Scheme option, the well-known Join Request addressed with a Proxy-Scheme option, the well-known
host name of the JRC in the Uri-Host option, and its EUI-64 as pledge host name of the JRC in the Uri-Host option, and its EUI-64 as pledge
identifier and OSCORE kid context. Triggered by the presence of a identifier and OSCORE kid context. Triggered by the presence of a
Proxy-Scheme option, the JP forwards the request to the JRC and sets Proxy-Scheme option, the JP forwards the request to the JRC and sets
the CoAP token to the internally needed state. The JP has learned the CoAP token to the internally needed state. The JP has learned
skipping to change at page 46, line 11 skipping to change at page 48, line 42
network. Once the JRC receives the request, it looks up the correct network. Once the JRC receives the request, it looks up the correct
context based on the kid context parameter. The OSCORE data context based on the kid context parameter. The OSCORE data
authenticity verification ensures that the request has not been authenticity verification ensures that the request has not been
modified in transit. In addition, replay protection is ensured modified in transit. In addition, replay protection is ensured
through persistent handling of mutable context parameters. through persistent handling of mutable context parameters.
Once the JP receives the Join Response, it authenticates the state Once the JP receives the Join Response, it authenticates the state
within the CoAP token before deciding where to forward. The JP sets within the CoAP token before deciding where to forward. The JP sets
its internal state to that found in the token, and forwards the Join its internal state to that found in the token, and forwards the Join
Response to the correct pledge. Note that the JP does not possess Response to the correct pledge. Note that the JP does not possess
the key to decrypt the CBOR object (configuration) present in the the key to decrypt the CoJP object (configuration) present in the
payload. The Join Response is matched to the Join Request and payload. The Join Response is matched to the Join Request and
verified for replay protection at the pledge using OSCORE processing verified for replay protection at the pledge using OSCORE processing
rules. In this example, the Join Response does not contain the IPv6 rules. In this example, the Join Response does not contain the IPv6
address of the JRC, the pledge hence understands the JRC is co- address of the JRC, the pledge hence understands the JRC is co-
located with the 6LBR. located with the 6LBR.
<---E2E OSCORE--> <---E2E OSCORE-->
Client Proxy Server Client Proxy Server
Pledge JP JRC Pledge JP JRC
| | | | | |
skipping to change at page 49, line 17 skipping to change at page 51, line 17
unique as long as the input for different pledges varies. This unique as long as the input for different pledges varies. This
specification ensures the uniqueness by mandating unique pledge specification ensures the uniqueness by mandating unique pledge
identifiers and a unique PSK for each (6LBR) pledge. From the AEAD identifiers and a unique PSK for each (6LBR) pledge. From the AEAD
nonce reuse viewpoint, having a unique pledge identifier is a nonce reuse viewpoint, having a unique pledge identifier is a
sufficient condition. However, as discussed in Section 9, the use of sufficient condition. However, as discussed in Section 9, the use of
a single PSK shared among many devices is a common security pitfall. a single PSK shared among many devices is a common security pitfall.
The compromise of this shared PSK on a single device would lead to The compromise of this shared PSK on a single device would lead to
the compromise of the entire batch. When using the implementation/ the compromise of the entire batch. When using the implementation/
deployment scheme outlined above, the PSK does not need to be written deployment scheme outlined above, the PSK does not need to be written
to individual pledges. As a consequence, even if a shared PSK is to individual pledges. As a consequence, even if a shared PSK is
used, the scheme offers the same level of security as in the scenario used, the scheme offers a comparable level of security as in the
where each pledge is provisioned with a unique PSK. scenario where each pledge is provisioned with a unique PSK. In this
case, there is still a latent risk of the shared PSK being
compromised from the provisioning device, which would compromise all
devices in the batch.
Authors' Addresses Authors' Addresses
Malisa Vucinic (editor) Malisa Vucinic (editor)
Inria Inria
2 Rue Simone Iff 2 Rue Simone Iff
Paris 75012 Paris 75012
France France
Email: malisa.vucinic@inria.fr Email: malisa.vucinic@inria.fr
 End of changes. 98 change blocks. 
305 lines changed or deleted 443 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/