[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

TLS Working Group                                              M. Tiloca
Internet-Draft                                                  L. Seitz
Intended status: Standards Track                            RISE SICS AB
Expires: December 30, 2017                                      M. Hoeve
                                                                    ENCS
                                                           June 28, 2017


  Extension for protecting (D)TLS handshakes against Denial of Service
                   draft-tiloca-tls-dos-handshake-00

Abstract

   This document describes an extension for TLS and DTLS to protect the
   server from Denial of Service attacks against the handshake protocol.
   The extension includes a Message Authentication Code (MAC) over the
   ClientHello message, computed by the Client through key material
   obtained from a Trust Anchor entity.  The server registered at the
   Trust Anchor derives the same key material and checks the MAC to
   determine whether continuing or aborting the handshake.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 30, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Tiloca, et al.          Expires December 30, 2017               [Page 1]


Internet-Draft (D)TLS extension against Denial of Service      June 2017


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  DoS Protection Extension  . . . . . . . . . . . . . . . . . .   4
     2.1.  Extension Type  . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Extension Data  . . . . . . . . . . . . . . . . . . . . .   4
   3.  Protocol overview . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Client to Trust Anchor  . . . . . . . . . . . . . . . . . . .   6
   5.  Client to Server  . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Server Processing . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Replay Protection . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Session Resumption  . . . . . . . . . . . . . . . . . . . . .   9
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     9.1.  Renewal of Long-Term Key K_M  . . . . . . . . . . . . . .  10
     9.2.  Rate Limit to Nonce Release . . . . . . . . . . . . . . .  10
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     12.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Servers running TLS [RFC5246][I-D.ietf-tls-tls13] and DTLS
   [RFC6347][I-D.ietf-tls-dtls13] are vulnerable to Denial of Service
   (DoS) attacks during the very first step of the handshake protocol.
   That is, an adversary can repeatedly send ClientHello messages to the
   server and induce it to start performing invalid handshakes.

   DTLS 1.2 as well as both TLS 1.3 and DTLS 1.3 provide the optional
   Cookie exchange as possible solution to mitigate this Denial of
   Service attack.  While this makes the attack more complicated to
   mount, a well determined and resourceful adversary able to spoof
   valid IP addresses can still successfully perform it, by intercepting
   the possible server response including the Cookie and then echoing it
   in the second ClientHello.  This is particularly doable in case the
   handshake is not based on Pre-Shared Key exchange modes.

   Depending on the specific protocol version and the key establishment
   mode used in the handshake, the attack impact can range from single
   replies triggered by invalid ClientHello messages, to the server



Tiloca, et al.          Expires December 30, 2017               [Page 2]


Internet-Draft (D)TLS extension against Denial of Service      June 2017


   performing advanced handshake steps with consequent setup of invalid
   half-open sessions.  Especially if performed in a large-scale and
   distributed manner, this attack can thwart performance and service
   availability of (D)TLS servers.  Moreover, it can be particularly
   effective in application scenarios where servers are resource-
   constrained devices running DTLS over low-power, low bandwidth and
   lossy networks.

   This specification proposes a "dos_protection" extension for TLS and
   DTLS, which is used to mark valid ClientHello messages and neutralize
   the Denial of Service attack mentioned above.  In essence, the client
   computes a Message Authentication Code (MAC) of the first ClientHello
   message addressed to the server.  Then, the MAC is included in the
   "dos_protection" extension, together with information used for its
   validation on the server side.  Upon receiving the ClientHello
   message, the server checks the MAC carried in the "dos_protection"
   extension, and determines whether to continue the handshake or to
   immediately abort it.

   The proposed method relies on a Trust Anchor (TA) entity, which is in
   a trust relation with the server and authorizes the client to
   establish a secure session with the server.  In particular, the Trust
   Anchor provides the client with the key material to compute the MAC
   included in the "dos_protection" extension.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].  These
   words may also appear in this document in lowercase, absent their
   normative meanings.

   Readers are expected to be familiar with terms and concepts related
   to TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347], as well as to TLS 1.3
   [I-D.ietf-tls-tls13] and DTLS 1.3 [I-D.ietf-tls-dtls13], with
   particular reference to their respective handshake protocol.

   This document refers also to the following terminology.

   o  Trust Anchor (TA): a trusted third party in a trust relation with
      the (D)TLS server.

   o  Master Key (K_M): a long-term symmetric key shared between the
      Trust Anchor and the server.

   o  Session Key (K_S): a symmetric key provided by the Trust Anchor to
      a client intending to start a handshake with the server.



