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