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