idnits 2.17.1 draft-ietf-dice-profile-10.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 (March 8, 2015) is 3330 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 1266, but not defined == Unused Reference: 'I-D.ietf-lwig-tls-minimal' is defined on line 1968, 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 (-03) exists of draft-ietf-tls-sslv3-diediedie-02 -- 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 (~~), 9 warnings (==), 10 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: September 9, 2015 Alcatel-Lucent 6 March 8, 2015 8 A TLS/DTLS Profile for the Internet of Things 9 draft-ietf-dice-profile-10.txt 11 Abstract 13 A common design pattern in Internet of Things (IoT) deployments is 14 the use of a constrained device that collects data via sensor or 15 controls actuators for use in 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 (DTLS) 1.2 profile that offers communications security for this 20 data exchange thereby preventing eavesdropping, tampering, and 21 message forgery. The lack of communication security is a common 22 vulnerability in Internet of Things products that can easily be 23 solved by using these well-researched and widely deployed Internet 24 security protocols. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 9, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. TLS/DTLS Protocol Overview . . . . . . . . . . . . . . . . . 4 63 4. Communication Models . . . . . . . . . . . . . . . . . . . . 5 64 4.1. Constrained TLS/DTLS Clients . . . . . . . . . . . . . . 6 65 4.2. Constrained TLS/DTLS Servers . . . . . . . . . . . . . . 13 66 5. The Ciphersuite Concept . . . . . . . . . . . . . . . . . . . 18 67 6. Credential Types . . . . . . . . . . . . . . . . . . . . . . 19 68 6.1. Pre-Shared Secret . . . . . . . . . . . . . . . . . . . . 19 69 6.2. Raw Public Key . . . . . . . . . . . . . . . . . . . . . 21 70 6.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 23 71 7. Signature Algorithm Extension . . . . . . . . . . . . . . . . 27 72 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 28 73 9. Session Resumption . . . . . . . . . . . . . . . . . . . . . 29 74 10. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 30 75 11. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 30 76 12. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 31 77 13. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 33 78 14. Random Number Generation . . . . . . . . . . . . . . . . . . 34 79 15. Truncated MAC and Encrypt-then-MAC Extension . . . . . . . . 35 80 16. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 35 81 17. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 36 82 18. Session Hash . . . . . . . . . . . . . . . . . . . . . . . . 36 83 19. Re-Negotiation Attacks . . . . . . . . . . . . . . . . . . . 36 84 20. Downgrading Attacks . . . . . . . . . . . . . . . . . . . . . 37 85 21. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 38 86 22. Key Length Recommendations . . . . . . . . . . . . . . . . . 39 87 23. False Start . . . . . . . . . . . . . . . . . . . . . . . . . 39 88 24. Privacy Considerations . . . . . . . . . . . . . . . . . . . 40 89 25. Security Considerations . . . . . . . . . . . . . . . . . . . 41 90 26. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 91 27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 92 28. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 93 28.1. Normative References . . . . . . . . . . . . . . . . . . 42 94 28.2. Informative References . . . . . . . . . . . . . . . . . 43 95 Appendix A. Conveying DTLS over SMS . . . . . . . . . . . . . . 49 96 A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 49 97 A.2. Message Segmentation and Re-Assembly . . . . . . . . . . 50 98 A.3. Multiplexing Security Associations . . . . . . . . . . . 50 99 A.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 51 100 Appendix B. DTLS Record Layer Per-Packet Overhead . . . . . . . 52 101 Appendix C. DTLS Fragmentation . . . . . . . . . . . . . . . . . 53 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 104 1. Introduction 106 An engineer developing an Internet of Things (IoT) device needs to 107 investigate the security threats and decide about the security 108 services that can be used to mitigate these threats. 110 Enabling IoT devices to exchange data often requires authentication 111 of the two endpoints and the ability to provide integrity- and 112 confidentiality-protection of exchanged data. While these security 113 services can be provided at different layers in the protocol stack, 114 the use of Transport Layer Security (TLS)/Datagram TLS (DTLS) has 115 been very popular with many application protocols and it is likely to 116 be useful for IoT scenarios as well. 118 Fitting Internet protocols into constrained devices can be difficult 119 but thanks to the standardization efforts new profiles and protocols 120 are available, such as the Constrained Application Protocol (CoAP) 121 [RFC7252]. UDP is mainly used to carry CoAP messages but other 122 transports can be utilized, such as SMS or even TCP. 124 While the main goal for this document is to protect CoAP messages 125 using DTLS 1.2 [RFC6347] the information contained in the following 126 sections is not limited to CoAP nor to DTLS itself. 128 Instead, this document defines a profile of DTLS 1.2 [RFC6347] and 129 TLS 1.2 [RFC5246] that offers communication security services for IoT 130 applications and is reasonably implementable on many constrained 131 devices. Profile thereby means that available configuration options 132 and protocol extensions are utilized to best support the IoT 133 environment. This document does not alter TLS/DTLS specifications 134 and does not introduce any new TLS/DTLS extension. 136 The main target audience for this document is the embedded system 137 developer configuring and using a TLS/DTLS stack. This document may, 138 however, also help those developing or selecting a suitable TLS/DTLS 139 stack for an Internet of Things product. 141 2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 This specification refers to TLS as well as DTLS and particularly to 148 version 1.2, which is the most recent version at the time of writing. 149 We refer to TLS/DTLS whenever the text is applicable to both versions 150 of the protocol and to TLS or DTLS when there are differences between 151 the two protocols. 153 Note that "Client" and "Server" in this document refer to TLS/DTLS 154 roles, where the client initiates the handshake. This does not 155 restrict the interaction pattern of the protocols on top of DTLS 156 since the record layer allows bi-directional communication. This 157 aspect is further described in Section 4. 159 RFC 7228 [RFC7228] introduces the notion of constrained-node 160 networks, which are made of small devices with severe constraints on 161 power, memory, and processing resources. The terms constrained 162 devices, and Internet of Things (IoT) devices are used 163 interchangeably. 165 The terms "Certification Authority" (CA) and "Distinguished Name" 166 (DN) are taken from [RFC5280]. The terms "trust anchor" and "trust 167 anchor store" are defined in [RFC6024] as 169 "A trust anchor represents an authoritative entity via a public 170 key and associated data. The public key is used to verify digital 171 signatures, and the associated data is used to constrain the types 172 of information for which the trust anchor is authoritative." 174 "A trust anchor store is a set of one or more trust anchors stored 175 in a device. A device may have more than one trust anchor store, 176 each of which may be used by one or more applications." 178 3. TLS/DTLS Protocol Overview 180 The TLS protocol [RFC5246] provides authenticated, confidentiality- 181 and integrity-protected communication between two endpoints. The 182 protocol is composed of two layers: the Record Protocol and the 183 Handshaking Protocols. At the lowest level, layered on top of a 184 reliable transport protocol (e.g., TCP), is the Record Protocol. It 185 provides connection security by using symmetric cryptography for 186 confidentiality, data origin authentication, and integrity 187 protection. The Record Protocol is used for encapsulation of various 188 higher-level protocols. The handshaking protocols consist of three 189 sub-protocols, namely the handshake protocol, the change cipher spec 190 protocol and the alert protocol. The handshake protocol allows the 191 server and client to authenticate each other and to negotiate an 192 encryption algorithm and cryptographic keys before the application 193 protocol transmits or receives data. 195 The design of DTLS [RFC6347] is intentionally very similar to TLS. 196 However, since DTLS operates on top of an unreliable datagram 197 transport, it must explicitly cope with the reliable and ordered 198 delivery assumptions made by TLS. RFC 6347 explains these 199 differences in great detail. As a short summary, for those not 200 familiar with DTLS the differences are: 202 o An explicit sequence number and an epoch field is included in the 203 Record Protocol. Section 4.1 of RFC 6347 explains the processing 204 rules for these two new fields. The value used to compute the MAC 205 is the 64-bit value formed by concatenating the epoch and the 206 sequence number. 208 o Stream ciphers must not be used with DTLS. The only stream cipher 209 defined for TLS 1.2 is RC4 and due to cryptographic weaknesses it 210 is not recommended anymore even for use with TLS 211 [I-D.ietf-tls-prohibiting-rc4]. Note that the term 'stream 212 cipher' is a technical term in the TLS specification. Section 4.7 213 of RFC 5246 defines stream ciphers in TLS as follows: in stream 214 cipher encryption, the plaintext is exclusive-ORed with an 215 identical amount of output generated from a cryptographically 216 secure keyed pseudorandom number generator. 218 o The TLS Handshake Protocol has been enhanced to include a 219 stateless cookie exchange for Denial of Service (DoS) resistance. 220 For this purpose a new handshake message, the HelloVerifyRequest, 221 was added to DTLS. This handshake message is sent by the server 222 and includes a stateless cookie, which is returned in a 223 ClientHello message back to the server. Although the exchange is 224 optional for the server to execute, a client implementation has to 225 be prepared to respond to it. Furthermore, the handshake message 226 format has been extended to deal with message loss, reordering, 227 and fragmentation. 229 4. Communication Models 231 This document describes a profile of DTLS and, to be useful, it has 232 to make assumptions about the envisioned communication architecture. 234 Two communication architectures (and consequently two profiles) are 235 described in this document. 237 4.1. Constrained TLS/DTLS Clients 239 The communication architecture shown in Figure 1 assumes a unicast 240 communication interaction with an IoT device utilizing a constrained 241 TLS/DTLS client interacting with one or multiple TLS/DTLS servers. 243 Before a client can initiate the TLS/DTLS handshake it needs to know 244 the IP address of that server and what credentials to use. 245 Application layer protocols, such as CoAP, which is conveyed on top 246 of DTLS, may be configured with URIs of the endpoints to which CoAP 247 needs to register and publish data. This configuration information 248 (including credentials) may be conveyed to clients as part of a 249 firmware/software package or via a configuration protocol. The 250 following credential types are supported by this profile: 252 o For PSK-based authentication (see Section 6.1), this includes the 253 paired "PSK identity" and shared secret to be used with each 254 server. 256 o For raw public key-based authentication (see Section 6.2), this 257 includes either the server's public key or the hash of the 258 server's public key. 260 o For certificate-based authentication (see Section 6.3), this 261 includes a pre-populated trust anchor store that allows the DTLS 262 stack to perform path validation for the certificate obtained 263 during the handshake with the server. 265 Figure 1 shows example configuration information stored at the 266 constrained client for use with respective servers. 268 This document focuses on the description of the DTLS client-side 269 functionality but, quite naturally, the equivalent server-side 270 support has to be available. 272 +////////////////////////////////////+ 273 | Configuration | 274 |////////////////////////////////////| 275 | Server A --> PSK Identity, PSK | 276 | | 277 | Server B --> Public Key (Server B),| 278 | Public/Private Key | 279 | (for Client) | 280 | | 281 | Server C --> Public/Private Key | 282 | (for Client) | 283 | Trust Anchor Store | 284 +------------------------------------+ 285 oo 286 oooooo 287 o 288 +-----------+ 289 |Constrained| 290 |TLS/DTLS | 291 |Client |- 292 +-----------+ \ 293 \ ,-------. 294 ,' `. +------+ 295 / IP-based \ |Server| 296 ( Network ) | A | 297 \ / +------+ 298 `. ,' 299 '---+---' +------+ 300 | |Server| 301 | | B | 302 | +------+ 303 | 304 | +------+ 305 +----------------->|Server| 306 | C | 307 +------+ 309 Figure 1: Constrained Client Profile. 311 4.1.1. Examples of Constrained Client Exchanges 313 4.1.1.1. Network Access Authentication Example 315 Re-use is a recurring theme when considering constrained environments 316 and is behind a lot of the directions taken in developments for 317 constrained environments. The corollary of re-use is to not add 318 functionality if it can be avoided. An example relevant to the use 319 of TLS is network access authentication, which takes place when a 320 device connects to a network and needs to go through an 321 authentication and access control procedure before it is allowed to 322 communicate with other devices or connect to the Internet. 324 Figure 2 shows the network access architecture with the IoT device 325 initiating the communication to an access point in the network using 326 the procedures defined for a specific physical layer. Since 327 credentials may be managed and stored centrally, in the 328 Authentication, Authorization, and Accounting (AAA) server, the 329 security protocol exchange may need to be relayed via the 330 Authenticator, i.e., functionality running on the access point, to 331 the AAA server. The authentication and key exchange protocol itself 332 is encapsulated within a container, the Extensible Authentication 333 Protocol (EAP) [RFC3748], and messages are conveyed back and forth 334 between the EAP endpoints, namely the EAP peer located on the IoT 335 device and the EAP server located on the AAA server or the access 336 point. To route EAP messages from the access point, acting as a AAA 337 client, to the AAA server requires an adequate protocol mechanism, 338 namely RADIUS [RFC2865] or Diameter [RFC6733]. 340 More details about the concepts and a description about the 341 terminology can be found in RFC 5247 [RFC5247]. 343 +--------------+ 344 |Authentication| 345 |Authorization | 346 |Accounting | 347 |Server | 348 |(EAP Server) | 349 | | 350 +-^----------^-+ 351 * EAP o RADIUS/ 352 * o Diameter 353 --v----------v-- 354 /// \\\ 355 // \\ 356 | Federation | 357 | Substrate | 358 \\ // 359 \\\ /// 360 --^----------^-- 361 * EAP o RADIUS/ 362 * o Diameter 363 +-------------+ +-v----------v--+ 364 | | EAP/EAP Method | | 365 | Internet of |<***************************>| Access Point | 366 | Things | |(Authenticator)| 367 | Device | EAP Lower Layer and |(AAA Client) | 368 | (EAP Peer) | Secure Association Protocol | | 369 | |<--------------------------->| | 370 | | | | 371 | | Physical Layer | | 372 | |<===========================>| | 373 +-------------+ +---------------+ 374 Legend: 376 <****>: Device-to-AAA Server Exchange 377 <---->: Device-to-Authenticator Exchange 378 : AAA Client-to-AAA Server Exchange 379 <====>: Physical layer like IEEE 802.11/802.15.4 381 Figure 2: Network Access Architecture. 383 One standardized EAP method is EAP-TLS, defined in RFC 5216 384 [RFC5216], which re-uses the TLS-based protocol exchange and 385 encapsulates it inside the EAP payload. In terms of re-use this 386 allows many components of the TLS protocol to be shared between the 387 network access security functionality and the TLS functionality 388 needed for securing application layer traffic. In the EAP-TLS 389 exchange shown in Figure 3 the IoT device as the EAP peer acts as a 390 TLS client. 392 Authenticating Peer Authenticator 393 ------------------- ------------- 394 <- EAP-Request/ 395 Identity 396 EAP-Response/ 397 Identity (MyID) -> 398 <- EAP-Request/ 399 EAP-Type=EAP-TLS 400 (TLS Start) 401 EAP-Response/ 402 EAP-Type=EAP-TLS 403 (TLS client_hello)-> 404 <- EAP-Request/ 405 EAP-Type=EAP-TLS 406 (TLS server_hello, 407 TLS certificate, 408 [TLS server_key_exchange,] 409 TLS certificate_request, 410 TLS server_hello_done) 411 EAP-Response/ 412 EAP-Type=EAP-TLS 413 (TLS certificate, 414 TLS client_key_exchange, 415 TLS certificate_verify, 416 TLS change_cipher_spec, 417 TLS finished) -> 418 <- EAP-Request/ 419 EAP-Type=EAP-TLS 420 (TLS change_cipher_spec, 421 TLS finished) 422 EAP-Response/ 423 EAP-Type=EAP-TLS -> 424 <- EAP-Success 426 Figure 3: EAP-TLS Exchange. 428 The guidance in this document also applies to the use of EAP-TLS for 429 network access authentication. An IoT device using a network access 430 authentication solution based on TLS can re-use most parts of the 431 code for the use of DTLS/TLS at the application layer thereby saving 432 a significant amount of flash memory. Note, however, that the 433 credentials used for network access authentication and those used for 434 application layer security are very likely different. 436 4.1.1.2. CoAP-based Data Exchange Example 438 When a constrained client uploads sensor data to a server 439 infrastructure it may use CoAP by pushing the data via a POST message 440 to a pre-configured endpoint on the server. In certain circumstances 441 this might be too limiting and additional functionality is needed, as 442 shown in Figure 4, where the IoT device itself runs a CoAP server 443 hosting the resource that is made accessible to other entities. 444 Despite running a CoaP server on the IoT device it is still the DTLS 445 client on the IoT device that initiates the interaction with the non- 446 constrained resource server in our scenario. 448 Figure 4 shows a sensor starting a DTLS exchange with a resource 449 directory to register available resources. 450 [I-D.ietf-core-resource-directory] defines the resource directory 451 (RD) as a web entity that stores information about web resources and 452 implements Representational State Transfer (REST) interfaces for 453 registration and lookup of those resources. Note that the described 454 exchange is borrowed from the OMA Lightweight Machine-to-Machine 455 (LWM2M) specification [LWM2M] that uses RD but adds proxy 456 functionality. 458 The initial DTLS interaction between the sensor, acting as a DTLS 459 client, and the resource directory, acting as a DTLS server, will be 460 a full DTLS handshake. Once this handshake is complete both parties 461 have established the DTLS record layer. Subsequently, the CoAP 462 client can securely register at the resource directory. 464 After some time (assuming that the client regularly refreshes its 465 registration) the resource directory receives a request from an 466 application to retrieve the temperature information from the sensor. 467 This request is relayed by the resource directory to the sensor using 468 a GET message exchange. The already established DTLS record layer 469 can be used to secure the message exchange. 471 Resource 472 Sensor Directory 473 ------ --------- 475 +--- 476 | 477 | ClientHello --------> 478 | client_certificate_type 479 F| server_certificate_type 480 U| 481 L| <------- HelloVerifyRequest 482 L| 483 | ClientHello --------> 484 D| client_certificate_type 485 T| server_certificate_type 486 L| 487 S| ServerHello 488 | client_certificate_type 489 H| server_certificate_type 490 A| Certificate 491 N| ServerKeyExchange 492 D| CertificateRequest 493 S| <-------- ServerHelloDone 494 H| 495 A| Certificate 496 K| ClientKeyExchange 497 E| CertificateVerify 498 | [ChangeCipherSpec] 499 | Finished --------> 500 | 501 | [ChangeCipherSpec] 502 | <-------- Finished 503 +--- 505 +--- ///+ 506 C| \ D 507 O| Req: POST coap://rd.example.com/rd?ep=node1 \ T 508 A| Payload: \ L 509 P| ;ct=41; \ S 510 | rt="temperature-c";if="sensor", \ 511 R| ;ct=41; \ R 512 D| rt="light-lux";if="sensor" \ E 513 | --------> \ C 514 R| \ O 515 E| \ R 516 G| Res: 2.01 Created \ D 517 .| <-------- Location: /rd/4521 \ 518 | \ L 519 +--- \ A 520 \ Y 521 * \ E 522 * (time passes) \ R 523 * \ 524 +--- \ P 525 C| \ R 526 O| Req: GET coaps://sensor.example.com/temp \ O 527 A| <-------- \ T 528 P| \ E 529 | Res: 2.05 Content \ C 530 G| Payload: \ T 531 E| 25.5 --------> \ E 532 T| \ D 533 +--- ///+ 535 Figure 4: DTLS/CoAP exchange using Resource Directory. 537 4.2. Constrained TLS/DTLS Servers 539 Section 4.1 illustrates a deployment model where the TLS/DTLS client 540 is constrained and efforts need to be taken to improve memory 541 utilization, bandwidth consumption, reduce performance impacts, etc. 542 In this section, we assume a scenario where constrained devices run 543 TLS/ DTLS servers to secure access to application layer services 544 running on top of CoAP, HTTP or other protocols. Figure 5 545 illustrates a possible deployment whereby a number of constrained 546 servers are waiting for regular clients to access their resources. 547 The entire process is likely, but not necessarily, controlled by a 548 third party, the authentication and authorisation server. This 549 authentication and authorization server is responsible for holding 550 authorization policies that govern the access to resources and 551 distribution of keying material. 553 +////////////////////////////////////+ 554 | Configuration | 555 |////////////////////////////////////| 556 | Credentials | 557 | Client A -> Public Key | 558 | Server S1 -> Symmetric Key | 559 | Server S2 -> Certificate | 560 | Server S3 -> Public Key | 561 | Trust Anchor Store | 562 | Access Control Lists | 563 | Resource X: Client A / GET | 564 | Resource Y: Client A / PUT | 565 +------------------------------------+ 566 oo 567 oooooo 568 o 569 +---------------+ +-----------+ 570 |Authentication | +-------->|TLS/DTLS | 571 |& Authorization| | |Client A | 572 |Server | | +-----------+ 573 +---------------+ ++ 574 ^ | +-----------+ 575 \ | |Constrained| 576 \ ,-------. | Server S1 | 577 ,' `. +-----------+ 578 / Local \ 579 ( Network ) 580 \ / +-----------+ 581 `. ,' |Constrained| 582 '---+---' | Server S2 | 583 | +-----------+ 584 | 585 | +-----------+ 586 +-----------------> |Constrained| 587 | Server S3 | 588 +-----------+ 590 Figure 5: Constrained Server Profile. 592 A deployment with constrained servers has to overcome several 593 challenges. Below we explain how these challenges have be solved 594 with CoAP, as an example. Other protocols may offer similar 595 capabilities. While the requirements for the TLS/DTLS protocol 596 profile change only slightly when run on a constrained server (in 597 comparison to running it on a constrained client) several other eco- 598 system factor will impact deployment. 600 There are several challenges that need to be addressed: 602 Discovery and Reachability: 604 A client must first and foremost discover the server before 605 initiating a connection to it. Once it as been discovered, 606 reachability to the device needs to be maintained. 608 In CoAP the discovery of resources offered by servers is 609 accomplished by sending a unicast or multicast CoAP GET to a well- 610 known URI. The CORE Link format specification [RFC6690] describes 611 the use case (see Section 1.2.1), and reserves the URI (see 612 Section 7.1). Section 7 of the CoAP specification [RFC7252] 613 describes the discovery procedure. [RFC7390] describes use case 614 for discovering CoAP servers using multicast (see Section 3.3), 615 and specifies the protocol processing rules for CoAP group 616 communications (see Section 2.7). 618 The use of Resource Directory (RD) 619 [I-D.ietf-core-resource-directory] is yet another possibility for 620 discovering registered servers and their resources. Since RD is 621 usually not a proxy, clients can discover links registered with 622 the RD and then access them directly. 624 Authentication: 626 The next challenge concerns the provisioning of authentication 627 credentials to the clients as well as servers. In Section 4.1 we 628 assumed that credentials (and other configuration information) are 629 provisioned to the device and that those can be used with the 630 authorization servers. Of course, this leads to a very static 631 relationship between the clients and their server-side 632 infrastructure but poses fewer challenges from a deployment point 633 of view, as described in Section 2 of 634 [I-D.iab-smart-object-architecture] these different communication 635 patterns. In any case, engineers and product designers have to 636 determine how the relevant credentials are distributed to the 637 respective parties. For example, shared secrets may need to be 638 provisioned to clients and the constrained servers for subsequent 639 use of TLS/DTLS PSK. In other deployments, certificates, private 640 keys, and trust anchors for use with certificate-based 641 authentication may need to be utilized. 643 Practical solutions either use pairing (also called imprinting) or 644 a trusted third party. With pairing two devices execute a special 645 protocol exchange that is unauthenticated to establish an shared 646 key (for example using an unauthenticated Diffie-Hellman exchange) 647 key. To avoid man-in-the-middle attacks an out-of-band channel is 648 used to verify that nobody has tampered with the exchanged 649 protocol messages. This out-of-band channel can come in many 650 forms, including: 652 * Human involvement by comparing hashed keys, entering passkeys, 653 scanning QR codes 655 * The use of alternative wireless communication channels (e.g., 656 infra-red communication in addition to WiFi) 658 * Proximity-based information 660 More details about these different pairing/imprinting techniques 661 can be found in the smart object security workshop report 662 [RFC7397] and various position papers submitted to that topic, 663 such as [ImprintingSurvey]. The use of a trusted third party 664 follows a different approach and is subject to ongoing 665 standardization efforts in the 'Authentication and Authorization 666 for Constrained Environments (ACE)' working group [ACE-WG]. 668 Authorization 670 The last challenge is the ability for the constrained server to 671 make an authorization decision when clients access protected 672 resources. Pre-provisioning access control information to 673 constrained servers may be one option but works only in a small 674 scale, less dynamic environment. For a more fine-grained and 675 dynamic access control the reader is referred to the ongoing work 676 in the ACE working group. 678 Figure 6 shows an example interaction whereby a device, a thermostat 679 in our case, searches in the local network for discoverable resources 680 and accesses those. The thermostat starts the procedure using a 681 link-local discovery message using the "All CoAP Nodes" multicast 682 address by utilizing the RFC 6690 [RFC6690] link format. The IPv6 683 multicast address used for site-local discovery is FF02::FD. As a 684 result, a temperature sensor and a fan respond. These responses 685 allow the thermostat to subsequently read temperature information 686 from the temperature sensor with a CoAP GET request issued to the 687 previously learned endpoint. In this example we assume that 688 accessing the temperature sensor readings and controlling the fan 689 requires authentication and authorization of the thermostat and TLS 690 is used to authenticate both endpoint and to secure the 691 communication. 693 Temperature 694 Thermostat Sensor Fan 695 ---------- --------- --- 697 Discovery 698 --------------------> 699 GET coap://[FF02::FD]/.well-known/core 701 CoAP 2.05 Content 702 <------------------------------- 703 ;rt="temperature"; 704 if="sensor" 706 CoAP 2.05 Content 707 <-------------------------------------------------- 708 ;rt="fan";if="actuation" 710 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ 711 \ / 712 \ Protocol steps to obtain access token or keying / 713 \ material for access to the temperature sensor and fan. / 714 \ / 715 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ 717 Read Sensor Data 718 (authenticated/authorized) 719 -------------------------------> 720 GET /3303/0/5700 722 CoAP 2.05 Content 723 <------------------------------- 724 22.5 C 726 Configure Actuator 727 (authenticated/authorized) 728 -------------------------------------------------> 729 PUT /fan?on-off=true 731 CoAP 2.04 Changed 732 <------------------------------------------------- 733 Figure 6: Local Discovery and Resouce Access. 735 5. The Ciphersuite Concept 737 TLS (and consequently DTLS) has the concept of ciphersuites and an 738 IANA registry [IANA-TLS] was created to register the suites. A 739 ciphersuite (and the specification that defines it) contains the 740 following information: 742 o Authentication and key exchange algorithm (e.g., PSK) 744 o Cipher and key length (e.g., Advanced Encryption Standard (AES) 745 with 128 bit keys [AES]) 747 o Mode of operation (e.g., Counter with Cipher Block Chaining - 748 Message Authentication Code (CBC-MAC) Mode (CCM) for AES) 749 [RFC3610] 751 o Hash algorithm for integrity protection, such as the Secure Hash 752 Algorithm (SHA) in combination with Keyed-Hashing for Message 753 Authentication (HMAC) (see [RFC2104] and [RFC4634]) 755 o Hash algorithm for use with pseudorandom functions (e.g., HMAC 756 with the SHA-256) 758 o Misc information (e.g., length of authentication tags) 760 o Information whether the ciphersuite is suitable for DTLS or only 761 for TLS 763 The TLS ciphersuite TLS_PSK_WITH_AES_128_CCM_8, for example, uses a 764 pre-shared authentication and key exchange algorithm. [RFC6655] 765 defines this ciphersuite. It uses the Advanced Encryption Standard 766 (AES) encryption algorithm, which is a block cipher. Since the AES 767 algorithm supports different key lengths (such as 128, 192 and 256 768 bits) this information has to be specified as well and the selected 769 ciphersuite supports 128 bit keys. A block cipher encrypts plaintext 770 in fixed-size blocks and AES operates on fixed block size of 128 771 bits. For messages exceeding 128 bits, the message is partitioned 772 into 128-bit blocks and the AES cipher is applied to these input 773 blocks with appropriate chaining, which is called mode of operation. 775 TLS 1.2 introduced Authenticated Encryption with Associated Data 776 (AEAD) ciphersuites (see [RFC5116] and [RFC6655]). AEAD is a class 777 of block cipher modes which encrypt (parts of) the message and 778 authenticate the message simultaneously. Examples of such modes 779 include the Counter with Cipher Block Chaining - Message 780 Authentication Code (CBC-MAC) Mode (CCM) mode, and the Galois/Counter 781 Mode (GCM) (see [RFC5288] and [RFC7251]). 783 Some AEAD ciphersuites have shorter authentication tags (i.e., 784 message authentication codes) and are therefore more suitable for 785 networks with low bandwidth where small message size matters. The 786 TLS_PSK_WITH_AES_128_CCM_8 ciphersuite that ends in "_8" has an 787 8-octet authentication tag, while the regular CCM ciphersuites have, 788 at the time of writing, 16-octet authentication tags. The design of 789 CCM and the security properties are described in [CCM]. 791 TLS 1.2 also replaced the combination of MD5/SHA-1 hash functions in 792 the TLS pseudo random function (PRF) used in earlier versions of TLS 793 with cipher-suite-specified PRFs. For this reason authors of more 794 recent TLS 1.2 ciphersuite specifications explicitly indicate the MAC 795 algorithm and the hash functions used with the TLS PRF. 797 6. Credential Types 799 The mandatory-to-implement functionality will depend on the 800 credential type used with IoT devices. The sub-sections below 801 describe the implications of three different credential types, namely 802 pre-shared secrets, raw public keys, and certificates. When using 803 pre-shared key, a critical consideration is how to assure the 804 randomness of these secrets. The best practice is to ensure that any 805 pre-shared key contains as much randomness as possible. Deriving a 806 shared secret from a password, name, or other low-entropy source is 807 not secure. A low-entropy secret, or password, is subject to 808 dictionary attacks. 810 6.1. Pre-Shared Secret 812 The use of pre-shared secrets is one of the most basic techniques for 813 TLS/DTLS since it is both computational efficient and bandwidth 814 conserving. Pre-shared secret based authentication was introduced to 815 TLS with RFC 4279 [RFC4279]. The exchange shown in Figure 7 816 illustrates the DTLS exchange including the cookie exchange. While 817 the server is not required to initiate a cookie exchange with every 818 handshake, the client is required to implement and to react on it 819 when challenged. The cookie exchange allows the server to react to 820 flooding attacks. 822 Client Server 823 ------ ------ 824 ClientHello --------> 826 <-------- HelloVerifyRequest 827 (contains cookie) 829 ClientHello --------> 830 (with cookie) 831 ServerHello 832 *ServerKeyExchange 833 <-------- ServerHelloDone 834 ClientKeyExchange 835 ChangeCipherSpec 836 Finished --------> 837 ChangeCipherSpec 838 <-------- Finished 840 Application Data <-------> Application Data 842 Legend: 844 * indicates an optional message payload 846 Figure 7: DTLS PSK Authentication including the Cookie Exchange. 848 [RFC4279] does not mandate the use of any particular type of client 849 identity and the client and server have to agree on the identities 850 and keys to be used. The mandated encoding of identities in 851 Section 5.1 of RFC 4279 aims to improve interoperability for those 852 cases where the identity is configured by a person using some 853 management interface. However, many IoT devices do not have a user 854 interface and most of their credentials are bound to the device 855 rather than the user. Furthermore, credentials are often provisioned 856 into trusted hardware modules or in the firmware by developers. As 857 such, the encoding considerations are not applicable to this usage 858 environment. For use with this profile the PSK identities SHOULD NOT 859 assume a structured format (as domain names, Distinguished Names, or 860 IP addresses have) and a bit-by-bit comparison operation can then be 861 used by the server-side infrastructure. 863 The client indicates which key it uses by including a "PSK identity" 864 in the ClientKeyExchange message. As described in Section 4 clients 865 may have multiple pre-shared keys with a single server, for example 866 in a hosting context. The TLS Server Name Indication (SNI) extension 867 allows the client to convey the name of the server it is contacting, 868 which is relevant for hosting environments. A server implementation 869 needs to guide the selection based on a received SNI value from the 870 client. 872 RFC 4279 requires TLS implementations supporting PSK ciphersuites to 873 support arbitrary PSK identities up to 128 octets in length, and 874 arbitrary PSKs up to 64 octets in length. This is a useful 875 assumption for TLS stacks used in the desktop and mobile environments 876 where management interfaces are used to provision identities and 877 keys. For the IoT environment, keys are distributed as part of 878 hardware modules or are embedded into the firmware. Implementations 879 in compliance with this profile MAY use PSK identities up to 128 880 octets in length, and arbitrary PSKs up to 64 octets in length. The 881 use of shorter PSK identities is RECOMMENDED. 883 Constrained Application Protocol (CoAP) [RFC7252] currently specifies 884 TLS_PSK_WITH_AES_128_CCM_8 as the mandatory to implement ciphersuite 885 for use with shared secrets. This ciphersuite uses the AES algorithm 886 with 128 bit keys and CCM as the mode of operation. The label "_8" 887 indicates that an 8-octet authentication tag is used. This 888 ciphersuite makes use of the default TLS 1.2 Pseudorandom Function 889 (PRF), which uses an HMAC with the SHA-256 hash function. Note: 890 Starting with TLS 1.2 (and consequently DTLS 1.2) ciphersuites have 891 to specify the pseudorandom function. RFC 5246 states that 'New 892 cipher suites MUST explicitly specify a PRF and, in general, SHOULD 893 use the TLS PRF with SHA-256 or a stronger standard hash function.'. 894 The ciphersuites recommended in this document use the SHA-256 895 construct defined in Section 5 of RFC 5246. 897 A device compliant with the profile in this section MUST implement 898 TLS_PSK_WITH_AES_128_CCM_8 and follow the guidance from this section. 900 6.2. Raw Public Key 902 The use of raw public keys with TLS/DTLS, as defined in [RFC7250], is 903 the first entry point into public key cryptography without having to 904 pay the price of certificates and a public key infrastructure (PKI). 905 The specification re-uses the existing Certificate message to convey 906 the raw public key encoded in the SubjectPublicKeyInfo structure. To 907 indicate support two new extensions had been defined, as shown in 908 Figure 8, namely the server_certificate_type*' and the 909 client_certificate_type. To operate this mechanism securely it is 910 necessary to authenticate and authorize the public keys out-of-band. 911 This key distribution step may, for example, be provided by a 912 dedicated protocol, such as the OMA LWM2M [LWM2M]. This document 913 therefore assumes that a client implementation comes with one or 914 multiple raw public keys of servers, it has to communicate with, pre- 915 provisioned. To replace, delete, or add raw public keys to this list 916 requires a software update, for example using a firmware update 917 mechanism. Additionally, a device will have its own raw public key 918 and the corresponding private key. This key pair may, for example, 919 be configured during the manufacturing process of the device. 921 Client Server 922 ------ ------ 924 ClientHello --------> 925 #client_certificate_type# 926 #server_certificate_type# 928 ServerHello 929 #client_certificate_type# 930 #server_certificate_type# 931 Certificate 932 ServerKeyExchange 933 CertificateRequest 934 <-------- ServerHelloDone 936 Certificate 937 ClientKeyExchange 938 CertificateVerify 939 [ChangeCipherSpec] 940 Finished --------> 942 [ChangeCipherSpec] 943 <-------- Finished 945 Note: Extensions marked with '#' were introduced with 946 RFC 7250. 948 Figure 8: DTLS Raw Public Key Exchange. 950 The CoAP recommended ciphersuite for use with this credential type is 951 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251]. This elliptic curve 952 cryptography (ECC) based AES-CCM TLS ciphersuite uses the Ephemeral 953 Elliptic Curve Diffie-Hellman (ECDHE) as the key establishment 954 mechanism and an Elliptic Curve Digital Signature Algorithm (ECDSA) 955 for authentication. Due to the use of Ephemeral Elliptic Curve 956 Diffie-Hellman (ECDHE) the recently introduced named Diffie-Hellman 957 groups [I-D.ietf-tls-negotiated-dl-dhe] are not applicable to this 958 profile. This ciphersuite makes use of the AEAD capability in DTLS 959 1.2 and utilizes an eight-octet authentication tag. The use of a 960 Diffie-Hellman key exchange provides perfect forward secrecy (PFS). 961 More details about PFS can be found in Section 11. 963 [RFC6090] provides valuable information for implementing Elliptic 964 Curve Cryptography algorithms, particularly for choosing methods that 965 have been available in the literature for a long time (i.e., 20 years 966 and more). 968 A device compliant with the profile in this section MUST implement 969 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this 970 section. 972 6.3. Certificates 974 The use of mutual certificate-based authentication is shown in 975 Figure 9, which makes use of the cached info extension 976 [I-D.ietf-tls-cached-info]. Support of the cached info extension is 977 REQUIRED. Caching certificate chains allows the client to reduce the 978 communication overhead significantly since otherwise the server would 979 provide the end entity certificate, and the certificate chain. 980 Because certificate validation requires that root keys be distributed 981 independently, the self-signed certificate that specifies the root 982 certificate authority is omitted from the chain. Client 983 implementations MUST be provisioned with a trust anchor store that 984 contains the root certificates. The use of the Trust Anchor 985 Management Protocol (TAMP) [RFC5934] is, however, not envisioned. 986 Instead IoT devices using this profile MUST use a software update 987 mechanism to populate the trust anchor store. 989 Client Server 990 ------ ------ 992 ClientHello --------> 993 *cached_info* 995 ServerHello 996 *cached_info* 997 Certificate 998 ServerKeyExchange 999 CertificateRequest 1000 <-------- ServerHelloDone 1002 Certificate 1003 ClientKeyExchange 1004 CertificateVerify 1005 [ChangeCipherSpec] 1006 Finished --------> 1008 [ChangeCipherSpec] 1009 <-------- Finished 1011 Note: Extensions marked with '*' were introduced with 1012 [I-D.ietf-tls-cached-info]. 1014 Figure 9: DTLS Mutual Certificate-based Authentication. 1016 Server certificates MUST contain the fully qualified DNS domain name 1017 or "FQDN" as dNSName [RFC5280]. For CoAP, the coaps URI scheme is 1018 described in Section 6.2 of [RFC7252]. This FQDN is stored in the 1019 SubjectAltName or in the leftmost CN component of subject name, as 1020 explained in Section 9.1.3.3 of [RFC7252], and used by the client to 1021 match it against the FQDN used during the look-up process, as 1022 described in [RFC6125]. For other protocols, the appropriate URI 1023 scheme specification has to be consulted. 1025 When constrained servers are used, for example in context of locally 1026 discoverable services as shown in Figure 6, then the rules of client 1027 certificates are applicable since these constrained servers are less 1028 likely to have an FQDN configured. Note that the Service Name 1029 Indication (SNI) extension cannot be used in this case since SNI does 1030 not offer the ability to convey EUI-64 [EUI64] identifiers. 1032 For client certificates the identifier used in the SubjectAltName or 1033 in the leftmost CN component of subject name MUST be an EUI-64, as 1034 mandated in Section 9.1.3.3 of [RFC7252]. 1036 For certificate revocation neither the Online Certificate Status 1037 Protocol (OCSP) nor Certificate Revocation Lists (CRLs) are used. 1038 Instead, this profile relies on a software update mechanism to 1039 provision information about revoked certificates. While multiple 1040 OCSP stapling [RFC6961] has recently been introduced as a mechanism 1041 to piggyback OCSP request/responses inside the DTLS/TLS handshake (to 1042 avoid the cost of a separate protocol handshake), further 1043 investigations are needed to determine its suitability for the IoT 1044 environment. 1046 Regarding the ciphersuite choice the discussion in Section 6.2 1047 applies. Further details about X.509 certificates can be found in 1048 Section 9.1.3.3 of [RFC7252]. The TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 1049 ciphersuite description in Section 6.2 is also applicable to this 1050 section. 1052 When using certificates, IoT devices MUST provide support for a 1053 server certificate chain of at least 3 not including the trust anchor 1054 and MAY reject connections from servers offering chains longer than 1055 3. IoT devices MAY have client certificate chains of any length. 1056 Obviously, longer chains require more digital signature verification 1057 operations to perform and lead to larger certificate messages in the 1058 TLS handshake. 1060 Table 1 provides a summary of the elements in a certificate for use 1061 with this profile. 1063 +----------------------+--------------------------------------------+ 1064 | Element | Notes | 1065 +----------------------+--------------------------------------------+ 1066 | version | This profile uses X.509 v3 certificates | 1067 | | [RFC5280]. | 1068 | | | 1069 | serialNumber | Positive integer unique per certificate. | 1070 | | | 1071 | signature | This field contains the signature | 1072 | | algorithm and this profile uses ecdsa- | 1073 | | with-SHA256 or stronger [RFC5758]. | 1074 | | | 1075 | issuer | Contains the DN of the issuing CA. | 1076 | | | 1077 | validity | Values expressed as UTC time in notBefore | 1078 | | and notAfter fields. No validity period | 1079 | | mandated. | 1080 | | | 1081 | subject | See rules outlined in this section. | 1082 | | | 1083 | subjectPublicKeyInfo | The SubjectPublicKeyInfo structure | 1084 | | indicates the algorithm and any associated | 1085 | | parameters for the ECC public key.This | 1086 | | profile uses the id-ecPublicKey algorithm | 1087 | | identifier for ECDSA signature keys, as | 1088 | | defined in specified in [RFC5480]. | 1089 | | | 1090 | signatureAlgorithm | The ECDSA signature algorithm with ecdsa- | 1091 | | with-SHA256 or stronger. | 1092 | | | 1093 | signatureValue | Bit string containing the digital | 1094 | | signature. | 1095 | | | 1096 | Extension: | See rules outlined in this section. | 1097 | subjectAltName | | 1098 | | | 1099 | Extension: | Indicates whether the subject of the | 1100 | BasicConstraints | certificate is a CA and the maximum depth | 1101 | | of valid certification paths that include | 1102 | | this certificate. This extension is used | 1103 | | for CA certs only and then the value of | 1104 | | the 'cA' field is set to TRUE. The default | 1105 | | is FALSE. | 1106 | | | 1107 | Extension: Key Usage | The KeyUsage field MAY have the following | 1108 | | values in the context of this profile: | 1109 | | digitalSignature or keyAgreement, | 1110 | | keyCertSign for verifying signatures on | 1111 | | public key certificates. | 1112 | | | 1113 | Extension: Extended | The ExtKeyUsageSyntax field MAY have the | 1114 | Key Usage | following values in context of this | 1115 | | profile: id-kp-serverAuth for server | 1116 | | authentication, id-kp-clientAuth for | 1117 | | client authentication, id-kp-codeSigning | 1118 | | for code signing (for software update | 1119 | | mechanism), id-kp-OCSPSigning for future | 1120 | | OCSP usage in TLS. | 1121 +----------------------+--------------------------------------------+ 1123 Table 1: Certificate Content. 1125 All certificate elements listed in Table 1 are mandatory-to- 1126 implement. No other certificate elements are used by this 1127 specification. 1129 A device compliant with the profile in this section MUST implement 1130 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this 1131 section. 1133 6.3.1. Client Certificate URLs 1135 RFC 6066 [RFC6066] allows to avoid sending client-side certificates 1136 and uses URLs instead. This reduces the over-the-air transmission. 1137 Note that the TLS cached info extension does not provide any help 1138 with caching client certificates. 1140 TLS/DTLS clients MUST implement support for client certificate URLs 1141 for those environments where client-side certificates are used and 1142 the server-side is not constrained. For constrained servers this 1143 functionality is NOT RECOMMENDED since it forces the server to 1144 execute an additional protocol exchange, potentially using a protocol 1145 it does not even support. The use of this extension also increases 1146 the risk of a denial of service attack against the constrained server 1147 due to the additional workload. 1149 6.3.2. Trusted CA Indication 1151 RFC 6066 [RFC6066] allows clients to indicate what trust anchor they 1152 support. With certificate-based authentication a DTLS server conveys 1153 its end entity certificate to the client during the DTLS exchange 1154 provides. Since the server does not necessarily know what trust 1155 anchors the client has stored and to facilitate certification path 1156 construction as well as path validation, it includes intermediate CA 1157 certs in the certificate payload. 1159 Today, in most IoT deployments there is a fairly static relationship 1160 between the IoT device (and the software running on them) and the 1161 server-side infrastructure. For these deployments where IoT devices 1162 interact with a fixed, pre-configured set of servers this extension 1163 is NOT RECOMMENDED. 1165 In cases where client interact with dynamically discovered TLS/DTLS 1166 servers, for example in the use cases described in Section 4.2, the 1167 use of this extension is RECOMMENDED. 1169 7. Signature Algorithm Extension 1171 The "signature_algorithms" extension, defined in Section 7.4.1.4.1 of 1172 RFC 5246 [RFC5246], allows the client to indicate to the server which 1173 signature/hash algorithm pairs may be used in digital signatures. 1174 The client MUST send this extension to select the use of SHA-256 1175 since otherwise absent this extension RFC 5246 defaults to SHA-1 / 1176 ECDSA for the ECDH_ECDSA and the ECDHE_ECDSA key exchange algorithms. 1178 The "signature_algorithms" extension is not applicable to the PSK- 1179 based ciphersuite described in Section 6.1. 1181 8. Error Handling 1183 TLS/DTLS uses the Alert protocol to convey errors and specifies a 1184 long list of error types. However, not all error messages defined in 1185 the TLS/DTLS specification are applicable to this profile. In 1186 general, there are two categories of errors (as defined in 1187 Section 7.2 of RFC 5246), namely fatal errors and warnings. Alert 1188 messages with a level of fatal result in the immediate termination of 1189 the connection. If possible, developers should try to develop 1190 strategies to react to those fatal errors, such as re-starting the 1191 handshake or informing the user using the (often limited) user 1192 interface. Warnings may be ignored by the application since many IoT 1193 devices will either have limited ways to log errors or no ability at 1194 all. In any case, implementers have to carefully evaluate the impact 1195 of errors and ways to remedy the situation since a commonly used 1196 approach for delegating decision making to users is difficult (or 1197 impossible) to accomplish in a timely fashion. 1199 All error messages marked as RESERVED are only supported for 1200 backwards compatibility with SSL MUST NOT be used with this profile. 1201 Those include decryption_failed_RESERVED, no_certificate_RESERVED, 1202 and export_restriction_RESERVED. 1204 A number of the error messages MUST only be used for certificate- 1205 based ciphersuites. Hence, the following error messages MUST NOT be 1206 used with with PSK and raw public key authentication: 1208 o bad_certificate, 1210 o unsupported_certificate, 1212 o certificate_revoked, 1214 o certificate_expired, 1216 o certificate_unknown, 1218 o unknown_ca, and 1220 o access_denied. 1222 Since this profile does not make use of compression at the TLS layer 1223 the decompression_failure error message MUST NOT be used either. 1225 RFC 4279 introduced a new alert message unknown_psk_identity for PSK 1226 ciphersuites. As stated in Section 2 of RFC 4279 the 1227 decryption_error error message may also be used instead. For this 1228 profile the TLS server MUST return the decryption_error error message 1229 instead of the unknown_psk_identity since the two mechanisms exist 1230 and provide the same functionality. 1232 Furthermore, the following errors should not occur with devices and 1233 servers supporting this specification but implementations MUST be 1234 prepared to process these errors to deal with servers that are not 1235 compliant to the profiles in this document: 1237 protocol_version: While this document focuses only on one version of 1238 the TLS/DTLS protocol, namely version 1.2, ongoing work on TLS/ 1239 DTLS 1.3 is in progress at the time of writing. 1241 insufficient_security: This error message indicates that the server 1242 requires ciphers to be more secure. This document specifies only 1243 one ciphersuite per profile but it is likely that additional 1244 ciphtersuites get added over time. 1246 user_canceled: Many IoT devices are unattended and hence this error 1247 message is unlikely to occur. 1249 9. Session Resumption 1251 Session resumption is a feature of the core TLS/DTLS specifications 1252 that allows a client to continue with an earlier established session 1253 state. The resulting exchange is shown in Figure 10. In addition, 1254 the server may choose not to do a cookie exchange when a session is 1255 resumed. Still, clients have to be prepared to do a cookie exchange 1256 with every handshake. The cookie exchange is not shown in the 1257 figure. 1259 Client Server 1260 ------ ------ 1262 ClientHello --------> 1263 ServerHello 1264 [ChangeCipherSpec] 1265 <-------- Finished 1266 [ChangeCipherSpec] 1267 Finished --------> 1268 Application Data <-------> Application Data 1270 Figure 10: DTLS Session Resumption. 1272 Constrained clients MUST implement session resumption to improve the 1273 performance of the handshake. This will lead to a reduced number of 1274 message exchanges, lower computational overhead (since only symmetric 1275 cryptography is used during a session resumption exchange), and 1276 session resumption requires less bandwidth. 1278 For cases where the server is constrained (but not the client) the 1279 client MUST implement RFC 5077 [RFC5077]. RFC 5077 specifies a 1280 version of TLS/DTLS session resumption that does not require per- 1281 session state information to be maintained by the constrained server. 1282 This is accomplished by using a ticket-based approach. 1284 If both the client and the server are constrained devices both 1285 devices SHOULD implement RFC 5077 and MUST implement basic session 1286 resumption. Clients that do not want to use session resumption are 1287 always able to send a ClientHello message with an empty session_id to 1288 revert to a full handshake. 1290 10. Compression 1292 Section 3.3 of [I-D.ietf-uta-tls-bcp] recommends to disable TLS/DTLS- 1293 level compression due to attacks, such as CRIME. For IoT 1294 applications compression at the TLS/DTLS layer is not needed since 1295 application layer protocols are highly optimized and the compression 1296 algorithms at the DTLS layer increases code size and complexity. 1298 This TLS/DTLS profile MUST NOT implement TLS/DTLS layer compression. 1300 11. Perfect Forward Secrecy 1302 Perfect forward secrecy (PFS) is a property that preserves the 1303 confidentiality of past conversations even in situations where the 1304 long-term secret is compromised. 1306 The PSK ciphersuite recommended in Section 6.1 does not offer this 1307 property since it does not utilize a Diffie-Hellman exchange. New 1308 ciphersuites that support PFS for PSK-based authentication, such as 1309 proposed in [I-D.schmertmann-dice-ccm-psk-pfs], might become 1310 available as standardized ciphersuite in the (near) future. The 1311 recommended PSK-based ciphersuite offers excellent performance, a 1312 very small memory footprint, and has the lowest on the wire overhead 1313 at the expense of not using any public cryptography. For deployments 1314 where public key cryptography is acceptable the raw public might 1315 offer an acceptable middleground between the PSK ciphersuite in terms 1316 of out-of-band validation and the functionality offered by asymmetric 1317 cryptography. 1319 The use of PFS is a trade-off decision since on one hand the 1320 compromise of long-term secrets of embedded devices is more likely 1321 than with many other Internet hosts but on the other hand a Diffie- 1322 Hellman exchange requires ephemeral key pairs to be generated, which 1323 is demanding from a performance point of view. For obvious 1324 performance improvement, some implementations re-use key pairs over 1325 multiple exchanges (rather than generating new keys for each 1326 exchange). However, note that such key re-use over long periods 1327 voids the benefits of forward secrecy when an attack gains access to 1328 this DH key pair. 1330 The impact of the disclosure of past conversations and the desire to 1331 increase the cost for pervasive monitoring (as demanded by [RFC7258]) 1332 has to be taken into account when making a deployment decision. 1334 Client implementations claiming support of this profile MUST 1335 implement the ciphersuites listed in Section 6 according to the 1336 selected credential type. 1338 12. Keep-Alive 1340 Application layer communication may create state at the endpoints and 1341 this state my expire at some time. For this reason, applications 1342 define ways to refresh state, if necessary. While the application 1343 layer exchanges are largely outside the scope of the underlying TLS/ 1344 DTLS exchange similar state considerations also play a role at the 1345 level of TLS/DTLS. While TLS/DTLS also creates state in form of a 1346 security context (see the security parameter described in Appendix A6 1347 in RFC 5246) at the client and the server this state information does 1348 not expire. However, network intermediaries may also allocate state 1349 and require this state to be kept alive. Failure to keep state alive 1350 at a stateful packet filtering firewall or at a NAT may result in the 1351 inability for one node to reach the other since packets will get 1352 blocked by these middleboxes. Periodic keep-alive messages exchanged 1353 between the TLS/DTLS client and server keep state at these 1354 middleboxes alive. According to measurements described in 1355 [HomeGateway] there is some variance in state management practices 1356 used in residential gateways but the timeouts are heavily impacted by 1357 the choice of the transport layer protocol: timeouts for UDP are 1358 typically much shorter than those for TCP. 1360 RFC 6520 [RFC6520] defines a heartbeat mechanism to test whether the 1361 other peer is still alive. As an additional feature, the same 1362 mechanism can also be used to perform Path Maximum Transmission Unit 1363 (MTU) Discovery. 1365 A recommendation about the use of RFC 6520 depends on the type of 1366 message exchange an IoT device performs and the number of messages 1367 the application needs to exchange as part of their application 1368 functionality. There are three types of exchanges that need to be 1369 analysed: 1371 Client-Initiated, One-Shot Messages 1373 This is a common communication pattern where IoT devices upload 1374 data to a server on the Internet on an irregular basis. The 1375 communication may be triggered by specific events, such as opening 1376 a door. 1378 Since the upload happens on an irregular and unpredictable basis 1379 and due to renumbering and Network Address Translation (NAT) the 1380 DTLS handshake may need to be re-started (ideally using session 1381 resumption, if possible). 1383 In this case there is no use for a keep-alive extension for this 1384 scenario. 1386 Client-Initiated, Regular Data Uploads 1388 This is a variation of the previous case whereby data gets 1389 uploaded on a regular basis, for example, based on frequent 1390 temperature readings. If neither NAT bindings nor IP address 1391 changes occurred then the record layer will not notice any 1392 changes. For the case where the IP address and port number 1393 changes, it is necessary to re-create the record layer using 1394 session resumption. 1396 In this scenario there is no use for a keep-alive extension. It 1397 is also very likely that the device will enter a sleep cycle in 1398 between data transmissions to keep power consumption low. 1400 Server-Initiated Messages 1402 In the two previous scenarios the client initiated the protocol 1403 interaction and maintains it. Since messages to the client may 1404 get blocked by middleboxes the initial connection setup is 1405 triggered by the client and then kept alive by the server. 1407 For this message exchange pattern the use of DTLS heartbeat 1408 messages is quite useful but may have to be coordinated with 1409 application exchanges (for example when the CoAP resource 1410 directory is used) to avoid redundant keep-alive message 1411 exchanges. The MTU discovery mechanism, which is also part of 1412 [RFC6520], is less likely to be relevant since for many IoT 1413 deployments the most constrained link is the wireless interface 1414 between the IoT device and the network itself (rather than some 1415 links along the end-to-end path). Only in more complex network 1416 topologies, such as multi-hop mesh networks, path MTU discovery 1417 might be appropriate. It also has to be noted that DTLS itself 1418 already provides a basic path discovery mechanism (see 1419 Section 4.1.1.1 of RFC 6347 by using the fragmentation capability 1420 of the handshake protocol). 1422 For server-initiated messages the heartbeat extension is RECOMMENDED. 1424 13. Timeouts 1426 To connect to the Internet a variety of wired and wireless 1427 technologies are available. Many of the low power radio 1428 technologies, such as IEEE 802.15.4 or Bluetooth Smart, only support 1429 small frame sizes (e.g., 127 bytes in case of IEEE 802.15.4 as 1430 explained in RFC 4919 [RFC4919]). Other radio technologies, such as 1431 the Global System for Mobile Communications (GSM) using the short 1432 messaging service (SMS) have similar constraints in terms of payload 1433 sizes, such as 140 bytes without the optional segmentation and 1434 reassembly scheme known as Concatenated SMS, but show higher latency. 1436 The DTLS handshake protocol adds a fragmentation and reassembly 1437 mechanism to the TLS handshake protocol since each DTLS record must 1438 fit within a single transport layer datagram, as described in 1439 Section 4.2.3 of [RFC6347]. Since handshake messages are potentially 1440 bigger than the maximum record size, the mechanism fragments a 1441 handshake message over a number of DTLS records, each of which can be 1442 transmitted separately. 1444 To deal with the unreliable message delivery provided by UDP, DTLS 1445 adds timeouts and re-transmissions, as described in Section 4.2.4 of 1446 [RFC6347]. Although the timeout values are implementation specific, 1447 recommendations are provided in Section 4.2.4.1 of [RFC6347], with an 1448 initial timer value of 1 second and doubled with at each 1449 retransmission up to no less than 60 seconds. Due to the nature of 1450 some radio technologies, these values are too aggressive and lead to 1451 spurious failures when messages in flight need longer. 1453 Note: If a round-trip time estimator (such as proposed in 1454 [I-D.bormann-core-cocoa]) is available in the protocol stack of the 1455 device, it could be used to dynamically update the setting of the 1456 retransmit timeout. 1458 Choosing appropriate timeout values is difficult with changing 1459 network conditions, and large variance in latency. This 1460 specification therefore RECOMMENDS an initial timer value of 10 1461 seconds with exponential back off up to no less then 60 seconds. 1462 Appendix A provides additional normative text for carrying DTLS over 1463 SMS. 1465 14. Random Number Generation 1467 The TLS/DTLS protocol requires random numbers to be available during 1468 the protocol run. For example, during the ClientHello and the 1469 ServerHello exchange the client and the server exchange random 1470 numbers. Also, the use of the Diffie-Hellman exchange requires 1471 random numbers during the key pair generation. Special care has to 1472 be taken when generating random numbers in embedded systems as many 1473 entropy sources available on desktop operating systems or mobile 1474 devices might be missing, as described in [Heninger]. Consequently, 1475 if not enough time is given during system start time to fill the 1476 entropy pool then the output might be predictable and repeatable, for 1477 example leading to the same keys generated again and again. 1479 It is important to note that sources contributing to the randomness 1480 pool on laptops, or desktop PCs are not available on many IoT device, 1481 such as mouse movement, timing of keystrokes, air turbulence on the 1482 movement of hard drive heads, etc. Other sources have to be found or 1483 dedicated hardware has to be added. 1485 The ClientHello and the ServerHello messages contains the 'Random' 1486 structure, which has two components: gmt_unix_time and a sequence of 1487 28 random bytes. gmt_unix_time holds the current time and date in 1488 standard UNIX 32-bit format (seconds since the midnight starting Jan 1489 1, 1970, GMT). [I-D.mathewson-no-gmtunixtime] argues that the entire 1490 ClientHello.Random value (including gmt_unix_time) should be a 1491 sequence of random bits because of device fingerprinting privacy 1492 concerns. Since many IoT devices do not have access to an accurate 1493 clock, it is RECOMMENDED to follow the guidance outlined in 1494 [I-D.mathewson-no-gmtunixtime] regarding the content of the 1495 ClientHello.Random field. However, for the ServerHello.Random 1496 structure it is RECOMMENDED to maintain the existing structure with 1497 gmt_unix_time followed by a sequence of 28 random bytes since the 1498 client can use the received time information to securely obtain time 1499 information. For constrained servers it cannot be assumed that they 1500 maintain accurate time information; these devices MUST include time 1501 information in the Server.Random structure when they actually obtain 1502 accurate time information that can be utilized by clients. Clients 1503 MUST only use time information obtained from servers they trust and 1504 the use of this approach has to be agreed out-of-band. 1506 IoT devices using TLS/DTLS MUST offer ways to generate quality random 1507 numbers using hardware-based random number generators. Note that 1508 these hardware-based random number generators do not necessarily need 1509 to be implemented inside the microcontroller itself but could be made 1510 available in dedicated crypto-chips as well. Guidelines and 1511 requirements for random number generation can be found in RFC 4086 1512 [RFC4086] and in the NIST Special Publication 800-90a [SP800-90A]. 1514 Chip manufacturers are highly encouraged to provide sufficient 1515 documentation of their design for random number generators so that 1516 customers can have confidence about the quality of the generated 1517 random numbers. The confidence can be increased by providing 1518 information about the procedures that have been used to verify the 1519 randomness of numbers generated by the hardware modules. For 1520 example, NIST Special Publication 800-22b [SP800-22b] describes 1521 statistical tests that can be used to verify random random number 1522 generators. 1524 15. Truncated MAC and Encrypt-then-MAC Extension 1526 The truncated MAC extension was introduced with RFC 6066 [RFC6066] 1527 with the goal to reduce the size of the MAC used at the Record Layer. 1528 This extension was developed for TLS ciphersuites that used older 1529 modes of operation where the MAC and the encryption operation was 1530 performed independently. 1532 The recommended ciphersuites in this document use the newer 1533 Authenticated Encryption with Associated Data (AEAD) construct, 1534 namely the CBC-MAC mode (CCM) with eight-octet authentication tags, 1535 and are therefore not appliable to the truncated MAC extension. 1537 RFC 7366 [RFC7366] introduced the encrypt-then-MAC extension (instead 1538 of the previously used MAC-then-encrypt) since the MAC-then-encrypt 1539 mechanism has been the subject of a number of security 1540 vulnerabilities. RFC 7366 is, however, also not applicable to the 1541 AEAD ciphers recommended in this document. 1543 Implementations conformant to this specification MUST use AEAD 1544 ciphers. Hence, RFC 7366 and RFC 6066 are not applicable to this 1545 specifciation and MUST NOT be implemented. 1547 16. Server Name Indication (SNI) 1549 The Server Name Indication extension defined in [RFC6066] defines a 1550 mechanism for a client to tell a TLS/DTLS server the name of the 1551 server it wants to contact. This is a useful extension for many 1552 hosting environments where multiple virtual servers are run on single 1553 IP address. 1555 This specification RECOMMENDs the implementation of the Server Name 1556 Indication extension unless it is known that a TLS/DTLS client does 1557 not interact with a server in a hosting environment. 1559 17. Maximum Fragment Length Negotiation 1561 This RFC 6066 extension lowers the maximum fragment length support 1562 needed for the Record Layer from 2^14 bytes to 2^9 bytes. 1564 This is a very useful extension that allows the client to indicate to 1565 the server how much maximum memory buffers it uses for incoming 1566 messages. Ultimately, the main benefit of this extension is to allow 1567 client implementations to lower their RAM requirements since the 1568 client does not need to accept packets of large size (such as 16k 1569 packets as required by plain TLS/DTLS). 1571 Client implementations MUST support this extension. 1573 18. Session Hash 1575 In order to begin connection protection, the Record Protocol requires 1576 specification of a suite of algorithms, a master secret, and the 1577 client and server random values. The algorithm for computing the 1578 master secret is defined in Section 8.1 of RFC 5246 but only includes 1579 a small number of parameters exchanged during the handshake and does 1580 not include parameters like the client and server identities. This 1581 can be utilized by an attacker to mount a man-in-the-middle attack 1582 since the master secret is not guaranteed to be unique across 1583 sessions, as discovered in the 'Triple Handshake' attack [Triple-HS]. 1585 [I-D.ietf-tls-session-hash] defines a TLS extension that binds the 1586 master secret to a log of the full handshake that computes it, thus 1587 preventing such attacks. 1589 Client implementations SHOULD implement this extension even though 1590 the ciphersuites recommended by this profile are not vulnerable to 1591 this attack. For Diffie-Hellman-based ciphersuites the keying 1592 material is contributed by both parties and in case of the pre-shared 1593 secret key ciphersuite, both parties need to be in possession of the 1594 shared secret to ensure that the handshake completes successfully. 1595 It is, however, possible that some application layer protocols will 1596 tunnel other authentication protocols on top of DTLS making this 1597 attack relevant again. 1599 19. Re-Negotiation Attacks 1601 TLS/DTLS allows a client and a server who already have a TLS/DTLS 1602 connection to negotiate new parameters, generate new keys, etc by 1603 using the re-negotiation feature. Renegotiation happens in the 1604 existing connection, with the new handshake packets being encrypted 1605 along with application data. Upon completion of the re-negotiation 1606 procedure the new channel replaces the old channel. 1608 As described in RFC 5746 [RFC5746] there is no cryptographic binding 1609 between the two handshakes, although the new handshake is carried out 1610 using the cryptographic parameters established by the original 1611 handshake. 1613 To prevent the re-negotiation attack [RFC5746] this specification 1614 RECOMMENDS to disable the TLS renegotigation feature. Clients MUST 1615 respond to server-initiated re-negotiation attempts with an alert 1616 message (no_renegotiation) and clients MUST NOT initiate them. 1618 20. Downgrading Attacks 1620 When a client sends a ClientHello with a version higher than the 1621 highest version known to the server, the server is supposed to reply 1622 with ServerHello.version equal to the highest version known to the 1623 server and the handshake can proceed. This behaviour is known as 1624 version tolerance. Version-intolerance is when the server (or a 1625 middlebox) breaks the handshake when it sees a ClientHello.version 1626 higher than what it knows about. This is the behaviour that leads 1627 some clients to re-run the handshake with lower version. As a 1628 result, a potential security vulnerability is introduced when a 1629 system is running an old TLS/SSL version (e.g., because of the need 1630 to integrate with legacy systems). In the worst case, this allows an 1631 attacker to downgrade the protocol handshake to SSL 3.0. SSL 3.0 is 1632 so broken that there is no secure cipher available for it (see 1633 [I-D.ietf-tls-sslv3-diediedie]). 1635 The above-described downgrade vulnerability is solved by the TLS 1636 Fallback Signaling Cipher Suite Value (SCSV) 1637 [I-D.ietf-tls-downgrade-scsv] extension. However, the solution is 1638 not appliable to implementations conforming to this profile since the 1639 version negotiation MUST use TLS/DTLS version 1.2 (or higher). More 1640 specifically, this implies: 1642 o Clients MUST NOT send a TLS/DTLS version lower than version 1.2 in 1643 the ClientHello. 1645 o Clients MUST NOT retry a failed negotiation offering a TLS/DTLS 1646 version lower than 1.2. 1648 o Servers MUST fail the handshake by sending a protocol_version 1649 fatal alert if a TLS/DTLS version >= 1.2 cannot be negotiated. 1650 Note that the aborted connection is non-resumable. 1652 If at some time in the future this profile reaches the quality of SSL 1653 3.0 a software update is needed since constrained devices are 1654 unlikely to run multiple TLS/DTLS versions due to memory size 1655 restrictions. 1657 21. Crypto Agility 1659 This document recommends software and chip manufacturers to implement 1660 AES and the CCM mode of operation. This document references the CoAP 1661 recommended ciphersuite choices, which have been selected based on 1662 implementation and deployment experience from the IoT community. 1663 Over time the preference for algorithms will, however, change. Not 1664 all components of a ciphersuite are likely to change at the same 1665 speed. Changes are more likely expected for ciphers, the mode of 1666 operation, and the hash algorithms. The recommended key lengths have 1667 to be adjusted over time. Some deployment environments will also be 1668 impacted by local regulation, which might dictate a certain cipher 1669 and key size. Ongoing discussions regarding the choice of specific 1670 ECC curves will also likely impact implementations. Note that this 1671 document does not recommend or mandate a specific ECC curve. 1673 The following recommendations can be made to chip manufacturers: 1675 o Make any AES hardware-based crypto implementation accessible to 1676 developers working on security implementations at higher layers. 1677 Sometimes hardware implementatios are added to microcontrollers to 1678 offer support for functionality needed at the link layer and are 1679 only available to the on-chip link layer protocol implementation. 1681 o Provide flexibility for the use of the crypto function with future 1682 extensibility in mind. For example, making an AES-CCM 1683 implementation available to developers is a first step but such an 1684 implementation may not be usable due to parameter differences 1685 between an AES-CCM implementations. AES-CCM in IEEE 802.15.4 and 1686 Bluetooth Smart uses a nonce length of 13-octets while DTLS uses a 1687 nonce length of 12-octets. Hardware implementations of AES-CCM 1688 for IEEE 802.15.4 and Bluetooth Smart are therefore not re-usable 1689 by a DTLS stack. 1691 o Offer access to building blocks in addition (or as an alternative) 1692 to the complete functionality. For example, a chip manufacturer 1693 who gives developers access to the AES crypto function can use it 1694 to build an efficient AES-GCM implementations. Another example is 1695 to make a special instruction available that increases the speed 1696 of speed-up carryless multiplications. 1698 As a recommendation for developers and product architects we 1699 recommend that sufficient headroom is provided to allow an upgrade to 1700 a newer cryptographic algorithms over the lifetime of the product. 1701 As an example, while AES-CCM is recommended thoughout this 1702 specification future products might use the ChaCha20 cipher in 1703 combination with the Poly1305 authenticator 1705 [I-D.irtf-cfrg-chacha20-poly1305]. The assumption is made that a 1706 robust software update mechanism is offered. 1708 22. Key Length Recommendations 1710 RFC 4492 [RFC4492] gives approximate comparable key sizes for 1711 symmetric- and asymmetric-key cryptosystems based on the best-known 1712 algorithms for attacking them. While other publications suggest 1713 slightly different numbers, such as [Keylength], the approximate 1714 relationship still holds true. Figure 11 illustrates the comparable 1715 key sizes in bits. 1717 At the time of writing the key size recommendations for use with TLS- 1718 based ciphers found in [I-D.ietf-uta-tls-bcp] recommend DH key 1719 lengths of at least 2048 bit, which corresponds to a 112-bit 1720 symmetric key and a 233 bit ECC key. These recommendations are 1721 inline with those from other organizations, such as National 1722 Institute of Standards and Technology (NIST) or European Network and 1723 Information Security Agency (ENISA). The authors of 1724 [ENISA-Report2013] add that a 80-bit symmetric key is sufficient for 1725 legacy applications for the coming years, but a 128-bit symmetric key 1726 is the minimum requirement for new systems being deployed. The 1727 authors further note that one needs to also take into account the 1728 length of time data needs to be kept secure for. The use of 80-bit 1729 symmetric keys for transactional data may be acceptable for the near 1730 future while one has to insist on 128-bit symmetric keys for long 1731 lived data. 1733 Symmetric | ECC | DH/DSA/RSA 1734 ------------+---------+------------- 1735 80 | 163 | 1024 1736 112 | 233 | 2048 1737 128 | 283 | 3072 1738 192 | 409 | 7680 1739 256 | 571 | 15360 1741 Figure 11: Comparable Key Sizes (in bits). 1743 23. False Start 1745 A full TLS handshake as specified in [RFC5246] requires two full 1746 protocol rounds (four flights) before the handshake is complete and 1747 the protocol parties may begin to send application data. 1749 An abbreviated handshake (resuming an earlier TLS session) is 1750 complete after three flights, thus adding just one round-trip time if 1751 the client sends application data first. 1753 If the conditions outlined in [I-D.bmoeller-tls-falsestart] are met, 1754 application data can be transmitted when the sender has sent its own 1755 "ChangeCipherSpec" and "Finished" messages. This achieves an 1756 improvement of one round-trip time for full handshakes if the client 1757 sends application data first, and for abbreviated handshakes if the 1758 server sends application data first. 1760 The conditions for using the TLS False Start mechanism are met by the 1761 public-key-based ciphersuites in this document. In summary, the 1762 conditions are 1764 o Modern symmetric ciphers with an effective key length of 128 bits, 1765 such as AES-128-CCM 1767 o Client certificate types, such as ecdsa_sign 1769 o Key exchange methods, such as ECDHE_ECDSA 1771 Based on the improvement over a full roundtrip for the full TLS/DTLS 1772 exchange this specification RECOMMENDS the use of the False Start 1773 mechanism when clients send application data first. 1775 24. Privacy Considerations 1777 The DTLS handshake exchange conveys various identifiers, which can be 1778 observed by an on-path eavesdropper. For example, the DTLS PSK 1779 exchange reveals the PSK identity, the supported extensions, the 1780 session id, algorithm parameters, etc. When session resumption is 1781 used then individual TLS sessions can be correlated by an on-path 1782 adversary. With many IoT deployments it is likely that keying 1783 material and their identifiers are persistent over a longer period of 1784 time due to the cost of updating software on these devices. 1786 User participation with many IoT deployments poses a challenge since 1787 many of the IoT devices operate unattended, even though they will 1788 initially be provisioned by a human. The ability to control data 1789 sharing and to configure preference will have to be provided at a 1790 system level rather than at the level of the DTLS exchange itself, 1791 which is the scope of this document. Quite naturally, the use of 1792 DTLS with mutual authentication will allow a TLS server to collect 1793 authentication information about the IoT device (likely over a long 1794 period of time). While this strong form of authentication will 1795 prevent mis-attribution, it also allows strong identification. 1796 Device-related data collection (e.g., sensor recordings) associated 1797 with other data type will prove to be truly useful but this extra 1798 data might include personal information about the owner of the device 1799 or data about the environment it senses. Consequently, the data 1800 stored on the server-side will be vulnerable to stored data 1801 compromise. For the communication between the client and the server 1802 this specification prevents eavesdroppers to gain access to the 1803 communication content. While the PSK-based ciphersuite does not 1804 provide PFS the asymmetric versions do. This prevents an adversary 1805 from obtaining past communication content when access to a long-term 1806 secret has been gained. Note that no extra effort to make traffic 1807 analysis more difficult is provided by the recommendations made in 1808 this document. 1810 25. Security Considerations 1812 This entire document is about security. 1814 We would also like to point out that designing a software update 1815 mechanism into an IoT system is crucial to ensure that both 1816 functionality can be enhanced and that potential vulnerabilities can 1817 be fixed. This software update mechanism is important for changing 1818 configuration information, for example, trust anchors and other 1819 keying related information. Such a suitable software update 1820 mechanism is available with the Lightweight Machine-to-Machine 1821 (LWM2M) protocol published by the Open Mobile Alliance (OMA) [LWM2M]. 1823 26. IANA Considerations 1825 This document includes no request to IANA. 1827 27. Acknowledgements 1829 Thanks to Olaf Bergmann, Paul Bakker, Robert Cragie, Russ Housley, 1830 Rene Hummen, Matthias Kovatsch, Sandeep Kumar, Sye Loong Keoh, Simon 1831 Lemay, Alexey Melnikov, Manuel Pegourie-Gonnard, Akbar Rahman, Eric 1832 Rescorla, Michael Richardson, Ludwig Seitz, Zach Shelby, Michael 1833 StJohns, Rene Struik, and Sean Turner for their helpful comments and 1834 discussions that have shaped the document. 1836 Big thanks also to Klaus Hartke, who wrote the initial version of 1837 this document. 1839 Finally, we would like to thank our area director (Stephen Farrell) 1840 and our working group chairs (Zach Shelby and Dorothy Gellert) for 1841 their support. 1843 28. References 1845 28.1. Normative References 1847 [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 1848 REGISTRATION AUTHORITY", April 2010, 1849 . 1852 [GSM-SMS] ETSI, "3GPP TS 23.040 V7.0.1 (2007-03): 3rd Generation 1853 Partnership Project; Technical Specification Group Core 1854 Network and Terminals; Technical realization of the Short 1855 Message Service (SMS) (Release 7)", March 2007. 1857 [I-D.ietf-tls-cached-info] 1858 Santesson, S. and H. Tschofenig, "Transport Layer Security 1859 (TLS) Cached Information Extension", draft-ietf-tls- 1860 cached-info-17 (work in progress), November 2014. 1862 [I-D.ietf-tls-session-hash] 1863 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 1864 A., and M. Ray, "Transport Layer Security (TLS) Session 1865 Hash and Extended Master Secret Extension", draft-ietf- 1866 tls-session-hash-03 (work in progress), November 2014. 1868 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1869 Requirement Levels", BCP 14, RFC 2119, March 1997. 1871 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 1872 for Transport Layer Security (TLS)", RFC 4279, December 1873 2005. 1875 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1876 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1878 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 1879 "Transport Layer Security (TLS) Renegotiation Indication 1880 Extension", RFC 5746, February 2010. 1882 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1883 Extension Definitions", RFC 6066, January 2011. 1885 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1886 Verification of Domain-Based Application Service Identity 1887 within Internet Public Key Infrastructure Using X.509 1888 (PKIX) Certificates in the Context of Transport Layer 1889 Security (TLS)", RFC 6125, March 2011. 1891 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1892 Security Version 1.2", RFC 6347, January 2012. 1894 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 1895 Layer Security (TLS) and Datagram Transport Layer Security 1896 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 1898 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 1899 T. Kivinen, "Using Raw Public Keys in Transport Layer 1900 Security (TLS) and Datagram Transport Layer Security 1901 (DTLS)", RFC 7250, June 2014. 1903 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 1904 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 1905 TLS", RFC 7251, June 2014. 1907 [WAP-WDP] Wireless Application Protocol Forum, "Wireless Datagram 1908 Protocol", June 2001. 1910 28.2. Informative References 1912 [ACE-WG] IETF, "Authentication and Authorization for Constrained 1913 Environments (ace) Working Group", URL: 1914 https://datatracker.ietf.org/wg/ace/charter/, Jan 2015. 1916 [AES] National Institute of Standards and Technology, "FIPS PUB 1917 197, Advanced Encryption Standard (AES)", 1918 http://www.iana.org/assignments/tls-parameters/ 1919 tls-parameters.xhtml#tls-parameters-4, November 2001. 1921 [CCM] National Institute of Standards and Technology, "Special 1922 Publication 800-38C, Recommendation for Block Cipher Modes 1923 of Operation: The CCM Mode for Authentication and 1924 Confidentiality", http://csrc.nist.gov/publications/ 1925 nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf, May 1926 2004. 1928 [ENISA-Report2013] 1929 ENISA, "Algorithms, Key Sizes and Parameters Report - 1930 2013", http://www.enisa.europa.eu/activities/identity-and- 1931 trust/library/deliverables/ 1932 algorithms-key-sizes-and-parameters-report, October 2013. 1934 [Heninger] 1935 Heninger, N., Durumeric, Z., Wustrow, E., and A. 1936 Halderman, "Mining Your Ps and Qs: Detection of Widespread 1937 Weak Keys in Network Devices", 21st USENIX Security 1938 Symposium, 1939 https://www.usenix.org/conference/usenixsecurity12/ 1940 technical-sessions/presentation/heninger, 2012. 1942 [HomeGateway] 1943 Eggert, L., "An experimental study of home gateway 1944 characteristics, In Proceedings of the '10th annual 1945 conference on Internet measurement'", 2010. 1947 [I-D.bmoeller-tls-falsestart] 1948 Langley, A., Modadugu, N., and B. Moeller, "Transport 1949 Layer Security (TLS) False Start", draft-bmoeller-tls- 1950 falsestart-01 (work in progress), November 2014. 1952 [I-D.bormann-core-cocoa] 1953 Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, 1954 "CoAP Simple Congestion Control/Advanced", draft-bormann- 1955 core-cocoa-02 (work in progress), July 2014. 1957 [I-D.iab-smart-object-architecture] 1958 Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 1959 "Architectural Considerations in Smart Object Networking", 1960 draft-iab-smart-object-architecture-06 (work in progress), 1961 October 2014. 1963 [I-D.ietf-core-resource-directory] 1964 Shelby, Z. and C. Bormann, "CoRE Resource Directory", 1965 draft-ietf-core-resource-directory-02 (work in progress), 1966 November 2014. 1968 [I-D.ietf-lwig-tls-minimal] 1969 Kumar, S., Keoh, S., and H. Tschofenig, "A Hitchhiker's 1970 Guide to the (Datagram) Transport Layer Security Protocol 1971 for Smart Objects and Constrained Node Networks", draft- 1972 ietf-lwig-tls-minimal-01 (work in progress), March 2014. 1974 [I-D.ietf-tls-downgrade-scsv] 1975 Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 1976 Suite Value (SCSV) for Preventing Protocol Downgrade 1977 Attacks", draft-ietf-tls-downgrade-scsv-05 (work in 1978 progress), February 2015. 1980 [I-D.ietf-tls-negotiated-dl-dhe] 1981 Gillmor, D., "Negotiated Discrete Log Diffie-Hellman 1982 Ephemeral Parameters for TLS", draft-ietf-tls-negotiated- 1983 dl-dhe-00 (work in progress), July 2014. 1985 [I-D.ietf-tls-prohibiting-rc4] 1986 Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf- 1987 tls-prohibiting-rc4-01 (work in progress), October 2014. 1989 [I-D.ietf-tls-sslv3-diediedie] 1990 Barnes, R., Thomson, M., Pironti, A., and A. Langley, 1991 "Deprecating Secure Sockets Layer Version 3.0", draft- 1992 ietf-tls-sslv3-diediedie-02 (work in progress), March 1993 2015. 1995 [I-D.ietf-uta-tls-bcp] 1996 Sheffer, Y., Holz, R., and P. Saint-Andre, 1997 "Recommendations for Secure Use of TLS and DTLS", draft- 1998 ietf-uta-tls-bcp-11 (work in progress), February 2015. 2000 [I-D.irtf-cfrg-chacha20-poly1305] 2001 Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 2002 protocols", draft-irtf-cfrg-chacha20-poly1305-10 (work in 2003 progress), February 2015. 2005 [I-D.mathewson-no-gmtunixtime] 2006 Mathewson, N. and B. Laurie, "Deprecating gmt_unix_time in 2007 TLS", draft-mathewson-no-gmtunixtime-00 (work in 2008 progress), December 2013. 2010 [I-D.schmertmann-dice-ccm-psk-pfs] 2011 Schmertmann, L. and C. Bormann, "ECDHE-PSK AES-CCM Cipher 2012 Suites with Forward Secrecy for Transport Layer Security 2013 (TLS)", draft-schmertmann-dice-ccm-psk-pfs-01 (work in 2014 progress), August 2014. 2016 [IANA-TLS] 2017 IANA, "TLS Cipher Suite Registry", 2018 http://www.iana.org/assignments/tls-parameters/ 2019 tls-parameters.xhtml#tls-parameters-4, 2014. 2021 [ImprintingSurvey] 2022 Chilton, E., "A Brief Survey of Imprinting Options for 2023 Constrained Devices", URL: http://www.lix.polytechnique.fr 2024 /hipercom/SmartObjectSecurity/papers/EricRescorla.pdf, 2025 March 2012. 2027 [Keylength] 2028 Giry, D., "Cryptographic Key Length Recommendations", 2029 http://www.keylength.com, November 2014. 2031 [LWM2M] Open Mobile Alliance, "Lightweight Machine-to-Machine, 2032 Technical Specification, Candidate Version 1.0", December 2033 2013. 2035 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2036 November 1990. 2038 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 2039 for IP version 6", RFC 1981, August 1996. 2041 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2042 Hashing for Message Authentication", RFC 2104, February 2043 1997. 2045 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2046 "Remote Authentication Dial In User Service (RADIUS)", RFC 2047 2865, June 2000. 2049 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 2050 CBC-MAC (CCM)", RFC 3610, September 2003. 2052 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2053 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 2054 3748, June 2004. 2056 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 2057 Requirements for Security", BCP 106, RFC 4086, June 2005. 2059 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 2060 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 2061 for Transport Layer Security (TLS)", RFC 4492, May 2006. 2063 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 2064 (SHA and HMAC-SHA)", RFC 4634, July 2006. 2066 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 2067 over Low-Power Wireless Personal Area Networks (6LoWPANs): 2068 Overview, Assumptions, Problem Statement, and Goals", RFC 2069 4919, August 2007. 2071 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 2072 "Transport Layer Security (TLS) Session Resumption without 2073 Server-Side State", RFC 5077, January 2008. 2075 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 2076 Encryption", RFC 5116, January 2008. 2078 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 2079 Authentication Protocol", RFC 5216, March 2008. 2081 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 2082 Authentication Protocol (EAP) Key Management Framework", 2083 RFC 5247, August 2008. 2085 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2086 Housley, R., and W. Polk, "Internet X.509 Public Key 2087 Infrastructure Certificate and Certificate Revocation List 2088 (CRL) Profile", RFC 5280, May 2008. 2090 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 2091 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 2092 August 2008. 2094 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 2095 "Elliptic Curve Cryptography Subject Public Key 2096 Information", RFC 5480, March 2009. 2098 [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. 2099 Polk, "Internet X.509 Public Key Infrastructure: 2100 Additional Algorithms and Identifiers for DSA and ECDSA", 2101 RFC 5758, January 2010. 2103 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 2104 Management Protocol (TAMP)", RFC 5934, August 2010. 2106 [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management 2107 Requirements", RFC 6024, October 2010. 2109 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 2110 Curve Cryptography Algorithms", RFC 6090, February 2011. 2112 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 2113 Transport Layer Security (TLS)", RFC 6655, July 2012. 2115 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 2116 Format", RFC 6690, August 2012. 2118 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 2119 "Diameter Base Protocol", RFC 6733, October 2012. 2121 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 2122 Multiple Certificate Status Request Extension", RFC 6961, 2123 June 2013. 2125 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2126 Constrained-Node Networks", RFC 7228, May 2014. 2128 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2129 Application Protocol (CoAP)", RFC 7252, June 2014. 2131 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2132 Attack", BCP 188, RFC 7258, May 2014. 2134 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer 2135 Security (TLS) and Datagram Transport Layer Security 2136 (DTLS)", RFC 7366, September 2014. 2138 [RFC7390] Rahman, A. and E. Dijk, "Group Communication for the 2139 Constrained Application Protocol (CoAP)", RFC 7390, 2140 October 2014. 2142 [RFC7397] Gilger, J. and H. Tschofenig, "Report from the Smart 2143 Object Security Workshop", RFC 7397, December 2014. 2145 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 2146 IPv6 over Low-Power Wireless Personal Area Networks 2147 (6LoWPANs)", RFC 7400, November 2014. 2149 [SP800-22b] 2150 National Institute of Standards and Technology, "Special 2151 Publication 800-22, Revision 1a, A Statistical Test Suite 2152 for Random and Pseudorandom Number Generators for 2153 Cryptographic Applications", 2154 http://csrc.nist.gov/publications/nistpubs/800-22-rev1a/ 2155 SP800-22rev1a.pdf, April 2010. 2157 [SP800-90A] 2158 NIST, "DRAFT Special Publication 800-90a, Revision 1, 2159 Recommendation for Random Number Generation Using 2160 Deterministic Random Bit Generators", 2161 http://csrc.nist.gov/publications/drafts/800-90/ 2162 sp800-90a_r1_draft_november2014_ver.pdf, November 2014. 2164 [Triple-HS] 2165 Bhargavan, K., Delignat-Lavaud, C., Pironti, A., and P. 2166 Strub, "Triple Handshakes and Cookie Cutters: Breaking and 2167 Fixing Authentication over TLS", IEEE Symposium on 2168 Security and Privacy, pages 98-113, 2014. 2170 Appendix A. Conveying DTLS over SMS 2172 This section is normative for the use of DTLS over SMS. Timer 2173 recommendations are already outlined in Section 13 and also 2174 applicable to the transport of DTLS over SMS. 2176 This section requires readers to be familiar with the terminology and 2177 concepts described in [GSM-SMS], and [WAP-WDP]. 2179 The remainder of this section assumes Mobile Stations are capable of 2180 producing and consuming 8-bit binary data encoded Transport Protocol 2181 Data Units (TPDU). 2183 A.1. Overview 2185 DTLS adds an additional roundtrip to the TLS [RFC5246] handshake to 2186 serve as a return-routability test for protection against certain 2187 types of DoS attacks. Thus a full blown DTLS handshake comprises up 2188 to 6 "flights" (i.e., logical message exchanges), each of which is 2189 then mapped on to one or more DTLS records using the segmentation and 2190 reassembly (SaR) scheme described in Section 4.2.3 of [RFC6347]. The 2191 overhead for said scheme is 6 bytes per Handshake message which, 2192 given a realistic 10+ messages handshake, would amount around 60 2193 bytes across the whole handshake sequence. 2195 Note that the DTLS SaR scheme is defined for handshake messages only. 2196 In fact, DTLS records are never fragmented and MUST fit within a 2197 single transport layer datagram. 2199 SMS provides an optional segmentation and reassembly scheme as well, 2200 known as Concatenated short messages (see Section 9.2.3.24.1 of 2201 [GSM-SMS]). However, since the SaR scheme in DTLS cannot be 2202 circumvented, the Concatenated short messages mechanism SHOULD NOT be 2203 used during handshake to avoid redundant overhead. Before starting 2204 the handshake phase (either actively or passively), the DTLS 2205 implementation MUST be explicitly configured with the PMTU of the SMS 2206 transport in order to correctly instrument its SaR function. The 2207 PMTU SHALL be 133 bytes if WDP-based multiplexing is used (see 2208 Appendix A.3), 140 bytes otherwise. 2210 It is RECOMMENDED to use the established security context over the 2211 longest possible period (possibly until a Closure Alert message is 2212 received, or after a very long inactivity timeout) to avoid the 2213 expensive re-establishment of the security association. 2215 A.2. Message Segmentation and Re-Assembly 2217 The content of an SMS message is carried in the TP-UserData field, 2218 and its size may be up to 140 bytes. As already mentioned in 2219 Appendix A.1, longer (i.e., up to 34170 bytes) messages can be sent 2220 using Concatenated SMS. 2222 This scheme consumes 6-7 bytes (depending on whether the short or 2223 long segmentation format is used) of the TP-UserData field, thus 2224 reducing the space available for the actual content of the SMS 2225 message to 133-134 bytes per TPDU. 2227 Though in principle a PMTU value higher than 140 bytes could be used, 2228 which may look like an appealing option given its more efficient use 2229 of the transport, there are disadvantages to consider. First, there 2230 is an additional overhead of 7 bytes per TPDU to be paid to the SaR 2231 function (which is in addition to the overhead introduced by the DTLS 2232 SaR mechanism. Second, some networks only partially support the 2233 Concatenated SMS function and others do not support it at all. 2235 For these reasons, the Concatenated short messages mechanism SHOULD 2236 NOT be used, and it is RECOMMENDED to leave the same PMTU settings 2237 used during the handshake phase, i.e., 133 bytes if WDP- based 2238 multiplexing is enabled, 140 bytes otherwise. 2240 Note that, after DTLS handshake has completed, any fragmentation and 2241 reassembly logic that pertains the application layer (e.g., 2242 segmenting CoAP messages into DTLS records and reassembling them 2243 after the crypto operations have been successfully performed) needs 2244 to be handled by the application that uses the established DTLS 2245 tunnel. 2247 A.3. Multiplexing Security Associations 2249 Unlike IPsec ESP/AH, DTLS records do not contain any association 2250 identifiers. Applications must arrange to multiplex between 2251 associations on the same endpoint which, when using UDP/IP, is 2252 usually done with the host/port number. 2254 If the DTLS server allows more than one client to be active at any 2255 given time, then the WAP User Datagram Protocol [WAP-WDP] can be used 2256 to achieve multiplexing of the different security associations. (The 2257 use of WDP provides the additional benefit that upper layer protocols 2258 can operate independently of the underlying wireless network, hence 2259 achieving application-agnostic transport handover.) 2261 The total overhead cost for encoding the WDP source and destination 2262 ports is either 5 or 7 bytes out of the total available for the SMS 2263 content depending on if 1-byte or 2-byte port identifiers are used, 2264 as shown in Figure 12 and Figure 13. 2266 0 1 2 3 4 2267 +--------+--------+--------+--------+--------+ 2268 | ... | 0x04 | 2 | ... | ... | 2269 +--------+--------+--------+--------+--------+ 2270 UDH IEI IE Dest Source 2271 Length Length Port Port 2273 Figure 12: Application Port Addressing Scheme (8 bit address). 2275 0 1 2 3 4 5 6 2276 +--------+--------+--------+--------+--------+--------+--------+ 2277 | ... | 0x05 | 4 | ... | ... | 2278 +--------+--------+--------+--------+--------+--------+--------+ 2279 UDH IEI IE Dest Source 2280 Length Length Port Port 2282 Figure 13: Application Port Addressing Scheme (16 bit address). 2284 The receiving side of the communication gets the source address from 2285 the originator address (TP-OA) field of the SMS-DELIVER TPDU. This 2286 way an unique 4-tuple identifying the security association can be 2287 reconstructed at both ends. (When replying to its DTLS peer, the 2288 sender will swaps the TP-OA and TP-DA parameters and the source and 2289 destination ports in the WDP.) 2291 A.4. Timeout 2293 If SMS-STATUS-REPORT messages are enabled, their receipt is not to be 2294 interpreted as the signal that the specific handshake message has 2295 been acted upon by the receiving party. Therefore, it MUST NOT be 2296 taken into account by the DTLS timeout and retransmission function. 2298 Handshake messages MUST carry a validity period (TP-VP parameter in a 2299 SMS-SUBMIT TPDU) that is not less than the current value of the 2300 retransmission timeout. In order to avoid persisting messages in the 2301 network that will be discarded by the receiving party, handshake 2302 messages SHOULD carry a validity period that is the same as, or just 2303 slightly higher than, the current value of the retransmission 2304 timeout. 2306 Appendix B. DTLS Record Layer Per-Packet Overhead 2308 Figure 14 shows the overhead for the DTLS record layer for protecting 2309 data traffic when AES-128-CCM with an 8-octet Integrity Check Value 2310 (ICV) is used. 2312 DTLS Record Layer Header................13 bytes 2313 Nonce (Explicit).........................8 bytes 2314 ICV..................................... 8 bytes 2315 ------------------------------------------------ 2316 Overhead................................29 bytes 2317 ------------------------------------------------ 2319 Figure 14: AES-128-CCM-8 DTLS Record Layer Per-Packet Overhead. 2321 The DTLS record layer header has 13 octets and consists of 2323 o 1 octet content type field, 2325 o 2 octet version field, 2327 o 2 octet epoch field, 2329 o 6 octet sequence number, 2331 o 2 octet length field. 2333 The "nonce" input to the AEAD algorithm is exactly that of [RFC5288], 2334 i.e., 12 bytes long. It consists of a 4 octet salt and an 8 octet 2335 nonce. The salt is the "implicit" part of the nonce and is not sent 2336 in the packet. Since the nonce_explicit may be the 8 octet sequence 2337 number and, in DTLS, it is the 8 octet epoch concatenated with the 6 2338 octet sequence number. 2340 RFC 6655 [RFC6655] allows the nonce_explicit to be a sequence number 2341 or something else. This document makes this use more restrictive for 2342 use with DTLS: the 64-bit none_explicit MUST be the 16-bit epoch 2343 concatenated with the 48-bit seq_num. The sequence number component 2344 of the nonce_explicit field at the AES-CCM layer is an exact copy of 2345 the sequence number in the record layer header field. This leads to 2346 a duplication of 8-bytes per record. 2348 To avoid this 8-byte duplication RFC 7400 [RFC7400] provides help 2349 with the use of the generic header compression technique for IPv6 2350 over Low-Power Wireless Personal Area Networks (6LoWPANs). Note that 2351 this header compression technique is not available when DTLS is 2352 exchanged over transports that do not use IPv6 or 6LoWPAN, such as 2353 the SMS transport described in Appendix A. 2355 Appendix C. DTLS Fragmentation 2357 [Editor's Note: Proposed text that requires discussion. ] 2359 Section 4.2.3 of [RFC6347] advises DTLS implementations to not 2360 produce overlapping fragments, but requires receivers to be able to 2361 cope with them. The need for the latter requisite is explained in 2362 Section 4.1.1.1 of [RFC6347]: accurate path MTU (PMTU) estimation may 2363 be traded for shorter handshake completion time. This approach may 2364 be beneficial in unconstrained networks where a PMTU of 1280 bytes 2365 can be pretty much universally assumed. However, an handshake that 2366 is carried over a narrow-band radio technology, such as IEEE 2367 802.15.4, Bluetooth Smart or GSM-SMS, and the client is lacking 2368 reliable PMTU data to inform fragmentation (e.g., using [RFC1981] or 2369 [RFC1191]) can place a cost on the constrained implementation in 2370 terms of memory (due to re-buffering) and latency (due to re- 2371 transmission) much higher than the benefit that it would get from a 2372 shorter handshake. 2374 In order to reduce the likelihood of producing different fragment 2375 sizes (and consequent overlaps) within the same handshake, this 2376 document RECOMMENDs: 2378 o for clients (handshake initiators), to perform PMTU discovery 2379 towards the server before handshake starts, and not rely on any 2380 guesses (unless the network path characteristics are reliably 2381 known from another source); 2383 o for servers, to mirror the fragment size selected by their 2384 clients. 2386 Authors' Addresses 2388 Hannes Tschofenig (editor) 2389 ARM Ltd. 2390 110 Fulbourn Rd 2391 Cambridge CB1 9NJ 2392 Great Britain 2394 Email: Hannes.tschofenig@gmx.net 2395 URI: http://www.tschofenig.priv.at 2396 Thomas Fossati 2397 Alcatel-Lucent 2398 3 Ely Road 2399 Milton, Cambridge CB24 6DD 2400 UK 2402 Email: thomas.fossati@alcatel-lucent.com