idnits 2.17.1 draft-ietf-taps-transport-security-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (23 April 2020) is 1436 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-27 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-27 == Outdated reference: A later version (-19) exists of draft-ietf-taps-arch-07 == Outdated reference: A later version (-26) exists of draft-ietf-taps-interface-06 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-37 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 8229 (Obsoleted by RFC 9329) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Enghardt 3 Internet-Draft TU Berlin 4 Intended status: Informational T. Pauly 5 Expires: 25 October 2020 Apple Inc. 6 C. Perkins 7 University of Glasgow 8 K. Rose 9 Akamai Technologies, Inc. 10 C.A. Wood 11 Cloudflare 12 23 April 2020 14 A Survey of the Interaction Between Security Protocols and Transport 15 Services 16 draft-ietf-taps-transport-security-12 18 Abstract 20 This document provides a survey of commonly used or notable network 21 security protocols, with a focus on how they interact and integrate 22 with applications and transport protocols. Its goal is to supplement 23 efforts to define and catalog transport services by describing the 24 interfaces required to add security protocols. This survey is not 25 limited to protocols developed within the scope or context of the 26 IETF, and those included represent a superset of features a Transport 27 Services system may need to support. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 25 October 2020. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Transport Security Protocol Descriptions . . . . . . . . . . 6 67 3.1. Application Payload Security Protocols . . . . . . . . . 7 68 3.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.1.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.2. Application-Specific Security Protocols . . . . . . . . . 8 71 3.2.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . 8 72 3.3. Transport-Layer Security Protocols . . . . . . . . . . . 8 73 3.3.1. IETF QUIC . . . . . . . . . . . . . . . . . . . . . . 8 74 3.3.2. Google QUIC . . . . . . . . . . . . . . . . . . . . . 9 75 3.3.3. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . 9 76 3.3.4. MinimaLT . . . . . . . . . . . . . . . . . . . . . . 9 77 3.3.5. CurveCP . . . . . . . . . . . . . . . . . . . . . . . 9 78 3.4. Packet Security Protocols . . . . . . . . . . . . . . . . 9 79 3.4.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . 10 80 3.4.2. WireGuard . . . . . . . . . . . . . . . . . . . . . . 10 81 3.4.3. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . 10 82 4. Transport Dependencies . . . . . . . . . . . . . . . . . . . 10 83 4.1. Reliable Byte-Stream Transports . . . . . . . . . . . . . 10 84 4.2. Unreliable Datagram Transports . . . . . . . . . . . . . 11 85 4.2.1. Datagram Protocols with Defined Byte-Stream 86 Mappings . . . . . . . . . . . . . . . . . . . . . . 11 87 4.3. Transport-Specific Dependencies . . . . . . . . . . . . . 12 88 5. Application Interface . . . . . . . . . . . . . . . . . . . . 12 89 5.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 12 90 5.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 15 91 5.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 16 92 5.4. Summary of Interfaces Exposed by Protocols . . . . . . . 17 93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 95 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 96 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 97 10. Informative References . . . . . . . . . . . . . . . . . . . 19 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 100 1. Introduction 102 Services and features provided by transport protocols have been 103 cataloged in [RFC8095]. This document supplements that work by 104 surveying commonly used and notable network security protocols, and 105 identifying the interfaces between these protocols and both transport 106 protocols and applications. It examines Transport Layer Security 107 (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google 108 QUIC (gQUIC), tcpcrypt, Internet Protocol Security (IPsec), Secure 109 Real-time Transport Protocol (SRTP) with DTLS, WireGuard, CurveCP, 110 and MinimaLT. For each protocol, this document provides a brief 111 description. Then, it describes the interfaces between these 112 protocols and transports in Section 4 and the interfaces between 113 these protocols and applications in Section 5. 115 A Transport Services system exposes an interface for applications to 116 access various (secure) transport protocol features. The security 117 protocols included in this survey represent a superset of 118 functionality and features a Transport Services system may need to 119 support, both internally and externally (via an API) for applications 120 [I-D.ietf-taps-arch]. Ubiquitous IETF protocols such as (D)TLS, as 121 well as non-standard protocols such as gQUIC, are included despite 122 overlapping features. As such, this survey is not limited to 123 protocols developed within the scope or context of the IETF. Outside 124 of this candidate set, protocols that do not offer new features are 125 omitted. For example, newer protocols such as WireGuard make unique 126 design choices that have implications for and limitations on 127 application usage. In contrast, protocols such as SSH [RFC4253], GRE 128 [RFC2890], L2TP [RFC5641], and ALTS [ALTS] are omitted since they do 129 not provide interfaces deemed unique. 131 Authentication-only protocols such as TCP-AO [RFC5925] and IPsec 132 Authentication Header (AH) [RFC4302] are excluded from this survey. 133 TCP-AO adds authentication to long-lived TCP connections, e.g., 134 replay protection with per-packet Message Authentication Codes. 135 (TCP-AO obsoletes TCP MD5 "signature" options specified in 136 [RFC2385].) One primary use case of TCP-AO is for protecting BGP 137 connections. Similarly, AH adds per-datagram authentication and 138 integrity, along with replay protection. Despite these improvements, 139 neither protocol sees general use and both lack critical properties 140 important for emergent transport security protocols, such as 141 confidentiality and privacy protections. Such protocols are thus 142 omitted from this survey. 144 This document only surveys point-to-point protocols; multicast 145 protocols are out of scope. 147 1.1. Goals 149 This survey is intended to help identify the most common interface 150 surfaces between security protocols and transport protocols, and 151 between security protocols and applications. 153 One of the goals of the Transport Services effort is to define a 154 common interface for using transport protocols that allows software 155 using transport protocols to easily adopt new protocols that provide 156 similar feature-sets. The survey of the dependencies security 157 protocols have upon transport protocols can guide implementations in 158 determining which transport protocols are appropriate to be able to 159 use beneath a given security protocol. For example, a security 160 protocol that expects to run over a reliable stream of bytes, like 161 TLS, restricts the set of transport protocols that can be used to 162 those that offer a reliable stream of bytes. 164 Defining the common interfaces that security protocols provide to 165 applications also allows interfaces to be designed in a way that 166 common functionality can use the same APIs. For example, many 167 security protocols that provide authentication let the application be 168 involved in peer identity validation. Any interface to use a secure 169 transport protocol stack thus needs to allow applications to perform 170 this action during connection establishment. 172 1.2. Non-Goals 174 While this survey provides similar analysis to that which was 175 performed for transport protocols in [RFC8095], it is important to 176 distinguish that the use of security protocols requires more 177 consideration. 179 It is not a goal to allow software implementations to automatically 180 switch between different security protocols, even where their 181 interfaces to transport and applications are equivalent. Even 182 between versions, security protocols have subtly different guarantees 183 and vulnerabilities. Thus, any implementation needs to only use the 184 set of protocols and algorithms that are requested by applications or 185 by a system policy. 187 Different security protocols also can use incompatible notions of 188 peer identity and authentication, and cryptographic options. It is 189 not a goal to identify a common set of representations for these 190 concepts. 192 The protocols surveyed in this document represent a superset of 193 functionality and features a Transport Services system may need to 194 support. It does not list all transport protocols that a Transport 195 Services system may need to implement, nor does it mandate that a 196 Transport Service system implement any particular protocol. 198 A Transport Services system may implement any secure transport 199 protocol that provides the described features. In doing so, it may 200 need to expose an interface to the application to configure these 201 features. 203 2. Terminology 205 The following terms are used throughout this document to describe the 206 roles and interactions of transport security protocols (some of which 207 are also defined in [RFC8095]): 209 * Transport Feature: a specific end-to-end feature that the 210 transport layer provides to an application. Examples include 211 confidentiality, reliable delivery, ordered delivery, and message- 212 versus-stream orientation. 214 * Transport Service: a set of Transport Features, without an 215 association to any given framing protocol, which provides 216 functionality to an application. 218 * Transport Services system: a software component that exposes an 219 interface to different Transport Services to an application. 221 * Transport Protocol: an implementation that provides one or more 222 different transport services using a specific framing and header 223 format on the wire. A Transport Protocol services an application, 224 whether directly or in conjunction with a security protocol. 226 * Application: an entity that uses a transport protocol for end-to- 227 end delivery of data across the network. This may also be an 228 upper layer protocol or tunnel encapsulation. 230 * Security Protocol: a defined network protocol that implements one 231 or more security features, such as authentication, encryption, key 232 generation, session resumption, and privacy. Security protocols 233 may be used alongside transport protocols, and in combination with 234 other security protocols when appropriate. 236 * Handshake Protocol: a protocol that enables peers to validate each 237 other and to securely establish shared cryptographic context. 239 * Record: Framed protocol messages. 241 * Record Protocol: a security protocol that allows data to be 242 divided into manageable blocks and protected using shared 243 cryptographic context. 245 * Session: an ephemeral security association between applications. 247 * Connection: the shared state of two or more endpoints that 248 persists across messages that are transmitted between these 249 endpoints. A connection is a transient participant of a session, 250 and a session generally lasts between connection instances. 252 * Peer: an endpoint application party to a session. 254 * Client: the peer responsible for initiating a session. 256 * Server: the peer responsible for responding to a session 257 initiation. 259 3. Transport Security Protocol Descriptions 261 This section contains brief transport and security descriptions of 262 various security protocols currently used to protect data being sent 263 over a network. These protocols are grouped based on where in the 264 protocol stack they are implemented, which influences which parts of 265 a packet they protect: Generic application payload, application 266 payload for specific application-layer protocols, both application 267 payload and transport headers, or entire IP packets. 269 Note that not all security protocols can be easily categorized, e.g., 270 as some protocols can be used in different ways or in combination 271 with other protocols. One major reason for this is that channel 272 security protocols often consist of two components: 274 * A handshake protocol, which is responsible for negotiating 275 parameters, authenticating the endpoints, and establishing shared 276 keys. 278 * A record protocol, which is used to encrypt traffic using keys and 279 parameters provided by the handshake protocol. 281 For some protocols, such as tcpcrypt, these two components are 282 tightly integrated. In contrast, for IPsec, these components are 283 implemented in separate protocols: AH and ESP are record protocols, 284 which can use keys supplied by the handshake protocol IKEv2, by other 285 handshake protocols, or by manual configuration. Moreover, some 286 protocols can be used in different ways: While the base TLS protocol 287 as defined in [RFC8446] has an integrated handshake and record 288 protocol, TLS or DTLS can also be used to negotiate keys for other 289 protocols, as in DTLS-SRTP, or the handshake protocol can be used 290 with a separate record layer, as in QUIC [I-D.ietf-quic-transport]. 292 3.1. Application Payload Security Protocols 294 The following protocols provide security that protects application 295 payloads sent over a transport. They do not specifically protect any 296 headers used for transport-layer functionality. 298 3.1.1. TLS 300 TLS (Transport Layer Security) [RFC8446] is a common protocol used to 301 establish a secure session between two endpoints. Communication over 302 this session "prevents eavesdropping, tampering, and message 303 forgery." TLS consists of a tightly coupled handshake and record 304 protocol. The handshake protocol is used to authenticate peers, 305 negotiate protocol options, such as cryptographic algorithms, and 306 derive session-specific keying material. The record protocol is used 307 to marshal and, once the handshake has sufficiently progressed, 308 encrypt, data from one peer to the other. This data may contain 309 handshake messages or raw application data. 311 3.1.2. DTLS 313 DTLS (Datagram Transport Layer Security) [RFC6347] 314 [I-D.ietf-tls-dtls13] is based on TLS, but differs in that it is 315 designed to run over unreliable datagram protocols like UDP instead 316 of TCP. DTLS modifies the protocol to make sure it can still provide 317 equivalent security guarantees to TLS with the exception of order 318 protection/non-replayability. DTLS was designed to be as similar to 319 TLS as possible, so this document assumes that all properties from 320 TLS are carried over except where specified. 322 3.2. Application-Specific Security Protocols 324 The following protocols provide application-specific security by 325 protecting application payloads used for specific use-cases. Unlike 326 the protocols above, these are not intended for generic application 327 use. 329 3.2.1. Secure RTP 331 Secure RTP (SRTP) is a profile for RTP that provides confidentiality, 332 message authentication, and replay protection for RTP data packets 333 and RTP control protocol (RTCP) packets [RFC3711]. SRTP provides a 334 record layer only, and requires a separate handshake protocol to 335 provide key agreement and identity management. 337 The commonly used handshake protocol for SRTP is DTLS, in the form of 338 DTLS-SRTP [RFC5764]. This is an extension to DTLS that negotiates 339 the use of SRTP as the record layer, and describes how to export keys 340 for use with SRTP. 342 ZRTP [RFC6189] is an alternative key agreement and identity 343 management protocol for SRTP. ZRTP Key agreement is performed using 344 a Diffie-Hellman key exchange that runs on the media path. This 345 generates a shared secret that is then used to generate the master 346 key and salt for SRTP. 348 3.3. Transport-Layer Security Protocols 350 The following security protocols provide protection for both 351 application payloads and headers that are used for transport 352 services. 354 3.3.1. IETF QUIC 356 QUIC is a new standards-track transport protocol that runs over UDP, 357 loosely based on Google's original proprietary gQUIC protocol 358 [I-D.ietf-quic-transport] (See Section 3.3.2 for more details). The 359 QUIC transport layer itself provides support for data confidentiality 360 and integrity. This requires keys to be derived with a separate 361 handshake protocol. A mapping for QUIC of TLS 1.3 362 [I-D.ietf-quic-tls] has been specified to provide this handshake. 364 3.3.2. Google QUIC 366 Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol 367 designed and deployed by Google following experience from deploying 368 SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally 369 known as "QUIC": this document uses gQUIC to unambiguously 370 distinguish it from the standards-track IETF QUIC. The proprietary 371 technical forebear of IETF QUIC, gQUIC was originally designed with 372 tightly-integrated security and application data transport protocols. 374 3.3.3. tcpcrypt 376 Tcpcrypt [RFC8548] is a lightweight extension to the TCP protocol for 377 opportunistic encryption. Applications may use tcpcrypt's unique 378 session ID for further application-level authentication. Absent this 379 authentication, tcpcrypt is vulnerable to active attacks. 381 3.3.4. MinimaLT 383 MinimaLT [MinimaLT] is a UDP-based transport security protocol 384 designed to offer confidentiality, mutual authentication, DoS 385 prevention, and connection mobility. One major goal of the protocol 386 is to leverage existing protocols to obtain server-side configuration 387 information used to more quickly bootstrap a connection. MinimaLT 388 uses a variant of TCP's congestion control algorithm. 390 3.3.5. CurveCP 392 CurveCP [CurveCP] is a UDP-based transport security that, unlike many 393 other security protocols, is based entirely upon public key 394 algorithms. CurveCP provides its own reliability for application 395 data as part of its protocol. 397 3.4. Packet Security Protocols 399 The following protocols provide protection for IP packets. These are 400 generally used as tunnels, such as for Virtual Private Networks 401 (VPNs). Often, applications will not interact directly with these 402 protocols. However, applications that implement tunnels will 403 interact directly with these protocols. 405 3.4.1. IPsec 407 IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec 408 protocol suite that encrypts and authenticates IP packets, either for 409 creating tunnels (tunnel-mode) or for direct transport connections 410 (transport-mode). This suite of protocols separates out the key 411 generation protocol (IKEv2) from the transport encryption protocol 412 (ESP). Each protocol can be used independently, but this document 413 considers them together, since that is the most common pattern. 415 3.4.2. WireGuard 417 WireGuard [WireGuard] is an IP-layer protocol designed as an 418 alternative to IPsec for certain use cases. It uses UDP to 419 encapsulate IP datagrams between peers. Unlike most transport 420 security protocols, which rely on Public Key Infrastructure (PKI) for 421 peer authentication, WireGuard authenticates peers using pre-shared 422 public keys delivered out-of-band, each of which is bound to one or 423 more IP addresses. Moreover, as a protocol suited for VPNs, 424 WireGuard offers no extensibility, negotiation, or cryptographic 425 agility. 427 3.4.3. OpenVPN 429 OpenVPN [OpenVPN] is a commonly used protocol designed as an 430 alternative to IPsec. A major goal of this protocol is to provide a 431 VPN that is simple to configure and works over a variety of 432 transports. OpenVPN encapsulates either IP packets or Ethernet 433 frames within a secure tunnel and can run over either UDP or TCP. 434 For key establishment, OpenVPN can either use TLS as a handshake 435 protocol or use pre-shared keys. 437 4. Transport Dependencies 439 Across the different security protocols listed above, the primary 440 dependency on transport protocols is the presentation of data: either 441 an unbounded stream of bytes, or framed messages. Within protocols 442 that rely on the transport for message framing, most are built to run 443 over transports that inherently provide framing, like UDP, but some 444 also define how their messages can be framed over byte-stream 445 transports. 447 4.1. Reliable Byte-Stream Transports 449 The following protocols all depend upon running on a transport 450 protocol that provides a reliable, in-order stream of bytes. This is 451 typically TCP. 453 Application Payload Security Protocols: 455 * TLS 457 Transport-Layer Security Protocols: 459 * tcpcrypt 461 4.2. Unreliable Datagram Transports 463 The following protocols all depend on the transport protocol to 464 provide message framing to encapsulate their data. These protocols 465 are built to run using UDP, and thus do not have any requirement for 466 reliability. Running these protocols over a protocol that does 467 provide reliability will not break functionality, but may lead to 468 multiple layers of reliability if the security protocol is 469 encapsulating other transport protocol traffic. 471 Application Payload Security Protocols: 473 * DTLS 475 * ZRTP 477 * SRTP 479 Transport-Layer Security Protocols: 481 * QUIC 483 * MinimaLT 485 * CurveCP 487 Packet Security Protocols: 489 * IPsec 491 * WireGuard 493 * OpenVPN 495 4.2.1. Datagram Protocols with Defined Byte-Stream Mappings 497 Of the protocols listed above that depend on the transport for 498 message framing, some do have well-defined mappings for sending their 499 messages over byte-stream transports like TCP. 501 Application Payload Security Protocols: 503 * DTLS when used as a handshake protocol for SRTP [RFC7850] 505 * ZRTP [RFC6189] 507 * SRTP [RFC4571][RFC3711] 509 Packet Security Protocols: 511 * IPsec [RFC8229] 513 4.3. Transport-Specific Dependencies 515 One protocol surveyed, tcpcrypt, has an direct dependency on a 516 feature in the transport that is needed for its functionality. 517 Specifically, tcpcrypt is designed to run on top of TCP, and uses the 518 TCP Encryption Negotiation Option (ENO) [RFC8547] to negotiate its 519 protocol support. 521 QUIC, CurveCP, and MinimaLT provide both transport functionality and 522 security functionality. They depend on running over a framed 523 protocol like UDP, but they add their own layers of reliability and 524 other transport services. Thus, an application that uses one of 525 these protocols cannot decouple the security from transport 526 functionality. 528 5. Application Interface 530 This section describes the interface exposed by the security 531 protocols described above. We partition these interfaces into pre- 532 connection (configuration), connection, and post-connection 533 interfaces, following conventions in [I-D.ietf-taps-interface] and 534 [I-D.ietf-taps-arch]. 536 Note that not all protocols support each interface. The table in 537 Section 5.4 summarizes which protocol exposes which of the 538 interfaces. In the following sections, we provide abbreviations of 539 the interface names to use in the summary table. 541 5.1. Pre-Connection Interfaces 543 Configuration interfaces are used to configure the security protocols 544 before a handshake begins or keys are negotiated. 546 * Identities and Private Keys (IPK): The application can provide its 547 identity, credentials (e.g., certificates), and private keys, or 548 mechanisms to access these, to the security protocol to use during 549 handshakes. 551 - TLS 553 - DTLS 555 - ZRTP 557 - QUIC 559 - MinimaLT 561 - CurveCP 563 - IPsec 565 - WireGuard 567 - OpenVPN 569 * Supported Algorithms (Key Exchange, Signatures, and Ciphersuites) 570 (ALG): The application can choose the algorithms that are 571 supported for key exchange, signatures, and ciphersuites. 573 - TLS 575 - DTLS 577 - ZRTP 579 - QUIC 581 - tcpcrypt 583 - MinimaLT 585 - IPsec 587 - OpenVPN 589 * Extensions (EXT): The application enables or configures extensions 590 that are to be negotiated by the security protocol, such as 591 Application-Layer Protocol Negotiation (ALPN) [RFC7301]. 593 - TLS 594 - DTLS 596 - QUIC 598 * Session Cache Management (CM): The application provides the 599 ability to save and retrieve session state (such as tickets, 600 keying material, and server parameters) that may be used to resume 601 the security session. 603 - TLS 605 - DTLS 607 - ZRTP 609 - QUIC 611 - tcpcrypt 613 - MinimaLT 615 * Authentication Delegation (AD): The application provides access to 616 a separate module that will provide authentication, using 617 Extensible Authentication Protocol (EAP) [RFC3748] for example. 619 - IPsec 621 - tcpcrypt 623 * Pre-Shared Key Import (PSKI): Either the handshake protocol or the 624 application directly can supply pre-shared keys for use in 625 encrypting (and authenticating) communication with a peer. 627 - TLS 629 - DTLS 631 - ZRTP 633 - QUIC 635 - tcpcrypt 637 - MinimaLT 639 - IPsec 641 - WireGuard 642 - OpenVPN 644 5.2. Connection Interfaces 646 * Identity Validation (IV): During a handshake, the security 647 protocol will conduct identity validation of the peer. This can 648 offload validation or occur transparently to the application. 650 - TLS 652 - DTLS 654 - ZRTP 656 - QUIC 658 - MinimaLT 660 - CurveCP 662 - IPsec 664 - WireGuard 666 - OpenVPN 668 * Source Address Validation (SAV): The handshake protocol may 669 interact with the transport protocol or application to validate 670 the address of the remote peer that has sent data. This involves 671 sending a cookie exchange to avoid DoS attacks. (This list omits 672 protocols which depend on TCP and therefore implicitly perform 673 SAV.) 675 - DTLS 677 - QUIC 679 - IPsec 681 - WireGuard 683 5.3. Post-Connection Interfaces 685 * Connection Termination (CT): The security protocol may be 686 instructed to tear down its connection and session information. 687 This is needed by some protocols, e.g., to prevent application 688 data truncation attacks in which an attacker terminates an 689 underlying insecure connection-oriented protocol to terminate the 690 session. 692 - TLS 694 - DTLS 696 - ZRTP 698 - QUIC 700 - tcpcrypt 702 - MinimaLT 704 - IPsec 706 - OpenVPN 708 * Key Update (KU): The handshake protocol may be instructed to 709 update its keying material, either by the application directly or 710 by the record protocol sending a key expiration event. 712 - TLS 714 - DTLS 716 - QUIC 718 - tcpcrypt 720 - MinimaLT 722 - IPsec 724 * Shared Secret Export (PSKE): The handshake protocol may provide an 725 interface for producing shared secrets for application-specific 726 uses. 728 - TLS 730 - DTLS 731 - tcpcrypt 733 - IPsec 735 - OpenVPN 737 - MinimaLT 739 * Key Expiration (KE): The record protocol can signal that its keys 740 are expiring due to reaching a time-based deadline, or a use-based 741 deadline (number of bytes that have been encrypted with the key). 742 This interaction is often limited to signaling between the record 743 layer and the handshake layer. 745 - IPsec 747 * Mobility Events (ME): The record protocol can be signaled that it 748 is being migrated to another transport or interface due to 749 connection mobility, which may reset address and state validation 750 and induce state changes such as use of a new Connection 751 Identifier (CID). 753 - DTLS (version 1.3 only [I-D.ietf-tls-dtls13]) 755 - QUIC 757 - MinimaLT 759 - CurveCP 761 - IPsec [RFC4555] 763 - WireGuard 765 5.4. Summary of Interfaces Exposed by Protocols 767 The following table summarizes which protocol exposes which 768 interface. 770 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ 771 | Protocol |IPK|ALG | EXT |CM|AD| PSKI |IV| SAV |CT|KU| PSKE |KE|ME| 772 +===========+===+====+=====+==+==+======+==+=====+==+==+======+==+==+ 773 | TLS | x | x | x |x | | x |x | |x |x | x | | | 774 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ 775 | DTLS | x | x | x |x | | x |x | x |x |x | x | |x | 776 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ 777 | ZRTP | x | x | |x | | x |x | |x | | | | | 778 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ 779 | QUIC | x | x | x |x | | x |x | x |x |x | | |x | 780 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ 781 | tcpcrypt | | x | |x |x | x | | |x |x | x | | | 782 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ 783 | MinimaLT | x | x | |x | | x |x | |x |x | x | |x | 784 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ 785 | CurveCP | x | | | | | |x | | | | | |x | 786 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ 787 | IPsec | x | x | | |x | x |x | x |x |x | x |x |x | 788 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ 789 | WireGuard | x | | | | | x |x | x | | | | |x | 790 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ 791 | OpenVPN | x | x | | | | x |x | |x | | x | | | 792 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ 794 Table 1 796 x=Interface is exposed (blank)=Interface is not exposed 798 6. IANA Considerations 800 This document has no request to IANA. 802 7. Security Considerations 804 This document summarizes existing transport security protocols and 805 their interfaces. It does not propose changes to or recommend usage 806 of reference protocols. Moreover, no claims of security and privacy 807 properties beyond those guaranteed by the protocols discussed are 808 made. For example, metadata leakage via timing side channels and 809 traffic analysis may compromise any protocol discussed in this 810 survey. Applications using Security Interfaces should take such 811 limitations into consideration when using a particular protocol 812 implementation. 814 8. Privacy Considerations 816 Analysis of how features improve or degrade privacy is intentionally 817 omitted from this survey. All security protocols surveyed generally 818 improve privacy by using encryption to reduce information leakage. 819 However, varying amounts of metadata remain in the clear across each 820 protocol. For example, client and server certificates are sent in 821 cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3 822 [RFC8446]. A survey of privacy features, or lack thereof, for 823 various security protocols could be addressed in a separate document. 825 9. Acknowledgments 827 The authors would like to thank Bob Bradley, Frederic Jacobs, Mirja 828 Kuehlewind, Yannick Sierra, Brian Trammell, and Magnus Westerlund for 829 their input and feedback on this draft. 831 10. Informative References 833 [ALTS] Ghali, C., Stubblefield, A., Knapp, E., Li, J., Schmidt, 834 B., and J. Boeuf, "Application Layer Transport Security", 835 . 838 [CurveCP] Bernstein, D.J., "CurveCP -- Usable security for the 839 Internet", . 841 [I-D.ietf-quic-tls] 842 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 843 Work in Progress, Internet-Draft, draft-ietf-quic-tls-27, 844 21 February 2020, . 847 [I-D.ietf-quic-transport] 848 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 849 and Secure Transport", Work in Progress, Internet-Draft, 850 draft-ietf-quic-transport-27, 21 February 2020, 851 . 854 [I-D.ietf-taps-arch] 855 Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., 856 Perkins, C., Tiesel, P., and C. Wood, "An Architecture for 857 Transport Services", Work in Progress, Internet-Draft, 858 draft-ietf-taps-arch-07, 9 March 2020, 859 . 862 [I-D.ietf-taps-interface] 863 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 864 Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. 865 Pauly, "An Abstract Application Layer Interface to 866 Transport Services", Work in Progress, Internet-Draft, 867 draft-ietf-taps-interface-06, 9 March 2020, 868 . 871 [I-D.ietf-tls-dtls13] 872 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 873 Datagram Transport Layer Security (DTLS) Protocol Version 874 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 875 dtls13-37, 9 March 2020, . 878 [MinimaLT] Petullo, W.M., Zhang, X., Solworth, J.A., Bernstein, D.J., 879 and T. Lange, "MinimaLT -- Minimal-latency Networking 880 Through Better Security", 881 . 883 [OpenVPN] "OpenVPN cryptographic layer", . 886 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 887 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 888 1998, . 890 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 891 RFC 2890, DOI 10.17487/RFC2890, September 2000, 892 . 894 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 895 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 896 RFC 3711, DOI 10.17487/RFC3711, March 2004, 897 . 899 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 900 Levkowetz, Ed., "Extensible Authentication Protocol 901 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 902 . 904 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 905 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 906 January 2006, . 908 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 909 DOI 10.17487/RFC4302, December 2005, 910 . 912 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 913 RFC 4303, DOI 10.17487/RFC4303, December 2005, 914 . 916 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 917 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 918 . 920 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 921 and RTP Control Protocol (RTCP) Packets over Connection- 922 Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 923 2006, . 925 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 926 (TLS) Protocol Version 1.2", RFC 5246, 927 DOI 10.17487/RFC5246, August 2008, 928 . 930 [RFC5641] McGill, N. and C. Pignataro, "Layer 2 Tunneling Protocol 931 Version 3 (L2TPv3) Extended Circuit Status Values", 932 RFC 5641, DOI 10.17487/RFC5641, August 2009, 933 . 935 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 936 Security (DTLS) Extension to Establish Keys for the Secure 937 Real-time Transport Protocol (SRTP)", RFC 5764, 938 DOI 10.17487/RFC5764, May 2010, 939 . 941 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 942 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 943 June 2010, . 945 [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: 946 Media Path Key Agreement for Unicast Secure RTP", 947 RFC 6189, DOI 10.17487/RFC6189, April 2011, 948 . 950 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 951 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 952 January 2012, . 954 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 955 Kivinen, "Internet Key Exchange Protocol Version 2 956 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 957 2014, . 959 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 960 "Transport Layer Security (TLS) Application-Layer Protocol 961 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 962 July 2014, . 964 [RFC7850] Nandakumar, S., "Registering Values of the SDP 'proto' 965 Field for Transporting RTP Media over TCP under Various 966 RTP Profiles", RFC 7850, DOI 10.17487/RFC7850, April 2016, 967 . 969 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 970 Ed., "Services Provided by IETF Transport Protocols and 971 Congestion Control Mechanisms", RFC 8095, 972 DOI 10.17487/RFC8095, March 2017, 973 . 975 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 976 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 977 August 2017, . 979 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 980 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 981 . 983 [RFC8547] Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. 984 Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547, 985 DOI 10.17487/RFC8547, May 2019, 986 . 988 [RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, 989 Q., and E. Smith, "Cryptographic Protection of TCP Streams 990 (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, 991 . 993 [WireGuard] 994 Donenfeld, J.A., "WireGuard -- Next Generation Kernel 995 Network Tunnel", 996 . 998 Authors' Addresses 999 Theresa Enghardt 1000 TU Berlin 1001 Marchstr. 23 1002 10587 Berlin 1003 Germany 1005 Email: ietf@tenghardt.net 1007 Tommy Pauly 1008 Apple Inc. 1009 One Apple Park Way 1010 Cupertino, California 95014, 1011 United States of America 1013 Email: tpauly@apple.com 1015 Colin Perkins 1016 University of Glasgow 1017 School of Computing Science 1018 Glasgow G12 8QQ 1019 United Kingdom 1021 Email: csp@csperkins.org 1023 Kyle Rose 1024 Akamai Technologies, Inc. 1025 150 Broadway 1026 Cambridge, MA 02144, 1027 United States of America 1029 Email: krose@krose.org 1031 Christopher A. Wood 1032 Cloudflare 1033 101 Townsend St 1034 San Francisco, 1035 United States of America 1037 Email: caw@heapingbits.net