idnits 2.17.1 draft-ietf-dice-profile-09.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 (January 19, 2015) is 3378 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 1219, but not defined == Unused Reference: 'I-D.ietf-lwig-tls-minimal' is defined on line 1892, 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: A later version (-23) exists of draft-ietf-tls-cached-info-17 == Outdated reference: A later version (-06) exists of draft-ietf-tls-session-hash-03 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** 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: A later version (-28) exists of draft-ietf-core-resource-directory-02 == Outdated reference: A later version (-05) exists of draft-ietf-tls-downgrade-scsv-03 == Outdated reference: A later version (-03) exists of draft-ietf-tls-sslv3-diediedie-00 == Outdated reference: A later version (-11) exists of draft-ietf-uta-tls-bcp-08 == Outdated reference: A later version (-10) exists of draft-irtf-cfrg-chacha20-poly1305-07 -- 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: 4 errors (**), 0 flaws (~~), 12 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: July 23, 2015 Alcatel-Lucent 6 January 19, 2015 8 A TLS/DTLS 1.2 Profile for the Internet of Things 9 draft-ietf-dice-profile-09.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 July 23, 2015. 40 Copyright Notice 42 Copyright (c) 2015 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 . . . . . . . . . . . . . . 16 64 6. Credential Types . . . . . . . . . . . . . . . . . . . . . . 18 65 6.1. Pre-Shared Secret . . . . . . . . . . . . . . . . . . . . 18 66 6.2. Raw Public Key . . . . . . . . . . . . . . . . . . . . . 20 67 6.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 22 68 7. Signature Algorithm Extension . . . . . . . . . . . . . . . . 26 69 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 26 70 9. Session Resumption . . . . . . . . . . . . . . . . . . . . . 28 71 10. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 29 72 11. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 29 73 12. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 30 74 13. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 31 75 14. Random Number Generation . . . . . . . . . . . . . . . . . . 32 76 15. Truncated MAC and Encrypt-then-MAC Extension . . . . . . . . 33 77 16. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 34 78 17. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 34 79 18. Session Hash . . . . . . . . . . . . . . . . . . . . . . . . 34 80 19. Re-Negotiation Attacks . . . . . . . . . . . . . . . . . . . 35 81 20. Downgrading Attacks . . . . . . . . . . . . . . . . . . . . . 35 82 21. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 36 83 22. Key Length Recommendations . . . . . . . . . . . . . . . . . 37 84 23. False Start . . . . . . . . . . . . . . . . . . . . . . . . . 38 85 24. Privacy Considerations . . . . . . . . . . . . . . . . . . . 38 86 25. Security Considerations . . . . . . . . . . . . . . . . . . . 39 87 26. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 88 27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 89 28. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 90 28.1. Normative References . . . . . . . . . . . . . . . . . . 40 91 28.2. Informative References . . . . . . . . . . . . . . . . . 41 92 Appendix A. Conveying DTLS over SMS . . . . . . . . . . . . . . 46 93 A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 47 94 A.2. Message Segmentation and Re-Assembly . . . . . . . . . . 47 95 A.3. Multiplexing Security Associations . . . . . . . . . . . 48 96 A.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 48 98 Appendix B. DTLS Record Layer Per-Packet Overhead . . . . . . . 49 99 Appendix C. DTLS Fragmentation . . . . . . . . . . . . . . . . . 50 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 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 a deployment model 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 application layer services running 518 on top of CoAP, HTTP or other protocols. Running server 519 functionality on a constrained node is typically more demanding since 520 servers have to wait for incoming requests. Therefore, they will 521 have fewer possibilities to enter sleep-cycles. Nevertheless, there 522 are legitimate reasons for deploying servers as constrained devices. 523 Figure 5 illustrates a possible deployment whereby a number of 524 constrained servers are waiting for regular clients to access their 525 resources. The entire process is likely to be controlled by a third 526 party, the authentication and authorization server. This 527 authentication and authorization server is responsible for holding 528 authorization policies (in the form of access control policies) that 529 govern the access to resources and distribution of keying material. 531 +////////////////////////////////////+ 532 | Configuration | 533 |////////////////////////////////////| 534 | Credentials | 535 | Client A -> Public Key | 536 | Server S1 -> Symmetric Key ,| 537 | Server S2 -> Certificate | 538 | Server S3 -> Public Key | 539 | Trust Anchor Store | 540 | Access Control Lists | 541 | Resource X: Client A / GET | 542 | Resource Y: Client A / PUT | 543 +------------------------------------+ 544 oo 545 oooooo 546 o 547 +---------------+ +-----------+ 548 |Authentication | +-------->|TLS/DTLS | 549 |& Authorization| | |Client A | 550 |Server | | +-----------+ 551 +---------------+ ++ 552 ^ | +-----------+ 553 \ | |Constrained| 554 \ ,-------. | Server S1 | 555 ,' `. +-----------+ 556 / Local \ 557 ( Network ) 558 \ / +-----------+ 559 `. ,' |Constrained| 560 '---+---' | Server S2 | 561 | +-----------+ 562 | 563 | +-----------+ 564 +-----------------> |Constrained| 565 | Server S3 | 566 +-----------+ 568 Figure 5: Constrained Server Profile. 570 Figure 6 shows an example interaction whereby a device, a thermostat 571 in our case, searches in the local network for discoverable resources 572 and accesses those. The thermostat starts the procedure using a 573 link-local discovery message using the "All CoAP Nodes" multicast 574 address by utilizing the RFC 6690 [RFC6690] link format. The IPv6 575 multicast address used for site-local discovery is FF02::FD. As a 576 result, a temperature sensor and a fan respond. These responses 577 allow the thermostat to subsequently read temperature information 578 from the temperature sensor with a CoAP GET request issued to the 579 previously learned endpoint. In this hypothetical example we assume 580 that this temperature sensor provides this information to every party 581 and no access control mechanism is enforced. However, when the 582 thermostat subsequently uses the obtained temperature reading to 583 control a fan, the fan requires authentication and authorization of 584 the entity requesting changes and TLS is used to authenticate both 585 endpointas and to secure the communication. 587 Temperature 588 Thermostat Sensor Fan 589 ---------- --------- --- 591 Discovery 592 --------------------> 593 GET coap://[FF02::FD]/.well-known/core 595 CoAP 2.05 Content 596 <------------------------------- 597 ;rt="temperature"; 598 if="sensor" 600 CoAP 2.05 Content 601 <-------------------------------------------------- 602 ;rt="fan";if="actuation" 604 Read Sensor Data (unauthenticated) 605 -------------------------------> 606 GET /3303/0/5700 608 CoAP 2.05 Content 609 <------------------------------- 610 22.5 C 612 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ 613 \ / 614 \ Protocol steps to obtain authorization token / client / 615 \ credentials for access to the fan-provided resources. / 616 \ / 617 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ 618 Configure Actuator (with authorization credentials) 619 -------------------------------------------------- 620 PUT /fan?on-off=true 622 CoAP 2.04 Changed 623 <------------------------------------------------- 625 Figure 6: Local Discovery and Resouce Access. 627 A deployment with constrained servers has to overcome several 628 challenges. Below we explain how these challenges have been solved 629 with CoAP, as an example. Other protocols may offer similar 630 capabilities. While the requirements for the TLS/DTLS protocol 631 profile change only slightly when run on a constrained server (in 632 comparison to running it on a constrained client) several other eco- 633 system factor will impact deployment. 635 The challenges are: 637 Discovery and Reachability: 639 Before initiating a connection to a constrained server a client 640 first needs to discover that server and, once discovered, it needs 641 to maintain reachability with that device. 643 In CoAP the discovery of resources offered by servers is 644 accomplished by sending a unicast or multicast CoAP GET to a well- 645 known URI. The CORE Link format specification [RFC6690] describes 646 the use case (see Section 1.2.1), and reserves the URI (see 647 Section 7.1). Section 7 of the CoAP specification [RFC7252] 648 describes the discovery procedure. RFC 7390 [RFC7390] describes 649 use case for discovering CoAP servers using multicast (see 650 Section 3.3), and specifies the protocol processing rules for CoAP 651 group communications (see Section 2.7). 653 Authentication: 655 The next challenge concerns the provisioning of authentication 656 credentials to the clients as well as servers. In Section 4.1 we 657 assumed that credentials (and other configuration information) are 658 provisioned to the device and that those can be used with the 659 authorization servers. Of course, this leads to a very static 660 relationship between the clients and their server-side 661 infrastructure but poses fewer challenges from a deployment point 662 of view, as described in Section 2 of 663 [I-D.iab-smart-object-architecture] these different communication 664 patterns. In any case, engineers and product designers have to 665 determine how the relevant credentials are distributed to the 666 respective parties. For example, shared secrets may need to be 667 provisioned to clients and the constrained servers for subsequent 668 use of TLS/DTLS PSK. In other deployments, certificates, private 669 keys, and trust anchors for use with certificate-based 670 authentication may need to be utilized. 672 Practical solutions either use pairing (also called imprinting) or 673 a trusted third party. With pairing two devices execute a special 674 protocol exchange that is unauthenticated to establish an shared 675 key (for example using an unauthenticated Diffie-Hellman exchange) 676 key. To avoid man-in-the-middle attacks an out-of-band channel is 677 used to verify that nobody has tampered with the exchanged 678 protocol messages. This out-of-band channel can come in many 679 forms, including: 681 * Human involvement by comparing hashed keys, entering passkeys, 682 scanning QR codes 684 * The use of alternative wireless communication channels (e.g., 685 infra-red communication in addition to WiFi) 687 * Proximity-based information 689 More details about these different pairing/imprinting techniques 690 can be found in the smart object security workshop report 691 [RFC7397] and various position papers submitted to that topic, 692 such as [ImprintingSurvey]. The use of a trusted third party 693 follows a different approach and is subject to ongoing 694 standardization efforts in the 'Authentication and Authorization 695 for Constrained Environments (ACE)' working group [ACE-WG]. 697 Authorization 699 The last challenge is the ability for the constrained server to 700 make an authorization decision when clients access protected 701 resources. Pre-provisioning access control information to 702 constrained servers may be one option but works only in a small 703 scale, less dynamic environment. For a more fine-grained and 704 dynamic access control the reader is referred to the ongoing work 705 in the ACE working group. 707 5. The TLS/DTLS Ciphersuite Concept 709 TLS (and consequently DTLS) has the concept of ciphersuites and an 710 IANA registry [IANA-TLS] was created to register the suites. A 711 ciphersuite (and the specification that defines it) contains the 712 following information: 714 o Authentication and key exchange algorithm (e.g., PSK) 716 o Cipher and key length (e.g., Advanced Encryption Standard (AES) 717 with 128 bit keys [AES]) 719 o Mode of operation (e.g., Counter with Cipher Block Chaining - 720 Message Authentication Code (CBC-MAC) Mode (CCM) for AES) 721 [RFC3610] 723 o Hash algorithm for integrity protection, such as the Secure Hash 724 Algorithm (SHA) in combination with Keyed-Hashing for Message 725 Authentication (HMAC) (see [RFC2104] and [RFC4634]) 727 o Hash algorithm for use with the pseudorandom function (e.g., HMAC 728 with the SHA-256) 730 o Misc information (e.g., length of authentication tags) 732 o Information whether the ciphersuite is suitable for DTLS or only 733 for TLS 735 The TLS ciphersuite TLS_PSK_WITH_AES_128_CCM_8, for example, uses a 736 pre-shared authentication and key exchange algorithm. RFC 6655 737 [RFC6655] defines this ciphersuite. It uses the Advanced Encryption 738 Standard (AES) encryption algorithm, which is a block cipher. Since 739 the AES algorithm supports different key lengths (such as 128, 192 740 and 256 bits) this information has to be specified as well and the 741 selected ciphersuite supports 128 bit keys. A block cipher encrypts 742 plaintext in fixed-size blocks and AES operates on fixed block size 743 of 128 bits. For messages exceeding 128 bits, the message is 744 partitioned into 128-bit blocks and the AES cipher is applied to 745 these input blocks with appropriate chaining, which is called mode of 746 operation. 748 TLS 1.2 introduced Authenticated Encryption with Associated Data 749 (AEAD) ciphersuites (see [RFC5116] and [RFC6655]). AEAD is a class 750 of block cipher modes which encrypt (parts of) the message and 751 authenticate the message simultaneously. Examples of such modes 752 include the Counter with Cipher Block Chaining - Message 753 Authentication Code (CBC-MAC) Mode (CCM) mode, and the Galois/Counter 754 Mode (GCM) (see [RFC5288] and [RFC7251]). 756 Some AEAD ciphersuites have shorter authentication tags and are 757 therefore more suitable for networks with low bandwidth where small 758 message size matters. The TLS_PSK_WITH_AES_128_CCM_8 ciphersuite 759 that ends in "_8" has an 8-octet authentication tag, while the 760 regular CCM ciphersuites have, at the time of writing, 16-octet 761 authentication tags. 763 TLS 1.2 also replaced the combination of MD5/SHA-1 hash functions in 764 the TLS pseudo random function (PRF) used in earlier versions of TLS 765 with cipher-suite-specified PRFs. For this reason authors of more 766 recent TLS 1.2 ciphersuite specifications explicitly indicate the MAC 767 algorithm and the hash functions used with the TLS PRF. 769 6. Credential Types 771 6.1. Pre-Shared Secret 773 The use of pre-shared secret credentials is one of the most basic 774 techniques for TLS/DTLS since it is both computational efficient and 775 bandwidth conserving. Pre-shared secret based authentication was 776 introduced to TLS with RFC 4279 [RFC4279]. The exchange shown in 777 Figure 7 illustrates the DTLS exchange including the cookie exchange. 778 While the server is not required to initiate a cookie exchange with 779 every handshake, the client is required to implement and to react on 780 it when challenged. The cookie exchange allows the server to react 781 to flooding attacks. 783 Client Server 784 ------ ------ 785 ClientHello --------> 787 <-------- HelloVerifyRequest 788 (contains cookie) 790 ClientHello --------> 791 (with cookie) 792 ServerHello 793 *ServerKeyExchange 794 <-------- ServerHelloDone 795 ClientKeyExchange 796 ChangeCipherSpec 797 Finished --------> 798 ChangeCipherSpec 799 <-------- Finished 801 Application Data <-------> Application Data 803 Legend: 805 * indicates an optional message payload 807 Figure 7: DTLS PSK Authentication including the Cookie Exchange. 809 [RFC4279] does not mandate the use of any particular type of client 810 identity and the client and server have to agree on the identities 811 and keys to be used. The mandated encoding of identities in 812 Section 5.1 of RFC 4279 aims to improve interoperability for those 813 cases where the identity is configured by a person using some 814 management interface. Many IoT devices do, however, not have a user 815 interface and most of their credentials are bound to the device 816 rather than the user. Furthermore, credentials are often provisioned 817 into trusted hardware modules or in the firmware by developers. As 818 such, the encoding considerations are not applicable to this usage 819 environment. For use with this profile the PSK identities SHOULD NOT 820 assume a structured format (as domain names, Distinguished Names, or 821 IP addresses have) and a bit-by-bit comparison operation can then be 822 used by the server-side infrastructure. 824 The client indicates which key it uses by including a "PSK identity" 825 in the ClientKeyExchange message. As described in Section 4 clients 826 may have multiple pre-shared keys with a single server and to help 827 the client in selecting which PSK identity / PSK pair to use, the 828 server can provide a "PSK identity hint" in the ServerKeyExchange 829 message. If the hint for PSK key selection is based on the domain 830 name of the server then servers SHOULD NOT send the "PSK identity 831 hint" in the ServerKeyExchange message. In general, servers SHOULD 832 NOT send the "PSK identity hint" in the ServerKeyExchange message and 833 client MUST ignore the message. This approach is inline with RFC 834 4279 [RFC4279]. Note: The TLS Server Name Indication (SNI) extension 835 allows the client to tell a server the name of the server it is 836 contacting, which is relevant for hosting environments. A server 837 using the identity hint needs to guide the selection based on a 838 received SNI value from the client. 840 RFC 4279 requires TLS implementations supporting PSK ciphersuites to 841 support arbitrary PSK identities up to 128 octets in length, and 842 arbitrary PSKs up to 64 octets in length. This is a useful 843 assumption for TLS stacks used in the desktop and mobile environments 844 where management interfaces are used to provision identities and 845 keys. For the IoT environment, keys are distributed as part of 846 hardware modules or are embedded into the firmware. Implementations 847 in compliance with this profile MAY use PSK identities up to 128 848 octets in length, and arbitrary PSKs up to 64 octets in length. The 849 use of shorter PSK identities and shorter PSKs is RECOMMENDED. 851 Constrained Application Protocol (CoAP) [RFC7252] currently specifies 852 TLS_PSK_WITH_AES_128_CCM_8 as the mandatory to implement ciphersuite 853 for use with shared secrets. This ciphersuite uses the AES algorithm 854 with 128 bit keys and CCM as the mode of operation. The label "_8" 855 indicates that an 8-octet authentication tag is used. This 856 ciphersuite makes use of the default TLS 1.2 Pseudorandom Function 857 (PRF), which uses an HMAC with the SHA-256 hash function. (Note that 858 all IoT implementations will need a SHA-256 implementation due to the 859 construction of the pseudo-random number function in DTLS/TLS 1.2.) 861 A device compliant with the profile in this section MUST implement 862 TLS_PSK_WITH_AES_128_CCM_8 and follow the guidance from this section. 864 6.2. Raw Public Key 866 The use of raw public keys with TLS/DTLS, as defined in [RFC7250], is 867 the first entry point into public key cryptography without having to 868 pay the price of certificates and a public key infrastructure (PKI). 869 The specification re-uses the existing Certificate message to convey 870 the raw public key encoded in the SubjectPublicKeyInfo structure. To 871 indicate support two new extensions had been defined, as shown in 872 Figure 8, namely the server_certificate_type*' and the 873 client_certificate_type. To operate this mechanism securely it is 874 necessary to authenticate and authorize the public keys out-of-band. 875 This document therefore assumes that a client implementation comes 876 with one or multiple raw public keys of servers, it has to 877 communicate with, pre-provisioned. Additionally, a device will have 878 its own raw public key. To replace, delete, or add raw public key to 879 this list requires a software update, for example using a firmware 880 update mechanism. 882 Client Server 883 ------ ------ 885 ClientHello --------> 886 *client_certificate_type* 887 *server_certificate_type* 889 ServerHello 890 *client_certificate_type* 891 *server_certificate_type* 892 Certificate 893 ServerKeyExchange 894 CertificateRequest 895 <-------- ServerHelloDone 897 Certificate 898 ClientKeyExchange 899 CertificateVerify 900 [ChangeCipherSpec] 901 Finished --------> 903 [ChangeCipherSpec] 904 <-------- Finished 906 Note: Extensions marked with '*' were introduced with 907 RFC 7250. 909 Figure 8: DTLS Raw Public Key Exchange including the Cookie Exchange. 911 The CoAP recommended ciphersuite for use with this credential type is 912 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251]. This elliptic curve 913 cryptography (ECC) based AES-CCM TLS ciphersuite uses the Ephemeral 914 Elliptic Curve Diffie-Hellman (ECDHE) as the key establishment 915 mechanism and an Elliptic Curve Digital Signature Algorithm (ECDSA) 916 for authentication. Due to the use of Ephemeral Elliptic Curve 917 Diffie-Hellman (ECDHE) the recently introduced named Diffie-Hellman 918 groups [I-D.ietf-tls-negotiated-dl-dhe] are not applicable to this 919 profile. This ciphersuite make use of the AEAD capability in DTLS 920 1.2 and utilizes an eight-octet authentication tag. The use of a 921 Diffie-Hellman key exchange provides perfect forward secrecy (PFS). 922 More details about PFS can be found in Section 11. 924 RFC 6090 [RFC6090] provides valuable information for implementing 925 Elliptic Curve Cryptography algorithms, particularly for choosing 926 methods that have been available in the literature for a long time 927 (i.e., 20 years and more). 929 A device compliant with the profile in this section MUST implement 930 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this 931 section. 933 6.3. Certificates 935 The use of mutual certificate-based authentication is shown in 936 Figure 9, which makes use of the cached info extension 937 [I-D.ietf-tls-cached-info]. Support of the cached info extension is 938 REQUIRED. Caching certificate chains allows the client to reduce the 939 communication overhead significantly since otherwise the server would 940 provide the end entity certificate, and the certificate chain. 941 Because certificate validation requires that root keys be distributed 942 independently, the self-signed certificate that specifies the root 943 certificate authority is omitted from the chain. Client 944 implementations MUST be provisioned with a trust anchor store that 945 contains the root certificates. The use of the Trust Anchor 946 Management Protocol (TAMP) [RFC5934] is, however, not envisioned. 947 Instead IoT devices using this profile MUST use a software update 948 mechanism to populate the trust anchor store. 950 Client Server 951 ------ ------ 953 ClientHello --------> 954 *cached_info* 956 ServerHello 957 *cached_info* 958 Certificate 959 ServerKeyExchange 960 CertificateRequest 961 <-------- ServerHelloDone 963 Certificate 964 ClientKeyExchange 965 CertificateVerify 966 [ChangeCipherSpec] 967 Finished --------> 969 [ChangeCipherSpec] 970 <-------- Finished 972 Note: Extensions marked with '*' were introduced with 973 [I-D.ietf-tls-cached-info]. 975 Figure 9: DTLS Mutual Certificate-based Authentication. 977 Server certificates MUST contain the fully qualified DNS domain name 978 or "FQDN" as dNSName. For CoAP, the coaps URI scheme is described in 979 Section 6.2 of [RFC7252]. This FQDN is stored in the SubjectAltName 980 or in the leftmost CN component of subject name, as explained in 981 Section 9.1.3.3 of [RFC7252], and used by the client to match it 982 against the FQDN used during the look-up process, as described in RFC 983 6125 [RFC6125]. For other protocols, the appropriate URI scheme 984 specification has to be consulted. 986 When constrained servers are used, for example in context of locally 987 discoverable services as shown in Figure 6, then the rules of client 988 certificates are applicable since these constrained servers are less 989 likely to have an FQDN configured. Note that the Service Name 990 Indication (SNI) extension cannot be used in this case since SNI does 991 not offer the ability to convey EUI-64 identifiers. 993 For client certificates the identifier used in the SubjectAltName or 994 in the leftmost CN component of subject name MUST be an EUI-64 995 [EUI64], as mandated in Section 9.1.3.3 of [RFC7252]. 997 For certificate revocation neither the Online Certificate Status 998 Protocol (OCSP) nor Certificate Revocation Lists (CRLs) are used. 999 Instead, this profile relies on a software update mechanism. While 1000 multiple OCSP stapling [RFC6961] has recently been introduced as a 1001 mechanism to piggyback OCSP request/responses inside the DTLS/TLS 1002 handshake to avoid the cost of a separate protocol handshake further 1003 investigations are needed to determine its suitability for the IoT 1004 environment. 1006 Regarding the ciphersuite choice the discussion in Section 6.2 1007 applies. Further details about X.509 certificates can be found in 1008 Section 9.1.3.3 of [RFC7252]. The TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 1009 ciphersuite description in Section 6.2 is also applicable to this 1010 section. 1012 When using certificates, IoT devices MUST provide support for a 1013 server certificate chain of at least 3 not including the trust anchor 1014 and MAY reject connections from servers offering chains longer than 1015 3. IoT devices MAY have client certificate chains of any length. 1016 Obviously, longer chains require more digital signature verification 1017 operations to perform and lead to larger certificate messages in the 1018 TLS handshake. 1020 Table 1 provides a summary of the elements in a certificate for use 1021 with this profile. 1023 +---------------+---------------------------------------------------+ 1024 | Element | Notes | 1025 +---------------+---------------------------------------------------+ 1026 | Version | This profile uses the X.509 v3 certificate | 1027 | | [RFC5280]. | 1028 | | | 1029 | Serial Number | Positive integer unique per certificate. | 1030 | | | 1031 | Issuer | This profile uses ecdsa-with-SHA256 or stronger | 1032 | Signature | [RFC5758]. | 1033 | Algorithms | | 1034 | | | 1035 | Issuer | Contains the DN of the issuing CA. | 1036 | Distinguished | | 1037 | Name | | 1038 | | | 1039 | Validity | Values expressed as UTC time. No validity period | 1040 | Period | mandated. | 1041 | | | 1042 | Subject | See rules outlined in this section. | 1043 | Distinguished | | 1044 | Name | | 1045 | | | 1046 | Subject | This element contains the ECDSA signature | 1047 | Public Key | certificate. The algorithm field in the | 1048 | Information | SubjectPublicKeyInfo structure indicates the | 1049 | | algorithm and any associated parameters for the | 1050 | | ECC public key. This profile uses the id- | 1051 | | ecPublicKey algorithm identifier. | 1052 | | | 1053 | Issuer's | Includes the ECDSA signature with ecdsa-with- | 1054 | Signature | SHA256 or stronger. | 1055 | | | 1056 | Extension: | See rules outlined in this section. | 1057 | Subject | | 1058 | Alternative | | 1059 | Name | | 1060 | | | 1061 | Extension: | Indicates whether the subject of the certificate | 1062 | Basic | is a CA. This extension is used for CA certs only | 1063 | Constraints | and then the value is set to TRUE. The default is | 1064 | | FALSE. | 1065 | | | 1066 | Extension: | digitalSignature or keyAgreement, keyCertSign for | 1067 | Key Usage | verifying signatures on public key certificates. | 1068 | | | 1069 | Extension: | id-kp-serverAuth for server authentication, id- | 1070 | Extended Key | kp-clientAuth for client authentication, id-kp- | 1071 | Usage | codeSigning for code signing (for software update | 1072 | | mechanism), id-kp-OCSPSigning for future OCSP | 1073 | | usage in TLS. | 1074 +---------------+---------------------------------------------------+ 1076 Table 1: Certificate Content. 1078 All certificate elements listed in Table 1 are mandatory-to- 1079 implement. No other certificate elements are used by this 1080 specification. 1082 A device compliant with the profile in this section MUST implement 1083 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this 1084 section. 1086 6.3.1. Client Certificate URLs 1088 RFC 6066 [RFC6066] allows to avoid sending client-side certificates 1089 and uses URLs instead. This reduces the over-the-air transmission. 1090 Note that the TLS cached info extension does not provide any help 1091 with caching client certificates. 1093 TLS/DTLS clients MUST implement support for client certificate URLs 1094 for those environments where client-side certificates are used and 1095 the server-side is not constrained. For constrained servers this 1096 functionality is NOT RECOMMENDED since it forces the server to 1097 execute an additional protocol exchange, potentially using a protocol 1098 it does not even support. The use of this extension also increases 1099 the risk of a denial of service attack against the constrained server 1100 due to the additional workload. 1102 6.3.2. Trusted CA Indication 1104 RFC 6066 [RFC6066] allows clients to indicate what trust anchor they 1105 support. With certificate-based authentication a DTLS server conveys 1106 its end entity certificate to the client during the DTLS exchange 1107 provides. Since the server does not necessarily know what trust 1108 anchors the client has stored it includes intermediate CA certs in 1109 the certificate payload as well to facilitate with certification path 1110 construction and path validation. 1112 Today, in most IoT deployments there is a fairly static relationship 1113 between the IoT device (and the software running on them) and the 1114 server-side infrastructure. For these deployments where IoT devices 1115 interact with a fixed, pre-configured set of servers this extension 1116 is NOT RECOMMENDED. 1118 In cases where client interact with dynamically discovered TLS/DTLS 1119 servers, for example in the use cases described in Section 4.2, the 1120 use of this extension is RECOMMENDED. 1122 7. Signature Algorithm Extension 1124 The "signature_algorithms" extension, defined in Section 7.4.1.4.1 of 1125 RFC 5246 [RFC5246], allows the client to indicate to the server which 1126 signature/hash algorithm pairs may be used in digital signatures. 1127 The client MUST send this extension to select the use of SHA-256 1128 since otherwise absent this extension RFC 5246 defaults to SHA-1 / 1129 ECDSA for the ECDH_ECDSA and the ECDHE_ECDSA key exchange algorithms. 1131 The "signature_algorithms" extension is not applicable to the PSK- 1132 based ciphersuite described in Section 6.1. 1134 8. Error Handling 1136 TLS/DTLS uses the Alert protocol to convey error messages and 1137 specifies a longer list of errors. However, not all error messages 1138 defined in the TLS/DTLS specification are applicable to this profile. 1139 In general, there are two categories of errors (as defined in 1140 Section 7.2 of RFC 5246), namely fatal errors and warnings. Alert 1141 messages with a level of fatal result in the immediate termination of 1142 the connection. If possible, developers should try to develop 1143 strategies to react to those fatal errors, such as re-starting the 1144 handshake or informing the user using the (often limited) user 1145 interface. Warnings may be ignored by the application since many IoT 1146 devices will either have limited ways to log errors or no ability at 1147 all. In any case, implementers have to carefully evaluate the impact 1148 of errors and ways to remedy the situation since a commonly used 1149 approach for delegating decision making to users is difficult (or 1150 impossible) to accomplish in a timely fashion. 1152 All error messages marked as RESERVED are only supported for 1153 backwards compatibility with SSL and are therefore not applicable to 1154 this profile. Those include decryption_failed_RESERVED, 1155 no_certificate_RESERVE, and export_restriction_RESERVED. 1157 A number of the error messages are applicable only for certificate- 1158 based authentication ciphersuites. Hence, for PSK and raw public key 1159 use the following error messages are not applicable: 1161 o bad_certificate, 1163 o unsupported_certificate, 1165 o certificate_revoked, 1167 o certificate_expired, 1169 o certificate_unknown, 1171 o unknown_ca, and 1173 o access_denied. 1175 Since this profile does not make use of compression at the TLS layer 1176 the decompression_failure error message is not applicable either. 1178 RFC 4279 introduced a new alert message unknown_psk_identity for PSK 1179 ciphersuites. As stated in Section 2 of RFC 4279 the 1180 decryption_error error message may also be used instead. For this 1181 profile the TLS server MUST return the decryption_error error message 1182 instead of the unknown_psk_identity since the two mechanisms exist 1183 and provide the same functionality. 1185 Furthermore, the following errors should not occur with devices and 1186 servers supporting this specification but implementations MUST be 1187 prepared to process these errors to deal with servers that are not 1188 compliant to the profiles in this document: 1190 protocol_version: While this document focuses only on one version of 1191 the TLS/DTLS protocol, namely version 1.2, ongoing work on TLS/ 1192 DTLS 1.3 is in progress at the time of writing. 1194 insufficient_security: This error message indicates that the server 1195 requires ciphers to be more secure. This document specifies only 1196 one ciphersuite per profile but it is likely that additional 1197 ciphtersuites get added over time. 1199 user_canceled: Many IoT devices are unattended and hence this error 1200 message is unlikely to occur. 1202 9. Session Resumption 1204 Session resumption is a feature of the core TLS/DTLS specifications 1205 that allows a client to continue with an earlier established session 1206 state. The resulting exchange is shown in Figure 10. In addition, 1207 the server may choose not to do a cookie exchange when a session is 1208 resumed. Still, clients have to be prepared to do a cookie exchange 1209 with every handshake. The cookie exchange is not shown in the 1210 figure. 1212 Client Server 1213 ------ ------ 1215 ClientHello --------> 1216 ServerHello 1217 [ChangeCipherSpec] 1218 <-------- Finished 1219 [ChangeCipherSpec] 1220 Finished --------> 1221 Application Data <-------> Application Data 1223 Figure 10: DTLS Session Resumption. 1225 Constrained clients MUST implement session resumption to improve the 1226 performance of the handshake. This will lead to a reduced number of 1227 message exchanges, lower computational overhead (since only symmetric 1228 cryptography is used during a session resumption exchange), and 1229 session resumption requires less bandwidth. 1231 For cases where the server is constrained (but not the client) the 1232 client MUST implement RFC 5077 [RFC5077]. RFC 5077 specifies a 1233 version of TLS/DTLS session resumption that does not require per- 1234 session state information to be maintained by the constrained server. 1235 This is accomplished by using a ticket-based approach. 1237 If both the client and the server are constrained devices both 1238 devices SHOULD implement RFC 5077 and MUST implement basic session 1239 resumption. 1241 10. Compression 1243 Section 3.3 of [I-D.ietf-uta-tls-bcp] recommends to disable TLS/DTLS- 1244 level compression due to attacks, such as CRIME. For IoT 1245 applications compression at the TLS/DTLS layer is not needed since 1246 application layer protocols are highly optimized and the compression 1247 algorithms at the DTLS layer increases code size and complexity. 1249 This TLS/DTLS profile MUST NOT implement TLS/DTLS layer compression. 1251 11. Perfect Forward Secrecy 1253 Perfect forward secrecy (PFS) is a property that preserves the 1254 confidentiality of past conversations even in situations where the 1255 long-term secret is compromised. 1257 The PSK ciphersuite recommended in Section 6.1 does not offer this 1258 property since it does not utilize a Diffie-Hellman exchange. New 1259 ciphersuites that support PFS for PSK-based authentication, such as 1260 proposed in [I-D.schmertmann-dice-ccm-psk-pfs], might become 1261 available as standardized ciphersuite in the (near) future. The 1262 recommended PSK-based ciphersuite offers excellent performance, a 1263 very small memory footprint, and has the lowest on the wire overhead 1264 at the expense of not using any public cryptography. For deployments 1265 where public key cryptography is acceptable the raw public might 1266 offer an acceptable middleground between the PSK ciphersuite in terms 1267 of out-of-band validation and the functionality offered by asymmetric 1268 cryptography. 1270 The use of PFS is a trade-off decision since on one hand the 1271 compromise of long-term secrets of embedded devices is more likely 1272 than with many other Internet hosts but on the other hand a Diffie- 1273 Hellman exchange requires ephemeral key pairs to be generated, which 1274 is demanding from a performance point of view. For performance 1275 reasons some implementations re-use key pairs over multiple exchanges 1276 (rather than generating new keys for each exchange) for the obvious 1277 performance improvement. Note, however, that such key re-use over 1278 long periods voids the benefits of forward secrecy when an attack 1279 gains access to this DH key pair. 1281 The impact of the disclosure of past conversations and the desire to 1282 increase the cost for pervasive monitoring (as demanded by [RFC7258]) 1283 has to be taken into account when making a deployment decision. 1285 Client implementations claiming support of this profile MUST 1286 implement the ciphersuites listed in Section 6 according to the 1287 selected credential type. 1289 12. Keep-Alive 1291 RFC 6520 [RFC6520] defines a heartbeat mechanism to test whether the 1292 other peer is still alive. The same mechanism can also be used to 1293 perform Path Maximum Transmission Unit (MTU) Discovery. 1295 A recommendation about the use of RFC 6520 depends on the type of 1296 message exchange an IoT device performs. There are three types of 1297 exchanges that need to be analysed: 1299 Client-Initiated, One-Shot Messages 1301 This is a common communication pattern where IoT devices upload 1302 data to a server on the Internet on an irregular basis. The 1303 communication may be triggered by specific events, such as opening 1304 a door. 1306 Since the upload happens on an irregular and unpredictable basis 1307 and due to renumbering and Network Address Translation (NAT) the 1308 DTLS handshake may need to be re-started (ideally using session 1309 resumption, if possible). 1311 In this case there is no use for a keep-alive extension for this 1312 scenario. 1314 Client-Initiated, Regular Data Uploads 1316 This is a variation of the previous case whereby data gets 1317 uploaded on a regular basis, for example, based on frequent 1318 temperature readings. If neither NAT bindings nor IP address 1319 changes occurred then the record layer will not notice any 1320 changes. For the case where the IP address and port number 1321 changes, it is necessary to re-create the record layer using 1322 session resumption. 1324 In this scenario there is no use for a keep-alive extension. It 1325 is also very likely that the device will enter a sleep cycle in 1326 between data transmissions to keep power consumption low. 1328 Server-Initiated Messages 1330 In the two previous scenarios the client initiated the protocol 1331 interaction but in this case we consider server-initiated 1332 messages. Since messages to the client may get blocked by 1333 intermediaries, such as NATs (including IPv4/IPv6 protocol 1334 translators) and stateful packet filtering firewalls, the initial 1335 connection setup is triggered by the client and then kept alive. 1336 Since state at middleboxes expires fairly quickly (according to 1337 measurements described in [HomeGateway]), regular heartbeats are 1338 necessary whereby these keep-alive messages may be exchanged at 1339 the application layer or within DTLS itself. 1341 For this message exchange pattern the use of DTLS heartbeat 1342 messages is quite useful but may interfere with registrations kept 1343 at the application layer (for example when the CoAP resource 1344 directory is used). The MTU discovery mechanism, which is also 1345 part of [RFC6520], is less likely to be relevant since for many 1346 IoT deployments the most constrained link is the wireless 1347 interface between the IoT device and the network itself (rather 1348 than some links along the end-to-end path). Only in more complex 1349 network topologies, such as multi-hop mesh networks, path MTU 1350 discovery might be appropriate. It also has to be noted that DTLS 1351 itself already provides a basic path discovery mechanism (see 1352 Section 4.1.1.1 of RFC 6347 by using the fragmentation capability 1353 of the handshake protocol). 1355 For server-initiated messages the heartbeat extension is RECOMMENDED. 1357 13. Timeouts 1359 To connect to the Internet a variety of wired and wireless 1360 technologies are available. Many of the low power radio 1361 technologies, such as IEEE 802.15.4 or Bluetooth Smart, only support 1362 small frame sizes (e.g., 127 bytes in case of IEEE 802.15.4 as 1363 explained in RFC 4919 [RFC4919]). Other radio technologies, such as 1364 the Global System for Mobile Communications (GSM) using the short 1365 messaging service (SMS) have similar constraints in terms of payload 1366 sizes, such as 140 bytes without the optional segmentation and 1367 reassembly scheme known as Concatenated SMS, but show higher latency. 1369 The DTLS handshake protocol adds a fragmentation and reassembly 1370 mechanism to the TLS handshake protocol since each DTLS record must 1371 fit within a single transport layer datagram, as described in 1372 Section 4.2.3 of [RFC6347]. Since handshake messages are potentially 1373 bigger than the maximum record size, the mechanism fragments a 1374 handshake message over a number of DTLS records, each of which can be 1375 transmitted separately. 1377 To deal with the unreliable message delivery provided by UDP, DTLS 1378 adds timeouts and re-transmissions, as described in Section 4.2.4 of 1379 [RFC6347]. Although the timeout values are implementation specific, 1380 recommendations are provided in Section 4.2.4.1 of [RFC6347], with an 1381 initial timer value of 1 second and twice the value at each 1382 retransmission up to no less than 60 seconds. Due to the nature of 1383 some radio technologies, these values are too aggressive and lead to 1384 spurious failures when messages in flight need longer. 1386 Note: If a round-trip time estimator (such as proposed in 1387 [I-D.bormann-core-cocoa]) is available in the protocol stack of the 1388 device, it could be used to dynamically update the setting of the 1389 retransmit timeout. 1391 Choosing appropriate timeout values is difficult with infrequent data 1392 transmissions, changing network conditions, and large variance in 1393 latency. This specification therefore RECOMMENDS an initial timer 1394 value of 10 seconds with exponential back off up to no less then 60 1395 seconds. Appendix A provides additional normative text for carrying 1396 DTLS over SMS. 1398 14. Random Number Generation 1400 The TLS/DTLS protocol requires random numbers to be available during 1401 the protocol run. For example, during the ClientHello and the 1402 ServerHello exchange the client and the server exchange random 1403 numbers. Also, the use of the Diffie-Hellman exchange requires 1404 random numbers during the key pair generation. Special care has to 1405 be paid when generating random numbers in embedded systems as many 1406 entropy sources available on desktop operating systems or mobile 1407 devices might be missing, as described in [Heninger]. Consequently, 1408 if not enough time is given during system start time to fill the 1409 entropy pool then the output might be predictable and repeatable, for 1410 example leading to the same keys generated again and again. 1412 It is important to note that sources contributing to the randomness 1413 pool on laptops, or desktop PCs are not available on many IoT device, 1414 such as mouse movement, timing of keystrokes, air turbulence on the 1415 movement of hard drive heads, etc. Other sources have to be found or 1416 dedicated hardware has to be added. 1418 The ClientHello and the ServerHello messages contains the 'Random' 1419 structure, which has two components: gmt_unix_time and a random 1420 sequence of 28 random bytes. gmt_unix_time holds the current time and 1421 date in standard UNIX 32-bit format (seconds since the midnight 1422 starting Jan 1, 1970, GMT). [I-D.mathewson-no-gmtunixtime] argues 1423 that the entire ClientHello.Random value (including gmt_unix_time) 1424 should be set to a cryptographically random sequence because of 1425 privacy concerns regarding device fingerprinting. Since many IoT 1426 devices do not have access to a real-time clock this recommendation 1427 it is RECOMMENDED to follow the guidance outlined in 1428 [I-D.mathewson-no-gmtunixtime] regarding the content of the 1429 ClientHello.Random field. However, for the ServerHello.Random 1430 structure it is RECOMMENDED to maintain the existing structure with 1431 gmt_unix_time followed by a random sequence of 28 random bytes since 1432 the client can use the received time information to securely obtain 1433 time information. For constrained servers it cannot be assumed that 1434 they maintain accurate time information; these devices MUST include 1435 time information in the Server.Random structure when they actually 1436 obtain accurate time information that can be utilized by clients. 1437 Clients MUST only use time information obtained from servers they 1438 trust. 1440 IoT devices using TLS/DTLS MUST offer ways to generate quality random 1441 numbers. Note that these hardware-based random number generators do 1442 not necessarily need to be implemented inside the microcontroller 1443 itself but could be made available in dedicated crypto-chips as well. 1444 Guidelines and requirements for random number generation can be found 1445 in RFC 4086 [RFC4086] and in the NIST Special Publication 800-90a 1446 [SP800-90A]. 1448 Chip manufacturers are highly encouraged to provide sufficient 1449 documentation of their design for random number generators so that 1450 customers can have confidence about the quality of the generated 1451 random numbers. The confidence can be increased by providing 1452 information about the procedures that have been used to verify the 1453 randomness of numbers generated by the hardware modules. For 1454 example, NIST Special Publication 800-22b [SP800-22b] describes 1455 statistical tests that can be used to verify random random number 1456 generators. 1458 15. Truncated MAC and Encrypt-then-MAC Extension 1460 The truncated MAC extension was introduced with RFC 6066 [RFC6066] 1461 with the goal to reduce the size of the MAC used at the Record Layer. 1462 This extension was developed for TLS ciphersuites that used older 1463 modes of operation where the MAC and the encryption operation was 1464 performed independently. 1466 The recommended ciphersuites in this document use the newer 1467 Authenticated Encryption with Associated Data (AEAD) construct, 1468 namely the CBC-MAC mode (CCM) with eight-octet authentication tags, 1469 and are therefore not appliable to the truncated MAC extension. 1471 RFC 7366 [RFC7366] introduced the encrypt-then-MAC extension (instead 1472 of the previously used MAC-then-encrypt) since the MAC-then-encrypt 1473 mechanism has been the subject of a number of security 1474 vulnerabilities. RFC 7366 is, however, also not applicable to the 1475 AEAD ciphers recommended in this document. 1477 Implementations conformant to this specification MUST use AEAD 1478 ciphers and RFC 7366 and RFC 6066 MUST NOT be implemented. 1480 16. Server Name Indication (SNI) 1482 The Server Name Indication extension defined in [RFC6066] defines a 1483 mechanism for a client to tell a TLS/DTLS server the name of the 1484 server it wants to contact. This is a useful extension for many 1485 hosting environments where multiple virtual servers are run on single 1486 IP address. 1488 This specification RECOMMENDs the implementation of RFC 6066 unless 1489 it is known that a TLS/DTLS client does not interact with a server in 1490 a hosting environment. 1492 17. Maximum Fragment Length Negotiation 1494 This RFC 6066 extension lowers the maximum fragment length support 1495 needed for the Record Layer from 2^14 bytes to 2^9 bytes. 1497 This is a very useful extension that allows the client to indicate to 1498 the server how much maximum memory buffers it uses for incoming 1499 messages. Ultimately, the main benefit of this extension is it to 1500 allows client implementations to lower their RAM requirements since 1501 the client does not need to accept packets of large size (such as 16k 1502 packets as required by plain TLS/DTLS). 1504 Client implementations MUST support this extension. 1506 18. Session Hash 1508 In order to begin connection protection, the Record Protocol requires 1509 specification of a suite of algorithms, a master secret, and the 1510 client and server random values. The algorithm for computing the 1511 master secret is defined in Section 8.1 of RFC 5246 but only includes 1512 a small number of parameters exchanged during the handshake and does 1513 not include parameters like the client and server identities. This 1514 can be utilized by an attacker to mount a man-in-the-middle attack 1515 since the master secret is not guaranteed to be unique across 1516 sessions, as discovered in the 'Triple Handshake' attack 1517 [Tripple-HS]. 1519 [I-D.ietf-tls-session-hash] defines a TLS extension that binds the 1520 master secret to a log of the full handshake that computes it, thus 1521 preventing such attacks. 1523 Client implementations SHOULD implement this extension even though 1524 the ciphersuites recommended by this profile are not vulnerable to 1525 this attack. For Diffie-Hellman-based ciphersuites the keying 1526 material is contributed by both parties and in case of the pre-shared 1527 secret key ciphersuite both parties need to be in possession of the 1528 shared secret to ensure that the handshake completes successfully. 1529 It is, however, possible that some application layer protocols will 1530 tunnel other authentication protocols on top of DTLS making this 1531 attack relevant again. 1533 19. Re-Negotiation Attacks 1535 TLS/DTLS allows a client and a server who already have a TLS/DTLS 1536 connection to negotiate new parameters, generate new keys, etc by 1537 using the re-negotiation feature. Renegotiation happens in the 1538 existing connection, with the new handshake packets being encrypted 1539 along with application data. Upon completion of the re-negotiation 1540 procedure the new channel replaces the old channel. 1542 As described in RFC 5746 [RFC5746] there is no cryptographic binding 1543 between the two handshakes, although the new handshake is carried out 1544 using the cryptographic parameters established by the original 1545 handshake. 1547 To prevent the re-negotiation attack [RFC5746] this specification 1548 RECOMMENDS to disable the TLS renegotigation feature. Clients MUST 1549 respond to server-initiated re-negotiation attempts with an alert 1550 message (no_renegotiation) and clients MUST NOT initiate them. 1552 20. Downgrading Attacks 1554 When a client sends a ClientHello with a version higher than the 1555 highest version known to the server, the server is supposed to reply 1556 with ServerHello.version equal to the highest version known to the 1557 server and the handshake can proceed. This behaviour is known as 1558 version tolerance. Version-intolerance is when the server (or a 1559 middlebox) breaks the handshake when it sees a ClientHello.version 1560 higher than what it knows about. This is the behaviour that leads 1561 some clients to re-run the handshake with lower version. As a 1562 result, a potential security vulnerability is introduced when a 1563 system is running an old TLS/SSL version (e.g., because of the need 1564 to integrate with legacy systems). In the worst case, this allows an 1565 attacker to downgrade the protocol handshake to SSL 3.0. SSL 3.0 is 1566 so broken that there is no secure cipher available for it (see 1567 [I-D.ietf-tls-sslv3-diediedie]). 1569 The above-described downgrade vulnerability is solved by the TLS 1570 Fallback Signaling Cipher Suite Value (SCSV) 1571 [I-D.ietf-tls-downgrade-scsv] extension. However, the solution is 1572 not appliable to implementations conforming to this profile since the 1573 version negotiation MUST use TLS/DTLS version 1.2 (or higher). More 1574 specifically, this implies: 1576 o Clients MUST NOT send a TLS/DTLS version lower than version 1.2 in 1577 the ClientHello. 1579 o Clients MUST NOT retry a failed negotiation offering a TLS/DTLS 1580 version lower than 1.2. 1582 o Servers MUST fail the handshake by sending a protocol_version 1583 fatal alert if a TLS/DTLS version >= 1.2 cannot be negotiated. 1584 Note that the aborted connection is non-resumable. 1586 If at some time in the future the TLS/DTLS 1.2 profile reaches the 1587 quality of SSL 3.0 a software update mechanism is needed since 1588 constrained devices are unlikely to run multiple TLS/DTLS versions 1589 due to memory size restrictions. 1591 21. Crypto Agility 1593 This document recommends software and chip manufacturers to implement 1594 AES and the CCM mode of operation. This document references the CoAP 1595 recommended ciphersuite choices, which have been selected based on 1596 implementation and deployment experience from the IoT community. 1597 Over time the preference for algorithms will, however, change. Not 1598 all components of a ciphersuite are likely to change at the same 1599 speed. Changes are more likely expected for ciphers, the mode of 1600 operation, and the hash algorithms. The recommended key lengths have 1601 to be adjusted over time. Some deployment environments will also be 1602 impacted by local regulation, which might dictate a certain cipher 1603 and key size. Ongoing discussions regarding the choice of specific 1604 ECC curves will also likely to impact implementations. 1606 The following recommendations can be made to chip manufacturers: 1608 o Make any AES hardware-based crypto implementation accessible to 1609 developers working on security implementations at higher layers. 1610 Sometimes hardware implementatios are added to microcontrollers to 1611 offer support for functionality needed at the link layer and are 1612 only available to the on-chip link layer protocol implementation. 1614 o Provide flexibility for the use of the crypto function with future 1615 extensibility in mind. For example, making an AES-CCM 1616 implementation available to developers is a first step but such an 1617 implementation may not be usable due to parameter differences 1618 between an AES-CCM implementations. AES-CCM in IEEE 802.15.4 and 1619 Bluetooth Smart uses a nonce length of 13-octets while DTLS uses a 1620 nonce length of 12-octets. Hardware implementations of AES-CCM 1621 for IEEE 802.15.4 and Bluetooth Smart are therefore not re-usable 1622 by a DTLS stack. 1624 o Offer access to building blocks in addition (or as an alternative) 1625 to the complete functionality. For example, a chip manufacturer 1626 who gives developers access to an the AES crypto function can use 1627 it in functions to build an efficient AES-GCM implementations. 1628 Another example is to make a special instruction available that 1629 increases the speed of speed-up carryless multiplications. 1631 As a recommendation for developers and product architects we 1632 recommend that sufficient headroom is provided to allow an upgrade to 1633 a newer cryptographic algorithms over the lifetime of the product. 1634 As an example, while AES-CCM is recommended thoughout this 1635 specification future products might use the ChaCha20 cipher in 1636 combination with the Poly1305 authenticator 1637 [I-D.irtf-cfrg-chacha20-poly1305]. The assumption is made that a 1638 robust software update mechanism is offered. 1640 22. Key Length Recommendations 1642 RFC 4492 [RFC4492] gives approximate comparable key sizes for 1643 symmetric- and asymmetric-key cryptosystems based on the best-known 1644 algorithms for attacking them. While other publications suggest 1645 slightly different numbers, such as [Keylength], the approximate 1646 relationship still holds true. Figure 11 illustrates the comparable 1647 key sizes in bits. 1649 At the time of writing the key size recommendations for use with TLS- 1650 based ciphers found in [I-D.ietf-uta-tls-bcp] recommend DH key 1651 lengths of at least 2048 bit, which corresponds to a 112-bit 1652 symmetric key and a 233 bit ECC keys. These recommendations are 1653 inline with those from other organizations, such as National 1654 Institute of Standards and Technology (NIST) or European Network and 1655 Information Security Agency (ENISA). The authors of 1656 [ENISA-Report2013] add that a symmetric 80-bit security level is 1657 sufficient for legacy applications for the coming years, but a 1658 128-bit security level is the minimum requirement for new systems 1659 being deployed. The authors further note that one needs to also take 1660 into account the length of time data needs to be kept secure for. 1661 The use 80-bit encryption for transactional data may be acceptable 1662 for the near future while one has to insist on 128-bit encryption for 1663 long lived data. 1665 Symmetric | ECC | DH/DSA/RSA 1666 ------------+---------+------------- 1667 80 | 163 | 1024 1668 112 | 233 | 2048 1669 128 | 283 | 3072 1670 192 | 409 | 7680 1671 256 | 571 | 15360 1673 Figure 11: Comparable Key Sizes (in bits). 1675 23. False Start 1677 A full TLS handshake as specified in [RFC5246] requires two full 1678 protocol rounds (four flights) before the handshake is complete and 1679 the protocol parties may begin to send application data. 1681 An abbreviated handshake (resuming an earlier TLS session) is 1682 complete after three flights, thus adding just one round-trip time if 1683 the client sends application data first. 1685 If the conditions outlined in [I-D.bmoeller-tls-falsestart] are met, 1686 application data can be transmitted when the sender has sent its own 1687 "ChangeCipherSpec" and "Finished" messages. This achieves an 1688 improvement of one round-trip time for full handshakes if the client 1689 sends application data first, and for abbreviated handshakes if the 1690 server sends application data first. 1692 The conditions for using the TLS False Start mechanism are met by the 1693 public-key-based ciphersuites in this document. In summary, the 1694 conditions are 1696 o Modern symmetric ciphers with an effective key length of 128 bits, 1697 such as AES-128-CCM 1699 o Client certificate types, such as ecdsa_sign 1701 o Key exchange methods, such as ECDHE_ECDSA 1703 Based on the improvement over a full roundtrip for the full TLS/DTLS 1704 exchange this specification RECOMMENDS the use of the False Start 1705 mechanism when clients send application data first. 1707 24. Privacy Considerations 1709 The DTLS handshake exchange conveys various identifiers, which can be 1710 observed by an on-path eavesdropper. For example, the DTLS PSK 1711 exchange reveals the PSK identity, the supported extensions, the 1712 session id, algorithm parameters, etc. When session resumption is 1713 used then individual TLS sessions can be correlated by an on-path 1714 adversary. With many IoT deployments it is likely that keying 1715 material and their identifiers are persistent over a longer period of 1716 time due to the cost of updating software on these devices. 1718 User participation with many IoT deployments poses a challenge since 1719 many of the IoT devices operate unattended, even though they will 1720 initially be provisioned by a human. The ability to control data 1721 sharing and to configure preference will have to be provided at a 1722 system level rather than at the level of the DTLS exchange itself, 1723 which is the scope of this document. Quite naturally, the use of 1724 DTLS with mutual authentication will allow a TLS server to collect 1725 authentication information about the IoT device (likely over a long 1726 period of time). While this strong form of authentication will 1727 prevent mis-attribution it also allows strong identification. 1728 Device-related data collection (e.g., sensor recordings) will be 1729 associated with other data to be truly useful and this extra data 1730 might include personal data about the owner of the device or data 1731 about the environment it senses. Consequently, the data stored on 1732 the server-side will be vulnerable to stored data compromise. For 1733 the communication between the client and the server this 1734 specification prevents eavesdroppers to gain access to the 1735 communication content. While the PSK-based ciphersuite does not 1736 provide PFS the asymmetric versions do. This prevents an adversary 1737 from obtaining past communication content when access to a long-term 1738 secret has been gained. Note that no extra effort to make traffic 1739 analysis more difficult is provided by the recommendations made in 1740 this document. 1742 25. Security Considerations 1744 This entire document is about security. 1746 We would also like to point out that designing a software update 1747 mechanism into an IoT system is crucial to ensure that both 1748 functionality can be enhanced and that potential vulnerabilities can 1749 be fixed. This software update mechanism is important for changing 1750 configuration information, for example, trust anchors and other 1751 keying related information. Such a suitable software update 1752 mechanism is available with the Lightweight Machine-to-Machine 1753 (LWM2M) protocol published by the Open Mobile Alliance (OMA) [LWM2M]. 1755 26. IANA Considerations 1757 This document includes no request to IANA. 1759 27. Acknowledgements 1761 Thanks to Paul Bakker, Robert Cragie, Russ Housley, Rene Hummen, 1762 Matthias Kovatsch, Sandeep Kumar, Sye Loong Keoh, Alexey Melnikov, 1763 Manuel Pegourie-Gonnard, Akbar Rahman, Eric Rescorla, Michael 1764 Richardson, Zach Shelby, Michael StJohns, Rene Struik, and Sean 1765 Turner for their helpful comments and discussions that have shaped 1766 the document. 1768 Big thanks also to Klaus Hartke, who wrote the initial version of 1769 this document. 1771 Finally, we would like to thank our area director (Stephen Farrell) 1772 and our working group chairs (Zach Shelby and Dorothy Gellert) for 1773 their support. 1775 28. References 1777 28.1. Normative References 1779 [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 1780 REGISTRATION AUTHORITY", April 2010, 1781 . 1784 [GSM-SMS] ETSI, "3GPP TS 23.040 V7.0.1 (2007-03): 3rd Generation 1785 Partnership Project; Technical Specification Group Core 1786 Network and Terminals; Technical realization of the Short 1787 Message Service (SMS) (Release 7)", March 2007. 1789 [I-D.ietf-tls-cached-info] 1790 Santesson, S. and H. Tschofenig, "Transport Layer Security 1791 (TLS) Cached Information Extension", draft-ietf-tls- 1792 cached-info-17 (work in progress), November 2014. 1794 [I-D.ietf-tls-session-hash] 1795 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 1796 A., and M. Ray, "Transport Layer Security (TLS) Session 1797 Hash and Extended Master Secret Extension", draft-ietf- 1798 tls-session-hash-03 (work in progress), November 2014. 1800 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1801 Requirement Levels", BCP 14, RFC 2119, March 1997. 1803 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 1804 for Transport Layer Security (TLS)", RFC 4279, December 1805 2005. 1807 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1808 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1810 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 1811 "Transport Layer Security (TLS) Renegotiation Indication 1812 Extension", RFC 5746, February 2010. 1814 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1815 Extension Definitions", RFC 6066, January 2011. 1817 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1818 Verification of Domain-Based Application Service Identity 1819 within Internet Public Key Infrastructure Using X.509 1820 (PKIX) Certificates in the Context of Transport Layer 1821 Security (TLS)", RFC 6125, March 2011. 1823 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1824 Security Version 1.2", RFC 6347, January 2012. 1826 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 1827 Layer Security (TLS) and Datagram Transport Layer Security 1828 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 1830 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 1831 T. Kivinen, "Using Raw Public Keys in Transport Layer 1832 Security (TLS) and Datagram Transport Layer Security 1833 (DTLS)", RFC 7250, June 2014. 1835 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 1836 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 1837 TLS", RFC 7251, June 2014. 1839 [WAP-WDP] Wireless Application Protocol Forum, "Wireless Datagram 1840 Protocol", June 2001. 1842 28.2. Informative References 1844 [ACE-WG] IETF, "Authentication and Authorization for Constrained 1845 Environments (ace) Working Group", URL: 1846 https://datatracker.ietf.org/wg/ace/charter/, Jan 2015. 1848 [AES] NIST, "FIPS PUB 197, Advanced Encryption Standard (AES)", 1849 http://www.iana.org/assignments/tls-parameters/ 1850 tls-parameters.xhtml#tls-parameters-4, November 2001. 1852 [ENISA-Report2013] 1853 ENISA, "Algorithms, Key Sizes and Parameters Report - 1854 2013", http://www.enisa.europa.eu/activities/identity-and- 1855 trust/library/deliverables/ 1856 algorithms-key-sizes-and-parameters-report, October 2013. 1858 [Heninger] 1859 Heninger, N., Durumeric, Z., Wustrow, E., and A. 1860 Halderman, "Mining Your Ps and Qs: Detection of Widespread 1861 Weak Keys in Network Devices", 21st USENIX Security 1862 Symposium, 1863 https://www.usenix.org/conference/usenixsecurity12/ 1864 technical-sessions/presentation/heninger, 2012. 1866 [HomeGateway] 1867 Eggert, L., "An experimental study of home gateway 1868 characteristics, In Proceedings of the '10th annual 1869 conference on Internet measurement'", 2010. 1871 [I-D.bmoeller-tls-falsestart] 1872 Langley, A., Modadugu, N., and B. Moeller, "Transport 1873 Layer Security (TLS) False Start", draft-bmoeller-tls- 1874 falsestart-01 (work in progress), November 2014. 1876 [I-D.bormann-core-cocoa] 1877 Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, 1878 "CoAP Simple Congestion Control/Advanced", draft-bormann- 1879 core-cocoa-02 (work in progress), July 2014. 1881 [I-D.iab-smart-object-architecture] 1882 Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 1883 "Architectural Considerations in Smart Object Networking", 1884 draft-iab-smart-object-architecture-06 (work in progress), 1885 October 2014. 1887 [I-D.ietf-core-resource-directory] 1888 Shelby, Z. and C. Bormann, "CoRE Resource Directory", 1889 draft-ietf-core-resource-directory-02 (work in progress), 1890 November 2014. 1892 [I-D.ietf-lwig-tls-minimal] 1893 Kumar, S., Keoh, S., and H. Tschofenig, "A Hitchhiker's 1894 Guide to the (Datagram) Transport Layer Security Protocol 1895 for Smart Objects and Constrained Node Networks", draft- 1896 ietf-lwig-tls-minimal-01 (work in progress), March 2014. 1898 [I-D.ietf-tls-downgrade-scsv] 1899 Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 1900 Suite Value (SCSV) for Preventing Protocol Downgrade 1901 Attacks", draft-ietf-tls-downgrade-scsv-03 (work in 1902 progress), December 2014. 1904 [I-D.ietf-tls-negotiated-dl-dhe] 1905 Gillmor, D., "Negotiated Discrete Log Diffie-Hellman 1906 Ephemeral Parameters for TLS", draft-ietf-tls-negotiated- 1907 dl-dhe-00 (work in progress), July 2014. 1909 [I-D.ietf-tls-prohibiting-rc4] 1910 Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf- 1911 tls-prohibiting-rc4-01 (work in progress), October 2014. 1913 [I-D.ietf-tls-sslv3-diediedie] 1914 Barnes, R., Thomson, M., Pironti, A., and A. Langley, 1915 "Deprecating Secure Sockets Layer Version 3.0", draft- 1916 ietf-tls-sslv3-diediedie-00 (work in progress), December 1917 2014. 1919 [I-D.ietf-uta-tls-bcp] 1920 Sheffer, Y., Holz, R., and P. Saint-Andre, 1921 "Recommendations for Secure Use of TLS and DTLS", draft- 1922 ietf-uta-tls-bcp-08 (work in progress), December 2014. 1924 [I-D.irtf-cfrg-chacha20-poly1305] 1925 Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 1926 protocols", draft-irtf-cfrg-chacha20-poly1305-07 (work in 1927 progress), January 2015. 1929 [I-D.mathewson-no-gmtunixtime] 1930 Mathewson, N. and B. Laurie, "Deprecating gmt_unix_time in 1931 TLS", draft-mathewson-no-gmtunixtime-00 (work in 1932 progress), December 2013. 1934 [I-D.schmertmann-dice-ccm-psk-pfs] 1935 Schmertmann, L. and C. Bormann, "ECDHE-PSK AES-CCM Cipher 1936 Suites with Forward Secrecy for Transport Layer Security 1937 (TLS)", draft-schmertmann-dice-ccm-psk-pfs-01 (work in 1938 progress), August 2014. 1940 [IANA-TLS] 1941 IANA, "TLS Cipher Suite Registry", 1942 http://www.iana.org/assignments/tls-parameters/ 1943 tls-parameters.xhtml#tls-parameters-4, 2014. 1945 [ImprintingSurvey] 1946 Chilton, E., "A Brief Survey of Imprinting Options for 1947 Constrained Devices", URL: http://www.lix.polytechnique.fr 1948 /hipercom/SmartObjectSecurity/papers/EricRescorla.pdf, 1949 March 2012. 1951 [Keylength] 1952 Giry, D., "Cryptographic Key Length Recommendations", 1953 http://www.keylength.com, November 2014. 1955 [LWM2M] Open Mobile Alliance, "Lightweight Machine-to-Machine, 1956 Technical Specification, Candidate Version 1.0", December 1957 2013. 1959 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1960 November 1990. 1962 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 1963 for IP version 6", RFC 1981, August 1996. 1965 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1966 Hashing for Message Authentication", RFC 2104, February 1967 1997. 1969 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 1970 CBC-MAC (CCM)", RFC 3610, September 2003. 1972 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1973 Requirements for Security", BCP 106, RFC 4086, June 2005. 1975 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1976 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1977 for Transport Layer Security (TLS)", RFC 4492, May 2006. 1979 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1980 (SHA and HMAC-SHA)", RFC 4634, July 2006. 1982 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1983 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1984 Overview, Assumptions, Problem Statement, and Goals", RFC 1985 4919, August 2007. 1987 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1988 "Transport Layer Security (TLS) Session Resumption without 1989 Server-Side State", RFC 5077, January 2008. 1991 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1992 Encryption", RFC 5116, January 2008. 1994 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 1995 Authentication Protocol", RFC 5216, March 2008. 1997 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1998 Authentication Protocol (EAP) Key Management Framework", 1999 RFC 5247, August 2008. 2001 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2002 Housley, R., and W. Polk, "Internet X.509 Public Key 2003 Infrastructure Certificate and Certificate Revocation List 2004 (CRL) Profile", RFC 5280, May 2008. 2006 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 2007 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 2008 August 2008. 2010 [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. 2011 Polk, "Internet X.509 Public Key Infrastructure: 2012 Additional Algorithms and Identifiers for DSA and ECDSA", 2013 RFC 5758, January 2010. 2015 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 2016 Management Protocol (TAMP)", RFC 5934, August 2010. 2018 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 2019 Curve Cryptography Algorithms", RFC 6090, February 2011. 2021 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 2022 Transport Layer Security (TLS)", RFC 6655, July 2012. 2024 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 2025 Format", RFC 6690, August 2012. 2027 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 2028 Multiple Certificate Status Request Extension", RFC 6961, 2029 June 2013. 2031 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2032 Constrained-Node Networks", RFC 7228, May 2014. 2034 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2035 Application Protocol (CoAP)", RFC 7252, June 2014. 2037 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2038 Attack", BCP 188, RFC 7258, May 2014. 2040 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer 2041 Security (TLS) and Datagram Transport Layer Security 2042 (DTLS)", RFC 7366, September 2014. 2044 [RFC7390] Rahman, A. and E. Dijk, "Group Communication for the 2045 Constrained Application Protocol (CoAP)", RFC 7390, 2046 October 2014. 2048 [RFC7397] Gilger, J. and H. Tschofenig, "Report from the Smart 2049 Object Security Workshop", RFC 7397, December 2014. 2051 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 2052 IPv6 over Low-Power Wireless Personal Area Networks 2053 (6LoWPANs)", RFC 7400, November 2014. 2055 [SP800-22b] 2056 NIST, "Special Publication 800-22, Revision 1a, A 2057 Statistical Test Suite for Random and Pseudorandom Number 2058 Generators for Cryptographic Applications", 2059 http://csrc.nist.gov/publications/nistpubs/800-22-rev1a/ 2060 SP800-22rev1a.pdf, April 2010. 2062 [SP800-90A] 2063 NIST, "DRAFT Special Publication 800-90a, Revision 1, 2064 Recommendation for Random Number Generation Using 2065 Deterministic Random Bit Generators", 2066 http://csrc.nist.gov/publications/drafts/800-90/ 2067 sp800-90a_r1_draft_november2014_ver.pdf, November 2014. 2069 [Tripple-HS] 2070 Bhargavan, K., Delignat-Lavaud, C., Pironti, A., and P. 2071 Strub, "Triple Handshakes and Cookie Cutters: Breaking and 2072 Fixing Authentication over TLS", IEEE Symposium on 2073 Security and Privacy, pages 98-113, 2014. 2075 Appendix A. Conveying DTLS over SMS 2077 This section is normative for the use of DTLS over SMS. Timer 2078 recommendations are already outlined in Section 13 and also 2079 applicable to the transport of DTLS over SMS. 2081 This section requires readers to be familiar with the terminology and 2082 concepts described in [GSM-SMS], and [WAP-WDP]. 2084 The remainder of this section assumes Mobile Stations are capable of 2085 producing and consuming 8-bit binary data encoded Transport Protocol 2086 Data Units (TPDU). 2088 A.1. Overview 2090 DTLS adds an additional roundtrip to the TLS [RFC5246] handshake to 2091 serve as a return-routability test for protection against certain 2092 types of DoS attacks. Thus a full blown DTLS handshake comprises up 2093 to 6 "flights" (i.e., logical message exchanges), each of which is 2094 then mapped on to one or more DTLS records using the segmentation and 2095 reassembly (SaR) scheme described in Section 4.2.3 of [RFC6347]. The 2096 overhead for said scheme is 6 bytes per Handshake message which, 2097 given a realistic 10+ messages handshake, would amount around 60 2098 bytes across the whole handshake sequence. 2100 Note that the DTLS SaR scheme is defined for handshake messages only. 2101 In fact, DTLS records are never fragmented and MUST fit within a 2102 single transport layer datagram. 2104 SMS provides an optional segmentation and reassembly scheme as well, 2105 known as Concatenated short messages (see Section 9.2.3.24.1 of 2106 [GSM-SMS]). However, since the SaR scheme in DTLS cannot be 2107 circumvented, the Concatenated short messages mechanism SHOULD NOT be 2108 used during handshake to avoid redundant overhead. Before starting 2109 the handshake phase (either actively or passively), the DTLS 2110 implementation MUST be explicitly configured with the PMTU of the SMS 2111 transport in order to correctly instrument its SaR function. The 2112 PMTU SHALL be 133 bytes if WDP-based multiplexing is used (see 2113 Appendix A.3), 140 bytes otherwise. 2115 It is RECOMMENDED to use the established security context over the 2116 longest possible period (possibly until a Closure Alert message is 2117 received, or after a very long inactivity timeout) to avoid the 2118 expensive re-establishment of the security association. 2120 A.2. Message Segmentation and Re-Assembly 2122 The content of an SMS message is carried in the TP-UserData field, 2123 and its size may be up to 140 bytes. As already mentioned in 2124 Appendix A.1, longer (i.e., up to 34170 bytes) messages can be sent 2125 using Concatenated SMS. 2127 This scheme consumes 6-7 bytes (depending on whether the short or 2128 long segmentation format is used) of the TP-UserData field, thus 2129 reducing the space available for the actual content of the SMS 2130 message to 133-134 bytes per TPDU. 2132 Though in principle a PMTU value higher than 140 bytes could be used, 2133 which may look like an appealing option given its more efficient use 2134 of the transport, there are disadvantages to consider. First, there 2135 is an additional overhead of 7 bytes per TPDU to be paid to the SaR 2136 function (which is in addition to the overhead introduced by the DTLS 2137 SaR mechanism. Second, some networks only partially support the 2138 Concatenated SMS function and others do not support it at all. 2140 For these reasons, the Concatenated short messages mechanism SHOULD 2141 NOT be used, and it is RECOMMENDED to leave the same PMTU settings 2142 used during the handshake phase, i.e., 133 bytes if WDP- based 2143 multiplexing is enabled, 140 bytes otherwise. 2145 Note that, after DTLS handshake has completed, any fragmentation and 2146 reassembly logic that pertains the application layer (e.g., 2147 segmenting CoAP messages into DTLS records and reassembling them 2148 after the crypto operations have been successfully performed) needs 2149 to be handled by the application that uses the established DTLS 2150 tunnel. 2152 A.3. Multiplexing Security Associations 2154 Unlike IPsec ESP/AH, DTLS records do not contain any association 2155 identifiers. Applications must arrange to multiplex between 2156 associations on the same endpoint which, when using UDP/IP, is 2157 usually done with the host/port number. 2159 If the DTLS server allows more than one client to be active at any 2160 given time, then the WAP User Datagram Protocol [WAP-WDP] can be used 2161 to achieve multiplexing of the different security associations. (The 2162 use of WDP provides the additional benefit that upper layer protocols 2163 can operate independently of the underlying wireless network, hence 2164 achieving application-agnostic transport handover.) 2166 The total overhead cost for encoding the WDP source and destination 2167 ports is 7 bytes out of the total available for the SMS content. 2169 The receiving side of the communication gets the source address from 2170 the originator address (TP-OA) field of the SMS-DELIVER TPDU. This 2171 way an unique 4-tuple identifying the security association can be 2172 reconstructed at both ends. (When replying to its DTLS peer, the 2173 sender will swaps the TP-OA and TP-DA parameters and the source and 2174 destination ports in the WDP.) 2176 A.4. Timeout 2178 If SMS-STATUS-REPORT messages are enabled, their receipt is not to be 2179 interpreted as the signal that the specific handshake message has 2180 been acted upon by the receiving party. Therefore, it MUST NOT be 2181 taken into account by the DTLS timeout and retransmission function. 2183 Handshake messages MUST carry a validity period (TP-VP parameter in a 2184 SMS-SUBMIT TPDU) that is not less than the current value of the 2185 retransmission timeout. In order to avoid persisting messages in the 2186 network that will be discarded by the receiving party, handshake 2187 messages SHOULD carry a validity period that is the same as, or just 2188 slightly higher than, the current value of the retransmission 2189 timeout. 2191 Appendix B. DTLS Record Layer Per-Packet Overhead 2193 Figure 12 shows the overhead for the DTLS record layer for protecting 2194 data traffic when AES-128-CCM with an 8-octet Integrity Check Value 2195 (ICV) is used. 2197 DTLS Record Layer Header................13 bytes 2198 Nonce (Explicit).........................8 bytes 2199 ICV..................................... 8 bytes 2200 ------------------------------------------------ 2201 Overhead................................29 bytes 2202 ------------------------------------------------ 2204 Figure 12: AES-128-CCM-8 DTLS Record Layer Per-Packet Overhead. 2206 The DTLS record layer header has 13 octets and consists of 2208 o 1 octet content type field, 2210 o 2 octet version field, 2212 o 2 octet epoch field, 2214 o 6 octet sequence number, 2216 o 2 octet length field. 2218 The "nonce" input to the AEAD algorithm is exactly that of [RFC5288], 2219 i.e., 12 bytes long. It consists of a 4 octet salt and an 8 octet 2220 nonce. The salt is the "implicit" part of the nonce and is not sent 2221 in the packet. Since the nonce_explicit may be the 8 octet sequence 2222 number and, in DTLS, it is the 8 octet epoch concatenated with the 6 2223 octet sequence number. 2225 RFC 6655 [RFC6655] allows the nonce_explicit to be a sequence number 2226 or something else. This document makes this use more restrictive for 2227 use with DTLS: the 64-bit none_explicit MUST be the 16-bit epoch 2228 concatenated with the 48-bit seq_num. The sequence number component 2229 of the nonce_explicit field at the AES-CCM layer is an exact copy of 2230 the sequence number in the record layer header field. This leads to 2231 a duplication of 8-bytes per record. 2233 To avoid this 8-byte duplication RFC 7400 [RFC7400] provides help 2234 with the use of the generic header compression technique for IPv6 2235 over Low-Power Wireless Personal Area Networks (6LoWPANs). Note that 2236 this header compression technique is not available when DTLS is 2237 exchanged over transports that do not use IPv6 or 6LoWPAN, such as 2238 the SMS transport described in Appendix A. 2240 Appendix C. DTLS Fragmentation 2242 [Editor's Note: Proposed text that requires discussion. ] 2244 Section 4.2.3 of [RFC6347] advises DTLS implementations to not 2245 produce overlapping fragments, but requires receivers to be able to 2246 cope with them. The need for the latter requisite is explained in 2247 Section 4.1.1.1 of [RFC6347]: accurate path MTU (PMTU) estimation may 2248 be traded for shorter handshake completion time. This approach may 2249 be beneficial in unconstrained networks where a PMTU of 1280 bytes 2250 can be pretty much universally assumed. However, when the handshake 2251 is carried over a narrow-band radio technology, such as IEEE 802.15.4 2252 or GSM-SMS, and the client is lacking reliable PMTU data to inform 2253 fragmentation (e.g., using [RFC1981] or [RFC1191]) can put a cost on 2254 the constrained implementation in terms of memory (due to re- 2255 buffering) and latency (due to re-transmission) much higher than the 2256 benefit that it would get from a shorter handshake. 2258 In order to reduce the likelihood of producing different fragment 2259 sizes (and consequent overlaps) within the same handshake, this 2260 document RECOMMENDs: 2262 o for clients (handshake initiators), to perform PMTU discovery 2263 towards the server before handshake starts, and not rely on any 2264 guesses (unless the network path characteristics are reliably 2265 known from another source); 2267 o for servers, to mirror the fragment size selected by their 2268 clients. 2270 Authors' Addresses 2271 Hannes Tschofenig (editor) 2272 ARM Ltd. 2273 110 Fulbourn Rd 2274 Cambridge CB1 9NJ 2275 Great Britain 2277 Email: Hannes.tschofenig@gmx.net 2278 URI: http://www.tschofenig.priv.at 2280 Thomas Fossati 2281 Alcatel-Lucent 2282 3 Ely Road 2283 Milton, Cambridge CB24 6DD 2284 UK 2286 Email: thomas.fossati@alcatel-lucent.com