idnits 2.17.1 draft-ietf-taps-transport-security-02.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8095]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1312: '...g Security Interfaces SHOULD take such...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 30, 2018) is 2126 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-tls-dtls13' is defined on line 1370, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-13 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-13 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-14 == Outdated reference: A later version (-19) exists of draft-ietf-taps-arch-00 == Outdated reference: A later version (-15) exists of draft-ietf-tcpinc-tcpcrypt-12 == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-00 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-26 ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7539 (Obsoleted by RFC 8439) ** Obsolete normative reference: RFC 8229 (Obsoleted by RFC 9329) Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Pauly 3 Internet-Draft Apple Inc. 4 Intended status: Informational C. Perkins 5 Expires: January 1, 2019 University of Glasgow 6 K. Rose 7 Akamai Technologies, Inc. 8 C. Wood 9 Apple Inc. 10 June 30, 2018 12 A Survey of Transport Security Protocols 13 draft-ietf-taps-transport-security-02 15 Abstract 17 This document provides a survey of commonly used or notable network 18 security protocols, with a focus on how they interact and integrate 19 with applications and transport protocols. Its goal is to supplement 20 efforts to define and catalog transport services [RFC8095] by 21 describing the interfaces required to add security protocols. It 22 examines Transport Layer Security (TLS), Datagram Transport Layer 23 Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + 24 TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with 25 Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and 26 WireGuard. This survey is not limited to protocols developed within 27 the scope or context of the IETF, and those included represent a 28 superset of features a TAPS system may need to support. 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 January 1, 2019. 47 Copyright Notice 49 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Transport Security Protocol Descriptions . . . . . . . . . . 7 68 4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.1.1. Protocol Description . . . . . . . . . . . . . . . . 7 70 4.1.2. Protocol Features . . . . . . . . . . . . . . . . . . 8 71 4.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 9 72 4.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.2.1. Protocol Description . . . . . . . . . . . . . . . . 9 74 4.2.2. Protocol Features . . . . . . . . . . . . . . . . . . 10 75 4.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10 76 4.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 10 77 4.3.1. Protocol Description . . . . . . . . . . . . . . . . 10 78 4.3.2. Protocol Features . . . . . . . . . . . . . . . . . . 11 79 4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 11 80 4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 11 81 4.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 12 82 4.4.1. Protocol descriptions . . . . . . . . . . . . . . . . 12 83 4.4.2. Protocol features . . . . . . . . . . . . . . . . . . 13 84 4.4.3. Protocol dependencies . . . . . . . . . . . . . . . . 14 85 4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 14 86 4.5.1. Protocol description . . . . . . . . . . . . . . . . 14 87 4.5.2. Protocol features . . . . . . . . . . . . . . . . . . 15 88 4.5.3. Protocol dependencies . . . . . . . . . . . . . . . . 16 89 4.5.4. Variant: ZRTP for Media Path Key Agreement . . . . . 16 90 4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 16 91 4.6.1. Protocol Description . . . . . . . . . . . . . . . . 16 92 4.6.2. Protocol Features . . . . . . . . . . . . . . . . . . 17 93 4.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 18 94 4.7. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 18 95 4.7.1. Protocol description . . . . . . . . . . . . . . . . 18 96 4.7.2. Protocol features . . . . . . . . . . . . . . . . . . 19 97 4.7.3. Protocol dependencies . . . . . . . . . . . . . . . . 19 98 4.8. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 19 99 4.8.1. Protocol Description . . . . . . . . . . . . . . . . 19 100 4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 20 101 4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 20 102 4.9. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 20 103 4.9.1. Protocol Description . . . . . . . . . . . . . . . . 20 104 4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 22 105 4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 22 106 5. Security Features and Transport Dependencies . . . . . . . . 22 107 5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 22 108 5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 23 109 5.3. Optional Feature Availability . . . . . . . . . . . . . . 25 110 6. Transport Security Protocol Interfaces . . . . . . . . . . . 25 111 6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 26 112 6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 27 113 6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 27 114 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 115 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 116 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 117 10. Normative References . . . . . . . . . . . . . . . . . . . . 28 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 120 1. Introduction 122 This document provides a survey of commonly used or notable network 123 security protocols, with a focus on how they interact and integrate 124 with applications and transport protocols. Its goal is to supplement 125 efforts to define and catalog transport services [RFC8095] by 126 describing the interfaces required to add security protocols. It 127 examines Transport Layer Security (TLS), Datagram Transport Layer 128 Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + 129 TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with 130 Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and 131 WireGuard. For each protocol, this document provides a brief 132 description, the security features it provides, and the dependencies 133 it has on the underlying transport. This is followed by defining the 134 set of transport security features shared by these protocols. 135 Finally, we distill the application and transport interfaces provided 136 by the transport security protocols. 138 Selected protocols represent a superset of functionality and features 139 a TAPS system may need to support, both internally and externally - 140 via an API - for applications [I-D.ietf-taps-arch]. Ubiquitous IETF 141 protocols such as (D)TLS, as well as non-standard protocols such as 142 Google QUIC, are both included despite overlapping features. As 143 such, this survey is not limited to protocols developed within the 144 scope or context of the IETF. Outside of this candidate set, 145 protocols that do not offer new features are omitted. For example, 146 newer protocols such as WireGuard make unique design choices that 147 have important implications on applications, such as how to best 148 configure peer public keys and to delegate algorithm selection to the 149 system. In contrast, protocols such as ALTS [ALTS] are omitted since 150 they do not represent features deemed unique. 152 Also, authentication-only protocols such as TCP-AO [RFC5925] and 153 IPsec AH [RFC4302] are excluded from this survey. TCP-AO adds 154 authenticity protections to long-lived TCP connections, e.g., replay 155 protection with per-packet Message Authentication Codes. (This 156 protocol obsoletes TCP MD5 "signature" options specified in 157 [RFC2385].) One prime use case of TCP-AO is for protecting BGP 158 connections. Similarly, AH adds per-datagram authenticity and adds 159 similar replay protection. Despite these improvements, neither 160 protocol sees general use and both lack critical properties important 161 for emergent transport security protocols: confidentiality, privacy 162 protections, and agility. Thus, we omit these and related protocols 163 from our survey. 165 2. Terminology 167 The following terms are used throughout this document to describe the 168 roles and interactions of transport security protocols: 170 o Transport Feature: a specific end-to-end feature that the 171 transport layer provides to an application. Examples include 172 confidentiality, reliable delivery, ordered delivery, message- 173 versus-stream orientation, etc. 175 o Transport Service: a set of Transport Features, without an 176 association to any given framing protocol, which provides 177 functionality to an application. 179 o Transport Protocol: an implementation that provides one or more 180 different transport services using a specific framing and header 181 format on the wire. A Transport Protocol services an application. 183 o Application: an entity that uses a transport protocol for end-to- 184 end delivery of data across the network. This may also be an 185 upper layer protocol or tunnel encapsulation. 187 o Security Feature: a feature that a network security layer provides 188 to applications. Examples include authentication, encryption, key 189 generation, session resumption, and privacy. Features may be 190 Mandatory or Optional for an application's implementation. 192 o Security Protocol: a defined network protocol that implements one 193 or more security features. Security protocols may be used 194 alongside transport protocols, and in combination with other 195 security protocols when appropriate. 197 o Handshake Protocol: a protocol that enables peers to validate each 198 other and to securely establish shared cryptographic context. 200 o Record Protocol: a security protocol that allows data to be 201 divided into manageable blocks and protected using shared 202 cryptographic context. 204 o Session: an ephemeral security association between applications. 206 o Cryptographic context: a set of cryptographic parameters, 207 including but not necessarily limited to keys for encryption, 208 authentication, and session resumption, enabling authorized 209 parties to a session to communicate securely. 211 o Connection: the shared state of two or more endpoints that 212 persists across messages that are transmitted between these 213 endpoints. A connection is a transient participant of a session, 214 and a session generally lasts between connection instances. 216 o Connection Mobility: a property of a connection that allows it to 217 be multihomed or resilient across network interface or address 218 changes. 220 o Peer: an endpoint application party to a session. 222 o Client: the peer responsible for initiating a session. 224 o Server: the peer responsible for responding to a session 225 initiation. 227 3. Security Features 229 In this section, we enumerate Security Features exposed by protocols 230 discussed in the remainder of this document. Protocol security 231 properties that are unrelated to the API surface exposed by such 232 protocols, such as client or server identity hiding, are not listed 233 here as features. 235 o Forward-secure key establishment: Cryptographic key establishment 236 with forward secure properties. 238 o Cryptographic algorithm negotiation: Negotiate support of protocol 239 algorithms, including: encryption, hash, MAC (PRF), and digital 240 signature algorithms. 242 o Stateful and stateless cross-connection session resumption: 243 Connection establishment without needing to complete an entirely 244 new handshake. 246 o Peer authentication (certificate, raw public key, pre-shared key, 247 or EAP-based): Peer authentication using select or protocol- 248 specific mechanisms. 250 o Mutual authentication: Connection establishment wherein both 251 endpoints are authenticated. 253 o Record (channel or datagram) confidentiality and integrity: 254 Encryption and authentication of application plaintext bytes sent 255 between peers over a channel or in individual datagrams. 257 o Partial record confidentiality: Encryption of some portion of 258 records. 260 o Optional record integrity: Optional authentication of certain 261 records. 263 o Record replay prevention: Protocol detection and defense against 264 record replays, e.g., due to in-network retransmissions. 266 o Application-layer feature negotiation: Securely negotiate 267 application-specific functionality. 269 o Early data support (starting with TLS 1.3): Transmission of 270 application data prior to connection (handshake) establishment. 272 o Connection mobility: Connection continuation in the presence of 273 5-tuple changes beneath the secure transport protocol, e.g., due 274 to NAT rebindings. 276 o Application-layer authentication delegation: Out-of-band peer 277 authentication performed by applications outside of the connection 278 establishment. 280 o Out-of-order record receipt: Processing of records received out- 281 of-order. 283 o DoS mitigation (cookie or puzzle based): Peer DoS mitigation via 284 explicit proof of origin (cookie) or work mechanisms (puzzles). 286 o Connection re-keying: In-band cryptographic handshake re-keying. 288 o Optional length-hiding and anti-amplification padding: Protocol- 289 drive record padding aimed at hiding plaintext message length and 290 mitigating amplification attack vectors. 292 4. Transport Security Protocol Descriptions 294 This section contains descriptions of security protocols currently 295 used to protect data being sent over a network. 297 For each protocol, we describe its provided features and dependencies 298 on other protocols. 300 4.1. TLS 302 TLS (Transport Layer Security) [RFC5246] is a common protocol used to 303 establish a secure session between two endpoints. Communication over 304 this session "prevents eavesdropping, tampering, and message 305 forgery." TLS consists of a tightly coupled handshake and record 306 protocol. The handshake protocol is used to authenticate peers, 307 negotiate protocol options, such as cryptographic algorithms, and 308 derive session-specific keying material. The record protocol is used 309 to marshal (possibly encrypted) data from one peer to the other. 310 This data may contain handshake messages or raw application data. 312 4.1.1. Protocol Description 314 TLS is the composition of a handshake and record protocol 315 [I-D.ietf-tls-tls13]. The record protocol is designed to marshal an 316 arbitrary, in-order stream of bytes from one endpoint to the other. 317 It handles segmenting, compressing (when enabled), and encrypting 318 data into discrete records. When configured to use an authenticated 319 encryption with associated data (AEAD) algorithm, it also handles 320 nonce generation and encoding for each record. The record protocol 321 is hidden from the client behind a bytestream-oriented API. 323 The handshake protocol serves several purposes, including: peer 324 authentication, protocol option (key exchange algorithm and 325 ciphersuite) negotiation, and key derivation. Peer authentication 326 may be mutual; however, commonly, only the server is authenticated. 327 X.509 certificates are commonly used in this authentication step, 328 though other mechanisms, such as raw public keys [RFC7250], exist. 329 The client is not authenticated unless explicitly requested by the 330 server with a CertificateRequest handshake message. Assuming strong 331 cryptography, an infrastructure for trust establishment, correctly- 332 functioning endpoints, and communication patterns free from side 333 channels, server authentication is sufficient to establish a channel 334 resistant to eavesdroppers. 336 The handshake protocol is also extensible. It allows for a variety 337 of extensions to be included by either the client or server. These 338 extensions are used to specify client preferences, e.g., the 339 application-layer protocol to be driven with the TLS connection 340 [RFC7301], or signals to the server to aid operation, e.g., Server 341 Name Indication (SNI) [RFC6066]. Various extensions also exist to 342 tune the parameters of the record protocol, e.g., the maximum 343 fragment length [RFC6066]. 345 Alerts are used to convey errors and other atypical events to the 346 endpoints. There are two classes of alerts: closure and error 347 alerts. A closure alert is used to signal to the other peer that the 348 sender wishes to terminate the connection. The sender typically 349 follows a close alert with a TCP FIN segment to close the connection. 350 Error alerts are used to indicate problems with the handshake or 351 individual records. Most errors are fatal and are followed by 352 connection termination. However, warning alerts may be handled at 353 the discretion of the implementation. 355 Once a session is disconnected all session keying material must be 356 destroyed, with the exception of secrets previously established 357 expressly for purposes of session resumption. TLS supports stateful 358 and stateless resumption. (Here, "state" refers to bookkeeping on a 359 per-session basis by the server. It is assumed that the client must 360 always store some state information in order to resume a session.) 362 4.1.2. Protocol Features 364 o Forward-secure key establishment. 366 o Cryptographic algorithm negotiation. 368 o Stateful and stateless cross-connection session resumption. 370 o Peer authentication (Certificate, raw public key, and pre-shared 371 key). 373 o Mandatory server authentication, optional client authentication. 375 o Record (channel) confidentiality and integrity. 377 o Record replay prevention. 379 o Application-layer feature negotiation. 381 o Early data support (starting with TLS 1.3). 383 o Optional length-hiding padding (starting with TLS 1.3). 385 4.1.3. Protocol Dependencies 387 o TCP for in-order, reliable transport. 389 o (Optionally) A PKI trust store for certificate validation. 391 4.2. DTLS 393 DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS, 394 but differs in that it is designed to run over UDP instead of TCP. 395 Since UDP does not guarantee datagram ordering or reliability, DTLS 396 modifies the protocol to make sure it can still provide the same 397 security guarantees as TLS. DTLS was designed to be as close to TLS 398 as possible, so this document will assume that all properties from 399 TLS are carried over except where specified. 401 4.2.1. Protocol Description 403 DTLS is modified from TLS to operate with the possibility of packet 404 loss, reordering, and duplication that may occur when operating over 405 UDP. To enable out-of-order delivery of application data, the DTLS 406 record protocol itself has no inter-record dependencies. However, as 407 the handshake requires reliability, each handshake message is 408 assigned an explicit sequence number to enable retransmissions of 409 lost packets and in-order processing by the receiver. Handshake 410 message loss is remedied by sender retransmission after a 411 configurable period in which the expected response has not yet been 412 received. 414 As the DTLS handshake protocol runs atop the record protocol, to 415 account for long handshake messages that cannot fit within a single 416 record, DTLS supports fragmentation and subsequent reconstruction of 417 handshake messages across records. The receiver must reassemble 418 records before processing. 420 DTLS relies on unique UDP 4-tuples to identify connections. Since 421 all application-layer data is encrypted, demultiplexing over the same 422 4-tuple requires the use of a connection identifier extension 423 [I-D.ietf-tls-dtls-connection-id] to permit identification of the 424 correct connection-specific cryptographic context without the use of 425 trial decryption. (Note that this extension is only supported in 426 DTLS 1.2 and 1.3 {{I-D.ietf-tls-dtls13}.) 427 Since datagrams can be replayed, DTLS provides optional anti-replay 428 detection based on a window of acceptable sequence numbers [RFC6347]. 430 4.2.2. Protocol Features 432 o Record replay protection. 434 o Record (datagram) confidentiality and integrity. 436 o Out-of-order record receipt. 438 o DoS mitigation (cookie-based). 440 See also the features from TLS. 442 4.2.3. Protocol Dependencies 444 o Since DTLS runs over an unreliable, unordered datagram transport, 445 it does not require any reliability features. 447 o The DTLS record protocol explicitly encodes record lengths, so 448 although it runs over a datagram transport, it does not rely on 449 the transport protocol's framing beyond requiring transport-level 450 reconstruction of datagrams fragmented over packets. (Note: DTLS 451 1.3 short header records omit the explicit length field.) 453 o UDP 4-tuple uniqueness, or the connection identifier extension, 454 for demultiplexing. 456 o Path MTU discovery. 458 4.3. (IETF) QUIC with TLS 460 QUIC (Quick UDP Internet Connections) is a new standards-track 461 transport protocol that runs over UDP, loosely based on Google's 462 original proprietary gQUIC protocol [I-D.ietf-quic-transport]. (See 463 Section 4.3.4 for more details.) The QUIC transport layer itself 464 provides support for data confidentiality and integrity. This 465 requires keys to be derived with a separate handshake protocol. A 466 mapping for QUIC over TLS 1.3 [I-D.ietf-quic-tls] has been specified 467 to provide this handshake. 469 4.3.1. Protocol Description 471 As QUIC relies on TLS to secure its transport functions, it creates 472 specific integration points between its security and transport 473 functions: 475 o Starting the handshake to generate keys and provide authentication 476 (and providing the transport for the handshake). 478 o Client address validation. 480 o Key ready events from TLS to notify the QUIC transport. 482 o Exporting secrets from TLS to the QUIC transport. 484 The QUIC transport layer support multiple streams over a single 485 connection. The first stream is reserved specifically for a TLS 486 connection. The TLS handshake, along with further records, are sent 487 over this stream. This TLS connection follows the TLS standards and 488 inherits the security properties of TLS. The handshake generates 489 keys, which are then exported to the rest of the QUIC connection, and 490 are used to protect the rest of the streams. 492 Initial QUIC messages (packets) are encrypted using "fixed" keys 493 derived from the QUIC version and public packet information 494 (Connection ID). Packets are later encrypted using keys derived from 495 the TLS traffic secret upon handshake completion. The TLS 1.3 496 handshake for QUIC is used in either a single-RTT mode or a fast-open 497 zero-RTT mode. When zero-RTT handshakes are possible, the encryption 498 first transitions to use the zero-RTT keys before using single-RTT 499 handshake keys after the next TLS flight. 501 4.3.2. Protocol Features 503 o DoS mitigation (cookie-based). 505 See also the properties of TLS. 507 4.3.3. Protocol Dependencies 509 o QUIC transport relies on UDP. 511 o QUIC transport relies on TLS 1.3 for peer authentication and 512 initial key derivation. 514 o TLS within QUIC relies on QUIC for reliable handshake record 515 transmission and receipt. 517 4.3.4. Variant: Google QUIC 519 Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol 520 designed and deployed by Google following experience from deploying 521 SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally 522 known as "QUIC": this document uses gQUIC to unambiguously 523 distinguish it from the standards-track IETF QUIC. The proprietary 524 technical forebear of IETF QUIC, gQUIC was originally designed with 525 tightly-integrated security and application data transport protocols. 527 4.4. IKEv2 with ESP 529 IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec 530 protocol suite that encrypts and authenticates IP packets, either as 531 for creating tunnels (tunnel-mode) or for direct transport 532 connections (transport-mode). This suite of protocols separates out 533 the key generation protocol (IKEv2) from the transport encryption 534 protocol (ESP). Each protocol can be used independently, but this 535 document considers them together, since that is the most common 536 pattern. 538 4.4.1. Protocol descriptions 540 4.4.1.1. IKEv2 542 IKEv2 is a control protocol that runs on UDP port 500. Its primary 543 goal is to generate keys for Security Associations (SAs). An SA 544 contains shared (cryptographic) information used for establishing 545 other SAs or keying ESP; See Section 4.4.1.2. IKEv2 first uses a 546 Diffie-Hellman key exchange to generate keys for the "IKE SA", which 547 is a set of keys used to encrypt further IKEv2 messages. It then 548 goes through a phase of authentication in which both peers present 549 blobs signed by a shared secret or private key, after which another 550 set of keys is derived, referred to as the "Child SA". These Child 551 SA keys are used by ESP. 553 IKEv2 negotiates which protocols are acceptable to each peer for both 554 the IKE and Child SAs using "Proposals". Each proposal may contain 555 an encryption algorithm, an authentication algorithm, a Diffie- 556 Hellman group, and (for IKE SAs only) a pseudorandom function 557 algorithm. Each peer may support multiple proposals, and the most 558 preferred mutually supported proposal is chosen during the handshake. 560 The authentication phase of IKEv2 may use Shared Secrets, 561 Certificates, Digital Signatures, or an EAP (Extensible 562 Authentication Protocol) method. At a minimum, IKEv2 takes two round 563 trips to set up both an IKE SA and a Child SA. If EAP is used, this 564 exchange may be expanded. 566 Any SA used by IKEv2 can be rekeyed upon expiration, which is usually 567 based either on time or number of bytes encrypted. 569 There is an extension to IKEv2 that allows session resumption 570 [RFC5723]. 572 MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a 573 set of Security Associations to migrate over different addresses and 574 interfaces [RFC4555]. 576 When UDP is not available or well-supported on a network, IKEv2 may 577 be encapsulated in TCP [RFC8229]. 579 4.4.1.2. ESP 581 ESP is a protocol that encrypts and authenticates IPv4 and IPv6 582 packets. The keys used for both encryption and authentication can be 583 derived from an IKEv2 exchange. ESP Security Associations come as 584 pairs, one for each direction between two peers. Each SA is 585 identified by a Security Parameter Index (SPI), which is marked on 586 each encrypted ESP packet. 588 ESP packets include the SPI, a sequence number, an optional 589 Initialization Vector (IV), payload data, padding, a length and next 590 header field, and an Integrity Check Value. 592 From [RFC4303], "ESP is used to provide confidentiality, data origin 593 authentication, connectionless integrity, an anti-replay service (a 594 form of partial sequence integrity), and limited traffic flow 595 confidentiality." 597 Since ESP operates on IP packets, it is not directly tied to the 598 transport protocols it encrypts. This means it requires little or no 599 change from transports in order to provide security. 601 ESP packets may be sent directly over IP, but where network 602 conditions warrant (e.g., when a NAT is present or when a firewall 603 blocks such packets) they may be encapsulated in UDP [RFC3948] or TCP 604 [RFC8229]. 606 4.4.2. Protocol features 608 4.4.2.1. IKEv2 610 o Forward-secure key establishment. 612 o Cryptographic algorithm negotiation. 614 o Peer authentication (Certificate, raw public key, pre-shared key, 615 and EAP). 617 o Mutual authentication. 619 o Record (datagram) confidentiality and integrity. 621 o Session resumption. 623 o Connection mobility. 625 o DoS mitigation (cookie-based). 627 4.4.2.2. ESP 629 o Record confidentiality and integrity. 631 o Record replay protection. 633 4.4.3. Protocol dependencies 635 4.4.3.1. IKEv2 637 o Availability of UDP to negotiate, or implementation support for 638 TCP-encapsulation. 640 o Some EAP authentication types require accessing a hardware device, 641 such as a SIM card; or interacting with a user, such as password 642 prompting. 644 4.4.3.2. ESP 646 o Since ESP is below transport protocols, it does not have any 647 dependencies on the transports themselves, other than on UDP or 648 TCP where encapsulation is employed. 650 4.5. Secure RTP (with DTLS) 652 Secure RTP (SRTP) is a profile for RTP that provides confidentiality, 653 message authentication, and replay protection for RTP data packets 654 and RTP control protocol (RTCP) packets [RFC3711]. 656 4.5.1. Protocol description 658 SRTP adds confidentiality and optional integrity protection to RTP 659 data packets, and adds confidentially and mandatory integrity 660 protection to RTCP packets. For RTP data packets, this is done by 661 encrypting the payload section of the packet and optionally appending 662 an authentication tag (MAC) as a packet trailer, with the RTP header 663 authenticated but not encrypted (the RTP header was left unencrypted 664 to enable RTP header compression [RFC2508] [RFC3545]). For RTCP 665 packets, the first packet in the compound RTCP packet is partially 666 encrypted, leaving the first eight octets of the header as clear-text 667 to allow identification of the packet as RTCP, while the remainder of 668 the compound packet is fully encrypted. The entire RTCP packet is 669 then authenticated by appending a MAC as packet trailer. 671 Packets are encrypted using session keys, which are ultimately 672 derived from a master key and an additional master salt and session 673 salt. SRTP packets carry a 2-byte sequence number to partially 674 identify the unique packet index. SRTP peers maintain a separate 675 roll-over counter (ROC) for RTP data packets that is incremented 676 whenever the sequence number wraps. The sequence number and ROC 677 together determine the packet index. RTCP packets have a similar, 678 yet differently named, field called the RTCP index which serves the 679 same purpose. 681 Numerous encryption modes are supported. For popular modes of 682 operation, e.g., AES-CTR, the (unique) initialization vector (IV) 683 used for each encryption mode is a function of the RTP SSRC 684 (synchronization source), packet index, and session "salting key". 686 SRTP offers replay detection by keeping a replay list of already seen 687 and processed packet indices. If a packet arrives with an index that 688 matches one in the replay list, it is silently discarded. 690 DTLS [RFC5764] is commonly used to perform mutual authentication and 691 key agreement for SRTP [RFC5763]. Peers use DTLS to perform mutual 692 certificate-based authentication on the media path, and to generate 693 the SRTP master key. Peer certificates can be issued and signed by a 694 certificate authority. Alternatively, certificates used in the DTLS 695 exchange can be self-signed. If they are self-signed, certificate 696 fingerprints are included in the signalling exchange (e.g., in SIP or 697 WebRTC), and used to bind the DTLS key exchange in the media plane to 698 the signaling plane. The combination of a mutually authenticated 699 DTLS key exchange on the media path and a fingerprint sent in the 700 signalling channel protects against active attacks on the media, 701 provided the signalling can be trusted. Signalling needs to be 702 protected as described in, for example, SIP [RFC3261] Authenticated 703 Identity Management [RFC4474] or the WebRTC security architecture 704 [I-D.ietf-rtcweb-security-arch], to provide complete system security. 706 4.5.2. Protocol features 708 o Forward-secure key establishment. 710 o Cryptographic algorithm negotiation. 712 o Mutual authentication. 714 o Partial datagram confidentiality. (Packet headers are not 715 encrypted.) 717 o Optional authentication of data packets. 719 o Mandatory authentication of control packets. 721 o Out-of-order record receipt. 723 4.5.3. Protocol dependencies 725 o External key derivation and management protocol, e.g., DTLS 726 [RFC5763]. 728 o External identity management protocol, e.g., SIP Authenticated 729 Identity Management [RFC4474], WebRTC Security Architecture 730 [I-D.ietf-rtcweb-security-arch]. 732 4.5.4. Variant: ZRTP for Media Path Key Agreement 734 ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It 735 uses standard SRTP to protect RTP data packets and RTCP packets, but 736 provides alternative key agreement and identity management protocols. 738 Key agreement is performed using a Diffie-Hellman key exchange that 739 runs on the media path. This generates a shared secret that is then 740 used to generate the master key and salt for SRTP. 742 ZRTP does not rely on a PKI or external identity management system. 743 Rather, it uses an ephemeral Diffie-Hellman key exchange with hash 744 commitment to allow detection of man-in-the-middle attacks. This 745 requires endpoints to display a short authentication string that the 746 users must read and verbally compare to validate the hashes and 747 ensure security. Endpoints cache some key material after the first 748 call to use in subsequent calls; this is mixed in with the Diffie- 749 Hellman shared secret, so the short authentication string need only 750 be checked once for a given user. This gives key continuity 751 properties analogous to the secure shell (ssh) [RFC4253]. 753 4.6. tcpcrypt 755 Tcpcrypt is a lightweight extension to the TCP protocol to enable 756 opportunistic encryption with hooks available to the application 757 layer for implementation of endpoint authentication. 759 4.6.1. Protocol Description 761 Tcpcrypt extends TCP to enable opportunistic encryption between the 762 two ends of a TCP connection [I-D.ietf-tcpinc-tcpcrypt]. It is a 763 family of TCP encryption protocols (TEP), distinguished by key 764 exchange algorithm. The use of a TEP is negotiated with a TCP option 765 during the initial TCP handshake via the mechanism described by TCP 766 Encryption Negotiation Option (ENO) [I-D.ietf-tcpinc-tcpeno]. In the 767 case of initial session establishment, once a tcpcrypt TEP has been 768 negotiated the key exchange occurs within the data segments of the 769 first few packets exchanged after the handshake completes. The 770 initiator of a connection sends a list of supported AEAD algorithms, 771 a random nonce, and an ephemeral public key share. The responder 772 typically chooses a mutually-supported AEAD algorithm and replies 773 with this choice, its own nonce, and ephemeral key share. An initial 774 shared secret is derived from the ENO handshake, the tcpcrypt 775 handshake, and the initial keying material resulting from the key 776 exchange. The traffic encryption keys on the initial connection are 777 derived from the shared secret. Connections can be re-keyed before 778 the natural AEAD limit for a single set of traffic encryption keys is 779 reached. 781 Each tcpcrypt session is associated with a ladder of resumption IDs, 782 each derived from the respective entry in a ladder of shared secrets. 783 These resumption IDs can be used to negotiate a stateful resumption 784 of the session in a subsequent connection, resulting in use of a new 785 shared secret and traffic encryption keys without requiring a new key 786 exchange. Willingness to resume a session is signaled via the ENO 787 option during the TCP handshake. Given the length constraints 788 imposed by TCP options, unlike stateless resumption mechanisms (such 789 as that provided by session tickets in TLS) resumption in tcpcrypt 790 requires the maintenance of state on the server, and so successful 791 resumption across a pool of servers implies shared state. 793 Owing to middlebox ossification issues, tcpcrypt only protects the 794 payload portion of a TCP packet. It does not encrypt any header 795 information, such as the TCP sequence number. 797 Tcpcrypt exposes a universally-unique connection-specific session ID 798 to the application, suitable for application-level endpoint 799 authentication either in-band or out-of-band. 801 4.6.2. Protocol Features 803 o Forward-secure key establishment. 805 o Record (channel) confidentiality and integrity. 807 o Stateful cross-connection session resumption. 809 o Connection re-keying. 811 o Application authentication delegation. 813 4.6.3. Protocol Dependencies 815 o TCP 817 o TCP Encryption Negotiation Option (ENO) 819 4.7. WireGuard 821 WireGuard is a layer 3 protocol designed to complement or replace 822 IPsec [WireGuard]. Unlike most transport security protocols, which 823 rely on PKI for peer authentication, WireGuard authenticates peers 824 using pre-shared public keys delivered out-of-band, each of which is 825 bound to one or more IP addresses. Moreover, as a protocol suited 826 for VPNs, WireGuard offers no extensibility, negotiation, or 827 cryptographic agility. 829 4.7.1. Protocol description 831 WireGuard is a simple VPN protocol that binds a pre-shared public key 832 to one or more IP addresses. Users configure WireGuard by 833 associating peer public keys with IP addresses. These mappings are 834 stored in a CryptoKey Routing Table. (See Section 2 of [WireGuard] 835 for more details and sample configurations.) These keys are used 836 upon WireGuard packet transmission and reception. For example, upon 837 receipt of a Handshake Initiation message, receivers use the static 838 public key in their CryptoKey routing table to perform necessary 839 cryptographic computations. 841 WireGuard builds on Noise [Noise] for 1-RTT key exchange with 842 identity hiding. The handshake hides peer identities as per the 843 SIGMA construction [SIGMA]. As a consequence of using Noise, 844 WireGuard comes with a fixed set of cryptographic algorithms: 846 o x25519 [Curve25519] and HKDF [RFC5869] for ECDH and key 847 derivation. 849 o ChaCha20+Poly1305 [RFC7539] for packet authenticated encryption. 851 o BLAKE2s [BLAKE2] for hashing. 853 There is no cryptographic agility. If weaknesses are found in any of 854 these algorithms, new message types using new algorithms must be 855 introduced. 857 WireGuard is designed to be entirely stateless, modulo the CryptoKey 858 routing table, which has size linear with the number of trusted 859 peers. If a WireGuard receiver is under heavy load and cannot 860 process a packet, e.g., cannot spare CPU cycles for point 861 multiplication, it can reply with a cookie similar to DTLS and IKEv2. 862 This cookie only proves IP address ownership. Any rate limiting 863 scheme can be applied to packets coming from non-spoofed addresses. 865 4.7.2. Protocol features 867 o Forward-secure key establishment. 869 o Peer authentication (Public-key and PSK). 871 o Mutual authentication. 873 o Record replay prevention (Stateful, timestamp-based). 875 o DoS mitigation (cookie-based). 877 4.7.3. Protocol dependencies 879 o Datagram transport. 881 o Out-of-band key distribution and management. 883 4.8. MinimalT 885 MinimalT is a UDP-based transport security protocol designed to offer 886 confidentiality, mutual authentication, DoS prevention, and 887 connection mobility [MinimalT]. One major goal of the protocol is to 888 leverage existing protocols to obtain server-side configuration 889 information used to more quickly bootstrap a connection. MinimalT 890 uses a variant of TCP's congestion control algorithm. 892 4.8.1. Protocol Description 894 MinimalT is a secure transport protocol built on top of a widespread 895 directory service. Clients and servers interact with local directory 896 services to (a) resolve server information and (b) public ephemeral 897 state information, respectively. Clients connect to a local resolver 898 once at boot time. Through this resolver they recover the IP 899 address(es) and public key(s) of each server to which they want to 900 connect. 902 Connections are instances of user-authenticated, mobile sessions 903 between two endpoints. Connections run within tunnels between hosts. 904 A tunnel is a server-authenticated container that multiplexes 905 multiple connections between the same hosts. All connections in a 906 tunnel share the same transport state machine and encryption. Each 907 tunnel has a dedicated control connection used to configure and 908 manage the tunnel over time. Moreover, since tunnels are independent 909 of the network address information, they may be reused as both ends 910 of the tunnel move about the network. This does however imply that 911 the connection establishment and packet encryption mechanisms are 912 coupled. 914 Before a client connects to a remote service, it must first establish 915 a tunnel to the host providing or offering the service. Tunnels are 916 established in 1-RTT using an ephemeral key obtained from the 917 directory service. Tunnel initiators provide their own ephemeral key 918 and, optionally, a DoS puzzle solution such that the recipient 919 (server) can verify the authenticity of the request and derive a 920 shared secret. Within a tunnel, new connections to services may be 921 established. 923 4.8.2. Protocol Features 925 o Forward-secure key establishment. 927 o DoS mitigation (puzzle-based). 929 o Connection mobility (tunnel-based). 931 Additional (orthogonal) transport features include: connection 932 multiplexing between hosts across shared tunnels, and congestion 933 control state is shared across connections between the same host 934 pairs. 936 4.8.3. Protocol Dependencies 938 o A DNS-like resolution service to obtain location information (an 939 IP address) and ephemeral keys. 941 o A PKI trust store for certificate validation. 943 4.9. CurveCP 945 CurveCP [CurveCP] is a UDP-based transport security protocol from 946 Daniel J. Bernstein. Unlike other transport security protocols, it 947 is based entirely upon highly efficient public key algorithms. This 948 removes many pitfalls associated with nonce reuse and key 949 synchronization. 951 4.9.1. Protocol Description 953 CurveCP is a UDP-based transport security protocol. It is built on 954 three principal features: exclusive use of public key authenticated 955 encryption of packets, server-chosen cookies to prohibit memory and 956 computation DoS at the server, and connection mobility with a client- 957 chosen ephemeral identifier. 959 There are two rounds in CurveCP. In the first round, the client 960 sends its first initialization packet to the server, carrying its 961 (possibly fresh) ephemeral public key C', with zero-padding encrypted 962 under the server's long-term public key. The server replies with a 963 cookie and its own ephemeral key S' and a cookie that is to be used 964 by the client. Upon receipt, the client then generates its second 965 initialization packet carrying: the ephemeral key C', cookie, and an 966 encryption of C', the server's domain name, and, optionally, some 967 message data. The server verifies the cookie and the encrypted 968 payload and, if valid, proceeds to send data in return. At this 969 point, the connection is established and the two parties can 970 communicate. 972 The use of only public-key encryption and authentication, or 973 "boxing", is done to simplify problems that come with symmetric key 974 management and synchronization. For example, it allows the sender of 975 a message to be in complete control of each message's nonce. It does 976 not require either end to share secret keying material. Furthermore, 977 it allows connections (or sessions) to be associated with unique 978 ephemeral public keys as a mechanism for enabling forward secrecy 979 given the risk of long-term private key compromise. 981 The client and server do not perform a standard key exchange. 982 Instead, in the initial exchange of packets, each party provides its 983 own ephemeral key to the other end. The client can choose a new 984 ephemeral key for every new connection. However, the server must 985 rotate these keys on a slower basis. Otherwise, it would be trivial 986 for an attacker to force the server to create and store ephemeral 987 keys with a fake client initialization packet. 989 Unlike TCP, the server employs cookies to enable source validation. 990 After receiving the client's initial packet, encrypted under the 991 server's long-term public key, the server generates and returns a 992 stateless cookie that must be echoed back in the client's following 993 message. This cookie is encrypted under the client's ephemeral 994 public key. This stateless technique prevents attackers from 995 hijacking client initialization packets to obtain cookie values to 996 flood clients. (A client would detect the duplicate cookies and 997 reject the flooded packets.) Similarly, replaying the client's 998 second packet, carrying the cookie, will be detected by the server. 1000 CurveCP supports a weak form of client authentication. Clients are 1001 permitted to send their long-term public keys in the second 1002 initialization packet. A server can verify this public key and, if 1003 untrusted, drop the connection and subsequent data. 1005 Unlike some other protocols, CurveCP data packets leave only the 1006 ephemeral public key, the connection ID, and the per-message nonce in 1007 the clear. Everything else is encrypted. 1009 4.9.2. Protocol Features 1011 o Datagram confidentiality and integrity (via public key 1012 encryption). 1014 o 1-RTT session bootstrapping. 1016 o Connection mobility (based on a client-chosen ephemeral 1017 identifier). 1019 o Optional length-hiding and anti-amplification padding. 1021 4.9.3. Protocol Dependencies 1023 o An unreliable transport protocol such as UDP. 1025 5. Security Features and Transport Dependencies 1027 There exists a common set of features shared across the transport 1028 protocols surveyed in this document. Mandatory features constitute a 1029 baseline of functionality that an application may assume for any TAPS 1030 implementation. Optional features by contrast may vary from 1031 implementation to implementation, and so an application cannot simply 1032 assume they are available. Applications learn of and use optional 1033 features by querying for their presence and support. Optional 1034 features may not be implemented, or may be disabled if their presence 1035 impacts transport services or if a necessary transport service is 1036 unavailable. 1038 5.1. Mandatory Features 1040 o Segment or datagram encryption and authentication: Transit data 1041 must be protected with an authenticated encryption algorithm. 1043 o Forward-secure key establishment: Negotiated keying material must 1044 come from an authenticated, forward-secure key exchange protocol. 1046 o Public-key (raw or certificate) based authentication: 1047 Authentication based on public key signatures is commonplace for 1048 many transport security protocols. 1050 o Responder authentication: The endpoint (receiver) of a new 1051 connection must be authenticated before any data is sent to said 1052 party. 1054 o Pre-shared key support: A security protocol must be able to use a 1055 pre-shared key established out-of-band or from a prior session to 1056 encrypt individual messages, packets, or datagrams. 1058 5.2. Optional Features 1060 o Cryptographic algorithm negotiation (AN): Transport security 1061 protocols should permit applications to configure supported or 1062 enabled cryptographic algorithms. 1064 * Transport dependency: None. 1066 * Application dependency: Application awareness of supported or 1067 desired algorithms. 1069 o Application authentication delegation (AD): Some protocols may 1070 completely defer endpoint authentication to applications, e.g., to 1071 reduce online protocol complexity. 1073 * Transport dependency: None. 1075 * Application dependency: Application opt-in and policy for 1076 endpoint authentication 1078 o Mutual authentication (MA): Transport security protocols should 1079 allow each endpoint to authenticate the other if required by the 1080 application. 1082 * Transport dependency: None. 1084 * Application dependency: Mutual authentication required for 1085 application support. 1087 o DoS mitigation (DM): Transport security protocols may need to 1088 support volumetric DoS prevention via, e.g., cookies or initiator- 1089 side puzzles. 1091 * Transport dependency: None. 1093 * Application dependency: None. 1095 o Connection mobility (CM): Sessions should not be bound to a 1096 network connection (or 5-tuple). This allows cryptographic key 1097 material and other state information to be reused in the event of 1098 a connection change. Examples of this include a NAT rebinding 1099 that occurs without a client's knowledge. 1101 * Transport dependency: Connections are unreliable or can change 1102 due to unpredictable network events, e.g., NAT re-bindings. 1104 * Application dependency: None. 1106 o Source validation (SV): Source validation must be provided to 1107 mitigate server-targeted DoS attacks. This can be done with 1108 puzzles or cookies. 1110 * Transport dependency: Packets may arrive as datagrams instead 1111 of streams from unauthenticated sources. 1113 * Application dependency: None. 1115 o Application-layer feature negotiation (AFN): The type of 1116 application using a transport security protocol often requires 1117 features configured at the connection establishment layer, e.g., 1118 ALPN [RFC7301]. Moreover, application-layer features may often be 1119 used to offload the session to another server which can better 1120 handle the request. (The TLS SNI is one example of such a 1121 feature.) As such, transport security protocols should provide a 1122 generic mechanism to allow for such application-specific features 1123 and options to be configured or otherwise negotiated. 1125 * Transport dependency: None. 1127 * Application dependency: Specification of application-layer 1128 features or functionality. 1130 o Configuration extensions (CX): The protocol negotiation should be 1131 extensible with addition of new configuration options. 1133 * Transport dependency: None. 1135 * Application dependency: Specification of application-specific 1136 extensions. 1138 o Session caching and management (SC): Sessions should be cacheable 1139 to enable reuse and amortize the cost of performing session 1140 establishment handshakes. 1142 * Transport dependency: None. 1144 * Application dependency: None. 1146 o Length-hiding padding (LHP): Applications may wish to defer 1147 traffic padding to the security protocol to deter traffic analysis 1148 attacks. 1150 * Transport dependency: None. 1152 * Application dependency: Knowledge of desired padding policies. 1154 5.3. Optional Feature Availability 1156 The following table lists the availability of the above-listed 1157 optional features in each of the analyzed protocols. "Mandatory" 1158 indicates that the feature is intrinsic to the protocol and cannot be 1159 disabled. "Supported" indicates that the feature is optionally 1160 provided natively or through a (standardized, where applicable) 1161 extension. 1163 +-----------+----+----+----+-----+----+----+-----+----+----+-----+ 1164 | Protocol | AN | AD | MA | DM | CM | SV | AFN | CX | SC | LHP | 1165 +-----------+----+----+----+-----+----+----+-----+----+----+-----+ 1166 | TLS | S | S | S | S | U* | M | S | S | S | S | 1167 | | | | | | | | | | | | 1168 | DTLS | S | S | S | S | S | M | S | S | S | S | 1169 | | | | | | | | | | | | 1170 | IETF QUIC | S | S | S | S | S | M | S | S | S | S | 1171 | | | | | | | | | | | | 1172 | IKEv2+ESP | S | S | M | S | S | M | S | S | S | S | 1173 | | | | | | | | | | | | 1174 | SRTP+DTLS | S | S | S | S | U | M | S | S | S | U | 1175 | | | | | | | | | | | | 1176 | tcpcrypt | S | M | U | U** | U* | M | U | U | S | U | 1177 | | | | | | | | | | | | 1178 | WireGuard | U | S | M | S | U | M | U | U | U | S+ | 1179 | | | | | | | | | | | | 1180 | MinimalT | U | U | M | S | M | M | U | U | U | S | 1181 | | | | | | | | | | | | 1182 | CurveCP | U | U | S | S | M | M | U | U | U | S | 1183 +-----------+----+----+----+-----+----+----+-----+----+----+-----+ 1185 M=Mandatory 1186 S=Supported but not required 1187 U=Unsupported 1188 *=On TCP; MPTCP would provide this ability 1189 **=TCP provides SYN cookies natively, but these are not 1190 cryptographically strong 1191 +=For transport packets only 1193 6. Transport Security Protocol Interfaces 1195 This section describes the interface surface exposed by the security 1196 protocols described above. Note that not all protocols support each 1197 interface. We partition these interfaces into pre-connection 1198 (configuration), connection, and post-connection interfaces. 1200 6.1. Pre-Connection Interfaces 1202 Configuration interfaces are used to configure the security protocols 1203 before a handshake begins or the keys are negotiated. 1205 o Identity and Private Keys 1206 The application can provide its identities (certificates) and 1207 private keys, or mechanisms to access these, to the security 1208 protocol to use during handshakes. 1209 Protocols: TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2, 1210 WireGuard, SRTP 1212 o Supported Algorithms (Key Exchange, Signatures, and Ciphersuites) 1213 The application can choose the algorithms that are supported for 1214 key exchange, signatures, and ciphersuites. 1215 Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP 1217 o Session Cache Management The application provides the ability to 1218 save and retrieve session state (such as tickets, keying material, 1219 and server parameters) that may be used to resume the security 1220 session. 1221 Protocols: TLS, DTLS, QUIC + TLS, MinimalT 1223 o Authentication Delegation 1224 The application provides access to a separate module that will 1225 provide authentication, using EAP for example. 1226 Protocols: IKEv2, SRTP 1228 o Pre-Shared Key Import 1229 Either the handshake protocol or the application directly can 1230 supply pre-shared keys for the record protocol use for encryption/ 1231 decryption and authentication. If the application can supply keys 1232 directly, this is considered explicit import; if the handshake 1233 protocol traditionally provides the keys directly, it is 1234 considered direct import; if the keys can only be shared by the 1235 handshake, they are considered non-importable. 1237 * Explict import: QUIC, ESP 1239 * Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard 1241 * Non-importable: CurveCP 1243 6.2. Connection Interfaces 1245 o Identity Validation 1246 During a handshake, the security protocol will conduct identity 1247 validation of the peer. This can call into the application to 1248 offload validation. Protocols: All (TLS, DTLS, QUIC + TLS, 1249 MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS)) 1251 o Source Address Validation 1252 The handshake protocol may delegate validation of the remote peer 1253 that has sent data to the transport protocol or application. This 1254 involves sending a cookie exchange to avoid DoS attacks. 1255 Protocols: QUIC + TLS, DTLS, WireGuard 1257 6.3. Post-Connection Interfaces 1259 o Connection Termination The security protocol may be instructed to 1260 tear down its connection and session information. This is needed 1261 by some protocols to prevent application data truncation attacks. 1262 Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2 1264 o Key Update 1265 The handshake protocol may be instructed to update its keying 1266 material, either by the application directly or by the record 1267 protocol sending a key expiration event. 1268 Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2 1270 o Pre-Shared Key Export The handshake protocol will generate one or 1271 more keys to be used for record encryption/decryption and 1272 authentication. These may be explicitly exportable to the 1273 application, traditionally limited to direct export to the record 1274 protocol, or inherently non-exportable because the keys must be 1275 used directly in conjunction with the record protocol. 1277 * Explicit export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for 1278 SRTP) 1280 * Direct export: TLS, DTLS, MinimalT 1282 * Non-exportable: CurveCP 1284 o Key Expiration 1285 The record protocol can signal that its keys are expiring due to 1286 reaching a time-based deadline, or a use-based deadline (number of 1287 bytes that have been encrypted with the key). This interaction is 1288 often limited to signaling between the record layer and the 1289 handshake layer. 1291 Protocols: ESP ((Editor's note: One may consider TLS/DTLS to also 1292 have this interface)) 1294 o Connection mobility 1295 The record protocol can be signaled that it is being migrated to 1296 another transport or interface due to connection mobility, which 1297 may reset address and state validation. 1298 Protocols: QUIC, MinimalT, CurveCP, ESP, WireGuard (roaming) 1300 7. IANA Considerations 1302 This document has no request to IANA. 1304 8. Security Considerations 1306 This document summarizes existing transport security protocols and 1307 their interfaces. It does not propose changes to or recommend usage 1308 of reference protocols. Moreover, no claims of security and privacy 1309 properties beyond those guaranteed by the protocols discussed are 1310 made. For example, metadata leakage via timing side channels and 1311 traffic analysis may compromise any protocol discussed in this 1312 survey. Applications using Security Interfaces SHOULD take such 1313 limitations into consideration when using a particular protocol 1314 implementation. 1316 9. Acknowledgments 1318 The authors would like to thank Mirja Kuehlewind, Brian Trammell, 1319 Yannick Sierra, Frederic Jacobs, and Bob Bradley for their input and 1320 feedback on earlier versions of this draft. 1322 10. Normative References 1324 [ALTS] "Application Layer Transport Security", n.d.. 1326 [BLAKE2] "BLAKE2 -- simpler, smaller, fast as MD5", n.d.. 1328 [Curve25519] 1329 "Curve25519 - new Diffie-Hellman speed records", n.d.. 1331 [CurveCP] "CurveCP -- Usable security for the Internet", n.d.. 1333 [I-D.ietf-quic-tls] 1334 Thomson, M. and S. Turner, "Using Transport Layer Security 1335 (TLS) to Secure QUIC", draft-ietf-quic-tls-13 (work in 1336 progress), June 2018. 1338 [I-D.ietf-quic-transport] 1339 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1340 and Secure Transport", draft-ietf-quic-transport-13 (work 1341 in progress), June 2018. 1343 [I-D.ietf-rtcweb-security-arch] 1344 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 1345 rtcweb-security-arch-14 (work in progress), March 2018. 1347 [I-D.ietf-taps-arch] 1348 Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., 1349 Perkins, C., Tiesel, P., and C. Wood, "An Architecture for 1350 Transport Services", draft-ietf-taps-arch-00 (work in 1351 progress), April 2018. 1353 [I-D.ietf-tcpinc-tcpcrypt] 1354 Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, 1355 Q., and E. Smith, "Cryptographic protection of TCP Streams 1356 (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-12 (work in 1357 progress), June 2018. 1359 [I-D.ietf-tcpinc-tcpeno] 1360 Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. 1361 Smith, "TCP-ENO: Encryption Negotiation Option", draft- 1362 ietf-tcpinc-tcpeno-19 (work in progress), June 2018. 1364 [I-D.ietf-tls-dtls-connection-id] 1365 Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, 1366 "The Datagram Transport Layer Security (DTLS) Connection 1367 Identifier", draft-ietf-tls-dtls-connection-id-00 (work in 1368 progress), December 2017. 1370 [I-D.ietf-tls-dtls13] 1371 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1372 Datagram Transport Layer Security (DTLS) Protocol Version 1373 1.3", draft-ietf-tls-dtls13-26 (work in progress), March 1374 2018. 1376 [I-D.ietf-tls-tls13] 1377 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1378 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 1379 March 2018. 1381 [MinimalT] 1382 "MinimaLT -- Minimal-latency Networking Through Better 1383 Security", n.d.. 1385 [Noise] "The Noise Protocol Framework", n.d.. 1387 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1388 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 1389 1998, . 1391 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 1392 Headers for Low-Speed Serial Links", RFC 2508, 1393 DOI 10.17487/RFC2508, February 1999, 1394 . 1396 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1397 A., Peterson, J., Sparks, R., Handley, M., and E. 1398 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1399 DOI 10.17487/RFC3261, June 2002, 1400 . 1402 [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and 1403 P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with 1404 High Delay, Packet Loss and Reordering", RFC 3545, 1405 DOI 10.17487/RFC3545, July 2003, 1406 . 1408 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1409 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1410 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1411 . 1413 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1414 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1415 RFC 3948, DOI 10.17487/RFC3948, January 2005, 1416 . 1418 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 1419 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 1420 January 2006, . 1422 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1423 DOI 10.17487/RFC4302, December 2005, 1424 . 1426 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1427 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1428 . 1430 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1431 Authenticated Identity Management in the Session 1432 Initiation Protocol (SIP)", RFC 4474, 1433 DOI 10.17487/RFC4474, August 2006, 1434 . 1436 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1437 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 1438 . 1440 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1441 (TLS) Protocol Version 1.2", RFC 5246, 1442 DOI 10.17487/RFC5246, August 2008, 1443 . 1445 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 1446 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 1447 DOI 10.17487/RFC5723, January 2010, 1448 . 1450 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1451 for Establishing a Secure Real-time Transport Protocol 1452 (SRTP) Security Context Using Datagram Transport Layer 1453 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1454 2010, . 1456 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1457 Security (DTLS) Extension to Establish Keys for the Secure 1458 Real-time Transport Protocol (SRTP)", RFC 5764, 1459 DOI 10.17487/RFC5764, May 2010, 1460 . 1462 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1463 Key Derivation Function (HKDF)", RFC 5869, 1464 DOI 10.17487/RFC5869, May 2010, 1465 . 1467 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1468 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1469 June 2010, . 1471 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1472 Extensions: Extension Definitions", RFC 6066, 1473 DOI 10.17487/RFC6066, January 2011, 1474 . 1476 [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: 1477 Media Path Key Agreement for Unicast Secure RTP", 1478 RFC 6189, DOI 10.17487/RFC6189, April 2011, 1479 . 1481 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1482 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1483 January 2012, . 1485 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1486 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1487 Transport Layer Security (TLS) and Datagram Transport 1488 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1489 June 2014, . 1491 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1492 Kivinen, "Internet Key Exchange Protocol Version 2 1493 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1494 2014, . 1496 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1497 "Transport Layer Security (TLS) Application-Layer Protocol 1498 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1499 July 2014, . 1501 [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 1502 Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, 1503 . 1505 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 1506 Ed., "Services Provided by IETF Transport Protocols and 1507 Congestion Control Mechanisms", RFC 8095, 1508 DOI 10.17487/RFC8095, March 2017, 1509 . 1511 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 1512 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 1513 August 2017, . 1515 [SIGMA] "SIGMA -- The 'SIGn-and-MAc' Approach to Authenticated 1516 Diffie-Hellman and Its Use in the IKE-Protocols", n.d.. 1518 [WireGuard] 1519 "WireGuard -- Next Generation Kernel Network Tunnel", 1520 n.d.. 1522 Authors' Addresses 1524 Tommy Pauly 1525 Apple Inc. 1526 One Apple Park Way 1527 Cupertino, California 95014 1528 United States of America 1530 Email: tpauly@apple.com 1531 Colin Perkins 1532 University of Glasgow 1533 School of Computing Science 1534 Glasgow G12 8QQ 1535 United Kingdom 1537 Email: csp@csperkins.org 1539 Kyle Rose 1540 Akamai Technologies, Inc. 1541 150 Broadway 1542 Cambridge, MA 02144 1543 United States of America 1545 Email: krose@krose.org 1547 Christopher A. Wood 1548 Apple Inc. 1549 One Apple Park Way 1550 Cupertino, California 95014 1551 United States of America 1553 Email: cawood@apple.com