draft-ietf-6tisch-minimal-security-00.txt   draft-ietf-6tisch-minimal-security-01.txt 
6TiSCH M. Vucinic, Ed. 6TiSCH Working Group M. Vucinic
Internet-Draft Inria Internet-Draft Inria
Intended status: Standards Track J. Simon Intended status: Standards Track J. Simon
Expires: June 17, 2017 Linear Technology Expires: August 6, 2017 Linear Technology
K. Pister K. Pister
University of California Berkeley University of California Berkeley
December 14, 2016 February 02, 2017
Minimal Security Framework for 6TiSCH Minimal Security Framework for 6TiSCH
draft-ietf-6tisch-minimal-security-00 draft-ietf-6tisch-minimal-security-01
Abstract Abstract
This draft describes the minimal mechanisms required to support This draft describes the minimal mechanisms required to support
secure initial configuration in a device being added to a 6TiSCH secure initial configuration in a device being added to a 6TiSCH
network. The goal of this configuration is to set link-layer keys, network. The goal of this configuration is to set link-layer keys,
and to establish a secure session between each joining node and the and to establish a secure session between each joining node and the
JCE who may use that to further configure the joining device. JCE who may use that to further configure the joining device.
Additional security behaviors and mechanisms may be added on top of Additional security behaviors and mechanisms may be added on top of
this minimal framework. this minimal framework.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
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 June 17, 2017. This Internet-Draft will expire on August 6, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Join Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Join Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 5 3.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 5
3.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 5 3.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 5
3.3. Step 3 - Security Handshake . . . . . . . . . . . . . . . 5 3.3. Step 3 - Security Handshake . . . . . . . . . . . . . . . 5
3.3.1. Pre-Shared Key . . . . . . . . . . . . . . . . . . . 5 3.3.1. Pre-Shared Key . . . . . . . . . . . . . . . . . . . 6
3.3.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . 5 3.3.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . 6
3.4. Step 4 - Join Request . . . . . . . . . . . . . . . . . . 6 3.4. Step 4 - Join Request . . . . . . . . . . . . . . . . . . 6
3.5. Step 5 - Join Response . . . . . . . . . . . . . . . . . 6 3.5. Step 5 - Join Response . . . . . . . . . . . . . . . . . 6
4. Protocol Specification . . . . . . . . . . . . . . . . . . . 6 4. Protocol Specification . . . . . . . . . . . . . . . . . . . 7
4.1. Proxy Operation of JA . . . . . . . . . . . . . . . . . . 7 4.1. Proxy Operation of JA . . . . . . . . . . . . . . . . . . 7
4.1.1. Implementation of origin_info . . . . . . . . . . . . 7 4.1.1. Implementation of origin_info . . . . . . . . . . . . 8
4.2. OSCOAP Security Context Instantiation . . . . . . . . . . 7 4.2. OSCOAP Security Context Instantiation . . . . . . . . . . 8
4.3. Implementation of Join Request . . . . . . . . . . . . . 8 4.3. Implementation of Join Request . . . . . . . . . . . . . 9
4.4. Implementation of Join Response . . . . . . . . . . . . . 8 4.4. Implementation of Join Response . . . . . . . . . . . . . 9
5. Link-layer requirements . . . . . . . . . . . . . . . . . . . 9 5. Link-layer requirements . . . . . . . . . . . . . . . . . . . 10
5.1. Well-known beacon authentication key . . . . . . . . . . 10 5.1. Well-known beacon authentication key . . . . . . . . . . 10
5.2. Private beacon authentication key . . . . . . . . . . . . 10 5.2. Private beacon authentication key . . . . . . . . . . . . 10
6. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . . . 10 6. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . 13
11.3. External Informative References . . . . . . . . . . . . 14
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
When a previously unknown device seeks admission to a 6TiSCH When a previously unknown device seeks admission to a 6TiSCH
[RFC7554] network (to "join"), it first needs to synchronize to the [RFC7554] network (to "join"), it first needs to synchronize to the
network. The device then configures its IPv6 address and network. The device then configures its IPv6 address and
authenticates itself, and also validates that it is joining the right authenticates itself, and also validates that it is joining the right
network. At this point it can expect to interact with the network to network. At this point it can expect to interact with the network to
configure its link-layer keying material. Only then may the node configure its link-layer keying material. Only then may the node
establish an end-to-end secure session with an Internet host using establish an end-to-end secure session with an Internet host using
skipping to change at page 3, line 28 skipping to change at page 3, line 17
This document describes the mechanisms comprising a minimal feature This document describes the mechanisms comprising a minimal feature
set for a device to join a 6TiSCH network, up to the point where it set for a device to join a 6TiSCH network, up to the point where it
can establish a secure session with an Internet host. can establish a secure session with an Internet host.
It presumes a network as described by [RFC7554], It 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 joining device 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 joining device expects one or
more link-layer key(s) and optionally a temporary network identifier. more link-layer key(s) and optionally a temporary network identifier.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. These
words may also appear in this document in lowercase, absent their
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], and
[I-D.ietf-core-object-security]. The entities participating in the [I-D.ietf-core-object-security]. The entities participating in the
protocol that is specified in this document are: protocol that is specified in this document are:
o JN: Joining node - the device attempting to join a particular o JN: Joining node - the device attempting to join a particular
6TiSCH network. 6TiSCH network.
o JCE: Join coordinating entity - central entity responsible for o JCE: Join coordinating entity - 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 o JA: Join assistant - the device within radio range of the JN that
generates Enhanced Beacons (EBs) and facilitates end-to-end generates Enhanced Beacons (EBs) and facilitates end-to-end
communications between the JN and JCE. communications between the JN and JCE.
3. Join Overview 3. Join Overview
This section describes the steps taken by a joining node (JN) in a This section describes the steps taken by a joining node (JN) in a
6TiSCH network. When a previously unknown device seeks admission to 6TiSCH network. When a previously unknown device seeks admission to
a 6TiSCH [RFC7554] network, the following exchange occurs: a 6TiSCH [RFC7554] network, the following exchange occurs:
skipping to change at page 4, line 34 skipping to change at page 5, line 5
subsequent transmissions to peers. subsequent transmissions to peers.
From the joining node's perspective, minimal joining is a local From the joining node's perspective, minimal joining is a local
phenomenon - the JN only interacts with the JA, and it need not know phenomenon - the JN only interacts with the JA, and it need not know
how far it is from the DAG root, or how to route to the JCE. Only how far it is from the DAG root, or how to route to the JCE. Only
after establishing one or more link-layer keys does it need to know after establishing one or more link-layer keys does it need to know
about the particulars of a 6TiSCH network. about 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 | | JCE | | JA | | JN |
| | | | | | | | | | | |
+-----+ +----------+ +-----------+ +-----+ +----------+ +-----------+
| | | | | |
| |-----------ENH BEACON (1)-->| | |-----------ENH BEACON (1)-->|
| | | | | |
| |<--Neighbor Discovery (2)-->| | |<--Neighbor Discovery (2)-->|
| | | | | |
|<--Sec. Handshake (3a)--|---Security Handshake (3)-->| |<--Sec. Handshake (3a)--|---Security Handshake (3)-->|
| | | | | |
|<----Join request (4a)--|---------Join request (4)---| |<----Join request (4a)--|---------Join request (4)---|
| | | | | |
|----Join response (5a)--|--------Join response (5)-->| |----Join response (5a)--|--------Join response (5)-->|
| | | | | |
Figure 1: Message sequence for join protocol. Figure 1: Message sequence for join protocol.
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 3.1. Step 1 - Enhanced Beacon
The JN hears an EB from the JA and synchronizes itself to the joining The JN hears an EB from the JA and synchronizes itself to the joining
schedule using the cells contained in the EB. At this point the JN schedule using the cells contained in the EB. At this point the JN
MAY proceed to step 2, or continue to listen for additional EBs. If MAY proceed to step 2, or continue to listen for additional EBs. If
skipping to change at page 7, line 39 skipping to change at page 8, line 11
to implement JA's CoAP proxy in a stateless manner. It also allows 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 JCE to look up the right security context for communication with a
given JN. given JN.
4.1.1. Implementation of origin_info 4.1.1. Implementation of origin_info
The origin_info is implemented as a CBOR [RFC7049] array object The origin_info is implemented as a CBOR [RFC7049] array object
containing: containing:
o EUI64: JN's EUI64 address o EUI64: JN's EUI64 address
o source_port: JN's UDP source port o source_port: JN's UDP source port
o token: JN's CoAP token o token: JN's CoAP token
origin_info = [ origin_info = [
EUI64 : bstr, EUI64 : bstr,
source_port : uint, source_port : uint,
token : uint token : uint
] ]
4.2. OSCOAP Security Context Instantiation 4.2. OSCOAP Security Context Instantiation
The OSCOAP security context MUST be derived at JN and JCE as per The OSCOAP security context MUST be derived at JN and JCE 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 Context Identifier (Cid) MUST be the origin_info object wrapped as
a byte string (bstr). a byte string (bstr).
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 o Base key (base_key) MUST be the secret generated by the run of
EDHOC, or the PSK in case EDHOC step was omitted. 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 o Sender ID of JN MUST be set to 0x00, while the ID of JCE MUST be
set to 0x01. 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. Implementations
MUST ensure that multiple CoAP requests to different JCEs result in MUST ensure that multiple CoAP requests to different JCEs result in
the use of the same OSCOAP context so that sequence numbers are the use of the same OSCOAP context so that sequence numbers are
skipping to change at page 8, line 45 skipping to change at page 9, line 27
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 4.4. Implementation of Join Response
If OSCOAP processing is a success, Join Response message SHALL be a If OSCOAP processing is a success, Join Response message SHALL be a
CoAP response: 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 The payload is a CBOR array containing, in order:
* COSE Key Set [I-D.ietf-cose-msg]. Each key in the Key Set * COSE Key Set [I-D.ietf-cose-msg]. Each key in the Key Set
SHALL be a symmetric key. A key that is present in the Key Set 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- and does not have an identifier is assumed to be "K2" link-
layer key from [I-D.ietf-6tisch-minimal]. Parameter "kid" of layer key from [I-D.ietf-6tisch-minimal]. Parameter "kid" of
the COSE Key structure SHALL be used to denote pair-wise keys 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 if present, where the value SHALL be set to the address of the
corresponding peer. corresponding peer.
* Optional byte string representing IEEE 802.15.4 short address * Optional byte string representing IEEE 802.15.4 short address
assigned to JN. If the length of the byte string is different assigned to JN. If the length of the byte string is different
than 2 bytes, the implementation SHOULD ignore it. than 2 bytes, the implementation SHOULD ignore it.
payload = [ payload = [
COSE_KeySet, COSE_KeySet,
? short_address : bstr, ? short_address : bstr,
] ]
In case JCE determines that JN is not supposed to join the network In case JCE determines that JN is not supposed to join the network
(e.g. by failing to find an appropriate security context), it should (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 respond with a 4.01 Unauthorized error. Upon reception of a 4.01
Unauthorized, JN SHALL attempt to join the next advertised 6TiSCH Unauthorized, JN SHALL attempt to join the next advertised 6TiSCH
network. If all join attempts have failed at JN, JN SHOULD signal to 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 the user by an out-of-band mechanism the presence of an error
condition. condition.
5. Link-layer requirements 5. Link-layer requirements
skipping to change at page 10, line 13 skipping to change at page 10, line 45
valid EB, since the JN can neither know the ASN a priori nor verify valid EB, since the JN can neither know the ASN a priori nor verify
the address of the JA. This permits a Denial of Service (DoS) attack the address of the JA. This permits a Denial of Service (DoS) attack
at the JN. Beacon authentication keys are discussed in Section 5.1 at the JN. Beacon authentication keys are discussed in Section 5.1
and Section 5.2. and Section 5.2.
5.1. Well-known beacon authentication key 5.1. Well-known beacon authentication key
For zero-touch operation, where any 6TiSCH device can attempt to join For zero-touch operation, where any 6TiSCH device can attempt to join
any 6TiSCH network out of the box, a well-known EB link-layer key any 6TiSCH network out of the box, a well-known EB link-layer key
MUST be used. The value of this key is specified in MUST be used. The value of this key is specified in
[I-D.ietf-6tisch-minimal]. [I-D.ietf-6tisch-minimal]
5.2. Private beacon authentication key 5.2. Private beacon authentication key
Some pre-configuration MAY be done when the device is manufactured or Some pre-configuration MAY be done when the device is manufactured or
designated for a specific network (i.e. the network is one-touch) or 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 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 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. MAY be used in place of a well-known key to create a private network.
6. Asymmetric Keys 6. Asymmetric Keys
skipping to change at page 12, line 46 skipping to change at page 13, line 30
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] [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.
[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-00 (work in progress), October 2016. object-security-01 (work in progress), December 2016.
11.2. Informative References 11.2. Informative References
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement", RFC 7554, Internet of Things (IoT): Problem Statement", RFC 7554,
DOI 10.17487/RFC7554, May 2015, DOI 10.17487/RFC7554, May 2015,
<http://www.rfc-editor.org/info/rfc7554>. <http://www.rfc-editor.org/info/rfc7554>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
skipping to change at page 13, line 37 skipping to change at page 14, line 21
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>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<http://www.rfc-editor.org/info/rfc7721>. <http://www.rfc-editor.org/info/rfc7721>.
[I-D.ietf-6tisch-minimal] [I-D.ietf-6tisch-minimal]
Vilajosana, X. and K. Pister, "Minimal 6TiSCH Vilajosana, X., Pister, K., and T. Watteyne, "Minimal
Configuration", draft-ietf-6tisch-minimal-17 (work in 6TiSCH Configuration", draft-ietf-6tisch-minimal-19 (work
progress), November 2016. 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-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-07 (work in 802.15.4e", draft-ietf-6tisch-terminology-08 (work in
progress), March 2016. progress), December 2016.
[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.
11.3. External Informative References
[IEEE802154-2015] [IEEE802154-2015]
IEEE standard for Information Technology, "IEEE Std IEEE standard for Information Technology, ., "IEEE Std
802.15.4-2015 Standard for Low-Rate Wireless Personal Area 802.15.4-2015 Standard for Low-Rate Wireless Personal Area
Networks (WPANs)", December 2015. Networks (WPANs)", 2015.
Appendix A. Example Appendix A. Example
Figure 3 illustrates a join protocol exchange in case PSKs are used. Figure 3 illustrates a join protocol exchange in case PSKs are used.
JN instantiates the OSCOAP context and derives the traffic keys and JN instantiates the OSCOAP context and derives the traffic keys and
nonces from the PSK. It uses the instantiated context to protect the nonces from the PSK. It uses the instantiated context to protect the
CoAP request addressed with Proxy-Scheme option and well-known host CoAP request addressed with Proxy-Scheme option and well-known host
name of JCE in the Uri-Host option. The example assumes a JA that is 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 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 well-known "6tisch.jce" host name. Triggered by the presence of
skipping to change at page 14, line 32 skipping to change at page 15, line 12
CoAP request addressed with Proxy-Scheme option and well-known host CoAP request addressed with Proxy-Scheme option and well-known host
name of JCE in the Uri-Host option. The example assumes a JA that is 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 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 well-known "6tisch.jce" host name. Triggered by the presence of
Proxy-Scheme option, JA forwards the request to the JCE. Once JCE Proxy-Scheme option, JA forwards the request to the JCE. Once JCE
receives the request, it looks up the correct context based on the receives the request, it looks up the correct context based on the
context identifier (cid) field. It reconstructs OSCOAP's external context identifier (cid) field. 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 URI reconstructed following o Request URI reconstructed following
[I-D.ietf-core-object-security]. [I-D.ietf-core-object-security].
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 JN. Once JA to join under a given context, not coming from the JN. Once JA
receives the response, it looks up and decodes the cid field in order receives the response, it looks up and decodes the cid field in order
to decide where to forward it. JA constructs the CoAP response to JN to decide where to forward it. JA constructs the CoAP response to JN
by setting the CoAP token to the value decoded from cid and by setting the CoAP token to the value decoded from cid and
skipping to change at page 14, line 52 skipping to change at page 15, line 35
to decide where to forward it. JA constructs the CoAP response to JN to decide where to forward it. JA constructs the CoAP response to JN
by setting the CoAP token to the value decoded from cid and by setting the CoAP token to the value decoded from cid and
constructs the link-local IPv6 address of JN from the EUI64 address constructs the link-local IPv6 address of JN from the EUI64 address
found in the cid. Note that JA does not posses the key to decrypt found in the cid. Note that JA does not posses the key to decrypt
the COSE object present in the payload so the join_response object is 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 opaque to it. The response is matched to the request and verified
for replay protection at JN using OSCOAP processing rules. Namely, for replay protection at JN using OSCOAP processing rules. Namely,
to verify the response JN reconstructs the AAD based on: to verify the response JN reconstructs the AAD 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 Transaction identifier (Tid) of the corresponding CoAP request.
Tid contains the context identifier (origin_info object), Sender Tid contains the context identifier (origin_info object), Sender
ID (0x00 for JN), and Sender Sequence number (set to 1 in the ID (0x00 for JN), and Sender Sequence number (set to 1 in the
example). example).
In addition to AAD, JN also uses the explicit, protected fields in In addition to AAD, JN also uses the explicit, protected fields in
the COSE message, present in the payload of the response. For more the COSE message, present in the payload of the response. For more
details, see [I-D.ietf-core-object-security] and [I-D.ietf-cose-msg]. details, see [I-D.ietf-core-object-security] and [I-D.ietf-cose-msg].
<--E2E OSCOAP--> <--E2E OSCOAP-->
Client Proxy Server Client Proxy Server
JN JA JCE JN JA JCE
| | | | | |
+----->| | 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.jce]
| | | Object-Security: [cid:origin_info, seq:1, | | | Object-Security: [cid:origin_info, 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.jce]
| | | Object-Security: [cid:origin_info, seq:1, | | | Object-Security: [cid:origin_info, seq:1,
| | | {Uri-Path:"j"}, | | | {Uri-Path:"j"},
| | | <Tag>] | | | <Tag>]
| | | Payload: - | | | Payload: -
| | | | | |
| |<-----+ Code: [2.05] (Content) | |<-----+ Code: [2.05] (Content)
| | 2.05 | Token: 0x7b | | 2.05 | Token: 0x7b
| | | Object-Security: - | | | Object-Security: -
| | | Payload: [cid: origin_info, seq:7, | | | Payload: [cid: origin_info, seq:7,
| | | {join_response}, <Tag>] | | | {join_response}, <Tag>]
| | | | | |
|<-----+ | Code: [2.05] (Content) |<-----+ | Code: [2.05] (Content)
| 2.05 | | Token: 0x8c | 2.05 | | Token: 0x8c
| | | Object-Security: - | | | Object-Security: -
| | | Payload: [cid: origin_info, seq:7, | | | Payload: [cid: origin_info, seq:7,
| | | {join_response}, <Tag>] | | | {join_response}, <Tag>]
| | | | | |
Figure 3: Example of a join protocol exchange with a PSK. {} denotes Figure 3: 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 origin_info and join_response are as follows.
origin_info: origin_info:
[ [
h'00170d00060d9f0e', / JN's EUI64 / h'00170d00060d9f0e', / JN's EUI64 /
49152, / JN's UDP source port / 49152, / JN's UDP source port /
0x8c / JN's CoAP token / 0x8c / JN's CoAP token /
] ]
Encodes to h'834800170d00060d9f0e19c000188c' with a size of 15 bytes. 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 / -1:h'e6bf4287c2d7618d6a9687445ffd33e6' / key value /
} }
], ],
h'af93' / assigned short address / h'af93' / assigned short address /
] ]
Encodes to h'8281a201042050e6bf4287c2d7618d6a9687445ffd33e642af93' Encodes to h'8281a201042050e6bf4287c2d7618d6a9687445ffd33e642af93'
with a size of 26 bytes. with a size of 26 bytes.
Authors' Addresses Authors' Addresses
Malisa Vucinic (editor) 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
Jonathan Simon Jonathan Simon
Linear Technology Linear Technology
32990 Alvarado-Niles Road, Suite 910 32990 Alvarado-Niles Road, Suite 910
skipping to change at page 17, line 4 skipping to change at page 17, line 36
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
Union City, CA 94587 Union City, CA 94587
USA USA
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, California 94720 Berkeley, CA 94720
USA USA
Email: pister@eecs.berkeley.edu Email: pister@eecs.berkeley.edu
 End of changes. 45 change blocks. 
104 lines changed or deleted 117 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/