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