Internet DRAFT - draft-kazuho-quic-authenticated-handshake

draft-kazuho-quic-authenticated-handshake







QUIC                                                              K. Oku
Internet-Draft                                                    Fastly
Intended status: Experimental                                 C. Huitema
Expires: January 6, 2020                            Private Octopus Inc.
                                                           July 05, 2019


                    Authenticated Handshake for QUIC
              draft-kazuho-quic-authenticated-handshake-01

Abstract

   This document explains a variant of QUIC protocol version 1 that uses
   the ESNI Keys to authenticate the Initial packets thereby making the
   entire handshake tamper-proof.

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 January 6, 2020.

Copyright Notice

   Copyright (c) 2019 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
   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.




Oku & Huitema            Expires January 6, 2020                [Page 1]

Internet-Draft      Authenticated Handshake for QUIC           July 2019


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   3
   2.  Differences from QUIC version 1 . . . . . . . . . . . . . . .   3
     2.1.  Protocol Version Number . . . . . . . . . . . . . . . . .   3
     2.2.  The "QUIC-AH" TLS Extension . . . . . . . . . . . . . . .   3
     2.3.  Initial Packet  . . . . . . . . . . . . . . . . . . . . .   4
       2.3.1.  Mapping to Connections  . . . . . . . . . . . . . . .   4
       2.3.2.  Protection  . . . . . . . . . . . . . . . . . . . . .   4
       2.3.3.  Destination Connection ID . . . . . . . . . . . . . .   4
     2.4.  Version Negotiation Packet  . . . . . . . . . . . . . . .   5
     2.5.  Connection Close Packet . . . . . . . . . . . . . . . . .   5
     2.6.  Retry Packet  . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Considerations  . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Using GCM to Authenticate Initial Packets . . . . . . . .   6
     3.2.  Split Mode  . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     4.1.  Resisting the duplicate context attack  . . . . . . . . .   8
     4.2.  Resisting Address Substitution Attacks  . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   9
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  10
   Appendix B.  Change Log . . . . . . . . . . . . . . . . . . . . .  10
     B.1.  Since draft-kazuho-quic-authenticated-handshake-00  . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   As defined in Secure Using TLS to Secure QUIC [QUIC-TLS], QUIC
   version 1 [QUIC-TRANSPORT] protects the payload of every QUIC packet
   using AEAD making the protocol injection- and tamper-proof, with the
   exception being the Initial packets.  Initial packets are merely
   obfuscated because there is no shared secret between the endpoints
   when they start sending the Initial packets against each other.

   However, when Encrypted Server Name Indication for TLS 1.3 [TLS-ESNI]
   is used, a shared secret between the endpoints can be used for
   authentication from the very first packet of the connection.

   This document defines a Packet Protection method for Initial packets
   that incorporates the ESNI shared secret, so that spoofed Initial
   packets will be detected and droped.








Oku & Huitema            Expires January 6, 2020                [Page 2]

Internet-Draft      Authenticated Handshake for QUIC           July 2019


1.1.  Notational Conventions

   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].

2.  Differences from QUIC version 1

   The document describes the changes from QUIC version 1.

   Implementations MUST conform to the specifications of QUIC version 1
   unless a different behavior is defined in this document.

2.1.  Protocol Version Number

   The long header packets exchanged using this specification carry the
   QUIC version number of 0xXXXXXXXX (TBD).

2.2.  The "QUIC-AH" TLS Extension

   The QUIC-AH TLS Extension indicates the versions of QUIC supported by
   the server that have the authenticated handshake flavors, along with
   the versions being exposed on the wire for each of those versions.

      struct {
          uint32 base_version;
          uint32 wire_versions<4..2^16-4>;
      } SupportedVersion;

      struct {
          SupportedVersion supported_versions<8..2^16-4>;
      } QUIC_AH;

   This specification defines a variant of QUIC version 1.  Therefore, a
   ESNI Resource Records being published for a server providing support
   for this specification MUST include a QUIC_AH extension that contains
   a SupportedVersion structure with the "base_version" set to 1.

   A client MUST NOT initiate a connection establishment attempt
   specified in this document unless it sees a compatible base version
   number in the QUIC_AH extension of the ESNI Resource Record
   advertised by the server.

   The "wire_versions" field indicates the version numbers to be
   contained in the long header packets, for each of the base versions
   that the server supports.  The wire versions SHOULD be chosen at
   random, as the exposure of arbitrary version numbers prevents network