Tiloca, et al.          Expires December 30, 2017               [Page 3]


Internet-Draft (D)TLS extension against Denial of Service      June 2017


   o  Nonce (N): a 32 bit unsigned integer provided by the Trust Anchor
      to a client intending to start a handshake with the server.  The
      Trust Anchor maintains a separate pairwise counter for each
      associated server in order to provide Nonce values.

   o  MAC Key (K_MAC): a symmetric key derived from the Session Key and
      used to compute a MAC over the ClientHello message.

2.  DoS Protection Extension

2.1.  Extension Type

   This specification extends the ExtensionType enum as follows:

      enum {
          ...,
          dos_protection(TBD),
          (65535)
      } ExtensionType;

2.2.  Extension Data

   The "extension_data" field of the "dos_protection" extension contains
   the following information:

       struct {
         uint32 nonce;
         uint16 resumption_counter;
         opaque dos_MAC;
       } extension_data_content;

   The "dos_MAC" field is 256 bits in size and is intended to include
   the Message Authentication Code (MAC) computed over the ClientHello
   message.

3.  Protocol overview

   Before becoming fully operational, the server S registers at the TA
   through a secure communication channel or other out-of-band means.  A
   server is registered at only one TA, while the same TA can be
   associated to multiple servers.  For each registered server S, the TA
   and S maintain a pairwise counter z_S, associated to that server and
   encoded as a 32 bit unsigned integer.  Upon S registration, S and the
   TA initialize z_S to 0 and establish a long-term symmetric key K_M.
   The specific means to establish K_M are out of the scope of this
   specification.





Tiloca, et al.          Expires December 30, 2017               [Page 4]


Internet-Draft (D)TLS extension against Denial of Service      June 2017


   The rest of this document refers to H as the hash function SHA-256,
   and to PRF as the pseudorandom function defined in Section 5 of
   [RFC5246] and based on HMAC [RFC2104] using SHA-256 as hash function.

   Figure 1 shows the messages exchanged between the client (C), the
   Trust Anchor (TA) and the server (S).

           C                                   TA                   S
           |                                   |                    |
           |                                   | { Shared key K_M } |
           |                                   |                    |
           | --- Request handshake with S ---> |                    |
     (1)   |                                   |                    |
           | <----- N, K_S = f(K_M , N) ------ |                    |
           |                                   |                    |
     ---   |                                   |                    |
           |                                                        |
           |      ClientHello with "dos_protection" extension       |
     (2)   | -----------------------------------------------------> |
           |    Including a MAC computed through K_MAC = f(K_S)     |
           |                                                        |
     ---   |                                   |                    |
           |                                   |                    |
           |                                                        |
     (3)   | [<-------------- Next handshake steps -------------->] |
           |                                                        |
           |                                   |                    |

                        Figure 1: Protocol Overview

   Step (1) concerns a client C that intends to start a new (D)TLS
   session with the server S.  That is, C contacts the TA and specifies
   its intention to start a (D)TLS handshake with S.  The client C can
   rely on services such as [I-D.ietf-core-resource-directory] to know
   what is the specific TA associated to S.  All communications between
   C and the TA MUST be secured, ensuring integrity, source
   authentication, confidentiality and replay protection of exchanged
   messages.  The specific means to secure communications between C and
   the TA are out of the scope of this specification.

   The TA MUST be able to verify that C is authorized to establish a
   (D)TLS session with S.  To this end, the TA can directly authorize
   the client, or expect the client to upload authorization evidence
   previously obtained from a trusted entity.  Compared with models
   based on proxies, this approach does not require particular
   adaptations to the communication between clients and servers.  The
   specific authorization process of clients is out of the scope of this
   specfication.



