idnits 2.17.1 draft-ietf-dice-profile-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 28, 2015) is 3257 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 1329, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' -- Possible downref: Non-RFC (?) normative reference: ref. 'GSM-SMS' == Outdated reference: A later version (-23) exists of draft-ietf-tls-cached-info-19 == Outdated reference: A later version (-06) exists of draft-ietf-tls-session-hash-05 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Informational RFC: RFC 7251 -- Possible downref: Non-RFC (?) normative reference: ref. 'WAP-WDP' == Outdated reference: A later version (-04) exists of draft-bormann-core-cocoa-02 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-02 == Outdated reference: A later version (-11) exists of draft-irtf-cfrg-curves-02 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) -- Obsolete informational reference (is this intentional?): RFC 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 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 7539 (Obsoleted by RFC 8439) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dice H. Tschofenig, Ed. 3 Internet-Draft ARM Ltd. 4 Intended status: Standards Track T. Fossati 5 Expires: November 29, 2015 Alcatel-Lucent 6 May 28, 2015 8 A TLS/DTLS Profile for the Internet of Things 9 draft-ietf-dice-profile-12.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 November 29, 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 92 28. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 93 28.1. Normative References . . . . . . . . . . . . . . . . . . 43 94 28.2. Informative References . . . . . . . . . . . . . . . . . 44 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 authorisation 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 Resouce 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 certificate authority is omitted 985 from the chain. Client implementations MUST be provisioned with a 986 trust anchor store that contains the root certificates. The use of 987 the Trust Anchor Management Protocol (TAMP) [RFC5934] is, however, 988 not envisioned. Instead IoT devices using this profile MUST use a 989 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 For certificate revocation neither the Online Certificate Status 1098 Protocol (OCSP) nor Certificate Revocation Lists (CRLs) are used. 1099 Instead, this profile relies on a software update mechanism to 1100 provision information about revoked certificates. While multiple 1101 OCSP stapling [RFC6961] has recently been introduced as a mechanism 1102 to piggyback OCSP request/responses inside the DTLS/TLS handshake (to 1103 avoid the cost of a separate protocol handshake), further 1104 investigations are needed to determine its suitability for the IoT 1105 environment. 1107 6.3.3. Certificate Content 1109 All certificate elements listed in Table 1 are mandatory-to-implement 1110 for client and servers claiming support for certificate-based 1111 authentication. No other certificate elements are used by this 1112 specification. 1114 When using certificates, IoT devices MUST provide support for a 1115 server certificate chain of at least 3 not including the trust anchor 1116 and MAY reject connections from servers offering chains longer than 1117 3. IoT devices MAY have client certificate chains of any length. 1118 Obviously, longer chains require more digital signature verification 1119 operations to perform and lead to larger certificate messages in the 1120 TLS handshake. 1122 Table 1 provides a summary of the elements in a certificate for use 1123 with this profile. 1125 +----------------------+--------------------------------------------+ 1126 | Element | Notes | 1127 +----------------------+--------------------------------------------+ 1128 | version | This profile uses X.509 v3 certificates | 1129 | | [RFC5280]. | 1130 | | | 1131 | serialNumber | Positive integer unique per certificate. | 1132 | | | 1133 | signature | This field contains the signature | 1134 | | algorithm and this profile uses ecdsa- | 1135 | | with-SHA256 or stronger [RFC5758]. | 1136 | | | 1137 | issuer | Contains the DN of the issuing CA. | 1138 | | | 1139 | validity | Values expressed as UTC time in notBefore | 1140 | | and notAfter fields. No validity period | 1141 | | mandated. | 1142 | | | 1143 | subject | See rules outlined in this section. | 1144 | | | 1145 | subjectPublicKeyInfo | The SubjectPublicKeyInfo structure | 1146 | | indicates the algorithm and any associated | 1147 | | parameters for the ECC public key.This | 1148 | | profile uses the id-ecPublicKey algorithm | 1149 | | identifier for ECDSA signature keys, as | 1150 | | defined in specified in [RFC5480]. | 1151 | | | 1152 | signatureAlgorithm | The ECDSA signature algorithm with ecdsa- | 1153 | | with-SHA256 or stronger. | 1154 | | | 1155 | signatureValue | Bit string containing the digital | 1156 | | signature. | 1157 | | | 1158 | Extension: | See rules outlined in this section. | 1159 | subjectAltName | | 1160 | | | 1161 | Extension: | Indicates whether the subject of the | 1162 | BasicConstraints | certificate is a CA and the maximum depth | 1163 | | of valid certification paths that include | 1164 | | this certificate. This extension is used | 1165 | | for CA certs only and then the value of | 1166 | | the 'cA' field is set to TRUE. The default | 1167 | | is FALSE. | 1168 | | | 1169 | Extension: Key Usage | The KeyUsage field MAY have the following | 1170 | | values in the context of this profile: | 1171 | | digitalSignature or keyAgreement, | 1172 | | keyCertSign for verifying signatures on | 1173 | | public key certificates. | 1174 | | | 1175 | Extension: Extended | The ExtKeyUsageSyntax field MAY have the | 1176 | Key Usage | following values in context of this | 1177 | | profile: id-kp-serverAuth for server | 1178 | | authentication, id-kp-clientAuth for | 1179 | | client authentication, id-kp-codeSigning | 1180 | | for code signing (for software update | 1181 | | mechanism), id-kp-OCSPSigning for future | 1182 | | OCSP usage in TLS. | 1183 +----------------------+--------------------------------------------+ 1185 Table 1: Certificate Content. 1187 There are various algorithms used to sign digital certificates, such 1188 as RSA, the Digital Signature Algorithm (DSA), and the Elliptic Curve 1189 Digital Signature Algorithm (ECDSA). As Table 1 indicates 1190 certificate are signed using ECDSA. This is not only true for the 1191 end-entity certificates but also for all other certificates in the 1192 chain, including CA certificates. 1194 Further details about X.509 certificates can be found in 1195 Section 9.1.3.3 of [RFC7252]. 1197 6.3.4. Client Certificate URLs 1199 RFC 6066 [RFC6066] allows to avoid sending client-side certificates 1200 and uses URLs instead. This reduces the over-the-air transmission. 1201 Note that the TLS cached info extension does not provide any help 1202 with caching client certificates. 1204 TLS/DTLS clients MUST implement support for client certificate URLs 1205 for those environments where client-side certificates are used and 1206 the server-side is not constrained. For constrained servers this 1207 functionality is NOT RECOMMENDED since it forces the server to 1208 execute an additional protocol exchange, potentially using a protocol 1209 it does not even support. The use of this extension also increases 1210 the risk of a denial of service attack against the constrained server 1211 due to the additional workload. 1213 6.3.5. Trusted CA Indication 1215 RFC 6066 [RFC6066] allows clients to indicate what trust anchor they 1216 support. With certificate-based authentication a DTLS server conveys 1217 its end entity certificate to the client during the DTLS exchange 1218 provides. Since the server does not necessarily know what trust 1219 anchors the client has stored and to facilitate certification path 1220 construction as well as path validation, it includes intermediate CA 1221 certs in the certificate payload. 1223 Today, in most IoT deployments there is a fairly static relationship 1224 between the IoT device (and the software running on them) and the 1225 server-side infrastructure. For these deployments where IoT devices 1226 interact with a fixed, pre-configured set of servers this extension 1227 is NOT RECOMMENDED. 1229 In cases where client interact with dynamically discovered TLS/DTLS 1230 servers, for example in the use cases described in Section 4.2, the 1231 use of this extension is RECOMMENDED. 1233 7. Signature Algorithm Extension 1235 The "signature_algorithms" extension, defined in Section 7.4.1.4.1 of 1236 RFC 5246 [RFC5246], allows the client to indicate to the server which 1237 signature/hash algorithm pairs may be used in digital signatures. 1238 The client MUST send this extension to select the use of SHA-256 1239 since otherwise absent this extension RFC 5246 defaults to SHA-1 / 1240 ECDSA for the ECDH_ECDSA and the ECDHE_ECDSA key exchange algorithms. 1242 The "signature_algorithms" extension is not applicable to the PSK- 1243 based ciphersuite described in Section 6.1. 1245 8. Error Handling 1247 TLS/DTLS uses the Alert protocol to convey errors and specifies a 1248 long list of error types. However, not all error messages defined in 1249 the TLS/DTLS specification are applicable to this profile. In 1250 general, there are two categories of errors (as defined in 1251 Section 7.2 of RFC 5246), namely fatal errors and warnings. Alert 1252 messages with a level of fatal result in the immediate termination of 1253 the connection. If possible, developers should try to develop 1254 strategies to react to those fatal errors, such as re-starting the 1255 handshake or informing the user using the (often limited) user 1256 interface. Warnings may be ignored by the application since many IoT 1257 devices will either have limited ways to log errors or no ability at 1258 all. In any case, implementers have to carefully evaluate the impact 1259 of errors and ways to remedy the situation since a commonly used 1260 approach for delegating decision making to users is difficult (or 1261 impossible) to accomplish in a timely fashion. 1263 All error messages marked as RESERVED are only supported for 1264 backwards compatibility with SSL MUST NOT be used with this profile. 1265 Those include decryption_failed_RESERVED, no_certificate_RESERVED, 1266 and export_restriction_RESERVED. 1268 A number of the error messages MUST only be used for certificate- 1269 based ciphersuites. Hence, the following error messages MUST NOT be 1270 used with with PSK and raw public key authentication: 1272 o bad_certificate, 1274 o unsupported_certificate, 1276 o certificate_revoked, 1277 o certificate_expired, 1279 o certificate_unknown, 1281 o unknown_ca, and 1283 o access_denied. 1285 Since this profile does not make use of compression at the TLS layer 1286 the decompression_failure error message MUST NOT be used either. 1288 RFC 4279 introduced a new alert message unknown_psk_identity for PSK 1289 ciphersuites. As stated in Section 2 of RFC 4279 the 1290 decryption_error error message may also be used instead. For this 1291 profile the TLS server MUST return the decryption_error error message 1292 instead of the unknown_psk_identity since the two mechanisms exist 1293 and provide the same functionality. 1295 Furthermore, the following errors should not occur with devices and 1296 servers supporting this specification but implementations MUST be 1297 prepared to process these errors to deal with servers that are not 1298 compliant to the profiles in this document: 1300 protocol_version: While this document focuses only on one version of 1301 the TLS/DTLS protocol, namely version 1.2, ongoing work on TLS/ 1302 DTLS 1.3 is in progress at the time of writing. 1304 insufficient_security: This error message indicates that the server 1305 requires ciphers to be more secure. This document specifies only 1306 one ciphersuite per profile but it is likely that additional 1307 ciphtersuites get added over time. 1309 user_canceled: Many IoT devices are unattended and hence this error 1310 message is unlikely to occur. 1312 9. Session Resumption 1314 Session resumption is a feature of the core TLS/DTLS specifications 1315 that allows a client to continue with an earlier established session 1316 state. The resulting exchange is shown in Figure 10. In addition, 1317 the server may choose not to do a cookie exchange when a session is 1318 resumed. Still, clients have to be prepared to do a cookie exchange 1319 with every handshake. The cookie exchange is not shown in the 1320 figure. 1322 Client Server 1323 ------ ------ 1325 ClientHello --------> 1326 ServerHello 1327 [ChangeCipherSpec] 1328 <-------- Finished 1329 [ChangeCipherSpec] 1330 Finished --------> 1331 Application Data <-------> Application Data 1333 Figure 10: DTLS Session Resumption. 1335 Constrained clients MUST implement session resumption to improve the 1336 performance of the handshake. This will lead to a reduced number of 1337 message exchanges, lower computational overhead (since only symmetric 1338 cryptography is used during a session resumption exchange), and 1339 session resumption requires less bandwidth. 1341 For cases where the server constrained (but not the client) the 1342 client MUST implement RFC 5077 [RFC5077]. Note that the constrained 1343 server refers to a device that has limitations in terms of RAM and 1344 flash memory, which place restrictions on the amount of TLS/DTLS 1345 security state information that can be stored on such a device. RFC 1346 5077 specifies a version of TLS/DTLS session resumption that does not 1347 require per-session state information to be maintained by the 1348 constrained server. This is accomplished by using a ticket-based 1349 approach. 1351 If both the client and the server are constrained devices both 1352 devices SHOULD implement RFC 5077 and MUST implement basic session 1353 resumption. Clients that do not want to use session resumption are 1354 always able to send a ClientHello message with an empty session_id to 1355 revert to a full handshake. 1357 10. Compression 1359 Section 3.3 of [RFC7525] recommends to disable TLS/DTLS-level 1360 compression due to attacks, such as CRIME. For IoT applications 1361 compression at the TLS/DTLS layer is not needed since application 1362 layer protocols are highly optimized and the compression algorithms 1363 at the DTLS layer increases code size and complexity. 1365 This TLS/DTLS profile MUST NOT implement TLS/DTLS layer compression. 1367 11. Perfect Forward Secrecy 1369 Perfect forward secrecy (PFS) is a property that preserves the 1370 confidentiality of past conversations even in situations where the 1371 long-term secret is compromised. 1373 The PSK ciphersuite recommended in Section 6.1 does not offer this 1374 property since it does not utilize a Diffie-Hellman exchange. New 1375 ciphersuites that support PFS for PSK-based authentication, such as 1376 proposed in [I-D.schmertmann-dice-ccm-psk-pfs], might become 1377 available as standardized ciphersuite in the (near) future. The 1378 recommended PSK-based ciphersuite offers excellent performance, a 1379 very small memory footprint, and has the lowest on the wire overhead 1380 at the expense of not using any public cryptography. For deployments 1381 where public key cryptography is acceptable the raw public might 1382 offer an acceptable middleground between the PSK ciphersuite in terms 1383 of out-of-band validation and the functionality offered by asymmetric 1384 cryptography. 1386 The use of PFS is a trade-off decision since on one hand the 1387 compromise of long-term secrets of embedded devices is more likely 1388 than with many other Internet hosts but on the other hand a Diffie- 1389 Hellman exchange requires ephemeral key pairs to be generated, which 1390 is demanding from a performance point of view. For obvious 1391 performance improvement, some implementations re-use key pairs over 1392 multiple exchanges (rather than generating new keys for each 1393 exchange). However, note that such key re-use over long periods 1394 voids the benefits of forward secrecy when an attack gains access to 1395 this DH key pair. 1397 The impact of the disclosure of past conversations and the desire to 1398 increase the cost for pervasive monitoring (as demanded by [RFC7258]) 1399 has to be taken into account when making a deployment decision. 1401 Client implementations claiming support of this profile MUST 1402 implement the ciphersuites listed in Section 6 according to the 1403 selected credential type. 1405 12. Keep-Alive 1407 Application layer communication may create state at the endpoints and 1408 this state my expire at some time. For this reason, applications 1409 define ways to refresh state, if necessary. While the application 1410 layer exchanges are largely outside the scope of the underlying TLS/ 1411 DTLS exchange similar state considerations also play a role at the 1412 level of TLS/DTLS. While TLS/DTLS also creates state in form of a 1413 security context (see the security parameter described in Appendix A6 1414 in RFC 5246) at the client and the server this state information does 1415 not expire. However, network intermediaries may also allocate state 1416 and require this state to be kept alive. Failure to keep state alive 1417 at a stateful packet filtering firewall or at a NAT may result in the 1418 inability for one node to reach the other since packets will get 1419 blocked by these middleboxes. Periodic keep-alive messages exchanged 1420 between the TLS/DTLS client and server keep state at these 1421 middleboxes alive. According to measurements described in 1422 [HomeGateway] there is some variance in state management practices 1423 used in residential gateways but the timeouts are heavily impacted by 1424 the choice of the transport layer protocol: timeouts for UDP are 1425 typically much shorter than those for TCP. 1427 RFC 6520 [RFC6520] defines a heartbeat mechanism to test whether the 1428 other peer is still alive. As an additional feature, the same 1429 mechanism can also be used to perform Path Maximum Transmission Unit 1430 (MTU) Discovery. 1432 A recommendation about the use of RFC 6520 depends on the type of 1433 message exchange an IoT device performs and the number of messages 1434 the application needs to exchange as part of their application 1435 functionality. There are three types of exchanges that need to be 1436 analysed: 1438 Client-Initiated, One-Shot Messages 1440 This is a common communication pattern where IoT devices upload 1441 data to a server on the Internet on an irregular basis. The 1442 communication may be triggered by specific events, such as opening 1443 a door. 1445 Since the upload happens on an irregular and unpredictable basis 1446 and due to renumbering and Network Address Translation (NAT) the 1447 DTLS handshake may need to be re-started (ideally using session 1448 resumption, if possible). 1450 In this case there is no use for a keep-alive extension for this 1451 scenario. 1453 Client-Initiated, Regular Data Uploads 1455 This is a variation of the previous case whereby data gets 1456 uploaded on a regular basis, for example, based on frequent 1457 temperature readings. If neither NAT bindings nor IP address 1458 changes occurred then the record layer will not notice any 1459 changes. For the case where the IP address and port number 1460 changes, it is necessary to re-create the record layer using 1461 session resumption. 1463 In this scenario there is no use for a keep-alive extension. It 1464 is also very likely that the device will enter a sleep cycle in 1465 between data transmissions to keep power consumption low. 1467 Server-Initiated Messages 1469 In the two previous scenarios the client initiated the protocol 1470 interaction and maintains it. Since messages to the client may 1471 get blocked by middleboxes the initial connection setup is 1472 triggered by the client and then kept alive by the server. 1474 For this message exchange pattern the use of DTLS heartbeat 1475 messages is quite useful but may have to be coordinated with 1476 application exchanges (for example when the CoAP resource 1477 directory is used) to avoid redundant keep-alive message 1478 exchanges. The MTU discovery mechanism, which is also part of 1479 [RFC6520], is less likely to be relevant since for many IoT 1480 deployments the most constrained link is the wireless interface 1481 between the IoT device and the network itself (rather than some 1482 links along the end-to-end path). Only in more complex network 1483 topologies, such as multi-hop mesh networks, path MTU discovery 1484 might be appropriate. It also has to be noted that DTLS itself 1485 already provides a basic path discovery mechanism (see 1486 Section 4.1.1.1 of RFC 6347 by using the fragmentation capability 1487 of the handshake protocol). 1489 For server-initiated messages the heartbeat extension is RECOMMENDED. 1491 13. Timeouts 1493 To connect to the Internet a variety of wired and wireless 1494 technologies are available. Many of the low power radio 1495 technologies, such as IEEE 802.15.4 or Bluetooth Smart, only support 1496 small frame sizes (e.g., 127 bytes in case of IEEE 802.15.4 as 1497 explained in RFC 4919 [RFC4919]). Other radio technologies, such as 1498 the Global System for Mobile Communications (GSM) using the short 1499 messaging service (SMS) have similar constraints in terms of payload 1500 sizes, such as 140 bytes without the optional segmentation and 1501 reassembly scheme known as Concatenated SMS, but show higher latency. 1503 The DTLS handshake protocol adds a fragmentation and reassembly 1504 mechanism to the TLS handshake protocol since each DTLS record must 1505 fit within a single transport layer datagram, as described in 1506 Section 4.2.3 of [RFC6347]. Since handshake messages are potentially 1507 bigger than the maximum record size, the mechanism fragments a 1508 handshake message over a number of DTLS records, each of which can be 1509 transmitted separately. 1511 To deal with the unreliable message delivery provided by UDP, DTLS 1512 adds timeouts and re-transmissions, as described in Section 4.2.4 of 1513 [RFC6347]. Although the timeout values are implementation specific, 1514 recommendations are provided in Section 4.2.4.1 of [RFC6347], with an 1515 initial timer value of 1 second and doubled with at each 1516 retransmission up to no less than 60 seconds. Due to the nature of 1517 some radio technologies, these values are too aggressive and lead to 1518 spurious failures when messages in flight need longer. 1520 Note: If a round-trip time estimator (such as proposed in 1521 [I-D.bormann-core-cocoa]) is available in the protocol stack of the 1522 device, it could be used to dynamically update the setting of the 1523 retransmit timeout. 1525 Choosing appropriate timeout values is difficult with changing 1526 network conditions, and large variance in latency. This 1527 specification therefore RECOMMENDS an initial timer value of 10 1528 seconds with exponential back off up to no less then 60 seconds. 1529 Appendix A provides additional normative text for carrying DTLS over 1530 SMS. 1532 14. Random Number Generation 1534 The TLS/DTLS protocol requires random numbers to be available during 1535 the protocol run. For example, during the ClientHello and the 1536 ServerHello exchange the client and the server exchange random 1537 numbers. Also, the use of the Diffie-Hellman exchange requires 1538 random numbers during the key pair generation. Special care has to 1539 be taken when generating random numbers in embedded systems as many 1540 entropy sources available on desktop operating systems or mobile 1541 devices might be missing, as described in [Heninger]. Consequently, 1542 if not enough time is given during system start time to fill the 1543 entropy pool then the output might be predictable and repeatable, for 1544 example leading to the same keys generated again and again. 1546 It is important to note that sources contributing to the randomness 1547 pool on laptops, or desktop PCs are not available on many IoT device, 1548 such as mouse movement, timing of keystrokes, air turbulence on the 1549 movement of hard drive heads, etc. Other sources have to be found or 1550 dedicated hardware has to be added. 1552 The ClientHello and the ServerHello messages contains the 'Random' 1553 structure, which has two components: gmt_unix_time and a sequence of 1554 28 random bytes. gmt_unix_time holds the current time and date in 1555 standard UNIX 32-bit format (seconds since the midnight starting Jan 1556 1, 1970, GMT). [I-D.mathewson-no-gmtunixtime] argues that the entire 1557 ClientHello.Random value (including gmt_unix_time) should be a 1558 sequence of random bits because of device fingerprinting privacy 1559 concerns. Since many IoT devices do not have access to an accurate 1560 clock, it is RECOMMENDED to follow the guidance outlined in 1561 [I-D.mathewson-no-gmtunixtime] regarding the content of the 1562 ClientHello.Random field. However, for the ServerHello.Random 1563 structure it is RECOMMENDED to maintain the existing structure with 1564 gmt_unix_time followed by a sequence of 28 random bytes since the 1565 client can use the received time information to securely obtain time 1566 information. For constrained servers it cannot be assumed that they 1567 maintain accurate time information; these devices MUST include time 1568 information in the Server.Random structure when they actually obtain 1569 accurate time information that can be utilized by clients. Clients 1570 MUST only use time information obtained from servers they trust and 1571 the use of this approach has to be agreed out-of-band. 1573 IoT devices using TLS/DTLS MUST offer ways to generate quality random 1574 numbers using hardware-based random number generators. Note that 1575 these hardware-based random number generators do not necessarily need 1576 to be implemented inside the microcontroller itself but could be made 1577 available in dedicated crypto-chips as well. Guidelines and 1578 requirements for random number generation can be found in RFC 4086 1579 [RFC4086] and in the NIST Special Publication 800-90a [SP800-90A]. 1581 Chip manufacturers are highly encouraged to provide sufficient 1582 documentation of their design for random number generators so that 1583 customers can have confidence about the quality of the generated 1584 random numbers. The confidence can be increased by providing 1585 information about the procedures that have been used to verify the 1586 randomness of numbers generated by the hardware modules. For 1587 example, NIST Special Publication 800-22b [SP800-22b] describes 1588 statistical tests that can be used to verify random random number 1589 generators. 1591 15. Truncated MAC and Encrypt-then-MAC Extension 1593 The truncated MAC extension was introduced with RFC 6066 [RFC6066] 1594 with the goal to reduce the size of the MAC used at the Record Layer. 1595 This extension was developed for TLS ciphersuites that used older 1596 modes of operation where the MAC and the encryption operation was 1597 performed independently. 1599 The recommended ciphersuites in this document use the newer 1600 Authenticated Encryption with Associated Data (AEAD) construct, 1601 namely the CBC-MAC mode (CCM) with eight-octet authentication tags, 1602 and are therefore not appliable to the truncated MAC extension. 1604 RFC 7366 [RFC7366] introduced the encrypt-then-MAC extension (instead 1605 of the previously used MAC-then-encrypt) since the MAC-then-encrypt 1606 mechanism has been the subject of a number of security 1607 vulnerabilities. RFC 7366 is, however, also not applicable to the 1608 AEAD ciphers recommended in this document. 1610 Implementations conformant to this specification MUST use AEAD 1611 ciphers. Hence, RFC 7366 and RFC 6066 are not applicable to this 1612 specifciation and MUST NOT be implemented. 1614 16. Server Name Indication (SNI) 1616 The Server Name Indication extension defined in [RFC6066] defines a 1617 mechanism for a client to tell a TLS/DTLS server the name of the 1618 server it wants to contact. This is a useful extension for many 1619 hosting environments where multiple virtual servers are run on single 1620 IP address. 1622 This specification RECOMMENDs the implementation of the Server Name 1623 Indication extension unless it is known that a TLS/DTLS client does 1624 not interact with a server in a hosting environment. 1626 17. Maximum Fragment Length Negotiation 1628 This RFC 6066 extension lowers the maximum fragment length support 1629 needed for the Record Layer from 2^14 bytes to 2^9 bytes. 1631 This is a very useful extension that allows the client to indicate to 1632 the server how much maximum memory buffers it uses for incoming 1633 messages. Ultimately, the main benefit of this extension is to allow 1634 client implementations to lower their RAM requirements since the 1635 client does not need to accept packets of large size (such as 16k 1636 packets as required by plain TLS/DTLS). 1638 Client implementations MUST support this extension. 1640 18. Session Hash 1642 In order to begin connection protection, the Record Protocol requires 1643 specification of a suite of algorithms, a master secret, and the 1644 client and server random values. The algorithm for computing the 1645 master secret is defined in Section 8.1 of RFC 5246 but only includes 1646 a small number of parameters exchanged during the handshake and does 1647 not include parameters like the client and server identities. This 1648 can be utilized by an attacker to mount a man-in-the-middle attack 1649 since the master secret is not guaranteed to be unique across 1650 sessions, as discovered in the 'Triple Handshake' attack [Triple-HS]. 1652 [I-D.ietf-tls-session-hash] defines a TLS extension that binds the 1653 master secret to a log of the full handshake that computes it, thus 1654 preventing such attacks. 1656 Client implementations SHOULD implement this extension even though 1657 the ciphersuites recommended by this profile are not vulnerable to 1658 this attack. For Diffie-Hellman-based ciphersuites the keying 1659 material is contributed by both parties and in case of the pre-shared 1660 secret key ciphersuite, both parties need to be in possession of the 1661 shared secret to ensure that the handshake completes successfully. 1662 It is, however, possible that some application layer protocols will 1663 tunnel other authentication protocols on top of DTLS making this 1664 attack relevant again. 1666 19. Re-Negotiation Attacks 1668 TLS/DTLS allows a client and a server who already have a TLS/DTLS 1669 connection to negotiate new parameters, generate new keys, etc by 1670 using the re-negotiation feature. Renegotiation happens in the 1671 existing connection, with the new handshake packets being encrypted 1672 along with application data. Upon completion of the re-negotiation 1673 procedure the new channel replaces the old channel. 1675 As described in RFC 5746 [RFC5746] there is no cryptographic binding 1676 between the two handshakes, although the new handshake is carried out 1677 using the cryptographic parameters established by the original 1678 handshake. 1680 To prevent the re-negotiation attack [RFC5746] this specification 1681 RECOMMENDS to disable the TLS renegotigation feature. Clients MUST 1682 respond to server-initiated re-negotiation attempts with an alert 1683 message (no_renegotiation) and clients MUST NOT initiate them. 1685 20. Downgrading Attacks 1687 When a client sends a ClientHello with a version higher than the 1688 highest version known to the server, the server is supposed to reply 1689 with ServerHello.version equal to the highest version known to the 1690 server and the handshake can proceed. This behaviour is known as 1691 version tolerance. Version-intolerance is when the server (or a 1692 middlebox) breaks the handshake when it sees a ClientHello.version 1693 higher than what it knows about. This is the behaviour that leads 1694 some clients to re-run the handshake with lower version. As a 1695 result, a potential security vulnerability is introduced when a 1696 system is running an old TLS/SSL version (e.g., because of the need 1697 to integrate with legacy systems). In the worst case, this allows an 1698 attacker to downgrade the protocol handshake to SSL 3.0. SSL 3.0 is 1699 so broken that there is no secure cipher available for it (see 1700 [I-D.ietf-tls-sslv3-diediedie]). 1702 The above-described downgrade vulnerability is solved by the TLS 1703 Fallback Signaling Cipher Suite Value (SCSV) [RFC7507] extension. 1705 However, the solution is not appliable to implementations conforming 1706 to this profile since the version negotiation MUST use TLS/DTLS 1707 version 1.2 (or higher). More specifically, this implies: 1709 o Clients MUST NOT send a TLS/DTLS version lower than version 1.2 in 1710 the ClientHello. 1712 o Clients MUST NOT retry a failed negotiation offering a TLS/DTLS 1713 version lower than 1.2. 1715 o Servers MUST fail the handshake by sending a protocol_version 1716 fatal alert if a TLS/DTLS version >= 1.2 cannot be negotiated. 1717 Note that the aborted connection is non-resumable. 1719 If at some time in the future this profile reaches the quality of SSL 1720 3.0 a software update is needed since constrained devices are 1721 unlikely to run multiple TLS/DTLS versions due to memory size 1722 restrictions. 1724 21. Crypto Agility 1726 This document recommends software and chip manufacturers to implement 1727 AES and the CCM mode of operation. This document references the CoAP 1728 recommended ciphersuite choices, which have been selected based on 1729 implementation and deployment experience from the IoT community. 1730 Over time the preference for algorithms will, however, change. Not 1731 all components of a ciphersuite are likely to change at the same 1732 speed. Changes are more likely expected for ciphers, the mode of 1733 operation, and the hash algorithms. The recommended key lengths have 1734 to be adjusted over time. Some deployment environments will also be 1735 impacted by local regulation, which might dictate a certain cipher 1736 and key size. Ongoing discussions regarding the choice of specific 1737 ECC curves will also likely impact implementations. Note that this 1738 document does not recommend or mandate a specific ECC curve. 1740 The following recommendations can be made to chip manufacturers: 1742 o Make any AES hardware-based crypto implementation accessible to 1743 developers working on security implementations at higher layers. 1744 Sometimes hardware implementatios are added to microcontrollers to 1745 offer support for functionality needed at the link layer and are 1746 only available to the on-chip link layer protocol implementation. 1748 o Provide flexibility for the use of the crypto function with future 1749 extensibility in mind. For example, making an AES-CCM 1750 implementation available to developers is a first step but such an 1751 implementation may not be usable due to parameter differences 1752 between an AES-CCM implementations. AES-CCM in IEEE 802.15.4 and 1753 Bluetooth Smart uses a nonce length of 13-octets while DTLS uses a 1754 nonce length of 12-octets. Hardware implementations of AES-CCM 1755 for IEEE 802.15.4 and Bluetooth Smart are therefore not re-usable 1756 by a DTLS stack. 1758 o Offer access to building blocks in addition (or as an alternative) 1759 to the complete functionality. For example, a chip manufacturer 1760 who gives developers access to the AES crypto function can use it 1761 to build an efficient AES-GCM implementations. Another example is 1762 to make a special instruction available that increases the speed 1763 of speed-up carryless multiplications. 1765 As a recommendation for developers and product architects we 1766 recommend that sufficient headroom is provided to allow an upgrade to 1767 a newer cryptographic algorithms over the lifetime of the product. 1768 As an example, while AES-CCM is recommended thoughout this 1769 specification future products might use the ChaCha20 cipher in 1770 combination with the Poly1305 authenticator [RFC7539]. The 1771 assumption is made that a robust software update mechanism is 1772 offered. 1774 22. Key Length Recommendations 1776 RFC 4492 [RFC4492] gives approximate comparable key sizes for 1777 symmetric- and asymmetric-key cryptosystems based on the best-known 1778 algorithms for attacking them. While other publications suggest 1779 slightly different numbers, such as [Keylength], the approximate 1780 relationship still holds true. Figure 11 illustrates the comparable 1781 key sizes in bits. 1783 Symmetric | ECC | DH/DSA/RSA 1784 ------------+---------+------------- 1785 80 | 163 | 1024 1786 112 | 233 | 2048 1787 128 | 283 | 3072 1788 192 | 409 | 7680 1789 256 | 571 | 15360 1791 Figure 11: Comparable Key Sizes (in bits) based on RFC 4492. 1793 At the time of writing the key size recommendations for use with TLS- 1794 based ciphers found in [RFC7525] recommend DH key lengths of at least 1795 2048 bit, which corresponds to a 112-bit symmetric key and a 233 bit 1796 ECC key. These recommendations are roughly inline with those from 1797 other organizations, such as the National Institute of Standards and 1798 Technology (NIST) or the European Network and Information Security 1799 Agency (ENISA). The authors of [ENISA-Report2013] add that a 80-bit 1800 symmetric key is sufficient for legacy applications for the coming 1801 years, but a 128-bit symmetric key is the minimum requirement for new 1802 systems being deployed. The authors further note that one needs to 1803 also take into account the length of time data needs to be kept 1804 secure for. The use of 80-bit symmetric keys for transactional data 1805 may be acceptable for the near future while one has to insist on 1806 128-bit symmetric keys for long lived data. 1808 Note that the recommendations for 112-bit symmetric keys are chosen 1809 conservatively under the assumption that IoT devices have a long 1810 expected lifetime (such as 10+ years) and that this key length 1811 recommendation refers to the long-term keys used for device 1812 authentication. Keys, which are provisioned dynamically, for the 1813 protection of transactional data (such as ephemeral Diffie-Hellman 1814 keys used in various TLS/DTLS ciphersuites) may be shorter 1815 considering the sensitivity of the exchanged data. 1817 23. False Start 1819 A full TLS handshake as specified in [RFC5246] requires two full 1820 protocol rounds (four flights) before the handshake is complete and 1821 the protocol parties may begin to send application data. 1823 An abbreviated handshake (resuming an earlier TLS session) is 1824 complete after three flights, thus adding just one round-trip time if 1825 the client sends application data first. 1827 If the conditions outlined in [I-D.bmoeller-tls-falsestart] are met, 1828 application data can be transmitted when the sender has sent its own 1829 "ChangeCipherSpec" and "Finished" messages. This achieves an 1830 improvement of one round-trip time for full handshakes if the client 1831 sends application data first, and for abbreviated handshakes if the 1832 server sends application data first. 1834 The conditions for using the TLS False Start mechanism are met by the 1835 public-key-based ciphersuites in this document. In summary, the 1836 conditions are 1838 o Modern symmetric ciphers with an effective key length of 128 bits, 1839 such as AES-128-CCM 1841 o Client certificate types, such as ecdsa_sign 1843 o Key exchange methods, such as ECDHE_ECDSA 1844 Based on the improvement over a full roundtrip for the full TLS/DTLS 1845 exchange this specification RECOMMENDS the use of the False Start 1846 mechanism when clients send application data first. 1848 24. Privacy Considerations 1850 The DTLS handshake exchange conveys various identifiers, which can be 1851 observed by an on-path eavesdropper. For example, the DTLS PSK 1852 exchange reveals the PSK identity, the supported extensions, the 1853 session id, algorithm parameters, etc. When session resumption is 1854 used then individual TLS sessions can be correlated by an on-path 1855 adversary. With many IoT deployments it is likely that keying 1856 material and their identifiers are persistent over a longer period of 1857 time due to the cost of updating software on these devices. 1859 User participation with many IoT deployments poses a challenge since 1860 many of the IoT devices operate unattended, even though they will 1861 initially be provisioned by a human. The ability to control data 1862 sharing and to configure preference will have to be provided at a 1863 system level rather than at the level of the DTLS exchange itself, 1864 which is the scope of this document. Quite naturally, the use of 1865 DTLS with mutual authentication will allow a TLS server to collect 1866 authentication information about the IoT device (likely over a long 1867 period of time). While this strong form of authentication will 1868 prevent mis-attribution, it also allows strong identification. 1869 Device-related data collection (e.g., sensor recordings) associated 1870 with other data type will prove to be truly useful but this extra 1871 data might include personal information about the owner of the device 1872 or data about the environment it senses. Consequently, the data 1873 stored on the server-side will be vulnerable to stored data 1874 compromise. For the communication between the client and the server 1875 this specification prevents eavesdroppers to gain access to the 1876 communication content. While the PSK-based ciphersuite does not 1877 provide PFS the asymmetric versions do. This prevents an adversary 1878 from obtaining past communication content when access to a long-term 1879 secret has been gained. Note that no extra effort to make traffic 1880 analysis more difficult is provided by the recommendations made in 1881 this document. 1883 25. Security Considerations 1885 This entire document is about security. 1887 We would also like to point out that designing a software update 1888 mechanism into an IoT system is crucial to ensure that both 1889 functionality can be enhanced and that potential vulnerabilities can 1890 be fixed. This software update mechanism is important for changing 1891 configuration information, for example, trust anchors and other 1892 keying related information. Such a suitable software update 1893 mechanism is available with the Lightweight Machine-to-Machine 1894 (LWM2M) protocol published by the Open Mobile Alliance (OMA) [LWM2M]. 1896 26. IANA Considerations 1898 This document includes no request to IANA. 1900 27. Acknowledgements 1902 Thanks to Derek Atkins, Olaf Bergmann, Paul Bakker, Robert Cragie, 1903 Russ Housley, Rene Hummen, Matthias Kovatsch, Sandeep Kumar, Sye 1904 Loong Keoh, Simon Lemay, Alexey Melnikov, Manuel Pegourie-Gonnard, 1905 Akbar Rahman, Eric Rescorla, Michael Richardson, Ludwig Seitz, Zach 1906 Shelby, Michael StJohns, Rene Struik, and Sean Turner for their 1907 helpful comments and discussions that have shaped the document. 1909 Big thanks also to Klaus Hartke, who wrote the initial version of 1910 this document. 1912 Finally, we would like to thank our area director (Stephen Farrell) 1913 and our working group chairs (Zach Shelby and Dorothy Gellert) for 1914 their support. 1916 28. References 1918 28.1. Normative References 1920 [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 1921 REGISTRATION AUTHORITY", April 2010, 1922 . 1925 [GSM-SMS] ETSI, "3GPP TS 23.040 V7.0.1 (2007-03): 3rd Generation 1926 Partnership Project; Technical Specification Group Core 1927 Network and Terminals; Technical realization of the Short 1928 Message Service (SMS) (Release 7)", March 2007. 1930 [I-D.ietf-tls-cached-info] 1931 Santesson, S. and H. Tschofenig, "Transport Layer Security 1932 (TLS) Cached Information Extension", draft-ietf-tls- 1933 cached-info-19 (work in progress), March 2015. 1935 [I-D.ietf-tls-session-hash] 1936 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 1937 A., and M. Ray, "Transport Layer Security (TLS) Session 1938 Hash and Extended Master Secret Extension", draft-ietf- 1939 tls-session-hash-05 (work in progress), April 2015. 1941 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1942 Requirement Levels", BCP 14, RFC 2119, March 1997. 1944 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 1945 for Transport Layer Security (TLS)", RFC 4279, December 1946 2005. 1948 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1949 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1951 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 1952 "Transport Layer Security (TLS) Renegotiation Indication 1953 Extension", RFC 5746, February 2010. 1955 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1956 Extension Definitions", RFC 6066, January 2011. 1958 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1959 Verification of Domain-Based Application Service Identity 1960 within Internet Public Key Infrastructure Using X.509 1961 (PKIX) Certificates in the Context of Transport Layer 1962 Security (TLS)", RFC 6125, March 2011. 1964 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1965 Security Version 1.2", RFC 6347, January 2012. 1967 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 1968 Layer Security (TLS) and Datagram Transport Layer Security 1969 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 1971 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 1972 T. Kivinen, "Using Raw Public Keys in Transport Layer 1973 Security (TLS) and Datagram Transport Layer Security 1974 (DTLS)", RFC 7250, June 2014. 1976 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 1977 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 1978 TLS", RFC 7251, June 2014. 1980 [WAP-WDP] Wireless Application Protocol Forum, "Wireless Datagram 1981 Protocol", June 2001. 1983 28.2. Informative References 1985 [ACE-WG] IETF, "Authentication and Authorization for Constrained 1986 Environments (ace) Working Group", URL: 1987 https://datatracker.ietf.org/wg/ace/charter/, Jan 2015. 1989 [AES] National Institute of Standards and Technology, "FIPS PUB 1990 197, Advanced Encryption Standard (AES)", 1991 http://www.iana.org/assignments/tls-parameters/ 1992 tls-parameters.xhtml#tls-parameters-4, November 2001. 1994 [CCM] National Institute of Standards and Technology, "Special 1995 Publication 800-38C, Recommendation for Block Cipher Modes 1996 of Operation: The CCM Mode for Authentication and 1997 Confidentiality", http://csrc.nist.gov/publications/ 1998 nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf, May 1999 2004. 2001 [ENISA-Report2013] 2002 ENISA, "Algorithms, Key Sizes and Parameters Report - 2003 2013", http://www.enisa.europa.eu/activities/identity-and- 2004 trust/library/deliverables/ 2005 algorithms-key-sizes-and-parameters-report, October 2013. 2007 [Heninger] 2008 Heninger, N., Durumeric, Z., Wustrow, E., and A. 2009 Halderman, "Mining Your Ps and Qs: Detection of Widespread 2010 Weak Keys in Network Devices", 21st USENIX Security 2011 Symposium, 2012 https://www.usenix.org/conference/usenixsecurity12/ 2013 technical-sessions/presentation/heninger, 2012. 2015 [HomeGateway] 2016 Eggert, L., "An experimental study of home gateway 2017 characteristics, In Proceedings of the '10th annual 2018 conference on Internet measurement'", 2010. 2020 [I-D.bmoeller-tls-falsestart] 2021 Langley, A., Modadugu, N., and B. Moeller, "Transport 2022 Layer Security (TLS) False Start", draft-bmoeller-tls- 2023 falsestart-01 (work in progress), November 2014. 2025 [I-D.bormann-core-cocoa] 2026 Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, 2027 "CoAP Simple Congestion Control/Advanced", draft-bormann- 2028 core-cocoa-02 (work in progress), July 2014. 2030 [I-D.ietf-core-resource-directory] 2031 Shelby, Z. and C. Bormann, "CoRE Resource Directory", 2032 draft-ietf-core-resource-directory-02 (work in progress), 2033 November 2014. 2035 [I-D.ietf-tls-negotiated-dl-dhe] 2036 Gillmor, D., "Negotiated Discrete Log Diffie-Hellman 2037 Ephemeral Parameters for TLS", draft-ietf-tls-negotiated- 2038 dl-dhe-00 (work in progress), July 2014. 2040 [I-D.ietf-tls-sslv3-diediedie] 2041 Barnes, R., Thomson, M., Pironti, A., and A. Langley, 2042 "Deprecating Secure Sockets Layer Version 3.0", draft- 2043 ietf-tls-sslv3-diediedie-03 (work in progress), April 2044 2015. 2046 [I-D.irtf-cfrg-curves] 2047 Langley, A., Salz, R., and S. Turner, "Elliptic Curves for 2048 Security", draft-irtf-cfrg-curves-02 (work in progress), 2049 March 2015. 2051 [I-D.josefsson-eddsa-ed25519] 2052 Josefsson, S. and N. Moller, "EdDSA and Ed25519", draft- 2053 josefsson-eddsa-ed25519-03 (work in progress), May 2015. 2055 [I-D.mathewson-no-gmtunixtime] 2056 Mathewson, N. and B. Laurie, "Deprecating gmt_unix_time in 2057 TLS", draft-mathewson-no-gmtunixtime-00 (work in 2058 progress), December 2013. 2060 [I-D.schmertmann-dice-ccm-psk-pfs] 2061 Schmertmann, L. and C. Bormann, "ECDHE-PSK AES-CCM Cipher 2062 Suites with Forward Secrecy for Transport Layer Security 2063 (TLS)", draft-schmertmann-dice-ccm-psk-pfs-01 (work in 2064 progress), August 2014. 2066 [IANA-TLS] 2067 IANA, "TLS Cipher Suite Registry", 2068 http://www.iana.org/assignments/tls-parameters/ 2069 tls-parameters.xhtml#tls-parameters-4, 2014. 2071 [ImprintingSurvey] 2072 Chilton, E., "A Brief Survey of Imprinting Options for 2073 Constrained Devices", URL: http://www.lix.polytechnique.fr 2074 /hipercom/SmartObjectSecurity/papers/EricRescorla.pdf, 2075 March 2012. 2077 [Keylength] 2078 Giry, D., "Cryptographic Key Length Recommendations", 2079 http://www.keylength.com, November 2014. 2081 [LWM2M] Open Mobile Alliance, "Lightweight Machine-to-Machine, 2082 Technical Specification, Candidate Version 1.0", December 2083 2013. 2085 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2086 November 1990. 2088 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 2089 for IP version 6", RFC 1981, August 1996. 2091 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2092 Hashing for Message Authentication", RFC 2104, February 2093 1997. 2095 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2096 "Remote Authentication Dial In User Service (RADIUS)", RFC 2097 2865, June 2000. 2099 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 2100 CBC-MAC (CCM)", RFC 3610, September 2003. 2102 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2103 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 2104 3748, June 2004. 2106 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 2107 Requirements for Security", BCP 106, RFC 4086, June 2005. 2109 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 2110 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 2111 for Transport Layer Security (TLS)", RFC 4492, May 2006. 2113 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 2114 over Low-Power Wireless Personal Area Networks (6LoWPANs): 2115 Overview, Assumptions, Problem Statement, and Goals", RFC 2116 4919, August 2007. 2118 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 2119 "Transport Layer Security (TLS) Session Resumption without 2120 Server-Side State", RFC 5077, January 2008. 2122 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 2123 Encryption", RFC 5116, January 2008. 2125 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 2126 Authentication Protocol", RFC 5216, March 2008. 2128 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 2129 Authentication Protocol (EAP) Key Management Framework", 2130 RFC 5247, August 2008. 2132 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2133 Housley, R., and W. Polk, "Internet X.509 Public Key 2134 Infrastructure Certificate and Certificate Revocation List 2135 (CRL) Profile", RFC 5280, May 2008. 2137 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 2138 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 2139 August 2008. 2141 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 2142 "Elliptic Curve Cryptography Subject Public Key 2143 Information", RFC 5480, March 2009. 2145 [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. 2146 Polk, "Internet X.509 Public Key Infrastructure: 2147 Additional Algorithms and Identifiers for DSA and ECDSA", 2148 RFC 5758, January 2010. 2150 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 2151 Management Protocol (TAMP)", RFC 5934, August 2010. 2153 [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management 2154 Requirements", RFC 6024, October 2010. 2156 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 2157 Curve Cryptography Algorithms", RFC 6090, February 2011. 2159 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 2160 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 2162 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 2163 Transport Layer Security (TLS)", RFC 6655, July 2012. 2165 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 2166 Format", RFC 6690, August 2012. 2168 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 2169 "Diameter Base Protocol", RFC 6733, October 2012. 2171 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 2172 Multiple Certificate Status Request Extension", RFC 6961, 2173 June 2013. 2175 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2176 Constrained-Node Networks", RFC 7228, May 2014. 2178 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2179 Application Protocol (CoAP)", RFC 7252, June 2014. 2181 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2182 Attack", BCP 188, RFC 7258, May 2014. 2184 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer 2185 Security (TLS) and Datagram Transport Layer Security 2186 (DTLS)", RFC 7366, September 2014. 2188 [RFC7390] Rahman, A. and E. Dijk, "Group Communication for the 2189 Constrained Application Protocol (CoAP)", RFC 7390, 2190 October 2014. 2192 [RFC7397] Gilger, J. and H. Tschofenig, "Report from the Smart 2193 Object Security Workshop", RFC 7397, December 2014. 2195 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 2196 IPv6 over Low-Power Wireless Personal Area Networks 2197 (6LoWPANs)", RFC 7400, November 2014. 2199 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 2200 "Architectural Considerations in Smart Object Networking", 2201 RFC 7452, March 2015. 2203 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, 2204 February 2015. 2206 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 2207 Suite Value (SCSV) for Preventing Protocol Downgrade 2208 Attacks", RFC 7507, April 2015. 2210 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2211 "Recommendations for Secure Use of Transport Layer 2212 Security (TLS) and Datagram Transport Layer Security 2213 (DTLS)", BCP 195, RFC 7525, May 2015. 2215 [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 2216 Protocols", RFC 7539, May 2015. 2218 [SP800-22b] 2219 National Institute of Standards and Technology, "Special 2220 Publication 800-22, Revision 1a, A Statistical Test Suite 2221 for Random and Pseudorandom Number Generators for 2222 Cryptographic Applications", 2223 http://csrc.nist.gov/publications/nistpubs/800-22-rev1a/ 2224 SP800-22rev1a.pdf, April 2010. 2226 [SP800-90A] 2227 NIST, "DRAFT Special Publication 800-90a, Revision 1, 2228 Recommendation for Random Number Generation Using 2229 Deterministic Random Bit Generators", 2230 http://csrc.nist.gov/publications/drafts/800-90/ 2231 sp800-90a_r1_draft_november2014_ver.pdf, November 2014. 2233 [Triple-HS] 2234 Bhargavan, K., Delignat-Lavaud, C., Pironti, A., and P. 2235 Strub, "Triple Handshakes and Cookie Cutters: Breaking and 2236 Fixing Authentication over TLS", IEEE Symposium on 2237 Security and Privacy, pages 98-113, 2014. 2239 Appendix A. Conveying DTLS over SMS 2241 This section is normative for the use of DTLS over SMS. Timer 2242 recommendations are already outlined in Section 13 and also 2243 applicable to the transport of DTLS over SMS. 2245 This section requires readers to be familiar with the terminology and 2246 concepts described in [GSM-SMS], and [WAP-WDP]. 2248 The remainder of this section assumes Mobile Stations are capable of 2249 producing and consuming 8-bit binary data encoded Transport Protocol 2250 Data Units (TPDU). 2252 A.1. Overview 2254 DTLS adds an additional roundtrip to the TLS [RFC5246] handshake to 2255 serve as a return-routability test for protection against certain 2256 types of DoS attacks. Thus a full blown DTLS handshake comprises up 2257 to 6 "flights" (i.e., logical message exchanges), each of which is 2258 then mapped on to one or more DTLS records using the segmentation and 2259 reassembly (SaR) scheme described in Section 4.2.3 of [RFC6347]. The 2260 overhead for said scheme is 6 bytes per Handshake message which, 2261 given a realistic 10+ messages handshake, would amount around 60 2262 bytes across the whole handshake sequence. 2264 Note that the DTLS SaR scheme is defined for handshake messages only. 2265 In fact, DTLS records are never fragmented and MUST fit within a 2266 single transport layer datagram. 2268 SMS provides an optional segmentation and reassembly scheme as well, 2269 known as Concatenated short messages (see Section 9.2.3.24.1 of 2270 [GSM-SMS]). However, since the SaR scheme in DTLS cannot be 2271 circumvented, the Concatenated short messages mechanism SHOULD NOT be 2272 used during handshake to avoid redundant overhead. Before starting 2273 the handshake phase (either actively or passively), the DTLS 2274 implementation MUST be explicitly configured with the PMTU of the SMS 2275 transport in order to correctly instrument its SaR function. The 2276 PMTU SHALL be 133 bytes if WDP-based multiplexing is used (see 2277 Appendix A.3), 140 bytes otherwise. 2279 It is RECOMMENDED to use the established security context over the 2280 longest possible period (possibly until a Closure Alert message is 2281 received, or after a very long inactivity timeout) to avoid the 2282 expensive re-establishment of the security association. 2284 A.2. Message Segmentation and Re-Assembly 2286 The content of an SMS message is carried in the TP-UserData field, 2287 and its size may be up to 140 bytes. As already mentioned in 2288 Appendix A.1, longer (i.e., up to 34170 bytes) messages can be sent 2289 using Concatenated SMS. 2291 This scheme consumes 6-7 bytes (depending on whether the short or 2292 long segmentation format is used) of the TP-UserData field, thus 2293 reducing the space available for the actual content of the SMS 2294 message to 133-134 bytes per TPDU. 2296 Though in principle a PMTU value higher than 140 bytes could be used, 2297 which may look like an appealing option given its more efficient use 2298 of the transport, there are disadvantages to consider. First, there 2299 is an additional overhead of 7 bytes per TPDU to be paid to the SaR 2300 function (which is in addition to the overhead introduced by the DTLS 2301 SaR mechanism. Second, some networks only partially support the 2302 Concatenated SMS function and others do not support it at all. 2304 For these reasons, the Concatenated short messages mechanism SHOULD 2305 NOT be used, and it is RECOMMENDED to leave the same PMTU settings 2306 used during the handshake phase, i.e., 133 bytes if WDP- based 2307 multiplexing is enabled, 140 bytes otherwise. 2309 Note that, after DTLS handshake has completed, any fragmentation and 2310 reassembly logic that pertains the application layer (e.g., 2311 segmenting CoAP messages into DTLS records and reassembling them 2312 after the crypto operations have been successfully performed) needs 2313 to be handled by the application that uses the established DTLS 2314 tunnel. 2316 A.3. Multiplexing Security Associations 2318 Unlike IPsec ESP/AH, DTLS records do not contain any association 2319 identifiers. Applications must arrange to multiplex between 2320 associations on the same endpoint which, when using UDP/IP, is 2321 usually done with the host/port number. 2323 If the DTLS server allows more than one client to be active at any 2324 given time, then the WAP User Datagram Protocol [WAP-WDP] can be used 2325 to achieve multiplexing of the different security associations. (The 2326 use of WDP provides the additional benefit that upper layer protocols 2327 can operate independently of the underlying wireless network, hence 2328 achieving application-agnostic transport handover.) 2330 The total overhead cost for encoding the WDP source and destination 2331 ports is either 5 or 7 bytes out of the total available for the SMS 2332 content depending on if 1-byte or 2-byte port identifiers are used, 2333 as shown in Figure 12 and Figure 13. 2335 0 1 2 3 4 2336 +--------+--------+--------+--------+--------+ 2337 | ... | 0x04 | 2 | ... | ... | 2338 +--------+--------+--------+--------+--------+ 2339 UDH IEI IE Dest Source 2340 Length Length Port Port 2342 Figure 12: Application Port Addressing Scheme (8 bit address). 2344 0 1 2 3 4 5 6 2345 +--------+--------+--------+--------+--------+--------+--------+ 2346 | ... | 0x05 | 4 | ... | ... | 2347 +--------+--------+--------+--------+--------+--------+--------+ 2348 UDH IEI IE Dest Source 2349 Length Length Port Port 2351 Figure 13: Application Port Addressing Scheme (16 bit address). 2353 The receiving side of the communication gets the source address from 2354 the originator address (TP-OA) field of the SMS-DELIVER TPDU. This 2355 way an unique 4-tuple identifying the security association can be 2356 reconstructed at both ends. (When replying to its DTLS peer, the 2357 sender will swaps the TP-OA and TP-DA parameters and the source and 2358 destination ports in the WDP.) 2360 A.4. Timeout 2362 If SMS-STATUS-REPORT messages are enabled, their receipt is not to be 2363 interpreted as the signal that the specific handshake message has 2364 been acted upon by the receiving party. Therefore, it MUST NOT be 2365 taken into account by the DTLS timeout and retransmission function. 2367 Handshake messages MUST carry a validity period (TP-VP parameter in a 2368 SMS-SUBMIT TPDU) that is not less than the current value of the 2369 retransmission timeout. In order to avoid persisting messages in the 2370 network that will be discarded by the receiving party, handshake 2371 messages SHOULD carry a validity period that is the same as, or just 2372 slightly higher than, the current value of the retransmission 2373 timeout. 2375 Appendix B. DTLS Record Layer Per-Packet Overhead 2377 Figure 14 shows the overhead for the DTLS record layer for protecting 2378 data traffic when AES-128-CCM with an 8-octet Integrity Check Value 2379 (ICV) is used. 2381 DTLS Record Layer Header................13 bytes 2382 Nonce (Explicit).........................8 bytes 2383 ICV..................................... 8 bytes 2384 ------------------------------------------------ 2385 Overhead................................29 bytes 2386 ------------------------------------------------ 2388 Figure 14: AES-128-CCM-8 DTLS Record Layer Per-Packet Overhead. 2390 The DTLS record layer header has 13 octets and consists of 2392 o 1 octet content type field, 2394 o 2 octet version field, 2396 o 2 octet epoch field, 2398 o 6 octet sequence number, 2400 o 2 octet length field. 2402 The "nonce" input to the AEAD algorithm is exactly that of [RFC5288], 2403 i.e., 12 bytes long. It consists of a 4 octet salt and an 8 octet 2404 nonce. The salt is the "implicit" part of the nonce and is not sent 2405 in the packet. Since the nonce_explicit may be the 8 octet sequence 2406 number and, in DTLS, it is the 8 octet epoch concatenated with the 6 2407 octet sequence number. 2409 RFC 6655 [RFC6655] allows the nonce_explicit to be a sequence number 2410 or something else. This document makes this use more restrictive for 2411 use with DTLS: the 64-bit none_explicit MUST be the 16-bit epoch 2412 concatenated with the 48-bit seq_num. The sequence number component 2413 of the nonce_explicit field at the AES-CCM layer is an exact copy of 2414 the sequence number in the record layer header field. This leads to 2415 a duplication of 8-bytes per record. 2417 To avoid this 8-byte duplication RFC 7400 [RFC7400] provides help 2418 with the use of the generic header compression technique for IPv6 2419 over Low-Power Wireless Personal Area Networks (6LoWPANs). Note that 2420 this header compression technique is not available when DTLS is 2421 exchanged over transports that do not use IPv6 or 6LoWPAN, such as 2422 the SMS transport described in Appendix A. 2424 Appendix C. DTLS Fragmentation 2426 [Editor's Note: Proposed text that requires discussion. ] 2428 Section 4.2.3 of [RFC6347] advises DTLS implementations to not 2429 produce overlapping fragments, but requires receivers to be able to 2430 cope with them. The need for the latter requisite is explained in 2431 Section 4.1.1.1 of [RFC6347]: accurate path MTU (PMTU) estimation may 2432 be traded for shorter handshake completion time. This approach may 2433 be beneficial in unconstrained networks where a PMTU of 1280 bytes 2434 can be pretty much universally assumed. However, an handshake that 2435 is carried over a narrow-band radio technology, such as IEEE 2436 802.15.4, Bluetooth Smart or GSM-SMS, and the client is lacking 2437 reliable PMTU data to inform fragmentation (e.g., using [RFC1981] or 2438 [RFC1191]) can place a cost on the constrained implementation in 2439 terms of memory (due to re-buffering) and latency (due to re- 2440 transmission) much higher than the benefit that it would get from a 2441 shorter handshake. 2443 In order to reduce the likelihood of producing different fragment 2444 sizes (and consequent overlaps) within the same handshake, this 2445 document RECOMMENDs: 2447 o for clients (handshake initiators), to perform PMTU discovery 2448 towards the server before handshake starts, and not rely on any 2449 guesses (unless the network path characteristics are reliably 2450 known from another source); 2452 o for servers, to mirror the fragment size selected by their 2453 clients. 2455 Authors' Addresses 2457 Hannes Tschofenig (editor) 2458 ARM Ltd. 2459 110 Fulbourn Rd 2460 Cambridge CB1 9NJ 2461 Great Britain 2463 Email: Hannes.tschofenig@gmx.net 2464 URI: http://www.tschofenig.priv.at 2466 Thomas Fossati 2467 Alcatel-Lucent 2468 3 Ely Road 2469 Milton, Cambridge CB24 6DD 2470 UK 2472 Email: thomas.fossati@alcatel-lucent.com