idnits 2.17.1 draft-ietf-taps-transport-security-03.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 1294: '...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 (October 22, 2018) is 2012 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-tls-dtls13' is defined on line 1359, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-15 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-15 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-15 == Outdated reference: A later version (-19) exists of draft-ietf-taps-arch-02 == Outdated reference: A later version (-26) exists of draft-ietf-taps-interface-02 == Outdated reference: A later version (-15) exists of draft-ietf-tcpinc-tcpcrypt-13 == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-01 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-28 ** 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 (~~), 10 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: April 25, 2019 University of Glasgow 6 K. Rose 7 Akamai Technologies, Inc. 8 C. Wood 9 Apple Inc. 10 October 22, 2018 12 A Survey of Transport Security Protocols 13 draft-ietf-taps-transport-security-03 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 April 25, 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. Security 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. Security Features . . . . . . . . . . . . . . . . . . 10 75 4.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10 76 4.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 11 77 4.3.1. Protocol Description . . . . . . . . . . . . . . . . 11 78 4.3.2. Security Features . . . . . . . . . . . . . . . . . . 11 79 4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 12 80 4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 12 81 4.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 12 82 4.4.1. Protocol descriptions . . . . . . . . . . . . . . . . 12 83 4.4.2. Security Features . . . . . . . . . . . . . . . . . . 14 84 4.4.3. Protocol Dependencies . . . . . . . . . . . . . . . . 14 85 4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 15 86 4.5.1. Protocol description . . . . . . . . . . . . . . . . 15 87 4.5.2. Security Features . . . . . . . . . . . . . . . . . . 16 88 4.5.3. Protocol Dependencies . . . . . . . . . . . . . . . . 16 89 4.5.4. Variant: ZRTP for Media Path Key Agreement . . . . . 16 90 4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 17 91 4.6.1. Protocol Description . . . . . . . . . . . . . . . . 17 92 4.6.2. Security Features . . . . . . . . . . . . . . . . . . 18 93 4.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 18 94 4.7. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 18 95 4.7.1. Protocol description . . . . . . . . . . . . . . . . 18 96 4.7.2. Security Features . . . . . . . . . . . . . . . . . . 19 97 4.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 19 98 4.8. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 20 99 4.8.1. Protocol Description . . . . . . . . . . . . . . . . 20 100 4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 20 101 4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 21 102 4.9. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 21 103 4.9.1. Protocol Description . . . . . . . . . . . . . . . . 21 104 4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 22 105 4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 22 106 5. Security Features and Transport Dependencies . . . . . . . . 23 107 5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 23 108 5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 23 109 5.3. Optional Feature Availability . . . . . . . . . . . . . . 25 110 6. Transport Security Protocol Interfaces . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . . . . . . . . . 33 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: Framed protocol messages. 202 o Record Protocol: a security protocol that allows data to be 203 divided into manageable blocks and protected using shared 204 cryptographic context. 206 o Session: an ephemeral security association between applications. 208 o Cryptographic context: a set of cryptographic parameters, 209 including but not necessarily limited to keys for encryption, 210 authentication, and session resumption, enabling authorized 211 parties to a session to communicate securely. 213 o Connection: the shared state of two or more endpoints that 214 persists across messages that are transmitted between these 215 endpoints. A connection is a transient participant of a session, 216 and a session generally lasts between connection instances. 218 o Connection Mobility: a property of a connection that allows it to 219 be multihomed or resilient across network interface or address 220 changes, e.g., NAT rebindings that occur without an endpoint's 221 knowledge. Mobility allows cryptographic key material and other 222 state information to be reused in the event of a connection 223 change. 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. Security Features 236 extend the set of Transport Features described in [RFC8095] and 237 provided by Transport Services implementations. Protocol security 238 properties that are unrelated to the API surface exposed by such 239 protocols, such as client or server identity hiding, are not listed 240 here as features. 242 o Forward-secure key establishment: Cryptographic key establishment 243 with forward secure properties. 245 o Cryptographic algorithm negotiation: Negotiate support of protocol 246 algorithms, including: encryption, hash, MAC (PRF), and digital 247 signature algorithms. 249 o Stateful and stateless cross-connection session resumption: 250 Connection establishment without needing to complete an entirely 251 new handshake. 253 o Session caching and management: Manage session state cache used 254 for subsequent connections aimed towards amortizing connection 255 establishment costs. 257 o Peer authentication (certificate, raw public key, pre-shared key, 258 or EAP-based): Peer authentication using select or protocol- 259 specific mechanisms. 261 o Mutual authentication: Connection establishment wherein both 262 endpoints are authenticated. 264 o Application-layer authentication delegation: Out-of-band peer 265 authentication performed by applications outside of the connection 266 establishment. 268 o Record (channel or datagram) confidentiality and integrity: 269 Encryption and authentication of application plaintext bytes sent 270 between peers over a channel or in individual datagrams. 272 o Partial record confidentiality: Encryption of some portion of 273 records. 275 o Optional record integrity: Optional authentication of certain 276 records. 278 o Record replay prevention: Protocol detection and defense against 279 record replays, e.g., due to in-network retransmissions. 281 o Early data support (starting with TLS 1.3): Transmission of 282 application data prior to connection (handshake) establishment. 284 o Connection mobility: Connection continuation in the presence of 285 5-tuple changes beneath the secure transport protocol, e.g., due 286 to NAT rebindings. 288 o Application-layer feature negotiation: Securely negotiate 289 application-specific functionality, including those necessary for 290 connection handling and management, e.g., the TLS parent 291 connection protocol type via ALPN [RFC7301] or desired application 292 identity via SNI [RFC6066]. 294 o Configuration extensions: Add protocol features via extensions or 295 configuration options. TLS extensions are a primary example of 296 this feature. 298 o Out-of-order record receipt: Processing of records received out- 299 of-order. 301 o Source validation (cookie or puzzle based): Peer source validation 302 and DoS mitigation via explicit proof of origin (cookie) or work 303 mechanisms (puzzles). 305 o Connection re-keying: In-band cryptographic handshake re-keying. 307 o Length-hiding padding: Protocol-drive record padding aimed at 308 hiding plaintext message length and mitigating amplification 309 attack vectors. 311 4. Transport Security Protocol Descriptions 313 This section contains descriptions of security protocols currently 314 used to protect data being sent over a network. 316 For each protocol, we describe its provided features and dependencies 317 on other protocols. 319 4.1. TLS 321 TLS (Transport Layer Security) [RFC5246] is a common protocol used to 322 establish a secure session between two endpoints. Communication over 323 this session "prevents eavesdropping, tampering, and message 324 forgery." TLS consists of a tightly coupled handshake and record 325 protocol. The handshake protocol is used to authenticate peers, 326 negotiate protocol options, such as cryptographic algorithms, and 327 derive session-specific keying material. The record protocol is used 328 to marshal (possibly encrypted) data from one peer to the other. 329 This data may contain handshake messages or raw application data. 331 4.1.1. Protocol Description 333 TLS is the composition of a handshake and record protocol 334 [I-D.ietf-tls-tls13]. The record protocol is designed to marshal an 335 arbitrary, in-order stream of bytes from one endpoint to the other. 337 It handles segmenting, compressing (when enabled), and encrypting 338 data into discrete records. When configured to use an authenticated 339 encryption with associated data (AEAD) algorithm, it also handles 340 nonce generation and encoding for each record. The record protocol 341 is hidden from the client behind a bytestream-oriented API. 343 The handshake protocol serves several purposes, including: peer 344 authentication, protocol option (key exchange algorithm and 345 ciphersuite) negotiation, and key derivation. Peer authentication 346 may be mutual; however, commonly, only the server is authenticated. 347 X.509 certificates are commonly used in this authentication step, 348 though other mechanisms, such as raw public keys [RFC7250], exist. 349 The client is not authenticated unless explicitly requested by the 350 server. 352 The handshake protocol is also extensible. It allows for a variety 353 of extensions to be included by either the client or server. These 354 extensions are used to specify client preferences, e.g., the 355 application-layer protocol to be driven with the TLS connection 356 [RFC7301], or signals to the server to aid operation, e.g., Server 357 Name Indication (SNI) [RFC6066]. Various extensions also exist to 358 tune the parameters of the record protocol, e.g., the maximum 359 fragment length [RFC6066] and record size limit 360 [I-D.ietf-tls-record-limit]. 362 Alerts are used to convey errors and other atypical events to the 363 endpoints. There are two classes of alerts: closure and error 364 alerts. A closure alert is used to signal to the other peer that the 365 sender wishes to terminate the connection. The sender typically 366 follows a close alert with a TCP FIN segment to close the connection. 367 Error alerts are used to indicate problems with the handshake or 368 individual records. Most errors are fatal and are followed by 369 connection termination. However, warning alerts may be handled at 370 the discretion of the implementation. 372 Once a session is disconnected all session keying material must be 373 destroyed, with the exception of secrets previously established 374 expressly for purposes of session resumption. TLS supports stateful 375 and stateless resumption. (Here, "state" refers to bookkeeping on a 376 per-session basis by the server. It is assumed that the client must 377 always store some state information in order to resume a session.) 379 4.1.2. Security Features 381 o Forward-secure key establishment. 383 o Cryptographic algorithm negotiation. 385 o Stateful and stateless cross-connection session resumption. 387 o Session caching and management. 389 o Peer authentication (Certificate, raw public key, and pre-shared 390 key). 392 o Mandatory server authentication, optional client authentication. 394 o Application authentication delegation. 396 o Record (channel) confidentiality and integrity. 398 o Record replay prevention. 400 o Application-layer feature negotiation. 402 o Configuration extensions. 404 o Early data support (starting with TLS 1.3). 406 o Optional record-layer padding (starting with TLS 1.3). 408 4.1.3. Protocol Dependencies 410 o TCP for in-order, reliable transport. 412 o (Optionally) A PKI trust store for certificate validation. 414 4.2. DTLS 416 DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS, 417 but differs in that it is designed to run over UDP instead of TCP. 418 Since UDP does not guarantee datagram ordering or reliability, DTLS 419 modifies the protocol to make sure it can still provide the same 420 security guarantees as TLS. DTLS was designed to be as close to TLS 421 as possible, so this document will assume that all properties from 422 TLS are carried over except where specified. 424 4.2.1. Protocol Description 426 DTLS is modified from TLS to operate with the possibility of packet 427 loss, reordering, and duplication that may occur when operating over 428 UDP. To enable out-of-order delivery of application data, the DTLS 429 record protocol itself has no inter-record dependencies. However, as 430 the handshake requires reliability, each handshake message is 431 assigned an explicit sequence number to enable retransmissions of 432 lost packets and in-order processing by the receiver. Handshake 433 message loss is remedied by sender retransmission after a 434 configurable period in which the expected response has not yet been 435 received. 437 As the DTLS handshake protocol runs atop the record protocol, to 438 account for long handshake messages that cannot fit within a single 439 record, DTLS supports fragmentation and subsequent reconstruction of 440 handshake messages across records. The receiver must reassemble 441 records before processing. 443 DTLS relies on unique UDP 4-tuples to identify connections. Since 444 all application-layer data is encrypted, demultiplexing over the same 445 4-tuple requires the use of a connection identifier extension 446 [I-D.ietf-tls-dtls-connection-id] to permit identification of the 447 correct connection-specific cryptographic context without the use of 448 trial decryption. (Note that this extension is only supported in 449 DTLS 1.2 and 1.3 {{I-D.ietf-tls-dtls13}.) 451 Since datagrams can be replayed, DTLS provides optional anti-replay 452 detection based on a window of acceptable sequence numbers [RFC6347]. 454 4.2.2. Security Features 456 o Record replay protection. 458 o Record (datagram) confidentiality and integrity. 460 o Out-of-order record receipt. 462 o DoS mitigation (cookie-based). 464 See also the features from TLS. 466 4.2.3. Protocol Dependencies 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 UDP 4-tuple uniqueness, or the connection identifier extension, 475 for demultiplexing. 477 o Path MTU discovery. 479 4.3. (IETF) QUIC with TLS 481 QUIC (Quick UDP Internet Connections) is a new standards-track 482 transport protocol that runs over UDP, loosely based on Google's 483 original proprietary gQUIC protocol [I-D.ietf-quic-transport]. (See 484 Section 4.3.4 for more details.) The QUIC transport layer itself 485 provides support for data confidentiality and integrity. This 486 requires keys to be derived with a separate handshake protocol. A 487 mapping for QUIC over TLS 1.3 [I-D.ietf-quic-tls] has been specified 488 to provide this handshake. 490 4.3.1. Protocol Description 492 As QUIC relies on TLS to secure its transport functions, it creates 493 specific integration points between its security and transport 494 functions: 496 o Starting the handshake to generate keys and provide authentication 497 (and providing the transport for the handshake). 499 o Client address validation. 501 o Key ready events from TLS to notify the QUIC transport. 503 o Exporting secrets from TLS to the QUIC transport. 505 The QUIC transport layer support multiple streams over a single 506 connection. QUIC implements a record protocol for TLS handshake 507 messages to establish a connection. These messages are sent in 508 special INITIAL and CRYPTO frames [I-D.ietf-quic-transport], types of 509 which are encrypted using different keys. INITIAL frames are 510 encrypted using "fixed" keys derived from the QUIC version and public 511 packet information (Connection ID). CRYPTO frames are encrypted 512 using TLS handshake secrets. Once TLS completes, QUIC uses the 513 resultant traffic secrets to for the QUIC connection to protect the 514 rest of the streams. QUIC supports 0-RTT (early) data using 515 previously negotiated connection secrets. Early data is sent in 516 0-RTT packets, which may be included in the same datagram as the 517 Initial and Handshake packets. 519 4.3.2. Security Features 521 o DoS mitigation (cookie-based). 523 See also the properties of TLS. 525 4.3.3. Protocol Dependencies 527 o QUIC transport relies on UDP. 529 o QUIC transport relies on TLS 1.3 for key exchange, peer 530 authentication, and shared secret derivation. 532 4.3.4. Variant: Google QUIC 534 Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol 535 designed and deployed by Google following experience from deploying 536 SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally 537 known as "QUIC": this document uses gQUIC to unambiguously 538 distinguish it from the standards-track IETF QUIC. The proprietary 539 technical forebear of IETF QUIC, gQUIC was originally designed with 540 tightly-integrated security and application data transport protocols. 542 4.4. IKEv2 with ESP 544 IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec 545 protocol suite that encrypts and authenticates IP packets, either for 546 creating tunnels (tunnel-mode) or for direct transport connections 547 (transport-mode). This suite of protocols separates out the key 548 generation protocol (IKEv2) from the transport encryption protocol 549 (ESP). Each protocol can be used independently, but this document 550 considers them together, since that is the most common pattern. 552 4.4.1. Protocol descriptions 554 4.4.1.1. IKEv2 556 IKEv2 is a control protocol that runs on UDP port 500. Its primary 557 goal is to generate keys for Security Associations (SAs). An SA 558 contains shared (cryptographic) information used for establishing 559 other SAs or keying ESP; See Section 4.4.1.2. IKEv2 first uses a 560 Diffie-Hellman key exchange to generate keys for the "IKE SA", which 561 is a set of keys used to encrypt further IKEv2 messages. It then 562 goes through a phase of authentication in which both peers present 563 blobs signed by a shared secret or private key, after which another 564 set of keys is derived, referred to as the "Child SA". These Child 565 SA keys are used by ESP. 567 IKEv2 negotiates which protocols are acceptable to each peer for both 568 the IKE and Child SAs using "Proposals". Each proposal may contain 569 an encryption algorithm, an authentication algorithm, a Diffie- 570 Hellman group, and (for IKE SAs only) a pseudorandom function 571 algorithm. Each peer may support multiple proposals, and the most 572 preferred mutually supported proposal is chosen during the handshake. 574 The authentication phase of IKEv2 may use Shared Secrets, 575 Certificates, Digital Signatures, or an EAP (Extensible 576 Authentication Protocol) method. At a minimum, IKEv2 takes two round 577 trips to set up both an IKE SA and a Child SA. If EAP is used, this 578 exchange may be expanded. 580 Any SA used by IKEv2 can be rekeyed upon expiration, which is usually 581 based either on time or number of bytes encrypted. 583 There is an extension to IKEv2 that allows session resumption 584 [RFC5723]. 586 MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a 587 set of Security Associations to migrate over different addresses and 588 interfaces [RFC4555]. 590 When UDP is not available or well-supported on a network, IKEv2 may 591 be encapsulated in TCP [RFC8229]. 593 4.4.1.2. ESP 595 ESP is a protocol that encrypts and authenticates IPv4 and IPv6 596 packets. The keys used for both encryption and authentication can be 597 derived from an IKEv2 exchange. ESP Security Associations come as 598 pairs, one for each direction between two peers. Each SA is 599 identified by a Security Parameter Index (SPI), which is marked on 600 each encrypted ESP packet. 602 ESP packets include the SPI, a sequence number, an optional 603 Initialization Vector (IV), payload data, padding, a length and next 604 header field, and an Integrity Check Value. 606 From [RFC4303], "ESP is used to provide confidentiality, data origin 607 authentication, connectionless integrity, an anti-replay service (a 608 form of partial sequence integrity), and limited traffic flow 609 confidentiality." 611 Since ESP operates on IP packets, it is not directly tied to the 612 transport protocols it encrypts. This means it requires little or no 613 change from transports in order to provide security. 615 ESP packets may be sent directly over IP, but where network 616 conditions warrant (e.g., when a NAT is present or when a firewall 617 blocks such packets) they may be encapsulated in UDP [RFC3948] or TCP 618 [RFC8229]. 620 4.4.2. Security Features 622 4.4.2.1. IKEv2 624 o Forward-secure key establishment. 626 o Cryptographic algorithm negotiation. 628 o Peer authentication (Certificate, raw public key, pre-shared key, 629 and EAP). 631 o Mutual authentication. 633 o Record (datagram) confidentiality and integrity. 635 o Session resumption. 637 o Connection mobility. 639 o DoS mitigation (cookie-based). 641 4.4.2.2. ESP 643 o Record confidentiality and integrity. 645 o Record replay protection. 647 4.4.3. Protocol Dependencies 649 4.4.3.1. IKEv2 651 o Availability of UDP to negotiate, or implementation support for 652 TCP-encapsulation. 654 o Some EAP authentication types require accessing a hardware device, 655 such as a SIM card; or interacting with a user, such as password 656 prompting. 658 4.4.3.2. ESP 660 o Since ESP is below transport protocols, it does not have any 661 dependencies on the transports themselves, other than on UDP or 662 TCP where encapsulation is employed. 664 4.5. Secure RTP (with DTLS) 666 Secure RTP (SRTP) is a profile for RTP that provides confidentiality, 667 message authentication, and replay protection for RTP data packets 668 and RTP control protocol (RTCP) packets [RFC3711]. 670 4.5.1. Protocol description 672 SRTP adds confidentiality and optional integrity protection to RTP 673 data packets, and adds confidentially and mandatory integrity 674 protection to RTCP packets. For RTP data packets, this is done by 675 encrypting the payload section of the packet and optionally appending 676 an authentication tag (MAC) as a packet trailer, with the RTP header 677 authenticated but not encrypted (the RTP header was left unencrypted 678 to enable RTP header compression [RFC2508] [RFC3545]). For RTCP 679 packets, the first packet in the compound RTCP packet is partially 680 encrypted, leaving the first eight octets of the header as clear-text 681 to allow identification of the packet as RTCP, while the remainder of 682 the compound packet is fully encrypted. The entire RTCP packet is 683 then authenticated by appending a MAC as packet trailer. 685 Packets are encrypted using session keys, which are ultimately 686 derived from a master key and an additional master salt and session 687 salt. SRTP packets carry a 2-byte sequence number to partially 688 identify the unique packet index. SRTP peers maintain a separate 689 roll-over counter (ROC) for RTP data packets that is incremented 690 whenever the sequence number wraps. The sequence number and ROC 691 together determine the packet index. RTCP packets have a similar, 692 yet differently named, field called the RTCP index which serves the 693 same purpose. 695 Numerous encryption modes are supported. For popular modes of 696 operation, e.g., AES-CTR, the (unique) initialization vector (IV) 697 used for each encryption mode is a function of the RTP SSRC 698 (synchronization source), packet index, and session "salting key". 700 SRTP offers replay detection by keeping a replay list of already seen 701 and processed packet indices. If a packet arrives with an index that 702 matches one in the replay list, it is silently discarded. 704 DTLS [RFC5764] is commonly used to perform mutual authentication and 705 key agreement for SRTP [RFC5763]. Peers use DTLS to perform mutual 706 certificate-based authentication on the media path, and to generate 707 the SRTP master key. Peer certificates can be issued and signed by a 708 certificate authority. Alternatively, certificates used in the DTLS 709 exchange can be self-signed. If they are self-signed, certificate 710 fingerprints are included in the signalling exchange (e.g., in SIP or 711 WebRTC), and used to bind the DTLS key exchange in the media plane to 712 the signaling plane. The combination of a mutually authenticated 713 DTLS key exchange on the media path and a fingerprint sent in the 714 signalling channel protects against active attacks on the media, 715 provided the signalling can be trusted. Signalling needs to be 716 protected as described in, for example, SIP [RFC3261] Authenticated 717 Identity Management [RFC4474] or the WebRTC security architecture 718 [I-D.ietf-rtcweb-security-arch], to provide complete system security. 720 4.5.2. Security Features 722 o Forward-secure key establishment. 724 o Cryptographic algorithm negotiation. 726 o Mutual authentication. 728 o Partial datagram confidentiality. (Packet headers are not 729 encrypted.) 731 o Optional authentication of data packets. 733 o Mandatory authentication of control packets. 735 o Out-of-order record receipt. 737 4.5.3. Protocol Dependencies 739 o External key derivation and management protocol, e.g., DTLS 740 [RFC5763]. 742 o External identity management protocol, e.g., SIP Authenticated 743 Identity Management [RFC4474], WebRTC Security Architecture 744 [I-D.ietf-rtcweb-security-arch]. 746 4.5.4. Variant: ZRTP for Media Path Key Agreement 748 ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It 749 uses standard SRTP to protect RTP data packets and RTCP packets, but 750 provides alternative key agreement and identity management protocols. 752 Key agreement is performed using a Diffie-Hellman key exchange that 753 runs on the media path. This generates a shared secret that is then 754 used to generate the master key and salt for SRTP. 756 ZRTP does not rely on a PKI or external identity management system. 757 Rather, it uses an ephemeral Diffie-Hellman key exchange with hash 758 commitment to allow detection of man-in-the-middle attacks. This 759 requires endpoints to display a short authentication string that the 760 users must read and verbally compare to validate the hashes and 761 ensure security. Endpoints cache some key material after the first 762 call to use in subsequent calls; this is mixed in with the Diffie- 763 Hellman shared secret, so the short authentication string need only 764 be checked once for a given user. This gives key continuity 765 properties analogous to the secure shell (ssh) [RFC4253]. 767 4.6. tcpcrypt 769 Tcpcrypt is a lightweight extension to the TCP protocol to enable 770 opportunistic encryption with hooks available to the application 771 layer for implementation of endpoint authentication. 773 4.6.1. Protocol Description 775 Tcpcrypt extends TCP to enable opportunistic encryption between the 776 two ends of a TCP connection [I-D.ietf-tcpinc-tcpcrypt]. It is a 777 family of TCP encryption protocols (TEP), distinguished by key 778 exchange algorithm. The use of a TEP is negotiated with a TCP option 779 during the initial TCP handshake via the mechanism described by TCP 780 Encryption Negotiation Option (ENO) [I-D.ietf-tcpinc-tcpeno]. In the 781 case of initial session establishment, once a tcpcrypt TEP has been 782 negotiated the key exchange occurs within the data segments of the 783 first few packets exchanged after the handshake completes. The 784 initiator of a connection sends a list of supported AEAD algorithms, 785 a random nonce, and an ephemeral public key share. The responder 786 typically chooses a mutually-supported AEAD algorithm and replies 787 with this choice, its own nonce, and ephemeral key share. An initial 788 shared secret is derived from the ENO handshake, the tcpcrypt 789 handshake, and the initial keying material resulting from the key 790 exchange. The traffic encryption keys on the initial connection are 791 derived from the shared secret. Connections can be re-keyed before 792 the natural AEAD limit for a single set of traffic encryption keys is 793 reached. 795 Each tcpcrypt session is associated with a ladder of resumption IDs, 796 each derived from the respective entry in a ladder of shared secrets. 797 These resumption IDs can be used to negotiate a stateful resumption 798 of the session in a subsequent connection, resulting in use of a new 799 shared secret and traffic encryption keys without requiring a new key 800 exchange. Willingness to resume a session is signaled via the ENO 801 option during the TCP handshake. Given the length constraints 802 imposed by TCP options, unlike stateless resumption mechanisms (such 803 as that provided by session tickets in TLS) resumption in tcpcrypt 804 requires the maintenance of state on the server, and so successful 805 resumption across a pool of servers implies shared state. 807 Owing to middlebox ossification issues, tcpcrypt only protects the 808 payload portion of a TCP packet. It does not encrypt any header 809 information, such as the TCP sequence number. 811 Tcpcrypt exposes a universally-unique connection-specific session ID 812 to the application, suitable for application-level endpoint 813 authentication either in-band or out-of-band. 815 4.6.2. Security Features 817 o Forward-secure key establishment. 819 o Record (channel) confidentiality and integrity. 821 o Stateful cross-connection session resumption. 823 o Session caching and management. 825 o Connection re-keying. 827 o Application authentication delegation. 829 4.6.3. Protocol Dependencies 831 o TCP. 833 o TCP Encryption Negotiation Option (ENO). 835 4.7. WireGuard 837 WireGuard is a layer 3 protocol designed to complement or replace 838 IPsec [WireGuard] for certain use cases. It uses UDP to encapsulate 839 IP datagrams between peers. Unlike most transport security 840 protocols, which rely on PKI for peer authentication, WireGuard 841 authenticates peers using pre-shared public keys delivered out-of- 842 band, each of which is bound to one or more IP addresses. Moreover, 843 as a protocol suited for VPNs, WireGuard offers no extensibility, 844 negotiation, or cryptographic agility. 846 4.7.1. Protocol description 848 WireGuard is a simple VPN protocol that binds a pre-shared public key 849 to one or more IP addresses. Users configure WireGuard by 850 associating peer public keys with IP addresses. These mappings are 851 stored in a CryptoKey Routing Table. (See Section 2 of [WireGuard] 852 for more details and sample configurations.) These keys are used 853 upon WireGuard packet transmission and reception. For example, upon 854 receipt of a Handshake Initiation message, receivers use the static 855 public key in their CryptoKey routing table to perform necessary 856 cryptographic computations. 858 WireGuard builds on Noise [Noise] for 1-RTT key exchange with 859 identity hiding. The handshake hides peer identities as per the 860 SIGMA construction [SIGMA]. As a consequence of using Noise, 861 WireGuard comes with a fixed set of cryptographic algorithms: 863 o x25519 [Curve25519] and HKDF [RFC5869] for ECDH and key 864 derivation. 866 o ChaCha20+Poly1305 [RFC7539] for packet authenticated encryption. 868 o BLAKE2s [BLAKE2] for hashing. 870 There is no cryptographic agility. If weaknesses are found in any of 871 these algorithms, new message types using new algorithms must be 872 introduced. 874 WireGuard is designed to be entirely stateless, modulo the CryptoKey 875 routing table, which has size linear with the number of trusted 876 peers. If a WireGuard receiver is under heavy load and cannot 877 process a packet, e.g., cannot spare CPU cycles for point 878 multiplication, it can reply with a cookie similar to DTLS and IKEv2. 879 This cookie only proves IP address ownership. Any rate limiting 880 scheme can be applied to packets coming from non-spoofed addresses. 882 4.7.2. Security Features 884 o Forward-secure key establishment. 886 o Peer authentication (Public-key and PSK). 888 o Mutual authentication. 890 o Record replay prevention (Stateful, timestamp-based). 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. MinimalT 902 MinimalT is a UDP-based transport security protocol designed to offer 903 confidentiality, mutual authentication, DoS prevention, and 904 connection mobility [MinimalT]. One major goal of the protocol is to 905 leverage existing protocols to obtain server-side configuration 906 information used to more quickly bootstrap a connection. MinimalT 907 uses a variant of TCP's congestion control algorithm. 909 4.8.1. Protocol Description 911 MinimalT is a secure transport protocol built on top of a widespread 912 directory service. Clients and servers interact with local directory 913 services to (a) resolve server information and (b) public ephemeral 914 state information, respectively. Clients connect to a local resolver 915 once at boot time. Through this resolver they recover the IP 916 address(es) and public key(s) of each server to which they want to 917 connect. 919 Connections are instances of user-authenticated, mobile sessions 920 between two endpoints. Connections run within tunnels between hosts. 921 A tunnel is a server-authenticated container that multiplexes 922 multiple connections between the same hosts. All connections in a 923 tunnel share the same transport state machine and encryption. Each 924 tunnel has a dedicated control connection used to configure and 925 manage the tunnel over time. Moreover, since tunnels are independent 926 of the network address information, they may be reused as both ends 927 of the tunnel move about the network. This does however imply that 928 the connection establishment and packet encryption mechanisms are 929 coupled. 931 Before a client connects to a remote service, it must first establish 932 a tunnel to the host providing or offering the service. Tunnels are 933 established in 1-RTT using an ephemeral key obtained from the 934 directory service. Tunnel initiators provide their own ephemeral key 935 and, optionally, a DoS puzzle solution such that the recipient 936 (server) can verify the authenticity of the request and derive a 937 shared secret. Within a tunnel, new connections to services may be 938 established. 940 4.8.2. Protocol Features 942 o Forward-secure key establishment. 944 o DoS mitigation (puzzle-based). 946 o Connection mobility (based on tunnel identifiers). 948 Additional (orthogonal) transport features include: connection 949 multiplexing between hosts across shared tunnels, and congestion 950 control state is shared across connections between the same host 951 pairs. 953 4.8.3. Protocol Dependencies 955 o A DNS-like resolution service to obtain location information (an 956 IP address) and ephemeral keys. 958 o A PKI trust store for certificate validation. 960 4.9. CurveCP 962 CurveCP [CurveCP] is a UDP-based transport security protocol from 963 Daniel J. Bernstein. Unlike other transport security protocols, it 964 is based entirely upon highly efficient public key algorithms. This 965 removes many pitfalls associated with nonce reuse and key 966 synchronization. 968 4.9.1. Protocol Description 970 CurveCP is a UDP-based transport security protocol. It is built on 971 three principal features: exclusive use of public key authenticated 972 encryption of packets, server-chosen cookies to prohibit memory and 973 computation DoS at the server, and connection mobility with a client- 974 chosen ephemeral identifier. 976 There are two rounds in CurveCP. In the first round, the client 977 sends its first initialization packet to the server, carrying its 978 (possibly fresh) ephemeral public key C', with zero-padding encrypted 979 under the server's long-term public key. The server replies with a 980 cookie and its own ephemeral key S' and a cookie that is to be used 981 by the client. Upon receipt, the client then generates its second 982 initialization packet carrying: the ephemeral key C', cookie, and an 983 encryption of C', the server's domain name, and, optionally, some 984 message data. The server verifies the cookie and the encrypted 985 payload and, if valid, proceeds to send data in return. At this 986 point, the connection is established and the two parties can 987 communicate. 989 The use of only public-key encryption and authentication, or 990 "boxing", is done to simplify problems that come with symmetric key 991 management and synchronization. For example, it allows the sender of 992 a message to be in complete control of each message's nonce. It does 993 not require either end to share secret keying material. Furthermore, 994 it allows connections (or sessions) to be associated with unique 995 ephemeral public keys as a mechanism for enabling forward secrecy 996 given the risk of long-term private key compromise. 998 The client and server do not perform a standard key exchange. 999 Instead, in the initial exchange of packets, each party provides its 1000 own ephemeral key to the other end. The client can choose a new 1001 ephemeral key for every new connection. However, the server must 1002 rotate these keys on a slower basis. Otherwise, it would be trivial 1003 for an attacker to force the server to create and store ephemeral 1004 keys with a fake client initialization packet. 1006 Servers use cookies for source validation. After receiving a 1007 client's initial packet, encrypted under the server's long-term 1008 public key, a server generates and returns a stateless cookie that 1009 must be echoed back in the client's following message. This cookie 1010 is encrypted under the client's ephemeral public key. This stateless 1011 technique prevents attackers from hijacking client initialization 1012 packets to obtain cookie values to flood clients. (A client would 1013 detect the duplicate cookies and reject the flooded packets.) 1014 Similarly, replaying the client's second packet, carrying the cookie, 1015 will be detected by the server. 1017 CurveCP supports a weak form of client authentication. Clients are 1018 permitted to send their long-term public keys in the second 1019 initialization packet. A server can verify this public key and, if 1020 untrusted, drop the connection and subsequent data. 1022 Unlike some other protocols, CurveCP data packets leave only the 1023 ephemeral public key, the connection ID, and the per-message nonce in 1024 the clear. Everything else is encrypted. 1026 4.9.2. Protocol Features 1028 o Datagram confidentiality and integrity (via public key 1029 encryption). 1031 o Connection mobility (based on a client-chosen ephemeral 1032 identifier). 1034 o Optional length-hiding and anti-amplification padding. 1036 4.9.3. Protocol Dependencies 1038 o An unreliable transport protocol such as UDP. 1040 5. Security Features and Transport Dependencies 1042 There exists a common set of features shared across the transport 1043 protocols surveyed in this document. Mandatory features constitute a 1044 baseline of functionality that an application may assume for any TAPS 1045 implementation. They were selected on the basis that they are either 1046 (a) required for any secure transport protocol or (b) nearly 1047 ubiquitous amongst common secure transport protocols. Optional 1048 features by contrast may vary from implementation to implementation, 1049 and so an application cannot simply assume they are available. 1050 Applications learn of and use optional features by querying for their 1051 presence and support. Optional features may not be implemented, or 1052 may be disabled if their presence impacts transport services or if a 1053 necessary transport service is unavailable. 1055 5.1. Mandatory Features 1057 o Segment or datagram encryption and authentication: Protect transit 1058 data with an authenticated encryption algorithm. 1060 o Forward-secure key establishment. 1062 o Public-key (raw or certificate) based authentication. 1064 o Unilateral responder authentication. 1066 o Pre-shared key support. 1068 5.2. Optional Features 1070 o Cryptographic algorithm negotiation (AN): 1072 * Transport dependency: None. 1074 * Application dependency: Application awareness of supported or 1075 desired algorithms. 1077 o Application authentication delegation (AD): 1079 * Transport dependency: None. 1081 * Application dependency: Application opt-in and policy for 1082 endpoint authentication 1084 o Mutual authentication (MA): 1086 * Transport dependency: None. 1088 * Application dependency: Mutual authentication required for 1089 application support. 1091 o DoS mitigation (DM): 1093 * Transport dependency: None. 1095 * Application dependency: None. 1097 o Connection mobility (CM): 1099 * Transport dependency: Connections are unreliable or can change 1100 due to unpredictable network events, e.g., NAT re-bindings. 1102 * Application dependency: None. 1104 o Source validation (SV): 1106 * Transport dependency: Packets may arrive as datagrams instead 1107 of streams from unauthenticated sources. 1109 * Application dependency: None. 1111 o Application-layer feature negotiation (AFN): 1113 * Transport dependency: None. 1115 * Application dependency: Specification of application-layer 1116 features or functionality. 1118 o Configuration extensions (CX): 1120 * Transport dependency: None. 1122 * Application dependency: Specification of application-specific 1123 extensions. 1125 o Session caching and management (SC): 1127 * Transport dependency: None. 1129 * Application dependency: None. 1131 o Early data support (ED): 1133 * Transport dependency: None. 1135 * Application dependency: Anti-replay protections or hints of 1136 data idempotency. 1138 o Length-hiding padding (LHP): 1140 * Transport dependency: None. 1142 * Application dependency: Knowledge of desired padding policies. 1144 5.3. Optional Feature Availability 1146 The following table lists the availability of the above-listed 1147 optional features in each of the analyzed protocols. "Mandatory" 1148 indicates that the feature is intrinsic to the protocol and cannot be 1149 disabled. "Supported" indicates that the feature is optionally 1150 provided natively or through a (standardized, where applicable) 1151 extension. 1153 +----------+---+----+----+-----+----+----+-----+----+----+-----+----+ 1154 | Protocol | A | AD | MA | DM | CM | SV | AFN | CX | SC | LHP | ED | 1155 | | N | | | | | | | | | | | 1156 +----------+---+----+----+-----+----+----+-----+----+----+-----+----+ 1157 | TLS | S | S | S | S | U* | M | S | S | S | S | S | 1158 | | | | | | | | | | | | | 1159 | DTLS | S | S | S | S | S | M | S | S | S | S | U | 1160 | | | | | | | | | | | | | 1161 | IETF | S | S | S | S | S | M | S | S | S | S | S | 1162 | QUIC | | | | | | | | | | | | 1163 | | | | | | | | | | | | | 1164 | IKEv2+ES | S | S | M | S | S | M | S | S | S | S | U | 1165 | P | | | | | | | | | | | | 1166 | | | | | | | | | | | | | 1167 | SRTP+DTL | S | S | S | S | U | M | S | S | S | U | U | 1168 | S | | | | | | | | | | | | 1169 | | | | | | | | | | | | | 1170 | tcpcrypt | S | M | U | U** | U* | M | U | U | S | U | U | 1171 | | | | | | | | | | | | | 1172 | WireGuar | U | S | M | S | U | M | U | U | U | S+ | U | 1173 | d | | | | | | | | | | | | 1174 | | | | | | | | | | | | | 1175 | MinimalT | U | U | M | S | M | M | U | U | U | S | U | 1176 | | | | | | | | | | | | | 1177 | CurveCP | U | U | S | S | M | M | U | U | U | S | U | 1178 +----------+---+----+----+-----+----+----+-----+----+----+-----+----+ 1180 M=Mandatory S=Supported but not required U=Unsupported *=On TCP; 1181 MPTCP would provide this ability **=TCP provides SYN cookies 1182 natively, but these are not cryptographically strong +=For transport 1183 packets only 1185 6. Transport Security Protocol Interfaces 1187 This section describes the interface surface exposed by the security 1188 protocols described above. Note that not all protocols support each 1189 interface. We partition these interfaces into pre-connection 1190 (configuration), connection, and post-connection interfaces, 1191 following conventions in [I-D.ietf-taps-interface] and 1192 [I-D.ietf-taps-arch]. 1194 6.1. Pre-Connection Interfaces 1196 Configuration interfaces are used to configure the security protocols 1197 before a handshake begins or the keys are negotiated. 1199 o Identity and Private Keys The application can provide its 1200 identities (certificates) and private keys, or mechanisms to 1201 access these, to the security protocol to use during handshakes. 1202 Protocols: TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2, 1203 WireGuard, SRTP 1205 o Supported Algorithms (Key Exchange, Signatures, and Ciphersuites) 1206 The application can choose the algorithms that are supported for 1207 key exchange, signatures, and ciphersuites. Protocols: TLS, DTLS, 1208 QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP 1210 o Session Cache Management The application provides the ability to 1211 save and retrieve session state (such as tickets, keying material, 1212 and server parameters) that may be used to resume the security 1213 session. Protocols: TLS, DTLS, QUIC + TLS, MinimalT 1215 o Authentication Delegation The application provides access to a 1216 separate module that will provide authentication, using EAP for 1217 example. Protocols: IKEv2, SRTP 1219 o Pre-Shared Key Import Either the handshake protocol or the 1220 application directly can supply pre-shared keys for the record 1221 protocol use for encryption/decryption and authentication. If the 1222 application can supply keys directly, this is considered explicit 1223 import; if the handshake protocol traditionally provides the keys 1224 directly, it is considered direct import; if the keys can only be 1225 shared by the handshake, they are considered non-importable. 1227 * Explict import: QUIC, ESP 1229 * Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard 1230 * Non-importable: CurveCP 1232 6.2. Connection Interfaces 1234 o Identity Validation During a handshake, the security protocol will 1235 conduct identity validation of the peer. This can call into the 1236 application to offload validation. Protocols: All (TLS, DTLS, 1237 QUIC + TLS, MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS)) 1239 o Source Address Validation The handshake protocol may delegate 1240 validation of the remote peer that has sent data to the transport 1241 protocol or application. This involves sending a cookie exchange 1242 to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard 1244 6.3. Post-Connection Interfaces 1246 o Connection Termination The security protocol may be instructed to 1247 tear down its connection and session information. This is needed 1248 by some protocols to prevent application data truncation attacks. 1249 Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2 1251 o Key Update The handshake protocol may be instructed to update its 1252 keying material, either by the application directly or by the 1253 record protocol sending a key expiration event. Protocols: TLS, 1254 DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2 1256 o Pre-Shared Key Export The handshake protocol will generate one or 1257 more keys to be used for record encryption/decryption and 1258 authentication. These may be explicitly exportable to the 1259 application, traditionally limited to direct export to the record 1260 protocol, or inherently non-exportable because the keys must be 1261 used directly in conjunction with the record protocol. 1263 * Explicit export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for 1264 SRTP) 1266 * Direct export: TLS, DTLS, MinimalT 1268 * Non-exportable: CurveCP 1270 o Key Expiration The record protocol can signal that its keys are 1271 expiring due to reaching a time-based deadline, or a use-based 1272 deadline (number of bytes that have been encrypted with the key). 1273 This interaction is often limited to signaling between the record 1274 layer and the handshake layer. Protocols: ESP ((Editor's note: 1275 One may consider TLS/DTLS to also have this interface)) 1277 o Connection mobility The record protocol can be signaled that it is 1278 being migrated to another transport or interface due to connection 1279 mobility, which may reset address and state validation. 1280 Protocols: QUIC, MinimalT, CurveCP, ESP, WireGuard (roaming) 1282 7. IANA Considerations 1284 This document has no request to IANA. 1286 8. Security Considerations 1288 This document summarizes existing transport security protocols and 1289 their interfaces. It does not propose changes to or recommend usage 1290 of reference protocols. Moreover, no claims of security and privacy 1291 properties beyond those guaranteed by the protocols discussed are 1292 made. For example, metadata leakage via timing side channels and 1293 traffic analysis may compromise any protocol discussed in this 1294 survey. Applications using Security Interfaces SHOULD take such 1295 limitations into consideration when using a particular protocol 1296 implementation. 1298 9. Acknowledgments 1300 The authors would like to thank Mirja Kuehlewind, Brian Trammell, 1301 Yannick Sierra, Frederic Jacobs, and Bob Bradley for their input and 1302 feedback on earlier versions of this draft. 1304 10. Normative References 1306 [ALTS] "Application Layer Transport Security", n.d.. 1308 [BLAKE2] "BLAKE2 -- simpler, smaller, fast as MD5", n.d.. 1310 [Curve25519] 1311 "Curve25519 - new Diffie-Hellman speed records", n.d.. 1313 [CurveCP] "CurveCP -- Usable security for the Internet", n.d.. 1315 [I-D.ietf-quic-tls] 1316 Thomson, M. and S. Turner, "Using Transport Layer Security 1317 (TLS) to Secure QUIC", draft-ietf-quic-tls-15 (work in 1318 progress), October 2018. 1320 [I-D.ietf-quic-transport] 1321 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1322 and Secure Transport", draft-ietf-quic-transport-15 (work 1323 in progress), October 2018. 1325 [I-D.ietf-rtcweb-security-arch] 1326 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 1327 rtcweb-security-arch-15 (work in progress), July 2018. 1329 [I-D.ietf-taps-arch] 1330 Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., 1331 Perkins, C., Tiesel, P., and C. Wood, "An Architecture for 1332 Transport Services", draft-ietf-taps-arch-02 (work in 1333 progress), October 2018. 1335 [I-D.ietf-taps-interface] 1336 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 1337 Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An 1338 Abstract Application Layer Interface to Transport 1339 Services", draft-ietf-taps-interface-02 (work in 1340 progress), October 2018. 1342 [I-D.ietf-tcpinc-tcpcrypt] 1343 Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, 1344 Q., and E. Smith, "Cryptographic protection of TCP Streams 1345 (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-13 (work in 1346 progress), September 2018. 1348 [I-D.ietf-tcpinc-tcpeno] 1349 Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. 1350 Smith, "TCP-ENO: Encryption Negotiation Option", draft- 1351 ietf-tcpinc-tcpeno-19 (work in progress), June 2018. 1353 [I-D.ietf-tls-dtls-connection-id] 1354 Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, 1355 "The Datagram Transport Layer Security (DTLS) Connection 1356 Identifier", draft-ietf-tls-dtls-connection-id-01 (work in 1357 progress), July 2018. 1359 [I-D.ietf-tls-dtls13] 1360 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1361 Datagram Transport Layer Security (DTLS) Protocol Version 1362 1.3", draft-ietf-tls-dtls13-28 (work in progress), July 1363 2018. 1365 [I-D.ietf-tls-record-limit] 1366 Thomson, M., "Record Size Limit Extension for Transport 1367 Layer Security (TLS)", draft-ietf-tls-record-limit-03 1368 (work in progress), May 2018. 1370 [I-D.ietf-tls-tls13] 1371 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1372 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 1373 March 2018. 1375 [MinimalT] 1376 "MinimaLT -- Minimal-latency Networking Through Better 1377 Security", n.d.. 1379 [Noise] "The Noise Protocol Framework", n.d.. 1381 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1382 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 1383 1998, . 1385 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 1386 Headers for Low-Speed Serial Links", RFC 2508, 1387 DOI 10.17487/RFC2508, February 1999, 1388 . 1390 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1391 A., Peterson, J., Sparks, R., Handley, M., and E. 1392 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1393 DOI 10.17487/RFC3261, June 2002, 1394 . 1396 [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and 1397 P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with 1398 High Delay, Packet Loss and Reordering", RFC 3545, 1399 DOI 10.17487/RFC3545, July 2003, 1400 . 1402 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1403 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1404 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1405 . 1407 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1408 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1409 RFC 3948, DOI 10.17487/RFC3948, January 2005, 1410 . 1412 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 1413 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 1414 January 2006, . 1416 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1417 DOI 10.17487/RFC4302, December 2005, 1418 . 1420 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1421 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1422 . 1424 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1425 Authenticated Identity Management in the Session 1426 Initiation Protocol (SIP)", RFC 4474, 1427 DOI 10.17487/RFC4474, August 2006, 1428 . 1430 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1431 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 1432 . 1434 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1435 (TLS) Protocol Version 1.2", RFC 5246, 1436 DOI 10.17487/RFC5246, August 2008, 1437 . 1439 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 1440 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 1441 DOI 10.17487/RFC5723, January 2010, 1442 . 1444 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1445 for Establishing a Secure Real-time Transport Protocol 1446 (SRTP) Security Context Using Datagram Transport Layer 1447 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1448 2010, . 1450 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1451 Security (DTLS) Extension to Establish Keys for the Secure 1452 Real-time Transport Protocol (SRTP)", RFC 5764, 1453 DOI 10.17487/RFC5764, May 2010, 1454 . 1456 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1457 Key Derivation Function (HKDF)", RFC 5869, 1458 DOI 10.17487/RFC5869, May 2010, 1459 . 1461 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1462 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1463 June 2010, . 1465 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1466 Extensions: Extension Definitions", RFC 6066, 1467 DOI 10.17487/RFC6066, January 2011, 1468 . 1470 [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: 1471 Media Path Key Agreement for Unicast Secure RTP", 1472 RFC 6189, DOI 10.17487/RFC6189, April 2011, 1473 . 1475 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1476 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1477 January 2012, . 1479 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1480 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1481 Transport Layer Security (TLS) and Datagram Transport 1482 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1483 June 2014, . 1485 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1486 Kivinen, "Internet Key Exchange Protocol Version 2 1487 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1488 2014, . 1490 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1491 "Transport Layer Security (TLS) Application-Layer Protocol 1492 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1493 July 2014, . 1495 [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 1496 Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, 1497 . 1499 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 1500 Ed., "Services Provided by IETF Transport Protocols and 1501 Congestion Control Mechanisms", RFC 8095, 1502 DOI 10.17487/RFC8095, March 2017, 1503 . 1505 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 1506 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 1507 August 2017, . 1509 [SIGMA] "SIGMA -- The 'SIGn-and-MAc' Approach to Authenticated 1510 Diffie-Hellman and Its Use in the IKE-Protocols", n.d.. 1512 [WireGuard] 1513 "WireGuard -- Next Generation Kernel Network Tunnel", 1514 n.d.. 1516 Authors' Addresses 1518 Tommy Pauly 1519 Apple Inc. 1520 One Apple Park Way 1521 Cupertino, California 95014 1522 United States of America 1524 Email: tpauly@apple.com 1526 Colin Perkins 1527 University of Glasgow 1528 School of Computing Science 1529 Glasgow G12 8QQ 1530 United Kingdom 1532 Email: csp@csperkins.org 1534 Kyle Rose 1535 Akamai Technologies, Inc. 1536 150 Broadway 1537 Cambridge, MA 02144 1538 United States of America 1540 Email: krose@krose.org 1542 Christopher A. Wood 1543 Apple Inc. 1544 One Apple Park Way 1545 Cupertino, California 95014 1546 United States of America 1548 Email: cawood@apple.com