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