Tiloca, et al.          Expires December 30, 2017               [Page 5]


Internet-Draft (D)TLS extension against Denial of Service      June 2017


   In case of successful authorization, the TA provides C with a nonce N
   as well as a symmetric key K_S computed using K_M and N.

   During Step (2), C computes a symmetric key K_MAC using K_S, and
   prepares the ClientHello message addressed to S, including the
   "dos_protection" extension defined in Section 2.  In particular, the
   extension contains the nonce N and a MAC over the ClientHello message
   computed by means of K_MAC.  Then, C sends the ClientHello message to
   S.  The overall content and format of the ClientHello message depend
   on the specific version of (D)TLS.

   Upon receiving the ClientHello message, the server S derives the key
   K_S using the key K_M and the nonce N included in the
   "dos_protection" extension.  Then, S derives the key K_MAC using K_S,
   recomputes the MAC over the ClientHello message, and compares it with
   the one conveyed in the "dos_protection" extension.  Furthermore, S
   relies on the nonce N to verify that the ClientHello message is not a
   replay.

   In case the ClientHello message is fresh and the MAC is valid, S
   continues to Step (3), i.e. it proceeds with the handshake with C.
   Otherwise, S discards the ClientHello message and aborts the
   handshake.

4.  Client to Trust Anchor

   The client C requests from the TA an authorization to open a new
   (D)TLS session with S.  That is, this step does not take place if C
   intends to resume a (D)TLS session previously established with S.  In
   case of successful authorization, the TA performs the following
   actions.

   1.  It selects the nonce N as the current value of the pairwise
       counter z_S associated to S.

   2.  It derives the key K_S as output of PRF(K_M, "session_key", N).

   3.  It provides C with N and K_S.

   4.  It increments the counter z_S by 1.

   The TA handles a wrap-around of the counter z_S as described in
   Section 9.1.








Tiloca, et al.          Expires December 30, 2017               [Page 6]


Internet-Draft (D)TLS extension against Denial of Service      June 2017


5.  Client to Server

   This section considers the client C intending to establish a new
   (D)TLS session with S.  Session resumption is discussed in Section 8.

   When preparing the ClientHello message, the client C builds the
   "dos_protection" extension defined in Section 2 as follows.

   o  The "nonce" field is set to the nonce N received from the TA.

   o  The "resumption_counter" field is set to 0.

   o  Each byte of the "dos_MAC" field is temporarily set to 0.

   Then, C includes the "dos_protection" extension into the ClientHello
   message, consistently with what is mandated and recommended by the
   specific version of (D)TLS.  Once the ClientHello message has been
   completely prepared, C performs the following actions.

   1.  It derives K_MAC as output of PRF(K_S, "mac_key", 0).

   2.  It computes a MAC as the output of HMAC(K_MAC, H(ClientHello)).

   3.  It writes the MAC computed at the previous step into the
       "dos_MAC" field of the "dos_protection" extension.

   Finally, C transmits the ClientHello message to S.  Note that C MUST
   retransmit exactly the same "dos_protection" extension from this
   first ClientHello message, in case it sends a second ClientHello
   message as a reply to a HelloVerifyRequest in DTLS 1.2 or a
   HelloRetryRequest in (D)TLS 1.3.

6.  Server Processing

   This section considers the server S receiving a ClientHello from C
   for establishing a new (D)TLS session.  Session resumption is
   discussed in Section 8.

   Servers MAY require clients to send a valid "dos_protection"
   extension.  Servers requiring this MUST respond to a ClientHello
   lacking a "dos_protection" extension by terminating the handshake,
   with a "missing_extension" alert if the client has shown support for
   (D)TLS 1.3, or a "handshake_failure" alert otherwise.

   Upon receiving the first ClientHello message from C, the server S
   verifies that the "resumption_counter" field of the "dos_protection"
   extension is set to 0.  If its value is different than 0, then S




Tiloca, et al.          Expires December 30, 2017               [Page 7]


