idnits 2.17.1 draft-tiloca-tls-dos-handshake-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 28, 2017) is 2487 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-00 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-20 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-10 -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group M. Tiloca 3 Internet-Draft L. Seitz 4 Intended status: Standards Track RISE SICS AB 5 Expires: December 30, 2017 M. Hoeve 6 ENCS 7 June 28, 2017 9 Extension for protecting (D)TLS handshakes against Denial of Service 10 draft-tiloca-tls-dos-handshake-00 12 Abstract 14 This document describes an extension for TLS and DTLS to protect the 15 server from Denial of Service attacks against the handshake protocol. 16 The extension includes a Message Authentication Code (MAC) over the 17 ClientHello message, computed by the Client through key material 18 obtained from a Trust Anchor entity. The server registered at the 19 Trust Anchor derives the same key material and checks the MAC to 20 determine whether continuing or aborting the handshake. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 30, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. DoS Protection Extension . . . . . . . . . . . . . . . . . . 4 59 2.1. Extension Type . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Extension Data . . . . . . . . . . . . . . . . . . . . . 4 61 3. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Client to Trust Anchor . . . . . . . . . . . . . . . . . . . 6 63 5. Client to Server . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Server Processing . . . . . . . . . . . . . . . . . . . . . . 7 65 7. Replay Protection . . . . . . . . . . . . . . . . . . . . . . 8 66 8. Session Resumption . . . . . . . . . . . . . . . . . . . . . 9 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 9.1. Renewal of Long-Term Key K_M . . . . . . . . . . . . . . 10 69 9.2. Rate Limit to Nonce Release . . . . . . . . . . . . . . . 10 70 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 74 12.2. Informative References . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 Servers running TLS [RFC5246][I-D.ietf-tls-tls13] and DTLS 80 [RFC6347][I-D.ietf-tls-dtls13] are vulnerable to Denial of Service 81 (DoS) attacks during the very first step of the handshake protocol. 82 That is, an adversary can repeatedly send ClientHello messages to the 83 server and induce it to start performing invalid handshakes. 85 DTLS 1.2 as well as both TLS 1.3 and DTLS 1.3 provide the optional 86 Cookie exchange as possible solution to mitigate this Denial of 87 Service attack. While this makes the attack more complicated to 88 mount, a well determined and resourceful adversary able to spoof 89 valid IP addresses can still successfully perform it, by intercepting 90 the possible server response including the Cookie and then echoing it 91 in the second ClientHello. This is particularly doable in case the 92 handshake is not based on Pre-Shared Key exchange modes. 94 Depending on the specific protocol version and the key establishment 95 mode used in the handshake, the attack impact can range from single 96 replies triggered by invalid ClientHello messages, to the server 97 performing advanced handshake steps with consequent setup of invalid 98 half-open sessions. Especially if performed in a large-scale and 99 distributed manner, this attack can thwart performance and service 100 availability of (D)TLS servers. Moreover, it can be particularly 101 effective in application scenarios where servers are resource- 102 constrained devices running DTLS over low-power, low bandwidth and 103 lossy networks. 105 This specification proposes a "dos_protection" extension for TLS and 106 DTLS, which is used to mark valid ClientHello messages and neutralize 107 the Denial of Service attack mentioned above. In essence, the client 108 computes a Message Authentication Code (MAC) of the first ClientHello 109 message addressed to the server. Then, the MAC is included in the 110 "dos_protection" extension, together with information used for its 111 validation on the server side. Upon receiving the ClientHello 112 message, the server checks the MAC carried in the "dos_protection" 113 extension, and determines whether to continue the handshake or to 114 immediately abort it. 116 The proposed method relies on a Trust Anchor (TA) entity, which is in 117 a trust relation with the server and authorizes the client to 118 establish a secure session with the server. In particular, the Trust 119 Anchor provides the client with the key material to compute the MAC 120 included in the "dos_protection" extension. 122 1.1. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. These 127 words may also appear in this document in lowercase, absent their 128 normative meanings. 130 Readers are expected to be familiar with terms and concepts related 131 to TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347], as well as to TLS 1.3 132 [I-D.ietf-tls-tls13] and DTLS 1.3 [I-D.ietf-tls-dtls13], with 133 particular reference to their respective handshake protocol. 135 This document refers also to the following terminology. 137 o Trust Anchor (TA): a trusted third party in a trust relation with 138 the (D)TLS server. 140 o Master Key (K_M): a long-term symmetric key shared between the 141 Trust Anchor and the server. 143 o Session Key (K_S): a symmetric key provided by the Trust Anchor to 144 a client intending to start a handshake with the server. 146 o Nonce (N): a 32 bit unsigned integer provided by the Trust Anchor 147 to a client intending to start a handshake with the server. The 148 Trust Anchor maintains a separate pairwise counter for each 149 associated server in order to provide Nonce values. 151 o MAC Key (K_MAC): a symmetric key derived from the Session Key and 152 used to compute a MAC over the ClientHello message. 154 2. DoS Protection Extension 156 2.1. Extension Type 158 This specification extends the ExtensionType enum as follows: 160 enum { 161 ..., 162 dos_protection(TBD), 163 (65535) 164 } ExtensionType; 166 2.2. Extension Data 168 The "extension_data" field of the "dos_protection" extension contains 169 the following information: 171 struct { 172 uint32 nonce; 173 uint16 resumption_counter; 174 opaque dos_MAC; 175 } extension_data_content; 177 The "dos_MAC" field is 256 bits in size and is intended to include 178 the Message Authentication Code (MAC) computed over the ClientHello 179 message. 181 3. Protocol overview 183 Before becoming fully operational, the server S registers at the TA 184 through a secure communication channel or other out-of-band means. A 185 server is registered at only one TA, while the same TA can be 186 associated to multiple servers. For each registered server S, the TA 187 and S maintain a pairwise counter z_S, associated to that server and 188 encoded as a 32 bit unsigned integer. Upon S registration, S and the 189 TA initialize z_S to 0 and establish a long-term symmetric key K_M. 190 The specific means to establish K_M are out of the scope of this 191 specification. 193 The rest of this document refers to H as the hash function SHA-256, 194 and to PRF as the pseudorandom function defined in Section 5 of 195 [RFC5246] and based on HMAC [RFC2104] using SHA-256 as hash function. 197 Figure 1 shows the messages exchanged between the client (C), the 198 Trust Anchor (TA) and the server (S). 200 C TA S 201 | | | 202 | | { Shared key K_M } | 203 | | | 204 | --- Request handshake with S ---> | | 205 (1) | | | 206 | <----- N, K_S = f(K_M , N) ------ | | 207 | | | 208 --- | | | 209 | | 210 | ClientHello with "dos_protection" extension | 211 (2) | -----------------------------------------------------> | 212 | Including a MAC computed through K_MAC = f(K_S) | 213 | | 214 --- | | | 215 | | | 216 | | 217 (3) | [<-------------- Next handshake steps -------------->] | 218 | | 219 | | | 221 Figure 1: Protocol Overview 223 Step (1) concerns a client C that intends to start a new (D)TLS 224 session with the server S. That is, C contacts the TA and specifies 225 its intention to start a (D)TLS handshake with S. The client C can 226 rely on services such as [I-D.ietf-core-resource-directory] to know 227 what is the specific TA associated to S. All communications between 228 C and the TA MUST be secured, ensuring integrity, source 229 authentication, confidentiality and replay protection of exchanged 230 messages. The specific means to secure communications between C and 231 the TA are out of the scope of this specification. 233 The TA MUST be able to verify that C is authorized to establish a 234 (D)TLS session with S. To this end, the TA can directly authorize 235 the client, or expect the client to upload authorization evidence 236 previously obtained from a trusted entity. Compared with models 237 based on proxies, this approach does not require particular 238 adaptations to the communication between clients and servers. The 239 specific authorization process of clients is out of the scope of this 240 specfication. 242 In case of successful authorization, the TA provides C with a nonce N 243 as well as a symmetric key K_S computed using K_M and N. 245 During Step (2), C computes a symmetric key K_MAC using K_S, and 246 prepares the ClientHello message addressed to S, including the 247 "dos_protection" extension defined in Section 2. In particular, the 248 extension contains the nonce N and a MAC over the ClientHello message 249 computed by means of K_MAC. Then, C sends the ClientHello message to 250 S. The overall content and format of the ClientHello message depend 251 on the specific version of (D)TLS. 253 Upon receiving the ClientHello message, the server S derives the key 254 K_S using the key K_M and the nonce N included in the 255 "dos_protection" extension. Then, S derives the key K_MAC using K_S, 256 recomputes the MAC over the ClientHello message, and compares it with 257 the one conveyed in the "dos_protection" extension. Furthermore, S 258 relies on the nonce N to verify that the ClientHello message is not a 259 replay. 261 In case the ClientHello message is fresh and the MAC is valid, S 262 continues to Step (3), i.e. it proceeds with the handshake with C. 263 Otherwise, S discards the ClientHello message and aborts the 264 handshake. 266 4. Client to Trust Anchor 268 The client C requests from the TA an authorization to open a new 269 (D)TLS session with S. That is, this step does not take place if C 270 intends to resume a (D)TLS session previously established with S. In 271 case of successful authorization, the TA performs the following 272 actions. 274 1. It selects the nonce N as the current value of the pairwise 275 counter z_S associated to S. 277 2. It derives the key K_S as output of PRF(K_M, "session_key", N). 279 3. It provides C with N and K_S. 281 4. It increments the counter z_S by 1. 283 The TA handles a wrap-around of the counter z_S as described in 284 Section 9.1. 286 5. Client to Server 288 This section considers the client C intending to establish a new 289 (D)TLS session with S. Session resumption is discussed in Section 8. 291 When preparing the ClientHello message, the client C builds the 292 "dos_protection" extension defined in Section 2 as follows. 294 o The "nonce" field is set to the nonce N received from the TA. 296 o The "resumption_counter" field is set to 0. 298 o Each byte of the "dos_MAC" field is temporarily set to 0. 300 Then, C includes the "dos_protection" extension into the ClientHello 301 message, consistently with what is mandated and recommended by the 302 specific version of (D)TLS. Once the ClientHello message has been 303 completely prepared, C performs the following actions. 305 1. It derives K_MAC as output of PRF(K_S, "mac_key", 0). 307 2. It computes a MAC as the output of HMAC(K_MAC, H(ClientHello)). 309 3. It writes the MAC computed at the previous step into the 310 "dos_MAC" field of the "dos_protection" extension. 312 Finally, C transmits the ClientHello message to S. Note that C MUST 313 retransmit exactly the same "dos_protection" extension from this 314 first ClientHello message, in case it sends a second ClientHello 315 message as a reply to a HelloVerifyRequest in DTLS 1.2 or a 316 HelloRetryRequest in (D)TLS 1.3. 318 6. Server Processing 320 This section considers the server S receiving a ClientHello from C 321 for establishing a new (D)TLS session. Session resumption is 322 discussed in Section 8. 324 Servers MAY require clients to send a valid "dos_protection" 325 extension. Servers requiring this MUST respond to a ClientHello 326 lacking a "dos_protection" extension by terminating the handshake, 327 with a "missing_extension" alert if the client has shown support for 328 (D)TLS 1.3, or a "handshake_failure" alert otherwise. 330 Upon receiving the first ClientHello message from C, the server S 331 verifies that the "resumption_counter" field of the "dos_protection" 332 extension is set to 0. If its value is different than 0, then S 333 discards the ClientHello message and terminates the handshake with an 334 "illegal_parameter" alert. 336 After that, S MUST check that the ClientHello message is not a 337 replay. Section 7 of this specification describes a possible method 338 to perform the anti-replay check. If the ClientHello message is 339 found to be not fresh, then S discards it and terminates the 340 handshake with a "handshake_failure" alert. 342 If the ClientHello message is fresh and consistent with a new session 343 establishment, then S performs the following actions. 345 1. It stores the MAC from the "dos_MAC" field of the 346 "dos_protection" extension. 348 2. It sets each byte of the "dos_MAC" field to 0. 350 3. It retrieves the nonce N from the "nonce" field of the 351 "dos_protection" extension. 353 4. It derives K_S as output of PRF(K_M, "session_key", N). 355 5. It derives K_MAC as output of PRF(K_S, "mac_key", 0). 357 6. It computes a MAC as the output of HMAC(K_MAC, H(ClientHello)). 359 If the computed MAC differs from the stored MAC, S discards the 360 ClientHello message and terminates the handshake with a 361 "handshake_failure" alert. Otherwise, S proceeds with the following 362 step of the handshake with C. 364 7. Replay Protection 366 The server S maintains a sliding window W of size A, as a pair {w, 367 w_b}, where w is an A-bit vector and w_b indicates the current left 368 bound of W. That is, w_b indicates the lowest value that S can 369 accept as included in the "nonce" field of the "dos_protection" 370 extension. Upon startup, S sets w_b to 0 and all bits in w to 0. 372 Upon receiving a ClientHello message for establishing a new (D)TLS 373 session, the server S considers the nonce N from the "nonce" field of 374 the "dos_protection" extension, and performs the following checks. 376 o If N < w_b, then S discards the ClientHello message and terminates 377 the handshake. 379 o If w_b <= N < min(w_b + A, 2^32), then S defines i = (N - w_b), 380 and checks the i-th bit of vector w. If such bit is set to 1, 381 i.e. the same nonce N has been already used, then S discards the 382 ClientHello message and terminates the handshake. Instead, if 383 such bit is set to 0, then S proceeds with processing the 384 "dos_protection" extension as described in Section 6. 386 o If (w_b + A) <= N < 2^32, then S proceeds with processing the 387 "dos_protection" extension as described in Section 6. 389 Once the handshake has been successfully completed, S checks whether 390 the condition N >= w_b is still valid. In such a case, S updates the 391 window W as follows. 393 o If w_b <= N < min(w_b + A, 2^32), then S defines i = (N - w_b) and 394 sets the i-th bit of vector w to 1, so marking N as used. 395 Instead, 397 o If (w_b + A) <= N < 2^32, then S defines w* = (N - A + 1) and 398 updates vector w as w = w >> (w* - w_b), where '>>' is the 399 unsigned right bit shift operator. After that, S updates w_b as 400 w_b = w*. Finally, S defines i = (N - w_b) and sets the i-th bit 401 of vector w to 1, so marking N as used. 403 The window size A should be determined based on the expected 404 frequency of new session establishments on the server S. Evidently, 405 the larger the window, the more accurate is the replay protection, 406 but the greater the memory overhead on the server side. 408 8. Session Resumption 410 In case session resumption is supported, both C and S maintain a 411 resumption counter R for each resumable session, encoded as a 16 bit 412 unsigned integer and indicating the value expected at the next 413 resumption of that session. In particular, C and S set the counter R 414 to 0 upon the first establishment of a new session. Both C and S 415 increment the counter R by 1 each time that the associated session 416 has been successfully resumed. 418 In order to resume a session with S, the client C does not contact 419 the TA as a first step, but simply behaves as described in Section 5, 420 with the following differences. 422 o The "nonce" field of the "dos_protection" extension is set to 0. 424 o The "resumption_counter" field is set to the current value of R. 426 o K_MAC is derived as output of PRF(K_S, "mac_key_resumption", R). 428 Upon receiving a ClientHello message from C asking to resume a 429 previously established session, the server S behaves as described in 430 Section 6, with the following differences. 432 o It verifies that the "resumption_counter" field of the 433 "dos_protection" extension is equal to the current value of the 434 counter R associated to that session. In case of negative match, 435 S discards the ClientHello message and terminates the handshake 436 with an "illegal_parameter" alert. 438 o It does not perform a replay check based on the value of the 439 "nonce" field of the "dos_protection" extension, such as the one 440 described in Section 7. 442 o K_MAC is derived as output of PRF(K_S, "mac_key_resumption", R). 444 Further details about session resumptions are defined in the (D)TLS 445 specifications of the different respective versions. 447 9. Security Considerations 449 This specification does not change the intended security properties 450 of TLS and DTLS. Additional security aspects are discussed below. 452 9.1. Renewal of Long-Term Key K_M 454 While it can practically take a long amount of time, the pairwise 455 counter z_S maintained by the TA and associated to S eventually wraps 456 around. When this happens, the TA MUST revoke the key K_M shared 457 with S, in order to not re-issue previously released pairs {N, K_S} 458 to requesting clients. 460 In particular, when the counter z_S wraps-around, the TA MUST perform 461 the following actions. 463 1. It stops accepting requests related to S from clients. 465 2. It securely generates a new long-term key K_M and securely 466 provides it to S. 468 3. It resumes serving requests related to S from clients, using the 469 new K_M to derive keys K_S. 471 9.2. Rate Limit to Nonce Release 473 It is RECOMMENDED that the TA does not release nonces to clients 474 beyond a maximum rate. This prevents a client with legitimate 475 credentials from quickly consuming the nonce space associated to S, 476 and thus making the TA unable to serve other clients. 478 10. IANA Considerations 480 IANA [SHALL add/has added] a new entry to the TLS ExtensionType 481 Registry originally created in [RFC4366], including the 482 "dos_protection" extension with the value described in this 483 specification. 485 11. Acknowledgments 487 The authors sincerely thank Santiago Aragon for his comments and 488 feedback. 490 The authors worked on this document as part of the EU FP7 project 491 SEGRID (Grant Agreement no. 607109) and the EIT-Digital High Impact 492 Initiative ACTIVE. 494 12. References 496 12.1. Normative References 498 [I-D.ietf-tls-dtls13] 499 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 500 Datagram Transport Layer Security (DTLS) Protocol Version 501 1.3", draft-ietf-tls-dtls13-00 (work in progress), April 502 2017. 504 [I-D.ietf-tls-tls13] 505 Rescorla, E., "The Transport Layer Security (TLS) Protocol 506 Version 1.3", draft-ietf-tls-tls13-20 (work in progress), 507 April 2017. 509 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 510 Hashing for Message Authentication", RFC 2104, 511 DOI 10.17487/RFC2104, February 1997, 512 . 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, 516 DOI 10.17487/RFC2119, March 1997, 517 . 519 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 520 (TLS) Protocol Version 1.2", RFC 5246, 521 DOI 10.17487/RFC5246, August 2008, 522 . 524 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 525 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 526 January 2012, . 528 12.2. Informative References 530 [I-D.ietf-core-resource-directory] 531 Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE 532 Resource Directory", draft-ietf-core-resource-directory-10 533 (work in progress), March 2017. 535 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 536 and T. Wright, "Transport Layer Security (TLS) 537 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 538 . 540 Authors' Addresses 542 Marco Tiloca 543 RISE SICS AB 544 Isafjordsgatan 22 545 Kista SE-164 29 546 Sweden 548 Phone: +46 70 604 65 01 549 Email: marco.tiloca@ri.se 551 Ludwig Seitz 552 RISE SICS AB 553 Scheelevaegen 17 554 Lund SE-223 70 555 Sweden 557 Phone: +46 70 349 92 51 558 Email: ludwig.seitz@ri.se 560 Maarten Hoeve 561 ENCS 562 Regulusweg 5 563 The Hague 2516 AC 564 The Netherlands 566 Phone: +31 62 015 75 51 567 Email: maarten.hoeve@encs.eu