idnits 2.17.1 draft-ietf-dice-profile-17.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 date (October 19, 2015) is 3109 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 1433, 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 ** 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 (-28) exists of draft-ietf-core-resource-directory-04 == Outdated reference: A later version (-02) exists of draft-ietf-tls-falsestart-00 == Outdated reference: A later version (-05) exists of draft-tschofenig-core-coap-tcp-tls-04 -- 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 (~~), 6 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: April 21, 2016 Alcatel-Lucent 6 October 19, 2015 8 TLS/DTLS Profiles for the Internet of Things 9 draft-ietf-dice-profile-17.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 sensors 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 April 21, 2016. 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. TLS and DTLS . . . . . . . . . . . . . . . . . . . . . . 4 64 3.2. Communication Models . . . . . . . . . . . . . . . . . . 6 65 3.3. The Ciphersuite Concept . . . . . . . . . . . . . . . . . 18 66 4. Credential Types . . . . . . . . . . . . . . . . . . . . . . 20 67 4.1. Pre-Conditions . . . . . . . . . . . . . . . . . . . . . 20 68 4.2. Pre-Shared Secret . . . . . . . . . . . . . . . . . . . . 21 69 4.3. Raw Public Key . . . . . . . . . . . . . . . . . . . . . 24 70 4.4. Certificates . . . . . . . . . . . . . . . . . . . . . . 25 71 5. Signature Algorithm Extension . . . . . . . . . . . . . . . . 31 72 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 31 73 7. Session Resumption . . . . . . . . . . . . . . . . . . . . . 33 74 8. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 34 75 9. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 34 76 10. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 35 77 11. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 37 78 12. Random Number Generation . . . . . . . . . . . . . . . . . . 38 79 13. Truncated MAC and Encrypt-then-MAC Extension . . . . . . . . 39 80 14. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 39 81 15. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 40 82 16. Session Hash . . . . . . . . . . . . . . . . . . . . . . . . 40 83 17. Re-Negotiation Attacks . . . . . . . . . . . . . . . . . . . 40 84 18. Downgrading Attacks . . . . . . . . . . . . . . . . . . . . . 41 85 19. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 41 86 20. Key Length Recommendations . . . . . . . . . . . . . . . . . 43 87 21. False Start . . . . . . . . . . . . . . . . . . . . . . . . . 44 88 22. Privacy Considerations . . . . . . . . . . . . . . . . . . . 44 89 23. Security Considerations . . . . . . . . . . . . . . . . . . . 45 90 24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 91 25. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 92 26. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 93 26.1. Normative References . . . . . . . . . . . . . . . . . . 46 94 26.2. Informative References . . . . . . . . . . . . . . . . . 48 95 Appendix A. Conveying DTLS over SMS . . . . . . . . . . . . . . 54 96 A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 54 97 A.2. Message Segmentation and Re-Assembly . . . . . . . . . . 55 98 A.3. Multiplexing Security Associations . . . . . . . . . . . 56 99 A.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 57 100 Appendix B. DTLS Record Layer Per-Packet Overhead . . . . . . . 57 101 Appendix C. DTLS Fragmentation . . . . . . . . . . . . . . . . . 58 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 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]. CoAP messages are mainly carried over UDP/DTLS, but other 122 transports can be utilized, such as SMS (as described in Appendix A) 123 or TCP (as currently being proposed with 124 [I-D.tschofenig-core-coap-tcp-tls]). 126 While the main goal for this document is to protect CoAP messages 127 using DTLS 1.2 [RFC6347], the information contained in the following 128 sections is not limited to CoAP nor to DTLS itself. 130 Instead, this document defines a profile of DTLS 1.2 [RFC6347] and 131 TLS 1.2 [RFC5246] that offers communication security services for IoT 132 applications and is reasonably implementable on many constrained 133 devices. Profile thereby means that available configuration options 134 and protocol extensions are utilized to best support the IoT 135 environment. This document does not alter TLS/DTLS specifications 136 and does not introduce any new TLS/DTLS extension. 138 The main target audience for this document is the embedded system 139 developer configuring and using a TLS/DTLS stack. This document may, 140 however, also help those developing or selecting a suitable TLS/DTLS 141 stack for an Internet of Things product. If you are familiar with 142 (D)TLS, then skip ahead to Section 4. 144 2. Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 148 "OPTIONAL" in this document are to be interpreted as described in RFC 149 2119 [RFC2119]. 151 This specification refers to TLS as well as DTLS and particularly to 152 version 1.2, which is the most recent version at the time of writing. 153 We refer to TLS/DTLS whenever the text is applicable to both versions 154 of the protocol and to TLS or DTLS when there are differences between 155 the two protocols. Note that TLS 1.3 is being developed but it is 156 not expected that this profile will "just work" due to the 157 significant changes being done to TLS for version 1.3. 159 Note that "Client" and "Server" in this document refer to TLS/DTLS 160 roles, where the client initiates the handshake. This does not 161 restrict the interaction pattern of the protocols on top of DTLS 162 since the record layer allows bi-directional communication. This 163 aspect is further described in Section 3.2. 165 RFC 7228 [RFC7228] introduces the notion of constrained-node 166 networks, which are made of small devices with severe constraints on 167 power, memory, and processing resources. The terms constrained 168 devices, and Internet of Things (IoT) devices are used 169 interchangeably. 171 The terms "Certification Authority" (CA) and "Distinguished Name" 172 (DN) are taken from [RFC5280]. The terms "trust anchor" and "trust 173 anchor store" are defined in [RFC6024] as 175 "A trust anchor represents an authoritative entity via a public 176 key and associated data. The public key is used to verify digital 177 signatures, and the associated data is used to constrain the types 178 of information for which the trust anchor is authoritative." 180 "A trust anchor store is a set of one or more trust anchors stored 181 in a device. A device may have more than one trust anchor store, 182 each of which may be used by one or more applications." 184 3. Overview 186 3.1. TLS and DTLS 188 The TLS protocol [RFC5246] provides authenticated, confidentiality- 189 and integrity-protected communication between two endpoints. The 190 protocol is composed of two layers: the Record Protocol and the 191 Handshaking Protocols. At the lowest level, layered on top of a 192 reliable transport protocol (e.g., TCP), is the Record Protocol. It 193 provides connection security by using symmetric cryptography for 194 confidentiality, data origin authentication, and integrity 195 protection. The Record Protocol is used for encapsulation of various 196 higher-level protocols. The handshaking protocols consist of three 197 sub-protocols, namely the handshake protocol, the change cipher spec 198 protocol and the alert protocol. The handshake protocol allows the 199 server and client to authenticate each other and to negotiate an 200 encryption algorithm and cryptographic keys before the application 201 protocol transmits or receives data. 203 The design of DTLS [RFC6347] is intentionally very similar to TLS. 204 However, since DTLS operates on top of an unreliable datagram 205 transport, it must explicitly cope with the absence of reliable and 206 ordered delivery assumptions made by TLS. RFC 6347 explains these 207 differences in great detail. As a short summary, for those not 208 familiar with DTLS the differences are: 210 o An explicit sequence number and an epoch field is included in the 211 Record Protocol. Section 4.1 of RFC 6347 explains the processing 212 rules for these two new fields. The value used to compute the MAC 213 is the 64-bit value formed by concatenating the epoch and the 214 sequence number. 216 o Stream ciphers must not be used with DTLS. The only stream cipher 217 defined for TLS 1.2 is RC4 and due to cryptographic weaknesses it 218 is not recommended anymore even for use with TLS [RFC7465]. Note 219 that the term 'stream cipher' is a technical term in the TLS 220 specification. Section 4.7 of RFC 5246 defines stream ciphers in 221 TLS as follows: in stream cipher encryption, the plaintext is 222 exclusive-ORed with an identical amount of output generated from a 223 cryptographically secure keyed pseudorandom number generator. 225 o The TLS Handshake Protocol has been enhanced to include a 226 stateless cookie exchange for Denial of Service (DoS) resistance. 227 For this purpose a new handshake message, the HelloVerifyRequest, 228 was added to DTLS. This handshake message is sent by the server 229 and includes a stateless cookie, which is returned in a 230 ClientHello message back to the server. Although the exchange is 231 optional for the server to execute, a client implementation has to 232 be prepared to respond to it. Furthermore, the handshake message 233 format has been extended to deal with message loss, reordering, 234 and fragmentation. 236 3.2. Communication Models 238 This document describes a profile of DTLS and, to be useful, it has 239 to make assumptions about the envisioned communication architecture. 241 Two communication architectures (and consequently two profiles) are 242 described in this document. 244 3.2.1. Constrained TLS/DTLS Clients 246 The communication architecture shown in Figure 1 assumes a unicast 247 communication interaction with an IoT device utilizing a constrained 248 TLS/DTLS client interacting with one or multiple TLS/DTLS servers. 250 Before a client can initiate the TLS/DTLS handshake it needs to know 251 the IP address of that server and what credentials to use. 252 Application layer protocols, such as CoAP, which is conveyed on top 253 of DTLS, may be configured with URIs of the endpoints to which CoAP 254 needs to register and publish data. This configuration information 255 (including non-confidential credentials, like certificates) may be 256 conveyed to clients as part of a firmware/software package or via a 257 configuration protocol. The following credential types are supported 258 by this profile: 260 o For PSK-based authentication (see Section 4.2), this includes the 261 paired "PSK identity" and shared secret to be used with each 262 server. 264 o For raw public key-based authentication (see Section 4.3), this 265 includes either the server's public key or the hash of the 266 server's public key. 268 o For certificate-based authentication (see Section 4.4), this 269 includes a pre-populated trust anchor store that allows the DTLS 270 stack to perform path validation for the certificate obtained 271 during the handshake with the server. 273 Figure 1 shows example configuration information stored at the 274 constrained client for use with respective servers. 276 This document focuses on the description of the DTLS client-side 277 functionality but, quite naturally, the equivalent server-side 278 support has to be available. 280 +////////////////////////////////////+ 281 | Configuration | 282 |////////////////////////////////////| 283 | Server A --> PSK Identity, PSK | 284 | | 285 | Server B --> Public Key (Server B),| 286 | Public/Private Key | 287 | (for Client) | 288 | | 289 | Server C --> Public/Private Key | 290 | (for Client) | 291 | Trust Anchor Store | 292 +------------------------------------+ 293 oo 294 oooooo 295 o 296 +-----------+ 297 |Constrained| 298 |TLS/DTLS | 299 |Client |- 300 +-----------+ \ 301 \ ,-------. 302 ,' `. +------+ 303 / IP-based \ |Server| 304 ( Network ) | A | 305 \ / +------+ 306 `. ,' 307 '---+---' +------+ 308 | |Server| 309 | | B | 310 | +------+ 311 | 312 | +------+ 313 +----------------->|Server| 314 | C | 315 +------+ 317 Figure 1: Constrained Client Profile. 319 3.2.1.1. Examples of Constrained Client Exchanges 321 3.2.1.1.1. Network Access Authentication Example 323 Re-use is a recurring theme when considering constrained environments 324 and is behind a lot of the directions taken in developments for 325 constrained environments. The corollary of re-use is to not add 326 functionality if it can be avoided. An example relevant to the use 327 of TLS is network access authentication, which takes place when a 328 device connects to a network and needs to go through an 329 authentication and access control procedure before it is allowed to 330 communicate with other devices or connect to the Internet. 332 Figure 2 shows the network access architecture with the IoT device 333 initiating the communication to an access point in the network using 334 the procedures defined for a specific physical layer. Since 335 credentials may be managed and stored centrally, in the 336 Authentication, Authorization, and Accounting (AAA) server, the 337 security protocol exchange may need to be relayed via the 338 Authenticator, i.e., functionality running on the access point, to 339 the AAA server. The authentication and key exchange protocol itself 340 is encapsulated within a container, the Extensible Authentication 341 Protocol (EAP) [RFC3748], and messages are conveyed back and forth 342 between the EAP endpoints, namely the EAP peer located on the IoT 343 device and the EAP server located on the AAA server or the access 344 point. To route EAP messages from the access point, acting as a AAA 345 client, to the AAA server requires an adequate protocol mechanism, 346 namely RADIUS [RFC2865] or Diameter [RFC6733]. 348 More details about the concepts and a description about the 349 terminology can be found in RFC 5247 [RFC5247]. 351 +--------------+ 352 |Authentication| 353 |Authorization | 354 |Accounting | 355 |Server | 356 |(EAP Server) | 357 | | 358 +-^----------^-+ 359 * EAP o RADIUS/ 360 * o Diameter 361 --v----------v-- 362 /// \\\ 363 // \\ 364 | Federation | 365 | Substrate | 366 \\ // 367 \\\ /// 368 --^----------^-- 369 * EAP o RADIUS/ 370 * o Diameter 371 +-------------+ +-v----------v--+ 372 | | EAP/EAP Method | | 373 | Internet of |<***************************>| Access Point | 374 | Things | |(Authenticator)| 375 | Device | EAP Lower Layer and |(AAA Client) | 376 | (EAP Peer) | Secure Association Protocol | | 377 | |<--------------------------->| | 378 | | | | 379 | | Physical Layer | | 380 | |<===========================>| | 381 +-------------+ +---------------+ 382 Legend: 384 <****>: Device-to-AAA Server Exchange 385 <---->: Device-to-Authenticator Exchange 386 : AAA Client-to-AAA Server Exchange 387 <====>: Physical layer like IEEE 802.11/802.15.4 389 Figure 2: Network Access Architecture. 391 One standardized EAP method is EAP-TLS, defined in RFC 5216 392 [RFC5216], which re-uses the TLS-based protocol exchange and 393 encapsulates it inside the EAP payload. In terms of re-use this 394 allows many components of the TLS protocol to be shared between the 395 network access security functionality and the TLS functionality 396 needed for securing application layer traffic. In the EAP-TLS 397 exchange shown in Figure 3 the IoT device as the EAP peer acts as a 398 TLS client. 400 Authenticating Peer Authenticator 401 ------------------- ------------- 402 <- EAP-Request/ 403 Identity 404 EAP-Response/ 405 Identity (MyID) -> 406 <- EAP-Request/ 407 EAP-Type=EAP-TLS 408 (TLS Start) 409 EAP-Response/ 410 EAP-Type=EAP-TLS 411 (TLS client_hello)-> 412 <- EAP-Request/ 413 EAP-Type=EAP-TLS 414 (TLS server_hello, 415 TLS certificate, 416 [TLS server_key_exchange,] 417 TLS certificate_request, 418 TLS server_hello_done) 419 EAP-Response/ 420 EAP-Type=EAP-TLS 421 (TLS certificate, 422 TLS client_key_exchange, 423 TLS certificate_verify, 424 TLS change_cipher_spec, 425 TLS finished) -> 426 <- EAP-Request/ 427 EAP-Type=EAP-TLS 428 (TLS change_cipher_spec, 429 TLS finished) 430 EAP-Response/ 431 EAP-Type=EAP-TLS -> 432 <- EAP-Success 434 Figure 3: EAP-TLS Exchange. 436 The guidance in this document also applies to the use of EAP-TLS for 437 network access authentication. An IoT device using a network access 438 authentication solution based on TLS can re-use most parts of the 439 code for the use of DTLS/TLS at the application layer thereby saving 440 a significant amount of flash memory. Note, however, that the 441 credentials used for network access authentication and those used for 442 application layer security are very likely different. 444 3.2.1.1.2. CoAP-based Data Exchange Example 446 When a constrained client uploads sensor data to a server 447 infrastructure it may use CoAP by pushing the data via a POST message 448 to a pre-configured endpoint on the server. In certain circumstances 449 this might be too limiting and additional functionality is needed, as 450 shown in Figure 4 and Figure 5, where the IoT device itself runs a 451 CoAP server hosting the resource that is made accessible to other 452 entities. Despite running a CoAP server on the IoT device it is 453 still the DTLS client on the IoT device that initiates the 454 interaction with the non-constrained resource server in our scenario. 456 Figure 4 shows a sensor starting a DTLS exchange with a resource 457 directory and uses CoAP to register available resources in Figure 5. 458 [I-D.ietf-core-resource-directory] defines the resource directory 459 (RD) as a web entity that stores information about web resources and 460 implements Representational State Transfer (REST) interfaces for 461 registration and lookup of those resources. Note that the described 462 exchange is borrowed from the OMA Lightweight Machine-to-Machine 463 (LWM2M) specification [LWM2M] that uses RD but adds proxy 464 functionality. 466 The initial DTLS interaction between the sensor, acting as a DTLS 467 client, and the resource directory, acting as a DTLS server, will be 468 a full DTLS handshake. Once this handshake is complete both parties 469 have established the DTLS record layer. Subsequently, the CoAP 470 client can securely register at the resource directory. 472 After some time (assuming that the client regularly refreshes its 473 registration) the resource directory receives a request from an 474 application to retrieve the temperature information from the sensor. 475 This request is relayed by the resource directory to the sensor using 476 a GET message exchange. The already established DTLS record layer 477 can be used to secure the message exchange. 479 Resource 480 Sensor Directory 481 ------ --------- 483 +--- 484 | 485 | ClientHello --------> 486 | #client_certificate_type# 487 F| #server_certificate_type# 488 U| 489 L| <------- HelloVerifyRequest 490 L| 491 | ClientHello --------> 492 D| #client_certificate_type# 493 T| #server_certificate_type# 494 L| 495 S| ServerHello 496 | #client_certificate_type# 497 H| #server_certificate_type# 498 A| Certificate 499 N| ServerKeyExchange 500 D| CertificateRequest 501 S| <-------- ServerHelloDone 502 H| 503 A| Certificate 504 K| ClientKeyExchange 505 E| CertificateVerify 506 | [ChangeCipherSpec] 507 | Finished --------> 508 | 509 | [ChangeCipherSpec] 510 | <-------- Finished 511 +--- 513 Note: Extensions marked with '#' were introduced with 514 RFC 7250. 516 Figure 4: DTLS/CoAP exchange using Resource Directory: Part 1 - DTLS 517 Handshake. 519 Figure 5 shows the DTLS-secured communication between the sensor and 520 the resource directory using CoAP. 522 Resource 523 Sensor Directory 524 ------ --------- 526 [[==============DTLS-secured Communication===================]] 528 +--- ///+ 529 C| \ D 530 O| Req: POST coap://rd.example.com/rd?ep=node1 \ T 531 A| Payload: \ L 532 P| ;ct=41; \ S 533 | rt="temperature-c";if="sensor", \ 534 R| ;ct=41; \ R 535 D| rt="light-lux";if="sensor" \ E 536 | --------> \ C 537 R| \ O 538 E| \ R 539 G| Res: 2.01 Created \ D 540 .| <-------- Location: /rd/4521 \ 541 | \ L 542 +--- \ A 543 \ Y 544 * \ E 545 * (time passes) \ R 546 * \ 547 +--- \ P 548 C| \ R 549 O| Req: GET coaps://sensor.example.com/temp \ O 550 A| <-------- \ T 551 P| \ E 552 | Res: 2.05 Content \ C 553 G| Payload: \ T 554 E| 25.5 --------> \ E 555 T| \ D 556 +--- ///+ 558 Figure 5: DTLS/CoAP exchange using Resource Directory: Part 2 - CoAP/ 559 RD Exchange. 561 Note that the CoAP GET message transmitted from the Resource Server 562 is protected using the previously established DTLS Record Layer. 564 3.2.2. Constrained TLS/DTLS Servers 566 Section 3.2.1 illustrates a deployment model where the TLS/DTLS 567 client is constrained and efforts need to be taken to improve memory 568 utilization, bandwidth consumption, reduce performance impacts, etc. 570 In this section, we assume a scenario where constrained devices run 571 TLS/DTLS servers to secure access to application layer services 572 running on top of CoAP, HTTP or other protocols. Figure 6 573 illustrates a possible deployment whereby a number of constrained 574 servers are waiting for regular clients to access their resources. 575 The entire process is likely, but not necessarily, controlled by a 576 third party, the authentication and authorization server. This 577 authentication and authorization server is responsible for holding 578 authorization policies that govern the access to resources and 579 distribution of keying material. 581 +////////////////////////////////////+ 582 | Configuration | 583 |////////////////////////////////////| 584 | Credentials | 585 | Client A -> Public Key | 586 | Server S1 -> Symmetric Key | 587 | Server S2 -> Certificate | 588 | Server S3 -> Public Key | 589 | Trust Anchor Store | 590 | Access Control Lists | 591 | Resource X: Client A / GET | 592 | Resource Y: Client A / PUT | 593 +------------------------------------+ 594 oo 595 oooooo 596 o 597 +---------------+ +-----------+ 598 |Authentication | +-------->|TLS/DTLS | 599 |& Authorization| | |Client A | 600 |Server | | +-----------+ 601 +---------------+ ++ 602 ^ | +-----------+ 603 \ | |Constrained| 604 \ ,-------. | Server S1 | 605 ,' `. +-----------+ 606 / Local \ 607 ( Network ) 608 \ / +-----------+ 609 `. ,' |Constrained| 610 '---+---' | Server S2 | 611 | +-----------+ 612 | 613 | +-----------+ 614 +-----------------> |Constrained| 615 | Server S3 | 616 +-----------+ 618 Figure 6: Constrained Server Profile. 620 A deployment with constrained servers has to overcome several 621 challenges. Below we explain how these challenges can be solved with 622 CoAP, as an example. Other protocols may offer similar capabilities. 623 While the requirements for the TLS/DTLS protocol profile change only 624 slightly when run on a constrained server (in comparison to running 625 it on a constrained client) several other eco-system factors will 626 impact deployment. 628 There are several challenges that need to be addressed: 630 Discovery and Reachability: 632 A client must first and foremost discover the server before 633 initiating a connection to it. Once it has been discovered, 634 reachability to the device needs to be maintained. 636 In CoAP the discovery of resources offered by servers is 637 accomplished by sending a unicast or multicast CoAP GET to a well- 638 known URI. The CORE Link format specification [RFC6690] describes 639 the use case (see Section 1.2.1), and reserves the URI (see 640 Section 7.1). Section 7 of the CoAP specification [RFC7252] 641 describes the discovery procedure. [RFC7390] describes use case 642 for discovering CoAP servers using multicast (see Section 3.3), 643 and specifies the protocol processing rules for CoAP group 644 communications (see Section 2.7). 646 The use of Resource Directory (RD) 647 [I-D.ietf-core-resource-directory] is yet another possibility for 648 discovering registered servers and their resources. Since RD is 649 usually not a proxy, clients can discover links registered with 650 the RD and then access them directly. 652 Authentication: 654 The next challenge concerns the provisioning of authentication 655 credentials to the clients as well as servers. In Section 3.2.1 656 we assumed that credentials (and other configuration information) 657 are provisioned to the device and that those can be used with the 658 authorization servers. Of course, this leads to a very static 659 relationship between the clients and their server-side 660 infrastructure but poses fewer challenges from a deployment point 661 of view, as described in Section 2 of [RFC7452]. In any case, 662 engineers and product designers have to determine how the relevant 663 credentials are distributed to the respective parties. For 664 example, shared secrets may need to be provisioned to clients and 665 the constrained servers for subsequent use of TLS/DTLS PSK. In 666 other deployments, certificates, private keys, and trust anchors 667 for use with certificate-based authentication may need to be 668 utilized. 670 Practical solutions either use pairing (also called imprinting) or 671 a trusted third party. With pairing two devices execute a special 672 protocol exchange that is unauthenticated to establish a shared 673 key (for example using an unauthenticated Diffie-Hellman 674 exchange). To avoid man-in-the-middle attacks an out-of-band 675 channel is used to verify that nobody has tampered with the 676 exchanged protocol messages. This out-of-band channel can come in 677 many forms, including: 679 * Human involvement by comparing hashed keys, entering passkeys, 680 scanning QR codes 682 * The use of alternative wireless communication channels (e.g., 683 infra-red communication in addition to WiFi) 685 * Proximity-based information 687 More details about these different pairing/imprinting techniques 688 can be found in the smart object security workshop report 689 [RFC7397] and various position papers submitted on that topic, 690 such as [ImprintingSurvey]. The use of a trusted third party 691 follows a different approach and is subject to ongoing 692 standardization efforts in the 'Authentication and Authorization 693 for Constrained Environments (ACE)' working group [ACE-WG]. 695 Authorization 697 The last challenge is the ability for the constrained server to 698 make an authorization decision when clients access protected 699 resources. Pre-provisioning access control information to 700 constrained servers may be one option but works only in a small 701 scale, less dynamic environment. For a finer-grained and more 702 dynamic access control solution the reader is referred to the 703 ongoing work in the IETF ACE working group. 705 Figure 7 shows an example interaction whereby a device, a thermostat 706 in our case, searches in the local network for discoverable resources 707 and accesses those. The thermostat starts the procedure using a 708 link-local discovery message using the "All CoAP Nodes" multicast 709 address by utilizing the RFC 6690 [RFC6690] link format. The IPv6 710 multicast address used for CoAP link-local discovery is FF02::FD. As 711 a result, a temperature sensor and a fan respond. These responses 712 allow the thermostat to subsequently read temperature information 713 from the temperature sensor with a CoAP GET request issued to the 714 previously learned endpoint. In this example we assume that 715 accessing the temperature sensor readings and controlling the fan 716 requires authentication and authorization of the thermostat and TLS 717 is used to authenticate both endpoints and to secure the 718 communication. 720 Temperature 721 Thermostat Sensor Fan 722 ---------- --------- --- 724 Discovery 725 --------------------> 726 GET coap://[FF02::FD]/.well-known/core 728 CoAP 2.05 Content 729 <------------------------------- 730 ;rt="temperature"; 731 if="sensor" 733 CoAP 2.05 Content 734 <-------------------------------------------------- 735 ;rt="fan";if="actuation" 737 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ 738 \ Protocol steps to obtain access token or keying / 739 \ material for access to the temperature sensor and fan. / 740 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ 742 Read Sensor Data 743 (authenticated/authorized) 744 -------------------------------> 745 GET /3303/0/5700 747 CoAP 2.05 Content 748 <------------------------------- 749 22.5 C 751 Configure Actuator 752 (authenticated/authorized) 753 -------------------------------------------------> 754 PUT /fan?on-off=true 755 CoAP 2.04 Changed 756 <------------------------------------------------- 758 Figure 7: Local Discovery and Resource Access. 760 3.3. The Ciphersuite Concept 762 TLS (and consequently DTLS) has the concept of ciphersuites and an 763 IANA registry [IANA-TLS] was created to register the suites. A 764 ciphersuite (and the specification that defines it) contains the 765 following information: 767 o Authentication and key exchange algorithm (e.g., PSK) 769 o Cipher and key length (e.g., Advanced Encryption Standard (AES) 770 with 128 bit keys [AES]) 772 o Mode of operation (e.g., Counter with Cipher Block Chaining - 773 Message Authentication Code (CBC-MAC) Mode (CCM) for AES) 774 [RFC3610] 776 o Hash algorithm for integrity protection, such as the Secure Hash 777 Algorithm (SHA) in combination with Keyed-Hashing for Message 778 Authentication (HMAC) (see [RFC2104] and [RFC6234]) 780 o Hash algorithm for use with pseudorandom functions (e.g., HMAC 781 with the SHA-256) 783 o Misc information (e.g., length of authentication tags) 785 o Information whether the ciphersuite is suitable for DTLS or only 786 for TLS 788 The TLS ciphersuite TLS_PSK_WITH_AES_128_CCM_8, for example, uses a 789 pre-shared authentication and key exchange algorithm. [RFC6655] 790 defines this ciphersuite. It uses the Advanced Encryption Standard 791 (AES) encryption algorithm, which is a block cipher. Since the AES 792 algorithm supports different key lengths (such as 128, 192 and 256 793 bits) this information has to be specified as well and the selected 794 ciphersuite supports 128 bit keys. A block cipher encrypts plaintext 795 in fixed-size blocks and AES operates on fixed block size of 128 796 bits. For messages exceeding 128 bits, the message is partitioned 797 into 128-bit blocks and the AES cipher is applied to these input 798 blocks with appropriate chaining, which is called mode of operation. 800 TLS 1.2 introduced Authenticated Encryption with Associated Data 801 (AEAD) ciphersuites (see [RFC5116] and [RFC6655]). AEAD is a class 802 of block cipher modes which encrypt (parts of) the message and 803 authenticate the message simultaneously. Examples of such modes 804 include the Counter with Cipher Block Chaining - Message 805 Authentication Code (CBC-MAC) Mode (CCM) mode, and the Galois/Counter 806 Mode (GCM) (see [RFC5288] and [RFC7251]). 808 Some AEAD ciphersuites have shorter authentication tags (i.e., 809 message authentication codes) and are therefore more suitable for 810 networks with low bandwidth where small message size matters. The 811 TLS_PSK_WITH_AES_128_CCM_8 ciphersuite that ends in "_8" has an 812 8-octet authentication tag, while the regular CCM ciphersuites have, 813 at the time of writing, 16-octet authentication tags. The design of 814 CCM and the security properties are described in [CCM]. 816 TLS 1.2 also replaced the combination of MD5/SHA-1 hash functions in 817 the TLS pseudo random function (PRF) used in earlier versions of TLS 818 with cipher-suite-specified PRFs. For this reason authors of more 819 recent TLS 1.2 ciphersuite specifications explicitly indicate the MAC 820 algorithm and the hash functions used with the TLS PRF. 822 4. Credential Types 824 The mandatory-to-implement functionality will depend on the 825 credential type used with IoT devices. The sub-sections below 826 describe the implications of three different credential types, namely 827 pre-shared secrets, raw public keys, and certificates. 829 4.1. Pre-Conditions 831 All exchanges described in the subsequent sections assume that some 832 information has been distributed before the TLS/DTLS interaction can 833 start. The credentials are used to authenticate the client to the 834 server and vice versa. What information items have to be distributed 835 depends on the chosen credential types. In all cases the IoT device 836 needs to know what algorithms to prefer, particularly if there are 837 multiple algorithms choices available as part of the implemented 838 ciphersuites, as well as information about the other communication 839 endpoint (for example in form of a URI) a particular credential has 840 to be used with. 842 Pre-Shared Secrets: In this case a shared secret together with an 843 identifier needs to be made available to the device as well as to 844 the other communication party. 846 Raw Public Keys: A public key together with a private key are stored 847 on the device and typically associated with some identifier. To 848 authenticate the other communication party the appropriate 849 credential has to be known. If the other end uses raw public keys 850 as well then their public key needs to be provisioned (out-of- 851 band) to the device. 853 Certificates The use of certificates requires the device to store 854 the public key (as part of the certificate) as well as the private 855 key. The certificate will contain the identifier of the device as 856 well as various other attributes. Both communication parties are 857 assumed to be in possession of a trust anchor store that contains 858 CA certificates and, in case of certificate pinning, end-entity 859 certificates. Similarly to the other credentials the IoT device 860 needs information about which entity to use which certificate 861 with. Without a trust anchor store on the IoT device it will not 862 be possible to perform certificate validation. 864 We call the above-listed information device credentials and these 865 device credentials may be provisioned to the device already during 866 the manufacturing time or later in the process, depending on the 867 envisioned business and deployment model. These initial credentials 868 are often called 'root of trust'. Whatever process for generating 869 these initial device credential is chosen it MUST be ensured that a 870 different key pair is provisioned for each device and installed in 871 as-secure a manner as possible. For example, it is preferable to 872 generate public / private keys on the IoT device itself rather than 873 generating them outside the device. Since an IoT device is likely to 874 interact with various other parties the initial device credential may 875 only be used with some dedicated entities and configuring further 876 configuration and credentials to the device is left to a separate 877 interaction. An example of a dedicated protocol used to distribute 878 credentials, access control lists and configuration information is 879 the Lightweight Machine-to-Machine (LWM2M) protocol [LWM2M]. 881 For all the credentials listed above there is a chance that those may 882 need to be replaced or deleted. While separate protocols have been 883 developed to check the status of these credentials and to manage 884 these credentials, such as the Trust Anchor Management Protocol 885 (TAMP) [RFC5934], their usage is, however, not envisioned in the IoT 886 context so far. IoT devices are assumed to have a software update 887 mechanism built-in and it will allow updates of low-level device 888 information, including credentials and configuration parameters. 889 This document does, however, not mandate a specific software / 890 firmware update protocol. 892 With all credentials used as input to TLS/DTLS authentication it is 893 important that these credentials have been generated with care. When 894 using a pre-shared secret, a critical consideration is use sufficient 895 entropy during the key generation, as discussed in [RFC4086]. 896 Deriving a shared secret from a password, some device identifiers, or 897 other low-entropy source is not secure. A low-entropy secret, or 898 password, is subject to dictionary attacks. Attention also has to be 899 paid when generating public / private key pairs since the lack of 900 randomness can result in the same key pair being used in many 901 devices. This topic is also discussed in Section 12 since keys are 902 generated during the TLS/DTLS exchange itself as well and the same 903 considerations apply. 905 4.2. Pre-Shared Secret 907 The use of pre-shared secrets is one of the most basic techniques for 908 TLS/DTLS since it is both computationally efficient and bandwidth 909 conserving. Pre-shared secret based authentication was introduced to 910 TLS with RFC 4279 [RFC4279]. 912 The exchange shown in Figure 8 illustrates the DTLS exchange 913 including the cookie exchange. While the server is not required to 914 initiate a cookie exchange with every handshake, the client is 915 required to implement and to react on it when challenged, as defined 916 in RFC 6347 [RFC6347]. The cookie exchange allows the server to 917 react to flooding attacks. 919 Client Server 920 ------ ------ 921 ClientHello --------> 923 <-------- HelloVerifyRequest 924 (contains cookie) 926 ClientHello --------> 927 (with cookie) 928 ServerHello 929 *ServerKeyExchange 930 <-------- ServerHelloDone 931 ClientKeyExchange 932 ChangeCipherSpec 933 Finished --------> 934 ChangeCipherSpec 935 <-------- Finished 937 Application Data <-------> Application Data 939 Legend: 941 * indicates an optional message payload 943 Figure 8: DTLS PSK Authentication including the Cookie Exchange. 945 Note that [RFC4279] used the term PSK identity to refer to the 946 identifier used to refer to the appropriate secret. While 947 'identifier' would be more appropriate in this context we re-use the 948 terminology defined in RFC 4279 to avoid confusion. RFC 4279 does 949 not mandate the use of any particular type of PSK identity and the 950 client and server have to agree on the identities and keys to be 951 used. The UTF-8 encoding of identities described in Section 5.1 of 952 RFC 4279 aims to improve interoperability for those cases where the 953 identity is configured by a human using some management interface 954 provided by a Web browser. However, many IoT devices do not have a 955 user interface and most of their credentials are bound to the device 956 rather than to the user. Furthermore, credentials are often 957 provisioned into hardware modules or provisioned alongside with 958 firmware. As such, the encoding considerations are not applicable to 959 this usage environment. For use with this profile the PSK identities 960 SHOULD NOT assume a structured format (such as domain names, 961 Distinguished Names, or IP addresses) and a byte-by-byte comparison 962 operation MUST be used by the server for any operation related to the 963 PSK identity. RFC 6943 [RFC6943] calls these types of identifiers 964 "absolute". 966 Protocol-wise the client indicates which key it uses by including a 967 "PSK identity" in the ClientKeyExchange message. As described in 968 Section 3.2 clients may have multiple pre-shared keys with a single 969 server, for example in a hosting context. The TLS Server Name 970 Indication (SNI) extension allows the client to convey the name of 971 the server it is contacting. A server implementation needs to guide 972 the selection based on a received SNI value from the client. 974 RFC 4279 requires TLS implementations supporting PSK ciphersuites to 975 support arbitrary PSK identities up to 128 octets in length, and 976 arbitrary PSKs up to 64 octets in length. This is a useful 977 assumption for TLS stacks used in the desktop and mobile environments 978 where management interfaces are used to provision identities and 979 keys. Implementations in compliance with this profile MAY use PSK 980 identities up to 128 octets in length, and arbitrary PSKs up to 64 981 octets in length. The use of shorter PSK identities is RECOMMENDED. 983 Constrained Application Protocol (CoAP) [RFC7252] currently specifies 984 TLS_PSK_WITH_AES_128_CCM_8 as the mandatory to implement ciphersuite 985 for use with shared secrets. This ciphersuite uses the AES algorithm 986 with 128 bit keys and CCM as the mode of operation. The label "_8" 987 indicates that an 8-octet authentication tag is used. Note that the 988 shorted authentication tag increases the chance that an adversary 989 with no knowledge of the secret key can present a message with a MAC 990 that will pass the verification procedure. The likelihoods of 991 accepting forged data is explained in Section 5.3.5 of 992 [SP800-107-rev1] and depends on the lengths of the authentication tag 993 and allowed numbers of MAC verifications using a given key. 995 This ciphersuite makes use of the default TLS 1.2 Pseudorandom 996 Function (PRF), which uses an HMAC with the SHA-256 hash function. 997 Note: Starting with TLS 1.2 (and consequently DTLS 1.2) ciphersuites 998 have to specify the pseudorandom function. RFC 5246 states that 'New 999 cipher suites MUST explicitly specify a PRF and, in general, SHOULD 1000 use the TLS PRF with SHA-256 or a stronger standard hash function.'. 1001 The ciphersuites recommended in this document use the SHA-256 1002 construct defined in Section 5 of RFC 5246. 1004 A device compliant with the profile in this section MUST implement 1005 TLS_PSK_WITH_AES_128_CCM_8 and follow the guidance from this section. 1007 4.3. Raw Public Key 1009 The use of raw public keys with TLS/DTLS, as defined in [RFC7250], is 1010 the first entry point into public key cryptography without having to 1011 pay the price of certificates and a public key infrastructure (PKI). 1012 The specification re-uses the existing Certificate message to convey 1013 the raw public key encoded in the SubjectPublicKeyInfo structure. To 1014 indicate support two new extensions had been defined, as shown in 1015 Figure 9, namely the server_certificate_type and the 1016 client_certificate_type. 1018 Client Server 1019 ------ ------ 1021 ClientHello --------> 1022 #client_certificate_type# 1023 #server_certificate_type# 1025 ServerHello 1026 #client_certificate_type# 1027 #server_certificate_type# 1028 Certificate 1029 ServerKeyExchange 1030 CertificateRequest 1031 <-------- ServerHelloDone 1033 Certificate 1034 ClientKeyExchange 1035 CertificateVerify 1036 [ChangeCipherSpec] 1037 Finished --------> 1039 [ChangeCipherSpec] 1040 <-------- Finished 1042 Note: Extensions marked with '#' were introduced with 1043 RFC 7250. 1045 Figure 9: DTLS Raw Public Key Exchange. 1047 The CoAP recommended ciphersuite for use with this credential type is 1048 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251]. This elliptic curve 1049 cryptography (ECC) based AES-CCM TLS ciphersuite uses the Ephemeral 1050 Elliptic Curve Diffie-Hellman (ECDHE) as the key establishment 1051 mechanism and an Elliptic Curve Digital Signature Algorithm (ECDSA) 1052 for authentication. The named Diffie-Hellman groups 1054 [I-D.ietf-tls-negotiated-dl-dhe] are not applicable to this profile 1055 since it relies on the ECC-based counterparts. This ciphersuite 1056 makes use of the AEAD capability in DTLS 1.2 and utilizes an eight- 1057 octet authentication tag. The use of a Diffie-Hellman key exchange 1058 provides perfect forward secrecy (PFS). More details about PFS can 1059 be found in Section 9. 1061 [RFC6090] provides valuable information for implementing Elliptic 1062 Curve Cryptography algorithms, particularly for choosing methods that 1063 have been available in the literature for a long time (i.e., 20 years 1064 and more). 1066 A device compliant with the profile in this section MUST implement 1067 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this 1068 section. 1070 4.4. Certificates 1072 The use of mutual certificate-based authentication is shown in 1073 Figure 10, which makes use of the cached info extension 1074 [I-D.ietf-tls-cached-info]. Support of the cached info extension is 1075 REQUIRED. Caching certificate chains allows the client to reduce the 1076 communication overhead significantly since otherwise the server would 1077 provide the end entity certificate, and the certificate chain with 1078 every full DTLS handshake. 1080 Client Server 1081 ------ ------ 1083 ClientHello --------> 1084 *cached_info* 1086 ServerHello 1087 *cached_info* 1088 Certificate 1089 ServerKeyExchange 1090 CertificateRequest 1091 <-------- ServerHelloDone 1093 Certificate 1094 ClientKeyExchange 1095 CertificateVerify 1096 [ChangeCipherSpec] 1097 Finished --------> 1099 [ChangeCipherSpec] 1100 <-------- Finished 1102 Note: Extensions marked with '*' were introduced with 1103 [I-D.ietf-tls-cached-info]. 1105 Figure 10: DTLS Mutual Certificate-based Authentication. 1107 TLS/DTLS offers a lot of choices when selecting ECC-based 1108 ciphersuites. This document restricts the use to named curves 1109 defined in RFC 4492 [RFC4492]. At the time of writing the 1110 recommended curve is secp256r1 and the use of uncompressed points to 1111 follow the recommendation in CoAP. Note that standardization for 1112 Curve25519 (for ECDHE) is ongoing (see [I-D.irtf-cfrg-curves]) and 1113 support for this curve will likely be required in the future. 1115 A device compliant with the profile in this section MUST implement 1116 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this 1117 section. 1119 4.4.1. Certificates used by Servers 1121 The algorithm for verifying the service identity, as described in RFC 1122 6125 [RFC6125], is essential for ensuring proper security when 1123 certificates are used. As a summary, the algorithm contains the 1124 following steps: 1126 1. The client constructs a list of acceptable reference identifiers 1127 based on the source domain and, optionally, the type of service 1128 to which the client is connecting. 1130 2. The server provides its identifiers in the form of a PKIX 1131 certificate. 1133 3. The client checks each of its reference identifiers against the 1134 presented identifiers for the purpose of finding a match. 1136 4. When checking a reference identifier against a presented 1137 identifier, the client matches the source domain of the 1138 identifiers and, optionally, their application service type. 1140 For various terms used in the algorithm shown above consult RFC 6125. 1141 It is important to highlight that comparing the reference identifier 1142 against the presented identifier obtained from the certificate is 1143 required to ensure the client is communicating with the intended 1144 server. 1146 It is worth noting that the algorithm description and the text in RFC 1147 6125 assumes that fully qualified DNS domain names are used. If a 1148 server node is provisioned with a fully qualified DNS domain then the 1149 server certificate MUST contain the fully qualified DNS domain name 1150 or "FQDN" as dNSName [RFC5280]. For CoAP, the coaps URI scheme is 1151 described in Section 6.2 of [RFC7252]. This FQDN is stored in the 1152 SubjectAltName or in the leftmost CN component of subject name, as 1153 explained in Section 9.1.3.3 of [RFC7252], and used by the client to 1154 match it against the FQDN used during the look-up process, as 1155 described in [RFC6125]. For other protocols, the appropriate URI 1156 scheme specification has to be consulted. 1158 The following recommendation is provided: 1160 1. Certificates MUST NOT use DNS domain names in the Common Name of 1161 certificates and instead use the subjectAltName attribute, as 1162 described in the previous paragraph. 1164 2. Certificates MUST NOT contain domain names with wildcard 1165 characters. 1167 3. Certificates MUST NOT contain multiple names (e.g., more than one 1168 dNSName field). 1170 Note that there will be servers that are not provisioned for use with 1171 DNS domain names, for example, IoT devices that offer resources to 1172 nearby devices in a local area network, as shown in Figure 7. When 1173 such constrained servers are used then the use of certificates as 1174 described in Section 4.4.2 is applicable. Note that the Service Name 1175 Indication (SNI) extension cannot be used in this case since SNI does 1176 not offer the ability to convey EUI-64 [EUI64] identifiers. Note 1177 that this document does not recommend to use IP addresses in 1178 certificates nor does it discuss the implications of placing IP 1179 addresses in certificates. 1181 4.4.2. Certificates used by Clients 1183 For client certificates the identifier used in the SubjectAltName or 1184 in the leftmost CN component of subject name MUST be an EUI-64. 1186 4.4.3. Certificate Revocation 1188 For certificate revocation neither the Online Certificate Status 1189 Protocol (OCSP) nor Certificate Revocation Lists (CRLs) are used. 1190 Instead, this profile relies on a software update mechanism to 1191 provision information about revoked certificates. While multiple 1192 OCSP stapling [RFC6961] has recently been introduced as a mechanism 1193 to piggyback OCSP request/responses inside the DTLS/TLS handshake (to 1194 avoid the cost of a separate protocol handshake), further 1195 investigations are needed to determine its suitability for the IoT 1196 environment. 1198 As stated earlier in this section, modifications to the trust anchor 1199 store depends on a software update mechanism as well. There are 1200 limitations to the use of a software update mechanism because of the 1201 potential inability to change certain types of keys, such as those 1202 provisioned during manufacturing. For this reason, manufacturer 1203 provisioned credentials are typically employed only to obtain further 1204 certificates (for example via a key distribution server) for use with 1205 servers the IoT device is finally communicating with. 1207 4.4.4. Certificate Content 1209 All certificate elements listed in Table 1 MUST be implemented by 1210 clients and servers claiming support for certificate-based 1211 authentication. No other certificate elements are used by this 1212 specification. 1214 When using certificates, IoT devices MUST provide support for a 1215 server certificate chain of at least 3 not including the trust anchor 1216 and MAY reject connections from servers offering chains longer than 1217 3. IoT devices MAY have client certificate chains of any length. 1218 Obviously, longer chains require more digital signature verification 1219 operations to perform and lead to larger certificate messages in the 1220 TLS handshake. 1222 Table 1 provides a summary of the elements in a certificate for use 1223 with this profile. 1225 +----------------------+--------------------------------------------+ 1226 | Element | Notes | 1227 +----------------------+--------------------------------------------+ 1228 | version | This profile uses X.509 v3 certificates | 1229 | | [RFC5280]. | 1230 | | | 1231 | serialNumber | Positive integer unique per certificate. | 1232 | | | 1233 | signature | This field contains the signature | 1234 | | algorithm and this profile uses ecdsa- | 1235 | | with-SHA256 or stronger [RFC5758]. | 1236 | | | 1237 | issuer | Contains the DN of the issuing CA. | 1238 | | | 1239 | validity | Values expressed as UTC time in notBefore | 1240 | | and notAfter fields. No validity period | 1241 | | mandated. | 1242 | | | 1243 | subject | See rules outlined in this section. | 1244 | | | 1245 | subjectPublicKeyInfo | The SubjectPublicKeyInfo structure | 1246 | | indicates the algorithm and any associated | 1247 | | parameters for the ECC public key.This | 1248 | | profile uses the id-ecPublicKey algorithm | 1249 | | identifier for ECDSA signature keys, as | 1250 | | defined in specified in [RFC5480]. | 1251 | | | 1252 | signatureAlgorithm | The ECDSA signature algorithm with ecdsa- | 1253 | | with-SHA256 or stronger. | 1254 | | | 1255 | signatureValue | Bit string containing the digital | 1256 | | signature. | 1257 | | | 1258 | Extension: | See rules outlined in this section. | 1259 | subjectAltName | | 1260 | | | 1261 | Extension: | Indicates whether the subject of the | 1262 | BasicConstraints | certificate is a CA and the maximum depth | 1263 | | of valid certification paths that include | 1264 | | this certificate. This extension is used | 1265 | | for CA certs only and then the value of | 1266 | | the 'cA' field is set to TRUE. The default | 1267 | | is FALSE. | 1268 | | | 1269 | Extension: Key Usage | The KeyUsage field MAY have the following | 1270 | | values in the context of this profile: | 1271 | | digitalSignature or keyAgreement, | 1272 | | keyCertSign for verifying signatures on | 1273 | | public key certificates. | 1274 | | | 1275 | Extension: Extended | The ExtKeyUsageSyntax field MAY have the | 1276 | Key Usage | following values in context of this | 1277 | | profile: id-kp-serverAuth for server | 1278 | | authentication, id-kp-clientAuth for | 1279 | | client authentication, id-kp-codeSigning | 1280 | | for code signing (for software update | 1281 | | mechanism), id-kp-OCSPSigning for future | 1282 | | OCSP usage in TLS. | 1283 +----------------------+--------------------------------------------+ 1285 Table 1: Certificate Content. 1287 There are various cryptographic algorithms available to sign digital 1288 certificates; those algorithms include RSA, the Digital Signature 1289 Algorithm (DSA), and the Elliptic Curve Digital Signature Algorithm 1290 (ECDSA). As Table 1 shows, in this profile certificates are signed 1291 using ECDSA. This is not only true for the end-entity certificates 1292 but also for all other certificates in the chain, including CA 1293 certificates. This profiling reduces the amount of flash memory 1294 needed on IoT device to store the code of several algorithm 1295 implementations due to the smaller number of options. 1297 Further details about X.509 certificates can be found in 1298 Section 9.1.3.3 of [RFC7252]. 1300 4.4.5. Client Certificate URLs 1302 RFC 6066 [RFC6066] allows to avoid sending client-side certificates 1303 and uses URLs instead. This reduces the over-the-air transmission. 1304 Note that the TLS cached info extension does not provide any help 1305 with caching client certificates. 1307 TLS/DTLS clients MUST implement support for client certificate URLs 1308 for those environments where client-side certificates are used and 1309 the server-side is not constrained. For constrained servers this 1310 functionality is NOT RECOMMENDED since it forces the server to 1311 execute an additional protocol exchange, potentially using a protocol 1312 it does not even support. The use of this extension also increases 1313 the risk of a denial of service attack against the constrained server 1314 due to the additional workload. 1316 4.4.6. Trusted CA Indication 1318 RFC 6066 [RFC6066] allows clients to indicate what trust anchor they 1319 support. With certificate-based authentication, a DTLS server 1320 conveys its end entity certificate to the client during the DTLS 1321 handshake. Since the server does not necessarily know what trust 1322 anchors the client has stored, to facilitate certification path 1323 construction and validation, it includes intermediate CA certs in the 1324 certificate payload. 1326 Today, in most IoT deployments there is a fairly static relationship 1327 between the IoT device (and the software running on them) and the 1328 server-side infrastructure. For these deployments where IoT devices 1329 interact with a fixed, pre-configured set of servers this extension 1330 is NOT RECOMMENDED. 1332 In cases where client interact with dynamically discovered TLS/DTLS 1333 servers, for example in the use cases described in Section 3.2.2, the 1334 use of this extension is RECOMMENDED. 1336 5. Signature Algorithm Extension 1338 The "signature_algorithms" extension, defined in Section 7.4.1.4.1 of 1339 RFC 5246 [RFC5246], allows the client to indicate to the server which 1340 signature/hash algorithm pairs may be used in digital signatures. 1341 The client MUST send this extension to select the use of SHA-256 1342 since otherwise absent this extension RFC 5246 defaults to SHA-1 / 1343 ECDSA for the ECDH_ECDSA and the ECDHE_ECDSA key exchange algorithms. 1345 The "signature_algorithms" extension is not applicable to the PSK- 1346 based ciphersuite described in Section 4.2. 1348 6. Error Handling 1350 TLS/DTLS uses the Alert protocol to convey errors and specifies a 1351 long list of error types. However, not all error messages defined in 1352 the TLS/DTLS specification are applicable to this profile. In 1353 general, there are two categories of errors (as defined in 1354 Section 7.2 of RFC 5246), namely fatal errors and warnings. Alert 1355 messages with a level of fatal result in the immediate termination of 1356 the connection. If possible, developers should try to develop 1357 strategies to react to those fatal errors, such as re-starting the 1358 handshake or informing the user using the (often limited) user 1359 interface. Warnings may be ignored by the application since many IoT 1360 devices will either have limited ways to log errors or no ability at 1361 all. In any case, implementers have to carefully evaluate the impact 1362 of errors and ways to remedy the situation since a commonly used 1363 approach for delegating decision making to users is difficult (or 1364 impossible) to accomplish in a timely fashion. 1366 All error messages marked as RESERVED are only supported for 1367 backwards compatibility with SSL and MUST NOT be used with this 1368 profile. Those include decryption_failed_RESERVED, 1369 no_certificate_RESERVED, and export_restriction_RESERVED. 1371 A number of the error messages MUST only be used for certificate- 1372 based ciphersuites. Hence, the following error messages MUST NOT be 1373 used with with PSK and raw public key authentication: 1375 o bad_certificate, 1377 o unsupported_certificate, 1379 o certificate_revoked, 1381 o certificate_expired, 1383 o certificate_unknown, 1385 o unknown_ca, and 1387 o access_denied. 1389 Since this profile does not make use of compression at the TLS layer 1390 the decompression_failure error message MUST NOT be used either. 1392 RFC 4279 introduced a new alert message unknown_psk_identity for PSK 1393 ciphersuites. As stated in Section 2 of RFC 4279 the 1394 decryption_error error message may also be used instead. For this 1395 profile the TLS server MUST return the decryption_error error message 1396 instead of the unknown_psk_identity since the two mechanisms exist 1397 and provide the same functionality. 1399 Furthermore, the following errors should not occur with devices and 1400 servers supporting this specification but implementations MUST be 1401 prepared to process these errors to deal with servers that are not 1402 compliant to the profiles in this document: 1404 protocol_version: While this document focuses only on one version of 1405 the TLS/DTLS protocol, namely version 1.2, ongoing work on TLS/ 1406 DTLS 1.3 is in progress at the time of writing. 1408 insufficient_security: This error message indicates that the server 1409 requires ciphers to be more secure. This document specifies only 1410 one ciphersuite per profile but it is likely that additional 1411 ciphersuites get added over time. 1413 user_canceled: Many IoT devices are unattended and hence this error 1414 message is unlikely to occur. 1416 7. Session Resumption 1418 Session resumption is a feature of the core TLS/DTLS specifications 1419 that allows a client to continue with an earlier established session 1420 state. The resulting exchange is shown in Figure 11. In addition, 1421 the server may choose not to do a cookie exchange when a session is 1422 resumed. Still, clients have to be prepared to do a cookie exchange 1423 with every handshake. The cookie exchange is not shown in the 1424 figure. 1426 Client Server 1427 ------ ------ 1429 ClientHello --------> 1430 ServerHello 1431 [ChangeCipherSpec] 1432 <-------- Finished 1433 [ChangeCipherSpec] 1434 Finished --------> 1435 Application Data <-------> Application Data 1437 Figure 11: DTLS Session Resumption. 1439 Constrained clients MUST implement session resumption to improve the 1440 performance of the handshake. This will lead to a reduced number of 1441 message exchanges, lower computational overhead (since only symmetric 1442 cryptography is used during a session resumption exchange), and 1443 session resumption requires less bandwidth. 1445 For cases where the server is constrained (but not the client) the 1446 client MUST implement RFC 5077 [RFC5077]. Note that the constrained 1447 server refers to a device that has limitations in terms of RAM and 1448 flash memory, which place restrictions on the amount of TLS/DTLS 1449 security state information that can be stored on such a device. RFC 1450 5077 specifies a version of TLS/DTLS session resumption that does not 1451 require per-session state information to be maintained by the 1452 constrained server. This is accomplished by using a ticket-based 1453 approach. 1455 If both the client and the server are constrained devices both 1456 devices SHOULD implement RFC 5077 and MUST implement basic session 1457 resumption. Clients that do not want to use session resumption are 1458 always able to send a ClientHello message with an empty session_id to 1459 revert to a full handshake. 1461 8. Compression 1463 Section 3.3 of [RFC7525] recommends to disable TLS/DTLS-level 1464 compression due to attacks, such as CRIME [CRIME]. For IoT 1465 applications compression at the TLS/DTLS layer is not needed since 1466 application layer protocols are highly optimized and the compression 1467 algorithms at the DTLS layer increases code size and complexity. 1469 TLS/DTLS layer compression is NOT RECOMMENDED by this TLS/DTLS 1470 profile. 1472 9. Perfect Forward Secrecy 1474 Perfect forward secrecy (PFS) is a property that preserves the 1475 confidentiality of past protocol interactions even in situations 1476 where the long-term secret is compromised. 1478 The PSK ciphersuite recommended in Section 4.2 does not offer this 1479 property since it does not utilize a Diffie-Hellman (DH) exchange. 1480 New ciphersuites that support PFS for PSK-based authentication, such 1481 as proposed in [I-D.schmertmann-dice-ccm-psk-pfs], might become 1482 available as standardized ciphersuite in the (near) future. The 1483 recommended PSK-based ciphersuite offers excellent performance, a 1484 very small memory footprint, and has the lowest on the wire overhead 1485 at the expense of not using any public cryptography. For deployments 1486 where public key cryptography is acceptable, the use of raw public 1487 keys might offer a middle ground between the PSK ciphersuite in terms 1488 of out-of-band validation and the functionality offered by asymmetric 1489 cryptography. 1491 Physical attacks create additional opportunities to gain access to 1492 the crypto material stored on IoT devices. A PFS ciphersuite 1493 prevents an attacker from obtaining the communication content 1494 exchanged prior to a successful long-term key compromise; however, an 1495 implementation that (for performance or energy efficiency reasons) 1496 has been re-using the same ephemeral DH keys over multiple different 1497 sessions partially defeats PFS, thus increasing the damage extent. 1498 For this reason, implementations SHOULD NOT reuse ephemeral DH keys 1499 over multiple protocol exchanges. 1501 The impact of the disclosure of past communication interactions and 1502 the desire to increase the cost for pervasive monitoring (as demanded 1503 by [RFC7258]) has to be taken into account when selecting a 1504 ciphersuite that does not support the PFS property. 1506 Client implementations claiming support of this profile MUST 1507 implement the ciphersuites listed in Section 4 according to the 1508 selected credential type. 1510 10. Keep-Alive 1512 Application layer communication may create state at the endpoints and 1513 this state my expire at some time. For this reason, applications 1514 define ways to refresh state, if necessary. While the application 1515 layer exchanges are largely outside the scope of the underlying TLS/ 1516 DTLS exchange similar state considerations also play a role at the 1517 level of TLS/DTLS. While TLS/DTLS also creates state in form of a 1518 security context (see the security parameter described in Appendix A6 1519 in RFC 5246) at the client and the server this state information does 1520 not expire. However, network intermediaries may also allocate state 1521 and require this state to be kept alive. Failure to keep state alive 1522 at a stateful packet filtering firewall or at a NAT may result in the 1523 inability for one node to reach the other since packets will get 1524 blocked by these middleboxes. Periodic keep-alive messages exchanged 1525 between the TLS/DTLS client and server keep state at these 1526 middleboxes alive. According to measurements described in 1527 [HomeGateway] there is some variance in state management practices 1528 used in residential gateways but the timeouts are heavily impacted by 1529 the choice of the transport layer protocol: timeouts for UDP are 1530 typically much shorter than those for TCP. 1532 RFC 6520 [RFC6520] defines a heartbeat mechanism to test whether the 1533 other peer is still alive. As an additional feature, the same 1534 mechanism can also be used to perform Path Maximum Transmission Unit 1535 (MTU) Discovery. 1537 A recommendation about the use of RFC 6520 depends on the type of 1538 message exchange an IoT device performs and the number of messages 1539 the application needs to exchange as part of their application 1540 functionality. There are three types of exchanges that need to be 1541 analyzed: 1543 Client-Initiated, One-Shot Messages 1545 This is a common communication pattern where IoT devices upload 1546 data to a server on the Internet on an irregular basis. The 1547 communication may be triggered by specific events, such as opening 1548 a door. 1550 The DTLS handshake may need to be re-started (ideally using 1551 session resumption, if possible) in case of an IP address change. 1553 In this case there is no use for a keep-alive extension for this 1554 scenario. 1556 Client-Initiated, Regular Data Uploads 1558 This is a variation of the previous case whereby data gets 1559 uploaded on a regular basis, for example, based on frequent 1560 temperature readings. If neither NAT bindings nor IP address 1561 changes occurred then the record layer will not notice any 1562 changes. For the case where the IP address and port number 1563 changes, it is necessary to re-create the record layer using 1564 session resumption. 1566 In this scenario there is no use for a keep-alive extension. It 1567 is also very likely that the device will enter a sleep cycle in 1568 between data transmissions to keep power consumption low. 1570 Server-Initiated Messages 1572 In the two previous scenarios the client initiated the protocol 1573 interaction and maintains it. Since messages to the client may 1574 get blocked by middleboxes the initial connection setup is 1575 triggered by the client and then kept alive by the server. 1577 For this message exchange pattern the use of DTLS heartbeat 1578 messages is quite useful but may have to be coordinated with 1579 application exchanges (for example when the CoAP resource 1580 directory is used) to avoid redundant keep-alive message 1581 exchanges. The MTU discovery mechanism, which is also part of 1582 [RFC6520], is less likely to be relevant since for many IoT 1583 deployments the most constrained link is the wireless interface 1584 between the IoT device and the network itself (rather than some 1585 links along the end-to-end path). Only in more complex network 1586 topologies, such as multi-hop mesh networks, path MTU discovery 1587 might be appropriate. It also has to be noted that DTLS itself 1588 already provides a basic path discovery mechanism (see 1589 Section 4.1.1.1 of RFC 6347 by using the fragmentation capability 1590 of the handshake protocol). 1592 For server-initiated messages the heartbeat extension is RECOMMENDED. 1594 11. Timeouts 1596 A variety of wired and wireless technologies are available to connect 1597 devices to the Internet. Many of the low power radio technologies, 1598 such as IEEE 802.15.4 or Bluetooth Smart, only support small frame 1599 sizes (e.g., 127 bytes in case of IEEE 802.15.4 as explained in 1600 [RFC4919]). Other radio technologies, such as the Global System for 1601 Mobile Communications (GSM) using the short messaging service (SMS) 1602 have similar constraints in terms of payload sizes, such as 140 bytes 1603 without the optional segmentation and reassembly scheme known as 1604 Concatenated SMS, but show higher latency. 1606 The DTLS handshake protocol adds a fragmentation and reassembly 1607 mechanism to the TLS handshake protocol since each DTLS record must 1608 fit within a single transport layer datagram, as described in 1609 Section 4.2.3 of [RFC6347]. Since handshake messages are potentially 1610 bigger than the maximum record size, the mechanism fragments a 1611 handshake message over a number of DTLS records, each of which can be 1612 transmitted separately. 1614 To deal with the unreliable message delivery provided by UDP, DTLS 1615 adds timeouts and "per-flight" re-transmissions, as described in 1616 Section 4.2.4 of [RFC6347]. Although the timeout values are 1617 implementation specific, recommendations are provided in 1618 Section 4.2.4.1 of [RFC6347], with an initial timer value of 1 second 1619 and doubled with at each retransmission up to no less than 60 1620 seconds. 1622 TLS protocol steps can take longer due to higher processing time on 1623 the constrained side. On the other hand, the way DTLS handles 1624 retransmission, which is per-flight instead of per-segment, tends to 1625 interact poorly with low bandwidth networks. 1627 For these reasons, it's essential that the probability of a spurious 1628 retransmit is minimized and, on timeout, the sending endpoint does 1629 not react too aggressively. The latter is particularly relevant when 1630 the WSN is temporarily congested: if lost packets are re-injected too 1631 quickly, congestion worsens. 1633 An initial timer value of 9 seconds with exponential back off up to 1634 no less then 60 seconds is therefore RECOMMENDED. 1636 This value is chosen big enough to absorb large latency variance due 1637 to either slow computation on constrained endpoints or to intrinsic 1638 network characteristics (e.g., GSM-SMS), as well as to produce a low 1639 number of retransmission events and relax the pacing between them. 1640 Its worst case wait time is the same as using 1s timeout (i.e. 63s), 1641 while triggering less then half retransmissions (2 instead of 5). 1643 In order to minimise the wake time during DTLS handshake, sleepy 1644 nodes might decide to select a lower threshold, and consequently a 1645 smaller initial timeout value. If this is the case, the 1646 implementation MUST keep into account the considerations about 1647 network stability described in this section. 1649 12. Random Number Generation 1651 The TLS/DTLS protocol requires random numbers to be available during 1652 the protocol run. For example, during the ClientHello and the 1653 ServerHello exchange the client and the server exchange random 1654 numbers. Also, the use of the Diffie-Hellman exchange requires 1655 random numbers during the key pair generation. 1657 It is important to note that sources contributing to the randomness 1658 pool on laptops, or desktop PCs are not available on many IoT device, 1659 such as mouse movement, timing of keystrokes, air turbulence on the 1660 movement of hard drive heads, etc. Other sources have to be found or 1661 dedicated hardware has to be added. 1663 Lacking sources of randomness in an embedded system may lead to the 1664 same keys generated again and again. 1666 The ClientHello and the ServerHello messages contains the 'Random' 1667 structure, which has two components: gmt_unix_time and a sequence of 1668 28 random bytes. gmt_unix_time holds the current time and date in 1669 standard UNIX 32-bit format (seconds since the midnight starting Jan 1670 1, 1970, GMT). Since many IoT devices do not have access to an 1671 accurate clock, it is RECOMMENDED that the receiver of a ClientHello 1672 or ServerHello does not assume that the value in 1673 'Random.gmt_unix_time' is an accurate representation of the current 1674 time, and instead treats it as an opaque random string. 1676 When TLS is used with certificate-based authentication the 1677 availability of time information is needed to check the validity of a 1678 certificate. Higher-layer protocols may provide secure time 1679 information. The gmt_unix_time component of the ServerHello is not 1680 used for this purpose. 1682 IoT devices using TLS/DTLS must offer ways to generate quality random 1683 numbers. There are various implementation choices for integrating a 1684 hardware-based random number generator into a product: an 1685 implementation inside the microcontroller itself is one option but 1686 also dedicated crypto-chips are reasonable choices. The best choice 1687 will depend on various factors outside the scope of this document. 1688 Guidelines and requirements for random number generation can be found 1689 in RFC 4086 [RFC4086] and in the NIST Special Publication 800-90a 1690 [SP800-90A]. 1692 Chip manufacturers are highly encouraged to provide sufficient 1693 documentation of their design for random number generators so that 1694 customers can have confidence about the quality of the generated 1695 random numbers. The confidence can be increased by providing 1696 information about the procedures that have been used to verify the 1697 randomness of numbers generated by the hardware modules. For 1698 example, NIST Special Publication 800-22b [SP800-22b] describes 1699 statistical tests that can be used to verify random random number 1700 generators. 1702 13. Truncated MAC and Encrypt-then-MAC Extension 1704 The truncated MAC extension was introduced with RFC 6066 [RFC6066] 1705 with the goal to reduce the size of the MAC used at the Record Layer. 1706 This extension was developed for TLS ciphersuites that used older 1707 modes of operation where the MAC and the encryption operation was 1708 performed independently. 1710 The recommended ciphersuites in this document use the newer 1711 Authenticated Encryption with Associated Data (AEAD) construct, 1712 namely the CBC-MAC mode (CCM) with eight-octet authentication tags, 1713 and are therefore not applicable to the truncated MAC extension. 1715 RFC 7366 [RFC7366] introduced the encrypt-then-MAC extension (instead 1716 of the previously used MAC-then-encrypt) since the MAC-then-encrypt 1717 mechanism has been the subject of a number of security 1718 vulnerabilities. RFC 7366 is, however, also not applicable to the 1719 AEAD ciphers recommended in this document. 1721 Implementations conformant to this specification MUST use AEAD 1722 ciphers. RFC 7366 ("Encrypt-then-MAC") and RFC 6066 ("Truncated MAC 1723 extension") are not applicable to this specification and MUST NOT be 1724 used. 1726 14. Server Name Indication (SNI) 1728 The Server Name Indication extension defined in [RFC6066] defines a 1729 mechanism for a client to tell a TLS/DTLS server the name of the 1730 server it wants to contact. This is a useful extension for many 1731 hosting environments where multiple virtual servers are run on single 1732 IP address. 1734 Implementing the Server Name Indication extension is REQUIRED unless 1735 it is known that a TLS/DTLS client does not interact with a server in 1736 a hosting environment. 1738 15. Maximum Fragment Length Negotiation 1740 This RFC 6066 extension lowers the maximum fragment length support 1741 needed for the Record Layer from 2^14 bytes to 2^9 bytes. 1743 This is a very useful extension that allows the client to indicate to 1744 the server how much maximum memory buffers it uses for incoming 1745 messages. Ultimately, the main benefit of this extension is to allow 1746 client implementations to lower their RAM requirements since the 1747 client does not need to accept packets of large size (such as 16k 1748 packets as required by plain TLS/DTLS). 1750 Client implementations MUST support this extension. 1752 16. Session Hash 1754 In order to begin connection protection, the Record Protocol requires 1755 specification of a suite of algorithms, a master secret, and the 1756 client and server random values. The algorithm for computing the 1757 master secret is defined in Section 8.1 of RFC 5246 but only includes 1758 a small number of parameters exchanged during the handshake and does 1759 not include parameters like the client and server identities. This 1760 can be utilized by an attacker to mount a man-in-the-middle attack 1761 since the master secret is not guaranteed to be unique across 1762 sessions, as discovered in the 'Triple Handshake' attack [Triple-HS]. 1764 [I-D.ietf-tls-session-hash] defines a TLS extension that binds the 1765 master secret to a log of the full handshake that computes it, thus 1766 preventing such attacks. 1768 Client implementations SHOULD implement this extension even though 1769 the ciphersuites recommended by this profile are not vulnerable to 1770 this attack. For Diffie-Hellman-based ciphersuites the keying 1771 material is contributed by both parties and in case of the pre-shared 1772 secret key ciphersuite, both parties need to be in possession of the 1773 shared secret to ensure that the handshake completes successfully. 1774 It is, however, possible that some application layer protocols will 1775 tunnel other authentication protocols on top of DTLS making this 1776 attack relevant again. 1778 17. Re-Negotiation Attacks 1780 TLS/DTLS allows a client and a server who already have a TLS/DTLS 1781 connection to negotiate new parameters, generate new keys, etc by 1782 using the re-negotiation feature. Renegotiation happens in the 1783 existing connection, with the new handshake packets being encrypted 1784 along with application data. Upon completion of the re-negotiation 1785 procedure the new channel replaces the old channel. 1787 As described in RFC 5746 [RFC5746] there is no cryptographic binding 1788 between the two handshakes, although the new handshake is carried out 1789 using the cryptographic parameters established by the original 1790 handshake. 1792 To prevent the re-negotiation attack [RFC5746] this specification 1793 REQUIRES to disable the TLS renegotiation feature. Clients MUST 1794 respond to server-initiated re-negotiation attempts with an alert 1795 message (no_renegotiation) and clients MUST NOT initiate them. 1797 18. Downgrading Attacks 1799 When a client sends a ClientHello with a version higher than the 1800 highest version known to the server, the server is supposed to reply 1801 with ServerHello.version equal to the highest version known to the 1802 server and the handshake can proceed. This behavior is known as 1803 version tolerance. Version-intolerance is when the server (or a 1804 middlebox) breaks the handshake when it sees a ClientHello.version 1805 higher than what it knows about. This is the behavior that leads 1806 some clients to re-run the handshake with lower version. As a 1807 result, a potential security vulnerability is introduced when a 1808 system is running an old TLS/SSL version (e.g., because of the need 1809 to integrate with legacy systems). In the worst case, this allows an 1810 attacker to downgrade the protocol handshake to SSL 3.0. SSL 3.0 is 1811 so broken that there is no secure cipher available for it (see 1812 [RFC7568]). 1814 The above-described downgrade vulnerability is solved by the TLS 1815 Fallback Signaling Cipher Suite Value (SCSV) [RFC7507] extension. 1816 However, the solution is not applicable to implementations conforming 1817 to this profile since the version negotiation MUST use TLS/DTLS 1818 version 1.2 (or higher). More specifically, this implies: 1820 o Clients MUST NOT send a TLS/DTLS version lower than version 1.2 in 1821 the ClientHello. 1823 o Clients MUST NOT retry a failed negotiation offering a TLS/DTLS 1824 version lower than 1.2. 1826 o Servers MUST fail the handshake by sending a protocol_version 1827 fatal alert if a TLS/DTLS version >= 1.2 cannot be negotiated. 1828 Note that the aborted connection is non-resumable. 1830 19. Crypto Agility 1832 This document recommends software and chip manufacturers to implement 1833 AES and the CCM mode of operation. This document references the CoAP 1834 recommended ciphersuite choices, which have been selected based on 1835 implementation and deployment experience from the IoT community. 1836 Over time the preference for algorithms will, however, change. Not 1837 all components of a ciphersuite are likely to change at the same 1838 speed. Changes are more likely expected for ciphers, the mode of 1839 operation, and the hash algorithms. The recommended key lengths have 1840 to be adjusted over time as well. Some deployment environments will 1841 also be impacted by local regulation, which might dictate a certain 1842 algorithm and key size combination. Ongoing discussions regarding 1843 the choice of specific ECC curves will also likely impact 1844 implementations. Note that this document does not recommend or 1845 mandate a specific ECC curve. 1847 The following recommendations can be made to chip manufacturers: 1849 o Make any AES hardware-based crypto implementation accessible to 1850 developers working on security implementations at higher layers in 1851 the protocol stack. Sometimes hardware implementations are added 1852 to microcontrollers to offer support for functionality needed at 1853 the link layer and are only available to the on-chip link layer 1854 protocol implementation. Such a setup does not allow application 1855 developers to re-use the hardware-based AES implementation. 1857 o Provide flexibility for the use of the crypto function with future 1858 extensibility in mind. For example, making an AES-CCM 1859 implementation available to developers is a first step but such an 1860 implementation may not be usable due to parameter differences 1861 between an AES-CCM implementations. AES-CCM in IEEE 802.15.4 and 1862 Bluetooth Smart uses a nonce length of 13-octets while DTLS uses a 1863 nonce length of 12-octets. Hardware implementations of AES-CCM 1864 for IEEE 802.15.4 and Bluetooth Smart are therefore not re-usable 1865 by a DTLS stack. 1867 o Offer access to building blocks in addition (or as an alternative) 1868 to the complete functionality. For example, a chip manufacturer 1869 who gives developers access to the AES crypto function can use it 1870 to build an efficient AES-GCM implementations. Another example is 1871 to make a special instruction available that increases the speed 1872 of speed-up carryless multiplications. 1874 As a recommendation for developers and product architects we suggest 1875 that sufficient headroom is provided to allow an upgrade to a newer 1876 cryptographic algorithms over the lifetime of the product. As an 1877 example, while AES-CCM is recommended throughout this specification 1878 future products might use the ChaCha20 cipher in combination with the 1879 Poly1305 authenticator [RFC7539]. The assumption is made that a 1880 robust software update mechanism is offered. 1882 20. Key Length Recommendations 1884 RFC 4492 [RFC4492] gives approximate comparable key sizes for 1885 symmetric- and asymmetric-key cryptosystems based on the best-known 1886 algorithms for attacking them. While other publications suggest 1887 slightly different numbers, such as [Keylength], the approximate 1888 relationship still holds true. Figure 12 illustrates the comparable 1889 key sizes in bits. 1891 Symmetric | ECC | DH/DSA/RSA 1892 ------------+---------+------------- 1893 80 | 163 | 1024 1894 112 | 233 | 2048 1895 128 | 283 | 3072 1896 192 | 409 | 7680 1897 256 | 571 | 15360 1899 Figure 12: Comparable Key Sizes (in bits) based on RFC 4492. 1901 At the time of writing the key size recommendations for use with TLS- 1902 based ciphers found in [RFC7525] recommend DH key lengths of at least 1903 2048 bit, which corresponds to a 112-bit symmetric key and a 233 bit 1904 ECC key. These recommendations are roughly inline with those from 1905 other organizations, such as the National Institute of Standards and 1906 Technology (NIST) or the European Network and Information Security 1907 Agency (ENISA). The authors of [ENISA-Report2013] add that a 80-bit 1908 symmetric key is sufficient for legacy applications for the coming 1909 years, but a 128-bit symmetric key is the minimum requirement for new 1910 systems being deployed. The authors further note that one needs to 1911 also take into account the length of time data needs to be kept 1912 secure for. The use of 80-bit symmetric keys for transactional data 1913 may be acceptable for the near future while one has to insist on 1914 128-bit symmetric keys for long lived data. 1916 Note that the recommendations for 112-bit symmetric keys are chosen 1917 conservatively under the assumption that IoT devices have a long 1918 expected lifetime (such as 10+ years) and that this key length 1919 recommendation refers to the long-term keys used for device 1920 authentication. Keys, which are provisioned dynamically, for the 1921 protection of transactional data (such as ephemeral Diffie-Hellman 1922 keys used in various TLS/DTLS ciphersuites) may be shorter 1923 considering the sensitivity of the exchanged data. 1925 21. False Start 1927 A full TLS handshake as specified in [RFC5246] requires two full 1928 protocol rounds (four flights) before the handshake is complete and 1929 the protocol parties may begin to send application data. 1931 An abbreviated handshake (resuming an earlier TLS session) is 1932 complete after three flights, thus adding just one round-trip time if 1933 the client sends application data first. 1935 If the conditions outlined in [I-D.ietf-tls-falsestart] are met, 1936 application data can be transmitted when the sender has sent its own 1937 "ChangeCipherSpec" and "Finished" messages. This achieves an 1938 improvement of one round-trip time for full handshakes if the client 1939 sends application data first, and for abbreviated handshakes if the 1940 server sends application data first. 1942 The conditions for using the TLS False Start mechanism are met by the 1943 public-key-based ciphersuites in this document. In summary, the 1944 conditions are 1946 o Modern symmetric ciphers with an effective key length of 128 bits, 1947 such as AES-128-CCM 1949 o Client certificate types, such as ecdsa_sign 1951 o Key exchange methods, such as ECDHE_ECDSA 1953 Based on the improvement over a full round-trip for the full TLS/DTLS 1954 exchange this specification RECOMMENDS the use of the False Start 1955 mechanism when clients send application data first. 1957 22. Privacy Considerations 1959 The DTLS handshake exchange conveys various identifiers, which can be 1960 observed by an on-path eavesdropper. For example, the DTLS PSK 1961 exchange reveals the PSK identity, the supported extensions, the 1962 session id, algorithm parameters, etc. When session resumption is 1963 used then individual TLS sessions can be correlated by an on-path 1964 adversary. With many IoT deployments it is likely that keying 1965 material and their identifiers are persistent over a longer period of 1966 time due to the cost of updating software on these devices. 1968 User participation poses a challenge in many IoT deployments since 1969 many of the IoT devices operate unattended, even though they are 1970 initially provisioned by a human. The ability to control data 1971 sharing and to configure preferences will have to be provided at a 1972 system level rather than at the level of the DTLS exchange itself, 1973 which is the scope of this document. Quite naturally, the use of 1974 DTLS with mutual authentication will allow a TLS server to collect 1975 authentication information about the IoT device (likely over a long 1976 period of time). While this strong form of authentication will 1977 prevent mis-attribution, it also allows strong identification. 1978 Device-related data collection (e.g., sensor recordings) associated 1979 with other data type will prove to be truly useful but this extra 1980 data might include personal information about the owner of the device 1981 or data about the environment it senses. Consequently, the data 1982 stored on the server-side will be vulnerable to stored data 1983 compromise. For the communication between the client and the server 1984 this specification prevents eavesdroppers to gain access to the 1985 communication content. While the PSK-based ciphersuite does not 1986 provide PFS the asymmetric versions do. This prevents an adversary 1987 from obtaining past communication content when access to a long-term 1988 secret has been gained. Note that no extra effort to make traffic 1989 analysis more difficult is provided by the recommendations made in 1990 this document. 1992 Note that the absence or presence of communication itself might 1993 reveal information to an adversary. For example, a presence sensor 1994 may initiate messaging when a person enters a building. While TLS/ 1995 DTLS would offer confidentiality protection of the transmitted 1996 information it does not help to conceal all communication patterns. 1997 Furthermore, the IP header, which is not protected by TLS/DTLS, 1998 additionally reveals information about the other communication 1999 endpoint. For applications where such privacy concerns exist 2000 additional safeguards are required, such as injecting dummy traffic 2001 and onion routing. A detailed treatment of such solutions is outside 2002 the scope of this document and requires a system-level view. 2004 23. Security Considerations 2006 This entire document is about security. 2008 We would also like to point out that designing a software update 2009 mechanism into an IoT system is crucial to ensure that both 2010 functionality can be enhanced and that potential vulnerabilities can 2011 be fixed. This software update mechanism is important for changing 2012 configuration information, for example, trust anchors and other 2013 keying related information. Such a suitable software update 2014 mechanism is available with the Lightweight Machine-to-Machine 2015 (LWM2M) protocol published by the Open Mobile Alliance (OMA) [LWM2M]. 2017 24. IANA Considerations 2019 This document includes no request to IANA. 2021 25. Acknowledgments 2023 Thanks to Derek Atkins, Olaf Bergmann, Paul Bakker, Carsten Bormann, 2024 Ben Campbell, Brian Carpenter, Robert Cragie, Spencer Dawkins, Russ 2025 Housley, Rene Hummen, Jayaraghavendran K, Matthias Kovatsch, Sandeep 2026 Kumar, Barry Leiba, Sye Loong Keoh, Simon Lemay, Alexey Melnikov, 2027 Gabriel Montenegro, Manuel Pegourie-Gonnard, Akbar Rahman, Eric 2028 Rescorla, Michael Richardson, Ludwig Seitz, Zach Shelby, Michael 2029 StJohns, Rene Struik, Sean Turner, and Tina Tsou for their helpful 2030 comments and discussions that have shaped the document. 2032 Big thanks also to Klaus Hartke, who wrote the initial version of 2033 this document. 2035 Finally, we would like to thank our area director (Stephen Farrell) 2036 and our working group chairs (Zach Shelby and Dorothy Gellert) for 2037 their support. 2039 26. References 2041 26.1. Normative References 2043 [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 2044 REGISTRATION AUTHORITY", URL: 2045 https://standards.ieee.org/regauth/oui/tutorials/ 2046 EUI64.html, April 2010. 2048 [GSM-SMS] ETSI, "3GPP TS 23.040 V7.0.1 (2007-03): 3rd Generation 2049 Partnership Project; Technical Specification Group Core 2050 Network and Terminals; Technical realization of the Short 2051 Message Service (SMS) (Release 7)", March 2007. 2053 [I-D.ietf-tls-cached-info] 2054 Santesson, S. and H. Tschofenig, "Transport Layer Security 2055 (TLS) Cached Information Extension", draft-ietf-tls- 2056 cached-info-19 (work in progress), March 2015. 2058 [I-D.ietf-tls-session-hash] 2059 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 2060 A., and M. Ray, "Transport Layer Security (TLS) Session 2061 Hash and Extended Master Secret Extension", draft-ietf- 2062 tls-session-hash-06 (work in progress), July 2015. 2064 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2065 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 2066 RFC2119, March 1997, 2067 . 2069 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 2070 Ciphersuites for Transport Layer Security (TLS)", RFC 2071 4279, DOI 10.17487/RFC4279, December 2005, 2072 . 2074 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2075 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 2076 RFC5246, August 2008, 2077 . 2079 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 2080 "Transport Layer Security (TLS) Renegotiation Indication 2081 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 2082 . 2084 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 2085 Extensions: Extension Definitions", RFC 6066, DOI 2086 10.17487/RFC6066, January 2011, 2087 . 2089 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2090 Verification of Domain-Based Application Service Identity 2091 within Internet Public Key Infrastructure Using X.509 2092 (PKIX) Certificates in the Context of Transport Layer 2093 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2094 2011, . 2096 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2097 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2098 January 2012, . 2100 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 2101 Layer Security (TLS) and Datagram Transport Layer Security 2102 (DTLS) Heartbeat Extension", RFC 6520, DOI 10.17487/ 2103 RFC6520, February 2012, 2104 . 2106 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 2107 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 2108 Transport Layer Security (TLS) and Datagram Transport 2109 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 2110 June 2014, . 2112 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 2113 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 2114 TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, 2115 . 2117 [WAP-WDP] Wireless Application Protocol Forum, "Wireless Datagram 2118 Protocol", June 2001. 2120 26.2. Informative References 2122 [ACE-WG] IETF, "Authentication and Authorization for Constrained 2123 Environments (ace) Working Group", URL: 2124 https://datatracker.ietf.org/wg/ace/charter/, Jan 2015. 2126 [AES] National Institute of Standards and Technology, "FIPS PUB 2127 197, Advanced Encryption Standard (AES)", URL: 2128 http://csrc.nist.gov/publications/fips/fips197/ 2129 fips-197.pdf, November 2001. 2131 [CCM] National Institute of Standards and Technology, "Special 2132 Publication 800-38C, Recommendation for Block Cipher Modes 2133 of Operation: The CCM Mode for Authentication and 2134 Confidentiality", http://csrc.nist.gov/publications/ 2135 nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf, May 2136 2004. 2138 [CRIME] Wikipedia, "CRIME Security Exploit", HTML 2139 https://en.wikipedia.org/wiki/CRIME, June 2001. 2141 [ENISA-Report2013] 2142 ENISA, "Algorithms, Key Sizes and Parameters Report - 2143 2013", URL: https://www.enisa.europa.eu/activities/ 2144 identity-and-trust/library/deliverables/algorithms-key- 2145 sizes-and-parameters-report, October 2013. 2147 [HomeGateway] 2148 Eggert, L., "An experimental study of home gateway 2149 characteristics, In Proceedings of the '10th annual 2150 conference on Internet measurement'", PDF 2151 https://eggert.org/papers/2010-imc-hgw-study.pdf, 2010. 2153 [I-D.ietf-core-resource-directory] 2154 Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE 2155 Resource Directory", draft-ietf-core-resource-directory-04 2156 (work in progress), July 2015. 2158 [I-D.ietf-tls-falsestart] 2159 Langley, A., Modadugu, N., and B. Moeller, "Transport 2160 Layer Security (TLS) False Start", draft-ietf-tls- 2161 falsestart-00 (work in progress), May 2015. 2163 [I-D.ietf-tls-negotiated-dl-dhe] 2164 Gillmor, D., "Negotiated Discrete Log Diffie-Hellman 2165 Ephemeral Parameters for TLS", draft-ietf-tls-negotiated- 2166 dl-dhe-00 (work in progress), July 2014. 2168 [I-D.irtf-cfrg-curves] 2169 Langley, A. and M. Hamburg, "Elliptic Curves for 2170 Security", draft-irtf-cfrg-curves-11 (work in progress), 2171 October 2015. 2173 [I-D.schmertmann-dice-ccm-psk-pfs] 2174 Schmertmann, L. and C. Bormann, "ECDHE-PSK AES-CCM Cipher 2175 Suites with Forward Secrecy for Transport Layer Security 2176 (TLS)", draft-schmertmann-dice-ccm-psk-pfs-01 (work in 2177 progress), August 2014. 2179 [I-D.tschofenig-core-coap-tcp-tls] 2180 Bormann, C., Lemay, S., Technologies, Z., and H. 2181 Tschofenig, "A TCP and TLS Transport for the Constrained 2182 Application Protocol (CoAP)", draft-tschofenig-core-coap- 2183 tcp-tls-04 (work in progress), June 2015. 2185 [IANA-TLS] 2186 IANA, "TLS Cipher Suite Registry", URL: 2187 https://www.iana.org/assignments/tls-parameters/tls- 2188 parameters.xhtml#tls-parameters-4, 2014. 2190 [ImprintingSurvey] 2191 Chilton, E., "A Brief Survey of Imprinting Options for 2192 Constrained Devices", URL: http://www.lix.polytechnique.fr 2193 /hipercom/SmartObjectSecurity/papers/EricRescorla.pdf, 2194 March 2012. 2196 [Keylength] 2197 Giry, D., "Cryptographic Key Length Recommendations", URL: 2198 http://www.keylength.com, November 2014. 2200 [LWM2M] Open Mobile Alliance, "Lightweight Machine-to-Machine, 2201 Technical Specification, Candidate Version 1.0", HTML 2202 http://openmobilealliance.org/about-oma/work-program/ 2203 m2m-enablers/, December 2013. 2205 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 2206 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 2207 1996, . 2209 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2210 Hashing for Message Authentication", RFC 2104, DOI 2211 10.17487/RFC2104, February 1997, 2212 . 2214 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2215 "Remote Authentication Dial In User Service (RADIUS)", RFC 2216 2865, DOI 10.17487/RFC2865, June 2000, 2217 . 2219 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 2220 CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 2221 2003, . 2223 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2224 Levkowetz, Ed., "Extensible Authentication Protocol 2225 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 2226 . 2228 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2229 "Randomness Requirements for Security", BCP 106, RFC 4086, 2230 DOI 10.17487/RFC4086, June 2005, 2231 . 2233 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 2234 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 2235 for Transport Layer Security (TLS)", RFC 4492, DOI 2236 10.17487/RFC4492, May 2006, 2237 . 2239 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2240 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 2241 . 2243 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 2244 over Low-Power Wireless Personal Area Networks (6LoWPANs): 2245 Overview, Assumptions, Problem Statement, and Goals", RFC 2246 4919, DOI 10.17487/RFC4919, August 2007, 2247 . 2249 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 2250 "Transport Layer Security (TLS) Session Resumption without 2251 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 2252 January 2008, . 2254 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 2255 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 2256 . 2258 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 2259 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 2260 March 2008, . 2262 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 2263 Authentication Protocol (EAP) Key Management Framework", 2264 RFC 5247, DOI 10.17487/RFC5247, August 2008, 2265 . 2267 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2268 Housley, R., and W. Polk, "Internet X.509 Public Key 2269 Infrastructure Certificate and Certificate Revocation List 2270 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2271 . 2273 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 2274 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, DOI 2275 10.17487/RFC5288, August 2008, 2276 . 2278 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 2279 "Elliptic Curve Cryptography Subject Public Key 2280 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 2281 . 2283 [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. 2284 Polk, "Internet X.509 Public Key Infrastructure: 2285 Additional Algorithms and Identifiers for DSA and ECDSA", 2286 RFC 5758, DOI 10.17487/RFC5758, January 2010, 2287 . 2289 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 2290 Management Protocol (TAMP)", RFC 5934, DOI 10.17487/ 2291 RFC5934, August 2010, 2292 . 2294 [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management 2295 Requirements", RFC 6024, DOI 10.17487/RFC6024, October 2296 2010, . 2298 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 2299 Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/ 2300 RFC6090, February 2011, 2301 . 2303 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 2304 (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 2305 10.17487/RFC6234, May 2011, 2306 . 2308 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 2309 Transport Layer Security (TLS)", RFC 6655, DOI 10.17487/ 2310 RFC6655, July 2012, 2311 . 2313 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 2314 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 2315 . 2317 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 2318 Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/ 2319 RFC6733, October 2012, 2320 . 2322 [RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for 2323 Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 2324 2013, . 2326 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 2327 Multiple Certificate Status Request Extension", RFC 6961, 2328 DOI 10.17487/RFC6961, June 2013, 2329 . 2331 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2332 Constrained-Node Networks", RFC 7228, DOI 10.17487/ 2333 RFC7228, May 2014, 2334 . 2336 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2337 Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ 2338 RFC7252, June 2014, 2339 . 2341 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2342 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2343 2014, . 2345 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer 2346 Security (TLS) and Datagram Transport Layer Security 2347 (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, 2348 . 2350 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 2351 the Constrained Application Protocol (CoAP)", RFC 7390, 2352 DOI 10.17487/RFC7390, October 2014, 2353 . 2355 [RFC7397] Gilger, J. and H. Tschofenig, "Report from the Smart 2356 Object Security Workshop", RFC 7397, DOI 10.17487/RFC7397, 2357 December 2014, . 2359 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 2360 IPv6 over Low-Power Wireless Personal Area Networks 2361 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 2362 2014, . 2364 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 2365 "Architectural Considerations in Smart Object Networking", 2366 RFC 7452, DOI 10.17487/RFC7452, March 2015, 2367 . 2369 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, DOI 2370 10.17487/RFC7465, February 2015, 2371 . 2373 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 2374 Suite Value (SCSV) for Preventing Protocol Downgrade 2375 Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, 2376 . 2378 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2379 "Recommendations for Secure Use of Transport Layer 2380 Security (TLS) and Datagram Transport Layer Security 2381 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2382 2015, . 2384 [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 2385 Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, 2386 . 2388 [RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, 2389 "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, 2390 DOI 10.17487/RFC7568, June 2015, 2391 . 2393 [SP800-107-rev1] 2394 NIST, "NIST Special Publication 800-107, Revision 1, 2395 Recommendation for Applications Using Approved Hash 2396 Algorithms", URL: http://csrc.nist.gov/publications/ 2397 nistpubs/800-107-rev1/sp800-107-rev1.pdf, August 2012. 2399 [SP800-22b] 2400 National Institute of Standards and Technology, "Special 2401 Publication 800-22, Revision 1a, A Statistical Test Suite 2402 for Random and Pseudorandom Number Generators for 2403 Cryptographic Applications", URL: 2404 http://csrc.nist.gov/publications/nistpubs/800-22-rev1a/ 2405 SP800-22rev1a.pdf, April 2010. 2407 [SP800-90A] 2408 NIST, "DRAFT Special Publication 800-90a, Revision 1, 2409 Recommendation for Random Number Generation Using 2410 Deterministic Random Bit Generators", URL: 2411 http://csrc.nist.gov/publications/drafts/800-90/ 2412 sp800-90a_r1_draft_november2014_ver.pdf, November 2014. 2414 [Triple-HS] 2415 Bhargavan, K., Delignat-Lavaud, C., Pironti, A., and P. 2416 Strub, "Triple Handshakes and Cookie Cutters: Breaking and 2417 Fixing Authentication over TLS", IEEE Symposium on 2418 Security and Privacy, pages 98-113, 2014. 2420 Appendix A. Conveying DTLS over SMS 2422 This section is normative for the use of DTLS over SMS. Timer 2423 recommendations are already outlined in Section 11 and also 2424 applicable to the transport of DTLS over SMS. 2426 This section requires readers to be familiar with the terminology and 2427 concepts described in [GSM-SMS], and [WAP-WDP]. 2429 The remainder of this section assumes Mobile Stations are capable of 2430 producing and consuming 8-bit binary data encoded Transport Protocol 2431 Data Units (TPDU). 2433 A.1. Overview 2435 DTLS adds an additional round-trip to the TLS [RFC5246] handshake to 2436 serve as a return-routability test for protection against certain 2437 types of DoS attacks. Thus a full blown DTLS handshake comprises up 2438 to 6 "flights" (i.e., logical message exchanges), each of which is 2439 then mapped on to one or more DTLS records using the segmentation and 2440 reassembly (SaR) scheme described in Section 4.2.3 of [RFC6347]. The 2441 overhead for said scheme is 6 bytes per Handshake message which, 2442 given a realistic 10+ messages handshake, would amount around 60 2443 bytes across the whole handshake sequence. 2445 Note that the DTLS SaR scheme is defined for handshake messages only. 2446 In fact, DTLS records are never fragmented and MUST fit within a 2447 single transport layer datagram. 2449 SMS provides an optional segmentation and reassembly scheme as well, 2450 known as Concatenated short messages (see Section 9.2.3.24.1 of 2451 [GSM-SMS]). However, since the SaR scheme in DTLS cannot be 2452 circumvented, the Concatenated short messages mechanism SHOULD NOT be 2453 used during handshake to avoid redundant overhead. Before starting 2454 the handshake phase (either actively or passively), the DTLS 2455 implementation MUST be explicitly configured with the PMTU of the SMS 2456 transport in order to correctly instrument its SaR function. The 2457 PMTU SHALL be 133 bytes if WDP-based multiplexing is used (see 2458 Appendix A.3), 140 bytes otherwise. 2460 It is RECOMMENDED to use the established security context over the 2461 longest possible period (possibly until a Closure Alert message is 2462 received, or after a very long inactivity timeout) to avoid the 2463 expensive re-establishment of the security association. 2465 A.2. Message Segmentation and Re-Assembly 2467 The content of an SMS message is carried in the TP-UserData field, 2468 and its size may be up to 140 bytes. As already mentioned in 2469 Appendix A.1, longer (i.e., up to 34170 bytes) messages can be sent 2470 using Concatenated SMS. 2472 This scheme consumes 6-7 bytes (depending on whether the short or 2473 long segmentation format is used) of the TP-UserData field, thus 2474 reducing the space available for the actual content of the SMS 2475 message to 133-134 bytes per TPDU. 2477 Though in principle a PMTU value higher than 140 bytes could be used, 2478 which may look like an appealing option given its more efficient use 2479 of the transport, there are disadvantages to consider. First, there 2480 is an additional overhead of 7 bytes per TPDU to be paid to the SaR 2481 function (which is in addition to the overhead introduced by the DTLS 2482 SaR mechanism. Second, some networks only partially support the 2483 Concatenated SMS function and others do not support it at all. 2485 For these reasons, the Concatenated short messages mechanism SHOULD 2486 NOT be used, and it is RECOMMENDED to leave the same PMTU settings 2487 used during the handshake phase, i.e., 133 bytes if WDP- based 2488 multiplexing is enabled, 140 bytes otherwise. 2490 Note that, after DTLS handshake has completed, any fragmentation and 2491 reassembly logic that pertains the application layer (e.g., 2492 segmenting CoAP messages into DTLS records and reassembling them 2493 after the crypto operations have been successfully performed) needs 2494 to be handled by the application that uses the established DTLS 2495 tunnel. 2497 A.3. Multiplexing Security Associations 2499 Unlike IPsec ESP/AH, DTLS records do not contain any association 2500 identifiers. Applications must arrange to multiplex between 2501 associations on the same endpoint which, when using UDP/IP, is 2502 usually done with the host/port number. 2504 If the DTLS server allows more than one client to be active at any 2505 given time, then the WAP User Datagram Protocol [WAP-WDP] can be used 2506 to achieve multiplexing of the different security associations. (The 2507 use of WDP provides the additional benefit that upper layer protocols 2508 can operate independently of the underlying wireless network, hence 2509 achieving application-agnostic transport handover.) 2511 The total overhead cost for encoding the WDP source and destination 2512 ports is either 5 or 7 bytes out of the total available for the SMS 2513 content depending on if 1-byte or 2-byte port identifiers are used, 2514 as shown in Figure 13 and Figure 14. 2516 0 1 2 3 4 2517 +--------+--------+--------+--------+--------+ 2518 | ... | 0x04 | 2 | ... | ... | 2519 +--------+--------+--------+--------+--------+ 2520 UDH IEI IE Dest Source 2521 Length Length Port Port 2523 Figure 13: Application Port Addressing Scheme (8 bit address). 2525 0 1 2 3 4 5 6 2526 +--------+--------+--------+--------+--------+--------+--------+ 2527 | ... | 0x05 | 4 | ... | ... | 2528 +--------+--------+--------+--------+--------+--------+--------+ 2529 UDH IEI IE Dest Source 2530 Length Length Port Port 2532 Figure 14: Application Port Addressing Scheme (16 bit address). 2534 The receiving side of the communication gets the source address from 2535 the originator address (TP-OA) field of the SMS-DELIVER TPDU. This 2536 way an unique 4-tuple identifying the security association can be 2537 reconstructed at both ends. (When replying to its DTLS peer, the 2538 sender will swaps the TP-OA and TP-DA parameters and the source and 2539 destination ports in the WDP.) 2541 A.4. Timeout 2543 If SMS-STATUS-REPORT messages are enabled, their receipt is not to be 2544 interpreted as the signal that the specific handshake message has 2545 been acted upon by the receiving party. Therefore, it MUST NOT be 2546 taken into account by the DTLS timeout and retransmission function. 2548 Handshake messages MUST carry a validity period (TP-VP parameter in a 2549 SMS-SUBMIT TPDU) that is not less than the current value of the 2550 retransmission timeout. In order to avoid persisting messages in the 2551 network that will be discarded by the receiving party, handshake 2552 messages SHOULD carry a validity period that is the same as, or just 2553 slightly higher than, the current value of the retransmission 2554 timeout. 2556 Appendix B. DTLS Record Layer Per-Packet Overhead 2558 Figure 15 shows the overhead for the DTLS record layer for protecting 2559 data traffic when AES-128-CCM with an 8-octet Integrity Check Value 2560 (ICV) is used. 2562 DTLS Record Layer Header................13 bytes 2563 Nonce (Explicit).........................8 bytes 2564 ICV..................................... 8 bytes 2565 ------------------------------------------------ 2566 Overhead................................29 bytes 2567 ------------------------------------------------ 2569 Figure 15: AES-128-CCM-8 DTLS Record Layer Per-Packet Overhead. 2571 The DTLS record layer header has 13 octets and consists of 2573 o 1 octet content type field, 2575 o 2 octet version field, 2577 o 2 octet epoch field, 2579 o 6 octet sequence number, 2581 o 2 octet length field. 2583 The "nonce" input to the AEAD algorithm is exactly that of [RFC5288], 2584 i.e., 12 bytes long. It consists of two values, namely a 4 octet 2585 salt and an 8 octet nonce_explicit: 2587 The salt is the "implicit" part and is not sent in the packet. 2588 Instead, the salt is generated as part of the handshake process. 2590 The nonce_explicit value is 8 octet long and it is chosen by the 2591 sender and carried in each TLS record. RFC 6655 [RFC6655] allows 2592 the nonce_explicit to be a sequence number or something else. 2593 This document makes this use more restrictive for use with DTLS: 2594 the 64-bit none_explicit value MUST be the 16-bit epoch 2595 concatenated with the 48-bit seq_num. The sequence number 2596 component of the nonce_explicit field at the AES-CCM layer is an 2597 exact copy of the sequence number in the record layer header 2598 field. This leads to a duplication of 8-bytes per record. 2600 To avoid this 8-byte duplication RFC 7400 [RFC7400] provides help 2601 with the use of the generic header compression technique for IPv6 2602 over Low-Power Wireless Personal Area Networks (6LoWPANs). Note 2603 that this header compression technique is not available when DTLS 2604 is exchanged over transports that do not use IPv6 or 6LoWPAN, such 2605 as the SMS transport described in Appendix A. 2607 Appendix C. DTLS Fragmentation 2609 Section 4.2.3 of [RFC6347] advises DTLS implementations to not 2610 produce overlapping fragments. However, it requires receivers to be 2611 able to cope with them. The need for the latter requisite is 2612 explained in Section 4.1.1.1 of [RFC6347]: accurate path MTU (PMTU) 2613 estimation may be traded for shorter handshake completion time. 2615 In many cases, the cost of handling fragment overlaps has proved to 2616 be unaffordable for constrained implementations, particularly because 2617 of the increased complexity in buffer management. 2619 In order to reduce the likelihood of producing different fragment 2620 sizes and consequent overlaps within the same handshake, this 2621 document RECOMMENDs: 2623 o clients (handshake initiators) to use reliable PMTU information 2624 for the intended destination; 2626 o servers to mirror the fragment size selected by their clients. 2628 The PMTU information comes either from a "fresh enough" discovery 2629 performed by the client ([RFC1981], [RFC4821]), or from some other 2630 reliable out-of-band channel. 2632 Authors' Addresses 2634 Hannes Tschofenig (editor) 2635 ARM Ltd. 2636 110 Fulbourn Rd 2637 Cambridge CB1 9NJ 2638 Great Britain 2640 Email: Hannes.tschofenig@gmx.net 2641 URI: http://www.tschofenig.priv.at 2643 Thomas Fossati 2644 Alcatel-Lucent 2645 3 Ely Road 2646 Milton, Cambridge CB24 6DD 2647 UK 2649 Email: thomas.fossati@alcatel-lucent.com