idnits 2.17.00 (12 Aug 2021) /tmp/idnits41836/draft-ietf-dice-profile-07.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). == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (December 15, 2014) is 2713 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 943, but not defined == Unused Reference: 'I-D.ietf-lwig-tls-minimal' is defined on line 1580, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 1673, 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' -- No information found for draft-bmoeller-tls-falsestart - is the name correct? == Outdated reference: A later version (-04) exists of draft-bormann-core-cocoa-02 == Outdated reference: draft-ietf-core-resource-directory has been published as RFC 9176 -- No information found for draft-ietf-tls-downgrade-scsv - is the name correct? -- No information found for draft-ietf-tls-prohibiting-rc4 - is the name correct? -- No information found for draft-ietf-tls-sslv3-diediedie - is the name correct? == 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 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 (~~), 12 warnings (==), 12 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 18, 2015 Alcatel-Lucent 6 December 15, 2014 8 A TLS/DTLS 1.2 Profile for the Internet of Things 9 draft-ietf-dice-profile-07.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 18, 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 . . . . . . . . . . . . . . 12 64 6. Credential Types . . . . . . . . . . . . . . . . . . . . . . 13 65 6.1. Pre-Shared Secret . . . . . . . . . . . . . . . . . . . . 13 66 6.2. Raw Public Key . . . . . . . . . . . . . . . . . . . . . 15 67 6.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 17 68 7. Signature Algorithm Extension . . . . . . . . . . . . . . . . 20 69 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 20 70 9. Session Resumption . . . . . . . . . . . . . . . . . . . . . 21 71 10. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 22 72 11. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 22 73 12. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 23 74 13. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 25 75 14. Random Number Generation . . . . . . . . . . . . . . . . . . 25 76 15. Truncated MAC and Encrypt-then-MAC Extension . . . . . . . . 26 77 16. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 27 78 17. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 27 79 18. Session Hash . . . . . . . . . . . . . . . . . . . . . . . . 27 80 19. Re-Negotiation Attacks . . . . . . . . . . . . . . . . . . . 28 81 20. Downgrading Attacks . . . . . . . . . . . . . . . . . . . . . 28 82 21. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 29 83 22. Key Length Recommendations . . . . . . . . . . . . . . . . . 30 84 23. False Start . . . . . . . . . . . . . . . . . . . . . . . . . 31 85 24. Privacy Considerations . . . . . . . . . . . . . . . . . . . 32 86 25. Security Considerations . . . . . . . . . . . . . . . . . . . 32 87 26. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 88 27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 89 28. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 90 28.1. Normative References . . . . . . . . . . . . . . . . . . 33 91 28.2. Informative References . . . . . . . . . . . . . . . . . 34 92 Appendix A. Conveying DTLS over SMS . . . . . . . . . . . . . . 38 93 A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 38 94 A.2. Message Segmentation and Re-Assembly . . . . . . . . . . 39 95 A.3. Multiplexing Security Associations . . . . . . . . . . . 40 96 A.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 40 98 Appendix B. DTLS Record Layer Per-Packet Overhead . . . . . . . 41 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 101 1. Introduction 103 An engineer developing an Internet of Things (IoT) device needs to 104 investigate the security threats and decide about the security 105 services that can be used to mitigate these threats. 107 Enabling IoT devices to make data available often requires 108 authentication of the two endpoints and the ability to provide 109 integrity- and confidentiality-protection of exchanged data. While 110 these security services can be provided at different layers in the 111 protocol stack the use of Transport Layer Security (TLS)/Datagram TLS 112 (DTLS) has been very popular with many application protocols and it 113 is likely to be useful for IoT scenarios as well. 115 To make Internet protocols fit constrained devices can be difficult 116 but thanks to the standardization efforts new profiles and protocols 117 are available, such as the Constrained Application Protocol (CoAP) 118 [RFC7252]. UDP is mainly used to carry CoAP messages but other 119 transports can be utilized, such as SMS or even TCP. 121 While this document is inspired by the desire to protect CoAP 122 messages using DTLS 1.2 [RFC6347] the guidance in this document is 123 not limited to CoAP nor to DTLS itself. 125 Instead, this document defines a profile of DTLS 1.2 [RFC6347] and 126 TLS 1.2 [RFC5246] that offers communication security for IoT 127 applications and is reasonably implementable on many constrained 128 devices. Profile thereby means that available configuration options 129 and protocol extensions are utilized to best support the IoT 130 environment. This document does not alter TLS/DTLS specifications 131 and does not introduce any new TLS/DTLS extensions. 133 The main target audience for this document is the embedded system 134 developer configuring and using a TLS/DTLS stack. This document may, 135 however, also help those developing or selecting a suitable TLS/DTLS 136 stack for an Internet of Things product development. 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 Note that "Client" and "Server" in this document refer to TLS/DTLS 145 roles, where the Client initiates the TLS/DTLS handshake. This does 146 not restrict the interaction pattern of the protocols on top of TLS/ 147 DTLS since the record layer allows bi-directional communication. 148 This aspect is further described in Section 4. 150 RFC 7228 [RFC7228] introduces the notion of constrained-node 151 networks, which are small devices with severe constraints on power, 152 memory, and processing resources. The terms constrained devices, and 153 Internet of Things (IoT) devices are used interchangeably. 155 3. TLS/DTLS Protocol Overview 157 The TLS protocol [RFC5246] provides authenticated, confidentiality- 158 and integrity-protected communication between two endpoints. The 159 protocol is composed of two layers: the Record Protocol and the 160 Handshake Protocol. At the lowest level, layered on top of a 161 reliable transport protocol (e.g., TCP), is the Record Protocol. It 162 provides connection security by using symmetric cryptography for 163 confidentiality, data origin authentication, and integrity 164 protection. The Record Protocol is used for encapsulation of various 165 higher-level protocols. One such encapsulated protocol, the 166 Handshake Protocol, allows the server and client to authenticate each 167 other and to negotiate an encryption algorithm and cryptographic keys 168 before the application protocol transmits or receives data. 170 The design of DTLS [RFC6347] is intentionally very similar to TLS. 171 Since DTLS operates on top of an unreliable datagram transport a few 172 enhancements to the TLS structure are, however necessary. RFC 6347 173 explains these differences in great detail. As a short summary, for 174 those not familiar with DTLS the differences are: 176 o An explicit sequence number and an epoch field is included in the 177 Record Protocol. Section 4.1 of RFC 6347 explains the processing 178 rules for these two new fields. The value used to compute the MAC 179 is the 64-bit value formed by concatenating the epoch and the 180 sequence number. 182 o Stream ciphers must not be used with DTLS. The only stream cipher 183 defined for TLS 1.2 is RC4 and due to cryptographic weaknesses it 184 is not recommended anymore even for use with TLS 185 [I-D.ietf-tls-prohibiting-rc4]. 187 o The TLS Handshake Protocol has been enhanced to include a 188 stateless cookie exchange for Denial of Service (DoS) resistance. 189 For this purpose a new handshake message, the HelloVerifyRequest, 190 was added to DTLS. This handshake message is sent by the server 191 and includes a stateless cookie, which is returned in a 192 ClientHello message back to the server. Although the exchange is 193 optional for the server to execute, a client implementation has to 194 be prepared to respond to it. Furthermore, the handshake message 195 format has been extended to deal with message loss, reordering, 196 and fragmentation. Retransmission timers have been included to 197 deal with message loss. 199 4. Communication Models 201 This document describes a profile of TLS/DTLS 1.2 and, to be useful, 202 it has to make assumptions about the envisioned communication 203 architecture. 205 Two communication architectures (and consequently two profiles) are 206 described in this document. 208 4.1. Constrained TLS/DTLS Clients 210 The communication architecture shown in Figure 1 assumes a unicast 211 communication interaction with an IoT device utilizing a constrained 212 TLS/DTLS client interacting with one or multiple TLS/DTLS servers. 214 Before a client can initiate the TLS/DTLS handshake it needs to know 215 the IP address of that server and what credentials to use. 216 Application layer protocols, such as CoAP, conveyed on top of DTLS 217 may need additional information, such information about URLs of the 218 endpoints the CoAP needs to register and publish information to. 219 This configuration information (including credentials) may be 220 conveyed to clients as part of a firmware/software package or via a 221 configuration protocol. The following credential types are supported 222 by this profile: 224 o For PSK-based authentication (see Section 6.1), this includes the 225 paired "PSK identity" and shared secret to be used with each 226 server. 228 o For raw public key-based authentication (see Section 6.2), this 229 includes either the server's public key or the hash of the 230 server's public key. 232 o For certificate-based authentication (see Section 6.3), this 233 includes a pre-populated trust anchor store that allows the DTLS 234 stack to perform path validation for the certificate obtained 235 during the handshake with the server. 237 This document focuses on the description of the DTLS client-side 238 functionality but, quite naturally, the equivalent server-side 239 support has to be available. 241 +////////////////////////////////////+ 242 | Configuration | 243 |////////////////////////////////////| 244 | Server A --> PSK Identity, PSK | 245 | Server B --> Public Key (Server B),| 246 | Public Key (Client) | 247 | Server C --> Public Key (Client), | 248 | Trust Anchor Store | 249 +------------------------------------+ 250 oo 251 oooooo 252 o 253 +-----------+ 254 |Constrained| 255 |TLS/DTLS | 256 |Client |- 257 +-----------+ \ 258 \ ,-------. 259 ,' `. +------+ 260 / IP-based \ |Server| 261 ( Network ) | A | 262 \ / +------+ 263 `. ,' 264 '---+---' +------+ 265 | |Server| 266 | | B | 267 | +------+ 268 | 269 | +------+ 270 +----------------->|Server| 271 | C | 272 +------+ 274 Figure 1: Constrained Client Profile. 276 4.1.1. Examples of Constrained Client Exchanges 278 4.1.1.1. Network Access Authentication Example 280 Re-use is a recurring theme when considering constrained environments 281 and is behind a lot of the directions taken in developments for 282 constrained environments. The corollary of re-use is to not add 283 functionality if it can be avoided. An example relevant to the use 284 of TLS is network access authentication, which takes place when a 285 device connects to a network and needs to go through an 286 authentication and access control procedure before it is allowed to 287 communicate with other devices or connect to the Internet. 289 Figure 2 shows the network access architecture with the IoT device 290 initiating the communication to an access point in the network using 291 the procedures defined for a specific physical layer. Since 292 credentials may be managed and stored centrally, in the 293 Authentication, Authorization, and Accounting (AAA) server, the 294 security protocol exchange may need to be relayed via the 295 Authenticator, i.e., functionality running on the access point, to 296 the AAA server. The authentication and key exchange protocol itself 297 is encapsulated within a container, the Extensible Authentication 298 Protocol (EAP), and messages are conveyed back and forth between the 299 EAP endpoints, namely the EAP peer located on the IoT device and the 300 EAP server located on the AAA server or the access point. To route 301 EAP messages from the access point, acting as a AAA client, to the 302 AAA server requires an adequate protocol mechanism, name RADIUS or 303 Diameter. 305 More details about the concepts and a description about the 306 terminology can be found in RFC 5247 [RFC5247]. 308 +--------------+ 309 |Authentication| 310 |Authorization | 311 |Accounting | 312 |Server | 313 |(EAP Server) | 314 | | 315 +-^----------^-+ 316 * EAP o RADIUS/ 317 * o Diameter 318 --v----------v-- 319 /// \\\ 320 // \\ 321 | Federation | 322 | Substrate | 323 \\ // 324 \\\ /// 325 --^----------^-- 326 * EAP o RADIUS/ 327 * o Diameter 328 +-------------+ +-v----------v--+ 329 | | EAP/EAP Method | | 330 | Internet of |<***************************>| Access Point | 331 | Things | |(Authenticator)| 332 | Device | EAP Lower Layer and |(AAA Client) | 333 | (EAP Peer) | Secure Association Protocol | | 334 | |<--------------------------->| | 335 | | | | 336 | | Physical Layer | | 337 | |<===========================>| | 338 +-------------+ +---------------+ 339 Legend: 341 <****>: Device-to-AAA Server Exchange 342 <---->: Device-to-Authenticator Exchange 343 : AAA Client-to-AAA Server Exchange 344 <====>: Phyiscal layer like IEEE 802.11/802.15.4 346 Figure 2: Network Access Architecture.. 348 One standardized EAP method is EAP-TLS, defined in RFC 5216 349 [RFC5216], which re-uses the TLS-based protocol exchange and 350 encapsulates it inside the EAP payload. In terms of re-use this 351 allows many components of the TLS protocol to be shared between the 352 network access security functionality and the TLS functionality 353 needed for securing application layer traffic. The EAP-TLS exchange 354 is shown in Figure 3 where it is worthwhile to point out that in EAP 355 the client / server roles are reversed but with the use of EAP-TLS 356 the IoT device acts as a TLS client. 358 Authenticating Peer Authenticator 359 ------------------- ------------- 360 <- EAP-Request/ 361 Identity 362 EAP-Response/ 363 Identity (MyID) -> 364 <- EAP-Request/ 365 EAP-Type=EAP-TLS 366 (TLS Start) 367 EAP-Response/ 368 EAP-Type=EAP-TLS 369 (TLS client_hello)-> 370 <- EAP-Request/ 371 EAP-Type=EAP-TLS 372 (TLS server_hello, 373 TLS certificate, 374 [TLS server_key_exchange,] 375 TLS certificate_request, 376 TLS server_hello_done) 377 EAP-Response/ 378 EAP-Type=EAP-TLS 379 (TLS certificate, 380 TLS client_key_exchange, 381 TLS certificate_verify, 382 TLS change_cipher_spec, 383 TLS finished) -> 384 <- EAP-Request/ 385 EAP-Type=EAP-TLS 386 (TLS change_cipher_spec, 387 TLS finished) 388 EAP-Response/ 389 EAP-Type=EAP-TLS -> 390 <- EAP-Success 392 Figure 3: EAP-TLS Exchange. 394 The guidance in this document also applies to the use of EAP-TLS for 395 network access authentication. An IoT device using a network access 396 authentication solution based on TLS can re-use most parts of the 397 code for the use of DTLS/TLS at the application layer thereby saving 398 a significant amount of flash memory. Note, however, that the 399 credentials used for network access authentication and those used for 400 application layer security are very likely different. 402 4.1.1.2. CoAP-based Data Exchange Example 404 When a constrained client uploads sensor data to a server 405 infrastructure it may use CoAP by pushing the data via a POST to a 406 pre-configured endpoint on the server. In certain circumstances this 407 might be too limiting and additional functionality is needed, as 408 shown in Figure 4, where the IoT device itself runs a CoAP server 409 hosting the resource that is made accessible to other entities. 410 Despite running a CoaP server on the IoT device it is still the DTLS 411 client on the IoT device that initiates the interaction with the non- 412 constrained resource server in our scenario. 414 Figure 4 shows a sensor starting with a DTLS exchange with a resource 415 server to register available resources. The initial DTLS interaction 416 between the sensor, acting as a DTLS client, and the resource server, 417 acting as a DTLS server, will be a full DTLS handshake. Once this 418 handshake is complete both parties have established the DTLS record 419 layer, which can subsequently be used to secure the CoAP message 420 exchange, which starts with a the resource registration. Details 421 about the resource registry capabilities can be found in 422 [I-D.ietf-core-resource-directory]. 424 After some time (assuming that the client regularly refreshes its 425 registration) the resource server receives a request (not shown) from 426 an application to retrieve the temperature information from the 427 sensor. This request is relayed by the resource directory to the 428 sensor using a GET message exchange. The already established DTLS 429 record layer can be used to secure the message exchange. 431 Resource 432 Sensor Directory 433 ------ --------- 435 +--- 436 | 437 | ClientHello --------> 438 | client_certificate_type 439 F| server_certificate_type 440 U| 441 L| <------- HelloVerifyRequest 442 L| 443 | ClientHello --------> 444 D| client_certificate_type 445 T| server_certificate_type 446 L| 447 S| ServerHello 448 | client_certificate_type 450 H| server_certificate_type 451 A| Certificate 452 N| ServerKeyExchange 453 D| CertificateRequest 454 S| <-------- ServerHelloDone 455 H| 456 A| Certificate 457 K| ClientKeyExchange 458 E| CertificateVerify 459 | [ChangeCipherSpec] 460 | Finished --------> 461 | 462 | [ChangeCipherSpec] 463 | <-------- Finished 464 +--- 466 +--- ///+ 467 C| \ D 468 O| Req: POST coap://rd.example.com/rd?ep=node1 \ T 469 A| Payload: \ L 470 P| ;ct=41; \ S 471 | rt="temperature-c";if="sensor", \ 472 R| ;ct=41; \ R 473 D| rt="light-lux";if="sensor" \ E 474 | --------> \ C 475 R| \ O 476 E| \ R 477 G| Res: 2.01 Created \ D 478 .| <-------- Location: /rd/4521 \ 479 | \ L 480 +--- \ A 481 \ Y 482 * \ E 483 * (time passes) \ R 484 * \ 485 +--- \ P 486 C| \ R 487 O| Req: GET coaps://sensor.example.com/temp \ O 488 A| <-------- \ T 489 P| \ E 490 | Res: 2.05 Content \ C 491 G| Payload: \ T 492 E| 25.5 --------> \ E 493 T| \ D 494 +--- ///+ 496 Figure 4: DTLS/CoAP exchange using Resource Directory. 498 4.2. Constrained TLS/DTLS Servers 500 TEXT TO BE DONE 502 5. The TLS/DTLS Ciphersuite Concept 504 TLS (and consequently DTLS) has the concept of ciphersuites and an 505 IANA registry [IANA-TLS] was created to register the suites. A 506 ciphersuite (and the specification that defines it) contains the 507 following information: 509 o Authentication and key exchange algorithm (e.g., PSK) 511 o Cipher and key length (e.g., Advanced Encryption Standard (AES) 512 with 128 bit keys [AES]) 514 o Mode of operation (e.g., Counter with Cipher Block Chaining - 515 Message Authentication Code (CBC-MAC) Mode (CCM) for AES) 516 [RFC3610] 518 o Hash algorithm for integrity protection, such as the Secure Hash 519 Algorithm (SHA) in combination with Keyed-Hashing for Message 520 Authentication (HMAC) (see [RFC2104] and [RFC4634]) 522 o Hash algorithm for use with the pseudorandom function (e.g., HMAC 523 with the SHA-256) 525 o Misc information (e.g., length of authentication tags) 527 o Information whether the ciphersuite is suitable for DTLS or only 528 for TLS 530 The TLS ciphersuite TLS_PSK_WITH_AES_128_CCM_8, for example, uses a 531 pre-shared authentication and key exchange algorithm. RFC 6655 532 [RFC6655] defines this ciphersuite. It uses the Advanced Encryption 533 Standard (AES) encryption algorithm, which is a block cipher. Since 534 the AES algorithm supports different key lengths (such as 128, 192 535 and 256 bits) this information has to be specified as well and the 536 selected ciphersuite supports 128 bit keys. A block cipher encrypts 537 plaintext in fixed-size blocks and AES operates on fixed block size 538 of 128 bits. For messages exceeding 128 bits, the message is 539 partitioned into 128-bit blocks and the AES cipher is applied to 540 these input blocks with appropriate chaining, which is called mode of 541 operation. 543 TLS 1.2 introduced Authenticated Encryption with Associated Data 544 (AEAD) ciphersuites (see [RFC5116] and [RFC6655]). AEAD is a class 545 of block cipher modes which encrypt (parts of) the message and 546 authenticate the message simultaneously. Examples of such modes 547 include the Counter with Cipher Block Chaining - Message 548 Authentication Code (CBC-MAC) Mode (CCM) mode, and the Galois/Counter 549 Mode (GCM) (see [RFC5288] and [RFC7251]). 551 Some AEAD ciphersuites have shorter authentication tags and are 552 therefore more suitable for networks with low bandwidth where small 553 message size matters. The TLS_PSK_WITH_AES_128_CCM_8 ciphersuite 554 that ends in "_8" has an 8-octet authentication tag, while the 555 regular CCM ciphersuites have, at the time of writing, 16-octet 556 authentication tags. 558 TLS 1.2 also replaced the combination of MD5/SHA-1 hash functions in 559 the TLS pseudo random function (PRF) used in earlier versions of TLS 560 with cipher-suite-specified PRFs. For this reason authors of more 561 recent TLS 1.2 ciphersuite specifications explicitly indicate the MAC 562 algorithm and the hash functions used with the TLS PRF. 564 6. Credential Types 566 6.1. Pre-Shared Secret 568 The use of pre-shared secret credentials is one of the most basic 569 techniques for TLS/DTLS since it is both computational efficient and 570 bandwidth conserving. Pre-shared secret based authentication was 571 introduced to TLS with RFC 4279 [RFC4279]. The exchange shown in 572 Figure 5 illustrates the DTLS exchange including the cookie exchange. 573 While the server is not required to initiate a cookie exchange with 574 every handshake, the client is required to implement and to react on 575 it when challenged. The cookie exchange allows the server to react 576 to flooding attacks. 578 Client Server 579 ------ ------ 580 ClientHello --------> 582 <-------- HelloVerifyRequest 583 (contains cookie) 585 ClientHello --------> 586 (with cookie) 587 ServerHello 588 *ServerKeyExchange 589 <-------- ServerHelloDone 590 ClientKeyExchange 591 ChangeCipherSpec 592 Finished --------> 593 ChangeCipherSpec 594 <-------- Finished 596 Application Data <-------> Application Data 598 Legend: 600 * indicates an optional message payload 602 Figure 5: DTLS PSK Authentication including the Cookie Exchange. 604 [RFC4279] does not mandate the use of any particular type of client 605 identity and the client and server have to agree on the identities 606 and keys to be used. The mandated encoding of identities in 607 Section 5.1 of RFC 4279 aims to improve interoperability for those 608 cases where the identity is configured by a person using some 609 management interface. Many IoT devices do, however, not have a user 610 interface and most of their credentials are bound to the device 611 rather than the user. Furthermore, credentials are often provisioned 612 into trusted hardware modules or in the firmware by developers. As 613 such, the encoding considerations are not applicable to this usage 614 environment. For use with this profile the PSK identities SHOULD NOT 615 assume a structured format (as domain names, Distinguished Names, or 616 IP addresses have) and a bit-by-bit comparison operation can then be 617 used by the server-side infrastructure. 619 The client indicates which key it uses by including a "PSK identity" 620 in the ClientKeyExchange message. As described in Section 4 clients 621 may have multiple pre-shared keys with a single server and to help 622 the client in selecting which PSK identity / PSK pair to use, the 623 server can provide a "PSK identity hint" in the ServerKeyExchange 624 message. If the hint for PSK key selection is based on the domain 625 name of the server then servers SHOULD NOT send the "PSK identity 626 hint" in the ServerKeyExchange message. In general, servers SHOULD 627 NOT send the "PSK identity hint" in the ServerKeyExchange message and 628 client MUST ignore the message. This approach is inline with RFC 629 4279 [RFC4279]. Note: The TLS Server Name Indication (SNI) extension 630 allows the client to tell a server the name of the server it is 631 contacting, which is relevant for hosting environments. A server 632 using the identity hint needs to guide the selection based on a 633 received SNI value from the client. 635 RFC 4279 requires TLS implementations supporting PSK ciphersuites to 636 support arbitrary PSK identities up to 128 octets in length, and 637 arbitrary PSKs up to 64 octets in length. This is a useful 638 assumption for TLS stacks used in the desktop and mobile environments 639 where management interfaces are used to provision identities and 640 keys. For the IoT environment, keys are distributed as part of 641 hardware modules or are embedded into the firmware and, as such, 642 these restrictions are not applicable to this profile. 644 Constrained Application Protocol (CoAP) [RFC7252] currently specifies 645 TLS_PSK_WITH_AES_128_CCM_8 as the mandatory to implement ciphersuite 646 for use with shared secrets. This ciphersuite uses the AES algorithm 647 with 128 bit keys and CCM as the mode of operation. The label "_8" 648 indicates that an 8-octet authentication tag is used. This 649 ciphersuite makes use of the default TLS 1.2 Pseudorandom Function 650 (PRF), which uses an HMAC with the SHA-256 hash function. (Note that 651 all IoT implementations will need a SHA-256 implementation due to the 652 construction of the pseudo-random number function in DTLS/TLS 1.2.) 654 A device compliant with the profile in this section MUST implement 655 TLS_PSK_WITH_AES_128_CCM_8 and follow the guidance from this section. 657 6.2. Raw Public Key 659 The use of raw public keys with TLS/DTLS, as defined in [RFC7250], is 660 the first entry point into public key cryptography without having to 661 pay the price of certificates and a public key infrastructure (PKI). 662 The specification re-uses the existing Certificate message to convey 663 the raw public key encoded in the SubjectPublicKeyInfo structure. To 664 indicate support two new extensions had been defined, as shown in 665 Figure 6, namely the server_certificate_type and the 666 client_certificate_type. To operate this mechanism securely it is 667 necessary to authenticate and authorize the public keys out-of-band. 668 This document therefore assumes that a client implementation comes 669 with one or multiple raw public keys of servers, it has to 670 communicate with, pre-provisioned. Additionally, a device will have 671 its own raw public key. To replace, delete, or add raw public key to 672 this list requires a software update, for example using a firmware 673 update mechanism. 675 Client Server 676 ------ ------ 678 ClientHello --------> 679 client_certificate_type 680 server_certificate_type 682 <------- HelloVerifyRequest 684 ClientHello --------> 685 client_certificate_type 686 server_certificate_type 688 ServerHello 689 client_certificate_type 690 server_certificate_type 691 Certificate 692 ServerKeyExchange 693 CertificateRequest 694 <-------- ServerHelloDone 696 Certificate 697 ClientKeyExchange 698 CertificateVerify 699 [ChangeCipherSpec] 700 Finished --------> 702 [ChangeCipherSpec] 703 <-------- Finished 705 Figure 6: DTLS Raw Public Key Exchange including the Cookie Exchange. 707 The CoAP recommended ciphersuite for use with this credential type is 708 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251]. This elliptic curve 709 cryptography (ECC) based AES-CCM TLS ciphersuite uses the Ephemeral 710 Elliptic Curve Diffie-Hellman (ECDHE) as the key establishment 711 mechanism and an Elliptic Curve Digital Signature Algorithm (ECDSA) 712 for authentication. Due to the use of Ephemeral Elliptic Curve 713 Diffie-Hellman (ECDHE) the recently introduced named Diffie-Hellman 714 groups [I-D.ietf-tls-negotiated-dl-dhe] are not applicable to this 715 profile. This ciphersuite make use of the AEAD capability in DTLS 716 1.2 and utilizes an eight-octet authentication tag. The use of a 717 Diffie-Hellman key exchange adds perfect forward secrecy (PFS). More 718 details about PFS can be found in Section 11. 720 RFC 6090 [RFC6090] provides valuable information for implementing 721 Elliptic Curve Cryptography algorithms, particularly for choosing 722 methods that have been available in the literature for a long time 723 (i.e., 20 years and more). 725 A device compliant with the profile in this section MUST implement 726 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this 727 section. 729 6.3. Certificates 731 The use of mutual certificate-based authentication is shown in 732 Figure 7, which makes use of the cached info extension 733 [I-D.ietf-tls-cached-info]. Support of the cached info extension is 734 REQUIRED. Caching certificate chains allows the client to reduce the 735 communication overhead significantly since otherwise the server would 736 provide the end entity certificate, and the certificate chain. 737 Because certificate validation requires that root keys be distributed 738 independently, the self-signed certificate that specifies the root 739 certificate authority is omitted from the chain. Client 740 implementations MUST be provisioned with a trust anchor store that 741 contains the root certificates. The use of the Trust Anchor 742 Management Protocol (TAMP) [RFC5934] is, however, not envisioned. 743 Instead IoT devices using this profile MUST rely on a software update 744 mechanism to provision these trust anchors. 746 Client Server 747 ------ ------ 749 ClientHello --------> 750 cached_information 752 <------- HelloVerifyRequest 754 ClientHello --------> 755 cached_information 756 ServerHello 757 cached_information 758 Certificate 759 ServerKeyExchange 760 CertificateRequest 761 <-------- ServerHelloDone 763 Certificate 764 ClientKeyExchange 765 CertificateVerify 766 [ChangeCipherSpec] 767 Finished --------> 769 [ChangeCipherSpec] 770 <-------- Finished 772 Figure 7: DTLS Mutual Certificate-based Authentication. 774 When DTLS is used to secure CoAP messages then the server provided 775 certificates MUST contain the fully qualified DNS domain name or 776 "FQDN" as dNSName. The coaps URI scheme is described in Section 6.2 777 of [RFC7252]. This FQDN is stored in the SubjectAltName or in the 778 leftmost CN component of subject name, as explained in 779 Section 9.1.3.3 of [RFC7252], and used by the client to match it 780 against the FQDN used during the look-up process, as described in RFC 781 6125 [RFC6125]. For the profile in this specification does not 782 assume dynamic discovery of local servers. 784 For client certificates the identifier used in the SubjectAltName or 785 in the CN MUST be an EUI-64 [EUI64], as mandated in Section 9.1.3.3 786 of [RFC7252]. 788 For certificate revocation neither the Online Certificate Status 789 Protocol (OCSP) nor Certificate Revocation Lists (CRLs) are used. 790 Instead, this profile relies on a software update mechanism. While 791 multiple OCSP stapling [RFC6961] has recently been introduced as a 792 mechanism to piggyback OCSP request/responses inside the DTLS/TLS 793 handshake to avoid the cost of a separate protocol handshake further 794 investigations are needed to determine its suitability for the IoT 795 environment. 797 Regarding the ciphersuite choice the discussion in Section 6.2 798 applies. Further details about X.509 certificates can be found in 799 Section 9.1.3.3 of [RFC7252]. The TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 800 ciphersuite description in Section 6.2 is also applicable to this 801 section. 803 When using certificates, IoT devices MUST provide support for a 804 server certificate chain of at least 3 not including the trust anchor 805 and MAY reject connections from servers offering chains longer than 806 3. IoT devices MAY have client certificate chains of any length. 807 Obviously, longer chains require more resources to process, transmit 808 or receive. 810 A device compliant with the profile in this section MUST implement 811 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this 812 section. 814 6.3.1. Client Certificate URLs 816 RFC 6066 [RFC6066] allows to avoid sending client-side certificates 817 and uses URLs instead. This reduces the over-the-air transmission. 818 Note that the TLS cached info extension does not provide any help 819 with caching client certificates. 821 Recommendation: Add support for client certificate URLs for those 822 environments where client-side certificates are used. 824 6.3.2. Trusted CA Indication 826 RFC 6066 [RFC6066] allows clients to indicate what trust anchor they 827 support. With certificate-based authentication a DTLS server conveys 828 its end entity certificate to the client during the DTLS exchange 829 provides. Since the server does not necessarily know what trust 830 anchors the client has stored it includes intermediate CA certs in 831 the certificate payload as well to facilitate with certification path 832 construction and path validation. 834 Today, in most IoT deployments there is a fairly static relationship 835 between the IoT device (and the software running on them) and the 836 server- side infrastructure and no such dynamic indication of trust 837 anchors is needed. 839 Recommendation: For IoT deployments where clients talk to a fixed, 840 pre-configured set of servers and where a software update mechanism 841 is available this extension is not recommended. Environments where 842 the client needs to interact with dynamically discovered TLS/DTLS 843 servers this extension may be useful to reduce the communication 844 overhead. Note, however, in that case the TLS cached info extension 845 may help to reduce the communication overhead for everything but the 846 first protocol interaction. 848 7. Signature Algorithm Extension 850 The "signature_algorithms" extension, defined in Section 7.4.1.4.1 of 851 RFC 5246 [RFC5246], allows the client to indicate to the server which 852 signature/hash algorithm pairs may be used in digital signatures. 853 The client MUST send this extension to select the use of SHA-256 854 since otherwise absent this extension RFC 5246 defaults to SHA-1 / 855 ECDSA for the ECDH_ECDSA and the ECDHE_ECDSA key exchange algorithms. 857 The "signature_algorithms" extension is not applicable to the PSK- 858 based ciphersuite described in Section 6.1. 860 8. Error Handling 862 TLS/DTLS uses the Alert protocol to convey error messages and 863 specifies a longer list of errors. However, not all error messages 864 defined in the TLS/DTLS specification are applicable to this profile. 865 In general, there are two categories of errors (as defined in 866 Section 7.2 of RFC 5246), namely fatal errors and warnings. Alert 867 messages with a level of fatal result in the immediate termination of 868 the connection. If possible, developers should try to develop 869 strategies to react to those fatal errors, such as re-starting the 870 handshake or informing the user using the (often limited) user 871 interface. Warnings may be ignored by the application since many IoT 872 devices will either have limited ways to log errors or no ability at 873 all. In any case, implementers have to carefully evaluate the impact 874 of errors and ways to remedy the situation since a commonly used 875 approach for delegating decision making to users is difficult (or 876 impossible) to accomplish in a timely fashion. 878 All error messages marked as RESERVED are only supported for 879 backwards compatibility with SSL and are therefore not applicable to 880 this profile. Those include decryption_failed_RESERVED, 881 no_certificate_RESERVE, and export_restriction_RESERVED. 883 A number of the error messages are applicable only for certificate- 884 based authentication ciphersuites. Hence, for PSK and raw public key 885 use the following error messages are not applicable: 887 o bad_certificate, 888 o unsupported_certificate, 890 o certificate_revoked, 892 o certificate_expired, 894 o certificate_unknown, 896 o unknown_ca, and 898 o access_denied. 900 Since this profile does not make use of compression at the TLS layer 901 the decompression_failure error message is not applicable either. 903 RFC 4279 introduced a new alert message unknown_psk_identity for PSK 904 ciphersuites. As stated in Section 2 of RFC 4279 the 905 decryption_error error message may also be used instead. For this 906 profile the TLS server MUST return the decryption_error error message 907 instead of the unknown_psk_identity since the two mechanisms exist 908 and provide the same functionality. 910 Furthermore, the following errors should not occur with devices and 911 servers supporting this specification but implementations MUST be 912 prepared to process these errors to deal with servers that are not 913 compliant to the profiles in this document: 915 protocol_version: While this document focuses only on one version of 916 the TLS/DTLS protocol, namely version 1.2, ongoing work on TLS/ 917 DTLS 1.3 is in progress at the time of writing. 919 insufficient_security: This error message indicates that the server 920 requires ciphers to be more secure. This document specifies only 921 only one ciphersuite per profile but it is likely that additional 922 ciphtersuites get added over time. 924 user_canceled: Many IoT devices are unattended and hence this error 925 message is unlikely to occur. 927 9. Session Resumption 929 Session resumption is a feature of TLS/DTLS that allows a client to 930 continue with an earlier established session state. The resulting 931 exchange is shown in Figure 8. In addition, the server may choose 932 not to do a cookie exchange when a session is resumed. Still, 933 clients have to be prepared to do a cookie exchange with every 934 handshake. 936 Client Server 937 ------ ------ 939 ClientHello --------> 940 ServerHello 941 [ChangeCipherSpec] 942 <-------- Finished 943 [ChangeCipherSpec] 944 Finished --------> 945 Application Data <-------> Application Data 947 Figure 8: DTLS Session Resumption. 949 Clients MUST implement session resumption to improve the performance 950 of the handshake (in terms of reduced number of message exchanges, 951 lower computational overhead, and less bandwidth conserved). 953 Since the communication model described in Section 4 does not assume 954 that the server is constrained, RFC 5077 [RFC5077] specifying TLS/ 955 DTLS session resumption without server-side state is not utilized by 956 this profile. 958 10. Compression 960 Section 3.3 of [I-D.ietf-uta-tls-bcp] recommends to disable TLS/DTLS- 961 level compression due to attacks, such as CRIME. For IoT 962 applications compression at the TLS/DTLS layer is not needed since 963 application layer protocols are highly optimized and the compression 964 algorithms at the DTLS layer increases code size and complexity. 966 Recommendation: This TLS/DTLS profile MUST NOT implement and use TLS/ 967 DTLS layer compression. 969 11. Perfect Forward Secrecy 971 Perfect forward secrecy (PFS) is a property that preserves the 972 confidentiality of past conversations even in situations where the 973 long-term secret is compromised. 975 The PSK ciphersuite recommended in Section 6.1 does not offer this 976 property since it does not utilize a Diffie-Hellman exchange. New 977 ciphersuites that support PFS for PSK-based authentication, such as 978 proposed in [I-D.schmertmann-dice-ccm-psk-pfs], might become 979 available as standardized ciphersuite in the (near) future. The 980 recommended PSK-based ciphersuite offers excellent performance, a 981 very small memory footprint, and has the lowest on the wire overhead 982 at the expense of not using any public cryptography. For deployments 983 where public key cryptography is acceptable the raw public might 984 offer an acceptable middleground between the PSK ciphersuite in terms 985 of out-of-band validation and the functionality offered by asymmetric 986 cryptography. 988 The use of PFS is a trade-off decision since on one hand the 989 compromise of long-term secrets of embedded devices is more likely 990 than with many other Internet hosts but on the other hand a Diffie- 991 Hellman exchange requires ephemeral key pairs to be generated, which 992 is demanding from a performance point of view. For performance 993 reasons some implementations re-use key pairs over multiple exchanges 994 (rather than generating new keys for each exchange) for the obvious 995 performance improvement. Note, however, that such key re-use over 996 long periods voids the benefits of forward secrecy when an attack 997 gains access to this DH key pair. 999 The impact of the disclosure of past conversations and the desire to 1000 increase the cost for pervasive monitoring (as demanded by [RFC7258]) 1001 has to be taken into account when making a deployment decision. 1003 Recommendation: Client implementations claiming support of this 1004 profile MUST implement the ciphersuites listed in Section 6 according 1005 to the selected credential type. 1007 12. Keep-Alive 1009 RFC 6520 [RFC6520] defines a heartbeat mechanism to test whether the 1010 other peer is still alive. The same mechanism can also be used to 1011 perform Path Maximum Transmission Unit (MTU) Discovery. 1013 A recommendation about the use of RFC 6520 depends on the type of 1014 message exchange an IoT device performs. There are three types of 1015 exchanges that need to be analysed: 1017 Client-Initiated, One-Shot Messages 1019 This is a common communication pattern where IoT devices upload 1020 data to a server on the Internet on an irregular basis. The 1021 communication may be triggered by specific events, such as opening 1022 a door. 1024 Since the upload happens on an irregular and unpredictable basis 1025 and due to renumbering and Network Address Translation (NAT) the 1026 DTLS handshake may need to be re-started (ideally using session 1027 resumption, if possible). 1029 In this case there is no use for a keep-alive extension for this 1030 scenario. 1032 Client-Initiated, Regular Data Uploads 1034 This is a variation of the previous case whereby data gets 1035 uploaded on a regular basis, for example, based on frequent 1036 temperature readings. If neither NAT bindings nor IP address 1037 changes occurred then the record layer will not notice any 1038 changes. For the case where the IP address and port number 1039 changes, it is necessary to re-create the record layer using 1040 session resumption. 1042 In this scenario there is no use for a keep-alive extension. It 1043 is also very likely that the device will enter a sleep cycle in 1044 between data transmissions to keep power consumption low. 1046 Server-Initiated Messages 1048 In the two previous scenarios the client initiated the protocol 1049 interaction but in this case we consider server-initiated 1050 messages. Since messages to the client may get blocked by 1051 intermediaries, such as NATs (including IPv4/IPv6 protocol 1052 translators) and stateful packet filtering firewalls, the initial 1053 connection setup is triggered by the client and then kept alive. 1054 Since state at middleboxes expires fairly quickly (according to 1055 measurements described in [HomeGateway]), regular heartbeats are 1056 necessary whereby these keep-alive messages may be exchanged at 1057 the application layer or within DTLS itself. 1059 For this message exchange pattern the use of DTLS heartbeat 1060 messages is quite useful but may interfere with registrations kept 1061 at the application layer (for example when the CoAP resource 1062 directory is used). The MTU discovery mechanism, which is also 1063 part of [RFC6520], is less likely to be relevant since for many 1064 IoT deployments the most constrained link is the wireless 1065 interface between the IoT device and the network itself (rather 1066 than some links along the end-to-end path). Only in more complex 1067 network topologies, such as multi-hop mesh networks, path MTU 1068 discovery might be appropriate. It also has to be noted that DTLS 1069 itself already provides a basic path discovery mechanism (see 1070 Section 4.1.1.1 of RFC 6347 by using the fragmentation capability 1071 of the handshake protocol). 1073 For server-initiated messages the heartbeat extension can be 1074 RECOMMENDED. 1076 13. Timeouts 1078 To connect to the Internet a variety of wired and wireless 1079 technologies are available. Many of the low power radio 1080 technologies, such as IEEE 802.15.4 or Bluetooth Smart, only support 1081 small frame sizes (e.g., 127 bytes in case of IEEE 802.15.4 as 1082 explained in RFC 4919 [RFC4919]). Other radio technologies, such as 1083 the Global System for Mobile Communications (GSM) using the short 1084 messaging service (SMS) have similar constraints in terms of payload 1085 sizes, such as 140 bytes without the optional segmentation and 1086 reassembly scheme known as Concatenated SMS, but show higher latency. 1088 The DTLS handshake protocol adds a fragmentation and reassembly 1089 mechanism to the TLS handshake protocol since each DTLS record must 1090 fit within a single transport layer datagram, as described in 1091 Section 4.2.3 of [RFC6347]. Since handshake messages are potentially 1092 bigger than the maximum record size, the mechanism fragments a 1093 handshake message over a number of DTLS records, each of which can be 1094 transmitted separately. 1096 To deal with the unreliable message delivery provided by UDP, DTLS 1097 adds timeouts and re-transmissions, as described in Section 4.2.4 of 1098 [RFC6347]. Although the timeout values are implementation specific, 1099 recommendations are provided in Section 4.2.4.1 of [RFC6347], with an 1100 initial timer value of 1 second and twice the value at each 1101 retransmission up to no less than 60 seconds. Due to the nature of 1102 some radio technologies, these values are too aggressive and lead to 1103 spurious failures when messages in flight need longer. 1105 Note: If a round-trip time estimator (such as proposed in 1106 [I-D.bormann-core-cocoa]) is available in the protocol stack of the 1107 device, it could be used to dynamically update the setting of the 1108 retransmit timeout. 1110 Recommendation: Choosing appropriate timeout values is difficult with 1111 infrequent data transmissions, changing network conditions, and large 1112 variance in latency. This specification therefore RECOMMENDS an 1113 initial timer value of 10 seconds with exponential back off up to no 1114 less then 60 seconds. Appendix A provides additional normative text 1115 for carrying DTLS over SMS. 1117 14. Random Number Generation 1119 The TLS/DTLS protocol requires random numbers to be available during 1120 the protocol run. For example, during the ClientHello and the 1121 ServerHello exchange the client and the server exchange random 1122 numbers. Also, the use of the Diffie-Hellman exchange requires 1123 random numbers during the key pair generation. Special care has to 1124 be paid when generating random numbers in embedded systems as many 1125 entropy sources available on desktop operating systems or mobile 1126 devices might be missing, as described in [Heninger]. Consequently, 1127 if not enough time is given during system start time to fill the 1128 entropy pool then the output might be predictable and repeatable, for 1129 example leading to the same keys generated again and again. 1131 It is important to note that sources contributing to the randomness 1132 pool on laptops, or desktop PCs are not available on many IoT device, 1133 such as mouse movement, timing of keystrokes, air turbulence on the 1134 movement of hard drive heads, etc. Other sources have to be found or 1135 dedicated hardware has to be added. 1137 The ClientHello and the ServerHello messages contains the 'Random' 1138 structure, which has two components: gmt_unix_time and a random 1139 sequence of 28 random bytes. gmt_unix_time holds the current time 1140 and date in standard UNIX 32-bit format (seconds since the midnight 1141 starting Jan 1, 1970, GMT). [I-D.mathewson-no-gmtunixtime] argues 1142 that the entire ClientHello.Random value (including gmt_unix_time) 1143 should be set to a cryptographically random sequence because of 1144 privacy concerns regarding device fingerprinting. Since many IoT 1145 devices do not have access to a real-time clock this recommendation 1146 it is RECOMMENDED to follow the guidance outlined in 1147 [I-D.mathewson-no-gmtunixtime] regarding the content of the 1148 ClientHello.Random field. However, for the ServerHello.Random 1149 structure it is RECOMMENDED to maintain the existing structure with 1150 gmt_unix_time followed by a random sequence of 28 random bytes since 1151 the client can use the received time information to securely obtain 1152 time information. 1154 Recommendation: IoT devices using TLS/DTLS MUST offer ways to 1155 generate quality random numbers. Guidelines and requirements for 1156 random number generation can be found in RFC 4086 [RFC4086]. 1158 15. Truncated MAC and Encrypt-then-MAC Extension 1160 The truncated MAC extension was introduced with RFC 6066 [RFC6066] 1161 with the goal to reduce the size of the MAC used at the Record Layer. 1162 This extension was developed for TLS ciphersuites that used older 1163 modes of operation where the MAC and the encryption operation was 1164 performed independently. 1166 The recommended ciphersuites in this document use the newer 1167 Authenticated Encryption with Associated Data (AEAD) construct, 1168 namely the CBC-MAC mode (CCM) with eight-octet authentication tags, 1169 and are therefore not appliable to the truncated MAC extension. 1171 RFC 7366 [RFC7366] introduced the encrypt-then-MAC extension (instead 1172 of the previously used MAC-then-encrypt) since the MAC-then-encrypt 1173 mechanism has been the subject of a number of security 1174 vulnerabilities. RFC 7366 is, however, also not applicable to the 1175 AEAD ciphers recommended in this document. 1177 Recommendation: Since this profile only supports AEAD ciphersuites 1178 these two extensions are not applicable. 1180 16. Server Name Indication (SNI) 1182 This RFC 6066 extension defines a mechanism for a client to tell a 1183 TLS/DTLS server the name of the server it wants to contact. This is 1184 a useful extension for many hosting environments where multiple 1185 virtual servers are run on single IP address. 1187 Recommendation: Unless it is known that a TLS/DTLS client does not 1188 interact with a server in a hosting environment we RECOMMEND clients 1189 to implement the SNI extension. 1191 17. Maximum Fragment Length Negotiation 1193 This RFC 6066 extension lowers the maximum fragment length support 1194 needed for the Record Layer from 2^14 bytes to 2^9 bytes. 1196 This is a very useful extension that allows the client to indicate to 1197 the server how much maximum memory buffers it uses for incoming 1198 messages. Ultimately, the main benefit of this extension is it to 1199 allows client implementations to lower their RAM requirements since 1200 the client does not need to accept packets of large size (such as 16k 1201 packets as required by plain TLS/DTLS). 1203 Recommendation: Client implementations MUST support this extension. 1205 18. Session Hash 1207 In order to begin connection protection, the Record Protocol requires 1208 specification of a suite of algorithms, a master secret, and the 1209 client and server random values. The algorithm for computing the 1210 master secret is defined in Section 8.1 of RFC 5246 but only includes 1211 a small number of parameters exchanged during the handshake and does 1212 not include parameters like the client and server identities. This 1213 can be utilized by an attacker to mount a man-in-the-middle attack 1214 since the master secret is not guaranteed to be unique across 1215 sessions, as discovered in the 'Triple Handshake' attack 1216 [Tripple-HS]. 1218 [I-D.ietf-tls-session-hash] defines a TLS extension that binds the 1219 master secret to a log of the full handshake that computes it, thus 1220 preventing such attacks. 1222 Recommendation: Client implementations SHOULD implement this 1223 extension even though the ciphersuites recommended by this profile 1224 are not vulnerable to this attack. For Diffie-Hellman-based 1225 ciphersuites the keying material is contributed by both parties and 1226 in case of the pre-shared secret key ciphersuite both parties need to 1227 be in possession of the shared secret to ensure that the handshake 1228 completes successfully. It is, however, possible that some 1229 application layer protocols will tunnel other authentication 1230 protocols on top of DTLS making this attack relevant again. 1232 19. Re-Negotiation Attacks 1234 TLS/DTLS allows a client and a server who already have a TLS/DTLS 1235 connection to negotiate new parameters, generate new keys, etc by 1236 using the re-negotiation feature. Renegotiation happens in the 1237 existing connection, with the new handshake packets being encrypted 1238 along with application data. Upon completion of the re-negotiation 1239 procedure the new channel replaces the old channel. 1241 As described in RFC 5746 [RFC5746] there is no cryptographic binding 1242 between the two handshakes, although the new handshake is carried out 1243 using the cryptographic parameters established by the original 1244 handshake. 1246 Recommendation: To prevent the re-negotiation attack [RFC5746] this 1247 specification RECOMMENDS to disable the TLS renegotigation feature. 1248 Clients MUST respond to server-initiated re-negotiation attempts with 1249 an alert message (no_renegotiation) and clients MUST NOT initiate 1250 them. 1252 20. Downgrading Attacks 1254 When a client sends a ClientHello with a version higher than the 1255 highest version known to the server, the server is supposed to reply 1256 with ServerHello.version equal to the highest version known to the 1257 server and the handshake can proceed. This behaviour is known as 1258 version tolerance. Version-intolerance is when the server (or a 1259 middlebox) breaks the handshake when it sees a ClientHello.version 1260 higher than what it knows about. This is the behaviour that leads 1261 some clients to re-run the handshake with lower version. As a 1262 result, a potential security vulnerability is introduced when a 1263 system is running an old TLS/SSL version (e.g., because of the need 1264 to integrate with legacy systems). In the worst case, this allows an 1265 attacker to downgrade the protocol handshake to SSL 3.0. SSL 3.0 is 1266 so broken that there is no secure cipher available for it (see 1267 [I-D.ietf-tls-sslv3-diediedie]). 1269 The above-described downgrade vulnerability is solved by the TLS 1270 Fallback Signaling Cipher Suite Value (SCSV) 1271 [I-D.ietf-tls-downgrade-scsv] extension. However, the solution is 1272 not appliable to implementations conforming to this profile since the 1273 version negotiation MUST use TLS/DTLS version 1.2 (or higher). More 1274 specifically, this implies: 1276 o Clients MUST NOT send a TLS/DTLS version lower than version 1.2 in 1277 the ClientHello. 1279 o Clients MUST NOT retry a failed negotiation offering a TLS/DTLS 1280 version lower than 1.2. 1282 o Servers MUST fail the handshake by sending a protocol_version 1283 fatal alert if a TLS/DTLS version >= 1.2 cannot be negotiated. 1284 Note that the aborted connection is non-resumable. 1286 If at some time in the future the TLS/DTLS 1.2 profile reaches the 1287 quality of SSL 3.0 a software update mechanism is needed since 1288 constrained devices are unlikely to run multiple TLS/DTLS versions 1289 due to memory size restrictions. 1291 21. Crypto Agility 1293 This document recommends software and chip manufacturers to implement 1294 AES and the CCM mode of operation. This document references the CoAP 1295 recommended ciphersuite choices, which have been selected based on 1296 implementation and deployment experience from the IoT community. 1297 Over time the preference for algorithms will, however, change. Not 1298 all components of a ciphersuite are likely to change at the same 1299 speed. Changes are more likely expected for ciphers, the mode of 1300 operation, and the hash algorithms. The recommended key lengths have 1301 to be adjusted over time. Some deployment environments will also be 1302 impacted by local regulation, which might dictate a certain cipher 1303 and key size. Ongoing discussions regarding the choice of specific 1304 ECC curves will also likely to impact implementations. 1306 The following recommendations can be made to chip manufacturers: 1308 o Make any AES hardware-based crypto implementation accessible to 1309 developers working on security implementations at higher layers. 1310 Sometimes hardware implementatios are added to microcontrollers to 1311 offer support for functionality needed at the link layer and are 1312 only available to the on-chip link layer protocol implementation. 1314 o Provide flexibility for the use of the crypto function with future 1315 extensibility in mind. For example, making an AES-CCM 1316 implementation available to developers is a first step but such an 1317 implementation may not be usable due to parameter differences 1318 between an AES-CCM implementations. AES-CCM in IEEE 802.15.4 and 1319 Bluetooth Smart uses a nonce length of 13-octets while DTLS uses a 1320 nonce length of 12-octets. Hardware implementations of AES-CCM 1321 for IEEE 802.15.4 and Bluetooth Smart are therefore not re-usable 1322 by a DTLS stack. 1324 o Offer access to building blocks in addition (or as an alternative) 1325 to the complete functionality. For example, a chip manufacturer 1326 who gives developers access to an the AES crypto function can use 1327 it in functions to build an efficient AES-GCM implementations. 1328 Another example is to make a special instruction available that 1329 increases the speed of speed-up carryless multiplications. 1331 As a recommendation for developers and product architects we 1332 recommend that sufficient headroom is provided to allow an upgrade to 1333 a newer cryptographic algorithms over the lifetime of the product. 1334 As an example, while AES-CCM is recommended thoughout this 1335 specification future products might use the ChaCha20 cipher in 1336 combination with the Poly1305 authenticator 1337 [I-D.irtf-cfrg-chacha20-poly1305]. The assumption is made that a 1338 robust software update mechanism is offered. 1340 22. Key Length Recommendations 1342 RFC 4492 [RFC4492] gives approximate comparable key sizes for 1343 symmetric- and asymmetric-key cryptosystems based on the best-known 1344 algorithms for attacking them. While other publications suggest 1345 slightly different numbers, such as [Keylength], the approximate 1346 relationship still holds true. Figure 9 illustrates the comparable 1347 key sizes in bits. 1349 At the time of writing the key size recommendations for use with TLS- 1350 based ciphers found in [I-D.ietf-uta-tls-bcp] recommend DH key 1351 lengths of at least 2048 bit, which corresponds to a 112-bit 1352 symmetric key and a 233 bit ECC keys. These recommendations are 1353 inline with those from other organizations, such as National 1354 Institute of Standards and Technology (NIST) or European Network and 1355 Information Security Agency (ENISA). The authors of 1356 [ENISA-Report2013] add that a symmetric 80-bit security level is 1357 sufficient for legacy applications for the coming years, but a 1358 128-bit security level is the minimum requirement for new systems 1359 being deployed. The authors further note that one needs to also take 1360 into account the length of time data needs to be kept secure for. 1361 The use 80-bit encryption for transactional data may be acceptable 1362 for the near future while one has to insist on 128-bit encryption for 1363 long lived data. 1365 Symmetric | ECC | DH/DSA/RSA 1366 ------------+---------+------------- 1367 80 | 163 | 1024 1368 112 | 233 | 2048 1369 128 | 283 | 3072 1370 192 | 409 | 7680 1371 256 | 571 | 15360 1373 Figure 9: Comparable Key Sizes (in bits). 1375 23. False Start 1377 A full TLS handshake as specified in [RFC5246] requires two full 1378 protocol rounds (four flights) before the handshake is complete and 1379 the protocol parties may begin to send application data. 1381 An abbreviated handshake (resuming an earlier TLS session) is 1382 complete after three flights, thus adding just one round-trip time if 1383 the client sends application data first. 1385 If the conditions outlined in [I-D.bmoeller-tls-falsestart] are met, 1386 application data can be transmitted when the sender has sent its own 1387 "ChangeCipherSpec" and "Finished" messages. This achieves an 1388 improvement of one round-trip time for full handshakes if the client 1389 sends application data first, and for abbreviated handshakes if the 1390 server sends application data first. 1392 The conditions for using the TLS False Start mechanism are met by the 1393 public-key-based ciphersuites in this document. In summary, the 1394 conditions are 1396 o Modern symmetric ciphers with an effective key length of 128 bits, 1397 such as AES-128-CCM 1399 o Client certificate types, such as ecdsa_sign 1401 o Key exchange methods, such as ECDHE_ECDSA 1403 Based on the improvement over a full roundtrip for the full TLS/DTLS 1404 exchange this specification RECOMMENDS the use of the False Start 1405 mechanism when clients send application data first. 1407 24. Privacy Considerations 1409 The DTLS handshake exchange conveys various identifiers, which can be 1410 observed by an on-path eavesdropper. For example, the DTLS PSK 1411 exchange reveals the PSK identity, the supported extensions, the 1412 session id, algorithm parameters, etc. When session resumption is 1413 used then individual TLS sessions can be correlated by an on-path 1414 adversary. With many IoT deployments it is likely that keying 1415 material and their identifiers are persistent over a longer period of 1416 time due to the cost of updating software on these devices. 1418 User participation with many IoT deployments poses a challenge since 1419 many of the IoT devices operate unattended, even though they will 1420 initially be provisioned by a human. The ability to control data 1421 sharing and to configure preference will have to be provided at a 1422 system level rather than at the level of the DTLS exchange itself, 1423 which is the scope of this document. Quite naturally, the use of 1424 DTLS with mutual authentication will allow a TLS server to collect 1425 authentication information about the IoT device (likely over a long 1426 period of time). While this strong form of authentication will 1427 prevent mis-attribution it also allows strong identification. 1428 Device-related data collection (e.g., sensor recordings) will be 1429 associated with other data to be truly useful and this extra data 1430 might include personal data about the owner of the device or data 1431 about the environment it senses. Consequently, the data stored on 1432 the server-side will be vulnerable to stored data compromise. For 1433 the communication between the client and the server this 1434 specification prevents eavesdroppers to gain access to the 1435 communication content. While the PSK-based ciphersuite does not 1436 provide PFS the asymmetric versions do. This prevents an adversary 1437 from obtaining past communication content when access to a long-term 1438 secret has been gained. Note that no extra effort to make traffic 1439 analysis more difficult is provided by the recommendations made in 1440 this document. 1442 25. Security Considerations 1444 This entire document is about security. 1446 We would also like to point out that designing a software update 1447 mechanism into an IoT system is crucial to ensure that both 1448 functionality can be enhanced and that potential vulnerabilities can 1449 be fixed. This software update mechanism is also useful for changing 1450 configuration information, for example, trust anchors and other 1451 keying related information. 1453 26. IANA Considerations 1455 This document includes no request to IANA. 1457 27. Acknowledgements 1459 Thanks to Paul Bakker, Robert Cragie, Russ Housley, Rene Hummen, 1460 Matthias Kovatsch, Sandeep Kumar, Sye Loong Keoh, Alexey Melnikov, 1461 Manuel Pegourie-Gonnard, Akbar Rahman, Eric Rescorla, Michael 1462 Richardson, Zach Shelby, Michael StJohns, Rene Struik, and Sean 1463 Turner for their helpful comments and discussions that have shaped 1464 the document. 1466 Big thanks also to Klaus Hartke, who wrote the initial version of 1467 this document. 1469 Finally, we would like to thank our area director (Stephen Farrell) 1470 and our working group chairs (Zach Shelby and Dorothy Gellert) for 1471 their support. 1473 28. References 1475 28.1. Normative References 1477 [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 1478 REGISTRATION AUTHORITY", April 2010, 1479 . 1482 [GSM-SMS] ETSI, "3GPP TS 23.040 V7.0.1 (2007-03): 3rd Generation 1483 Partnership Project; Technical Specification Group Core 1484 Network and Terminals; Technical realization of the Short 1485 Message Service (SMS) (Release 7)", March 2007. 1487 [I-D.ietf-tls-cached-info] 1488 Santesson, S. and H. Tschofenig, "Transport Layer Security 1489 (TLS) Cached Information Extension", draft-ietf-tls- 1490 cached-info-17 (work in progress), November 2014. 1492 [I-D.ietf-tls-session-hash] 1493 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 1494 A., and M. Ray, "Transport Layer Security (TLS) Session 1495 Hash and Extended Master Secret Extension", draft-ietf- 1496 tls-session-hash-03 (work in progress), November 2014. 1498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1499 Requirement Levels", BCP 14, RFC 2119, March 1997. 1501 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 1502 for Transport Layer Security (TLS)", RFC 4279, December 1503 2005. 1505 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1506 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1508 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 1509 "Transport Layer Security (TLS) Renegotiation Indication 1510 Extension", RFC 5746, February 2010. 1512 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1513 Extension Definitions", RFC 6066, January 2011. 1515 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1516 Verification of Domain-Based Application Service Identity 1517 within Internet Public Key Infrastructure Using X.509 1518 (PKIX) Certificates in the Context of Transport Layer 1519 Security (TLS)", RFC 6125, March 2011. 1521 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1522 Security Version 1.2", RFC 6347, January 2012. 1524 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 1525 Layer Security (TLS) and Datagram Transport Layer Security 1526 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 1528 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 1529 T. Kivinen, "Using Raw Public Keys in Transport Layer 1530 Security (TLS) and Datagram Transport Layer Security 1531 (DTLS)", RFC 7250, June 2014. 1533 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 1534 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 1535 TLS", RFC 7251, June 2014. 1537 [WAP-WDP] Wireless Application Protocol Forum, "Wireless Datagram 1538 Protocol", June 2001. 1540 28.2. Informative References 1542 [AES] NIST, "FIPS PUB 197, Advanced Encryption Standard (AES)", 1543 http://www.iana.org/assignments/tls-parameters/ 1544 tls-parameters.xhtml#tls-parameters-4, November 2001. 1546 [ENISA-Report2013] 1547 ENISA, "Algorithms, Key Sizes and Parameters Report - 1548 2013", http://www.enisa.europa.eu/activities/identity-and- 1549 trust/library/deliverables/ 1550 algorithms-key-sizes-and-parameters-report, October 2013. 1552 [Heninger] 1553 Heninger, N., Durumeric, Z., Wustrow, E., and A. 1554 Halderman, "Mining Your Ps and Qs: Detection of Widespread 1555 Weak Keys in Network Devices", 21st USENIX Security 1556 Symposium, 1557 https://www.usenix.org/conference/usenixsecurity12/ 1558 technical-sessions/presentation/heninger, 2012. 1560 [HomeGateway] 1561 Eggert, L., "An experimental study of home gateway 1562 characteristics, In Proceedings of the '10th annual 1563 conference on Internet measurement'", 2010. 1565 [I-D.bmoeller-tls-falsestart] 1566 Langley, A., Modadugu, N., and B. Moeller, "Transport 1567 Layer Security (TLS) False Start", draft-bmoeller-tls- 1568 falsestart-01 (work in progress), November 2014. 1570 [I-D.bormann-core-cocoa] 1571 Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, 1572 "CoAP Simple Congestion Control/Advanced", draft-bormann- 1573 core-cocoa-02 (work in progress), July 2014. 1575 [I-D.ietf-core-resource-directory] 1576 Shelby, Z. and C. Bormann, "CoRE Resource Directory", 1577 draft-ietf-core-resource-directory-02 (work in progress), 1578 November 2014. 1580 [I-D.ietf-lwig-tls-minimal] 1581 Kumar, S., Keoh, S., and H. Tschofenig, "A Hitchhiker's 1582 Guide to the (Datagram) Transport Layer Security Protocol 1583 for Smart Objects and Constrained Node Networks", draft- 1584 ietf-lwig-tls-minimal-01 (work in progress), March 2014. 1586 [I-D.ietf-tls-downgrade-scsv] 1587 Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 1588 Suite Value (SCSV) for Preventing Protocol Downgrade 1589 Attacks", draft-ietf-tls-downgrade-scsv-02 (work in 1590 progress), November 2014. 1592 [I-D.ietf-tls-negotiated-dl-dhe] 1593 Gillmor, D., "Negotiated Discrete Log Diffie-Hellman 1594 Ephemeral Parameters for TLS", draft-ietf-tls-negotiated- 1595 dl-dhe-00 (work in progress), July 2014. 1597 [I-D.ietf-tls-prohibiting-rc4] 1598 Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf- 1599 tls-prohibiting-rc4-01 (work in progress), October 2014. 1601 [I-D.ietf-tls-sslv3-diediedie] 1602 Barnes, R., Thomson, M., Pironti, A., and A. Langley, 1603 "Deprecating Secure Sockets Layer Version 3.0", draft- 1604 ietf-tls-sslv3-diediedie-00 (work in progress), December 1605 2014. 1607 [I-D.ietf-uta-tls-bcp] 1608 Sheffer, Y., Holz, R., and P. Saint-Andre, 1609 "Recommendations for Secure Use of TLS and DTLS", draft- 1610 ietf-uta-tls-bcp-08 (work in progress), December 2014. 1612 [I-D.irtf-cfrg-chacha20-poly1305] 1613 Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 1614 protocols", draft-irtf-cfrg-chacha20-poly1305-03 (work in 1615 progress), November 2014. 1617 [I-D.mathewson-no-gmtunixtime] 1618 Mathewson, N. and B. Laurie, "Deprecating gmt_unix_time in 1619 TLS", draft-mathewson-no-gmtunixtime-00 (work in 1620 progress), December 2013. 1622 [I-D.schmertmann-dice-ccm-psk-pfs] 1623 Schmertmann, L. and C. Bormann, "ECDHE-PSK AES-CCM Cipher 1624 Suites with Forward Secrecy for Transport Layer Security 1625 (TLS)", draft-schmertmann-dice-ccm-psk-pfs-01 (work in 1626 progress), August 2014. 1628 [IANA-TLS] 1629 IANA, "TLS Cipher Suite Registry", 1630 http://www.iana.org/assignments/tls-parameters/ 1631 tls-parameters.xhtml#tls-parameters-4, 2014. 1633 [Keylength] 1634 Giry, D., "Cryptographic Key Length Recommendations", 1635 http://www.keylength.com, November 2014. 1637 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1638 Hashing for Message Authentication", RFC 2104, February 1639 1997. 1641 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 1642 CBC-MAC (CCM)", RFC 3610, September 2003. 1644 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1645 Requirements for Security", BCP 106, RFC 4086, June 2005. 1647 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1648 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1649 for Transport Layer Security (TLS)", RFC 4492, May 2006. 1651 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1652 (SHA and HMAC-SHA)", RFC 4634, July 2006. 1654 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1655 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1656 Overview, Assumptions, Problem Statement, and Goals", RFC 1657 4919, August 2007. 1659 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1660 "Transport Layer Security (TLS) Session Resumption without 1661 Server-Side State", RFC 5077, January 2008. 1663 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1664 Encryption", RFC 5116, January 2008. 1666 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 1667 Authentication Protocol", RFC 5216, March 2008. 1669 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1670 Authentication Protocol (EAP) Key Management Framework", 1671 RFC 5247, August 2008. 1673 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1674 Housley, R., and W. Polk, "Internet X.509 Public Key 1675 Infrastructure Certificate and Certificate Revocation List 1676 (CRL) Profile", RFC 5280, May 2008. 1678 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 1679 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 1680 August 2008. 1682 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 1683 Management Protocol (TAMP)", RFC 5934, August 2010. 1685 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1686 Curve Cryptography Algorithms", RFC 6090, February 2011. 1688 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 1689 Transport Layer Security (TLS)", RFC 6655, July 2012. 1691 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 1692 Multiple Certificate Status Request Extension", RFC 6961, 1693 June 2013. 1695 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1696 Constrained-Node Networks", RFC 7228, May 2014. 1698 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1699 Application Protocol (CoAP)", RFC 7252, June 2014. 1701 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1702 Attack", BCP 188, RFC 7258, May 2014. 1704 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer 1705 Security (TLS) and Datagram Transport Layer Security 1706 (DTLS)", RFC 7366, September 2014. 1708 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 1709 IPv6 over Low-Power Wireless Personal Area Networks 1710 (6LoWPANs)", RFC 7400, November 2014. 1712 [Tripple-HS] 1713 Bhargavan, K., Delignat-Lavaud, C., Pironti, A., and P. 1714 Strub, "Triple Handshakes and Cookie Cutters: Breaking and 1715 Fixing Authentication over TLS", IEEE Symposium on 1716 Security and Privacy, pages 98-113, 2014. 1718 Appendix A. Conveying DTLS over SMS 1720 This section is normative for the use of DTLS over SMS. Timer 1721 recommendations are already outlined in Section 13 and also 1722 applicable to the transport of DTLS over SMS. 1724 This section requires readers to be familiar with the terminology and 1725 concepts described in [GSM-SMS], and [WAP-WDP]. 1727 The remainder of this section assumes Mobile Stations are capable of 1728 producing and consuming 8-bit binary data encoded Transport Protocol 1729 Data Units (TPDU). 1731 A.1. Overview 1733 DTLS adds an additional roundtrip to the TLS [RFC5246] handshake to 1734 serve as a return-routability test for protection against certain 1735 types of DoS attacks. Thus a full blown DTLS handshake comprises up 1736 to 6 "flights" (i.e., logical message exchanges), each of which is 1737 then mapped on to one or more DTLS records using the segmentation and 1738 reassembly (SaR) scheme described in Section 4.2.3 of [RFC6347]. The 1739 overhead for said scheme is 6 bytes per Handshake message which, 1740 given a realistic 10+ messages handshake, would amount around 60 1741 bytes across the whole handshake sequence. 1743 Note that the DTLS SaR scheme is defined for handshake messages only. 1744 In fact, DTLS records are never fragmented and MUST fit within a 1745 single transport layer datagram. 1747 SMS provides an optional segmentation and reassembly scheme as well, 1748 known as Concatenated short messages (see Section 9.2.3.24.1 of 1749 [GSM-SMS]). However, since the SaR scheme in DTLS cannot be 1750 circumvented, the Concatenated short messages mechanism SHOULD NOT be 1751 used during handshake to avoid redundant overhead. Before starting 1752 the handshake phase (either actively or passively), the DTLS 1753 implementation MUST be explicitly configured with the PMTU of the SMS 1754 transport in order to correctly instrument its SaR function. The 1755 PMTU SHALL be 133 bytes if WDP-based multiplexing is used (see 1756 Appendix A.3), 140 bytes otherwise. 1758 It is RECOMMENDED to use the established security context over the 1759 longest possible period (possibly until a Closure Alert message is 1760 received, or after a very long inactivity timeout) to avoid the 1761 expensive re-establishment of the security association. 1763 A.2. Message Segmentation and Re-Assembly 1765 The content of an SMS message is carried in the TP-UserData field, 1766 and its size may be up to 140 bytes. As already mentioned in 1767 Appendix A.1, longer (i.e., up to 34170 bytes) messages can be sent 1768 using Concatenated SMS. 1770 This scheme consumes 6-7 bytes (depending on whether the short or 1771 long segmentation format is used) of the TP-UserData field, thus 1772 reducing the space available for the actual content of the SMS 1773 message to 133-134 bytes per TPDU. 1775 Though in principle a PMTU value higher than 140 bytes could be used, 1776 which may look like an appealing option given its more efficient use 1777 of the transport, there are disadvantages to consider. First, there 1778 is an additional overhead of 7 bytes per TPDU to be paid to the SaR 1779 function (which is in addition to the overhead introduced by the DTLS 1780 SaR mechanism. Second, some networks only partially support the 1781 Concatenated SMS function and others do not support it at all. 1783 For these reasons, the Concatenated short messages mechanism SHOULD 1784 NOT be used, and it is RECOMMENDED to leave the same PMTU settings 1785 used during the handshake phase, i.e., 133 bytes if WDP- based 1786 multiplexing is enabled, 140 bytes otherwise. 1788 Note that, after DTLS handshake has completed, any fragmentation and 1789 reassembly logic that pertains the application layer (e.g., 1790 segmenting CoAP messages into DTLS records and reassembling them 1791 after the crypto operations have been successfully performed) needs 1792 to be handled by the application that uses the established DTLS 1793 tunnel. 1795 A.3. Multiplexing Security Associations 1797 Unlike IPsec ESP/AH, DTLS records do not contain any association 1798 identifiers. Applications must arrange to multiplex between 1799 associations on the same endpoint which, when using UDP/IP, is 1800 usually done with the host/port number. 1802 If the DTLS server allows more than one client to be active at any 1803 given time, then the WAP User Datagram Protocol [WAP-WDP] can be used 1804 to achieve multiplexing of the different security associations. (The 1805 use of WDP provides the additional benefit that upper layer protocols 1806 can operate independently of the underlying wireless network, hence 1807 achieving application-agnostic transport handover.) 1809 The total overhead cost for encoding the WDP source and destination 1810 ports is 7 bytes out of the total available for the SMS content. 1812 The receiving side of the communication gets the source address from 1813 the originator address (TP-OA) field of the SMS-DELIVER TPDU. This 1814 way an unique 4-tuple identifying the security association can be 1815 reconstructed at both ends. (When replying to its DTLS peer, the 1816 sender will swaps the TP-OA and TP-DA parameters and the source and 1817 destination ports in the WDP.) 1819 A.4. Timeout 1821 If SMS-STATUS-REPORT messages are enabled, their receipt is not to be 1822 interpreted as the signal that the specific handshake message has 1823 been acted upon by the receiving party. Therefore, it MUST NOT be 1824 taken into account by the DTLS timeout and retransmission function. 1826 Handshake messages MUST carry a validity period (TP-VP parameter in a 1827 SMS-SUBMIT TPDU) that is not less than the current value of the 1828 retransmission timeout. In order to avoid persisting messages in the 1829 network that will be discarded by the receiving party, handshake 1830 messages SHOULD carry a validity period that is the same as, or just 1831 slightly higher than, the current value of the retransmission 1832 timeout. 1834 Appendix B. DTLS Record Layer Per-Packet Overhead 1836 Figure 10 shows the overhead for the DTLS record layer for protecting 1837 data traffic when AES-128-CCM with an 8-octet Integrity Check Value 1838 (ICV) is used. 1840 DTLS Record Layer Header................13 bytes 1841 Nonce (Explicit).........................8 bytes 1842 ICV..................................... 8 bytes 1843 ------------------------------------------------ 1844 Overhead................................29 bytes 1845 ------------------------------------------------ 1847 Figure 10: AES-128-CCM-8 DTLS Record Layer Per-Packet Overhead. 1849 The DTLS record layer header has 13 octets and consists of 1851 o 1 octet content type field, 1853 o 2 octet version field, 1855 o 2 octet epoch field, 1857 o 6 octet sequence number, 1859 o 2 octet length field. 1861 The "nonce" input to the AEAD algorithm is exactly that of [RFC5288], 1862 i.e., 12 bytes long. It consists of a 4 octet salt and an 8 octet 1863 nonce. The salt is the "implicit" part of the nonce and is not sent 1864 in the packet. Since the nonce_explicit may be the 8 octet sequence 1865 number and, in DTLS, it is the 8 octet epoch concatenated with the 6 1866 octet sequence number. 1868 RFC 6655 [RFC6655] allows the nonce_explicit to be a sequence number 1869 or something else. This document makes this use more restrictive for 1870 use with DTLS: the 64-bit none_explicit MUST be the 16-bit epoch 1871 concatenated with the 48-bit seq_num. The sequence number component 1872 of the nonce_explicit field at the AES-CCM layer is an exact copy of 1873 the sequence number in the record layer header field. This leads to 1874 a duplication of 8-bytes per record. 1876 To avoid this 8-byte duplication RFC 7400 [RFC7400] provides help 1877 with the use of the generic header compression technique for IPv6 1878 over Low-Power Wireless Personal Area Networks (6LoWPANs). Note that 1879 this header compression technique is not available when DTLS is 1880 exchanged over transports that do not use IPv6 or 6LoWPAN, such as 1881 the SMS transport described in Appendix A. 1883 Authors' Addresses 1885 Hannes Tschofenig (editor) 1886 ARM Ltd. 1887 110 Fulbourn Rd 1888 Cambridge CB1 9NJ 1889 Great Britain 1891 Email: Hannes.tschofenig@gmx.net 1892 URI: http://www.tschofenig.priv.at 1894 Thomas Fossati 1895 Alcatel-Lucent 1896 3 Ely Road 1897 Milton, Cambridge CB24 6DD 1898 UK 1900 Email: thomas.fossati@alcatel-lucent.com