idnits 2.17.1
draft-ietf-taps-transport-security-09.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 (September 28, 2019) is 1671 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-23
== Outdated reference: A later version (-34) exists of
draft-ietf-quic-transport-23
== Outdated reference: A later version (-19) exists of
draft-ietf-taps-arch-04
== Outdated reference: A later version (-26) exists of
draft-ietf-taps-interface-04
== Outdated reference: A later version (-13) exists of
draft-ietf-tls-dtls-connection-id-06
== Outdated reference: A later version (-43) exists of
draft-ietf-tls-dtls13-32
-- 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 (~~), 7 warnings (==), 5 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group C. Wood, Ed.
3 Internet-Draft Apple Inc.
4 Intended status: Informational T. Enghardt
5 Expires: March 31, 2020 TU Berlin
6 T. Pauly
7 Apple Inc.
8 C. Perkins
9 University of Glasgow
10 K. Rose
11 Akamai Technologies, Inc.
12 September 28, 2019
14 A Survey of Transport Security Protocols
15 draft-ietf-taps-transport-security-09
17 Abstract
19 This document provides a survey of commonly used or notable network
20 security protocols, with a focus on how they interact and integrate
21 with applications and transport protocols. Its goal is to supplement
22 efforts to define and catalog transport services by describing the
23 interfaces required to add security protocols. This survey is not
24 limited to protocols developed within the scope or context of the
25 IETF, and those included represent a superset of features a Transport
26 Services system may need to support. Moreover, this document defines
27 a minimal set of security features that a secure transport system
28 should provide.
30 Status of This Memo
32 This Internet-Draft is submitted in full conformance with the
33 provisions of BCP 78 and BCP 79.
35 Internet-Drafts are working documents of the Internet Engineering
36 Task Force (IETF). Note that other groups may also distribute
37 working documents as Internet-Drafts. The list of current Internet-
38 Drafts is at https://datatracker.ietf.org/drafts/current/.
40 Internet-Drafts are draft documents valid for a maximum of six months
41 and may be updated, replaced, or obsoleted by other documents at any
42 time. It is inappropriate to use Internet-Drafts as reference
43 material or to cite them other than as "work in progress."
45 This Internet-Draft will expire on March 31, 2020.
47 Copyright Notice
49 Copyright (c) 2019 IETF Trust and the persons identified as the
50 document authors. All rights reserved.
52 This document is subject to BCP 78 and the IETF Trust's Legal
53 Provisions Relating to IETF Documents
54 (https://trustee.ietf.org/license-info) in effect on the date of
55 publication of this document. Please review these documents
56 carefully, as they describe your rights and restrictions with respect
57 to this document. Code Components extracted from this document must
58 include Simplified BSD License text as described in Section 4.e of
59 the Trust Legal Provisions and are provided without warranty as
60 described in the Simplified BSD License.
62 Table of Contents
64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
66 3. Security Features . . . . . . . . . . . . . . . . . . . . . . 6
67 4. Transport Security Protocol Descriptions . . . . . . . . . . 7
68 4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
69 4.1.1. Protocol Description . . . . . . . . . . . . . . . . 8
70 4.1.2. Security Features . . . . . . . . . . . . . . . . . . 9
71 4.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 9
72 4.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9
73 4.2.1. Protocol Description . . . . . . . . . . . . . . . . 10
74 4.2.2. Security Features . . . . . . . . . . . . . . . . . . 10
75 4.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10
76 4.3. QUIC with TLS . . . . . . . . . . . . . . . . . . . . . . 11
77 4.3.1. Protocol Description . . . . . . . . . . . . . . . . 11
78 4.3.2. Security Features . . . . . . . . . . . . . . . . . . 12
79 4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 12
80 4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 12
81 4.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 12
82 4.4.1. IKEv2 Protocol Description . . . . . . . . . . . . . 12
83 4.4.2. ESP Protocol Description . . . . . . . . . . . . . . 13
84 4.4.3. IKEv2 Security Features . . . . . . . . . . . . . . . 14
85 4.4.4. ESP Security Features . . . . . . . . . . . . . . . . 14
86 4.4.5. IKEv2 Protocol Dependencies . . . . . . . . . . . . . 14
87 4.4.6. ESP Protocol Dependencies . . . . . . . . . . . . . . 15
88 4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 15
89 4.5.1. Protocol description . . . . . . . . . . . . . . . . 15
90 4.5.2. Security Features . . . . . . . . . . . . . . . . . . 16
91 4.5.3. Protocol Dependencies . . . . . . . . . . . . . . . . 16
92 4.5.4. Variant: ZRTP for Media Path Key Agreement . . . . . 17
93 4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 17
94 4.6.1. Protocol Description . . . . . . . . . . . . . . . . 17
95 4.6.2. Security Features . . . . . . . . . . . . . . . . . . 18
96 4.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 18
97 4.7. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 18
98 4.7.1. Protocol description . . . . . . . . . . . . . . . . 19
99 4.7.2. Security Features . . . . . . . . . . . . . . . . . . 19
100 4.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 20
101 4.8. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 20
102 4.8.1. Protocol Description . . . . . . . . . . . . . . . . 20
103 4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 21
104 4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 21
105 4.9. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 22
106 4.9.1. Protocol Description . . . . . . . . . . . . . . . . 22
107 4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 23
108 4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 23
109 4.10. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . 23
110 4.10.1. Protocol Description . . . . . . . . . . . . . . . . 23
111 4.10.2. Protocol Features . . . . . . . . . . . . . . . . . 24
112 4.10.3. Protocol Dependencies . . . . . . . . . . . . . . . 25
113 5. Security Features and Application Dependencies . . . . . . . 25
114 5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 25
115 5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 26
116 5.3. Optional Feature Availability . . . . . . . . . . . . . . 27
117 6. Transport Security Protocol Interfaces . . . . . . . . . . . 29
118 6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 29
119 6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 30
120 6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 30
121 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
122 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
123 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31
124 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
125 11. Informative References . . . . . . . . . . . . . . . . . . . 31
126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
128 1. Introduction
130 Services and features provided by transport protocols have been
131 cataloged in [RFC8095]. This document supplements that work by
132 surveying commonly used and notable network security protocols, and
133 identifying the services and features a Transport Services system (a
134 system that provides a transport API) needs to provide in order to
135 add transport security. It examines Transport Layer Security (TLS),
136 Datagram Transport Layer Security (DTLS), QUIC + TLS, tcpcrypt,
137 Internet Key Exchange with Encapsulating Security Protocol (IKEv2 +
138 ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimalT. For each
139 protocol, this document provides a brief description, the security
140 features it provides, and the dependencies it has on the underlying
141 transport. This is followed by defining the set of transport
142 security features shared by these protocols. The document groups
143 these security features into a minimal set of features, which every
144 secure transport system should provide in addition to the transport
145 features described in [I-D.ietf-taps-minset], and additional optional
146 features, which may not be available in every secure transport
147 system. Finally, the document distills the application and transport
148 interfaces provided by the transport security protocols.
150 Selected protocols represent a superset of functionality and features
151 a Transport Services system may need to support, both internally and
152 externally (via an API) for applications [I-D.ietf-taps-arch].
153 Ubiquitous IETF protocols such as (D)TLS, as well as non-standard
154 protocols such as Google QUIC, are both included despite overlapping
155 features. As such, this survey is not limited to protocols developed
156 within the scope or context of the IETF. Outside of this candidate
157 set, protocols that do not offer new features are omitted. For
158 example, newer protocols such as WireGuard make unique design choices
159 that have important implications on applications, such as how to best
160 configure peer public keys and to delegate algorithm selection to the
161 system. In contrast, protocols such as ALTS [ALTS] are omitted since
162 they do not represent features deemed unique.
164 Authentication-only protocols such as TCP-AO [RFC5925] and IPsec AH
165 [RFC4302] are excluded from this survey. TCP-AO adds authenticity
166 protections to long-lived TCP connections, e.g., replay protection
167 with per-packet Message Authentication Codes. (This protocol
168 obsoletes TCP MD5 "signature" options specified in [RFC2385].) One
169 prime use case of TCP-AO is for protecting BGP connections.
170 Similarly, AH adds per-datagram authenticity and adds similar replay
171 protection. Despite these improvements, neither protocol sees
172 general use and both lack critical properties important for emergent
173 transport security protocols: confidentiality, privacy protections,
174 and agility. Such protocols are thus omitted from this survey.
176 2. Terminology
178 The following terms are used throughout this document to describe the
179 roles and interactions of transport security protocols:
181 o Transport Feature: a specific end-to-end feature that the
182 transport layer provides to an application. Examples include
183 confidentiality, reliable delivery, ordered delivery, message-
184 versus-stream orientation, etc.
186 o Transport Service: a set of Transport Features, without an
187 association to any given framing protocol, which provides
188 functionality to an application.
190 o Transport Protocol: an implementation that provides one or more
191 different transport services using a specific framing and header
192 format on the wire. A Transport Protocol services an application.
194 o Application: an entity that uses a transport protocol for end-to-
195 end delivery of data across the network. This may also be an
196 upper layer protocol or tunnel encapsulation.
198 o Security Feature: a feature that a network security layer provides
199 to applications. Examples include authentication, encryption, key
200 generation, session resumption, and privacy. Features may be
201 Mandatory or Optional for an application's implementation.
202 Security Features extend the set of Transport Features described
203 in [RFC8095] and provided by Transport Services implementations.
205 o Security Protocol: a defined network protocol that implements one
206 or more security features. Security protocols may be used
207 alongside transport protocols, and in combination with other
208 security protocols when appropriate.
210 o Handshake Protocol: a protocol that enables peers to validate each
211 other and to securely establish shared cryptographic context.
213 o Record: Framed protocol messages.
215 o Record Protocol: a security protocol that allows data to be
216 divided into manageable blocks and protected using shared
217 cryptographic context.
219 o Session: an ephemeral security association between applications.
221 o Cryptographic context: a set of cryptographic parameters,
222 including but not necessarily limited to keys for encryption,
223 authentication, and session resumption, enabling authorized
224 parties to a session to communicate securely.
226 o Connection: the shared state of two or more endpoints that
227 persists across messages that are transmitted between these
228 endpoints. A connection is a transient participant of a session,
229 and a session generally lasts between connection instances.
231 o Peer: an endpoint application party to a session.
233 o Client: the peer responsible for initiating a session.
235 o Server: the peer responsible for responding to a session
236 initiation.
238 3. Security Features
240 In this section, we enumerate Security Features exposed by protocols
241 discussed in the remainder of this document. Protocol security (and
242 privacy) properties that are unrelated to the API surface exposed by
243 such protocols, such as client or server identity hiding, are not
244 listed here as features.
246 o Forward-secure session key establishment: Establishing
247 cryptographic keys with forward-secure properties.
249 o Cryptographic algorithm negotiation: Negotiating support of
250 protocol algorithms, including algorithms for encryption, hashing,
251 MAC (PRF), and digital signatures.
253 o Session caching and management: Managing session state caches used
254 for subsequent connections, with the aim of amortizing connection
255 establishment costs.
257 o Peer authentication: Authenticating peers using generic or
258 protocol-specific mechanisms, such as certificates, raw public
259 keys, pre-shared keys, or EAP methods.
261 o Unilateral responder authentication: Requiring authentication for
262 the responder of a connection.
264 o Mutual authentication: Establishing connections in which both
265 endpoints are authenticated.
267 o Application authentication delegation: Delegating to applications
268 out-of-band to perform peer authentication.
270 o Record (channel or datagram) confidentiality and integrity:
271 Encrypting and authenticating application plaintext bytes sent
272 between peers over a channel or in individual datagrams.
274 o Partial record confidentiality: Encrypting some portion of
275 records.
277 o Optional record integrity: Optionally authenticating certain
278 records.
280 o Record replay prevention: Detecting and defending against record
281 replays, which can be due to in-network retransmissions.
283 o Early data support: Transmitting application data prior to secure
284 connection establishment via a handshake. For TLS, this support
285 begins with TLS 1.3.
287 o Connection mobility: Allowing a connection to be multihomed or
288 resilient across network interface or address changes, such as NAT
289 rebindings that occur without an endpoint's knowledge. Mobility
290 allows cryptographic key material and other state information to
291 be reused in the event of a connection change.
293 o Application-layer feature negotiation: Securely negotiating
294 application-specific functionality. Such features may be
295 necessary for further application processing, such as the TLS
296 parent connection protocol type via ALPN [RFC7301] or desired
297 application identity via SNI [RFC6066].
299 o Configuration extensions: Adding protocol features via extensions
300 or configuration options. TLS extensions are a primary example of
301 this feature.
303 o Out-of-order record receipt: Processing of records received out-
304 of-order.
306 o Source validation (cookie or puzzle based): Validating peers and
307 mitigating denial-of-service (DoS) attacks via explicit proof of
308 origin (cookies) or work mechanisms (puzzles).
310 o Length-hiding padding: Adding padding to records in order to hide
311 plaintext message length and mitigate amplification attack
312 vectors.
314 4. Transport Security Protocol Descriptions
316 This section contains descriptions of security protocols currently
317 used to protect data being sent over a network.
319 For each protocol, we describe its provided features and dependencies
320 on other protocols.
322 4.1. TLS
324 TLS (Transport Layer Security) [RFC8446] is a common protocol used to
325 establish a secure session between two endpoints. Communication over
326 this session "prevents eavesdropping, tampering, and message
327 forgery." TLS consists of a tightly coupled handshake and record
328 protocol. The handshake protocol is used to authenticate peers,
329 negotiate protocol options, such as cryptographic algorithms, and
330 derive session-specific keying material. The record protocol is used
331 to marshal (possibly encrypted) data from one peer to the other.
332 This data may contain handshake messages or raw application data.
334 4.1.1. Protocol Description
336 TLS is the composition of a handshake and record protocol [RFC8446].
337 The record protocol is designed to marshal an arbitrary, in-order
338 stream of bytes from one endpoint to the other. It handles
339 segmenting, compressing (when enabled), and encrypting data into
340 discrete records. When configured to use an authenticated encryption
341 with associated data (AEAD) algorithm, it also handles nonce
342 generation and encoding for each record. The record protocol is
343 hidden from the client behind a bytestream-oriented API.
345 The handshake protocol serves several purposes, including: peer
346 authentication, protocol option (key exchange algorithm and
347 ciphersuite) negotiation, and key derivation. Peer authentication
348 may be mutual; however, commonly, only the server is authenticated.
349 X.509 certificates are commonly used in this authentication step,
350 though other mechanisms, such as raw public keys [RFC7250], exist.
351 The client is not authenticated unless explicitly requested by the
352 server.
354 The handshake protocol is also extensible. It allows for a variety
355 of extensions to be included by either the client or server. These
356 extensions are used to specify client preferences, e.g., the
357 application-layer protocol to be driven with the TLS connection
358 [RFC7301], or signals to the server to aid operation, e.g., Server
359 Name Indication (SNI) [RFC6066]. Various extensions also exist to
360 tune the parameters of the record protocol, e.g., the maximum
361 fragment length [RFC6066] and record size limit [RFC8449].
363 Alerts are used to convey errors and other atypical events to the
364 endpoints. There are two classes of alerts: closure and error
365 alerts. A closure alert is used to signal to the other peer that the
366 sender wishes to terminate the connection. The sender typically
367 follows a close alert with a TCP FIN segment to close the connection.
368 Error alerts are used to indicate problems with the handshake or
369 individual records. Most errors are fatal and are followed by
370 connection termination. However, warning alerts may be handled at
371 the discretion of the implementation.
373 Once a session is disconnected all session keying material must be
374 destroyed, with the exception of secrets previously established
375 expressly for purposes of session resumption. TLS supports stateful
376 and stateless resumption. (Here, "state" refers to bookkeeping on a
377 per-session basis by the server. It is assumed that the client must
378 always store some state information in order to resume a session.)
380 4.1.2. Security Features
382 o Forward-secure session key establishment.
384 o Cryptographic algorithm negotiation.
386 o Stateful and stateless cross-connection session resumption.
388 o Session caching and management.
390 o Peer authentication (Certificate, raw public key, and pre-shared
391 key).
393 o Unilateral responder authentication.
395 o Mutual authentication.
397 o Application authentication delegation.
399 o Record (channel) confidentiality and integrity.
401 o Record replay prevention.
403 o Application-layer feature negotiation.
405 o Configuration extensions.
407 o Early data support (starting with TLS 1.3).
409 o Optional record-layer padding (starting with TLS 1.3).
411 4.1.3. Protocol Dependencies
413 o In-order, reliable bytestream transport.
415 o (Optionally) A PKI trust store for certificate validation.
417 4.2. DTLS
419 DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS,
420 but differs in that it is designed to run over unreliable datagram
421 protocols like UDP instead of TCP. DTLS modifies the protocol to
422 make sure it can still provide the same security guarantees as TLS
423 even without reliability from the transport. DTLS was designed to be
424 as similar to TLS as possible, so this document assumes that all
425 properties from TLS are carried over except where specified.
427 4.2.1. Protocol Description
429 DTLS is modified from TLS to operate with the possibility of packet
430 loss, reordering, and duplication that may occur when operating over
431 UDP. To enable out-of-order delivery of application data, the DTLS
432 record protocol itself has no inter-record dependencies. However, as
433 the handshake requires reliability, each handshake message is
434 assigned an explicit sequence number to enable retransmissions of
435 lost packets and in-order processing by the receiver. Handshake
436 message loss is remedied by sender retransmission after a
437 configurable period in which the expected response has not yet been
438 received.
440 As the DTLS handshake protocol runs atop the record protocol, to
441 account for long handshake messages that cannot fit within a single
442 record, DTLS supports fragmentation and subsequent reconstruction of
443 handshake messages across records. The receiver must reassemble
444 records before processing.
446 DTLS relies on unique UDP 4-tuples to identify connections, or a
447 similar mechanism in other datagram transports. Since all
448 application-layer data is encrypted, demultiplexing over the same
449 4-tuple requires the use of a connection identifier extension
450 [I-D.ietf-tls-dtls-connection-id] to permit identification of the
451 correct connection-specific cryptographic context without the use of
452 trial decryption. (Note that this extension is only supported in
453 DTLS 1.2 and 1.3 [I-D.ietf-tls-dtls13].)
455 Since datagrams can be replayed, DTLS provides optional anti-replay
456 detection based on a window of acceptable sequence numbers [RFC6347].
458 4.2.2. Security Features
460 o Record replay protection.
462 o Record (datagram) confidentiality and integrity.
464 o Out-of-order record receipt.
466 o DoS mitigation (cookie-based).
468 See also the features from TLS.
470 4.2.3. Protocol Dependencies
472 o DTLS relies on an unreliable datagram transport.
474 o The DTLS record protocol explicitly encodes record lengths, so
475 although it runs over a datagram transport, it does not rely on
476 the transport protocol's framing beyond requiring transport-level
477 reconstruction of datagrams fragmented over packets. (Note: DTLS
478 1.3 short header records omit the explicit length field.)
480 o Uniqueness of the session within the transport flow (only one DTLS
481 connection on a UDP 4-tuple, for example); or else support for the
482 connection identifier extension to enable demultiplexing.
484 o Path MTU discovery.
486 o For the handshake: Reliable, in-order transport. DTLS provides
487 its own reliability.
489 4.3. QUIC with TLS
491 QUIC is a new standards-track transport protocol that runs over UDP,
492 loosely based on Google's original proprietary gQUIC protocol
493 [I-D.ietf-quic-transport] (See Section 4.3.4 for more details). The
494 QUIC transport layer itself provides support for data confidentiality
495 and integrity. This requires keys to be derived with a separate
496 handshake protocol. A mapping for QUIC of TLS 1.3
497 [I-D.ietf-quic-tls] has been specified to provide this handshake.
499 4.3.1. Protocol Description
501 As QUIC relies on TLS to secure its transport functions, it creates
502 specific integration points between its security and transport
503 functions:
505 o Starting the handshake to generate keys and provide authentication
506 (and providing the transport for the handshake).
508 o Client address validation.
510 o Key ready events from TLS to notify the QUIC transport.
512 o Exporting secrets from TLS to the QUIC transport.
514 The QUIC transport layer support multiple streams over a single
515 connection. QUIC implements a record protocol for TLS handshake
516 messages to establish a connection. These messages are sent in
517 CRYPTO frames [I-D.ietf-quic-transport] in Initial and Handshake
518 packets. Initial packets are encrypted using fixed keys derived from
519 the QUIC version and public packet information (Connection ID).
520 Handshake packets are encrypted using TLS handshake secrets. Once
521 TLS completes, QUIC uses the resulting traffic secrets to for the
522 QUIC connection to protect the rest of the frames. QUIC supports
523 0-RTT data using previously negotiated connection secrets Early data
524 is sent in 0-RTT packets, which may be included in the same datagram
525 as the Initial and Handshake packets.
527 4.3.2. Security Features
529 o DoS mitigation (cookie-based).
531 See also the properties of TLS.
533 4.3.3. Protocol Dependencies
535 o QUIC transport assumes an unreliable transport, e.g., UDP.
537 o QUIC transport relies on TLS 1.3 for key exchange, peer
538 authentication, and shared secret derivation.
540 o For the handshake: Reliable, in-order transport. QUIC provides
541 its own reliability.
543 4.3.4. Variant: Google QUIC
545 Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol
546 designed and deployed by Google following experience from deploying
547 SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally
548 known as "QUIC": this document uses gQUIC to unambiguously
549 distinguish it from the standards-track IETF QUIC. The proprietary
550 technical forebear of IETF QUIC, gQUIC was originally designed with
551 tightly-integrated security and application data transport protocols.
553 4.4. IKEv2 with ESP
555 IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec
556 protocol suite that encrypts and authenticates IP packets, either for
557 creating tunnels (tunnel-mode) or for direct transport connections
558 (transport-mode). This suite of protocols separates out the key
559 generation protocol (IKEv2) from the transport encryption protocol
560 (ESP). Each protocol can be used independently, but this document
561 considers them together, since that is the most common pattern.
563 4.4.1. IKEv2 Protocol Description
565 IKEv2 is a control protocol that runs on UDP ports 500 or 4500 and
566 TCP port 4500. Its primary goal is to generate keys for Security
567 Associations (SAs). An SA contains shared (cryptographic)
568 information used for establishing other SAs or keying ESP; See
569 Section 4.4.2. IKEv2 first uses a Diffie-Hellman key exchange to
570 generate keys for the "IKE SA", which is a set of keys used to
571 encrypt further IKEv2 messages. IKE then performs a phase of
572 authentication in which both peers present blobs signed by a shared
573 secret or private key that authenticates the entire IKE exchange and
574 the IKE identities. IKE then derives further sets of keys on demand,
575 which together with traffic policies are referred to as the "Child
576 SA". These Child SA keys are used by ESP.
578 IKEv2 negotiates which protocols are acceptable to each peer for both
579 the IKE and Child SAs using "Proposals". Each proposal specifies an
580 encryption and authentication algorithm, or an AEAD algorithm, a
581 Diffie-Hellman group, and (for IKE SAs only) a pseudorandom function
582 algorithm. Each peer may support multiple proposals, and the most
583 preferred mutually supported proposal is chosen during the handshake.
585 The authentication phase of IKEv2 may use Shared Secrets,
586 Certificates, Digital Signatures, or an EAP (Extensible
587 Authentication Protocol) method. At a minimum, IKEv2 takes two round
588 trips to set up both an IKE SA and a Child SA. If EAP is used, this
589 exchange may be expanded.
591 Any SA used by IKEv2 can be re-keyed before expiration, which is
592 usually based either on time or number of bytes encrypted.
594 There is an extension to IKEv2 that allows session resumption
595 [RFC5723].
597 MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a
598 set of Security Associations to migrate over different outer IP
599 addresses and interfaces [RFC4555].
601 When UDP is not available or well-supported on a network, IKEv2 may
602 be encapsulated in TCP [RFC8229].
604 4.4.2. ESP Protocol Description
606 ESP is a protocol that encrypts and authenticates IPv4 and IPv6
607 packets. The keys used for both encryption and authentication can be
608 derived from an IKEv2 exchange. ESP Security Associations come as
609 pairs, one for each direction between two peers. Each SA is
610 identified by a Security Parameter Index (SPI), which is marked on
611 each encrypted ESP packet.
613 ESP packets include the SPI, a sequence number, an optional
614 Initialization Vector (IV), payload data, padding, a length and next
615 header field, and an Integrity Check Value.
617 From [RFC4303], "ESP is used to provide confidentiality, data origin
618 authentication, connectionless integrity, an anti-replay service (a
619 form of partial sequence integrity), and limited traffic flow
620 confidentiality."
622 Since ESP operates on IP packets, it is not directly tied to the
623 transport protocols it encrypts. This means it requires little or no
624 change from transports in order to provide security.
626 ESP packets may be sent directly over IP, but where network
627 conditions warrant (e.g., when a NAT is present or when a firewall
628 blocks such packets) they may be encapsulated in UDP [RFC3948] or TCP
629 [RFC8229].
631 4.4.3. IKEv2 Security Features
633 o Forward-secure session key establishment.
635 o Cryptographic algorithm negotiation.
637 o Peer authentication (certificate, raw public key, pre-shared key,
638 and EAP).
640 o Unilateral responder authentication.
642 o Mutual authentication.
644 o Record (datagram) confidentiality and integrity.
646 o Session resumption.
648 o Connection mobility.
650 o DoS mitigation (cookie-based).
652 4.4.4. ESP Security Features
654 o Record confidentiality and integrity.
656 o Record replay protection.
658 4.4.5. IKEv2 Protocol Dependencies
660 o Availability of UDP to negotiate, or implementation support for
661 TCP-encapsulation.
663 o Some EAP authentication types require accessing a hardware device,
664 such as a SIM card; or interacting with a user, such as password
665 prompting.
667 4.4.6. ESP Protocol Dependencies
669 o Since ESP is below transport protocols, it does not have any
670 dependencies on the transports themselves, other than on UDP or
671 TCP where encapsulation is employed.
673 4.5. Secure RTP (with DTLS)
675 Secure RTP (SRTP) is a profile for RTP that provides confidentiality,
676 message authentication, and replay protection for RTP data packets
677 and RTP control protocol (RTCP) packets [RFC3711].
679 4.5.1. Protocol description
681 SRTP adds confidentiality and optional integrity protection to RTP
682 data packets, and adds confidentially and mandatory integrity
683 protection to RTCP packets. For RTP data packets, this is done by
684 encrypting the payload section of the packet and optionally appending
685 an authentication tag (MAC) as a packet trailer, with the RTP header
686 authenticated but not encrypted (the RTP header was left unencrypted
687 to enable RTP header compression [RFC2508] [RFC3545]). For RTCP
688 packets, the first packet in the compound RTCP packet is partially
689 encrypted, leaving the first eight octets of the header as clear-text
690 to allow identification of the packet as RTCP, while the remainder of
691 the compound packet is fully encrypted. The entire RTCP packet is
692 then authenticated by appending a MAC as packet trailer.
694 Packets are encrypted using session keys, which are ultimately
695 derived from a master key and an additional master salt and session
696 salt. SRTP packets carry a 2-byte sequence number to partially
697 identify the unique packet index. SRTP peers maintain a separate
698 roll-over counter (ROC) for RTP data packets that is incremented
699 whenever the sequence number wraps. The sequence number and ROC
700 together determine the packet index. RTCP packets have a similar,
701 yet differently named, field called the RTCP index which serves the
702 same purpose.
704 Numerous encryption modes are supported. For popular modes of
705 operation, e.g., AES-CTR, the (unique) initialization vector (IV)
706 used for each encryption mode is a function of the RTP SSRC
707 (synchronization source), packet index, and session "salting key".
709 SRTP offers replay detection by keeping a replay list of already seen
710 and processed packet indices. If a packet arrives with an index that
711 matches one in the replay list, it is silently discarded.
713 DTLS [RFC5764] is commonly used to perform mutual authentication and
714 key agreement for SRTP [RFC5763]. Peers use DTLS to perform mutual
715 certificate-based authentication on the media path, and to generate
716 the SRTP master key. Peer certificates can be issued and signed by a
717 certificate authority. Alternatively, certificates used in the DTLS
718 exchange can be self-signed. If they are self-signed, certificate
719 fingerprints are included in the signaling exchange (e.g., in SIP or
720 WebRTC), and used to bind the DTLS key exchange in the media plane to
721 the signaling plane. The combination of a mutually authenticated
722 DTLS key exchange on the media path and a fingerprint sent in the
723 signaling channel protects against active attacks on the media,
724 provided the signaling can be trusted. Signaling needs to be
725 protected as described in, for example, SIP [RFC3261] Authenticated
726 Identity Management [RFC8224] or the WebRTC security architecture
727 [I-D.ietf-rtcweb-security-arch], to provide complete system security.
729 4.5.2. Security Features
731 o Forward-secure session key establishment.
733 o Cryptographic algorithm negotiation.
735 o Mutual authentication.
737 o Partial datagram confidentiality. (Packet headers are not
738 encrypted.)
740 o Optional authentication of data packets.
742 o Mandatory authentication of control packets.
744 o Out-of-order record receipt.
746 4.5.3. Protocol Dependencies
748 o Secure RTP can run over UDP or TCP.
750 o External key derivation and management protocol, e.g., DTLS
751 [RFC5763].
753 o External identity management protocol, e.g., SIP Authenticated
754 Identity Management [RFC8224], WebRTC Security Architecture
755 [I-D.ietf-rtcweb-security-arch].
757 4.5.4. Variant: ZRTP for Media Path Key Agreement
759 ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It
760 uses standard SRTP to protect RTP data packets and RTCP packets, but
761 provides alternative key agreement and identity management protocols.
763 Key agreement is performed using a Diffie-Hellman key exchange that
764 runs on the media path. This generates a shared secret that is then
765 used to generate the master key and salt for SRTP.
767 ZRTP does not rely on a PKI or external identity management system.
768 Rather, it uses an ephemeral Diffie-Hellman key exchange with hash
769 commitment to allow detection of man-in-the-middle attacks. This
770 requires endpoints to display a short authentication string that the
771 users must read and verbally compare to validate the hashes and
772 ensure security. Endpoints cache some key material after the first
773 call to use in subsequent calls; this is mixed in with the Diffie-
774 Hellman shared secret, so the short authentication string need only
775 be checked once for a given user. This gives key continuity
776 properties analogous to the secure shell (ssh) [RFC4253].
778 4.6. tcpcrypt
780 Tcpcrypt [RFC8548] is a lightweight extension to the TCP protocol for
781 opportunistic encryption. Applications may use tcpcrypt's unique
782 session ID for further application-level authentication. Absent this
783 authentication, tcpcrypt is vulnerable to active attacks.
785 4.6.1. Protocol Description
787 Tcpcrypt extends TCP to enable opportunistic encryption between the
788 two ends of a TCP connection [RFC8548]. It is a family of TCP
789 encryption protocols (TEP), distinguished by key exchange algorithm.
790 The use of a TEP is negotiated with a TCP option during the initial
791 TCP handshake via the mechanism described by TCP Encryption
792 Negotiation Option (ENO) [RFC8547]. In the case of initial session
793 establishment, once a tcpcrypt TEP has been negotiated the key
794 exchange occurs within the data segments of the first few packets
795 exchanged after the handshake completes. The initiator of a
796 connection sends a list of supported AEAD algorithms, a random nonce,
797 and an ephemeral public key share. The responder typically chooses a
798 mutually-supported AEAD algorithm and replies with this choice, its
799 own nonce, and ephemeral key share. An initial shared secret is
800 derived from the ENO handshake, the tcpcrypt handshake, and the
801 initial keying material resulting from the key exchange. The traffic
802 encryption keys on the initial connection are derived from the shared
803 secret. Connections can be re-keyed before the natural AEAD limit
804 for a single set of traffic encryption keys is reached.
806 Each tcpcrypt session is associated with a ladder of resumption IDs,
807 each derived from the respective entry in a ladder of shared secrets.
808 These resumption IDs can be used to negotiate a stateful resumption
809 of the session in a subsequent connection, resulting in use of a new
810 shared secret and traffic encryption keys without requiring a new key
811 exchange. Willingness to resume a session is signaled via the ENO
812 option during the TCP handshake. Given the length constraints
813 imposed by TCP options, unlike stateless resumption mechanisms (such
814 as that provided by session tickets in TLS) resumption in tcpcrypt
815 requires the maintenance of state on the server, and so successful
816 resumption across a pool of servers implies shared state.
818 Owing to middlebox ossification issues, tcpcrypt only protects the
819 payload portion of a TCP packet. It does not encrypt any header
820 information, such as the TCP sequence number.
822 4.6.2. Security Features
824 o Forward-secure session key establishment.
826 o Record (channel) confidentiality and integrity.
828 o Stateful cross-connection session resumption.
830 o Session caching and management.
832 o Application authentication delegation.
834 4.6.3. Protocol Dependencies
836 o TCP for in-order, reliable transport.
838 o TCP Encryption Negotiation Option (ENO).
840 4.7. WireGuard
842 WireGuard is a layer 3 protocol designed as an alternative to IPsec
843 [WireGuard] for certain use cases. It uses UDP to encapsulate IP
844 datagrams between peers. Unlike most transport security protocols,
845 which rely on PKI for peer authentication, WireGuard authenticates
846 peers using pre-shared public keys delivered out-of-band, each of
847 which is bound to one or more IP addresses. Moreover, as a protocol
848 suited for VPNs, WireGuard offers no extensibility, negotiation, or
849 cryptographic agility.
851 4.7.1. Protocol description
853 WireGuard is a simple VPN protocol that binds a pre-shared public key
854 to one or more IP addresses. Users configure WireGuard by
855 associating peer public keys with IP addresses. These mappings are
856 stored in a CryptoKey Routing Table. (See Section 2 of [WireGuard]
857 for more details and sample configurations.) These keys are used
858 upon WireGuard packet transmission and reception. For example, upon
859 receipt of a Handshake Initiation message, receivers use the static
860 public key in their CryptoKey routing table to perform necessary
861 cryptographic computations.
863 WireGuard builds on Noise [Noise] for 1-RTT key exchange with
864 identity hiding. The handshake hides peer identities as per the
865 SIGMA construction [SIGMA]. As a consequence of using Noise,
866 WireGuard comes with a fixed set of cryptographic algorithms:
868 o x25519 [Curve25519] and HKDF [RFC5869] for ECDH and key
869 derivation.
871 o ChaCha20+Poly1305 [RFC8439] for packet authenticated encryption.
873 o BLAKE2s [BLAKE2] for hashing.
875 There is no cryptographic agility. If weaknesses are found in any of
876 these algorithms, new message types using new algorithms must be
877 introduced.
879 If a WireGuard receiver is under heavy load and cannot process a
880 packet, e.g., cannot spare CPU cycles for expensive public key
881 cryptographic operations, it can reply with a cookie similar to DTLS
882 and IKEv2. This cookie only proves IP address ownership. Any rate
883 limiting scheme can be applied to packets coming from non-spoofed
884 addresses.
886 4.7.2. Security Features
888 o Forward-secure session key establishment.
890 o Peer authentication (public-key and PSK).
892 o Mutual authentication.
894 o Record replay prevention (Stateful, timestamp-based).
896 o Connection mobility.
898 o DoS mitigation (cookie-based).
900 4.7.3. Protocol Dependencies
902 o Datagram transport.
904 o Out-of-band key distribution and management.
906 4.8. CurveCP
908 CurveCP [CurveCP] is a UDP-based transport security protocol from
909 Daniel J. Bernstein. Unlike other transport security protocols, it
910 is based entirely upon highly efficient public key algorithms. This
911 removes many pitfalls associated with nonce reuse and key
912 synchronization.
914 4.8.1. Protocol Description
916 CurveCP is a UDP-based transport security protocol. It is built on
917 three principal features: exclusive use of public key authenticated
918 encryption of packets, server-chosen cookies to prohibit memory and
919 computation DoS at the server, and connection mobility with a client-
920 chosen ephemeral identifier.
922 There are two rounds in CurveCP. In the first round, the client
923 sends its first initialization packet to the server, carrying its
924 (possibly fresh) ephemeral public key C', with zero-padding encrypted
925 under the server's long-term public key. The server replies with a
926 cookie and its own ephemeral key S' and a cookie that is to be used
927 by the client. Upon receipt, the client then generates its second
928 initialization packet carrying: the ephemeral key C', cookie, and an
929 encryption of C', the server's domain name, and, optionally, some
930 message data. The server verifies the cookie and the encrypted
931 payload and, if valid, proceeds to send data in return. At this
932 point, the connection is established and the two parties can
933 communicate.
935 The use of public-key encryption and authentication, or "boxing",
936 simplifies problems that come with symmetric key management and nonce
937 synchronization. For example, it allows the sender of a message to
938 be in complete control of each message's nonce. It does not require
939 either end to share secret keying material. Furthermore, it allows
940 connections (or sessions) to be associated with unique ephemeral
941 public keys as a mechanism for enabling forward secrecy given the
942 risk of long-term private key compromise.
944 The client and server do not perform a standard key exchange.
945 Instead, in the initial exchange of packets, each party provides its
946 own ephemeral key to the other end. The client can choose a new
947 ephemeral key for every new connection. However, the server must
948 rotate these keys on a slower basis. Otherwise, it would be trivial
949 for an attacker to force the server to create and store ephemeral
950 keys with a fake client initialization packet.
952 Servers use cookies for source validation. After receiving a
953 client's initial packet, encrypted under the server's long-term
954 public key, a server generates and returns a stateless cookie that
955 must be echoed back in the client's following message. This cookie
956 is encrypted under the client's ephemeral public key. This stateless
957 technique prevents attackers from hijacking client initialization
958 packets to obtain cookie values to flood clients. (A client would
959 detect the duplicate cookies and reject the flooded packets.)
960 Similarly, replaying the client's second packet, carrying the cookie,
961 will be detected by the server.
963 CurveCP supports client authentication by allowing clients to send
964 their long-term public keys in the second initialization packet. A
965 server can verify this public key and, if untrusted, drop the
966 connection and subsequent data.
968 Unlike some other protocols, CurveCP data packets leave only the
969 ephemeral public key, connection ID, and per-message nonce in the
970 clear. All other data is encrypted.
972 4.8.2. Protocol Features
974 o Datagram confidentiality and integrity (via public key
975 encryption).
977 o Peer authentication (public-key).
979 o Unilateral responder authentication.
981 o Mutual authentication.
983 o Connection mobility (based on a client-chosen ephemeral
984 identifier).
986 o Optional length-hiding and anti-amplification padding.
988 o Source validation (cookie-based)
990 4.8.3. Protocol Dependencies
992 o An unreliable transport protocol such as UDP.
994 4.9. MinimalT
996 MinimalT is a UDP-based transport security protocol designed to offer
997 confidentiality, mutual authentication, DoS prevention, and
998 connection mobility [MinimalT]. One major goal of the protocol is to
999 leverage existing protocols to obtain server-side configuration
1000 information used to more quickly bootstrap a connection. MinimalT
1001 uses a variant of TCP's congestion control algorithm.
1003 4.9.1. Protocol Description
1005 MinimalT is a secure transport protocol built on top of a widespread
1006 directory service. Clients and servers interact with local directory
1007 services to (a) resolve server information and (b) publish ephemeral
1008 state information, respectively. Clients connect to a local resolver
1009 once at boot time. Through this resolver they recover the IP
1010 address(es) and public key(s) of each server to which they want to
1011 connect.
1013 Connections are instances of user-authenticated, mobile sessions
1014 between two endpoints. Connections run within tunnels between hosts.
1015 A tunnel is a server-authenticated container that multiplexes
1016 multiple connections between the same hosts. All connections in a
1017 tunnel share the same transport state machine and encryption. Each
1018 tunnel has a dedicated control connection used to configure and
1019 manage the tunnel over time. Moreover, since tunnels are independent
1020 of the network address information, they may be reused as both ends
1021 of the tunnel move about the network. This does however imply that
1022 connection establishment and packet encryption mechanisms are
1023 coupled.
1025 Before a client connects to a remote service, it must first establish
1026 a tunnel to the host providing or offering the service. Tunnels are
1027 established in 1-RTT using an ephemeral key obtained from the
1028 directory service. Tunnel initiators provide their own ephemeral key
1029 and, optionally, a DoS puzzle solution such that the recipient
1030 (server) can verify the authenticity of the request and derive a
1031 shared secret. Within a tunnel, new connections to services may be
1032 established.
1034 Additional (orthogonal) transport features include: connection
1035 multiplexing between hosts across shared tunnels, and congestion
1036 control state is shared across connections between the same host
1037 pairs.
1039 4.9.2. Protocol Features
1041 o Record or datagram confidentiality and integrity.
1043 o Forward-secure session key establishment.
1045 o Peer authentication (public-key).
1047 o Unilateral responder authentication.
1049 o DoS mitigation (puzzle-based).
1051 o Out-of-order receipt record.
1053 o Connection mobility (based on tunnel identifiers).
1055 4.9.3. Protocol Dependencies
1057 o An unreliable transport protocol such as UDP.
1059 o A DNS-like resolution service to obtain location information (an
1060 IP address) and ephemeral keys.
1062 o A PKI trust store for certificate validation.
1064 4.10. OpenVPN
1066 OpenVPN [OpenVPN] is a commonly used protocol designed as an
1067 alternative to IPsec. A major goal of this protocol is to provide a
1068 VPN that is simple to configure and works over a variety of
1069 transports. OpenVPN encapsulates either IP packets or Ethernet
1070 frames within a secure tunnel and can run over UDP or TCP.
1072 4.10.1. Protocol Description
1074 OpenVPN facilitates authentication using either a pre-shared static
1075 key or using X.509 certificates and TLS. In pre-shared key mode,
1076 OpenVPN derives keys for encryption and authentication directly from
1077 one or multiple symmetric keys. In TLS mode, OpenVPN encapsulates a
1078 TLS handshake, in which both peers must present a certificate for
1079 authentication. After the handshake, both sides contribute random
1080 source material to derive keys for encryption and authentication
1081 using the TLS pseudo random function (PRF). OpenVPN provides the
1082 possibility to authenticate and encrypt the TLS handshake itself
1083 using a pre-shared key or passphrase. Furthermore, it supports re-
1084 keying using TLS.
1086 After authentication and key exchange, OpenVPN encrypts payload data,
1087 i.e., IP packets or Ethernet frames, and authenticates the payload
1088 using HMAC. Applications can select an arbitrary encryption
1089 algorithm (cipher) and key size, as well hash function for HMAC. The
1090 default cipher and hash functions are AES-GCM and SHA1, respectively.
1091 Recent versions of the protocol support cipher negotiation.
1093 OpenVPN can run over TCP or UDP. When running over UDP, OpenVPN
1094 provides a simple reliability layer for control packets such as the
1095 TLS handshake and key exchange. It assigns sequence numbers to
1096 packets, acknowledges packets it receives, and retransmits packets it
1097 deems lost. Similar to DTLS, this reliability layer is not used for
1098 data packets, which prevents the problem of two reliability
1099 mechanisms being encapsulated within each other. When running over
1100 TCP, OpenVPN includes the packet length in the header, which allows
1101 the peer to deframe the TCP stream into messages.
1103 For replay protection, OpenVPN assigns an identifier to each outgoing
1104 packet, which is unique for the packet and the currently used key.
1105 In pre-shared key mode or with a CFB or OFB mode cipher, OpenVPN
1106 combines a timestamp with an incrementing sequence number into a
1107 64-bit identifier. In TLS mode with CBC cipher mode, OpenVPN omits
1108 the timestamp, so identifiers are only 32-bit. This is sufficient
1109 since OpenVPN can guarantee the uniqueness of this identifier for
1110 each key, as it can trigger re-keying if needed.
1112 OpenVPN supports connection mobility by allowing a peer to change its
1113 IP address during an ongoing session. When configured accordingly, a
1114 host will accept authenticated packets for a session from any IP
1115 address.
1117 4.10.2. Protocol Features
1119 o Peer authentication using certificates or pre-shared key.
1121 o Mandatory mutual authentication.
1123 o Connection mobility.
1125 o Out-of-order record receipt.
1127 o Length-hiding padding.
1129 See also the properties of TLS.
1131 4.10.3. Protocol Dependencies
1133 o For control packets such as handshake and key exchange: Reliable,
1134 in-order transport. Reliability is provided either by TCP, or by
1135 OpenVPN's own reliability layer when using UDP.
1137 5. Security Features and Application Dependencies
1139 There exists a common set of features shared across the transport
1140 protocols surveyed in this document. Mandatory features constitute a
1141 baseline of functionality that an application may assume for any
1142 Transport Services implementation. They were selected on the basis
1143 that they are either (a) required for any secure transport protocol
1144 or (b) nearly ubiquitous amongst common secure transport protocols.
1146 Optional features by contrast may vary from implementation to
1147 implementation, and so an application cannot simply assume they are
1148 available. Applications learn of and use optional features by
1149 querying for their presence and support. Optional features may not
1150 be implemented, or may be disabled if their presence impacts
1151 transport services or if a necessary transport service or application
1152 dependency is unavailable.
1154 In this context, an application dependency is an aspect of the
1155 security feature which can be exposed to the application. An
1156 application dependency may be required for the security feature to
1157 function, or it may provide additional information and control to the
1158 application. For example, an application may need to provide
1159 information such as keying material or authentication credentials, or
1160 it may want to restrict which cryptographic algorithms to allow for
1161 negotiation.
1163 5.1. Mandatory Features
1165 Mandatory features must be supported regardless of transport and
1166 application services available. Note that not all mandatory features
1167 are provided by each surveyed protocol above. For example, tcpcrypt
1168 does not provide responder authentication and CurveCP does not
1169 provide forward-secure session key establishment.
1171 o Record or datagram confidentiality and integrity.
1173 * Application dependency: None.
1175 o Forward-secure session key establishment.
1177 * Application dependency: None.
1179 o Unilateral responder authentication.
1181 * (Optional) Application dependency: Application-provided trust
1182 information. System trust stores may also be used to
1183 authenticate responders.
1185 5.2. Optional Features
1187 In this section we list optional features along with their necessary
1188 application dependencies, if any.
1190 o Pre-shared key support (PSK):
1192 * Application dependency: Application provisioning and
1193 distribution of pre-shared keys.
1195 o Mutual authentication (MA):
1197 * Application dependency: Mutual authentication credentials
1198 required.
1200 o Cryptographic algorithm negotiation (AN):
1202 * Application dependency: Application awareness of supported or
1203 desired algorithms.
1205 o Application authentication delegation (AD):
1207 * Application dependency: Application opt-in and policy for
1208 endpoint authentication.
1210 o DoS mitigation (DM):
1212 * Application dependency: None.
1214 o Connection mobility (CM):
1216 * Application dependency: None.
1218 o Source validation (SV):
1220 * Application dependency: None.
1222 o Application-layer feature negotiation (AFN):
1224 * Application dependency: Specification of application-layer
1225 features or functionality.
1227 o Configuration extensions (CX):
1229 * Application dependency: Specification of application-specific
1230 extensions.
1232 o Session caching and management (SC):
1234 * Application dependency: None.
1236 o Length-hiding padding (LHP): (Optional) Application dependency:
1237 Knowledge of desired padding policies. Some protocols, such as
1238 IKE, can negotiate application-agnostic padding policies.
1240 o Early data support (ED):
1242 * Application dependency: Anti-replay protections or hints of
1243 data idempotency.
1245 o Record replay prevention (RP):
1247 * Application dependency: None.
1249 o Out-of-order receipt record (OO):
1251 * Application dependency: None.
1253 5.3. Optional Feature Availability
1255 The following table lists the availability of the above-listed
1256 optional features in each of the analyzed protocols. "Mandatory"
1257 indicates that the feature is intrinsic to the protocol and cannot be
1258 disabled. "Supported" indicates that the feature is optionally
1259 provided natively or through a (standardized, where applicable)
1260 extension.
1262 +-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+
1263 | Pro | P | A | A | M | D | C | S | A | CX | SC | LH | ED | RP | OO |
1264 | toc | S | N | D | A | M | M | V | F | | | P | | | |
1265 | ol | K | | | | | | | N | | | | | | |
1266 +-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+
1267 | TLS | S | S | S | S | S | U | M | S | S | S | S | S | U | U |
1268 | | | | | | | * | | | | | | | | |
1269 | | | | | | | | | | | | | | | |
1270 | DTL | S | S | S | S | S | S | M | S | S | S | S | U | M | M |
1271 | S | | | | | | | | | | | | | | |
1272 | | | | | | | | | | | | | | | |
1273 | QUI | S | S | S | S | S | S | M | S | S | S | S | S | M | M |
1274 | C | | | | | | | | | | | | | | |
1275 | | | | | | | | | | | | | | | |
1276 | IKE | S | S | S | M | S | S | M | S | S | S | S | U | M | M |
1277 | v2+ | | | | | | | | | | | | | | |
1278 | ESP | | | | | | | | | | | | | | |
1279 | | | | | | | | | | | | | | | |
1280 | SRT | S | S | S | S | S | U | M | S | S | S | U | U | M | M |
1281 | P+D | | | | | | | | | | | | | | |
1282 | TLS | | | | | | | | | | | | | | |
1283 | | | | | | | | | | | | | | | |
1284 | tcp | U | S | M | U | U | U | M | U | U | S | U | U | U | U |
1285 | cry | | | | | * | * | | | | | | | | |
1286 | pt | | | | | * | | | | | | | | | |
1287 | | | | | | | | | | | | | | | |
1288 | Wir | S | U | S | M | S | U | M | U | U | U | S+ | U | M | M |
1289 | eGu | | | | | | | | | | | | | | |
1290 | ard | | | | | | | | | | | | | | |
1291 | | | | | | | | | | | | | | | |
1292 | Min | U | U | U | M | S | M | M | U | U | U | S | U | U | U |
1293 | ima | | | | | | | | | | | | | | |
1294 | lT | | | | | | | | | | | | | | |
1295 | | | | | | | | | | | | | | | |
1296 | Cur | U | U | U | S | S | M | M | U | U | U | S | U | M | M |
1297 | veC | | | | | | | | | | | | | | |
1298 | P | | | | | | | | | | | | | | |
1299 +-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+
1301 M=Mandatory S=Supported but not required U=Unsupported *=On TCP;
1302 MPTCP would provide this ability **=TCP provides SYN cookies
1303 natively, but these are not cryptographically strong +=For transport
1304 packets only
1306 6. Transport Security Protocol Interfaces
1308 This section describes the interface surface exposed by the security
1309 protocols described above. Note that not all protocols support each
1310 interface. We partition these interfaces into pre-connection
1311 (configuration), connection, and post-connection interfaces,
1312 following conventions in [I-D.ietf-taps-interface] and
1313 [I-D.ietf-taps-arch].
1315 6.1. Pre-Connection Interfaces
1317 Configuration interfaces are used to configure the security protocols
1318 before a handshake begins or the keys are negotiated.
1320 o Identities and Private Keys The application can provide its
1321 identities (certificates) and private keys, or mechanisms to
1322 access these, to the security protocol to use during handshakes.
1323 Protocols: TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2,
1324 WireGuard, SRTP
1326 o Supported Algorithms (Key Exchange, Signatures, and Ciphersuites)
1327 The application can choose the algorithms that are supported for
1328 key exchange, signatures, and ciphersuites. Protocols: TLS, DTLS,
1329 QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP
1331 o Extensions (Application-Layer Protocol Negotiation): The
1332 application enables or configures extensions that are to be
1333 negotiated by the security protocol, such as ALPN [RFC7301].
1334 Protocols: TLS, DTLS, QUIC + TLS
1336 o Session Cache Management The application provides the ability to
1337 save and retrieve session state (such as tickets, keying material,
1338 and server parameters) that may be used to resume the security
1339 session. Protocols: TLS, DTLS, QUIC + TLS, MinimalT
1341 o Authentication Delegation The application provides access to a
1342 separate module that will provide authentication, using EAP for
1343 example. Protocols: IKEv2, SRTP
1345 o Pre-Shared Key Import Either the handshake protocol or the
1346 application directly can supply pre-shared keys for the record
1347 protocol use for encryption/decryption and authentication. If the
1348 application can supply keys directly, this is considered explicit
1349 import; if the handshake protocol traditionally provides the keys
1350 directly, it is considered direct import; if the keys can only be
1351 shared by the handshake, they are considered non-importable.
1353 * Explicit import: QUIC, ESP
1354 * Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard
1356 * Non-importable: CurveCP
1358 6.2. Connection Interfaces
1360 o Identity Validation During a handshake, the security protocol will
1361 conduct identity validation of the peer. This can call into the
1362 application to offload validation. Protocols: All (TLS, DTLS,
1363 QUIC + TLS, MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS))
1365 o Source Address Validation The handshake protocol may delegate
1366 validation of the remote peer that has sent data to the transport
1367 protocol or application. This involves sending a cookie exchange
1368 to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard
1370 6.3. Post-Connection Interfaces
1372 o Connection Termination The security protocol may be instructed to
1373 tear down its connection and session information. This is needed
1374 by some protocols to prevent application data truncation attacks.
1375 Protocols: TLS, DTLS, QUIC, tcpcrypt, IKEv2, MinimalT
1377 o Key Update The handshake protocol may be instructed to update its
1378 keying material, either by the application directly or by the
1379 record protocol sending a key expiration event. Protocols: TLS,
1380 DTLS, QUIC, tcpcrypt, IKEv2, MinimalT
1382 o Pre-Shared Key Export The handshake protocol will generate one or
1383 more keys to be used for record encryption/decryption and
1384 authentication. These may be explicitly exportable to the
1385 application, traditionally limited to direct export to the record
1386 protocol, or inherently non-exportable because the keys must be
1387 used directly in conjunction with the record protocol.
1389 * Explicit export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for
1390 SRTP)
1392 * Direct export: TLS, DTLS, MinimalT
1394 * Non-exportable: CurveCP
1396 o Key Expiration The record protocol can signal that its keys are
1397 expiring due to reaching a time-based deadline, or a use-based
1398 deadline (number of bytes that have been encrypted with the key).
1399 This interaction is often limited to signaling between the record
1400 layer and the handshake layer. Protocols: ESP ((Editor's note:
1401 One may consider TLS/DTLS to also have this interface))
1403 o Mobility Events The record protocol can be signaled that it is
1404 being migrated to another transport or interface due to connection
1405 mobility, which may reset address and state validation and induce
1406 state changes such as use of a new Connection Identifier (CID).
1407 Protocols: QUIC, MinimalT, CurveCP, ESP, WireGuard (roaming)
1409 7. IANA Considerations
1411 This document has no request to IANA.
1413 8. Security Considerations
1415 This document summarizes existing transport security protocols and
1416 their interfaces. It does not propose changes to or recommend usage
1417 of reference protocols. Moreover, no claims of security and privacy
1418 properties beyond those guaranteed by the protocols discussed are
1419 made. For example, metadata leakage via timing side channels and
1420 traffic analysis may compromise any protocol discussed in this
1421 survey. Applications using Security Interfaces should take such
1422 limitations into consideration when using a particular protocol
1423 implementation.
1425 9. Privacy Considerations
1427 Analysis of how features improve or degrade privacy is intentionally
1428 omitted from this survey. All security protocols surveyed generally
1429 improve privacy by reducing information leakage via encryption.
1430 However, varying amounts of metadata remain in the clear across each
1431 protocol. For example, client and server certificates are sent in
1432 cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3
1433 [RFC8446]. A survey of privacy features, or lack thereof, for
1434 various security protocols could be addressed in a separate document.
1436 10. Acknowledgments
1438 The authors would like to thank Bob Bradley, Frederic Jacobs, Mirja
1439 Kuehlewind, Yannick Sierra, Brian Trammell, and Magnus Westerlund for
1440 their input and feedback on this draft.
1442 11. Informative References
1444 [ALTS] Ghali, C., Stubblefield, A., Knapp, E., Li, J., Schmidt,
1445 B., and J. Boeuf, "Application Layer Transport Security",
1446 .
1449 [BLAKE2] Aumasson, J., Neves, S., Wilcox-O'Hearn, Z., and C.
1450 Winnerlein, "BLAKE2 -- simpler, smaller, fast as MD5",
1451 .
1453 [Curve25519]
1454 Bernstein, D., "Curve25519 - new Diffie-Hellman speed
1455 records", .
1457 [CurveCP] Bernstein, D., "CurveCP -- Usable security for the
1458 Internet", .
1460 [I-D.ietf-quic-tls]
1461 Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
1462 draft-ietf-quic-tls-23 (work in progress), September 2019.
1464 [I-D.ietf-quic-transport]
1465 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
1466 and Secure Transport", draft-ietf-quic-transport-23 (work
1467 in progress), September 2019.
1469 [I-D.ietf-rtcweb-security-arch]
1470 Rescorla, E., "WebRTC Security Architecture", draft-ietf-
1471 rtcweb-security-arch-20 (work in progress), July 2019.
1473 [I-D.ietf-taps-arch]
1474 Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G.,
1475 Perkins, C., Tiesel, P., and C. Wood, "An Architecture for
1476 Transport Services", draft-ietf-taps-arch-04 (work in
1477 progress), July 2019.
1479 [I-D.ietf-taps-interface]
1480 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G.,
1481 Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T.
1482 Pauly, "An Abstract Application Layer Interface to
1483 Transport Services", draft-ietf-taps-interface-04 (work in
1484 progress), July 2019.
1486 [I-D.ietf-taps-minset]
1487 Welzl, M. and S. Gjessing, "A Minimal Set of Transport
1488 Services for End Systems", draft-ietf-taps-minset-11 (work
1489 in progress), September 2018.
1491 [I-D.ietf-tls-dtls-connection-id]
1492 Rescorla, E., Tschofenig, H., and T. Fossati, "Connection
1493 Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection-
1494 id-06 (work in progress), July 2019.
1496 [I-D.ietf-tls-dtls13]
1497 Rescorla, E., Tschofenig, H., and N. Modadugu, "The
1498 Datagram Transport Layer Security (DTLS) Protocol Version
1499 1.3", draft-ietf-tls-dtls13-32 (work in progress), July
1500 2019.
1502 [MinimalT]
1503 Petullo, W., Zhang, X., Solworth, J., Bernstein, D., and
1504 T. Lange, "MinimaLT -- Minimal-latency Networking Through
1505 Better Security",
1506 .
1508 [Noise] Perrin, T., "The Noise Protocol Framework",
1509 .
1511 [OpenVPN] "OpenVPN cryptographic layer", .
1514 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
1515 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
1516 1998, .
1518 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
1519 Headers for Low-Speed Serial Links", RFC 2508,
1520 DOI 10.17487/RFC2508, February 1999,
1521 .
1523 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
1524 A., Peterson, J., Sparks, R., Handley, M., and E.
1525 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
1526 DOI 10.17487/RFC3261, June 2002,
1527 .
1529 [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and
1530 P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with
1531 High Delay, Packet Loss and Reordering", RFC 3545,
1532 DOI 10.17487/RFC3545, July 2003,
1533 .
1535 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
1536 Norrman, "The Secure Real-time Transport Protocol (SRTP)",
1537 RFC 3711, DOI 10.17487/RFC3711, March 2004,
1538 .
1540 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
1541 Stenberg, "UDP Encapsulation of IPsec ESP Packets",
1542 RFC 3948, DOI 10.17487/RFC3948, January 2005,
1543 .
1545 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
1546 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
1547 January 2006, .
1549 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
1550 DOI 10.17487/RFC4302, December 2005,
1551 .
1553 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
1554 RFC 4303, DOI 10.17487/RFC4303, December 2005,
1555 .
1557 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
1558 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
1559 .
1561 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1562 (TLS) Protocol Version 1.2", RFC 5246,
1563 DOI 10.17487/RFC5246, August 2008,
1564 .
1566 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
1567 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
1568 DOI 10.17487/RFC5723, January 2010,
1569 .
1571 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
1572 for Establishing a Secure Real-time Transport Protocol
1573 (SRTP) Security Context Using Datagram Transport Layer
1574 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
1575 2010, .
1577 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
1578 Security (DTLS) Extension to Establish Keys for the Secure
1579 Real-time Transport Protocol (SRTP)", RFC 5764,
1580 DOI 10.17487/RFC5764, May 2010,
1581 .
1583 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
1584 Key Derivation Function (HKDF)", RFC 5869,
1585 DOI 10.17487/RFC5869, May 2010,
1586 .
1588 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
1589 Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
1590 June 2010, .
1592 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
1593 Extensions: Extension Definitions", RFC 6066,
1594 DOI 10.17487/RFC6066, January 2011,
1595 .
1597 [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
1598 Media Path Key Agreement for Unicast Secure RTP",
1599 RFC 6189, DOI 10.17487/RFC6189, April 2011,
1600 .
1602 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
1603 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
1604 January 2012, .
1606 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
1607 Weiler, S., and T. Kivinen, "Using Raw Public Keys in
1608 Transport Layer Security (TLS) and Datagram Transport
1609 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
1610 June 2014, .
1612 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
1613 Kivinen, "Internet Key Exchange Protocol Version 2
1614 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
1615 2014, .
1617 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
1618 "Transport Layer Security (TLS) Application-Layer Protocol
1619 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
1620 July 2014, .
1622 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
1623 Ed., "Services Provided by IETF Transport Protocols and
1624 Congestion Control Mechanisms", RFC 8095,
1625 DOI 10.17487/RFC8095, March 2017,
1626 .
1628 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
1629 "Authenticated Identity Management in the Session
1630 Initiation Protocol (SIP)", RFC 8224,
1631 DOI 10.17487/RFC8224, February 2018,
1632 .
1634 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
1635 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
1636 August 2017, .
1638 [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
1639 Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
1640 .
1642 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1643 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1644 .
1646 [RFC8449] Thomson, M., "Record Size Limit Extension for TLS",
1647 RFC 8449, DOI 10.17487/RFC8449, August 2018,
1648 .
1650 [RFC8547] Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E.
1651 Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547,
1652 DOI 10.17487/RFC8547, May 2019,
1653 .
1655 [RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
1656 Q., and E. Smith, "Cryptographic Protection of TCP Streams
1657 (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019,
1658 .
1660 [SIGMA] Krawczyk, H., "SIGMA -- The 'SIGn-and-MAc' Approach to
1661 Authenticated Diffie-Hellman and Its Use in the IKE-
1662 Protocols", .
1665 [WireGuard]
1666 Donenfeld, J., "WireGuard -- Next Generation Kernel
1667 Network Tunnel",
1668 .
1670 Authors' Addresses
1672 Christopher A. Wood (editor)
1673 Apple Inc.
1674 One Apple Park Way
1675 Cupertino, California 95014
1676 United States of America
1678 Email: cawood@apple.com
1679 Theresa Enghardt
1680 TU Berlin
1681 Marchstr. 23
1682 10587 Berlin
1683 Germany
1685 Email: theresa@inet.tu-berlin.de
1687 Tommy Pauly
1688 Apple Inc.
1689 One Apple Park Way
1690 Cupertino, California 95014
1691 United States of America
1693 Email: tpauly@apple.com
1695 Colin Perkins
1696 University of Glasgow
1697 School of Computing Science
1698 Glasgow G12 8QQ
1699 United Kingdom
1701 Email: csp@csperkins.org
1703 Kyle Rose
1704 Akamai Technologies, Inc.
1705 150 Broadway
1706 Cambridge, MA 02144
1707 United States of America
1709 Email: krose@krose.org