idnits 2.17.1
draft-ietf-taps-transport-security-11.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 (5 March 2020) is 1506 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-06
== Outdated reference: A later version (-26) exists of
draft-ietf-taps-interface-05
-- 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 (~~), 5 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: 6 September 2020 Apple Inc.
6 C. Perkins
7 University of Glasgow
8 K. Rose
9 Akamai Technologies, Inc.
10 C.A. Wood, Ed.
11 Apple Inc.
12 5 March 2020
14 A Survey of the Interaction Between Security Protocols and Transport
15 Services
16 draft-ietf-taps-transport-security-11
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 6 September 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
66 3. Transport Security Protocol Descriptions . . . . . . . . . . 6
67 3.1. Application Payload Security Protocols . . . . . . . . . 6
68 3.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 6
69 3.1.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . 7
70 3.2. Application-Specific Security Protocols . . . . . . . . . 7
71 3.2.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . 7
72 3.3. Transport-Layer Security Protocols . . . . . . . . . . . 7
73 3.3.1. IETF QUIC . . . . . . . . . . . . . . . . . . . . . . 8
74 3.3.2. Google QUIC . . . . . . . . . . . . . . . . . . . . . 8
75 3.3.3. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . 8
76 3.3.4. MinimalT . . . . . . . . . . . . . . . . . . . . . . 8
77 3.3.5. CurveCP . . . . . . . . . . . . . . . . . . . . . . . 8
78 3.4. Packet Security Protocols . . . . . . . . . . . . . . . . 9
79 3.4.1. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . 9
80 3.4.2. WireGuard . . . . . . . . . . . . . . . . . . . . . . 9
81 3.4.3. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . 9
82 4. Transport Dependencies . . . . . . . . . . . . . . . . . . . 9
83 4.1. Reliable Byte-Stream Transports . . . . . . . . . . . . . 10
84 4.2. Unreliable Datagram Transports . . . . . . . . . . . . . 10
85 4.2.1. Datagram Protocols with Defined Byte-Stream
86 Mappings . . . . . . . . . . . . . . . . . . . . . . 11
87 4.3. Transport-Specific Dependencies . . . . . . . . . . . . . 11
88 5. Application Interface . . . . . . . . . . . . . . . . . . . . 11
89 5.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 12
90 5.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 14
91 5.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 15
92 5.4. Summary of Interfaces Exposed by Protocols . . . . . . . 16
93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
95 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
96 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
97 10. Informative References . . . . . . . . . . . . . . . . . . . 18
98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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 Key Exchange with Encapsulating
109 Security Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard,
110 CurveCP, and MinimalT. For each protocol, this document provides a
111 brief 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 Selected protocols represent a superset of functionality and features
116 a Transport Services system may need to support, both internally and
117 externally (via an API) for applications [I-D.ietf-taps-arch].
118 Ubiquitous IETF protocols such as (D)TLS, as well as non-standard
119 protocols such as gQUIC, are both included despite overlapping
120 features. As such, this survey is not limited to protocols developed
121 within the scope or context of the IETF. Outside of this candidate
122 set, protocols that do not offer new features are omitted. For
123 example, newer protocols such as WireGuard make unique design choices
124 that have implications and limitations on application usage. In
125 contrast, protocols such as ALTS [ALTS] are omitted since they do not
126 provide interfaces deemed unique.
128 Authentication-only protocols such as TCP-AO [RFC5925] and IPsec AH
129 [RFC4302] are excluded from this survey. TCP-AO adds authenticity
130 protections to long-lived TCP connections, e.g., replay protection
131 with per-packet Message Authentication Codes. (This protocol
132 obsoletes TCP MD5 "signature" options specified in [RFC2385].) One
133 prime use case of TCP-AO is for protecting BGP connections.
134 Similarly, AH adds per-datagram authenticity and adds similar replay
135 protection. Despite these improvements, neither protocol sees
136 general use and both lack critical properties important for emergent
137 transport security protocols: confidentiality, privacy protections,
138 and agility. Such protocols are thus omitted from this survey.
140 1.1. Goals
142 This survey is intended to help identify the most common interface
143 surfaces between security protocols and transport protocols, and
144 between security protocols and applications.
146 One of the goals of Transport Services is to define a common
147 interface for using transport protocols that allows software using
148 transport protocols to easily adopt new protocols that provide
149 similar feature-sets. The survey of the dependencies security
150 protocols have upon transport protocols can guide implementations in
151 determining which transport protocols are appropriate to be able to
152 use beneath a given security protocol. For example, a security
153 protocol that expects to run over a reliable stream of bytes, like
154 TLS, restrict the set of transport protocols that can be used to
155 those that offer a reliable stream of bytes.
157 Defining the common interfaces that security protocols provide to
158 applications also allows interfaces to be designed in a way that
159 common functionality can use the same APIs. For example, many
160 security protocols that provide authentication let the application be
161 involved in peer identity validation. Any interface to use a secure
162 transport protocol stack thus needs to allow applications to perform
163 this action during connection establishment.
165 1.2. Non-Goals
167 While this survey provides similar analysis to that which was
168 performed for transport protocols in [RFC8095], it is important to
169 distinguish that the use of security protocols requires more
170 consideration.
172 It is not a goal to allow software implementations to automatically
173 switch between different security protocols, even where their
174 interfaces to transport and applications are equivalent. Even
175 between versions, security protocols have subtly different guarantees
176 and vulnerabilities. Thus, any implementation needs to only use the
177 set of protocols and algorithms that are requested by applications or
178 by a system policy.
180 2. Terminology
182 The following terms are used throughout this document to describe the
183 roles and interactions of transport security protocols:
185 * Transport Feature: a specific end-to-end feature that the
186 transport layer provides to an application. Examples include
187 confidentiality, reliable delivery, ordered delivery, message-
188 versus-stream orientation, etc.
190 * Transport Service: a set of Transport Features, without an
191 association to any given framing protocol, which provides
192 functionality to an application.
194 * Transport Protocol: an implementation that provides one or more
195 different transport services using a specific framing and header
196 format on the wire. A Transport Protocol services an application.
198 * Application: an entity that uses a transport protocol for end-to-
199 end delivery of data across the network. This may also be an
200 upper layer protocol or tunnel encapsulation.
202 * Security Protocol: a defined network protocol that implements one
203 or more security features, such as authentication, encryption, key
204 generation, session resumption, and privacy. Security protocols
205 may be used alongside transport protocols, and in combination with
206 other security protocols when appropriate.
208 * Handshake Protocol: a protocol that enables peers to validate each
209 other and to securely establish shared cryptographic context.
211 * Record: Framed protocol messages.
213 * Record Protocol: a security protocol that allows data to be
214 divided into manageable blocks and protected using shared
215 cryptographic context.
217 * Session: an ephemeral security association between applications.
219 * Connection: the shared state of two or more endpoints that
220 persists across messages that are transmitted between these
221 endpoints. A connection is a transient participant of a session,
222 and a session generally lasts between connection instances.
224 * Peer: an endpoint application party to a session.
226 * Client: the peer responsible for initiating a session.
228 * Server: the peer responsible for responding to a session
229 initiation.
231 3. Transport Security Protocol Descriptions
233 This section contains brief descriptions of the various security
234 protocols currently used to protect data being sent over a network.
235 These protocols are grouped based on where in the protocol stack they
236 are implemented, which influences which parts of a packet they
237 protect: Generic application payload, application payload for
238 specific application-layer protocols, both application payload and
239 transport headers, or entire IP packets.
241 Note that not all security protocols can be easily categorized, e.g.,
242 as some protocols can be used in different ways or in combination
243 with other protocols. One major reason for this is that channel
244 security protocols often consist of two components:
246 * A handshake protocol, which is responsible for negotiating
247 parameters, authenticating the endpoints, and establishing shared
248 keys.
250 * A record protocol, which is used to encrypt traffic using keys and
251 parameters provided by the handshake protocol.
253 For some protocols, such as tcpcrypt, these two components are
254 tightly integrated. In contrast, for IPsec, these components are
255 implemented in separate protocols: AH and ESP are record protocols,
256 which can use keys supplied by the handshake protocol IKEv2, by other
257 handshake protocols, or by manual configuration. Moreover, some
258 protocols can be used in different ways: While the base TLS protocol
259 as defined in [RFC8446] has an integrated handshake and record
260 protocol, TLS or DTLS can also be used to negotiate keys for other
261 protocols, as in DTLS-SRTP, or the handshake protocol can be used
262 with a separate record layer, as in QUIC.
264 3.1. Application Payload Security Protocols
266 The following protocols provide security that protects application
267 payloads sent over a transport. They do not specifically protect any
268 headers used for transport-layer functionality.
270 3.1.1. TLS
272 TLS (Transport Layer Security) [RFC8446] is a common protocol used to
273 establish a secure session between two endpoints. Communication over
274 this session "prevents eavesdropping, tampering, and message
275 forgery." TLS consists of a tightly coupled handshake and record
276 protocol. The handshake protocol is used to authenticate peers,
277 negotiate protocol options, such as cryptographic algorithms, and
278 derive session-specific keying material. The record protocol is used
279 to marshal (possibly encrypted) data from one peer to the other.
280 This data may contain handshake messages or raw application data.
282 3.1.2. DTLS
284 DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS,
285 but differs in that it is designed to run over unreliable datagram
286 protocols like UDP instead of TCP. DTLS modifies the protocol to
287 make sure it can still provide the same security guarantees as TLS
288 even without reliability from the transport. DTLS was designed to be
289 as similar to TLS as possible, so this document assumes that all
290 properties from TLS are carried over except where specified.
292 3.2. Application-Specific Security Protocols
294 The following protocols provide application-specific security by
295 protecting application payloads used for specific use-cases. Unlike
296 the protocols above, these are not intended for generic application
297 use.
299 3.2.1. Secure RTP
301 Secure RTP (SRTP) is a profile for RTP that provides confidentiality,
302 message authentication, and replay protection for RTP data packets
303 and RTP control protocol (RTCP) packets [RFC3711]. SRTP provides a
304 record layer only, and requires a separate handshake protocol to
305 provide key agreement and identity management.
307 The commonly used handshake protocol for SRTP is DTLS, in the form of
308 DTLS-SRTP [RFC5764]. This is an extension to DTLS that negotiates
309 the use of SRTP as the record layer, and describes how to export keys
310 for use with SRTP.
312 ZRTP [RFC6189] is an alternative key agreement and identity
313 management protocols for SRTP. ZRTP Key agreement is performed using
314 a Diffie-Hellman key exchange that runs on the media path. This
315 generates a shared secret that is then used to generate the master
316 key and salt for SRTP.
318 3.3. Transport-Layer Security Protocols
320 The following security protocols provide protection for both
321 application payloads and headers that are used for transport
322 services.
324 3.3.1. IETF QUIC
326 QUIC is a new standards-track transport protocol that runs over UDP,
327 loosely based on Google's original proprietary gQUIC protocol
328 [I-D.ietf-quic-transport] (See Section 3.3.2 for more details). The
329 QUIC transport layer itself provides support for data confidentiality
330 and integrity. This requires keys to be derived with a separate
331 handshake protocol. A mapping for QUIC of TLS 1.3
332 [I-D.ietf-quic-tls] has been specified to provide this handshake.
334 3.3.2. Google QUIC
336 Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol
337 designed and deployed by Google following experience from deploying
338 SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally
339 known as "QUIC": this document uses gQUIC to unambiguously
340 distinguish it from the standards-track IETF QUIC. The proprietary
341 technical forebear of IETF QUIC, gQUIC was originally designed with
342 tightly-integrated security and application data transport protocols.
344 3.3.3. tcpcrypt
346 Tcpcrypt [RFC8548] is a lightweight extension to the TCP protocol for
347 opportunistic encryption. Applications may use tcpcrypt's unique
348 session ID for further application-level authentication. Absent this
349 authentication, tcpcrypt is vulnerable to active attacks.
351 3.3.4. MinimalT
353 MinimalT is a UDP-based transport security protocol designed to offer
354 confidentiality, mutual authentication, DoS prevention, and
355 connection mobility [MinimalT]. One major goal of the protocol is to
356 leverage existing protocols to obtain server-side configuration
357 information used to more quickly bootstrap a connection. MinimalT
358 uses a variant of TCP's congestion control algorithm.
360 3.3.5. CurveCP
362 CurveCP [CurveCP] is a UDP-based transport security protocol from
363 Daniel J. Bernstein. Unlike many other security protocols, it is
364 based entirely upon public key algorithms. CurveCP provides its own
365 reliability for application data as part of its protocol.
367 3.4. Packet Security Protocols
369 The following protocols provide protection for IP packets. These are
370 generally used as tunnels, such as for Virtual Private Networks
371 (VPNs). Often, applications will not interact directly with these
372 protocols. However, applications that implement tunnels will
373 interact directly with these protocols.
375 3.4.1. IKEv2 with ESP
377 IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec
378 protocol suite that encrypts and authenticates IP packets, either for
379 creating tunnels (tunnel-mode) or for direct transport connections
380 (transport-mode). This suite of protocols separates out the key
381 generation protocol (IKEv2) from the transport encryption protocol
382 (ESP). Each protocol can be used independently, but this document
383 considers them together, since that is the most common pattern.
385 3.4.2. WireGuard
387 WireGuard is an IP-layer protocol designed as an alternative to IPsec
388 [WireGuard] for certain use cases. It uses UDP to encapsulate IP
389 datagrams between peers. Unlike most transport security protocols,
390 which rely on Public Key Infrastructure (PKI) for peer
391 authentication, WireGuard authenticates peers using pre-shared public
392 keys delivered out-of-band, each of which is bound to one or more IP
393 addresses. Moreover, as a protocol suited for VPNs, WireGuard offers
394 no extensibility, negotiation, or cryptographic agility.
396 3.4.3. OpenVPN
398 OpenVPN [OpenVPN] is a commonly used protocol designed as an
399 alternative to IPsec. A major goal of this protocol is to provide a
400 VPN that is simple to configure and works over a variety of
401 transports. OpenVPN encapsulates either IP packets or Ethernet
402 frames within a secure tunnel and can run over either UDP or TCP.
403 For key establishment, OpenVPN can use TLS as a handshake protocol or
404 pre-shared keys.
406 4. Transport Dependencies
408 Across the different security protocols listed above, the primary
409 dependency on transport protocols is the presentation of data: either
410 an unbounded stream of bytes, or framed messages. Within protocols
411 that rely on the transport for message framing, most are built to run
412 over transports that inherently provide framing, like UDP, but some
413 also define how their messages can be framed over byte-stream
414 transports.
416 4.1. Reliable Byte-Stream Transports
418 The following protocols all depend upon running on a transport
419 protocol that provides a reliable, in-order stream of bytes. This is
420 typically TCP.
422 Application Payload Security Protocols:
424 * TLS
426 Transport-Layer Security Protocols:
428 * tcpcrypt
430 4.2. Unreliable Datagram Transports
432 The following protocols all depend on the transport protocol to
433 provide message framing to encapsulate their data. These protocols
434 are built to run using UDP, and thus do not have any requirement for
435 reliability. Running these protocols over a protocol that does
436 provide reliability will not break functionality, but may lead to
437 multiple layers of reliability if the security protocol is
438 encapsulating other transport protocol traffic.
440 Application Payload Security Protocols:
442 * DTLS
444 * ZRTP
446 * SRTP
448 Transport-Layer Security Protocols:
450 * QUIC
452 * MinimalT
454 * CurveCP
456 Packet Security Protocols:
458 * IKEv2 and ESP
460 * WireGuard
462 * OpenVPN
464 4.2.1. Datagram Protocols with Defined Byte-Stream Mappings
466 Of the protocols listed above that depend on the transport for
467 message framing, some do have well-defined mappings for sending their
468 messages over byte-stream transports like TCP.
470 Application Payload Security Protocols:
472 * DTLS when used as a handshake protocol for SRTP [RFC7850]
474 * ZRTP [RFC4571]
476 * SRTP [RFC4571]
478 Packet Security Protocols:
480 * IKEv2 and ESP [RFC8229]
482 4.3. Transport-Specific Dependencies
484 One protocol surveyed, tcpcrypt, has an direct dependency on a
485 feature in the transport that is needed for its functionality.
486 Specific, tcpcrypt is designed to run on top of TCP, and uses the TCP
487 Encryption Negotiation Option (ENO) [RFC8547] to negotiate its
488 protocol support.
490 QUIC, CurveCP, and MinimalT provide both transport functionality and
491 security functionality. They have a dependencies on running over a
492 framed protocol like UDP, but they add their own layers of
493 reliability and other transport services. Thus, an application that
494 uses one of these protocols cannot decouple the security from
495 transport functionality.
497 5. Application Interface
499 This section describes the interface surface exposed by the security
500 protocols described above. We partition these interfaces into pre-
501 connection (configuration), connection, and post-connection
502 interfaces, following conventions in [I-D.ietf-taps-interface] and
503 [I-D.ietf-taps-arch].
505 Note that not all protocols support each interface. The table in
506 Section 5.4 summarizes which protocol exposes which of the
507 interfaces. In the following sections, we provide abbreviations of
508 the interface names to use in the summary table.
510 5.1. Pre-Connection Interfaces
512 Configuration interfaces are used to configure the security protocols
513 before a handshake begins or the keys are negotiated.
515 * Identities and Private Keys (IPK): The application can provide its
516 identities (certificates) and private keys, or mechanisms to
517 access these, to the security protocol to use during handshakes.
519 - TLS
521 - DTLS
523 - ZRTP
525 - QUIC
527 - MinimalT
529 - CurveCP
531 - IKEv2
533 - WireGuard
535 - OpenVPN
537 * Supported Algorithms (Key Exchange, Signatures, and Ciphersuites)
538 (ALG): The application can choose the algorithms that are
539 supported for key exchange, signatures, and ciphersuites.
541 - TLS
543 - DTLS
545 - ZRTP
547 - QUIC
549 - tcpcrypt
551 - MinimalT
553 - IKEv2
555 - OpenVPN
557 * Extensions (Application-Layer Protocol Negotiation) (EXT): The
558 application enables or configures extensions that are to be
559 negotiated by the security protocol, such as ALPN [RFC7301].
561 - TLS
563 - DTLS
565 - QUIC
567 * Session Cache Management (CM): The application provides the
568 ability to save and retrieve session state (such as tickets,
569 keying material, and server parameters) that may be used to resume
570 the security session.
572 - TLS
574 - DTLS
576 - ZRTP
578 - QUIC
580 - tcpcrypt
582 - MinimalT
584 * Authentication Delegation (AD): The application provides access to
585 a separate module that will provide authentication, using EAP for
586 example.
588 - IKEv2
590 - tcpcrypt
592 * Pre-Shared Key Import (PSKI): Either the handshake protocol or the
593 application directly can supply pre-shared keys for use in
594 encrypting (and authenticating) communication with a peer.
596 - TLS
598 - DTLS
600 - ZRTP
602 - QUIC
604 - ESP
605 - IKEv2
607 - OpenVPN
609 - tcpcrypt
611 - MinimalT
613 - WireGuard
615 5.2. Connection Interfaces
617 * Identity Validation (IV): During a handshake, the security
618 protocol will conduct identity validation of the peer. This can
619 call into the application to offload validation.
621 - TLS
623 - DTLS
625 - ZRTP
627 - QUIC
629 - MinimalT
631 - CurveCP
633 - IKEv2
635 - WireGuard
637 - OpenVPN
639 * Source Address Validation (SAV): The handshake protocol may
640 delegate validation of the remote peer that has sent data to the
641 transport protocol or application. This involves sending a cookie
642 exchange to avoid DoS attacks.
644 - DTLS
646 - QUIC
648 - IKEv2
650 - WireGuard
652 5.3. Post-Connection Interfaces
654 * Connection Termination (CT): The security protocol may be
655 instructed to tear down its connection and session information.
656 This is needed by some protocols, e.g., to prevent application
657 data truncation attacks in which an attacker terminates an
658 underlying insecure connection-oriented protocol to terminate the
659 session.
661 - TLS
663 - DTLS
665 - ZRTP
667 - QUIC
669 - tcpcrypt
671 - MinimalT
673 - IKEv2
675 - OpenVPN
677 * Key Update (KU): The handshake protocol may be instructed to
678 update its keying material, either by the application directly or
679 by the record protocol sending a key expiration event.
681 - TLS
683 - DTLS
685 - QUIC
687 - tcpcrypt
689 - MinimalT
691 - IKEv2
693 * Shared Secret Export (PSKE): The handshake protocol may provide an
694 interface for producing shared secrets for application-specific
695 uses.
697 - TLS
699 - DTLS
700 - tcpcrypt
702 - IKEv2
704 - OpenVPN
706 - MinimalT
708 * Key Expiration (KE): The record protocol can signal that its keys
709 are expiring due to reaching a time-based deadline, or a use-based
710 deadline (number of bytes that have been encrypted with the key).
711 This interaction is often limited to signaling between the record
712 layer and the handshake layer.
714 - ESP
716 * Mobility Events (ME): The record protocol can be signaled that it
717 is being migrated to another transport or interface due to
718 connection mobility, which may reset address and state validation
719 and induce state changes such as use of a new Connection
720 Identifier (CID).
722 - QUIC
724 - MinimalT
726 - CurveCP
728 - IKEv2 [RFC4555]
730 - WireGuard
732 5.4. Summary of Interfaces Exposed by Protocols
734 The following table summarizes which protocol exposes which
735 interface.
737 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
738 | Protocol |IPK|ALG | EXT |CM|AD| PSKI |IV| SAV |CT|KU| PSKE |KE|ME|
739 +===========+===+====+=====+==+==+======+==+=====+==+==+======+==+==+
740 | TLS | x | x | x |x | | x |x | |x |x | x | | |
741 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
742 | DTLS | x | x | x |x | | x |x | x |x |x | x | | |
743 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
744 | ZRTP | x | x | |x | | x |x | |x | | | | |
745 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
746 | QUIC | x | x | x |x | | x |x | x |x |x | | |x |
747 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
748 | tcpcrypt | | x | |x |x | x | | |x |x | x | | |
749 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
750 | MinimalT | x | x | |x | | x |x | |x |x | x | |x |
751 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
752 | CurveCP | x | | | | | |x | | | | | |x |
753 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
754 | IKEv2 | x | x | | |x | x |x | x |x |x | x | |x |
755 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
756 | ESP | | | | | | x | | | | | |x | |
757 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
758 | WireGuard | x | | | | | x |x | x | | | | |x |
759 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
760 | OpenVPN | x | x | | | | x |x | |x | | x | | |
761 +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
763 Table 1
765 x=Interface is exposed (blank)=Interface is not exposed
767 6. IANA Considerations
769 This document has no request to IANA.
771 7. Security Considerations
773 This document summarizes existing transport security protocols and
774 their interfaces. It does not propose changes to or recommend usage
775 of reference protocols. Moreover, no claims of security and privacy
776 properties beyond those guaranteed by the protocols discussed are
777 made. For example, metadata leakage via timing side channels and
778 traffic analysis may compromise any protocol discussed in this
779 survey. Applications using Security Interfaces should take such
780 limitations into consideration when using a particular protocol
781 implementation.
783 8. Privacy Considerations
785 Analysis of how features improve or degrade privacy is intentionally
786 omitted from this survey. All security protocols surveyed generally
787 improve privacy by reducing information leakage via encryption.
788 However, varying amounts of metadata remain in the clear across each
789 protocol. For example, client and server certificates are sent in
790 cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3
791 [RFC8446]. A survey of privacy features, or lack thereof, for
792 various security protocols could be addressed in a separate document.
794 9. Acknowledgments
796 The authors would like to thank Bob Bradley, Frederic Jacobs, Mirja
797 Kuehlewind, Yannick Sierra, Brian Trammell, and Magnus Westerlund for
798 their input and feedback on this draft.
800 10. Informative References
802 [ALTS] Ghali, C., Stubblefield, A., Knapp, E., Li, J., Schmidt,
803 B., and J. Boeuf, "Application Layer Transport Security",
804 .
807 [CurveCP] Bernstein, D.J., "CurveCP -- Usable security for the
808 Internet", .
810 [I-D.ietf-quic-tls]
811 Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
812 Work in Progress, Internet-Draft, draft-ietf-quic-tls-27,
813 21 February 2020, .
816 [I-D.ietf-quic-transport]
817 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
818 and Secure Transport", Work in Progress, Internet-Draft,
819 draft-ietf-quic-transport-27, 21 February 2020,
820 .
823 [I-D.ietf-taps-arch]
824 Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G.,
825 Perkins, C., Tiesel, P., and C. Wood, "An Architecture for
826 Transport Services", Work in Progress, Internet-Draft,
827 draft-ietf-taps-arch-06, 23 December 2019,
828 .
831 [I-D.ietf-taps-interface]
832 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G.,
833 Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T.
834 Pauly, "An Abstract Application Layer Interface to
835 Transport Services", Work in Progress, Internet-Draft,
836 draft-ietf-taps-interface-05, 4 November 2019,
837 .
840 [MinimalT] Petullo, W.M., Zhang, X., Solworth, J.A., Bernstein, D.J.,
841 and T. Lange, "MinimaLT -- Minimal-latency Networking
842 Through Better Security",
843 .
845 [OpenVPN] "OpenVPN cryptographic layer", .
848 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
849 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
850 1998, .
852 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
853 Norrman, "The Secure Real-time Transport Protocol (SRTP)",
854 RFC 3711, DOI 10.17487/RFC3711, March 2004,
855 .
857 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
858 DOI 10.17487/RFC4302, December 2005,
859 .
861 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
862 RFC 4303, DOI 10.17487/RFC4303, December 2005,
863 .
865 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
866 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
867 .
869 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
870 and RTP Control Protocol (RTCP) Packets over Connection-
871 Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July
872 2006, .
874 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
875 (TLS) Protocol Version 1.2", RFC 5246,
876 DOI 10.17487/RFC5246, August 2008,
877 .
879 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
880 Security (DTLS) Extension to Establish Keys for the Secure
881 Real-time Transport Protocol (SRTP)", RFC 5764,
882 DOI 10.17487/RFC5764, May 2010,
883 .
885 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
886 Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
887 June 2010, .
889 [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
890 Media Path Key Agreement for Unicast Secure RTP",
891 RFC 6189, DOI 10.17487/RFC6189, April 2011,
892 .
894 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
895 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
896 January 2012, .
898 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
899 Kivinen, "Internet Key Exchange Protocol Version 2
900 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
901 2014, .
903 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
904 "Transport Layer Security (TLS) Application-Layer Protocol
905 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
906 July 2014, .
908 [RFC7850] Nandakumar, S., "Registering Values of the SDP 'proto'
909 Field for Transporting RTP Media over TCP under Various
910 RTP Profiles", RFC 7850, DOI 10.17487/RFC7850, April 2016,
911 .
913 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
914 Ed., "Services Provided by IETF Transport Protocols and
915 Congestion Control Mechanisms", RFC 8095,
916 DOI 10.17487/RFC8095, March 2017,
917 .
919 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
920 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
921 August 2017, .
923 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
924 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
925 .
927 [RFC8547] Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E.
928 Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547,
929 DOI 10.17487/RFC8547, May 2019,
930 .
932 [RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
933 Q., and E. Smith, "Cryptographic Protection of TCP Streams
934 (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019,
935 .
937 [WireGuard]
938 Donenfeld, J.A., "WireGuard -- Next Generation Kernel
939 Network Tunnel",
940 .
942 Authors' Addresses
944 Theresa Enghardt
945 TU Berlin
946 Marchstr. 23
947 10587 Berlin
948 Germany
950 Email: ietf@tenghardt.net
952 Tommy Pauly
953 Apple Inc.
954 One Apple Park Way
955 Cupertino, California 95014,
956 United States of America
958 Email: tpauly@apple.com
960 Colin Perkins
961 University of Glasgow
962 School of Computing Science
963 Glasgow G12 8QQ
964 United Kingdom
966 Email: csp@csperkins.org
968 Kyle Rose
969 Akamai Technologies, Inc.
970 150 Broadway
971 Cambridge, MA 02144,
972 United States of America
974 Email: krose@krose.org
976 Christopher A. Wood (editor)
977 Apple Inc.
978 One Apple Park Way
979 Cupertino, California 95014,
980 United States of America
982 Email: cawood@apple.com