Internet-Draft (D)TLS extension against Denial of Service      June 2017


   discards the ClientHello message and terminates the handshake with an
   "illegal_parameter" alert.

   After that, S MUST check that the ClientHello message is not a
   replay.  Section 7 of this specification describes a possible method
   to perform the anti-replay check.  If the ClientHello message is
   found to be not fresh, then S discards it and terminates the
   handshake with a "handshake_failure" alert.

   If the ClientHello message is fresh and consistent with a new session
   establishment, then S performs the following actions.

   1.  It stores the MAC from the "dos_MAC" field of the
       "dos_protection" extension.

   2.  It sets each byte of the "dos_MAC" field to 0.

   3.  It retrieves the nonce N from the "nonce" field of the
       "dos_protection" extension.

   4.  It derives K_S as output of PRF(K_M, "session_key", N).

   5.  It derives K_MAC as output of PRF(K_S, "mac_key", 0).

   6.  It computes a MAC as the output of HMAC(K_MAC, H(ClientHello)).

   If the computed MAC differs from the stored MAC, S discards the
   ClientHello message and terminates the handshake with a
   "handshake_failure" alert.  Otherwise, S proceeds with the following
   step of the handshake with C.

7.  Replay Protection

   The server S maintains a sliding window W of size A, as a pair {w,
   w_b}, where w is an A-bit vector and w_b indicates the current left
   bound of W.  That is, w_b indicates the lowest value that S can
   accept as included in the "nonce" field of the "dos_protection"
   extension.  Upon startup, S sets w_b to 0 and all bits in w to 0.

   Upon receiving a ClientHello message for establishing a new (D)TLS
   session, the server S considers the nonce N from the "nonce" field of
   the "dos_protection" extension, and performs the following checks.

   o  If N < w_b, then S discards the ClientHello message and terminates
      the handshake.

   o  If w_b <= N < min(w_b + A, 2^32), then S defines i = (N - w_b),
      and checks the i-th bit of vector w.  If such bit is set to 1,



Tiloca, et al.          Expires December 30, 2017               [Page 8]


Internet-Draft (D)TLS extension against Denial of Service      June 2017


      i.e. the same nonce N has been already used, then S discards the
      ClientHello message and terminates the handshake.  Instead, if
      such bit is set to 0, then S proceeds with processing the
      "dos_protection" extension as described in Section 6.

   o  If (w_b + A) <= N < 2^32, then S proceeds with processing the
      "dos_protection" extension as described in Section 6.

   Once the handshake has been successfully completed, S checks whether
   the condition N >= w_b is still valid.  In such a case, S updates the
   window W as follows.

   o  If w_b <= N < min(w_b + A, 2^32), then S defines i = (N - w_b) and
      sets the i-th bit of vector w to 1, so marking N as used.
      Instead,

   o  If (w_b + A) <= N < 2^32, then S defines w* = (N - A + 1) and
      updates vector w as w = w >> (w* - w_b), where '>>' is the
      unsigned right bit shift operator.  After that, S updates w_b as
      w_b = w*. Finally, S defines i = (N - w_b) and sets the i-th bit
      of vector w to 1, so marking N as used.

   The window size A should be determined based on the expected
   frequency of new session establishments on the server S.  Evidently,
   the larger the window, the more accurate is the replay protection,
   but the greater the memory overhead on the server side.

8.  Session Resumption

   In case session resumption is supported, both C and S maintain a
   resumption counter R for each resumable session, encoded as a 16 bit
   unsigned integer and indicating the value expected at the next
   resumption of that session.  In particular, C and S set the counter R
   to 0 upon the first establishment of a new session.  Both C and S
   increment the counter R by 1 each time that the associated session
   has been successfully resumed.

   In order to resume a session with S, the client C does not contact
   the TA as a first step, but simply behaves as described in Section 5,
   with the following differences.

   o  The "nonce" field of the "dos_protection" extension is set to 0.

   o  The "resumption_counter" field is set to the current value of R.

   o  K_MAC is derived as output of PRF(K_S, "mac_key_resumption", R).





Tiloca, et al.          Expires December 30, 2017               [Page 9]