Oku & Huitema            Expires January 6, 2020                [Page 3]

Internet-Draft      Authenticated Handshake for QUIC           July 2019


   devices from incorrectly assuming that the version numbers are
   stable.

   For each connection establishment attempt, a client SHOULD randomly
   choose one wire version, and the endpoints MUST use long header
   packets containing the chosen wire version throughout that connection
   establishment attempt.

2.3.  Initial Packet

2.3.1.  Mapping to Connections

   A server associates an Initial packet to an existing connection using
   the Destination Connection ID, QUIC version, and the five tuple.  If
   all of the values match to that of an existing connection, the packet
   is processed accordingly.  Otherwise, a server MUST handle the packet
   as potentially creating a new connection.

2.3.2.  Protection

   Initial packets are encrypted and authenticated differently from QUIC
   version 1.

   AES [AES] in counter (CTR) mode is used for encrypting the payload.
   The key and iv being used are identical to that of QUIC version 1.

   HMAC [RFC2104] is used for authenticating the header.  The message
   being authenticated is the concatenation of the packet header without
   Header Protection and the payload in cleartext.  The underlying hash
   function being used is the one selected for encrypting the Encrypted
   SNI extension.  The HMAC key is calculated using the following
   formula, where Zx is the extracted DH shared secret of Encrypted SNI:

   hmac_key = HKDF-Expand-Label(Zx, "quic initial auth", Hash(ESNIContents),
                                digest_size)

   The first sixteen (16) octets of the HMAC output replaces the
   authentication tag of QUIC version 1.

   Other types of packets are protected using the Packet Protection
   method defined in QUIC version 1.

2.3.3.  Destination Connection ID

   When establishing a connection, a client MUST initially set the
   Destination Connection ID to the hashed value of the first payload of
   the CRYPTO stream (i.e., the ClientHello message) truncated to first




Oku & Huitema            Expires January 6, 2020                [Page 4]

Internet-Draft      Authenticated Handshake for QUIC           July 2019


   sixteen (16) bytes.  The hash function being used is the one selected
   by Encrypted SNI.

   When processing the first payload carried by a CRYPTO stream, a
   server MUST, in addition to verifying the authentication tag, verify
   that the truncated hash value of the payload is identical to the
   Destination Connection ID or to the original Connection ID recovered
   from the the Retry Token.  A server MUST NOT create or modify
   connection state if either or both the verification fails.

2.4.  Version Negotiation Packet

   A client MUST ignore Version Negotiation packets.  When the client
   gives up of establishing a connection, it MAY report the failure
   differently based on the receipt of (or lack of) Version Negotiation
   packets.

