Internet DRAFT - draft-ietf-6tisch-dtsecurity-secure-join
draft-ietf-6tisch-dtsecurity-secure-join
6tisch Working Group M. Richardson
Internet-Draft Sandelman Software Works
Intended status: Informational February 25, 2017
Expires: August 29, 2017
6tisch Secure Join protocol
draft-ietf-6tisch-dtsecurity-secure-join-01
Abstract
This document describes a zero-touch mechanism to enroll a new device
(the "pledge") into a IEEE802.15.4 TSCH network using the 6tisch
signaling mechanisms. The resulting device will obtain a domain
specific credential that can be used with either 802.15.9 per-host
pair keying protocols, or to obtain the network-wide key from a
coordinator. The mechanism describe her is an augmentation to the
one-touch mechanism described in [I-D.ietf-6tisch-minimal-security].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 29, 2017.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Richardson Expires August 29, 2017 [Page 1]
Internet-Draft 6tisch-secure-join February 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Credentials . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. One-Touch Assumptions . . . . . . . . . . . . . . . . 4
1.2.2. Factory provided credentials (if any) . . . . . . . . 4
1.2.3. Credentials to be introduced . . . . . . . . . . . . 5
1.3. Network Assumptions . . . . . . . . . . . . . . . . . . . 5
1.3.1. Security above and below IP . . . . . . . . . . . . . 5
1.3.2. Join network assumptions . . . . . . . . . . . . . . 6
1.3.3. Number and cost of round trips . . . . . . . . . . . 6
1.3.4. Size of packets, number of fragments . . . . . . . . 7
1.4. Target end-state for join process . . . . . . . . . . . . 7
2. Join Protocol . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Key Agreement process . . . . . . . . . . . . . . . . . . 8
2.2. Provisional Enrollment process . . . . . . . . . . . . . 8
2.3. Key Distribution Process . . . . . . . . . . . . . . . . 9
3. YANG model for BRSKI objects . . . . . . . . . . . . . . . . 9
3.1. Description of Pledge States in Join Process . . . . . . 10
4. Definition of managed objects for zero-touch bootstrap . . . 10
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
5.1. Privacy Considerations for Production network . . . . . . 11
5.2. Privacy Considerations for New Pledges . . . . . . . . . 11
5.2.1. EUI-64 derived address for join time IID . . . . . . 12
5.3. Privacy Considerations for Join Assistant . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 12
9. Acknwoledgements . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 15
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Appendix A. appendix . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
Enrollment of new nodes into LLNs present unique challenges. The
constrained nodes has no user interfaces, and even if they did,
configuring thousands of such nodes manually is undesireable from a
human resources issue, as well as the difficulty in getting
consistent results.
Richardson Expires August 29, 2017 [Page 2]
Internet-Draft 6tisch-secure-join February 2017
This document is about a standard way to introduce new nodes into a
6tisch network that does not involve any direct manipulation of the
nodes themselves. This act has been called "zero-touch"
provisioning, and it does not occur by chance, but requires
coordination between the manufacturer of the node, the service
operator running the LLN, and the installers actually taking the
devices out of the shipping boxes.
The act of doing "one-touch" provisioning, where a node undergoes a
site-specific indoctrination process is described in
[I-D.ietf-6tisch-minimal-security].
The mechanism described here and in
[I-D.ietf-6tisch-minimal-security] can be discovered by a new node in
a running network, so a device which has received a network-specific
"one-touch" setup, but which is located in another network, and is
capable of "zero-touch" operation could discovery this fact and
operate in other mode.
Many of the components of the zero-touch mechanisms described here
are in common with [I-D.ietf-anima-bootstrapping-keyinfra] and
[I-D.ietf-netconf-zerotouch]. The on-the-wire pledge to join
registrar protocols are different in this protocol from those
described in ANIMA, but conceptually operate identically. The
vouchers are identical. It is expected that the back-end network
operator infrastructure would be able to bootstrap ANIMA-type devices
over ethernet, while also being able bootstrap 6tisch devices over
802.15.4 with few changes.
1.1. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant STuPiD
implementations.
The reader is expected to be familiar with the terms and concepts
defined in [I-D.ietf-6tisch-terminology], [RFC7252],
[I-D.ietf-core-object-security], and
[I-D.ietf-anima-bootstrapping-keyinfra]. The following terms are
imported: drop ship, imprint, enrollment, pledge, join proxy,
ownership voucher, join registrar/coordinator. The following terms
are repeated here for readability, but this document is not
authoritative for their definition:
Richardson Expires August 29, 2017 [Page 3]
Internet-Draft 6tisch-secure-join February 2017
pledge the prospective device, which has the identity provided to at
the factory. Neither the device nor the network knows if the
device yet knows if this device belongs with this network.
Joined Node the prospective device, after having completing 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.
Audit Token A signed token from the manufacturer authorized signing
authority indicating that the bootstrapping event has been
successfully logged. This has been referred to as an
"authorization token" indicating that it authorizes bootstrapping
to proceed.
Ownership Voucher A signed voucher from the vendor vouching that a
specific domain "owns" the new entity as defined in
[I-D.ietf-netconf-zerotouch].
MIC manufacturer installed certificate. An [ieee802-1AR] identity.
1.2. Credentials
In the zero-touch scenario, every device expected to be drop shipped
would have an [ieee802-1AR] manufacturer installed certificate (MIC).
The private key part of the certificate would either be generated in
the device, or installed securely (and privately) as part of the
manufacturing process. [cullenCiscoPhoneDeploy] provides an example
of process which has been active for a good part of a decade.
The MIC would be signed by the manufacturer's CA, the public key
component of that would be included in the firmware.
1.2.1. One-Touch Assumptions
This document interacts with the one-touch solution described in
[I-D.ietf-6tisch-minimal-security].
1.2.2. Factory provided credentials (if any)
When a manufacturer installed certificate is provided as the IDevID,
it SHOULD contain a number of fields.
[I-D.ietf-anima-bootstrapping-keyinfra] provides a detailed set of
requirements.
Richardson Expires August 29, 2017 [Page 4]
Internet-Draft 6tisch-secure-join February 2017
A manufacturer unique serial number MUST be provided in the
serialNumber SubjectAltName extension, and MAY be repeated in the
Common Name. There are no sequential or numeric requirements on the
serialNumber, it may be any unique value that the manufacturer wants
to use. The serialNumber SHOULD be printed on the packaging and/or
on the device in a discrete way so that failures can be physically
traced to the relevant device.
1.2.3. Credentials to be introduced
The goal of the bootstrap process is to introduce one or more new
locally relevant credentials:
1. a certificate signed by a local certificate authority/registrar.
This is the LDevID of [ieee802-1AR].
2. alternatively, a network-wide key to be used to secure L2
traffic.
3. alternatively, a network-wide key to be used to authenticate per-
peer keying of L2 traffic using a mechanism such as provided by
[ieee802159].
1.3. Network Assumptions
This document is about enrollment of constrained devices [RFC7228] to
a constrained network. Constrained networks is such as [ieee802154],
and in particular the time-slotted, channel hopping (tsch) mode,
feature low bandwidths, and limited opportunities to transmit. A key
feature of these networks is that receivers are only listening at
certain times.
1.3.1. Security above and below IP
802.15.4 networks have three kinds of layer-2 security:
o a network key that is shared with all nodes and is used for
unicast and multicast. The key may be used for privacy, and it
may be used in some cases for authentication only (in the case of
enhanced beacons).
o a series of network keys that are shared (agreed to) between pairs
of nodes (the per-peer key)
o a network key that is shared with all nodes (through a group key
management system), and is used for multicast traffic only, while
a per-pair key is used for unicast traffic
Richardson Expires August 29, 2017 [Page 5]
Internet-Draft 6tisch-secure-join February 2017
Setting up the credentials to bootstrap one of these kinds of
security, (or directly configuring the key itself for the first case)
is required. This is the security below the IP layer.
Security is required above the IP layer: there are three aspects
which the credentials in the previous section are to be used.
o to provide for secure connection with a Path Computation Element
[RFC4655], or other LLC (see ({RFC7554}} section 3).
o to initiate a connection between a Resource Server (RS) and an
application layer Authorization Server (AS and CAS from
[I-D.ietf-ace-actors]).
1.3.1.1. Perfect Forward Secrecy
Perfert Forward Secrecy (PFS) is the property of a protocol such that
complete knowledge of the crypto state (for instance, via a memory
dump) at time X does not imply that data from a disjoint time Y can
also be recovered. ([PFS]).
PFS is important for two reasons: one is that it offers protection
against the compromise of a node. It does this by changing the keys
in a non-deterministic way. This second property also makes it much
easier to remove a node from the network, as any node which has not
participated in the key changing process will find itself no longer
connected.
1.3.2. Join network assumptions
The network which the new pledge will connect to will have to have
the following properties:
o a known PANID. The PANID 0xXXXX where XXXX is the assigned RFC#
for this document is suggested.
o a minimal schedule with some Aloha time. This is usually in the
same slotframe as the Enhanced Beacon, but a pledge MUST listen
for an unencrypted Enhanced Beacon to so that it can synchronize.
1.3.3. Number and cost of round trips
TBD.
Richardson Expires August 29, 2017 [Page 6]
Internet-Draft 6tisch-secure-join February 2017
1.3.4. Size of packets, number of fragments
1.4. Target end-state for join process
At the end of the zero-touch join process there will be a symmetric
key protected channel between the Join Registrar/Coordinator and the
pledge, now known as a Joined Node. This channel may be rekeyed via
new exchange of asymmetric exponents (ECDH for instance),
authenticated using the domain specific credentials created during
the join process.
This channel is in the form of an OSCOAP protected connection with
[I-D.ietf-core-comi] encoded objects. This document includes
definition of a [I-D.ietf-netconf-keystore] compatible objects for
encoding of the relevant [I-D.ietf-anima-bootstrapping-keyinfra]
objects.
2. Join Protocol
The pledge join protocol state machine is described in
[I-D.ietf-6tisch-minimal-security], in section XYZ. The pledge
recognizes that it is in zero-touch configuration by the following
situation:
o no PSK has been configured for the network in which it has joined.
o the pledge has no locally defined certificate (no LDevID), only an
IDevID.
o the network asserts an identity that the pledge does not
recognize.
All of these conditions MUST be true. If any of these are not true,
then the pledge has either been connected to the wrong network, or it
has already been bootstrapped into a different network, and it should
wait until it finds that network.
The zero-touch process consists of three stages:
1. the key agreement process
2. the provisional enrollment process
3. the key distribution process
Richardson Expires August 29, 2017 [Page 7]
Internet-Draft 6tisch-secure-join February 2017
2.1. Key Agreement process
The key agreement process is identical to
[I-D.ietf-6tisch-minimal-security]. The process uses EDHOC with
certificates.
The pledge will have to trust the JRC provisionally, as described in
[I-D.ietf-anima-bootstrapping-keyinfra], section 3.1.2, and in
section 4.1.1 of [RFC7030].
The JRC will be able to validate the IDevID of the pledge using the
manufacturer's CA.
The pledge may not know if it is in a zero-touch or one-touch
situation: the pledge may be able to verify the JRC based upon trust
anchors that were installed at manufacturing time. In that case, the
pledge runs the simplified one-touch process.
The pledge signals in the EDHOC message_2 if it has accepted the JRC
certificate. The JRC will in general, not trust the pledge with the
network keys until it has provided the pledge with a voucher. The
pledge will notice the absence of the provisioning keys.
XXX - there could be some disconnect here. May need additional
signals here.
2.2. Provisional Enrollment process
When the pledge determines that it can not verify the certificate of
the JRC using built-in trust anchors, then it enters a provisional
state. In this state, it keeps the channel created by EDHOC open.
A new EDHOC key derivation is done by the JRC and pledge using a new
label, "6tisch-provisional".
The pledge runs as a passive CoMI server, leaving the JRC to drive
the enrollment process. The JRC can interrogate the pledge in a
variety of fashions as shown below: the process terminates when the
JRC provides the pledge with an ownership voucher and the pledge
leaves the provisional state.
A typical interaction involves the following requests:
Richardson Expires August 29, 2017 [Page 8]
Internet-Draft 6tisch-secure-join February 2017
+-----------+ +----------+ +-----------+ +----------+
| | | | | Circuit | | New |
| Vendor | | Registrar| | Proxy | | Entity |
| (MASA) | | | | | | |
++----------+ +--+-------+ +-----------+ +----------+
| | GET request voucher |
| |-------------------------------->
| <----------voucher-token---------|
|/requestvoucher| |
<---------------+ |
+---------------> |
|/requestlog | |
<---------------+ |
+---------------> |
| | POST voucher |
| |-------------------------------->
| <------------2.05 OK ------------+
| | |
| | POST csr attributes |
| |-------------------------------->
| <------------2.05 OK ------------+
| | |
| | GET cert request |
| |-------------------------------->
| ???? <------------2.05 OK ------------+
|<--------------| CSR |
|-------------->| |
| | POST certificate |
| |-------------------------------->
| <------------2.05 OK ------------+
| | |
2.3. Key Distribution Process
The key distribution process utilizes the protocol described
[I-D.richardson-6tisch-minimal-rekey]. The process starts with the
initial key, rather than an actual rekey.
This protocol remains active for subsequent rekey operations.
3. YANG model for BRSKI objects
module ietf-6tisch-brski { yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:6tisch-brski"; prefix
"ietf6brski";
Richardson Expires August 29, 2017 [Page 9]
Internet-Draft 6tisch-secure-join February 2017
//import ietf-yang-types { prefix yang; } //import ietf-inet-types {
prefix inet; }
organization "IETF 6tisch Working Group";
contact "WG Web: http://tools.ietf.org/wg/6tisch/ WG List:
6tisch@ietf.org [2] Author: Michael Richardson mcr+ietf@sandelman.ca
[3]";
description "This module defines an interface to set and retrieve
BRSKI objects using CoMI. This interface is used as part of an
enrollment process for constrained nodes and networks.";
revision "2017-03-01" { description "Initial version"; reference "RFC
XXXX: 6tisch zero-touch bootstrap"; }
// top-level container container ietf6brski { leaf requestnonce {
type binary; length XX; // how big can/should it be? mandatory true;
description "Request Nonce."; } leaf voucher { type binary;
description "The voucher as a serialized COSE object"; }
leaf csrattributes {
type binary;
description "A list of attributes that MUST be in the CSR";
}
leaf certificaterequest {
type binary;
description "A PKIX format Certificate Request";
}
leaf certificate {
type binary;
description "The LDevID certificate";
} } }
3.1. Description of Pledge States in Join Process
TBD
4. Definition of managed objects for zero-touch bootstrap
The following is relevant YANG for use in the bootstrap protocol.
The objects identified are identical in format to the named objects
from [I-D.ietf-anima-bootstrapping-keyinfra].
Richardson Expires August 29, 2017 [Page 10]
Internet-Draft 6tisch-secure-join February 2017
5. Privacy Considerations
[I-D.ietf-6lo-privacy-considerations] details a number of privacy
considerations important in Resource Constrained nodes. There are
two networks and three sets of constrained nodes to consider. They
are: 1. the production nodes on the production network. 2. the new
pledges, which have yet to enroll, and which are on a join network.
3. the production nodes which are also acting as proxy nodes.
5.1. Privacy Considerations for Production network
The details of this are out of scope for this document.
5.2. Privacy Considerations for New Pledges
New Pledges do not yet receive Router Advertisements with PIO
options, and so configure link-local addresses only based upon
layer-2 addresses using the normal SLAAC mechanisms described in
[RFC4191].
These link-local addresses are visible to any on-link eavesdropper
(who is synchronized to the same Join Assistant), so regardless of
what is chosen they can be seen. This link-layer traffic is
encapsulated by the Join Assistant into IPIP packets and carried to
the JCE. The traffic SHOULD never leave the operator's network, and
no outside traffic should enter, so it should not be possible to do
any ICMP scanning as described in
[I-D.ietf-6lo-privacy-considerations].
The join process described herein requires that some identifier
meaningful to the network operator be communicated to the JCE via the
Neighbor Advertisement's ARO option. This need not be a manufacturer
created EUI-64 as assigned by IEEE; it could be another value with
higher entropy and less interesting vendor/device information.
Regardless of what is chosen, it can be used to track where the
device attaches.
For most constrained device, network attachment occurs very
infrequently, often only once in their lifetime, so tracking
opportunities may be rare.
Further, during the enrollment process, a DTLS connection connection
will be created. Unless TLS1.3 is used, the device identity will be
visible to passive observers in the 802.11AR IDevID certificate that
is sent. Even when TLS1.3 is used, an active attacker could collect
the information by simply connecting to the device; it would not have
to successful complete the negotiation either, or even attempt to
Man-In-The-Middle the device.
Richardson Expires August 29, 2017 [Page 11]
Internet-Draft 6tisch-secure-join February 2017
There is, at the same time, significant value in avoiding a link-
local DAD process by using an IEEE assigned EUI-64, and there is also
significant advantage to the operator being able to see what the
vendor of the new device is.
5.2.1. EUI-64 derived address for join time IID
It is therefore suggested that the IID used in the link-local address
used during the join process be a vendor assigned EUI-64. After the
join process has concluded, the device SHOULD be assigned a unique
randomly generated long address, and a unique short address (not
based upon the vendor EUI-64) for use at link-layer. At that point,
all layer-3 content is encrypted by the layer-2 key.
5.3. Privacy Considerations for Join Assistant
6. Security Considerations
7. IANA Considerations
This document allocates one value from the subregistry "Address
Registration Option Status Values": ND_NS_JOIN_DECLINED Join
Assistant, JOIN DECLINED (TBD-AA)
8. Protocol Definition
9. Acknwoledgements
Kristofer Pister helped with many non-IETF references.
10. References
10.1. Normative References
[cullenCiscoPhoneDeploy]
Jennings, C., "Transitive Trust Enrollment for Constrained
Devices", 2012, <http://www.lix.polytechnique.fr/hipercom/
SmartObjectSecurity/papers/CullenJennings.pdf>.
[I-D.ietf-6lo-privacy-considerations]
Thaler, D., "Privacy Considerations for IPv6 Adaptation
Layer Mechanisms", draft-ietf-6lo-privacy-
considerations-04 (work in progress), October 2016.
[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.
Richardson Expires August 29, 2017 [Page 12]
Internet-Draft 6tisch-secure-join February 2017
[I-D.ietf-6tisch-minimal-security]
Vucinic, M., Simon, J., and K. Pister, "Minimal Security
Framework for 6TiSCH", draft-ietf-6tisch-minimal-
security-01 (work in progress), February 2017.
[I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terminology in IPv6 over the TSCH mode of IEEE
802.15.4e", draft-ietf-6tisch-terminology-08 (work in
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.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-09 (work in progress), December 2016.
[I-D.ietf-core-comi]
Stok, P., Bierman, A., Veillette, M., and A. Pelov, "CoAP
Management Interface", draft-ietf-core-comi-00 (work in
progress), January 2017.
[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-netconf-keystore]
Watsen, K. and G. Wu, "Keystore Model", draft-ietf-
netconf-keystore-00 (work in progress), October 2016.
[I-D.ietf-netconf-zerotouch]
Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning
for NETCONF or RESTCONF based Management", draft-ietf-
netconf-zerotouch-12 (work in progress), January 2017.
[I-D.richardson-6tisch-join-enhanced-beacon]
Richardson, M., "802.15.4 Informational Element
encapsulation of 6tisch Join Information", draft-
richardson-6tisch-join-enhanced-beacon-00 (work in
progress), February 2017.
Richardson Expires August 29, 2017 [Page 13]
Internet-Draft 6tisch-secure-join February 2017
[I-D.richardson-6tisch-minimal-rekey]
Richardson, M., "Minimal Security rekeying mechanism for
6TiSCH", draft-richardson-6tisch-minimal-rekey-00 (work in
progress), February 2017.
[I-D.richardson-anima-6join-discovery]
Richardson, M., "GRASP discovery of Registrar by Join
Assistant", draft-richardson-anima-6join-discovery-00
(work in progress), October 2016.
[iec62591]
IEC, ., "62591:2016 Industrial networks - Wireless
communication network and communication profiles -
WirelessHART", 2016, <https://webstore.iec.ch/
publication/24433>.
[ieee802-1AR]
IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier",
2009, <http://standards.ieee.org/findstds/
standard/802.1AR-2009.html>.
[ieee802154]
IEEE Standard, ., "802.15.4-2015 - IEEE Standard for Low-
Rate Wireless Personal Area Networks (WPANs)", 2015,
<http://standards.ieee.org/findstds/
standard/802.15.4-2015.html>.
[ieee802159]
IEEE Standard, ., "802.15.9-2016 - IEEE Approved Draft
Recommended Practice for Transport of Key Management
Protocol (KMP) Datagrams", 2016,
<http://standards.ieee.org/findstds/
standard/802.15.9-2016.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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>.
Richardson Expires August 29, 2017 [Page 14]
Internet-Draft 6tisch-secure-join February 2017
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013,
<http://www.rfc-editor.org/info/rfc7030>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
10.2. Informative References
[duckling]
Stajano, F. and R. Anderson, "The resurrecting duckling:
security issues for ad-hoc wireless networks", 1999,
<https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-
duckling.pdf>.
[I-D.ietf-ace-actors]
Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An
architecture for authorization in constrained
environments", draft-ietf-ace-actors-04 (work in
progress), September 2016.
[I-D.ietf-roll-useofrplinfo]
Robles, I., Richardson, M., and P. Thubert, "When to use
RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll-
useofrplinfo-10 (work in progress), December 2016.
[ISA100] "The Technology Behind the ISA100.11a Standard", June
2010, <http://www.isa100wci.org/Documents/PDF/
The-Technology-Behind-ISA100-11a-v-3_pptx>.
[PFS] Wikipedia, ., "Forward Secrecy", August 2016,
<https://en.wikipedia.org/w/
index.php?title=Forward_secrecy&oldid=731318899>.
Richardson Expires August 29, 2017 [Page 15]
Internet-Draft 6tisch-secure-join February 2017
[pledge] Dictionary.com, ., "Dictionary.com Unabridged", 2015,
<http://dictionary.reference.com/browse/pledge>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <http://www.rfc-editor.org/info/rfc4191>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>.
[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>.
[RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power
and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731,
February 2016, <http://www.rfc-editor.org/info/rfc7731>.
10.3. URIs
[2] mailto:6tisch@ietf.org
[3] mailto:mcr+ietf@sandelman.ca
Appendix A. appendix
insert appendix here
Author's Address
Michael Richardson
Sandelman Software Works
Email: mcr+ietf@sandelman.ca
Richardson Expires August 29, 2017 [Page 16]
