idnits 2.17.00 (12 Aug 2021) /tmp/idnits33257/draft-ietf-dice-profile-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (June 11, 2015) is 2535 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 1335, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' -- Possible downref: Non-RFC (?) normative reference: ref. 'GSM-SMS' == Outdated reference: draft-ietf-tls-cached-info has been published as RFC 7924 == Outdated reference: draft-ietf-tls-session-hash has been published as RFC 7627 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Informational RFC: RFC 7251 -- Possible downref: Non-RFC (?) normative reference: ref. 'WAP-WDP' -- No information found for draft-bmoeller-tls-falsestart - is the name correct? == Outdated reference: A later version (-04) exists of draft-bormann-core-cocoa-02 == Outdated reference: draft-ietf-core-resource-directory has been published as RFC 9176 -- No information found for draft-ietf-tls-sslv3-diediedie - is the name correct? -- No information found for draft-irtf-cfrg-curves - is the name correct? -- 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 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7507 (Obsoleted by RFC 8996) -- Obsolete informational reference (is this intentional?): RFC 7539 (Obsoleted by RFC 8439) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 14 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: December 13, 2015 Alcatel-Lucent 6 June 11, 2015 8 A TLS/DTLS Profile for the Internet of Things 9 draft-ietf-dice-profile-13.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 December 13, 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 . . . . . . . . . . . . . . . . 29 72 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 29 73 9. Session Resumption . . . . . . . . . . . . . . . . . . . . . 30 74 10. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 31 75 11. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 32 76 12. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 32 77 13. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 34 78 14. Random Number Generation . . . . . . . . . . . . . . . . . . 35 79 15. Truncated MAC and Encrypt-then-MAC Extension . . . . . . . . 36 80 16. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 37 81 17. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 37 82 18. Session Hash . . . . . . . . . . . . . . . . . . . . . . . . 37 83 19. Re-Negotiation Attacks . . . . . . . . . . . . . . . . . . . 38 84 20. Downgrading Attacks . . . . . . . . . . . . . . . . . . . . . 38 85 21. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 39 86 22. Key Length Recommendations . . . . . . . . . . . . . . . . . 40 87 23. False Start . . . . . . . . . . . . . . . . . . . . . . . . . 41 88 24. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42 89 25. Security Considerations . . . . . . . . . . . . . . . . . . . 42 90 26. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 91 27. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 92 28. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 93 28.1. Normative References . . . . . . . . . . . . . . . . . . 43 94 28.2. Informative References . . . . . . . . . . . . . . . . . 45 95 Appendix A. Conveying DTLS over SMS . . . . . . . . . . . . . . 50 96 A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 50 97 A.2. Message Segmentation and Re-Assembly . . . . . . . . . . 51 98 A.3. Multiplexing Security Associations . . . . . . . . . . . 52 99 A.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 53 100 Appendix B. DTLS Record Layer Per-Packet Overhead . . . . . . . 53 101 Appendix C. DTLS Fragmentation . . . . . . . . . . . . . . . . . 54 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 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 [RFC7465]. Note 211 that the term 'stream cipher' is a technical term in the TLS 212 specification. Section 4.7 of RFC 5246 defines stream ciphers in 213 TLS as follows: in stream cipher encryption, the plaintext is 214 exclusive-ORed with an identical amount of output generated from a 215 cryptographically secure keyed pseudorandom number generator. 217 o The TLS Handshake Protocol has been enhanced to include a 218 stateless cookie exchange for Denial of Service (DoS) resistance. 219 For this purpose a new handshake message, the HelloVerifyRequest, 220 was added to DTLS. This handshake message is sent by the server 221 and includes a stateless cookie, which is returned in a 222 ClientHello message back to the server. Although the exchange is 223 optional for the server to execute, a client implementation has to 224 be prepared to respond to it. Furthermore, the handshake message 225 format has been extended to deal with message loss, reordering, 226 and fragmentation. 228 4. Communication Models 230 This document describes a profile of DTLS and, to be useful, it has 231 to make assumptions about the envisioned communication architecture. 233 Two communication architectures (and consequently two profiles) are 234 described in this document. 236 4.1. Constrained TLS/DTLS Clients 238 The communication architecture shown in Figure 1 assumes a unicast 239 communication interaction with an IoT device utilizing a constrained 240 TLS/DTLS client interacting with one or multiple TLS/DTLS servers. 242 Before a client can initiate the TLS/DTLS handshake it needs to know 243 the IP address of that server and what credentials to use. 244 Application layer protocols, such as CoAP, which is conveyed on top 245 of DTLS, may be configured with URIs of the endpoints to which CoAP 246 needs to register and publish data. This configuration information 247 (including credentials) may be conveyed to clients as part of a 248 firmware/software package or via a configuration protocol. The 249 following credential types are supported by this profile: 251 o For PSK-based authentication (see Section 6.1), this includes the 252 paired "PSK identity" and shared secret to be used with each 253 server. 255 o For raw public key-based authentication (see Section 6.2), this 256 includes either the server's public key or the hash of the 257 server's public key. 259 o For certificate-based authentication (see Section 6.3), this 260 includes a pre-populated trust anchor store that allows the DTLS 261 stack to perform path validation for the certificate obtained 262 during the handshake with the server. 264 Figure 1 shows example configuration information stored at the 265 constrained client for use with respective servers. 267 This document focuses on the description of the DTLS client-side 268 functionality but, quite naturally, the equivalent server-side 269 support has to be available. 271 +////////////////////////////////////+ 272 | Configuration | 273 |////////////////////////////////////| 274 | Server A --> PSK Identity, PSK | 275 | | 276 | Server B --> Public Key (Server B),| 277 | Public/Private Key | 278 | (for Client) | 279 | | 280 | Server C --> Public/Private Key | 281 | (for Client) | 282 | Trust Anchor Store | 283 +------------------------------------+ 284 oo 285 oooooo 286 o 287 +-----------+ 288 |Constrained| 289 |TLS/DTLS | 290 |Client |- 291 +-----------+ \ 292 \ ,-------. 293 ,' `. +------+ 294 / IP-based \ |Server| 295 ( Network ) | A | 296 \ / +------+ 297 `. ,' 298 '---+---' +------+ 299 | |Server| 300 | | B | 301 | +------+ 302 | 303 | +------+ 304 +----------------->|Server| 305 | C | 306 +------+ 308 Figure 1: Constrained Client Profile. 310 4.1.1. Examples of Constrained Client Exchanges 312 4.1.1.1. Network Access Authentication Example 314 Re-use is a recurring theme when considering constrained environments 315 and is behind a lot of the directions taken in developments for 316 constrained environments. The corollary of re-use is to not add 317 functionality if it can be avoided. An example relevant to the use 318 of TLS is network access authentication, which takes place when a 319 device connects to a network and needs to go through an 320 authentication and access control procedure before it is allowed to 321 communicate with other devices or connect to the Internet. 323 Figure 2 shows the network access architecture with the IoT device 324 initiating the communication to an access point in the network using 325 the procedures defined for a specific physical layer. Since 326 credentials may be managed and stored centrally, in the 327 Authentication, Authorization, and Accounting (AAA) server, the 328 security protocol exchange may need to be relayed via the 329 Authenticator, i.e., functionality running on the access point, to 330 the AAA server. The authentication and key exchange protocol itself 331 is encapsulated within a container, the Extensible Authentication 332 Protocol (EAP) [RFC3748], and messages are conveyed back and forth 333 between the EAP endpoints, namely the EAP peer located on the IoT 334 device and the EAP server located on the AAA server or the access 335 point. To route EAP messages from the access point, acting as a AAA 336 client, to the AAA server requires an adequate protocol mechanism, 337 namely RADIUS [RFC2865] or Diameter [RFC6733]. 339 More details about the concepts and a description about the 340 terminology can be found in RFC 5247 [RFC5247]. 342 +--------------+ 343 |Authentication| 344 |Authorization | 345 |Accounting | 346 |Server | 347 |(EAP Server) | 348 | | 349 +-^----------^-+ 350 * EAP o RADIUS/ 351 * o Diameter 352 --v----------v-- 353 /// \\\ 354 // \\ 355 | Federation | 356 | Substrate | 357 \\ // 358 \\\ /// 359 --^----------^-- 360 * EAP o RADIUS/ 361 * o Diameter 362 +-------------+ +-v----------v--+ 363 | | EAP/EAP Method | | 364 | Internet of |<***************************>| Access Point | 365 | Things | |(Authenticator)| 366 | Device | EAP Lower Layer and |(AAA Client) | 367 | (EAP Peer) | Secure Association Protocol | | 368 | |<--------------------------->| | 369 | | | | 370 | | Physical Layer | | 371 | |<===========================>| | 372 +-------------+ +---------------+ 373 Legend: 375 <****>: Device-to-AAA Server Exchange 376 <---->: Device-to-Authenticator Exchange 377 : AAA Client-to-AAA Server Exchange 378 <====>: Physical layer like IEEE 802.11/802.15.4 380 Figure 2: Network Access Architecture. 382 One standardized EAP method is EAP-TLS, defined in RFC 5216 383 [RFC5216], which re-uses the TLS-based protocol exchange and 384 encapsulates it inside the EAP payload. In terms of re-use this 385 allows many components of the TLS protocol to be shared between the 386 network access security functionality and the TLS functionality 387 needed for securing application layer traffic. In the EAP-TLS 388 exchange shown in Figure 3 the IoT device as the EAP peer acts as a 389 TLS client. 391 Authenticating Peer Authenticator 392 ------------------- ------------- 393 <- EAP-Request/ 394 Identity 395 EAP-Response/ 396 Identity (MyID) -> 397 <- EAP-Request/ 398 EAP-Type=EAP-TLS 399 (TLS Start) 400 EAP-Response/ 401 EAP-Type=EAP-TLS 402 (TLS client_hello)-> 403 <- EAP-Request/ 404 EAP-Type=EAP-TLS 405 (TLS server_hello, 406 TLS certificate, 407 [TLS server_key_exchange,] 408 TLS certificate_request, 409 TLS server_hello_done) 410 EAP-Response/ 411 EAP-Type=EAP-TLS 412 (TLS certificate, 413 TLS client_key_exchange, 414 TLS certificate_verify, 415 TLS change_cipher_spec, 416 TLS finished) -> 417 <- EAP-Request/ 418 EAP-Type=EAP-TLS 419 (TLS change_cipher_spec, 420 TLS finished) 421 EAP-Response/ 422 EAP-Type=EAP-TLS -> 423 <- EAP-Success 425 Figure 3: EAP-TLS Exchange. 427 The guidance in this document also applies to the use of EAP-TLS for 428 network access authentication. An IoT device using a network access 429 authentication solution based on TLS can re-use most parts of the 430 code for the use of DTLS/TLS at the application layer thereby saving 431 a significant amount of flash memory. Note, however, that the 432 credentials used for network access authentication and those used for 433 application layer security are very likely different. 435 4.1.1.2. CoAP-based Data Exchange Example 437 When a constrained client uploads sensor data to a server 438 infrastructure it may use CoAP by pushing the data via a POST message 439 to a pre-configured endpoint on the server. In certain circumstances 440 this might be too limiting and additional functionality is needed, as 441 shown in Figure 4, where the IoT device itself runs a CoAP server 442 hosting the resource that is made accessible to other entities. 443 Despite running a CoAP server on the IoT device it is still the DTLS 444 client on the IoT device that initiates the interaction with the non- 445 constrained resource server in our scenario. 447 Figure 4 shows a sensor starting a DTLS exchange with a resource 448 directory to register available resources. 449 [I-D.ietf-core-resource-directory] defines the resource directory 450 (RD) as a web entity that stores information about web resources and 451 implements Representational State Transfer (REST) interfaces for 452 registration and lookup of those resources. Note that the described 453 exchange is borrowed from the OMA Lightweight Machine-to-Machine 454 (LWM2M) specification [LWM2M] that uses RD but adds proxy 455 functionality. 457 The initial DTLS interaction between the sensor, acting as a DTLS 458 client, and the resource directory, acting as a DTLS server, will be 459 a full DTLS handshake. Once this handshake is complete both parties 460 have established the DTLS record layer. Subsequently, the CoAP 461 client can securely register at the resource directory. 463 After some time (assuming that the client regularly refreshes its 464 registration) the resource directory receives a request from an 465 application to retrieve the temperature information from the sensor. 466 This request is relayed by the resource directory to the sensor using 467 a GET message exchange. The already established DTLS record layer 468 can be used to secure the message exchange. 470 Resource 471 Sensor Directory 472 ------ --------- 474 +--- 475 | 476 | ClientHello --------> 477 | #client_certificate_type# 478 F| #server_certificate_type# 479 U| 480 L| <------- HelloVerifyRequest 481 L| 482 | ClientHello --------> 483 D| #client_certificate_type# 484 T| #server_certificate_type# 485 L| 486 S| ServerHello 487 | #client_certificate_type# 488 H| #server_certificate_type# 489 A| Certificate 490 N| ServerKeyExchange 491 D| CertificateRequest 492 S| <-------- ServerHelloDone 493 H| 494 A| Certificate 495 K| ClientKeyExchange 496 E| CertificateVerify 497 | [ChangeCipherSpec] 498 | Finished --------> 499 | 500 | [ChangeCipherSpec] 501 | <-------- Finished 502 +--- 504 +--- ///+ 505 C| \ D 506 O| Req: POST coap://rd.example.com/rd?ep=node1 \ T 507 A| Payload: \ L 508 P| ;ct=41; \ S 509 | rt="temperature-c";if="sensor", \ 510 R| ;ct=41; \ R 511 D| rt="light-lux";if="sensor" \ E 512 | --------> \ C 513 R| \ O 514 E| \ R 515 G| Res: 2.01 Created \ D 516 .| <-------- Location: /rd/4521 \ 517 | \ L 518 +--- \ A 519 \ Y 520 * \ E 521 * (time passes) \ R 522 * \ 523 +--- \ P 524 C| \ R 525 O| Req: GET coaps://sensor.example.com/temp \ O 526 A| <-------- \ T 527 P| \ E 528 | Res: 2.05 Content \ C 529 G| Payload: \ T 530 E| 25.5 --------> \ E 531 T| \ D 532 +--- ///+ 534 Note: Extensions marked with '#' were introduced with 535 RFC 7250. 537 Figure 4: DTLS/CoAP exchange using Resource Directory. 539 4.2. Constrained TLS/DTLS Servers 541 Section 4.1 illustrates a deployment model where the TLS/DTLS client 542 is constrained and efforts need to be taken to improve memory 543 utilization, bandwidth consumption, reduce performance impacts, etc. 544 In this section, we assume a scenario where constrained devices run 545 TLS/ DTLS servers to secure access to application layer services 546 running on top of CoAP, HTTP or other protocols. Figure 5 547 illustrates a possible deployment whereby a number of constrained 548 servers are waiting for regular clients to access their resources. 549 The entire process is likely, but not necessarily, controlled by a 550 third party, the authentication and authorization server. This 551 authentication and authorization server is responsible for holding 552 authorization policies that govern the access to resources and 553 distribution of keying material. 555 +////////////////////////////////////+ 556 | Configuration | 557 |////////////////////////////////////| 558 | Credentials | 559 | Client A -> Public Key | 560 | Server S1 -> Symmetric Key | 561 | Server S2 -> Certificate | 562 | Server S3 -> Public Key | 563 | Trust Anchor Store | 564 | Access Control Lists | 565 | Resource X: Client A / GET | 566 | Resource Y: Client A / PUT | 567 +------------------------------------+ 568 oo 569 oooooo 570 o 571 +---------------+ +-----------+ 572 |Authentication | +-------->|TLS/DTLS | 573 |& Authorization| | |Client A | 574 |Server | | +-----------+ 575 +---------------+ ++ 576 ^ | +-----------+ 577 \ | |Constrained| 578 \ ,-------. | Server S1 | 579 ,' `. +-----------+ 580 / Local \ 581 ( Network ) 582 \ / +-----------+ 583 `. ,' |Constrained| 584 '---+---' | Server S2 | 585 | +-----------+ 586 | 587 | +-----------+ 588 +-----------------> |Constrained| 589 | Server S3 | 590 +-----------+ 592 Figure 5: Constrained Server Profile. 594 A deployment with constrained servers has to overcome several 595 challenges. Below we explain how these challenges have be solved 596 with CoAP, as an example. Other protocols may offer similar 597 capabilities. While the requirements for the TLS/DTLS protocol 598 profile change only slightly when run on a constrained server (in 599 comparison to running it on a constrained client) several other eco- 600 system factor will impact deployment. 602 There are several challenges that need to be addressed: 604 Discovery and Reachability: 606 A client must first and foremost discover the server before 607 initiating a connection to it. Once it has been discovered, 608 reachability to the device needs to be maintained. 610 In CoAP the discovery of resources offered by servers is 611 accomplished by sending a unicast or multicast CoAP GET to a well- 612 known URI. The CORE Link format specification [RFC6690] describes 613 the use case (see Section 1.2.1), and reserves the URI (see 614 Section 7.1). Section 7 of the CoAP specification [RFC7252] 615 describes the discovery procedure. [RFC7390] describes use case 616 for discovering CoAP servers using multicast (see Section 3.3), 617 and specifies the protocol processing rules for CoAP group 618 communications (see Section 2.7). 620 The use of Resource Directory (RD) 621 [I-D.ietf-core-resource-directory] is yet another possibility for 622 discovering registered servers and their resources. Since RD is 623 usually not a proxy, clients can discover links registered with 624 the RD and then access them directly. 626 Authentication: 628 The next challenge concerns the provisioning of authentication 629 credentials to the clients as well as servers. In Section 4.1 we 630 assumed that credentials (and other configuration information) are 631 provisioned to the device and that those can be used with the 632 authorization servers. Of course, this leads to a very static 633 relationship between the clients and their server-side 634 infrastructure but poses fewer challenges from a deployment point 635 of view, as described in Section 2 of [RFC7452] these different 636 communication patterns. In any case, engineers and product 637 designers have to determine how the relevant credentials are 638 distributed to the respective parties. For example, shared 639 secrets may need to be provisioned to clients and the constrained 640 servers for subsequent use of TLS/DTLS PSK. In other deployments, 641 certificates, private keys, and trust anchors for use with 642 certificate-based authentication may need to be utilized. 644 Practical solutions either use pairing (also called imprinting) or 645 a trusted third party. With pairing two devices execute a special 646 protocol exchange that is unauthenticated to establish an shared 647 key (for example using an unauthenticated Diffie-Hellman exchange) 648 key. To avoid man-in-the-middle attacks an out-of-band channel is 649 used to verify that nobody has tampered with the exchanged 650 protocol messages. This out-of-band channel can come in many 651 forms, including: 653 * Human involvement by comparing hashed keys, entering passkeys, 654 scanning QR codes 656 * The use of alternative wireless communication channels (e.g., 657 infra-red communication in addition to WiFi) 659 * Proximity-based information 661 More details about these different pairing/imprinting techniques 662 can be found in the smart object security workshop report 663 [RFC7397] and various position papers submitted to that topic, 664 such as [ImprintingSurvey]. The use of a trusted third party 665 follows a different approach and is subject to ongoing 666 standardization efforts in the 'Authentication and Authorization 667 for Constrained Environments (ACE)' working group [ACE-WG]. 669 Authorization 671 The last challenge is the ability for the constrained server to 672 make an authorization decision when clients access protected 673 resources. Pre-provisioning access control information to 674 constrained servers may be one option but works only in a small 675 scale, less dynamic environment. For a more fine-grained and 676 dynamic access control the reader is referred to the ongoing work 677 in the ACE working group. 679 Figure 6 shows an example interaction whereby a device, a thermostat 680 in our case, searches in the local network for discoverable resources 681 and accesses those. The thermostat starts the procedure using a 682 link-local discovery message using the "All CoAP Nodes" multicast 683 address by utilizing the RFC 6690 [RFC6690] link format. The IPv6 684 multicast address used for site-local discovery is FF02::FD. As a 685 result, a temperature sensor and a fan respond. These responses 686 allow the thermostat to subsequently read temperature information 687 from the temperature sensor with a CoAP GET request issued to the 688 previously learned endpoint. In this example we assume that 689 accessing the temperature sensor readings and controlling the fan 690 requires authentication and authorization of the thermostat and TLS 691 is used to authenticate both endpoint and to secure the 692 communication. 694 Temperature 695 Thermostat Sensor Fan 696 ---------- --------- --- 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 <------------------------------------------------- 734 Figure 6: Local Discovery and Resource Access. 736 5. The Ciphersuite Concept 738 TLS (and consequently DTLS) has the concept of ciphersuites and an 739 IANA registry [IANA-TLS] was created to register the suites. A 740 ciphersuite (and the specification that defines it) contains the 741 following information: 743 o Authentication and key exchange algorithm (e.g., PSK) 745 o Cipher and key length (e.g., Advanced Encryption Standard (AES) 746 with 128 bit keys [AES]) 748 o Mode of operation (e.g., Counter with Cipher Block Chaining - 749 Message Authentication Code (CBC-MAC) Mode (CCM) for AES) 750 [RFC3610] 752 o Hash algorithm for integrity protection, such as the Secure Hash 753 Algorithm (SHA) in combination with Keyed-Hashing for Message 754 Authentication (HMAC) (see [RFC2104] and [RFC6234]) 756 o Hash algorithm for use with pseudorandom functions (e.g., HMAC 757 with the SHA-256) 759 o Misc information (e.g., length of authentication tags) 761 o Information whether the ciphersuite is suitable for DTLS or only 762 for TLS 764 The TLS ciphersuite TLS_PSK_WITH_AES_128_CCM_8, for example, uses a 765 pre-shared authentication and key exchange algorithm. [RFC6655] 766 defines this ciphersuite. It uses the Advanced Encryption Standard 767 (AES) encryption algorithm, which is a block cipher. Since the AES 768 algorithm supports different key lengths (such as 128, 192 and 256 769 bits) this information has to be specified as well and the selected 770 ciphersuite supports 128 bit keys. A block cipher encrypts plaintext 771 in fixed-size blocks and AES operates on fixed block size of 128 772 bits. For messages exceeding 128 bits, the message is partitioned 773 into 128-bit blocks and the AES cipher is applied to these input 774 blocks with appropriate chaining, which is called mode of operation. 776 TLS 1.2 introduced Authenticated Encryption with Associated Data 777 (AEAD) ciphersuites (see [RFC5116] and [RFC6655]). AEAD is a class 778 of block cipher modes which encrypt (parts of) the message and 779 authenticate the message simultaneously. Examples of such modes 780 include the Counter with Cipher Block Chaining - Message 781 Authentication Code (CBC-MAC) Mode (CCM) mode, and the Galois/Counter 782 Mode (GCM) (see [RFC5288] and [RFC7251]). 784 Some AEAD ciphersuites have shorter authentication tags (i.e., 785 message authentication codes) and are therefore more suitable for 786 networks with low bandwidth where small message size matters. The 787 TLS_PSK_WITH_AES_128_CCM_8 ciphersuite that ends in "_8" has an 788 8-octet authentication tag, while the regular CCM ciphersuites have, 789 at the time of writing, 16-octet authentication tags. The design of 790 CCM and the security properties are described in [CCM]. 792 TLS 1.2 also replaced the combination of MD5/SHA-1 hash functions in 793 the TLS pseudo random function (PRF) used in earlier versions of TLS 794 with cipher-suite-specified PRFs. For this reason authors of more 795 recent TLS 1.2 ciphersuite specifications explicitly indicate the MAC 796 algorithm and the hash functions used with the TLS PRF. 798 6. Credential Types 800 The mandatory-to-implement functionality will depend on the 801 credential type used with IoT devices. The sub-sections below 802 describe the implications of three different credential types, namely 803 pre-shared secrets, raw public keys, and certificates. 805 6.1. Pre-Shared Secret 807 The use of pre-shared secrets is one of the most basic techniques for 808 TLS/DTLS since it is both computational efficient and bandwidth 809 conserving. Pre-shared secret based authentication was introduced to 810 TLS with RFC 4279 [RFC4279]. When using a pre-shared secret, a 811 critical consideration is how to assure the randomness of these 812 secrets. The best practice is to ensure that any pre-shared key 813 contains as much randomness as possible. Deriving a shared secret 814 from a password, name, or other low-entropy source is not secure. A 815 low-entropy secret, or password, is subject to dictionary attacks. 817 The exchange shown in Figure 7 illustrates the DTLS exchange 818 including the cookie exchange. While the server is not required to 819 initiate a cookie exchange with every handshake, the client is 820 required to implement and to react on it when challenged. The cookie 821 exchange allows the server to react to flooding attacks. 823 Client Server 824 ------ ------ 825 ClientHello --------> 827 <-------- HelloVerifyRequest 828 (contains cookie) 830 ClientHello --------> 831 (with cookie) 832 ServerHello 833 *ServerKeyExchange 834 <-------- ServerHelloDone 835 ClientKeyExchange 836 ChangeCipherSpec 837 Finished --------> 838 ChangeCipherSpec 839 <-------- Finished 841 Application Data <-------> Application Data 843 Legend: 845 * indicates an optional message payload 847 Figure 7: DTLS PSK Authentication including the Cookie Exchange. 849 Note that [RFC4279] used the term PSK identity to refer to the 850 identifier used to refer to the appropriate secret. While 851 'identifier' would be more appropriate in this context we re-use the 852 terminology defined in RFC 4279 to avoid confusion. RFC 4279 does 853 not mandate the use of any particular type of PSK identity and the 854 client and server have to agree on the identities and keys to be 855 used. The UTF-8 encoding of identities described in Section 5.1 of 856 RFC 4279 aims to improve interoperability for those cases where the 857 identity is configured by a human using some management interface 858 provided by a Web browser. However, many IoT devices do not have a 859 user interface and most of their credentials are bound to the device 860 rather than to the user. Furthermore, credentials are often 861 provisioned into hardware modules or into the firmware by developers. 862 As such, the encoding considerations are not applicable to this usage 863 environment. For use with this profile the PSK identities SHOULD NOT 864 assume a structured format (such as domain names, Distinguished 865 Names, or IP addresses) and a bit-by-bit comparison operation MUST be 866 used by the server for any operation related to the PSK identity. 868 Protocol-wise the client indicates which key it uses by including a 869 "PSK identity" in the ClientKeyExchange message. As described in 870 Section 4 clients may have multiple pre-shared keys with a single 871 server, for example in a hosting context. The TLS Server Name 872 Indication (SNI) extension allows the client to convey the name of 873 the server it is contacting. A server implementation needs to guide 874 the selection based on a received SNI value from the client. 876 RFC 4279 requires TLS implementations supporting PSK ciphersuites to 877 support arbitrary PSK identities up to 128 octets in length, and 878 arbitrary PSKs up to 64 octets in length. This is a useful 879 assumption for TLS stacks used in the desktop and mobile environments 880 where management interfaces are used to provision identities and 881 keys. Implementations in compliance with this profile MAY use PSK 882 identities up to 128 octets in length, and arbitrary PSKs up to 64 883 octets in length. The use of shorter PSK identities is RECOMMENDED. 885 Constrained Application Protocol (CoAP) [RFC7252] currently specifies 886 TLS_PSK_WITH_AES_128_CCM_8 as the mandatory to implement ciphersuite 887 for use with shared secrets. This ciphersuite uses the AES algorithm 888 with 128 bit keys and CCM as the mode of operation. The label "_8" 889 indicates that an 8-octet authentication tag is used. This 890 ciphersuite makes use of the default TLS 1.2 Pseudorandom Function 891 (PRF), which uses an HMAC with the SHA-256 hash function. Note: 892 Starting with TLS 1.2 (and consequently DTLS 1.2) ciphersuites have 893 to specify the pseudorandom function. RFC 5246 states that 'New 894 cipher suites MUST explicitly specify a PRF and, in general, SHOULD 895 use the TLS PRF with SHA-256 or a stronger standard hash function.'. 896 The ciphersuites recommended in this document use the SHA-256 897 construct defined in Section 5 of RFC 5246. 899 A device compliant with the profile in this section MUST implement 900 TLS_PSK_WITH_AES_128_CCM_8 and follow the guidance from this section. 902 6.2. Raw Public Key 904 The use of raw public keys with TLS/DTLS, as defined in [RFC7250], is 905 the first entry point into public key cryptography without having to 906 pay the price of certificates and a public key infrastructure (PKI). 907 The specification re-uses the existing Certificate message to convey 908 the raw public key encoded in the SubjectPublicKeyInfo structure. To 909 indicate support two new extensions had been defined, as shown in 910 Figure 8, namely the server_certificate_type*' and the 911 client_certificate_type. To operate this mechanism securely it is 912 necessary to authenticate and authorize the public keys out-of-band. 913 This key distribution step may, for example, be provided by a 914 dedicated protocol, such as the OMA LWM2M [LWM2M]. This document 915 therefore assumes that a client implementation comes with one or 916 multiple raw public keys of servers, it has to communicate with, pre- 917 provisioned. To replace, delete, or add raw public keys to this list 918 requires a software update, for example using a firmware update 919 mechanism. Additionally, a device will have its own raw public key 920 and the corresponding private key. This key pair may, for example, 921 be configured during the manufacturing process of the device. 923 Client Server 924 ------ ------ 926 ClientHello --------> 927 #client_certificate_type# 928 #server_certificate_type# 930 ServerHello 931 #client_certificate_type# 932 #server_certificate_type# 933 Certificate 934 ServerKeyExchange 935 CertificateRequest 936 <-------- ServerHelloDone 938 Certificate 939 ClientKeyExchange 940 CertificateVerify 941 [ChangeCipherSpec] 942 Finished --------> 944 [ChangeCipherSpec] 945 <-------- Finished 947 Note: Extensions marked with '#' were introduced with 948 RFC 7250. 950 Figure 8: DTLS Raw Public Key Exchange. 952 The CoAP recommended ciphersuite for use with this credential type is 953 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251]. This elliptic curve 954 cryptography (ECC) based AES-CCM TLS ciphersuite uses the Ephemeral 955 Elliptic Curve Diffie-Hellman (ECDHE) as the key establishment 956 mechanism and an Elliptic Curve Digital Signature Algorithm (ECDSA) 957 for authentication. Due to the use of Ephemeral Elliptic Curve 958 Diffie-Hellman (ECDHE) the recently introduced named Diffie-Hellman 959 groups [I-D.ietf-tls-negotiated-dl-dhe] are not applicable to this 960 profile. This ciphersuite makes use of the AEAD capability in DTLS 961 1.2 and utilizes an eight-octet authentication tag. The use of a 962 Diffie-Hellman key exchange provides perfect forward secrecy (PFS). 963 More details about PFS can be found in Section 11. 965 [RFC6090] provides valuable information for implementing Elliptic 966 Curve Cryptography algorithms, particularly for choosing methods that 967 have been available in the literature for a long time (i.e., 20 years 968 and more). 970 A device compliant with the profile in this section MUST implement 971 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this 972 section. 974 6.3. Certificates 976 The use of mutual certificate-based authentication is shown in 977 Figure 9, which makes use of the cached info extension 978 [I-D.ietf-tls-cached-info]. Support of the cached info extension is 979 REQUIRED. Caching certificate chains allows the client to reduce the 980 communication overhead significantly since otherwise the server would 981 provide the end entity certificate, and the certificate chain with 982 every full DTLS handshake. Because certificate validation requires 983 that root keys be distributed independently, the self-signed 984 certificate that specifies the root certification authority is 985 omitted from the chain. Client implementations MUST be provisioned 986 with a trust anchor store that contains these root certificates. The 987 use of the Trust Anchor Management Protocol (TAMP) [RFC5934] is, 988 however, not envisioned. Instead IoT devices using this profile MUST 989 use a software update mechanism to populate the trust anchor store. 991 Client Server 992 ------ ------ 994 ClientHello --------> 995 *cached_info* 997 ServerHello 998 *cached_info* 999 Certificate 1000 ServerKeyExchange 1001 CertificateRequest 1002 <-------- ServerHelloDone 1004 Certificate 1005 ClientKeyExchange 1006 CertificateVerify 1007 [ChangeCipherSpec] 1008 Finished --------> 1010 [ChangeCipherSpec] 1011 <-------- Finished 1013 Note: Extensions marked with '*' were introduced with 1014 [I-D.ietf-tls-cached-info]. 1016 Figure 9: DTLS Mutual Certificate-based Authentication. 1018 TLS/DTLS offers a lot of freedom for the use with ECC. This document 1019 restricts the use of ECC ciphersuites to named curves defined in RFC 1020 4492 [RFC4492]. At the time of writing the recommended curve is 1021 secp256r1 and the use of uncompressed points to follow the 1022 recommendation in CoAP. Note that standardization for Curve25519 1023 (for ECDHE) is ongoing (see [I-D.irtf-cfrg-curves]) and support for 1024 this curve will likely be required in the future. To offer elliptic- 1025 curve signatures using the Edwards-curve Digital Signature Algorithm 1026 (EdDSA) standardization work on Ed25519 is also ongoing (see 1027 [I-D.josefsson-eddsa-ed25519]). 1029 A device compliant with the profile in this section MUST implement 1030 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this 1031 section. 1033 6.3.1. Certificates used by Servers 1035 The algorithm for verifying the service identity, as described in RFC 1036 6125 [RFC6125], is essential for ensuring proper security when 1037 certificates are used. As a summary, the algorithm contains the 1038 following steps: 1040 1. The client constructs a list of acceptable reference identifiers 1041 based on the source domain and, optionally, the type of service 1042 to which the client is connecting. 1044 2. The server provides its identifiers in the form of a PKIX 1045 certificate. 1047 3. The client checks each of its reference identifiers against the 1048 presented identifiers for the purpose of finding a match. 1050 4. When checking a reference identifier against a presented 1051 identifier, the client matches the source domain of the 1052 identifiers and, optionally, their application service type. 1054 For various terms used in the algorithm shown above consult RFC 6125. 1055 It is important to highlight that certificate usage without comparing 1056 the reference identifier against the presented identifier obtained 1057 from the certificate breaks security. 1059 It is worth noting that the algorithm description and the text in RFC 1060 6125 assumes that fully qualified DNS domain names are used. If a 1061 server node is provisioned with a fully qualified DNS domain then the 1062 server certificate MUST contain the fully qualified DNS domain name 1063 or "FQDN" as dNSName [RFC5280]. For CoAP, the coaps URI scheme is 1064 described in Section 6.2 of [RFC7252]. This FQDN is stored in the 1065 SubjectAltName or in the leftmost CN component of subject name, as 1066 explained in Section 9.1.3.3 of [RFC7252], and used by the client to 1067 match it against the FQDN used during the look-up process, as 1068 described in [RFC6125]. For other protocols, the appropriate URI 1069 scheme specification has to be consulted. 1071 The following recommendation is provided: 1073 1. Certificates MUST NOT use DNS domain names in the Common Name of 1074 certificates and instead use the subjectAltName attribute, as 1075 described in the previous paragraph. 1077 2. Certificates MUST NOT contain domain names with wildcard 1078 characters. 1080 3. Certificates MUST NOT contains multiple names (e.g., more than 1081 one dNSName field). 1083 Note that there will be servers that are not provisioned for use with 1084 DNS domain names, for example, IoT devices that offer resources to 1085 nearby devices in a local area network, as shown in Figure 6. When 1086 such constrained servers are used then the use of certificates as 1087 described in Section 6.3.2 is applicable. Note that the Service Name 1088 Indication (SNI) extension cannot be used in this case since SNI does 1089 not offer the ability to convey EUI-64 [EUI64] identifiers. 1091 6.3.2. Certificates used by Clients 1093 For client certificates the identifier used in the SubjectAltName or 1094 in the leftmost CN component of subject name MUST be an EUI-64, as 1095 mandated in Section 9.1.3.3 of [RFC7252]. 1097 6.3.3. Certificate Revocation 1099 For certificate revocation neither the Online Certificate Status 1100 Protocol (OCSP) nor Certificate Revocation Lists (CRLs) are used. 1101 Instead, this profile relies on a software update mechanism to 1102 provision information about revoked certificates. While multiple 1103 OCSP stapling [RFC6961] has recently been introduced as a mechanism 1104 to piggyback OCSP request/responses inside the DTLS/TLS handshake (to 1105 avoid the cost of a separate protocol handshake), further 1106 investigations are needed to determine its suitability for the IoT 1107 environment. 1109 As stated earlier in this section, modifications to the trust anchor 1110 store depends on a software update mechanism as well. 1112 6.3.4. Certificate Content 1114 All certificate elements listed in Table 1 are mandatory-to-implement 1115 for client and servers claiming support for certificate-based 1116 authentication. No other certificate elements are used by this 1117 specification. 1119 When using certificates, IoT devices MUST provide support for a 1120 server certificate chain of at least 3 not including the trust anchor 1121 and MAY reject connections from servers offering chains longer than 1122 3. IoT devices MAY have client certificate chains of any length. 1123 Obviously, longer chains require more digital signature verification 1124 operations to perform and lead to larger certificate messages in the 1125 TLS handshake. 1127 Table 1 provides a summary of the elements in a certificate for use 1128 with this profile. 1130 +----------------------+--------------------------------------------+ 1131 | Element | Notes | 1132 +----------------------+--------------------------------------------+ 1133 | version | This profile uses X.509 v3 certificates | 1134 | | [RFC5280]. | 1135 | | | 1136 | serialNumber | Positive integer unique per certificate. | 1137 | | | 1138 | signature | This field contains the signature | 1139 | | algorithm and this profile uses ecdsa- | 1140 | | with-SHA256 or stronger [RFC5758]. | 1141 | | | 1142 | issuer | Contains the DN of the issuing CA. | 1143 | | | 1144 | validity | Values expressed as UTC time in notBefore | 1145 | | and notAfter fields. No validity period | 1146 | | mandated. | 1147 | | | 1148 | subject | See rules outlined in this section. | 1149 | | | 1150 | subjectPublicKeyInfo | The SubjectPublicKeyInfo structure | 1151 | | indicates the algorithm and any associated | 1152 | | parameters for the ECC public key.This | 1153 | | profile uses the id-ecPublicKey algorithm | 1154 | | identifier for ECDSA signature keys, as | 1155 | | defined in specified in [RFC5480]. | 1156 | | | 1157 | signatureAlgorithm | The ECDSA signature algorithm with ecdsa- | 1158 | | with-SHA256 or stronger. | 1159 | | | 1160 | signatureValue | Bit string containing the digital | 1161 | | signature. | 1162 | | | 1163 | Extension: | See rules outlined in this section. | 1164 | subjectAltName | | 1165 | | | 1166 | Extension: | Indicates whether the subject of the | 1167 | BasicConstraints | certificate is a CA and the maximum depth | 1168 | | of valid certification paths that include | 1169 | | this certificate. This extension is used | 1170 | | for CA certs only and then the value of | 1171 | | the 'cA' field is set to TRUE. The default | 1172 | | is FALSE. | 1173 | | | 1174 | Extension: Key Usage | The KeyUsage field MAY have the following | 1175 | | values in the context of this profile: | 1176 | | digitalSignature or keyAgreement, | 1177 | | keyCertSign for verifying signatures on | 1178 | | public key certificates. | 1179 | | | 1180 | Extension: Extended | The ExtKeyUsageSyntax field MAY have the | 1181 | Key Usage | following values in context of this | 1182 | | profile: id-kp-serverAuth for server | 1183 | | authentication, id-kp-clientAuth for | 1184 | | client authentication, id-kp-codeSigning | 1185 | | for code signing (for software update | 1186 | | mechanism), id-kp-OCSPSigning for future | 1187 | | OCSP usage in TLS. | 1188 +----------------------+--------------------------------------------+ 1190 Table 1: Certificate Content. 1192 There are various algorithms used to sign digital certificates, such 1193 as RSA, the Digital Signature Algorithm (DSA), and the Elliptic Curve 1194 Digital Signature Algorithm (ECDSA). As Table 1 indicates 1195 certificate are signed using ECDSA. This is not only true for the 1196 end-entity certificates but also for all other certificates in the 1197 chain, including CA certificates. 1199 Further details about X.509 certificates can be found in 1200 Section 9.1.3.3 of [RFC7252]. 1202 6.3.5. Client Certificate URLs 1204 RFC 6066 [RFC6066] allows to avoid sending client-side certificates 1205 and uses URLs instead. This reduces the over-the-air transmission. 1206 Note that the TLS cached info extension does not provide any help 1207 with caching client certificates. 1209 TLS/DTLS clients MUST implement support for client certificate URLs 1210 for those environments where client-side certificates are used and 1211 the server-side is not constrained. For constrained servers this 1212 functionality is NOT RECOMMENDED since it forces the server to 1213 execute an additional protocol exchange, potentially using a protocol 1214 it does not even support. The use of this extension also increases 1215 the risk of a denial of service attack against the constrained server 1216 due to the additional workload. 1218 6.3.6. Trusted CA Indication 1220 RFC 6066 [RFC6066] allows clients to indicate what trust anchor they 1221 support. With certificate-based authentication a DTLS server conveys 1222 its end entity certificate to the client during the DTLS exchange 1223 provides. Since the server does not necessarily know what trust 1224 anchors the client has stored and to facilitate certification path 1225 construction as well as path validation, it includes intermediate CA 1226 certs in the certificate payload. 1228 Today, in most IoT deployments there is a fairly static relationship 1229 between the IoT device (and the software running on them) and the 1230 server-side infrastructure. For these deployments where IoT devices 1231 interact with a fixed, pre-configured set of servers this extension 1232 is NOT RECOMMENDED. 1234 In cases where client interact with dynamically discovered TLS/DTLS 1235 servers, for example in the use cases described in Section 4.2, the 1236 use of this extension is RECOMMENDED. 1238 7. Signature Algorithm Extension 1240 The "signature_algorithms" extension, defined in Section 7.4.1.4.1 of 1241 RFC 5246 [RFC5246], allows the client to indicate to the server which 1242 signature/hash algorithm pairs may be used in digital signatures. 1243 The client MUST send this extension to select the use of SHA-256 1244 since otherwise absent this extension RFC 5246 defaults to SHA-1 / 1245 ECDSA for the ECDH_ECDSA and the ECDHE_ECDSA key exchange algorithms. 1247 The "signature_algorithms" extension is not applicable to the PSK- 1248 based ciphersuite described in Section 6.1. 1250 8. Error Handling 1252 TLS/DTLS uses the Alert protocol to convey errors and specifies a 1253 long list of error types. However, not all error messages defined in 1254 the TLS/DTLS specification are applicable to this profile. In 1255 general, there are two categories of errors (as defined in 1256 Section 7.2 of RFC 5246), namely fatal errors and warnings. Alert 1257 messages with a level of fatal result in the immediate termination of 1258 the connection. If possible, developers should try to develop 1259 strategies to react to those fatal errors, such as re-starting the 1260 handshake or informing the user using the (often limited) user 1261 interface. Warnings may be ignored by the application since many IoT 1262 devices will either have limited ways to log errors or no ability at 1263 all. In any case, implementers have to carefully evaluate the impact 1264 of errors and ways to remedy the situation since a commonly used 1265 approach for delegating decision making to users is difficult (or 1266 impossible) to accomplish in a timely fashion. 1268 All error messages marked as RESERVED are only supported for 1269 backwards compatibility with SSL MUST NOT be used with this profile. 1270 Those include decryption_failed_RESERVED, no_certificate_RESERVED, 1271 and export_restriction_RESERVED. 1273 A number of the error messages MUST only be used for certificate- 1274 based ciphersuites. Hence, the following error messages MUST NOT be 1275 used with with PSK and raw public key authentication: 1277 o bad_certificate, 1279 o unsupported_certificate, 1281 o certificate_revoked, 1283 o certificate_expired, 1285 o certificate_unknown, 1287 o unknown_ca, and 1289 o access_denied. 1291 Since this profile does not make use of compression at the TLS layer 1292 the decompression_failure error message MUST NOT be used either. 1294 RFC 4279 introduced a new alert message unknown_psk_identity for PSK 1295 ciphersuites. As stated in Section 2 of RFC 4279 the 1296 decryption_error error message may also be used instead. For this 1297 profile the TLS server MUST return the decryption_error error message 1298 instead of the unknown_psk_identity since the two mechanisms exist 1299 and provide the same functionality. 1301 Furthermore, the following errors should not occur with devices and 1302 servers supporting this specification but implementations MUST be 1303 prepared to process these errors to deal with servers that are not 1304 compliant to the profiles in this document: 1306 protocol_version: While this document focuses only on one version of 1307 the TLS/DTLS protocol, namely version 1.2, ongoing work on TLS/ 1308 DTLS 1.3 is in progress at the time of writing. 1310 insufficient_security: This error message indicates that the server 1311 requires ciphers to be more secure. This document specifies only 1312 one ciphersuite per profile but it is likely that additional 1313 ciphersuites get added over time. 1315 user_canceled: Many IoT devices are unattended and hence this error 1316 message is unlikely to occur. 1318 9. Session Resumption 1320 Session resumption is a feature of the core TLS/DTLS specifications 1321 that allows a client to continue with an earlier established session 1322 state. The resulting exchange is shown in Figure 10. In addition, 1323 the server may choose not to do a cookie exchange when a session is 1324 resumed. Still, clients have to be prepared to do a cookie exchange 1325 with every handshake. The cookie exchange is not shown in the 1326 figure. 1328 Client Server 1329 ------ ------ 1331 ClientHello --------> 1332 ServerHello 1333 [ChangeCipherSpec] 1334 <-------- Finished 1335 [ChangeCipherSpec] 1336 Finished --------> 1337 Application Data <-------> Application Data 1339 Figure 10: DTLS Session Resumption. 1341 Constrained clients MUST implement session resumption to improve the 1342 performance of the handshake. This will lead to a reduced number of 1343 message exchanges, lower computational overhead (since only symmetric 1344 cryptography is used during a session resumption exchange), and 1345 session resumption requires less bandwidth. 1347 For cases where the server constrained (but not the client) the 1348 client MUST implement RFC 5077 [RFC5077]. Note that the constrained 1349 server refers to a device that has limitations in terms of RAM and 1350 flash memory, which place restrictions on the amount of TLS/DTLS 1351 security state information that can be stored on such a device. RFC 1352 5077 specifies a version of TLS/DTLS session resumption that does not 1353 require per-session state information to be maintained by the 1354 constrained server. This is accomplished by using a ticket-based 1355 approach. 1357 If both the client and the server are constrained devices both 1358 devices SHOULD implement RFC 5077 and MUST implement basic session 1359 resumption. Clients that do not want to use session resumption are 1360 always able to send a ClientHello message with an empty session_id to 1361 revert to a full handshake. 1363 10. Compression 1365 Section 3.3 of [RFC7525] recommends to disable TLS/DTLS-level 1366 compression due to attacks, such as CRIME. For IoT applications 1367 compression at the TLS/DTLS layer is not needed since application 1368 layer protocols are highly optimized and the compression algorithms 1369 at the DTLS layer increases code size and complexity. 1371 This TLS/DTLS profile MUST NOT implement TLS/DTLS layer compression. 1373 11. Perfect Forward Secrecy 1375 Perfect forward secrecy (PFS) is a property that preserves the 1376 confidentiality of past conversations even in situations where the 1377 long-term secret is compromised. 1379 The PSK ciphersuite recommended in Section 6.1 does not offer this 1380 property since it does not utilize a Diffie-Hellman exchange. New 1381 ciphersuites that support PFS for PSK-based authentication, such as 1382 proposed in [I-D.schmertmann-dice-ccm-psk-pfs], might become 1383 available as standardized ciphersuite in the (near) future. The 1384 recommended PSK-based ciphersuite offers excellent performance, a 1385 very small memory footprint, and has the lowest on the wire overhead 1386 at the expense of not using any public cryptography. For deployments 1387 where public key cryptography is acceptable the raw public might 1388 offer an acceptable middle ground between the PSK ciphersuite in 1389 terms of out-of-band validation and the functionality offered by 1390 asymmetric cryptography. 1392 The use of PFS is a trade-off decision since on one hand the 1393 compromise of long-term secrets of embedded devices is more likely 1394 than with many other Internet hosts but on the other hand a Diffie- 1395 Hellman exchange requires ephemeral key pairs to be generated, which 1396 is demanding from a performance point of view. For obvious 1397 performance improvement, some implementations re-use key pairs over 1398 multiple exchanges (rather than generating new keys for each 1399 exchange). However, note that such key re-use over long periods 1400 voids the benefits of forward secrecy when an attack gains access to 1401 this DH key pair. 1403 The impact of the disclosure of past conversations and the desire to 1404 increase the cost for pervasive monitoring (as demanded by [RFC7258]) 1405 has to be taken into account when making a deployment decision. 1407 Client implementations claiming support of this profile MUST 1408 implement the ciphersuites listed in Section 6 according to the 1409 selected credential type. 1411 12. Keep-Alive 1413 Application layer communication may create state at the endpoints and 1414 this state my expire at some time. For this reason, applications 1415 define ways to refresh state, if necessary. While the application 1416 layer exchanges are largely outside the scope of the underlying TLS/ 1417 DTLS exchange similar state considerations also play a role at the 1418 level of TLS/DTLS. While TLS/DTLS also creates state in form of a 1419 security context (see the security parameter described in Appendix A6 1420 in RFC 5246) at the client and the server this state information does 1421 not expire. However, network intermediaries may also allocate state 1422 and require this state to be kept alive. Failure to keep state alive 1423 at a stateful packet filtering firewall or at a NAT may result in the 1424 inability for one node to reach the other since packets will get 1425 blocked by these middleboxes. Periodic keep-alive messages exchanged 1426 between the TLS/DTLS client and server keep state at these 1427 middleboxes alive. According to measurements described in 1428 [HomeGateway] there is some variance in state management practices 1429 used in residential gateways but the timeouts are heavily impacted by 1430 the choice of the transport layer protocol: timeouts for UDP are 1431 typically much shorter than those for TCP. 1433 RFC 6520 [RFC6520] defines a heartbeat mechanism to test whether the 1434 other peer is still alive. As an additional feature, the same 1435 mechanism can also be used to perform Path Maximum Transmission Unit 1436 (MTU) Discovery. 1438 A recommendation about the use of RFC 6520 depends on the type of 1439 message exchange an IoT device performs and the number of messages 1440 the application needs to exchange as part of their application 1441 functionality. There are three types of exchanges that need to be 1442 analyzed: 1444 Client-Initiated, One-Shot Messages 1446 This is a common communication pattern where IoT devices upload 1447 data to a server on the Internet on an irregular basis. The 1448 communication may be triggered by specific events, such as opening 1449 a door. 1451 Since the upload happens on an irregular and unpredictable basis 1452 and due to renumbering and Network Address Translation (NAT) the 1453 DTLS handshake may need to be re-started (ideally using session 1454 resumption, if possible). 1456 In this case there is no use for a keep-alive extension for this 1457 scenario. 1459 Client-Initiated, Regular Data Uploads 1461 This is a variation of the previous case whereby data gets 1462 uploaded on a regular basis, for example, based on frequent 1463 temperature readings. If neither NAT bindings nor IP address 1464 changes occurred then the record layer will not notice any 1465 changes. For the case where the IP address and port number 1466 changes, it is necessary to re-create the record layer using 1467 session resumption. 1469 In this scenario there is no use for a keep-alive extension. It 1470 is also very likely that the device will enter a sleep cycle in 1471 between data transmissions to keep power consumption low. 1473 Server-Initiated Messages 1475 In the two previous scenarios the client initiated the protocol 1476 interaction and maintains it. Since messages to the client may 1477 get blocked by middleboxes the initial connection setup is 1478 triggered by the client and then kept alive by the server. 1480 For this message exchange pattern the use of DTLS heartbeat 1481 messages is quite useful but may have to be coordinated with 1482 application exchanges (for example when the CoAP resource 1483 directory is used) to avoid redundant keep-alive message 1484 exchanges. The MTU discovery mechanism, which is also part of 1485 [RFC6520], is less likely to be relevant since for many IoT 1486 deployments the most constrained link is the wireless interface 1487 between the IoT device and the network itself (rather than some 1488 links along the end-to-end path). Only in more complex network 1489 topologies, such as multi-hop mesh networks, path MTU discovery 1490 might be appropriate. It also has to be noted that DTLS itself 1491 already provides a basic path discovery mechanism (see 1492 Section 4.1.1.1 of RFC 6347 by using the fragmentation capability 1493 of the handshake protocol). 1495 For server-initiated messages the heartbeat extension is RECOMMENDED. 1497 13. Timeouts 1499 To connect to the Internet a variety of wired and wireless 1500 technologies are available. Many of the low power radio 1501 technologies, such as IEEE 802.15.4 or Bluetooth Smart, only support 1502 small frame sizes (e.g., 127 bytes in case of IEEE 802.15.4 as 1503 explained in RFC 4919 [RFC4919]). Other radio technologies, such as 1504 the Global System for Mobile Communications (GSM) using the short 1505 messaging service (SMS) have similar constraints in terms of payload 1506 sizes, such as 140 bytes without the optional segmentation and 1507 reassembly scheme known as Concatenated SMS, but show higher latency. 1509 The DTLS handshake protocol adds a fragmentation and reassembly 1510 mechanism to the TLS handshake protocol since each DTLS record must 1511 fit within a single transport layer datagram, as described in 1512 Section 4.2.3 of [RFC6347]. Since handshake messages are potentially 1513 bigger than the maximum record size, the mechanism fragments a 1514 handshake message over a number of DTLS records, each of which can be 1515 transmitted separately. 1517 To deal with the unreliable message delivery provided by UDP, DTLS 1518 adds timeouts and re-transmissions, as described in Section 4.2.4 of 1519 [RFC6347]. Although the timeout values are implementation specific, 1520 recommendations are provided in Section 4.2.4.1 of [RFC6347], with an 1521 initial timer value of 1 second and doubled with at each 1522 retransmission up to no less than 60 seconds. Due to the nature of 1523 some radio technologies, these values are too aggressive and lead to 1524 spurious failures when messages in flight need longer. 1526 Note: If a round-trip time estimator (such as proposed in 1527 [I-D.bormann-core-cocoa]) is available in the protocol stack of the 1528 device, it could be used to dynamically update the setting of the 1529 retransmit timeout. 1531 Choosing appropriate timeout values is difficult with changing 1532 network conditions, and large variance in latency. This 1533 specification therefore RECOMMENDS an initial timer value of 10 1534 seconds with exponential back off up to no less then 60 seconds. 1535 Appendix A provides additional normative text for carrying DTLS over 1536 SMS. 1538 14. Random Number Generation 1540 The TLS/DTLS protocol requires random numbers to be available during 1541 the protocol run. For example, during the ClientHello and the 1542 ServerHello exchange the client and the server exchange random 1543 numbers. Also, the use of the Diffie-Hellman exchange requires 1544 random numbers during the key pair generation. Special care has to 1545 be taken when generating random numbers in embedded systems as many 1546 entropy sources available on desktop operating systems or mobile 1547 devices might be missing, as described in [Heninger]. Consequently, 1548 if not enough time is given during system start time to fill the 1549 entropy pool then the output might be predictable and repeatable, for 1550 example leading to the same keys generated again and again. 1552 It is important to note that sources contributing to the randomness 1553 pool on laptops, or desktop PCs are not available on many IoT device, 1554 such as mouse movement, timing of keystrokes, air turbulence on the 1555 movement of hard drive heads, etc. Other sources have to be found or 1556 dedicated hardware has to be added. 1558 The ClientHello and the ServerHello messages contains the 'Random' 1559 structure, which has two components: gmt_unix_time and a sequence of 1560 28 random bytes. gmt_unix_time holds the current time and date in 1561 standard UNIX 32-bit format (seconds since the midnight starting Jan 1562 1, 1970, GMT). [I-D.mathewson-no-gmtunixtime] argues that the entire 1563 ClientHello.Random value (including gmt_unix_time) should be a 1564 sequence of random bits because of device fingerprinting privacy 1565 concerns. Since many IoT devices do not have access to an accurate 1566 clock, it is RECOMMENDED to follow the guidance outlined in 1567 [I-D.mathewson-no-gmtunixtime] regarding the content of the 1568 ClientHello.Random field. However, for the ServerHello.Random 1569 structure it is RECOMMENDED to maintain the existing structure with 1570 gmt_unix_time followed by a sequence of 28 random bytes since the 1571 client can use the received time information to securely obtain time 1572 information. For constrained servers it cannot be assumed that they 1573 maintain accurate time information; these devices MUST include time 1574 information in the Server.Random structure when they actually obtain 1575 accurate time information that can be utilized by clients. Clients 1576 MUST only use time information obtained from servers they trust and 1577 the use of this approach has to be agreed out-of-band. 1579 IoT devices using TLS/DTLS MUST offer ways to generate quality random 1580 numbers using hardware-based random number generators. Note that 1581 these hardware-based random number generators do not necessarily need 1582 to be implemented inside the microcontroller itself but could be made 1583 available in dedicated crypto-chips as well. Guidelines and 1584 requirements for random number generation can be found in RFC 4086 1585 [RFC4086] and in the NIST Special Publication 800-90a [SP800-90A]. 1587 Chip manufacturers are highly encouraged to provide sufficient 1588 documentation of their design for random number generators so that 1589 customers can have confidence about the quality of the generated 1590 random numbers. The confidence can be increased by providing 1591 information about the procedures that have been used to verify the 1592 randomness of numbers generated by the hardware modules. For 1593 example, NIST Special Publication 800-22b [SP800-22b] describes 1594 statistical tests that can be used to verify random random number 1595 generators. 1597 15. Truncated MAC and Encrypt-then-MAC Extension 1599 The truncated MAC extension was introduced with RFC 6066 [RFC6066] 1600 with the goal to reduce the size of the MAC used at the Record Layer. 1601 This extension was developed for TLS ciphersuites that used older 1602 modes of operation where the MAC and the encryption operation was 1603 performed independently. 1605 The recommended ciphersuites in this document use the newer 1606 Authenticated Encryption with Associated Data (AEAD) construct, 1607 namely the CBC-MAC mode (CCM) with eight-octet authentication tags, 1608 and are therefore not applicable to the truncated MAC extension. 1610 RFC 7366 [RFC7366] introduced the encrypt-then-MAC extension (instead 1611 of the previously used MAC-then-encrypt) since the MAC-then-encrypt 1612 mechanism has been the subject of a number of security 1613 vulnerabilities. RFC 7366 is, however, also not applicable to the 1614 AEAD ciphers recommended in this document. 1616 Implementations conformant to this specification MUST use AEAD 1617 ciphers. Hence, RFC 7366 and RFC 6066 are not applicable to this 1618 specification and MUST NOT be implemented. 1620 16. Server Name Indication (SNI) 1622 The Server Name Indication extension defined in [RFC6066] defines a 1623 mechanism for a client to tell a TLS/DTLS server the name of the 1624 server it wants to contact. This is a useful extension for many 1625 hosting environments where multiple virtual servers are run on single 1626 IP address. 1628 This specification RECOMMENDs the implementation of the Server Name 1629 Indication extension unless it is known that a TLS/DTLS client does 1630 not interact with a server in a hosting environment. 1632 17. Maximum Fragment Length Negotiation 1634 This RFC 6066 extension lowers the maximum fragment length support 1635 needed for the Record Layer from 2^14 bytes to 2^9 bytes. 1637 This is a very useful extension that allows the client to indicate to 1638 the server how much maximum memory buffers it uses for incoming 1639 messages. Ultimately, the main benefit of this extension is to allow 1640 client implementations to lower their RAM requirements since the 1641 client does not need to accept packets of large size (such as 16k 1642 packets as required by plain TLS/DTLS). 1644 Client implementations MUST support this extension. 1646 18. Session Hash 1648 In order to begin connection protection, the Record Protocol requires 1649 specification of a suite of algorithms, a master secret, and the 1650 client and server random values. The algorithm for computing the 1651 master secret is defined in Section 8.1 of RFC 5246 but only includes 1652 a small number of parameters exchanged during the handshake and does 1653 not include parameters like the client and server identities. This 1654 can be utilized by an attacker to mount a man-in-the-middle attack 1655 since the master secret is not guaranteed to be unique across 1656 sessions, as discovered in the 'Triple Handshake' attack [Triple-HS]. 1658 [I-D.ietf-tls-session-hash] defines a TLS extension that binds the 1659 master secret to a log of the full handshake that computes it, thus 1660 preventing such attacks. 1662 Client implementations SHOULD implement this extension even though 1663 the ciphersuites recommended by this profile are not vulnerable to 1664 this attack. For Diffie-Hellman-based ciphersuites the keying 1665 material is contributed by both parties and in case of the pre-shared 1666 secret key ciphersuite, both parties need to be in possession of the 1667 shared secret to ensure that the handshake completes successfully. 1668 It is, however, possible that some application layer protocols will 1669 tunnel other authentication protocols on top of DTLS making this 1670 attack relevant again. 1672 19. Re-Negotiation Attacks 1674 TLS/DTLS allows a client and a server who already have a TLS/DTLS 1675 connection to negotiate new parameters, generate new keys, etc by 1676 using the re-negotiation feature. Renegotiation happens in the 1677 existing connection, with the new handshake packets being encrypted 1678 along with application data. Upon completion of the re-negotiation 1679 procedure the new channel replaces the old channel. 1681 As described in RFC 5746 [RFC5746] there is no cryptographic binding 1682 between the two handshakes, although the new handshake is carried out 1683 using the cryptographic parameters established by the original 1684 handshake. 1686 To prevent the re-negotiation attack [RFC5746] this specification 1687 RECOMMENDS to disable the TLS renegotiation feature. Clients MUST 1688 respond to server-initiated re-negotiation attempts with an alert 1689 message (no_renegotiation) and clients MUST NOT initiate them. 1691 20. Downgrading Attacks 1693 When a client sends a ClientHello with a version higher than the 1694 highest version known to the server, the server is supposed to reply 1695 with ServerHello.version equal to the highest version known to the 1696 server and the handshake can proceed. This behavior is known as 1697 version tolerance. Version-intolerance is when the server (or a 1698 middlebox) breaks the handshake when it sees a ClientHello.version 1699 higher than what it knows about. This is the behavior that leads 1700 some clients to re-run the handshake with lower version. As a 1701 result, a potential security vulnerability is introduced when a 1702 system is running an old TLS/SSL version (e.g., because of the need 1703 to integrate with legacy systems). In the worst case, this allows an 1704 attacker to downgrade the protocol handshake to SSL 3.0. SSL 3.0 is 1705 so broken that there is no secure cipher available for it (see 1706 [I-D.ietf-tls-sslv3-diediedie]). 1708 The above-described downgrade vulnerability is solved by the TLS 1709 Fallback Signaling Cipher Suite Value (SCSV) [RFC7507] extension. 1710 However, the solution is not applicable to implementations conforming 1711 to this profile since the version negotiation MUST use TLS/DTLS 1712 version 1.2 (or higher). More specifically, this implies: 1714 o Clients MUST NOT send a TLS/DTLS version lower than version 1.2 in 1715 the ClientHello. 1717 o Clients MUST NOT retry a failed negotiation offering a TLS/DTLS 1718 version lower than 1.2. 1720 o Servers MUST fail the handshake by sending a protocol_version 1721 fatal alert if a TLS/DTLS version >= 1.2 cannot be negotiated. 1722 Note that the aborted connection is non-resumable. 1724 If at some time in the future this profile reaches the quality of SSL 1725 3.0 a software update is needed since constrained devices are 1726 unlikely to run multiple TLS/DTLS versions due to memory size 1727 restrictions. 1729 21. Crypto Agility 1731 This document recommends software and chip manufacturers to implement 1732 AES and the CCM mode of operation. This document references the CoAP 1733 recommended ciphersuite choices, which have been selected based on 1734 implementation and deployment experience from the IoT community. 1735 Over time the preference for algorithms will, however, change. Not 1736 all components of a ciphersuite are likely to change at the same 1737 speed. Changes are more likely expected for ciphers, the mode of 1738 operation, and the hash algorithms. The recommended key lengths have 1739 to be adjusted over time. Some deployment environments will also be 1740 impacted by local regulation, which might dictate a certain cipher 1741 and key size. Ongoing discussions regarding the choice of specific 1742 ECC curves will also likely impact implementations. Note that this 1743 document does not recommend or mandate a specific ECC curve. 1745 The following recommendations can be made to chip manufacturers: 1747 o Make any AES hardware-based crypto implementation accessible to 1748 developers working on security implementations at higher layers. 1749 Sometimes hardware implementations are added to microcontrollers 1750 to offer support for functionality needed at the link layer and 1751 are only available to the on-chip link layer protocol 1752 implementation. 1754 o Provide flexibility for the use of the crypto function with future 1755 extensibility in mind. For example, making an AES-CCM 1756 implementation available to developers is a first step but such an 1757 implementation may not be usable due to parameter differences 1758 between an AES-CCM implementations. AES-CCM in IEEE 802.15.4 and 1759 Bluetooth Smart uses a nonce length of 13-octets while DTLS uses a 1760 nonce length of 12-octets. Hardware implementations of AES-CCM 1761 for IEEE 802.15.4 and Bluetooth Smart are therefore not re-usable 1762 by a DTLS stack. 1764 o Offer access to building blocks in addition (or as an alternative) 1765 to the complete functionality. For example, a chip manufacturer 1766 who gives developers access to the AES crypto function can use it 1767 to build an efficient AES-GCM implementations. Another example is 1768 to make a special instruction available that increases the speed 1769 of speed-up carryless multiplications. 1771 As a recommendation for developers and product architects we 1772 recommend that sufficient headroom is provided to allow an upgrade to 1773 a newer cryptographic algorithms over the lifetime of the product. 1774 As an example, while AES-CCM is recommended throughout this 1775 specification future products might use the ChaCha20 cipher in 1776 combination with the Poly1305 authenticator [RFC7539]. The 1777 assumption is made that a robust software update mechanism is 1778 offered. 1780 22. Key Length Recommendations 1782 RFC 4492 [RFC4492] gives approximate comparable key sizes for 1783 symmetric- and asymmetric-key cryptosystems based on the best-known 1784 algorithms for attacking them. While other publications suggest 1785 slightly different numbers, such as [Keylength], the approximate 1786 relationship still holds true. Figure 11 illustrates the comparable 1787 key sizes in bits. 1789 Symmetric | ECC | DH/DSA/RSA 1790 ------------+---------+------------- 1791 80 | 163 | 1024 1792 112 | 233 | 2048 1793 128 | 283 | 3072 1794 192 | 409 | 7680 1795 256 | 571 | 15360 1797 Figure 11: Comparable Key Sizes (in bits) based on RFC 4492. 1799 At the time of writing the key size recommendations for use with TLS- 1800 based ciphers found in [RFC7525] recommend DH key lengths of at least 1801 2048 bit, which corresponds to a 112-bit symmetric key and a 233 bit 1802 ECC key. These recommendations are roughly inline with those from 1803 other organizations, such as the National Institute of Standards and 1804 Technology (NIST) or the European Network and Information Security 1805 Agency (ENISA). The authors of [ENISA-Report2013] add that a 80-bit 1806 symmetric key is sufficient for legacy applications for the coming 1807 years, but a 128-bit symmetric key is the minimum requirement for new 1808 systems being deployed. The authors further note that one needs to 1809 also take into account the length of time data needs to be kept 1810 secure for. The use of 80-bit symmetric keys for transactional data 1811 may be acceptable for the near future while one has to insist on 1812 128-bit symmetric keys for long lived data. 1814 Note that the recommendations for 112-bit symmetric keys are chosen 1815 conservatively under the assumption that IoT devices have a long 1816 expected lifetime (such as 10+ years) and that this key length 1817 recommendation refers to the long-term keys used for device 1818 authentication. Keys, which are provisioned dynamically, for the 1819 protection of transactional data (such as ephemeral Diffie-Hellman 1820 keys used in various TLS/DTLS ciphersuites) may be shorter 1821 considering the sensitivity of the exchanged data. 1823 23. False Start 1825 A full TLS handshake as specified in [RFC5246] requires two full 1826 protocol rounds (four flights) before the handshake is complete and 1827 the protocol parties may begin to send application data. 1829 An abbreviated handshake (resuming an earlier TLS session) is 1830 complete after three flights, thus adding just one round-trip time if 1831 the client sends application data first. 1833 If the conditions outlined in [I-D.bmoeller-tls-falsestart] are met, 1834 application data can be transmitted when the sender has sent its own 1835 "ChangeCipherSpec" and "Finished" messages. This achieves an 1836 improvement of one round-trip time for full handshakes if the client 1837 sends application data first, and for abbreviated handshakes if the 1838 server sends application data first. 1840 The conditions for using the TLS False Start mechanism are met by the 1841 public-key-based ciphersuites in this document. In summary, the 1842 conditions are 1844 o Modern symmetric ciphers with an effective key length of 128 bits, 1845 such as AES-128-CCM 1847 o Client certificate types, such as ecdsa_sign 1849 o Key exchange methods, such as ECDHE_ECDSA 1851 Based on the improvement over a full round-trip for the full TLS/DTLS 1852 exchange this specification RECOMMENDS the use of the False Start 1853 mechanism when clients send application data first. 1855 24. Privacy Considerations 1857 The DTLS handshake exchange conveys various identifiers, which can be 1858 observed by an on-path eavesdropper. For example, the DTLS PSK 1859 exchange reveals the PSK identity, the supported extensions, the 1860 session id, algorithm parameters, etc. When session resumption is 1861 used then individual TLS sessions can be correlated by an on-path 1862 adversary. With many IoT deployments it is likely that keying 1863 material and their identifiers are persistent over a longer period of 1864 time due to the cost of updating software on these devices. 1866 User participation with many IoT deployments poses a challenge since 1867 many of the IoT devices operate unattended, even though they will 1868 initially be provisioned by a human. The ability to control data 1869 sharing and to configure preference will have to be provided at a 1870 system level rather than at the level of the DTLS exchange itself, 1871 which is the scope of this document. Quite naturally, the use of 1872 DTLS with mutual authentication will allow a TLS server to collect 1873 authentication information about the IoT device (likely over a long 1874 period of time). While this strong form of authentication will 1875 prevent mis-attribution, it also allows strong identification. 1876 Device-related data collection (e.g., sensor recordings) associated 1877 with other data type will prove to be truly useful but this extra 1878 data might include personal information about the owner of the device 1879 or data about the environment it senses. Consequently, the data 1880 stored on the server-side will be vulnerable to stored data 1881 compromise. For the communication between the client and the server 1882 this specification prevents eavesdroppers to gain access to the 1883 communication content. While the PSK-based ciphersuite does not 1884 provide PFS the asymmetric versions do. This prevents an adversary 1885 from obtaining past communication content when access to a long-term 1886 secret has been gained. Note that no extra effort to make traffic 1887 analysis more difficult is provided by the recommendations made in 1888 this document. 1890 25. Security Considerations 1892 This entire document is about security. 1894 We would also like to point out that designing a software update 1895 mechanism into an IoT system is crucial to ensure that both 1896 functionality can be enhanced and that potential vulnerabilities can 1897 be fixed. This software update mechanism is important for changing 1898 configuration information, for example, trust anchors and other 1899 keying related information. Such a suitable software update 1900 mechanism is available with the Lightweight Machine-to-Machine 1901 (LWM2M) protocol published by the Open Mobile Alliance (OMA) [LWM2M]. 1903 26. IANA Considerations 1905 This document includes no request to IANA. 1907 27. Acknowledgments 1909 Thanks to Derek Atkins, Olaf Bergmann, Paul Bakker, Robert Cragie, 1910 Russ Housley, Rene Hummen, Jayaraghavendran K, Matthias Kovatsch, 1911 Sandeep Kumar, Sye Loong Keoh, Simon Lemay, Alexey Melnikov, Manuel 1912 Pegourie-Gonnard, Akbar Rahman, Eric Rescorla, Michael Richardson, 1913 Ludwig Seitz, Zach Shelby, Michael StJohns, Rene Struik, and Sean 1914 Turner for their helpful comments and discussions that have shaped 1915 the document. 1917 Big thanks also to Klaus Hartke, who wrote the initial version of 1918 this document. 1920 Finally, we would like to thank our area director (Stephen Farrell) 1921 and our working group chairs (Zach Shelby and Dorothy Gellert) for 1922 their support. 1924 28. References 1926 28.1. Normative References 1928 [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 1929 REGISTRATION AUTHORITY", April 2010, 1930 . 1933 [GSM-SMS] ETSI, "3GPP TS 23.040 V7.0.1 (2007-03): 3rd Generation 1934 Partnership Project; Technical Specification Group Core 1935 Network and Terminals; Technical realization of the Short 1936 Message Service (SMS) (Release 7)", March 2007. 1938 [I-D.ietf-tls-cached-info] 1939 Santesson, S. and H. Tschofenig, "Transport Layer Security 1940 (TLS) Cached Information Extension", draft-ietf-tls- 1941 cached-info-19 (work in progress), March 2015. 1943 [I-D.ietf-tls-session-hash] 1944 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 1945 A., and M. Ray, "Transport Layer Security (TLS) Session 1946 Hash and Extended Master Secret Extension", draft-ietf- 1947 tls-session-hash-05 (work in progress), April 2015. 1949 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1950 Requirement Levels", BCP 14, RFC 2119, March 1997. 1952 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 1953 for Transport Layer Security (TLS)", RFC 4279, December 1954 2005. 1956 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1957 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1959 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 1960 "Transport Layer Security (TLS) Renegotiation Indication 1961 Extension", RFC 5746, February 2010. 1963 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1964 Extension Definitions", RFC 6066, January 2011. 1966 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1967 Verification of Domain-Based Application Service Identity 1968 within Internet Public Key Infrastructure Using X.509 1969 (PKIX) Certificates in the Context of Transport Layer 1970 Security (TLS)", RFC 6125, March 2011. 1972 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1973 Security Version 1.2", RFC 6347, January 2012. 1975 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 1976 Layer Security (TLS) and Datagram Transport Layer Security 1977 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 1979 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 1980 T. Kivinen, "Using Raw Public Keys in Transport Layer 1981 Security (TLS) and Datagram Transport Layer Security 1982 (DTLS)", RFC 7250, June 2014. 1984 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 1985 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 1986 TLS", RFC 7251, June 2014. 1988 [WAP-WDP] Wireless Application Protocol Forum, "Wireless Datagram 1989 Protocol", June 2001. 1991 28.2. Informative References 1993 [ACE-WG] IETF, "Authentication and Authorization for Constrained 1994 Environments (ace) Working Group", URL: 1995 https://datatracker.ietf.org/wg/ace/charter/, Jan 2015. 1997 [AES] National Institute of Standards and Technology, "FIPS PUB 1998 197, Advanced Encryption Standard (AES)", 1999 http://www.iana.org/assignments/tls-parameters/ 2000 tls-parameters.xhtml#tls-parameters-4, November 2001. 2002 [CCM] National Institute of Standards and Technology, "Special 2003 Publication 800-38C, Recommendation for Block Cipher Modes 2004 of Operation: The CCM Mode for Authentication and 2005 Confidentiality", http://csrc.nist.gov/publications/ 2006 nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf, May 2007 2004. 2009 [ENISA-Report2013] 2010 ENISA, "Algorithms, Key Sizes and Parameters Report - 2011 2013", http://www.enisa.europa.eu/activities/identity-and- 2012 trust/library/deliverables/ 2013 algorithms-key-sizes-and-parameters-report, October 2013. 2015 [Heninger] 2016 Heninger, N., Durumeric, Z., Wustrow, E., and A. 2017 Halderman, "Mining Your Ps and Qs: Detection of Widespread 2018 Weak Keys in Network Devices", 21st USENIX Security 2019 Symposium, 2020 https://www.usenix.org/conference/usenixsecurity12/ 2021 technical-sessions/presentation/heninger, 2012. 2023 [HomeGateway] 2024 Eggert, L., "An experimental study of home gateway 2025 characteristics, In Proceedings of the '10th annual 2026 conference on Internet measurement'", 2010. 2028 [I-D.bmoeller-tls-falsestart] 2029 Langley, A., Modadugu, N., and B. Moeller, "Transport 2030 Layer Security (TLS) False Start", draft-bmoeller-tls- 2031 falsestart-01 (work in progress), November 2014. 2033 [I-D.bormann-core-cocoa] 2034 Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, 2035 "CoAP Simple Congestion Control/Advanced", draft-bormann- 2036 core-cocoa-02 (work in progress), July 2014. 2038 [I-D.ietf-core-resource-directory] 2039 Shelby, Z. and C. Bormann, "CoRE Resource Directory", 2040 draft-ietf-core-resource-directory-02 (work in progress), 2041 November 2014. 2043 [I-D.ietf-tls-negotiated-dl-dhe] 2044 Gillmor, D., "Negotiated Discrete Log Diffie-Hellman 2045 Ephemeral Parameters for TLS", draft-ietf-tls-negotiated- 2046 dl-dhe-00 (work in progress), July 2014. 2048 [I-D.ietf-tls-sslv3-diediedie] 2049 Barnes, R., Thomson, M., Pironti, A., and A. Langley, 2050 "Deprecating Secure Sockets Layer Version 3.0", draft- 2051 ietf-tls-sslv3-diediedie-03 (work in progress), April 2052 2015. 2054 [I-D.irtf-cfrg-curves] 2055 Langley, A. and R. Salz, "Elliptic Curves for Security", 2056 draft-irtf-cfrg-curves-02 (work in progress), March 2015. 2058 [I-D.josefsson-eddsa-ed25519] 2059 Josefsson, S. and N. Moller, "EdDSA and Ed25519", draft- 2060 josefsson-eddsa-ed25519-03 (work in progress), May 2015. 2062 [I-D.mathewson-no-gmtunixtime] 2063 Mathewson, N. and B. Laurie, "Deprecating gmt_unix_time in 2064 TLS", draft-mathewson-no-gmtunixtime-00 (work in 2065 progress), December 2013. 2067 [I-D.schmertmann-dice-ccm-psk-pfs] 2068 Schmertmann, L. and C. Bormann, "ECDHE-PSK AES-CCM Cipher 2069 Suites with Forward Secrecy for Transport Layer Security 2070 (TLS)", draft-schmertmann-dice-ccm-psk-pfs-01 (work in 2071 progress), August 2014. 2073 [IANA-TLS] 2074 IANA, "TLS Cipher Suite Registry", 2075 http://www.iana.org/assignments/tls-parameters/ 2076 tls-parameters.xhtml#tls-parameters-4, 2014. 2078 [ImprintingSurvey] 2079 Chilton, E., "A Brief Survey of Imprinting Options for 2080 Constrained Devices", URL: http://www.lix.polytechnique.fr 2081 /hipercom/SmartObjectSecurity/papers/EricRescorla.pdf, 2082 March 2012. 2084 [Keylength] 2085 Giry, D., "Cryptographic Key Length Recommendations", 2086 http://www.keylength.com, November 2014. 2088 [LWM2M] Open Mobile Alliance, "Lightweight Machine-to-Machine, 2089 Technical Specification, Candidate Version 1.0", December 2090 2013. 2092 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2093 November 1990. 2095 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 2096 for IP version 6", RFC 1981, August 1996. 2098 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2099 Hashing for Message Authentication", RFC 2104, February 2100 1997. 2102 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2103 "Remote Authentication Dial In User Service (RADIUS)", RFC 2104 2865, June 2000. 2106 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 2107 CBC-MAC (CCM)", RFC 3610, September 2003. 2109 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2110 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 2111 3748, June 2004. 2113 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 2114 Requirements for Security", BCP 106, RFC 4086, June 2005. 2116 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 2117 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 2118 for Transport Layer Security (TLS)", RFC 4492, May 2006. 2120 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 2121 over Low-Power Wireless Personal Area Networks (6LoWPANs): 2122 Overview, Assumptions, Problem Statement, and Goals", RFC 2123 4919, August 2007. 2125 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 2126 "Transport Layer Security (TLS) Session Resumption without 2127 Server-Side State", RFC 5077, January 2008. 2129 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 2130 Encryption", RFC 5116, January 2008. 2132 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 2133 Authentication Protocol", RFC 5216, March 2008. 2135 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 2136 Authentication Protocol (EAP) Key Management Framework", 2137 RFC 5247, August 2008. 2139 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2140 Housley, R., and W. Polk, "Internet X.509 Public Key 2141 Infrastructure Certificate and Certificate Revocation List 2142 (CRL) Profile", RFC 5280, May 2008. 2144 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 2145 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 2146 August 2008. 2148 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 2149 "Elliptic Curve Cryptography Subject Public Key 2150 Information", RFC 5480, March 2009. 2152 [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. 2153 Polk, "Internet X.509 Public Key Infrastructure: 2154 Additional Algorithms and Identifiers for DSA and ECDSA", 2155 RFC 5758, January 2010. 2157 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 2158 Management Protocol (TAMP)", RFC 5934, August 2010. 2160 [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management 2161 Requirements", RFC 6024, October 2010. 2163 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 2164 Curve Cryptography Algorithms", RFC 6090, February 2011. 2166 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 2167 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 2169 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 2170 Transport Layer Security (TLS)", RFC 6655, July 2012. 2172 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 2173 Format", RFC 6690, August 2012. 2175 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 2176 "Diameter Base Protocol", RFC 6733, October 2012. 2178 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 2179 Multiple Certificate Status Request Extension", RFC 6961, 2180 June 2013. 2182 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2183 Constrained-Node Networks", RFC 7228, May 2014. 2185 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2186 Application Protocol (CoAP)", RFC 7252, June 2014. 2188 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2189 Attack", BCP 188, RFC 7258, May 2014. 2191 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer 2192 Security (TLS) and Datagram Transport Layer Security 2193 (DTLS)", RFC 7366, September 2014. 2195 [RFC7390] Rahman, A. and E. Dijk, "Group Communication for the 2196 Constrained Application Protocol (CoAP)", RFC 7390, 2197 October 2014. 2199 [RFC7397] Gilger, J. and H. Tschofenig, "Report from the Smart 2200 Object Security Workshop", RFC 7397, December 2014. 2202 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 2203 IPv6 over Low-Power Wireless Personal Area Networks 2204 (6LoWPANs)", RFC 7400, November 2014. 2206 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 2207 "Architectural Considerations in Smart Object Networking", 2208 RFC 7452, March 2015. 2210 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, 2211 February 2015. 2213 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 2214 Suite Value (SCSV) for Preventing Protocol Downgrade 2215 Attacks", RFC 7507, April 2015. 2217 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2218 "Recommendations for Secure Use of Transport Layer 2219 Security (TLS) and Datagram Transport Layer Security 2220 (DTLS)", BCP 195, RFC 7525, May 2015. 2222 [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 2223 Protocols", RFC 7539, May 2015. 2225 [SP800-22b] 2226 National Institute of Standards and Technology, "Special 2227 Publication 800-22, Revision 1a, A Statistical Test Suite 2228 for Random and Pseudorandom Number Generators for 2229 Cryptographic Applications", 2230 http://csrc.nist.gov/publications/nistpubs/800-22-rev1a/ 2231 SP800-22rev1a.pdf, April 2010. 2233 [SP800-90A] 2234 NIST, "DRAFT Special Publication 800-90a, Revision 1, 2235 Recommendation for Random Number Generation Using 2236 Deterministic Random Bit Generators", 2237 http://csrc.nist.gov/publications/drafts/800-90/ 2238 sp800-90a_r1_draft_november2014_ver.pdf, November 2014. 2240 [Triple-HS] 2241 Bhargavan, K., Delignat-Lavaud, C., Pironti, A., and P. 2242 Strub, "Triple Handshakes and Cookie Cutters: Breaking and 2243 Fixing Authentication over TLS", IEEE Symposium on 2244 Security and Privacy, pages 98-113, 2014. 2246 Appendix A. Conveying DTLS over SMS 2248 This section is normative for the use of DTLS over SMS. Timer 2249 recommendations are already outlined in Section 13 and also 2250 applicable to the transport of DTLS over SMS. 2252 This section requires readers to be familiar with the terminology and 2253 concepts described in [GSM-SMS], and [WAP-WDP]. 2255 The remainder of this section assumes Mobile Stations are capable of 2256 producing and consuming 8-bit binary data encoded Transport Protocol 2257 Data Units (TPDU). 2259 A.1. Overview 2261 DTLS adds an additional round-trip to the TLS [RFC5246] handshake to 2262 serve as a return-routability test for protection against certain 2263 types of DoS attacks. Thus a full blown DTLS handshake comprises up 2264 to 6 "flights" (i.e., logical message exchanges), each of which is 2265 then mapped on to one or more DTLS records using the segmentation and 2266 reassembly (SaR) scheme described in Section 4.2.3 of [RFC6347]. The 2267 overhead for said scheme is 6 bytes per Handshake message which, 2268 given a realistic 10+ messages handshake, would amount around 60 2269 bytes across the whole handshake sequence. 2271 Note that the DTLS SaR scheme is defined for handshake messages only. 2272 In fact, DTLS records are never fragmented and MUST fit within a 2273 single transport layer datagram. 2275 SMS provides an optional segmentation and reassembly scheme as well, 2276 known as Concatenated short messages (see Section 9.2.3.24.1 of 2277 [GSM-SMS]). However, since the SaR scheme in DTLS cannot be 2278 circumvented, the Concatenated short messages mechanism SHOULD NOT be 2279 used during handshake to avoid redundant overhead. Before starting 2280 the handshake phase (either actively or passively), the DTLS 2281 implementation MUST be explicitly configured with the PMTU of the SMS 2282 transport in order to correctly instrument its SaR function. The 2283 PMTU SHALL be 133 bytes if WDP-based multiplexing is used (see 2284 Appendix A.3), 140 bytes otherwise. 2286 It is RECOMMENDED to use the established security context over the 2287 longest possible period (possibly until a Closure Alert message is 2288 received, or after a very long inactivity timeout) to avoid the 2289 expensive re-establishment of the security association. 2291 A.2. Message Segmentation and Re-Assembly 2293 The content of an SMS message is carried in the TP-UserData field, 2294 and its size may be up to 140 bytes. As already mentioned in 2295 Appendix A.1, longer (i.e., up to 34170 bytes) messages can be sent 2296 using Concatenated SMS. 2298 This scheme consumes 6-7 bytes (depending on whether the short or 2299 long segmentation format is used) of the TP-UserData field, thus 2300 reducing the space available for the actual content of the SMS 2301 message to 133-134 bytes per TPDU. 2303 Though in principle a PMTU value higher than 140 bytes could be used, 2304 which may look like an appealing option given its more efficient use 2305 of the transport, there are disadvantages to consider. First, there 2306 is an additional overhead of 7 bytes per TPDU to be paid to the SaR 2307 function (which is in addition to the overhead introduced by the DTLS 2308 SaR mechanism. Second, some networks only partially support the 2309 Concatenated SMS function and others do not support it at all. 2311 For these reasons, the Concatenated short messages mechanism SHOULD 2312 NOT be used, and it is RECOMMENDED to leave the same PMTU settings 2313 used during the handshake phase, i.e., 133 bytes if WDP- based 2314 multiplexing is enabled, 140 bytes otherwise. 2316 Note that, after DTLS handshake has completed, any fragmentation and 2317 reassembly logic that pertains the application layer (e.g., 2318 segmenting CoAP messages into DTLS records and reassembling them 2319 after the crypto operations have been successfully performed) needs 2320 to be handled by the application that uses the established DTLS 2321 tunnel. 2323 A.3. Multiplexing Security Associations 2325 Unlike IPsec ESP/AH, DTLS records do not contain any association 2326 identifiers. Applications must arrange to multiplex between 2327 associations on the same endpoint which, when using UDP/IP, is 2328 usually done with the host/port number. 2330 If the DTLS server allows more than one client to be active at any 2331 given time, then the WAP User Datagram Protocol [WAP-WDP] can be used 2332 to achieve multiplexing of the different security associations. (The 2333 use of WDP provides the additional benefit that upper layer protocols 2334 can operate independently of the underlying wireless network, hence 2335 achieving application-agnostic transport handover.) 2337 The total overhead cost for encoding the WDP source and destination 2338 ports is either 5 or 7 bytes out of the total available for the SMS 2339 content depending on if 1-byte or 2-byte port identifiers are used, 2340 as shown in Figure 12 and Figure 13. 2342 0 1 2 3 4 2343 +--------+--------+--------+--------+--------+ 2344 | ... | 0x04 | 2 | ... | ... | 2345 +--------+--------+--------+--------+--------+ 2346 UDH IEI IE Dest Source 2347 Length Length Port Port 2349 Figure 12: Application Port Addressing Scheme (8 bit address). 2351 0 1 2 3 4 5 6 2352 +--------+--------+--------+--------+--------+--------+--------+ 2353 | ... | 0x05 | 4 | ... | ... | 2354 +--------+--------+--------+--------+--------+--------+--------+ 2355 UDH IEI IE Dest Source 2356 Length Length Port Port 2358 Figure 13: Application Port Addressing Scheme (16 bit address). 2360 The receiving side of the communication gets the source address from 2361 the originator address (TP-OA) field of the SMS-DELIVER TPDU. This 2362 way an unique 4-tuple identifying the security association can be 2363 reconstructed at both ends. (When replying to its DTLS peer, the 2364 sender will swaps the TP-OA and TP-DA parameters and the source and 2365 destination ports in the WDP.) 2367 A.4. Timeout 2369 If SMS-STATUS-REPORT messages are enabled, their receipt is not to be 2370 interpreted as the signal that the specific handshake message has 2371 been acted upon by the receiving party. Therefore, it MUST NOT be 2372 taken into account by the DTLS timeout and retransmission function. 2374 Handshake messages MUST carry a validity period (TP-VP parameter in a 2375 SMS-SUBMIT TPDU) that is not less than the current value of the 2376 retransmission timeout. In order to avoid persisting messages in the 2377 network that will be discarded by the receiving party, handshake 2378 messages SHOULD carry a validity period that is the same as, or just 2379 slightly higher than, the current value of the retransmission 2380 timeout. 2382 Appendix B. DTLS Record Layer Per-Packet Overhead 2384 Figure 14 shows the overhead for the DTLS record layer for protecting 2385 data traffic when AES-128-CCM with an 8-octet Integrity Check Value 2386 (ICV) is used. 2388 DTLS Record Layer Header................13 bytes 2389 Nonce (Explicit).........................8 bytes 2390 ICV..................................... 8 bytes 2391 ------------------------------------------------ 2392 Overhead................................29 bytes 2393 ------------------------------------------------ 2395 Figure 14: AES-128-CCM-8 DTLS Record Layer Per-Packet Overhead. 2397 The DTLS record layer header has 13 octets and consists of 2399 o 1 octet content type field, 2401 o 2 octet version field, 2403 o 2 octet epoch field, 2405 o 6 octet sequence number, 2407 o 2 octet length field. 2409 The "nonce" input to the AEAD algorithm is exactly that of [RFC5288], 2410 i.e., 12 bytes long. It consists of two values, namely a 4 octet 2411 salt and an 8 octet nonce_explicit: 2413 The salt is the "implicit" part and is not sent in the packet. 2414 Instead, the salt is generated as part of the handshake process. 2416 The nonce_explicit value is 8 octet long and it is chosen by the 2417 sender and carried in each TLS record. RFC 6655 [RFC6655] allows 2418 the nonce_explicit to be a sequence number or something else. 2419 This document makes this use more restrictive for use with DTLS: 2420 the 64-bit none_explicit value MUST be the 16-bit epoch 2421 concatenated with the 48-bit seq_num. The sequence number 2422 component of the nonce_explicit field at the AES-CCM layer is an 2423 exact copy of the sequence number in the record layer header 2424 field. This leads to a duplication of 8-bytes per record. 2426 To avoid this 8-byte duplication RFC 7400 [RFC7400] provides help 2427 with the use of the generic header compression technique for IPv6 2428 over Low-Power Wireless Personal Area Networks (6LoWPANs). Note 2429 that this header compression technique is not available when DTLS 2430 is exchanged over transports that do not use IPv6 or 6LoWPAN, such 2431 as the SMS transport described in Appendix A. 2433 Appendix C. DTLS Fragmentation 2435 [Editor's Note: Proposed text that requires discussion. ] 2437 Section 4.2.3 of [RFC6347] advises DTLS implementations to not 2438 produce overlapping fragments, but requires receivers to be able to 2439 cope with them. The need for the latter requisite is explained in 2440 Section 4.1.1.1 of [RFC6347]: accurate path MTU (PMTU) estimation may 2441 be traded for shorter handshake completion time. This approach may 2442 be beneficial in unconstrained networks where a PMTU of 1280 bytes 2443 can be pretty much universally assumed. However, an handshake that 2444 is carried over a narrow-band radio technology, such as IEEE 2445 802.15.4, Bluetooth Smart or GSM-SMS, and the client is lacking 2446 reliable PMTU data to inform fragmentation (e.g., using [RFC1981] or 2447 [RFC1191]) can place a cost on the constrained implementation in 2448 terms of memory (due to re-buffering) and latency (due to re- 2449 transmission) much higher than the benefit that it would get from a 2450 shorter handshake. 2452 In order to reduce the likelihood of producing different fragment 2453 sizes (and consequent overlaps) within the same handshake, this 2454 document RECOMMENDs: 2456 o for clients (handshake initiators), to perform PMTU discovery 2457 towards the server before handshake starts, and not rely on any 2458 guesses (unless the network path characteristics are reliably 2459 known from another source); 2461 o for servers, to mirror the fragment size selected by their 2462 clients. 2464 Authors' Addresses 2466 Hannes Tschofenig (editor) 2467 ARM Ltd. 2468 110 Fulbourn Rd 2469 Cambridge CB1 9NJ 2470 Great Britain 2472 Email: Hannes.tschofenig@gmx.net 2473 URI: http://www.tschofenig.priv.at 2475 Thomas Fossati 2476 Alcatel-Lucent 2477 3 Ely Road 2478 Milton, Cambridge CB24 6DD 2479 UK 2481 Email: thomas.fossati@alcatel-lucent.com