Opportunistic TCP-AO with TLS

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 https://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 24 April 2025.¶

Copyright Notice

Copyright (c) 2024 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 (https://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 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

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 [RFC5926].¶

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 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 mechanism can be used to authenticate the TCP transport of BGP sessions when TLS is used to secure their BGP messages as discussed in [CONEXT24].¶

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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "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.¶

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. Then, during the TLS handshake, both endpoints announce the parameters they will use for their MKT. When the TLS handshake completes, they can use their MKT to protect the TCP packets they send and use their peer MKT to verify the TCP packets they receive. 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.¶

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 ACK and sends a TLS ClientHello containing the AO Extension defined in this document. This extension specifies the authentication algorithms that the client will use when sending TCP packets on the connection and whether TCP options will be protected. At this point the server can derive the TLS keys and the TCP-AO keys to use for validating clients packet. The server replies with TLS ServerHello and TLS EncryptedExtensions messages that are sent in packets using the default TCP-AO MKT. To finish the setting up of TCP-AO, the server includes the AO Extension in in the sent EncryptedExtensions to announce the parameters it will use to protect the packets it will send. It then 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 Enc.Extensions + AO |
 |          (KeyID=0, RNextID=x)             |
 |<------------------------------------------|
 |              [TLS Finished]               |
 |           (KeyID=x, RNextID=y)            |
 |------------------------------------------>|
 |              [TLS records]                |
 |           (KeyID=y, RNextID=x)            |
 |<----------------------------------------->|

4. Opportunistic TCP-AO

enum {
    tcp_ao(TBD),
    (65535)
} ExtensionType;

   enum {
      tcp_option_protection_disabled(0),
      tcp_option_protection_enabled(1),
      (255)
   } TCPAOOptionProt;

   enum {
      HMAC-SHA-1-96(0),
      AES-128-CMAC-96(1),
      (255)
   } TCPAOAuth;

   enum {
      KDF_HMAC_SHA1(0),
      KDF_AES_128_CMAC(1),
      (255)
   } TCPAOKDF;

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

struct {
   TCPAO ao;
   uint8 key_id;
} TCPAOKeyExporterContext;

TLS-Exporter("tcp-ao", TCPAOKeyExporterContext, 32)
   = tcp_ao_secret

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 to 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.¶

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

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

Acknowledgments

The authors thank Dimitri Safonov for the TCP-AO implementation in Linux. The authors thank Michael Tüxen, Yoshifumi Nishida and Alessandro Ghedini for their questions and comments on the document during the TCPM meeting at IETF 118.¶

Change log

References

Authors' Addresses