2.5.  Connection Close Packet

   A Connection Close packet shares a long packet header with a type
   value of 0x3 with the Retry packet.  The two types of packets are
   identified by the lower 4-bits of the first octet.  The packet is a
   Connection Close packet if all the bits are set to zero.  Otherwise,
   the packet is a Retry packet.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+
   |1|1| 3 |   0   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Version (32)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |DCIL(4)|SCIL(4)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Destination Connection ID (0/32..144)         ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Source Connection ID (0/32..144)            ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Error Code (16)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   (: #connection-close-format title="Connection Close Packet")

   A Connection Close packet is sent by a server when a connection error
   occurs prior to deriving the HMAC key.  In all other conditions,
   connection close MUST be signalled using the CONNECTION_CLOSE frame.





Oku & Huitema            Expires January 6, 2020                [Page 5]

Internet-Draft      Authenticated Handshake for QUIC           July 2019


   A client that receives a Connection Close packet before an Initial
   packet SHOULD retain the error code, and continue the connection
   establishment attempt as if it did not see the packet.  When the
   attempt times out, it MAY assume that the error code was a legitimate
   value sent by the server.  A client MAY ignore Connection Close
   packets.

2.6.  Retry Packet

   A client SHOULD send one Initial packet in response to each Retry
   packet it receives.  The Destination Connection ID of the Initial
   packet MUST be set to the value specified by the Retry packet,
   however the keys for encrypting and authenticating the packet MUST
   continue to be the original ones.  A server sending a Retry packet is
   expected to include the original Connection ID in the Retry Token it
   emits, and to use the value contained in the token attached to the
   Initial packet for unprotecting the payload.

   Payload of the CRYPTO frame contained in the resent Initial packets
   MUST be identical to that of the Initial packet that triggered the
   retry.

   When the client does not receive a valid Initial packet after a
   handshake timeout, it SHOULD send an Initial packet with the
   Destination Connection ID and the token set to the original value.

   A client MUST ignore Retry packets received anterior to an Initial
   packet that successfully authenticates.

3.  Considerations

3.1.  Using GCM to Authenticate Initial Packets

   An alternative approach to using the combination of AES-CTR and HMAC
   is to continue using AES-GCM.  In such approach, the additional
   authenticated data (AAD) will incorporate the ESNI shared secret to
   detect spoofed or broken packets.

   A server that receives an Initial packet for a new connection will at
   first decrypt the payload using AES-CTR, derive ESNI shared secret
   from the Hello message being contained, then use that to verify the
   GCM tag.

   The benefit of the approach is that we will have less divergence from
   QUIC version 1.  The downside is that the authentication algorithm
   would be hard-coded to GCM, and that some AEAD APIs might not provide
   an interface to handle input in this particular way.




Oku & Huitema            Expires January 6, 2020                [Page 6]

Internet-Draft      Authenticated Handshake for QUIC           July 2019


   We can also consider adding a small checksum to the Initial packets
   so that the server can determine if the packet is corrupt.  The
   downside is that the endpoints would be required to calculate the
   checksum for Initial packets that carry server's messages and ACKs as
   well, even though the correctness of the packet can be verified using
   the ordinary procedure of AEAD.

3.2.  Split Mode

   To support server-side deployments using "Split Mode" ([TLS-ESNI];
   section 3), the following properties need to be exchanged between the
   fronting server and the hidden server, in addition to those generally
   required by a QUIC version 1 proxy and the Encrypted SNI extension:

   o  hmac_key

   o  ODCID

   Both the fronting server and the hidden server need access to the
   hmac_key to authenticate the Initial packets.  However, because the
   key is derived from the shared DH secret of ESNI, it is not
   necessarily available to the hidden server.

   ODCID is necessary to decrypt an Initial packet sent in response to a
   Retry.  However, the value is typically available only to the server
   that generates the Retry.  The fronting server and the hidden server
   need to exchange the ODCID, or provide the secret for extracting the
   ODCID from a Retry token.

4.  Security Considerations

   The authenticated handshake is designed to enable successful
   connections even if clients and servers are attacked by a powerful
   "man on the side", which cannot delete packets but can inject packets
   and will always win the race against original packets.i We want to
   enable the following pattern: ```

   Client Attacker Server

   CInitial -> CInitial' -> CInitial -> <- SInitial <- SInitial' <-
   SInitial

   CHandshake -> CHandshake -> ``` The goal is a successful handshake
   despite injection by the attacker of fake Client Initial packet
   (CInitial') or Server Initial packet (SInitial').

   The main defense against forgeries is the HMAC authentication of the
   Initial packets using an ESNI derived key that is not accessible to



Oku & Huitema            Expires January 6, 2020                [Page 7]

Internet-Draft      Authenticated Handshake for QUIC           July 2019


   the attacker.  This prevents all classes of attacks using forged
   Initial packets.  There are however two methods that are still
   available to the attackers:

   1) Forge an Initial packet that will claim the same context as the
   client request,

   2) Send duplicates of the client request from a fake source address.

   These two attacks and their mitigation are discussed in the next
   sections.

4.1.  Resisting the duplicate context attack

   The attacker mounts a duplicate context attack by observing the
   original Client Initial packet, and then creating its own Client
   Initial packet in which source and destination CID are the same as in
   the original packet.  The ESNI secret will be different, because the
   packet is composed by the server.  The goal of the attacker is to let
   the server create a context associated with the CID, so that when the
   original Client Initial later arrives it gets discarded.

   This attack is mitigated by verifying that the Destination CID of the
   Client Initial matches the hash of the first CRYPTO stream payload.

   If the server uses address verification, there may be a Retry
   scenario: ``` Client Attacker Server

   CInitial -> <- Retry (with Token) CInitial2 (including Token) -> <-
   Sinitial

   CHandshake -> ``` The Destination CID of the second Client Initial
   packet is selected by the server, or by a device acting on behalf of
   the server.  This destination CID will not match the hash of the
   CRYPTO stream payload.  However, in the retry scenario, the server is
   already rquired to know the Destination CID from the original Client
   Initial packet (ODCID), because it has to echo it in the transport
   parameters extension.  The server can then verify that the hash of
   the CRYPTO stream payload matches the ODCID.

