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