< draft-ietf-dice-profile-10.txt   draft-ietf-dice-profile-11.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: September 9, 2015 Alcatel-Lucent Expires: November 28, 2015 Alcatel-Lucent
March 8, 2015 May 27, 2015
A TLS/DTLS Profile for the Internet of Things A TLS/DTLS Profile for the Internet of Things
draft-ietf-dice-profile-10.txt draft-ietf-dice-profile-11.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 sensor or the use of a constrained device that collects data via sensor 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 September 9, 2015. This Internet-Draft will expire on November 28, 2015.
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 28 skipping to change at page 2, line 28
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. TLS/DTLS Protocol Overview . . . . . . . . . . . . . . . . . 4 3. TLS/DTLS Protocol Overview . . . . . . . . . . . . . . . . . 4
4. Communication Models . . . . . . . . . . . . . . . . . . . . 5 4. Communication Models . . . . . . . . . . . . . . . . . . . . 5
4.1. Constrained TLS/DTLS Clients . . . . . . . . . . . . . . 6 4.1. Constrained TLS/DTLS Clients . . . . . . . . . . . . . . 6
4.2. Constrained TLS/DTLS Servers . . . . . . . . . . . . . . 13 4.2. Constrained TLS/DTLS Servers . . . . . . . . . . . . . . 13
5. The Ciphersuite Concept . . . . . . . . . . . . . . . . . . . 18 5. The Ciphersuite Concept . . . . . . . . . . . . . . . . . . . 18
6. Credential Types . . . . . . . . . . . . . . . . . . . . . . 19 6. Credential Types . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Pre-Shared Secret . . . . . . . . . . . . . . . . . . . . 19 6.1. Pre-Shared Secret . . . . . . . . . . . . . . . . . . . . 19
6.2. Raw Public Key . . . . . . . . . . . . . . . . . . . . . 21 6.2. Raw Public Key . . . . . . . . . . . . . . . . . . . . . 21
6.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 23 6.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 23
7. Signature Algorithm Extension . . . . . . . . . . . . . . . . 27 7. Signature Algorithm Extension . . . . . . . . . . . . . . . . 29
8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 28 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 29
9. Session Resumption . . . . . . . . . . . . . . . . . . . . . 29 9. Session Resumption . . . . . . . . . . . . . . . . . . . . . 30
10. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 31
11. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 30 11. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 32
12. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 31 12. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 32
13. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 33 13. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 34
14. Random Number Generation . . . . . . . . . . . . . . . . . . 34 14. Random Number Generation . . . . . . . . . . . . . . . . . . 35
15. Truncated MAC and Encrypt-then-MAC Extension . . . . . . . . 35 15. Truncated MAC and Encrypt-then-MAC Extension . . . . . . . . 36
16. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 35 16. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 37
17. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 36 17. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 37
18. Session Hash . . . . . . . . . . . . . . . . . . . . . . . . 36 18. Session Hash . . . . . . . . . . . . . . . . . . . . . . . . 37
19. Re-Negotiation Attacks . . . . . . . . . . . . . . . . . . . 36 19. Re-Negotiation Attacks . . . . . . . . . . . . . . . . . . . 38
20. Downgrading Attacks . . . . . . . . . . . . . . . . . . . . . 37 20. Downgrading Attacks . . . . . . . . . . . . . . . . . . . . . 38
21. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 38 21. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 39
22. Key Length Recommendations . . . . . . . . . . . . . . . . . 39 22. Key Length Recommendations . . . . . . . . . . . . . . . . . 40
23. False Start . . . . . . . . . . . . . . . . . . . . . . . . . 39 23. False Start . . . . . . . . . . . . . . . . . . . . . . . . . 41
24. Privacy Considerations . . . . . . . . . . . . . . . . . . . 40 24. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42
25. Security Considerations . . . . . . . . . . . . . . . . . . . 41 25. Security Considerations . . . . . . . . . . . . . . . . . . . 42
26. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 26. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
28. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 28. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
28.1. Normative References . . . . . . . . . . . . . . . . . . 42 28.1. Normative References . . . . . . . . . . . . . . . . . . 43
28.2. Informative References . . . . . . . . . . . . . . . . . 43 28.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A. Conveying DTLS over SMS . . . . . . . . . . . . . . 49 Appendix A. Conveying DTLS over SMS . . . . . . . . . . . . . . 50
A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 49 A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 50
A.2. Message Segmentation and Re-Assembly . . . . . . . . . . 50 A.2. Message Segmentation and Re-Assembly . . . . . . . . . . 51
A.3. Multiplexing Security Associations . . . . . . . . . . . 50 A.3. Multiplexing Security Associations . . . . . . . . . . . 52
A.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 51 A.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 53
Appendix B. DTLS Record Layer Per-Packet Overhead . . . . . . . 52 Appendix B. DTLS Record Layer Per-Packet Overhead . . . . . . . 53
Appendix C. DTLS Fragmentation . . . . . . . . . . . . . . . . . 53 Appendix C. DTLS Fragmentation . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
An engineer developing an Internet of Things (IoT) device needs to An engineer developing an Internet of Things (IoT) device needs to
investigate the security threats and decide about the security investigate the security threats and decide about the security
services that can be used to mitigate these threats. services that can be used to mitigate these threats.
Enabling IoT devices to exchange data often requires authentication Enabling IoT devices to exchange data often requires authentication
of the two endpoints and the ability to provide integrity- and of the two endpoints and the ability to provide integrity- and
confidentiality-protection of exchanged data. While these security confidentiality-protection of exchanged data. While these security
skipping to change at page 11, line 47 skipping to change at page 11, line 47
a GET message exchange. The already established DTLS record layer a GET message exchange. The already established DTLS record layer
can be used to secure the message exchange. can be used to secure the message exchange.
Resource Resource
Sensor Directory Sensor Directory
------ --------- ------ ---------
+--- +---
| |
| ClientHello --------> | ClientHello -------->
| client_certificate_type | #client_certificate_type#
F| server_certificate_type F| #server_certificate_type#
U| U|
L| <------- HelloVerifyRequest L| <------- HelloVerifyRequest
L| L|
| ClientHello --------> | ClientHello -------->
D| client_certificate_type D| #client_certificate_type#
T| server_certificate_type T| #server_certificate_type#
L| L|
S| ServerHello S| ServerHello
| client_certificate_type | #client_certificate_type#
H| server_certificate_type H| #server_certificate_type#
A| Certificate A| Certificate
N| ServerKeyExchange N| ServerKeyExchange
D| CertificateRequest D| CertificateRequest
S| <-------- ServerHelloDone S| <-------- ServerHelloDone
H| H|
A| Certificate A| Certificate
K| ClientKeyExchange K| ClientKeyExchange
E| CertificateVerify E| CertificateVerify
| [ChangeCipherSpec] | [ChangeCipherSpec]
| Finished --------> | Finished -------->
skipping to change at page 13, line 8 skipping to change at page 13, line 8
C| \ R C| \ R
O| Req: GET coaps://sensor.example.com/temp \ O O| Req: GET coaps://sensor.example.com/temp \ O
A| <-------- \ T A| <-------- \ T
P| \ E P| \ E
| Res: 2.05 Content \ C | Res: 2.05 Content \ C
G| Payload: \ T G| Payload: \ T
E| 25.5 --------> \ E E| 25.5 --------> \ E
T| \ D T| \ D
+--- ///+ +--- ///+
Note: Extensions marked with '#' were introduced with
RFC 7250.
Figure 4: DTLS/CoAP exchange using Resource Directory. Figure 4: DTLS/CoAP exchange using Resource Directory.
4.2. Constrained TLS/DTLS Servers 4.2. Constrained TLS/DTLS Servers
Section 4.1 illustrates a deployment model where the TLS/DTLS client Section 4.1 illustrates a deployment model where the TLS/DTLS client
is constrained and efforts need to be taken to improve memory is constrained and efforts need to be taken to improve memory
utilization, bandwidth consumption, reduce performance impacts, etc. utilization, bandwidth consumption, reduce performance impacts, etc.
In this section, we assume a scenario where constrained devices run In this section, we assume a scenario where constrained devices run
TLS/ DTLS servers to secure access to application layer services TLS/ DTLS servers to secure access to application layer services
running on top of CoAP, HTTP or other protocols. Figure 5 running on top of CoAP, HTTP or other protocols. Figure 5
skipping to change at page 15, line 10 skipping to change at page 15, line 10
capabilities. While the requirements for the TLS/DTLS protocol capabilities. While the requirements for the TLS/DTLS protocol
profile change only slightly when run on a constrained server (in profile change only slightly when run on a constrained server (in
comparison to running it on a constrained client) several other eco- comparison to running it on a constrained client) several other eco-
system factor will impact deployment. system factor will impact deployment.
There are several challenges that need to be addressed: There are several challenges that need to be addressed:
Discovery and Reachability: Discovery and Reachability:
A client must first and foremost discover the server before A client must first and foremost discover the server before
initiating a connection to it. Once it as been discovered, initiating a connection to it. Once it has been discovered,
reachability to the device needs to be maintained. reachability to the device needs to be maintained.
In CoAP the discovery of resources offered by servers is In CoAP the discovery of resources offered by servers is
accomplished by sending a unicast or multicast CoAP GET to a well- accomplished by sending a unicast or multicast CoAP GET to a well-
known URI. The CORE Link format specification [RFC6690] describes known URI. The CORE Link format specification [RFC6690] describes
the use case (see Section 1.2.1), and reserves the URI (see the use case (see Section 1.2.1), and reserves the URI (see
Section 7.1). Section 7 of the CoAP specification [RFC7252] Section 7.1). Section 7 of the CoAP specification [RFC7252]
describes the discovery procedure. [RFC7390] describes use case describes the discovery procedure. [RFC7390] describes use case
for discovering CoAP servers using multicast (see Section 3.3), for discovering CoAP servers using multicast (see Section 3.3),
and specifies the protocol processing rules for CoAP group and specifies the protocol processing rules for CoAP group
skipping to change at page 19, line 26 skipping to change at page 19, line 26
the TLS pseudo random function (PRF) used in earlier versions of TLS the TLS pseudo random function (PRF) used in earlier versions of TLS
with cipher-suite-specified PRFs. For this reason authors of more with cipher-suite-specified PRFs. For this reason authors of more
recent TLS 1.2 ciphersuite specifications explicitly indicate the MAC recent TLS 1.2 ciphersuite specifications explicitly indicate the MAC
algorithm and the hash functions used with the TLS PRF. algorithm and the hash functions used with the TLS PRF.
6. Credential Types 6. Credential Types
The mandatory-to-implement functionality will depend on the The mandatory-to-implement functionality will depend on the
credential type used with IoT devices. The sub-sections below credential type used with IoT devices. The sub-sections below
describe the implications of three different credential types, namely describe the implications of three different credential types, namely
pre-shared secrets, raw public keys, and certificates. When using pre-shared secrets, raw public keys, and certificates.
pre-shared key, a critical consideration is how to assure the
randomness of these secrets. The best practice is to ensure that any
pre-shared key contains as much randomness as possible. Deriving a
shared secret from a password, name, or other low-entropy source is
not secure. A low-entropy secret, or password, is subject to
dictionary attacks.
6.1. Pre-Shared Secret 6.1. Pre-Shared Secret
The use of pre-shared secrets is one of the most basic techniques for The use of pre-shared secrets is one of the most basic techniques for
TLS/DTLS since it is both computational efficient and bandwidth TLS/DTLS since it is both computational efficient and bandwidth
conserving. Pre-shared secret based authentication was introduced to conserving. Pre-shared secret based authentication was introduced to
TLS with RFC 4279 [RFC4279]. The exchange shown in Figure 7 TLS with RFC 4279 [RFC4279]. When using a pre-shared secret, a
illustrates the DTLS exchange including the cookie exchange. While critical consideration is how to assure the randomness of these
the server is not required to initiate a cookie exchange with every secrets. The best practice is to ensure that any pre-shared key
handshake, the client is required to implement and to react on it contains as much randomness as possible. Deriving a shared secret
when challenged. The cookie exchange allows the server to react to from a password, name, or other low-entropy source is not secure. A
flooding attacks. low-entropy secret, or password, is subject to dictionary attacks.
The exchange shown in Figure 7 illustrates the DTLS exchange
including the cookie exchange. While the server is not required to
initiate a cookie exchange with every handshake, the client is
required to implement and to react on it when challenged. The cookie
exchange allows the server to react to flooding attacks.
Client Server Client Server
------ ------ ------ ------
ClientHello --------> ClientHello -------->
<-------- HelloVerifyRequest <-------- HelloVerifyRequest
(contains cookie) (contains cookie)
ClientHello --------> ClientHello -------->
(with cookie) (with cookie)
skipping to change at page 20, line 31 skipping to change at page 20, line 31
<-------- Finished <-------- Finished
Application Data <-------> Application Data Application Data <-------> Application Data
Legend: Legend:
* indicates an optional message payload * indicates an optional message payload
Figure 7: DTLS PSK Authentication including the Cookie Exchange. Figure 7: DTLS PSK Authentication including the Cookie Exchange.
[RFC4279] does not mandate the use of any particular type of client Note that [RFC4279] used the term PSK identity to refer to the
identity and the client and server have to agree on the identities identifier used to refer to the appropriate secret. While
and keys to be used. The mandated encoding of identities in 'identifier' would be more appropriate in this context we re-use the
Section 5.1 of RFC 4279 aims to improve interoperability for those terminology defined in RFC 4279 to avoid confusion. RFC 4279 does
cases where the identity is configured by a person using some not mandate the use of any particular type of PSK identity and the
management interface. However, many IoT devices do not have a user client and server have to agree on the identities and keys to be
interface and most of their credentials are bound to the device used. The UTF-8 encoding of identities described in Section 5.1 of
rather than the user. Furthermore, credentials are often provisioned RFC 4279 aims to improve interoperability for those cases where the
into trusted hardware modules or in the firmware by developers. As identity is configured by a human using some management interface
such, the encoding considerations are not applicable to this usage provided by a Web browser. However, many IoT devices do not have a
user interface and most of their credentials are bound to the device
rather than to the user. Furthermore, credentials are often
provisioned into hardware modules or into the firmware by developers.
As such, the encoding considerations are not applicable to this usage
environment. For use with this profile the PSK identities SHOULD NOT environment. For use with this profile the PSK identities SHOULD NOT
assume a structured format (as domain names, Distinguished Names, or assume a structured format (such as domain names, Distinguished
IP addresses have) and a bit-by-bit comparison operation can then be Names, or IP addresses) and a bit-by-bit comparison operation MUST be
used by the server-side infrastructure. used by the server for any operation related to the PSK identity.
The client indicates which key it uses by including a "PSK identity" Protocol-wise the client indicates which key it uses by including a
in the ClientKeyExchange message. As described in Section 4 clients "PSK identity" in the ClientKeyExchange message. As described in
may have multiple pre-shared keys with a single server, for example Section 4 clients may have multiple pre-shared keys with a single
in a hosting context. The TLS Server Name Indication (SNI) extension server, for example in a hosting context. The TLS Server Name
allows the client to convey the name of the server it is contacting, Indication (SNI) extension allows the client to convey the name of
which is relevant for hosting environments. A server implementation the server it is contacting. A server implementation needs to guide
needs to guide the selection based on a received SNI value from the the selection based on a received SNI value from the client.
client.
RFC 4279 requires TLS implementations supporting PSK ciphersuites to RFC 4279 requires TLS implementations supporting PSK ciphersuites to
support arbitrary PSK identities up to 128 octets in length, and support arbitrary PSK identities up to 128 octets in length, and
arbitrary PSKs up to 64 octets in length. This is a useful arbitrary PSKs up to 64 octets in length. This is a useful
assumption for TLS stacks used in the desktop and mobile environments assumption for TLS stacks used in the desktop and mobile environments
where management interfaces are used to provision identities and where management interfaces are used to provision identities and
keys. For the IoT environment, keys are distributed as part of keys. Implementations in compliance with this profile MAY use PSK
hardware modules or are embedded into the firmware. Implementations identities up to 128 octets in length, and arbitrary PSKs up to 64
in compliance with this profile MAY use PSK identities up to 128 octets in length. The use of shorter PSK identities is RECOMMENDED.
octets in length, and arbitrary PSKs up to 64 octets in length. The
use of shorter PSK identities is RECOMMENDED.
Constrained Application Protocol (CoAP) [RFC7252] currently specifies Constrained Application Protocol (CoAP) [RFC7252] currently specifies
TLS_PSK_WITH_AES_128_CCM_8 as the mandatory to implement ciphersuite TLS_PSK_WITH_AES_128_CCM_8 as the mandatory to implement ciphersuite
for use with shared secrets. This ciphersuite uses the AES algorithm for use with shared secrets. This ciphersuite uses the AES algorithm
with 128 bit keys and CCM as the mode of operation. The label "_8" with 128 bit keys and CCM as the mode of operation. The label "_8"
indicates that an 8-octet authentication tag is used. This indicates that an 8-octet authentication tag is used. This
ciphersuite makes use of the default TLS 1.2 Pseudorandom Function ciphersuite makes use of the default TLS 1.2 Pseudorandom Function
(PRF), which uses an HMAC with the SHA-256 hash function. Note: (PRF), which uses an HMAC with the SHA-256 hash function. Note:
Starting with TLS 1.2 (and consequently DTLS 1.2) ciphersuites have Starting with TLS 1.2 (and consequently DTLS 1.2) ciphersuites have
to specify the pseudorandom function. RFC 5246 states that 'New to specify the pseudorandom function. RFC 5246 states that 'New
skipping to change at page 23, line 21 skipping to change at page 23, line 21
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this
section. section.
6.3. Certificates 6.3. Certificates
The use of mutual certificate-based authentication is shown in The use of mutual certificate-based authentication is shown in
Figure 9, which makes use of the cached info extension Figure 9, which makes use of the cached info extension
[I-D.ietf-tls-cached-info]. Support of the cached info extension is [I-D.ietf-tls-cached-info]. Support of the cached info extension is
REQUIRED. Caching certificate chains allows the client to reduce the REQUIRED. Caching certificate chains allows the client to reduce the
communication overhead significantly since otherwise the server would communication overhead significantly since otherwise the server would
provide the end entity certificate, and the certificate chain. provide the end entity certificate, and the certificate chain with
Because certificate validation requires that root keys be distributed every full DTLS handshake. Because certificate validation requires
independently, the self-signed certificate that specifies the root that root keys be distributed independently, the self-signed
certificate authority is omitted from the chain. Client certificate that specifies the root certificate authority is omitted
implementations MUST be provisioned with a trust anchor store that from the chain. Client implementations MUST be provisioned with a
contains the root certificates. The use of the Trust Anchor trust anchor store that contains the root certificates. The use of
Management Protocol (TAMP) [RFC5934] is, however, not envisioned. the Trust Anchor Management Protocol (TAMP) [RFC5934] is, however,
Instead IoT devices using this profile MUST use a software update not envisioned. Instead IoT devices using this profile MUST use a
mechanism to populate the trust anchor store. software update mechanism to populate the trust anchor store.
Client Server Client Server
------ ------ ------ ------
ClientHello --------> ClientHello -------->
*cached_info* *cached_info*
ServerHello ServerHello
*cached_info* *cached_info*
Certificate Certificate
skipping to change at page 24, line 32 skipping to change at page 24, line 32
Finished --------> Finished -------->
[ChangeCipherSpec] [ChangeCipherSpec]
<-------- Finished <-------- Finished
Note: Extensions marked with '*' were introduced with Note: Extensions marked with '*' were introduced with
[I-D.ietf-tls-cached-info]. [I-D.ietf-tls-cached-info].
Figure 9: DTLS Mutual Certificate-based Authentication. Figure 9: DTLS Mutual Certificate-based Authentication.
Server certificates MUST contain the fully qualified DNS domain name TLS/DTLS offers a lot of freedom for the use with ECC. This document
restricts the use of ECC ciphersuites to named curves defined in RFC
4492 [RFC4492]. At the time of writing the recommended curve is
secp256r1 and the use of uncompressed points to follow the
recommendation in CoAP. Note that standardization for Curve25519
(for ECDHE) is ongoing (see [I-D.irtf-cfrg-curves]) and support for
this curve will likely be required in the future. To offer elliptic-
curve signatures using the Edwards-curve Digital Signature Algorithm
(EdDSA) standardization work on Ed25519 is also ongoing (see
[I-D.josefsson-eddsa-ed25519]).
A device compliant with the profile in this section MUST implement
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this
section.
6.3.1. Certificates used by Servers
The algorithm for verifying the service identity, as described in RFC
6125 [RFC6125], is essential for ensuring proper security when
certificates are used. As a summary, the algorithm contains the
following steps:
1. The client constructs a list of acceptable reference identifiers
based on the source domain and, optionally, the type of service
to which the client is connecting.
2. The server provides its identifiers in the form of a PKIX
certificate.
3. The client checks each of its reference identifiers against the
presented identifiers for the purpose of finding a match.
4. When checking a reference identifier against a presented
identifier, the client matches the source domain of the
identifiers and, optionally, their application service type.
For various terms used in the algorithm shown above consult RFC 6125.
It is important to highlight that certificate usage without comparing
the reference identifier against the presented identifier obtained
from the certificate breaks security.
It is worth noting that the algorithm description and the text in RFC
6125 assumes that fully qualified DNS domain names are used. If a
server node is provisioned with a fully qualified DNS domain then the
server certificate MUST contain the fully qualified DNS domain name
or "FQDN" as dNSName [RFC5280]. For CoAP, the coaps URI scheme is or "FQDN" as dNSName [RFC5280]. For CoAP, the coaps URI scheme is
described in Section 6.2 of [RFC7252]. This FQDN is stored in the described in Section 6.2 of [RFC7252]. This FQDN is stored in the
SubjectAltName or in the leftmost CN component of subject name, as SubjectAltName or in the leftmost CN component of subject name, as
explained in Section 9.1.3.3 of [RFC7252], and used by the client to explained in Section 9.1.3.3 of [RFC7252], and used by the client to
match it against the FQDN used during the look-up process, as match it against the FQDN used during the look-up process, as
described in [RFC6125]. For other protocols, the appropriate URI described in [RFC6125]. For other protocols, the appropriate URI
scheme specification has to be consulted. scheme specification has to be consulted.
When constrained servers are used, for example in context of locally The following recommendation is provided:
discoverable services as shown in Figure 6, then the rules of client
certificates are applicable since these constrained servers are less 1. Certificates MUST NOT use DNS domain names in the Common Name of
likely to have an FQDN configured. Note that the Service Name certificates and instead use the subjectAltName attribute, as
described in the previous paragraph.
2. Certificates MUST NOT contain domain names with wildcard
characters.
3. Certificates MUST NOT contains multiple names (e.g., more than
one dNSName field).
Note that there will be servers that are not provisioned for use with
DNS domain names, for example, IoT devices that offer resources to
nearby devices in a local area network, as shown in Figure 6. When
such constrained servers are used then the use of certificates as
described in Section 6.3.2 is applicable. Note that the Service Name
Indication (SNI) extension cannot be used in this case since SNI does Indication (SNI) extension cannot be used in this case since SNI does
not offer the ability to convey EUI-64 [EUI64] identifiers. not offer the ability to convey EUI-64 [EUI64] identifiers.
6.3.2. Certificates used by Clients
For client certificates the identifier used in the SubjectAltName or For client certificates the identifier used in the SubjectAltName or
in the leftmost CN component of subject name MUST be an EUI-64, as in the leftmost CN component of subject name MUST be an EUI-64, as
mandated in Section 9.1.3.3 of [RFC7252]. mandated in Section 9.1.3.3 of [RFC7252].
For certificate revocation neither the Online Certificate Status For certificate revocation neither the Online Certificate Status
Protocol (OCSP) nor Certificate Revocation Lists (CRLs) are used. Protocol (OCSP) nor Certificate Revocation Lists (CRLs) are used.
Instead, this profile relies on a software update mechanism to Instead, this profile relies on a software update mechanism to
provision information about revoked certificates. While multiple provision information about revoked certificates. While multiple
OCSP stapling [RFC6961] has recently been introduced as a mechanism OCSP stapling [RFC6961] has recently been introduced as a mechanism
to piggyback OCSP request/responses inside the DTLS/TLS handshake (to to piggyback OCSP request/responses inside the DTLS/TLS handshake (to
avoid the cost of a separate protocol handshake), further avoid the cost of a separate protocol handshake), further
investigations are needed to determine its suitability for the IoT investigations are needed to determine its suitability for the IoT
environment. environment.
Regarding the ciphersuite choice the discussion in Section 6.2 6.3.3. Certificate Content
applies. Further details about X.509 certificates can be found in
Section 9.1.3.3 of [RFC7252]. The TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 All certificate elements listed in Table 1 are mandatory-to-implement
ciphersuite description in Section 6.2 is also applicable to this for client and servers claiming support for certificate-based
section. authentication. No other certificate elements are used by this
specification.
When using certificates, IoT devices MUST provide support for a When using certificates, IoT devices MUST provide support for a
server certificate chain of at least 3 not including the trust anchor server certificate chain of at least 3 not including the trust anchor
and MAY reject connections from servers offering chains longer than and MAY reject connections from servers offering chains longer than
3. IoT devices MAY have client certificate chains of any length. 3. IoT devices MAY have client certificate chains of any length.
Obviously, longer chains require more digital signature verification Obviously, longer chains require more digital signature verification
operations to perform and lead to larger certificate messages in the operations to perform and lead to larger certificate messages in the
TLS handshake. TLS handshake.
Table 1 provides a summary of the elements in a certificate for use Table 1 provides a summary of the elements in a certificate for use
skipping to change at page 26, line 45 skipping to change at page 28, line 10
| | profile: id-kp-serverAuth for server | | | profile: id-kp-serverAuth for server |
| | authentication, id-kp-clientAuth for | | | authentication, id-kp-clientAuth for |
| | client authentication, id-kp-codeSigning | | | client authentication, id-kp-codeSigning |
| | for code signing (for software update | | | for code signing (for software update |
| | mechanism), id-kp-OCSPSigning for future | | | mechanism), id-kp-OCSPSigning for future |
| | OCSP usage in TLS. | | | OCSP usage in TLS. |
+----------------------+--------------------------------------------+ +----------------------+--------------------------------------------+
Table 1: Certificate Content. Table 1: Certificate Content.
All certificate elements listed in Table 1 are mandatory-to- There are various algorithms used to sign digital certificates, such
implement. No other certificate elements are used by this as RSA, the Digital Signature Algorithm (DSA), and the Elliptic Curve
specification. Digital Signature Algorithm (ECDSA). As Table 1 indicates
certificate are signed using ECDSA. This is not only true for the
end-entity certificates but also for all other certificates in the
chain, including CA certificates.
A device compliant with the profile in this section MUST implement Further details about X.509 certificates can be found in
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this Section 9.1.3.3 of [RFC7252].
section.
6.3.1. Client Certificate URLs 6.3.4. Client Certificate URLs
RFC 6066 [RFC6066] allows to avoid sending client-side certificates RFC 6066 [RFC6066] allows to avoid sending client-side certificates
and uses URLs instead. This reduces the over-the-air transmission. and uses URLs instead. This reduces the over-the-air transmission.
Note that the TLS cached info extension does not provide any help Note that the TLS cached info extension does not provide any help
with caching client certificates. with caching client certificates.
TLS/DTLS clients MUST implement support for client certificate URLs TLS/DTLS clients MUST implement support for client certificate URLs
for those environments where client-side certificates are used and for those environments where client-side certificates are used and
the server-side is not constrained. For constrained servers this the server-side is not constrained. For constrained servers this
functionality is NOT RECOMMENDED since it forces the server to functionality is NOT RECOMMENDED since it forces the server to
execute an additional protocol exchange, potentially using a protocol execute an additional protocol exchange, potentially using a protocol
it does not even support. The use of this extension also increases it does not even support. The use of this extension also increases
the risk of a denial of service attack against the constrained server the risk of a denial of service attack against the constrained server
due to the additional workload. due to the additional workload.
6.3.2. Trusted CA Indication 6.3.5. Trusted CA Indication
RFC 6066 [RFC6066] allows clients to indicate what trust anchor they RFC 6066 [RFC6066] allows clients to indicate what trust anchor they
support. With certificate-based authentication a DTLS server conveys support. With certificate-based authentication a DTLS server conveys
its end entity certificate to the client during the DTLS exchange its end entity certificate to the client during the DTLS exchange
provides. Since the server does not necessarily know what trust provides. Since the server does not necessarily know what trust
anchors the client has stored and to facilitate certification path anchors the client has stored and to facilitate certification path
construction as well as path validation, it includes intermediate CA construction as well as path validation, it includes intermediate CA
certs in the certificate payload. certs in the certificate payload.
Today, in most IoT deployments there is a fairly static relationship Today, in most IoT deployments there is a fairly static relationship
skipping to change at page 30, line 7 skipping to change at page 31, line 24
Application Data <-------> Application Data Application Data <-------> Application Data
Figure 10: DTLS Session Resumption. Figure 10: DTLS Session Resumption.
Constrained clients MUST implement session resumption to improve the Constrained clients MUST implement session resumption to improve the
performance of the handshake. This will lead to a reduced number of performance of the handshake. This will lead to a reduced number of
message exchanges, lower computational overhead (since only symmetric message exchanges, lower computational overhead (since only symmetric
cryptography is used during a session resumption exchange), and cryptography is used during a session resumption exchange), and
session resumption requires less bandwidth. session resumption requires less bandwidth.
For cases where the server is constrained (but not the client) the For cases where the server constrained (but not the client) the
client MUST implement RFC 5077 [RFC5077]. RFC 5077 specifies a client MUST implement RFC 5077 [RFC5077]. Note that the constrained
version of TLS/DTLS session resumption that does not require per- server refers to a device that has limitations in terms of RAM and
session state information to be maintained by the constrained server. flash memory, which place restrictions on the amount of TLS/DTLS
This is accomplished by using a ticket-based approach. security state information that can be stored on such a device. RFC
5077 specifies a version of TLS/DTLS session resumption that does not
require per-session state information to be maintained by the
constrained server. This is accomplished by using a ticket-based
approach.
If both the client and the server are constrained devices both If both the client and the server are constrained devices both
devices SHOULD implement RFC 5077 and MUST implement basic session devices SHOULD implement RFC 5077 and MUST implement basic session
resumption. Clients that do not want to use session resumption are resumption. Clients that do not want to use session resumption are
always able to send a ClientHello message with an empty session_id to always able to send a ClientHello message with an empty session_id to
revert to a full handshake. revert to a full handshake.
10. Compression 10. Compression
Section 3.3 of [I-D.ietf-uta-tls-bcp] recommends to disable TLS/DTLS- Section 3.3 of [I-D.ietf-uta-tls-bcp] recommends to disable TLS/DTLS-
skipping to change at page 39, line 4 skipping to change at page 40, line 23
to build an efficient AES-GCM implementations. Another example is to build an efficient AES-GCM implementations. Another example is
to make a special instruction available that increases the speed to make a special instruction available that increases the speed
of speed-up carryless multiplications. of speed-up carryless multiplications.
As a recommendation for developers and product architects we As a recommendation for developers and product architects we
recommend that sufficient headroom is provided to allow an upgrade to recommend that sufficient headroom is provided to allow an upgrade to
a newer cryptographic algorithms over the lifetime of the product. a newer cryptographic algorithms over the lifetime of the product.
As an example, while AES-CCM is recommended thoughout this As an example, while AES-CCM is recommended thoughout this
specification future products might use the ChaCha20 cipher in specification future products might use the ChaCha20 cipher in
combination with the Poly1305 authenticator combination with the Poly1305 authenticator
[I-D.irtf-cfrg-chacha20-poly1305]. The assumption is made that a [I-D.irtf-cfrg-chacha20-poly1305]. The assumption is made that a
robust software update mechanism is offered. robust software update mechanism is offered.
22. Key Length Recommendations 22. Key Length Recommendations
RFC 4492 [RFC4492] gives approximate comparable key sizes for RFC 4492 [RFC4492] gives approximate comparable key sizes for
symmetric- and asymmetric-key cryptosystems based on the best-known symmetric- and asymmetric-key cryptosystems based on the best-known
algorithms for attacking them. While other publications suggest algorithms for attacking them. While other publications suggest
slightly different numbers, such as [Keylength], the approximate slightly different numbers, such as [Keylength], the approximate
relationship still holds true. Figure 11 illustrates the comparable relationship still holds true. Figure 11 illustrates the comparable
key sizes in bits. key sizes in bits.
Symmetric | ECC | DH/DSA/RSA
------------+---------+-------------
80 | 163 | 1024
112 | 233 | 2048
128 | 283 | 3072
192 | 409 | 7680
256 | 571 | 15360
Figure 11: Comparable Key Sizes (in bits) based on RFC 4492.
At the time of writing the key size recommendations for use with TLS- At the time of writing the key size recommendations for use with TLS-
based ciphers found in [I-D.ietf-uta-tls-bcp] recommend DH key based ciphers found in [I-D.ietf-uta-tls-bcp] recommend DH key
lengths of at least 2048 bit, which corresponds to a 112-bit lengths of at least 2048 bit, which corresponds to a 112-bit
symmetric key and a 233 bit ECC key. These recommendations are symmetric key and a 233 bit ECC key. These recommendations are
inline with those from other organizations, such as National roughly inline with those from other organizations, such as the
Institute of Standards and Technology (NIST) or European Network and National Institute of Standards and Technology (NIST) or the European
Information Security Agency (ENISA). The authors of Network and Information Security Agency (ENISA). The authors of
[ENISA-Report2013] add that a 80-bit symmetric key is sufficient for [ENISA-Report2013] add that a 80-bit symmetric key is sufficient for
legacy applications for the coming years, but a 128-bit symmetric key legacy applications for the coming years, but a 128-bit symmetric key
is the minimum requirement for new systems being deployed. The is the minimum requirement for new systems being deployed. The
authors further note that one needs to also take into account the authors further note that one needs to also take into account the
length of time data needs to be kept secure for. The use of 80-bit length of time data needs to be kept secure for. The use of 80-bit
symmetric keys for transactional data may be acceptable for the near symmetric keys for transactional data may be acceptable for the near
future while one has to insist on 128-bit symmetric keys for long future while one has to insist on 128-bit symmetric keys for long
lived data. lived data.
Symmetric | ECC | DH/DSA/RSA Note that the recommendations for 112-bit symmetric keys are chosen
------------+---------+------------- conservatively under the assumption that IoT devices have a long
80 | 163 | 1024 expected lifetime (such as 10+ years) and that this key length
112 | 233 | 2048 recommendation refers to the long-term keys used for device
128 | 283 | 3072 authentication. Keys, which are provisioned dynamically, for the
192 | 409 | 7680 protection of transactional data (such as ephemeral Diffie-Hellman
256 | 571 | 15360 keys used in various TLS/DTLS ciphersuites) may be shorter
considering the sensitivity of the exchanged data.
Figure 11: Comparable Key Sizes (in bits).
23. False Start 23. False Start
A full TLS handshake as specified in [RFC5246] requires two full A full TLS handshake as specified in [RFC5246] requires two full
protocol rounds (four flights) before the handshake is complete and protocol rounds (four flights) before the handshake is complete and
the protocol parties may begin to send application data. the protocol parties may begin to send application data.
An abbreviated handshake (resuming an earlier TLS session) is An abbreviated handshake (resuming an earlier TLS session) is
complete after three flights, thus adding just one round-trip time if complete after three flights, thus adding just one round-trip time if
the client sends application data first. the client sends application data first.
skipping to change at page 41, line 36 skipping to change at page 43, line 14
keying related information. Such a suitable software update keying related information. Such a suitable software update
mechanism is available with the Lightweight Machine-to-Machine mechanism is available with the Lightweight Machine-to-Machine
(LWM2M) protocol published by the Open Mobile Alliance (OMA) [LWM2M]. (LWM2M) protocol published by the Open Mobile Alliance (OMA) [LWM2M].
26. IANA Considerations 26. IANA Considerations
This document includes no request to IANA. This document includes no request to IANA.
27. Acknowledgements 27. Acknowledgements
Thanks to Olaf Bergmann, Paul Bakker, Robert Cragie, Russ Housley, Thanks to Derek Atkins, Olaf Bergmann, Paul Bakker, Robert Cragie,
Rene Hummen, Matthias Kovatsch, Sandeep Kumar, Sye Loong Keoh, Simon Russ Housley, Rene Hummen, Matthias Kovatsch, Sandeep Kumar, Sye
Lemay, Alexey Melnikov, Manuel Pegourie-Gonnard, Akbar Rahman, Eric Loong Keoh, Simon Lemay, Alexey Melnikov, Manuel Pegourie-Gonnard,
Rescorla, Michael Richardson, Ludwig Seitz, Zach Shelby, Michael Akbar Rahman, Eric Rescorla, Michael Richardson, Ludwig Seitz, Zach
StJohns, Rene Struik, and Sean Turner for their helpful comments and Shelby, Michael StJohns, Rene Struik, and Sean Turner for their
discussions that have shaped the document. helpful comments and discussions that have shaped the document.
Big thanks also to Klaus Hartke, who wrote the initial version of Big thanks also to Klaus Hartke, who wrote the initial version of
this document. this document.
Finally, we would like to thank our area director (Stephen Farrell) Finally, we would like to thank our area director (Stephen Farrell)
and our working group chairs (Zach Shelby and Dorothy Gellert) for and our working group chairs (Zach Shelby and Dorothy Gellert) for
their support. their support.
28. References 28. References
skipping to change at page 42, line 22 skipping to change at page 43, line 45
EUI64.html>. EUI64.html>.
[GSM-SMS] ETSI, "3GPP TS 23.040 V7.0.1 (2007-03): 3rd Generation [GSM-SMS] ETSI, "3GPP TS 23.040 V7.0.1 (2007-03): 3rd Generation
Partnership Project; Technical Specification Group Core Partnership Project; Technical Specification Group Core
Network and Terminals; Technical realization of the Short Network and Terminals; Technical realization of the Short
Message Service (SMS) (Release 7)", March 2007. Message Service (SMS) (Release 7)", March 2007.
[I-D.ietf-tls-cached-info] [I-D.ietf-tls-cached-info]
Santesson, S. and H. Tschofenig, "Transport Layer Security Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", draft-ietf-tls- (TLS) Cached Information Extension", draft-ietf-tls-
cached-info-17 (work in progress), November 2014. cached-info-19 (work in progress), March 2015.
[I-D.ietf-tls-session-hash] [I-D.ietf-tls-session-hash]
Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley,
A., and M. Ray, "Transport Layer Security (TLS) Session A., and M. Ray, "Transport Layer Security (TLS) Session
Hash and Extended Master Secret Extension", draft-ietf- Hash and Extended Master Secret Extension", draft-ietf-
tls-session-hash-03 (work in progress), November 2014. tls-session-hash-05 (work in progress), April 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279, December for Transport Layer Security (TLS)", RFC 4279, December
2005. 2005.
[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, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
skipping to change at page 45, line 17 skipping to change at page 46, line 34
Ephemeral Parameters for TLS", draft-ietf-tls-negotiated- Ephemeral Parameters for TLS", draft-ietf-tls-negotiated-
dl-dhe-00 (work in progress), July 2014. dl-dhe-00 (work in progress), July 2014.
[I-D.ietf-tls-prohibiting-rc4] [I-D.ietf-tls-prohibiting-rc4]
Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf- Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf-
tls-prohibiting-rc4-01 (work in progress), October 2014. tls-prohibiting-rc4-01 (work in progress), October 2014.
[I-D.ietf-tls-sslv3-diediedie] [I-D.ietf-tls-sslv3-diediedie]
Barnes, R., Thomson, M., Pironti, A., and A. Langley, Barnes, R., Thomson, M., Pironti, A., and A. Langley,
"Deprecating Secure Sockets Layer Version 3.0", draft- "Deprecating Secure Sockets Layer Version 3.0", draft-
ietf-tls-sslv3-diediedie-02 (work in progress), March ietf-tls-sslv3-diediedie-03 (work in progress), April
2015. 2015.
[I-D.ietf-uta-tls-bcp] [I-D.ietf-uta-tls-bcp]
Sheffer, Y., Holz, R., and P. Saint-Andre, Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", draft- "Recommendations for Secure Use of TLS and DTLS", draft-
ietf-uta-tls-bcp-11 (work in progress), February 2015. ietf-uta-tls-bcp-11 (work in progress), February 2015.
[I-D.irtf-cfrg-chacha20-poly1305] [I-D.irtf-cfrg-chacha20-poly1305]
Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
protocols", draft-irtf-cfrg-chacha20-poly1305-10 (work in protocols", draft-irtf-cfrg-chacha20-poly1305-10 (work in
progress), February 2015. progress), February 2015.
[I-D.irtf-cfrg-curves]
Langley, A., Salz, R., and S. Turner, "Elliptic Curves for
Security", draft-irtf-cfrg-curves-02 (work in progress),
March 2015.
[I-D.josefsson-eddsa-ed25519]
Josefsson, S. and N. Moller, "EdDSA and Ed25519", draft-
josefsson-eddsa-ed25519-03 (work in progress), May 2015.
[I-D.mathewson-no-gmtunixtime] [I-D.mathewson-no-gmtunixtime]
Mathewson, N. and B. Laurie, "Deprecating gmt_unix_time in Mathewson, N. and B. Laurie, "Deprecating gmt_unix_time in
TLS", draft-mathewson-no-gmtunixtime-00 (work in TLS", draft-mathewson-no-gmtunixtime-00 (work in
progress), December 2013. progress), December 2013.
[I-D.schmertmann-dice-ccm-psk-pfs] [I-D.schmertmann-dice-ccm-psk-pfs]
Schmertmann, L. and C. Bormann, "ECDHE-PSK AES-CCM Cipher Schmertmann, L. and C. Bormann, "ECDHE-PSK AES-CCM Cipher
Suites with Forward Secrecy for Transport Layer Security Suites with Forward Secrecy for Transport Layer Security
(TLS)", draft-schmertmann-dice-ccm-psk-pfs-01 (work in (TLS)", draft-schmertmann-dice-ccm-psk-pfs-01 (work in
progress), August 2014. progress), August 2014.
 End of changes. 34 change blocks. 
136 lines changed or deleted 223 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/