draft-ietf-6tisch-minimal-security-06.txt   draft-ietf-6tisch-minimal-security-07.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: November 26, 2018 Analog Devices Expires: April 26, 2019 Analog Devices
K. Pister K. Pister
University of California Berkeley University of California Berkeley
M. Richardson M. Richardson
Sandelman Software Works Sandelman Software Works
May 25, 2018 October 23, 2018
Minimal Security Framework for 6TiSCH Minimal Security Framework for 6TiSCH
draft-ietf-6tisch-minimal-security-06 draft-ietf-6tisch-minimal-security-07
Abstract Abstract
This document describes the minimal framework required for a new This document describes the minimal framework required for a new
device, called "pledge", to securely join a 6TiSCH (IPv6 over the device, called "pledge", to securely join a 6TiSCH (IPv6 over the
TSCH mode of IEEE 802.15.4e) network. The framework requires that TSCH mode of IEEE 802.15.4e) network. The framework requires that
the pledge and the JRC (join registrar/coordinator, a central the pledge and the JRC (join registrar/coordinator, a central
entity), share a symmetric key. How this key is provisioned is out entity), share a symmetric key. How this key is provisioned is out
of scope of this document. Through a single CoAP (Constrained of scope of this document. Through a single CoAP (Constrained
Application Protocol) request-response exchange secured by OSCORE Application Protocol) request-response exchange secured by OSCORE
(Object Security for Constrained RESTful Environments), the pledge (Object Security for Constrained RESTful Environments), the pledge
requests admission into the network and the JRC configures it with requests admission into the network and the JRC configures it with
link-layer keying material and other parameters. The JRC may at any link-layer keying material and other parameters. The JRC may at any
time update the parameters through another request-response exchange time update the parameters through another request-response exchange
secured by OSCORE. This specification defines the Constrained Join secured by OSCORE. This specification defines the Constrained Join
Protocol and its CBOR (Concise Binary Object Representation) data Protocol and its CBOR (Concise Binary Object Representation) data
structures, a new Stateless-Proxy CoAP option, and configures the structures and configures the rest of the 6TiSCH communication stack
rest of the 6TiSCH communication stack for this join process to occur for this join process to occur in a secure manner. Additional
in a secure manner. Additional security mechanisms may be added on security mechanisms may be added on top of this minimal framework.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 26, 2018. This Internet-Draft will expire on April 26, 2019.
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
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. One-Touch Assumption . . . . . . . . . . . . . . . . . . . . 5 4. One-Touch Assumption . . . . . . . . . . . . . . . . . . . . 6
5. Join Process Overview . . . . . . . . . . . . . . . . . . . . 7 5. Join Process Overview . . . . . . . . . . . . . . . . . . . . 7
5.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 8 5.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 8
5.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 9 5.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 9
5.3. Step 3 - Constrained Join Protocol (CoJP) Execution . . . 9 5.3. Step 3 - Constrained Join Protocol (CoJP) Execution . . . 9
5.4. The Special Case of the 6LBR Pledge Joining . . . . . . . 10 5.4. The Special Case of the 6LBR Pledge Joining . . . . . . . 10
6. Link-layer Configuration . . . . . . . . . . . . . . . . . . 10 6. Link-layer Configuration . . . . . . . . . . . . . . . . . . 10
7. Network-layer Configuration . . . . . . . . . . . . . . . . . 10 7. Network-layer Configuration . . . . . . . . . . . . . . . . . 11
7.1. Identification of Join Request Traffic . . . . . . . . . 11 7.1. Identification of Join Request Traffic . . . . . . . . . 12
7.2. Identification of Join Response Traffic . . . . . . . . . 12 7.2. Identification of Join Response Traffic . . . . . . . . . 12
8. Application-level Configuration . . . . . . . . . . . . . . . 12 8. Application-level Configuration . . . . . . . . . . . . . . . 13
8.1. OSCORE Security Context . . . . . . . . . . . . . . . . . 13 8.1. Statelessness of the JP . . . . . . . . . . . . . . . . . 13
9. Constrained Join Protocol (CoJP) . . . . . . . . . . . . . . 15 8.2. OSCORE Security Context . . . . . . . . . . . . . . . . . 14
9.1. Join Exchange . . . . . . . . . . . . . . . . . . . . . . 16 9. Constrained Join Protocol (CoJP) . . . . . . . . . . . . . . 16
9.1. Join Exchange . . . . . . . . . . . . . . . . . . . . . . 17
9.2. Parameter Update Exchange . . . . . . . . . . . . . . . . 18 9.2. Parameter Update Exchange . . . . . . . . . . . . . . . . 18
9.3. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 19 9.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 19
9.4. Parameters . . . . . . . . . . . . . . . . . . . . . . . 27 9.4. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 22
9.5. Mandatory to Implement Algorithms . . . . . . . . . . . . 28 9.5. Parameters . . . . . . . . . . . . . . . . . . . . . . . 34
10. Stateless-Proxy CoAP Option . . . . . . . . . . . . . . . . . 28 9.6. Mandatory to Implement Algorithms . . . . . . . . . . . . 34
11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 10. Security Considerations . . . . . . . . . . . . . . . . . . . 35
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
13.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 31 12.1. CoJP Parameters Registry . . . . . . . . . . . . . . . . 37
13.2. CoJP Parameters Registry . . . . . . . . . . . . . . . . 31 12.2. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 37
13.3. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 31 12.3. CoJP Error Registry . . . . . . . . . . . . . . . . . . 38
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
15.1. Normative References . . . . . . . . . . . . . . . . . . 33 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
15.2. Informative References . . . . . . . . . . . . . . . . . 33 14.1. Normative References . . . . . . . . . . . . . . . . . . 39
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 35 14.2. Informative References . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
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 4, line 14 skipping to change at page 4, line 15
document: this may happen through the one-touch provisioning process document: this may happen through the one-touch provisioning process
or by a key exchange protocol that may precede the execution of the or by a key exchange protocol that may precede the execution of the
6TiSCH Join protocol. 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]. The pledge then exchanges messages with the JRC; [IEEE802.15.4]. The pledge then exchanges messages with the JRC;
these messages can be forwarded by nodes already part of the 6TiSCH these messages can be forwarded by nodes already part of the 6TiSCH
network. The messages exchanged allow the JRC and the pledge to network. The messages exchanged allow the JRC and the pledge to
mutually authenticate, based on the PSK. They also allow the JRC to mutually authenticate, based on the PSK. They also allow the JRC to
configure the pledge with link-layer keying material, link-layer configure the pledge with link-layer keying material, short
short address and other parameters. After this secure join process identifier and other parameters. After this secure join process
successfully completes, the joined node can interact with its successfully completes, the joined node can interact with its
neighbors to request 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
skipping to change at page 5, line 27 skipping to change at page 5, line 27
network interface. The device that attempts to join as the 6LBR of network interface. The device that attempts to join as the 6LBR of
the network and does so over another network interface is explicitly the network and does so over another network interface is explicitly
denoted as the "6LBR pledge". When the text equally applies to the denoted as the "6LBR pledge". When the text equally applies to the
pledge and the 6LBR pledge, the "(6LBR) pledge" form is used. 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" identifies the 6TiSCH network. The network
the namespace managed by a JRC. Typically, this is the 16-bit identifier MUST be carried within Enhanced Beacon (EB) frames.
Personal Area Network Identifier (PAN ID) defined in [IEEE802.15.4]. Typically, the 16-bit Personal Area Network Identifier (PAN ID)
Companion documents can specify the use of a different network defined in [IEEE802.15.4] is used as the network identifier.
identifier for join purposes, but this is out of scope of this However, PAN ID is not considered a stable network identifier as it
specification. Such identifier needs to be carried within Enhanced may change during network lifetime if a collision with another
Beacon (EB) frames. network is detected. Companion documents can specify the use of a
different network identifier for join purposes, but this is out of
scope of this specification.
The "pledge identifier" uniquely identifies the (6LBR) pledge in the The "pledge identifier" identifies the (6LBR) pledge. The pledge
namespace managed by a JRC. The pledge identifier is typically the identifier MUST be unique in the set of all pledge identifiers
globally unique 64-bit Extended Unique Identifier (EUI-64) of the managed by a JRC. The pledge identifier uniqueness is an important
IEEE Std 802.15.4 device. This identifier is used to generate the security requirement, as discussed in Section 10. The pledge
IPv6 addresses of the (6LBR) pledge and to identify it during the identifier is typically the globally unique 64-bit Extended Unique
execution of the join protocol. For privacy reasons, it is possible Identifier (EUI-64) of the IEEE Std 802.15.4 device. This identifier
to use an identifier different from the EUI-64 (e.g. a random is used to generate the IPv6 addresses of the (6LBR) pledge and to
string). See Section 12. identify it during the execution of the join protocol. For privacy
reasons (see Section 11), it is possible to use a pledge identifier
different from the EUI-64. For example, a pledge identifier may be a
random byte string, but care needs to be taken that such a string
meets the uniqueness requirement. How pledge identifier is
configured at the pledge is out of scope of this specification.
4. One-Touch Assumption 4. One-Touch Assumption
This document assumes a one-touch scenario. The (6LBR) 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 (6LBR) pledge Physically, the parameters can be written into the (6LBR) pledge
using a number of mechanisms, such as a JTAG interface, a serial using a number of mechanisms, such as a JTAG interface, a serial
skipping to change at page 6, line 18 skipping to change at page 6, line 27
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 (6LBR) pledge, and that the two conversation between the JRC and the (6LBR) pledge, and that the two
devices can exchange the parameters. devices can exchange the parameters.
Parameters that are provisioned to the (6LBR) 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
pledge identifier bound to the given PSK. The PSK SHOULD be at pledge identifier bound to the given PSK. Each (6LBR) pledge MUST
least 128 bits in length, generated uniformly at random. It is be provisioned with a unique PSK. The PSK SHOULD be a
RECOMMENDED to generate the PSK with a cryptographically secure cryptographically strong key, at least 128 bits in length,
pseudorandom number generator. Each (6LBR) pledge SHOULD be indistinguishable by feasible computation from a random uniform
provisioned with a unique PSK. string of the same length. How the PSK is generated and/or
provisioned is out of scope of this specification. This could be
done during a provisioning step or companion documents can specify
the use of a key agreement protocol. Common pitfalls when
generating PSKs are discussed in Section 10.
o Optionally, a network identifier. Provisioning the network o Optionally, a network identifier. Provisioning the network
identifier is RECOMMENDED. However, due to the operational identifier is RECOMMENDED. However, due to the operational
constraints the network identifier may not be known at the time constraints the network identifier may not be known at the time
when the provisioning is done. In case this parameter is not when the provisioning is done. In case this parameter is not
provisioned to the pledge, the pledge attempts to join one network provisioned to the pledge, the pledge attempts to join one network
at a time, which significantly prolongs the join process. In case at a time, which significantly prolongs the join process. In case
this parameter is not provisioned to the 6LBR pledge, the 6LBR this parameter is not provisioned to the 6LBR pledge, the 6LBR
pledge can receive it from the JRC as part of the join protocol. pledge can receive it from the JRC as part of the join protocol.
o Optionally, any non-default algorithms. The default algorithms o Optionally, any non-default algorithms. The default algorithms
are specified in Section 9.5. When algorithm identifiers are not are specified in Section 9.6. When algorithm identifiers are not
exchanged, the use of these default algorithms is implied. exchanged, the use of these default algorithms is implied.
Additionally, the 6LBR pledge that is not co-located with the JRC Additionally, the 6LBR pledge that is not co-located with the JRC
needs to be provisioned with: needs to be provisioned with:
o Global IPv6 address of the JRC. This address is used by the 6LBR o Global IPv6 address of the JRC. This address is used by the 6LBR
pledge to address the JRC during the join process. The 6LBR pledge to address the JRC during the join process. The 6LBR
pledge may also obtain the IPv6 address of the JRC through other pledge may also obtain the IPv6 address of the JRC through other
available mechanisms, such as DHCPv6, GRASP, mDNS, the use of available mechanisms, such as DHCPv6, GRASP, mDNS, the use of
which is out of scope of this document. Pledges do not need to be which is out of scope of this document. Pledges do not need to be
skipping to change at page 7, line 14 skipping to change at page 7, line 22
5. Join Process Overview 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]. 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 acts as a Join Proxy (JP) for the
for the pledge, and when it can expect to receive a frame. The pledge, and when it can expect to receive a frame. The Enhanced
Enhanced Beacon provides the L2 address of the JP and it may also Beacon provides the L2 address of the JP and it may also provide
provide its link-local IPv6 address. its link-local IPv6 address.
2. The pledge configures its link-local IPv6 address and advertises 2. The pledge configures its link-local IPv6 address and advertises
it to the JP using Neighbor Discovery. This step may be omitted it to the JP using Neighbor Discovery. This step may be omitted
if the link-local address has been derived from a known unique if the link-local address has been derived from a known unique
interface identifier, such as an EUI-64 address. interface identifier, such as an EUI-64 address.
3. The pledge sends a Join Request to the JP in order to securely 3. The pledge sends a Join Request to the JP in order to securely
identify itself to the network. The Join Request is forwarded to identify itself to the network. The Join Request is forwarded to
the JRC. the JRC.
skipping to change at page 8, line 22 skipping to change at page 8, line 22
|<-Neighbor Discovery (2)->| | |<-Neighbor Discovery (2)->| |
| | | | | |
|-----Join Request (3a)----|----Join Request (3a)---->| \ |-----Join Request (3a)----|----Join Request (3a)---->| \
| | | | CoJP | | | | CoJP
|<----Join Response (3b)---|----Join Response (3b)----| / |<----Join Response (3b)---|----Join Response (3b)----| /
| | | | | |
Figure 1: Overview of a successful join process. CoJP stands for Figure 1: Overview of a successful join process. CoJP stands for
Constrained Join Protocol. Constrained Join Protocol.
As other nodes in the network, the 6LBR node plays the role of the As other nodes in the network, the 6LBR node may act as the JP. The
JP. The 6LBR may in addition be co-located with the JRC. 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], and network. This process is entirely defined by [IEEE802.15.4], 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 the value of the Join Metric field within EBs, whether the source
before, what signal strength the different EBs were received at, etc. link-layer address of the EB has been tried before, what signal
In addition, the pledge may be pre-configured to search for EBs with strength the different EBs were received at, etc. In addition, the
a specific network identifier. pledge may be pre-configured to search for EBs with 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 attempts to join one network at a time, as described in
Section 9.1.3. Section 9.3.1.
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 follows the provided schedule which into a low-power mode. It follows the provided schedule which
indicates the slots that the pledge may use for the join process. indicates the slots that the pledge may use for the join process.
During the remainder of the join process, the node that has sent the During the remainder of the join process, the node that has sent the
EB to the pledge plays the role of JP. EB to the pledge acts as the JP.
At this point, the pledge may proceed to step 2, or continue to At this point, the pledge may proceed to step 2, or continue to
listen for additional EBs. listen for additional EBs.
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-
skipping to change at page 9, line 28 skipping to change at page 9, line 31
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 - Constrained Join Protocol (CoJP) Execution 5.3. Step 3 - Constrained Join Protocol (CoJP) Execution
The pledge triggers the join exchange of the Constrained Join The pledge triggers the join exchange of the Constrained Join
Protocol (CoJP). The join exchange consists of two messages: the Protocol (CoJP). The join exchange consists of two messages: the
Join Request message (Step 3a), and the Join Response message Join Request message (Step 3a), and the Join Response message
conditioned on the successful security processing of the request conditioned on the successful security processing of the request
(Step 3b). All CoJP messages are exchanged over a secure channel (Step 3b).
that provides confidentiality, data authenticity and replay
protection. All CoJP messages are exchanged over a secure end-to-end channel that
provides confidentiality, data authenticity and replay protection.
Frames carrying CoJP messages are not protected with link-layer
security when exchanged between the pledge and the JP as the pledge
is not in possession of the link-layer keys in use. How JP and
pledge accept these unprotected frames is discussed in Section 6.
When frames carrying CoJP messages are exchanged between nodes that
have already joined the network, the link-layer security is applied
according to the security configuration used in the network.
5.3.1. Step 3a - Join Request 5.3.1. Step 3a - Join Request
The Join Request is a message sent from the pledge to the JP, and The Join Request is a message sent from the pledge to the JP, and
which the JP forwards to the JRC. The pledge indicates in the Join which the JP forwards to the JRC. The pledge indicates in the Join
Request the role it requests to play in the network as well as the 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 identifier of the network it requests to join. The JP forwards the
Join Request to the JRC on the existing 6TiSCH network. How exactly 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 this happens is out of scope of this document; some networks may wish
to dedicate specific slots for this join traffic. to dedicate specific slots for this join traffic.
skipping to change at page 10, line 40 skipping to change at page 10, line 52
unencrypted and unauthenticated frames. The JP accepts these unencrypted and unauthenticated frames. The JP accepts these
unsecured frames for the duration of the join process. This behavior unsecured frames for the duration of the join process. This behavior
may be implemented by setting the "secExempt" attribute in the IEEE may be implemented by setting the "secExempt" attribute in the IEEE
Std 802.15.4 security configuration tables. How the JP learns Std 802.15.4 security configuration tables. How the JP learns
whether the join process is ongoing is out of scope of this whether the join process is ongoing is out of scope of this
specification. 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 verify the freshness 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 10.
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,
as the attacker may fill JP's neighbor table and prevent the as the attacker may fill JP's neighbor table and prevent the
discovery of legitimate neighbors. How the pledge and the JP decide discovery of legitimate neighbors.
to transition each other from untrusted to trusted cache, once the
join process completes, is out of scope. One implementation Once the pledge obtains link-layer keys and becomes a joined node, it
technique is to use the information whether the incoming frames are is able to securely communicate with its neighbors, obtain the
secured at the link layer. network IPv6 prefix and form a global IPv6 address. The joined node
then undergoes an independent process to bootstrap the neighbor cache
entries, possibly with a node that formerly acted as a JP, following
[RFC6775]. From the point of view of the JP, there is no relation
between the neighbor cache entry belonging to a pledge and the joined
node that formerly acted as a pledge.
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 using link-local addressing, and with the JRC at the layer using link-local addressing, and with the JRC at the
application layer, as specified in Section 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 IPv6 prefix and configures its global IPv6 discovers the network IPv6 prefix and configures its global IPv6
address upon successful completion of the join process and the address upon successful completion of the join process and the
skipping to change at page 12, line 29 skipping to change at page 12, line 47
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.1.3). AF42 has lower drop legitimate pledges (see Section 9.3.1). 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.
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 CoJP join exchange in Figure 1 is carried over CoAP [RFC7252] and The CoJP join exchange in Figure 1 is carried over CoAP [RFC7252] and
the secure channel provided by OSCORE the secure channel provided by OSCORE
[I-D.ietf-core-object-security]. The (6LBR) pledge plays the role of [I-D.ietf-core-object-security]. The (6LBR) acts as a CoAP client;
a CoAP client; the JRC plays the role of a CoAP server. The JP the JRC acts as a CoAP server. The JP implements CoAP forward proxy
implements CoAP forward proxy functionality [RFC7252]. Because the functionality [RFC7252]. Because the JP can also be a constrained
JP can also be a constrained device, it cannot implement a cache. If device, it cannot implement a cache.
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.
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.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
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
state, needed to forward the Join Response message to the pledge.
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. Statelessness of the JP
The CoAP proxy defined in [RFC7252] keeps per-client state
information in order to forward the response towards the originator
of the request. This state information includes at least the CoAP
token, the IPv6 address of the client, and the UDP source port
number. Since the JP can be a constrained device that acts as a CoAP
proxy, memory limitations make it prone to Denial-of-Service (DoS)
attacks.
The DoS risk on the JP can be mitigated by making the JP act as a
stateless CoAP proxy. The JP can wrap the state it needs to keep for
a given pledge throughout the network stack in a "state object" and
include it as a CoAP token in the forwarded request to the JRC (i.e.
origin server). The JP may use the CoAP token as defined in
[RFC7252], if the size of the serialized state object permits, or use
the extended CoAP token being defined in [I-D.hartke-core-stateless].
Since the CoAP token is echoed back in the response, the JP is able
to decode the token and configure the state needed to forward the
response to the pledge. The information that the JP needs to encode
in the state object to operate in a fully stateless manner with
respect to a given pledge is implementation specific. In all cases,
the state object communicated in the token SHOULD be integrity
protected, with a key that is known only to the JP, and SHOULD
include a freshness indicator. It is RECOMMENDED that the JP
operates in a stateless manner and signals the per-pledge state
within the CoAP token, for every request it forwards into the network
on behalf of unauthenticated pledges.
Note, however, that in some networking stack implementations, a fully
stateless operation of the JP may be challenging from the
implementation point of view. In those cases, the JP may operate as
a statefull proxy that stores the per-pledge state until the response
is received or timed out, but this comes at an increased risk of DoS
attacks.
8.2. OSCORE Security Context
Before the (6LBR) pledge and the JRC may start exchanging CoAP Before the (6LBR) pledge and the JRC may start exchanging CoAP
messages protected with OSCORE, they need to derive the OSCORE messages protected with OSCORE, they need to derive the OSCORE
security context from the parameters provisioned out-of-band, as security context from the parameters provisioned out-of-band, as
discussed in Section 4. discussed in Section 4.
The OSCORE security context MUST be derived as per Section 3 of The OSCORE security context MUST be derived as per Section 3 of
[I-D.ietf-core-object-security]. [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 empty. o the Master Salt MUST be the empty byte string.
o the ID of the pledge MUST be set to the byte string 0x00. This 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 identifier is used as the OSCORE Sender ID of the pledge in the
derivation, as the pledge initially plays the role of a CoAP security context derivation, as the pledge initially acts as a
client. CoAP client.
o the ID of the JRC MUST be set to the byte string 0x4a5243 ("JRC" 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 in ASCII). This identifier is used as the OSCORE Recipient ID of
the security context derivation, as the JRC initially plays the the pledge in the security context derivation, as the JRC
role of a CoAP server. initially acts as a CoAP server.
o the ID Context MUST be set to the pledge identifier. 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
constructed by XOR'ing the common IV with the current sequence number constructed by XOR'ing the common IV with the current sequence number
and sender identifier. For details on nonce construction, refer to and sender identifier. For details on nonce construction, refer to
[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 are properly incrementing the sequence numbers in the OSCORE
sequence numbers are properly incremented for each request. The security context for each message, so that the same sequence number
pledge typically sends requests to different JRCs if it is not is never reused in distinct requests. The pledge typically sends
provisioned with the network identifier and attempts to join one requests to different JRCs if it is not provisioned with the network
network at a time. A simple implementation technique is to identifier and attempts to join one network at a time. A simple
instantiate the OSCORE security context with a given PSK only once implementation technique is to instantiate the OSCORE security
and use it for all subsequent requests. Failure to comply will break context with a given PSK only once and use it for all subsequent
the confidentiality property of the Authenticated Encryption with requests. Failure to comply will break the security guarantees of
Associated Data (AEAD) algorithm due to the nonce reuse. the Authenticated Encryption with Associated Data (AEAD) algorithm
due to the nonce reuse.
This OSCORE security context is used for initial joining of the This OSCORE security context is used for initial joining of the
(6LBR) pledge, where the (6LBR) pledge acts as a CoAP client, as well (6LBR) pledge, where the (6LBR) pledge acts as a CoAP client, as well
as for any later parameter updates, where the JRC acts as a CoAP as for any later parameter updates, where the JRC acts as a CoAP
client and the joined node as a CoAP server, as discussed in client and the joined node as a CoAP server, as discussed in
Section 9.2. A (6LBR) pledge is expected to have exactly one OSCORE Section 9.2. The (6LBR) pledge and the JRC use the OSCORE security
security context with the JRC. context parameters (e.g. sender and recipient identifiers) as they
were used at the moment of context derivation, regardless of whether
they currently act as a CoAP client or a CoAP server. A (6LBR)
pledge is expected to have exactly one OSCORE security context with
the JRC.
8.1.1. Persistency 8.2.1. Replay Window and Persistency
Both (6LBR) pledge and the JRC MUST implement a replay protection
mechanism. The use of the default OSCORE replay protection mechanism
specified in Section 3.2.2 of [I-D.ietf-core-object-security] is
RECOMMENDED.
Implementations MUST ensure that mutable OSCORE context parameters Implementations MUST ensure that mutable OSCORE context parameters
(Sender Sequence Number, Replay Window) are stored in persistent (Sender Sequence Number, Replay Window) are stored in persistent
memory. A technique that prevents reuse of sequence numbers, memory. A technique that prevents reuse of sequence numbers,
detailed in Section 6.5.1 of [I-D.ietf-core-object-security], MUST be detailed in Section 7.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 (6LBR) pledge and the JRC is rare, rejoins. Traffic between the (6LBR) pledge and the JRC is rare,
making security outweigh the cost of writing to persistent memory. making security outweigh the cost of writing to persistent memory.
9. Constrained Join Protocol (CoJP) 9. Constrained Join Protocol (CoJP)
skipping to change at page 15, line 37 skipping to change at page 16, line 37
protection, and a secure binding of responses to requests. protection, and a secure binding of responses to requests.
+-----------------------------------+ +-----------------------------------+
| Constrained Join Protocol (CoJP) | | Constrained Join Protocol (CoJP) |
+-----------------------------------+ +-----------------------------------+
+-----------------------------------+ \ +-----------------------------------+ \
| Requests / Responses | | | Requests / Responses | |
|-----------------------------------| | |-----------------------------------| |
| OSCORE | | CoAP | OSCORE | | CoAP
|-----------------------------------| | |-----------------------------------| |
| Messaging Layer / Message Framing | | | Messaging Layer | |
+-----------------------------------+ / +-----------------------------------+ /
+-----------------------------------+ +-----------------------------------+
| UDP | | UDP |
+-----------------------------------+ +-----------------------------------+
Figure 2: Abstract layering of CoJP. Figure 2: Abstract layering of CoJP.
When a (6LBR) pledge requests admission to a given network, it When a (6LBR) pledge requests admission to a given network, it
undergoes the CoJP join exchange that consists of: undergoes the CoJP join exchange that consists of:
skipping to change at page 16, line 29 skipping to change at page 17, line 29
message and its mapping to CoAP is specified in Section 9.2.1. message and its mapping to CoAP is specified in Section 9.2.1.
o the Parameter Update Response message, sent by the joined node to o the Parameter Update Response message, sent by the joined node to
the JRC in response to the Parameter Update message to signal the JRC in response to the Parameter Update message to signal
successful reception of the updated parameters. The Parameter successful reception of the updated parameters. The Parameter
Update Response message and its mapping to CoAP is specified in Update Response message and its mapping to CoAP is specified in
Section 9.2.2. Section 9.2.2.
The payload of CoJP messages is encoded with CBOR [RFC7049]. The The payload of CoJP messages is encoded with CBOR [RFC7049]. The
CBOR data structures that may appear as the payload of different CoJP CBOR data structures that may appear as the payload of different CoJP
messages are specified in Section 9.3. messages are specified in Section 9.4.
9.1. Join Exchange 9.1. Join Exchange
This section specifies the messages exchanged when the (6LBR) pledge This section specifies the messages exchanged when the (6LBR) pledge
requests admission and configuration parameters from the JRC. requests admission and configuration parameters from the JRC.
9.1.1. Join Request Message 9.1.1. Join Request Message
The Join Request message SHALL be mapped to a CoAP request: The Join Request message SHALL be mapped to a CoAP request:
skipping to change at page 17, line 7 skipping to change at page 18, line 7
o The Proxy-Scheme option is set to "coap". o The Proxy-Scheme option is set to "coap".
o The Uri-Host option is set to "6tisch.arpa". This is an anycast o The Uri-Host option is set to "6tisch.arpa". This is an anycast
type of identifier of the JRC that is resolved to its IPv6 address type of identifier of the JRC that is resolved to its IPv6 address
by the JP or the 6LBR pledge. by the JP or the 6LBR pledge.
o The Uri-Path option is set to "j". o The Uri-Path option is set to "j".
o The 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 kid context is set is the one derived in Section 8.2. The OSCORE kid context 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 Join_Request CBOR object, as defined in o The payload is a Join_Request CBOR object, as defined in
Section 9.3.1. Section 9.4.1.
9.1.2. Join Response Message 9.1.2. Join Response Message
The Join Response message that the JRC sends SHALL be mapped to a The Join Response message that the JRC sends SHALL be mapped to a
CoAP response: CoAP response:
o The response Code is 2.04 (Changed). o The response Code is 2.04 (Changed).
o The payload is a Configuration CBOR object, as defined in o The payload is a Configuration CBOR object, as defined in
Section 9.3.2. Section 9.4.2.
9.1.3. Error Handling and Retransmission 9.2. Parameter Update Exchange
During the network lifetime, parameters returned as part of the Join
Response may need to be updated. One typical example is the update
of link-layer keying material for the network, a process known as
rekeying. This section specifies a generic mechanism when this
parameter update is initiated by the JRC.
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.
Instead, once the (6LBR) pledge receives and successfully validates
the Join Response and so becomes a joined node, it becomes a CoAP
server. The joined node exposes the "/j" resource that is used by
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.2. 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.4.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.
In case the JRC does not receive a response to a Parameter Update
message, it will attempt multiple retransmissions, as configured by
the underlying CoAP retransmission mechanism triggered for
confirmable messages. Finally, if the CoAP implementation declares
that the destination is unreachable, the JRC may consider this as a
hint that the joined node is no longer in the network. How JRC
decides when to stop managing a given joined node is out of scope of
this specification but security considerations on the reuse of
assigned resources apply, as discussed in Section 10.
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. Error Handling
9.3.1. OSCORE Error Handling and Retransmission
This section describes handling of errors raised by the underlying
OSCORE.
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 18, line 13 skipping to change at page 20, line 36
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.4. Section 9.5.
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.2. Parameter Update Exchange 9.3.2. CoJP CBOR Object Processing
During the network lifetime, parameters returned as part of the Join
Response may need to be updated. One typical example is the update
of link-layer keying material for the network, a process known as
rekeying. This section specifies a generic mechanism when this
parameter update is initiated by the JRC.
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.
Instead, once the (6LBR) pledge receives and successfully validates This section describes error handling when processing CoJP CBOR
the Join Response and so becomes a joined node, it switches its CoAP objects that are transported within the payload of different CoJP
role and becomes a server. The joined node exposes the "/j" resource messages. See Section 9.3.1 for the handling of errors that may be
that is used by the JRC to update the parameters. Consequently, the raised by the underlying OSCORE implementation.
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 CoJP CBOR objects are transported both within CoAP requests and
responses. When an error is detected while processing CoJP objects
in a CoAP request (Join Request message, Parameter Update message),
Error Response message MUST be returned. Error Response message maps
to a CoAP response and is specified in Section 9.3.3.
The Parameter Update message that the JRC sends to the joined node When an error is detected while processing a CoJP object in a CoAP
SHALL be mapped to a CoAP request: response (Join Response message), a (6LBR) pledge SHOULD reattempt to
join. In this case, the (6LBR) pledge SHOULD enclose an Error CBOR
object within the Join Request object in the following Join Request
message. A (6LBR) pledge MUST NOT attempt more than MAX_RETRANSMIT
number of attempts to join if the processing of the Join Response
message fails. If MAX_RETRANSMIT number of attempts is reached
without success, the (6LBR) pledge SHOULD signal to the user the
presence of an error condition, through some out-of-band mechanism.
o The request method is POST. 9.3.3. Error Response Message
o The type is Confirmable (CON). The Error Response Message is returned for any CoJP request when the
processing of the payload failed. Note that the Error Response
message is protected by OSCORE as any other CoJP protocol message.
o The Uri-Path option is set to "j". The Error Response message SHALL be mapped to a CoAP response:
o The Object-Security option SHALL be set according to o The response Code is 4.00 (Bad Request).
[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 o The payload is an Error CBOR object, as defined in Section 9.4.5,
Section 9.3.2. containing the error code that triggered the sending of this
message.
The JRC has implicit knowledge on the global IPv6 address of the 9.3.4. Failure Handling
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 exchange may be triggered at any time during the
network lifetime that may span several years. During this period, it
may occur that a joined node or the JRC experience unexpected events
such as reboots or complete failures.
The Parameter Update Response message that the joined node sends to This document mandates that the mutable parameters in the security
the JRC SHALL be mapped to a CoAP response: context are written to persistent memory (see Section 8.2.1) by both
the JRC and pledges (joined nodes). In case of a reboot on either
side, the retrieval of mutable security context parameters is
feasible from the persistent memory such that there is no risk of
AEAD nonce reuse due to a reinitialized Sender Sequence number, or of
a replay attack due to the reinitialized replay window.
o The response Code is 2.04 (Changed). In the case of a complete failure, where the mutable security context
parameters cannot be retrieved, it is expected that a failed joined
node is replaced with a new physical device, using a new pledge
identifier and a PSK. When such an event occurs at the JRC, it is
likely that the information about joined nodes, their assigned short
identifiers and mutable security context parameters is lost. If this
is the case, during the process of JRC replacement, the network
administrator MUST force all the networks managed by the failed JRC
to rejoin, through e.g. the reinitialization of the 6LBR nodes.
Since the joined nodes kept track of their mutable security context
parameters, they will use these during the (re)join exchange without
a risk of AEAD nonce reuse. However, even after all the nodes
rejoined, an AEAD nonce reuse risk exists during the first Parameter
Update exchange, as the new JRC does not possess the last Sender
Sequence number used, and can only initialize it to zero. Since the
loss of security properties including confidentiality for this
message is likely the JRC MUST limit the information that may be
exposed within.
o The payload is empty. When such a message arrives at the joined node, the OSCORE
implementation rejects it due to the Partial IV being largely below
the acceptable replay window state. When this is detected, the
joined node MUST send an Error Response message with error code set
to "Invalid parameter: OSCORE partial IV" from Table 4 and Additional
information set to the next Partial IV it will expect. When
protecting this error response by OSCORE, the joined node MUST use
the value of its Sender Sequence number to generate the Partial IV
and include it in the CoAP OSCORE option, as specified by
[I-D.ietf-core-object-security]. Upon successful OSCORE verification
of the received CoJP message, the JRC processes the error response
and configures the Sender Sequence number to the one indicated in the
Additional information field. The next Parameter Update exchange
triggered by the JRC will therefore use the proper Sender Sequence
number and will be accepted by the joined node.
9.3. CoJP Objects 9.4. CoJP Objects
This section specifies the structure of CoJP CBOR objects that may be This section specifies the structure of CoJP CBOR objects that may be
carried as the payload of CoJP messages. Some of these objects may carried as the payload of CoJP messages. Some of these objects may
be received both as part of the CoJP join exchange when the device be received both as part of the CoJP join exchange when the device
operates as a (CoJP) pledge, or the parameter update exchange, when operates as a (CoJP) pledge, or the parameter update exchange, when
the device operates as a joined (6LBR) node. the device operates as a joined (6LBR) node.
9.3.1. Join Request Object 9.4.1. Join Request Object
The Join_Request structure is built on a CBOR map object. The Join_Request structure is built on a CBOR map object.
The set of parameters that can appear in a Join_Request object is The set of parameters that can appear in a Join_Request object is
summarized below. The defined labels can be found below, the details summarized below. The labels can be found in "CoJP Parameters"
of this registry are in section "CoJP Parameters" registry registry Section 12.1, initially populated with the values from
Section 13.2. Table 2.
o role: The identifier of the role that the pledge requests to play o role: The identifier of the role that the pledge requests to play
in the network once it joins, encoded as an unsigned integer. in the network once it joins, encoded as an unsigned integer.
Possible values are specified in Table 1. This parameter MAY be Possible values are specified in Table 1. This parameter MAY be
included. In case the parameter is omitted, the default value of included. In case the parameter is omitted, the default value of
0, i.e. the role "6TiSCH Node", MUST be assumed. 0, i.e. the role "6TiSCH Node", MUST be assumed.
o network identifier: The identifier of the network, as discussed in o network identifier: The identifier of the network, as discussed in
Section 3, encoded as a CBOR byte string. This parameter may Section 3, encoded as a CBOR byte string. This parameter may
appear both in the Join Request and in the Join Response. When appear both in the Join_Request and in the Configuration objects.
present in the Join Request, it hints to the JRC the network that When present in the Join_Request, it hints to the JRC the network
the pledge is requesting to join, enabling the JRC to manage that the pledge is requesting to join, enabling the JRC to manage
multiple networks. The pledge obtains the value of the network multiple networks. The pledge obtains the value of the network
identifier from the received EB frames. This parameter MUST be identifier from the received EB frames. This parameter MUST be
included in a Join_Request object if the role parameter is set to included in a Join_Request object if the role parameter is set to
"6TiSCH Node". This parameter MAY be included if the role "6TiSCH Node". This parameter MAY be included if the role
parameter is set to "6LBR". The inclusion of this parameter by parameter is set to "6LBR". The inclusion of this parameter by
the 6LBR pledge depends on whether the parameter was exchanged the 6LBR pledge depends on whether the parameter was exchanged
during the one-touch process, which in turn depends on the during the one-touch process, which in turn depends on the
operational constraints. operational constraints.
o response processing error: The identifier of the error from the
previous join attempt, encoded as an Error object described in
Section 9.4.5. This parameter MAY be included. If a (6LBR)
pledge previously attempted to join and received a valid Join
Response message over OSCORE but failed to process its payload
(Configuration object), it SHOULD include this parameter to
facilitate the debugging process.
The CDDL fragment that represents the text above for the Join_Request The CDDL fragment that represents the text above for the Join_Request
follows. follows.
Join_Request = { Join_Request = {
? 1 : uint ; role ? 1 : uint, ; role
? 5 : bstr ; network identifier ? 5 : bstr, ; network identifier
? 7 : Error, ; response processing error
} }
+--------+-------+-------------------------------------+------------+ +--------+-------+-------------------------------------+------------+
| Name | Value | Description | Reference | | Name | Value | Description | Reference |
+--------+-------+-------------------------------------+------------+ +--------+-------+-------------------------------------+------------+
| 6TiSCH | 0 | The pledge requests to play the | [[this | | 6TiSCH | 0 | The pledge requests to play the | [[this |
| Node | | role of a regular 6TiSCH node, i.e. | document]] | | Node | | role of a regular 6TiSCH node, i.e. | document]] |
| | | non-6LBR node. | | | | | non-6LBR node. | |
| | | | | | | | | |
| 6LBR | 1 | The pledge requests to play the | [[this | | 6LBR | 1 | The pledge requests to play the | [[this |
| | | role of 6LoWPAN Border Router | document]] | | | | role of 6LoWPAN Border Router | document]] |
| | | (6LBR). | | | | | (6LBR). | |
+--------+-------+-------------------------------------+------------+ +--------+-------+-------------------------------------+------------+
Table 1: Role values. Table 1: Role values.
9.3.2. Configuration Object 9.4.2. Configuration Object
The Configuration structure is built on a CBOR map object. The set The Configuration structure is built on a CBOR map object. The set
of parameters that can appear in a Configuration object is summarized of parameters that can appear in a Configuration object is summarized
below. The defined labels can be found below, the details of this below. The labels can be found in "CoJP Parameters" registry
registry are in section "CoJP Key Usage Registry" Section 13.3. Section 12.1, initially populated with the values from Table 2.
o link-layer key set: An array encompassing a set of cryptographic o link-layer key set: An array encompassing a set of cryptographic
keys and their identifiers that are currently in use in the keys and their identifiers that are currently in use in the
network, or that are scheduled to be used in the future. The network, or that are scheduled to be used in the future. The
encoding of individual keys is described in Section 9.3.2.1. The encoding of individual keys is described in Section 9.4.3. The
link-layer key set parameter MAY be included in a Configuration link-layer key set parameter MAY be included in a Configuration
object. When present, the link-layer key set parameter MUST object. When present, the link-layer key set parameter MUST
contain at least one key. How the keys are installed and used contain at least one key. How the keys are installed and used
differs for the 6LBR and other nodes. When 6LBR receives this differs for the 6LBR and other nodes. When 6LBR receives this
parameter, it MUST remove any old keys it has installed from the parameter, it MUST remove any old keys it has installed from the
previous key set and immediately install and start using the new previous key set and immediately install and start using the new
keys for all outgoing and incoming traffic. When a non-6LBR node keys for all outgoing and incoming traffic. When a non-6LBR node
receives this parameter, it MUST install the keys, use them for receives this parameter, it MUST install the keys, use them for
any incoming traffic matching the key identifier, but keep using any incoming traffic matching the key identifier, but keep using
the old keys for all outgoing traffic. A non-6LBR node accepts the old keys for all outgoing traffic. A non-6LBR node accepts
skipping to change at page 21, line 38 skipping to change at page 24, line 51
have been provisioned with the new keys, then the JRC updates the 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. In the special case when the JRC is co-located with the
6LBR, it can simply trigger the sending of a new broadcast frame 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 (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 goes out with the new key, and upon reception and successful
security processing of the new frame all receiving nodes will security processing of the new frame all receiving nodes will
switch to the new active keys. Outgoing traffic from those nodes switch to the new active keys. Outgoing traffic from those nodes
will then use the new key, which causes an update of additional will then use the new key, which causes an update of additional
peers, and the network will switch over in a flood-fill fashion. 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 o short identifier: a compact identifier assigned to the pledge.
to the pledge. The short address structure is described in The short identifier structure is described in Section 9.4.4. The
Section 9.3.2.2. The link-layer short address parameter MAY be short identifier parameter MAY be included in a Configuration
included in a Configuration object. When a node receives this object.
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 o JRC address: the IPv6 address of the JRC, encoded as a byte
string, with the length of 16 bytes. If the length of the byte string, with the length of 16 bytes. If the length of the byte
string is different than 16, the parameter MUST be discarded. If 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 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 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 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 same IPv6 address as the 6LBR, this parameter MAY be included. If
the JRC address parameter is not present in the Join Response, the JRC address parameter is not present in the Configuration
this indicates that the JRC has the same IPv6 address as the 6LBR. object, this indicates that the JRC has the same IPv6 address as
The joined node can then discover the IPv6 address of the JRC the 6LBR. The joined node can then discover the IPv6 address of
through network control traffic. See Section 7. the JRC through network control traffic. See Section 7.
o network identifier: the identifier of the network, as discussed in o network identifier: the identifier of the network, as discussed in
Section 3, encoded as a byte string. When present in the Join Section 3, encoded as a byte string. When present in the
Response, this parameter is only valid when received by the 6LBR Configuration object, this parameter is only valid when received
pledge. The parameter indicates to the 6LBR the value of the by the 6LBR pledge. The parameter indicates to the 6LBR the value
network identifier it should advertise at the link layer. This of the network identifier it should advertise at the link layer.
parameter MUST NOT be included in the Join Response if the role This parameter MUST NOT be included in the Configuration object if
parameter from the corresponding Join Request indicated 0, i.e. the role parameter from the corresponding Join_Request object
the role "6TiSCH Node". In the case where the corresponding indicated 0, i.e. the role "6TiSCH Node". In the case where the
Join_Request object does not contain the network identifier corresponding Join_Request object does not contain the network
parameter, this parameter MUST be included. When the identifier parameter, this parameter MUST be included. When the
corresponding Join_Request object does contain the network corresponding Join_Request object does contain the network
identifier parameter, this parameter MAY be included in the identifier parameter, this parameter MAY be included in the
Configuration object. This may happen if the JRC decides to Configuration object. This may happen if the JRC decides to
overwrite the network identifier provisioned during the one-touch overwrite the network identifier provisioned during the one-touch
process. The value of the network identifier parameter from the process. The value of the network identifier parameter from the
Configuration object SHOULD take precedence over the value Configuration object SHOULD take precedence over the value
provisioned during the one-touch process. provisioned during the one-touch process.
o network prefix: the IPv6 network prefix, encoded as a byte string. o network prefix: the IPv6 network prefix, encoded as a byte string.
The length of the byte string determines the prefix length. This The length of the byte string determines the prefix length. This
parameter is only valid when received by the 6LBR pledge. The parameter is only valid when received by the 6LBR pledge. The
parameter indicates to the 6LBR the value of the IPv6 network parameter indicates to the 6LBR the value of the IPv6 network
prefix. This parameter MAY be included in the Join Response if prefix. This parameter MAY be included in the Configuration
the role parameter from the corresponding Join_Request object object if the role parameter from the corresponding Join_Request
indicated 1, i.e. the role "6LBR". This parameter MUST NOT be object indicated 1, i.e. the role "6LBR". This parameter MUST NOT
included in the Join Response if the role parameter from the be included in the Configuration object if the role parameter from
corresponding Join_Request object indicated 0, i.e. the role the corresponding Join_Request object indicated 0, i.e. the role
"6TiSCH Node". "6TiSCH Node".
The CDDL fragment that represents the text above for the The CDDL fragment that represents the text above for the
Configuration follows. Structures Link_Layer_Key and Short_Address Configuration follows. Structures Link_Layer_Key and
are specified in Section 9.3.2.1 and Section 9.3.2.2. Short_Identifier are specified in Section 9.4.3 and Section 9.4.4.
Configuration = { Configuration = {
? 2 : [ +Link_Layer_Key ], ; link-layer key set ? 2 : [ +Link_Layer_Key ], ; link-layer key set
? 3 : Short_Address, ; link-layer short address ? 3 : Short_Identifier, ; short identifier
? 4 : bstr ; JRC address ? 4 : bstr ; JRC address
? 5 : bstr ; network identifier ? 5 : bstr ; network identifier
? 6 : bstr ; network prefix ? 6 : bstr ; network prefix
} }
+------------+-------+----------+----------------------+------------+ +------------+-------+----------+----------------------+------------+
| Name | Label | CBOR | Description | Reference | | Name | Label | CBOR | Description | Reference |
| | | type | | | | | | type | | |
+------------+-------+----------+----------------------+------------+ +------------+-------+----------+----------------------+------------+
| role | 1 | unsigned | Identifies the role | [[this | | role | 1 | unsigned | Identifies the role | [[this |
| | | integer | parameter. | document]] | | | | integer | parameter. | document]] |
| | | | | | | | | | | |
| link-layer | 2 | array | Identifies the array | [[this | | link-layer | 2 | array | Identifies the array | [[this |
| key set | | | carrying one or more | document]] | | key set | | | carrying one or more | document]] |
| | | | link-level | | | | | | link-level | |
skipping to change at page 23, line 16 skipping to change at page 26, line 25
| | | type | | | | | | type | | |
+------------+-------+----------+----------------------+------------+ +------------+-------+----------+----------------------+------------+
| role | 1 | unsigned | Identifies the role | [[this | | role | 1 | unsigned | Identifies the role | [[this |
| | | integer | parameter. | document]] | | | | integer | parameter. | document]] |
| | | | | | | | | | | |
| link-layer | 2 | array | Identifies the array | [[this | | link-layer | 2 | array | Identifies the array | [[this |
| key set | | | carrying one or more | document]] | | key set | | | carrying one or more | document]] |
| | | | link-level | | | | | | link-level | |
| | | | cryptographic keys. | | | | | | cryptographic keys. | |
| | | | | | | | | | | |
| link-layer | 3 | array | Identifies the | [[this | | short | 3 | array | Identifies the | [[this |
| short | | | assigned link-layer | document]] | | identifier | | | assigned short | document]] |
| address | | | short address | | | | | | identifier | |
| | | | | | | | | | | |
| JRC | 4 | byte | Identifies the IPv6 | [[this | | JRC | 4 | byte | Identifies the IPv6 | [[this |
| address | | string | address of the JRC | document]] | | address | | string | address of the JRC | document]] |
| | | | | | | | | | | |
| network | 5 | byte | Identifies the | [[this | | network | 5 | byte | Identifies the | [[this |
| identifier | | string | network identifier | document]] | | identifier | | string | network identifier | document]] |
| | | | parameter | | | | | | parameter | |
| | | | | | | | | | | |
| network | 6 | byte | Identifies the IPv6 | [[this | | network | 6 | byte | Identifies the IPv6 | [[this |
| prefix | | string | prefix of the | document]] | | prefix | | string | prefix of the | document]] |
| | | | network | | | | | | network | |
| | | | | |
| error | 7 | array | Identifies the error | [[this |
| | | | parameter | document]] |
+------------+-------+----------+----------------------+------------+ +------------+-------+----------+----------------------+------------+
Table 2: Join Response map labels. Table 2: CoJP parameters map labels.
9.3.2.1. Link-Layer Key 9.4.3. Link-Layer Key
The Link_Layer_Key structure encompasses the parameters needed to The Link_Layer_Key structure encompasses the parameters needed to
configure the link-layer security module: the value of the configure the link-layer security module: the key identifier; the
cryptographic key, the key identifier, the link-layer algorithm value of the cryptographic key; the link-layer algorithm identifier
identifier, and the security level and the frame types that it should and the security level and the frame types that it should be used
be used with, both for outgoing and incoming security operations. with, both for outgoing and incoming security operations; and any
additional information that may be needed to configure the key.
For encoding compactness, Link_Layer_Key object is not enclosed in a For encoding compactness, Link_Layer_Key object is not enclosed in a
top-level CBOR object. Rather, it is transported as a consecutive top-level CBOR object. Rather, it is transported as a sequence of
group of CBOR elements, with some being optional. To be able to CBOR elements, with some being optional.
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 The set of parameters that can appear in a Link_Layer_Key object is
summarized below, in order: summarized below, in order:
o key_index: The identifier of the key, encoded as a CBOR unsigned o key_id: The identifier of the key, encoded as a CBOR unsigned
integer. This parameter MUST be included. The parameter uniquely integer. This parameter MUST be included. If the decoded CBOR
identifies the key and is used to retrieve the key for incoming unsigned integer value is larger than the maximum link-layer key
traffic. In case of [IEEE802.15.4], the decoded CBOR unsigned identifier, the key is considered invalid. In case the key is
integer value sets the "secKeyIndex" parameter that is signaled in considered invalid, the implementation MUST discard the key and
all outgoing and incoming frames secured with this key. If the attempt to decode the next key in the array.
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 o key_usage: The identifier of the link-layer algorithm, security
level and link-layer frame types that can be used with the key, level and link-layer frame types that can be used with the key,
encoded as a CBOR unsigned or negative integer. This parameter encoded as a CBOR unsigned or negative integer. This parameter
MAY be included. Possible values and the corresponding link-layer MAY be included. Possible values and the corresponding link-layer
settings are specified in IANA "CoJP Key Usage" registry settings are specified in IANA "CoJP Key Usage" registry
(Section 13.3). In case the parameter is omitted, the default (Section 12.2). In case the parameter is omitted, the default
value of 0 from Table 3 MUST be assumed. value of 0 from Table 3 MUST be assumed.
o key_value: The value of the cryptographic key, encoded as a byte o key_value: The value of the cryptographic key, encoded as a byte
string. This parameter MUST be included. If the length of the string. This parameter MUST be included. If the length of the
byte string is different than the corresponding key length for a byte string is different than the corresponding key length for a
given algorithm specified by the key_usage parameter, the key MUST given algorithm specified by the key_usage parameter, the key MUST
be discarded and the decoder should attempt to decode the next key be discarded and the decoder should attempt to decode the next key
in the array. in the array.
o key_addinfo: Additional information needed to configure the link-
layer key, encoded as a byte string. This parameter MAY be
included. The processing of this parameter is dependent on the
link-layer technology in use and a particular keying mode.
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, a uint that follows a byte
string signals to the decoder that a new Link_Layer_Key object is
being processed.
The CDDL fragment that represents the text above for the The CDDL fragment that represents the text above for the
Link_Layer_Key follows. Link_Layer_Key follows.
Link_Layer_Key = ( Link_Layer_Key = (
key_index : uint, key_id : uint,
? key_usage : uint / nint, ? key_usage : uint / nint,
key_value : bstr, key_value : bstr,
? key_addinfo : bstr,
) )
+------------------+-----+-----------------+-------------+----------+ +-----------------+-----+------------------+-------------+----------+
| Name | Val | Algorithm | Description | Referenc | | Name | Val | Algorithm | Description | Referenc |
| | ue | | | e | | | ue | | | e |
+------------------+-----+-----------------+-------------+----------+ +-----------------+-----+------------------+-------------+----------+
| 6TiSCH-K1K2-ENC- | 0 | IEEE802154-AES- | Use MIC-32 | [[this d | | 6TiSCH-K1K2 | 0 | IEEE802154-AES- | Use MIC-32 | [[this d |
| MIC-32 | | CCM-128 | for EBs, | ocument] | | -ENC-MIC32 | | CCM-128 | for EBs, | ocument] |
| | | | ENC-MIC-32 | ] | | | | | ENC-MIC-32 | ] |
| | | | for DATA | | | | | | for DATA | |
| | | | and ACKNOWL | | | | | | and ACKNOWL | |
| | | | EDGMENT. | | | | | | EDGMENT. | |
| | | | | | | | | | | |
| 6TiSCH-K1K2-ENC- | 1 | IEEE802154-AES- | Use MIC-64 | [[this d | | 6TiSCH-K1K2 | 1 | IEEE802154-AES- | Use MIC-64 | [[this d |
| MIC-64 | | CCM-128 | for EBs, | ocument] | | -ENC-MIC64 | | CCM-128 | for EBs, | ocument] |
| | | | ENC-MIC-64 | ] | | | | | ENC-MIC-64 | ] |
| | | | for DATA | | | | | | for DATA | |
| | | | and ACKNOWL | | | | | | and ACKNOWL | |
| | | | EDGMENT. | | | | | | EDGMENT. | |
| | | | | | | | | | | |
| 6TiSCH-K1K2-ENC- | 2 | IEEE802154-AES- | Use MIC-128 | [[this d | | 6TiSCH-K1K2 | 2 | IEEE802154-AES- | Use MIC-128 | [[this d |
| MIC-128 | | CCM-128 | for EBs, | ocument] | | -ENC-MIC128 | | CCM-128 | for EBs, | ocument] |
| | | | ENC-MIC-128 | ] | | | | | ENC-MIC-128 | ] |
| | | | for DATA | | | | | | for DATA | |
| | | | and ACKNOWL | | | | | | and ACKNOWL | |
| | | | EDGMENT. | | | | | | EDGMENT. | |
| | | | | | | | | | | |
| 6TiSCH- | 3 | IEEE802154-AES- | Use MIC-32 | [[this d | | 6TiSCH- | 3 | IEEE802154-AES- | Use MIC-32 | [[this d |
| K1K2-MIC-32 | | CCM-128 | for EBs, | ocument] | | K1K2-MIC32 | | CCM-128 | for EBs, | ocument] |
| | | | DATA and AC | ] | | | | | DATA and AC | ] |
| | | | KNOWLEDGMEN | | | | | | KNOWLEDGMEN | |
| | | | T. | | | | | | T. | |
| | | | | | | | | | | |
| 6TiSCH- | 4 | IEEE802154-AES- | Use MIC-64 | [[this d | | 6TiSCH- | 4 | IEEE802154-AES- | Use MIC-64 | [[this d |
| K1K2-MIC-64 | | CCM-128 | for EBs, | ocument] | | K1K2-MIC64 | | CCM-128 | for EBs, | ocument] |
| | | | DATA and AC | ] | | | | | DATA and AC | ] |
| | | | KNOWLEDGMEN | | | | | | KNOWLEDGMEN | |
| | | | T. | | | | | | T. | |
| | | | | | | | | | | |
| 6TiSCH- | 5 | IEEE802154-AES- | Use MIC-128 | [[this d | | 6TiSCH- | 5 | IEEE802154-AES- | Use MIC-128 | [[this d |
| K1K2-MIC-128 | | CCM-128 | for EBs, | ocument] | | K1K2-MIC128 | | CCM-128 | for EBs, | ocument] |
| | | | DATA and AC | ] | | | | | DATA and AC | ] |
| | | | KNOWLEDGMEN | | | | | | KNOWLEDGMEN | |
| | | | T. | | | | | | T. | |
| | | | | | | | | | | |
| 6TiSCH-K1-MIC-32 | 6 | IEEE802154-AES- | Use MIC-32 | [[this d | | 6TiSCH-K1-MIC32 | 6 | IEEE802154-AES- | Use MIC-32 | [[this d |
| | | CCM-128 | for EBs. | ocument] | | | | CCM-128 | for EBs. | ocument] |
| | | | | ] | | | | | | ] |
| | | | | | | | | | | |
| 6TiSCH-K1-MIC-64 | 7 | IEEE802154-AES- | Use MIC-64 | [[this d | | 6TiSCH-K1-MIC64 | 7 | IEEE802154-AES- | Use MIC-64 | [[this d |
| | | CCM-128 | for EBs. | ocument] | | | | CCM-128 | for EBs. | ocument] |
| | | | | ] | | | | | | ] |
| | | | | | | | | | | |
| 6TiSCH-K1-MIC-12 | 8 | IEEE802154-AES- | Use MIC-128 | [[this d | | 6TiSCH-K1-MIC12 | 8 | IEEE802154-AES- | Use MIC-128 | [[this d |
| 8 | | CCM-128 | for EBs. | ocument] | | 8 | | CCM-128 | for EBs. | ocument] |
| | | | | ] | | | | | | ] |
| | | | | | | | | | | |
| 6TiSCH-K2-MIC-32 | 9 | IEEE802154-AES- | Use MIC-32 | [[this d | | 6TiSCH-K2-MIC32 | 9 | IEEE802154-AES- | Use MIC-32 | [[this d |
| | | CCM-128 | for DATA | ocument] | | | | CCM-128 | for DATA | ocument] |
| | | | and ACKNOWL | ] | | | | | and ACKNOWL | ] |
| | | | EDGMENT. | | | | | | EDGMENT. | |
| | | | | | | | | | | |
| 6TiSCH-K2-MIC-64 | 10 | IEEE802154-AES- | Use MIC-64 | [[this d | | 6TiSCH-K2-MIC64 | 10 | IEEE802154-AES- | Use MIC-64 | [[this d |
| | | CCM-128 | for DATA | ocument] | | | | CCM-128 | for DATA | ocument] |
| | | | and ACKNOWL | ] | | | | | and ACKNOWL | ] |
| | | | EDGMENT. | | | | | | EDGMENT. | |
| | | | | | | | | | | |
| 6TiSCH-K2-MIC-12 | 11 | IEEE802154-AES- | Use MIC-128 | [[this d | | 6TiSCH-K2-MIC12 | 11 | IEEE802154-AES- | Use MIC-128 | [[this d |
| 8 | | CCM-128 | for DATA | ocument] | | 8 | | CCM-128 | for DATA | ocument] |
| | | | and ACKNOWL | ] | | | | | and ACKNOWL | ] |
| | | | EDGMENT. | | | | | | EDGMENT. | |
| | | | | | | | | | | |
| 6TiSCH-K2-ENC- | 12 | IEEE802154-AES- | Use ENC- | [[this d | | 6TiSCH-K2-ENC- | 12 | IEEE802154-AES- | Use ENC- | [[this d |
| MIC-32 | | CCM-128 | MIC-32 for | ocument] | | MIC32 | | CCM-128 | MIC-32 for | ocument] |
| | | | DATA and AC | ] | | | | | DATA and AC | ] |
| | | | KNOWLEDGMEN | | | | | | KNOWLEDGMEN | |
| | | | T. | | | | | | T. | |
| | | | | | | | | | | |
| 6TiSCH-K2-ENC- | 13 | IEEE802154-AES- | Use ENC- | [[this d | | 6TiSCH-K2-ENC- | 13 | IEEE802154-AES- | Use ENC- | [[this d |
| MIC-64 | | CCM-128 | MIC-64 for | ocument] | | MIC64 | | CCM-128 | MIC-64 for | ocument] |
| | | | DATA and AC | ] | | | | | DATA and AC | ] |
| | | | KNOWLEDGMEN | | | | | | KNOWLEDGMEN | |
| | | | T. | | | | | | T. | |
| | | | | | | | | | | |
| 6TiSCH-K2-ENC- | 14 | IEEE802154-AES- | Use ENC- | [[this d | | 6TiSCH-K2-ENC- | 14 | IEEE802154-AES- | Use ENC- | [[this d |
| MIC-128 | | CCM-128 | MIC-128 for | ocument] | | MIC128 | | CCM-128 | MIC-128 for | ocument] |
| | | | DATA and AC | ] | | | | | DATA and AC | ] |
| | | | KNOWLEDGMEN | | | | | | KNOWLEDGMEN | |
| | | | T. | | | | | | T. | |
+------------------+-----+-----------------+-------------+----------+ +-----------------+-----+------------------+-------------+----------+
Table 3: Key Usage values. Table 3: Key Usage values.
9.3.2.2. Short Address 9.4.3.1. Use in IEEE Std 802.15.4
The Short_Address object represents an address assigned to the pledge When Link_Layer_Key is used in the context of [IEEE802.15.4],
that is unique locally in the network. It is encoded as a CBOR array following considerations apply.
object, containing, in order:
o address: The assigned locally-unique address, encoded as a byte Signaling of different keying modes of [IEEE802.15.4] is done based
string. This parameter MUST be included. In case of on the parameter values present in a Link_Layer_Key object.
[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], o Key ID Mode 0x00 (Implicit, pairwise): key_id parameter MUST be
the value of this parameter is used to set the short address of set to 0. key_addinfo parameter MUST be present. key_addinfo
IEEE Std 802.15.4 module. In case the address is considered parameter MUST be set to the link-layer address(es) of a single
invalid, the decoder MUST silently ignore the Short_Address peer with whom the key should be used. Depending on the
configuration of the network, key_addinfo may carry the peer's
long link-layer address (i.e. pledge identifier), short link-layer
address, or their concatenation with the long address being
encoded first. Which address is carried is determined from the
length of the byte string.
o Key ID Mode 0x01 (Key Index): key_id parameter MUST be set to a
value different than 0. key_addinfo parameter MUST NOT be
present.
o Key ID Mode 0x02 (4-byte Explicit Key Source): key_id parameter
MUST be set to a value different than 0. key_addinfo parameter
MUST be present. key_addinfo parameter MUST be set to a byte
string, exactly 4 bytes long. key_addinfo parameter carries the
Key Source parameter used to configure [IEEE802.15.4].
o Key ID Mode 0x03 (8-byte Explicit Key Source): key_id parameter
MUST be set to a value different than 0. key_addinfo parameter
MUST be present. key_addinfo parameter MUST be set to a byte
string, exactly 8 bytes long. key_addinfo parameter carries the
Key Source parameter used to configure [IEEE802.15.4].
In all cases, key_usage parameter determines how a particular key
should be used in respect to incoming and outgoing security policies.
For Key ID Modes 0x01 - 0x03, parameter key_id sets the "secKeyIndex"
parameter of {{IEEE802.15.4} that is signaled in all outgoing frames
secured with a given key. The maximum value key_id can have is 254.
The value of 255 is reserved in {{IEEE802.15.4} and is therefore
considered invalid.
Key ID Mode 0x00 (Implicit, pairwise) enables the JRC to act as a
trusted third party and assign pairwise keys between nodes in the
network. How JRC learns about the network topology is out of scope
of this specification, but could be done through 6LBR - JRC signaling
for example. Pairwise keys could also be derived through a key
agreement protocol executed between the peers directly, where the
authentication is based on the symmetric cryptographic material
provided to both peers by the JRC. Such a protocol is out of scope
of this specification.
9.4.4. Short Identifier
The Short_Identifier object represents an identifier assigned to the
pledge. It is encoded as a CBOR array object, containing, in order:
o identifier: The short identifier assigned to the pledge, encoded
as a byte string. This parameter MUST be included. The
identifier MUST be unique in the set of all identifiers assigned
in a network that is managed by a JRC. In case the identifier is
invalid, the decoder MUST silently ignore the Short_Identifier
object. object.
o lease_time: The validity of the address in seconds after the o lease_time: The validity of the identifier in hours after the
reception of the CBOR object, encoded as a CBOR unsigned integer. reception of the CBOR object, encoded as a CBOR unsigned integer.
This parameter MAY be included. The node MUST stop using the This parameter MAY be included. The node MUST stop using the
assigned short address after the expiry of the lease_time assigned short identifier after the expiry of the lease_time
interval. It is up to the JRC to renew the lease before the interval. It is up to the JRC to renew the lease before the
expiry of the previous interval. The JRC updates the lease by expiry of the previous interval. The JRC updates the lease by
executing the Parameter Update exchange with the node and executing the Parameter Update exchange with the node and
including the Short_Address in the Configuration object, as including the Short_Identifier in the Configuration object, as
described in Section 9.2. In case the address lease expires, the described in Section 9.2. In case the lease expires, the node
node SHOULD initiate a new join exchange, as described in SHOULD initiate a new join exchange, as described in Section 9.1.
Section 9.1. In case this parameter is omitted, the value of In case this parameter is omitted, the value of positive infinity
positive infinity MUST be assumed, meaning that the address is MUST be assumed, meaning that the identifier is valid for as long
valid for as long as the node participates in the network. as the node participates in the network.
The CDDL fragment that represents the text above for the The CDDL fragment that represents the text above for the
Short_Address follows. Short_Identifier follows.
Short_Address = [ Short_Identifier = [
address : bstr, identifier : bstr,
? lease_time : uint ? lease_time : uint
] ]
9.4. Parameters 9.4.4.1. Use in IEEE Std 802.15.4
When Short_Identifier is used in the context of [IEEE802.15.4],
following considerations apply.
The identifier MUST be used to set the short address of IEEE Std
802.15.4 module. When operating in TSCH mode, the identifier MUST be
unique in the set of all identifiers assigned in multiple networks
that share link-layer key(s). If the length of the byte string
corresponding to the identifier parameter is different than 2, the
identifier is considered invalid. The values 0xfffe and 0xffff are
reserved by [IEEE802.15.4] and their use is considered invalid.
The security properties offered by the [IEEE802.15.4] link-layer in
TSCH mode are conditioned on the uniqueness requirement of the short
identifier (i.e. short address). The short address is one of the
inputs in the construction of the nonce, which is used to protect
link-layer frames. If a misconfiguration occurs, and the same short
address is assigned twice under the same link-layer key, the loss of
security properties is eminent. For this reason, practices where the
pledge generates the short identifier locally are not safe and are
likely to result in the loss of link-layer security properties.
The JRC MUST ensure that at any given time there are never two same
short identifiers being used under the same link-layer key. If the
lease_time parameter of a given Short_Identifier object is set to
positive infinity, care needs to be taken that the corresponding
identifier is not assigned to another node until the JRC is certain
that it is no longer in use, potentially through out-of-band
signaling. If the lease_time parameter expires for any reason, the
JRC should take into consideration potential ongoing transmissions by
the joined node, which may be hanging in the queues, before assigning
the same identifier to another node.
9.4.5. Error Object
The Error object is encoded as a CBOR array object, containing in
order:
o error_code: Error code for the first encountered error while
processing a CoJP object, encoded as an unsigned integer. This
parameter MUST be included. This parameter MUST be set to the
"Value" column of the "CoJP Error Registry" (Section 12.3).
o error_addinfo: Additional information relevant to the error. This
parameter MUST be included. This parameter MUST be set as
described by the "Additional info" column of the "CoJP Error
Registry" (Section 12.3).
o error_description: Human-readable description of the error,
encoded as a text string. This parameter MAY be included. The
RECOMMENDED setting of this parameter is the "Description" column
of the "CoJP Error Registry" Section 12.3).
The CDDL fragment that represents the text above for the Error object
follows.
Error = [
error_code : int,
error_addinfo : int / bstr / tstr / nil,
? error_description : tstr,
]
+-----------------+-------+---------------+------------+------------+
| Description | Value | Additional | Additional | Reference |
| | | info | info type | |
+-----------------+-------+---------------+------------+------------+
| Invalid | 0 | None | nil | [[this |
| Join_Request | | | | document]] |
| object | | | | |
| | | | | |
| Invalid | 1 | None | nil | [[this |
| Configuration | | | | document]] |
| object | | | | |
| | | | | |
| Invalid | 2 | None | nil | [[this |
| parameter: role | | | | document]] |
| | | | | |
| Invalid | 3 | None | nil | [[this |
| parameter: | | | | document]] |
| network | | | | |
| identifier | | | | |
| | | | | |
| Invalid | 4 | None | nil | [[this |
| parameter: | | | | document]] |
| link-layer key | | | | |
| set | | | | |
| | | | | |
| Invalid | 5 | Index of the | uint | [[this |
| parameter: | | invalid key | | document]] |
| link-layer key | | | | |
| | | | | |
| Invalid | 6 | None | nil | [[this |
| paramater: | | | | document]] |
| short | | | | |
| identifier | | | | |
| | | | | |
| Invalid | 7 | None | nil | [[this |
| parameter: JRC | | | | document]] |
| address | | | | |
| | | | | |
| Invalid | 8 | None | nil | [[this |
| parameter: | | | | document]] |
| network prefix | | | | |
| | | | | |
| Invalid | 9 | Next | bstr | [[this |
| parameter: | | acceptable | | document]] |
| OSCORE partial | | OSCORE | | |
| IV | | partial IV | | |
+-----------------+-------+---------------+------------+------------+
Table 4: CoJP error codes.
9.5. Parameters
CoJP uses the following 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.5. Mandatory to Implement Algorithms 9.6. 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 IEEE Std 802.15.4 frames, and hardware acceleration for it securing IEEE Std 802.15.4 frames, and hardware acceleration for it
is present in virtually all compliant radio chips. With this choice, is present in virtually all compliant radio chips. With this choice,
CoAP messages are protected with an 8-byte CCM authentication tag, CoAP messages are protected with an 8-byte CCM authentication tag,
and the algorithm uses 13-byte long nonces. and the algorithm uses 13-byte long nonces.
The mandatory to implement hash algorithm is SHA-256 [RFC4231]. The 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. Security Considerations
The CoAP proxy defined in [RFC7252] keeps per-client state
information in order to forward the response towards the originator
of the request. This state information includes at least the CoAP
token, the IPv6 address of the host, and the UDP source port number.
The Stateless-Proxy CoAP option (see Figure 3) allows the proxy to be
entirely stateless. The proxy inserts this option in the request to
carry the state information needed for relaying the response back to
the client. The proxy still keeps some general state (e.g. for
congestion control or request retransmission), but no per-client
state.
The Stateless-Proxy CoAP option is critical, Safe-to-Forward, not
part of the cache key, not repeatable and opaque. When processed by
OSCORE, the Stateless-Proxy option is neither encrypted nor integrity
protected.
+-----+---+---+---+---+-----------------+--------+--------+
| No. | C | U | N | R | Name | Format | Length |
+-----+---+---+---+---+-----------------+--------+--------|
| TBD | x | | x | | Stateless-Proxy | opaque | 1-255 |
+-----+---+---+---+---+-----------------+--------+--------+
C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable
Figure 3: Stateless-Proxy CoAP Option
Upon reception of a Stateless-Proxy option, the CoAP server MUST echo
it in the response. The value of the Stateless-Proxy option is
internal proxy state that is opaque to the server. For security
reasons, the option value MUST be authenticated, MUST include a
freshness indicator (e.g. a sequence number or timestamp) and MAY be
encrypted. The proxy may use a COSE structure [RFC8152] to wrap the
state information as the value of the Stateless-Proxy option. The
key used for encryption/authentication of the state information may
be known only to the proxy.
Once the proxy has received the CoAP response with a Stateless-Proxy
option present, it decrypts/authenticates it, checks the freshness
indicator and constructs the response for the client, based on the
information present in the option value.
Note that a CoAP proxy using the Stateless-Proxy option is not able Since this document uses the pledge identifier to set the ID Context
to return a 5.04 Gateway Timeout Response Code in case the request to parameter of OSCORE, an important security requirement is that the
the server times out. Likewise, if the response to the proxy's pledge identifier is unique in the set of all pledge identifiers
request does not contain the Stateless-Proxy option, for example when managed by a JRC. The uniqueness of the pledge identifier ensures
the option is not supported by the server, the proxy is not able to unique (key, nonce) pairs for AEAD algorithm used by OSCORE. It also
return the response to the client, and the client eventually times allows the JRC to retrieve the correct security context, upon the
out. reception of a Join Request message. The management of pledge
identifiers is simplified if the globally unique EUI-64 is used, but
this comes with privacy risks, as discussed in Section 11.
11. Security Considerations This document further mandates that the (6LBR) pledge and the JRC are
provisioned with unique PSKs. The PSK is used to set the OSCORE
Master Secret during security context derivation and is important for
mutual authentication of the (6LBR) pledge and the JRC. Should an
attacker come to know the PSK, then a man-in-the-middle attack is
possible.
This document recommends that the (6LBR) pledge and JRC are Many vendors are known to use unsafe practices when generating and
provisioned with unique PSKs. The nonce used for the Join Request provisioning PSKs. The use of a single PSK shared among a group of
and the Join Response is the same, but used under a different key. devices is a common pitfall that results in poor security. In this
The design differentiates between keys derived for requests and keys case, the compromise of a single device is likely to lead to a
derived for responses by different sender identifiers. Note that the compromise of the whole batch, with the attacker having the ability
address of the JRC does not take part in nonce or key construction. to impersonate a legitimate device and join the network, generate
Even in the case of a misconfiguration in which the same PSK is used bogus data and disturb the network operation. As a reminder, recall
for several pledges, the keys used to protect the requests/responses the well-known problem with Bluetooth headsets with a "0000" pin.
from/towards different pledges are different, as they are derived Additionally, some vendors use methods such as scrambling or hashing
using the pledge identifier as Master Salt. The PSK is still of device serial numbers or their EUI-64 to generate "unique" PSKs.
important for mutual authentication of the (6LBR) pledge and the JRC. Without any secret information involved, the effort that the attacker
Should an attacker come to know the PSK, then a man-in-the-middle needs to invest into breaking these unsafe derivation methods is
attack is possible. The well-known problem with Bluetooth headsets quite low, resulting in the possible impersonation of any device from
with a "0000" pin applies here. the batch, without even needing to compromise a single device. The
use of cryptographically secure random number generators to generate
the PSK is RECOMMENDED, see [NIST800-90A] for different mechanisms
using deterministic methods.
Being a stateless relay, the JP blindly forwards the join traffic The JP forwards the unauthenticated join traffic into the network. A
into the network. A simple bandwidth cap on the JP prevents it from simple bandwidth cap on the JP prevents it from forwarding more
forwarding more traffic than the network can handle. This forces traffic than the network can handle. This forces attackers to use
attackers to use more than one Join Proxy if they wish to overwhelm more than one Join Proxy if they wish to overwhelm the network.
the network. Marking the join traffic packets with a non-zero DSCP Marking the join traffic packets with a non-zero DSCP allows the
allows the network to carry the traffic if it has capacity, but network to carry the traffic if it has capacity, but encourages the
encourages the network to drop the extra traffic rather than add network to drop the extra traffic rather than add bandwidth due to
bandwidth due to that traffic. that traffic.
The shared nature of the "minimal" cell used for the join traffic The shared nature of the "minimal" cell used for the join traffic
makes the network prone to DoS attacks by congesting the JP with makes the network prone to DoS attacks by congesting the JP with
bogus traffic. Such an attacker is limited by its maximum transmit bogus traffic. Such an attacker is limited by its maximum transmit
power. The redundancy in the number of deployed JPs alleviates the power. The redundancy in the number of deployed JPs alleviates the
issue and also gives the pledge a possibility to use the best issue and also gives the pledge a possibility to use the best
available link for joining. How a network node decides to become a available link for joining. How a network node decides to become a
JP is out of scope of this specification. JP is out of scope of this specification.
At the beginning of the join process, the pledge has no means of At the beginning of the join process, the pledge has no means of
verifying the content in the EB, and has to accept it at "face verifying the content in the EB, and has to accept it at "face
value". In case the pledge tries to join an attacker's network, the value". In case the pledge tries to join an attacker's network, the
Join Response message will either fail the security check or time Join Response message will either fail the security check or time
out. The pledge may implement a temporary blacklist in order to out. The pledge may implement a temporary blacklist in order to
filter out undesired EBs and try to join using the next seemingly filter out undesired EBs and try to join using the next seemingly
valid EB. This blacklist alleviates the issue, but is effectively valid EB. This blacklist alleviates the issue, but is effectively
limited by the node's available memory. Bogus beacons prolong the limited by the node's available memory. Bogus beacons prolong the
join time of the pledge, and so the time spent in "minimal" [RFC8180] join time of the pledge, and so the time spent in "minimal" [RFC8180]
duty cycle mode. duty cycle mode.
12. Privacy Considerations 11. 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 in the set of all pledge identifiers managed
This identifier is transferred in clear as an OSCORE kid context. by a JRC. This identifier is transferred in clear as an OSCORE kid
The use of the globally unique EUI-64 as pledge identifier simplifies context. The use of the globally unique EUI-64 as pledge identifier
the management but comes with certain privacy risks. The simplifies the management but comes with certain privacy risks. The
implications are thoroughly discussed in [RFC7721] and comprise implications are thoroughly discussed in [RFC7721] and comprise
correlation of activities over time, location tracking, address correlation of activities over time, location tracking, address
scanning and device-specific vulnerability exploitation. Since the scanning and device-specific vulnerability exploitation. Since the
join protocol is executed rarely compared to the network lifetime, join process occurs rarely compared to the network lifetime, long-
long-term threats that arise from using EUI-64 as the pledge term threats that arise from using EUI-64 as the pledge identifier
identifier are minimal. In addition, the Join Response message are minimal. In addition, the Join Response message contains a short
contains a short address which is assigned by the JRC to the (6LBR) address which is assigned by the JRC to the (6LBR) pledge. The
pledge. The assigned short address SHOULD be uncorrelated with the assigned short address SHOULD be uncorrelated with the long-term
long-term pledge identifier. The short address is encrypted in the pledge identifier. The short address is encrypted in the response.
response. Once the join process completes, the new node uses the Once the join process completes, the new node uses the short
short addresses for all further layer 2 (and layer-3) operations. addresses for all further layer 2 (and layer-3) operations. This
This mitigates the aforementioned privacy risks as the short layer-2 reduces the aforementioned privacy risks as the short layer-2 address
address (visible even when the network is encrypted) is not traceable (visible even when the network is encrypted) is not traceable between
between locations and does not disclose the manufacturer, as is the locations and does not disclose the manufacturer, as is the case of
case of EUI-64. EUI-64. However, an eavesdropper with access to the radio medium
during the join process may be able to correlate the assigned short
address with the extended address based on timing information with a
non-negligible probability. This probability decreases with an
increasing number of pledges joining concurrently.
13. IANA Considerations 12. 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 12.1. CoJP Parameters Registry
The Stateless-Proxy option is added to the CoAP Option Numbers
registry:
+--------+-----------------+-----------------------+
| Number | Name | Reference |
+--------+-----------------+-----------------------+
| TBD | Stateless-Proxy | \[\[this document\]\] |
+--------+-----------------+-----------------------+
13.2. CoJP Parameters Registry
This section defines a sub-registries within the "IPv6 over the TSCH This section defines a sub-registries within the "IPv6 over the TSCH
mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name
"Constrained Join Protocol Parameters Registry". "Constrained Join Protocol Parameters Registry".
The columns of the registry are: The columns of the registry are:
Name: This is a descriptive name that enables an easier reference to Name: This is a descriptive name that enables an easier reference to
the item. It is not used in the encoding. the item. It is not used in the encoding.
skipping to change at page 31, line 47 skipping to change at page 37, line 46
This registry is to be populated with the values in Table 2. This registry is to be populated with the values in Table 2.
The amending formula for this sub-registry is: Different ranges of The amending formula for this sub-registry is: Different ranges of
values use different registration policies [RFC8126]. Integer values values use different registration policies [RFC8126]. Integer values
from -256 to 255 are designated as Standards Action. Integer values from -256 to 255 are designated as Standards Action. Integer values
from -65536 to -257 and from 256 to 65535 are designated as from -65536 to -257 and from 256 to 65535 are designated as
Specification Required. Integer values greater than 65535 are Specification Required. Integer values greater than 65535 are
designated as Expert Review. Integer values less than -65536 are designated as Expert Review. Integer values less than -65536 are
marked as Private Use. marked as Private Use.
13.3. CoJP Key Usage Registry 12.2. CoJP Key Usage Registry
This section defines a sub-registries within the "IPv6 over the TSCH This section defines a sub-registries within the "IPv6 over the TSCH
mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name
"Constrained Join Protocol Key Usage Registry". "Constrained Join Protocol Key Usage Registry".
The columns of this registry are: The columns of this registry are:
Name: This is a descriptive name that enables easier reference to the 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. item. The name MUST be unique. It is not used in the encoding.
skipping to change at page 32, line 22 skipping to change at page 38, line 20
Algorithm: This is a descriptive name of the link-layer algorithm in 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 use and uniquely determines the key length. The name is not used in
the encoding. the encoding.
Description: This field contains a description of the key usage Description: This field contains a description of the key usage
setting. The field should describe in enough detail how the key is setting. The field should describe in enough detail how the key is
to be used with different frame types, specific for the link-layer to be used with different frame types, specific for the link-layer
technology in question. technology in question.
References: This contains a pointer to the public specification for Reference: This contains a pointer to the public specification for
the field, if one exists. the field, if one exists.
This registry is to be populated with the values in Table 3. This registry is to be populated with the values in Table 3.
The amending formula for this sub-registry is: Different ranges of The amending formula for this sub-registry is: Different ranges of
values use different registration policies [RFC8126]. Integer values values use different registration policies [RFC8126]. Integer values
from -256 to 255 are designated as Standards Action. Integer values from -256 to 255 are designated as Standards Action. Integer values
from -65536 to -257 and from 256 to 65535 are designated as from -65536 to -257 and from 256 to 65535 are designated as
Specification Required. Integer values greater than 65535 are Specification Required. Integer values greater than 65535 are
designated as Expert Review. Integer values less than -65536 are designated as Expert Review. Integer values less than -65536 are
marked as Private Use. marked as Private Use.
14. Acknowledgments 12.3. CoJP Error 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 Error Registry".
The columns of this registry are:
Description: This is a descriptive human-readble name. The
description MUST be unique. It is not used in the encoding.
Value: This is the value used to identify the error. These values
MUST be unique. The value is an integer.
Additional information: This is a descriptive name of additional
information that is meaningful for the error. The name is not used
in the encoding.
Additional information type: A CBOR type of the additional
information field.
Reference: 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 4.
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. 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, Goeran Selander, Xavier The following individuals provided input to this document (in
Vilajosana, Pascal Thubert for reviewing, and to Klaus Hartke for alphabetic order): Tengfei Chang, Klaus Hartke, Tero Kivinen, Jim
providing input on the Stateless-Proxy CoAP option. Schaad, Goeran Selander, Yasuyuki Tanaka, Pascal Thubert, William
Vignat, Xavier Vilajosana, Thomas Watteyne.
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 14. References
15.1. Normative References 14.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-13 (work in (OSCORE)", draft-ietf-core-object-security-15 (work in
progress), May 2018. progress), August 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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, "Assured Forwarding PHB Group", RFC 2597,
DOI 10.17487/RFC2597, June 1999, <https://www.rfc- DOI 10.17487/RFC2597, June 1999,
editor.org/info/rfc2597>. <https://www.rfc-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, <https://www.rfc- DOI 10.17487/RFC7252, June 2014,
editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
15.2. Informative References 14.2. Informative References
[I-D.hartke-core-stateless]
Hartke, K., "Extended Tokens and Stateless Clients in the
Constrained Application Protocol (CoAP)", draft-hartke-
core-stateless-02 (work in progress), October 2018.
[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, "6TiSCH
(6P)", draft-ietf-6tisch-6top-protocol-11 (work in Operation Sublayer Protocol (6P)", draft-ietf-6tisch-6top-
progress), March 2018. protocol-12 (work in progress), June 2018.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-14 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-15 (work
in progress), April 2018. in progress), October 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,
"Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e",
draft-ietf-6tisch-terminology-10 (work in progress), March draft-ietf-6tisch-terminology-10 (work in progress), March
2018. 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 and JSON data structures", draft-ietf-cbor-
(work in progress), February 2018. cddl-05 (work in progress), August 2018.
[IEEE802.15.4] [IEEE802.15.4]
IEEE standard for Information Technology, ., "IEEE Std IEEE standard for Information Technology, ., "IEEE Std
802.15.4 Standard for Low-Rate Wireless Networks", n.d.. 802.15.4 Standard for Low-Rate Wireless Networks", n.d..
[NIST800-90A]
NIST Special Publication 800-90A, Revision 1, ., Barker,
E., and J. Kelsey, "Recommendation for Random Number
Generation Using Deterministic Random Bit Generators",
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, <https://www.rfc- DOI 10.17487/RFC5869, May 2010,
editor.org/info/rfc5869>. <https://www.rfc-editor.org/info/rfc5869>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, <https://www.rfc- DOI 10.17487/RFC6550, March 2012,
editor.org/info/rfc6550>. <https://www.rfc-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, <https://www.rfc- DOI 10.17487/RFC7554, May 2015,
editor.org/info/rfc7554>. <https://www.rfc-editor.org/info/rfc7554>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>. <https://www.rfc-editor.org/info/rfc7721>.
[RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal [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 3 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 AEAD keys and nonces
nonces from the PSK. It uses the instantiated context to protect the from the PSK. It uses the instantiated context to protect the Join
Join Request addressed with a Proxy-Scheme option, the well-known Request addressed with a Proxy-Scheme option, the well-known host
host name of the JRC in the Uri-Host option, and its EUI-64 as pledge name of the JRC in the Uri-Host option, and its EUI-64 as pledge
identifier and OSCORE kid context. Triggered by the presence of a identifier and OSCORE kid context. Triggered by the presence of a
Proxy-Scheme option, the JP forwards the request to the JRC and adds Proxy-Scheme option, the JP forwards the request to the JRC and sets
the Stateless-Proxy option with value set to the internally needed the CoAP token to the internally needed state. The JP has learned
state. The JP has learned the IPv6 address of the JRC when it acted the IPv6 address of the JRC when it acted as a pledge and joined the
as a pledge and joined the network. Once the JRC receives the network. Once the JRC receives the request, it looks up the correct
request, it looks up the correct context based on the kid context context based on the kid context parameter. OSCORE data authenticity
parameter. OSCORE data authenticity verification ensures that the verification ensures that the request has not been modified in
request has not been modified in transit. In addition, replay transit. In addition, replay protection is ensured through
protection is ensured through persistent handling of mutable context persistent handling of mutable context parameters.
parameters.
Once the JP receives the Join Response, it authenticates the Once the JP receives the Join Response, it authenticates the state
Stateless-Proxy option before deciding where to forward. The JP sets within the CoAP token before deciding where to forward. The JP sets
its internal state to that found in the Stateless-Proxy option, and its internal state to that found in the token, and forwards the Join
forwards the Join Response to the correct pledge. Note that the JP Response to the correct pledge. Note that the JP does not possess
does not possess the key to decrypt the CBOR object (configuration) the key to decrypt the CBOR object (configuration) present in the
present in the payload. The Join Response is matched to the Join payload. The Join Response is matched to the Join Request and
Request and verified for replay protection at the pledge using OSCORE verified for replay protection at the pledge using OSCORE processing
processing rules. In this example, the Join Response does not rules. In this example, the Join Response does not contain the IPv6
contain the IPv6 address of the JRC, the pledge hence understands the address of the JRC, the pledge hence understands the JRC is co-
JRC is co-located with the 6LBR. located with the 6LBR.
<---E2E OSCORE--> <---E2E OSCORE-->
Client Proxy Server Client Proxy Server
Pledge JP JRC Pledge JP JRC
| | | | | |
| Join | | Code: { 0.02 } (POST) | Join | | Code: { 0.02 } (POST)
| Request | | Token: 0x8c | Request | | Token: 0x8c
+--------->| | Proxy-Scheme: [ coap ] +--------->| | Proxy-Scheme: [ coap ]
| POST | | Uri-Host: [ 6tisch.arpa ] | POST | | Uri-Host: [ 6tisch.arpa ]
| | | Object-Security: [ kid: 0 ] | | | Object-Security: [ kid: 0 ]
| | | Payload: kid_context: EUI-64 | | | Payload: kid_context: EUI-64
| | | [ Partial IV: 1, | | | [ Partial IV: 1,
| | | { Uri-Path:"j", | | | { Uri-Path:"j",
| | | join_request }, | | | join_request },
| | | <Tag> ] | | | <Tag> ]
| | | | | |
| | Join | Code: { 0.01 } (GET) | | Join | Code: { 0.01 } (GET)
| | Request | Token: 0x7b | | Request | Token: opaque state
| +--------->| Uri-Host: [ 6tisch.arpa ] | +--------->| Uri-Host: [ 6tisch.arpa ]
| | POST | Object-Security: [ kid: 0 ] | | POST | Object-Security: [ kid: 0 ]
| | | Stateless-Proxy: opaque state
| | | Payload: kid_context: EUI-64 | | | Payload: kid_context: EUI-64
| | | [ Partial IV: 1, | | | [ Partial IV: 1,
| | | { Uri-Path:"j", | | | { Uri-Path:"j",
| | | join_request }, | | | join_request },
| | | <Tag> ] | | | <Tag> ]
| | | | | |
| | Join | Code: { 2.05 } (Content) | | Join | Code: { 2.05 } (Content)
| | Response | Token: 0x7b | | Response | Token: 0x7b
| |<---------+ Object-Security: - | |<---------+ Object-Security: -
| | 2.04 | Stateless-Proxy: opaque state | | 2.04 | Payload: [ { configuration }, <Tag> ]
| | | Payload: [ { configuration }, <Tag> ]
| | | | | |
| Join | | Code: { 2.05 } (Content) | Join | | Code: { 2.05 } (Content)
| Response | | Token: 0x8c | Response | | Token: 0x8c
|<---------+ | Object-Security: - |<---------+ | Object-Security: -
| 2.04 | | Payload: [ { configuration }, <Tag> ] | 2.04 | | Payload: [ { configuration }, <Tag> ]
| | | | | |
Figure 4: Example of a successful join protocol exchange. { ... } Figure 3: Example of a successful join protocol exchange. { ... }
denotes encryption and authentication, [ ... ] denotes denotes encryption and authentication, [ ... ] denotes
authentication. authentication.
Where the join_request object is: Where the join_request object is:
join_request: join_request:
{ {
5 : h'cafe' / PAN ID of the network pledge is attempting to join / 5 : h'cafe' / PAN ID of the network pledge is attempting to join /
} }
Since the role parameter is not present, the default role of "6TiSCH Since the role parameter is not present, the default role of "6TiSCH
Node" is implied. Node" is implied.
The join_request object encodes to h'a10542cafe' with a size of 5 The join_request object encodes to h'a10542cafe' with a size of 5
bytes. bytes.
And the configuration object is: And the configuration object is:
configuration: configuration:
{ {
skipping to change at page 37, line 21 skipping to change at page 44, line 15
Node" is implied. Node" is implied.
The join_request object encodes to h'a10542cafe' with a size of 5 The join_request object encodes to h'a10542cafe' with a size of 5
bytes. bytes.
And the configuration object is: And the configuration object is:
configuration: configuration:
{ {
2 : [ / link-layer key set / 2 : [ / link-layer key set /
1, / key_index / 1, / key_id /
h'e6bf4287c2d7618d6a9687445ffd33e6' / key_value / h'e6bf4287c2d7618d6a9687445ffd33e6' / key_value /
], ],
3 : [ / link-layer short address / 3 : [ / short identifier /
h'af93' / assigned short address / h'af93' / assigned short address /
] ]
} }
Since the key_usage parameter is not present in the link-layer key 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. set object, the default value of "6TiSCH-K1K2-ENC-MIC32" is implied.
Similarly, since the lease_time parameter is not present in the link- Since key_addinfo parameter is not present and key_id is different
layer short address object, the default value of positive infinity is than 0, Key ID Mode 0x01 (Key Index) is implied. Similarly, since
implied. the lease_time parameter is not present in the short identifier
object, the default value of positive infinity is implied.
The configuration object encodes to The configuration object encodes to
h'a202820150e6bf4287c2d7618d6a9687445ffd33e6038142af93' with a size h'a202820150e6bf4287c2d7618d6a9687445ffd33e6038142af93' with a size
of 26 bytes. of 26 bytes.
Authors' Addresses Authors' Addresses
Malisa Vucinic (editor) Malisa Vucinic (editor)
University of Montenegro University of Montenegro
 End of changes. 135 change blocks. 
530 lines changed or deleted 866 lines changed or added

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