idnits 2.17.00 (12 Aug 2021) /tmp/idnits41456/draft-ietf-dice-profile-01.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 (May 6, 2014) is 2936 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ChangeCipherSpec' is mentioned on line 593, but not defined == Unused Reference: 'RFC5246' is defined on line 757, but no explicit reference was found in the text == Unused Reference: 'RFC6066' is defined on line 764, but no explicit reference was found in the text == Unused Reference: 'I-D.campagna-suitee' is defined on line 796, but no explicit reference was found in the text == Unused Reference: 'I-D.cooper-ietf-privacy-requirements' is defined on line 801, but no explicit reference was found in the text == Unused Reference: 'I-D.greevenbosch-tls-ocsp-lite' is defined on line 806, but no explicit reference was found in the text == Unused Reference: 'I-D.gutmann-tls-encrypt-then-mac' is defined on line 811, but no explicit reference was found in the text == Unused Reference: 'I-D.hummen-dtls-extended-session-resumption' is defined on line 816, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lwig-guidance' is defined on line 827, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lwig-terminology' is defined on line 832, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tls-applayerprotoneg' is defined on line 843, but no explicit reference was found in the text == Unused Reference: 'I-D.pettersen-tls-version-rollback-removal' is defined on line 849, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 864, but no explicit reference was found in the text == Unused Reference: 'RFC4492' is defined on line 871, but no explicit reference was found in the text == Unused Reference: 'RFC5289' is defined on line 887, but no explicit reference was found in the text == Unused Reference: 'RFC6973' is defined on line 904, but no explicit reference was found in the text == Outdated reference: draft-ietf-tls-cached-info has been published as RFC 7924 == Outdated reference: draft-ietf-tls-oob-pubkey has been published as RFC 7250 == Outdated reference: draft-mcgrew-tls-aes-ccm-ecc has been published as RFC 7251 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** 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: draft-ietf-core-coap has been published as RFC 7252 == Outdated reference: draft-ietf-lwig-terminology has been published as RFC 7228 == Outdated reference: draft-ietf-tls-applayerprotoneg has been published as RFC 7301 -- 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: 2 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: November 7, 2014 ARM Ltd. 6 May 6, 2014 8 A DTLS 1.2 Profile for the Internet of Things 9 draft-ietf-dice-profile-01.txt 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 November 7, 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. The Communication Model . . . . . . . . . . . . . . . . . . . 4 54 4. The Ciphersuite Concept . . . . . . . . . . . . . . . . . . . 6 55 5. Pre-Shared Secret Authentication with DTLS . . . . . . . . . 8 56 6. Raw Public Key Use with DTLS . . . . . . . . . . . . . . . . 9 57 7. Certificate Use with DTLS . . . . . . . . . . . . . . . . . . 11 58 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 13 59 9. Session Resumption . . . . . . . . . . . . . . . . . . . . . 13 60 10. TLS Compression . . . . . . . . . . . . . . . . . . . . . . . 14 61 11. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 14 62 12. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 15 63 13. Negotiation and Downgrading Attacks . . . . . . . . . . . . . 15 64 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 65 15. Security Considerations . . . . . . . . . . . . . . . . . . . 16 66 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 67 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 68 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 69 18.1. Normative References . . . . . . . . . . . . . . . . . . 17 70 18.2. Informative References . . . . . . . . . . . . . . . . . 18 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 73 1. Introduction 75 This document defines a DTLS 1.2 [RFC6347] profile that offers 76 communication security for Internet of Things (IoT) applications and 77 is reasonably implementable on many constrained devices. It aims to 78 meet the following goals: 80 o Serve as a one-stop shop for implementers to know which pieces of 81 the specification jungle contain relevant details. 83 o Not alter the DTLS specification. 85 o Not introduce any new extensions. 87 o Align with the DTLS security modes of the Constrained Application 88 Protocol (CoAP) [I-D.ietf-core-coap]. 90 DTLS is used to secure a number of applications run over an 91 unreliable datagram transport. CoAP [I-D.ietf-core-coap] is one such 92 protocol and has been designed specifically for use in IoT 93 environments. CoAP can be secured a number of different ways, also 94 called security modes. These security modes are as follows, see 95 Section 5, Section 6, Section 7 for additional details: 97 No Security Protection at the Transport Layer: No DTLS is used but 98 instead application layer security functionality is assumed. 100 Shared Secret-based DTLS Authentication: DTLS supports the use of 101 shared secrets [RFC4279]. This mode is useful if the number of 102 communication relationships between the IoT device and servers is 103 small and for very constrained devices. Shared secret-based 104 authentication mechanisms offer good performance and require a 105 minimum of data to be exchanged. 107 DTLS Authentication using Asymmetric Cryptography: TLS supports 108 client and server authentication using asymmetric cryptography. 109 Two approaches for validating these public keys are available. 110 First, [I-D.ietf-tls-oob-pubkey] allows raw public keys to be used 111 in TLS without the overhead of certificates. This approach 112 requires out-of-band validation of the public key. Second, the 113 use of X.509 certificates [RFC5280] with TLS is common on the Web 114 today (at least for server-side authentication) and certain IoT 115 environments may also re-use those capabilities. Certificates 116 bind an identifier to the public key signed by a certification 117 authority (CA). A trust anchor store has to be provisioned on the 118 device to indicate what CAs are trusted. Furthermore, the 119 certificate may contain a wealth of other information used to make 120 authorization decisions. 122 As described in [I-D.ietf-lwig-tls-minimal], an application designer 123 developing an IoT device needs to consider the security threats and 124 the security services that can be used to mitigate the threats. 125 Enabling devices to upload data and retrieve configuration 126 information, inevitably requires that Internet-connected devices be 127 able to authenticate themselves to servers and vice versa as well as 128 to ensure that the data and information exchanged is integrity and 129 confidentiality protected. While these security services can be 130 provided at different layers in the protocol stack the use of 131 communication security, as offered by DTLS, has been very popular on 132 the Internet and it is likely to be useful for IoT scenarios as well. 133 In case the communication security features offered by DTLS meet the 134 security requirements of your application the remainder of the 135 document might offer useful guidance. 137 Not every IoT deployment will use CoAP but the discussion regarding 138 choice of credentials and cryptographic algorithms will be very 139 similar. As such, the discussions in this document are applicable 140 beyond the use of the CoAP protocol. 142 The design of DTLS is intentionally very similar to TLS. Since DTLS 143 operates on top of an unreliable datagram transport a few 144 enhancements to the TLS structure are, however necessary. RFC 6347 145 explains these differences in great detail. As a short summary, for 146 those not familiar with DTLS the differences are: 148 o An explicit sequence number and an epoch field is included in the 149 TLS Record Layer. Section 4.1 of RFC 6347 explains the processing 150 rules for these two new fields. The value used to compute the MAC 151 is the 64-bit value formed by concatenating the epoch and the 152 sequence number. 154 o Stream ciphers must not be used with DTLS. The only stream cipher 155 defined for TLS 1.2 is RC4 and due to cryptographic weaknesses it 156 is not recommended anymore even for use with TLS. 158 o The TLS Handshake Protocol has been enhanced to include a 159 stateless cookie exchange for Denial of Service (DoS) resistance. 160 Furthermore, the header has been extended to deal with message 161 loss, reordering, and fragmentation. Retransmission timers have 162 been included to deal with message loss. For DoS protection a new 163 handshake message, the HelloVerifyRequest, was added to DTLS. 164 This handshake message is sent by the server and includes a 165 stateless cookie, which is returned in a ClientHello message back 166 to the server. This type of DoS protection mechanism has also 167 been incorporated into the design of IKEv2. Although the exchange 168 is optional for the server to execute, a client implementation has 169 to be prepared to respond to it. 171 2. Terminology 173 The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC2119]. 177 Note that "Client" and "Server" in this document refer to TLS roles, 178 where the Client initiates the TLS handshake. This does not restrict 179 the interaction pattern of the protocols carried inside TLS as the 180 record layer allows bi-directional communication. In the case of 181 CoAP the "Client" can act as a CoAP Server or Client. 183 3. The Communication Model 185 This document describes a profile of DTLS 1.2 and, to be useful, it 186 has to make assumptions about the envisioned communication 187 architecture. 189 The communication architecture shown in Figure 1 assumes a uni-cast 190 communication interaction with an IoT device utilizing a DTLS client 191 and that client interacts with one or multiple DTLS servers. 193 Clients are preconfigured with the address or addresses of servers 194 (e.g., as part of the firmware) they will communicate with as well as 195 authentication information: 197 o For PSK-based authentication (see Section 5), this includes the 198 paired "PSK identity" and shared secret to be used with each 199 server. 201 o For raw public key-based authentication (see Section 6), this 202 includes either the server's public key or the hash of the 203 server's public key. 205 o For certificate-based authentication (see Section 7), this may 206 include a pre-populated trust anchor store that allows the client 207 to perform path validation for the certificate obtained during the 208 handshake with the server. 210 This document only focuses on the description of the DTLS client-side 211 functionality. 213 +////////////////////////////////////+ 214 | Configuration | 215 |////////////////////////////////////| 216 | Server A --> PSK Identity, PSK | 217 | Server B --> Public Key (Server B),| 218 | Public Key (Client) | 219 | Server C --> Public Key (Client), | 220 | Trust Anchor Store | 221 +------------------------------------+ 222 oo 223 oooooo 224 o 225 +------+ 226 |Client|--- 227 +------+ \ 228 \ ,-------. 229 ,' `. +------+ 230 / IP-based \ |Server| 231 ( Network ) | A | 232 \ / +------+ 233 `. ,' 234 '---+---' +------+ 235 | |Server| 236 | | B | 237 | +------+ 238 | 239 | +------+ 240 +----------------->|Server| 241 | C | 242 +------+ 244 Figure 1: Constrained DTLS Client Profile. 246 4. The Ciphersuite Concept 248 TLS (and consequently DTLS) has the concept of ciphersuites and an 249 IANA registry [IANA-TLS] was created to register the suites. A 250 ciphersuite (and the specification that defines it) contains the 251 following information: 253 o Authentication and Key Exchange Algorithm (e.g., PSK) 255 o Cipher and Key Length (e.g., AES with 128 bit keys) 257 o Mode of operation (e.g., CBC) 258 o Hash Algorithm for Integrity Protection (e.g., SHA in combination 259 with HMAC) 261 o Hash Algorithm for use with the Pseudorandom Function (e.g. HMAC 262 with the SHA-256) 264 o Misc information (e.g., length of authentication tags) 266 o Information whether the ciphersuite is suitable for DTLS or only 267 for TLS 269 The TLS ciphersuite TLS_PSK_WITH_AES_128_CCM_8, for example, uses a 270 pre-shared authentication and key exchange algorithm. RFC 6655 271 [RFC6655] defines this ciphersuite. It uses the Advanced Encryption 272 Standard (AES) encryption algorithm, which is a block cipher. Since 273 the AES algorithm supports different key lengths (such as 128, 192 274 and 256 bits) this information has to be specified as well and the 275 selected ciphersuite supports 128 bit keys. A block cipher encrypts 276 plaintext in fixed-size blocks and AES operates on fixed block size 277 of 128 bits. For messages exceeding 128 bits, the message is 278 partitioned into 128-bit blocks and the AES cipher is applied to 279 these input blocks with appropriate chaining, which is called mode of 280 operation. 282 TLS 1.2 introduced Authenticated Encryption with Associated Data 283 (AEAD) ciphersuites [RFC5116]. AEAD is a class of block cipher modes 284 which encrypt (parts of) the message and authenticate the message 285 simultaneously. Examples of such modes include the Counter with CBC- 286 MAC (CCM) mode, and the Galois/Counter Mode (GCM). 288 Some AEAD ciphersuites have shorter authentication tags and are 289 therefore more suitable for networks with low bandwidth where small 290 message size matters. The TLS_PSK_WITH_AES_128_CCM_8 ciphersuite 291 that ends in "_8" has an 8-octet authentication tag, while the 292 regular CCM ciphersuites have 16-octet authentication tags. 294 TLS 1.2 also replaced the combination of MD5/SHA-1 hash functions in 295 the TLS pseudo random function (PRF) with cipher-suite-specified 296 PRFs. For this reason authors of more recent TLS 1.2 ciphersuite 297 specifications explicitly indicate the MAC algorithm and the hash 298 functions used with the TLS PRF. 300 This document references the CoAP recommended ciphersuite choices, 301 which have been selected based on implementation and deployment 302 experience from the IoT community. Over time the preference for 303 certain algorithms will, however, change. Not all components of a 304 ciphersuite change at the same speed. Changes are more likely to 305 expect for ciphers, the mode of operation, and the hash algorithms. 307 Some deployment environments will also be impacted by local 308 regulation, which might dictate a certain and less likely for public 309 key algorithms (such as RSA vs. ECC). 311 5. Pre-Shared Secret Authentication with DTLS 313 The use of pre-shared secret credentials is one of the most basic 314 techniques for DTLS since it is both computational efficient and 315 bandwidth conserving. Pre-shared secret based authentication was 316 introduced to TLS with RFC 4279 [RFC4279]. The exchange shown in 317 Figure 2 illustrates the DTLS exchange including the cookie exchange. 318 While the server is not required to initiate a cookie exchange with 319 every handshake, the client is required to implement and to react on 320 it when challenged. 322 Client Server 323 ------ ------ 324 ClientHello --------> 326 <-------- HelloVerifyRequest 327 (contains cookie) 329 ClientHello --------> 330 (with cookie) 331 ServerHello 332 *ServerKeyExchange 333 <-------- ServerHelloDone 334 ClientKeyExchange 335 ChangeCipherSpec 336 Finished --------> 337 ChangeCipherSpec 338 <-------- Finished 340 Application Data <-------> Application Data 342 Legend: 344 * indicates an optional message payload 346 Figure 2: DTLS PSK Authentication including the Cookie Exchange. 348 [RFC4279] does not mandate the use of any particular type of 349 identity. Hence, the TLS client and server clearly have to agree on 350 the identities and keys to be used. The mandated encoding of 351 identities in Section 5.1 of RFC 4279 aims to improve 352 interoperability for those cases where the identity is configured by 353 a person using some management interface. Many IoT devices do, 354 however, not have a user interface and most of their credentials are 355 bound to the device rather than the user. Furthermore, credentials 356 are provisioned into trusted hardware modules or in the firmware by 357 the developers. As such, the encoding considerations are not 358 applicable to this usage environment. For use with this profile the 359 PSK identities SHOULD NOT assume a structured format (as domain 360 names, Distinguished Names, or IP addresses have) and a bit-by-bit 361 comparison operation can then be used by the server-side 362 infrastructure. 364 As described in Section 3 clients may have pre-shared keys with 365 several different servers. The client indicates which key it uses by 366 including a "PSK identity" in the ClientKeyExchange message. To help 367 the client in selecting which PSK identity / PSK pair to use, the 368 server can provide a "PSK identity hint" in the ServerKeyExchange 369 message. For IoT environments a simplifying assumption is made that 370 the hint for PSK key selection is based on the domain name of the 371 server. Hence, servers SHOULD NOT send the "PSK identity hint" in 372 the ServerKeyExchange message and client MUST ignore the message. 373 This approach is inline with RFC 4279 [RFC4279]. 375 RFC 4279 requires TLS implementations supporting PSK ciphersuites to 376 support arbitrary PSK identities up to 128 octets in length, and 377 arbitrary PSKs up to 64 octets in length. This is a useful 378 assumption for TLS stacks used in the desktop and mobile environment 379 where management interfaces are used to provision identities and 380 keys. For the IoT environment, however, many devices are not 381 equipped with displays and input devices (e.g., keyboards). Hence, 382 keys are distributed as part of hardware modules or are embedded into 383 the firmware. As such, these restrictions are not applicable to this 384 profile. 386 Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] 387 currently specifies TLS_PSK_WITH_AES_128_CCM_8 as the mandatory to 388 implement ciphersuite for use with shared secrets. This ciphersuite 389 uses the AES algorithm with 128 bit keys and CCM as the mode of 390 operation. The label "_8" indicates that an 8-octet authentication 391 tag is used. This ciphersuite makes use of the default TLS 1.2 392 Pseudorandom Function (PRF), which uses HMAC with the SHA-256 hash 393 function. 395 6. Raw Public Key Use with DTLS 397 The use of raw public keys with DTLS, as defined in 398 [I-D.ietf-tls-oob-pubkey], is the first entry point into public key 399 cryptography without having to pay the price of certificates and a 400 PKI. The specification re-uses the existing Certificate message to 401 convey the raw public key encoded in the SubjectPublicKeyInfo 402 structure. To indicate support two new TLS extensions had been 403 defined, as shown in Figure 3, namely the server_certificate_type and 404 the client_certificate_type. To operate this mechanism securely it 405 is necessary to authenticate and authorize the public keys out-of- 406 band. This document therefore assumes that a client implementation 407 comes with one or multiple raw public keys of servers, it has to 408 communicate with, pre-provisioned. Additionally, a device will have 409 its own raw public key. To replace, delete, or add raw public key to 410 this list requires a software update, for example using a firmware 411 update mechanism. 413 Client Server 414 ------ ------ 416 ClientHello --------> 417 client_certificate_type 418 server_certificate_type 420 <------- HelloVerifyRequest 422 ClientHello --------> 423 client_certificate_type 424 server_certificate_type 426 ServerHello 427 client_certificate_type 428 server_certificate_type 429 Certificate 430 ServerKeyExchange 431 CertificateRequest 432 <-------- ServerHelloDone 434 Certificate 435 ClientKeyExchange 436 CertificateVerify 437 [ChangeCipherSpec] 438 Finished --------> 440 [ChangeCipherSpec] 441 <-------- Finished 443 Figure 3: DTLS Raw Public Key Exchange including the Cookie Exchange. 445 The CoAP recommended ciphersuite for use with this credential type is 446 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [I-D.mcgrew-tls-aes-ccm-ecc]. 448 This elliptic curve cryptography (ECC) based AES-CCM TLS ciphersuite 449 uses the Elliptic Curve Diffie Hellman (ECDHE) as the key 450 establishment mechanism and an Elliptic Curve Digital Signature 451 Algorithm (ECDSA) for authentication. This ciphersuite make use of 452 the AEAD capability in DTLS 1.2 and utilizes an eight-octet 453 authentication tag. Based on the Diffie-Hellman it provides perfect 454 forward secrecy (PFS). More details about the PFS can be found in 455 Section 11. 457 RFC 6090 [RFC6090] provides valuable information for implementing 458 Elliptic Curve Cryptography algorithms. 460 Since many IoT devices will either have limited ways to log error or 461 no ability at all, any error will lead to implementations attempting 462 to re-try the exchange. 464 7. Certificate Use with DTLS 466 The use of mutual certificate-based authentication is shown in 467 Figure 4, which makes use of the cached info extension 468 [I-D.ietf-tls-cached-info]. Support of the cached info extension is 469 required. Caching certificate chains allows the client to reduce the 470 communication overhead significantly since otherwise the server would 471 provide the end entity certificate, and the certificate chain. 472 Because certificate validation requires that root keys be distributed 473 independently, the self-signed certificate that specifies the root 474 certificate authority is omitted from the chain. Client 475 implementations MUST be provisioned with a trust anchor store that 476 contains the root certificates. The use of the Trust Anchor 477 Management Protocol (TAMP) [RFC5934] is, however, not envisioned. 478 Instead IoT devices using this profile MUST rely a software update 479 mechanism to provision these trust anchors. 481 When DTLS is used to secure CoAP messages then the server provided 482 certificates MUST contain the fully qualified DNS domain name or 483 "FQDN". The coaps URI scheme is described in Section 6.2 of 484 [I-D.ietf-core-coap]. This FQDN is stored in the SubjectAltName or 485 in the CN, as explained in Section 9.1.3.3 of [I-D.ietf-core-coap], 486 and used by the client to match it against the FQDN used during the 487 look-up process, as described in RFC 6125 [RFC6125]. For the profile 488 in this specification does not assume dynamic discovery of local 489 servers. 491 For client certificates the identifier used in the SubjectAltName or 492 in the CN MUST be an EUI-64 [EUI64], as mandated in Section 9.1.3.3 493 of [I-D.ietf-core-coap]. 495 For certificate revocation neither the Online Certificate Status 496 Protocol (OCSP) nor Certificate Revocation Lists (CRLs) are used. 497 Instead, this profile relies on a software update mechanism. While 498 multiple OCSP stapling [RFC6961] has recently been introduced as a 499 mechanism to piggyback OCSP request/responses inside the DTLS/TLS 500 handshake to avoid the cost of a separate protocol handshake further 501 investigations are needed to determine its suitability for the IoT 502 environment. 504 Client Server 505 ------ ------ 507 ClientHello --------> 508 cached_information 510 <------- HelloVerifyRequest 512 ClientHello --------> 513 cached_information 514 ServerHello 515 cached_information 516 Certificate 517 ServerKeyExchange 518 CertificateRequest 519 <-------- ServerHelloDone 521 Certificate 522 ClientKeyExchange 523 CertificateVerify 524 [ChangeCipherSpec] 525 Finished --------> 527 [ChangeCipherSpec] 528 <-------- Finished 530 Figure 4: DTLS Mutual Certificate-based Authentication. 532 Regarding the ciphersuite choice the discussion in Section 6 applies. 533 Further details about X.509 certificates can be found in 534 Section 9.1.3.3 of [I-D.ietf-core-coap]. 536 QUESTION: What restrictions regarding the depth of the certificate 537 chain should be made? Is one level enough? 539 8. Error Handling 541 DTLS uses the Alert protocol to convey error messages and specifies a 542 longer list of errors. However, not all error messages defined in 543 the TLS specification are applicable to this profile. All error 544 messages marked as RESERVED are only supported for backwards 545 compatibility with SSL and are therefore not applicable to this 546 profile. Those include decryption_failed_RESERVED, 547 no_certificate_RESERVE, and export_restriction_RESERVED. A number of 548 the error messages are applicable only for certificate-based 549 authentication ciphersuites. Hence, for PSK and raw public key use 550 the following error messages are not applicable: bad_certificate, 551 unsupported_certificate, certificate_revoked, certificate_expired, 552 certificate_unknown, unknown_ca, and access_denied. 554 Since this profile does not make use of compression at the TLS layer 555 the decompression_failure error message is not applicable either. 557 RFC 4279 introduced a new alert message unknown_psk_identity for PSK 558 ciphersuites. As stated in Section 2 of RFC 4279 the 559 decryption_error error message may also be used instead. For this 560 profile the TLS server MUST return the decryption_error error message 561 instead of the unknown_psk_identity. 563 Furthermore, the following errors should not occur based on the 564 description in this specification: 566 protocol_version: This document only focuses on one version of the 567 DTLS protocol. 569 insufficient_security: This error message indicates that the server 570 requires ciphers to be more secure. This document does, however, 571 specify the only acceptable ciphersuites and client 572 implementations must support them. 574 user_canceled: The IoT devices in focus of this specification are 575 assumed to be unattended. 577 9. Session Resumption 579 Session resumption is a feature of DTLS that allows a client to 580 continue with an earlier established session state. The resulting 581 exchange is shown in Figure 5. In addition, the server may choose 582 not to do a cookie exchange when a session is resumed. Still, 583 clients have to be prepared to do a cookie exchange with every 584 handshake. 586 Client Server 587 ------ ------ 589 ClientHello --------> 590 ServerHello 591 [ChangeCipherSpec] 592 <-------- Finished 593 [ChangeCipherSpec] 594 Finished --------> 595 Application Data <-------> Application Data 597 Figure 5: DTLS Session Resumption. 599 Clients MUST implement session resumption to improve the performance 600 of the handshake (in terms of reduced number of message exchanges, 601 lower computational overhead, and less bandwidth conserved). 603 Since the communication model described in Section 3 does not assume 604 that the server is constrained. RFC 5077 [RFC5077] describing TLS 605 session resumption without server-side state is not utilized by this 606 profile. 608 10. TLS Compression 610 [I-D.sheffer-tls-bcp] recommends to always disable DTLS-level 611 compression due to attacks. For IoT applications compression at the 612 DTLS is not needed since application layer protocols are highly 613 optimized and the compression algorithms at the DTLS layer increase 614 code size and complexity. Hence, for use with this profile 615 compression at the DTLS layer SHOULD NOT be implemented by the DTLS 616 client. 618 11. Perfect Forward Secrecy 620 Perfect forward secrecy is designed to prevent the compromise of a 621 long-term secret key from affecting the confidentiality of past 622 conversations. The PSK ciphersuite recommended in the CoAP 623 specification [I-D.ietf-core-coap] does not offer this property. 624 [I-D.sheffer-tls-bcp] on the other hand recommends using ciphersuites 625 offering this security property. 627 QUESTION: Should the PSK ciphersuite offer PFS? 629 12. Keep-Alive 631 RFC 6520 [RFC6520] defines a heartbeat mechanism to test whether the 632 other peer is still alive. The same mechanism can also be used to 633 perform path MTU discovery. 635 QUESTION: Do IoT deployments make use of this extension? 637 13. Negotiation and Downgrading Attacks 639 CoAP demands version 1.2 of DTLS to be used and the earlier version 640 of DTLS is not supported. As such, there is no risk of downgrading 641 to an older version of DTLS. The work described in 642 [I-D.bmoeller-tls-downgrade-scsv] is therefore also not applicable to 643 this environment since there is no legacy server infrastructure to 644 worry about. 646 QUESTION: Should we say something for non-CoAP use of DTLS? 648 To prevent the TLS renegotiation attack [RFC5746] clients MUST 649 respond to server-initiated renegotiation attempts with an Alert 650 message (no_renegotiation) and clients MUST NOT initiate them. TLS 651 and DTLS allows a client and a server who already have a TLS 652 connection to negotiate new parameters, generate new keys, etc by 653 initiating a TLS handshake using a ClientHello message. 654 Renegotiation happens in the existing TLS connection, with the new 655 handshake packets being encrypted along with application data. 657 14. Privacy Considerations 659 The DTLS handshake exchange conveys various identifiers, which can be 660 observed by an on-path eavesdropper. For example, the DTLS PSK 661 exchange reveals the PSK identity, the supported extensions, the 662 session id, algorithm parameters, etc. When session resumption is 663 used then individual TLS sessions can be correlated by an on-path 664 adversary. With many IoT deployments it is likely that keying 665 material and their identifiers are persistent over a longer period of 666 time due to the cost of updating software on these devices. 668 User participation with many IoT deployments poses a challenge since 669 many of the IoT devices operate unattended, even though they will 670 initially be enabled by a human. The ability to control data sharing 671 and to configure preference will have to be provided at a system 672 level rather than at the level of a DTLS profile, which is the scope 673 of this document. Quite naturally, the use of DTLS with mutual 674 authentication will allow a TLS server to collect authentication 675 information about the IoT device (potentially over a long period of 676 time). While this strong form of authentication will prevent mis- 677 attribution it also allows strong identification. This device- 678 related data collection (e.g., sensor recordings) will be associated 679 with other data to be truly useful and this extra data might include 680 personal data about the owner of the device or data about the 681 environment it senses. Consequently, the data stored on the server- 682 side will be vulnerable to stored data compromise. For the 683 communication between the client and the server this specification 684 prevents eavesdroppers to gain access to the communication content. 685 While the PSK-based ciphersuite does not provide PFS the asymmetric 686 version does. No explicit techniques, such as extra padding, have 687 been provided to make traffic analysis more difficult. 689 15. Security Considerations 691 This entire document is about security. 693 The TLS protocol requires random numbers to be available during the 694 protocol run. For example, during the ClientHello and the 695 ServerHello exchange the client and the server exchange random 696 numbers. Also, the use of the Diffie Hellman exchange requires 697 random numbers during the key pair generation. Special care has to 698 be paid when generating random numbers in embedded systems as many 699 entropy sources available on desktop operating systems or mobile 700 devices might be missing, as described in [Heninger]. Consequently, 701 if not enough time is given during system start time to fill the 702 entropy pool then the output might be predictable and repeatable, for 703 example leading to the same keys generated again and again. 704 Guidelines and requirements for random number generation can be found 705 in RFC 4086 [RFC4086]. 707 We would also like to point out that designing a software update 708 mechanism into an IoT system is crucial to ensure that both 709 functionality can be enhanced and that potential vulnerabilities can 710 be fixed. This software update mechanism is also useful for changing 711 configuration information, for example, trust anchors and other 712 keying related information. 714 16. IANA Considerations 716 This document includes no request to IANA. 718 17. Acknowledgements 720 Thanks to Rene Hummen, Sye Loong Keoh, Sandeep Kumar, Eric Rescorla, 721 Zach Shelby, and Sean Turner for helpful comments and discussions 722 that have shaped the document. 724 18. References 726 18.1. Normative References 728 [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 729 REGISTRATION AUTHORITY", April 2010, 730 . 733 [I-D.ietf-tls-cached-info] 734 Santesson, S. and H. Tschofenig, "Transport Layer Security 735 (TLS) Cached Information Extension", draft-ietf-tls- 736 cached-info-16 (work in progress), February 2014. 738 [I-D.ietf-tls-oob-pubkey] 739 Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 740 T. Kivinen, "Using Raw Public Keys in Transport Layer 741 Security (TLS) and Datagram Transport Layer Security 742 (DTLS)", draft-ietf-tls-oob-pubkey-11 (work in progress), 743 January 2014. 745 [I-D.mcgrew-tls-aes-ccm-ecc] 746 McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 747 CCM ECC Cipher Suites for TLS", draft-mcgrew-tls-aes-ccm- 748 ecc-08 (work in progress), February 2014. 750 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 751 Requirement Levels", BCP 14, RFC 2119, March 1997. 753 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 754 for Transport Layer Security (TLS)", RFC 4279, December 755 2005. 757 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 758 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 760 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 761 "Transport Layer Security (TLS) Renegotiation Indication 762 Extension", RFC 5746, February 2010. 764 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 765 Extension Definitions", RFC 6066, January 2011. 767 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 768 Verification of Domain-Based Application Service Identity 769 within Internet Public Key Infrastructure Using X.509 770 (PKIX) Certificates in the Context of Transport Layer 771 Security (TLS)", RFC 6125, March 2011. 773 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 774 Security Version 1.2", RFC 6347, January 2012. 776 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 777 Layer Security (TLS) and Datagram Transport Layer Security 778 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 780 18.2. Informative References 782 [Heninger] 783 Heninger, N., Durumeric, Z., Wustrow, E., and A. 784 Halderman, "Mining Your Ps and Qs: Detection of Widespread 785 Weak Keys in Network Devices", 21st USENIX Security 786 Symposium, https://www.usenix.org/conference/ 787 usenixsecurity12/technical-sessions/presentation/heninger, 788 2012. 790 [I-D.bmoeller-tls-downgrade-scsv] 791 Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 792 Suite Value (SCSV) for Preventing Protocol Downgrade 793 Attacks", draft-bmoeller-tls-downgrade-scsv-01 (work in 794 progress), November 2013. 796 [I-D.campagna-suitee] 797 Campagna, M., "A Cryptographic Suite for Embedded Systems 798 (SuiteE)", draft-campagna-suitee-04 (work in progress), 799 October 2012. 801 [I-D.cooper-ietf-privacy-requirements] 802 Cooper, A., Farrell, S., and S. Turner, "Privacy 803 Requirements for IETF Protocols", draft-cooper-ietf- 804 privacy-requirements-01 (work in progress), October 2013. 806 [I-D.greevenbosch-tls-ocsp-lite] 807 Greevenbosch, B., "OCSP-lite - Revocation of raw public 808 keys", draft-greevenbosch-tls-ocsp-lite-01 (work in 809 progress), June 2013. 811 [I-D.gutmann-tls-encrypt-then-mac] 812 Gutmann, P., "Encrypt-then-MAC for TLS and DTLS", draft- 813 gutmann-tls-encrypt-then-mac-05 (work in progress), 814 December 2013. 816 [I-D.hummen-dtls-extended-session-resumption] 817 Hummen, R., Gilger, J., and H. Shafagh, "Extended DTLS 818 Session Resumption for Constrained Network Environments", 819 draft-hummen-dtls-extended-session-resumption-01 (work in 820 progress), October 2013. 822 [I-D.ietf-core-coap] 823 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 824 Application Protocol (CoAP)", draft-ietf-core-coap-18 825 (work in progress), June 2013. 827 [I-D.ietf-lwig-guidance] 828 Bormann, C., "Guidance for Light-Weight Implementations of 829 the Internet Protocol Suite", draft-ietf-lwig-guidance-03 830 (work in progress), February 2013. 832 [I-D.ietf-lwig-terminology] 833 Bormann, C., Ersue, M., and A. Keranen, "Terminology for 834 Constrained Node Networks", draft-ietf-lwig-terminology-07 835 (work in progress), February 2014. 837 [I-D.ietf-lwig-tls-minimal] 838 Kumar, S., Keoh, S., and H. Tschofenig, "A Hitchhiker's 839 Guide to the (Datagram) Transport Layer Security Protocol 840 for Smart Objects and Constrained Node Networks", draft- 841 ietf-lwig-tls-minimal-01 (work in progress), March 2014. 843 [I-D.ietf-tls-applayerprotoneg] 844 Friedl, S., Popov, A., Langley, A., and S. Emile, 845 "Transport Layer Security (TLS) Application Layer Protocol 846 Negotiation Extension", draft-ietf-tls-applayerprotoneg-05 847 (work in progress), March 2014. 849 [I-D.pettersen-tls-version-rollback-removal] 850 Pettersen, Y., "Managing and removing automatic version 851 rollback in TLS Clients", draft-pettersen-tls-version- 852 rollback-removal-03 (work in progress), February 2014. 854 [I-D.sheffer-tls-bcp] 855 Sheffer, Y., Holz, R., and P. Saint-Andre, 856 "Recommendations for Secure Use of TLS and DTLS", draft- 857 sheffer-tls-bcp-02 (work in progress), February 2014. 859 [IANA-TLS] 860 IANA, "TLS Cipher Suite Registry", http://www.iana.org/ 861 assignments/tls-parameters/ 862 tls-parameters.xhtml#tls-parameters-4, 2014. 864 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 865 Text on Security Considerations", BCP 72, RFC 3552, July 866 2003. 868 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 869 Requirements for Security", BCP 106, RFC 4086, June 2005. 871 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 872 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 873 for Transport Layer Security (TLS)", RFC 4492, May 2006. 875 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 876 "Transport Layer Security (TLS) Session Resumption without 877 Server-Side State", RFC 5077, January 2008. 879 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 880 Encryption", RFC 5116, January 2008. 882 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 883 Housley, R., and W. Polk, "Internet X.509 Public Key 884 Infrastructure Certificate and Certificate Revocation List 885 (CRL) Profile", RFC 5280, May 2008. 887 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with 888 SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 889 August 2008. 891 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 892 Management Protocol (TAMP)", RFC 5934, August 2010. 894 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 895 Curve Cryptography Algorithms", RFC 6090, February 2011. 897 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 898 Transport Layer Security (TLS)", RFC 6655, July 2012. 900 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 901 Multiple Certificate Status Request Extension", RFC 6961, 902 June 2013. 904 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 905 Morris, J., Hansen, M., and R. Smith, "Privacy 906 Considerations for Internet Protocols", RFC 6973, July 907 2013. 909 Authors' Addresses 911 Klaus Hartke 912 Universitaet Bremen TZI 913 Postfach 330440 914 Bremen D-28359 915 Germany 917 Phone: +49-421-218-63905 918 Email: hartke@tzi.org 919 Hannes Tschofenig 920 ARM Ltd. 921 110 Fulbourn Rd 922 Cambridge CB1 9NJ 923 Great Britain 925 Email: Hannes.tschofenig@gmx.net 926 URI: http://www.tschofenig.priv.at