draft-ietf-6tisch-dtsecurity-secure-join-00.txt		draft-ietf-6tisch-dtsecurity-secure-join-01.txt
	6tisch Working Group M. Richardson		6tisch Working Group M. Richardson
	Internet-Draft Sandelman Software Works		Internet-Draft Sandelman Software Works
	Intended status: Informational December 15, 2016		Intended status: Informational February 25, 2017
	Expires: June 18, 2017		Expires: August 29, 2017
	6tisch Secure Join protocol		6tisch Secure Join protocol
	draft-ietf-6tisch-dtsecurity-secure-join-00		draft-ietf-6tisch-dtsecurity-secure-join-01
	Abstract		Abstract
	Charter: The WG will continue working on securing the join process		This document describes a zero-touch mechanism to enroll a new device
	and making that fit within the constraints of high latency, low		(the "pledge") into a IEEE802.15.4 TSCH network using the 6tisch
	throughput and small frame sizes that characterize IEEE802.15.4 TSCH.		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		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 18, 2017.		This Internet-Draft will expire on August 29, 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
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Credentials . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Credentials . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2.1. One-Touch Assumptions . . . . . . . . . . . . . . . . 4		1.2.1. One-Touch Assumptions . . . . . . . . . . . . . . . . 4
	1.2.2. Factory provided credentials (if any) . . . . . . . . 5		1.2.2. Factory provided credentials (if any) . . . . . . . . 4
	1.2.3. Credentials to be introduced . . . . . . . . . . . . 5		1.2.3. Credentials to be introduced . . . . . . . . . . . . 5
	1.3. Network Assumptions . . . . . . . . . . . . . . . . . . . 5		1.3. Network Assumptions . . . . . . . . . . . . . . . . . . . 5
	1.3.1. Security above and below IP . . . . . . . . . . . . . 6		1.3.1. Security above and below IP . . . . . . . . . . . . . 5
	1.3.2. Join network assumptions . . . . . . . . . . . . . . 7		1.3.2. Join network assumptions . . . . . . . . . . . . . . 6
	1.3.3. Number and cost of round trips . . . . . . . . . . . 7		1.3.3. Number and cost of round trips . . . . . . . . . . . 6
	1.3.4. Size of packets, number of fragments . . . . . . . . 7		1.3.4. Size of packets, number of fragments . . . . . . . . 7
	1.4. Target end-state for join process . . . . . . . . . . . . 7		1.4. Target end-state for join process . . . . . . . . . . . . 7
	2. Join Protocol . . . . . . . . . . . . . . . . . . . . . . . . 7		2. Join Protocol . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.1. Diagram of Join Process . . . . . . . . . . . . . . . . . 7		2.1. Key Agreement process . . . . . . . . . . . . . . . . . . 8
	2.2. Description of Pledge States in Join Process . . . . . . 8		2.2. Provisional Enrollment process . . . . . . . . . . . . . 8
	2.2.1. (1) Layer-2 Enhanced Beacon . . . . . . . . . . . . . 8		2.3. Key Distribution Process . . . . . . . . . . . . . . . . 9
	2.2.2. (1B) Layer-3 Router Advertisement . . . . . . . . . . 8		3. YANG model for BRSKI objects . . . . . . . . . . . . . . . . 9
	2.2.3. (2) Pledge sends (unicast) Neighbor Solicitation to		3.1. Description of Pledge States in Join Process . . . . . . 10
	Join Assistant . . . . . . . . . . . . . . . . . . . 8		4. Definition of managed objects for zero-touch bootstrap . . . 10
	2.2.4. (3) Join Assistant sends Query to Registar . . . . . 9		5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
	2.2.5. (4) Join Assistant receives Acceptance response from		5.1. Privacy Considerations for Production network . . . . . . 11
	Registrar . . . . . . . . . . . . . . . . . . . . . . 9		5.2. Privacy Considerations for New Pledges . . . . . . . . . 11
	2.2.6. (5) Pledge receives (unicast) Neighbor Advertisement		5.2.1. EUI-64 derived address for join time IID . . . . . . 12
	from join assistant . . . . . . . . . . . . . . . . . 9		5.3. Privacy Considerations for Join Assistant . . . . . . . . 12
	2.3. Join process state machine for pledge . . . . . . . . . . 10		6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	2.4. Description of Join Assistant States in Join Process . . 11		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	2.4.1. Processing of Insecure Packets . . . . . . . . . . . 12		8. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 12
	3. Join Assistant to Registrar protocol . . . . . . . . . . . . 13		9. Acknwoledgements . . . . . . . . . . . . . . . . . . . . . . 12
	3.1. Discovery of Registrar . . . . . . . . . . . . . . . . . 13		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	3.2. Notification of a new pledge to Registar . . . . . . . . 14		10.1. Normative References . . . . . . . . . . . . . . . . . . 12
	3.3. Passing of traffic from Pledge to Registar . . . . . . . 14		10.2. Informative References . . . . . . . . . . . . . . . . . 15
	4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15		10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	4.1. Privacy Considerations for Production network . . . . . . 15		Appendix A. appendix . . . . . . . . . . . . . . . . . . . . . . 16
	4.2. Privacy Considerations for New Pledges . . . . . . . . . 15		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
	4.2.1. EUI-64 derived address for join time IID . . . . . . 16
	4.3. Privacy Considerations for Join Assistant . . . . . . . . 16
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	7. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 17
	8. Acknwoledgements . . . . . . . . . . . . . . . . . . . . . . 17
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	9.1. Normative References . . . . . . . . . . . . . . . . . . 17
	9.2. Informative References . . . . . . . . . . . . . . . . . 19
	Appendix A. appendix . . . . . . . . . . . . . . . . . . . . . . 20
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	Enrollment of new nodes into LLNs present unique challenges. The		Enrollment of new nodes into LLNs present unique challenges. The
	constrained nodes has no user interfaces, and even if they did,		constrained nodes has no user interfaces, and even if they did,
	configuring thousands of such nodes manually is undesireable from a		configuring thousands of such nodes manually is undesireable from a
	human resources issue, as well as the difficulty in getting		human resources issue, as well as the difficulty in getting
	consistent results.		consistent results.
	This document is about a standard way to introduce new nodes into a		This document is about a standard way to introduce new nodes into a
	6tisch network that does not involve any direct manipulation of the		6tisch network that does not involve any direct manipulation of the
	nodes themselves. This act has been called "zero-touch"		nodes themselves. This act has been called "zero-touch"
	provisioning, and it does not occur by chance, but requires		provisioning, and it does not occur by chance, but requires
	coordination between the manufacturer of the node, the service		coordination between the manufacturer of the node, the service
	operator running the LLN, and the installers actually taking the		operator running the LLN, and the installers actually taking the
	devices out of the shipping boxes.		devices out of the shipping boxes.
	In other installations (such as some factory/industrial settings, and		The act of doing "one-touch" provisioning, where a node undergoes a
	for some utilities), it is possible to pass devices through a		site-specific indoctrination process is described in
	"provisioning" room of some kind where the device in factory default		[I-D.ietf-6tisch-minimal-security].
	state may be touched once (via a cable, or a push button, or by being
	placed in a faraday cage, etc.) such that the devices can be		The mechanism described here and in
	initialized in a way specific to that installation. The devices are		[I-D.ietf-6tisch-minimal-security] can be discovered by a new node in
	then returned to inventory, and may be deployed at some future time.		a running network, so a device which has received a network-specific
	The node is not provisioned with the current keying material, as the		"one-touch" setup, but which is located in another network, and is
	network will need to be regularly rekeyed (even the algorithms may		capable of "zero-touch" operation could discovery this fact and
	change!), so in the one-touch provisioning case, the goal is simply		operate in other mode.
	to introduce some elements into the new node (the "pledge") such that
	the enrollment process will take less energy and fewer network		Many of the components of the zero-touch mechanisms described here
	resources.		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		1.1. Terminology
	In this document, the key words "MUST", "MUST NOT", "REQUIRED",		In this document, the key words "MUST", "MUST NOT", "REQUIRED",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",		"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119		and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
	[RFC2119] and indicate requirement levels for compliant STuPiD		[RFC2119] and indicate requirement levels for compliant STuPiD
	implementations.		implementations.
	The following terminology is repeated from		The reader is expected to be familiar with the terms and concepts
	[I-D.ietf-anima-bootstrapping-keyinfra] so as to have a common way to		defined in [I-D.ietf-6tisch-terminology], [RFC7252],
	speak:		[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:
	drop ship The physical distribution of equipment containing the		pledge the prospective device, which has the identity provided to at
	"factory default" configuration to a final destination. In zero-		the factory. Neither the device nor the network knows if the
	touch scenarios there is no staging or pre-configuration during		device yet knows if this device belongs with this network.
	drop-ship.
	imprint the process where a device obtains the cryptographic key		Joined Node the prospective device, after having completing the join
	material to identity and trust future interactions with a network.		process, often just called a Node.
	This term is taken from Konrad Lorenz's work in biology with new
	ducklings: during a critical period, the duckling would assume
	that anything that looks like a mother duck is in fact their
	mother. An equivalent for a device is to obtain the fingerprint
	of the network's root certification authority certificate. A
	device that imprints on an attacker suffers a similar fate to a
	duckling that imprints on a hungry wolf. Securely imprinting is a
	primary focus of this document. [duckling] anticipates this use.
	enrollment the process where a device presents key material to a		Join Proxy (JP): a stateless relay that provides connectivity
	network and acquires a network specific identity. For example		between the pledge and the join registrar/coordinator.
	when a certificate signing request is presented to a certification
	authority and a certificate is obtained in response.
	pledge the prospective device, which has the identity provided to at		Join Registrar/Coordinator (JRC): central entity responsible for
	the factory. Neither the device nor the network knows if the		authentication and authorization of joining nodes.
	device yet knows if this device belongs with this network. This
	is definition 6, according to [pledge].
	Audit Token A signed token from the manufacturer authorized signing		Audit Token A signed token from the manufacturer authorized signing
	authority indicating that the bootstrapping event has been		authority indicating that the bootstrapping event has been
	successfully logged. This has been referred to as an		successfully logged. This has been referred to as an
	"authorization token" indicating that it authorizes bootstrapping		"authorization token" indicating that it authorizes bootstrapping
	to proceed.		to proceed.
	Ownership Voucher A signed voucher from the vendor vouching that a		Ownership Voucher A signed voucher from the vendor vouching that a
	specific domain "owns" the new entity as defined in		specific domain "owns" the new entity as defined in
	[I-D.ietf-netconf-zerotouch].		[I-D.ietf-netconf-zerotouch].
			MIC manufacturer installed certificate. An [ieee802-1AR] identity.
	1.2. Credentials		1.2. Credentials
	In the zero-touch scenario, every device expected to be drop shipped		In the zero-touch scenario, every device expected to be drop shipped
	would have an [ieee802-1AR] manufacturer installed certificate (MIC).		would have an [ieee802-1AR] manufacturer installed certificate (MIC).
	The private key part of the certificate would either be generated in		The private key part of the certificate would either be generated in
	the device, or installed securely (and privately) as part of the		the device, or installed securely (and privately) as part of the
	manufacturer process. [cullenCiscoPhoneDeploy] provides an example		manufacturing process. [cullenCiscoPhoneDeploy] provides an example
	of process which has been active for a good part of a decade.		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		The MIC would be signed by the manufacturer's CA, the public key
	component of that would be included in the firmware.		component of that would be included in the firmware.
	1.2.1. One-Touch Assumptions		1.2.1. One-Touch Assumptions
	In a one-touch scenario, devices would be provided with some		This document interacts with the one-touch solution described in
	mechanism by which a secure association may be made in a controlled		[I-D.ietf-6tisch-minimal-security].
	environment. There are many ways in which this might be done, and
	detailing any of them is out of scope for this document. But, some
	notion of how this might be done is important so that the underlying
	assumptions can be reasoned about.
	Some examples of how to do this could include: * JTAG interface *
	serial (craft) console interface * pushes of physical buttons
	simulatenous to network attachment * insecured devices operated in a
	Faraday cage
	There are likely many other ways as well. What is assumed is that
	there can be a secure, private conversation between the Join
	Coordination Entity, and the Pledge, and that the two devices can
	exchange some trusted bytes of information.
	1.2.2. Factory provided credentials (if any)		1.2.2. Factory provided credentials (if any)
	When a manufacturer installed certificate is provided as the IDevID,		When a manufacturer installed certificate is provided as the IDevID,
	it SHOULD contain a number of fields.		it SHOULD contain a number of fields.
	[I-D.ietf-anima-bootstrapping-keyinfra] provides a detailed set of		[I-D.ietf-anima-bootstrapping-keyinfra] provides a detailed set of
	requirements.		requirements.
	A manufacturer unique serial number MUST be provided in the		A manufacturer unique serial number MUST be provided in the
	serialNumber SubjectAltName extension, and MAY be repeated in the		serialNumber SubjectAltName extension, and MAY be repeated in the
	Common Name. There are no sequential or numeric requirements on the		Common Name. There are no sequential or numeric requirements on the
	serialNumber, it may be any unique value that the manufacturer wants		serialNumber, it may be any unique value that the manufacturer wants
	to use. The serialNumber SHOULD be printed on the packaging and/or		to use. The serialNumber SHOULD be printed on the packaging and/or
	on the device in a discrete way.		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		1.2.3. Credentials to be introduced
	The goal of the bootstrap process is to introduce one or more new		The goal of the bootstrap process is to introduce one or more new
	locally relevant credentials:		locally relevant credentials:
	1. a certificate signed by a local certificate authority/registrar.		1. a certificate signed by a local certificate authority/registrar.
	This is the LDevID of [ieee802-1AR].		This is the LDevID of [ieee802-1AR].
	2. alternatively, a network-wide key to be used to secure L2		2. alternatively, a network-wide key to be used to secure L2
	skipping to change at page 6, line 13 ¶		skipping to change at page 5, line 42 ¶
	and in particular the time-slotted, channel hopping (tsch) mode,		and in particular the time-slotted, channel hopping (tsch) mode,
	feature low bandwidths, and limited opportunities to transmit. A key		feature low bandwidths, and limited opportunities to transmit. A key
	feature of these networks is that receivers are only listening at		feature of these networks is that receivers are only listening at
	certain times.		certain times.
	1.3.1. Security above and below IP		1.3.1. Security above and below IP
	802.15.4 networks have three kinds of layer-2 security:		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		o a network key that is shared with all nodes and is used for
	unicast and multicast.		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		o a series of network keys that are shared (agreed to) between pairs
	of nodes (the per-peer key)		of nodes (the per-peer key)
	o a network key that is shared with all nodes (through a group key		o a network key that is shared with all nodes (through a group key
	management system), and is used for multicast traffic only		management system), and is used for multicast traffic only, while
			a per-pair key is used for unicast traffic
	Setting up the credentials to bootstrap one of these kinds of		Setting up the credentials to bootstrap one of these kinds of
	security, (or directly configuring the key itself for the first case)		security, (or directly configuring the key itself for the first case)
	is required. This is the security below the IP layer.		is required. This is the security below the IP layer.
	Security is required above the IP layer: there are three aspects		Security is required above the IP layer: there are three aspects
	which the credentials in the previous section are to be used.		which the credentials in the previous section are to be used.
	o to provide for secure connection with a Path Computation Element		o to provide for secure connection with a Path Computation Element
	[RFC4655], or other LLC (see ({RFC7554}} section 3).		[RFC4655], or other LLC (see ({RFC7554}} section 3).
	skipping to change at page 7, line 14 ¶		skipping to change at page 6, line 42 ¶
	1.3.2. Join network assumptions		1.3.2. Join network assumptions
	The network which the new pledge will connect to will have to have		The network which the new pledge will connect to will have to have
	the following properties:		the following properties:
	o a known PANID. The PANID 0xXXXX where XXXX is the assigned RFC#		o a known PANID. The PANID 0xXXXX where XXXX is the assigned RFC#
	for this document is suggested.		for this document is suggested.
	o a minimal schedule with some Aloha time. This is usually in the		o a minimal schedule with some Aloha time. This is usually in the
	same slotframe as the Extended Beacon, but a pledge MUST listen		same slotframe as the Enhanced Beacon, but a pledge MUST listen
	for an unencrypted Extended Beacon to so that it can synchronize.		for an unencrypted Enhanced Beacon to so that it can synchronize.
	o a known K1 key, as described in [I-D.ietf-6tisch-minimal] section
	10, and used for reasons similar to [iec62591].
	1.3.3. Number and cost of round trips		1.3.3. Number and cost of round trips
			TBD.
	1.3.4. Size of packets, number of fragments		1.3.4. Size of packets, number of fragments
	1.4. Target end-state for join process		1.4. Target end-state for join process
	2. Join Protocol		At the end of the zero-touch join process there will be a symmetric
			key protected channel between the Join Registrar/Coordinator and the
	This section describes the interaction between a new pledge and the		pledge, now known as a Joined Node. This channel may be rekeyed via
	Join Assistant.		new exchange of asymmetric exponents (ECDH for instance),
			authenticated using the domain specific credentials created during
	2.1. Diagram of Join Process		the join process.
	This time sequence diagram intentionally shows additional layer-2 and
	layer-3 interactions, in order to put the entire process into
	context.
	PLEDGE(JN) JOIN ASSISTANT(JA) JCE
	<--------------- BEACON-L2 (1)
	<-------RA ------ (1B)
	---- NS w/ARO ---> (2)
	------- QUERY----> (3)
	<------ REPLY----- (4)
	<--- NA answer---- (5)
	some time later
	<-----coaps--------<=======IPIP-COAPS==== (6)
	multiple trips
	------------------->====================> (7)
	2.2. Description of Pledge States in Join Process
	2.2.1. (1) Layer-2 Enhanced Beacon
	A new pledge must listen for a beacon for a period of at least 2s
	(HELP) on each of the 16 possible channels. The pledge SHOULD
	collect all beacons from heard on all channels before selecting a
	beacon to start with. If the pledge is unable to record all of the
	beacons that it hears due to limitations on volatile storage, then it
	should at least attempt to record the detail as to how to find that
	beacon again (channel, time sequence).
	This search process entails having the pledge keep the receiver
	portion of it's radio active for the entire period of time.
	The selection of which beacon to start with is outside the scope of
	this document. Implementers SHOULD make use of information such as:
	whether the L2 address of the Beacon has been tried before, whether a
	Router Advertisement IE is present, any Network Identifier
	[I-D.richardson-6lo-ra-in-ie] seen, and the strength of the signal.
	Once a candidate network has been selected, the pledge can transition
	into a low-power duty cycle, waking only when the provided schedule
	indicates ALOHA slots which the pledge may use for the join process.
	2.2.2. (1B) Layer-3 Router Advertisement
	If [I-D.richardson-6lo-ra-in-ie] has not been used to embed a router
	advertisement in the Enhanced Beacon, then the pledge MUST wait to
	hear a Router Advertisement to know the layer-3 address of the
	adjacent router. These will be broadcast periodically during the
	ALOHA slot.
	A pledge MAY timeout and send a layer-2 unicast Router Solicitation
	(to the layer-2 of the Enhanced Beacon) to the layer-3 all-routers
	address. A pledge MAY also take this timeout to mean that this
	router is unwilling to perform Join Assistant activities and the
	pledge should move on to another Enhanced Beacon.
	2.2.3. (2) Pledge sends (unicast) Neighbor Solicitation to Join
	Assistant
	This NS message is formed much like a Duplicate Address Detection
	(DAD) message described in [RFC6775] section-4.3: it is a
	solicitation by the pledge for it's own address. [RFC6775] does not
	describe doing DAD for link-local address however, so this aspect is
	new.
	The Join Assistant will not validate the uniqueness using the DAR/DAC
	mechanism, but will otherwise process the NS as per normal:
	populating neighbor cache entries. The Join Assistant will take
	extra care with expiring neighbor cache entries: unsecured NS should
	never push secured NCE entries out of the cache or overwrite them.
	There are two equivalent ways to do this:
	1. marking the origin of the NCE and limiting unsecured ones to some
	portion of the entries;
	2. by considering unsecured NS to be arriving from a different
	virtual interface (different if_index) than secured ones. NCEs
	from different interfaces SHOULD already not be mixed.
	The pledge SHOULD NOT have configured a short Layer-2 address as it
	has no way to allocate a non-duplicate short address. It SHOULD have
	formed a standard 64-bit layer-3 link-local address using a built-in
	IID. This IID MUST be placed into the Address Resolution option
	(ARO) option in the Neighbor Soliciation, as it serves as the index
	by which the domain registrar will use to identify the device.
	The IID MAY be related to the layer-2 address, but privacy
	considerations recommend that the IID SHOULD instead be a form a
	stable privacy address [RFC7217]. Whichever method is used MUST be
	decided at manufacturing time, as the IID is also repeated as the
	SerialNumber in the Manufacturer Installed Certificate (MIC), also
	referred to as the 802.1AR IDevID.
	2.2.4. (3) Join Assistant sends Query to Registar
	This step does not involve the pledge, and it is described in section
	(#jastates).
	2.2.5. (4) Join Assistant receives Acceptance response from Registrar
	This step does not involve the pledge, and it is described in section
	(#jastates).
	2.2.6. (5) Pledge receives (unicast) Neighbor Advertisement from join
	assistant
	This NA message is again identical to the Duplicate Address Detection
	mechanism described in [RFC6775]. The status field of the ARO is
	extended (see (#ianaconsiderations)) to include an additional status
	value ND_NS_JOIN_DECLINED.
	The pledge, upon receipt of ND_NS_JOIN_DECLINED considers that this
	network is not an appropriate network to join, and SHOULD move on to
	attempt other networks. The pledge MUST also realize that this NA
	message MAY have been forced, and it SHOULD attempt joining this
	network again at a future time, but MUST NOT repeatedly attempt to
	join the same network.
	The pledge, upon receipt of a Neighbor Cache Full response SHOULD
	attempt to join using a different join assistant on the same network.
	The pledge, upon receipt of a Duplicate Address response SHOULD
	attempt to join using a different join assistant on a different
	network, if it has such offers. If it has no such offers, it should
	wait at least NEIGHBOR-CACHE TIMEOUT, and then retry. This may be a
	sign of a Denial of Service attack, or it may be a non-malicious mis-
	configuration.
	Upon receive of a successful NA, the pledge SHOULD consider that it
	is now in enrolled in a join queue. The pledge SHOULD resend
	Neighbor Soliciation (NUD) messages periodically as described in
	[RFC6775] to maintain the neighbor cache entry.
	A pledge with other Join Assistant offers MAY abandon this Join
	Assistant after a period of XXX minutes and attempt to join using a
	different Join Assistant.
	2.3. Join process state machine for pledge
	+----------------+ +----------+
	| collecting |-------->| sleep 1m |
	| beacons |<----- +~~~~~~~~~~+
	+----------------+ \______/ ^
	| |
	V | no beacons
	+-----------------+ | remain
	| try next/first | |
	| beacon/sched |-----------------/
	+-----------------+<____________ timeout
	| \--.<--.
	| send NS/DAD <-------. | |
	/-------->| w/ARO | | |
	| | timeout| | |
	| V retries<3 | | |
	| +-----------------+ | | |
	| | waiting for | | | |
	| | NA w/ARO |----------->----> |
	| +-----------------+ or invalid NA |
	| | |
	| | |
	| | |
	| V |
	| +-----------------+ DTLS failure |
	| | open DTLS 6p |--------------------/
	| | for system | ^
	| | keychain |<--------\ |
	| +-----------------+ | |
	| | | conclude |
	| | kill DTLS | not net |
	| | try again | looking |
	| | retries<3 | for |
	| V | |
	| +-----------------+ | |
	| | validate audit |---------/----------/
	| |token posted to | does not validate
	| | proper URL |
	| +-----------------+
	| |
	|too long | validate
	|try | audit
	|again | token
	| V
	| +-----------------+
	\-| accept 6p trans-|
	| actions for new |
	| certificate |
	+-----------------+
	|
	| receive new certificate,
	V restart with beacon
	X run appropriate KMP
	2.4. Description of Join Assistant States in Join Process
	The Join Assistant is a standard 6LR. It processes packets as
	described in [RFC6775], [I-D.ietf-6tisch-minimal] from secured
	(encrypted) sources.
	In particular the maintenance of Neighbor Cache Entries as described
	in [RFC6775] section 3.5. The Join Assistant maintains two sets of
	NCE for each physical interface that it has: one set is for secured
	neighbors, and the other is for new pledges that wish to join. The
	storage allocated for pledges will generally be a small fraction of
	available space. The Join Assistant will garbage collect the
	different caches according to different thresholds. It MAY chose to
	free space from the insecure cache to make space for additional
	secure entries, but it MUST NOT do the opposite.
	It sends Enhanced Beacons which are authenticated with the network-		This channel is in the form of an OSCOAP protected connection with
	wide key ("K2"), but it does not encrypt the Beacons.		[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.
	In addition, it listen for packets "encrypted" with the well-known		2. Join Protocol
	"K1" key, and when it receives them, it considers them to be as
	"Insecure Packets". It MAY also accept unencrypted, unauthenticated
	packets as being "Insecure Packets"
	Non-Join Assistant 6LRs would never accept K1 packets, nor		The pledge join protocol state machine is described in
	unauthenticated packets. Normal 6LRs and hosts MUST accept		[I-D.ietf-6tisch-minimal-security], in section XYZ. The pledge
	unencrypted Enhanced Beacons which can be authenticated with the "K2"		recognizes that it is in zero-touch configuration by the following
	key.		situation:
	In addition to seperating the secured and insecured packets for		o no PSK has been configured for the network in which it has joined.
	inbound processing, the Join Assistant also allocates a unique IID
	for the insecured interface. This IID is used to configure the Link
	Local address on that virtual interface. This Link Local address is
	called the Insecure Join Assistant Link Local, or IJALL.
	In addition, this IID is combined with the global prefix(es) (as		o the pledge has no locally defined certificate (no LDevID), only an
	found in various PIO(s) from the routing protocols). This additional		IDevID.
	address is configured as an alias on the loopback interface such that
	the Join Assistant can receive packets to this address via secured
	network. This activity SHOULD generate a routing protocol update
	(such as an updated DAO). This IID SHOULD be generated using a
	stable privacy address mechanism as described in [RFC7217]. The
	easiest is to assign the insecure virtual interface a unique
	if_index. This new address is called the Pledge Tunnel End Point
	Address, or PTEPA.
	2.4.1. Processing of Insecure Packets		o the network asserts an identity that the pledge does not
			recognize.
	Only the following insecure packets are to be accepted by the Join		All of these conditions MUST be true. If any of these are not true,
	Assistant:		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.
	1. Unicast Neighbor Solicitations.		The zero-touch process consists of three stages:
	2. Unicast Link-Local UDP packets with a destination port that map		1. the key agreement process
	to the Join Assistant's IPIP proxy.
	2.4.1.1. Processing of Insecure Neighbor Solicitation packets		2. the provisional enrollment process
	Upon receipt of an insecure unicast NS with an ARO option, the Join		3. the key distribution process
	Assistant looks up an NCE by the IID contained in the ARO in the
	insecure cache. If it finds an existing there are three
	possibilities:
	1. a lookup for this entry has previously been completed, and has		2.1. Key Agreement process
	resulted in a negative result. In this case, a negative
	ND_NS_JOIN_DECLINED NA is returned. The Join Assistant SHOULD
	rate limit the number of these messages that it is willing to
	return.
	2. a lookup for this entry has previously been done, and has		The key agreement process is identical to
	resulted in a positive result. The NCE entry should be		[I-D.ietf-6tisch-minimal-security]. The process uses EDHOC with
	"refresh", to keep it in the cache for a longer period of time,		certificates.
	and a new NA returned with a positive status.
	3. a lookup for this entry has previously been started, but no		The pledge will have to trust the JRC provisionally, as described in
	result has been received. In this case the Join Assistant SHOULD		[I-D.ietf-anima-bootstrapping-keyinfra], section 3.1.2, and in
	remain silent. The Join Assistant may wish to send a GRASP		section 4.1.1 of [RFC7030].
	M_NOOP message to verify that the connection is still useable if
	it has not receive any traffic in some time.
	If it does not find an existing entry, and there is space for another		The JRC will be able to validate the IDevID of the pledge using the
	entry, (or it can make space via garbage collection), then a new		manufacturer's CA.
	entry is created, marked to be "in progress", and a new GRASP 6JOIN
	query is initiated, see section (#6joingrasp).
	3. Join Assistant to Registrar protocol		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.
	There are three aspects to the protocols that the Join Assistant uses		The pledge signals in the EDHOC message_2 if it has accepted the JRC
	to communicate about its needs. They are:		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.
	1. Discovery of Registrar		XXX - there could be some disconnect here. May need additional
			signals here.
	2. Notification of new pledge to Registrar		2.2. Provisional Enrollment process
	3. Passing of traffic from Pledge to Registar		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.
	3.1. Discovery of Registrar		A new EDHOC key derivation is done by the JRC and pledge using a new
			label, "6tisch-provisional".
	The address of the registrar MAY be determined by other protocols,		The pledge runs as a passive CoMI server, leaving the JRC to drive
	such as DHCP, RA or RPL extensions, or provisioned into the Join		the enrollment process. The JRC can interrogate the pledge in a
	Assistant via other configuration protocol such as 6p.		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.
	In order to support fully autonomic operations, the Join Assistant		A typical interaction involves the following requests:
	MAY use a GRASP discovery ([I-D.ietf-anima-grasp]) to find the
	address of the Registrar. [I-D.richardson-anima-6join-discovery]
	describes the details of the process.
	In 6tisch networks multicast is not always available, requiring		+-----------+ +----------+ +-----------+ +----------+
	additional protocol [RFC7731] effort. Instead of doing a multicast		| | | | | Circuit | | New |
	GRASP discovery, the Join Assistant SHOULD instead to a TCP connect		| Vendor | | Registrar| | Proxy | | Entity |
	to the GRASP_LISTEN_PORT on the IP address of the DODAG root (when		| (MASA) | | | | | | |
	RPL is used as the routing protocol for 6tisch), or the ABRO address		++----------+ +--+-------+ +-----------+ +----------+
	when another protocol is used. The Join Assistant should then issue		| | GET request voucher |
	the appropriate M_DISCOVERY method using the 6JOIN objective. The		| |-------------------------------->
	GRASP discovery will then reply using the same TCP connection as per		| <----------voucher-token---------|
	Unicast Discovery in [I-D.ietf-anima-grasp] section TBD.		|/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 ------------+
			| | |
	3.2. Notification of a new pledge to Registar		2.3. Key Distribution Process
	As illustrated in (#joindiagram), when the Join Assistant receives a		The key distribution process utilizes the protocol described
	Neighbor Solication from a pledge, it must notify the Registar of the		[I-D.richardson-6tisch-minimal-rekey]. The process starts with the
	pledge, indicating to it how to reach the new pledge. The Registrar		initial key, rather than an actual rekey.
	will respond with a positive acknowledgement if the Registrar is
	willing/able to accept the pledge. The Registrar will respond with a
	negative acknowledgement if the provided pledge identity (the IID in
	the ARO) is not one that the Registrar recognizes as belonging to
	this network.
	The Registrar runs an ASA which is called the 6JOIN ASA (which can be		This protocol remains active for subsequent rekey operations.
	discovered above). This query/response is done using GRASP with the
	discovered ASA process.
	The query process is described in CDDL as:		3. YANG model for BRSKI objects
	request-6join-query = [M_REQ_NEG, session-id, "6JOIN", [IID, "6p-ipip"]]		module ietf-6tisch-brski { yang-version 1.1;
	IID = bytes .size 8
	The response from the Registrar is describe as:		namespace "urn:ietf:params:xml:ns:yang:6tisch-brski"; prefix
			"ietf6brski";
			//import ietf-yang-types { prefix yang; } //import ietf-inet-types {
			prefix inet; }
	response-6join-query = [M_END, session-id, [O_ACCEPT]]		organization "IETF 6tisch Working Group";
	or for a negative response:		contact "WG Web: http://tools.ietf.org/wg/6tisch/ WG List:
			6tisch@ietf.org [2] Author: Michael Richardson mcr+ietf@sandelman.ca
			[3]";
	response-6join-query = [M_END, session-id, [O_DECLINE]]		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.";
	for the 6p-ipip, the Registrar will need to know where to send the		revision "2017-03-01" { description "Initial version"; reference "RFC
	IPIP packets to. The Join Assistant will initiate the TCP connection		XXXX: 6tisch zero-touch bootstrap"; }
	to the Registrar's ASA using the IPv6 address associated with the
	insecure interface on which the pledge is located, i.e. using the
	PTEPA.
	3.3. Passing of traffic from Pledge to Registar		// 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"; }
	When the Registrar is ready to initiate the pledge into the domain,		leaf csrattributes {
	the Registrar will reach out to the pledge using a secure CoAP		type binary;
	protocol (6p). The security is provided using DTLS or EDHOC. As the		description "A list of attributes that MUST be in the CSR";
	pledge has only a link-local address, and the Registrar is not co-		}
	located on the same layer-2 as the pledge, the traffic must be
	relayed through the Join Assistant.
	To do this the Registrar needs to configure a Link Local address on a		leaf certificaterequest {
	virtual inteface which is the same as the PTEPA derived address.		type binary;
			description "A PKIX format Certificate Request";
			}
	The Registrar then sends it's traffic (UDP packets with CoAPS		leaf certificate {
	inside), inside of an IPIP header to the Join Assistant. The outer		type binary;
	IP header is from the Registrar to the PTEPA. The inner IP is from		description "The LDevID certificate";
	the link local address configured above, and the destination is the		} } }
	Link Local address of the pledge.
	The Registrar knows the IJALL by taking the IID from the connection		3.1. Description of Pledge States in Join Process
	address above, and knows the Link Local of the pledge from the IID in
	the objective message.
	The Join Assistant, upon receipt of the IPIP traffic from the		TBD
	Registar on it's PTEPA, then decapsulates it and forwards it on the
	appropriate. (This is identical code to decapsulation of IPIP
	headers as specified in [I-D.ietf-roll-useofrplinfo].
	The Join Assistant, upon receiving traffic from the pledge to the		4. Definition of managed objects for zero-touch bootstrap
	IJALL, it encapsulates it into an IPIP header, setting the source of
	this outer header to the PTEPA, and the destination being the
	Registrar.
	The Join Assistant can do this for as many pledges as the Registrar		The following is relevant YANG for use in the bootstrap protocol.
	decides to communicate with, without using any additional per-pledge		The objects identified are identical in format to the named objects
	state other than the obligatory Neighbor Cache Entries needed to		from [I-D.ietf-anima-bootstrapping-keyinfra].
	translate L3 addresses to L2 addresses.
	4. Privacy Considerations		5. Privacy Considerations
	[I-D.ietf-6lo-privacy-considerations] details a number of privacy		[I-D.ietf-6lo-privacy-considerations] details a number of privacy
	considerations important in Resource Constrained nodes. There are		considerations important in Resource Constrained nodes. There are
	two networks and three sets of constrained nodes to consider. They		two networks and three sets of constrained nodes to consider. They
	are: 1. the production nodes on the production network. 2. the new		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.		pledges, which have yet to enroll, and which are on a join network.
	3. the production nodes which are also acting as proxy nodes.		3. the production nodes which are also acting as proxy nodes.
	4.1. Privacy Considerations for Production network		5.1. Privacy Considerations for Production network
	The details of this are out of scope for this document.		The details of this are out of scope for this document.
	4.2. Privacy Considerations for New Pledges		5.2. Privacy Considerations for New Pledges
	New Pledges do not yet receive Router Advertisements with PIO		New Pledges do not yet receive Router Advertisements with PIO
	options, and so configure link-local addresses only based upon		options, and so configure link-local addresses only based upon
	layer-2 addresses using the normal SLAAC mechanisms described in		layer-2 addresses using the normal SLAAC mechanisms described in
	[RFC4191].		[RFC4191].
	These link-local addresses are visible to any on-link eavesdropper		These link-local addresses are visible to any on-link eavesdropper
	(who is synchronized to the same Join Assistant), so regardless of		(who is synchronized to the same Join Assistant), so regardless of
	what is chosen they can be seen. This link-layer traffic is		what is chosen they can be seen. This link-layer traffic is
	encapsulated by the Join Assistant into IPIP packets and carried to		encapsulated by the Join Assistant into IPIP packets and carried to
	skipping to change at page 16, line 39 ¶		skipping to change at page 12, line 10 ¶
	is sent. Even when TLS1.3 is used, an active attacker could collect		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		the information by simply connecting to the device; it would not have
	to successful complete the negotiation either, or even attempt to		to successful complete the negotiation either, or even attempt to
	Man-In-The-Middle the device.		Man-In-The-Middle the device.
	There is, at the same time, significant value in avoiding a link-		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		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		significant advantage to the operator being able to see what the
	vendor of the new device is.		vendor of the new device is.
	4.2.1. EUI-64 derived address for join time IID		5.2.1. EUI-64 derived address for join time IID
	It is therefore suggested that the IID used in the link-local address		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		used during the join process be a vendor assigned EUI-64. After the
	join process has concluded, the device SHOULD be assigned a unique		join process has concluded, the device SHOULD be assigned a unique
	randomly generated long address, and a unique short address (not		randomly generated long address, and a unique short address (not
	based upon the vendor EUI-64) for use at link-layer. At that point,		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.		all layer-3 content is encrypted by the layer-2 key.
	4.3. Privacy Considerations for Join Assistant		5.3. Privacy Considerations for Join Assistant
	5. Security Considerations
	6. IANA Considerations		6. Security Considerations
			7. IANA Considerations
	This document allocates one value from the subregistry "Address		This document allocates one value from the subregistry "Address
	Registration Option Status Values": ND_NS_JOIN_DECLINED Join		Registration Option Status Values": ND_NS_JOIN_DECLINED Join
	Assistant, JOIN DECLINED (TBD-AA)		Assistant, JOIN DECLINED (TBD-AA)
	7. Protocol Definition		8. Protocol Definition
	8. Acknwoledgements		9. Acknwoledgements
	Kristofer Pister helped with many non-IETF references.		Kristofer Pister helped with many non-IETF references.
	9. References		10. References
	9.1. Normative References		10.1. Normative References
	[cullenCiscoPhoneDeploy]		[cullenCiscoPhoneDeploy]
	Jennings, C., "Transitive Trust Enrollment for Constrained		Jennings, C., "Transitive Trust Enrollment for Constrained
	Devices", 2012, <http://www.lix.polytechnique.fr/hipercom/		Devices", 2012, <http://www.lix.polytechnique.fr/hipercom/
	SmartObjectSecurity/papers/CullenJennings.pdf>.		SmartObjectSecurity/papers/CullenJennings.pdf>.
	[I-D.ietf-6lo-privacy-considerations]		[I-D.ietf-6lo-privacy-considerations]
	Thaler, D., "Privacy Considerations for IPv6 Adaptation		Thaler, D., "Privacy Considerations for IPv6 Adaptation
	Layer Mechanisms", draft-ietf-6lo-privacy-		Layer Mechanisms", draft-ietf-6lo-privacy-
	considerations-04 (work in progress), October 2016.		considerations-04 (work in progress), October 2016.
	[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-21 (work
	progress), November 2016.		in progress), 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]		[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-04 (work in progress), October 2016.
	[I-D.ietf-anima-grasp]		[I-D.ietf-anima-grasp]
	Bormann, C., Carpenter, B., and B. Liu, "A Generic		Bormann, C., Carpenter, B., and B. Liu, "A Generic
	Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-		Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
	grasp-08 (work in progress), October 2016.		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]		[I-D.ietf-netconf-zerotouch]
	Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning		Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning
	for NETCONF or RESTCONF based Management", draft-ietf-		for NETCONF or RESTCONF based Management", draft-ietf-
	netconf-zerotouch-11 (work in progress), October 2016.		netconf-zerotouch-12 (work in progress), January 2017.
	[I-D.richardson-6lo-ra-in-ie]		[I-D.richardson-6tisch-join-enhanced-beacon]
	Richardson, M., "802.15.4 Informational Element		Richardson, M., "802.15.4 Informational Element
	encapsulation of ICMPv6 Router Advertisements", draft-		encapsulation of 6tisch Join Information", draft-
	richardson-6lo-ra-in-ie-00 (work in progress), October		richardson-6tisch-join-enhanced-beacon-00 (work in
	2016.		progress), 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]		[I-D.richardson-anima-6join-discovery]
	Richardson, M., "GRASP discovery of Registrar by Join		Richardson, M., "GRASP discovery of Registrar by Join
	Assistant", draft-richardson-anima-6join-discovery-00		Assistant", draft-richardson-anima-6join-discovery-00
	(work in progress), October 2016.		(work in progress), October 2016.
	[iec62591]		[iec62591]
	IEC, ., "62591:2016 Industrial networks - Wireless		IEC, ., "62591:2016 Industrial networks - Wireless
	communication network and communication profiles -		communication network and communication profiles -
	WirelessHART", 2016, <https://webstore.iec.ch/		WirelessHART", 2016, <https://webstore.iec.ch/
	skipping to change at page 19, line 5 ¶		skipping to change at page 15, line 5 ¶
	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>.
	[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.		[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
	Bormann, "Neighbor Discovery Optimization for IPv6 over		Bormann, "Neighbor Discovery Optimization for IPv6 over
	Low-Power Wireless Personal Area Networks (6LoWPANs)",		Low-Power Wireless Personal Area Networks (6LoWPANs)",
	RFC 6775, DOI 10.17487/RFC6775, November 2012,		RFC 6775, DOI 10.17487/RFC6775, November 2012,
	<http://www.rfc-editor.org/info/rfc6775>.		<http://www.rfc-editor.org/info/rfc6775>.
			[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		[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
	Interface Identifiers with IPv6 Stateless Address		Interface Identifiers with IPv6 Stateless Address
	Autoconfiguration (SLAAC)", RFC 7217,		Autoconfiguration (SLAAC)", RFC 7217,
	DOI 10.17487/RFC7217, April 2014,		DOI 10.17487/RFC7217, April 2014,
	<http://www.rfc-editor.org/info/rfc7217>.		<http://www.rfc-editor.org/info/rfc7217>.
	[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for		[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
	Constrained-Node Networks", RFC 7228,		Constrained-Node Networks", RFC 7228,
	DOI 10.17487/RFC7228, May 2014,		DOI 10.17487/RFC7228, May 2014,
	<http://www.rfc-editor.org/info/rfc7228>.		<http://www.rfc-editor.org/info/rfc7228>.
	9.2. Informative References		[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]		[duckling]
	Stajano, F. and R. Anderson, "The resurrecting duckling:		Stajano, F. and R. Anderson, "The resurrecting duckling:
	security issues for ad-hoc wireless networks", 1999,		security issues for ad-hoc wireless networks", 1999,
	<https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-		<https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-
	duckling.pdf>.		duckling.pdf>.
	[I-D.ietf-ace-actors]		[I-D.ietf-ace-actors]
	Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An		Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An
	architecture for authorization in constrained		architecture for authorization in constrained
	skipping to change at page 20, line 20 ¶		skipping to change at page 16, line 27 ¶
	[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>.
	[RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power		[RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power
	and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731,		and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731,
	February 2016, <http://www.rfc-editor.org/info/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		Appendix A. appendix
	insert appendix here		insert appendix here
	Author's Address		Author's Address
	Michael Richardson		Michael Richardson
	Sandelman Software Works		Sandelman Software Works
	Email: mcr+ietf@sandelman.ca		Email: mcr+ietf@sandelman.ca
End of changes. 84 change blocks.
	473 lines changed or deleted		292 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/