draft-ietf-6tisch-minimal-security-14.txt		draft-ietf-6tisch-minimal-security-15.txt
	6TiSCH Working Group M. Vucinic, Ed.		6TiSCH Working Group M. Vucinic, Ed.
	Internet-Draft Inria		Internet-Draft Inria
	Intended status: Standards Track J. Simon		Intended status: Standards Track J. Simon
	Expires: June 7, 2020 Analog Devices		Expires: June 12, 2020 Analog Devices
	K. Pister		K. Pister
	University of California Berkeley		University of California Berkeley
	M. Richardson		M. Richardson
	Sandelman Software Works		Sandelman Software Works
	December 05, 2019		December 10, 2019
	Constrained Join Protocol (CoJP) for 6TiSCH		Constrained Join Protocol (CoJP) for 6TiSCH
	draft-ietf-6tisch-minimal-security-14		draft-ietf-6tisch-minimal-security-15
	Abstract		Abstract
	This document describes the minimal framework required for a new		This document describes the minimal framework required for a new
	device, called "pledge", to securely join a 6TiSCH (IPv6 over the		device, called "pledge", to securely join a 6TiSCH (IPv6 over the
	TSCH mode of IEEE 802.15.4e) network. The framework requires that		TSCH mode of IEEE 802.15.4e) network. The framework requires that
	the pledge and the JRC (join registrar/coordinator, a central		the pledge and the JRC (join registrar/coordinator, a central
	entity), share a symmetric key. How this key is provisioned is out		entity), share a symmetric key. How this key is provisioned is out
	of scope of this document. Through a single CoAP (Constrained		of scope of this document. Through a single CoAP (Constrained
	Application Protocol) request-response exchange secured by OSCORE		Application Protocol) request-response exchange secured by OSCORE
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 7, 2020.		This Internet-Draft will expire on June 12, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 4 ¶		skipping to change at page 3, line 4 ¶
	8.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 23		8.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 23
	8.4. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 25		8.4. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 25
	8.5. Recommended Settings . . . . . . . . . . . . . . . . . . 39		8.5. Recommended Settings . . . . . . . . . . . . . . . . . . 39
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 39		9. Security Considerations . . . . . . . . . . . . . . . . . . . 39
	10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 41		10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 41
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
	11.1. CoJP Parameters Registry . . . . . . . . . . . . . . . . 42		11.1. CoJP Parameters Registry . . . . . . . . . . . . . . . . 42
	11.2. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 43		11.2. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 43
	11.3. CoJP Unsupported Configuration Code Registry . . . . . . 44		11.3. CoJP Unsupported Configuration Code Registry . . . . . . 44
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 44		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
	13.1. Normative References . . . . . . . . . . . . . . . . . . 45		13.1. Normative References . . . . . . . . . . . . . . . . . . 45
	13.2. Informative References . . . . . . . . . . . . . . . . . 46		13.2. Informative References . . . . . . . . . . . . . . . . . 46
	Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 48		Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 48
	Appendix B. Lightweight Implementation Option . . . . . . . . . 50		Appendix B. Lightweight Implementation Option . . . . . . . . . 51
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
	1. Introduction		1. Introduction
	This document defines a "secure join" solution for a new device,		This document defines a "secure join" solution for a new device,
	called "pledge", to securely join a 6TiSCH network. The term "secure		called "pledge", to securely join a 6TiSCH network. The term "secure
	join" refers to network access authentication, authorization and		join" refers to network access authentication, authorization and
	parameter distribution, as defined in [I-D.ietf-6tisch-architecture].		parameter distribution, as defined in [I-D.ietf-6tisch-architecture].
	The Constrained Join Protocol (CoJP) defined in this document handles		The Constrained Join Protocol (CoJP) defined in this document handles
	parameter distribution needed for a pledge to become a joined node.		parameter distribution needed for a pledge to become a joined node.
	Mutual authentication during network access and implicit		Mutual authentication during network access and implicit
	skipping to change at page 14, line 16 ¶		skipping to change at page 14, line 16 ¶
	The Join Proxy SHOULD set the DSCP of packets that it produces as		The Join Proxy SHOULD set the DSCP of packets that it produces as
	part of the forwarding process to AF43 code point (See Section 6 of		part of the forwarding process to AF43 code point (See Section 6 of
	[RFC2597]). A Join Proxy that does not require a specific DSCP value		[RFC2597]). A Join Proxy that does not require a specific DSCP value
	on traffic forwarded should set it to zero so that it is compressed		on traffic forwarded should set it to zero so that it is compressed
	out.		out.
	A Scheduling Function (SF) running on 6TiSCH nodes SHOULD NOT		A Scheduling Function (SF) running on 6TiSCH nodes SHOULD NOT
	allocate additional cells as a result of traffic with code point		allocate additional cells as a result of traffic with code point
	AF43. Companion SF documents SHOULD specify how this recommended		AF43. Companion SF documents SHOULD specify how this recommended
	behavior is achieved.		behavior is achieved. One example is the 6TiSCH Minimal Scheduling
			Function [I-D.ietf-6tisch-msf].
	6.1.2. Traffic from JRC to JP		6.1.2. Traffic from JRC to JP
	The JRC SHOULD set the DSCP of join response packets addressed to the		The JRC SHOULD set the DSCP of join response packets addressed to the
	Join Proxy to AF42 code point. AF42 has lower drop probability than		Join Proxy to AF42 code point. AF42 has lower drop probability than
	AF43, giving this traffic priority in buffers over the traffic going		AF43, giving this traffic priority in buffers over the traffic going
	towards the JRC.		towards the JRC.
	The 6LBR links are often the most congested within a DODAG, and from		The 6LBR links are often the most congested within a DODAG, and from
	that point down there is progressively less (or equal) congestion.		that point down there is progressively less (or equal) congestion.
	skipping to change at page 42, line 6 ¶		skipping to change at page 42, line 6 ¶
	The join solution specified in this document relies on the uniqueness		The join solution specified in this document relies on the uniqueness
	of the pledge identifier in the set of all pledge identifiers managed		of the pledge identifier in the set of all pledge identifiers managed
	by a JRC. This identifier is transferred in clear as an OSCORE kid		by a JRC. This identifier is transferred in clear as an OSCORE kid
	context. The use of the globally unique EUI-64 as pledge identifier		context. The use of the globally unique EUI-64 as pledge identifier
	simplifies the management but comes with certain privacy risks. The		simplifies the management but comes with certain privacy risks. The
	implications are thoroughly discussed in [RFC7721] and comprise		implications are thoroughly discussed in [RFC7721] and comprise
	correlation of activities over time, location tracking, address		correlation of activities over time, location tracking, address
	scanning and device-specific vulnerability exploitation. Since the		scanning and device-specific vulnerability exploitation. Since the
	join process occurs rarely compared to the network lifetime, long-		join process occurs rarely compared to the network lifetime, long-
	term threats that arise from using EUI-64 as the pledge identifier		term threats that arise from using EUI-64 as the pledge identifier
	are minimal. In addition, the Join Response message contains a short		are minimal. However, the use of EUI-64 after the join process
	address which is assigned by the JRC to the (6LBR) pledge. The		completes, in the form of a layer-2 or layer-3 address, extends the
	assigned short address SHOULD be uncorrelated with the long-term		aforementioned privacy threats to long term.
	pledge identifier. The short address is encrypted in the response.
	Once the join process completes, the new node uses the short		As an optional mitigation technique, the Join Response message may
	addresses for all further layer 2 (and layer-3) operations. This		contain a short address which is assigned by the JRC to the (6LBR)
	reduces the aforementioned privacy risks as the short layer-2 address		pledge. The assigned short address SHOULD be uncorrelated with the
	(visible even when the network is encrypted) is not traceable between		long-term pledge identifier. The short address is encrypted in the
	locations and does not disclose the manufacturer, as is the case of		response. Once the join process completes, the new node may use the
	EUI-64. However, an eavesdropper with access to the radio medium		short addresses for all further layer-2 (and layer-3) operations.
	during the join process may be able to correlate the assigned short		This reduces the privacy threats as the short layer-2 address
	address with the extended address based on timing information with a		(visible even when the network is encrypted) does not disclose the
	non-negligible probability. This probability decreases with an		manufacturer, as is the case of EUI-64. However, an eavesdropper
	increasing number of pledges joining concurrently.		with access to the radio medium during the join process may be able
			to correlate the assigned short address with the extended address
			based on timing information with a non-negligible probability. This
			probability decreases with an increasing number of pledges joining
			concurrently.
	11. IANA Considerations		11. IANA Considerations
	Note to RFC Editor: Please replace all occurrences of "[[this		Note to RFC Editor: Please replace all occurrences of "[[this
	document]]" with the RFC number of this specification.		document]]" with the RFC number of this specification.
	This document allocates a well-known name under the .arpa name space		This document allocates a well-known name under the .arpa name space
	according to the rules given in [RFC3172]. The name "6tisch.arpa" is		according to the rules given in [RFC3172]. The name "6tisch.arpa" is
	requested. No subdomains are expected, and addition of any such		requested. No subdomains are expected, and addition of any such
	subdomains requires the publication of an IETF standards-track RFC.		subdomains requires the publication of an IETF standards-track RFC.
	skipping to change at page 45, line 35 ¶		skipping to change at page 45, line 38 ¶
	[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,		[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
	"Assured Forwarding PHB Group", RFC 2597,		"Assured Forwarding PHB Group", RFC 2597,
	DOI 10.17487/RFC2597, June 1999,		DOI 10.17487/RFC2597, June 1999,
	<https://www.rfc-editor.org/info/rfc2597>.		<https://www.rfc-editor.org/info/rfc2597>.
	[RFC3172] Huston, G., Ed., "Management Guidelines & Operational		[RFC3172] Huston, G., Ed., "Management Guidelines & Operational
	Requirements for the Address and Routing Parameter Area		Requirements for the Address and Routing Parameter Area
	Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172,		Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172,
	September 2001, <https://www.rfc-editor.org/info/rfc3172>.		September 2001, <https://www.rfc-editor.org/info/rfc3172>.
			[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
			Key Derivation Function (HKDF)", RFC 5869,
			DOI 10.17487/RFC5869, May 2010,
			<https://www.rfc-editor.org/info/rfc5869>.
	[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object		[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,		Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
	October 2013, <https://www.rfc-editor.org/info/rfc7049>.		October 2013, <https://www.rfc-editor.org/info/rfc7049>.
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained		[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252,		Application Protocol (CoAP)", RFC 7252,
	DOI 10.17487/RFC7252, June 2014,		DOI 10.17487/RFC7252, June 2014,
	<https://www.rfc-editor.org/info/rfc7252>.		<https://www.rfc-editor.org/info/rfc7252>.
	[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190,		[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190,
	skipping to change at page 46, line 46 ¶		skipping to change at page 47, line 5 ¶
	Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,		Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
	<https://www.rfc-editor.org/info/rfc8505>.		<https://www.rfc-editor.org/info/rfc8505>.
	[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,		[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
	"Object Security for Constrained RESTful Environments		"Object Security for Constrained RESTful Environments
	(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,		(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
	<https://www.rfc-editor.org/info/rfc8613>.		<https://www.rfc-editor.org/info/rfc8613>.
	13.2. Informative References		13.2. Informative References
			[I-D.ietf-6tisch-msf]
			Chang, T., Vucinic, M., Vilajosana, X., Duquennoy, S., and
			D. Dujovne, "6TiSCH Minimal Scheduling Function (MSF)",
			draft-ietf-6tisch-msf-08 (work in progress), November
			2019.
	[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-15 (work in progress), July 2017.		grasp-15 (work in progress), July 2017.
	[I-D.ietf-cbor-cddl]		[I-D.ietf-cbor-cddl]
	Birkholz, H., Vigano, C., and C. Bormann, "Concise data		Birkholz, H., Vigano, C., and C. Bormann, "Concise data
	definition language (CDDL): a notational convention to		definition language (CDDL): a notational convention to
	express CBOR and JSON data structures", draft-ietf-cbor-		express CBOR and JSON data structures", draft-ietf-cbor-
	cddl-08 (work in progress), March 2019.		cddl-08 (work in progress), March 2019.
	skipping to change at page 47, line 37 ¶		skipping to change at page 48, line 5 ¶
	[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,		[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
	"Transmission of IPv6 Packets over IEEE 802.15.4		"Transmission of IPv6 Packets over IEEE 802.15.4
	Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,		Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
	<https://www.rfc-editor.org/info/rfc4944>.		<https://www.rfc-editor.org/info/rfc4944>.
	[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known		[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
	Uniform Resource Identifiers (URIs)", RFC 5785,		Uniform Resource Identifiers (URIs)", RFC 5785,
	DOI 10.17487/RFC5785, April 2010,		DOI 10.17487/RFC5785, April 2010,
	<https://www.rfc-editor.org/info/rfc5785>.		<https://www.rfc-editor.org/info/rfc5785>.
	[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
	Key Derivation Function (HKDF)", RFC 5869,
	DOI 10.17487/RFC5869, May 2010,
	<https://www.rfc-editor.org/info/rfc5869>.
	[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,		[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
	Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,		Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
	JP., and R. Alexander, "RPL: IPv6 Routing Protocol for		JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
	Low-Power and Lossy Networks", RFC 6550,		Low-Power and Lossy Networks", RFC 6550,
	DOI 10.17487/RFC6550, March 2012,		DOI 10.17487/RFC6550, March 2012,
	<https://www.rfc-editor.org/info/rfc6550>.		<https://www.rfc-editor.org/info/rfc6550>.
	[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,		[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
	DOI 10.17487/RFC6762, February 2013,		DOI 10.17487/RFC6762, February 2013,
	<https://www.rfc-editor.org/info/rfc6762>.		<https://www.rfc-editor.org/info/rfc6762>.
End of changes. 11 change blocks.
	27 lines changed or deleted		38 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/