draft-ietf-6tisch-minimal-security-01.txt   draft-ietf-6tisch-minimal-security-02.txt 
6TiSCH Working Group M. Vucinic 6TiSCH Working Group M. Vucinic
Internet-Draft Inria Internet-Draft Inria
Intended status: Standards Track J. Simon Intended status: Standards Track J. Simon
Expires: August 6, 2017 Linear Technology Expires: September 13, 2017 Linear Technology
K. Pister K. Pister
University of California Berkeley University of California Berkeley
February 02, 2017 M. Richardson
Sandelman Software Works
March 12, 2017
Minimal Security Framework for 6TiSCH Minimal Security Framework for 6TiSCH
draft-ietf-6tisch-minimal-security-01 draft-ietf-6tisch-minimal-security-02
Abstract Abstract
This draft describes the minimal mechanisms required to support This document describes the minimal mechanisms required to support
secure initial configuration in a device being added to a 6TiSCH secure enrollment of a pledge, a device being added to an IPv6 over
network. The goal of this configuration is to set link-layer keys, the TSCH mode of IEEE 802.15.4e (6TiSCH) network. It assumes that
and to establish a secure session between each joining node and the the pledge has been provisioned with a credential that is relevant to
JCE who may use that to further configure the joining device. the deployment - the "one-touch" scenario. The goal of this
Additional security behaviors and mechanisms may be added on top of configuration is to set link-layer keys, and to establish a secure
this minimal framework. end-to-end session between each pledge and the join registrar who may
use that to further configure the pledge. Additional security
behaviors and 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 http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 6, 2017. This Internet-Draft will expire on September 13, 2017.
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 (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Join Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 3. One-Touch Assumptions . . . . . . . . . . . . . . . . . . . . 4
3.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 5 4. Join Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 5 4.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 5
3.3. Step 3 - Security Handshake . . . . . . . . . . . . . . . 5 4.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 6
3.3.1. Pre-Shared Key . . . . . . . . . . . . . . . . . . . 6 4.3. Step 3 - Security Handshake . . . . . . . . . . . . . . . 6
3.3.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . 6 4.4. Step 4 - Simple Join Protocol - Join Request . . . . . . 8
3.4. Step 4 - Join Request . . . . . . . . . . . . . . . . . . 6 4.5. Step 5 - Simple Join Protocol - Join Response . . . . . . 8
3.5. Step 5 - Join Response . . . . . . . . . . . . . . . . . 6 5. Architectural Overview and Communication through Join Proxy . 8
4. Protocol Specification . . . . . . . . . . . . . . . . . . . 7 5.1. Stateless-Proxy CoAP Option . . . . . . . . . . . . . . . 9
4.1. Proxy Operation of JA . . . . . . . . . . . . . . . . . . 7 6. Security Handshake . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Implementation of origin_info . . . . . . . . . . . . 8 6.1. Discovery Message . . . . . . . . . . . . . . . . . . . . 11
4.2. OSCOAP Security Context Instantiation . . . . . . . . . . 8 7. Simple Join Protocol Specification . . . . . . . . . . . . . 11
4.3. Implementation of Join Request . . . . . . . . . . . . . 9 7.1. OSCOAP Security Context Instantiation . . . . . . . . . . 12
4.4. Implementation of Join Response . . . . . . . . . . . . . 9 7.2. Specification of Join Request . . . . . . . . . . . . . . 13
5. Link-layer requirements . . . . . . . . . . . . . . . . . . . 10 7.3. Specification of Join Response . . . . . . . . . . . . . 13
5.1. Well-known beacon authentication key . . . . . . . . . . 10 8. Link-layer Requirements . . . . . . . . . . . . . . . . . . . 15
5.2. Private beacon authentication key . . . . . . . . . . . . 10 9. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . . . 15
6. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . . . 11 10. Rekeying and Rejoin . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. Key Derivations . . . . . . . . . . . . . . . . . . . . . . . 16
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 14.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 13 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 14 16.1. Normative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 16.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
When a previously unknown device seeks admission to a 6TiSCH This document describes the minimal feature set for a new device,
[RFC7554] network (to "join"), it first needs to synchronize to the termed pledge, to securely join a 6TiSCH network. As a successful
network. The device then configures its IPv6 address and outcome of this process, the pledge is able to securely communicate
authenticates itself, and also validates that it is joining the right with its neighbors, participate in the routing structure of the
network. At this point it can expect to interact with the network to network or establish a secure session with an Internet host.
configure its link-layer keying material. Only then may the node
establish an end-to-end secure session with an Internet host using
DTLS [RFC6347] or OSCOAP [I-D.ietf-core-object-security]. Once the
application requirements are known, the device 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 describes the mechanisms comprising a minimal feature When a pledge seeks admission to a 6TiSCH [RFC7554] network, it first
set for a device to join a 6TiSCH network, up to the point where it needs to synchronize to the network. The pledge then configures its
can establish a secure session with an Internet host. 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].
It presumes a network as described by [RFC7554], This document presumes a network as described by [RFC7554],
[I-D.ietf-6tisch-6top-protocol], and [I-D.ietf-6tisch-terminology]. [I-D.ietf-6tisch-6top-protocol], and [I-D.ietf-6tisch-terminology].
It assumes the joining device pre-configured with either a: It assumes the pledge pre-configured with either a:
o pre-shared key (PSK), o pre-shared key (PSK),
o raw public key (RPK), o raw public key (RPK),
o or a locally-valid certificate and a trust anchor. o or a locally-valid certificate and a trust anchor.
As the outcome of the join process, the joining device expects one or As the outcome of the join process, the pledge expects one or more
more link-layer key(s) and optionally a temporary network identifier. link-layer key(s) and optionally a temporary network identifier.
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], and defined in [I-D.ietf-6tisch-terminology], [RFC7252],
[I-D.ietf-core-object-security]. The entities participating in the [I-D.ietf-core-object-security], and
protocol that is specified in this document are: [I-D.ietf-anima-bootstrapping-keyinfra]. The following terms are
imported: pledge, join proxy, join registrar/coordinator, drop ship,
imprint, enrollment, ownership voucher.
o JN: Joining node - the device attempting to join a particular Pledge: the prospective device, which has the identity provided to
6TiSCH network. at the factory.
o JCE: Join coordinating entity - central entity responsible for Joined Node: the prospective device, after having completed the join
process, often just called a Node.
Join Proxy (JP): a stateless relay that provides connectivity
between the pledge and the join registrar/coordinator.
Join Registrar/Coordinator (JRC): central entity responsible for
authentication and authorization of joining nodes. authentication and authorization of joining nodes.
o JA: Join assistant - the device within radio range of the JN that 3. One-Touch Assumptions
generates Enhanced Beacons (EBs) and facilitates end-to-end
communications between the JN and JCE.
3. Join Overview This document assumes the one-touch scenario, where devices are
provided with some mechanism by which a secure association may be
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.
This section describes the steps taken by a joining node (JN) in a Some examples of how to do this could include:
6TiSCH network. When a previously unknown device seeks admission to
a 6TiSCH [RFC7554] network, the following exchange occurs:
1. The JN listens for an Enhanced Beacon (EB) frame o JTAG interface
[IEEE802154-2015]. This frame provides network synchronization
o serial (craft) console interface
o pushes of physical buttons simultaneous to network attachment
o unsecured devices operated in a Faraday cage
There are likely many other ways as well. What is assumed is that
there can be a secure, private conversation between the Join
Registrar/Coordinator, and the pledge, and that the two devices can
exchange some trusted bytes of information.
4. Join Overview
This section describes the steps taken by a pledge in a 6TiSCH
network. When a previously unknown device seeks admission to a
6TiSCH [RFC7554] network, the following exchange occurs:
1. The pledge listens for an Enhanced Beacon (EB) frame
[IEEE8021542015]. 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 Assistant node sending the beacons, which plays the role of Join Proxy (JP)
(JA) for the JN, and when it can expect to receive a frame. for the pledge, and when it can expect to receive a frame.
2. The JN configures its link-local IPv6 address and advertises it 2. The pledge configures its link-local IPv6 address and advertizes
to JA. it to Join Proxy (JP).
3. The JN sends packets to the JA device in order to securely 3. The pledge sends packets to JP in order to securely identify
identify itself to the network. These packets are directed to itself to the network. These packets are directed to the Join
the Join Coordination Entity (JCE), which may be the JA or Registrar/Coordinator (JRC), which may be co-located on the JP or
another device. another device.
4. The JN receives one or more packets from JCE (via the JA) that 4. The pledge receives one or more packets from JRC (via the JP)
sets up one or more link-layer keys used to authenticate that sets up one or more link-layer keys used to authenticate
subsequent transmissions to peers. subsequent transmissions to peers.
From the joining node's perspective, minimal joining is a local From the pledge's perspective, minimal joining is a local phenomenon
phenomenon - the JN only interacts with the JA, and it need not know - the pledge only interacts with the JP, and it need not know how far
how far it is from the DAG root, or how to route to the JCE. Only it is from the DAG root, or how to route to the JRC. Only after
after establishing one or more link-layer keys does it need to know establishing one or more link-layer keys does it need to know about
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 handshake is shown as a transaction diagram in Figure 1:
+-----+ +----------+ +-----------+ +--------+ +-------+ +--------+
| JCE | | JA | | JN | | pledge | | JP | | JRC |
| | | | | | | | | | | |
+-----+ +----------+ +-----------+ +--------+ +-------+ +--------+
| | | | | |
| |-----------ENH BEACON (1)-->| |<----ENH BEACON (1)-------| |
| | | | | |
| |<--Neighbor Discovery (2)-->| |<-Neighbor Discovery (2)->| |
| | | | | |
|<--Sec. Handshake (3a)--|---Security Handshake (3)-->| |<---Sec. Handshake (3)----|---Sec. Handshake (3a)--->|
| | | | | |
|<----Join request (4a)--|---------Join request (4)---| .......................................................................
| | | . |-----Join Request (4)-----|------Join Request (4a)-->| .
|----Join response (5a)--|--------Join response (5)-->| . | | | Simple Join .
| | | . |<---Join Response (5)-----|-----Join Response (5a)---| Protocol .
. | | | .
.......................................................................
Figure 1: Message sequence for join protocol. Figure 1: Overview of the join process.
The details of each step are described in the following sections. The details of each step are described in the following sections.
3.1. Step 1 - Enhanced Beacon 4.1. Step 1 - Enhanced Beacon
The JN hears an EB from the JA and synchronizes itself to the joining Due to the channel hopping nature of 6TiSCH, transmissions take place
schedule using the cells contained in the EB. At this point the JN on physical channels in a circular fashion. For that reason,
MAY proceed to step 2, or continue to listen for additional EBs. If Enhanced Beacons (EBs) are expected to be found by listening on a
more than one EB is heard, the JN MAY use a metric based on DAG rank single channel. However, because some channels may be blacklisted, a
and received signal level of the EB, or other factors to decide which new pledge must listen for Enhanced Beacons for a certain period on
JA to use for the security handshake in step 3. Details on how a JN each of the 16 possible channels. This search process entails having
chooses the JA are out of scope of this specification. the pledge keep the receiver portion of its radio active for the
entire period of time.
3.2. Step 2 - Neighbor Discovery 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.
At this point, JN forms its link-local IPv6 address based on EUI64 Once a candidate network has been selected, the pledge can transition
and MAY further follow the Neighbor Discovery (ND) process described into a low-power duty cycle, waking up only when the provided
in Section 5 of [RFC6775]. schedule indicates shared slots which the pledge may use for the join
process.
3.3. Step 3 - Security Handshake At this point the pledge may proceed to step 2, or continue to listen
for additional EBs.
The security handshake between JN and JCE uses Ephemeral Diffie- A pledge which receives only Enhanced Beacons containing Network ID
extensions [I-D.richardson-6tisch-join-enhanced-beacon] with the
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
At this point, the pledge forms its link-local IPv6 address based on
EUI64 and may register it at JP, in order to bootstrap the IPv6
neighbor tables. The Neighbor Discovery exchange shown in Figure 1
refers to a single round trip Neighbor Solicitation / Neighbor
Advertisement exchange between the pledge and the JP. The pledge may
further follow the Neighbor Discovery (ND) process described in
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 Hellman over COSE (EDHOC) [I-D.selander-ace-cose-ecdhe] to establish
the shared secret used to encrypt the join request and join response. the shared session secret used to encrypt the Simple Join Protocol.
The security handshake step is OPTIONAL in case PSKs are used, while The security handshake step is OPTIONAL in case PSKs are used, while
it is REQUIRED for RPKs and certificates. In case the handshake step it is REQUIRED for RPKs and certificates.
is omitted, the shared secret used for protection of the join request
and join response in the next step is the PSK. This means that the
protocol trades off perfect forward secrecy for reduced traffic load
between JN and JCE. 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 JN, however,
would also imply the compromise of the same keying material, as it is
likely to be found in node's memory.
3.3.1. Pre-Shared Key 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, The Diffie-Hellman key exchange and the use of EDHOC is optional,
when using a pre-shared symmetric key. This cuts down on traffic when using a pre-shared symmetric key. This cuts down on traffic
between JCE and JN, but requires pre-configuration of the shared key between JRC and pledge, but requires pre-configuration of the shared
on both devices. key on both devices.
It is REQUIRED to use unique PSKs for each JN. 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.
3.3.2. Asymmetric Keys 4.3.2. Asymmetric Keys
The Security Handshake step is required, when using asymmetric keys. The Security Handshake step is required, when using asymmetric keys.
Before conducting the Diffie-Hellman key exchange using EDHOC Before conducting the Diffie-Hellman key exchange using EDHOC
[I-D.selander-ace-cose-ecdhe] the JN and JCE need to receive and [I-D.selander-ace-cose-ecdhe] the pledge and JRC need to receive and
validate each other's public key certificate. When RPKs are pre- validate each other's public key certificate. As detailed above,
configured at JN and JCE, they can directly proceed to the handshake. 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].
3.4. Step 4 - Join Request When RPKs are pre-configured at pledge and JRC, they can directly
proceed to the handshake.
The join request is sent from the JN to the JA using the slot 4.4. Step 4 - Simple Join Protocol - Join Request
information from the EB, and forwarded to the JCE.
The join request is authenticated/encrypted end-to-end using AES-CCM- The Join Request that makes part of the Simple Join Protocol is sent
16-64-128 algorithm from [I-D.ietf-cose-msg] and a key derived from from the pledge to the JP using the shared slot as described in the
the shared secret from step 3. The nonce is derived from the shared EB, and forwarded to the JRC. Which slot the JP uses to transmit to
secret, JN's EUI64 and a monotonically increasing counter initialized the JRC is out of scope: some networks may wish to dedicate specific
to 0 when first starting. slots for this join traffic.
3.5. Step 5 - Join Response The join request is typically authenticated/encrypted end-to-end
using AES-CCM-16-64-128 algorithm from [I-D.ietf-cose-msg] and a key
derived from the shared secret from step 3. Algorithm negotiation is
described in detail in [I-D.selander-ace-cose-ecdhe].
The join response is sent from the JCE to the JN through JA that The nonce is derived from the shared secret, the pledge's EUI64 and a
serves as a stateless relay. Packet containing the join response monotonically increasing counter initialized to 0 when first
travels on the path from JCE to JA using pre-established routes in starting.
the network. The JA delivers it to the JN using the slot information
from the EB. JA 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 using AES-CCM-16-64-128 4.5. Step 5 - Simple Join Protocol - Join Response
algorithm from [I-D.ietf-cose-msg] and a key derived from the shared
secret from step 3. The nonce is derived from the shared secret,
JN's EUI64 and a monotonically increasing counter matching that of
the join request.
The join response contains one or more (per-peer) link-layer key(s) The Join Response that makes part of the Simple Join Protocol is sent
K2 that the JN will use for subsequent communication. It optionally from the JRC to the pledge through JP that serves as a stateless
also contains an IEEE 802.15.4 short-address [IEEE802154-2015] relay. Packet containing the Join Response travels on the path from
assigned to JN by JCE. 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.
4. Protocol Specification The join response is typically authenticated/encrypted using AES-CCM-
16-64-128 algorithm from [I-D.ietf-cose-msg] and a key derived from
the shared secret from step 3.
The join protocol in Figure 1 is implemented over Constrained The nonce is derived from the shared secret, pledge's EUI64 and a
Application Protocol (CoAP) [RFC7252]. JN plays the role of a CoAP monotonically increasing counter matching that of the join request.
client, JCE the role of a CoAP server, while JA implements CoAP
forward proxy functionality [RFC7252]. Since JA is likely a The join response contains one or more link-layer key(s) that the
pledge will use for subsequent communication. Each key that is
provided by the JRC is associated with an 802.15.4 key identifier.
In other link-layer technologies, a different identifier may be
substituted. Join Response optionally also contains an IEEE 802.15.4
short address [IEEE8021542015] assigned to pledge by JRC.
5. Architectural Overview and Communication through Join Proxy
The protocol in Figure 1 is implemented over Constrained Application
Protocol (CoAP) [RFC7252]. The Pledge plays the role of a CoAP
client, JRC the role of a CoAP server, while JP implements CoAP
forward proxy functionality [RFC7252]. Since JP is also likely a
constrained device, it does not need to implement a cache but rather constrained device, it does not need to implement a cache but rather
process forwarding-related CoAP options and make requests on behalf process forwarding-related CoAP options and make requests on behalf
of JN that is not yet part of the network. of pledge that is not yet part of the network.
JN and JCE MUST protect their exchange end-to-end (i.e. through the The pledge communicates with a Join Proxy (JP) over link-local IPv6
proxy) using Object Security of CoAP (OSCOAP) addresses. The pledge designates a JP as a proxy by including in the
[I-D.ietf-core-object-security]. CoAP requests to the JP the Proxy-Scheme option with value "coap"
(CoAP-to-CoAP proxy). The pledge MUST include the Uri-Host option
with its value set to the well-known JRC's alias - "6tisch.arpa".
The pledge does not need to learn the actual IPv6 address of JRC at
any time during the join protocol. The JP knows the address of the
JRC, via a provisioning process that occured when the JP, acting as a
pledge, joined. The initial bootstrap of the DODAG root would
require explicit provisioning of the JRC address.
4.1. Proxy Operation of JA 5.1. Stateless-Proxy CoAP Option
JN designates a JA as a proxy by including in the CoAP requests to The CoAP proxy by default keeps per-client state information in order
the JA the Proxy-Scheme option with value "coap" (CoAP-to-CoAP to forward the response towards the originator of the request
proxy). JN MUST include the Uri-Host option with its value set to (client). This state information comprises CoAP token, but the
the well-known JCE's alias - "6tisch.jce". JN does not need to learn implementations also need to keep track of the IPv6 address of the
the actual IPv6 address of JCE at any time during the join protocol. host, as well as the corresponding UDP source port number. In the
JA resolves the address by performing a GET request at "/jce" setting where the proxy is a constrained device and there are
resource of its parent in the DODAG. potentially many clients, as in the case of JP, this makes it prone
to Denial of Service (DoS) attacks, due to the limited memory.
Note that the CoAP proxy by default keeps state information in order The Stateless-Proxy CoAP option (c.f. Figure 2) allows the proxy to
to forward the response towards the originator of the request. This insert within the request the state information necessary for
state information comprises CoAP token, but the implementations also relaying the response back to the client. Note that the proxy still
need to keep track of the IPv6 address of the host, as well as the needs to keep some state, such as for performing congestion control
corresponding UDP source port number. In the setting where the proxy or request retransmission, but what is aimed with Stateless-Proxy
is a constrained device, as in the case of JA, this makes it prone to option is to free the proxy from keeping per-client state.
Denial of Service (DoS) attacks, due to the limited memory.
In order to facilitate a stateless implementation of JA proxying, JN Stateless-Proxy option is critical, Safe-to-Forward, not part of the
shall encode in the CoAP message the information necessary for the JA cache key, not repeatable and opaque. When processed by OSCOAP,
to send the response back - "origin_info". For this purpose, JN uses Stateless-Proxy option is neither encrypted nor integrity protected.
the "Context Identifier (Cid)" parameter of OSCOAP's security context
structure. Context Identifier is sent in clear, readable by JA, and
MUST be echoed back in the response from JCE. This makes it possible
to implement JA's CoAP proxy in a stateless manner. It also allows
JCE to look up the right security context for communication with a
given JN.
4.1.1. Implementation of origin_info +-----+---+---+---+---+-----------------+--------+--------+
| No. | C | U | N | R | Name | Format | Length |
+-----+---+---+---+---+-----------------+--------+--------|
| TBD | x | | x | | Stateless-Proxy | opaque | 1-255 |
+-----+---+---+---+---+-----------------+--------+--------+
C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable
The origin_info is implemented as a CBOR [RFC7049] array object Figure 2: Stateless-Proxy CoAP Option
containing:
o EUI64: JN's EUI64 address 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. Example state
information includes IPv6 address of the client, its UDP source port,
and the CoAP token. For security reasons, the state information MUST
be authenticated, MUST include a freshness indicator (e.g. a sequence
number or timestamp) and MAY be encrypted. The proxy may use an
appropriate COSE structure [I-D.ietf-cose-msg] 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.
o source_port: JN's UDP source port Once the proxy has received the CoAP response with 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.
o token: JN's CoAP token 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
server times out. Likewise, if the response to the proxy's request
does not contain the Stateless-Proxy option, for example when the
option is not supported by the server, the proxy is not able to
return the response to the client.
origin_info = [ 6. Security Handshake
EUI64 : bstr,
source_port : uint,
token : uint
]
4.2. OSCOAP Security Context Instantiation 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.
The OSCOAP security context MUST be derived at JN and JCE as per 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].
+--------+ +--------+
| pledge | | JRC |
| | | |
+--------+ +--------+
| Discovery Message |
+-------------------------------->|
| |
| Optional ACK |
|< - - - - - - - - - - - - - - - -+
| |
| |
| EDHOC message_1 |
|<--------------------------------+
| |
| EDHOC message_2 |
+-------------------------------->|
| |
| EDHOC message_3 |
|<--------------------------------+
| |
Figure 3: Transaction diagram of the security handshake.
6.1. Discovery Message
Pledge triggers the security handshake by sending a discovery message
to the JRC. This initial message does not make part of the EDHOC
handshake. JRC is the initiator of the EDHOC run and is able to
schedule the execution of many concurrent enrollments at will by
acknowledging the request and sending a separate, delayed response.
The Discovery Message SHALL be mapped to a CoAP request:
o The request method is POST.
o The Proxy-Scheme option is set to "coap".
o The Uri-Host option is set to "6tisch.arpa".
o The Uri-Path option is set to "edhoc".
o The payload is optional and contains pledge's EUI-64.
7. Simple Join Protocol Specification
Simple Join Protocol is a single round trip protocol (c.f. Figure 4)
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
the proxy) using Object Security of CoAP (OSCOAP)
[I-D.ietf-core-object-security].
+--------+ +--------+
| pledge | | JRC |
| | | |
+--------+ +--------+
| |
| Join Request |
+-------------------------------->|
| |
| Join Response |
|<--------------------------------+
| |
Figure 4: Transaction diagram of the Simple Join Protocol.
7.1. OSCOAP Security Context Instantiation
The OSCOAP security context MUST be derived at pledge and JRC as per
Section 3.2 of [I-D.ietf-core-object-security] using HKDF [RFC5869] Section 3.2 of [I-D.ietf-core-object-security] using HKDF [RFC5869]
as the key derivation function. as the key derivation function.
o Context Identifier (Cid) MUST be the origin_info object wrapped as o Master Secret MUST be the secret generated by the run of EDHOC as
a byte string (bstr). per Appendix B of [I-D.selander-ace-cose-ecdhe], or the PSK in
case EDHOC step was omitted.
o Sender ID of the pledge MUST be set to the concatenation of its
EUI-64 and byte string 0x00.
o Recipient ID (ID of JRC) MUST be set to the concatenation of
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 AES-CCM-16-64-128 from o Algorithm MUST be set to AES-CCM-16-64-128 from
[I-D.ietf-cose-msg]. CoAP messages are therefore protected with [I-D.ietf-cose-msg]. CoAP messages are therefore protected with
an 8-byte CCM authentication tag and the algorithm uses 13-byte an 8-byte CCM authentication tag and the algorithm uses 13-byte
long nonces. long nonces.
o Base key (base_key) MUST be the secret generated by the run of
EDHOC, or the PSK in case EDHOC step was omitted.
o Sender ID of JN MUST be set to 0x00, while the ID of JCE MUST be
set to 0x01.
The hash algorithm that instantiates HKDF MUST be SHA-256 [RFC4231]. The hash algorithm that instantiates HKDF MUST be SHA-256 [RFC4231].
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 static IVs for each side of the conversation. Nonces are keys and static IVs for each side of the conversation. Nonces are
constructed by XOR'ing the static IV with current sequence number. constructed by XOR'ing the static IV with current sequence number.
The context derivation process occurs exactly once. Implementations The context derivation process occurs exactly once.
MUST ensure that multiple CoAP requests to different JCEs 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 JN tries to
join one network at a time.
4.3. Implementation of Join Request Implementations MUST ensure that multiple CoAP requests to different
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.
Join Request message SHALL be mapped to a CoAP request: 7.2. Specification of Join Request
Message Join Request SHALL be mapped to a CoAP request:
o The request method is GET. o The request method is GET.
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.jce". 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] and OSCOAP parameters set as
described above. described above.
4.4. Implementation of Join Response 7.3. Specification of Join Response
If OSCOAP processing is a success, Join Response message SHALL be a If OSCOAP processing is a success and the pledge is authorized to
CoAP response: join the network, message Join Response SHALL be mapped to a CoAP
response:
o The response Code is 2.05 (Content). o The response Code is 2.05 (Content).
o The payload is a CBOR array containing, in order: o Content-Format option is set to application/cbor.
* COSE Key Set [I-D.ietf-cose-msg]. Each key in the Key Set o The payload is a CBOR [RFC7049] array containing, in order:
SHALL be a symmetric key. A key that is present in the Key Set
and does not have an identifier is assumed to be "K2" link-
layer key from [I-D.ietf-6tisch-minimal]. Parameter "kid" of
the COSE Key structure SHALL be used to denote pair-wise keys
if present, where the value SHALL be set to the address of the
corresponding peer.
* Optional byte string representing IEEE 802.15.4 short address * COSE Key Set, specified in [I-D.ietf-cose-msg], containing one
assigned to JN. If the length of the byte string is different or more link-layer keys. The mapping of individual keys to
than 2 bytes, the implementation SHOULD ignore it. 802.15.4-specific parameters is described in Section 7.3.1.
* Optional short address that is assigned to the pledge. The
format of the short address follows Section 7.3.2.
payload = [ payload = [
COSE_KeySet, COSE_KeySet,
? short_address : bstr, ? short_address,
] ]
In case JCE determines that JN is not supposed to join the network 7.3.1. Link-layer Keys Transported in COSE Key Set
(e.g. by failing to find an appropriate security context), it should
respond with a 4.01 Unauthorized error. Upon reception of a 4.01
Unauthorized, JN SHALL attempt to join the next advertised 6TiSCH
network. If all join attempts have failed at JN, JN SHOULD signal to
the user by an out-of-band mechanism the presence of an error
condition.
5. Link-layer requirements Each key in the COSE Key Set [I-D.ietf-cose-msg] SHALL be a symmetric
key. If "kid" parameter of the COSE Key structure is present, the
corresponding keys SHALL belong to an IEEE 802.15.4 KeyIdMode 0x01
class. In that case, parameter "kid" of COSE Key structure SHALL be
used to carry IEEE 802.15.4 KeyIndex value. If the "kid" parameter
is not present in the transported key, the application SHALL consider
the key to be an IEEE 802.15.4 KeyIdMode 0x00 (implicit) key. This
document does not support IEEE 802.15.4 KeyIdMode 0x02 and 0x03 class
keys.
All frames in a 6TiSCH network MUST use link-layer frame security. 7.3.2. Short Address
The frame security options MUST include frame authentication, and MAY
include frame encryption.
In order for the JN to be able to validate that the Enhanced Beacon Optional "short_address" structure transported as part of the join
frame is coming from a 6TiSCH network, EB frames are authenticated at response payload represents IEEE 802.15.4 short address assigned to
the link layer using CCM* per [IEEE802154-2015]. Link-layer frames the pledge. It is encoded as CBOR array object, containing in order:
are protected with a 16-byte key, and a 13-byte nonce constructed
from current Absolute Slot Number (ASN) and the source (the JA for o Byte string, containing the 16-bit address.
EBs) address, as shown in Figure 2:
o Optional lease time parameter, "lease_asn". The value of the
"lease_asn" parameter is the 5-byte Absolute Slot Number (ASN)
corresponding to its expiration, carried as a byte string in
network byte order.
short_address = [
address : bstr,
? lease_asn : bstr,
]
It is up to the joined node to request a new short address before the
expiry of its previous address. The mechanism by which the node
requests renewal is the same as during join procedure, as described
in Section 10. The assigned short address is used for configuring
both Layer 2 short address and Layer 3 addresses.
7.3.3. Error Handling
In the case JRC determines that pledge is not supposed to join the
network (e.g. by failing to find an appropriate security context), it
should respond with a 4.01 Unauthorized error. Upon reception of a
4.01 Unauthorized, the pledge SHALL attempt to join the next
advertised 6TiSCH network. If all join attempts have failed at
pledge, the pledge SHOULD signal to the user by an out-of-band
mechanism the presence of an error condition.
In the case that the JRC determines that the pledge is not (yet)
authorized to join the network, but a further zero-touch process
might permit it, the JRC responds with a 2.05 (Content) code, but the
payload contains the single CBOR string "prov" (for "provisional").
No link-layer keys or short address is returned.
This response is typically only expected when in asymmetric
certificate mode using 802.1AR IDevID certificates. But for reasons
of provisioning or device reuse, this could occur even when a one-
touch PSK authentication process was expected.
8. Link-layer Requirements
In an operational 6TiSCH network, all frames MUST use link-layer
frame security. The frame security options MUST include frame
authentication, and MAY include frame encryption.
Link-layer frames are protected with a 16-byte key, and a 13-byte
nonce constructed from current Absolute Slot Number (ASN) and the
source (the JP for EBs) address, as shown in Figure 5:
+-------------------------------------------+ +-------------------------------------------+
| Address (8B or 00-padded 2B) | ASN (5B) | | Address (8B or 00-padded 2B) | ASN (5B) |
+-------------------------------------------+ +-------------------------------------------+
Figure 2: Link-layer CCM* nonce construction Figure 5: Link-layer CCM* nonce construction
The JN uses the initial key K1 [I-D.ietf-6tisch-minimal] until it is The pledge does not initially do any authentication of the EB frames,
configured with a new link-layer key K2 as described above. JA as it does not know the K1 key. When sending frames, the pledge
SHOULD secure/verify DATA and ACKNOWLEDGMENT frames destined/ sends unencrypted and unauthenticated frames. JP accepts these
originated at JN with K1 only during the duration of the join frames (exempt mode in 802.15.4) for the duration of the join
process. How JA learns whether the join process is ongoing is out of process. How JP learns whether the join process is ongoing is out of
scope of this specification. scope of this specification.
As the EB itself does not contain security information, where the As the EB itself cannot be authenticated by pledge, an attacker may
link key is known, an attacker may craft a frame that appears to be a craft a frame that appears to be a valid EB, since the pledge can
valid EB, since the JN can neither know the ASN a priori nor verify neither know the ASN a priori nor verify the address of the JP. This
the address of the JA. This permits a Denial of Service (DoS) attack permits a Denial of Service (DoS) attack at the pledge. Beacon
at the JN. Beacon authentication keys are discussed in Section 5.1 authentication keys are discussed in [I-D.ietf-6tisch-minimal].
and Section 5.2.
5.1. Well-known beacon authentication key 9. Asymmetric Keys
For zero-touch operation, where any 6TiSCH device can attempt to join Certificates or pre-configured RPKs may be used to exchange public
any 6TiSCH network out of the box, a well-known EB link-layer key keys between the pledge and JRC. The key pair is generated using
MUST be used. The value of this key is specified in elliptic curve secp256r1, and the certificate containing the public
[I-D.ietf-6tisch-minimal] key is signed using ECDSA. (XXX: would be nice to move to EdDSA)
5.2. Private beacon authentication key The certificate itself may be a compact representation of an X.509
certificate, or a full X.509 certificate. Compact representation of
X.509 certificates is out of scope of this specification. The
certificate is signed by a root CA whose certificate is installed on
all nodes participating in a particular 6TiSCH network, allowing each
node to validate the certificate of the JRC or pledge as appropriate.
Some pre-configuration MAY be done when the device is manufactured or 10. Rekeying and Rejoin
designated for a specific network (i.e. the network is one-touch) or
a network operator may not wish to allow arbitrary devices to try to
join. A private (per-vendor, or per-installation) EB link-layer key
MAY be used in place of a well-known key to create a private network.
6. Asymmetric Keys 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.
Certificates or pre-configured RPKs may be used to exchange public 11. Key Derivations
keys between the JN and JCE. The key pair is generated using
elliptic curve secp256r1, and the certificate containing the public
key is signed using ECDSA. The certificate itself may be a compact
representation of an X.509 certificate, or a full X.509 certificate.
Compact representation of X.509 certificates is out of scope of this
specification. The certificate is signed by a root CA whose
certificate is installed on all nodes participating in a particular
6TiSCH network, allowing each node to validate the certificate of the
JCE or JN as appropriate.
7. Security Considerations When EDHOC is used to derive keys, the cost of the asymmetric
operation can be amortized over any additional connections that may
be required between the node (during or after joining) and the JRC.
In case PSKs are used, this document mandates that JN and JCE are Each application SHOULD use a unique session key. EDHOC was designed
pre-configured with unique keys. The uniqueness of generated nonces with this in mind. In order to accomplish this, the EDHOC key
is guaranteed under the assumption of unique EUI64 identifiers for derivation algorithm can be run with a different label. Other users
each JN. Note that the address of the JCE does not take part in of this key MUST define the label.
nonce construction. Therefore, even under the assumption of a PSK
shared by a group of nodes, the nonces constructed as part of the
different responses are unique. The design differentiates between
nonces constructed for requests and nonces constructed for responses
by different sender identifiers (0x00 for JN and 0x01 for JCE).
Being a stateless relay, JA blindly forwards the join traffic into 12. Security Considerations
the network. While the exchange between JN and JA takes place over a
shared cell, join traffic is forwarded using dedicated cells on the In case PSKs are used, this document mandates that the pledge and JRC
JA to JCE path. In case of distributed scheduling, the join traffic are pre-configured with unique keys. The uniqueness of generated
may therefore cause intermediate nodes to request additional nonces is guaranteed under the assumption of unique EUI64 identifiers
bandwidth. Because the relay operation of JA is implemented at the for each pledge. Note that the address of the JRC does not take part
application layer, JA is the only hop on the JA-6LBR path that can in nonce construction. Therefore, even should an error occur, and a
distinguish join traffic from regular IP traffic in the network. It PSK shared by a group of nodes, the nonces constructed as part of the
is therefore permitted to implement rate limiting at JA. different responses are unique. The PSK is still important for
authentication of the pledge and authentication of the JRC to the
pledge. Should an attacker come to know the PSK, then a man-in-the-
middle attack is possible. The well known problem with Bluetooth
headsets with a "0000" pin applies here. The design differentiates
between nonces constructed for requests and nonces constructed for
responses by different sender identifiers (0x00 for pledge and 0x01
for JRC).
Being a stateless relay, JP blindly forwards the join traffic into
the network. While the exchange between pledge and JP takes place
over a shared cell, join traffic is forwarded using dedicated cells
on the JP to JRC path. In case of distributed scheduling, the join
traffic may therefore cause intermediate nodes to request additional
bandwidth. (EDNOTE: this is a problem that needs to be solved)
Because the relay operation of JP is implemented at the application
layer, JP is the only hop on the JP-6LBR path that can distinguish
join traffic from regular IP traffic in the network. It is therefore
recommended to implement stateless rate limiting at JP: a simple
bandwidth (in bytes or packets/second) 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 join traffic makes
the network prone to DoS attacks by congesting the JA with bogus the network prone to DoS attacks by congesting the JP with bogus
radio traffic. As such an attacker is limited by emitted radio radio traffic. As such an attacker is limited by emitted radio
power, redundancy in the number of deployed JAs alleviates the issue power, redundancy in the number of deployed JPs alleviates the issue
and also gives JN a possibility to use the best available link for and also gives the pledge a possibility to use the best available
join. How a network node decides to become a JA is out of scope of link for join. How a network node decides to become a JP is out of
this specification. scope of this specification.
Because the well-known beacon authentication key does not provide any At the time of the join, the pledge has no means of verifying the
security, it is feasible for an attacker to generate EBs that will content in the EB and has to accept it at "face value". In case the
get accepted at JN. At the time of the join, JN has no means of pledge tries to join an attacker's network, the join response message
verifying the content in the EB and has to accept it at "face value". in such cases will either fail the security check or time out. The
As the join response message in such cases will either fail the pledge may implement a blacklist in order to filter out undesired
security check or time out, JN may implement a blacklist in order to beacons and try to join the next seemingly valid network. The
filter out undesired beacons and try to join the next seemingly valid blacklist alleviates the issue but is effectively limited by the
network. The blacklist alleviates the issue but is effectively node's available memory. Such bogus beacons will prolong the join
limited by the node's available memory. Such bogus beacons will time of the pledge and so the time spent in "minimal"
prolong the join time of JN and so the time spent in "minimal" [I-D.ietf-6tisch-minimal] duty cycle mode.
[I-D.ietf-6tisch-minimal] duty cycle mode. The permitted practice is
to use a private, per-installation beacon authentication key.
8. Privacy Considerations 13. Privacy Considerations
This specification relies on the uniqueness of EUI64 that is This specification relies on the uniqueness of EUI64 that is
transferred in clear as part of the security context identifier. transferred in clear as part of the security context identifier.
Privacy implications of using such long-term identifier are discussed (EDNOTE: should we say IID here?) Privacy implications of using such
in [RFC7721] and comprise correlation of activities over time, long-term identifier are discussed in [RFC7721] and comprise
location tracking, address scanning and device-specific vulnerability correlation of activities over time, location tracking, address
exploitation. Since the join protocol is executed rarely compared to scanning and device-specific vulnerability exploitation. Since the
the network lifetime, long-term threats that arise from using EUI64 join protocol is executed rarely compared to the network lifetime,
are minimal. In addition, the join response message contains an long-term threats that arise from using EUI64 are minimal. In
optional short address which can be assigned by JCE to JN. Short addition, the join response message contains an optional short
address which can be assigned by JRC to the pledge. The short
address is independent of the long-term identifier EUI64 and is address is independent of the long-term identifier EUI64 and is
encrypted in the response. For that reason, it is not possible to encrypted in the response. For that reason, it is not possible to
correlate the short address with the EUI64 used during the join. Use correlate the short address with the EUI64 used during the join. Use
of short addresses once the join protocol completes mitigates the of short addresses once the join protocol completes mitigates the
aforementioned privacy risks. In addition, EDHOC may be used for aforementioned privacy risks. In addition, EDHOC may be used for
identity protection during the join protocol by generating a random identity protection during the join protocol by generating a random
context identifier in place of the EUI64 context identifier in place of the EUI64
[I-D.selander-ace-cose-ecdhe]. [I-D.selander-ace-cose-ecdhe].
9. IANA Considerations 14. IANA Considerations
There is no IANA action required for this document. Note to RFC Editor: Please replace all occurrences of "[[this
document]]" with the RFC number of this specification.
10. Acknowledgments This document allocates a well known name under the .arpa name space
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.
14.1. CoAP Option Numbers Registry
The Stateless-Proxy option is added to the CoAP Option Numbers
registry:
+--------+-----------------+-------------------+
| Number | Name | Reference |
+--------+-----------------+-------------------+
| TBD | Stateless-Proxy | [[this document]] |
+--------+-----------------+-------------------+
15. 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. The authors would also like to thank Francesca reviewing the draft. The authors would also like to thank Francesca
Palombini and Ludwig Seitz for participating in the discussions that Palombini and Ludwig Seitz for participating in the discussions that
have helped shape the document. have helped shape the document.
11. References 16. References
11.1. Normative References 16.1. Normative References
[I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security of CoAP (OSCOAP)", draft-ietf-core-
object-security-01 (work in progress), December 2016.
[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>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC3172] Huston, G., Ed., "Management Guidelines & Operational
Application Protocol (CoAP)", RFC 7252, Requirements for the Address and Routing Parameter Area
DOI 10.17487/RFC7252, June 2014, Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172,
<http://www.rfc-editor.org/info/rfc7252>. September 2001, <http://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, <http://www.rfc-editor.org/info/rfc7049>.
[I-D.ietf-cose-msg] [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Schaad, J., "CBOR Object Signing and Encryption (COSE)", Application Protocol (CoAP)", RFC 7252,
draft-ietf-cose-msg-24 (work in progress), November 2016. DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
[I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security of CoAP (OSCOAP)", draft-ietf-core-
object-security-01 (work in progress), December 2016.
11.2. Informative References
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement", RFC 7554,
DOI 10.17487/RFC7554, May 2015,
<http://www.rfc-editor.org/info/rfc7554>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<http://www.rfc-editor.org/info/rfc5869>.
[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
RFC 4231, DOI 10.17487/RFC4231, December 2005,
<http://www.rfc-editor.org/info/rfc4231>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<http://www.rfc-editor.org/info/rfc7721>.
[I-D.ietf-6tisch-minimal] 16.2. Informative References
Vilajosana, X., Pister, K., and T. Watteyne, "Minimal
6TiSCH Configuration", draft-ietf-6tisch-minimal-19 (work
in progress), January 2017.
[I-D.ietf-6tisch-6top-protocol] [I-D.ietf-6tisch-6top-protocol]
Wang, Q. and X. Vilajosana, "6top Protocol (6P)", draft- Wang, Q. and X. Vilajosana, "6top Protocol (6P)", draft-
ietf-6tisch-6top-protocol-03 (work in progress), October ietf-6tisch-6top-protocol-03 (work in progress), October
2016. 2016.
[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-08 (work in
progress), December 2016. progress), December 2016.
[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-04 (work in progress), October 2016.
[I-D.richardson-6tisch-join-enhanced-beacon]
Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational
Element encapsulation of 6tisch Join Information", draft-
richardson-6tisch-join-enhanced-beacon-01 (work in
progress), March 2017.
[I-D.richardson-6tisch-minimal-rekey]
Richardson, M., "Minimal Security rekeying mechanism for
6TiSCH", draft-richardson-6tisch-minimal-rekey-01 (work in
progress), February 2017.
[I-D.selander-ace-cose-ecdhe] [I-D.selander-ace-cose-ecdhe]
Selander, G., Mattsson, J., and F. Palombini, "Ephemeral Selander, G., Mattsson, J., and F. Palombini, "Ephemeral
Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace-
cose-ecdhe-04 (work in progress), October 2016. cose-ecdhe-04 (work in progress), October 2016.
[IEEE802154-2015] [IEEE8021542015]
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.
Appendix A. Example [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
RFC 4231, DOI 10.17487/RFC4231, December 2005,
<http://www.rfc-editor.org/info/rfc4231>.
Figure 3 illustrates a join protocol exchange in case PSKs are used. [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
JN instantiates the OSCOAP context and derives the traffic keys and Key Derivation Function (HKDF)", RFC 5869,
nonces from the PSK. It uses the instantiated context to protect the DOI 10.17487/RFC5869, May 2010,
CoAP request addressed with Proxy-Scheme option and well-known host <http://www.rfc-editor.org/info/rfc5869>.
name of JCE in the Uri-Host option. The example assumes a JA that is
already aware of JCE's IPv6 address and does not need to resolve the
well-known "6tisch.jce" host name. Triggered by the presence of
Proxy-Scheme option, JA forwards the request to the JCE. Once JCE
receives the request, it looks up the correct context based on the
context identifier (cid) field. It reconstructs OSCOAP's external
Additional Authenticated Data (AAD) needed for verification based on:
o Version field of the received CoAP header. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
o Code field of the received CoAP header. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>.
o Algorithm being the AES-CCM-16-64-128 from [I-D.ietf-cose-msg] [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement", RFC 7554,
DOI 10.17487/RFC7554, May 2015,
<http://www.rfc-editor.org/info/rfc7554>.
o Request URI reconstructed following [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
[I-D.ietf-core-object-security]. Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<http://www.rfc-editor.org/info/rfc7721>.
Replay protection is ensured by OSCOAP and the tracking of sequence Appendix A. Example
numbers at each side. In the example below, the response contains
sequence number 7 meaning that there have already been some attempts Figure 6 illustrates a join protocol exchange in case PSKs are used.
to join under a given context, not coming from the JN. Once JA Pledge instantiates the OSCOAP context and derives the traffic keys
receives the response, it looks up and decodes the cid field in order and nonces from the PSK. It uses the instantiated context to protect
to decide where to forward it. JA constructs the CoAP response to JN the CoAP request addressed with Proxy-Scheme option and well-known
by setting the CoAP token to the value decoded from cid and host name of JRC in the Uri-Host option. The example assumes a JP
constructs the link-local IPv6 address of JN from the EUI64 address that is already aware of JRC's IPv6 address and does not need to
found in the cid. Note that JA does not posses the key to decrypt resolve the well-known "6tisch.arpa" host name. Triggered by the
the COSE object present in the payload so the join_response object is presence of Proxy-Scheme option, JP forwards the request to the JRC
opaque to it. The response is matched to the request and verified and adds the Stateless-Proxy option with value set to the internally
for replay protection at JN using OSCOAP processing rules. Namely, needed state, authentication tag, and a freshness indicator. Once
to verify the response JN reconstructs the AAD based on: JRC receives the request, it looks up the correct context based on
the Sender ID (sid) parameter. It reconstructs OSCOAP's external
Additional Authenticated Data (AAD) needed for verification based on:
o Version field of the received CoAP header. o Version field of the received CoAP header.
o Code field of the received CoAP header. o Code field of the received CoAP header.
o Algorithm being the AES-CCM-16-64-128 from [I-D.ietf-cose-msg]. o Algorithm being the AES-CCM-16-64-128 from [I-D.ietf-cose-msg].
o Transaction identifier (Tid) of the corresponding CoAP request. o Request ID being set to pledge's EUI-64 concatenated with 0x00.
Tid contains the context identifier (origin_info object), Sender
ID (0x00 for JN), and Sender Sequence number (set to 1 in the
example).
In addition to AAD, JN also uses the explicit, protected fields in o Request Sequence number set to the value of "Partial IV" of the
the COSE message, present in the payload of the response. For more received COSE object.
details, see [I-D.ietf-core-object-security] and [I-D.ietf-cose-msg].
Replay protection is ensured by OSCOAP and the tracking of sequence
numbers at each side. In the example below, the response contains
sequence number 7 meaning that there have already been some attempts
to join under a given context, not coming from the pledge. Once JP
receives the response, it authenticates the Stateless-Proxy option
before deciding where to forward. JP sets its internal state to that
found in the Stateless-Proxy option. Note that JP does not posses
the key to decrypt the COSE object present in the payload so the
join_response object is opaque to it. The response is matched to the
request and verified for replay protection at pledge using OSCOAP
processing rules.
<--E2E OSCOAP--> <--E2E OSCOAP-->
Client Proxy Server Client Proxy Server
JN JA JCE Pledge JP JRC
| | | | | |
+----->| | Code: [0.01] (GET) +----->| | Code: [0.01] (GET)
| GET | | Token: 0x8c | GET | | Token: 0x8c
| | | Proxy-Scheme: [coap] | | | Proxy-Scheme: [coap]
| | | Uri-Host: [6tisch.jce] | | | Uri-Host: [6tisch.arpa]
| | | Object-Security: [cid:origin_info, seq:1, | | | Object-Security: [sid:EUI-64 | 0, seq:1,
| | | {Uri-Path:"j"}, | | | {Uri-Path:"j"},
| | | <Tag>] | | | <Tag>]
| | | Payload: - | | | Payload: -
| | | | | |
| +----->| Code: [0.01] (GET) | +----->| Code: [0.01] (GET)
| | GET | Token: 0x7b | | GET | Token: 0x7b
| | | Uri-Host: [6tisch.jce] | | | Uri-Host: [6tisch.arpa]
| | | Object-Security: [cid:origin_info, seq:1, | | | Object-Security: [sid:EUI-64 | 0, seq:1,
| | | {Uri-Path:"j"}, | | | {Uri-Path:"j"},
| | | <Tag>] | | | <Tag>]
| | | Payload: - | | | Stateless-Proxy: opaque state
| | | | | | Payload: -
| |<-----+ Code: [2.05] (Content) | | |
| | 2.05 | Token: 0x7b | |<-----+ Code: [2.05] (Content)
| | | Object-Security: - | | 2.05 | Token: 0x7b
| | | Payload: [cid: origin_info, seq:7, | | | Object-Security: -
| | | {join_response}, <Tag>] | | | Stateless-Proxy: opaque state
| | | | | | Payload: [ seq:7,
|<-----+ | Code: [2.05] (Content) | | | {join_response}, <Tag>]
| 2.05 | | Token: 0x8c | | |
| | | Object-Security: - |<-----+ | Code: [2.05] (Content)
| | | Payload: [cid: origin_info, seq:7, | 2.05 | | Token: 0x8c
| | | {join_response}, <Tag>] | | | Object-Security: -
| | | | | | Payload: [ seq:7,
| | | {join_response}, <Tag>]
| | |
Figure 3: Example of a join protocol exchange with a PSK. {} denotes Figure 6: Example of a join protocol exchange with a PSK. {} denotes
encryption and authentication, [] denotes authentication. encryption and authentication, [] denotes authentication.
Where origin_info and join_response are as follows. Where join_response is as follows.
origin_info:
[
h'00170d00060d9f0e', / JN's EUI64 /
49152, / JN's UDP source port /
0x8c / JN's CoAP token /
]
Encodes to h'834800170d00060d9f0e19c000188c' with a size of 15 bytes.
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 /
-1:h'e6bf4287c2d7618d6a9687445ffd33e6' / key value / 2 : h'01', / key id /
-1 : h'e6bf4287c2d7618d6a9687445ffd33e6' / key value /
} }
], ],
h'af93' / assigned short address / [
h'af93' / assigned short address /
]
] ]
Encodes to h'8281a201042050e6bf4287c2d7618d6a9687445ffd33e642af93' Encodes to
with a size of 26 bytes. h'8281a301040241012050e6bf4287c2d7618d6a9687445ffd33e68142af93' with
a size of 30 bytes.
Authors' Addresses Authors' Addresses
Malisa Vucinic Malisa Vucinic
Inria Inria
2 Rue Simone Iff 2 Rue Simone Iff
Paris 75012 Paris 75012
France France
Email: malisa.vucinic@inria.fr Email: malisa.vucinic@inria.fr
skipping to change at line 780 skipping to change at page 24, line 4
Email: jsimon@linear.com Email: jsimon@linear.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
Sandelman Software Works
470 Dawson Avenue
Ottawa, ON K1Z5V7
Canada
Email: mcr+ietf@sandelman.ca
 End of changes. 122 change blocks. 
471 lines changed or deleted 761 lines changed or added

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