draft-ietf-6tisch-minimal-security-02.txt   draft-ietf-6tisch-minimal-security-03.txt 
6TiSCH Working Group M. Vucinic 6TiSCH Working Group M. Vucinic, Ed.
Internet-Draft Inria Internet-Draft Inria
Intended status: Standards Track J. Simon Intended status: Standards Track J. Simon
Expires: September 13, 2017 Linear Technology Expires: December 17, 2017 Linear Technology
K. Pister K. Pister
University of California Berkeley University of California Berkeley
M. Richardson M. Richardson
Sandelman Software Works Sandelman Software Works
March 12, 2017 June 15, 2017
Minimal Security Framework for 6TiSCH Minimal Security Framework for 6TiSCH
draft-ietf-6tisch-minimal-security-02 draft-ietf-6tisch-minimal-security-03
Abstract Abstract
This document describes the minimal mechanisms required to support This document describes the minimal mechanisms required to support
secure enrollment of a pledge, a device being added to an IPv6 over secure enrollment of a pledge, a device being added to an IPv6 over
the TSCH mode of IEEE 802.15.4e (6TiSCH) network. It assumes that the TSCH mode of IEEE 802.15.4e (6TiSCH) network. It assumes that
the pledge has been provisioned with a credential that is relevant to the pledge has been provisioned with a credential that is relevant to
the deployment - the "one-touch" scenario. The goal of this the deployment - the "one-touch" scenario. The goal of this
configuration is to set link-layer keys, and to establish a secure configuration is to set link-layer keys, and to establish a secure
end-to-end session between each pledge and the join registrar who may end-to-end session between each pledge and the join registrar who may
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 September 13, 2017. This Internet-Draft will expire on December 17, 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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. One-Touch Assumptions . . . . . . . . . . . . . . . . . . . . 4 3. One-Touch Assumptions . . . . . . . . . . . . . . . . . . . . 4
4. Join Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Join Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 5 4.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 5
4.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 6 4.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 6
4.3. Step 3 - Security Handshake . . . . . . . . . . . . . . . 6 4.3. Step 3 - Security Handshake . . . . . . . . . . . . . . . 6
4.4. Step 4 - Simple Join Protocol - Join Request . . . . . . 8 4.4. Step 4 - Simple Join Protocol - Join Request . . . . . . 8
4.5. Step 5 - Simple Join Protocol - Join Response . . . . . . 8 4.5. Step 5 - Simple Join Protocol - Join Response . . . . . . 8
5. Architectural Overview and Communication through Join Proxy . 8 5. Architectural Overview and Communication through Join Proxy . 9
5.1. Stateless-Proxy CoAP Option . . . . . . . . . . . . . . . 9 5.1. Stateless-Proxy CoAP Option . . . . . . . . . . . . . . . 9
6. Security Handshake . . . . . . . . . . . . . . . . . . . . . 10 6. Security Handshake . . . . . . . . . . . . . . . . . . . . . 10
6.1. Discovery Message . . . . . . . . . . . . . . . . . . . . 11
7. Simple Join Protocol Specification . . . . . . . . . . . . . 11 7. Simple Join Protocol Specification . . . . . . . . . . . . . 11
7.1. OSCOAP Security Context Instantiation . . . . . . . . . . 12 7.1. OSCOAP Security Context Instantiation . . . . . . . . . . 12
7.2. Specification of Join Request . . . . . . . . . . . . . . 13 7.2. Specification of Join Request . . . . . . . . . . . . . . 13
7.3. Specification of Join Response . . . . . . . . . . . . . 13 7.3. Specification of Join Response . . . . . . . . . . . . . 13
8. Link-layer Requirements . . . . . . . . . . . . . . . . . . . 15 8. Mandatory to Implement Algorithms and Certificate Format . . 15
9. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . . . 15 9. Link-layer Requirements . . . . . . . . . . . . . . . . . . . 15
10. Rekeying and Rejoin . . . . . . . . . . . . . . . . . . . . . 16 10. Rekeying and Rejoin . . . . . . . . . . . . . . . . . . . . . 16
11. Key Derivations . . . . . . . . . . . . . . . . . . . . . . . 16 11. Key Derivations . . . . . . . . . . . . . . . . . . . . . . . 16
12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
14.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 18 14.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 18
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
16.1. Normative References . . . . . . . . . . . . . . . . . . 18 16.1. Normative References . . . . . . . . . . . . . . . . . . 19
16.2. Informative References . . . . . . . . . . . . . . . . . 19 16.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
This document describes the minimal feature set for a new device, This document describes the minimal feature set for a new device,
termed pledge, to securely join a 6TiSCH network. As a successful termed pledge, to securely join a 6TiSCH network. As a successful
outcome of this process, the pledge is able to securely communicate outcome of this process, the pledge is able to securely communicate
with its neighbors, participate in the routing structure of the with its neighbors, participate in the routing structure of the
skipping to change at page 3, line 36 skipping to change at page 3, line 36
[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 pledge 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 pledge expects one or more As the outcome of the join process, the pledge expects one or more
link-layer key(s) and optionally a temporary network identifier. link-layer key(s) and optionally a temporary link-layer 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
skipping to change at page 4, line 12 skipping to change at page 4, line 12
imported: pledge, join proxy, join registrar/coordinator, drop ship, imported: pledge, join proxy, join registrar/coordinator, drop ship,
imprint, enrollment, ownership voucher. imprint, enrollment, ownership voucher.
Pledge: the prospective device, which has the identity provided to Pledge: the prospective device, which has the identity provided to
at the factory. at the factory.
Joined Node: the prospective device, after having completed the join Joined Node: the prospective device, after having completed the join
process, often just called a Node. process, often just called a Node.
Join Proxy (JP): a stateless relay that provides connectivity Join Proxy (JP): a stateless relay that provides connectivity
between the pledge and the join registrar/coordinator. between the pledge and the Join Registrar/Coordinator.
Join Registrar/Coordinator (JRC): central entity responsible for Join Registrar/Coordinator (JRC): central entity responsible for
authentication and authorization of joining nodes. authentication and authorization of joining nodes.
3. One-Touch Assumptions 3. One-Touch Assumptions
This document assumes the one-touch scenario, where devices are This document assumes the one-touch scenario, where devices are
provided with some mechanism by which a secure association may be provided with some mechanism by which a secure association may be
made in a controlled environment. There are many ways in which this 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 might be done, and detailing any of them is out of scope for this
skipping to change at page 5, line 19 skipping to change at page 5, line 19
itself to the network. These packets are directed to the Join itself to the network. These packets are directed to the Join
Registrar/Coordinator (JRC), which may be co-located on the JP or Registrar/Coordinator (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. The pledge receives one or more packets from JRC (via the JP)
that 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 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 DAG root, 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 handshake is shown as a transaction diagram in Figure 1:
+--------+ +-------+ +--------+ +--------+ +-------+ +--------+
| pledge | | JP | | JRC | | pledge | | JP | | JRC |
| | | | | | | | | | | |
+--------+ +-------+ +--------+ +--------+ +-------+ +--------+
| | | | | |
skipping to change at page 8, line 13 skipping to change at page 8, line 13
proceed to the handshake. proceed to the handshake.
4.4. Step 4 - Simple Join Protocol - Join Request 4.4. Step 4 - Simple Join Protocol - Join Request
The Join Request that makes part of the Simple Join Protocol is sent The Join Request that makes part of the Simple Join Protocol is sent
from the pledge to the JP using the shared slot as described in the from the pledge to the JP using the shared slot as described in the
EB, and forwarded to the JRC. Which slot the JP uses to transmit to EB, and forwarded to the JRC. Which slot the JP uses to transmit to
the JRC is out of scope: some networks may wish to dedicate specific the JRC is out of scope: some networks may wish to dedicate specific
slots for this join traffic. slots for this join traffic.
The join request is typically authenticated/encrypted end-to-end The join request is authenticated/encrypted end-to-end using an
using AES-CCM-16-64-128 algorithm from [I-D.ietf-cose-msg] and a key algorithm from [I-D.ietf-cose-msg] and a key derived from the shared
derived from the shared secret from step 3. Algorithm negotiation is secret from step 3. Algorithm negotiation is described in detail in
described in detail in [I-D.selander-ace-cose-ecdhe]. [I-D.selander-ace-cose-ecdhe], and mandatory to implement algorithms
are specified in Section 8.
The nonce is derived from the shared secret, the pledge's EUI64 and a The nonce is derived from the shared secret, the pledge's EUI64 and a
monotonically increasing counter initialized to 0 when first monotonically increasing counter initialized to 0 when first
starting. starting.
4.5. Step 5 - Simple Join Protocol - Join Response 4.5. Step 5 - Simple Join Protocol - Join Response
The Join Response that makes part of the Simple Join Protocol is sent The Join Response that makes part of the Simple Join Protocol is sent
from the JRC to the pledge through JP that serves as a stateless from the JRC to the pledge through JP that serves as a stateless
relay. Packet containing the Join Response travels on the path from relay. Packet containing the Join Response travels on the path from
JRC to JP using pre-established routes in the network. The JP 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 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 operates as the application-layer proxy and does not keep any state
to relay the message. It uses information sent in the clear within to relay the message. It uses information sent in the clear within
the join response to decide where to forward to. the join response to decide where to forward to.
The join response is typically authenticated/encrypted using AES-CCM- The join response is authenticated/encrypted end-to-end using an
16-64-128 algorithm from [I-D.ietf-cose-msg] and a key derived from algorithm from [I-D.ietf-cose-msg] and a key derived from the shared
the shared secret from step 3. secret from step 3.
The nonce is derived from the shared secret, pledge's EUI64 and a The nonce is derived from the shared secret, pledge's EUI64 and a
monotonically increasing counter matching that of the join request. monotonically increasing counter matching that of the join 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. Join Response optionally also contains an IEEE 802.15.4
short address [IEEE8021542015] assigned to pledge by JRC. short address [IEEE8021542015] assigned to pledge by JRC, and the
IPv6 address of the JRC.
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 protocol in Figure 1 is implemented over Constrained Application
Protocol (CoAP) [RFC7252]. The Pledge plays the role of a CoAP Protocol (CoAP) [RFC7252]. The Pledge plays the role of a CoAP
client, JRC the role of a CoAP server, while JP implements CoAP client, JRC the role of a CoAP server, while JP implements CoAP
forward proxy functionality [RFC7252]. Since JP is also likely a 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 pledge that is not yet part of the network. of pledge that is not yet part of the network.
The pledge communicates with a Join Proxy (JP) over link-local IPv6 The pledge communicates with a Join Proxy (JP) over link-local IPv6
addresses. The pledge designates a JP as a proxy by including in the addresses. The pledge designates a JP as a proxy by including in the
CoAP requests to the JP the Proxy-Scheme option with value "coap" CoAP requests to the JP the Proxy-Scheme option with value "coap"
(CoAP-to-CoAP proxy). The pledge MUST include the Uri-Host option (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". 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 The pledge learns the actual IPv6 address of JRC from the join
any time during the join protocol. The JP knows the address of the response and it uses it once joined in order to operate as JP. The
JRC, via a provisioning process that occured when the JP, acting as a initial bootstrap of the 6LBR would require explicit provisioning of
pledge, joined. The initial bootstrap of the DODAG root would the JRC address.
require explicit provisioning of the JRC address.
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 by default keeps per-client state information in order
to forward the response towards the originator of the request to forward the response towards the originator of the request
(client). This state information comprises CoAP token, but the (client). This state information comprises CoAP token, but the
implementations also need to keep track of the IPv6 address of the implementations also need to keep track of the IPv6 address of the
host, as well as the corresponding UDP source port number. In the host, as well as the corresponding UDP source port number. In the
setting where the proxy is a constrained device and there are setting where the proxy is a constrained device and there are
potentially many clients, as in the case of JP, this makes it prone potentially many clients, as in the case of JP, this makes it prone
skipping to change at page 10, line 40 skipping to change at page 10, line 52
and JRC mutually authenticate each other and verify authorization and JRC mutually authenticate each other and verify authorization
information before proceeding with the Simple Join Protocol. In case information before proceeding with the Simple Join Protocol. In case
certificates are used for authentication, this document assumes that certificates are used for authentication, this document assumes that
a special certificate with role attribute set has been provisioned to a special certificate with role attribute set has been provisioned to
the JRC. This certificate is verified by pledge in order to the JRC. This certificate is verified by pledge in order to
authorize JRC to continue with the join process. How such a authorize JRC to continue with the join process. How such a
certificate is issued to the JRC is out of scope of this document. 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 Figure 3 details the exchanges between the pledge and JRC that take
place during the execution of the security handshake. Format of place during the execution of the security handshake. Format of
EDHOC messages is specified in [I-D.selander-ace-cose-ecdhe]. 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 | | pledge | | JRC |
| | | | | | | |
+--------+ +--------+ +--------+ +--------+
| Discovery Message | | |
| EDHOC message_1 |
+-------------------------------->| +-------------------------------->|
| | | |
| Optional ACK | | Optional ACK |
|< - - - - - - - - - - - - - - - -+ |< - - - - - - - - - - - - - - - -+
| | ~ ~
| |
| EDHOC message_1 |
|<--------------------------------+
| | | |
| EDHOC message_2 | | EDHOC message_2 |
+-------------------------------->| |<--------------------------------+
| | | |
| EDHOC message_3 | | EDHOC message_3 |
|<--------------------------------+ +-------------------------------->|
| | | |
Figure 3: Transaction diagram of the security handshake. 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 7. Simple Join Protocol Specification
Simple Join Protocol is a single round trip protocol (c.f. Figure 4) Simple Join Protocol is a single round trip protocol (c.f. Figure 4)
that facilitates secure enrollment of a pledge, based on a shared that facilitates secure enrollment of a pledge, based on a shared
symmetric secret. In case the pledge was provisioned by an symmetric secret. In case the pledge was provisioned by an
asymmetric key (certificate or RPK), Simple Join Protocol is preceded asymmetric key (certificate or RPK), Simple Join Protocol is preceded
by a security handshake, described in Section 6. When the pledge is by a security handshake, described in Section 6. When the pledge is
provisioned with a PSK, Simple Join Protocol may be run directly. provisioned with a PSK, Simple Join Protocol may be run directly.
Pledge and JRC MUST protect their exchange end-to-end (i.e. through Pledge and JRC MUST protect their exchange end-to-end (i.e. through
skipping to change at page 12, line 29 skipping to change at page 12, line 22
| | | |
| Join Response | | Join Response |
|<--------------------------------+ |<--------------------------------+
| | | |
Figure 4: Transaction diagram of the Simple Join Protocol. Figure 4: Transaction diagram of the Simple Join Protocol.
7.1. OSCOAP Security Context Instantiation 7.1. OSCOAP Security Context Instantiation
The OSCOAP security context MUST be derived at pledge and JRC as per 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 SHA-256
as the key derivation function. [RFC5869] as the key derivation function.
o Master Secret MUST be the secret generated by the run of EDHOC as o Master Secret MUST be the secret generated by the run of EDHOC as
per Appendix B of [I-D.selander-ace-cose-ecdhe], or the PSK in per Appendix B of [I-D.selander-ace-cose-ecdhe], or the PSK in
case EDHOC step was omitted. case EDHOC step was omitted.
o Sender ID of the pledge MUST be set to the concatenation of its o Sender ID of the pledge MUST be set to the concatenation of its
EUI-64 and byte string 0x00. EUI-64 and byte string 0x00.
o Recipient ID (ID of JRC) MUST be set to the concatenation of 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 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 EUI-64 to avoid nonce reuse in the response in the case same PSK
is shared by a group of pledges. 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 the value from [I-D.ietf-cose-msg] agreed
[I-D.ietf-cose-msg]. CoAP messages are therefore protected with by the run of EDHOC, or out-of-band in case of PSKs.
an 8-byte CCM authentication tag and the algorithm uses 13-byte
long nonces.
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. The context derivation process occurs exactly once.
Implementations MUST ensure that multiple CoAP requests to different Implementations MUST ensure that multiple CoAP requests to different
JRCs result in the use of the same OSCOAP context so that sequence JRCs result in the use of the same OSCOAP context so that sequence
numbers are properly incremented for each request. This may happen numbers are properly incremented for each request. This may happen
in a scenario where there are multiple 6TiSCH networks present and in a scenario where there are multiple 6TiSCH networks present and
the pledge tries to join one network at a time. the pledge tries to join one network at a time.
skipping to change at page 13, line 46 skipping to change at page 13, line 37
o The response Code is 2.05 (Content). o The response Code is 2.05 (Content).
o Content-Format option is set to application/cbor. o Content-Format option is set to application/cbor.
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 * COSE Key Set, specified in [I-D.ietf-cose-msg], containing one
or more link-layer keys. The mapping of individual keys to or 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 7.3.1.
* Optional short address that is assigned to the pledge. The * Optional. Link layer short address that is assigned to the
format of the short address follows Section 7.3.2. pledge. The format of the short address follows Section 7.3.2.
* Optional. IPv6 address of the JRC transported as a byte
string. If the address of the JRC is not present in the
response, JRC is co-located with 6LBR.
payload = [ payload = [
COSE_KeySet, COSE_KeySet,
? short_address, ? short_address,
? JRC_address : bstr,
] ]
7.3.1. Link-layer Keys Transported in COSE Key Set 7.3.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 [I-D.ietf-cose-msg] SHALL be a symmetric
key. If "kid" parameter of the COSE Key structure is present, the key. If "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 COSE Key structure SHALL be
used to carry IEEE 802.15.4 KeyIndex value. If the "kid" parameter used to carry IEEE 802.15.4 KeyIndex value. If the "kid" parameter
is not present in the transported key, the application SHALL consider is not present in the transported key, the application SHALL consider
skipping to change at page 15, line 18 skipping to change at page 15, line 13
authorized to join the network, but a further zero-touch process 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 might permit it, the JRC responds with a 2.05 (Content) code, but the
payload contains the single CBOR string "prov" (for "provisional"). payload contains the single CBOR string "prov" (for "provisional").
No link-layer keys or short address is returned. No link-layer keys or short address is returned.
This response is typically only expected when in asymmetric This response is typically only expected when in asymmetric
certificate mode using 802.1AR IDevID certificates. But for reasons certificate mode using 802.1AR IDevID certificates. But for reasons
of provisioning or device reuse, this could occur even when a one- of provisioning or device reuse, this could occur even when a one-
touch PSK authentication process was expected. touch PSK authentication process was expected.
8. Link-layer Requirements 8. Mandatory to Implement Algorithms and Certificate Format
The mandatory to implement symmetric-key algorithm for use with
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].
Certificates or pre-configured RPKs may be used to exchange public
keys between the pledge and JRC. The mandatory to implement Elliptic
Curve is P-256, also known as secp256r1. The mandatory to implement
signature algorithm is ECDSA with SHA-256.
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.
9. Link-layer Requirements
In an operational 6TiSCH network, all frames MUST use link-layer In an operational 6TiSCH network, all frames MUST use link-layer
frame security. The frame security options MUST include frame frame security. The frame security options MUST include frame
authentication, and MAY include frame encryption. authentication, and MAY include frame encryption.
Link-layer frames are protected with a 16-byte key, and a 13-byte Link-layer frames are protected with a 16-byte key, and a 13-byte
nonce constructed from current Absolute Slot Number (ASN) and the nonce constructed from current Absolute Slot Number (ASN) and the
source (the JP for EBs) address, as shown in Figure 5: source (the JP for EBs) address, as shown in Figure 5:
+-------------------------------------------+ +-------------------------------------------+
skipping to change at page 15, line 47 skipping to change at page 16, line 18
frames (exempt mode in 802.15.4) for the duration of the join frames (exempt mode in 802.15.4) for the duration of the join
process. How JP 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 cannot be authenticated by pledge, an attacker may As the EB itself cannot be authenticated by pledge, an attacker may
craft a frame that appears to be a valid EB, since the pledge can 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 permits a Denial of Service (DoS) attack at the pledge. Beacon
authentication keys are discussed in [I-D.ietf-6tisch-minimal]. authentication keys are discussed in [I-D.ietf-6tisch-minimal].
9. Asymmetric Keys
Certificates or pre-configured RPKs may be used to exchange public
keys between the pledge and JRC. The key pair is generated using
elliptic curve secp256r1, and the certificate containing the public
key is signed using ECDSA. (XXX: would be nice to move to EdDSA)
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.
10. Rekeying and Rejoin 10. Rekeying and Rejoin
This protocol handles initial keying of the pledge. For reasons such This protocol handles initial keying of the pledge. For reasons such
as rejoining after a long sleep, or expiry of the short address, the as rejoining after a long sleep, or expiry of the short address, the
joined node MAY send a new Join Request over the previously joined node MAY send a new Join Request over the previously
established secure end-to-end session with JRC. JRC responds with 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 up-to-date keys and a short address. The node may also use the
Simple Join Protocol exchange for node-initiated rekeying. How node Simple Join Protocol exchange for node-initiated rekeying. How node
learns that it should be rekeyed is out of scope. Additional work, learns that it should be rekeyed is out of scope. Additional work,
such as in [I-D.richardson-6tisch-minimal-rekey] can be used. such as in [I-D.richardson-6tisch-minimal-rekey] can be used.
skipping to change at page 18, line 13 skipping to change at page 18, line 17
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].
14. IANA Considerations 14. 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 14.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:
+--------+-----------------+-------------------+ +--------+-----------------+-------------------+
skipping to change at page 18, line 37 skipping to change at page 18, line 41
+--------+-----------------+-------------------+ +--------+-----------------+-------------------+
15. Acknowledgments 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 and to Klaus Hartke for providing input on the
Palombini and Ludwig Seitz for participating in the discussions that Stateless-Proxy CoAP option. The authors would also like to thank
have helped shape the document. Francesca Palombini and Ludwig Seitz for participating in the
discussions that have helped shape the document.
16. References 16. References
16.1. Normative References 16.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 of CoAP (OSCOAP)", draft-ietf-core-
object-security-01 (work in progress), December 2016. object-security-03 (work in progress), May 2017.
[I-D.ietf-cose-msg] [I-D.ietf-cose-msg]
Schaad, J., "CBOR Object Signing and Encryption (COSE)", Schaad, J., "CBOR Object Signing and Encryption (COSE)",
draft-ietf-cose-msg-24 (work in progress), November 2016. 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>.
skipping to change at page 19, line 31 skipping to change at page 19, line 37
October 2013, <http://www.rfc-editor.org/info/rfc7049>. October 2013, <http://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>. <http://www.rfc-editor.org/info/rfc7252>.
16.2. Informative References 16.2. Informative References
[I-D.ietf-6tisch-6top-protocol] [I-D.ietf-6tisch-6top-protocol]
Wang, Q. and X. Vilajosana, "6top Protocol (6P)", draft- Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol
ietf-6tisch-6top-protocol-03 (work in progress), October (6P)", draft-ietf-6tisch-6top-protocol-05 (work in
2016. progress), May 2017.
[I-D.ietf-6tisch-dtsecurity-secure-join] [I-D.ietf-6tisch-dtsecurity-secure-join]
Richardson, M., "6tisch Secure Join protocol", draft-ietf- Richardson, M., "6tisch Secure Join protocol", draft-ietf-
6tisch-dtsecurity-secure-join-01 (work in progress), 6tisch-dtsecurity-secure-join-01 (work in progress),
February 2017. February 2017.
[I-D.ietf-6tisch-minimal] [I-D.ietf-6tisch-minimal]
Vilajosana, X., Pister, K., and T. Watteyne, "Minimal Vilajosana, X., Pister, K., and T. Watteyne, "Minimal
6TiSCH Configuration", draft-ietf-6tisch-minimal-21 (work 6TiSCH Configuration", draft-ietf-6tisch-minimal-21 (work
in progress), February 2017. in progress), February 2017.
skipping to change at page 20, line 9 skipping to change at page 20, line 15
[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] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-04 (work in progress), October 2016. keyinfra-06 (work in progress), May 2017.
[I-D.richardson-6tisch-join-enhanced-beacon] [I-D.richardson-6tisch-join-enhanced-beacon]
Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational
Element encapsulation of 6tisch Join Information", draft- Element encapsulation of 6tisch Join Information", draft-
richardson-6tisch-join-enhanced-beacon-01 (work in richardson-6tisch-join-enhanced-beacon-01 (work in
progress), March 2017. progress), March 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-01 (work in
progress), February 2017. 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-06 (work in progress), April 2017.
[IEEE8021542015] [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.
[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>. <http://www.rfc-editor.org/info/rfc4231>.
skipping to change at page 21, line 22 skipping to change at page 21, line 28
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>. <http://www.rfc-editor.org/info/rfc7721>.
Appendix A. Example Appendix A. Example
Figure 6 illustrates a join protocol exchange in case PSKs are used. Figure 6 illustrates a join protocol exchange in case PSKs are used.
Pledge instantiates the OSCOAP context and derives the traffic keys Pledge instantiates the OSCOAP context and derives the traffic keys
and nonces from the PSK. It uses the instantiated context to protect and nonces from the PSK. It uses the instantiated context to protect
the CoAP request addressed with Proxy-Scheme option and well-known the CoAP request addressed with Proxy-Scheme option and well-known
host name of JRC in the Uri-Host option. The example assumes a JP host name of JRC in the Uri-Host option. Triggered by the presence
that is already aware of JRC's IPv6 address and does not need to of Proxy-Scheme option, JP forwards the request to the JRC and adds
resolve the well-known "6tisch.arpa" host name. Triggered by the the Stateless-Proxy option with value set to the internally needed
presence of Proxy-Scheme option, JP forwards the request to the JRC state, authentication tag, and a freshness indicator. JP learned the
and adds the Stateless-Proxy option with value set to the internally IPv6 address of JRC when it acted as a pledge and joined the network.
needed state, authentication tag, and a freshness indicator. Once Once JRC receives the request, it looks up the correct context based
JRC receives the request, it looks up the correct context based on on the Sender ID (sid) parameter. It reconstructs OSCOAP's external
the Sender ID (sid) parameter. It reconstructs OSCOAP's external
Additional Authenticated Data (AAD) needed for verification based on: 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 Request ID being set to pledge's EUI-64 concatenated with 0x00. o Request ID being set to pledge's EUI-64 concatenated with 0x00.
skipping to change at page 22, line 5 skipping to change at page 22, line 9
Replay protection is ensured by OSCOAP and the tracking of sequence Replay protection is ensured by OSCOAP and the tracking of sequence
numbers at each side. In the example below, the response contains numbers at each side. In the example below, the response contains
sequence number 7 meaning that there have already been some attempts sequence number 7 meaning that there have already been some attempts
to join under a given context, not coming from the pledge. Once JP to join under a given context, not coming from the pledge. Once JP
receives the response, it authenticates the Stateless-Proxy option receives the response, it authenticates the Stateless-Proxy option
before deciding where to forward. JP sets its internal state to that before deciding where to forward. JP sets its internal state to that
found in the Stateless-Proxy option. Note that JP does not posses 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 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 join_response object is opaque to it. The response is matched to the
request and verified for replay protection at pledge using OSCOAP request and verified for replay protection at pledge using OSCOAP
processing rules. processing rules. The response does not contain JRC's address as in
this particular example, we assume that JRC is co-located with 6LBR.
<--E2E OSCOAP--> <--E2E OSCOAP-->
Client Proxy Server Client Proxy Server
Pledge JP JRC 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.arpa] | | | Uri-Host: [6tisch.arpa]
| | | Object-Security: [sid:EUI-64 | 0, seq:1, | | | Object-Security: [sid:EUI-64 | 0, seq:1,
skipping to change at page 23, line 25 skipping to change at page 23, line 25
h'af93' / assigned short address / h'af93' / assigned short address /
] ]
] ]
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 Malisa Vucinic (editor)
Inria Inria
2 Rue Simone Iff 2 Rue Simone Iff
Paris 75012 Paris 75012
France France
Email: malisa.vucinic@inria.fr Email: malisa.vucinic@inria.fr
Jonathan Simon Jonathan Simon
Linear Technology Linear Technology
32990 Alvarado-Niles Road, Suite 910 32990 Alvarado-Niles Road, Suite 910
 End of changes. 39 change blocks. 
98 lines changed or deleted 93 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/