draft-ietf-6tisch-minimal-security-03.txt   draft-ietf-6tisch-minimal-security-04.txt 
6TiSCH Working Group M. Vucinic, Ed. 6TiSCH Working Group M. Vucinic, Ed.
Internet-Draft Inria Internet-Draft University of Montenegro
Intended status: Standards Track J. Simon Intended status: Standards Track J. Simon
Expires: December 17, 2017 Linear Technology Expires: May 3, 2018 Analog Devices
K. Pister K. Pister
University of California Berkeley University of California Berkeley
M. Richardson M. Richardson
Sandelman Software Works Sandelman Software Works
June 15, 2017 October 30, 2017
Minimal Security Framework for 6TiSCH Minimal Security Framework for 6TiSCH
draft-ietf-6tisch-minimal-security-03 draft-ietf-6tisch-minimal-security-04
Abstract Abstract
This document describes the minimal mechanisms required to support This document describes the minimal configuration required for a new
secure enrollment of a pledge, a device being added to an IPv6 over device, called "pledge", to securely join a 6TiSCH (IPv6 over the
the TSCH mode of IEEE 802.15.4e (6TiSCH) network. It assumes that TSCH mode of IEEE 802.15.4e) network. The entities involved use CoAP
the pledge has been provisioned with a credential that is relevant to (Constrained Application Protocol) and OSCORE (Object Security for
the deployment - the "one-touch" scenario. The goal of this Constrained RESTful Environments). The configuration requires that
configuration is to set link-layer keys, and to establish a secure the pledge and the JRC (join registrar/coordinator, a central
end-to-end session between each pledge and the join registrar who may entity), share a symmetric key. How this key is provisioned is out
use that to further configure the pledge. Additional security of scope of this document. The result of the joining process is that
behaviors and mechanisms may be added on top of this minimal the JRC configures the pledge with link-layer keying material and a
framework. short link-layer address. This specification also defines a new
Stateless-Proxy CoAP option. Additional security mechanisms may be
added on top of this minimal framework.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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 December 17, 2017. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. One-Touch Assumptions . . . . . . . . . . . . . . . . . . . . 4 3. One-Touch Assumption . . . . . . . . . . . . . . . . . . . . 4
4. Join Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Pre-Shared Key . . . . . . . . . . . . . . . . . . . . . 4
4.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 5 4. Join Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 6 4.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 6
4.3. Step 3 - Security Handshake . . . . . . . . . . . . . . . 6 4.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 7
4.4. Step 4 - Simple Join Protocol - Join Request . . . . . . 8 4.3. Step 3 - Join Request . . . . . . . . . . . . . . . . . . 7
4.5. Step 5 - Simple Join Protocol - Join Response . . . . . . 8 4.4. Step 4 - Join Response . . . . . . . . . . . . . . . . . 8
5. Architectural Overview and Communication through Join Proxy . 9 5. Architectural Overview and Communication through Join Proxy . 8
5.1. Stateless-Proxy CoAP Option . . . . . . . . . . . . . . . 9 5.1. Stateless-Proxy CoAP Option . . . . . . . . . . . . . . . 9
6. Security Handshake . . . . . . . . . . . . . . . . . . . . . 10 6. OSCORE Security Context . . . . . . . . . . . . . . . . . . . 10
7. Simple Join Protocol Specification . . . . . . . . . . . . . 11 6.1. Persistency . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. OSCOAP Security Context Instantiation . . . . . . . . . . 12 7. Specification of Join Request . . . . . . . . . . . . . . . . 11
7.2. Specification of Join Request . . . . . . . . . . . . . . 13 8. Specification of Join Response . . . . . . . . . . . . . . . 11
7.3. Specification of Join Response . . . . . . . . . . . . . 13 8.1. Link-layer Keys Transported in COSE Key Set . . . . . . . 12
8. Mandatory to Implement Algorithms and Certificate Format . . 15 8.2. Short Address . . . . . . . . . . . . . . . . . . . . . . 12
9. Link-layer Requirements . . . . . . . . . . . . . . . . . . . 15 9. Error Handling and Retransmission . . . . . . . . . . . . . . 13
10. Rekeying and Rejoin . . . . . . . . . . . . . . . . . . . . . 16 10. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Key Derivations . . . . . . . . . . . . . . . . . . . . . . . 16 11. Mandatory to Implement Algorithms . . . . . . . . . . . . . . 14
12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 12. Link-layer Requirements . . . . . . . . . . . . . . . . . . . 14
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 13. Rekeying and Rejoin . . . . . . . . . . . . . . . . . . . . . 15
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 14. Security Considerations . . . . . . . . . . . . . . . . . . . 15
14.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 18 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 16.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 16
16.1. Normative References . . . . . . . . . . . . . . . . . . 19 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
16.2. Informative References . . . . . . . . . . . . . . . . . 19 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 21 18.1. Normative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 18.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
This document describes the minimal feature set for a new device, This document presumes a 6TiSCH network as described by [RFC7554],
termed pledge, to securely join a 6TiSCH network. As a successful [RFC8180], [I-D.ietf-6tisch-6top-protocol], and
outcome of this process, the pledge is able to securely communicate [I-D.ietf-6tisch-terminology]. By design, nodes in a 6TiSCH network
with its neighbors, participate in the routing structure of the [RFC7554] have their radio turned off most of the time, to conserve
network or establish a secure session with an Internet host. energy. As a consequence, the link used by a new device for joining
the network has limited bandwidth [RFC8180]. The secure join
When a pledge seeks admission to a 6TiSCH [RFC7554] network, it first solution defined in this document therefore keeps the number of over-
needs to synchronize to the network. The pledge then configures its the-air exchanges for join purposes to a minimum.
link-local IPv6 address and authenticates itself, and also validates
that it is joining the right network. At this point it can expect to
interact with the network to configure its link-layer keying
material. Only then may the node establish an end-to-end secure
session with an Internet host using OSCOAP
[I-D.ietf-core-object-security] or DTLS [RFC6347]. Once the
application requirements are known, the node interacts with its peers
to request additional resources as needed, or to be reconfigured as
the network changes [I-D.ietf-6tisch-6top-protocol].
This document presumes a network as described by [RFC7554],
[I-D.ietf-6tisch-6top-protocol], and [I-D.ietf-6tisch-terminology].
It assumes the pledge pre-configured with either a:
o pre-shared key (PSK),
o raw public key (RPK), The micro-controllers at the heart of 6TiSCH nodes have a small
amount of code memory. It is therefore paramount to reuse existing
protocols available as part of the 6TiSCH stack. At the application
layer, the 6TiSCH stack already relies on CoAP [RFC7252] for web
transfer, and on OSCORE [I-D.ietf-core-object-security] for its end-
to-end security. The secure join solution defined in this document
therefore reuses those two protocols as its building blocks.
o or a locally-valid certificate and a trust anchor. This document defines a secure join solution for a new device, called
"pledge", to securely join a 6TiSCH network. The specification
configures different layers of the 6TiSCH protocol stack and also
defines a new CoAP option. It assumes the presence of a JRC (join
registrar/coordinator), a central entity. It further assumes that
the pledge and the JRC share a symmetric key, called PSK (pre-shared
key). How the PSK is installed is out of scope of this document.
As the outcome of the join process, the pledge expects one or more When the pledge seeks admission to a 6TiSCH network, it first
link-layer key(s) and optionally a temporary link-layer identifier. synchronizes to it, by initiating the passive scan defined in
[IEEE802.15.4-2015]. The pledge then exchanges messages with the
JRC; these messages can be forwarded by nodes already part of the
6TiSCH network. The messages exchanged allow the JRC and the pledge
to mutually authenticate, based on the PSK. They also allow the JRC
to configure the pledge with link-layer keying material and a short
link-layer address. After this secure joining process successfully
completes, the joined node can establish an end-to-end secure session
with an Internet host. The joined node can also interact with its
neighbors to request additional bandwidth using the 6top Protocol
[I-D.ietf-6tisch-6top-protocol].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. These document are to be interpreted as described in [RFC2119]. These
words may also appear in this document in lowercase, absent their words may also appear in this document in lowercase, absent their
normative meanings. normative meanings.
The reader is expected to be familiar with the terms and concepts The reader is expected to be familiar with the terms and concepts
defined in [I-D.ietf-6tisch-terminology], [RFC7252], defined in [I-D.ietf-6tisch-terminology], [RFC7252],
[I-D.ietf-core-object-security], and [I-D.ietf-core-object-security], and [RFC8152].
[I-D.ietf-anima-bootstrapping-keyinfra]. The following terms are
imported: pledge, join proxy, join registrar/coordinator, drop ship,
imprint, enrollment, ownership voucher.
Pledge: the prospective device, which has the identity provided to The specification also includes a set of informative examples using
at the factory. the CBOR diagnostic notation [I-D.ietf-cbor-cddl].
Joined Node: the prospective device, after having completed the join The following terms are used throughout this document:
process, often just called a Node.
Join Proxy (JP): a stateless relay that provides connectivity pledge: The new device that wishes to join a 6TiSCH network.
between the pledge and the Join Registrar/Coordinator.
Join Registrar/Coordinator (JRC): central entity responsible for joined node: The new device, after having completed the join
authentication and authorization of joining nodes. process, often just called a node.
3. One-Touch Assumptions join proxy (JP): A node already part of the 6TiSCH network that
serves as a relay to provide connectivity between the pledge and
the JRC.
This document assumes the one-touch scenario, where devices are join registrar/coordinator (JRC): A central entity responsible for
provided with some mechanism by which a secure association may be the authentication, authorization and configuration of the pledge.
made in a controlled environment. There are many ways in which this
might be done, and detailing any of them is out of scope for this
document. But, some notion of how this might be done is important so
that the underlying assumptions can be reasoned about.
Some examples of how to do this could include: 3. One-Touch Assumption
o JTAG interface This document assumes a one-touch scenario. The pledge is
provisioned with a PSK before attempting to join the network, and the
same PSK (as well as the uniquer identifier of the pledge) is
provisioned on the JRC.
o serial (craft) console interface There are many ways by which this provisioning can be done.
Physically, the PSK can be written into the pledge using a number of
mechanisms, such as a JTAG interface, a serial (craft) console
interface, pushing buttons simultaneously on different devices, over-
the-air configuration in a Faraday cage, etc. The provisioning can
be done by the vendor, the manufacturer, the integrator, etc.
o pushes of physical buttons simultaneous to network attachment 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
conversation between the JRC and the pledge, and that the two devices
can exchange the PSK.
o unsecured devices operated in a Faraday cage 3.1. Pre-Shared Key
There are likely many other ways as well. What is assumed is that The PSK SHOULD be at least 128 bits in length, generated uniformly at
there can be a secure, private conversation between the Join random. It is RECOMMENDED to generate the PSK with a
Registrar/Coordinator, and the pledge, and that the two devices can cryptographically secure pseudorandom number generator. Each pledge
exchange some trusted bytes of information. SHOULD be provisioned with a unique PSK.
4. Join Overview 4. Join 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 previously unknown device seeks admission to a network. When a pledge seeks admission to a 6TiSCH network, the
6TiSCH [RFC7554] 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
[IEEE8021542015]. This frame provides network synchronization [IEEE802.15.4-2015]. This frame provides network synchronization
information, and tells the device when it can send a frame to the information, and tells the device when it can send a frame to the
node sending the beacons, which plays the role of Join Proxy (JP) node sending the beacons, which plays the role of join proxy (JP)
for the pledge, and when it can expect to receive a frame. for the pledge, and when it can expect to receive a frame.
2. The pledge configures its link-local IPv6 address and advertizes 2. The pledge configures its link-local IPv6 address and advertises
it to Join Proxy (JP). it to the join proxy (JP).
3. The pledge sends packets to JP in order to securely identify 3. The pledge sends a Join Request to JP in order to securely
itself to the network. These packets are directed to the Join identify itself to the network. The Join Request is directed to
Registrar/Coordinator (JRC), which may be co-located on the JP or the JRC, which may be co-located on the JP or another device.
another device.
4. The pledge receives one or more packets from JRC (via the JP) 4. In case of successful processing of the request, the pledge
that sets up one or more link-layer keys used to authenticate receives a join response from JRC (via the JP) that sets up one
subsequent transmissions to peers. or more link-layer keys used to authenticate and encrypt
subsequent transmissions to peers, and a short link-layer address
for the pledge.
From the pledge's perspective, minimal joining is a local phenomenon From the pledge's perspective, minimal joining is a local phenomenon
- the pledge only interacts with the JP, and it need not know how far - the pledge only interacts with the JP, and it need not know how far
it is from the 6LBR, or how to route to the JRC. Only after it is from the 6LBR, or how to route to the JRC. Only after
establishing one or more link-layer keys does it need to know about establishing one or more link-layer keys does it need to know about
the particulars of a 6TiSCH network. the particulars of a 6TiSCH network.
The handshake is shown as a transaction diagram in Figure 1: The process is shown as a transaction diagram in Figure 1:
+--------+ +-------+ +--------+ +--------+ +-------+ +--------+
| pledge | | JP | | JRC | | pledge | | JP | | JRC |
| | | | | | | | | | | |
+--------+ +-------+ +--------+ +--------+ +-------+ +--------+
| | | | | |
|<----ENH BEACON (1)-------| | |<---Enhanced Beacon (1)---| |
| | | | | |
|<-Neighbor Discovery (2)->| | |<-Neighbor Discovery (2)->| |
| | | | | |
|<---Sec. Handshake (3)----|---Sec. Handshake (3a)--->| |-----Join Request (3)-----|------Join Request (3a)-->|
| | | | | |
....................................................................... |<---Join Response (4)-----|-----Join Response (4a)---|
. |-----Join Request (4)-----|------Join Request (4a)-->| . | | |
. | | | Simple Join .
. |<---Join Response (5)-----|-----Join Response (5a)---| Protocol .
. | | | .
.......................................................................
Figure 1: Overview of the join process. Figure 1: Overview of a successful join process.
The details of each step are described in the following sections. The details of each step are described in the following sections.
4.1. Step 1 - Enhanced Beacon 4.1. Step 1 - Enhanced Beacon
Due to the channel hopping nature of 6TiSCH, transmissions take place The pledge synchronizes to the network by listening for, and
on physical channels in a circular fashion. For that reason, receiving, an Enhanced Beacon (EB) sent by a node already in the
Enhanced Beacons (EBs) are expected to be found by listening on a network. This process is entirely defined by [IEEE802.15.4-2015],
single channel. However, because some channels may be blacklisted, a and described in [RFC7554].
new pledge must listen for Enhanced Beacons for a certain period on
each of the 16 possible channels. This search process entails having
the pledge keep the receiver portion of its radio active for the
entire period of time.
Once the pledge hears an EB from a JP, it synchronizes itself to the
joining schedule using the cells contained in the EB. The selection
of which beacon to start with is outside the scope of this document.
Implementers SHOULD make use of information such as: whether the L2
address of the EB has been tried before, any Network Identifier
[I-D.richardson-6tisch-join-enhanced-beacon] seen, and the strength
of the signal. The pledge can be configured with the Network
Identifier to seek when it is configured with the PSK.
Once a candidate network has been selected, the pledge can transition Once the pledge hears an EB, it synchronizes to the joining schedule
into a low-power duty cycle, waking up only when the provided using the cells contained in the EB. The pledge can hear multiple
schedule indicates shared slots which the pledge may use for the join EBs; the selection of which EB to use is out of the scope for this
process. document, and is discussed in [RFC7554]. Implementers SHOULD make
use of information such as: what Personal Area Network Identifier
(PAN ID) [IEEE802.15.4-2015] the EB contains, whether the source
link-layer address of the EB has been tried before, what signal
strength the different EBs were received at, etc. In addition, the
pledge may be pre-configured to search for EBs with a specific PAN
ID.
At this point the pledge may proceed to step 2, or continue to listen Once the pledge selects the EB, it synchronizes to it and transitions
for additional EBs. into a low-power mode. It deeply duty cycles its radio, switching
the radio on when the provided schedule indicates slots which the
pledge may use for the join process. During the remainder of the
join process, the node that has sent the EB to the pledge plays the
role of JP.
A pledge which receives only Enhanced Beacons containing Network ID At this point, the pledge may proceed to step 2, or continue to
extensions [I-D.richardson-6tisch-join-enhanced-beacon] with the listen for additional EBs.
initiate bit cleared, SHOULD NOT proceed with this protocol on that
network. The pledge SHOULD consider that it is in a network which
manages join traffic, it SHOULD switch to
[I-D.ietf-6tisch-dtsecurity-secure-join].
4.2. Step 2 - Neighbor Discovery 4.2. Step 2 - Neighbor Discovery
At this point, the pledge forms its link-local IPv6 address based on The pledge forms its link-local IPv6 address based on EUI-64, as per
EUI64 and may register it at JP, in order to bootstrap the IPv6 [RFC4944]. The Neighbor Discovery exchange shown in Figure 1 refers
neighbor tables. The Neighbor Discovery exchange shown in Figure 1 to a single round trip Neighbor Solicitation / Neighbor Advertisement
refers to a single round trip Neighbor Solicitation / Neighbor exchange between the pledge and the JP (Section 5.5.1 of [RFC6775]).
Advertisement exchange between the pledge and the JP. The pledge may The pledge uses the link-local IPv6 address for all subsequent
further follow the Neighbor Discovery (ND) process described in communication with the JP during the join process.
Section 5 of [RFC6775].
4.3. Step 3 - Security Handshake
The security handshake between pledge and JRC uses Ephemeral Diffie-
Hellman over COSE (EDHOC) [I-D.selander-ace-cose-ecdhe] to establish
the shared session secret used to encrypt the Simple Join Protocol.
The security handshake step is OPTIONAL in case PSKs are used, while
it is REQUIRED for RPKs and certificates.
When using certificates, the process continues as described in
[I-D.selander-ace-cose-ecdhe], but MAY result in no network key being
returned. In that case, the pledge enters a provisional situation
where it provides access to an enrollment mechanism described in
[I-D.ietf-6tisch-dtsecurity-secure-join].
If using a locally relevant certificate, the pledge will be able to
validate the certificate of the JRC via a local trust anchor. In
that case, the JRC will return networks keys as in the PSK case.
This would typically be the case for a device which has slept so long
that it no longer has valid network keys and must go through a
partial join process again.
In case the handshake step is omitted, the shared secret used for
protection of the Simple Join Protocol in the next step is the PSK.
A consequence is that if the long-term PSK is compromised, keying
material transferred as part of the join response is compromised as
well. Physical compromise of the pledge, however, would also imply
the compromise of the same keying material, as it is likely to be
found in node's memory.
4.3.1. Pre-Shared Symmetric Key
The Diffie-Hellman key exchange and the use of EDHOC is optional,
when using a pre-shared symmetric key. This cuts down on traffic
between JRC and pledge, but requires pre-configuration of the shared
key on both devices.
It is REQUIRED to use unique PSKs for each pledge. If there are
multiple JRCs in the network (such as for redundancy), they would
have to share a database of PSKs.
4.3.2. Asymmetric Keys
The Security Handshake step is required, when using asymmetric keys. Note that ND exchanges at this point are not protected with link-
Before conducting the Diffie-Hellman key exchange using EDHOC layer security as the pledge is not in possession of the keys. How
[I-D.selander-ace-cose-ecdhe] the pledge and JRC need to receive and JP accepts these unprotected frames is discussed in Section 12.
validate each other's public key certificate. As detailed above,
this can only be done for locally relevant (LDevID) certificates.
IDevID certificates require entering a provisional state as described
in [I-D.ietf-6tisch-dtsecurity-secure-join].
When RPKs are pre-configured at pledge and JRC, they can directly The pledge and the JP SHOULD keep a separate neighbor cache for
proceed to the handshake. untrusted entries and use it to store each other's information during
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.
How the pledge and JP decide to transition each other from untrusted
to trusted cache, once the join process completes, is out of scope.
One implementation technique is to use the information whether the
incoming frames are secured at the link layer.
4.4. Step 4 - Simple Join Protocol - Join Request 4.3. Step 3 - Join Request
The Join Request that makes part of the Simple Join Protocol is sent The Join Request is a message sent from the pledge to the JP using
from the pledge to the JP using the shared slot as described in the the shared slot as described in the EB, and which the JP forwards to
EB, and forwarded to the JRC. Which slot the JP uses to transmit to the JRC. The JP forwards the Join Request to the JRC on the existing
the JRC is out of scope: some networks may wish to dedicate specific 6TiSCH network. How exactly this happens is out of scope of this
slots for this join traffic. document; some networks may wish to dedicate specific slots for this
join traffic.
The join request is authenticated/encrypted end-to-end using an The Join Request is authenticated/encrypted end-to-end using an AEAD
algorithm from [I-D.ietf-cose-msg] and a key derived from the shared algorithm from [RFC8152] and a key derived from the PSK, the pledge's
secret from step 3. Algorithm negotiation is described in detail in EUI-64 and a request-specific constant value. Algorithms which MUST
[I-D.selander-ace-cose-ecdhe], and mandatory to implement algorithms be implemented are specified in Section 11.
are specified in Section 8.
The nonce is derived from the shared secret, the pledge's EUI64 and a The nonce used when securing the Join Request is derived from the
monotonically increasing counter initialized to 0 when first PSK, the pledge's EUI-64 and a monotonically increasing counter
starting. initialized to 0 when first starting.
4.5. Step 5 - Simple Join Protocol - Join Response Join Request construction is specified in Section 7, while the
details on processing can be found in Section 7 of
[I-D.ietf-core-object-security].
The Join Response that makes part of the Simple Join Protocol is sent 4.4. Step 4 - Join Response
from the JRC to the pledge through JP that serves as a stateless
relay. Packet containing the Join Response travels on the path from
JRC to JP using pre-established routes in the network. The JP
delivers it to the pledge using the slot information from the EB. JP
operates as the application-layer proxy and does not keep any state
to relay the message. It uses information sent in the clear within
the join response to decide where to forward to.
The join response is authenticated/encrypted end-to-end using an The Join Response is sent by the JRC to the pledge, and is forwarded
algorithm from [I-D.ietf-cose-msg] and a key derived from the shared through the JP as it serves as a stateless relay. The packet
secret from step 3. containing the Join Response travels from the JRC to JP using the
operating routes in the 6TiSCH network. The JP delivers it to the
pledge using the slot information it has indicated in the EB it sent.
The JP operates as the application-layer proxy, and does not keep any
state to relay the message. It uses information sent in the clear
within the Join Response to decide where to forward to.
The nonce is derived from the shared secret, pledge's EUI64 and a The Join Response is authenticated/encrypted end-to-end using an AEAD
monotonically increasing counter matching that of the join request. algorithm from [RFC8152]. The key used to protect the response is
different from the one used to protect the request (both are derived
from the PSK, as explained in Section 6). The response is protected
using the same nonce as in the request.
The join response contains one or more link-layer key(s) that the The Join Response contains one or more link-layer key(s) that the
pledge will use for subsequent communication. Each key that is pledge will use for subsequent communication. Each key that is
provided by the JRC is associated with an 802.15.4 key identifier. provided by the JRC is associated with an 802.15.4 key identifier.
In other link-layer technologies, a different identifier may be In other link-layer technologies, a different identifier may be
substituted. Join Response optionally also contains an IEEE 802.15.4 substituted. The Join Response also contains an IEEE 802.15.4 short
short address [IEEE8021542015] assigned to pledge by JRC, and the address [IEEE802.15.4-2015] assigned by the JRC to the pledge, and
IPv6 address of the JRC. optionally the IPv6 address of the JRC.
Join Response construction is specified in Section 8, while the
details on processing can be found in Section 7 of
[I-D.ietf-core-object-security].
5. Architectural Overview and Communication through Join Proxy 5. Architectural Overview and Communication through Join Proxy
The protocol in Figure 1 is implemented over Constrained Application The Join Request/Join Response exchange in Figure 1 is carried over
Protocol (CoAP) [RFC7252]. The Pledge plays the role of a CoAP CoAP [RFC7252] and secured using OSCORE
client, JRC the role of a CoAP server, while JP implements CoAP [I-D.ietf-core-object-security]. The pledge plays the role of a CoAP
forward proxy functionality [RFC7252]. Since JP is also likely a client; the JRC plays the role of a CoAP server. The JP implements
constrained device, it does not need to implement a cache but rather CoAP forward proxy functionality [RFC7252]. Because the JP can also
process forwarding-related CoAP options and make requests on behalf be a constrained device, it cannot implement a cache. Rather, the JP
of pledge that is not yet part of the network. processes forwarding-related CoAP options and makes requests on
behalf of the pledge, in a stateless manner.
The pledge communicates with a Join Proxy (JP) over link-local IPv6 The pledge communicates with a JP over link-local IPv6 addresses.
addresses. The pledge designates a JP as a proxy by including in the The pledge designates a JP as a proxy by including the Proxy-Scheme
CoAP requests to the JP the Proxy-Scheme option with value "coap" option with value "coap" (CoAP-to-CoAP proxy) in CoAP requests it
(CoAP-to-CoAP proxy). The pledge MUST include the Uri-Host option sends to the JP. The pledge MUST include the Uri-Host option with
with its value set to the well-known JRC's alias - "6tisch.arpa". its value set to the well-known JRC's alias "6tisch.arpa". This
The pledge learns the actual IPv6 address of JRC from the join allows the pledge to join without knowing the IPv6 address of the
response and it uses it once joined in order to operate as JP. The JRC. The pledge learns the actual IPv6 address of the JRC from the
initial bootstrap of the 6LBR would require explicit provisioning of Join Response; it uses it once joined in order to operate as a JP.
the JRC address.
The JRC can be co-located on the 6LBR. Before the 6TiSCH network is
started, the 6LBR MUST be provisioned with the IPv6 address of the
JRC.
5.1. Stateless-Proxy CoAP Option 5.1. Stateless-Proxy CoAP Option
The CoAP proxy by default keeps per-client state information in order The CoAP proxy defined in [RFC7252] keeps per-client state
to forward the response towards the originator of the request information in order to forward the response towards the originator
(client). This state information comprises CoAP token, but the of the request. This state information includes at least the CoAP
implementations also need to keep track of the IPv6 address of the token, the IPv6 address of the host, and the UDP source port number.
host, as well as the corresponding UDP source port number. In the If the JP used the stateful CoAP proxy defined in [RFC7252], it would
setting where the proxy is a constrained device and there are be prone to Denial-of-Service (DoS) attacks, due to its limited
potentially many clients, as in the case of JP, this makes it prone memory.
to Denial of Service (DoS) attacks, due to the limited memory.
The Stateless-Proxy CoAP option (c.f. Figure 2) allows the proxy to The Stateless-Proxy CoAP option Figure 2 allows the JP to be entirely
insert within the request the state information necessary for stateless. This option inserts, in the request, the state
relaying the response back to the client. Note that the proxy still information needed for relaying the response back to the client. The
needs to keep some state, such as for performing congestion control proxy still keeps some general state (e.g. for congestion control or
or request retransmission, but what is aimed with Stateless-Proxy request retransmission), but no per-client state.
option is to free the proxy from keeping per-client state.
Stateless-Proxy option is critical, Safe-to-Forward, not part of the The Stateless-Proxy CoAP option is critical, Safe-to-Forward, not
cache key, not repeatable and opaque. When processed by OSCOAP, part of the cache key, not repeatable and opaque. When processed by
Stateless-Proxy option is neither encrypted nor integrity protected. OSCORE, the Stateless-Proxy option is neither encrypted nor integrity
protected.
+-----+---+---+---+---+-----------------+--------+--------+ +-----+---+---+---+---+-----------------+--------+--------+
| No. | C | U | N | R | Name | Format | Length | | No. | C | U | N | R | Name | Format | Length |
+-----+---+---+---+---+-----------------+--------+--------| +-----+---+---+---+---+-----------------+--------+--------|
| TBD | x | | x | | Stateless-Proxy | opaque | 1-255 | | TBD | x | | x | | Stateless-Proxy | opaque | 1-255 |
+-----+---+---+---+---+-----------------+--------+--------+ +-----+---+---+---+---+-----------------+--------+--------+
C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable
Figure 2: Stateless-Proxy CoAP Option Figure 2: Stateless-Proxy CoAP Option
Upon reception of a Stateless-Proxy option, the CoAP server MUST echo Upon reception of a Stateless-Proxy option, the CoAP server MUST echo
it in the response. The value of the Stateless-Proxy option is it in the response. The value of the Stateless-Proxy option is
internal proxy state that is opaque to the server. Example state internal proxy state that is opaque to the server. Example state
information includes IPv6 address of the client, its UDP source port, information includes the IPv6 address of the client, its UDP source
and the CoAP token. For security reasons, the state information MUST port, and the CoAP token. For security reasons, the state
be authenticated, MUST include a freshness indicator (e.g. a sequence information MUST be authenticated, MUST include a freshness indicator
number or timestamp) and MAY be encrypted. The proxy may use an (e.g. a sequence number or timestamp) and MAY be encrypted. The
appropriate COSE structure [I-D.ietf-cose-msg] to wrap the state proxy may use an appropriate COSE structure [RFC8152] to wrap the
information as the value of the Stateless-Proxy option. The key used state information as the value of the Stateless-Proxy option. The
for encryption/authentication of the state information may be known key used for encryption/authentication of the state information may
only to the proxy. be known only to the proxy.
Once the proxy has received the CoAP response with Stateless-Proxy Once the proxy has received the CoAP response with Stateless-Proxy
option present, it decrypts/authenticates it, checks the freshness option present, it decrypts/authenticates it, checks the freshness
indicator and constructs the response for the client, based on the indicator and constructs the response for the client, based on the
information present in the option value. information present in the option value.
Note that a CoAP proxy using the Stateless-Proxy option is not able Note that a CoAP proxy using the Stateless-Proxy option is not able
to return 5.04 Gateway Timeout error in case the request to the to return a 5.04 Gateway Timeout Response Code in case the request to
server times out. Likewise, if the response to the proxy's request the server times out. Likewise, if the response to the proxy's
does not contain the Stateless-Proxy option, for example when the request does not contain the Stateless-Proxy option, for example when
option is not supported by the server, the proxy is not able to the option is not supported by the server, the proxy is not able to
return the response to the client. return the response to the client.
6. Security Handshake 6. OSCORE Security Context
In order to derive a shared session key, pledge and JRC run the EDHOC
protocol [I-D.selander-ace-cose-ecdhe]. During this process, pledge
and JRC mutually authenticate each other and verify authorization
information before proceeding with the Simple Join Protocol. In case
certificates are used for authentication, this document assumes that
a special certificate with role attribute set has been provisioned to
the JRC. This certificate is verified by pledge in order to
authorize JRC to continue with the join process. How such a
certificate is issued to the JRC is out of scope of this document.
Figure 3 details the exchanges between the pledge and JRC that take
place during the execution of the security handshake. Format of
EDHOC messages is specified in [I-D.selander-ace-cose-ecdhe]. The
handshake is initiated by the pledge. JRC may either respond with an
empty CoAP acknowledgment, signaling to the pledge that it needs to
wait, or directly with the second message of EDHOC handshake. How
JRC decides whether it will immediately proceed with the handshake is
out of scope of this document.
+--------+ +--------+
| pledge | | JRC |
| | | |
+--------+ +--------+
| |
| EDHOC message_1 |
+-------------------------------->|
| |
| Optional ACK |
|< - - - - - - - - - - - - - - - -+
~ ~
| |
| EDHOC message_2 |
|<--------------------------------+
| |
| EDHOC message_3 |
+-------------------------------->|
| |
Figure 3: Transaction diagram of the security handshake.
7. Simple Join Protocol Specification The OSCORE security context MUST be derived at the pledge and the JRC
as per Section 3 of [I-D.ietf-core-object-security].
Simple Join Protocol is a single round trip protocol (c.f. Figure 4) o the Master Secret MUST be the PSK.
that facilitates secure enrollment of a pledge, based on a shared
symmetric secret. In case the pledge was provisioned by an
asymmetric key (certificate or RPK), Simple Join Protocol is preceded
by a security handshake, described in Section 6. When the pledge is
provisioned with a PSK, Simple Join Protocol may be run directly.
Pledge and JRC MUST protect their exchange end-to-end (i.e. through o the Master Salt MUST be pledge's EUI-64.
the proxy) using Object Security of CoAP (OSCOAP)
[I-D.ietf-core-object-security].
+--------+ +--------+ o the Sender ID of the pledge MUST be set to byte string 0x00.
| pledge | | JRC |
| | | |
+--------+ +--------+
| |
| Join Request |
+-------------------------------->|
| |
| Join Response |
|<--------------------------------+
| |
Figure 4: Transaction diagram of the Simple Join Protocol. o the Recipient ID (ID of the JRC) MUST be set to byte string 0x01.
7.1. OSCOAP Security Context Instantiation 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
default is AES-CCM-16-64-128.
The OSCOAP security context MUST be derived at pledge and JRC as per o the Key derivation function MUST be agreed out-of-band. Default
Section 3.2 of [I-D.ietf-core-object-security] using HKDF SHA-256 is HKDF SHA-256.
[RFC5869] as the key derivation function.
o Master Secret MUST be the secret generated by the run of EDHOC as The derivation in [I-D.ietf-core-object-security] results in traffic
per Appendix B of [I-D.selander-ace-cose-ecdhe], or the PSK in keys and a common IV for each side of the conversation. Nonces are
case EDHOC step was omitted. constructed by XOR'ing the common IV with the current sequence number
and sender identifier. For details on nonce construction, refer to
[I-D.ietf-core-object-security].
o Sender ID of the pledge MUST be set to the concatenation of its It is RECOMMENDED that a PAN ID be provisioned to the pledge out-of-
EUI-64 and byte string 0x00. band by the same mechanism used to provision the PSK. This prevents
the pledge from attempting to join a wrong network. If the pledge is
not provisioned with the PAN ID, it SHOULD attempt to join one
network at a time. In that case, implementations MUST ensure that
multiple CoAP requests to different JRCs result in the use of the
same OSCORE context so that sequence numbers are properly incremented
for each request.
o Recipient ID (ID of JRC) MUST be set to the concatenation of 6.1. Persistency
pledge's EUI-64 and byte string 0x01. The construct uses pledge's
EUI-64 to avoid nonce reuse in the response in the case same PSK
is shared by a group of pledges.
o Algorithm MUST be set to the value from [I-D.ietf-cose-msg] agreed Implementations MUST ensure that mutable OSCORE context parameters
by the run of EDHOC, or out-of-band in case of PSKs. (Sender Sequence Number, Replay Window) are stored in persistent
memory. A technique that prevents reuse of sequence numbers,
detailed in Section 6.5.1 of [I-D.ietf-core-object-security], MUST be
implemented. Each update of the OSCORE Replay Window MUST be written
to persistent memory.
The derivation in [I-D.ietf-core-object-security] results in traffic This is an important security requirement in order to guarantee nonce
keys and static IVs for each side of the conversation. Nonces are uniqueness and resistance to replay attacks across reboots and
constructed by XOR'ing the static IV with current sequence number. rejoins. Traffic between the pledge and the JRC is rare, making
The context derivation process occurs exactly once. security outweigh the cost of writing to persistent memory.
Implementations MUST ensure that multiple CoAP requests to different 7. Specification of Join Request
JRCs result in the use of the same OSCOAP context so that sequence
numbers are properly incremented for each request. This may happen
in a scenario where there are multiple 6TiSCH networks present and
the pledge tries to join one network at a time.
7.2. Specification of Join Request The Join Request the pledge sends SHALL be mapped to a CoAP request:
Message Join Request SHALL be mapped to a CoAP request: o The request method is POST.
o The request method is GET. o The type is Non-confirmable (NON).
o The Proxy-Scheme option is set to "coap". o The Proxy-Scheme option is set to "coap".
o The Uri-Host option is set to "6tisch.arpa". o The Uri-Host option is set to "6tisch.arpa".
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] and OSCOAP parameters set as [I-D.ietf-core-object-security]. The OSCORE Context Hint SHALL be
described above. set to pledge's EUI-64. The OSCORE Context Hint allows the JRC to
retrieve the security context for a given pledge.
7.3. Specification of Join Response o The payload is empty.
If OSCOAP processing is a success and the pledge is authorized to 8. Specification of Join Response
join the network, message Join Response SHALL be mapped to a CoAP
response:
o The response Code is 2.05 (Content). If the JRC successfully processes the Join Request using OSCORE, and
if the pledge is authorized to join the network, the Join Response
the JRC sends back to the pledge SHALL be mapped to a CoAP response:
o Content-Format option is set to application/cbor. o The response Code is 2.04 (Changed).
o The payload is a CBOR [RFC7049] array containing, in order: o The payload is a CBOR [RFC7049] array containing, in order:
* COSE Key Set, specified in [I-D.ietf-cose-msg], containing one * the COSE Key Set, specified in [RFC8152], containing one or
or more link-layer keys. The mapping of individual keys to more link-layer keys. The mapping of individual keys to
802.15.4-specific parameters is described in Section 7.3.1. 802.15.4-specific parameters is described in Section 8.1.
* Optional. Link layer short address that is assigned to the * the link-layer short address to be used by the pledge. The
pledge. The format of the short address follows Section 7.3.2. format of the short address follows Section 8.2.
* Optional. IPv6 address of the JRC transported as a byte * optionally, the IPv6 address of the JRC transported as a byte
string. If the address of the JRC is not present in the string. If the IPv6 address of the JRC is not present in the
response, JRC is co-located with 6LBR. Join Response, this indicates the JRC is co-located with 6LBR,
and has the same IPv6 address as the 6LBR. The address of the
6LBR can then be learned from DODAGID field in RPL DIOs
[RFC6550].
payload = [ response_payload = [
COSE_KeySet, COSE_KeySet,
? short_address, short_address,
? JRC_address : bstr, ? JRC_address : bstr,
] ]
7.3.1. Link-layer Keys Transported in COSE Key Set 8.1. Link-layer Keys Transported in COSE Key Set
Each key in the COSE Key Set [I-D.ietf-cose-msg] SHALL be a symmetric Each key in the COSE Key Set [RFC8152] SHALL be a symmetric key. If
key. If "kid" parameter of the COSE Key structure is present, the the "kid" parameter of the COSE Key structure is present, the
corresponding keys SHALL belong to an IEEE 802.15.4 KeyIdMode 0x01 corresponding keys SHALL belong to an IEEE 802.15.4 KeyIdMode 0x01
class. In that case, parameter "kid" of COSE Key structure SHALL be class. In that case, parameter "kid" of the COSE Key structure SHALL
used to carry IEEE 802.15.4 KeyIndex value. If the "kid" parameter be used to carry the IEEE 802.15.4 KeyIndex value. If the "kid"
is not present in the transported key, the application SHALL consider parameter is not present in the transported key, the application
the key to be an IEEE 802.15.4 KeyIdMode 0x00 (implicit) key. This SHALL consider the key to be an IEEE 802.15.4 KeyIdMode 0x00
document does not support IEEE 802.15.4 KeyIdMode 0x02 and 0x03 class (implicit) key. This document does not support IEEE 802.15.4
keys. KeyIdMode 0x02 and 0x03 class keys.
7.3.2. Short Address 8.2. Short Address
Optional "short_address" structure transported as part of the join The "short_address" structure transported as part of the join
response payload represents IEEE 802.15.4 short address assigned to response payload represents the IEEE 802.15.4 short address assigned
the pledge. It is encoded as CBOR array object, containing in order: to the pledge. It is encoded as a CBOR array object, containing, in
order:
o Byte string, containing the 16-bit address. o Byte string, containing the 16-bit address.
o Optional lease time parameter, "lease_asn". The value of the o Optionally, the lease time parameter, "lease_asn". The value of
"lease_asn" parameter is the 5-byte Absolute Slot Number (ASN) the "lease_asn" parameter is the 5-byte Absolute Slot Number (ASN)
corresponding to its expiration, carried as a byte string in corresponding to its expiration, carried as a byte string in
network byte order. network byte order.
short_address = [ short_address = [
address : bstr, address : bstr,
? lease_asn : bstr, ? lease_asn : bstr,
] ]
It is up to the joined node to request a new short address before the It is up to the joined node to request a new short address before the
expiry of its previous address. The mechanism by which the node expiry of its previous address. The mechanism by which the node
requests renewal is the same as during join procedure, as described requests renewal is the same as during join procedure, as described
in Section 10. The assigned short address is used for configuring in Section 13. The assigned short address is used for configuring
both Layer 2 short address and Layer 3 addresses. both link-layer short address and IPv6 addresses.
7.3.3. Error Handling 9. Error Handling and Retransmission
In the case JRC determines that pledge is not supposed to join the Since the Join Request is mapped to a Non-confirmable CoAP message,
network (e.g. by failing to find an appropriate security context), it OSCORE processing at JRC will silently drop the request in case of a
should respond with a 4.01 Unauthorized error. Upon reception of a failure. This may happen for a number of reasons, including failed
4.01 Unauthorized, the pledge SHALL attempt to join the next lookup of an appropriate security context, failed decryption,
advertised 6TiSCH network. If all join attempts have failed at positive replay window lookup, formatting errors possibly due to
pledge, the pledge SHOULD signal to the user by an out-of-band malicious alterations in transit. Silent drop at JRC prevents a DoS
mechanism the presence of an error condition. attack where an attacker could force the pledge to attempt joining
one network at a time, until all networks have been tried.
In the case that the JRC determines that the pledge is not (yet) Using Non-confirmable CoAP message to transport Join Request also
authorized to join the network, but a further zero-touch process helps minimize the required CoAP state at the pledge and the Join
might permit it, the JRC responds with a 2.05 (Content) code, but the Proxy, keeping it to a minimum typically needed to perform CoAP
payload contains the single CBOR string "prov" (for "provisional"). congestion control. It does, however, introduce complexity at the
No link-layer keys or short address is returned. application layer, as the pledge needs to implement a retransmission
mechanism.
This response is typically only expected when in asymmetric The following binary exponential back-off algorithm is inspired by
certificate mode using 802.1AR IDevID certificates. But for reasons the one described in [RFC7252]. For each Join Request the pledge
of provisioning or device reuse, this could occur even when a one- sends while waiting for a Join Response, the pledge MUST keep track
touch PSK authentication process was expected. of a timeout and a retransmission counter. For a new Join Request,
the timeout is set to a random value between TIMEOUT and (TIMEOUT *
TIMEOUT_RANDOM_FACTOR), and the retransmission counter is set to 0.
When the timeout is triggered and the retransmission counter is less
than MAX_RETRANSMIT, the Join Request is retransmitted, the
retransmission counter is incremented, and the timeout is doubled.
Note that the retransmitted Join Request passes new OSCORE
processing, such that the sequence number in the OSCORE context is
properly incremented. If the retransmission counter reaches
MAX_RETRANSMIT on a timeout, the pledge SHOULD attempt to join the
next advertised 6TiSCH network. If the pledge receives a Join
Response that successfully passed OSCORE processing, it cancels the
pending timeout and processes the response. The pledge MUST silently
discard any response not protected with OSCORE, including error
codes. For default values of retransmission parameters, see
Section 10.
8. Mandatory to Implement Algorithms and Certificate Format If all join attempts to advertised networks have failed, the pledge
SHOULD signal to the user the presence of an error condition, through
some out-of-band mechanism.
The mandatory to implement symmetric-key algorithm for use with 10. Parameters
OSCOAP is AES-CCM-16-64-128 from [I-D.ietf-cose-msg]. This is the
algorithm used in 802.15.4, and is present in hardware on many
platforms. With this choice, CoAP messages are therefore protected
with an 8-byte CCM authentication tag and the algorithm uses 13-byte
long nonces.
The mandatory to implement hash algorithm is SHA-256 [RFC4231]. This specification uses the following parameters:
Certificates or pre-configured RPKs may be used to exchange public +-----------------------+----------------+
keys between the pledge and JRC. The mandatory to implement Elliptic | Name | Default Value |
Curve is P-256, also known as secp256r1. The mandatory to implement +-----------------------+----------------+
signature algorithm is ECDSA with SHA-256. | TIMEOUT | 10 s |
+-----------------------+----------------+
| TIMEOUT_RANDOM_FACTOR | 1.5 |
+-----------------------+----------------+
| MAX_RETRANSMIT | 4 |
+----------------------------------------+
The certificate itself may be a compact representation of an X.509 The values of TIMEOUT, TIMEOUT_RANDOM_FACTOR, MAX_RETRANSMIT may be
certificate, or a full X.509 certificate. Compact representation of configured to values specific to the deployment. The default values
X.509 certificates is out of scope of this specification. The have been chosen to accommodate a wide range of deployments, taking
certificate is signed by a root CA whose certificate is installed on into account dense networks.
all nodes participating in a particular 6TiSCH network, allowing each
node to validate the certificate of the JRC or pledge as appropriate.
9. Link-layer Requirements 11. Mandatory to Implement Algorithms
In an operational 6TiSCH network, all frames MUST use link-layer The mandatory to implement AEAD algorithm for use with OSCORE is AES-
frame security. The frame security options MUST include frame CCM-16-64-128 from [RFC8152]. This is the algorithm used for
authentication, and MAY include frame encryption. securing 802.15.4 frames, and hardware acceleration for it is present
in virtually all compliant radio chips. With this choice, CoAP
messages are protected with an 8-byte CCM authentication tag, and the
algorithm uses 13-byte long nonces.
Link-layer frames are protected with a 16-byte key, and a 13-byte The mandatory to implement hash algorithm is SHA-256 [RFC4231].
nonce constructed from current Absolute Slot Number (ASN) and the
source (the JP for EBs) address, as shown in Figure 5:
+-------------------------------------------+ 12. Link-layer Requirements
| Address (8B or 00-padded 2B) | ASN (5B) |
+-------------------------------------------+
Figure 5: Link-layer CCM* nonce construction In an operational 6TiSCH network, all frames MUST use link-layer
frame security [RFC8180]. The frame security options MUST include
frame authentication, and MAY include frame encryption.
The pledge does not initially do any authentication of the EB frames, The pledge does not initially do any authentication of the EB frames,
as it does not know the K1 key. When sending frames, the pledge as it does not know the K1 key [RFC8180]. When sending frames, the
sends unencrypted and unauthenticated frames. JP accepts these pledge sends unencrypted and unauthenticated frames. The JP accepts
frames (exempt mode in 802.15.4) for the duration of the join these frames (using the "exempt mode" in 802.15.4) for the duration
process. How JP learns whether the join process is ongoing is out of of the join process. How the JP learns whether the join process is
scope of this specification. ongoing is out of scope of this specification.
As the EB itself cannot be authenticated by pledge, an attacker may As the EB itself cannot be authenticated by the pledge, an attacker
craft a frame that appears to be a valid EB, since the pledge can may craft a frame that appears to be a valid EB, since the pledge can
neither know the ASN a priori nor verify the address of the JP. This neither know the ASN a priori nor verify the address of the JP. This
permits a Denial of Service (DoS) attack at the pledge. Beacon opens up a possibility of DoS attack, as discussed in Section 14.
authentication keys are discussed in [I-D.ietf-6tisch-minimal]. Beacon authentication keys are discussed in [RFC8180].
10. Rekeying and Rejoin
This protocol handles initial keying of the pledge. For reasons such
as rejoining after a long sleep, or expiry of the short address, the
joined node MAY send a new Join Request over the previously
established secure end-to-end session with JRC. JRC responds with
up-to-date keys and a short address. The node may also use the
Simple Join Protocol exchange for node-initiated rekeying. How node
learns that it should be rekeyed is out of scope. Additional work,
such as in [I-D.richardson-6tisch-minimal-rekey] can be used.
11. Key Derivations
When EDHOC is used to derive keys, the cost of the asymmetric 13. Rekeying and Rejoin
operation can be amortized over any additional connections that may
be required between the node (during or after joining) and the JRC.
Each application SHOULD use a unique session key. EDHOC was designed This specification handles initial keying of the pledge. For reasons
with this in mind. In order to accomplish this, the EDHOC key such as rejoining after a long sleep, expiry of the short address, or
derivation algorithm can be run with a different label. Other users node-initiated rekeying, the joined node MAY send a new Join Request
of this key MUST define the label. using the already-established OSCORE security context. The JRC then
responds with up-to-date keys and a (possibly new) short address.
How the joined node decides when to rekey is out of scope of this
document. Mechanisms for rekeying the network are defined in
companion specifications, such as
[I-D.richardson-6tisch-minimal-rekey].
12. Security Considerations 14. Security Considerations
In case PSKs are used, this document mandates that the pledge and JRC This document recommends that the pledge and JRC are provisioned with
are pre-configured with unique keys. The uniqueness of generated unique PSKs. The request nonce and the response nonce are the same,
nonces is guaranteed under the assumption of unique EUI64 identifiers but used under a different key. The design differentiates between
for each pledge. Note that the address of the JRC does not take part keys derived for requests and keys derived for responses by different
in nonce construction. Therefore, even should an error occur, and a sender identifiers (0x00 for pledge and 0x01 for JRC). Note that the
PSK shared by a group of nodes, the nonces constructed as part of the address of the JRC does not take part in nonce or key construction.
different responses are unique. The PSK is still important for Even in case of a misconfiguration in which the same PSK is used for
authentication of the pledge and authentication of the JRC to the several nodes, the keys used to protect the requests/responses from/
pledge. Should an attacker come to know the PSK, then a man-in-the- towards different pledges are different, as they are derived using
middle attack is possible. The well known problem with Bluetooth the pledge's EUI-64 as Master Salt. The PSK is still important for
headsets with a "0000" pin applies here. The design differentiates mutual authentication of the pledge and JRC. Should an attacker come
between nonces constructed for requests and nonces constructed for to know the PSK, then a man-in-the-middle attack is possible. The
responses by different sender identifiers (0x00 for pledge and 0x01 well-known problem with Bluetooth headsets with a "0000" pin applies
for JRC). here.
Being a stateless relay, JP blindly forwards the join traffic into Being a stateless relay, the JP blindly forwards the join traffic
the network. While the exchange between pledge and JP takes place into the network. While the exchange between pledge and JP takes
over a shared cell, join traffic is forwarded using dedicated cells place over a shared 6TiSCH cell, join traffic is forwarded using
on the JP to JRC path. In case of distributed scheduling, the join dedicated cells on the JP to JRC multi-hop path. In case of
traffic may therefore cause intermediate nodes to request additional distributed scheduling, the join traffic may therefore cause
bandwidth. (EDNOTE: this is a problem that needs to be solved) intermediate nodes to request additional bandwidth. Because the
Because the relay operation of JP is implemented at the application relay operation of the JP is implemented at the application layer,
layer, JP is the only hop on the JP-6LBR path that can distinguish the JP is the only hop on the JP-6LBR path that can distinguish join
join traffic from regular IP traffic in the network. It is therefore traffic from regular IP traffic in the network. It is therefore
recommended to implement stateless rate limiting at JP: a simple recommended to implement stateless rate limiting at JP; a simple
bandwidth (in bytes or packets/second) cap would be appropriate. bandwidth cap would be appropriate.
The shared nature of the "minimal" cell used for join traffic makes The shared nature of the "minimal" cell used for the join traffic
the network prone to DoS attacks by congesting the JP with bogus makes the network prone to DoS attacks by congesting the JP with
radio traffic. As such an attacker is limited by emitted radio bogus radio traffic. As such an attacker is limited by its emitted
power, redundancy in the number of deployed JPs alleviates the issue radio power, the redundancy in the number of deployed JPs alleviates
and also gives the pledge a possibility to use the best available the issue and also gives the pledge a possibility to use the best
link for join. How a network node decides to become a JP is out of available link for joining. How a network node decides to become a
scope of this specification. JP is out of scope of this specification.
At the time of the join, the pledge has no means of verifying the At the beginning of the join process, the pledge has no means of
content in the EB and has to accept it at "face value". In case the verifying the content in the EB, and has to accept it at "face
pledge tries to join an attacker's network, the join response message value". In case the pledge tries to join an attacker's network, the
in such cases will either fail the security check or time out. The Join Response message will either fail the security check or time
pledge may implement a blacklist in order to filter out undesired out. The pledge may implement a blacklist in order to filter out
beacons and try to join the next seemingly valid network. The undesired EBs and try to join using the next seemingly valid EB.
blacklist alleviates the issue but is effectively limited by the This blacklist alleviates the issue, but is effectively limited by
node's available memory. Such bogus beacons will prolong the join the node's available memory. Bogus beacons prolong the join time of
time of the pledge and so the time spent in "minimal" the pledge, and so the time spent in "minimal" [RFC8180] duty cycle
[I-D.ietf-6tisch-minimal] duty cycle mode. mode.
13. Privacy Considerations 15. Privacy Considerations
This specification relies on the uniqueness of EUI64 that is This specification relies on the uniqueness of the node's EUI-64 that
transferred in clear as part of the security context identifier. is transferred in clear as an OSCORE Context Hint. Privacy
(EDNOTE: should we say IID here?) Privacy implications of using such implications of using such long-term identifier are discussed in
long-term identifier are discussed in [RFC7721] and comprise [RFC7721] and comprise correlation of activities over time, location
correlation of activities over time, location tracking, address tracking, address scanning and device-specific vulnerability
scanning and device-specific vulnerability exploitation. Since the exploitation. Since the join protocol is executed rarely compared to
join protocol is executed rarely compared to the network lifetime, the network lifetime, long-term threats that arise from using EUI-64
long-term threats that arise from using EUI64 are minimal. In are minimal. In addition, the Join Response message contains a short
addition, the join response message contains an optional short address which is assigned by JRC to the pledge. The assigned short
address which can be assigned by JRC to the pledge. The short address SHOULD be uncorrelated with the long-term EUI-64 identifier.
address is independent of the long-term identifier EUI64 and is The short address is encrypted in the response. Use of short
encrypted in the response. For that reason, it is not possible to addresses once the join protocol completes mitigates the
correlate the short address with the EUI64 used during the join. Use aforementioned privacy risks.
of short addresses once the join protocol completes mitigates the
aforementioned privacy risks. In addition, EDHOC may be used for
identity protection during the join protocol by generating a random
context identifier in place of the EUI64
[I-D.selander-ace-cose-ecdhe].
14. IANA Considerations 16. 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" 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. is requested.
14.1. CoAP Option Numbers Registry 16.1. CoAP Option Numbers Registry
The Stateless-Proxy option is added to the CoAP Option Numbers The Stateless-Proxy option is added to the CoAP Option Numbers
registry: registry:
+--------+-----------------+-------------------+ +--------+-----------------+-------------------+
| Number | Name | Reference | | Number | Name | Reference |
+--------+-----------------+-------------------+ +--------+-----------------+-------------------+
| TBD | Stateless-Proxy | [[this document]] | | TBD | Stateless-Proxy | [[this document]] |
+--------+-----------------+-------------------+ +--------+-----------------+-------------------+
15. Acknowledgments 17. Acknowledgments
The work on this document has been partially supported by the The work on this document has been partially supported by the
European Union's H2020 Programme for research, technological European Union's H2020 Programme for research, technological
development and demonstration under grant agreement No 644852, development and demonstration under grant agreement No 644852,
project ARMOUR. project ARMOUR.
The authors are grateful to Thomas Watteyne and Goeran Selander for The authors are grateful to Thomas Watteyne and Goeran Selander for
reviewing the draft and to Klaus Hartke for providing input on the reviewing, and to Klaus Hartke for providing input on the Stateless-
Stateless-Proxy CoAP option. The authors would also like to thank Proxy CoAP option. The authors would also like to thank Francesca
Francesca Palombini and Ludwig Seitz for participating in the Palombini, Ludwig Seitz and John Mattsson for participating in the
discussions that have helped shape the document. discussions that have helped shape the document.
16. References 18. References
16.1. Normative References
18.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 of CoAP (OSCOAP)", draft-ietf-core- "Object Security for Constrained RESTful Environments
object-security-03 (work in progress), May 2017. (OSCORE)", draft-ietf-core-object-security-06 (work in
progress), October 2017.
[I-D.ietf-cose-msg]
Schaad, J., "CBOR Object Signing and Encryption (COSE)",
draft-ietf-cose-msg-24 (work in progress), November 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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, <http://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, <http://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
16.2. Informative References [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>.
18.2. Informative References
[I-D.ietf-6tisch-6top-protocol] [I-D.ietf-6tisch-6top-protocol]
Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol
(6P)", draft-ietf-6tisch-6top-protocol-05 (work in (6P)", draft-ietf-6tisch-6top-protocol-09 (work in
progress), May 2017. progress), October 2017.
[I-D.ietf-6tisch-dtsecurity-secure-join]
Richardson, M., "6tisch Secure Join protocol", draft-ietf-
6tisch-dtsecurity-secure-join-01 (work in progress),
February 2017.
[I-D.ietf-6tisch-minimal]
Vilajosana, X., Pister, K., and T. Watteyne, "Minimal
6TiSCH Configuration", draft-ietf-6tisch-minimal-21 (work
in progress), February 2017.
[I-D.ietf-6tisch-terminology] [I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terminology in IPv6 over the TSCH mode of IEEE "Terminology in IPv6 over the TSCH mode of IEEE
802.15.4e", draft-ietf-6tisch-terminology-08 (work in 802.15.4e", draft-ietf-6tisch-terminology-09 (work in
progress), December 2016. progress), June 2017.
[I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-06 (work in progress), May 2017.
[I-D.richardson-6tisch-join-enhanced-beacon] [I-D.ietf-cbor-cddl]
Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational Birkholz, H., Vigano, C., and C. Bormann, "Concise data
Element encapsulation of 6tisch Join Information", draft- definition language (CDDL): a notational convention to
richardson-6tisch-join-enhanced-beacon-01 (work in express CBOR data structures", draft-ietf-cbor-cddl-00
progress), March 2017. (work in progress), July 2017.
[I-D.richardson-6tisch-minimal-rekey] [I-D.richardson-6tisch-minimal-rekey]
Richardson, M., "Minimal Security rekeying mechanism for Richardson, M., "Minimal Security rekeying mechanism for
6TiSCH", draft-richardson-6tisch-minimal-rekey-01 (work in 6TiSCH", draft-richardson-6tisch-minimal-rekey-02 (work in
progress), February 2017. progress), August 2017.
[I-D.selander-ace-cose-ecdhe]
Selander, G., Mattsson, J., and F. Palombini, "Ephemeral
Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace-
cose-ecdhe-06 (work in progress), April 2017.
[IEEE8021542015] [IEEE802.15.4-2015]
IEEE standard for Information Technology, ., "IEEE Std IEEE standard for Information Technology, ., "IEEE Std
802.15.4-2015 Standard for Low-Rate Wireless Personal Area 802.15.4-2015 Standard for Low-Rate Wireless Personal Area
Networks (WPANs)", 2015. Networks (WPANs)", 2015.
[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
RFC 4231, DOI 10.17487/RFC4231, December 2005, RFC 4231, DOI 10.17487/RFC4231, December 2005,
<http://www.rfc-editor.org/info/rfc4231>. <https://www.rfc-editor.org/info/rfc4231>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
Key Derivation Function (HKDF)", RFC 5869, "Transmission of IPv6 Packets over IEEE 802.15.4
DOI 10.17487/RFC5869, May 2010, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<http://www.rfc-editor.org/info/rfc5869>. <https://www.rfc-editor.org/info/rfc4944>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<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,
<http://www.rfc-editor.org/info/rfc6775>. <https://www.rfc-editor.org/info/rfc6775>.
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement", RFC 7554, Internet of Things (IoT): Problem Statement", RFC 7554,
DOI 10.17487/RFC7554, May 2015, DOI 10.17487/RFC7554, May 2015,
<http://www.rfc-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,
<http://www.rfc-editor.org/info/rfc7721>. <https://www.rfc-editor.org/info/rfc7721>.
[RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal
IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH)
Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180,
May 2017, <https://www.rfc-editor.org/info/rfc8180>.
Appendix A. Example Appendix A. Example
Figure 6 illustrates a join protocol exchange in case PSKs are used. Figure 3 illustrates a successful join protocol exchange. The pledge
Pledge instantiates the OSCOAP context and derives the traffic keys instantiates the OSCORE context and derives the traffic keys and
and nonces from the PSK. It uses the instantiated context to protect nonces from the PSK. It uses the instantiated context to protect the
the CoAP request addressed with Proxy-Scheme option and well-known Join Request addressed with a Proxy-Scheme option, the well-known
host name of JRC in the Uri-Host option. Triggered by the presence host name of the JRC in the Uri-Host option, and its EUI-64
of Proxy-Scheme option, JP forwards the request to the JRC and adds identifier as OSCORE Context Hint. Triggered by the presence of
Proxy-Scheme option, the JP forwards the request to the JRC and adds
the Stateless-Proxy option with value set to the internally needed the Stateless-Proxy option with value set to the internally needed
state, authentication tag, and a freshness indicator. JP learned the state, authentication tag, and a freshness indicator. The JP learned
IPv6 address of JRC when it acted as a pledge and joined the network. the IPv6 address of JRC when it acted as a pledge and joined the
Once JRC receives the request, it looks up the correct context based network. Once the JRC receives the request, it looks up the correct
on the Sender ID (sid) parameter. It reconstructs OSCOAP's external context based on the Context Hint parameter. It reconstructs
Additional Authenticated Data (AAD) needed for verification based on: OSCORE's external Additional Authenticated Data (AAD) needed for
verification based on:
o Version field of the received CoAP header. o the Version of the received CoAP header.
o Code field of the received CoAP header. o the Algorithm value agreed out-of-band, default being AES-CCM-
16-64-128 from [RFC8152].
o Algorithm being the AES-CCM-16-64-128 from [I-D.ietf-cose-msg]. o the Request ID being set to the value of the "kid" field of the
received COSE object.
o Request ID being set to pledge's EUI-64 concatenated with 0x00. o the Join Request sequence number set to the value of "Partial IV"
field of the received COSE object.
o Request Sequence number set to the value of "Partial IV" of the o Integrity-protected options received as part of the request.
received COSE object.
Replay protection is ensured by OSCOAP and the tracking of sequence Replay protection is ensured by OSCORE and the tracking of sequence
numbers at each side. In the example below, the response contains numbers at each side. Once the JP receives the Join Response, it
sequence number 7 meaning that there have already been some attempts authenticates the Stateless-Proxy option before deciding where to
to join under a given context, not coming from the pledge. Once JP forward. The JP sets its internal state to that found in the
receives the response, it authenticates the Stateless-Proxy option Stateless-Proxy option, and forwards the Join Response to the correct
before deciding where to forward. JP sets its internal state to that pledge. Note that the JP does not possess the key to decrypt the
found in the Stateless-Proxy option. Note that JP does not posses COSE object (join_response) present in the payload. The Join
the key to decrypt the COSE object present in the payload so the Response is matched to the Join Request and verified for replay
join_response object is opaque to it. The response is matched to the protection at the pledge using OSCORE processing rules. In this
request and verified for replay protection at pledge using OSCOAP example, the Join Response does not contain the IPv6 address of the
processing rules. The response does not contain JRC's address as in JRC, the pledge hence understands the JRC is co-located with the
this particular example, we assume that JRC is co-located with 6LBR. 6LBR.
<--E2E OSCOAP--> <---E2E OSCORE-->
Client Proxy Server Client Proxy Server
Pledge JP JRC Pledge JP JRC
| | | | | |
+----->| | Code: [0.01] (GET) +------>| | Code: { 0.02 } (POST)
| GET | | Token: 0x8c | GET | | Token: 0x8c
| | | Proxy-Scheme: [coap] | | | Proxy-Scheme: [ coap ]
| | | Uri-Host: [6tisch.arpa] | | | Uri-Host: [ 6tisch.arpa ]
| | | Object-Security: [sid:EUI-64 | 0, seq:1, | | | Object-Security: [ kid: 0 ]
| | | {Uri-Path:"j"}, | | | Payload: Context-Hint: EUI-64
| | | <Tag>] | | | [ Partial IV: 1,
| | | Payload: - | | | { Uri-Path:"j" },
| | | | | | <Tag> ]
| +----->| Code: [0.01] (GET) | | |
| | GET | Token: 0x7b | +------>| Code: { 0.01 } (GET)
| | | Uri-Host: [6tisch.arpa] | | GET | Token: 0x7b
| | | Object-Security: [sid:EUI-64 | 0, seq:1, | | | Uri-Host: [ 6tisch.arpa ]
| | | {Uri-Path:"j"}, | | | Object-Security: [ kid: 0 ]
| | | <Tag>] | | | Stateless-Proxy: opaque state
| | | Stateless-Proxy: opaque state | | | Payload: Context-Hint: EUI-64
| | | Payload: - | | | [ Partial IV: 1,
| | | | | | { Uri-Path:"j" },
| |<-----+ Code: [2.05] (Content) | | | <Tag> ]
| | 2.05 | Token: 0x7b | | |
| | | Object-Security: - | |<------+ Code: { 2.05 } (Content)
| | | Stateless-Proxy: opaque state | | 2.05 | Token: 0x7b
| | | Payload: [ seq:7, | | | Object-Security: -
| | | {join_response}, <Tag>] | | | Stateless-Proxy: opaque state
| | | | | | Payload: [ { join_response }, <Tag> ]
|<-----+ | Code: [2.05] (Content) | | |
| 2.05 | | Token: 0x8c |<------+ | Code: { 2.05 } (Content)
| | | Object-Security: - | 2.05 | | Token: 0x8c
| | | Payload: [ seq:7, | | | Object-Security: -
| | | {join_response}, <Tag>] | | | Payload: [ { join_response }, <Tag> ]
| | | | | |
Figure 6: Example of a join protocol exchange with a PSK. {} denotes Figure 3: Example of a successful join protocol exchange. { ... }
encryption and authentication, [] denotes authentication. denotes encryption and authentication, [ ... ] denotes
authentication.
Where join_response is as follows. Where join_response is as follows.
join_response: join_response:
[ [
[ / COSE Key Set array with a single key / [ / COSE Key Set array with a single key /
{ {
1 : 4, / key type symmetric / 1 : 4, / key type symmetric /
2 : h'01', / key id / 2 : h'01', / key id /
-1 : h'e6bf4287c2d7618d6a9687445ffd33e6' / key value / -1 : h'e6bf4287c2d7618d6a9687445ffd33e6' / key value /
skipping to change at page 23, line 26 skipping to change at page 22, line 26
] ]
] ]
Encodes to Encodes to
h'8281a301040241012050e6bf4287c2d7618d6a9687445ffd33e68142af93' with h'8281a301040241012050e6bf4287c2d7618d6a9687445ffd33e68142af93' with
a size of 30 bytes. a size of 30 bytes.
Authors' Addresses Authors' Addresses
Malisa Vucinic (editor) Malisa Vucinic (editor)
Inria University of Montenegro
2 Rue Simone Iff Dzordza Vasingtona bb
Paris 75012 Podgorica 81000
France Montenegro
Email: malisa.vucinic@inria.fr Email: malisav@ac.me
Jonathan Simon Jonathan Simon
Linear Technology Analog Devices
32990 Alvarado-Niles Road, Suite 910 32990 Alvarado-Niles Road, Suite 910
Union City, CA 94587 Union City, CA 94587
USA USA
Email: jsimon@linear.com Email: jonathan.simon@analog.com
Kris Pister Kris Pister
University of California Berkeley University of California Berkeley
512 Cory Hall 512 Cory Hall
Berkeley, CA 94720 Berkeley, CA 94720
USA USA
Email: pister@eecs.berkeley.edu Email: pister@eecs.berkeley.edu
Michael Richardson Michael Richardson
Sandelman Software Works Sandelman Software Works
 End of changes. 157 change blocks. 
697 lines changed or deleted 620 lines changed or added

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