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