draft-ietf-lwig-crypto-sensors-00.txt		draft-ietf-lwig-crypto-sensors-01.txt
	Light-Weight Implementation Guidance M. Sethi		Light-Weight Implementation Guidance M. Sethi
	Internet-Draft J. Arkko		Internet-Draft J. Arkko
	Intended status: Informational A. Keranen		Intended status: Informational A. Keranen
	Expires: March 8, 2017 Ericsson		Expires: May 4, 2017 Ericsson
	H. Back		H. Back
	Comptel		Comptel
	September 4, 2016		October 31, 2016
	Practical Considerations and Implementation Experiences in Securing		Practical Considerations and Implementation Experiences in Securing
	Smart Object Networks		Smart Object Networks
	draft-ietf-lwig-crypto-sensors-00		draft-ietf-lwig-crypto-sensors-01
	Abstract		Abstract
	This memo describes challenges associated with securing smart object		This memo describes challenges associated with securing smart object
	devices in constrained implementations and environments. The memo		devices in constrained implementations and environments. The memo
	describes a possible deployment model suitable for these		describes a possible deployment model suitable for these
	environments, discusses the availability of cryptographic libraries		environments, discusses the availability of cryptographic libraries
	for small devices, presents some preliminary experiences in		for small devices, presents some preliminary experiences in
	implementing small devices using those libraries, and discusses		implementing small devices using those libraries, and discusses
	trade-offs involving different types of approaches.		trade-offs involving different types of approaches.
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 March 8, 2017.		This Internet-Draft will expire on May 4, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 17 ¶		skipping to change at page 2, line 17 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 5		4. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 5
	5. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 5		5. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 6
	6. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 8		6. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 8
	7. Code Availability . . . . . . . . . . . . . . . . . . . . . . 8		7. Code Availability . . . . . . . . . . . . . . . . . . . . . . 9
	8. Implementation Experiences . . . . . . . . . . . . . . . . . 10		8. Implementation Experiences . . . . . . . . . . . . . . . . . 11
	9. Example Application . . . . . . . . . . . . . . . . . . . . . 16		9. Example Application . . . . . . . . . . . . . . . . . . . . . 17
	10. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 20		10. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 21
	11. Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 20		11. Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 21
	12. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 21		12. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	13. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 23		13. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	14. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . . . 25		14. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . . . 26
	15. Security Considerations . . . . . . . . . . . . . . . . . . . 25		15. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
	17. Informative references . . . . . . . . . . . . . . . . . . . 26		17. Informative references . . . . . . . . . . . . . . . . . . . 26
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 31		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
	1. Introduction		1. Introduction
	This memo describes challenges associated with securing smart object		This memo describes challenges associated with securing smart object
	devices in constrained implementations and environments (see		devices in constrained implementations and environments. In
	Section 3).		Section 3) we specifically discuss three challenges: the
			implementation difficulties encountered on resource-constrained
			platforms, the problem of provisioning keys and making the choice of
			implementing security at the appropriate layer.
	Secondly, Section 4 discusses a deployment model that the authors are		Secondly, Section 4 discusses a deployment model that the authors are
	considering for constrained environments. The model requires minimal		considering for constrained environments. The model requires minimal
	amount of configuration, and we believe it is a natural fit with the		amount of configuration, and we believe it is a natural fit with the
	typical communication practices smart object networking environments.		typical communication practices in smart object networking
			environments.
	Thirdly, Section 7 discusses the availability of cryptographic		Thirdly, Section 7 discusses the availability of cryptographic
	libraries. Section 8 presents some experiences in implementing small		libraries. Section 8 presents some experiences in implementing
	devices using those libraries, including information about achievable		cryptography on small devices using those libraries, including
	code sizes and speeds on typical hardware.		information about achievable code sizes and speeds on typical
			hardware.
	Finally, Section 10 discusses trade-offs involving different types of		Finally, Section 10 discusses trade-offs involving different types of
	security approaches.		security approaches.
	2. Related Work		2. Related Work
	Constrained Application Protocol (CoAP) [RFC7252] is a light-weight		Constrained Application Protocol (CoAP) [RFC7252] is a light-weight
	protocol designed to be used in machine-to-machine applications such		protocol designed to be used in machine-to-machine applications such
	as smart energy and building automation. Our discussion uses this		as smart energy and building automation. Our discussion uses this
	protocol as an example, but the conclusions may apply to other		protocol as an example, but the conclusions may apply to other
	similar protocols. CoAP base specification [RFC7252] outlines how to		similar protocols. CoAP base specification [RFC7252] outlines how to
	use DTLS [RFC6347] and IKEv2 [RFC7296] for securing the protocol.		use DTLS [RFC6347] and IPsec [RFC4303] for securing the protocol.
	DTLS can be applied with group keys, pairwise shared keys, or with		DTLS can be applied with pairwise shared keys, raw public keys or
	certificates. The security model in all cases is mutual		with certificates. The security model in all cases is mutual
	authentication, so while there is some commonality to HTTP in		authentication, so while there is some commonality to HTTP in
	verifying the server identity, in practice the models are quite		verifying the server identity, in practice the models are quite
	different. The specification says little about how DTLS keys are		different. The CoAP specification says little about how DTLS keys
	managed. The IPsec mode is described with regards to the protocol		are managed. The use of IPsec with CoAP is described with regards to
	requirements, noting that small implementations of IKEv2 exist		the protocol requirements, noting that small implementations of IKEv2
	[RFC7815]. However, the specification is silent on policy and other		exist [RFC7815]. However, the CoAP specification is silent on policy
	aspects that are normally necessary in order to implement		and other aspects that are normally necessary in order to implement
	interoperable use of IPsec in any environment [RFC5406].		interoperable use of IPsec in any environment [RFC5406].
	[RFC6574] gives an overview of the security discussions at the March		[RFC6574] gives an overview of the security discussions at the March
	2011 IAB workshop on smart objects. The workshop recommended that		2011 IAB workshop on smart objects. The workshop recommended that
	additional work is needed in developing suitable credential		additional work is needed in developing suitable credential
	management mechanisms (perhaps something similar to the Bluetooth		management mechanisms (perhaps something similar to the Bluetooth
	pairing mechanism), understanding the implementability of standard		pairing mechanism), understanding the implementability of standard
	security mechanisms in small devices and additional research in the		security mechanisms in small devices and additional research in the
	area of lightweight cryptographic primitives.		area of lightweight cryptographic primitives.
	skipping to change at page 3, line 50 ¶		skipping to change at page 4, line 7 ¶
	[I-D.daniel-6lowpan-security-analysis] makes a comprehensive analysis		[I-D.daniel-6lowpan-security-analysis] makes a comprehensive analysis
	of security issues related to 6LoWPAN networks, but its findings also		of security issues related to 6LoWPAN networks, but its findings also
	apply more generally for all low-powered networks. Some of the		apply more generally for all low-powered networks. Some of the
	issues this document discusses include the need to minimize the		issues this document discusses include the need to minimize the
	number of transmitted bits and simplify implementations, threats in		number of transmitted bits and simplify implementations, threats in
	the smart object networking environments, and the suitability of		the smart object networking environments, and the suitability of
	6LoWPAN security mechanisms, IPsec, and key management protocols for		6LoWPAN security mechanisms, IPsec, and key management protocols for
	implementation in these environments.		implementation in these environments.
	[I-D.garcia-core-security] discusses the overall security problem for		[I-D.irtf-t2trg-iot-seccons] discusses the overall security problem
	Internet of Things devices. It also discusses various solutions,		for Internet of Things devices. It also discusses various solutions,
	including IKEv2/IPsec [RFC7296], TLS/SSL [RFC5246], DTLS [RFC6347],		including IKEv2/IPsec [RFC7296], TLS/SSL [RFC5246], DTLS [RFC6347],
	HIP [RFC7401] [I-D.moskowitz-hip-dex], PANA [RFC5191], and EAP		HIP [RFC7401] [I-D.moskowitz-hip-dex], PANA [RFC5191], and EAP
	[RFC3748]. The draft also discusses various operational scenarios,		[RFC3748]. The draft also discusses various operational scenarios,
	bootstrapping mechanisms, and challenges associated with implementing		bootstrapping mechanisms, and challenges associated with implementing
	security mechanisms in these environments.		security mechanisms in these environments.
	3. Challenges		3. Challenges
	This section discusses three challenges: implementation difficulties,		This section discusses three challenges: implementation difficulties,
	practical provisioning problems, and layering and communication		practical provisioning problems, and layering and communication
	skipping to change at page 5, line 40 ¶		skipping to change at page 5, line 47 ¶
	The basis of the proposed architecture are self-generated secure		The basis of the proposed architecture are self-generated secure
	identities, similar to Cryptographically Generated Addresses (CGAs)		identities, similar to Cryptographically Generated Addresses (CGAs)
	[RFC3972] or Host Identity Tags (HITs) [RFC7401]. That is, we assume		[RFC3972] or Host Identity Tags (HITs) [RFC7401]. That is, we assume
	the following holds:		the following holds:
	I = h(P|O)		I = h(P|O)
	where I is the secure identity of the device, h is a hash function, P		where I is the secure identity of the device, h is a hash function, P
	is the public key from a key pair generated by the device, and O is		is the public key from a key pair generated by the device, and O is
	optional other information.		optional other information. | here denotes the concatenation
			operator.
	5. Provisioning		5. Provisioning
	As provisioning security credentials, shared secrets, and policy		As it is difficult to provision security credentials, shared secrets,
	information is difficult, the provisioning model is based only on the		and policy information, the provisioning model is based only on the
	secure identities. A typical network installation involves physical		secure identities. A typical network installation involves physical
	placement of a number of devices while noting the identities of these		placement of a number of devices while noting the identities of these
	devices. This list of short identifiers can then be fed to a central		devices. This list of short identifiers can then be fed to a central
	server as a list of authorized devices. Secure communications can		server as a list of authorized devices. Secure communications can
	then commence with the devices, at least as far as information from		then commence with the devices, at least as far as information from
	from the devices to the server is concerned, which is what is needed		from the devices to the server is concerned, which is what is needed
	for sensor networks.		for sensor networks.
	The above architecture is a perfect fit for sensor networks where		The above architecture is a perfect fit for sensor networks where
	information flows from large number of devices to small number of		information flows from large number of devices to small number of
	skipping to change at page 9, line 20 ¶		skipping to change at page 9, line 33 ¶
	environment. Note that the results are preliminary, and could easily		environment. Note that the results are preliminary, and could easily
	be affected in any direction by implementation bugs, configuration		be affected in any direction by implementation bugs, configuration
	errors, and other mistakes. Please verify the numbers before relying		errors, and other mistakes. Please verify the numbers before relying
	on them for building something. No significant effort was done to		on them for building something. No significant effort was done to
	optimize ROM memory usage beyond what the libraries provided		optimize ROM memory usage beyond what the libraries provided
	themselves, so those numbers should be taken as upper limits.		themselves, so those numbers should be taken as upper limits.
	Here is the set of libraries we found:		Here is the set of libraries we found:
	o AvrCryptolib [avr-cryptolib]: This library provides a variety of		o AvrCryptolib [avr-cryptolib]: This library provides a variety of
	different symmetric key algorithms such as DES/Triple DES/AES etc.		different symmetric key algorithms such as AES and RSA as an
	and RSA as an asymmetric key algorithm. We stripped down the		asymmetric key algorithm. We stripped down the library to use
	library to use only the required RSA components and used a		only the required RSA components and used a separate SHA-256
	separate SHA-256 implementation from the original AvrCrypto-Lib		implementation from the original AvrCrypto-Lib library
	library [avr-crypto-lib]. Parts of SHA-256 and RSA algorithm		[avr-crypto-lib]. Parts of SHA-256 and RSA algorithm
	implementations were written in AVR-8 bit assembly language to		implementations were written in AVR-8 bit assembly language to
	reduce the size and optimize the performance. The library also		reduce the size and optimize the performance. The library also
	takes advantage of the fact that Arduino boards allow the		takes advantage of the fact that Arduino boards allow the
	programmer to directly address the flash memory to access constant		programmer to directly address the flash memory to access constant
	data which can save the amount of SRAM used during execution.		data which can save the amount of SRAM used during execution.
	o Relic-Toolkit [relic-toolkit]: This library is written entirely in		o Relic-Toolkit [relic-toolkit]: This library is written entirely in
	C and provides a highly flexible and customizable implementation		C and provides a highly flexible and customizable implementation
	of a large variety of cryptographic algorithms. This not only		of a large variety of cryptographic algorithms. This not only
	includes RSA and ECC, but also pairing based asymmetric		includes RSA and ECC, but also pairing based asymmetric
	skipping to change at page 10, line 44 ¶		skipping to change at page 11, line 10 ¶
	original form takes about 50 kB of ROM which is not suitable for		original form takes about 50 kB of ROM which is not suitable for
	our hardware requirements. Moreover, it is intended for 32-bit		our hardware requirements. Moreover, it is intended for 32-bit
	systems and the API includes functions for SSL communication		systems and the API includes functions for SSL communication
	rather than just signing data with private keys.		rather than just signing data with private keys.
	This is by no ways an exhaustive list and there exist other		This is by no ways an exhaustive list and there exist other
	cryptographic libraries targeting resource-constrained devices.		cryptographic libraries targeting resource-constrained devices.
	8. Implementation Experiences		8. Implementation Experiences
			While evaluating the implementation experiences, we were particularly
			interested in the signature generation operation. This was because
			our example application discussed in Section 9 required only the
			signature generation operation on the resource-constrained platforms.
	We have summarized the initial results of RSA private key performance		We have summarized the initial results of RSA private key performance
	using AvrCryptolib in Table 1. All results are from a single run		using AvrCryptolib in Table 1. All results are from a single run
	since repeating the test did not change (or had only minimal impact		since repeating the test did not change (or had only minimal impact
	on) the results. The keys were generated separately and were hard		on) the results. The keys were generated separately and were hard
	coded into the program. All keys were generated with the value of		coded into the program. All keys were generated with the value of
	the public exponent as 3. The performance of signing with private		the public exponent as 3. The performance of signing with private
	key was faster for smaller key lengths as was expected. However the		key was faster for smaller key lengths as was expected. However the
	increase in the execution time was considerable when the key size was		increase in the execution time was considerable when the key size was
	2048 bits. It is important to note that two different sets of		2048 bits. It is important to note that two different sets of
	experiments were performed for each key length. In the first case,		experiments were performed for each key length. In the first case,
	skipping to change at page 26, line 45 ¶		skipping to change at page 27, line 35 ¶
	Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O.		Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O.
	Novo, "Implementing Tiny COAP Sensors", draft-arkko-core-		Novo, "Implementing Tiny COAP Sensors", draft-arkko-core-
	sleepy-sensors-01 (work in progress), July 2011.		sleepy-sensors-01 (work in progress), July 2011.
	[I-D.daniel-6lowpan-security-analysis]		[I-D.daniel-6lowpan-security-analysis]
	Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J.		Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J.
	Laganier, "IPv6 over Low Power WPAN Security Analysis",		Laganier, "IPv6 over Low Power WPAN Security Analysis",
	draft-daniel-6lowpan-security-analysis-05 (work in		draft-daniel-6lowpan-security-analysis-05 (work in
	progress), March 2011.		progress), March 2011.
	[I-D.garcia-core-security]
	Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and
	R. Struik, "Security Considerations in the IP-based
	Internet of Things", draft-garcia-core-security-06 (work
	in progress), September 2013.
	[I-D.ietf-core-resource-directory]		[I-D.ietf-core-resource-directory]
	Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE		Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE
	Resource Directory", draft-ietf-core-resource-directory-08		Resource Directory", draft-ietf-core-resource-directory-08
	(work in progress), July 2016.		(work in progress), July 2016.
	[I-D.irtf-cfrg-eddsa]		[I-D.irtf-cfrg-eddsa]
	Josefsson, S. and I. Liusvaara, "Edwards-curve Digital		Josefsson, S. and I. Liusvaara, "Edwards-curve Digital
	Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-08		Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-08
	(work in progress), August 2016.		(work in progress), August 2016.
			[I-D.irtf-t2trg-iot-seccons]
			Garcia-Morchon, O., Kumar, S., and M. Sethi, "Security
			Considerations in the IP-based Internet of Things", draft-
			irtf-t2trg-iot-seccons-00 (work in progress), October
			2016.
	[I-D.jennings-core-senml]		[I-D.jennings-core-senml]
	Jennings, C., Shelby, Z., Arkko, J., and A. Keranen,		Jennings, C., Shelby, Z., Arkko, J., and A. Keranen,
	"Media Types for Sensor Markup Language (SenML)", draft-		"Media Types for Sensor Markup Language (SenML)", draft-
	jennings-core-senml-06 (work in progress), April 2016.		jennings-core-senml-06 (work in progress), April 2016.
	[I-D.moskowitz-hip-dex]		[I-D.moskowitz-hip-dex]
	Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)",		Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)",
	draft-moskowitz-hip-dex-05 (work in progress), January		draft-moskowitz-hip-dex-05 (work in progress), January
	2016.		2016.
	skipping to change at page 28, line 14 ¶		skipping to change at page 29, line 5 ¶
	[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.		[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
	Levkowetz, Ed., "Extensible Authentication Protocol		Levkowetz, Ed., "Extensible Authentication Protocol
	(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,		(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
	<http://www.rfc-editor.org/info/rfc3748>.		<http://www.rfc-editor.org/info/rfc3748>.
	[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",		[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
	RFC 3972, DOI 10.17487/RFC3972, March 2005,		RFC 3972, DOI 10.17487/RFC3972, March 2005,
	<http://www.rfc-editor.org/info/rfc3972>.		<http://www.rfc-editor.org/info/rfc3972>.
			[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
			RFC 4303, DOI 10.17487/RFC4303, December 2005,
			<http://www.rfc-editor.org/info/rfc4303>.
	[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,		[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
	and A. Yegin, "Protocol for Carrying Authentication for		and A. Yegin, "Protocol for Carrying Authentication for
	Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,		Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
	May 2008, <http://www.rfc-editor.org/info/rfc5191>.		May 2008, <http://www.rfc-editor.org/info/rfc5191>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008,
	<http://www.rfc-editor.org/info/rfc5246>.		<http://www.rfc-editor.org/info/rfc5246>.
End of changes. 20 change blocks.
	46 lines changed or deleted		60 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/