4.2.  Resisting Address Substitution Attacks

   The DCID of the original Initial packet is defined as the hash of the
   first payload of the CRYPTO stream.  This prevents attackers from
   sending "fake" Initial packets that would be processed in the same
   server connection context as the authentic packet.  However, it does
   not prevent address substitution attacks such as: ``` Client Attacker
   Server



Oku & Huitema            Expires January 6, 2020                [Page 8]

Internet-Draft      Authenticated Handshake for QUIC           July 2019


   CInitial(from A) -> CInitial(from A') -> CInitial(from A) -> ``` In
   this attack, the attacker races a copy of the Initial packet,
   substituting a faked value for the client's source address.  The goal
   of the attack is to cause the server to associate the fake address
   with the connection context, causing the connection to fail.

   The server cannot prevent this attack by just verifying the HMAC,
   because the address field is not covered by the checksum
   authentication.  To actually mitigate the attack, the server needs to
   create different connection contexts for each pair of Initial DCID
   and source Address.  The resulting exchange will be: ``` Client
   Attacker Server

   CInitial(from A) -> CInitial(A') -> <- SInitial-X(to A') CInitial(A)
   -> <- SInitial-Y(to A) CHandshake-Y -> ```

   The server behavior is required even if the server uses address
   verification procedures, because the attacker could mount a complex
   attack in which it obtains a Retry Token for its own address, then
   forwards it to the client: ``` Client Attacker Server

   CInitial(from A) -> CInitial(from A') -> <- Retry(to A', T(A')) <-
   Retry(to A, T(A')) CInitial2(from A, T(A')) -> CInitial(from A',
   T(A')) ->

                    CInitial(from A)  ->
                                            <- Retry(T(A)) CInitial3(from A, T(A)) -> ``` At the end of this exchange, the server will have received two valid client Initial packets that both path address verification and the ESNI based HMAC, and both have the same CRYPTO stream initial payload and the same ODCID. If it kept only one of them, the attacker would have succeeded in distrupting the connection attempt.

5.  IANA Considerations

   TBD

6.  Normative References

   [AES]      "Advanced encryption standard (AES)", National Institute
              of Standards and Technology report,
              DOI 10.6028/nist.fips.197, November 2001.

   [QUIC-TLS]
              Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
              QUIC", draft-ietf-quic-tls-20 (work in progress), April
              2019.

   [QUIC-TRANSPORT]
              Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", draft-ietf-quic-
              transport-20 (work in progress), April 2019.




Oku & Huitema            Expires January 6, 2020                [Page 9]

Internet-Draft      Authenticated Handshake for QUIC           July 2019


   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997, <https://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, <https://www.rfc-
              editor.org/info/rfc2119>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [TLS-ESNI]
              Rescorla, E., Oku, K., Sullivan, N., and C. Wood,
              "Encrypted Server Name Indication for TLS 1.3", draft-
              ietf-tls-esni-03 (work in progress), March 2019.

Appendix A.  Acknowledgements

   TBD

Appendix B.  Change Log

B.1.  Since draft-kazuho-quic-authenticated-handshake-00

   o  Change DCID to Hash(ClientHello) (#8)

   o  Describe attacks (#12)

   o  Describe how Initial packets are mapped to connections (#10)

   o  Clarify the requirements to support split mode (#11)

   o  Version number greasing (#13)

Authors' Addresses

   Kazuho Oku
   Fastly

   Email: kazuhooku@gmail.com








Oku & Huitema            Expires January 6, 2020               [Page 10]

Internet-Draft      Authenticated Handshake for QUIC           July 2019


   Christian Huitema
   Private Octopus Inc.

   Email: huitema@huitema.net















































Oku & Huitema            Expires January 6, 2020               [Page 11]