< draft-ietf-dice-profile-15.txt		draft-ietf-dice-profile-16.txt >
	dice H. Tschofenig, Ed.		dice H. Tschofenig, Ed.
	Internet-Draft ARM Ltd.		Internet-Draft ARM Ltd.
	Intended status: Standards Track T. Fossati		Intended status: Standards Track T. Fossati
	Expires: March 12, 2016 Alcatel-Lucent		Expires: March 13, 2016 Alcatel-Lucent
	September 9, 2015		September 10, 2015
	TLS/DTLS Profiles for the Internet of Things		TLS/DTLS Profiles for the Internet of Things
	draft-ietf-dice-profile-15.txt		draft-ietf-dice-profile-16.txt
	Abstract		Abstract
	A common design pattern in Internet of Things (IoT) deployments is		A common design pattern in Internet of Things (IoT) deployments is
	the use of a constrained device that collects data via sensors or		the use of a constrained device that collects data via sensors or
	controls actuators for use in home automation, industrial control		controls actuators for use in home automation, industrial control
	systems, smart cities and other IoT deployments.		systems, smart cities and other IoT deployments.
	This document defines a Transport Layer Security (TLS) and Datagram		This document defines a Transport Layer Security (TLS) and Datagram
	TLS (DTLS) 1.2 profile that offers communications security for this		TLS (DTLS) 1.2 profile that offers communications security for this
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 12, 2016.		This Internet-Draft will expire on March 13, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 21 ¶		skipping to change at page 2, line 21 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. TLS and DTLS . . . . . . . . . . . . . . . . . . . . . . 4		3.1. TLS and DTLS . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. Communication Models . . . . . . . . . . . . . . . . . . 5		3.2. Communication Models . . . . . . . . . . . . . . . . . . 6
	3.3. The Ciphersuite Concept . . . . . . . . . . . . . . . . . 18		3.3. The Ciphersuite Concept . . . . . . . . . . . . . . . . . 18
	4. Credential Types . . . . . . . . . . . . . . . . . . . . . . 20		4. Credential Types . . . . . . . . . . . . . . . . . . . . . . 20
	4.1. Pre-Conditions . . . . . . . . . . . . . . . . . . . . . 20		4.1. Pre-Conditions . . . . . . . . . . . . . . . . . . . . . 20
	4.2. Pre-Shared Secret . . . . . . . . . . . . . . . . . . . . 21		4.2. Pre-Shared Secret . . . . . . . . . . . . . . . . . . . . 21
	4.3. Raw Public Key . . . . . . . . . . . . . . . . . . . . . 24		4.3. Raw Public Key . . . . . . . . . . . . . . . . . . . . . 24
	4.4. Certificates . . . . . . . . . . . . . . . . . . . . . . 25		4.4. Certificates . . . . . . . . . . . . . . . . . . . . . . 25
	5. Signature Algorithm Extension . . . . . . . . . . . . . . . . 31		5. Signature Algorithm Extension . . . . . . . . . . . . . . . . 31
	6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 31		6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 31
	7. Session Resumption . . . . . . . . . . . . . . . . . . . . . 32		7. Session Resumption . . . . . . . . . . . . . . . . . . . . . 32
	8. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 33		8. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 33
	skipping to change at page 4, line 7 ¶		skipping to change at page 4, line 7 ¶
	and does not introduce any new TLS/DTLS extension.		and does not introduce any new TLS/DTLS extension.
	The main target audience for this document is the embedded system		The main target audience for this document is the embedded system
	developer configuring and using a TLS/DTLS stack. This document may,		developer configuring and using a TLS/DTLS stack. This document may,
	however, also help those developing or selecting a suitable TLS/DTLS		however, also help those developing or selecting a suitable TLS/DTLS
	stack for an Internet of Things product. If you are familiar with		stack for an Internet of Things product. If you are familiar with
	(D)TLS, then skip ahead to Section 4.		(D)TLS, then skip ahead to Section 4.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in RFC
			2119 [RFC2119].
	This specification refers to TLS as well as DTLS and particularly to		This specification refers to TLS as well as DTLS and particularly to
	version 1.2, which is the most recent version at the time of writing.		version 1.2, which is the most recent version at the time of writing.
	We refer to TLS/DTLS whenever the text is applicable to both versions		We refer to TLS/DTLS whenever the text is applicable to both versions
	of the protocol and to TLS or DTLS when there are differences between		of the protocol and to TLS or DTLS when there are differences between
	the two protocols. Note that TLS 1.3 is being developed but it is		the two protocols. Note that TLS 1.3 is being developed but it is
	not expected that this profile will "just work" due to the		not expected that this profile will "just work" due to the
	significant changes being done to TLS for version 1.3.		significant changes being done to TLS for version 1.3.
	Note that "Client" and "Server" in this document refer to TLS/DTLS		Note that "Client" and "Server" in this document refer to TLS/DTLS
	skipping to change at page 11, line 11 ¶		skipping to change at page 11, line 11 ¶
	a significant amount of flash memory. Note, however, that the		a significant amount of flash memory. Note, however, that the
	credentials used for network access authentication and those used for		credentials used for network access authentication and those used for
	application layer security are very likely different.		application layer security are very likely different.
	3.2.1.1.2. CoAP-based Data Exchange Example		3.2.1.1.2. CoAP-based Data Exchange Example
	When a constrained client uploads sensor data to a server		When a constrained client uploads sensor data to a server
	infrastructure it may use CoAP by pushing the data via a POST message		infrastructure it may use CoAP by pushing the data via a POST message
	to a pre-configured endpoint on the server. In certain circumstances		to a pre-configured endpoint on the server. In certain circumstances
	this might be too limiting and additional functionality is needed, as		this might be too limiting and additional functionality is needed, as
	shown in Figure 4 and Figure 4, where the IoT device itself runs a		shown in Figure 4 and Figure 5, where the IoT device itself runs a
	CoAP server hosting the resource that is made accessible to other		CoAP server hosting the resource that is made accessible to other
	entities. Despite running a CoAP server on the IoT device it is		entities. Despite running a CoAP server on the IoT device it is
	still the DTLS client on the IoT device that initiates the		still the DTLS client on the IoT device that initiates the
	interaction with the non-constrained resource server in our scenario.		interaction with the non-constrained resource server in our scenario.
	Figure 4 shows a sensor starting a DTLS exchange with a resource		Figure 4 shows a sensor starting a DTLS exchange with a resource
	directory and uses CoAP to register available resources in Figure 5.		directory and uses CoAP to register available resources in Figure 5.
	[I-D.ietf-core-resource-directory] defines the resource directory		[I-D.ietf-core-resource-directory] defines the resource directory
	(RD) as a web entity that stores information about web resources and		(RD) as a web entity that stores information about web resources and
	implements Representational State Transfer (REST) interfaces for		implements Representational State Transfer (REST) interfaces for
	skipping to change at page 17, line 38 ¶		skipping to change at page 17, line 38 ¶
	constrained servers may be one option but works only in a small		constrained servers may be one option but works only in a small
	scale, less dynamic environment. For a finer-grained and more		scale, less dynamic environment. For a finer-grained and more
	dynamic access control solution the reader is referred to the		dynamic access control solution the reader is referred to the
	ongoing work in the IETF ACE working group.		ongoing work in the IETF ACE working group.
	Figure 7 shows an example interaction whereby a device, a thermostat		Figure 7 shows an example interaction whereby a device, a thermostat
	in our case, searches in the local network for discoverable resources		in our case, searches in the local network for discoverable resources
	and accesses those. The thermostat starts the procedure using a		and accesses those. The thermostat starts the procedure using a
	link-local discovery message using the "All CoAP Nodes" multicast		link-local discovery message using the "All CoAP Nodes" multicast
	address by utilizing the RFC 6690 [RFC6690] link format. The IPv6		address by utilizing the RFC 6690 [RFC6690] link format. The IPv6
	multicast address used for site-local discovery is FF02::FD. As a		multicast address used for CoAP link-local discovery is FF02::FD. As
	result, a temperature sensor and a fan respond. These responses		a result, a temperature sensor and a fan respond. These responses
	allow the thermostat to subsequently read temperature information		allow the thermostat to subsequently read temperature information
	from the temperature sensor with a CoAP GET request issued to the		from the temperature sensor with a CoAP GET request issued to the
	previously learned endpoint. In this example we assume that		previously learned endpoint. In this example we assume that
	accessing the temperature sensor readings and controlling the fan		accessing the temperature sensor readings and controlling the fan
	requires authentication and authorization of the thermostat and TLS		requires authentication and authorization of the thermostat and TLS
	is used to authenticate both endpoints and to secure the		is used to authenticate both endpoints and to secure the
	communication.		communication.
	Temperature		Temperature
	Thermostat Sensor Fan		Thermostat Sensor Fan
	skipping to change at page 39, line 28 ¶		skipping to change at page 39, line 28 ¶
	are not applicable to this specification and are NOT RECOMMENDED.		are not applicable to this specification and are NOT RECOMMENDED.
	14. Server Name Indication (SNI)		14. Server Name Indication (SNI)
	The Server Name Indication extension defined in [RFC6066] defines a		The Server Name Indication extension defined in [RFC6066] defines a
	mechanism for a client to tell a TLS/DTLS server the name of the		mechanism for a client to tell a TLS/DTLS server the name of the
	server it wants to contact. This is a useful extension for many		server it wants to contact. This is a useful extension for many
	hosting environments where multiple virtual servers are run on single		hosting environments where multiple virtual servers are run on single
	IP address.		IP address.
	This specification RECOMMENDs the implementation of the Server Name		Implementing the Server Name Indication extension is RECOMMENDED
	Indication extension unless it is known that a TLS/DTLS client does		unless it is known that a TLS/DTLS client does not interact with a
	not interact with a server in a hosting environment.		server in a hosting environment.
	15. Maximum Fragment Length Negotiation		15. Maximum Fragment Length Negotiation
	This RFC 6066 extension lowers the maximum fragment length support		This RFC 6066 extension lowers the maximum fragment length support
	needed for the Record Layer from 2^14 bytes to 2^9 bytes.		needed for the Record Layer from 2^14 bytes to 2^9 bytes.
	This is a very useful extension that allows the client to indicate to		This is a very useful extension that allows the client to indicate to
	the server how much maximum memory buffers it uses for incoming		the server how much maximum memory buffers it uses for incoming
	messages. Ultimately, the main benefit of this extension is to allow		messages. Ultimately, the main benefit of this extension is to allow
	client implementations to lower their RAM requirements since the		client implementations to lower their RAM requirements since the
End of changes. 8 change blocks.
	14 lines changed or deleted		15 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/