--- 1/draft-ietf-taps-transport-security-10.txt 2020-03-05 06:13:38.304446210 -0800 +++ 2/draft-ietf-taps-transport-security-11.txt 2020-03-05 06:13:38.460450179 -0800 @@ -1,26 +1,26 @@ Network Working Group T. Enghardt Internet-Draft TU Berlin Intended status: Informational T. Pauly -Expires: May 21, 2020 Apple Inc. +Expires: 6 September 2020 Apple Inc. C. Perkins University of Glasgow K. Rose Akamai Technologies, Inc. - C. Wood, Ed. + C.A. Wood, Ed. Apple Inc. - November 18, 2019 + 5 March 2020 A Survey of the Interaction Between Security Protocols and Transport Services - draft-ietf-taps-transport-security-10 + draft-ietf-taps-transport-security-11 Abstract This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog transport services by describing the interfaces required to add security protocols. This survey is not limited to protocols developed within the scope or context of the IETF, and those included represent a superset of features a Transport @@ -34,96 +34,96 @@ 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 May 21, 2020. + This Internet-Draft will expire on 6 September 2020. Copyright Notice - Copyright (c) 2019 IETF Trust and the persons identified as the + Copyright (c) 2020 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 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. + 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Transport Security Protocol Descriptions . . . . . . . . . . 6 3.1. Application Payload Security Protocols . . . . . . . . . 6 3.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.2. Application-Specific Security Protocols . . . . . . . . . 6 - 3.2.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . 6 - 3.2.2. ZRTP for Media Path Key Agreement . . . . . . . . . . 7 + 3.1.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2. Application-Specific Security Protocols . . . . . . . . . 7 + 3.2.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . 7 3.3. Transport-Layer Security Protocols . . . . . . . . . . . 7 - 3.3.1. QUIC with TLS . . . . . . . . . . . . . . . . . . . . 7 - 3.3.2. Google QUIC . . . . . . . . . . . . . . . . . . . . . 7 - 3.3.3. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . 7 - 3.3.4. MinimalT . . . . . . . . . . . . . . . . . . . . . . 7 + 3.3.1. IETF QUIC . . . . . . . . . . . . . . . . . . . . . . 8 + 3.3.2. Google QUIC . . . . . . . . . . . . . . . . . . . . . 8 + 3.3.3. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . 8 + 3.3.4. MinimalT . . . . . . . . . . . . . . . . . . . . . . 8 3.3.5. CurveCP . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.4. Packet Security Protocols . . . . . . . . . . . . . . . . 8 - 3.4.1. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . 8 - 3.4.2. WireGuard . . . . . . . . . . . . . . . . . . . . . . 8 - 3.4.3. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.4. Packet Security Protocols . . . . . . . . . . . . . . . . 9 + 3.4.1. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . 9 + 3.4.2. WireGuard . . . . . . . . . . . . . . . . . . . . . . 9 + 3.4.3. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . 9 4. Transport Dependencies . . . . . . . . . . . . . . . . . . . 9 - 4.1. Reliable Byte-Stream Transports . . . . . . . . . . . . . 9 - 4.2. Unreliable Datagram Transports . . . . . . . . . . . . . 9 - 4.2.1. Datagram Protocols with Defined Byte-Stream Mappings 10 - 4.3. Transport-Specific Dependencies . . . . . . . . . . . . . 10 - 5. Application Interface . . . . . . . . . . . . . . . . . . . . 10 - 5.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 11 - 5.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 13 - 5.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 13 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 - 10. Informative References . . . . . . . . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 + 4.1. Reliable Byte-Stream Transports . . . . . . . . . . . . . 10 + 4.2. Unreliable Datagram Transports . . . . . . . . . . . . . 10 + 4.2.1. Datagram Protocols with Defined Byte-Stream + Mappings . . . . . . . . . . . . . . . . . . . . . . 11 + 4.3. Transport-Specific Dependencies . . . . . . . . . . . . . 11 + 5. Application Interface . . . . . . . . . . . . . . . . . . . . 11 + 5.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 12 + 5.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 14 + 5.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 15 + 5.4. Summary of Interfaces Exposed by Protocols . . . . . . . 16 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 + 10. Informative References . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction Services and features provided by transport protocols have been cataloged in [RFC8095]. This document supplements that work by surveying commonly used and notable network security protocols, and - identifying the services and features a Transport Services system (a - system that provides a transport API) needs to provide in order to - add transport security. It examines Transport Layer Security (TLS), - Datagram Transport Layer Security (DTLS), QUIC + TLS, tcpcrypt, - Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + - ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimalT. For each - protocol, this document provides a brief description, the - dependencies it has on the underlying transports, and the interfaces - provided to applications. + identifying the interfaces between these protocols and both transport + protocols and applications. It examines Transport Layer Security + (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google + QUIC (gQUIC), tcpcrypt, Internet Key Exchange with Encapsulating + Security Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, + CurveCP, and MinimalT. For each protocol, this document provides a + brief description. Then, it describes the interfaces between these + protocols and transports in Section 4 and the interfaces between + these protocols and applications in Section 5. Selected protocols represent a superset of functionality and features a Transport Services system may need to support, both internally and externally (via an API) for applications [I-D.ietf-taps-arch]. Ubiquitous IETF protocols such as (D)TLS, as well as non-standard - protocols such as Google QUIC, are both included despite overlapping + protocols such as gQUIC, are both included despite overlapping features. As such, this survey is not limited to protocols developed within the scope or context of the IETF. Outside of this candidate set, protocols that do not offer new features are omitted. For example, newer protocols such as WireGuard make unique design choices that have implications and limitations on application usage. In contrast, protocols such as ALTS [ALTS] are omitted since they do not provide interfaces deemed unique. Authentication-only protocols such as TCP-AO [RFC5925] and IPsec AH [RFC4302] are excluded from this survey. TCP-AO adds authenticity @@ -175,73 +175,98 @@ between versions, security protocols have subtly different guarantees and vulnerabilities. Thus, any implementation needs to only use the set of protocols and algorithms that are requested by applications or by a system policy. 2. Terminology The following terms are used throughout this document to describe the roles and interactions of transport security protocols: - o Transport Feature: a specific end-to-end feature that the + * Transport Feature: a specific end-to-end feature that the transport layer provides to an application. Examples include confidentiality, reliable delivery, ordered delivery, message- versus-stream orientation, etc. - o Transport Service: a set of Transport Features, without an + * Transport Service: a set of Transport Features, without an association to any given framing protocol, which provides functionality to an application. - o Transport Protocol: an implementation that provides one or more + * Transport Protocol: an implementation that provides one or more different transport services using a specific framing and header format on the wire. A Transport Protocol services an application. - o Application: an entity that uses a transport protocol for end-to- + * Application: an entity that uses a transport protocol for end-to- end delivery of data across the network. This may also be an upper layer protocol or tunnel encapsulation. - o Security Protocol: a defined network protocol that implements one + * Security Protocol: a defined network protocol that implements one or more security features, such as authentication, encryption, key generation, session resumption, and privacy. Security protocols may be used alongside transport protocols, and in combination with other security protocols when appropriate. - o Handshake Protocol: a protocol that enables peers to validate each + * Handshake Protocol: a protocol that enables peers to validate each other and to securely establish shared cryptographic context. - o Record: Framed protocol messages. + * Record: Framed protocol messages. - o Record Protocol: a security protocol that allows data to be + * Record Protocol: a security protocol that allows data to be divided into manageable blocks and protected using shared cryptographic context. - o Session: an ephemeral security association between applications. + * Session: an ephemeral security association between applications. - o Connection: the shared state of two or more endpoints that + * Connection: the shared state of two or more endpoints that persists across messages that are transmitted between these endpoints. A connection is a transient participant of a session, and a session generally lasts between connection instances. - o Peer: an endpoint application party to a session. + * Peer: an endpoint application party to a session. - o Client: the peer responsible for initiating a session. + * Client: the peer responsible for initiating a session. - o Server: the peer responsible for responding to a session + * Server: the peer responsible for responding to a session initiation. 3. Transport Security Protocol Descriptions This section contains brief descriptions of the various security protocols currently used to protect data being sent over a network. - The interfaces between these protocols and transports are described - in Section 4; the interfaces between these protocols and applications - are described in Section 5. + These protocols are grouped based on where in the protocol stack they + are implemented, which influences which parts of a packet they + protect: Generic application payload, application payload for + specific application-layer protocols, both application payload and + transport headers, or entire IP packets. + + Note that not all security protocols can be easily categorized, e.g., + as some protocols can be used in different ways or in combination + with other protocols. One major reason for this is that channel + security protocols often consist of two components: + + * A handshake protocol, which is responsible for negotiating + parameters, authenticating the endpoints, and establishing shared + keys. + + * A record protocol, which is used to encrypt traffic using keys and + parameters provided by the handshake protocol. + + For some protocols, such as tcpcrypt, these two components are + tightly integrated. In contrast, for IPsec, these components are + implemented in separate protocols: AH and ESP are record protocols, + which can use keys supplied by the handshake protocol IKEv2, by other + handshake protocols, or by manual configuration. Moreover, some + protocols can be used in different ways: While the base TLS protocol + as defined in [RFC8446] has an integrated handshake and record + protocol, TLS or DTLS can also be used to negotiate keys for other + protocols, as in DTLS-SRTP, or the handshake protocol can be used + with a separate record layer, as in QUIC. 3.1. Application Payload Security Protocols The following protocols provide security that protects application payloads sent over a transport. They do not specifically protect any headers used for transport-layer functionality. 3.1.1. TLS TLS (Transport Layer Security) [RFC8446] is a common protocol used to @@ -268,38 +293,42 @@ The following protocols provide application-specific security by protecting application payloads used for specific use-cases. Unlike the protocols above, these are not intended for generic application use. 3.2.1. Secure RTP Secure RTP (SRTP) is a profile for RTP that provides confidentiality, message authentication, and replay protection for RTP data packets - and RTP control protocol (RTCP) packets [RFC3711]. + and RTP control protocol (RTCP) packets [RFC3711]. SRTP provides a + record layer only, and requires a separate handshake protocol to + provide key agreement and identity management. -3.2.2. ZRTP for Media Path Key Agreement + The commonly used handshake protocol for SRTP is DTLS, in the form of + DTLS-SRTP [RFC5764]. This is an extension to DTLS that negotiates + the use of SRTP as the record layer, and describes how to export keys + for use with SRTP. - ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It - uses standard SRTP to protect RTP data packets and RTCP packets, but - provides alternative key agreement and identity management protocols. - Key agreement is performed using a Diffie-Hellman key exchange that - runs on the media path. This generates a shared secret that is then - used to generate the master key and salt for SRTP. + ZRTP [RFC6189] is an alternative key agreement and identity + management protocols for SRTP. ZRTP Key agreement is performed using + a Diffie-Hellman key exchange that runs on the media path. This + generates a shared secret that is then used to generate the master + key and salt for SRTP. 3.3. Transport-Layer Security Protocols The following security protocols provide protection for both application payloads and headers that are used for transport services. -3.3.1. QUIC with TLS +3.3.1. IETF QUIC QUIC is a new standards-track transport protocol that runs over UDP, loosely based on Google's original proprietary gQUIC protocol [I-D.ietf-quic-transport] (See Section 3.3.2 for more details). The QUIC transport layer itself provides support for data confidentiality and integrity. This requires keys to be derived with a separate handshake protocol. A mapping for QUIC of TLS 1.3 [I-D.ietf-quic-tls] has been specified to provide this handshake. 3.3.2. Google QUIC @@ -324,25 +353,23 @@ MinimalT is a UDP-based transport security protocol designed to offer confidentiality, mutual authentication, DoS prevention, and connection mobility [MinimalT]. One major goal of the protocol is to leverage existing protocols to obtain server-side configuration information used to more quickly bootstrap a connection. MinimalT uses a variant of TCP's congestion control algorithm. 3.3.5. CurveCP CurveCP [CurveCP] is a UDP-based transport security protocol from - Daniel J. Bernstein. Unlike other security protocols, it is based - entirely upon highly efficient public key algorithms. This removes - many pitfalls associated with nonce reuse and key synchronization. - CurveCP provides its own reliability for application data as part of - its protocol. + Daniel J. Bernstein. Unlike many other security protocols, it is + based entirely upon public key algorithms. CurveCP provides its own + reliability for application data as part of its protocol. 3.4. Packet Security Protocols The following protocols provide protection for IP packets. These are generally used as tunnels, such as for Virtual Private Networks (VPNs). Often, applications will not interact directly with these protocols. However, applications that implement tunnels will interact directly with these protocols. 3.4.1. IKEv2 with ESP @@ -353,323 +380,396 @@ (transport-mode). This suite of protocols separates out the key generation protocol (IKEv2) from the transport encryption protocol (ESP). Each protocol can be used independently, but this document considers them together, since that is the most common pattern. 3.4.2. WireGuard WireGuard is an IP-layer protocol designed as an alternative to IPsec [WireGuard] for certain use cases. It uses UDP to encapsulate IP datagrams between peers. Unlike most transport security protocols, - which rely on PKI for peer authentication, WireGuard authenticates - peers using pre-shared public keys delivered out-of-band, each of - which is bound to one or more IP addresses. Moreover, as a protocol - suited for VPNs, WireGuard offers no extensibility, negotiation, or - cryptographic agility. + which rely on Public Key Infrastructure (PKI) for peer + authentication, WireGuard authenticates peers using pre-shared public + keys delivered out-of-band, each of which is bound to one or more IP + addresses. Moreover, as a protocol suited for VPNs, WireGuard offers + no extensibility, negotiation, or cryptographic agility. 3.4.3. OpenVPN OpenVPN [OpenVPN] is a commonly used protocol designed as an alternative to IPsec. A major goal of this protocol is to provide a VPN that is simple to configure and works over a variety of transports. OpenVPN encapsulates either IP packets or Ethernet - frames within a secure tunnel and can run over UDP or TCP. + frames within a secure tunnel and can run over either UDP or TCP. + For key establishment, OpenVPN can use TLS as a handshake protocol or + pre-shared keys. 4. Transport Dependencies Across the different security protocols listed above, the primary dependency on transport protocols is the presentation of data: either an unbounded stream of bytes, or framed messages. Within protocols that rely on the transport for message framing, most are built to run over transports that inherently provide framing, like UDP, but some also define how their messages can be framed over byte-stream transports. 4.1. Reliable Byte-Stream Transports The following protocols all depend upon running on a transport protocol that provides a reliable, in-order stream of bytes. This is typically TCP. Application Payload Security Protocols: - o TLS + * TLS Transport-Layer Security Protocols: - o tcpcrypt - - Packet Security Protocols: - - o OpenVPN + * tcpcrypt 4.2. Unreliable Datagram Transports The following protocols all depend on the transport protocol to provide message framing to encapsulate their data. These protocols are built to run using UDP, and thus do not have any requirement for reliability. Running these protocols over a protocol that does provide reliability will not break functionality, but may lead to multiple layers of reliability if the security protocol is encapsulating other transport protocol traffic. Application Payload Security Protocols: - o DTLS + * DTLS - o SRTP + * ZRTP - o ZRTP + * SRTP Transport-Layer Security Protocols: - o QUIC + * QUIC - o MinimalT + * MinimalT - o CurveCP + * CurveCP Packet Security Protocols: - o IKEv2 and ESP + * IKEv2 and ESP - o WireGuard + * WireGuard + + * OpenVPN 4.2.1. Datagram Protocols with Defined Byte-Stream Mappings Of the protocols listed above that depend on the transport for message framing, some do have well-defined mappings for sending their messages over byte-stream transports like TCP. Application Payload Security Protocols: - o SRTP [RFC7201] + * DTLS when used as a handshake protocol for SRTP [RFC7850] + + * ZRTP [RFC4571] + + * SRTP [RFC4571] Packet Security Protocols: - o IKEv2 and ESP [RFC8229] + * IKEv2 and ESP [RFC8229] 4.3. Transport-Specific Dependencies One protocol surveyed, tcpcrypt, has an direct dependency on a feature in the transport that is needed for its functionality. Specific, tcpcrypt is designed to run on top of TCP, and uses the TCP Encryption Negotiation Option (ENO) [RFC8547] to negotiate its protocol support. QUIC, CurveCP, and MinimalT provide both transport functionality and security functionality. They have a dependencies on running over a framed protocol like UDP, but they add their own layers of reliability and other transport services. Thus, an application that uses one of these protocols cannot decouple the security from transport functionality. 5. Application Interface This section describes the interface surface exposed by the security - protocols described above. Note that not all protocols support each - interface. We partition these interfaces into pre-connection - (configuration), connection, and post-connection interfaces, - following conventions in [I-D.ietf-taps-interface] and + protocols described above. We partition these interfaces into pre- + connection (configuration), connection, and post-connection + interfaces, following conventions in [I-D.ietf-taps-interface] and [I-D.ietf-taps-arch]. + Note that not all protocols support each interface. The table in + Section 5.4 summarizes which protocol exposes which of the + interfaces. In the following sections, we provide abbreviations of + the interface names to use in the summary table. + 5.1. Pre-Connection Interfaces Configuration interfaces are used to configure the security protocols before a handshake begins or the keys are negotiated. - o Identities and Private Keys: The application can provide its + * Identities and Private Keys (IPK): The application can provide its identities (certificates) and private keys, or mechanisms to access these, to the security protocol to use during handshakes. - * TLS + - TLS - * DTLS + - DTLS - * SRTP + - ZRTP - * QUIC + - QUIC - * MinimalT + - MinimalT - * CurveCP + - CurveCP - * IKEv2 + - IKEv2 - * WireGuard + - WireGuard - o Supported Algorithms (Key Exchange, Signatures, and Ciphersuites): - The application can choose the algorithms that are supported for - key exchange, signatures, and ciphersuites. + - OpenVPN - * TLS + * Supported Algorithms (Key Exchange, Signatures, and Ciphersuites) + (ALG): The application can choose the algorithms that are + supported for key exchange, signatures, and ciphersuites. - * DTLS + - TLS - * SRTP + - DTLS - * QUIC + - ZRTP - * tcpcrypt + - QUIC - * MinimalT + - tcpcrypt - * IKEv2 + - MinimalT - o Extensions (Application-Layer Protocol Negotiation): The + - IKEv2 + + - OpenVPN + + * Extensions (Application-Layer Protocol Negotiation) (EXT): The application enables or configures extensions that are to be negotiated by the security protocol, such as ALPN [RFC7301]. - * TLS + - TLS - * DTLS + - DTLS - * QUIC + - QUIC - o Session Cache Management: The application provides the ability to - save and retrieve session state (such as tickets, keying material, - and server parameters) that may be used to resume the security - session. + * Session Cache Management (CM): The application provides the + ability to save and retrieve session state (such as tickets, + keying material, and server parameters) that may be used to resume + the security session. - * TLS + - TLS - * DTLS + - DTLS - * QUIC + - ZRTP - * MinimalT + - QUIC - o Authentication Delegation: The application provides access to a - separate module that will provide authentication, using EAP for + - tcpcrypt + + - MinimalT + + * Authentication Delegation (AD): The application provides access to + a separate module that will provide authentication, using EAP for example. - * SRTP + - IKEv2 - * IKEv2 + - tcpcrypt - o Pre-Shared Key Import: Either the handshake protocol or the - application directly can supply pre-shared keys for the record - protocol use for encryption/decryption and authentication. If the - application can supply keys directly, this is considered explicit - import; if the handshake protocol traditionally provides the keys - directly, it is considered direct import; if the keys can only be - shared by the handshake, they are considered non-importable. + * Pre-Shared Key Import (PSKI): Either the handshake protocol or the + application directly can supply pre-shared keys for use in + encrypting (and authenticating) communication with a peer. - * Explicit import: QUIC, ESP + - TLS - * Direct import: TLS, DTLS, tcpcrypt, MinimalT, WireGuard + - DTLS - * Non-importable: CurveCP + - ZRTP + + - QUIC + + - ESP + - IKEv2 + + - OpenVPN + + - tcpcrypt + + - MinimalT + + - WireGuard 5.2. Connection Interfaces - o Identity Validation: During a handshake, the security protocol - will conduct identity validation of the peer. This can call into - the application to offload validation. + * Identity Validation (IV): During a handshake, the security + protocol will conduct identity validation of the peer. This can + call into the application to offload validation. - * TLS + - TLS - * DTLS + - DTLS - * SRTP + - ZRTP - * QUIC + - QUIC - * MinimalT + - MinimalT - * CurveCP + - CurveCP - * IKEv2 + - IKEv2 - * WireGuard + - WireGuard - * OpenVPN + - OpenVPN - o Source Address Validation: The handshake protocol may delegate - validation of the remote peer that has sent data to the transport - protocol or application. This involves sending a cookie exchange - to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard + * Source Address Validation (SAV): The handshake protocol may + delegate validation of the remote peer that has sent data to the + transport protocol or application. This involves sending a cookie + exchange to avoid DoS attacks. - * DTLS + - DTLS - * QUIC + - QUIC - * WireGuard + - IKEv2 + + - WireGuard 5.3. Post-Connection Interfaces - o Connection Termination: The security protocol may be instructed to - tear down its connection and session information. This is needed - by some protocols to prevent application data truncation attacks. + * Connection Termination (CT): The security protocol may be + instructed to tear down its connection and session information. + This is needed by some protocols, e.g., to prevent application + data truncation attacks in which an attacker terminates an + underlying insecure connection-oriented protocol to terminate the + session. - * TLS + - TLS - * DTLS + - DTLS - * QUIC + - ZRTP - * tcpcrypt - * MinimalT + - QUIC - * IKEv2 + - tcpcrypt - o Key Update: The handshake protocol may be instructed to update its - keying material, either by the application directly or by the - record protocol sending a key expiration event. + - MinimalT - * TLS + - IKEv2 - * DTLS + - OpenVPN - * QUIC + * Key Update (KU): The handshake protocol may be instructed to + update its keying material, either by the application directly or + by the record protocol sending a key expiration event. - * tcpcrypt + - TLS - * MinimalT + - DTLS - * IKEv2 + - QUIC - o Pre-Shared Key Export: The handshake protocol will generate one or - more keys to be used for record encryption/decryption and - authentication. These may be explicitly exportable to the - application, traditionally limited to direct export to the record - protocol, or inherently non-exportable because the keys must be - used directly in conjunction with the record protocol. + - tcpcrypt - * Explicit export: TLS (for QUIC), DTLS (for SRTP), tcpcrypt, - IKEv2 + - MinimalT - * Direct export: TLS, DTLS, MinimalT + - IKEv2 - * Non-exportable: CurveCP + * Shared Secret Export (PSKE): The handshake protocol may provide an + interface for producing shared secrets for application-specific + uses. - o Key Expiration: The record protocol can signal that its keys are - expiring due to reaching a time-based deadline, or a use-based + - TLS + + - DTLS + - tcpcrypt + + - IKEv2 + + - OpenVPN + + - MinimalT + + * Key Expiration (KE): The record protocol can signal that its keys + are expiring due to reaching a time-based deadline, or a use-based deadline (number of bytes that have been encrypted with the key). This interaction is often limited to signaling between the record layer and the handshake layer. - * ESP + - ESP - o Mobility Events: The record protocol can be signaled that it is - being migrated to another transport or interface due to connection - mobility, which may reset address and state validation and induce - state changes such as use of a new Connection Identifier (CID). + * Mobility Events (ME): The record protocol can be signaled that it + is being migrated to another transport or interface due to + connection mobility, which may reset address and state validation + and induce state changes such as use of a new Connection + Identifier (CID). - * QUIC - * MinimalT + - QUIC - * CurveCP + - MinimalT - * ESP + - CurveCP - * WireGuard + - IKEv2 [RFC4555] + + - WireGuard + +5.4. Summary of Interfaces Exposed by Protocols + + The following table summarizes which protocol exposes which + interface. + + +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ + | Protocol |IPK|ALG | EXT |CM|AD| PSKI |IV| SAV |CT|KU| PSKE |KE|ME| + +===========+===+====+=====+==+==+======+==+=====+==+==+======+==+==+ + | TLS | x | x | x |x | | x |x | |x |x | x | | | + +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ + | DTLS | x | x | x |x | | x |x | x |x |x | x | | | + +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ + | ZRTP | x | x | |x | | x |x | |x | | | | | + +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ + | QUIC | x | x | x |x | | x |x | x |x |x | | |x | + +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ + | tcpcrypt | | x | |x |x | x | | |x |x | x | | | + +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ + | MinimalT | x | x | |x | | x |x | |x |x | x | |x | + +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ + | CurveCP | x | | | | | |x | | | | | |x | + +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ + | IKEv2 | x | x | | |x | x |x | x |x |x | x | |x | + +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ + | ESP | | | | | | x | | | | | |x | | + +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ + | WireGuard | x | | | | | x |x | x | | | | |x | + +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ + | OpenVPN | x | x | | | | x |x | |x | | x | | | + +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ + + Table 1 + + x=Interface is exposed (blank)=Interface is not exposed 6. IANA Considerations This document has no request to IANA. 7. Security Considerations This document summarizes existing transport security protocols and their interfaces. It does not propose changes to or recommend usage of reference protocols. Moreover, no claims of security and privacy @@ -697,49 +797,56 @@ Kuehlewind, Yannick Sierra, Brian Trammell, and Magnus Westerlund for their input and feedback on this draft. 10. Informative References [ALTS] Ghali, C., Stubblefield, A., Knapp, E., Li, J., Schmidt, B., and J. Boeuf, "Application Layer Transport Security", . - [CurveCP] Bernstein, D., "CurveCP -- Usable security for the + [CurveCP] Bernstein, D.J., "CurveCP -- Usable security for the Internet", . [I-D.ietf-quic-tls] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", - draft-ietf-quic-tls-23 (work in progress), September 2019. + Work in Progress, Internet-Draft, draft-ietf-quic-tls-27, + 21 February 2020, . [I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed - and Secure Transport", draft-ietf-quic-transport-23 (work - in progress), September 2019. + and Secure Transport", Work in Progress, Internet-Draft, + draft-ietf-quic-transport-27, 21 February 2020, + . [I-D.ietf-taps-arch] Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., Perkins, C., Tiesel, P., and C. Wood, "An Architecture for - Transport Services", draft-ietf-taps-arch-04 (work in - progress), July 2019. + Transport Services", Work in Progress, Internet-Draft, + draft-ietf-taps-arch-06, 23 December 2019, + . [I-D.ietf-taps-interface] Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. Pauly, "An Abstract Application Layer Interface to - Transport Services", draft-ietf-taps-interface-04 (work in - progress), July 2019. + Transport Services", Work in Progress, Internet-Draft, + draft-ietf-taps-interface-05, 4 November 2019, + . - [MinimalT] - Petullo, W., Zhang, X., Solworth, J., Bernstein, D., and - T. Lange, "MinimaLT -- Minimal-latency Networking Through - Better Security", + [MinimalT] Petullo, W.M., Zhang, X., Solworth, J.A., Bernstein, D.J., + and T. Lange, "MinimaLT -- Minimal-latency Networking + Through Better Security", . [OpenVPN] "OpenVPN cryptographic layer", . [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 1998, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. @@ -748,52 +855,68 @@ . [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . + [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol + (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, + . + + [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) + and RTP Control Protocol (RTCP) Packets over Connection- + Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July + 2006, . + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . + [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer + Security (DTLS) Extension to Establish Keys for the Secure + Real-time Transport Protocol (SRTP)", RFC 5764, + DOI 10.17487/RFC5764, May 2010, + . + [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: Media Path Key Agreement for Unicast Secure RTP", RFC 6189, DOI 10.17487/RFC6189, April 2011, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . - [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP - Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, - . - [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, . + [RFC7850] Nandakumar, S., "Registering Values of the SDP 'proto' + Field for Transporting RTP Media over TCP under Various + RTP Profiles", RFC 7850, DOI 10.17487/RFC7850, April 2016, + . + [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed., "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms", RFC 8095, DOI 10.17487/RFC8095, March 2017, . [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, August 2017, . @@ -805,38 +928,38 @@ Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547, DOI 10.17487/RFC8547, May 2019, . [RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, Q., and E. Smith, "Cryptographic Protection of TCP Streams (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, . [WireGuard] - Donenfeld, J., "WireGuard -- Next Generation Kernel + Donenfeld, J.A., "WireGuard -- Next Generation Kernel Network Tunnel", . Authors' Addresses Theresa Enghardt TU Berlin Marchstr. 23 10587 Berlin Germany - Email: theresa@inet.tu-berlin.de + Email: ietf@tenghardt.net Tommy Pauly Apple Inc. One Apple Park Way - Cupertino, California 95014 + Cupertino, California 95014, United States of America Email: tpauly@apple.com Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom @@ -834,25 +957,26 @@ Email: tpauly@apple.com Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom Email: csp@csperkins.org + Kyle Rose Akamai Technologies, Inc. 150 Broadway - Cambridge, MA 02144 + Cambridge, MA 02144, United States of America Email: krose@krose.org Christopher A. Wood (editor) Apple Inc. One Apple Park Way - Cupertino, California 95014 + Cupertino, California 95014, United States of America Email: cawood@apple.com