draft-ietf-6tisch-minimal-security-05.txt   draft-ietf-6tisch-minimal-security-06.txt 
6TiSCH Working Group M. Vucinic, Ed. 6TiSCH Working Group M. Vucinic, Ed.
Internet-Draft University of Montenegro Internet-Draft University of Montenegro
Intended status: Standards Track J. Simon Intended status: Standards Track J. Simon
Expires: September 6, 2018 Analog Devices Expires: November 26, 2018 Analog Devices
K. Pister K. Pister
University of California Berkeley University of California Berkeley
M. Richardson M. Richardson
Sandelman Software Works Sandelman Software Works
March 05, 2018 May 25, 2018
Minimal Security Framework for 6TiSCH Minimal Security Framework for 6TiSCH
draft-ietf-6tisch-minimal-security-05 draft-ietf-6tisch-minimal-security-06
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 a short link-layer address. This link-layer keying material and other parameters. The JRC may at any
specification defines the message format, a new Stateless-Proxy CoAP time update the parameters through another request-response exchange
option, and configures the rest of the 6TiSCH communication stack for secured by OSCORE. This specification defines the Constrained Join
this join process to occur in a secure manner. Additional security Protocol and its CBOR (Concise Binary Object Representation) data
mechanisms may be added on top of this minimal framework. structures, a new Stateless-Proxy CoAP option, and configures the
rest of the 6TiSCH communication stack for this join process to occur
in a secure 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 http://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 November 26, 2018.
This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. One-Touch Assumption . . . . . . . . . . . . . . . . . . . . 5 4. One-Touch Assumption . . . . . . . . . . . . . . . . . . . . 5
5. Join Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Join Process Overview . . . . . . . . . . . . . . . . . . . . 7
5.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 7 5.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 8
5.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 7 5.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 9
5.3. Step 3 - Join Request . . . . . . . . . . . . . . . . . . 8 5.3. Step 3 - Constrained Join Protocol (CoJP) Execution . . . 9
5.4. Step 4 - Join Response . . . . . . . . . . . . . . . . . 8 5.4. The Special Case of the 6LBR Pledge Joining . . . . . . . 10
6. Link-layer Configuration . . . . . . . . . . . . . . . . . . 9 6. Link-layer Configuration . . . . . . . . . . . . . . . . . . 10
7. Network-layer Configuration . . . . . . . . . . . . . . . . . 9 7. Network-layer Configuration . . . . . . . . . . . . . . . . . 10
7.1. Identification of Join Request Traffic . . . . . . . . . 10 7.1. Identification of Join Request Traffic . . . . . . . . . 11
7.2. Identification of Join Response Traffic . . . . . . . . . 11 7.2. Identification of Join Response Traffic . . . . . . . . . 12
8. Application-level Configuration . . . . . . . . . . . . . . . 11 8. Application-level Configuration . . . . . . . . . . . . . . . 12
8.1. OSCORE Security Context . . . . . . . . . . . . . . . . . 12 8.1. OSCORE Security Context . . . . . . . . . . . . . . . . . 13
9. 6TiSCH Join Protocol . . . . . . . . . . . . . . . . . . . . 13 9. Constrained Join Protocol (CoJP) . . . . . . . . . . . . . . 15
9.1. Specification of the Join Request . . . . . . . . . . . . 14 9.1. Join Exchange . . . . . . . . . . . . . . . . . . . . . . 16
9.2. Specification of the Join Response . . . . . . . . . . . 15 9.2. Parameter Update Exchange . . . . . . . . . . . . . . . . 18
9.3. Error Handling and Retransmission . . . . . . . . . . . . 17 9.3. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 19
9.4. Rekeying and Rejoining . . . . . . . . . . . . . . . . . 18 9.4. Parameters . . . . . . . . . . . . . . . . . . . . . . . 27
9.5. Parameters . . . . . . . . . . . . . . . . . . . . . . . 18 9.5. Mandatory to Implement Algorithms . . . . . . . . . . . . 28
9.6. Mandatory to Implement Algorithms . . . . . . . . . . . . 18 10. Stateless-Proxy CoAP Option . . . . . . . . . . . . . . . . . 28
10. Stateless-Proxy CoAP Option . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29
11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 13.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 31
13.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 21 13.2. CoJP Parameters Registry . . . . . . . . . . . . . . . . 31
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 13.3. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 31
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
15.1. Normative References . . . . . . . . . . . . . . . . . . 22 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
15.2. Informative References . . . . . . . . . . . . . . . . . 23 15.1. Normative References . . . . . . . . . . . . . . . . . . 33
15.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
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 this document therefore keeps the number of over-the-air exchanges
for join purposes to a minimum. for join purposes to a minimum.
skipping to change at page 3, line 28 skipping to change at page 3, line 30
The micro-controllers at the heart of 6TiSCH nodes have a small The micro-controllers at the heart of 6TiSCH nodes have a small
amount of code memory. It is therefore paramount to reuse existing amount of code memory. It is therefore paramount to reuse existing
protocols available as part of the 6TiSCH stack. At the application protocols available as part of the 6TiSCH stack. At the application
layer, the 6TiSCH stack already relies on CoAP [RFC7252] for web layer, the 6TiSCH stack already relies on CoAP [RFC7252] for web
transfer, and on OSCORE [I-D.ietf-core-object-security] for its end- transfer, and on OSCORE [I-D.ietf-core-object-security] for its end-
to-end security. The secure join solution defined in this document to-end security. The secure join solution defined in this document
therefore reuses those two protocols as its building blocks. therefore reuses those two protocols as its building blocks.
This document defines a secure join solution for a new device, called This document defines a secure join solution for a new device, called
"pledge", to securely join a 6TiSCH network. The specification "pledge", to securely join a 6TiSCH network. The specification
defines a 6TiSCH Join Protocol (6JP) used by the pledge to request defines the Constrained Join Protocol (CoJP) used by the pledge to
admission into a network managed by the JRC, and for the JRC to request admission into a network managed by the JRC, and for the JRC
configure the pledge with the necessary parameters, a new CoAP to configure the pledge with the necessary parameters and update them
option, and configures different layers of the 6TiSCH protocol stack at a later time, a new CoAP option, and configures different layers
for the join process to occur in a secure manner. of the 6TiSCH protocol stack for the join process to occur in a
secure manner.
It assumes the presence of a JRC (join registrar/coordinator), a The Constrained Join Protocol defined in this document is generic and
central entity. It further assumes that the pledge and the JRC share can be used as-is in modes of IEEE Std 802.15.4 other than TSCH, that
a symmetric key, called PSK (pre-shared key). The PSK is used to 6TiSCH is based on. The Constrained Join Protocol may as well be
configure OSCORE to provide a secure channel to 6JP. How the PSK is used in other (low-power) networking technologies where efficiency in
installed is out of scope of this document. terms of communication overhead and code footprint is important. In
such a case, it may be necessary to register configuration parameters
specific to the technology in question, through the IANA process.
The overall join process described in Section 5 and the configuration
of the stack is, however, specific to 6TiSCH.
The Constrained Join Protocol assumes the presence of a JRC (join
registrar/coordinator), a central entity. It further assumes that
the pledge and the JRC share a symmetric key, called PSK (pre-shared
key). The PSK is used to configure OSCORE to provide a secure
channel to CoJP. How the PSK is installed is out of scope of this
document: this may happen through the one-touch provisioning process
or by a key exchange protocol that may precede the execution of the
6TiSCH Join protocol.
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-2015]. The pledge then exchanges messages with the [IEEE802.15.4]. The pledge then exchanges messages with the JRC;
JRC; these messages can be forwarded by nodes already part of the these messages can be forwarded by nodes already part of the 6TiSCH
6TiSCH network. The messages exchanged allow the JRC and the pledge network. The messages exchanged allow the JRC and the pledge to
to mutually authenticate, based on the PSK. They also allow the JRC mutually authenticate, based on the PSK. They also allow the JRC to
to configure the pledge with link-layer keying material and a short configure the pledge with link-layer keying material, link-layer
link-layer address. After this secure join process successfully short address and other parameters. After this secure join process
completes, the joined node can interact with its neighbors to request successfully completes, the joined node can interact with its
additional bandwidth using the 6top Protocol neighbors to request additional bandwidth using the 6top Protocol
[I-D.ietf-6tisch-6top-protocol] and start sending the application [I-D.ietf-6tisch-6top-protocol] and start sending the application
traffic. 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. These document are to be interpreted as described in [RFC2119]. These
words may also appear in this document in lowercase, absent their words may also appear in this document in lowercase, absent their
normative meanings. normative meanings.
The reader is expected to be familiar with the terms and concepts The reader is expected to be familiar with the terms and concepts
defined in [I-D.ietf-6tisch-terminology], [RFC7252], defined in [I-D.ietf-6tisch-terminology], [RFC7252],
[I-D.ietf-core-object-security], and [RFC8152]. [I-D.ietf-core-object-security], and [RFC8152].
The specification also includes a set of informative examples using The specification also includes a set of informative specifications
the CBOR diagnostic notation [I-D.ietf-cbor-cddl]. using the Concise data definition language (CDDL)
[I-D.ietf-cbor-cddl].
The following terms defined in [I-D.ietf-6tisch-terminology] are used The following terms defined in [I-D.ietf-6tisch-terminology] are used
extensively throughout this document: extensively throughout this document:
o pledge o pledge
o joined node o joined node
o join proxy (JP) o join proxy (JP)
skipping to change at page 4, line 34 skipping to change at page 5, line 4
o joined node o joined node
o join proxy (JP) o join proxy (JP)
o join registrar/coordinator (JRC) o join registrar/coordinator (JRC)
o enhanced beacon (EB) o enhanced beacon (EB)
o join protocol o join protocol
o join process o join process
The following terms defined in [RFC6775] are also used throughout
this document:
o 6LoWPAN Border Router (6LBR)
The term "6LBR" is used interchangeably with the term "DODAG root"
defined in [RFC6550], assuming the two entities are co-located, as
recommended by [I-D.ietf-6tisch-architecture].
The term "pledge", as used throughout the document, explicitly
denotes non-6LBR devices attempting to join over an 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 interface is explicitly
denoted as the "6LBR pledge". When the text equally applies to the
pledge and the 6LBR pledge, the "(6LBR) pledge" form is used.
In addition, we use the generic terms "network identifier" and In addition, we use the generic terms "network identifier" and
"pledge identifier". See Section 3. "pledge identifier". See Section 3.
3. Identifiers 3. Identifiers
The "network identifier" uniquely identifies the 6TiSCH network in The "network identifier" uniquely identifies the 6TiSCH network in
the namespace managed by a JRC. Typically, this is the 16-bit the namespace managed by a JRC. Typically, this is the 16-bit
Personal Area Network Identifier (PAN ID) defined in Personal Area Network Identifier (PAN ID) defined in [IEEE802.15.4].
[IEEE802.15.4-2015]. Companion documents can specify the use of a Companion documents can specify the use of a different network
different network identifier for join purposes, but this is out of identifier for join purposes, but this is out of scope of this
scope of this specification. Such identifier needs to be carried specification. Such identifier needs to be carried within Enhanced
within Enhanced Beacon (EB) frames. Beacon (EB) frames.
The "pledge identifier" uniquely identifies the pledge in the The "pledge identifier" uniquely identifies the (6LBR) pledge in the
namespace managed by a JRC. The pledge identifier is typically the namespace managed by a JRC. The pledge identifier is typically the
globally unique 64-bit Extended Unique Identifier (EUI-64) of the globally unique 64-bit Extended Unique Identifier (EUI-64) of the
IEEE 802.15.4 device. This identifier is used to generate the IPv6 IEEE Std 802.15.4 device. This identifier is used to generate the
addresses of the pledge and to identify it during the execution of IPv6 addresses of the (6LBR) pledge and to identify it during the
the join protocol. For privacy reasons, it is possible to use an execution of the join protocol. For privacy reasons, it is possible
identifier different from the EUI-64 (e.g. a random string). See to use an identifier different from the EUI-64 (e.g. a random
Section 12. string). See Section 12.
4. One-Touch Assumption 4. One-Touch Assumption
This document assumes a one-touch scenario. The pledge is This document assumes a one-touch scenario. The (6LBR) pledge is
provisioned with certain parameters before attempting to join the provisioned with certain parameters before attempting to join the
network, and the same parameters are provisioned to the JRC. network, and the same parameters are provisioned to the JRC.
There are many ways by which this provisioning can be done. There are many ways by which this provisioning can be done.
Physically, the parameters can be written into the pledge using a Physically, the parameters can be written into the (6LBR) pledge
number of mechanisms, such as a JTAG interface, a serial (craft) using a number of mechanisms, such as a JTAG interface, a serial
console interface, pushing buttons simultaneously on different (craft) console interface, pushing buttons simultaneously on
devices, over-the-air configuration in a Faraday cage, etc. The different devices, over-the-air configuration in a Faraday cage, etc.
provisioning can be done by the vendor, the manufacturer, the The provisioning can be done by the vendor, the manufacturer, the
integrator, etc. integrator, etc.
Details of how this provisioning is done is out of scope of this Details of how this provisioning is done is out of scope of this
document. What is assumed is that there can be a secure, private document. What is assumed is that there can be a secure, private
conversation between the JRC and the pledge, and that the two devices conversation between the JRC and the (6LBR) pledge, and that the two
can exchange the parameters. devices can exchange the parameters.
Parameters that are provisioned to the pledge include: Parameters that are provisioned to the (6LBR) pledge include:
o Pre-Shared Key (PSK). The JRC additionally needs to store the o Pre-Shared Key (PSK). The JRC additionally needs to store the
identifier of the pledge bound to the given PSK. The PSK SHOULD pledge identifier bound to the given PSK. The PSK SHOULD be at
be at least 128 bits in length, generated uniformly at random. It least 128 bits in length, generated uniformly at random. It is
is RECOMMENDED to generate the PSK with a cryptographically secure RECOMMENDED to generate the PSK with a cryptographically secure
pseudorandom number generator. Each pledge SHOULD be provisioned pseudorandom number generator. Each (6LBR) pledge SHOULD be
with a unique PSK. provisioned with a unique PSK.
o Optionally, a network identifier. Provisioning the network o Optionally, a network identifier. Provisioning the network
identifier to the pledge is RECOMMENDED, as it significantly identifier is RECOMMENDED. However, due to the operational
speeds up the join process. In case this parameter is not constraints the network identifier may not be known at the time
provisioned, the pledge attempts to join one network at a time. when the provisioning is done. In case this parameter is not
provisioned to the pledge, the pledge attempts to join one network
at a time, which significantly prolongs the join process. In case
this parameter is not provisioned to the 6LBR pledge, the 6LBR
pledge can receive it from the JRC as part of the join protocol.
o Optionally, any non-default algorithms. Mandatory to implement o Optionally, any non-default algorithms. The default algorithms
and default algorithms are specified in Section 9.6. are specified in Section 9.5. When algorithm identifiers are not
exchanged, the use of these default algorithms is implied.
5. Join Overview Additionally, the 6LBR pledge that is not co-located with the JRC
needs to be provisioned with:
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 may also obtain the IPv6 address of the JRC through other
available mechanisms, such as DHCPv6, GRASP, mDNS, the use of
which is out of scope of this document. Pledges do not need to be
provisioned with this address as they discover it dynamically
during the join process.
5. 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-2015]. 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 plays the role of join proxy (JP) node sending the beacons, which plays the role of Join Proxy (JP)
for the pledge, and when it can expect to receive a frame. for the 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 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 join proxy (JP). it to the JP using Neighbor Discovery. This step may be omitted
if the link-local address has been derived from a 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 directed to identify itself to the network. The Join Request is forwarded to
the JRC, which may be co-located on the JP or another device. 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 JRC (via the JP) that sets up one receives a Join Response from the JRC (via the JP). The Join
or more link-layer keys used to authenticate and encrypt Response contains configuration parameters necessary for the
subsequent transmissions to peers, and a short link-layer address pledge to join the network.
for the pledge.
From the pledge's perspective, joining is a local phenomenon - the From the pledge's perspective, joining is a local phenomenon - the
pledge only interacts with the JP, and it needs not know how far it pledge only interacts with the JP, and it needs not know how far it
is from the 6LBR, or how to route to the JRC. Only after is from the 6LBR, or how to route to the JRC. Only after
establishing one or more link-layer keys does it need to know about establishing one or more link-layer keys does it need to know about
the particulars of a 6TiSCH network. the particulars of a 6TiSCH network.
The join process is shown as a transaction diagram in Figure 1: The join process is shown as a transaction diagram in Figure 1:
+--------+ +-------+ +--------+ +--------+ +-------+ +--------+
| pledge | | JP | | JRC | | pledge | | JP | | JRC |
| | | | | | | | | | | |
+--------+ +-------+ +--------+ +--------+ +-------+ +--------+
| | | | | |
|<---Enhanced Beacon (1)---| | |<---Enhanced Beacon (1)---| |
| | | | | |
|<-Neighbor Discovery (2)->| | |<-Neighbor Discovery (2)->| |
| | | | | |
|-----Join Request (3)-----|------Join Request (3a)-->| \ |-----Join Request (3a)----|----Join Request (3a)---->| \
| | | | 6JP | | | | CoJP
|<---Join Response (4)-----|-----Join Response (4a)---| / |<----Join Response (3b)---|----Join Response (3b)----| /
| | | | | |
Figure 1: Overview of a successful join process. 6JP stands for Figure 1: Overview of a successful join process. CoJP stands for
6TiSCH Join Protocol. Constrained Join Protocol.
As other nodes in the network, the 6LBR node plays the role of the
JP. 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.
5.1. Step 1 - Enhanced Beacon 5.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-2015], network. This process is entirely defined by [IEEE802.15.4], and
and described in [RFC7554]. described in [RFC7554].
Once the pledge hears an EB, it synchronizes to the joining schedule Once the pledge hears an EB, it synchronizes to the joining schedule
using the cells contained in the EB. The pledge can hear multiple using the cells contained in the EB. The pledge can hear multiple
EBs; the selection of which EB to use is out of the scope for this EBs; the selection of which EB to use is out of the scope for this
document, and is discussed in [RFC7554]. Implementers should make document, and is discussed in [RFC7554]. Implementers should make
use of information such as: what network identifier the EB contains, use of information such as: what network identifier the EB contains,
whether the source link-layer address of the EB has been tried whether the source link-layer address of the EB has been tried
before, what signal strength the different EBs were received at, etc. before, what signal strength the different EBs were received at, etc.
In addition, the pledge may be pre-configured to search for EBs with In addition, the pledge may be pre-configured to search for EBs with
a specific network identifier. a specific network identifier.
If the pledge is not provisioned with the network identifier, it If the pledge is not provisioned with the network identifier, it
attempts to join one network at a time, as described in Section 9.3. attempts to join one network at a time, as described in
Section 9.1.3.
Once the pledge selects the EB, it synchronizes to it and transitions Once the pledge selects the EB, it synchronizes to it and transitions
into a low-power mode. It deeply duty cycles its radio, switching into a low-power mode. It follows the provided schedule which
the radio on when the provided schedule indicates slots which the indicates the slots that the pledge may use for the join process.
pledge may use for the join process. During the remainder of the During the remainder of the join process, the node that has sent the
join process, the node that has sent the EB to the pledge plays the EB to the pledge plays the role of JP.
role of 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.
5.2. Step 2 - Neighbor Discovery 5.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.5.1 of [RFC6775]. The pledge and the JP use their link- Section 5.5.1 of [RFC6775]. The pledge and the JP use their link-
local IPv6 addresses for all subsequent communication during the join local IPv6 addresses for all subsequent communication during the join
process. 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 JP accepts these unprotected frames is discussed in
Section 6. Section 6.
5.3. Step 3 - Join Request 5.3. Step 3 - Constrained Join Protocol (CoJP) Execution
The Join Request is a message sent from the pledge to the JP, and
which the JP forwards to the JRC. The JP forwards the Join Request
to the JRC on the existing 6TiSCH network. How exactly this happens
is out of scope of this document; some networks may wish to dedicate
specific slots for this join traffic.
The Join Request is authenticated/encrypted end-to-end using an AEAD The pledge triggers the join exchange of the Constrained Join
(Authenticated Encryption with Associated Data) algorithm from Protocol (CoJP). The join exchange consists of two messages: the
[RFC8152] and a key derived from the PSK, the pledge identifier and a Join Request message (Step 3a), and the Join Response message
request-specific constant value. Algorithms which MUST be conditioned on the successful security processing of the request
implemented are specified in Section 9.6. (Step 3b). All CoJP messages are exchanged over a secure channel
that provides confidentiality, data authenticity and replay
protection.
The nonce used when securing the Join Request is derived from the 5.3.1. Step 3a - Join Request
PSK, the pledge identifier and a monotonically increasing counter
initialized to 0 when first starting.
Join Request message is specified in Section 9.1, while the details The Join Request is a message sent from the pledge to the JP, and
on security processing can be found in Section 7 of which the JP forwards to the JRC. The pledge indicates in the Join
[I-D.ietf-core-object-security]. Request the role it requests to play in the network as well as the
identifier of the network it requests to join. The JP forwards the
Join Request to the JRC on the existing 6TiSCH network. How exactly
this happens is out of scope of this document; some networks may wish
to dedicate specific slots for this join traffic.
5.4. Step 4 - Join Response 5.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 as it serves as a stateless relay. The packet through the JP. The packet containing the Join Response travels from
containing the Join Response travels from the JRC to JP using the the JRC to JP using the operating routes in the 6TiSCH network. The
operating routes in the 6TiSCH network. The JP delivers it to the JP delivers it to the pledge. The JP operates as the application-
pledge. The JP operates as the application-layer proxy, and does not layer proxy, and does not keep any state to forward the message.
keep any state to relay the message. It uses information sent in the
clear within the Join Response to decide where to forward to.
The Join Response is authenticated/encrypted end-to-end using an AEAD The Join Response contains different parameters needed by the pledge
algorithm from [RFC8152]. The key used to protect the response is to become a fully operational network node. For example, these
different from the one used to protect the request (both are derived parameters are the link-layer key(s) currently in use in the network,
from the PSK, as explained in Section 8.1). The response is the short link-layer address assigned to the pledge, the IPv6 address
protected using the same nonce as in the request. of the JRC needed by the pledge to operate as the JP, and others.
The Join Response contains one or more link-layer key(s) that the 5.4. The Special Case of the 6LBR Pledge Joining
pledge will use for subsequent communication. Each key that is
provided by the JRC is associated with an 802.15.4 key identifier.
In other link-layer technologies, a different identifier may be
substituted. The Join Response also contains an IEEE 802.15.4 short
address [IEEE802.15.4-2015] assigned by the JRC to the pledge, and
optionally the IPv6 address of the JRC.
Join Response message is specified in Section 9.2, while the details The 6LBR pledge performs Section 5.3 of the join process described
on security processing can be found in Section 7 of above, just as any other pledge, albeit over another network
[I-D.ietf-core-object-security]. interface. There is no JP intermediating the communication between
the 6LBR pledge and the JRC, as described in Section 7. The other
steps of the described join process do not apply to the 6LBR pledge.
How the 6LBR pledge obtains an IPv6 address and triggers the
execution of the CoJP protocol is out of scope of this document.
6. Link-layer Configuration 6. Link-layer Configuration
In an operational 6TiSCH network, all frames MUST use link-layer In an operational 6TiSCH network, all frames MUST use link-layer
frame security [RFC8180]. The IEEE 802.15.4 security attributes MUST frame security [RFC8180]. The IEEE Std 802.15.4 security attributes
include frame authenticity, and MAY include frame confidentiality MUST include frame authenticity, and MAY include frame
(i.e. encryption). confidentiality (i.e. encryption).
As specified in [RFC8180], the network uses a key termed as K1 to
authenticate EBs and a key termed as K2 to authenticate and
optionally encrypt DATA and ACKNOWLEDGMENT frames. The keys K1 and
K2 MAY be the same key (same value and IEEE 802.15.4 index). How the
JRC communicates these keys to 6LBR is out of scope of this
specification.
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 know the K1 key. The pledge is still able to frames, as it does not possess the link-layer key(s) in use. The
parse the contents of the received EBs and synchronize to the pledge is still able to parse the contents of the received EBs and
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 frames unencrypted and unauthenticated frames. The JP accepts these
(using the "exempt mode" in 802.15.4) for the duration of the join unsecured frames for the duration of the join process. This behavior
process. How the JP learns whether the join process is ongoing is may be implemented by setting the "secExempt" attribute in the IEEE
out of scope of this specification. Std 802.15.4 security configuration tables. How the JP learns
whether the join process is ongoing is out of scope of this
specification.
As the EB itself cannot be authenticated by the pledge, an attacker As the EB itself cannot be authenticated by the pledge, an attacker
may craft a frame that appears to be a valid EB, since the pledge can may craft a frame that appears to be a valid EB, since the pledge can
neither know the ASN a priori nor verify the address of the JP. This neither verify the freshness nor verify the address of the JP. This
opens up a possibility of DoS attack, as discussed in Section 11. opens up a possibility of DoS attack, as discussed in Section 11.
Beacon authentication keys are discussed in [RFC8180].
7. Network-layer Configuration 7. 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,
How the pledge and the JP decide to transition each other from as the attacker may fill JP's neighbor table and prevent the
untrusted to trusted cache, once the join process completes, is out discovery of legitimate neighbors. How the pledge and the JP decide
of scope. One implementation technique is to use the information to transition each other from untrusted to trusted cache, once the
whether the incoming frames are secured at the link layer. join process completes, is out of scope. One implementation
technique is to use the information whether the incoming frames are
secured at the link layer.
The pledge does not communicate with the JRC at the network layer. The pledge does not communicate with the JRC at the network layer.
This allows the pledge to join without knowing the IPv6 address of This allows the pledge to join without knowing the IPv6 address of
the JRC. Instead, the pledge communicates with the JP at the network the JRC. Instead, the pledge communicates with the JP at the network
layer, and with the JRC at the application layer, as specified in layer using link-local addressing, and with the JRC at the
Section 8. application layer, as specified in Section 8.
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 prefix and configures its global IPv6 address discovers the network IPv6 prefix and configures its global IPv6
upon successful completion of the join process and the obtention of address upon successful completion of the join process and the
link-layer keys. The pledge learns the actual IPv6 address of the obtention of link-layer keys. The pledge learns the actual IPv6
JRC from the Join Response, as specified in Section 9.2; it uses it address of the JRC from the Join Response, as specified in
once joined in order to operate as a JP. Section 9.1.2; it uses it once joined in order to operate as a JP.
As a special case, the 6LBR pledge is expected to have an additional
network interface that it uses in order to obtain the configuration
parameters from the JRC and start advertising the 6TiSCH network.
This additional interface needs to be configured with a global IPv6
address, by a mechanism that is out of scope of this document. The
6LBR pledge uses this interface to directly communicate with the JRC
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
RPL DIOs [RFC6550] to its IPv6 address. The pledge learns the the RPL DIOs [RFC6550] to its IPv6 address. The pledge learns the
address of the JRC once joined and upon the reception of a first RPL address of the JRC once joined and upon the reception of the first
DIO message, and uses it to operate as a JP. RPL DIO message, and uses it to operate as a JP.
Before the 6TiSCH network is started, the 6LBR MUST be provisioned
with the IPv6 address of the JRC.
7.1. Identification of Join Request Traffic 7.1. Identification of Join Request Traffic
The join request traffic that is proxied by the Join Proxy comes from The join request traffic that is proxied by the Join Proxy (JP) comes
unauthenticated nodes, and there may be an arbitrary amount of it. from unauthenticated nodes, and there may be an arbitrary amount of
In particular, an attacker may send fraudulent traffic in attempt to it. In particular, an attacker may send fraudulent traffic in
overwhelm the network. attempt to overwhelm the network.
When operating as part of a [RFC8180] 6TiSCH minimal network using When operating as part of a [RFC8180] 6TiSCH minimal network using
reasonable scheduling algorithms, the join request traffic present distributed scheduling algorithms, the join request traffic present
may cause intermediate nodes to request additional bandwidth. An may cause intermediate nodes to request additional bandwidth. An
attacker could use this property to cause the network to overcommit attacker could use this property to cause the network to overcommit
bandwidth (and energy) to the join process. bandwidth (and energy) to the join process.
The Join Proxy is aware of what traffic is join request traffic, and The Join Proxy is aware of what traffic is join request traffic, and
so can avoid allocating additional bandwidth itself. The Join Proxy so can avoid allocating additional bandwidth itself. The Join Proxy
SHOULD implement a bandwidth cap on outgoing join request traffic. SHOULD implement a bandwidth cap on outgoing join request traffic.
This cap will not protect intermediate nodes as they can not tell This cap will not protect intermediate nodes as they can not tell
join request traffic from regular traffic. Despite the bandwidth cap join request traffic from regular traffic. Despite the bandwidth cap
implemented separately on each Join Proxy, the aggregate join request implemented separately on each Join Proxy, the aggregate join request
traffic from many Join Proxies may cause intermediate nodes to decide traffic from many Join Proxies may cause intermediate nodes to decide
to allocate additional cells. It is undesirable to to so in response to allocate additional cells. It is undesirable to do so in response
to the join request traffic. In order to permit the intermediate to the join request traffic. In order to permit the intermediate
nodes to avoid this, the traffic needs to be tagged in some way. nodes to avoid this, the traffic needs to be tagged.
[RFC2597] defines a set of per-hop behaviors that may be encoded into [RFC2597] defines a set of per-hop behaviors that may be encoded into
the Diffserv Code Points (DSCPs). The Join Proxy SHOULD set the DSCP the Diffserv Code Points (DSCPs). The Join Proxy SHOULD set the DSCP
of join request packets that it produces as part of the relay process of join request packets that it produces as part of the relay process
to AF43 code point (See Section 6 of [RFC2597]). to AF43 code point (See Section 6 of [RFC2597]).
A Join Proxy that does not set the DSCP on traffic forwarded should A Join Proxy that does not set the DSCP on traffic forwarded should
set it to zero so that it is compressed out. 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.
7.2. Identification of Join Response Traffic 7.2. Identification of Join Response Traffic
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. Join response traffic can not be Join Proxy to AF42 code point. Join response traffic can not be
induced by an attacker as it is generated only in response to induced by an attacker as it is generated only in response to
legitimate pledges (see Section 9.3). AF42 has lower drop legitimate pledges (see Section 9.1.3). AF42 has lower drop
probability than AF43, giving join response traffic priority in probability than AF43, giving join response traffic priority in
buffers over join request traffic. buffers over join request traffic.
When the JRC is not co-located with the 6LBR, then the code point
provides a clear indication to the 6LBR that this is join response
traffic.
Due to the convergecast nature of the DODAG, the 6LBR links are often Due to the convergecast nature of the DODAG, the 6LBR links are often
the most congested, and from that point down there is progressively the most congested, and from that point down there is progressively
less (or equal) congestion. If the 6LBR paces itself when sending less (or equal) congestion. If the 6LBR paces itself when sending
join response traffic then it ought to never exceed the bandwidth join response traffic then it ought to never exceed the bandwidth
allocated to the best effort traffic cells. If the 6LBR has the allocated to the best effort traffic cells. If the 6LBR has the
capacity (if it is not constrained) then it should provide some capacity (if it is not constrained) then it should provide some
buffers in order to satisfy the Assured Forwarding behavior. buffers in order to satisfy the Assured Forwarding behavior.
Companion SF documents SHOULD specify how traffic with code point Companion SF documents SHOULD specify how traffic with code point
AF42 is handled with respect to cell allocation. AF42 is handled with respect to cell allocation.
8. Application-level Configuration 8. Application-level Configuration
The Join Request/Join Response exchange in Figure 1 is carried over The CoJP join exchange in Figure 1 is carried over CoAP [RFC7252] and
CoAP [RFC7252] and secured using OSCORE the secure channel provided by OSCORE
[I-D.ietf-core-object-security]. The pledge plays the role of a CoAP [I-D.ietf-core-object-security]. The (6LBR) pledge plays the role of
client; the JRC plays the role of a CoAP server. The JP implements a CoAP client; the JRC plays the role of a CoAP server. The JP
CoAP forward proxy functionality [RFC7252]. Because the JP can also implements CoAP forward proxy functionality [RFC7252]. Because the
be a constrained device, it cannot implement a cache. Rather, the JP JP can also be a constrained device, it cannot implement a cache. If
processes forwarding-related CoAP options and makes requests on the JP used the stateful CoAP proxy defined in [RFC7252], it would be
behalf of the pledge, in a stateless manner by using the Stateless- prone to Denial-of-Service (DoS) attacks, due to its limited memory.
Proxy option defined in this document. Rather, the JP processes forwarding-related CoAP options and makes
requests on behalf of the pledge, in a stateless manner by using the
Stateless-Proxy option defined in this document.
The pledge designates a JP as a proxy by including the Proxy-Scheme The pledge designates a JP as a proxy by including the Proxy-Scheme
option in CoAP requests it sends to the JP. The pledge also includes option in CoAP requests it sends to the JP. The pledge also includes
in the requests the Uri-Host option with its value set to the well- in the requests the Uri-Host option with its value set to the well-
known JRC's alias, as specified in Section 9.1. known JRC's alias, as specified in Section 9.1.1.
The JP resolves the alias to the IPv6 address of the JRC that it The JP resolves the alias to the IPv6 address of the JRC that it
learned when it acted as a pledge, and joined the network. This learned when it acted as a pledge, and joined the network. This
allows the JP to reach the JRC at the network layer and forward the allows the JP to reach the JRC at the network layer and forward the
requests on behalf of the pledge. requests on behalf of the pledge.
The JP MUST add a Stateless-Proxy option to all the requests that it The JP MUST add a Stateless-Proxy option to all the requests that it
forwards on behalf of the pledge as part of the join process. forwards on behalf of the pledge as part of the join process.
The value of the Stateless-Proxy option is set to the internal JP The value of the Stateless-Proxy option is set to the internal JP
state, needed to forward the Join Response message to the pledge. state, needed to forward the Join Response message to the pledge.
The Stateless-Proxy option handling is defined in Section 10. The Stateless-Proxy option handling is defined in Section 10.
The JP also tags all packets carrying the Join Request message at the The JP also tags all packets carrying the Join Request message at the
network layer, as specified in Section 7.1. network layer, as specified in Section 7.1.
8.1. OSCORE Security Context 8.1. OSCORE Security Context
Before the pledge and the JRC may start exchanging CoAP messages Before the (6LBR) pledge and the JRC may start exchanging CoAP
protected with OSCORE, they need to derive the OSCORE security messages protected with OSCORE, they need to derive the OSCORE
context from the parameters provisioned out-of-band, as discussed in security context from the parameters provisioned out-of-band, as
Section 4. discussed in Section 4.
The OSCORE security context MUST be derived at the pledge and the JRC The OSCORE security context MUST be derived as per Section 3 of
as per Section 3 of [I-D.ietf-core-object-security]. [I-D.ietf-core-object-security].
o the Master Secret MUST be the PSK. o the Master Secret MUST be the PSK.
o the Master Salt MUST be the pledge identifier. o the Master Salt MUST be empty.
o the Sender ID of the pledge MUST be set to byte string 0x00. o the ID of the pledge MUST be set to the byte string 0x00. This
identifier is used as the OSCORE Sender ID in the security context
derivation, as the pledge initially plays the role of a CoAP
client.
o the Recipient ID (ID of the JRC) MUST be set to byte string 0x01. o the ID of the JRC MUST be set to the byte string 0x4a5243 ("JRC"
in ASCII). This identifier is used as the OSCORE Recipient ID in
the security context derivation, as the JRC initially plays the
role of a CoAP server.
o the ID Context MUST be set to the pledge identifier.
o the Algorithm MUST be set to the value from [RFC8152], agreed out- o the Algorithm MUST be set to the value from [RFC8152], agreed out-
of-band by the same mechanism used to provision the PSK. The of-band by the same mechanism used to provision the PSK. The
default is AES-CCM-16-64-128. default is AES-CCM-16-64-128.
o the Key Derivation Function MUST be agreed out-of-band. Default o the Key Derivation Function MUST be agreed out-of-band. Default
is HKDF SHA-256 [RFC5869]. is HKDF SHA-256 [RFC5869].
The derivation in [I-D.ietf-core-object-security] results in traffic The derivation in [I-D.ietf-core-object-security] results in traffic
keys and a common IV for each side of the conversation. Nonces are keys and a common IV for each side of the conversation. Nonces are
skipping to change at page 13, line 15 skipping to change at page 14, line 30
[I-D.ietf-core-object-security]. [I-D.ietf-core-object-security].
Implementations MUST ensure that multiple CoAP requests to different Implementations MUST ensure that multiple CoAP requests to different
JRCs result in the use of the same OSCORE context, so that the JRCs result in the use of the same OSCORE context, so that the
sequence numbers are properly incremented for each request. The sequence numbers are properly incremented for each request. The
pledge typically sends requests to different JRCs if it is not pledge typically sends requests to different JRCs if it is not
provisioned with the network identifier and attempts to join one provisioned with the network identifier and attempts to join one
network at a time. A simple implementation technique is to network at a time. A simple implementation technique is to
instantiate the OSCORE security context with a given PSK only once instantiate the OSCORE security context with a given PSK only once
and use it for all subsequent requests. Failure to comply will break and use it for all subsequent requests. Failure to comply will break
the confidentiality property of the AEAD algorithm due to the nonce the confidentiality property of the Authenticated Encryption with
reuse. Associated Data (AEAD) algorithm due to the nonce reuse.
This OSCORE security context is used for initial joining of the
(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
client and the joined node as a CoAP server, as discussed in
Section 9.2. A (6LBR) pledge is expected to have exactly one OSCORE
security context with the JRC.
8.1.1. Persistency 8.1.1. Persistency
Implementations MUST ensure that mutable OSCORE context parameters Implementations MUST ensure that mutable OSCORE context parameters
(Sender Sequence Number, Replay Window) are stored in persistent (Sender Sequence Number, Replay Window) are stored in persistent
memory. A technique that prevents reuse of sequence numbers, memory. A technique that prevents reuse of sequence numbers,
detailed in Section 6.5.1 of [I-D.ietf-core-object-security], MUST be detailed in Section 6.5.1 of [I-D.ietf-core-object-security], MUST be
implemented. Each update of the OSCORE Replay Window MUST be written implemented. Each update of the OSCORE Replay Window MUST be written
to persistent memory. to persistent 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 pledge and the JRC is rare, making rejoins. Traffic between the (6LBR) pledge and the JRC is rare,
security outweigh the cost of writing to persistent memory. making security outweigh the cost of writing to persistent memory.
9. 6TiSCH Join Protocol 9. Constrained Join Protocol (CoJP)
6TiSCH Join Protocol (6JP) is a lightweight protocol over CoAP Constrained Join Protocol (CoJP) is a lightweight protocol over CoAP
[RFC7252] and a secure channel provided by OSCORE [RFC7252] and a secure channel provided by OSCORE
[I-D.ietf-core-object-security]. 6JP allows the pledge to request [I-D.ietf-core-object-security]. CoJP allows the (6LBR) pledge to
admission into a network managed by the JRC, and for the JRC to request admission into a network managed by the JRC, and for the JRC
configure the pledge with the parameters necessary for joining the to configure the pledge with the parameters necessary for joining the
network. These parameters are: link-layer keys in use, IEEE 802.15.4 network, or advertising it in the case of 6LBR pledge. The JRC may
short address assigned to the pledge, and the IPv6 address of the update the parameters at any time, by reaching out to the joined node
JRC. that formerly acted as a (6LBR) pledge. For example, network-wide
rekeying can be implemented by updating the keying material on each
node.
This section specifies the 6JP bindings to CoAP and OSCORE, 6JP This section specifies how the CoJP messages are mapped to CoAP and
message formats and the semantics of different fields. OSCORE, CBOR data structures carrying different parameters,
transported within CoAP payload, and the parameter semantics and
processing rules.
6JP 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.
+-----------------------------------+ +-----------------------------------+
| 6TiSCH Join Protocol (6JP) | | Constrained Join Protocol (CoJP) |
+-----------------------------------+ +-----------------------------------+
+-----------------------------------+ \ +-----------------------------------+ \
| Requests / Responses | | | Requests / Responses | |
|-----------------------------------| | |-----------------------------------| |
| OSCORE | | CoAP | OSCORE | | CoAP
|-----------------------------------| | |-----------------------------------| |
| Messaging Layer / Message Framing | | | Messaging Layer / Message Framing | |
+-----------------------------------+ / +-----------------------------------+ /
+-----------------------------------+ +-----------------------------------+
| UDP | | UDP |
+-----------------------------------+ +-----------------------------------+
Figure 2: Abstract layering of 6JP. Figure 2: Abstract layering of CoJP.
6JP consists of two messages: When a (6LBR) pledge requests admission to a given network, it
undergoes the CoJP join exchange that consists of:
o the Join Request message, sent by the pledge to the JRC, proxied o the Join Request message, sent by the (6LBR) pledge to the JRC,
by the JP. The Join Request message and its mapping to CoAP is potentially proxied by the JP. The Join Request message and its
specified in Section 9.1. mapping to CoAP is specified in Section 9.1.1.
o the Join Response message, sent by the JRC to the pledge if the o the Join Response message, sent by the JRC to the (6LBR) pledge if
JRC successfully processes the Join Request using OSCORE and it the JRC successfully processes the Join Request using OSCORE and
determines through a mechanism that is out of scope of this it determines through a mechanism that is out of scope of this
specification that the pledge is authorized to join the network. specification that the (6LBR) pledge is authorized to join the
The Join Response message is proxied by the JP. The Join Response network. The Join Response message is potentially proxied by the
message and its mapping to CoAP is specified in Section 9.2. JP. The Join Response message and its mapping to CoAP is
specified in Section 9.1.2.
The payload of 6JP messages is encoded with CBOR [RFC7049], with some When the JRC needs to update the parameters of a joined node that
parameters being optional. The first byte of the CBOR-encoded byte formerly acted as a (6LBR) pledge, it executes the CoJP parameter
string contains the CBOR major type and additional information (e.g. update exchange that consists of:
the number of elements in an array). In case of an array, the CBOR
decoder decides based on this additional information if a certain
optional parameter is present or not.
9.1. Specification of the Join Request o the Parameter Update message, sent by the JRC to the joined node
that formerly acted as a (6LBR) pledge. The Parameter Update
message and its mapping to CoAP is specified in Section 9.2.1.
The Join Request the pledge sends SHALL be mapped to a CoAP request: 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 9.2.2.
The payload of CoJP messages is encoded with CBOR [RFC7049]. The
CBOR data structures that may appear as the payload of different CoJP
messages are specified in Section 9.3.
9.1. Join Exchange
This section specifies the messages exchanged when the (6LBR) pledge
requests admission and configuration parameters from the JRC.
9.1.1. Join Request Message
The Join Request message SHALL be mapped to a CoAP request:
o The request method is POST. o The request method is POST.
o The type is Non-confirmable (NON). o The type is Non-confirmable (NON).
o The Proxy-Scheme option is set to "coap". o The Proxy-Scheme option is set to "coap".
o The Uri-Host option is set to "6tisch.arpa". o The Uri-Host option is set to "6tisch.arpa". This is an anycast
type of identifier of the JRC that is resolved to its IPv6 address
by the JP or the 6LBR pledge.
o The Uri-Path option is set to "j". o The Uri-Path option is set to "j".
o The Object-Security option SHALL be set according to o The Object-Security option SHALL be set according to
[I-D.ietf-core-object-security]. The OSCORE security context used [I-D.ietf-core-object-security]. The OSCORE security context used
is the one derived in Section 8.1. The OSCORE Context Hint SHALL is the one derived in Section 8.1. The OSCORE kid context is set
be set to the pledge identifier. The OSCORE Context Hint allows to the ID context, which in turn is set to the pledge identifier.
the JRC to retrieve the security context for a given pledge. The OSCORE kid context allows the JRC to retrieve the security
context for a given pledge.
o The payload is a CBOR array [RFC7049] containing, in order:
* Byte string, containing the identifier of the network that the
pledge is attempting to join. This enables the JRC to manage
multiple 6TiSCH networks.
request_payload = [ o The payload is a Join_Request CBOR object, as defined in
network_identifier : bstr, Section 9.3.1.
]
9.2. Specification of the Join Response 9.1.2. Join Response Message
The Join Response the JRC sends SHALL be mapped to a CoAP response: The Join Response message that the JRC sends SHALL be mapped to a
CoAP response:
o The response Code is 2.04 (Changed). o The response Code is 2.04 (Changed).
o The payload is a CBOR array [RFC7049] containing, in order: o The payload is a Configuration CBOR object, as defined in
Section 9.3.2.
* the COSE Key Set, specified in [RFC8152], containing one or
more link-layer keys. The mapping of individual keys to
802.15.4-specific parameters is described in Section 9.2.1.
* the link-layer short address to be used by the pledge. The
format of the short address follows Section 9.2.2.
* optionally, the IPv6 address of the JRC, encoded as a byte
string, with the length of 16 bytes. If the IPv6 address of
the JRC is not present in the Join Response, this indicates the
JRC is co-located with the 6LBR, and has the same IPv6 address
as the 6LBR. See Section 7.
response_payload = [
COSE_KeySet,
short_address,
? JRC_address : bstr,
]
9.2.1. Link-layer Keys Transported in the COSE Key Set
Each key in the COSE Key Set [RFC8152] SHALL be a symmetric key. The
first key in the COSE Key Set SHALL be used as the K1 key from
[RFC8180]. The second key in the COSE Key Set SHALL be used as the
K2 key from [RFC8180]. In the case where the network uses the same
key for K1 and K2, the COSE Key Set SHALL carry a single key.
If the COSE Key Set carries more than 2 keys, the implementation
SHOULD consider the response as malformed.
If the "kid" parameter of the COSE Key structure is present, the
corresponding key SHALL be used as IEEE 802.15.4 KeyIdMode 0x01
(index). In that case, parameter "kid" of the COSE Key structure
SHALL be used to carry the IEEE 802.15.4 KeyIndex value.
If the length of the "kid" parameter is more than 1 byte (length
defined by [IEEE802.15.4-2015]), the implementation SHOULD consider
the response as malformed.
If the "kid" parameter is not present in the transported key, the
implementation SHALL consider the key to be an IEEE 802.15.4
KeyIdMode 0x00 (implicit) key.
This document does not support IEEE 802.15.4 KeyIdMode 0x02 and 0x03
class keys. In the case that the response is considered malformed,
the implementation SHOULD indicate to the user through an out-of-band
mechanism the presence of an error condition.
9.2.2. Short Address
The "short_address" structure transported as part of the join
response payload represents the IEEE 802.15.4 short address assigned
to the pledge. It is encoded as a CBOR array object, containing, in
order:
o Byte string, containing the 16-bit address.
o Optionally, the lease time parameter, "lease_asn". The value of
the "lease_asn" parameter is the 5-byte Absolute Slot Number (ASN)
corresponding to its expiration, carried as a byte string in
network byte order.
short_address = [
address : bstr,
? lease_asn : bstr,
]
It is up to the joined node to request a new short address before the
expiry of its previous address. The mechanism by which the node
requests renewal is the same as during join procedure, as described
in Section 9.4.
9.3. Error Handling and Retransmission 9.1.3. Error Handling and Retransmission
Since the Join Request is mapped to a Non-confirmable CoAP message, Since the Join Request is mapped to a Non-confirmable CoAP message,
OSCORE processing at the JRC will silently drop the request in case OSCORE processing at the JRC will silently drop the request in case
of a failure. This may happen for a number of reasons, including of a failure. This may happen for a number of reasons, including
failed lookup of an appropriate security context (e.g. the pledge failed lookup of an appropriate security context (e.g. the pledge
attempting to join a wrong network), failed decryption, positive attempting to join a wrong network), failed decryption, positive
replay window lookup, formatting errors (possibly due to malicious replay window lookup, formatting errors (possibly due to malicious
alterations in transit). Silently dropping the Join Request at the alterations in transit). Silently dropping the Join Request at the
JRC prevents a DoS attack where an attacker could force the pledge to JRC prevents a DoS attack where an attacker could force the pledge to
attempt joining one network at a time, until all networks have been attempt joining one network at a time, until all networks have been
skipping to change at page 17, line 33 skipping to change at page 17, line 49
also helps minimize the required CoAP state at the pledge and the also helps minimize the required CoAP state at the pledge and the
Join Proxy, keeping it to a minimum typically needed to perform CoAP Join Proxy, keeping it to a minimum typically needed to perform CoAP
congestion control. It does, however, introduce some complexity as congestion control. It does, however, introduce some complexity as
the pledge needs to implement a retransmission mechanism. the pledge needs to implement a retransmission mechanism.
The following binary exponential back-off algorithm is inspired by The following binary exponential back-off algorithm is inspired by
the one described in [RFC7252]. For each Join Request the pledge the one described in [RFC7252]. For each Join Request the pledge
sends while waiting for a Join Response, the pledge MUST keep track sends while waiting for a Join Response, the pledge MUST keep track
of a timeout and a retransmission counter. For a new Join Request, of a timeout and a retransmission counter. For a new Join Request,
the timeout is set to a random value between TIMEOUT_BASE and the timeout is set to a random value between TIMEOUT_BASE and
(TIMEOUT_BASE * TIMEOUT_RANDOM_FACTOR), and the retransmission (TIMEOUT_BASE * TIMEOUT_RANDOM_FACTOR). The retransmission counter
counter is set to 0. When the timeout is triggered and the is set to 0. When the timeout is triggered and the retransmission
retransmission counter is less than MAX_RETRANSMIT, the Join Request counter is less than MAX_RETRANSMIT, the Join Request is
is retransmitted, the retransmission counter is incremented, and the retransmitted, the retransmission counter is incremented, and the
timeout is doubled. Note that the retransmitted Join Request passes timeout is doubled. Note that the retransmitted Join Request passes
new OSCORE processing, such that the sequence number in the OSCORE new OSCORE processing, such that the sequence number in the OSCORE
context is properly incremented. If the retransmission counter context is properly incremented. If the retransmission counter
reaches MAX_RETRANSMIT on a timeout, the pledge SHOULD attempt to reaches MAX_RETRANSMIT on a timeout, the pledge SHOULD attempt to
join the next advertised 6TiSCH network. If the pledge receives a join the next advertised 6TiSCH network. If the pledge receives a
Join Response that successfully passes OSCORE processing, it cancels Join Response that successfully passes OSCORE processing, it cancels
the pending timeout and processes the response. The pledge MUST the pending timeout and processes the response. The pledge MUST
silently discard any response not protected with OSCORE, including silently discard any response not protected with OSCORE, including
error codes. For default values of retransmission parameters, see error codes. For default values of retransmission parameters, see
Section 9.5. Section 9.4.
If all join attempts to advertised networks have failed, the pledge If all join attempts to advertised networks have failed, the pledge
SHOULD signal to the user the presence of an error condition, through SHOULD signal to the user the presence of an error condition, through
some out-of-band mechanism. some out-of-band mechanism.
9.4. Rekeying and Rejoining 9.2. Parameter Update Exchange
This specification handles initial keying of the pledge. For reasons During the network lifetime, parameters returned as part of the Join
such as rejoining after a long sleep, expiry of the short address, or Response may need to be updated. One typical example is the update
node-initiated rekeying, the joined node MAY send a new Join Request of link-layer keying material for the network, a process known as
using the already-established OSCORE security context. The JRC then rekeying. This section specifies a generic mechanism when this
responds with up-to-date keys and a (possibly new) short address. parameter update is initiated by the JRC.
How the joined node decides when to rekey is out of scope of this
document. Mechanisms for rekeying the network are defined in
companion specifications.
9.5. Parameters 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"
resource, exposed by the JRC. In order for the update of these
parameters to happen, the JRC needs to asynchronously contact the
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
becomes the joined node and obtains a global address.
6JP uses the following parameters: Instead, once the (6LBR) pledge receives and successfully validates
the Join Response and so becomes a joined node, it switches its CoAP
role and becomes a server. The joined node exposes the "/j" resource
that is used by the JRC to update the parameters. Consequently, the
JRC operates as a CoAP client when updating the parameters. The
request/response exchange between the JRC and the (6LBR) pledge
happens over the already-established OSCORE secure channel.
9.2.1. Parameter Update Message
The Parameter Update message that the JRC sends to the joined node
SHALL be mapped to a CoAP request:
o The request method is POST.
o The type is Confirmable (CON).
o The Uri-Path option is set to "j".
o The Object-Security option SHALL be set according to
[I-D.ietf-core-object-security]. The OSCORE security context used
is the one derived in Section 8.1. When a joined node receives a
request with the Sender ID set to 0x4a5243 (ID of the JRC), it is
able to correctly retrieve the security context with the JRC.
o The payload is a Configuration CBOR object, as defined in
Section 9.3.2.
The JRC has implicit knowledge on the global IPv6 address of the
joined node, as it knows the pledge identifier that the joined node
used when it acted as a pledge, and the IPv6 network prefix. The JRC
uses this implicitly derived IPv6 address of the joined node to
directly address CoAP messages to it.
9.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.
9.3. CoJP Objects
This section specifies the structure of CoJP CBOR objects that may be
carried as the payload of CoJP messages. Some of these objects may
be received both as part of the CoJP join exchange when the device
operates as a (CoJP) pledge, or the parameter update exchange, when
the device operates as a joined (6LBR) node.
9.3.1. Join Request 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
summarized below. The defined labels can be found below, the details
of this registry are in section "CoJP Parameters" registry
Section 13.2.
o role: The identifier of the role that the pledge requests to play
in the network once it joins, encoded as an unsigned integer.
Possible values are specified in Table 1. This parameter MAY be
included. In case the parameter is omitted, the default value of
0, i.e. the role "6TiSCH Node", MUST be assumed.
o network identifier: The identifier of the network, as discussed in
Section 3, encoded as a CBOR byte string. This parameter may
appear both in the Join Request and in the Join Response. When
present in the Join Request, it hints to the JRC the network that
the pledge is requesting to join, enabling the JRC to manage
multiple networks. The pledge obtains the value of the network
identifier from the received EB frames. This parameter MUST be
included in a Join_Request object if the role parameter is set to
"6TiSCH Node". This parameter MAY be included if the role
parameter is set to "6LBR". The inclusion of this parameter by
the 6LBR pledge depends on whether the parameter was exchanged
during the one-touch process, which in turn depends on the
operational constraints.
The CDDL fragment that represents the text above for the Join_Request
follows.
Join_Request = {
? 1 : uint ; role
? 5 : bstr ; network identifier
}
+--------+-------+-------------------------------------+------------+
| Name | Value | Description | Reference |
+--------+-------+-------------------------------------+------------+
| 6TiSCH | 0 | The pledge requests to play the | [[this |
| Node | | role of a regular 6TiSCH node, i.e. | document]] |
| | | non-6LBR node. | |
| | | | |
| 6LBR | 1 | The pledge requests to play the | [[this |
| | | role of 6LoWPAN Border Router | document]] |
| | | (6LBR). | |
+--------+-------+-------------------------------------+------------+
Table 1: Role values.
9.3.2. Configuration Object
The Configuration structure is built on a CBOR map object. The set
of parameters that can appear in a Configuration object is summarized
below. The defined labels can be found below, the details of this
registry are in section "CoJP Key Usage Registry" Section 13.3.
o link-layer key set: An array encompassing a set of cryptographic
keys and their identifiers that are currently in use in the
network, or that are scheduled to be used in the future. The
encoding of individual keys is described in Section 9.3.2.1. The
link-layer key set parameter MAY be included in a Configuration
object. When present, the link-layer key set parameter MUST
contain at least one key. How the keys are installed and used
differs for the 6LBR and other nodes. When 6LBR receives this
parameter, it MUST remove any old keys it has installed from the
previous key set and immediately install and start using the new
keys for all outgoing and incoming traffic. When a non-6LBR node
receives this parameter, it MUST install the keys, use them for
any incoming traffic matching the key identifier, but keep using
the old keys for all outgoing traffic. A non-6LBR node accepts
any frames for which it has keys: both old and new keys. Upon
reception and successful security processing of a link-layer frame
secured with a key from the new key set, a non-6LBR node MUST
remove any old keys it has installed from the previous key set.
From that moment on, a non-6LBR node MUST use the keys from the
new key set for all outgoing traffic. In the case when the pledge
is joining for the first time, before sending the first outgoing
frame secured with a received key, the pledge needs to
successfully complete the security processing of an incoming
frame. To do so, the pledge can wait to receive a new frame or it
can also store an EB frame that it used to find the JP and use it
for immediate security processing upon reception of the key set.
The described mechanism permits the JRC to provision the new key
set to all the nodes while the network continues to use the
existing keys. When the JRC is certain that all (or enough) nodes
have been provisioned with the new keys, then the JRC updates the
6LBR. In the special case when the JRC is co-located with the
6LBR, it can simply trigger the sending of a new broadcast frame
(e.g. EB), secured with a key from the new key set. The frame
goes out with the new key, and upon reception and successful
security processing of the new frame all receiving nodes will
switch to the new active keys. Outgoing traffic from those nodes
will then use the new key, which causes an update of additional
peers, and the network will switch over in a flood-fill fashion.
o link-layer short address: IEEE Std 802.15.4 short address assigned
to the pledge. The short address structure is described in
Section 9.3.2.2. The link-layer short address parameter MAY be
included in a Configuration object. When a node receives this
parameter as part of the Parameter Update message, it MUST update
its link-layer short address to the one received.
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 is different than 16, the parameter MUST be discarded. If
the JRC is not co-located with the 6LBR and has a different IPv6
address than the 6LBR, this parameter MUST be included. In the
special case where the JRC is co-located with the 6LBR and has the
same IPv6 address as the 6LBR, this parameter MAY be included. If
the JRC address parameter is not present in the Join Response,
this indicates that the JRC has the same IPv6 address as the 6LBR.
The joined node can then discover the IPv6 address of the JRC
through network control traffic. See Section 7.
o network identifier: the identifier of the network, as discussed in
Section 3, encoded as a byte string. When present in the Join
Response, this parameter is only valid when received by the 6LBR
pledge. The parameter indicates to the 6LBR the value of the
network identifier it should advertise at the link layer. This
parameter MUST NOT be included in the Join Response if the role
parameter from the corresponding Join Request indicated 0, i.e.
the role "6TiSCH Node". In the case where the corresponding
Join_Request object does not contain the network identifier
parameter, this parameter MUST be included. When the
corresponding Join_Request object does contain the network
identifier parameter, this parameter MAY be included in the
Configuration object. This may happen if the JRC decides to
overwrite the network identifier provisioned during the one-touch
process. The value of the network identifier parameter from the
Configuration object SHOULD take precedence over the value
provisioned during the one-touch process.
o network prefix: the IPv6 network prefix, encoded as a byte string.
The length of the byte string determines the prefix length. This
parameter is only valid when received by the 6LBR pledge. The
parameter indicates to the 6LBR the value of the IPv6 network
prefix. This parameter MAY be included in the Join Response if
the role parameter from the corresponding Join_Request object
indicated 1, i.e. the role "6LBR". This parameter MUST NOT be
included in the Join Response if the role parameter from the
corresponding Join_Request object indicated 0, i.e. the role
"6TiSCH Node".
The CDDL fragment that represents the text above for the
Configuration follows. Structures Link_Layer_Key and Short_Address
are specified in Section 9.3.2.1 and Section 9.3.2.2.
Configuration = {
? 2 : [ +Link_Layer_Key ], ; link-layer key set
? 3 : Short_Address, ; link-layer short address
? 4 : bstr ; JRC address
? 5 : bstr ; network identifier
? 6 : bstr ; network prefix
}
+------------+-------+----------+----------------------+------------+
| Name | Label | CBOR | Description | Reference |
| | | type | | |
+------------+-------+----------+----------------------+------------+
| role | 1 | unsigned | Identifies the role | [[this |
| | | integer | parameter. | document]] |
| | | | | |
| link-layer | 2 | array | Identifies the array | [[this |
| key set | | | carrying one or more | document]] |
| | | | link-level | |
| | | | cryptographic keys. | |
| | | | | |
| link-layer | 3 | array | Identifies the | [[this |
| short | | | assigned link-layer | document]] |
| address | | | short address | |
| | | | | |
| JRC | 4 | byte | Identifies the IPv6 | [[this |
| address | | string | address of the JRC | document]] |
| | | | | |
| network | 5 | byte | Identifies the | [[this |
| identifier | | string | network identifier | document]] |
| | | | parameter | |
| | | | | |
| network | 6 | byte | Identifies the IPv6 | [[this |
| prefix | | string | prefix of the | document]] |
| | | | network | |
+------------+-------+----------+----------------------+------------+
Table 2: Join Response map labels.
9.3.2.1. Link-Layer Key
The Link_Layer_Key structure encompasses the parameters needed to
configure the link-layer security module: the value of the
cryptographic key, the key identifier, the link-layer algorithm
identifier, and the security level and the frame types that it should
be used with, both for outgoing and incoming security operations.
For encoding compactness, Link_Layer_Key object is not enclosed in a
top-level CBOR object. Rather, it is transported as a consecutive
group of CBOR elements, with some being optional. To be able to
decode the keys that are present in the link-layer key set, and to
identify individual parameters of a single Link_Layer_Key object, the
CBOR decoder needs to differentiate between elements based on the
CBOR type. For example, when the decoder determines that the current
element in the array is a byte string, it is certain that it is
processing the last element of a given Link_Layer_Key object.
The set of parameters that can appear in a Link_Layer_Key object is
summarized below, in order:
o key_index: The identifier of the key, encoded as a CBOR unsigned
integer. This parameter MUST be included. The parameter uniquely
identifies the key and is used to retrieve the key for incoming
traffic. In case of [IEEE802.15.4], the decoded CBOR unsigned
integer value sets the "secKeyIndex" parameter that is signaled in
all outgoing and incoming frames secured with this key. If the
decoded CBOR unsigned integer value is larger than the maximum
link-layer key identifier, which is 255 in [IEEE802.15.4]), the
key is considered invalid. Additionally, in case of
[IEEE802.15.4], the value of 0 is considered invalid. In case the
key is considered invalid, the implementation MUST discard the key
and attempt to decode the next key in the array.
o key_usage: The identifier of the link-layer algorithm, security
level and link-layer frame types that can be used with the key,
encoded as a CBOR unsigned or negative integer. This parameter
MAY be included. Possible values and the corresponding link-layer
settings are specified in IANA "CoJP Key Usage" registry
(Section 13.3). In case the parameter is omitted, the default
value of 0 from Table 3 MUST be assumed.
o key_value: The value of the cryptographic key, encoded as a byte
string. This parameter MUST be included. If the length of the
byte string is different than the corresponding key length for a
given algorithm specified by the key_usage parameter, the key MUST
be discarded and the decoder should attempt to decode the next key
in the array.
The CDDL fragment that represents the text above for the
Link_Layer_Key follows.
Link_Layer_Key = (
key_index : uint,
? key_usage : uint / nint,
key_value : bstr,
)
+------------------+-----+-----------------+-------------+----------+
| Name | Val | Algorithm | Description | Referenc |
| | ue | | | e |
+------------------+-----+-----------------+-------------+----------+
| 6TiSCH-K1K2-ENC- | 0 | IEEE802154-AES- | Use MIC-32 | [[this d |
| MIC-32 | | CCM-128 | for EBs, | ocument] |
| | | | ENC-MIC-32 | ] |
| | | | for DATA | |
| | | | and ACKNOWL | |
| | | | EDGMENT. | |
| | | | | |
| 6TiSCH-K1K2-ENC- | 1 | IEEE802154-AES- | Use MIC-64 | [[this d |
| MIC-64 | | CCM-128 | for EBs, | ocument] |
| | | | ENC-MIC-64 | ] |
| | | | for DATA | |
| | | | and ACKNOWL | |
| | | | EDGMENT. | |
| | | | | |
| 6TiSCH-K1K2-ENC- | 2 | IEEE802154-AES- | Use MIC-128 | [[this d |
| MIC-128 | | CCM-128 | for EBs, | ocument] |
| | | | ENC-MIC-128 | ] |
| | | | for DATA | |
| | | | and ACKNOWL | |
| | | | EDGMENT. | |
| | | | | |
| 6TiSCH- | 3 | IEEE802154-AES- | Use MIC-32 | [[this d |
| K1K2-MIC-32 | | CCM-128 | for EBs, | ocument] |
| | | | DATA and AC | ] |
| | | | KNOWLEDGMEN | |
| | | | T. | |
| | | | | |
| 6TiSCH- | 4 | IEEE802154-AES- | Use MIC-64 | [[this d |
| K1K2-MIC-64 | | CCM-128 | for EBs, | ocument] |
| | | | DATA and AC | ] |
| | | | KNOWLEDGMEN | |
| | | | T. | |
| | | | | |
| 6TiSCH- | 5 | IEEE802154-AES- | Use MIC-128 | [[this d |
| K1K2-MIC-128 | | CCM-128 | for EBs, | ocument] |
| | | | DATA and AC | ] |
| | | | KNOWLEDGMEN | |
| | | | T. | |
| | | | | |
| 6TiSCH-K1-MIC-32 | 6 | IEEE802154-AES- | Use MIC-32 | [[this d |
| | | CCM-128 | for EBs. | ocument] |
| | | | | ] |
| | | | | |
| 6TiSCH-K1-MIC-64 | 7 | IEEE802154-AES- | Use MIC-64 | [[this d |
| | | CCM-128 | for EBs. | ocument] |
| | | | | ] |
| | | | | |
| 6TiSCH-K1-MIC-12 | 8 | IEEE802154-AES- | Use MIC-128 | [[this d |
| 8 | | CCM-128 | for EBs. | ocument] |
| | | | | ] |
| | | | | |
| 6TiSCH-K2-MIC-32 | 9 | IEEE802154-AES- | Use MIC-32 | [[this d |
| | | CCM-128 | for DATA | ocument] |
| | | | and ACKNOWL | ] |
| | | | EDGMENT. | |
| | | | | |
| 6TiSCH-K2-MIC-64 | 10 | IEEE802154-AES- | Use MIC-64 | [[this d |
| | | CCM-128 | for DATA | ocument] |
| | | | and ACKNOWL | ] |
| | | | EDGMENT. | |
| | | | | |
| 6TiSCH-K2-MIC-12 | 11 | IEEE802154-AES- | Use MIC-128 | [[this d |
| 8 | | CCM-128 | for DATA | ocument] |
| | | | and ACKNOWL | ] |
| | | | EDGMENT. | |
| | | | | |
| 6TiSCH-K2-ENC- | 12 | IEEE802154-AES- | Use ENC- | [[this d |
| MIC-32 | | CCM-128 | MIC-32 for | ocument] |
| | | | DATA and AC | ] |
| | | | KNOWLEDGMEN | |
| | | | T. | |
| | | | | |
| 6TiSCH-K2-ENC- | 13 | IEEE802154-AES- | Use ENC- | [[this d |
| MIC-64 | | CCM-128 | MIC-64 for | ocument] |
| | | | DATA and AC | ] |
| | | | KNOWLEDGMEN | |
| | | | T. | |
| | | | | |
| 6TiSCH-K2-ENC- | 14 | IEEE802154-AES- | Use ENC- | [[this d |
| MIC-128 | | CCM-128 | MIC-128 for | ocument] |
| | | | DATA and AC | ] |
| | | | KNOWLEDGMEN | |
| | | | T. | |
+------------------+-----+-----------------+-------------+----------+
Table 3: Key Usage values.
9.3.2.2. Short Address
The Short_Address object represents an address assigned to the pledge
that is unique locally in the network. It is encoded as a CBOR array
object, containing, in order:
o address: The assigned locally-unique address, encoded as a byte
string. This parameter MUST be included. In case of
[IEEE802.15.4], if the length of the byte string is different than
2, the address is considered invalid. In case of [IEEE802.15.4],
the value of this parameter is used to set the short address of
IEEE Std 802.15.4 module. In case the address is considered
invalid, the decoder MUST silently ignore the Short_Address
object.
o lease_time: The validity of the address in seconds after the
reception of the CBOR object, encoded as a CBOR unsigned integer.
This parameter MAY be included. The node MUST stop using the
assigned short address after the expiry of the lease_time
interval. It is up to the JRC to renew the lease before the
expiry of the previous interval. The JRC updates the lease by
executing the Parameter Update exchange with the node and
including the Short_Address in the Configuration object, as
described in Section 9.2. In case the address lease expires, the
node SHOULD initiate a new join exchange, as described in
Section 9.1. In case this parameter is omitted, the value of
positive infinity MUST be assumed, meaning that the address is
valid for as long as the node participates in the network.
The CDDL fragment that represents the text above for the
Short_Address follows.
Short_Address = [
address : bstr,
? lease_time : uint
]
9.4. Parameters
CoJP uses the following parameters:
+-----------------------+----------------+ +-----------------------+----------------+
| Name | Default Value | | Name | Default Value |
+-----------------------+----------------+ +-----------------------+----------------+
| TIMEOUT_BASE | 10 s | | TIMEOUT_BASE | 10 s |
+-----------------------+----------------+ +-----------------------+----------------+
| TIMEOUT_RANDOM_FACTOR | 1.5 | | TIMEOUT_RANDOM_FACTOR | 1.5 |
+-----------------------+----------------+ +-----------------------+----------------+
| MAX_RETRANSMIT | 4 | | MAX_RETRANSMIT | 4 |
+----------------------------------------+ +----------------------------------------+
The values of TIMEOUT_BASE, TIMEOUT_RANDOM_FACTOR, MAX_RETRANSMIT may The values of TIMEOUT_BASE, TIMEOUT_RANDOM_FACTOR, MAX_RETRANSMIT may
be configured to values specific to the deployment. The default be configured to values specific to the deployment. The default
values have been chosen to accommodate a wide range of deployments, values have been chosen to accommodate a wide range of deployments,
taking into account dense networks. taking into account dense networks.
9.6. Mandatory to Implement Algorithms 9.5. Mandatory to Implement Algorithms
The mandatory to implement AEAD algorithm for use with OSCORE is AES- The mandatory to implement AEAD algorithm for use with OSCORE is AES-
CCM-16-64-128 from [RFC8152]. This is the algorithm used for CCM-16-64-128 from [RFC8152]. This is the algorithm used for
securing 802.15.4 frames, and hardware acceleration for it is present securing IEEE Std 802.15.4 frames, and hardware acceleration for it
in virtually all compliant radio chips. With this choice, CoAP is present in virtually all compliant radio chips. With this choice,
messages are protected with an 8-byte CCM authentication tag, and the CoAP messages are protected with an 8-byte CCM authentication tag,
algorithm uses 13-byte long nonces. and the algorithm uses 13-byte long nonces.
The mandatory to implement hash algorithm is SHA-256 [RFC4231]. The mandatory to implement hash algorithm is SHA-256 [RFC4231].
The mandatory to implement key derivation function is HKDF [RFC5869], The mandatory to implement key derivation function is HKDF [RFC5869],
instantiated with a SHA-256 hash. instantiated with a SHA-256 hash.
10. Stateless-Proxy CoAP Option 10. Stateless-Proxy CoAP Option
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 host, and the UDP source port number. token, the IPv6 address of the host, and the UDP source port number.
If the JP used the stateful CoAP proxy defined in [RFC7252], it would
be prone to Denial-of-Service (DoS) attacks, due to its limited
memory.
The Stateless-Proxy CoAP option Figure 3 allows the JP to be entirely The Stateless-Proxy CoAP option (see Figure 3) allows the proxy to be
stateless. This option inserts, in the request, the state entirely stateless. The proxy inserts this option in the request to
information needed for relaying the response back to the client. The carry the state information needed for relaying the response back to
proxy still keeps some general state (e.g. for congestion control or the client. The proxy still keeps some general state (e.g. for
request retransmission), but no per-client state. congestion control or request retransmission), but no per-client
state.
The Stateless-Proxy CoAP option is critical, Safe-to-Forward, not The Stateless-Proxy CoAP option is critical, Safe-to-Forward, not
part of the cache key, not repeatable and opaque. When processed by part of the cache key, not repeatable and opaque. When processed by
OSCORE, the Stateless-Proxy option is neither encrypted nor integrity OSCORE, the Stateless-Proxy option is neither encrypted nor integrity
protected. protected.
+-----+---+---+---+---+-----------------+--------+--------+ +-----+---+---+---+---+-----------------+--------+--------+
| No. | C | U | N | R | Name | Format | Length | | No. | C | U | N | R | Name | Format | Length |
+-----+---+---+---+---+-----------------+--------+--------| +-----+---+---+---+---+-----------------+--------+--------|
| TBD | x | | x | | Stateless-Proxy | opaque | 1-255 | | TBD | x | | x | | Stateless-Proxy | opaque | 1-255 |
+-----+---+---+---+---+-----------------+--------+--------+ +-----+---+---+---+---+-----------------+--------+--------+
C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable
Figure 3: Stateless-Proxy CoAP Option Figure 3: Stateless-Proxy CoAP Option
Upon reception of a Stateless-Proxy option, the CoAP server MUST echo Upon reception of a Stateless-Proxy option, the CoAP server MUST echo
it in the response. The value of the Stateless-Proxy option is it in the response. The value of the Stateless-Proxy option is
internal proxy state that is opaque to the server. Example state internal proxy state that is opaque to the server. For security
information includes the IPv6 address of the client, its UDP source reasons, the option value MUST be authenticated, MUST include a
port, and the CoAP token. For security reasons, the state freshness indicator (e.g. a sequence number or timestamp) and MAY be
information MUST be authenticated, MUST include a freshness indicator encrypted. The proxy may use a COSE structure [RFC8152] to wrap the
(e.g. a sequence number or timestamp) and MAY be encrypted. The
proxy may use an appropriate COSE structure [RFC8152] to wrap the
state information as the value of the Stateless-Proxy option. The state information as the value of the Stateless-Proxy option. The
key used for encryption/authentication of the state information may key used for encryption/authentication of the state information may
be known only to the proxy. be known only to the proxy.
Once the proxy has received the CoAP response with a Stateless-Proxy Once the proxy has received the CoAP response with a Stateless-Proxy
option present, it decrypts/authenticates it, checks the freshness option present, it decrypts/authenticates it, checks the freshness
indicator and constructs the response for the client, based on the indicator and constructs the response for the client, based on the
information present in the option value. information present in the option value.
Note that a CoAP proxy using the Stateless-Proxy option is not able Note that a CoAP proxy using the Stateless-Proxy option is not able
to return a 5.04 Gateway Timeout Response Code in case the request to to return a 5.04 Gateway Timeout Response Code in case the request to
the server times out. Likewise, if the response to the proxy's the server times out. Likewise, if the response to the proxy's
request does not contain the Stateless-Proxy option, for example when request does not contain the Stateless-Proxy option, for example when
the option is not supported by the server, the proxy is not able to the option is not supported by the server, the proxy is not able to
return the response to the client. return the response to the client, and the client eventually times
out.
11. Security Considerations 11. Security Considerations
This document recommends that the pledge and JRC are provisioned with This document recommends that the (6LBR) pledge and JRC are
unique PSKs. The nonce used for the Join Request and the Join provisioned with unique PSKs. The nonce used for the Join Request
Response is the same, but used under a different key. The design and the Join Response is the same, but used under a different key.
differentiates between keys derived for requests and keys derived for The design differentiates between keys derived for requests and keys
responses by different sender identifiers (0x00 for pledge and 0x01 derived for responses by different sender identifiers. Note that the
for JRC). Note that the address of the JRC does not take part in address of the JRC does not take part in nonce or key construction.
nonce or key construction. Even in the case of a misconfiguration in Even in the case of a misconfiguration in which the same PSK is used
which the same PSK is used for several pledges, the keys used to for several pledges, the keys used to protect the requests/responses
protect the requests/responses from/towards different pledges are from/towards different pledges are different, as they are derived
different, as they are derived using the pledge identifier as Master using the pledge identifier as Master Salt. The PSK is still
Salt. The PSK is still important for mutual authentication of the important for mutual authentication of the (6LBR) pledge and the JRC.
pledge and the JRC. Should an attacker come to know the PSK, then a Should an attacker come to know the PSK, then a man-in-the-middle
man-in-the-middle attack is possible. The well-known problem with attack is possible. The well-known problem with Bluetooth headsets
Bluetooth headsets with a "0000" pin applies here. with a "0000" pin applies here.
Being a stateless relay, the JP blindly forwards the join traffic Being a stateless relay, the JP blindly forwards the join traffic
into the network. A simple bandwidth cap on the JP prevents it from into the network. A simple bandwidth cap on the JP prevents it from
forwarding more traffic than the network can handle. This forces forwarding more traffic than the network can handle. This forces
attackers to use more than one Join Proxy if they wish to overwhelm attackers to use more than one Join Proxy if they wish to overwhelm
the network. Marking the join traffic packets with a non-zero DSCP the network. Marking the join traffic packets with a non-zero DSCP
allows the network to carry the traffic if it has capacity, but allows the network to carry the traffic if it has capacity, but
encourages the network to drop the extra traffic rather than add encourages the network to drop the extra traffic rather than add
bandwidth due to that traffic. bandwidth due to that traffic.
skipping to change at page 20, line 50 skipping to change at page 30, line 11
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 blacklist in order to filter out out. The pledge may implement a temporary blacklist in order to
undesired EBs and try to join using the next seemingly valid EB. filter out undesired EBs and try to join using the next seemingly
This blacklist alleviates the issue, but is effectively limited by valid EB. This blacklist alleviates the issue, but is effectively
the node's available memory. Bogus beacons prolong the join time of limited by the node's available memory. Bogus beacons prolong the
the pledge, and so the time spent in "minimal" [RFC8180] duty cycle join time of the pledge, and so the time spent in "minimal" [RFC8180]
mode. duty cycle mode.
12. Privacy Considerations 12. 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 within the namespace managed by the JRC. of the pledge identifier within the namespace managed by the JRC.
This identifier is transferred in clear as an OSCORE Context Hint. This identifier is transferred in clear as an OSCORE kid context.
The use of the globally unique EUI-64 as pledge identifier simplifies The use of the globally unique EUI-64 as pledge identifier simplifies
the management but comes with certain privacy risks. The 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
join protocol is executed rarely compared to the network lifetime, join protocol is executed rarely compared to the network lifetime,
long-term threats that arise from using EUI-64 as the pledge long-term threats that arise from using EUI-64 as the pledge
identifier are minimal. In addition, the Join Response message identifier are minimal. In addition, the Join Response message
contains a short address which is assigned by the JRC to the pledge. contains a short address which is assigned by the JRC to the (6LBR)
The assigned short address SHOULD be uncorrelated with the long-term pledge. The assigned short address SHOULD be uncorrelated with the
pledge identifier. The short address is encrypted in the response. long-term pledge identifier. The short address is encrypted in the
Once the join process completes, the new node uses the short response. Once the join process completes, the new node uses the
addresses for all further layer 2 (and layer-3) operations. This short addresses for all further layer 2 (and layer-3) operations.
mitigates the aforementioned privacy risks as the short layer-2 This mitigates the aforementioned privacy risks as the short layer-2
address (visible even when the network is encrypted) is not traceable address (visible even when the network is encrypted) is not traceable
between locations and does not disclose the manufacturer, as is the between locations and does not disclose the manufacturer, as is the
case of EUI-64. case of EUI-64.
13. IANA Considerations 13. 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. No A, AAAA or PTR record is
requested. requested.
13.1. CoAP Option Numbers Registry 13.1. CoAP Option Numbers Registry
The Stateless-Proxy option is added to the CoAP Option Numbers The Stateless-Proxy option is added to the CoAP Option Numbers
registry: registry:
+--------+-----------------+-------------------+ +--------+-----------------+-----------------------+
| Number | Name | Reference | | Number | Name | Reference |
+--------+-----------------+-------------------+ +--------+-----------------+-----------------------+
| TBD | Stateless-Proxy | [[this document]] | | TBD | Stateless-Proxy | \[\[this document\]\] |
+--------+-----------------+-------------------+ +--------+-----------------+-----------------------+
13.2. CoJP Parameters Registry
This section defines a sub-registries within the "IPv6 over the TSCH
mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name
"Constrained Join Protocol Parameters Registry".
The columns of the registry are:
Name: This is a descriptive name that enables an easier reference to
the item. It is not used in the encoding.
Label: The value to be used to identify this parameter. The label is
an unsigned integer.
CBOR type: This field contains the CBOR type for the field.
Description: This field contains a brief description for the field.
Reference: This field contains a pointer to the public specification
for the field, if one exists.
This registry is to be populated with the values in Table 2.
The amending formula for this sub-registry is: Different ranges of
values use different registration policies [RFC8126]. 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
Specification Required. Integer values greater than 65535 are
designated as Expert Review. Integer values less than -65536 are
marked as Private Use.
13.3. CoJP Key Usage Registry
This section defines a sub-registries within the "IPv6 over the TSCH
mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name
"Constrained Join Protocol Key Usage Registry".
The columns of this registry are:
Name: This is a descriptive name that enables easier reference to the
item. The name MUST be unique. It is not used in the encoding.
Value: This is the value used to identify the key usage setting.
These values MUST be unique. The value is an integer.
Algorithm: This is a descriptive name of the link-layer algorithm in
use and uniquely determines the key length. The name is not used in
the encoding.
Description: This field contains a description of the key usage
setting. The field should describe in enough detail how the key is
to be used with different frame types, specific for the link-layer
technology in question.
References: This contains a pointer to the public specification for
the field, if one exists.
This registry is to be populated with the values in Table 3.
The amending formula for this sub-registry is: Different ranges of
values use different registration policies [RFC8126]. 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
Specification Required. Integer values greater than 65535 are
designated as Expert Review. Integer values less than -65536 are
marked as Private Use.
14. Acknowledgments 14. Acknowledgments
The work on this document has been partially supported by the The work on this document has been partially supported by the
European Union's H2020 Programme for research, technological European Union's H2020 Programme for research, technological
development and demonstration under grant agreement No 644852, development and demonstration under grant agreement No 644852,
project ARMOUR. project ARMOUR.
The authors are grateful to Thomas Watteyne and Goeran Selander for The authors are grateful to Thomas Watteyne, Goeran Selander, Xavier
reviewing, and to Klaus Hartke for providing input on the Stateless- Vilajosana, Pascal Thubert for reviewing, and to Klaus Hartke for
Proxy CoAP option. The authors would also like to thank Francesca providing input on the Stateless-Proxy CoAP option.
Palombini, Ludwig Seitz and John Mattsson for participating in the
discussions that have helped shape the document. The authors would also like to thank Francesca Palombini, Ludwig
Seitz and John Mattsson for participating in the discussions that
have helped shape the document.
The IANA considerations for the three created registries is copied
verbatim from RFC8392 at the suggestion of Mike Jones.
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-core-object-security] [I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-08 (work in (OSCORE)", draft-ietf-core-object-security-13 (work in
progress), January 2018. progress), May 2018.
[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-
<https://www.rfc-editor.org/info/rfc2119>. 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-
<https://www.rfc-editor.org/info/rfc2597>. editor.org/info/rfc2597>.
[RFC3172] Huston, G., Ed., "Management Guidelines & Operational [RFC3172] Huston, G., Ed., "Management Guidelines & Operational
Requirements for the Address and Routing Parameter Area Requirements for the Address and Routing Parameter Area
Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172,
September 2001, <https://www.rfc-editor.org/info/rfc3172>. September 2001, <https://www.rfc-editor.org/info/rfc3172>.
[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-
<https://www.rfc-editor.org/info/rfc7252>. editor.org/info/rfc7252>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<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>.
15.2. Informative References 15.2. Informative References
[I-D.ietf-6tisch-6top-protocol] [I-D.ietf-6tisch-6top-protocol]
Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol
(6P)", draft-ietf-6tisch-6top-protocol-09 (work in (6P)", draft-ietf-6tisch-6top-protocol-11 (work in
progress), October 2017. progress), March 2018.
[I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-14 (work
in progress), April 2018.
[I-D.ietf-6tisch-terminology] [I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terminology in IPv6 over the TSCH mode of IEEE "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e",
802.15.4e", draft-ietf-6tisch-terminology-09 (work in draft-ietf-6tisch-terminology-10 (work in progress), March
progress), June 2017. 2018.
[I-D.ietf-cbor-cddl] [I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to definition language (CDDL): a notational convention to
express CBOR data structures", draft-ietf-cbor-cddl-02 express CBOR data structures", draft-ietf-cbor-cddl-02
(work in progress), February 2018. (work in progress), February 2018.
[I-D.richardson-6tisch-minimal-rekey] [IEEE802.15.4]
Richardson, M., "Minimal Security rekeying mechanism for
6TiSCH", draft-richardson-6tisch-minimal-rekey-02 (work in
progress), August 2017.
[IEEE802.15.4-2015]
IEEE standard for Information Technology, ., "IEEE Std IEEE standard for Information Technology, ., "IEEE Std
802.15.4-2015 Standard for Low-Rate Wireless Personal Area 802.15.4 Standard for Low-Rate Wireless Networks", n.d..
Networks (WPANs)", 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>.
[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-
<https://www.rfc-editor.org/info/rfc5869>. 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-
<https://www.rfc-editor.org/info/rfc6550>. editor.org/info/rfc6550>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>. <https://www.rfc-editor.org/info/rfc6775>.
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement", RFC 7554, Internet of Things (IoT): Problem Statement", RFC 7554,
DOI 10.17487/RFC7554, May 2015, DOI 10.17487/RFC7554, May 2015, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7554>. 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 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal
IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH)
Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180,
May 2017, <https://www.rfc-editor.org/info/rfc8180>. May 2017, <https://www.rfc-editor.org/info/rfc8180>.
Appendix A. Example Appendix A. Example
Figure 4 illustrates a successful join protocol exchange. The pledge Figure 4 illustrates a successful join protocol exchange. The pledge
instantiates the OSCORE context and derives the traffic keys and instantiates the OSCORE context and derives the traffic 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 Context Hint. 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 adds Proxy-Scheme option, the JP forwards the request to the JRC and adds
the Stateless-Proxy option with value set to the internally needed the Stateless-Proxy option with value set to the internally needed
state, authentication tag, and a freshness indicator. The JP has state. The JP has learned the IPv6 address of the JRC when it acted
learned the IPv6 address of the JRC when it acted as a pledge and as a pledge and joined the network. Once the JRC receives the
joined the network. Once the JRC receives the request, it looks up request, it looks up the correct context based on the kid context
the correct context based on the Context Hint parameter. It parameter. OSCORE data authenticity verification ensures that the
reconstructs OSCORE's external Additional Authenticated Data (AAD) request has not been modified in transit. In addition, replay
needed for verification based on: protection is ensured through persistent handling of mutable context
parameters.
o the Version of the received CoAP header.
o the Algorithm value agreed out-of-band, default being AES-CCM- Once the JP receives the Join Response, it authenticates the
16-64-128 from [RFC8152]. Stateless-Proxy option before deciding where to forward. The JP sets
its internal state to that found in the Stateless-Proxy option, and
forwards the Join Response to the correct pledge. Note that the JP
does not possess the key to decrypt the CBOR object (configuration)
present in the payload. The Join Response is matched to the Join
Request and verified for replay protection at the pledge using OSCORE
processing rules. In this example, the Join Response does not
contain the IPv6 address of the JRC, the pledge hence understands the
JRC is co-located with the 6LBR.
o the Request ID being set to the value of the "kid" field of the <---E2E OSCORE-->
received COSE object. Client Proxy Server
Pledge JP JRC
| | |
| Join | | Code: { 0.02 } (POST)
| Request | | Token: 0x8c
+--------->| | Proxy-Scheme: [ coap ]
| POST | | Uri-Host: [ 6tisch.arpa ]
| | | Object-Security: [ kid: 0 ]
| | | Payload: kid_context: EUI-64
| | | [ Partial IV: 1,
| | | { Uri-Path:"j",
| | | join_request },
| | | <Tag> ]
| | |
| | Join | Code: { 0.01 } (GET)
| | Request | Token: 0x7b
| +--------->| Uri-Host: [ 6tisch.arpa ]
| | POST | Object-Security: [ kid: 0 ]
| | | Stateless-Proxy: opaque state
| | | Payload: kid_context: EUI-64
| | | [ Partial IV: 1,
| | | { Uri-Path:"j",
| | | join_request },
| | | <Tag> ]
| | |
| | Join | Code: { 2.05 } (Content)
| | Response | Token: 0x7b
| |<---------+ Object-Security: -
| | 2.04 | Stateless-Proxy: opaque state
| | | Payload: [ { configuration }, <Tag> ]
| | |
| Join | | Code: { 2.05 } (Content)
| Response | | Token: 0x8c
|<---------+ | Object-Security: -
| 2.04 | | Payload: [ { configuration }, <Tag> ]
| | |
o the Join Request sequence number set to the value of "Partial IV" Figure 4: Example of a successful join protocol exchange. { ... }
field of the received COSE object. denotes encryption and authentication, [ ... ] denotes
authentication.
o Integrity-protected options received as part of the request. Where the join_request object is:
Replay protection is ensured by OSCORE and through persistent join_request:
handling of mutable context parameters. Once the JP receives the {
Join Response, it authenticates the Stateless-Proxy option before 5 : h'cafe' / PAN ID of the network pledge is attempting to join /
deciding where to forward. The JP sets its internal state to that }
found in the Stateless-Proxy option, and forwards the Join Response
to the correct pledge. Note that the JP does not possess the key to
decrypt the COSE object (join_response) present in the payload. The
Join Response is matched to the Join Request and verified for replay
protection at the pledge using OSCORE processing rules. In this
example, the Join Response does not contain the IPv6 address of the
JRC, the pledge hence understands the JRC is co-located with the
6LBR.
<---E2E OSCORE--> Since the role parameter is not present, the default role of "6TiSCH
Client Proxy Server Node" is implied.
Pledge JP JRC
| | |
+------>| | Code: { 0.02 } (POST)
| GET | | Token: 0x8c
| | | Proxy-Scheme: [ coap ]
| | | Uri-Host: [ 6tisch.arpa ]
| | | Object-Security: [ kid: 0 ]
| | | Payload: Context-Hint: EUI-64
| | | [ Partial IV: 1,
| | | { Uri-Path:"j",
| | | join_request },
| | | <Tag> ]
| | |
| +------>| Code: { 0.01 } (GET)
| | GET | Token: 0x7b
| | | Uri-Host: [ 6tisch.arpa ]
| | | Object-Security: [ kid: 0 ]
| | | Stateless-Proxy: opaque state
| | | Payload: Context-Hint: EUI-64
| | | [ Partial IV: 1,
| | | { Uri-Path:"j",
| | | join_request },
| | | <Tag> ]
| | |
| |<------+ Code: { 2.05 } (Content)
| | 2.05 | Token: 0x7b
| | | Object-Security: -
| | | Stateless-Proxy: opaque state
| | | Payload: [ { join_response }, <Tag> ]
| | |
|<------+ | Code: { 2.05 } (Content)
| 2.05 | | Token: 0x8c
| | | Object-Security: -
| | | Payload: [ { join_response }, <Tag> ]
| | |
Figure 4: Example of a successful join protocol exchange. { ... } The join_request object encodes to h'a10542cafe' with a size of 5
denotes encryption and authentication, [ ... ] denotes bytes.
authentication.
Where join_request is: And the configuration object is:
join_request: configuration:
[ {
h'cafe' / PAN ID of the network pledge is attempting to join / 2 : [ / link-layer key set /
] 1, / key_index /
The join_request encodes to h'8142cafe' with a size of 4 bytes. h'e6bf4287c2d7618d6a9687445ffd33e6' / key_value /
],
3 : [ / link-layer short address /
h'af93' / assigned short address /
]
}
And join_response is: Since the key_usage parameter is not present in the link-layer key
set object, the default value of "6TiSCH-K1K2-ENC-MIC-32" is implied.
Similarly, since the lease_time parameter is not present in the link-
layer short address object, the default value of positive infinity is
implied.
join_response: The configuration object encodes to
[
[ / COSE Key Set array with a single key /
{
1 : 4, / key type symmetric /
2 : h'01', / key id /
-1 : h'e6bf4287c2d7618d6a9687445ffd33e6' / key value /
}
],
[
h'af93' / assigned short address /
]
]
The join_response encodes to h'a202820150e6bf4287c2d7618d6a9687445ffd33e6038142af93' with a size
h'8281a301040241012050e6bf4287c2d7618d6a9687445ffd33e68142af93' with of 26 bytes.
a size of 30 bytes.
Authors' Addresses Authors' Addresses
Malisa Vucinic (editor) Malisa Vucinic (editor)
University of Montenegro University of Montenegro
Dzordza Vasingtona bb Dzordza Vasingtona bb
Podgorica 81000 Podgorica 81000
Montenegro Montenegro
Email: malisav@ac.me Email: malisav@ac.me
 End of changes. 132 change blocks. 
540 lines changed or deleted 1047 lines changed or added

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