Skip to main content

Opportunistic TCP-AO with TLS

Document Type Active Internet-Draft (individual)
Authors Maxime Piraux , Olivier Bonaventure , Thomas Wirtgen
Last updated 2023-10-23
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
TCPM                                                           M. Piraux
Internet-Draft                                            O. Bonaventure
Intended status: Experimental                                 T. Wirtgen
Expires: 25 April 2024                                 UCLouvain & WELRI
                                                         23 October 2023

                     Opportunistic TCP-AO with TLS


   This document specifies an opportunistic mode for TCP-AO.  In this
   mode, the TCP connection starts with a well-known authentication key
   which is later replaced by a secure key derived from a TLS handshake.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   tls.html.  Status information for this document may be found at

   Discussion of this document takes place on the TCPM Working Group
   mailing list (, which is archived at  Subscribe at

   Source for this draft and an issue tracker can be found at

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

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

Piraux, et al.            Expires 25 April 2024                 [Page 1]
Internet-Draft                 Opp-TCP-AO                   October 2023

   This Internet-Draft will expire on 25 April 2024.

Copyright Notice

   Copyright (c) 2023 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 (
   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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     2.1.  Notational conventions  . . . . . . . . . . . . . . . . .   3
   3.  An overview of Opportunistic TCP-AO . . . . . . . . . . . . .   3
   4.  Opportunistic TCP-AO  . . . . . . . . . . . . . . . . . . . .   4
     4.1.  The TCPAO TLS Extension . . . . . . . . . . . . . . . . .   4
     4.2.  The initial MKT . . . . . . . . . . . . . . . . . . . . .   5
     4.3.  Derivation of the secure TCP AO MKT . . . . . . . . . . .   6
     4.4.  Current limitations . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Change log  . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Normative References  . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   The TCP Authentication Option (TCP-AO) [RFC5925] provides integrity
   protection for long-lived TCP connections.  It assumes that the
   communicating hosts share a Master Key Tuple (MKT).  This MKT is used
   to derive traffic keys to authenticate the TCP packets exchanged by
   the two hosts.  TCP-AO supports different authentication algorithms

   TCP-AO protects the integrity of all the packets exchanged during a
   TCP connection, including the SYNs.  Such a protection is important
   for some specific services, but many applications would benefit from
   the integrity protection offered by TCP-AO, notably against RST
   attacks that can happen later in the connection.  Unfortunately, from

Piraux, et al.            Expires 25 April 2024                 [Page 2]
Internet-Draft                 Opp-TCP-AO                   October 2023

   a deployment viewpoint, for many applications that use long-lived TCP
   connections, having an existing MKT on the client and the server
   before establishing a connection is a severe limitation.

   This document proposes a way to derive a MKT from the TLS secure
   handshake [RFC8446].  Before the TLS handshake completes, this
   document defines default keys which offer a limited protection to the
   first TCP packets of the connection.  These default keys are then
   replaced by secure keys to protect the integrity of subsequent
   packets past the TLS handshake.  This prevents packet injection
   attacks that could result in the failure of the TLS connection.

   This document is organised as follows.  We provide a brief overview
   of Opportunistic TCP-AO in section Section 3.  Then section Section 4
   discusses the required changes to TCP-AO and TLS.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.1.  Notational conventions

   This document uses network byte order (that is, big endian) values.
   Fields are placed starting from the high-order bits of each byte.

3.  An overview of Opportunistic TCP-AO

   In a nutshell, an opportunistic TCP-AO connection starts like a TCP-
   AO connection, i.e. the SYNs and all subsequent packets are
   authenticated, but using a MKT with a default key specified in this
   document.  After the TLS secure handshake, the communicating hosts
   derive secure keys and update their MKT with these secure keys.
   Thus, the beginning of the connection is not protected against packet
   modifications and packet injection attacks.  The real protection only
   starts once the TLS handshake finishes.  The TCP packets carrying the
   TLS Finished message, and all subsequent TLS records, are protected
   with the secure traffic keys derived from the TLS handshake.

   Figure Figure 1 illustrates the establishment of an opportunistic
   TCP-AO connection.  The client sends a SYN packet using the default
   MKT defined in this document.  The TCP-AO option in the SYN packet
   indicates the use of this default MKT.  The server validates the TCP-
   AO option and replies with an integrity protected SYN+ACK.  The
   client confirms the establishment of the TCP-AO connection with an

Piraux, et al.            Expires 25 April 2024                 [Page 3]
Internet-Draft                 Opp-TCP-AO                   October 2023

   ACK and sends a TLS ClientHello.  This ClientHello contains the AO
   Extension defined in this document.  This extension specifies the
   authentication algorithms that the client wishes to use for the
   connection and whether TCP options should be protected or not.  At
   this point the server can derive the TLS keys and the TCP-AO keys.
   The server replies with TLS ServerHello and TLS EncryptedExtensions
   messages that are sent in packets using the default TCP-AO MKT.  It
   installs the new key in its TCP-AO MKT.  Upon reception of these
   messages, the client can derive the TLS and TCP-AO keys.  It installs
   the TCP-AO keys in its MKT and sends the Finished message protected
   with the new MKT.  All the packets exchanged after the Finished are
   protected using the MKT derived from the secure TLS handshake.

   Client                                   Server
    |            SYN (KeyID=0, RNextID=0)       |
    |          SYN+ACK (KeyID=0, RNextID=0)     |
    |       ACK, TLS ClientHello + AO           |
    |          (KeyID=0, RNextID=0)             |
    |  TLS ServerHello, TLS EncryptedExtensions |
    |          (KeyID=0, RNextID=x)             |
    |              [TLS Finished]               |
    |           (KeyID=x, RNextID=y)            |
    |              [TLS records]                |
    |           (KeyID=y, RNextID=x)            |

      Figure 1: Starting an opportunistic TCP-AO connection with TLS.
      The messages between brackets are authenticated using the TCP-AO
                    MKT derived from the TLS handshake.

4.  Opportunistic TCP-AO

4.1.  The TCPAO TLS Extension

   This document specifies one TLS extension to support the
   opportunistic utilization of TCP-AO with keys derived from the TLS
   secure handshake.  The "tcp_ao" extension can only be placed in the
   ClientHello message.

   enum {
   } ExtensionType;

Piraux, et al.            Expires 25 April 2024                 [Page 4]
Internet-Draft                 Opp-TCP-AO                   October 2023

   The format for the "tcp_ao" extension is defined by:

      enum {
      } TCPAOOptionProt;

      enum {
      } TCPAOAuth;

      enum {
      } TCPAOKDF;

      struct {
         TCPAOOptionProt prot;
         TCPAOAuth auth;
         TCPAOKDF kdf;
      } TCPAO;

   The TCPAOOptionProt indicates whether the client requests integrity
   protection for the TCP options or not.  The TCPAOAuth specifies the
   authentication algorithm defined in [RFC5926] that will be used to
   protect the packets starting from the transmission of the Finished
   message.  The TCPAOKDF specifies the key derivation function defined
   in [RFC5926] and requested by the client to derive the keys from the
   TLS Master Key.

4.2.  The initial MKT

   To support the establishment of opportunistics TCP-AO connections,
   the client and the server must be configured with a default MKT.
   This default MKT is used to authenticate the packets until the
   derivation of the secure MKT from the TLS Master Key. This document
   defines the following default MKT:

   *  TCP connection identifier: selected by the TCP stack.

   *  TCP option flag.  The default MKT assumes that TCP options are not
      included in the MAC calculation.

   *  The current values for the SendID and RecvID are set to 0.

Piraux, et al.            Expires 25 April 2024                 [Page 5]
Internet-Draft                 Opp-TCP-AO                   October 2023

   *  The Master key is set to 0x1cebb1ff.

   *  The default key derivation function is KDF_HMAC_SHA1.

   *  The default message authentication code is HMAC-SHA-1-96.

   Given that the TCP-AO KeyID is a local field and has no global
   meaning, hosts have no guarantee that a KeyID of 0 will be
   unequivocally recognised as designating the default MKT specified in
   this document.  Section 7.5.1 of [RFC5925] indicates that hosts
   receiving SYN segments with TCP-AO enabled and no matching MKT should
   remove the option and accept them.  A client initiating a TCP
   connection in the opportunistic mode of TCP-AO MUST check that the
   server accepted the use of TCP-AO in this mode by replying using the
   default MKT before deriving a secure MKT as described in this

4.3.  Derivation of the secure TCP AO MKT

   The Master key for the MKT to protect the TCP packets after the
   transmission of the Finished messages shall be derived from the TLS
   Master secret using:

    Derive-Secret(Master Secret, "tcpao", ClientHello...server Finished)
       = tcp_ao_secret

   The traffic keys used by the client and the server can then be
   derived from this Master key using the procedures defined in
   [RFC5925] and [RFC5926].

   The client and the server also need to decide on the key identifier
   to use after having sent (for the server) or received (for the
   client) the Finished message.  This is a local decision of each host
   provided that they select a different key identifier than the default
   KeyID of 0.

4.4.  Current limitations

   This version of the document does not specifiy how to do key updates
   for the MKT.  It is left for later versions of this document to fill
   this gap.  One way would be to derive a new tcp_ao_secret from the
   previous tcp_ao_secret and use a new KeyID.  However, this could
   expose the key update event to on-path attackers.  Further guidance
   is required on the severity of this issue and how it could be

Piraux, et al.            Expires 25 April 2024                 [Page 6]
Internet-Draft                 Opp-TCP-AO                   October 2023

   Later versions of this document will also specify the interactions
   between this mode of enabling TCP-AO and other TLS mechanisms, such
   as using pre-shared keys and 0-RTT data, as well as other TCP
   extensions, such as TCP Fast Open.


5.  Security Considerations

   TCP-AO provides a protection against the injection of TCP RST.  This
   can impact legitimate connectionless resets, e.g. when an endpoint
   loses the required state to send TCP-AO segments.  Section 7.7 of
   [RFC5925] provides recommendations to mitigate this effect.

   Using TCP-AO with TLS can also inhibits the triggering of the
   "bad_record_mac" alert that abruptly closes the TLS session when a
   decryption error occurs.  For instance, injected packets will fail
   the TCP-AO authentication and be ignored by the receiver instead.
   This also prevents sessionless resets at the TLS level, and similar
   recommendations as in Section 7.7 of [RFC5925] can apply.

6.  IANA Considerations

   IANA is requested to create a new "Opportunistic TCP-AO with TLS"
   heading for the new registries defined in this section.  New
   registrations under this heading follow the "Specification Required"
   policy of [RFC8126].

   IANA is requested to add the following entries to the existing "TLS
   ExtensionType Values" registry.

    | Value | Extension Name | TLS 1.3 | Recommended | Reference     |
    | TBD   | tcp_ao         | CH      | N           | This document |

                                 Table 1

   Note that "Recommended" is set to N as this extension is intended for
   uses as described in this document.

   IANA is requested to create a new registry "Authentication
   Algorithms" under the "Opportunistic TCP-AO with TLS" heading.

Piraux, et al.            Expires 25 April 2024                 [Page 7]
Internet-Draft                 Opp-TCP-AO                   October 2023

   The registry governs an 8-bit space.  Entries in this registry must
   include a "Algorithm name" field containing a short mnemonic for the
   algorithm.  Its initial content is presented in Section 4.1 in the
   TCPAOAuth enum.  The registry has a "Reference" column.  It is set to
   [RFC5926] for the two initial algorithms.

   IANA is requested to create a new registry "Key Derivation Functions"
   under the "Opportunistic TCP-AO with TLS" heading.

   The registry governs an 8-bit space.  Entries in this registry must
   include a "Key Derivation Function name" field containing a short
   mnemonic for the function.  Its initial content is presented in
   Section 4.1 in the TCPAOKDF enum.  The registry has a "Reference"
   column.  It is set to [RFC5926] for the two initial functions.


   The authors thank Dimitri Safonov for the TCP-AO implementation in

Change log

Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
              June 2010, <>.

   [RFC5926]  Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
              for the TCP Authentication Option (TCP-AO)", RFC 5926,
              DOI 10.17487/RFC5926, June 2010,

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

Piraux, et al.            Expires 25 April 2024                 [Page 8]
Internet-Draft                 Opp-TCP-AO                   October 2023

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,

Authors' Addresses

   Maxime Piraux
   UCLouvain & WELRI

   Olivier Bonaventure
   UCLouvain & WELRI

   Thomas Wirtgen
   UCLouvain & WELRI

Piraux, et al.            Expires 25 April 2024                 [Page 9]