idnits 2.17.00 (12 Aug 2021) /tmp/idnits31320/draft-ietf-dice-profile-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (August 31, 2014) is 2819 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 624, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' == Outdated reference: draft-ietf-tls-cached-info has been published as RFC 7924 == Outdated reference: draft-ietf-tls-session-hash has been published as RFC 7627 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Informational RFC: RFC 7251 == Outdated reference: draft-ietf-tls-encrypt-then-mac has been published as RFC 7366 == Outdated reference: draft-ietf-uta-tls-bcp has been published as RFC 7525 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dice H. Tschofenig, Ed. 3 Internet-Draft ARM Ltd. 4 Intended status: Standards Track August 31, 2014 5 Expires: March 4, 2015 7 A Datagram Transport Layer Security (DTLS) 1.2 Profile for the Internet 8 of Things 9 draft-ietf-dice-profile-04.txt 11 Abstract 13 This document defines a DTLS 1.2 profile that is suitable for 14 Internet of Things applications and is reasonably implementable on 15 many constrained devices. 17 A common design pattern in IoT deployments is the use of a 18 constrained device (typically providing sensor data) that interacts 19 with the web infrastructure. This document focuses on this 20 particular pattern. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 4, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. The Communication Model . . . . . . . . . . . . . . . . . . . 5 59 4. The Ciphersuite Concept . . . . . . . . . . . . . . . . . . . 6 60 5. Credential Types . . . . . . . . . . . . . . . . . . . . . . 8 61 5.1. Pre-Shared Secret . . . . . . . . . . . . . . . . . . . . 8 62 5.2. Raw Public Key . . . . . . . . . . . . . . . . . . . . . 9 63 5.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 11 64 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 13 65 7. Session Resumption . . . . . . . . . . . . . . . . . . . . . 14 66 8. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 9. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 15 68 10. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 11. Random Number Generation . . . . . . . . . . . . . . . . . . 16 70 12. Client Certificate URLs . . . . . . . . . . . . . . . . . . . 17 71 13. Trusted CA Indication . . . . . . . . . . . . . . . . . . . . 17 72 14. Truncated MAC Extension . . . . . . . . . . . . . . . . . . . 18 73 15. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 18 74 16. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 19 75 17. TLS Session Hash . . . . . . . . . . . . . . . . . . . . . . 19 76 18. Negotiation and Downgrading Attacks . . . . . . . . . . . . . 19 77 19. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 78 20. Security Considerations . . . . . . . . . . . . . . . . . . . 20 79 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 80 22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 81 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 23.1. Normative References . . . . . . . . . . . . . . . . . . 21 83 23.2. Informative References . . . . . . . . . . . . . . . . . 22 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 86 1. Introduction 88 This document defines a DTLS 1.2 [RFC6347] profile that offers 89 communication security for Internet of Things (IoT) applications and 90 is reasonably implementable on many constrained devices. The DTLS 91 1.2 protocol is based on Transport Layer Security (TLS) 1.2 [RFC5246] 92 and provides equivalent security guarantees. This document aims to 93 meet the following goals: 95 o Serves as a one-stop shop for implementers to know which pieces of 96 the specification jungle contain relevant details. 98 o Does not alter the DTLS 1.2 specification. 100 o Does not introduce any new extensions. 102 o Aligns with the DTLS security modes of the Constrained Application 103 Protocol (CoAP) [RFC7252]. 105 DTLS is used to secure a number of applications run over an 106 unreliable datagram transport. CoAP [RFC7252] is one such protocol 107 and has been designed specifically for use in IoT environments. CoAP 108 can be secured a number of different ways, also called security 109 modes. These security modes are as follows, see Section 5.1, 110 Section 5.2, Section 5.3 for additional details: 112 No Security Protection at the Transport Layer: No DTLS is used but 113 instead application layer security functionality is assumed. 115 Shared Secret-based DTLS Authentication: DTLS supports the use of 116 shared secrets [RFC4279]. This mode is useful if the number of 117 communication relationships between the IoT device and servers is 118 small and for very constrained devices. Shared secret-based 119 authentication mechanisms offer good performance and require a 120 minimum of data to be exchanged. 122 DTLS Authentication using Asymmetric Cryptography: TLS supports 123 client and server authentication using asymmetric cryptography. 124 Two approaches for validating these public keys are available. 125 First, [RFC7250] allows raw public keys to be used in TLS without 126 the overhead of certificates. This approach requires out-of-band 127 validation of the public key. Second, the use of X.509 128 certificates [RFC5280] with TLS is common on the Web today (at 129 least for server-side authentication) and certain IoT environments 130 may also re-use those capabilities. Certificates bind an 131 identifier to the public key signed by a certification authority 132 (CA). A trust anchor store has to be provisioned on the device to 133 indicate what CAs are trusted. Furthermore, the certificate may 134 contain a wealth of other information used to make authorization 135 decisions. 137 As described in [I-D.ietf-lwig-tls-minimal], an application designer 138 developing an IoT device needs to consider the security threats and 139 the security services that can be used to mitigate the threats. 140 Enabling devices to upload data and retrieve configuration 141 information, inevitably requires that Internet-connected devices be 142 able to authenticate themselves to servers and vice versa as well as 143 to ensure that the data and information exchanged is integrity and 144 confidentiality protected. While these security services can be 145 provided at different layers in the protocol stack the use of 146 communication security, as offered by DTLS, has been very popular on 147 the Internet and it is likely to be useful for IoT scenarios as well. 148 In case the communication security features offered by DTLS meet the 149 security requirements of your application the remainder of the 150 document might offer useful guidance. 152 Not every IoT deployment will use CoAP but the discussion regarding 153 choice of credentials and cryptographic algorithms will be very 154 similar. As such, the discussions in this document are applicable 155 beyond the use of the CoAP protocol. 157 The design of DTLS is intentionally very similar to TLS. Since DTLS 158 operates on top of an unreliable datagram transport a few 159 enhancements to the TLS structure are, however necessary. RFC 6347 160 explains these differences in great detail. As a short summary, for 161 those not familiar with DTLS the differences are: 163 o An explicit sequence number and an epoch field is included in the 164 TLS Record Layer. Section 4.1 of RFC 6347 explains the processing 165 rules for these two new fields. The value used to compute the MAC 166 is the 64-bit value formed by concatenating the epoch and the 167 sequence number. 169 o Stream ciphers must not be used with DTLS. The only stream cipher 170 defined for TLS 1.2 is RC4 and due to cryptographic weaknesses it 171 is not recommended anymore even for use with TLS. 173 o The TLS Handshake Protocol has been enhanced to include a 174 stateless cookie exchange for Denial of Service (DoS) resistance. 175 Furthermore, the header has been extended to deal with message 176 loss, reordering, and fragmentation. Retransmission timers have 177 been included to deal with message loss. For DoS protection a new 178 handshake message, the HelloVerifyRequest, was added to DTLS. 179 This handshake message is sent by the server and includes a 180 stateless cookie, which is returned in a ClientHello message back 181 to the server. This type of DoS protection mechanism has also 182 been incorporated into the design of IKEv2. Although the exchange 183 is optional for the server to execute, a client implementation has 184 to be prepared to respond to it. 186 2. Terminology 188 The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in [RFC2119]. 192 Note that "Client" and "Server" in this document refer to TLS roles, 193 where the Client initiates the TLS handshake. This does not restrict 194 the interaction pattern of the protocols carried inside TLS as the 195 record layer allows bi-directional communication. In the case of 196 CoAP the "Client" can act as a CoAP Server or Client. 198 3. The Communication Model 200 This document describes a profile of DTLS 1.2 and, to be useful, it 201 has to make assumptions about the envisioned communication 202 architecture. 204 The communication architecture shown in Figure 1 assumes a uni-cast 205 communication interaction with an IoT device utilizing a DTLS client 206 and that client interacts with one or multiple DTLS servers. 208 Clients are preconfigured with the address or addresses of servers 209 (e.g., as part of the firmware) they will communicate with as well as 210 authentication information: 212 o For PSK-based authentication (see Section 5.1), this includes the 213 paired "PSK identity" and shared secret to be used with each 214 server. 216 o For raw public key-based authentication (see Section 5.2), this 217 includes either the server's public key or the hash of the 218 server's public key. 220 o For certificate-based authentication (see Section 5.3), this may 221 include a pre-populated trust anchor store that allows the client 222 to perform path validation for the certificate obtained during the 223 handshake with the server. 225 This document only focuses on the description of the DTLS client-side 226 functionality. 228 +////////////////////////////////////+ 229 | Configuration | 230 |////////////////////////////////////| 231 | Server A --> PSK Identity, PSK | 232 | Server B --> Public Key (Server B),| 233 | Public Key (Client) | 234 | Server C --> Public Key (Client), | 235 | Trust Anchor Store | 236 +------------------------------------+ 237 oo 238 oooooo 239 o 240 +------+ 241 |Client|--- 242 +------+ \ 243 \ ,-------. 244 ,' `. +------+ 245 / IP-based \ |Server| 246 ( Network ) | A | 247 \ / +------+ 248 `. ,' 249 '---+---' +------+ 250 | |Server| 251 | | B | 252 | +------+ 253 | 254 | +------+ 255 +----------------->|Server| 256 | C | 257 +------+ 259 Figure 1: Constrained DTLS Client Profile. 261 4. The Ciphersuite Concept 263 TLS (and consequently DTLS) has the concept of ciphersuites and an 264 IANA registry [IANA-TLS] was created to register the suites. A 265 ciphersuite (and the specification that defines it) contains the 266 following information: 268 o Authentication and Key Exchange Algorithm (e.g., PSK) 270 o Cipher and Key Length (e.g., AES with 128 bit keys) 272 o Mode of operation (e.g., CBC) 273 o Hash Algorithm for Integrity Protection (e.g., SHA in combination 274 with HMAC) 276 o Hash Algorithm for use with the Pseudorandom Function (e.g. HMAC 277 with the SHA-256) 279 o Misc information (e.g., length of authentication tags) 281 o Information whether the ciphersuite is suitable for DTLS or only 282 for TLS 284 The TLS ciphersuite TLS_PSK_WITH_AES_128_CCM_8, for example, uses a 285 pre-shared authentication and key exchange algorithm. RFC 6655 286 [RFC6655] defines this ciphersuite. It uses the Advanced Encryption 287 Standard (AES) encryption algorithm, which is a block cipher. Since 288 the AES algorithm supports different key lengths (such as 128, 192 289 and 256 bits) this information has to be specified as well and the 290 selected ciphersuite supports 128 bit keys. A block cipher encrypts 291 plaintext in fixed-size blocks and AES operates on fixed block size 292 of 128 bits. For messages exceeding 128 bits, the message is 293 partitioned into 128-bit blocks and the AES cipher is applied to 294 these input blocks with appropriate chaining, which is called mode of 295 operation. 297 TLS 1.2 introduced Authenticated Encryption with Associated Data 298 (AEAD) ciphersuites [RFC5116]. AEAD is a class of block cipher modes 299 which encrypt (parts of) the message and authenticate the message 300 simultaneously. Examples of such modes include the Counter with CBC- 301 MAC (CCM) mode, and the Galois/Counter Mode (GCM). 303 Some AEAD ciphersuites have shorter authentication tags and are 304 therefore more suitable for networks with low bandwidth where small 305 message size matters. The TLS_PSK_WITH_AES_128_CCM_8 ciphersuite 306 that ends in "_8" has an 8-octet authentication tag, while the 307 regular CCM ciphersuites have 16-octet authentication tags. 309 TLS 1.2 also replaced the combination of MD5/SHA-1 hash functions in 310 the TLS pseudo random function (PRF) with cipher-suite-specified 311 PRFs. For this reason authors of more recent TLS 1.2 ciphersuite 312 specifications explicitly indicate the MAC algorithm and the hash 313 functions used with the TLS PRF. 315 This document references the CoAP recommended ciphersuite choices, 316 which have been selected based on implementation and deployment 317 experience from the IoT community. Over time the preference for 318 certain algorithms will, however, change. Not all components of a 319 ciphersuite change at the same speed. Changes are more likely to 320 expect for ciphers, the mode of operation, and the hash algorithms. 322 Some deployment environments will also be impacted by local 323 regulation, which might dictate a certain and less likely for public 324 key algorithms (such as RSA vs. ECC). 326 5. Credential Types 328 5.1. Pre-Shared Secret 330 The use of pre-shared secret credentials is one of the most basic 331 techniques for DTLS since it is both computational efficient and 332 bandwidth conserving. Pre-shared secret based authentication was 333 introduced to TLS with RFC 4279 [RFC4279]. The exchange shown in 334 Figure 2 illustrates the DTLS exchange including the cookie exchange. 335 While the server is not required to initiate a cookie exchange with 336 every handshake, the client is required to implement and to react on 337 it when challenged. 339 Client Server 340 ------ ------ 341 ClientHello --------> 343 <-------- HelloVerifyRequest 344 (contains cookie) 346 ClientHello --------> 347 (with cookie) 348 ServerHello 349 *ServerKeyExchange 350 <-------- ServerHelloDone 351 ClientKeyExchange 352 ChangeCipherSpec 353 Finished --------> 354 ChangeCipherSpec 355 <-------- Finished 357 Application Data <-------> Application Data 359 Legend: 361 * indicates an optional message payload 363 Figure 2: DTLS PSK Authentication including the Cookie Exchange. 365 [RFC4279] does not mandate the use of any particular type of 366 identity. Hence, the TLS client and server clearly have to agree on 367 the identities and keys to be used. The mandated encoding of 368 identities in Section 5.1 of RFC 4279 aims to improve 369 interoperability for those cases where the identity is configured by 370 a person using some management interface. Many IoT devices do, 371 however, not have a user interface and most of their credentials are 372 bound to the device rather than the user. Furthermore, credentials 373 are provisioned into trusted hardware modules or in the firmware by 374 the developers. As such, the encoding considerations are not 375 applicable to this usage environment. For use with this profile the 376 PSK identities SHOULD NOT assume a structured format (as domain 377 names, Distinguished Names, or IP addresses have) and a bit-by-bit 378 comparison operation can then be used by the server-side 379 infrastructure. 381 As described in Section 3 clients may have pre-shared keys with 382 several different servers. The client indicates which key it uses by 383 including a "PSK identity" in the ClientKeyExchange message. To help 384 the client in selecting which PSK identity / PSK pair to use, the 385 server can provide a "PSK identity hint" in the ServerKeyExchange 386 message. For IoT environments a simplifying assumption is made that 387 the hint for PSK key selection is based on the domain name of the 388 server. Hence, servers SHOULD NOT send the "PSK identity hint" in 389 the ServerKeyExchange message and client MUST ignore the message. 390 This approach is inline with RFC 4279 [RFC4279]. 392 RFC 4279 requires TLS implementations supporting PSK ciphersuites to 393 support arbitrary PSK identities up to 128 octets in length, and 394 arbitrary PSKs up to 64 octets in length. This is a useful 395 assumption for TLS stacks used in the desktop and mobile environment 396 where management interfaces are used to provision identities and 397 keys. For the IoT environment, however, many devices are not 398 equipped with displays and input devices (e.g., keyboards). Hence, 399 keys are distributed as part of hardware modules or are embedded into 400 the firmware. As such, these restrictions are not applicable to this 401 profile. 403 Constrained Application Protocol (CoAP) [RFC7252] currently specifies 404 TLS_PSK_WITH_AES_128_CCM_8 as the mandatory to implement ciphersuite 405 for use with shared secrets. This ciphersuite uses the AES algorithm 406 with 128 bit keys and CCM as the mode of operation. The label "_8" 407 indicates that an 8-octet authentication tag is used. This 408 ciphersuite makes use of the default TLS 1.2 Pseudorandom Function 409 (PRF), which uses HMAC with the SHA-256 hash function. 411 5.2. Raw Public Key 413 The use of raw public keys with DTLS, as defined in [RFC7250], is the 414 first entry point into public key cryptography without having to pay 415 the price of certificates and a PKI. The specification re-uses the 416 existing Certificate message to convey the raw public key encoded in 417 the SubjectPublicKeyInfo structure. To indicate support two new TLS 418 extensions had been defined, as shown in Figure 3, namely the 419 server_certificate_type and the client_certificate_type. To operate 420 this mechanism securely it is necessary to authenticate and authorize 421 the public keys out-of-band. This document therefore assumes that a 422 client implementation comes with one or multiple raw public keys of 423 servers, it has to communicate with, pre-provisioned. Additionally, 424 a device will have its own raw public key. To replace, delete, or 425 add raw public key to this list requires a software update, for 426 example using a firmware update mechanism. 428 Client Server 429 ------ ------ 431 ClientHello --------> 432 client_certificate_type 433 server_certificate_type 435 <------- HelloVerifyRequest 437 ClientHello --------> 438 client_certificate_type 439 server_certificate_type 441 ServerHello 442 client_certificate_type 443 server_certificate_type 444 Certificate 445 ServerKeyExchange 446 CertificateRequest 447 <-------- ServerHelloDone 449 Certificate 450 ClientKeyExchange 451 CertificateVerify 452 [ChangeCipherSpec] 453 Finished --------> 455 [ChangeCipherSpec] 456 <-------- Finished 458 Figure 3: DTLS Raw Public Key Exchange including the Cookie Exchange. 460 The CoAP recommended ciphersuite for use with this credential type is 461 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251]. This elliptic curve 462 cryptography (ECC) based AES-CCM TLS ciphersuite uses the Ephemeral 463 Elliptic Curve Diffie-Hellman (ECDHE) as the key establishment 464 mechanism and an Elliptic Curve Digital Signature Algorithm (ECDSA) 465 for authentication. Due to the use of Ephemeral Elliptic Curve 466 Diffie-Hellman (ECDHE) the recently introduced named Diffie-Hellman 467 groups [I-D.ietf-tls-negotiated-dl-dhe] are not applicable to this 468 profile. This ciphersuite make use of the AEAD capability in DTLS 469 1.2 and utilizes an eight-octet authentication tag. The use of a 470 Diffie-Hellman key exchange adds perfect forward secrecy (PFS). More 471 details about PFS can be found in Section 9. 473 RFC 6090 [RFC6090] provides valuable information for implementing 474 Elliptic Curve Cryptography algorithms, particularly for choosing 475 methods that have been published more than 20 years ago. 477 Since many IoT devices will either have limited ways to log error or 478 no ability at all, any error will lead to implementations attempting 479 to re-try the exchange. 481 5.3. Certificates 483 The use of mutual certificate-based authentication is shown in 484 Figure 4, which makes use of the cached info extension 485 [I-D.ietf-tls-cached-info]. Support of the cached info extension is 486 required. Caching certificate chains allows the client to reduce the 487 communication overhead significantly since otherwise the server would 488 provide the end entity certificate, and the certificate chain. 489 Because certificate validation requires that root keys be distributed 490 independently, the self-signed certificate that specifies the root 491 certificate authority is omitted from the chain. Client 492 implementations MUST be provisioned with a trust anchor store that 493 contains the root certificates. The use of the Trust Anchor 494 Management Protocol (TAMP) [RFC5934] is, however, not envisioned. 495 Instead IoT devices using this profile MUST rely a software update 496 mechanism to provision these trust anchors. 498 When DTLS is used to secure CoAP messages then the server provided 499 certificates MUST contain the fully qualified DNS domain name or 500 "FQDN". The coaps URI scheme is described in Section 6.2 of 501 [RFC7252]. This FQDN is stored in the SubjectAltName or in the CN, 502 as explained in Section 9.1.3.3 of [RFC7252], and used by the client 503 to match it against the FQDN used during the look-up process, as 504 described in RFC 6125 [RFC6125]. For the profile in this 505 specification does not assume dynamic discovery of local servers. 507 For client certificates the identifier used in the SubjectAltName or 508 in the CN MUST be an EUI-64 [EUI64], as mandated in Section 9.1.3.3 509 of [RFC7252]. 511 For certificate revocation neither the Online Certificate Status 512 Protocol (OCSP) nor Certificate Revocation Lists (CRLs) are used. 513 Instead, this profile relies on a software update mechanism. While 514 multiple OCSP stapling [RFC6961] has recently been introduced as a 515 mechanism to piggyback OCSP request/responses inside the DTLS/TLS 516 handshake to avoid the cost of a separate protocol handshake further 517 investigations are needed to determine its suitability for the IoT 518 environment. 520 Client Server 521 ------ ------ 523 ClientHello --------> 524 cached_information 526 <------- HelloVerifyRequest 528 ClientHello --------> 529 cached_information 530 ServerHello 531 cached_information 532 Certificate 533 ServerKeyExchange 534 CertificateRequest 535 <-------- ServerHelloDone 537 Certificate 538 ClientKeyExchange 539 CertificateVerify 540 [ChangeCipherSpec] 541 Finished --------> 543 [ChangeCipherSpec] 544 <-------- Finished 546 Figure 4: DTLS Mutual Certificate-based Authentication. 548 Regarding the ciphersuite choice the discussion in Section 5.2 549 applies. Further details about X.509 certificates can be found in 550 Section 9.1.3.3 of [RFC7252]. The TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 551 ciphersuite description in Section 5.2 is also applicable to this 552 section. 554 It is RECOMMENDED to limit the depth of the certificate chain to a 555 maximum of three (3). 557 6. Error Handling 559 DTLS uses the Alert protocol to convey error messages and specifies a 560 longer list of errors. However, not all error messages defined in 561 the TLS specification are applicable to this profile. All error 562 messages marked as RESERVED are only supported for backwards 563 compatibility with SSL and are therefore not applicable to this 564 profile. Those include decryption_failed_RESERVED, 565 no_certificate_RESERVE, and export_restriction_RESERVED. 567 A number of the error messages are applicable only for certificate- 568 based authentication ciphersuites. Hence, for PSK and raw public key 569 use the following error messages are not applicable: 571 o bad_certificate, 573 o unsupported_certificate, 575 o certificate_revoked, 577 o certificate_expired, 579 o certificate_unknown, 581 o unknown_ca, and 583 o access_denied. 585 Since this profile does not make use of compression at the TLS layer 586 the decompression_failure error message is not applicable either. 588 RFC 4279 introduced a new alert message unknown_psk_identity for PSK 589 ciphersuites. As stated in Section 2 of RFC 4279 the 590 decryption_error error message may also be used instead. For this 591 profile the TLS server MUST return the decryption_error error message 592 instead of the unknown_psk_identity. 594 Furthermore, the following errors should not occur based on the 595 description in this specification: 597 protocol_version: This document only focuses on one version of the 598 DTLS protocol. 600 insufficient_security: This error message indicates that the server 601 requires ciphers to be more secure. This document does, however, 602 specify the only acceptable ciphersuites and client 603 implementations must support them. 605 user_canceled: The IoT devices in focus of this specification are 606 assumed to be unattended. 608 7. Session Resumption 610 Session resumption is a feature of DTLS that allows a client to 611 continue with an earlier established session state. The resulting 612 exchange is shown in Figure 5. In addition, the server may choose 613 not to do a cookie exchange when a session is resumed. Still, 614 clients have to be prepared to do a cookie exchange with every 615 handshake. 617 Client Server 618 ------ ------ 620 ClientHello --------> 621 ServerHello 622 [ChangeCipherSpec] 623 <-------- Finished 624 [ChangeCipherSpec] 625 Finished --------> 626 Application Data <-------> Application Data 628 Figure 5: DTLS Session Resumption. 630 Clients MUST implement session resumption to improve the performance 631 of the handshake (in terms of reduced number of message exchanges, 632 lower computational overhead, and less bandwidth conserved). 634 Since the communication model described in Section 3 does not assume 635 that the server is constrained. RFC 5077 [RFC5077] describing TLS 636 session resumption without server-side state is not utilized by this 637 profile. 639 8. Compression 641 [I-D.ietf-uta-tls-bcp] recommends to always disable DTLS-level 642 compression due to attacks. For IoT applications compression at the 643 DTLS is not needed since application layer protocols are highly 644 optimized and the compression algorithms at the DTLS layer increase 645 code size and complexity. 647 This DTLS client profile does not include DTLS layer compression. 649 9. Perfect Forward Secrecy 651 Perfect forward secrecy (PFS) is designed to prevent the compromise 652 of a long-term secret key from affecting the confidentiality of past 653 conversations. The PSK ciphersuite recommended in the CoAP 654 specification [RFC7252] does not offer this property since it does 655 not utilize a Diffie-Hellman exchange. [I-D.ietf-uta-tls-bcp] on the 656 other hand recommends using ciphersuites offering this security 657 property and so do the public key-based ciphersuites recommended by 658 the CoAP specification. 660 The use of PFS is certainly a trade-off decision since on one hand 661 the compromise of long-term secrets of embedded devices is more 662 likely than with many other Internet hosts but on the other hand a 663 Diffie-Hellman exchange requires ephemeral key pairs to be generated, 664 which can be demanding from a performance point of view. Finally, 665 the impact of the disclosure of past conversations and the desire to 666 increase the cost for pervasive monitoring (see [RFC7258]) has to be 667 taken into account. 669 Our recommendation is to stick with the ciphersuite suggested in the 670 CoAP specification. New ciphersuites support PFS for pre-shared 671 secret-based authentication, such as 672 [I-D.schmertmann-dice-ccm-psk-pfs], and might be available as a 673 standardized ciphersuite in the future. 675 10. Keep-Alive 677 RFC 6520 [RFC6520] defines a heartbeat mechanism to test whether the 678 other peer is still alive. The same mechanism can also be used to 679 perform Path Maximum Transmission Unit (MTU) Discovery. 681 A recommendation about the use of RFC 6520 depends on the type of 682 message exchange an IoT device performs. There are three types of 683 exchanges that need to be analysed: 685 Client-Initiated, One-Shot Messages 687 This is a common communication pattern where IoT devices upload 688 data to a server on the Internet on an irregular basis. The 689 communication may be triggered by specific events, such as opening 690 a door. 692 Since the upload happens on an irregular and unpredictable basis 693 and due to renumbering and Network Address Translation (NAT) a new 694 DTLS session or DTLS session resumption can be used. 696 In this case there is no use for a keep-alive extension for this 697 scenario. 699 Client-Initiated, Regular Data Uploads 701 This is a variation of the previous case whereby data gets 702 uploaded on a regular basis, for example, based on frequent 703 temperature readings. With such regular exchange it can be 704 assumed that the DTLS context is still in kept at the IoT device. 705 If neither NAT bindings nor IP address changes occurred then the 706 DTLS record layer will not notice any changes. For the case where 707 IP and port changes happened it is necessary to re-create the DTLS 708 record layer using session resumption. 710 In this scenario there is no use for a keep-alive extension. It 711 is also very likely that the device will enter a sleep cycle in 712 between data transmissions to keep power consumption low. 714 Server-Initiated Messages 716 In the two previous scenarios the client initiated the protocol 717 interaction. In this case, we consider server-initiated messages. 718 Since messages to the client may get blocked by intermediaries, 719 such as NATs and stateful packet filtering firewalls, the initial 720 connection setup is triggered by the client and then kept alive. 721 Since state expires fairly quickly at middleboxes regular 722 heartbeats are necessary whereby these keep-alive messages may be 723 exchanged at the application layer or within DTLS itself. 725 For this message exchange pattern the use of DTLS heartbeat 726 messages is quite useful. The MTU discovery mechanism, on the 727 other hand, is less likely to be relevant since for many IoT 728 deployments the must constrained link is the wireless interface at 729 the IoT device itself rather than somewhere in the network. Only 730 in more complex network topologies the situation might be 731 different. 733 For server-initiated messages the heartbeat extension can be 734 recommended. 736 11. Random Number Generation 738 The DTLS protocol requires random numbers to be available during the 739 protocol run. For example, during the ClientHello and the 740 ServerHello exchange the client and the server exchange random 741 numbers. Also, the use of the Diffie-Hellman exchange requires 742 random numbers during the key pair generation. Special care has to 743 be paid when generating random numbers in embedded systems as many 744 entropy sources available on desktop operating systems or mobile 745 devices might be missing, as described in [Heninger]. Consequently, 746 if not enough time is given during system start time to fill the 747 entropy pool then the output might be predictable and repeatable, for 748 example leading to the same keys generated again and again. 750 Recommendation: IoT devices using DTLS MUST offer ways to generate 751 quality random numbers. Guidelines and requirements for random 752 number generation can be found in RFC 4086 [RFC4086]. 754 It is important to note that sources contributing to the randomness 755 pool on laptops, or desktop PCs are not available on many IoT device, 756 such as mouse movement, timing of keystrokes, air turbulence on the 757 movement of hard drive heads, etc. Other sources have to be found or 758 dedicated hardware has to be added. 760 The ClientHello and the ServerHello message contains the 'Random' 761 structure, which has two components: gmt_unix_time and a random 762 sequence of 28 random bytes. gmt_unix_time holds the current time 763 and date in standard UNIX 32-bit format (seconds since the midnight 764 starting Jan 1, 1970, GMT). [I-D.mathewson-no-gmtunixtime] argues 765 that the entire value the ClientHello.Random and ServerHello.Random 766 fields, including gmt_unix_time, should be set to a cryptographically 767 random sequence because of privacy concerns (fingerprinting). Since 768 many IoT devices do not have access to a real-time clock this 769 recommendation is even more relevant in the embedded systems 770 environment. 772 12. Client Certificate URLs 774 This RFC 6066 [RFC6066] extension allows to avoid sending client-side 775 certificates and URLs instead. This reduces the over-the-air 776 transmission. 778 This is certainly a useful extension when a certificate-based mode 779 for DTLS is used since the TLS cached info extension does not provide 780 any help with caching information on the server side. 782 Recommendation: Add support for client certificate URLs for those 783 environments where client-side certificates are used. 785 13. Trusted CA Indication 787 This RFC 6066 extension allows clients to indicate what trust anchor 788 they support. With certificate-based authentication a DTLS server 789 conveys its end entity certificate to the client during the DTLS 790 exchange provides. Since the server does not necessarily know what 791 trust anchors the client has stored it includes intermediate CA certs 792 in the certificate payload as well to facilitate with certification 793 path construction and path validation. 795 Today, in most IoT deployments there is a fairly static relationship 796 between the IoT device (and the software running on them) and the 797 server- side infrastructure and no such dynamic indication of trust 798 anchors is needed. 800 Recommendation: For IoT deployments where clients talk to a fixed, 801 pre-configured set of servers and where a software update mechanism 802 is available this extension is not recommended. Environments where 803 the client needs to interact with dynamically discovered DTLS servers 804 this extension may be useful to reduce the communication overhead. 805 Note, however, in that case the TLS cached info extension may help to 806 reduce the communication overhead for everything but the first 807 protocol interaction. 809 14. Truncated MAC Extension 811 The truncated MAC extension was introduced with RFC 6066 with the 812 goal to reduces the size of the MAC used at the Record Layer. This 813 extension was developed for TLS ciphersuites that used older modes of 814 operation where the MAC and the encryption operation was performed 815 independently. 817 For CoAP, however, the recommended ciphersuites use the newer 818 Authenticated Encryption with Associated Data (AEAD) construct, 819 namely the CBC-MAC mode (CCM) with eight-octet authentication tags. 820 Furthermore, the extension [I-D.ietf-tls-encrypt-then-mac] 821 introducing the encrypt-then-MAC security mechanism (instead of the 822 MAC-then-encrypt) is also not applicable for this profile. 824 Recommendation: Since this profile only supports AEAD ciphersuites 825 this extension is not applicable. 827 15. Server Name Indication (SNI) 829 This RFC 6066 extension defines a mechanism for a client to tell a 830 TLS server the name of the server it wants to contact. This is a 831 useful extension for many hosting environments where multiple virtual 832 servers are run on single IP address. 834 Recommendation: Unless it is known that a DTLS client does not 835 interact with a server in a hosting environment that requires such an 836 extension we advice to offer support for the SNI extension in this 837 profile. 839 16. Maximum Fragment Length Negotiation 841 This RFC 6066 extension lowers the maximum fragment length support 842 needed for the Record Layer from 2^14 bytes to 2^9 bytes. 844 This is a very useful extension that allows the client to indicate to 845 the server how much maximum memory buffers it uses for incoming 846 messages. Ultimately, the main benefit of this extension is it to 847 allows client implementations to lower their RAM requirements since 848 the client does not need to accept packets of large size (such as 16k 849 packets as required by plain TLS/DTLS). 851 Recommendation: Client implementations MUST support this extension. 853 17. TLS Session Hash 855 The TLS master secret is not cryptographically bound to important 856 session parameters such as the client and server identities. This 857 can be utilized by an attacker to mount a man-in-the-middle attack 858 since the master secret is not guaranteed to be unique across 859 sessions. 861 [I-D.ietf-tls-session-hash] defines a TLS extension that binds the 862 master secret to a log of the full handshake that computes it, thus 863 preventing such attacks. 865 Recommendation: Client implementations SHOULD implement this 866 extension support this extension even though the ciphersuites 867 recommended by this profile are not vulnerable this attack. For 868 Diffie-Hellman-based ciphersuites the keying material is contributed 869 by both parties and in case of the pre-shared secret key ciphersuite 870 both parties need to be in possession of the shared secret to ensure 871 that the handshake completes successfully. It is, however, possible 872 that some application layer protocols will tunnel other 873 authentication protocols on top of DTLS making this attack relevant 874 again. 876 18. Negotiation and Downgrading Attacks 878 CoAP demands version 1.2 of DTLS to be used and the earlier version 879 of DTLS is not supported. As such, there is no risk of downgrading 880 to an older version of DTLS. The work described in 881 [I-D.bmoeller-tls-downgrade-scsv] is therefore also not applicable to 882 this environment since there is no legacy server infrastructure to 883 worry about. 885 To prevent the TLS renegotiation attack [RFC5746] clients MUST 886 respond to server-initiated renegotiation attempts with an Alert 887 message (no_renegotiation) and clients MUST NOT initiate them. TLS 888 and DTLS allows a client and a server who already have a TLS 889 connection to negotiate new parameters, generate new keys, etc by 890 initiating a TLS handshake using a ClientHello message. 891 Renegotiation happens in the existing TLS connection, with the new 892 handshake packets being encrypted along with application data. 894 19. Privacy Considerations 896 The DTLS handshake exchange conveys various identifiers, which can be 897 observed by an on-path eavesdropper. For example, the DTLS PSK 898 exchange reveals the PSK identity, the supported extensions, the 899 session id, algorithm parameters, etc. When session resumption is 900 used then individual TLS sessions can be correlated by an on-path 901 adversary. With many IoT deployments it is likely that keying 902 material and their identifiers are persistent over a longer period of 903 time due to the cost of updating software on these devices. 905 User participation with many IoT deployments poses a challenge since 906 many of the IoT devices operate unattended, even though they will 907 initially be enabled by a human. The ability to control data sharing 908 and to configure preference will have to be provided at a system 909 level rather than at the level of a DTLS profile, which is the scope 910 of this document. Quite naturally, the use of DTLS with mutual 911 authentication will allow a TLS server to collect authentication 912 information about the IoT device (potentially over a long period of 913 time). While this strong form of authentication will prevent mis- 914 attribution it also allows strong identification. This device- 915 related data collection (e.g., sensor recordings) will be associated 916 with other data to be truly useful and this extra data might include 917 personal data about the owner of the device or data about the 918 environment it senses. Consequently, the data stored on the server- 919 side will be vulnerable to stored data compromise. For the 920 communication between the client and the server this specification 921 prevents eavesdroppers to gain access to the communication content. 922 While the PSK-based ciphersuite does not provide PFS the asymmetric 923 version does. No explicit techniques, such as extra padding, have 924 been provided to make traffic analysis more difficult. 926 20. Security Considerations 928 This entire document is about security. 930 We would also like to point out that designing a software update 931 mechanism into an IoT system is crucial to ensure that both 932 functionality can be enhanced and that potential vulnerabilities can 933 be fixed. This software update mechanism is also useful for changing 934 configuration information, for example, trust anchors and other 935 keying related information. 937 21. IANA Considerations 939 This document includes no request to IANA. 941 22. Acknowledgements 943 Thanks to Robert Cragie, Russ Housley, Rene Hummen, Sandeep Kumar, 944 Sye Loong Keoh, Eric Rescorla, Michael Richardson, Zach Shelby, and 945 Sean Turner for their helpful comments and discussions that have 946 shaped the document. 948 Big thanks also to Klaus Hartke, who wrote the initial version of 949 this document. 951 23. References 953 23.1. Normative References 955 [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 956 REGISTRATION AUTHORITY", April 2010, 957 . 960 [I-D.ietf-tls-cached-info] 961 Santesson, S. and H. Tschofenig, "Transport Layer Security 962 (TLS) Cached Information Extension", draft-ietf-tls- 963 cached-info-16 (work in progress), February 2014. 965 [I-D.ietf-tls-session-hash] 966 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 967 A., and M. Ray, "Transport Layer Security (TLS) Session 968 Hash and Extended Master Secret Extension", draft-ietf- 969 tls-session-hash-01 (work in progress), August 2014. 971 [I-D.mathewson-no-gmtunixtime] 972 Mathewson, N. and B. Laurie, "Deprecating gmt_unix_time in 973 TLS", draft-mathewson-no-gmtunixtime-00 (work in 974 progress), December 2013. 976 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 977 Requirement Levels", BCP 14, RFC 2119, March 1997. 979 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 980 for Transport Layer Security (TLS)", RFC 4279, December 981 2005. 983 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 984 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 986 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 987 "Transport Layer Security (TLS) Renegotiation Indication 988 Extension", RFC 5746, February 2010. 990 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 991 Extension Definitions", RFC 6066, January 2011. 993 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 994 Verification of Domain-Based Application Service Identity 995 within Internet Public Key Infrastructure Using X.509 996 (PKIX) Certificates in the Context of Transport Layer 997 Security (TLS)", RFC 6125, March 2011. 999 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1000 Security Version 1.2", RFC 6347, January 2012. 1002 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 1003 Layer Security (TLS) and Datagram Transport Layer Security 1004 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 1006 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 1007 T. Kivinen, "Using Raw Public Keys in Transport Layer 1008 Security (TLS) and Datagram Transport Layer Security 1009 (DTLS)", RFC 7250, June 2014. 1011 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 1012 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 1013 TLS", RFC 7251, June 2014. 1015 23.2. Informative References 1017 [Heninger] 1018 Heninger, N., Durumeric, Z., Wustrow, E., and A. 1019 Halderman, "Mining Your Ps and Qs: Detection of Widespread 1020 Weak Keys in Network Devices", 21st USENIX Security 1021 Symposium, 1022 https://www.usenix.org/conference/usenixsecurity12/ 1023 technical-sessions/presentation/heninger, 2012. 1025 [I-D.bmoeller-tls-downgrade-scsv] 1026 Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 1027 Suite Value (SCSV) for Preventing Protocol Downgrade 1028 Attacks", draft-bmoeller-tls-downgrade-scsv-02 (work in 1029 progress), May 2014. 1031 [I-D.ietf-lwig-tls-minimal] 1032 Kumar, S., Keoh, S., and H. Tschofenig, "A Hitchhiker's 1033 Guide to the (Datagram) Transport Layer Security Protocol 1034 for Smart Objects and Constrained Node Networks", draft- 1035 ietf-lwig-tls-minimal-01 (work in progress), March 2014. 1037 [I-D.ietf-tls-encrypt-then-mac] 1038 Gutmann, P., "Encrypt-then-MAC for TLS and DTLS", draft- 1039 ietf-tls-encrypt-then-mac-03 (work in progress), July 1040 2014. 1042 [I-D.ietf-tls-negotiated-dl-dhe] 1043 Gillmor, D., "Negotiated Discrete Log Diffie-Hellman 1044 Ephemeral Parameters for TLS", draft-ietf-tls-negotiated- 1045 dl-dhe-00 (work in progress), July 2014. 1047 [I-D.ietf-uta-tls-bcp] 1048 Sheffer, Y., Holz, R., and P. Saint-Andre, 1049 "Recommendations for Secure Use of TLS and DTLS", draft- 1050 ietf-uta-tls-bcp-02 (work in progress), August 2014. 1052 [I-D.schmertmann-dice-ccm-psk-pfs] 1053 Schmertmann, L. and C. Bormann, "ECDHE-PSK AES-CCM Cipher 1054 Suites with Forward Secrecy for Transport Layer Security 1055 (TLS)", draft-schmertmann-dice-ccm-psk-pfs-01 (work in 1056 progress), August 2014. 1058 [IANA-TLS] 1059 IANA, "TLS Cipher Suite Registry", 1060 http://www.iana.org/assignments/tls-parameters/ 1061 tls-parameters.xhtml#tls-parameters-4, 2014. 1063 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1064 Requirements for Security", BCP 106, RFC 4086, June 2005. 1066 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1067 "Transport Layer Security (TLS) Session Resumption without 1068 Server-Side State", RFC 5077, January 2008. 1070 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1071 Encryption", RFC 5116, January 2008. 1073 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1074 Housley, R., and W. Polk, "Internet X.509 Public Key 1075 Infrastructure Certificate and Certificate Revocation List 1076 (CRL) Profile", RFC 5280, May 2008. 1078 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 1079 Management Protocol (TAMP)", RFC 5934, August 2010. 1081 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1082 Curve Cryptography Algorithms", RFC 6090, February 2011. 1084 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 1085 Transport Layer Security (TLS)", RFC 6655, July 2012. 1087 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 1088 Multiple Certificate Status Request Extension", RFC 6961, 1089 June 2013. 1091 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1092 Application Protocol (CoAP)", RFC 7252, June 2014. 1094 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1095 Attack", BCP 188, RFC 7258, May 2014. 1097 Author's Address 1099 Hannes Tschofenig (editor) 1100 ARM Ltd. 1101 110 Fulbourn Rd 1102 Cambridge CB1 9NJ 1103 Great Britain 1105 Email: Hannes.tschofenig@gmx.net 1106 URI: http://www.tschofenig.priv.at