< draft-ietf-dice-profile-02.txt   draft-ietf-dice-profile-03.txt >
dice H. Tschofenig, Ed. dice H. Tschofenig, Ed.
Internet-Draft ARM Ltd. Internet-Draft ARM Ltd.
Intended status: Standards Track July 4, 2014 Intended status: Standards Track July 4, 2014
Expires: January 5, 2015 Expires: January 5, 2015
A Datagram Transport Layer Security (DTLS) 1.2 Profile for the Internet A Datagram Transport Layer Security (DTLS) 1.2 Profile for the Internet
of Things of Things
draft-ietf-dice-profile-02.txt draft-ietf-dice-profile-03.txt
Abstract Abstract
This document defines a DTLS profile that is suitable for Internet of This document defines a DTLS profile that is suitable for Internet of
Things applications and is reasonably implementable on many Things applications and is reasonably implementable on many
constrained devices. constrained devices.
A common design pattern in IoT deployments is the use of a A common design pattern in IoT deployments is the use of a
constrained device (typically providing sensor data) that interacts constrained device (typically providing sensor data) that interacts
with the web infrastructure. This document focuses on this with the web infrastructure. This document focuses on this
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Communication Model . . . . . . . . . . . . . . . . . . . 5 3. The Communication Model . . . . . . . . . . . . . . . . . . . 5
4. The Ciphersuite Concept . . . . . . . . . . . . . . . . . . . 6 4. The Ciphersuite Concept . . . . . . . . . . . . . . . . . . . 6
5. Pre-Shared Secret Authentication with DTLS . . . . . . . . . 8 5. Pre-Shared Secret Authentication with DTLS . . . . . . . . . 8
6. Raw Public Key Use with DTLS . . . . . . . . . . . . . . . . 9 6. Raw Public Key Use with DTLS . . . . . . . . . . . . . . . . 9
7. Certificate Use with DTLS . . . . . . . . . . . . . . . . . . 11 7. Certificate Use with DTLS . . . . . . . . . . . . . . . . . . 11
8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 12 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 12
9. Session Resumption . . . . . . . . . . . . . . . . . . . . . 14 9. Session Resumption . . . . . . . . . . . . . . . . . . . . . 13
10. TLS Compression . . . . . . . . . . . . . . . . . . . . . . . 14 10. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 14 11. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 14
12. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 15
13. Random Number Generation . . . . . . . . . . . . . . . . . . 16 13. Random Number Generation . . . . . . . . . . . . . . . . . . 16
14. Client Certificate URLs . . . . . . . . . . . . . . . . . . . 17 14. Client Certificate URLs . . . . . . . . . . . . . . . . . . . 17
15. Trusted CA Indication . . . . . . . . . . . . . . . . . . . . 17 15. Trusted CA Indication . . . . . . . . . . . . . . . . . . . . 17
16. Truncated MAC Extension . . . . . . . . . . . . . . . . . . . 18 16. Truncated MAC Extension . . . . . . . . . . . . . . . . . . . 17
17. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 18 17. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 18
18. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 18 18. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 18
19. Negotiation and Downgrading Attacks . . . . . . . . . . . . . 18 19. Negotiation and Downgrading Attacks . . . . . . . . . . . . . 18
20. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 20. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
21. Security Considerations . . . . . . . . . . . . . . . . . . . 19 21. Security Considerations . . . . . . . . . . . . . . . . . . . 19
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
24. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 24. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
24.1. Normative References . . . . . . . . . . . . . . . . . . 20 24.1. Normative References . . . . . . . . . . . . . . . . . . 20
24.2. Informative References . . . . . . . . . . . . . . . . . 21 24.2. Informative References . . . . . . . . . . . . . . . . . 21
skipping to change at page 10, line 49 skipping to change at page 10, line 49
Finished --------> Finished -------->
[ChangeCipherSpec] [ChangeCipherSpec]
<-------- Finished <-------- Finished
Figure 3: DTLS Raw Public Key Exchange including the Cookie Exchange. Figure 3: DTLS Raw Public Key Exchange including the Cookie Exchange.
The CoAP recommended ciphersuite for use with this credential type is The CoAP recommended ciphersuite for use with this credential type is
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251]. This elliptic curve TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251]. This elliptic curve
cryptography (ECC) based AES-CCM TLS ciphersuite uses the Elliptic cryptography (ECC) based AES-CCM TLS ciphersuite uses the Elliptic
Curve Diffie Hellman (ECDHE) as the key establishment mechanism and Curve Diffie-Hellman (ECDHE) as the key establishment mechanism and
an Elliptic Curve Digital Signature Algorithm (ECDSA) for an Elliptic Curve Digital Signature Algorithm (ECDSA) for
authentication. This ciphersuite make use of the AEAD capability in authentication. This ciphersuite make use of the AEAD capability in
DTLS 1.2 and utilizes an eight-octet authentication tag. Based on DTLS 1.2 and utilizes an eight-octet authentication tag. The use of
the Diffie-Hellman it provides perfect forward secrecy (PFS). More a Diffie-Hellman key exchange adds perfect forward secrecy (PFS).
details about the PFS can be found in Section 11. More details about PFS can be found in Section 11.
RFC 6090 [RFC6090] provides valuable information for implementing RFC 6090 [RFC6090] provides valuable information for implementing
Elliptic Curve Cryptography algorithms. Elliptic Curve Cryptography algorithms.
Since many IoT devices will either have limited ways to log error or Since many IoT devices will either have limited ways to log error or
no ability at all, any error will lead to implementations attempting no ability at all, any error will lead to implementations attempting
to re-try the exchange. to re-try the exchange.
7. Certificate Use with DTLS 7. Certificate Use with DTLS
skipping to change at page 12, line 40 skipping to change at page 12, line 40
[ChangeCipherSpec] [ChangeCipherSpec]
<-------- Finished <-------- Finished
Figure 4: DTLS Mutual Certificate-based Authentication. Figure 4: DTLS Mutual Certificate-based Authentication.
Regarding the ciphersuite choice the discussion in Section 6 applies. Regarding the ciphersuite choice the discussion in Section 6 applies.
Further details about X.509 certificates can be found in Further details about X.509 certificates can be found in
Section 9.1.3.3 of [RFC7252]. Section 9.1.3.3 of [RFC7252].
QUESTION: What restrictions regarding the depth of the certificate
chain should be made? Is one level enough?
8. Error Handling 8. Error Handling
DTLS uses the Alert protocol to convey error messages and specifies a DTLS uses the Alert protocol to convey error messages and specifies a
longer list of errors. However, not all error messages defined in longer list of errors. However, not all error messages defined in
the TLS specification are applicable to this profile. All error the TLS specification are applicable to this profile. All error
messages marked as RESERVED are only supported for backwards messages marked as RESERVED are only supported for backwards
compatibility with SSL and are therefore not applicable to this compatibility with SSL and are therefore not applicable to this
profile. Those include decryption_failed_RESERVED, profile. Those include decryption_failed_RESERVED,
no_certificate_RESERVE, and export_restriction_RESERVED. no_certificate_RESERVE, and export_restriction_RESERVED.
skipping to change at page 14, line 36 skipping to change at page 14, line 29
Clients MUST implement session resumption to improve the performance Clients MUST implement session resumption to improve the performance
of the handshake (in terms of reduced number of message exchanges, of the handshake (in terms of reduced number of message exchanges,
lower computational overhead, and less bandwidth conserved). lower computational overhead, and less bandwidth conserved).
Since the communication model described in Section 3 does not assume Since the communication model described in Section 3 does not assume
that the server is constrained. RFC 5077 [RFC5077] describing TLS that the server is constrained. RFC 5077 [RFC5077] describing TLS
session resumption without server-side state is not utilized by this session resumption without server-side state is not utilized by this
profile. profile.
10. TLS Compression 10. Compression
[I-D.ietf-uta-tls-bcp] recommends to always disable DTLS-level [I-D.ietf-uta-tls-bcp] recommends to always disable DTLS-level
compression due to attacks. For IoT applications compression at the compression due to attacks. For IoT applications compression at the
DTLS is not needed since application layer protocols are highly DTLS is not needed since application layer protocols are highly
optimized and the compression algorithms at the DTLS layer increase optimized and the compression algorithms at the DTLS layer increase
code size and complexity. code size and complexity.
This DTLS client profile does not include DTLS layer compression. This DTLS client profile does not include DTLS layer compression.
11. Perfect Forward Secrecy 11. Perfect Forward Secrecy
Perfect forward secrecy (PFS) is designed to prevent the compromise Perfect forward secrecy (PFS) is designed to prevent the compromise
of a long-term secret key from affecting the confidentiality of past of a long-term secret key from affecting the confidentiality of past
conversations. The PSK ciphersuite recommended in the CoAP conversations. The PSK ciphersuite recommended in the CoAP
specification [RFC7252] does not offer this property since it does specification [RFC7252] does not offer this property since it does
not utilize a Diffie-Hellman exchange. [I-D.ietf-uta-tls-bcp] on the not utilize a Diffie-Hellman exchange. [I-D.ietf-uta-tls-bcp] on the
other hand recommends using ciphersuites offering this security other hand recommends using ciphersuites offering this security
property and so do the public key-based ciphersuites recommended by property and so do the public key-based ciphersuites recommended by
the CoAP specification. the CoAP specification.
The use of PFS is certainly a tradeoff decision since on one hand the The use of PFS is certainly a trade-off decision since on one hand
compromise of long-term secrets of embedded devices is more likely the compromise of long-term secrets of embedded devices is more
than with many other Internet hosts but on the other hand a Diffie- likely than with many other Internet hosts but on the other hand a
Hellman exchange requires emphemeral key pairs to be generated, which Diffie-Hellman exchange requires ephemeral key pairs to be generated,
can be demanding from a performance point of view. Finally, the which can be demanding from a performance point of view. Finally,
impact of the disclosure of past conversations and the desire to the impact of the disclosure of past conversations and the desire to
increase the cost for pervasive monitoring (see [RFC7258]) has to be increase the cost for pervasive monitoring (see [RFC7258]) has to be
taken into account. taken into account.
Our recommendation is to stick with the ciphersuite suggested in the Our recommendation is to stick with the ciphersuite suggested in the
CoAP specification. New ciphersuites support PFS for pre-shared CoAP specification. New ciphersuites support PFS for pre-shared
secret-based authentication, such as secret-based authentication, such as
[I-D.schmertmann-dice-ccm-psk-pfs], and might be available as a [I-D.schmertmann-dice-ccm-psk-pfs], and might be available as a
standardized ciphersuite in the future. standardized ciphersuite in the future.
12. Keep-Alive 12. Keep-Alive
skipping to change at page 15, line 39 skipping to change at page 15, line 34
perform Path Maximum Transmission Unit (MTU) Discovery. perform Path Maximum Transmission Unit (MTU) Discovery.
A recommendation about the use of RFC 6520 depends on the type of A recommendation about the use of RFC 6520 depends on the type of
message exchange an IoT device performs. There are three types of message exchange an IoT device performs. There are three types of
exchanges that need to be analysed: exchanges that need to be analysed:
Client-Initiated, One-Shot Messages Client-Initiated, One-Shot Messages
This is a common communication pattern where IoT devices upload This is a common communication pattern where IoT devices upload
data to a server on the Internet on an irregular basis. The data to a server on the Internet on an irregular basis. The
communcation may be triggered by specific events, such as opening communication may be triggered by specific events, such as opening
a door. a door.
Since the upload happens on an irregular and unpredicable basis Since the upload happens on an irregular and unpredictable basis
and due to renumbering and Network Address Translation (NAT) a new and due to renumbering and Network Address Translation (NAT) a new
DTLS session or DTLS session resumption can be used. DTLS session or DTLS session resumption can be used.
In this case there is no use for a keep-alive extension for this In this case there is no use for a keep-alive extension for this
scenario. scenario.
Client-Initiated, Regular Data Uploads Client-Initiated, Regular Data Uploads
This is a variation of the previous case whereby data gets This is a variation of the previous case whereby data gets
uploaded on a regular basis, for example, based on frequent uploaded on a regular basis, for example, based on frequent
temperature readings. With such regular exchange it can be temperature readings. With such regular exchange it can be
assumed that the DTLS context is still in kept at the IoT device. assumed that the DTLS context is still in kept at the IoT device.
If neither NAT bindings nor IP address changes occurred then the If neither NAT bindings nor IP address changes occurred then the
DTLS record layer will not notice any changes. For the case where DTLS record layer will not notice any changes. For the case where
IP and port changes happened it is necessary to re-create the DTLS IP and port changes happened it is necessary to re-create the DTLS
record layer using session resumption. record layer using session resumption.
In this scenario there is no use for a keep-alive extension. It In this scenario there is no use for a keep-alive extension. It
skipping to change at page 16, line 44 skipping to change at page 16, line 38
different. different.
For server-initiated messages the heartbeat extension can be For server-initiated messages the heartbeat extension can be
recommended. recommended.
13. Random Number Generation 13. Random Number Generation
The DTLS protocol requires random numbers to be available during the The DTLS protocol requires random numbers to be available during the
protocol run. For example, during the ClientHello and the protocol run. For example, during the ClientHello and the
ServerHello exchange the client and the server exchange random ServerHello exchange the client and the server exchange random
numbers. Also, the use of the Diffie Hellman exchange requires numbers. Also, the use of the Diffie-Hellman exchange requires
random numbers during the key pair generation. Special care has to random numbers during the key pair generation. Special care has to
be paid when generating random numbers in embedded systems as many be paid when generating random numbers in embedded systems as many
entropy sources available on desktop operating systems or mobile entropy sources available on desktop operating systems or mobile
devices might be missing, as described in [Heninger]. Consequently, devices might be missing, as described in [Heninger]. Consequently,
if not enough time is given during system start time to fill the if not enough time is given during system start time to fill the
entropy pool then the output might be predictable and repeatable, for entropy pool then the output might be predictable and repeatable, for
example leading to the same keys generated again and again. example leading to the same keys generated again and again.
Recommendation: IoT devices using DTLS MUST offer ways to generate Recommendation: IoT devices using DTLS MUST offer ways to generate
quality random numbers. Guidelines and requirements for random quality random numbers. Guidelines and requirements for random
number generation can be found in RFC 4086 [RFC4086]. number generation can be found in RFC 4086 [RFC4086].
It is important to note that sources contributing to the randomness It is important to note that sources contributing to the randomness
pool on laptops, or desktop pcs are not available on many IoT device, pool on laptops, or desktop PCs are not available on many IoT device,
such as mouse movement, timing of keystrokes, air turbulence on the such as mouse movement, timing of keystrokes, air turbulence on the
movement of hard drive heads, etc. Other sources have to be found or movement of hard drive heads, etc. Other sources have to be found or
dedicated hardware has to be added. dedicated hardware has to be added.
14. Client Certificate URLs 14. Client Certificate URLs
This RFC 6066 [RFC6066] extension allows to avoid sending client-side This RFC 6066 [RFC6066] extension allows to avoid sending client-side
certificates and URLs instead. This reduces the over-the-air certificates and URLs instead. This reduces the over-the-air
transmission. transmission.
skipping to change at page 19, line 5 skipping to change at page 18, line 49
19. Negotiation and Downgrading Attacks 19. Negotiation and Downgrading Attacks
CoAP demands version 1.2 of DTLS to be used and the earlier version CoAP demands version 1.2 of DTLS to be used and the earlier version
of DTLS is not supported. As such, there is no risk of downgrading of DTLS is not supported. As such, there is no risk of downgrading
to an older version of DTLS. The work described in to an older version of DTLS. The work described in
[I-D.bmoeller-tls-downgrade-scsv] is therefore also not applicable to [I-D.bmoeller-tls-downgrade-scsv] is therefore also not applicable to
this environment since there is no legacy server infrastructure to this environment since there is no legacy server infrastructure to
worry about. worry about.
QUESTION: Should we say something for non-CoAP use of DTLS?
To prevent the TLS renegotiation attack [RFC5746] clients MUST To prevent the TLS renegotiation attack [RFC5746] clients MUST
respond to server-initiated renegotiation attempts with an Alert respond to server-initiated renegotiation attempts with an Alert
message (no_renegotiation) and clients MUST NOT initiate them. TLS message (no_renegotiation) and clients MUST NOT initiate them. TLS
and DTLS allows a client and a server who already have a TLS and DTLS allows a client and a server who already have a TLS
connection to negotiate new parameters, generate new keys, etc by connection to negotiate new parameters, generate new keys, etc by
initiating a TLS handshake using a ClientHello message. initiating a TLS handshake using a ClientHello message.
Renegotiation happens in the existing TLS connection, with the new Renegotiation happens in the existing TLS connection, with the new
handshake packets being encrypted along with application data. handshake packets being encrypted along with application data.
20. Privacy Considerations 20. Privacy Considerations
 End of changes. 14 change blocks. 
24 lines changed or deleted 20 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/