idnits 2.17.00 (12 Aug 2021) /tmp/idnits45907/draft-ietf-dice-profile-08.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 (December 21, 2014) is 2707 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 1041, but not defined == Unused Reference: 'I-D.ietf-lwig-tls-minimal' is defined on line 1694, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 1799, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' -- Possible downref: Non-RFC (?) normative reference: ref. 'GSM-SMS' == 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 -- Possible downref: Non-RFC (?) normative reference: ref. 'WAP-WDP' == Outdated reference: A later version (-04) exists of draft-bormann-core-cocoa-02 == Outdated reference: draft-iab-smart-object-architecture has been published as RFC 7452 == Outdated reference: draft-ietf-core-resource-directory has been published as RFC 9176 == Outdated reference: draft-ietf-tls-downgrade-scsv has been published as RFC 7507 == Outdated reference: draft-ietf-tls-prohibiting-rc4 has been published as RFC 7465 == Outdated reference: draft-ietf-tls-sslv3-diediedie has been published as RFC 7568 == Outdated reference: draft-ietf-uta-tls-bcp has been published as RFC 7525 == Outdated reference: draft-irtf-cfrg-chacha20-poly1305 has been published as RFC 7539 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) -- Obsolete informational reference (is this intentional?): RFC 4634 (Obsoleted by RFC 6234) -- 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 (~~), 15 warnings (==), 9 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 T. Fossati 5 Expires: June 24, 2015 Alcatel-Lucent 6 December 21, 2014 8 A TLS/DTLS 1.2 Profile for the Internet of Things 9 draft-ietf-dice-profile-08.txt 11 Abstract 13 A common design pattern in Internet of Things (IoT) deployments is 14 the use of a constrained device (typically providing sensor data) 15 that makes data available for home automation, industrial control 16 systems, smart cities and other IoT deployments. 18 This document defines a Transport Layer Security (TLS) and Datagram 19 TLS 1.2 profile that offers communications security for this data 20 exchange thereby preventing eavesdropping, tampering, and message 21 forgery. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 24, 2015. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. TLS/DTLS Protocol Overview . . . . . . . . . . . . . . . . . 4 60 4. Communication Models . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Constrained TLS/DTLS Clients . . . . . . . . . . . . . . 5 62 4.2. Constrained TLS/DTLS Servers . . . . . . . . . . . . . . 12 63 5. The TLS/DTLS Ciphersuite Concept . . . . . . . . . . . . . . 14 64 6. Credential Types . . . . . . . . . . . . . . . . . . . . . . 15 65 6.1. Pre-Shared Secret . . . . . . . . . . . . . . . . . . . . 15 66 6.2. Raw Public Key . . . . . . . . . . . . . . . . . . . . . 17 67 6.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 19 68 7. Signature Algorithm Extension . . . . . . . . . . . . . . . . 22 69 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 22 70 9. Session Resumption . . . . . . . . . . . . . . . . . . . . . 23 71 10. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 24 72 11. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 24 73 12. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 25 74 13. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 27 75 14. Random Number Generation . . . . . . . . . . . . . . . . . . 27 76 15. Truncated MAC and Encrypt-then-MAC Extension . . . . . . . . 28 77 16. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 29 78 17. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 29 79 18. Session Hash . . . . . . . . . . . . . . . . . . . . . . . . 29 80 19. Re-Negotiation Attacks . . . . . . . . . . . . . . . . . . . 30 81 20. Downgrading Attacks . . . . . . . . . . . . . . . . . . . . . 30 82 21. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 31 83 22. Key Length Recommendations . . . . . . . . . . . . . . . . . 32 84 23. False Start . . . . . . . . . . . . . . . . . . . . . . . . . 33 85 24. Privacy Considerations . . . . . . . . . . . . . . . . . . . 34 86 25. Security Considerations . . . . . . . . . . . . . . . . . . . 34 87 26. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 88 27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 89 28. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 90 28.1. Normative References . . . . . . . . . . . . . . . . . . 35 91 28.2. Informative References . . . . . . . . . . . . . . . . . 36 92 Appendix A. Conveying DTLS over SMS . . . . . . . . . . . . . . 41 93 A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 41 94 A.2. Message Segmentation and Re-Assembly . . . . . . . . . . 42 95 A.3. Multiplexing Security Associations . . . . . . . . . . . 42 96 A.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 43 98 Appendix B. DTLS Record Layer Per-Packet Overhead . . . . . . . 43 99 Appendix C. DTLS Fragmentation . . . . . . . . . . . . . . . . . 44 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 102 1. Introduction 104 An engineer developing an Internet of Things (IoT) device needs to 105 investigate the security threats and decide about the security 106 services that can be used to mitigate these threats. 108 Enabling IoT devices to make data available often requires 109 authentication of the two endpoints and the ability to provide 110 integrity- and confidentiality-protection of exchanged data. While 111 these security services can be provided at different layers in the 112 protocol stack the use of Transport Layer Security (TLS)/Datagram TLS 113 (DTLS) has been very popular with many application protocols and it 114 is likely to be useful for IoT scenarios as well. 116 To make Internet protocols fit constrained devices can be difficult 117 but thanks to the standardization efforts new profiles and protocols 118 are available, such as the Constrained Application Protocol (CoAP) 119 [RFC7252]. UDP is mainly used to carry CoAP messages but other 120 transports can be utilized, such as SMS or even TCP. 122 While this document is inspired by the desire to protect CoAP 123 messages using DTLS 1.2 [RFC6347] the guidance in this document is 124 not limited to CoAP nor to DTLS itself. 126 Instead, this document defines a profile of DTLS 1.2 [RFC6347] and 127 TLS 1.2 [RFC5246] that offers communication security for IoT 128 applications and is reasonably implementable on many constrained 129 devices. Profile thereby means that available configuration options 130 and protocol extensions are utilized to best support the IoT 131 environment. This document does not alter TLS/DTLS specifications 132 and does not introduce any new TLS/DTLS extensions. 134 The main target audience for this document is the embedded system 135 developer configuring and using a TLS/DTLS stack. This document may, 136 however, also help those developing or selecting a suitable TLS/DTLS 137 stack for an Internet of Things product development. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 Note that "Client" and "Server" in this document refer to TLS/DTLS 146 roles, where the Client initiates the TLS/DTLS handshake. This does 147 not restrict the interaction pattern of the protocols on top of TLS/ 148 DTLS since the record layer allows bi-directional communication. 149 This aspect is further described in Section 4. 151 RFC 7228 [RFC7228] introduces the notion of constrained-node 152 networks, which are small devices with severe constraints on power, 153 memory, and processing resources. The terms constrained devices, and 154 Internet of Things (IoT) devices are used interchangeably. 156 3. TLS/DTLS Protocol Overview 158 The TLS protocol [RFC5246] provides authenticated, confidentiality- 159 and integrity-protected communication between two endpoints. The 160 protocol is composed of two layers: the Record Protocol and the 161 Handshake Protocol. At the lowest level, layered on top of a 162 reliable transport protocol (e.g., TCP), is the Record Protocol. It 163 provides connection security by using symmetric cryptography for 164 confidentiality, data origin authentication, and integrity 165 protection. The Record Protocol is used for encapsulation of various 166 higher-level protocols. One such encapsulated protocol, the 167 Handshake Protocol, allows the server and client to authenticate each 168 other and to negotiate an encryption algorithm and cryptographic keys 169 before the application protocol transmits or receives data. 171 The design of DTLS [RFC6347] is intentionally very similar to TLS. 172 Since DTLS operates on top of an unreliable datagram transport a few 173 enhancements to the TLS structure are, however necessary. RFC 6347 174 explains these differences in great detail. As a short summary, for 175 those not familiar with DTLS the differences are: 177 o An explicit sequence number and an epoch field is included in the 178 Record Protocol. Section 4.1 of RFC 6347 explains the processing 179 rules for these two new fields. The value used to compute the MAC 180 is the 64-bit value formed by concatenating the epoch and the 181 sequence number. 183 o Stream ciphers must not be used with DTLS. The only stream cipher 184 defined for TLS 1.2 is RC4 and due to cryptographic weaknesses it 185 is not recommended anymore even for use with TLS 186 [I-D.ietf-tls-prohibiting-rc4]. Note that the term 'stream 187 cipher' is a technical term in the TLS specification. Section 4.7 188 of RFC 5246 defines stream ciphers in TLS as follows. In stream 189 cipher encryption, the plaintext is exclusive-ORed with an 190 dentical amount of output generated from a cryptographically 191 secure keyed pseudorandom number generator. 193 o The TLS Handshake Protocol has been enhanced to include a 194 stateless cookie exchange for Denial of Service (DoS) resistance. 195 For this purpose a new handshake message, the HelloVerifyRequest, 196 was added to DTLS. This handshake message is sent by the server 197 and includes a stateless cookie, which is returned in a 198 ClientHello message back to the server. Although the exchange is 199 optional for the server to execute, a client implementation has to 200 be prepared to respond to it. Furthermore, the handshake message 201 format has been extended to deal with message loss, reordering, 202 and fragmentation. Retransmission timers have been included to 203 deal with message loss. 205 4. Communication Models 207 This document describes a profile of TLS/DTLS 1.2 and, to be useful, 208 it has to make assumptions about the envisioned communication 209 architecture. 211 Two communication architectures (and consequently two profiles) are 212 described in this document. 214 4.1. Constrained TLS/DTLS Clients 216 The communication architecture shown in Figure 1 assumes a unicast 217 communication interaction with an IoT device utilizing a constrained 218 TLS/DTLS client interacting with one or multiple TLS/DTLS servers. 220 Before a client can initiate the TLS/DTLS handshake it needs to know 221 the IP address of that server and what credentials to use. 222 Application layer protocols, such as CoAP, conveyed on top of DTLS 223 may need additional information, such information about URLs of the 224 endpoints the CoAP needs to register and publish information to. 225 This configuration information (including credentials) may be 226 conveyed to clients as part of a firmware/software package or via a 227 configuration protocol. The following credential types are supported 228 by this profile: 230 o For PSK-based authentication (see Section 6.1), this includes the 231 paired "PSK identity" and shared secret to be used with each 232 server. 234 o For raw public key-based authentication (see Section 6.2), this 235 includes either the server's public key or the hash of the 236 server's public key. 238 o For certificate-based authentication (see Section 6.3), this 239 includes a pre-populated trust anchor store that allows the DTLS 240 stack to perform path validation for the certificate obtained 241 during the handshake with the server. 243 This document focuses on the description of the DTLS client-side 244 functionality but, quite naturally, the equivalent server-side 245 support has to be available. 247 +////////////////////////////////////+ 248 | Configuration | 249 |////////////////////////////////////| 250 | Server A --> PSK Identity, PSK | 251 | Server B --> Public Key (Server B),| 252 | Public Key (Client) | 253 | Server C --> Public Key (Client), | 254 | Trust Anchor Store | 255 +------------------------------------+ 256 oo 257 oooooo 258 o 259 +-----------+ 260 |Constrained| 261 |TLS/DTLS | 262 |Client |- 263 +-----------+ \ 264 \ ,-------. 265 ,' `. +------+ 266 / IP-based \ |Server| 267 ( Network ) | A | 268 \ / +------+ 269 `. ,' 270 '---+---' +------+ 271 | |Server| 272 | | B | 273 | +------+ 274 | 275 | +------+ 276 +----------------->|Server| 277 | C | 278 +------+ 280 Figure 1: Constrained Client Profile. 282 4.1.1. Examples of Constrained Client Exchanges 284 4.1.1.1. Network Access Authentication Example 286 Re-use is a recurring theme when considering constrained environments 287 and is behind a lot of the directions taken in developments for 288 constrained environments. The corollary of re-use is to not add 289 functionality if it can be avoided. An example relevant to the use 290 of TLS is network access authentication, which takes place when a 291 device connects to a network and needs to go through an 292 authentication and access control procedure before it is allowed to 293 communicate with other devices or connect to the Internet. 295 Figure 2 shows the network access architecture with the IoT device 296 initiating the communication to an access point in the network using 297 the procedures defined for a specific physical layer. Since 298 credentials may be managed and stored centrally, in the 299 Authentication, Authorization, and Accounting (AAA) server, the 300 security protocol exchange may need to be relayed via the 301 Authenticator, i.e., functionality running on the access point, to 302 the AAA server. The authentication and key exchange protocol itself 303 is encapsulated within a container, the Extensible Authentication 304 Protocol (EAP), and messages are conveyed back and forth between the 305 EAP endpoints, namely the EAP peer located on the IoT device and the 306 EAP server located on the AAA server or the access point. To route 307 EAP messages from the access point, acting as a AAA client, to the 308 AAA server requires an adequate protocol mechanism, name RADIUS or 309 Diameter. 311 More details about the concepts and a description about the 312 terminology can be found in RFC 5247 [RFC5247]. 314 +--------------+ 315 |Authentication| 316 |Authorization | 317 |Accounting | 318 |Server | 319 |(EAP Server) | 320 | | 321 +-^----------^-+ 322 * EAP o RADIUS/ 323 * o Diameter 324 --v----------v-- 325 /// \\\ 326 // \\ 327 | Federation | 328 | Substrate | 329 \\ // 330 \\\ /// 331 --^----------^-- 332 * EAP o RADIUS/ 333 * o Diameter 334 +-------------+ +-v----------v--+ 335 | | EAP/EAP Method | | 336 | Internet of |<***************************>| Access Point | 337 | Things | |(Authenticator)| 338 | Device | EAP Lower Layer and |(AAA Client) | 339 | (EAP Peer) | Secure Association Protocol | | 340 | |<--------------------------->| | 341 | | | | 342 | | Physical Layer | | 343 | |<===========================>| | 344 +-------------+ +---------------+ 345 Legend: 347 <****>: Device-to-AAA Server Exchange 348 <---->: Device-to-Authenticator Exchange 349 : AAA Client-to-AAA Server Exchange 350 <====>: Phyiscal layer like IEEE 802.11/802.15.4 352 Figure 2: Network Access Architecture.. 354 One standardized EAP method is EAP-TLS, defined in RFC 5216 355 [RFC5216], which re-uses the TLS-based protocol exchange and 356 encapsulates it inside the EAP payload. In terms of re-use this 357 allows many components of the TLS protocol to be shared between the 358 network access security functionality and the TLS functionality 359 needed for securing application layer traffic. The EAP-TLS exchange 360 is shown in Figure 3 where it is worthwhile to point out that in EAP 361 the client / server roles are reversed but with the use of EAP-TLS 362 the IoT device acts as a TLS client. 364 Authenticating Peer Authenticator 365 ------------------- ------------- 366 <- EAP-Request/ 367 Identity 368 EAP-Response/ 369 Identity (MyID) -> 370 <- EAP-Request/ 371 EAP-Type=EAP-TLS 372 (TLS Start) 373 EAP-Response/ 374 EAP-Type=EAP-TLS 375 (TLS client_hello)-> 376 <- EAP-Request/ 377 EAP-Type=EAP-TLS 378 (TLS server_hello, 379 TLS certificate, 380 [TLS server_key_exchange,] 381 TLS certificate_request, 382 TLS server_hello_done) 383 EAP-Response/ 384 EAP-Type=EAP-TLS 385 (TLS certificate, 386 TLS client_key_exchange, 387 TLS certificate_verify, 388 TLS change_cipher_spec, 389 TLS finished) -> 390 <- EAP-Request/ 391 EAP-Type=EAP-TLS 392 (TLS change_cipher_spec, 393 TLS finished) 394 EAP-Response/ 395 EAP-Type=EAP-TLS -> 396 <- EAP-Success 398 Figure 3: EAP-TLS Exchange. 400 The guidance in this document also applies to the use of EAP-TLS for 401 network access authentication. An IoT device using a network access 402 authentication solution based on TLS can re-use most parts of the 403 code for the use of DTLS/TLS at the application layer thereby saving 404 a significant amount of flash memory. Note, however, that the 405 credentials used for network access authentication and those used for 406 application layer security are very likely different. 408 4.1.1.2. CoAP-based Data Exchange Example 410 When a constrained client uploads sensor data to a server 411 infrastructure it may use CoAP by pushing the data via a POST message 412 to a pre-configured endpoint on the server. In certain circumstances 413 this might be too limiting and additional functionality is needed, as 414 shown in Figure 4, where the IoT device itself runs a CoAP server 415 hosting the resource that is made accessible to other entities. 416 Despite running a CoaP server on the IoT device it is still the DTLS 417 client on the IoT device that initiates the interaction with the non- 418 constrained resource server in our scenario. 420 Figure 4 shows a sensor starting with a DTLS exchange with a resource 421 directory to register available resources. 422 [I-D.ietf-core-resource-directory] defines the resource directory as 423 a web entity that stores information about web resources and 424 implements the REST interfaces defined in 425 [I-D.ietf-core-resource-directory] for registration and lookup of 426 those resources. 428 The initial DTLS interaction between the sensor, acting as a DTLS 429 client, and the resource directory, acting as a DTLS server, will be 430 a full DTLS handshake. Once this handshake is complete both parties 431 have established the DTLS record layer. Subsequently, the CoAP 432 client can securely register at the resource directory. Details 433 about the capabilities of the resource directory can be found in 434 [I-D.ietf-core-resource-directory]. 436 After some time (assuming that the client regularly refreshes its 437 registration) the resource directory receives a request (not shown in 438 the figure) from an application to retrieve the temperature 439 information from the sensor. This request is relayed by the resource 440 directory to the sensor using a GET message exchange. The already 441 established DTLS record layer can be used to secure the message 442 exchange. 444 Resource 445 Sensor Directory 446 ------ --------- 448 +--- 449 | 450 | ClientHello --------> 451 | client_certificate_type 452 F| server_certificate_type 453 U| 454 L| <------- HelloVerifyRequest 455 L| 456 | ClientHello --------> 457 D| client_certificate_type 458 T| server_certificate_type 459 L| 460 S| ServerHello 461 | client_certificate_type 462 H| server_certificate_type 463 A| Certificate 464 N| ServerKeyExchange 465 D| CertificateRequest 466 S| <-------- ServerHelloDone 467 H| 468 A| Certificate 469 K| ClientKeyExchange 470 E| CertificateVerify 471 | [ChangeCipherSpec] 472 | Finished --------> 473 | 474 | [ChangeCipherSpec] 475 | <-------- Finished 476 +--- 478 +--- ///+ 479 C| \ D 480 O| Req: POST coap://rd.example.com/rd?ep=node1 \ T 481 A| Payload: \ L 482 P| ;ct=41; \ S 483 | rt="temperature-c";if="sensor", \ 484 R| ;ct=41; \ R 485 D| rt="light-lux";if="sensor" \ E 486 | --------> \ C 487 R| \ O 488 E| \ R 489 G| Res: 2.01 Created \ D 490 .| <-------- Location: /rd/4521 \ 491 | \ L 492 +--- \ A 493 \ Y 494 * \ E 495 * (time passes) \ R 496 * \ 497 +--- \ P 498 C| \ R 499 O| Req: GET coaps://sensor.example.com/temp \ O 500 A| <-------- \ T 501 P| \ E 502 | Res: 2.05 Content \ C 504 G| Payload: \ T 505 E| 25.5 --------> \ E 506 T| \ D 507 +--- ///+ 509 Figure 4: DTLS/CoAP exchange using Resource Directory. 511 4.2. Constrained TLS/DTLS Servers 513 Section 4.1 illustrates deployment models where the TLS/DTLS client 514 is constrained and efforts need to be taken to improve memory 515 utilization, bandwidth consumption, reduce performance impacts, etc. 516 In this section we look at cases where constrained devices run TLS/ 517 DTLS servers to secure access to an application layer protocol 518 server, like a CoAP or HTTP server. Running server functionality on 519 a constrained node is typically more demanding since servers have to 520 listen and wait for incoming requests. Therefore, they will have 521 fewer possibilities to enter sleeping cycles. Nevertheless, there 522 are legitimate reasons to deploy servers as constrained devices. 524 A deployment with constrained servers has to overcome several 525 challenges. Later we will explain how these challenges has been 526 solved using CoAP as an example. Other protocols may offer similar 527 capabilities. While the requirements for the TLS/DTLS protocol 528 profile change only slightly when run on a constrained server (in 529 comparison to running it on a constrained client) several other eco- 530 system factor will impact deployment. 532 The challenges are: 534 Discovery and Reachability: 536 Before initiating a connection to a constrained server a client 537 first needs to discover that server and, once discovered, it needs 538 to maintain reachability with that device. 540 In CoAP the discovery of resources offered by servers is 541 accomplished by sending a unicast or multicast CoAP GET to a well- 542 known URI. The CORE Link format specification [RFC6690] describes 543 the use case (see Section 1.2.1), and reserves the URI (see 544 Section 7.1). Section 7 of the CoAP specification [RFC7252] 545 describes the discovery procedure. RFC 7390 [RFC7390] describes 546 use case for discovering CoAP servers using multicast (see 547 Section 3.3), and specifies the protocol processing rules for CoAP 548 group communications (see Section 2.7). 550 Authentication: 552 The next challenge concerns the provisioning of authentication 553 credentials to the clients as well as servers. In Section 4.1 we 554 assumed that credentials (and other configuration information) are 555 provisioned to the device and that those can be used with the 556 authorization servers. Of course, this leads to a very static 557 relationship between the clients and their server-side 558 infrastructure but poses fewer challenges from a deployment point 559 of view, as described in Section 2 of 560 [I-D.iab-smart-object-architecture] these different communication 561 patterns. In any case, engineers and product designers have to 562 determine how the relevant credentials are distributed to the 563 respective parties. For example, shared secrets may need to be 564 provisioned to clients and the constrained servers for subsequent 565 use of TLS/DTLS PSK. In other deployments, certificates, private 566 keys, and trust anchors for use with certificate-based 567 authentication may need to be utilized. 569 Practical solutions either use pairing (also called imprinting) or 570 a trusted third party. With pairing two devices execute a special 571 protocol exchange that is unauthenticated to establish an shared 572 key (for example using an unauthenticated Diffie-Hellman exchange) 573 key. To avoid man-in-the-middle attacks an out-of-band channel is 574 used to verify that nobody has tampered with the exchanged 575 protocol messages. This out-of-band channel can come in many 576 forms, including: 578 * Human involvement by comparing hashed keys, entering passkeys, 579 scanning QR codes 581 * The use of alternative wireless communication channels (e.g., 582 infra-red communication in addition to WiFi) 584 * Proximity-based information 586 More details about these different pairing/imprinting techniques 587 can be found in the smart object security workshop report 588 [RFC7397] and various position papers submitted to that topic, 589 such as [ImprintingSurvey]. The use of a trusted third party 590 follows a different approach and is subject to ongoing 591 standardization efforts in the 'Authentication and Authorization 592 for Constrained Environments (ACE)' working group. 594 Authorization 596 The last challenge is the ability for the constrained server to 597 make an authorization decision when clients access protected 598 resources. Pre-provisioning access control information to 599 constrained servers may be one option but works only in a small 600 scale, less dynamic environment. For a more fine-grained and 601 dynamic access control the reader is referred to the ongoing work 602 in the ACE working group. 604 5. The TLS/DTLS Ciphersuite Concept 606 TLS (and consequently DTLS) has the concept of ciphersuites and an 607 IANA registry [IANA-TLS] was created to register the suites. A 608 ciphersuite (and the specification that defines it) contains the 609 following information: 611 o Authentication and key exchange algorithm (e.g., PSK) 613 o Cipher and key length (e.g., Advanced Encryption Standard (AES) 614 with 128 bit keys [AES]) 616 o Mode of operation (e.g., Counter with Cipher Block Chaining - 617 Message Authentication Code (CBC-MAC) Mode (CCM) for AES) 618 [RFC3610] 620 o Hash algorithm for integrity protection, such as the Secure Hash 621 Algorithm (SHA) in combination with Keyed-Hashing for Message 622 Authentication (HMAC) (see [RFC2104] and [RFC4634]) 624 o Hash algorithm for use with the pseudorandom function (e.g., HMAC 625 with the SHA-256) 627 o Misc information (e.g., length of authentication tags) 629 o Information whether the ciphersuite is suitable for DTLS or only 630 for TLS 632 The TLS ciphersuite TLS_PSK_WITH_AES_128_CCM_8, for example, uses a 633 pre-shared authentication and key exchange algorithm. RFC 6655 634 [RFC6655] defines this ciphersuite. It uses the Advanced Encryption 635 Standard (AES) encryption algorithm, which is a block cipher. Since 636 the AES algorithm supports different key lengths (such as 128, 192 637 and 256 bits) this information has to be specified as well and the 638 selected ciphersuite supports 128 bit keys. A block cipher encrypts 639 plaintext in fixed-size blocks and AES operates on fixed block size 640 of 128 bits. For messages exceeding 128 bits, the message is 641 partitioned into 128-bit blocks and the AES cipher is applied to 642 these input blocks with appropriate chaining, which is called mode of 643 operation. 645 TLS 1.2 introduced Authenticated Encryption with Associated Data 646 (AEAD) ciphersuites (see [RFC5116] and [RFC6655]). AEAD is a class 647 of block cipher modes which encrypt (parts of) the message and 648 authenticate the message simultaneously. Examples of such modes 649 include the Counter with Cipher Block Chaining - Message 650 Authentication Code (CBC-MAC) Mode (CCM) mode, and the Galois/Counter 651 Mode (GCM) (see [RFC5288] and [RFC7251]). 653 Some AEAD ciphersuites have shorter authentication tags and are 654 therefore more suitable for networks with low bandwidth where small 655 message size matters. The TLS_PSK_WITH_AES_128_CCM_8 ciphersuite 656 that ends in "_8" has an 8-octet authentication tag, while the 657 regular CCM ciphersuites have, at the time of writing, 16-octet 658 authentication tags. 660 TLS 1.2 also replaced the combination of MD5/SHA-1 hash functions in 661 the TLS pseudo random function (PRF) used in earlier versions of TLS 662 with cipher-suite-specified PRFs. For this reason authors of more 663 recent TLS 1.2 ciphersuite specifications explicitly indicate the MAC 664 algorithm and the hash functions used with the TLS PRF. 666 6. Credential Types 668 6.1. Pre-Shared Secret 670 The use of pre-shared secret credentials is one of the most basic 671 techniques for TLS/DTLS since it is both computational efficient and 672 bandwidth conserving. Pre-shared secret based authentication was 673 introduced to TLS with RFC 4279 [RFC4279]. The exchange shown in 674 Figure 5 illustrates the DTLS exchange including the cookie exchange. 675 While the server is not required to initiate a cookie exchange with 676 every handshake, the client is required to implement and to react on 677 it when challenged. The cookie exchange allows the server to react 678 to flooding attacks. 680 Client Server 681 ------ ------ 682 ClientHello --------> 684 <-------- HelloVerifyRequest 685 (contains cookie) 687 ClientHello --------> 688 (with cookie) 689 ServerHello 690 *ServerKeyExchange 691 <-------- ServerHelloDone 692 ClientKeyExchange 693 ChangeCipherSpec 694 Finished --------> 695 ChangeCipherSpec 696 <-------- Finished 698 Application Data <-------> Application Data 700 Legend: 702 * indicates an optional message payload 704 Figure 5: DTLS PSK Authentication including the Cookie Exchange. 706 [RFC4279] does not mandate the use of any particular type of client 707 identity and the client and server have to agree on the identities 708 and keys to be used. The mandated encoding of identities in 709 Section 5.1 of RFC 4279 aims to improve interoperability for those 710 cases where the identity is configured by a person using some 711 management interface. Many IoT devices do, however, not have a user 712 interface and most of their credentials are bound to the device 713 rather than the user. Furthermore, credentials are often provisioned 714 into trusted hardware modules or in the firmware by developers. As 715 such, the encoding considerations are not applicable to this usage 716 environment. For use with this profile the PSK identities SHOULD NOT 717 assume a structured format (as domain names, Distinguished Names, or 718 IP addresses have) and a bit-by-bit comparison operation can then be 719 used by the server-side infrastructure. 721 The client indicates which key it uses by including a "PSK identity" 722 in the ClientKeyExchange message. As described in Section 4 clients 723 may have multiple pre-shared keys with a single server and to help 724 the client in selecting which PSK identity / PSK pair to use, the 725 server can provide a "PSK identity hint" in the ServerKeyExchange 726 message. If the hint for PSK key selection is based on the domain 727 name of the server then servers SHOULD NOT send the "PSK identity 728 hint" in the ServerKeyExchange message. In general, servers SHOULD 729 NOT send the "PSK identity hint" in the ServerKeyExchange message and 730 client MUST ignore the message. This approach is inline with RFC 731 4279 [RFC4279]. Note: The TLS Server Name Indication (SNI) extension 732 allows the client to tell a server the name of the server it is 733 contacting, which is relevant for hosting environments. A server 734 using the identity hint needs to guide the selection based on a 735 received SNI value from the client. 737 RFC 4279 requires TLS implementations supporting PSK ciphersuites to 738 support arbitrary PSK identities up to 128 octets in length, and 739 arbitrary PSKs up to 64 octets in length. This is a useful 740 assumption for TLS stacks used in the desktop and mobile environments 741 where management interfaces are used to provision identities and 742 keys. For the IoT environment, keys are distributed as part of 743 hardware modules or are embedded into the firmware. Implementations 744 in compliance with this profile MAY use PSK identities up to 128 745 octets in length, and arbitrary PSKs up to 64 octets in length. The 746 use of shorter PSK identities and shorter PSKs is RECOMMENDED. 748 Constrained Application Protocol (CoAP) [RFC7252] currently specifies 749 TLS_PSK_WITH_AES_128_CCM_8 as the mandatory to implement ciphersuite 750 for use with shared secrets. This ciphersuite uses the AES algorithm 751 with 128 bit keys and CCM as the mode of operation. The label "_8" 752 indicates that an 8-octet authentication tag is used. This 753 ciphersuite makes use of the default TLS 1.2 Pseudorandom Function 754 (PRF), which uses an HMAC with the SHA-256 hash function. (Note that 755 all IoT implementations will need a SHA-256 implementation due to the 756 construction of the pseudo-random number function in DTLS/TLS 1.2.) 758 A device compliant with the profile in this section MUST implement 759 TLS_PSK_WITH_AES_128_CCM_8 and follow the guidance from this section. 761 6.2. Raw Public Key 763 The use of raw public keys with TLS/DTLS, as defined in [RFC7250], is 764 the first entry point into public key cryptography without having to 765 pay the price of certificates and a public key infrastructure (PKI). 766 The specification re-uses the existing Certificate message to convey 767 the raw public key encoded in the SubjectPublicKeyInfo structure. To 768 indicate support two new extensions had been defined, as shown in 769 Figure 6, namely the server_certificate_type*' and the 770 client_certificate_type. To operate this mechanism securely it is 771 necessary to authenticate and authorize the public keys out-of-band. 772 This document therefore assumes that a client implementation comes 773 with one or multiple raw public keys of servers, it has to 774 communicate with, pre-provisioned. Additionally, a device will have 775 its own raw public key. To replace, delete, or add raw public key to 776 this list requires a software update, for example using a firmware 777 update mechanism. 779 Client Server 780 ------ ------ 782 ClientHello --------> 783 *client_certificate_type* 784 *server_certificate_type* 786 ServerHello 787 *client_certificate_type* 788 *server_certificate_type* 789 Certificate 790 ServerKeyExchange 791 CertificateRequest 792 <-------- ServerHelloDone 794 Certificate 795 ClientKeyExchange 796 CertificateVerify 797 [ChangeCipherSpec] 798 Finished --------> 800 [ChangeCipherSpec] 801 <-------- Finished 803 Note: Extensions marked with '*' were introduced with 804 RFC 7250. 806 Figure 6: DTLS Raw Public Key Exchange including the Cookie Exchange. 808 The CoAP recommended ciphersuite for use with this credential type is 809 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251]. This elliptic curve 810 cryptography (ECC) based AES-CCM TLS ciphersuite uses the Ephemeral 811 Elliptic Curve Diffie-Hellman (ECDHE) as the key establishment 812 mechanism and an Elliptic Curve Digital Signature Algorithm (ECDSA) 813 for authentication. Due to the use of Ephemeral Elliptic Curve 814 Diffie-Hellman (ECDHE) the recently introduced named Diffie-Hellman 815 groups [I-D.ietf-tls-negotiated-dl-dhe] are not applicable to this 816 profile. This ciphersuite make use of the AEAD capability in DTLS 817 1.2 and utilizes an eight-octet authentication tag. The use of a 818 Diffie-Hellman key exchange provides perfect forward secrecy (PFS). 819 More details about PFS can be found in Section 11. 821 RFC 6090 [RFC6090] provides valuable information for implementing 822 Elliptic Curve Cryptography algorithms, particularly for choosing 823 methods that have been available in the literature for a long time 824 (i.e., 20 years and more). 826 A device compliant with the profile in this section MUST implement 827 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this 828 section. 830 6.3. Certificates 832 The use of mutual certificate-based authentication is shown in 833 Figure 7, which makes use of the cached info extension 834 [I-D.ietf-tls-cached-info]. Support of the cached info extension is 835 REQUIRED. Caching certificate chains allows the client to reduce the 836 communication overhead significantly since otherwise the server would 837 provide the end entity certificate, and the certificate chain. 838 Because certificate validation requires that root keys be distributed 839 independently, the self-signed certificate that specifies the root 840 certificate authority is omitted from the chain. Client 841 implementations MUST be provisioned with a trust anchor store that 842 contains the root certificates. The use of the Trust Anchor 843 Management Protocol (TAMP) [RFC5934] is, however, not envisioned. 844 Instead IoT devices using this profile MUST use a software update 845 mechanism to populate the trust anchor store. 847 Client Server 848 ------ ------ 850 ClientHello --------> 851 *cached_information* 853 ServerHello 854 *cached_information* 855 Certificate 856 ServerKeyExchange 857 CertificateRequest 858 <-------- ServerHelloDone 860 Certificate 861 ClientKeyExchange 862 CertificateVerify 863 [ChangeCipherSpec] 864 Finished --------> 866 [ChangeCipherSpec] 867 <-------- Finished 869 Note: Extensions marked with '*' were introduced with 870 [I-D.ietf-tls-cached-info]. 872 Figure 7: DTLS Mutual Certificate-based Authentication. 874 When DTLS is used to secure CoAP messages then the server provided 875 certificates MUST contain the fully qualified DNS domain name or 876 "FQDN" as dNSName. The coaps URI scheme is described in Section 6.2 877 of [RFC7252]. This FQDN is stored in the SubjectAltName or in the 878 leftmost CN component of subject name, as explained in 879 Section 9.1.3.3 of [RFC7252], and used by the client to match it 880 against the FQDN used during the look-up process, as described in RFC 881 6125 [RFC6125]. For the profile in this specification does not 882 assume dynamic discovery of local servers. 884 For client certificates the identifier used in the SubjectAltName or 885 in the CN MUST be an EUI-64 [EUI64], as mandated in Section 9.1.3.3 886 of [RFC7252]. 888 For certificate revocation neither the Online Certificate Status 889 Protocol (OCSP) nor Certificate Revocation Lists (CRLs) are used. 890 Instead, this profile relies on a software update mechanism. While 891 multiple OCSP stapling [RFC6961] has recently been introduced as a 892 mechanism to piggyback OCSP request/responses inside the DTLS/TLS 893 handshake to avoid the cost of a separate protocol handshake further 894 investigations are needed to determine its suitability for the IoT 895 environment. 897 Regarding the ciphersuite choice the discussion in Section 6.2 898 applies. Further details about X.509 certificates can be found in 899 Section 9.1.3.3 of [RFC7252]. The TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 900 ciphersuite description in Section 6.2 is also applicable to this 901 section. 903 When using certificates, IoT devices MUST provide support for a 904 server certificate chain of at least 3 not including the trust anchor 905 and MAY reject connections from servers offering chains longer than 906 3. IoT devices MAY have client certificate chains of any length. 907 Obviously, longer chains require more resources to process, transmit 908 or receive. 910 A device compliant with the profile in this section MUST implement 911 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this 912 section. 914 6.3.1. Client Certificate URLs 916 RFC 6066 [RFC6066] allows to avoid sending client-side certificates 917 and uses URLs instead. This reduces the over-the-air transmission. 918 Note that the TLS cached info extension does not provide any help 919 with caching client certificates. 921 TLS/DTLS clients MUST implement support for client certificate URLs 922 for those environments where client-side certificates are used. 924 6.3.2. Trusted CA Indication 926 RFC 6066 [RFC6066] allows clients to indicate what trust anchor they 927 support. With certificate-based authentication a DTLS server conveys 928 its end entity certificate to the client during the DTLS exchange 929 provides. Since the server does not necessarily know what trust 930 anchors the client has stored it includes intermediate CA certs in 931 the certificate payload as well to facilitate with certification path 932 construction and path validation. 934 Today, in most IoT deployments there is a fairly static relationship 935 between the IoT device (and the software running on them) and the 936 server- side infrastructure and no such dynamic indication of trust 937 anchors is needed. 939 For deployments where IoT devices interact with a fixed, pre- 940 configured set of servers and where a software update mechanism is 941 available this extension is NOT RECOMMENDED. Environments where the 942 client needs to interact with dynamically discovered TLS/DTLS servers 943 the use of this extension is RECOMMENDED. 945 7. Signature Algorithm Extension 947 The "signature_algorithms" extension, defined in Section 7.4.1.4.1 of 948 RFC 5246 [RFC5246], allows the client to indicate to the server which 949 signature/hash algorithm pairs may be used in digital signatures. 950 The client MUST send this extension to select the use of SHA-256 951 since otherwise absent this extension RFC 5246 defaults to SHA-1 / 952 ECDSA for the ECDH_ECDSA and the ECDHE_ECDSA key exchange algorithms. 954 The "signature_algorithms" extension is not applicable to the PSK- 955 based ciphersuite described in Section 6.1. 957 8. Error Handling 959 TLS/DTLS uses the Alert protocol to convey error messages and 960 specifies a longer list of errors. However, not all error messages 961 defined in the TLS/DTLS specification are applicable to this profile. 962 In general, there are two categories of errors (as defined in 963 Section 7.2 of RFC 5246), namely fatal errors and warnings. Alert 964 messages with a level of fatal result in the immediate termination of 965 the connection. If possible, developers should try to develop 966 strategies to react to those fatal errors, such as re-starting the 967 handshake or informing the user using the (often limited) user 968 interface. Warnings may be ignored by the application since many IoT 969 devices will either have limited ways to log errors or no ability at 970 all. In any case, implementers have to carefully evaluate the impact 971 of errors and ways to remedy the situation since a commonly used 972 approach for delegating decision making to users is difficult (or 973 impossible) to accomplish in a timely fashion. 975 All error messages marked as RESERVED are only supported for 976 backwards compatibility with SSL and are therefore not applicable to 977 this profile. Those include decryption_failed_RESERVED, 978 no_certificate_RESERVE, and export_restriction_RESERVED. 980 A number of the error messages are applicable only for certificate- 981 based authentication ciphersuites. Hence, for PSK and raw public key 982 use the following error messages are not applicable: 984 o bad_certificate, 986 o unsupported_certificate, 988 o certificate_revoked, 989 o certificate_expired, 991 o certificate_unknown, 993 o unknown_ca, and 995 o access_denied. 997 Since this profile does not make use of compression at the TLS layer 998 the decompression_failure error message is not applicable either. 1000 RFC 4279 introduced a new alert message unknown_psk_identity for PSK 1001 ciphersuites. As stated in Section 2 of RFC 4279 the 1002 decryption_error error message may also be used instead. For this 1003 profile the TLS server MUST return the decryption_error error message 1004 instead of the unknown_psk_identity since the two mechanisms exist 1005 and provide the same functionality. 1007 Furthermore, the following errors should not occur with devices and 1008 servers supporting this specification but implementations MUST be 1009 prepared to process these errors to deal with servers that are not 1010 compliant to the profiles in this document: 1012 protocol_version: While this document focuses only on one version of 1013 the TLS/DTLS protocol, namely version 1.2, ongoing work on TLS/ 1014 DTLS 1.3 is in progress at the time of writing. 1016 insufficient_security: This error message indicates that the server 1017 requires ciphers to be more secure. This document specifies only 1018 one ciphersuite per profile but it is likely that additional 1019 ciphtersuites get added over time. 1021 user_canceled: Many IoT devices are unattended and hence this error 1022 message is unlikely to occur. 1024 9. Session Resumption 1026 Session resumption is a feature of the core TLS/DTLS specifications 1027 that allows a client to continue with an earlier established session 1028 state. The resulting exchange is shown in Figure 8. In addition, 1029 the server may choose not to do a cookie exchange when a session is 1030 resumed. Still, clients have to be prepared to do a cookie exchange 1031 with every handshake. The cookie exchange is not shown in the 1032 figure. 1034 Client Server 1035 ------ ------ 1037 ClientHello --------> 1038 ServerHello 1039 [ChangeCipherSpec] 1040 <-------- Finished 1041 [ChangeCipherSpec] 1042 Finished --------> 1043 Application Data <-------> Application Data 1045 Figure 8: DTLS Session Resumption. 1047 Constrained clients MUST implement session resumption to improve the 1048 performance of the handshake. This will lead to a reduced number of 1049 message exchanges, lower computational overhead (since only symmetric 1050 cryptography is used during a session resumption exchange), and 1051 session resumption requires less bandwidth. 1053 For cases where the server is constrained (but not the client) the 1054 client MUST implement RFC 5077 [RFC5077]. RFC 5077 specifies a 1055 version of TLS/DTLS session resumption that does not require per- 1056 session state information to be maintained by the constrained server. 1057 This is accomplished by using a ticket-based approach. 1059 If both the client and the server are constrained devices both 1060 devices SHOULD implement RFC 5077 and MUST implement basic session 1061 resumption. 1063 10. Compression 1065 Section 3.3 of [I-D.ietf-uta-tls-bcp] recommends to disable TLS/DTLS- 1066 level compression due to attacks, such as CRIME. For IoT 1067 applications compression at the TLS/DTLS layer is not needed since 1068 application layer protocols are highly optimized and the compression 1069 algorithms at the DTLS layer increases code size and complexity. 1071 This TLS/DTLS profile MUST NOT implement TLS/DTLS layer compression. 1073 11. Perfect Forward Secrecy 1075 Perfect forward secrecy (PFS) is a property that preserves the 1076 confidentiality of past conversations even in situations where the 1077 long-term secret is compromised. 1079 The PSK ciphersuite recommended in Section 6.1 does not offer this 1080 property since it does not utilize a Diffie-Hellman exchange. New 1081 ciphersuites that support PFS for PSK-based authentication, such as 1082 proposed in [I-D.schmertmann-dice-ccm-psk-pfs], might become 1083 available as standardized ciphersuite in the (near) future. The 1084 recommended PSK-based ciphersuite offers excellent performance, a 1085 very small memory footprint, and has the lowest on the wire overhead 1086 at the expense of not using any public cryptography. For deployments 1087 where public key cryptography is acceptable the raw public might 1088 offer an acceptable middleground between the PSK ciphersuite in terms 1089 of out-of-band validation and the functionality offered by asymmetric 1090 cryptography. 1092 The use of PFS is a trade-off decision since on one hand the 1093 compromise of long-term secrets of embedded devices is more likely 1094 than with many other Internet hosts but on the other hand a Diffie- 1095 Hellman exchange requires ephemeral key pairs to be generated, which 1096 is demanding from a performance point of view. For performance 1097 reasons some implementations re-use key pairs over multiple exchanges 1098 (rather than generating new keys for each exchange) for the obvious 1099 performance improvement. Note, however, that such key re-use over 1100 long periods voids the benefits of forward secrecy when an attack 1101 gains access to this DH key pair. 1103 The impact of the disclosure of past conversations and the desire to 1104 increase the cost for pervasive monitoring (as demanded by [RFC7258]) 1105 has to be taken into account when making a deployment decision. 1107 Client implementations claiming support of this profile MUST 1108 implement the ciphersuites listed in Section 6 according to the 1109 selected credential type. 1111 12. Keep-Alive 1113 RFC 6520 [RFC6520] defines a heartbeat mechanism to test whether the 1114 other peer is still alive. The same mechanism can also be used to 1115 perform Path Maximum Transmission Unit (MTU) Discovery. 1117 A recommendation about the use of RFC 6520 depends on the type of 1118 message exchange an IoT device performs. There are three types of 1119 exchanges that need to be analysed: 1121 Client-Initiated, One-Shot Messages 1123 This is a common communication pattern where IoT devices upload 1124 data to a server on the Internet on an irregular basis. The 1125 communication may be triggered by specific events, such as opening 1126 a door. 1128 Since the upload happens on an irregular and unpredictable basis 1129 and due to renumbering and Network Address Translation (NAT) the 1130 DTLS handshake may need to be re-started (ideally using session 1131 resumption, if possible). 1133 In this case there is no use for a keep-alive extension for this 1134 scenario. 1136 Client-Initiated, Regular Data Uploads 1138 This is a variation of the previous case whereby data gets 1139 uploaded on a regular basis, for example, based on frequent 1140 temperature readings. If neither NAT bindings nor IP address 1141 changes occurred then the record layer will not notice any 1142 changes. For the case where the IP address and port number 1143 changes, it is necessary to re-create the record layer using 1144 session resumption. 1146 In this scenario there is no use for a keep-alive extension. It 1147 is also very likely that the device will enter a sleep cycle in 1148 between data transmissions to keep power consumption low. 1150 Server-Initiated Messages 1152 In the two previous scenarios the client initiated the protocol 1153 interaction but in this case we consider server-initiated 1154 messages. Since messages to the client may get blocked by 1155 intermediaries, such as NATs (including IPv4/IPv6 protocol 1156 translators) and stateful packet filtering firewalls, the initial 1157 connection setup is triggered by the client and then kept alive. 1158 Since state at middleboxes expires fairly quickly (according to 1159 measurements described in [HomeGateway]), regular heartbeats are 1160 necessary whereby these keep-alive messages may be exchanged at 1161 the application layer or within DTLS itself. 1163 For this message exchange pattern the use of DTLS heartbeat 1164 messages is quite useful but may interfere with registrations kept 1165 at the application layer (for example when the CoAP resource 1166 directory is used). The MTU discovery mechanism, which is also 1167 part of [RFC6520], is less likely to be relevant since for many 1168 IoT deployments the most constrained link is the wireless 1169 interface between the IoT device and the network itself (rather 1170 than some links along the end-to-end path). Only in more complex 1171 network topologies, such as multi-hop mesh networks, path MTU 1172 discovery might be appropriate. It also has to be noted that DTLS 1173 itself already provides a basic path discovery mechanism (see 1174 Section 4.1.1.1 of RFC 6347 by using the fragmentation capability 1175 of the handshake protocol). 1177 For server-initiated messages the heartbeat extension is RECOMMENDED. 1179 13. Timeouts 1181 To connect to the Internet a variety of wired and wireless 1182 technologies are available. Many of the low power radio 1183 technologies, such as IEEE 802.15.4 or Bluetooth Smart, only support 1184 small frame sizes (e.g., 127 bytes in case of IEEE 802.15.4 as 1185 explained in RFC 4919 [RFC4919]). Other radio technologies, such as 1186 the Global System for Mobile Communications (GSM) using the short 1187 messaging service (SMS) have similar constraints in terms of payload 1188 sizes, such as 140 bytes without the optional segmentation and 1189 reassembly scheme known as Concatenated SMS, but show higher latency. 1191 The DTLS handshake protocol adds a fragmentation and reassembly 1192 mechanism to the TLS handshake protocol since each DTLS record must 1193 fit within a single transport layer datagram, as described in 1194 Section 4.2.3 of [RFC6347]. Since handshake messages are potentially 1195 bigger than the maximum record size, the mechanism fragments a 1196 handshake message over a number of DTLS records, each of which can be 1197 transmitted separately. 1199 To deal with the unreliable message delivery provided by UDP, DTLS 1200 adds timeouts and re-transmissions, as described in Section 4.2.4 of 1201 [RFC6347]. Although the timeout values are implementation specific, 1202 recommendations are provided in Section 4.2.4.1 of [RFC6347], with an 1203 initial timer value of 1 second and twice the value at each 1204 retransmission up to no less than 60 seconds. Due to the nature of 1205 some radio technologies, these values are too aggressive and lead to 1206 spurious failures when messages in flight need longer. 1208 Note: If a round-trip time estimator (such as proposed in 1209 [I-D.bormann-core-cocoa]) is available in the protocol stack of the 1210 device, it could be used to dynamically update the setting of the 1211 retransmit timeout. 1213 Choosing appropriate timeout values is difficult with infrequent data 1214 transmissions, changing network conditions, and large variance in 1215 latency. This specification therefore RECOMMENDS an initial timer 1216 value of 10 seconds with exponential back off up to no less then 60 1217 seconds. Appendix A provides additional normative text for carrying 1218 DTLS over SMS. 1220 14. Random Number Generation 1222 The TLS/DTLS protocol requires random numbers to be available during 1223 the protocol run. For example, during the ClientHello and the 1224 ServerHello exchange the client and the server exchange random 1225 numbers. Also, the use of the Diffie-Hellman exchange requires 1226 random numbers during the key pair generation. Special care has to 1227 be paid when generating random numbers in embedded systems as many 1228 entropy sources available on desktop operating systems or mobile 1229 devices might be missing, as described in [Heninger]. Consequently, 1230 if not enough time is given during system start time to fill the 1231 entropy pool then the output might be predictable and repeatable, for 1232 example leading to the same keys generated again and again. 1234 It is important to note that sources contributing to the randomness 1235 pool on laptops, or desktop PCs are not available on many IoT device, 1236 such as mouse movement, timing of keystrokes, air turbulence on the 1237 movement of hard drive heads, etc. Other sources have to be found or 1238 dedicated hardware has to be added. 1240 The ClientHello and the ServerHello messages contains the 'Random' 1241 structure, which has two components: gmt_unix_time and a random 1242 sequence of 28 random bytes. gmt_unix_time holds the current time and 1243 date in standard UNIX 32-bit format (seconds since the midnight 1244 starting Jan 1, 1970, GMT). [I-D.mathewson-no-gmtunixtime] argues 1245 that the entire ClientHello.Random value (including gmt_unix_time) 1246 should be set to a cryptographically random sequence because of 1247 privacy concerns regarding device fingerprinting. Since many IoT 1248 devices do not have access to a real-time clock this recommendation 1249 it is RECOMMENDED to follow the guidance outlined in 1250 [I-D.mathewson-no-gmtunixtime] regarding the content of the 1251 ClientHello.Random field. However, for the ServerHello.Random 1252 structure it is RECOMMENDED to maintain the existing structure with 1253 gmt_unix_time followed by a random sequence of 28 random bytes since 1254 the client can use the received time information to securely obtain 1255 time information. For constrained servers it cannot be assumed that 1256 they maintain accurate time information; these devices MUST include 1257 time information in the Server.Random structure when they actually 1258 obtain accurate time information that can be utilized by clients. 1259 Clients MUST only use time information obtained from servers they 1260 trust. 1262 IoT devices using TLS/DTLS MUST offer ways to generate quality random 1263 numbers. Guidelines and requirements for random number generation 1264 can be found in RFC 4086 [RFC4086]. 1266 15. Truncated MAC and Encrypt-then-MAC Extension 1268 The truncated MAC extension was introduced with RFC 6066 [RFC6066] 1269 with the goal to reduce the size of the MAC used at the Record Layer. 1270 This extension was developed for TLS ciphersuites that used older 1271 modes of operation where the MAC and the encryption operation was 1272 performed independently. 1274 The recommended ciphersuites in this document use the newer 1275 Authenticated Encryption with Associated Data (AEAD) construct, 1276 namely the CBC-MAC mode (CCM) with eight-octet authentication tags, 1277 and are therefore not appliable to the truncated MAC extension. 1279 RFC 7366 [RFC7366] introduced the encrypt-then-MAC extension (instead 1280 of the previously used MAC-then-encrypt) since the MAC-then-encrypt 1281 mechanism has been the subject of a number of security 1282 vulnerabilities. RFC 7366 is, however, also not applicable to the 1283 AEAD ciphers recommended in this document. 1285 Implementations conformant to this specification MUST use AEAD 1286 ciphers and RFC 7366 and RFC 6066 MUST NOT be implemented. 1288 16. Server Name Indication (SNI) 1290 The Server Name Indication extension defined in [RFC6066] defines a 1291 mechanism for a client to tell a TLS/DTLS server the name of the 1292 server it wants to contact. This is a useful extension for many 1293 hosting environments where multiple virtual servers are run on single 1294 IP address. 1296 This specification RECOMMENDs the implementation of RFC 6066 unless 1297 it is known that a TLS/DTLS client does not interact with a server in 1298 a hosting environment. 1300 17. Maximum Fragment Length Negotiation 1302 This RFC 6066 extension lowers the maximum fragment length support 1303 needed for the Record Layer from 2^14 bytes to 2^9 bytes. 1305 This is a very useful extension that allows the client to indicate to 1306 the server how much maximum memory buffers it uses for incoming 1307 messages. Ultimately, the main benefit of this extension is it to 1308 allows client implementations to lower their RAM requirements since 1309 the client does not need to accept packets of large size (such as 16k 1310 packets as required by plain TLS/DTLS). 1312 Client implementations MUST support this extension. 1314 18. Session Hash 1316 In order to begin connection protection, the Record Protocol requires 1317 specification of a suite of algorithms, a master secret, and the 1318 client and server random values. The algorithm for computing the 1319 master secret is defined in Section 8.1 of RFC 5246 but only includes 1320 a small number of parameters exchanged during the handshake and does 1321 not include parameters like the client and server identities. This 1322 can be utilized by an attacker to mount a man-in-the-middle attack 1323 since the master secret is not guaranteed to be unique across 1324 sessions, as discovered in the 'Triple Handshake' attack 1325 [Tripple-HS]. 1327 [I-D.ietf-tls-session-hash] defines a TLS extension that binds the 1328 master secret to a log of the full handshake that computes it, thus 1329 preventing such attacks. 1331 Client implementations SHOULD implement this extension even though 1332 the ciphersuites recommended by this profile are not vulnerable to 1333 this attack. For Diffie-Hellman-based ciphersuites the keying 1334 material is contributed by both parties and in case of the pre-shared 1335 secret key ciphersuite both parties need to be in possession of the 1336 shared secret to ensure that the handshake completes successfully. 1337 It is, however, possible that some application layer protocols will 1338 tunnel other authentication protocols on top of DTLS making this 1339 attack relevant again. 1341 19. Re-Negotiation Attacks 1343 TLS/DTLS allows a client and a server who already have a TLS/DTLS 1344 connection to negotiate new parameters, generate new keys, etc by 1345 using the re-negotiation feature. Renegotiation happens in the 1346 existing connection, with the new handshake packets being encrypted 1347 along with application data. Upon completion of the re-negotiation 1348 procedure the new channel replaces the old channel. 1350 As described in RFC 5746 [RFC5746] there is no cryptographic binding 1351 between the two handshakes, although the new handshake is carried out 1352 using the cryptographic parameters established by the original 1353 handshake. 1355 To prevent the re-negotiation attack [RFC5746] this specification 1356 RECOMMENDS to disable the TLS renegotigation feature. Clients MUST 1357 respond to server-initiated re-negotiation attempts with an alert 1358 message (no_renegotiation) and clients MUST NOT initiate them. 1360 20. Downgrading Attacks 1362 When a client sends a ClientHello with a version higher than the 1363 highest version known to the server, the server is supposed to reply 1364 with ServerHello.version equal to the highest version known to the 1365 server and the handshake can proceed. This behaviour is known as 1366 version tolerance. Version-intolerance is when the server (or a 1367 middlebox) breaks the handshake when it sees a ClientHello.version 1368 higher than what it knows about. This is the behaviour that leads 1369 some clients to re-run the handshake with lower version. As a 1370 result, a potential security vulnerability is introduced when a 1371 system is running an old TLS/SSL version (e.g., because of the need 1372 to integrate with legacy systems). In the worst case, this allows an 1373 attacker to downgrade the protocol handshake to SSL 3.0. SSL 3.0 is 1374 so broken that there is no secure cipher available for it (see 1375 [I-D.ietf-tls-sslv3-diediedie]). 1377 The above-described downgrade vulnerability is solved by the TLS 1378 Fallback Signaling Cipher Suite Value (SCSV) 1379 [I-D.ietf-tls-downgrade-scsv] extension. However, the solution is 1380 not appliable to implementations conforming to this profile since the 1381 version negotiation MUST use TLS/DTLS version 1.2 (or higher). More 1382 specifically, this implies: 1384 o Clients MUST NOT send a TLS/DTLS version lower than version 1.2 in 1385 the ClientHello. 1387 o Clients MUST NOT retry a failed negotiation offering a TLS/DTLS 1388 version lower than 1.2. 1390 o Servers MUST fail the handshake by sending a protocol_version 1391 fatal alert if a TLS/DTLS version >= 1.2 cannot be negotiated. 1392 Note that the aborted connection is non-resumable. 1394 If at some time in the future the TLS/DTLS 1.2 profile reaches the 1395 quality of SSL 3.0 a software update mechanism is needed since 1396 constrained devices are unlikely to run multiple TLS/DTLS versions 1397 due to memory size restrictions. 1399 21. Crypto Agility 1401 This document recommends software and chip manufacturers to implement 1402 AES and the CCM mode of operation. This document references the CoAP 1403 recommended ciphersuite choices, which have been selected based on 1404 implementation and deployment experience from the IoT community. 1405 Over time the preference for algorithms will, however, change. Not 1406 all components of a ciphersuite are likely to change at the same 1407 speed. Changes are more likely expected for ciphers, the mode of 1408 operation, and the hash algorithms. The recommended key lengths have 1409 to be adjusted over time. Some deployment environments will also be 1410 impacted by local regulation, which might dictate a certain cipher 1411 and key size. Ongoing discussions regarding the choice of specific 1412 ECC curves will also likely to impact implementations. 1414 The following recommendations can be made to chip manufacturers: 1416 o Make any AES hardware-based crypto implementation accessible to 1417 developers working on security implementations at higher layers. 1419 Sometimes hardware implementatios are added to microcontrollers to 1420 offer support for functionality needed at the link layer and are 1421 only available to the on-chip link layer protocol implementation. 1423 o Provide flexibility for the use of the crypto function with future 1424 extensibility in mind. For example, making an AES-CCM 1425 implementation available to developers is a first step but such an 1426 implementation may not be usable due to parameter differences 1427 between an AES-CCM implementations. AES-CCM in IEEE 802.15.4 and 1428 Bluetooth Smart uses a nonce length of 13-octets while DTLS uses a 1429 nonce length of 12-octets. Hardware implementations of AES-CCM 1430 for IEEE 802.15.4 and Bluetooth Smart are therefore not re-usable 1431 by a DTLS stack. 1433 o Offer access to building blocks in addition (or as an alternative) 1434 to the complete functionality. For example, a chip manufacturer 1435 who gives developers access to an the AES crypto function can use 1436 it in functions to build an efficient AES-GCM implementations. 1437 Another example is to make a special instruction available that 1438 increases the speed of speed-up carryless multiplications. 1440 As a recommendation for developers and product architects we 1441 recommend that sufficient headroom is provided to allow an upgrade to 1442 a newer cryptographic algorithms over the lifetime of the product. 1443 As an example, while AES-CCM is recommended thoughout this 1444 specification future products might use the ChaCha20 cipher in 1445 combination with the Poly1305 authenticator 1446 [I-D.irtf-cfrg-chacha20-poly1305]. The assumption is made that a 1447 robust software update mechanism is offered. 1449 22. Key Length Recommendations 1451 RFC 4492 [RFC4492] gives approximate comparable key sizes for 1452 symmetric- and asymmetric-key cryptosystems based on the best-known 1453 algorithms for attacking them. While other publications suggest 1454 slightly different numbers, such as [Keylength], the approximate 1455 relationship still holds true. Figure 9 illustrates the comparable 1456 key sizes in bits. 1458 At the time of writing the key size recommendations for use with TLS- 1459 based ciphers found in [I-D.ietf-uta-tls-bcp] recommend DH key 1460 lengths of at least 2048 bit, which corresponds to a 112-bit 1461 symmetric key and a 233 bit ECC keys. These recommendations are 1462 inline with those from other organizations, such as National 1463 Institute of Standards and Technology (NIST) or European Network and 1464 Information Security Agency (ENISA). The authors of 1465 [ENISA-Report2013] add that a symmetric 80-bit security level is 1466 sufficient for legacy applications for the coming years, but a 1467 128-bit security level is the minimum requirement for new systems 1468 being deployed. The authors further note that one needs to also take 1469 into account the length of time data needs to be kept secure for. 1470 The use 80-bit encryption for transactional data may be acceptable 1471 for the near future while one has to insist on 128-bit encryption for 1472 long lived data. 1474 Symmetric | ECC | DH/DSA/RSA 1475 ------------+---------+------------- 1476 80 | 163 | 1024 1477 112 | 233 | 2048 1478 128 | 283 | 3072 1479 192 | 409 | 7680 1480 256 | 571 | 15360 1482 Figure 9: Comparable Key Sizes (in bits). 1484 23. False Start 1486 A full TLS handshake as specified in [RFC5246] requires two full 1487 protocol rounds (four flights) before the handshake is complete and 1488 the protocol parties may begin to send application data. 1490 An abbreviated handshake (resuming an earlier TLS session) is 1491 complete after three flights, thus adding just one round-trip time if 1492 the client sends application data first. 1494 If the conditions outlined in [I-D.bmoeller-tls-falsestart] are met, 1495 application data can be transmitted when the sender has sent its own 1496 "ChangeCipherSpec" and "Finished" messages. This achieves an 1497 improvement of one round-trip time for full handshakes if the client 1498 sends application data first, and for abbreviated handshakes if the 1499 server sends application data first. 1501 The conditions for using the TLS False Start mechanism are met by the 1502 public-key-based ciphersuites in this document. In summary, the 1503 conditions are 1505 o Modern symmetric ciphers with an effective key length of 128 bits, 1506 such as AES-128-CCM 1508 o Client certificate types, such as ecdsa_sign 1510 o Key exchange methods, such as ECDHE_ECDSA 1511 Based on the improvement over a full roundtrip for the full TLS/DTLS 1512 exchange this specification RECOMMENDS the use of the False Start 1513 mechanism when clients send application data first. 1515 24. Privacy Considerations 1517 The DTLS handshake exchange conveys various identifiers, which can be 1518 observed by an on-path eavesdropper. For example, the DTLS PSK 1519 exchange reveals the PSK identity, the supported extensions, the 1520 session id, algorithm parameters, etc. When session resumption is 1521 used then individual TLS sessions can be correlated by an on-path 1522 adversary. With many IoT deployments it is likely that keying 1523 material and their identifiers are persistent over a longer period of 1524 time due to the cost of updating software on these devices. 1526 User participation with many IoT deployments poses a challenge since 1527 many of the IoT devices operate unattended, even though they will 1528 initially be provisioned by a human. The ability to control data 1529 sharing and to configure preference will have to be provided at a 1530 system level rather than at the level of the DTLS exchange itself, 1531 which is the scope of this document. Quite naturally, the use of 1532 DTLS with mutual authentication will allow a TLS server to collect 1533 authentication information about the IoT device (likely over a long 1534 period of time). While this strong form of authentication will 1535 prevent mis-attribution it also allows strong identification. 1536 Device-related data collection (e.g., sensor recordings) will be 1537 associated with other data to be truly useful and this extra data 1538 might include personal data about the owner of the device or data 1539 about the environment it senses. Consequently, the data stored on 1540 the server-side will be vulnerable to stored data compromise. For 1541 the communication between the client and the server this 1542 specification prevents eavesdroppers to gain access to the 1543 communication content. While the PSK-based ciphersuite does not 1544 provide PFS the asymmetric versions do. This prevents an adversary 1545 from obtaining past communication content when access to a long-term 1546 secret has been gained. Note that no extra effort to make traffic 1547 analysis more difficult is provided by the recommendations made in 1548 this document. 1550 25. Security Considerations 1552 This entire document is about security. 1554 We would also like to point out that designing a software update 1555 mechanism into an IoT system is crucial to ensure that both 1556 functionality can be enhanced and that potential vulnerabilities can 1557 be fixed. This software update mechanism is also useful for changing 1558 configuration information, for example, trust anchors and other 1559 keying related information. 1561 26. IANA Considerations 1563 This document includes no request to IANA. 1565 27. Acknowledgements 1567 Thanks to Paul Bakker, Robert Cragie, Russ Housley, Rene Hummen, 1568 Matthias Kovatsch, Sandeep Kumar, Sye Loong Keoh, Alexey Melnikov, 1569 Manuel Pegourie-Gonnard, Akbar Rahman, Eric Rescorla, Michael 1570 Richardson, Zach Shelby, Michael StJohns, Rene Struik, and Sean 1571 Turner for their helpful comments and discussions that have shaped 1572 the document. 1574 Big thanks also to Klaus Hartke, who wrote the initial version of 1575 this document. 1577 Finally, we would like to thank our area director (Stephen Farrell) 1578 and our working group chairs (Zach Shelby and Dorothy Gellert) for 1579 their support. 1581 28. References 1583 28.1. Normative References 1585 [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 1586 REGISTRATION AUTHORITY", April 2010, 1587 . 1590 [GSM-SMS] ETSI, "3GPP TS 23.040 V7.0.1 (2007-03): 3rd Generation 1591 Partnership Project; Technical Specification Group Core 1592 Network and Terminals; Technical realization of the Short 1593 Message Service (SMS) (Release 7)", March 2007. 1595 [I-D.ietf-tls-cached-info] 1596 Santesson, S. and H. Tschofenig, "Transport Layer Security 1597 (TLS) Cached Information Extension", draft-ietf-tls- 1598 cached-info-17 (work in progress), November 2014. 1600 [I-D.ietf-tls-session-hash] 1601 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 1602 A., and M. Ray, "Transport Layer Security (TLS) Session 1603 Hash and Extended Master Secret Extension", draft-ietf- 1604 tls-session-hash-03 (work in progress), November 2014. 1606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1607 Requirement Levels", BCP 14, RFC 2119, March 1997. 1609 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 1610 for Transport Layer Security (TLS)", RFC 4279, December 1611 2005. 1613 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1614 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1616 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 1617 "Transport Layer Security (TLS) Renegotiation Indication 1618 Extension", RFC 5746, February 2010. 1620 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1621 Extension Definitions", RFC 6066, January 2011. 1623 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1624 Verification of Domain-Based Application Service Identity 1625 within Internet Public Key Infrastructure Using X.509 1626 (PKIX) Certificates in the Context of Transport Layer 1627 Security (TLS)", RFC 6125, March 2011. 1629 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1630 Security Version 1.2", RFC 6347, January 2012. 1632 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 1633 Layer Security (TLS) and Datagram Transport Layer Security 1634 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 1636 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 1637 T. Kivinen, "Using Raw Public Keys in Transport Layer 1638 Security (TLS) and Datagram Transport Layer Security 1639 (DTLS)", RFC 7250, June 2014. 1641 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 1642 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 1643 TLS", RFC 7251, June 2014. 1645 [WAP-WDP] Wireless Application Protocol Forum, "Wireless Datagram 1646 Protocol", June 2001. 1648 28.2. Informative References 1650 [AES] NIST, "FIPS PUB 197, Advanced Encryption Standard (AES)", 1651 http://www.iana.org/assignments/tls-parameters/ 1652 tls-parameters.xhtml#tls-parameters-4, November 2001. 1654 [ENISA-Report2013] 1655 ENISA, "Algorithms, Key Sizes and Parameters Report - 1656 2013", http://www.enisa.europa.eu/activities/identity-and- 1657 trust/library/deliverables/ 1658 algorithms-key-sizes-and-parameters-report, October 2013. 1660 [Heninger] 1661 Heninger, N., Durumeric, Z., Wustrow, E., and A. 1662 Halderman, "Mining Your Ps and Qs: Detection of Widespread 1663 Weak Keys in Network Devices", 21st USENIX Security 1664 Symposium, 1665 https://www.usenix.org/conference/usenixsecurity12/ 1666 technical-sessions/presentation/heninger, 2012. 1668 [HomeGateway] 1669 Eggert, L., "An experimental study of home gateway 1670 characteristics, In Proceedings of the '10th annual 1671 conference on Internet measurement'", 2010. 1673 [I-D.bmoeller-tls-falsestart] 1674 Langley, A., Modadugu, N., and B. Moeller, "Transport 1675 Layer Security (TLS) False Start", draft-bmoeller-tls- 1676 falsestart-01 (work in progress), November 2014. 1678 [I-D.bormann-core-cocoa] 1679 Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, 1680 "CoAP Simple Congestion Control/Advanced", draft-bormann- 1681 core-cocoa-02 (work in progress), July 2014. 1683 [I-D.iab-smart-object-architecture] 1684 Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 1685 "Architectural Considerations in Smart Object Networking", 1686 draft-iab-smart-object-architecture-06 (work in progress), 1687 October 2014. 1689 [I-D.ietf-core-resource-directory] 1690 Shelby, Z. and C. Bormann, "CoRE Resource Directory", 1691 draft-ietf-core-resource-directory-02 (work in progress), 1692 November 2014. 1694 [I-D.ietf-lwig-tls-minimal] 1695 Kumar, S., Keoh, S., and H. Tschofenig, "A Hitchhiker's 1696 Guide to the (Datagram) Transport Layer Security Protocol 1697 for Smart Objects and Constrained Node Networks", draft- 1698 ietf-lwig-tls-minimal-01 (work in progress), March 2014. 1700 [I-D.ietf-tls-downgrade-scsv] 1701 Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 1702 Suite Value (SCSV) for Preventing Protocol Downgrade 1703 Attacks", draft-ietf-tls-downgrade-scsv-03 (work in 1704 progress), December 2014. 1706 [I-D.ietf-tls-negotiated-dl-dhe] 1707 Gillmor, D., "Negotiated Discrete Log Diffie-Hellman 1708 Ephemeral Parameters for TLS", draft-ietf-tls-negotiated- 1709 dl-dhe-00 (work in progress), July 2014. 1711 [I-D.ietf-tls-prohibiting-rc4] 1712 Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf- 1713 tls-prohibiting-rc4-01 (work in progress), October 2014. 1715 [I-D.ietf-tls-sslv3-diediedie] 1716 Barnes, R., Thomson, M., Pironti, A., and A. Langley, 1717 "Deprecating Secure Sockets Layer Version 3.0", draft- 1718 ietf-tls-sslv3-diediedie-00 (work in progress), December 1719 2014. 1721 [I-D.ietf-uta-tls-bcp] 1722 Sheffer, Y., Holz, R., and P. Saint-Andre, 1723 "Recommendations for Secure Use of TLS and DTLS", draft- 1724 ietf-uta-tls-bcp-08 (work in progress), December 2014. 1726 [I-D.irtf-cfrg-chacha20-poly1305] 1727 Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 1728 protocols", draft-irtf-cfrg-chacha20-poly1305-03 (work in 1729 progress), November 2014. 1731 [I-D.mathewson-no-gmtunixtime] 1732 Mathewson, N. and B. Laurie, "Deprecating gmt_unix_time in 1733 TLS", draft-mathewson-no-gmtunixtime-00 (work in 1734 progress), December 2013. 1736 [I-D.schmertmann-dice-ccm-psk-pfs] 1737 Schmertmann, L. and C. Bormann, "ECDHE-PSK AES-CCM Cipher 1738 Suites with Forward Secrecy for Transport Layer Security 1739 (TLS)", draft-schmertmann-dice-ccm-psk-pfs-01 (work in 1740 progress), August 2014. 1742 [IANA-TLS] 1743 IANA, "TLS Cipher Suite Registry", 1744 http://www.iana.org/assignments/tls-parameters/ 1745 tls-parameters.xhtml#tls-parameters-4, 2014. 1747 [ImprintingSurvey] 1748 Chilton, E., "A Brief Survey of Imprinting Options for 1749 Constrained Devices", URL: http://www.lix.polytechnique.fr 1750 /hipercom/SmartObjectSecurity/papers/EricRescorla.pdf, 1751 March 2012. 1753 [Keylength] 1754 Giry, D., "Cryptographic Key Length Recommendations", 1755 http://www.keylength.com, November 2014. 1757 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1758 November 1990. 1760 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 1761 for IP version 6", RFC 1981, August 1996. 1763 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1764 Hashing for Message Authentication", RFC 2104, February 1765 1997. 1767 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 1768 CBC-MAC (CCM)", RFC 3610, September 2003. 1770 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1771 Requirements for Security", BCP 106, RFC 4086, June 2005. 1773 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1774 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1775 for Transport Layer Security (TLS)", RFC 4492, May 2006. 1777 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1778 (SHA and HMAC-SHA)", RFC 4634, July 2006. 1780 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1781 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1782 Overview, Assumptions, Problem Statement, and Goals", RFC 1783 4919, August 2007. 1785 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1786 "Transport Layer Security (TLS) Session Resumption without 1787 Server-Side State", RFC 5077, January 2008. 1789 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1790 Encryption", RFC 5116, January 2008. 1792 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 1793 Authentication Protocol", RFC 5216, March 2008. 1795 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1796 Authentication Protocol (EAP) Key Management Framework", 1797 RFC 5247, August 2008. 1799 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1800 Housley, R., and W. Polk, "Internet X.509 Public Key 1801 Infrastructure Certificate and Certificate Revocation List 1802 (CRL) Profile", RFC 5280, May 2008. 1804 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 1805 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 1806 August 2008. 1808 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 1809 Management Protocol (TAMP)", RFC 5934, August 2010. 1811 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1812 Curve Cryptography Algorithms", RFC 6090, February 2011. 1814 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 1815 Transport Layer Security (TLS)", RFC 6655, July 2012. 1817 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1818 Format", RFC 6690, August 2012. 1820 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 1821 Multiple Certificate Status Request Extension", RFC 6961, 1822 June 2013. 1824 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1825 Constrained-Node Networks", RFC 7228, May 2014. 1827 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1828 Application Protocol (CoAP)", RFC 7252, June 2014. 1830 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1831 Attack", BCP 188, RFC 7258, May 2014. 1833 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer 1834 Security (TLS) and Datagram Transport Layer Security 1835 (DTLS)", RFC 7366, September 2014. 1837 [RFC7390] Rahman, A. and E. Dijk, "Group Communication for the 1838 Constrained Application Protocol (CoAP)", RFC 7390, 1839 October 2014. 1841 [RFC7397] Gilger, J. and H. Tschofenig, "Report from the Smart 1842 Object Security Workshop", RFC 7397, December 2014. 1844 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 1845 IPv6 over Low-Power Wireless Personal Area Networks 1846 (6LoWPANs)", RFC 7400, November 2014. 1848 [Tripple-HS] 1849 Bhargavan, K., Delignat-Lavaud, C., Pironti, A., and P. 1850 Strub, "Triple Handshakes and Cookie Cutters: Breaking and 1851 Fixing Authentication over TLS", IEEE Symposium on 1852 Security and Privacy, pages 98-113, 2014. 1854 Appendix A. Conveying DTLS over SMS 1856 This section is normative for the use of DTLS over SMS. Timer 1857 recommendations are already outlined in Section 13 and also 1858 applicable to the transport of DTLS over SMS. 1860 This section requires readers to be familiar with the terminology and 1861 concepts described in [GSM-SMS], and [WAP-WDP]. 1863 The remainder of this section assumes Mobile Stations are capable of 1864 producing and consuming 8-bit binary data encoded Transport Protocol 1865 Data Units (TPDU). 1867 A.1. Overview 1869 DTLS adds an additional roundtrip to the TLS [RFC5246] handshake to 1870 serve as a return-routability test for protection against certain 1871 types of DoS attacks. Thus a full blown DTLS handshake comprises up 1872 to 6 "flights" (i.e., logical message exchanges), each of which is 1873 then mapped on to one or more DTLS records using the segmentation and 1874 reassembly (SaR) scheme described in Section 4.2.3 of [RFC6347]. The 1875 overhead for said scheme is 6 bytes per Handshake message which, 1876 given a realistic 10+ messages handshake, would amount around 60 1877 bytes across the whole handshake sequence. 1879 Note that the DTLS SaR scheme is defined for handshake messages only. 1880 In fact, DTLS records are never fragmented and MUST fit within a 1881 single transport layer datagram. 1883 SMS provides an optional segmentation and reassembly scheme as well, 1884 known as Concatenated short messages (see Section 9.2.3.24.1 of 1885 [GSM-SMS]). However, since the SaR scheme in DTLS cannot be 1886 circumvented, the Concatenated short messages mechanism SHOULD NOT be 1887 used during handshake to avoid redundant overhead. Before starting 1888 the handshake phase (either actively or passively), the DTLS 1889 implementation MUST be explicitly configured with the PMTU of the SMS 1890 transport in order to correctly instrument its SaR function. The 1891 PMTU SHALL be 133 bytes if WDP-based multiplexing is used (see 1892 Appendix A.3), 140 bytes otherwise. 1894 It is RECOMMENDED to use the established security context over the 1895 longest possible period (possibly until a Closure Alert message is 1896 received, or after a very long inactivity timeout) to avoid the 1897 expensive re-establishment of the security association. 1899 A.2. Message Segmentation and Re-Assembly 1901 The content of an SMS message is carried in the TP-UserData field, 1902 and its size may be up to 140 bytes. As already mentioned in 1903 Appendix A.1, longer (i.e., up to 34170 bytes) messages can be sent 1904 using Concatenated SMS. 1906 This scheme consumes 6-7 bytes (depending on whether the short or 1907 long segmentation format is used) of the TP-UserData field, thus 1908 reducing the space available for the actual content of the SMS 1909 message to 133-134 bytes per TPDU. 1911 Though in principle a PMTU value higher than 140 bytes could be used, 1912 which may look like an appealing option given its more efficient use 1913 of the transport, there are disadvantages to consider. First, there 1914 is an additional overhead of 7 bytes per TPDU to be paid to the SaR 1915 function (which is in addition to the overhead introduced by the DTLS 1916 SaR mechanism. Second, some networks only partially support the 1917 Concatenated SMS function and others do not support it at all. 1919 For these reasons, the Concatenated short messages mechanism SHOULD 1920 NOT be used, and it is RECOMMENDED to leave the same PMTU settings 1921 used during the handshake phase, i.e., 133 bytes if WDP- based 1922 multiplexing is enabled, 140 bytes otherwise. 1924 Note that, after DTLS handshake has completed, any fragmentation and 1925 reassembly logic that pertains the application layer (e.g., 1926 segmenting CoAP messages into DTLS records and reassembling them 1927 after the crypto operations have been successfully performed) needs 1928 to be handled by the application that uses the established DTLS 1929 tunnel. 1931 A.3. Multiplexing Security Associations 1933 Unlike IPsec ESP/AH, DTLS records do not contain any association 1934 identifiers. Applications must arrange to multiplex between 1935 associations on the same endpoint which, when using UDP/IP, is 1936 usually done with the host/port number. 1938 If the DTLS server allows more than one client to be active at any 1939 given time, then the WAP User Datagram Protocol [WAP-WDP] can be used 1940 to achieve multiplexing of the different security associations. (The 1941 use of WDP provides the additional benefit that upper layer protocols 1942 can operate independently of the underlying wireless network, hence 1943 achieving application-agnostic transport handover.) 1945 The total overhead cost for encoding the WDP source and destination 1946 ports is 7 bytes out of the total available for the SMS content. 1948 The receiving side of the communication gets the source address from 1949 the originator address (TP-OA) field of the SMS-DELIVER TPDU. This 1950 way an unique 4-tuple identifying the security association can be 1951 reconstructed at both ends. (When replying to its DTLS peer, the 1952 sender will swaps the TP-OA and TP-DA parameters and the source and 1953 destination ports in the WDP.) 1955 A.4. Timeout 1957 If SMS-STATUS-REPORT messages are enabled, their receipt is not to be 1958 interpreted as the signal that the specific handshake message has 1959 been acted upon by the receiving party. Therefore, it MUST NOT be 1960 taken into account by the DTLS timeout and retransmission function. 1962 Handshake messages MUST carry a validity period (TP-VP parameter in a 1963 SMS-SUBMIT TPDU) that is not less than the current value of the 1964 retransmission timeout. In order to avoid persisting messages in the 1965 network that will be discarded by the receiving party, handshake 1966 messages SHOULD carry a validity period that is the same as, or just 1967 slightly higher than, the current value of the retransmission 1968 timeout. 1970 Appendix B. DTLS Record Layer Per-Packet Overhead 1972 Figure 10 shows the overhead for the DTLS record layer for protecting 1973 data traffic when AES-128-CCM with an 8-octet Integrity Check Value 1974 (ICV) is used. 1976 DTLS Record Layer Header................13 bytes 1977 Nonce (Explicit).........................8 bytes 1978 ICV..................................... 8 bytes 1979 ------------------------------------------------ 1980 Overhead................................29 bytes 1981 ------------------------------------------------ 1983 Figure 10: AES-128-CCM-8 DTLS Record Layer Per-Packet Overhead. 1985 The DTLS record layer header has 13 octets and consists of 1987 o 1 octet content type field, 1989 o 2 octet version field, 1991 o 2 octet epoch field, 1993 o 6 octet sequence number, 1995 o 2 octet length field. 1997 The "nonce" input to the AEAD algorithm is exactly that of [RFC5288], 1998 i.e., 12 bytes long. It consists of a 4 octet salt and an 8 octet 1999 nonce. The salt is the "implicit" part of the nonce and is not sent 2000 in the packet. Since the nonce_explicit may be the 8 octet sequence 2001 number and, in DTLS, it is the 8 octet epoch concatenated with the 6 2002 octet sequence number. 2004 RFC 6655 [RFC6655] allows the nonce_explicit to be a sequence number 2005 or something else. This document makes this use more restrictive for 2006 use with DTLS: the 64-bit none_explicit MUST be the 16-bit epoch 2007 concatenated with the 48-bit seq_num. The sequence number component 2008 of the nonce_explicit field at the AES-CCM layer is an exact copy of 2009 the sequence number in the record layer header field. This leads to 2010 a duplication of 8-bytes per record. 2012 To avoid this 8-byte duplication RFC 7400 [RFC7400] provides help 2013 with the use of the generic header compression technique for IPv6 2014 over Low-Power Wireless Personal Area Networks (6LoWPANs). Note that 2015 this header compression technique is not available when DTLS is 2016 exchanged over transports that do not use IPv6 or 6LoWPAN, such as 2017 the SMS transport described in Appendix A. 2019 Appendix C. DTLS Fragmentation 2021 [Editor's Note: Proposed text that requires discussion. ] 2023 Section 4.2.3 of [RFC6347] advises DTLS implementations to not 2024 produce overlapping fragments, but requires receivers to be able to 2025 cope with them. The need for the latter requisite is explained in 2026 Section 4.1.1.1 of [RFC6347]: accurate path MTU (PMTU) estimation may 2027 be traded for shorter handshake completion time. This approach may 2028 be beneficial in unconstrained networks where a PMTU of 1280 bytes 2029 can be pretty much universally assumed. However, when the handshake 2030 is carried over a narrow-band radio technology, such as IEEE 802.15.4 2031 or GSM-SMS, and the client is lacking reliable PMTU data to inform 2032 fragmentation (e.g., using [RFC1981] or [RFC1191]) can put a cost on 2033 the constrained implementation in terms of memory (due to re- 2034 buffering) and latency (due to re-transmission) much higher than the 2035 benefit that it would get from a shorter handshake. 2037 In order to reduce the likelihood of producing different fragment 2038 sizes (and consequent overlaps) within the same handshake, this 2039 document RECOMMENDs: 2041 o for clients (handshake initiators), to perform PMTU discovery 2042 towards the server before handshake starts, and not rely on any 2043 guesses (unless the network path characteristics are reliably 2044 known from another source); 2046 o for servers, to mirror the fragment size selected by their 2047 clients. 2049 Authors' Addresses 2051 Hannes Tschofenig (editor) 2052 ARM Ltd. 2053 110 Fulbourn Rd 2054 Cambridge CB1 9NJ 2055 Great Britain 2057 Email: Hannes.tschofenig@gmx.net 2058 URI: http://www.tschofenig.priv.at 2060 Thomas Fossati 2061 Alcatel-Lucent 2062 3 Ely Road 2063 Milton, Cambridge CB24 6DD 2064 UK 2066 Email: thomas.fossati@alcatel-lucent.com