Internet-Draft (D)TLS extension against Denial of Service      June 2017


   Upon receiving a ClientHello message from C asking to resume a
   previously established session, the server S behaves as described in
   Section 6, with the following differences.

   o  It verifies that the "resumption_counter" field of the
      "dos_protection" extension is equal to the current value of the
      counter R associated to that session.  In case of negative match,
      S discards the ClientHello message and terminates the handshake
      with an "illegal_parameter" alert.

   o  It does not perform a replay check based on the value of the
      "nonce" field of the "dos_protection" extension, such as the one
      described in Section 7.

   o  K_MAC is derived as output of PRF(K_S, "mac_key_resumption", R).

   Further details about session resumptions are defined in the (D)TLS
   specifications of the different respective versions.

9.  Security Considerations

   This specification does not change the intended security properties
   of TLS and DTLS.  Additional security aspects are discussed below.

9.1.  Renewal of Long-Term Key K_M

   While it can practically take a long amount of time, the pairwise
   counter z_S maintained by the TA and associated to S eventually wraps
   around.  When this happens, the TA MUST revoke the key K_M shared
   with S, in order to not re-issue previously released pairs {N, K_S}
   to requesting clients.

   In particular, when the counter z_S wraps-around, the TA MUST perform
   the following actions.

   1.  It stops accepting requests related to S from clients.

   2.  It securely generates a new long-term key K_M and securely
       provides it to S.

   3.  It resumes serving requests related to S from clients, using the
       new K_M to derive keys K_S.

9.2.  Rate Limit to Nonce Release

   It is RECOMMENDED that the TA does not release nonces to clients
   beyond a maximum rate.  This prevents a client with legitimate




Tiloca, et al.          Expires December 30, 2017              [Page 10]


Internet-Draft (D)TLS extension against Denial of Service      June 2017


   credentials from quickly consuming the nonce space associated to S,
   and thus making the TA unable to serve other clients.

10.  IANA Considerations

   IANA [SHALL add/has added] a new entry to the TLS ExtensionType
   Registry originally created in [RFC4366], including the
   "dos_protection" extension with the value described in this
   specification.

11.  Acknowledgments

   The authors sincerely thank Santiago Aragon for his comments and
   feedback.

   The authors worked on this document as part of the EU FP7 project
   SEGRID (Grant Agreement no. 607109) and the EIT-Digital High Impact
   Initiative ACTIVE.

12.  References

12.1.  Normative References

   [I-D.ietf-tls-dtls13]
              Rescorla, E., Tschofenig, H., and N. Modadugu, "The
              Datagram Transport Layer Security (DTLS) Protocol Version
              1.3", draft-ietf-tls-dtls13-00 (work in progress), April
              2017.

   [I-D.ietf-tls-tls13]
              Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", draft-ietf-tls-tls13-20 (work in progress),
              April 2017.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <http://www.rfc-editor.org/info/rfc2104>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.



Tiloca, et al.          Expires December 30, 2017              [Page 11]


Internet-Draft (D)TLS extension against Denial of Service      June 2017


   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <http://www.rfc-editor.org/info/rfc6347>.

12.2.  Informative References

   [I-D.ietf-core-resource-directory]
              Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE
              Resource Directory", draft-ietf-core-resource-directory-10
              (work in progress), March 2017.

   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006,
              <http://www.rfc-editor.org/info/rfc4366>.

Authors' Addresses

   Marco Tiloca
   RISE SICS AB
   Isafjordsgatan 22
   Kista  SE-164 29
   Sweden

   Phone: +46 70 604 65 01
   Email: marco.tiloca@ri.se


   Ludwig Seitz
   RISE SICS AB
   Scheelevaegen 17
   Lund  SE-223 70
   Sweden

   Phone: +46 70 349 92 51
   Email: ludwig.seitz@ri.se


   Maarten Hoeve
   ENCS
   Regulusweg 5
   The Hague  2516 AC
   The Netherlands

   Phone: +31 62 015 75 51
   Email: maarten.hoeve@encs.eu





Tiloca, et al.          Expires December 30, 2017              [Page 12]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/