idnits 2.17.1 draft-hartke-dice-profile-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 322: '... PSK identities MUST NOT assume a str...' RFC 2119 keyword, line 334: '... Hence, servers SHOULD NOT send the "...' RFC 2119 keyword, line 335: '...ssage and client MUST ignore the messa...' RFC 2119 keyword, line 443: '... implementations MUST be provisioned w...' RFC 2119 keyword, line 446: '...ing this profile MUST rely a software ...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3724 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5280' is mentioned on line 110, but not defined == Missing Reference: 'ChangeCipherSpec' is mentioned on line 561, but not defined == Unused Reference: 'I-D.ietf-tls-cached-info' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 727, but no explicit reference was found in the text == Unused Reference: 'RFC6066' is defined on line 734, but no explicit reference was found in the text == Unused Reference: 'I-D.campagna-suitee' is defined on line 766, but no explicit reference was found in the text == Unused Reference: 'I-D.cooper-ietf-privacy-requirements' is defined on line 771, but no explicit reference was found in the text == Unused Reference: 'I-D.greevenbosch-tls-ocsp-lite' is defined on line 776, but no explicit reference was found in the text == Unused Reference: 'I-D.gutmann-tls-encrypt-then-mac' is defined on line 781, but no explicit reference was found in the text == Unused Reference: 'I-D.hummen-dtls-extended-session-resumption' is defined on line 786, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lwig-guidance' is defined on line 792, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lwig-terminology' is defined on line 797, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tls-applayerprotoneg' is defined on line 809, but no explicit reference was found in the text == Unused Reference: 'I-D.pettersen-tls-version-rollback-removal' is defined on line 815, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 830, but no explicit reference was found in the text == Unused Reference: 'RFC4492' is defined on line 837, but no explicit reference was found in the text == Unused Reference: 'RFC6973' is defined on line 859, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-ietf-tls-cached-info-15 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-02) exists of draft-bmoeller-tls-downgrade-scsv-01 == Outdated reference: A later version (-07) exists of draft-ietf-lwig-terminology-06 == Outdated reference: A later version (-01) exists of draft-ietf-lwig-tls-minimal-00 == Outdated reference: A later version (-05) exists of draft-ietf-tls-applayerprotoneg-04 == Outdated reference: A later version (-03) exists of draft-pettersen-tls-version-rollback-removal-02 == Outdated reference: A later version (-02) exists of draft-sheffer-tls-bcp-01 -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) -- 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: 4 errors (**), 0 flaws (~~), 25 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dice K. Hartke 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Informational H. Tschofenig 5 Expires: August 18, 2014 ARM Ltd. 6 February 14, 2014 8 A DTLS 1.2 Profile for the Internet of Things 9 draft-hartke-dice-profile-03 11 Abstract 13 This document defines a DTLS profile that is suitable for Internet of 14 Things applications and is reasonably implementable on many 15 constrained devices. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on August 18, 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. The Communication Model . . . . . . . . . . . . . . . . . . . 4 53 3. The Ciphersuite Concept . . . . . . . . . . . . . . . . . . . 5 54 4. Pre-Shared Secret Authentication with DTLS . . . . . . . . . 6 55 5. Raw Public Key Use with DTLS . . . . . . . . . . . . . . . . 8 56 6. Certificate Use with DTLS . . . . . . . . . . . . . . . . . . 10 57 7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 11 58 8. Session Resumption . . . . . . . . . . . . . . . . . . . . . 12 59 9. TLS Compression . . . . . . . . . . . . . . . . . . . . . . . 13 60 10. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 13 61 11. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 14 62 12. Negotiation and Downgrading Attacks . . . . . . . . . . . . . 14 63 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 64 14. Security Considerations . . . . . . . . . . . . . . . . . . . 15 65 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 66 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 67 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 68 17.1. Normative References . . . . . . . . . . . . . . . . . . 16 69 17.2. Informative References . . . . . . . . . . . . . . . . . 17 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 72 1. Introduction 74 This document defines a DTLS 1.2 [RFC6347] profile that offers 75 communication security for Internet of Things (IoT) applications and 76 is reasonably implementable on many constrained devices. It aims to 77 meet the following goals: 79 o One-stop shop for implementers through the specification jungle. 81 o This document does not alter the DTLS 1.2 specification. 83 o This document does not introduce new extensions. 85 o This profile aligns with the DTLS security modes of the 86 Constrained Application Protocol (CoAP) [I-D.ietf-core-coap]. 88 DTLS is used to secure a number of applications run over an 89 unreliable datagram transport. CoAP [I-D.ietf-core-coap] is one such 90 protocol and has been designed specifically for use in IoT 91 environments. CoAP can be secured using a number of different ways, 92 also called security modes. These security modes are: 94 No Security Protection at the Transport Layer: No DTLS is used but 95 instead application layer security functionality is assumed. 97 Shared Secret-based DTLS Authentication: DTLS supports the use of 98 shared secrets [RFC4279]. This credential is useful if the number 99 of communication relationships between the IoT device and servers 100 is small and for very constrained devices. Shared secret-based 101 authentication mechanisms offer good performance and require a 102 minimum of data to be exchanged. 104 DTLS Authentication using Asymmetric Credentials: TLS supports 105 client and server authentication using asymmetric credentials. 106 Two approaches for validating these public key are available. 107 First, [I-D.ietf-tls-oob-pubkey] allows raw public keys to be used 108 in TLS without the overhead of certificates. This approach 109 requires out-of-band validation of the public key. Second, the 110 use of X.509 certificates [RFC5280] with TLS is common on the Web 111 today (at least for server-side authentication) and certain IoT 112 environments may also re-use those capabilities. Certificates 113 bind an identifier to the public key signed by a certification 114 authority (CA). A trust anchor store has to be provisioned on the 115 device to indicate what CAs are trusted. Furthermore, the 116 certificate may contain a wealth of other information used to make 117 authorization decisions. 119 As described in [I-D.ietf-lwig-tls-minimal] an application designer 120 developing an IoT device needs to think about the security threats 121 that need to be mitigated. For many Internet connected devices it 122 is, however, likely that authentication of the device and the server 123 infrastructure will be required. Along with the ability to upload 124 sensor data and to retrieve configuration information the need for 125 integrity and confidentiality protection will arise. While these 126 security services can be provided at different layers in the protocol 127 stack the use of channel security, as offered by DTLS, has been very 128 popular on the Internet and it is likely to be useful for IoT 129 scenarios as well. In case the channel security features offered by 130 DTLS meet the security requirements of your application the remainder 131 of the document might offer useful guidance. 133 Not every IoT deployment will use CoAP but the discussion regarding 134 choice of credentials and cryptographic algorithms will be very 135 similar. As such, the discussions in this document are applicable 136 beyond the use of the CoAP protocol. 138 The design of DTLS is intentionally very similar to TLS. Since DTLS 139 operates on top of an unreliable datagram transport a few 140 enhancements to the TLS structure are, however necessary. RFC 6347 141 explains these differences in great detail. As a short summary, for 142 those familiar with TLS the differences are: 144 o An explicit sequence number and an epoch field is included in the 145 TLS Record Layer. Section 4.1 of RFC 6347 explains the processing 146 rules for these two new fields. The value used to compute the MAC 147 is the 64-bit value formed by concatenating the epoch and the 148 sequence number. 150 o Stream ciphers must not be used with DTLS. The only stream cipher 151 defined for TLS 1.2 is RC4. 153 o The TLS Handshake Protocol has been enhanced to include a 154 stateless cookie exchange for Denial of Service (DoS) resistance. 155 Furthermore, the header has been extended to deal with message 156 loss, reordering, and fragmentation. Retransmission timers have 157 been included to deal with message loss. For DoS protection a new 158 handshake message, the HelloVerifyRequest, was added to DTLS. 159 This handshake message is sent by the server and includes a 160 stateless cookie, which is returned in a ClientHello message back 161 to the server. This type of DoS protection mechanism has also 162 been incorporated into the design of IKEv2. Although the exchange 163 is optional for the server to execute, a client implementation has 164 to be prepared to respond to it. 166 2. The Communication Model 168 This document describes a profile of DTLS 1.2 and to be useful it has 169 to make assumptions about the envisioned communication architecture. 170 The architecture shown in Figure 1 assumes a uni-cast communication 171 interaction with an IoT device acting as a client and the client 172 interacts with one or multiple servers. Which server to contact is 173 based on pre-configuration onto the client (e.g., as part of the 174 firmware). This configuration information also includes information 175 about the PSK identity and the corresponding secret to be used with 176 that specific server (in case of symmetric credentials). For 177 asymmetric cryptography mutual authentication is assumed in this 178 profile. For raw public keys the public key or the hash of the 179 public key is assumed to be available to both parties. For 180 certificate-based authentication the client may have a trust anchor 181 store pre-populated, which allows the client to perform path 182 validation for the certificate obtained during the handshake with the 183 server. The client also needs to know which certificate or raw 184 public key it has to use with a specific server. 186 This document only focuses on the description of the DTLS client-side 187 functionality. 189 +////////////////////////////////////+ 190 | Configuration | 191 |////////////////////////////////////| 192 | Server A --> PSK Identity, PSK | 193 | Server B --> Public Key (Server B),| 194 | Public Key (Client) | 195 | Server C --> Public Key (Client), | 196 | Trust Anchor Store | 197 +------------------------------------+ 198 oo 199 oooooo 200 o 201 +------+ 202 |Client|--- 203 +------+ \ 204 \ ,-------. 205 ,' `. +------+ 206 / IP-based \ |Server| 207 ( Network ) | A | 208 \ / +------+ 209 `. ,' 210 '---+---' +------+ 211 | |Server| 212 | | B | 213 | +------+ 214 | 215 | +------+ 216 +----------------->|Server| 217 | C | 218 +------+ 220 Figure 1: DTLS Profile: Assumed Communication Model. 222 A future version of this document may provide profiles for other 223 communication architectures. 225 3. The Ciphersuite Concept 227 TLS (and consequently DTLS) introduced the concept of ciphersuites 228 and an IANA registry [IANA-TLS] was created to keep track of the 229 specified suites. A ciphersuites (and the specification that defines 230 it) contains the following information: 232 o Authentication and Key Exchange Algorithm (e.g., PSK) 234 o Cipher and Key Length(e.g., AES with 128 bit keys) 235 o Mode of operation (e.g., CBC) 237 o Hash Algorithm for Integrity Protection (e.g., SHA in combination 238 with HMAC) 240 o Hash Algorithm for use with the Pseudorandom Function (e.g. HMAC 241 with the SHA-256) 243 o Misc information (e.g., length of authentication tags) 245 The TLS ciphersuite TLS_PSK_WITH_AES_256_CBC_SHA, for example, uses a 246 pre-shared authentication and key exchange algorithm. RFC 4279, 247 which defined this ciphersuite predates publication of TLS 1.2. It 248 uses the Advanced Encryption Standard (AES) encryption algorithm, 249 which is a block cipher. Since the AES algorithm supports different 250 key lengths (such as 128, 192 and 256 bits) this information has to 251 be specified as well and the selected ciphersuite supports 256 bit 252 keys. A block cipher encrypts plaintext in fixed-size blocks and AES 253 operates on fixed block size of 128 bits. For messages exceeding 128 254 bits, the message is partitioned into 128-bit blocks and the AES 255 cipher is applied to these input blocks with appropriate chaining, 256 which is called mode of operation. In our example, the mode of 257 operation is cipher block chaining (CBC). Since encryption itself 258 does not provide integrity protection a hash function is specified as 259 well, which will be used in concert with the HMAC function. In this 260 case, the Secure Hash Algorithm (SHA). 262 TLS 1.2 introduced Authenticated Encryption with Associated Data 263 (AEAD) ciphersuites. AEAD is a class of block cipher modes which 264 encrypt (parts of) the message and authenticate the message 265 simultaneously. Examples of such modes include the Counter with CBC- 266 MAC (CCM) mode, and the Galois/Counter Mode (GCM). 268 TLS 1.2 also replaced the combination of MD5/SHA-1 hash functions in 269 the TLS pseudo random function (PRF) with cipher-suite-specified 270 PRFs. For this reason authors of more recent TLS 1.2 ciphersuite 271 specifications explicitly indicate the MAC algorithm and the hash 272 functions used with the TLS PRF. 274 4. Pre-Shared Secret Authentication with DTLS 276 The use of pre-shared secret credentials is one of the most basic 277 techniques for DTLS since it is both computational efficient and 278 bandwidth conserving. Pre-shared secret based authentication was 279 introduced to TLS with RFC 4279 [RFC4279]. The exchange shown in 280 Figure 2 illustrates the DTLS exchange including the cookie exchange. 281 While the server is not required to initiate a cookie exchange with 282 every handshake, the client is required to implement and to react on 283 it when challenged. 285 Client Server 286 ------ ------ 287 ClientHello --------> 289 <-------- HelloVerifyRequest 290 (contains cookie) 292 ClientHello --------> 293 (with cookie) 294 ServerHello 295 *ServerKeyExchange 296 <-------- ServerHelloDone 297 ClientKeyExchange 298 ChangeCipherSpec 299 Finished --------> 300 ChangeCipherSpec 301 <-------- Finished 303 Application Data <-------> Application Data 305 Legend: 307 * indicates an optional message payload 309 Figure 2: DTLS PSK Authentication including the Cookie Exchange. 311 [RFC4279] does not mandate the use of any particular type of 312 identity. Hence, the TLS client and server clearly have to agree on 313 the identities and keys to be used. The mandated encoding of 314 identities in Section 5.1 of RFC 4279 aims to improve 315 interoperability for those cases where the identity is configured by 316 a person using some management interface. Many IoT devices do, 317 however, not have a user interface and most of their credentials are 318 bound to the device rather than the user. Furthermore, credentials 319 are provisioned into trusted hardware modules or in the firmware by 320 the developers. As such, the encoding considerations are not 321 applicable to this usage environment. For use with this profile the 322 PSK identities MUST NOT assume a structured format (as domain names, 323 Distinguished Names, or IP addresses have) and a bit-by-bit 324 comparison operation can then be used by the server-side 325 infrastructure. 327 As described in Section 2 clients may have pre-shared keys with 328 several different servers. The client indicates which key it uses by 329 including a "PSK identity" in the ClientKeyExchange message. To help 330 the client in selecting which PSK identity / PSK pair to use, the 331 server can provide a "PSK identity hint" in the ServerKeyExchange 332 message. For Iot environments a simplifying assumption is made that 333 the hint for PSK key selection is based on the domain name of the 334 server. Hence, servers SHOULD NOT send the "PSK identity hint" in 335 the ServerKeyExchange message and client MUST ignore the message. 337 RFC 4279 requires TLS implementations supporting PSK ciphersuites to 338 support arbitrary PSK identities up to 128 octets in length, and 339 arbitrary PSKs up to 64 octets in length. This is a useful 340 assumption for TLS stacks used in the desktop and mobile environment 341 where management interfaces are used to provision identities and 342 keys. For the IoT environment, however, many devices are not 343 equipped with displays and input devices (e.g., keyboards). Hence, 344 keys are distributed as part of hardware modules or are embedded into 345 the firmware. As such, these restrictions are not applicable to this 346 profile. 348 Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] 349 currently specifies TLS_PSK_WITH_AES_128_CCM_8 as the mandatory to 350 implement ciphersuite for use with shared secrets. This ciphersuite 351 uses the AES algorithm with 128 bit keys and CCM as the mode of 352 operation. The label "_8" indicates that an 8-octet authentication 353 tag is used. This ciphersuite makes use of the default TLS 1.2 354 Pseudorandom Function (PRF), which uses HMAC with the SHA-256 hash 355 function. 357 5. Raw Public Key Use with DTLS 359 The use of raw public keys with DTLS, as defined in 360 [I-D.ietf-tls-oob-pubkey], is the first entry point into public key 361 cryptography without having to pay the price of certificates and a 362 PKI. The specification re-uses the existing Certificate message to 363 convey the raw public key encoded in the SubjectPublicKeyInfo 364 structure. To indicate support two new TLS extensions had been 365 defined as shown in Figure 3, namely the server_certificate_type and 366 the client_certificate_type. To operate this mechanism securely it 367 is necessary to authenticate and authorize the public keys out-of- 368 band. This document therefore assumes that a client implementation 369 comes with one or multiple raw public keys of servers, it has to 370 communicate with, pre-provisioned. Additionally, a device will have 371 its own raw public key. To replace, delete, or add raw public key to 372 this list requires a software update, for example using a firmware 373 update. 375 Client Server 376 ------ ------ 378 ClientHello --------> 379 client_certificate_type 380 server_certificate_type 382 <------- HelloVerifyRequest 384 ClientHello --------> 385 client_certificate_type 386 server_certificate_type 388 ServerHello 389 client_certificate_type 390 server_certificate_type 391 Certificate 392 ServerKeyExchange 393 CertificateRequest 394 <-------- ServerHelloDone 396 Certificate 397 ClientKeyExchange 398 CertificateVerify 399 [ChangeCipherSpec] 400 Finished --------> 402 [ChangeCipherSpec] 403 <-------- Finished 405 Figure 3: DTLS Raw Public Key Exchange including the Cookie Exchange. 407 The ciphersuite for use with this credential type is 408 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [I-D.mcgrew-tls-aes-ccm-ecc]. 409 This elliptic curve cryptography (ECC) based AES-CCM TLS ciphersuite 410 uses the Elliptic Curve Diffie Hellman (ECDHE) as the key 411 establishment mechanism and an Elliptic Curve Digital Signature 412 Algorithm (ECDSA) for authentication. This ciphersuite make use of 413 the AEAD capability in DTLS 1.2 and utilizes an eight-octet 414 authentication tag. Based on the Diffie-Hellman it provides perfect 415 forward secrecy (PFS). More details about the PFS can be found in 416 Section 10. 418 RFC 6090 [RFC6090] provides valuable information for implementing 419 Elliptic Curve Cryptography algorithms. 421 Since many IoT devices will either have limited ways to log error or 422 no ability at all, any error will lead to implementations attempting 423 to re-try the exchange. 425 QUESTION: [I-D.sheffer-tls-bcp] recommends a different ciphersuite, 426 namely TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5289] or 427 alternatively TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (with a 2048-bit or 428 1024 DH parameters as second and third priority, respectively). Is 429 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 a good choice? 431 6. Certificate Use with DTLS 433 The use of mutual certificate-based authentication is shown in 434 Figure 4. Note that the figure also makes use of the cached info 435 extension, which is indicated by the TLS extension 436 (cached_information) and the changed content in the exchanged 437 certificates. Caching certificate chains allows the client to reduce 438 the communication overhead significantly since otherwise the server 439 would provide the end entity certificate, and the certificate chain. 440 Because certificate validation requires that root keys be distributed 441 independently, the self-signed certificate that specifies the root 442 certificate authority is omitted from the chain. Client 443 implementations MUST be provisioned with a trust anchor store that 444 contains the root certificates. The use of the Trust Anchor 445 Management Protocol (TAMP) [RFC5934] is, however, not envisioned. 446 Instead IoT devices using this profile MUST rely a software update 447 mechanism to provision these trust anchors. 449 When DTLS is used to secure CoAP messages then the server provided 450 certificates MUST contain the fully qualified DNS domain name or 451 "FQDN". The coaps URI scheme is described in Section 6.2 of 452 [I-D.ietf-core-coap]. This FQDN is stored in the SubjectAltName or 453 in the CN, as explained in Section 9.1.3.3 of [I-D.ietf-core-coap], 454 and used by the client to match it against the FQDN used during the 455 look-up process, as described in RFC 6125 [RFC6125]. For the profile 456 in this specification does not assume dynamic discovery of local 457 servers. 459 For client certificates the identifier used in the SubjectAltName or 460 in the CN MUST be an EUI-64 [EUI64], as mandated in Section 9.1.3.3 461 of [I-D.ietf-core-coap]. 463 For certificate revocation neither the Online Certificate Status 464 Protocol (OCSP) nor Certificate Revocation Lists (CRLs) are used. 465 Instead, this profile relies on a software update mechanism. While 466 multiple OCSP stapling [RFC6961] has recently been introduced as a 467 mechanism to piggyback OCSP request/responses inside the DTLS/TLS 468 handshake to avoid the cost of a separate protocol handshake further 469 investigations are needed to determine its suitability for the IoT 470 environment. 472 Client Server 473 ------ ------ 475 ClientHello --------> 476 cached_information 478 <------- HelloVerifyRequest 480 ClientHello --------> 481 cached_information 482 ServerHello 483 cached_information 484 Certificate 485 ServerKeyExchange 486 CertificateRequest 487 <-------- ServerHelloDone 489 Certificate 490 ClientKeyExchange 491 CertificateVerify 492 [ChangeCipherSpec] 493 Finished --------> 495 [ChangeCipherSpec] 496 <-------- Finished 498 Figure 4: DTLS Mutual Certificate-based Authentication. 500 Regarding the ciphersuite choice the discussion in Section 5 applies. 501 Further details about X.509 certificates can be found in 502 Section 9.1.3.3 of [I-D.ietf-core-coap]. 504 QUESTION: What restrictions regarding the depth of the certificate 505 chain should be made? Is one level enough? 507 7. Error Handling 509 DTLS uses the Alert protocol to convey error messages and specifies a 510 longer list of errors. However, not all error messages defined in 511 the TLS specification are applicable to this profile. All error 512 messages marked as RESERVED are only supported for backwards 513 compatibility with SSL and are therefore not applicable to this 514 profile. Those include decryption_failed_RESERVED, 515 no_certificate_RESERVE, and export_restriction_RESERVED. A number of 516 the error messages are applicable only for certificate-based 517 authentication ciphersuites. Hence, for PSK and raw public key use 518 the following error messages are not applicable: bad_certificate, 519 unsupported_certificate, certificate_revoked, certificate_expired, 520 certificate_unknown, unknown_ca, and access_denied. 522 Since this profile does not make use of compression at the TLS layer 523 the decompression_failure error message is not applicable either. 525 RFC 4279 introduced a new alert message unknown_psk_identity for PSK 526 ciphersuites. As stated in Section 2 of RFC 4279 the 527 decryption_error error message may also be used instead. For this 528 profile the TLS server MUST return the decryption_error error message 529 instead of the unknown_psk_identity. 531 Furthermore, the following errors should not occur based on the 532 description in this specification: 534 protocol_version: This document only focuses on one version of the 535 DTLS protocol. 537 insufficient_security: This error message indicates that the server 538 requires ciphers to be more secure. This document does, however, 539 specify the only acceptable ciphersuites and client 540 implementations must support them. 542 user_canceled: The IoT devices in focus of this specification are 543 assumed to be unattended. 545 8. Session Resumption 547 Session resumption is a feature of DTLS that allows a client to 548 continue with an earlier established session state. The resulting 549 exchange is shown in Figure 5. In addition, the server may choose 550 not to do a cookie exchange when a session is resumed. Still, 551 clients have to be prepared to do a cookie exchange with every 552 handshake. 554 Client Server 555 ------ ------ 557 ClientHello --------> 558 ServerHello 559 [ChangeCipherSpec] 560 <-------- Finished 561 [ChangeCipherSpec] 562 Finished --------> 563 Application Data <-------> Application Data 565 Figure 5: DTLS Session Resumption. 567 Clients MUST implement session resumption to improve the performance 568 of the handshake (in terms of reduced number of message exchanges, 569 lower computational overhead, and less bandwidth conserved). 571 Since the communication model described in Section 2 does not assume 572 that the server is constrained. RFC 5077 [RFC5077] describing TLS 573 session resumption without server-side state is not utilized by this 574 profile. 576 9. TLS Compression 578 [I-D.sheffer-tls-bcp] recommends to always disable DTLS-level 579 compression due to attacks. For IoT applications compression at the 580 DTLS is not needed since application layer protocols are highly 581 optimized and the compression algorithms at the DTLS layer increase 582 code size and complexity. Hence, for use with this profile 583 compression at the DTLS layer MUST NOT be implemented by the DTLS 584 client. 586 10. Perfect Forward Secrecy 588 Perfect forward secrecy is designed to prevent the compromise of a 589 long-term secret key from affecting the confidentiality of past 590 conversations. The PSK ciphersuite recommended in the CoAP 591 specification [I-D.ietf-core-coap] does not offer this property. 592 [I-D.sheffer-tls-bcp] on the other hand recommends using ciphersuites 593 offering this security property. 595 QUESTION: Should the PSK ciphersuite offer PFS? 597 11. Keep-Alive 599 RFC 6520 [RFC6520] defines a heartbeat mechanism to test whether the 600 other peer is still alive. The same mechanism can also be used to 601 perform path MTU discovery. 603 QUESTION: Do IoT deployments make use of this extension? 605 12. Negotiation and Downgrading Attacks 607 CoAP demands version 1.2 of DTLS to be used and the earlier version 608 of DTLS is not supported. As such, there is no risk of downgrading 609 to an older version of DTLS. The work described in 610 [I-D.bmoeller-tls-downgrade-scsv] is therefore also not applicable to 611 this environment since there is no legacy server infrastructure to 612 worry about. 614 QUESTION: Should we say something for non-CoAP use of DTLS? 616 To prevent the TLS renegotiation attack [RFC5746] clients MUST 617 respond to server-initiated renegotiation attempts with an Alert 618 message (no_renegotiation) and clients MUST NOT initiate them. TLS 619 and DTLS allows a client and a server who already have a TLS 620 connection to negotiate new parameters, generate new keys, etc by 621 initiating a TLS handshake using a ClientHello message. 622 Renegotiation happens in the existing TLS connection, with the new 623 handshake packets being encrypted along with application data. 625 13. Privacy Considerations 627 The DTLS handshake exchange conveys various identifiers, which can be 628 observed by an on-path eavesdropper. For example, the DTLS PSK 629 exchange reveals the PSK identity, the supported extensions, the 630 session id, algorithm parameters, etc. When session resumption is 631 used then individual TLS sessions can be correlated by an on-path 632 adversary. With many IoT deployments it is likely that keying 633 material and their identifiers are persistent over a longer period of 634 time due to the cost of updating software on these devices. 636 User participation with many IoT deployments poses a challenge since 637 many of the IoT devices operate unattended, even though they will 638 initially be enabled by a human. The ability to control data sharing 639 and to configure preference will have to be provided at a system 640 level rather than at the level of a DTLS profile, which is the scope 641 of this document. Quite naturally, the use of DTLS with mutual 642 authentication will allow a TLS server to collect authentication 643 information about the IoT device (potentially over a long period of 644 time). While this strong form of authentication will prevent mis- 645 attribution it also allows strong identification. This device- 646 related data collection (e.g., sensor recordings) will be associated 647 with other data to be truly useful and this extra data might include 648 personal data about the owner of the device or data about the 649 environment it senses. Consequently, the data stored on the server- 650 side will be vulnerable to stored data compromise. For the 651 communication between the client and the server this specification 652 prevents eavesdroppers to gain access to the communication content. 653 While the PSK-based ciphersuite does not provide PFS the asymmetric 654 version does. No explicit techniques, such as extra padding, have 655 been provided to make traffic analysis more difficult. 657 14. Security Considerations 659 This entire document is about security. 661 The TLS protocol requires random numbers to be available during the 662 protocol run. For example, during the ClientHello and the 663 ServerHello exchange the client and the server exchange random 664 numbers. Also, the use of the Diffie Hellman exchange requires 665 random numbers during the key pair generation. Special care has to 666 be paid when generating random numbers in embedded systems as many 667 entropy sources available on desktop operating systems or mobile 668 devices might be missing, as described in [Heninger]. Consequently, 669 if not enough time is given during system start time to fill the 670 entropy pool then the output might be predictable and repeatable, for 671 example leading to the same keys generated again and again. 672 Guidelines and requirements for random number generation can be found 673 in RFC 4086 [RFC4086]. 675 We would also like to point out that designing a software update 676 mechanism into an IoT system is crucial to ensure that both 677 functionality can be enhanced and that potential vulnerabilities can 678 be fixed. This software update mechanism is also useful for changing 679 configuration information, for example, trust anchors and other 680 keying related information. 682 15. IANA Considerations 684 This document includes no request to IANA. 686 16. Acknowledgements 688 Thanks to Rene Hummen, Sye Loong Keoh, Sandeep Kumar, Eric Rescorla, 689 Zach Shelby, and Sean Turner for helpful comments and discussions 690 that have shaped the document. 692 17. References 694 17.1. Normative References 696 [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 697 REGISTRATION AUTHORITY", April 2010, 698 . 701 [I-D.ietf-core-coap] 702 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 703 Application Protocol (CoAP)", draft-ietf-core-coap-18 704 (work in progress), June 2013. 706 [I-D.ietf-tls-cached-info] 707 Santesson, S. and H. Tschofenig, "Transport Layer Security 708 (TLS) Cached Information Extension", draft-ietf-tls- 709 cached-info-15 (work in progress), October 2013. 711 [I-D.ietf-tls-oob-pubkey] 712 Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 713 T. Kivinen, "Using Raw Public Keys in Transport Layer 714 Security (TLS) and Datagram Transport Layer Security 715 (DTLS)", draft-ietf-tls-oob-pubkey-11 (work in progress), 716 January 2014. 718 [I-D.mcgrew-tls-aes-ccm-ecc] 719 McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 720 CCM ECC Cipher Suites for TLS", draft-mcgrew-tls-aes-ccm- 721 ecc-08 (work in progress), February 2014. 723 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 724 for Transport Layer Security (TLS)", RFC 4279, December 725 2005. 727 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 728 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 730 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 731 "Transport Layer Security (TLS) Renegotiation Indication 732 Extension", RFC 5746, February 2010. 734 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 735 Extension Definitions", RFC 6066, January 2011. 737 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 738 Verification of Domain-Based Application Service Identity 739 within Internet Public Key Infrastructure Using X.509 740 (PKIX) Certificates in the Context of Transport Layer 741 Security (TLS)", RFC 6125, March 2011. 743 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 744 Security Version 1.2", RFC 6347, January 2012. 746 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 747 Layer Security (TLS) and Datagram Transport Layer Security 748 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 750 17.2. Informative References 752 [Heninger] 753 Heninger, N., Durumeric, Z., Wustrow, E., and A. 754 Halderman, "Mining Your Ps and Qs: Detection of Widespread 755 Weak Keys in Network Devices", 21st USENIX Security 756 Symposium, https://www.usenix.org/conference/ 757 usenixsecurity12/technical-sessions/presentation/heninger, 758 2012. 760 [I-D.bmoeller-tls-downgrade-scsv] 761 Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 762 Suite Value (SCSV) for Preventing Protocol Downgrade 763 Attacks", draft-bmoeller-tls-downgrade-scsv-01 (work in 764 progress), November 2013. 766 [I-D.campagna-suitee] 767 Campagna, M., "A Cryptographic Suite for Embedded Systems 768 (SuiteE)", draft-campagna-suitee-04 (work in progress), 769 October 2012. 771 [I-D.cooper-ietf-privacy-requirements] 772 Cooper, A., Farrell, S., and S. Turner, "Privacy 773 Requirements for IETF Protocols", draft-cooper-ietf- 774 privacy-requirements-01 (work in progress), October 2013. 776 [I-D.greevenbosch-tls-ocsp-lite] 777 Greevenbosch, B., "OCSP-lite - Revocation of raw public 778 keys", draft-greevenbosch-tls-ocsp-lite-01 (work in 779 progress), June 2013. 781 [I-D.gutmann-tls-encrypt-then-mac] 782 Gutmann, P., "Encrypt-then-MAC for TLS and DTLS", draft- 783 gutmann-tls-encrypt-then-mac-05 (work in progress), 784 December 2013. 786 [I-D.hummen-dtls-extended-session-resumption] 787 Hummen, R., Gilger, J., and H. Shafagh, "Extended DTLS 788 Session Resumption for Constrained Network Environments", 789 draft-hummen-dtls-extended-session-resumption-01 (work in 790 progress), October 2013. 792 [I-D.ietf-lwig-guidance] 793 Bormann, C., "Guidance for Light-Weight Implementations of 794 the Internet Protocol Suite", draft-ietf-lwig-guidance-03 795 (work in progress), February 2013. 797 [I-D.ietf-lwig-terminology] 798 Bormann, C., Ersue, M., and A. Keranen, "Terminology for 799 Constrained Node Networks", draft-ietf-lwig-terminology-06 800 (work in progress), December 2013. 802 [I-D.ietf-lwig-tls-minimal] 803 Kumar, S., Keoh, S., and H. Tschofenig, "A Hitchhiker's 804 Guide to the (Datagram) Transport Layer Security Protocol 805 for Smart Objects and Constrained Node Networks", draft- 806 ietf-lwig-tls-minimal-00 (work in progress), September 807 2013. 809 [I-D.ietf-tls-applayerprotoneg] 810 Friedl, S., Popov, A., Langley, A., and S. Emile, 811 "Transport Layer Security (TLS) Application Layer Protocol 812 Negotiation Extension", draft-ietf-tls-applayerprotoneg-04 813 (work in progress), January 2014. 815 [I-D.pettersen-tls-version-rollback-removal] 816 Pettersen, Y., "Managing and removing automatic version 817 rollback in TLS Clients", draft-pettersen-tls-version- 818 rollback-removal-02 (work in progress), August 2013. 820 [I-D.sheffer-tls-bcp] 821 Sheffer, Y. and R. Holz, "Recommendations for Secure Use 822 of TLS and DTLS", draft-sheffer-tls-bcp-01 (work in 823 progress), September 2013. 825 [IANA-TLS] 826 IANA, "TLS Cipher Suite Registry", http://www.iana.org/ 827 assignments/tls-parameters/ 828 tls-parameters.xhtml#tls-parameters-4, 2014. 830 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 831 Text on Security Considerations", BCP 72, RFC 3552, July 832 2003. 834 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 835 Requirements for Security", BCP 106, RFC 4086, June 2005. 837 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 838 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 839 for Transport Layer Security (TLS)", RFC 4492, May 2006. 841 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 842 "Transport Layer Security (TLS) Session Resumption without 843 Server-Side State", RFC 5077, January 2008. 845 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with 846 SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 847 August 2008. 849 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 850 Management Protocol (TAMP)", RFC 5934, August 2010. 852 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 853 Curve Cryptography Algorithms", RFC 6090, February 2011. 855 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 856 Multiple Certificate Status Request Extension", RFC 6961, 857 June 2013. 859 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 860 Morris, J., Hansen, M., and R. Smith, "Privacy 861 Considerations for Internet Protocols", RFC 6973, July 862 2013. 864 Authors' Addresses 866 Klaus Hartke 867 Universitaet Bremen TZI 868 Postfach 330440 869 Bremen D-28359 870 Germany 872 Phone: +49-421-218-63905 873 Email: hartke@tzi.org 874 Hannes Tschofenig 875 ARM Ltd. 876 110 Fulbourn Rd 877 Cambridge CB1 9NJ 878 Great Britain 880 Email: Hannes.tschofenig@gmx.net 881 URI: http://www.tschofenig.priv.at