idnits 2.17.1 draft-pauly-taps-transport-security-00.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 03, 2017) is 2489 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-quic-transport' is defined on line 941, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-04 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-04 == Outdated reference: A later version (-15) exists of draft-ietf-tcpinc-tcpcrypt-06 == Outdated reference: A later version (-19) exists of draft-ietf-tcpinc-tcpeno-08 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-20 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 3 errors (**), 0 flaws (~~), 7 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 C. Wood 4 Intended status: Informational Apple Inc. 5 Expires: January 4, 2018 July 03, 2017 7 A Survey of Transport Security Protocols 8 draft-pauly-taps-transport-security-00 10 Abstract 12 This document provides a survey of commonly used or notable network 13 security protocols, with a focus on how they interact and integrate 14 with applications and transport protocols. Its goal is to supplement 15 efforts to define and catalog transport services [RFC8095] by 16 describing the interfaces required to add security protocols. It 17 examines Transport Layer Security (TLS), Datagram Transport Layer 18 Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + 19 TLS), MinimalT, CurveCP, tcpcrypt, and Internet Key Exchange with 20 Encapsulating Security Protocol (IKEv2 + ESP). This survey is not 21 limited to protocols developed within the scope or context of the 22 IETF. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 4, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Transport Security Protocol Descriptions . . . . . . . . . . 4 61 3.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1.1. Protocol Description . . . . . . . . . . . . . . . . 5 63 3.1.2. Protocol Features . . . . . . . . . . . . . . . . . . 6 64 3.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 6 65 3.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.2.1. Protocol Description . . . . . . . . . . . . . . . . 7 67 3.2.2. Protocol Features . . . . . . . . . . . . . . . . . . 7 68 3.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 7 69 3.3. QUIC with TLS . . . . . . . . . . . . . . . . . . . . . . 8 70 3.3.1. Protocol Description . . . . . . . . . . . . . . . . 8 71 3.3.2. Protocol Features . . . . . . . . . . . . . . . . . . 8 72 3.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 9 73 3.4. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 9 74 3.4.1. Protocol Description . . . . . . . . . . . . . . . . 9 75 3.4.2. Protocol Features . . . . . . . . . . . . . . . . . . 10 76 3.4.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10 77 3.5. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 3.5.1. Protocol Description . . . . . . . . . . . . . . . . 10 79 3.5.2. Protocol Features . . . . . . . . . . . . . . . . . . 12 80 3.5.3. Protocol Dependencies . . . . . . . . . . . . . . . . 12 81 3.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 12 82 3.6.1. Protocol Description . . . . . . . . . . . . . . . . 12 83 3.6.2. Protocol Features . . . . . . . . . . . . . . . . . . 13 84 3.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 13 85 3.7. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 13 86 3.7.1. Protocol descriptions . . . . . . . . . . . . . . . . 13 87 3.7.2. Protocol features . . . . . . . . . . . . . . . . . . 14 88 3.7.3. Protocol dependencies . . . . . . . . . . . . . . . . 15 89 4. Common Transport Security Features . . . . . . . . . . . . . 15 90 4.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 16 91 4.1.1. Handshake . . . . . . . . . . . . . . . . . . . . . . 16 92 4.1.2. Record . . . . . . . . . . . . . . . . . . . . . . . 16 93 4.2. Optional Features . . . . . . . . . . . . . . . . . . . . 16 94 4.2.1. Handshake . . . . . . . . . . . . . . . . . . . . . . 16 95 4.2.2. Record . . . . . . . . . . . . . . . . . . . . . . . 17 96 5. Transport Security Protocol Interfaces . . . . . . . . . . . 17 97 5.1. Configuration Interfaces . . . . . . . . . . . . . . . . 17 98 5.2. Handshake Interfaces . . . . . . . . . . . . . . . . . . 17 99 5.3. Record Interfaces . . . . . . . . . . . . . . . . . . . . 18 100 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 102 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 103 9. Normative References . . . . . . . . . . . . . . . . . . . . 20 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 106 1. Introduction 108 This document provides a survey of commonly used or notable network 109 security protocols, with a focus on how they interact and integrate 110 with applications and transport protocols. Its goal is to supplement 111 efforts to define and catalog transport services [RFC8095] by 112 describing the interfaces required to add security protocols. It 113 examines Transport Layer Security (TLS), Datagram Transport Layer 114 Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + 115 TLS), MinimalT, CurveCP, tcpcrypt, and Internet Key Exchange with 116 Encapsulating Security Protocol (IKEv2 + ESP). This survey is not 117 limited to protocols developed within the scope or context of the 118 IETF. 120 For each protocol, this document provides a brief description, the 121 security features it provides, and the dependencies it has on the 122 underlying transport. This is followed by defining the set of 123 transport security features shared by these protocols. Finally, we 124 distill the application and transport interfaces provided by the 125 transport security protocols. 127 2. Terminology 129 The following terms are used throughout this document to describe the 130 roles and interactions of transport security protocols: 132 o Transport Feature: a specific end-to-end feature that the 133 transport layer provides to an application. Examples include 134 confidentiality, reliable delivery, ordered delivery, message- 135 versus-stream orientation, etc. 137 o Transport Service: a set of Transport Features, without an 138 association to any given framing protocol, which provides a 139 functionality to an application. 141 o Transport Protocol: an implementation that provides one or more 142 different transport services using a specific framing and header 143 format on the wire. A Transport Protocol services an application. 145 o Application: an entity that uses a transport protocol for end-to- 146 end delivery of data across the network (this may also be an upper 147 layer protocol or tunnel encapsulation). 149 o Security Feature: a specific feature that a network security layer 150 provides to applications. Examples include authentication, 151 encryption, key generation, session resumption, and privacy. A 152 feature may be considered to be Mandatory or Optional to an 153 application's implementation. 155 o Security Protocol: a defined network protocol that implements one 156 or more security features. Security protocols may be used 157 alongside transport protocols, and in combination with one another 158 when appropriate. 160 o Handshake Protocol: a security protocol that performs a handshake 161 to validate peers and establish a shared cryptographic key. 163 o Record Protocol: a security protocol that allows data to be 164 encrypted in records or datagrams based on a shared cryptographic 165 key. 167 o Session: an ephemeral security association between applications. 169 o Connection: the shared state of two or more endpoints that 170 persists across messages that are transmitted between these 171 endpoints. A connection is a transient participant of a session, 172 and a session generally lasts between connection instances. 174 o Connection Mobility: a property of a connection that allows it to 175 be multihomed or resilient across network interface or address 176 changes. 178 o Peer: an endpoint application party to a session. 180 o Client: the peer responsible for initiating a session. 182 o Server: the peer responsible for responding to a session 183 initiation. 185 3. Transport Security Protocol Descriptions 187 This section contains descriptions of security protocols that 188 currently used to protect data being sent over a network. 190 For each protocol, we describe the features it provides and its 191 dependencies on other protocols. 193 3.1. TLS 195 TLS (Transport Layer Security) [RFC5246] is a common protocol used to 196 establish a secure session between two endpoints. Communication over 197 this session "prevents eavesdropping, tampering, and message 198 forgery." TLS consists of a tightly coupled handshake and record 199 protocol. The handshake protocol is used to authenticate peers, 200 negotiate protocol options, such as cryptographic algorithms, and 201 derive session-specific keying material. The record protocol is used 202 to marshal (possibly encrypted) data from one peer to the other. 203 This data may contain handshake messages or raw application data. 205 3.1.1. Protocol Description 207 TLS is the composition of a handshake and record protocol 208 [I-D.ietf-tls-tls13]. The record protocol is designed to marshal an 209 arbitrary, in-order stream of bytes from one endpoint to the other. 210 It handles segmenting, compressing (when enabled), and encrypting 211 data into discrete records. When configured to use an AEAD 212 algorithm, it also handles nonce generation and encoding for each 213 record. The record protocol is hidden from the client behind a byte 214 stream-oriented API. 216 The handshake protocol serves several purposes, including: peer 217 authentication, protocol option (key exchange algorithm and 218 ciphersuite) negotiation, and key derivation. Peer authentication 219 may be mutual. However, commonly, only the server is authenticated. 220 X.509 certificates are commonly used in this authentication step, 221 though other mechanisms, such as raw public keys [RFC7250], exist. 222 The client is not authenticated unless explicitly requested by the 223 server with a CertificateRequest handshake message. 225 The handshake protocol is also extensible. It allows for a variety 226 of extensions to be included by either the client or server. These 227 extensions are used to specify client preferences, e.g., the 228 application-layer protocol to be driven with the TLS connection 229 [RFC7301], or signals to the server to aid operation, e.g., the 230 server name [RFC6066]. Various extensions also exist to tune the 231 parameters of the record protocol, e.g., the maximum fragment length 232 [RFC6066]. 234 Alerts are used to convey errors and other atypical events to the 235 endpoints. There are two classes of alerts: closure and error 236 alerts. A closure alert is used to signal to the other peer that the 237 sender wishes to terminate the connection. The sender typically 238 follows a close alert with a TCP FIN segment to close the connection. 239 Error alerts are used to indicate problems with the handshake or 240 individual records. Most errors are fatal and are followed by 241 connection termination. However, warning alerts may be handled at 242 the discretion of each respective implementation. 244 Once a session is disconnected all session keying material must be 245 torn down, unless resumption information was previously negotiated. 246 TLS supports stateful and stateless resumption. (Here, the state 247 refers to the information requirements for the server. It is assumed 248 that the client must always store some state information in order to 249 resume a session.) 251 3.1.2. Protocol Features 253 o Key exchange and ciphersuite algorithm negotiation. 255 o Stateful and stateless session resumption. 257 o Certificate- and raw public-key-based authentication. 259 o Mutual client and server authentication. 261 o Byte stream confidentiality and integrity. 263 o Extensibility via well-defined extensions. 265 o 0-RTT data support (in TLS 1.3 only). 267 o Application-layer protocol negotiation. 269 o Transparent data segmentation. 271 3.1.3. Protocol Dependencies 273 o TCP for in-order, reliable transport. 275 o (Optionally) A PKI trust store for certificate validation. 277 3.2. DTLS 279 DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS, 280 but differs in that it is designed to run over UDP instead of TCP. 281 Since UDP does not guarantee datagram ordering or reliability, DTLS 282 modifies the protocol to make sure it can still provide the same 283 security guarantees as TLS. DTLS was designed to be as close to TLS 284 as possible, so this document will assume that all properties from 285 TLS are carried over except where specified. 287 3.2.1. Protocol Description 289 DTLS is modified from TLS to account for packet loss and reordering 290 that occur when operating over a datagram-based transport, i.e., UDP. 291 Each message is assigned an explicit sequence number to be used to 292 reorder on the receiving end. This removes the inter-record 293 dependency and allows each record to be decrypt in isolation of the 294 rest. However, DTLS does not deviate from TLS in that in still 295 provides in-order delivery of data to the application. 297 With respect to packet loss, if one peer has sent a handshake message 298 and has not yet received its expected response, it will retransmit 299 the handshake message after a configurable timeout. 301 To account for long records that cannot fit within a single UDP 302 datagram, DTLS supports fragmentation of records across datagrams, 303 keeping track of fragment offsets and lengths in each datagram. The 304 receiving peer must re-assemble records before decrypting. 306 DTLS relies on UDP's port numbers to allow peers with multiple DTLS 307 sessions between them to demultiplex 'streams' of encrypted packets 308 that share a single TLS session. 310 Since datagrams may be replayed, DTLS provides anti-replay detection 311 based on a window of acceptable sequence numbers [RFC4303]. 313 3.2.2. Protocol Features 315 o Anti-replay protection between datagrams. 317 o Basic reliability for handshake messages. 319 o See also the features from TLS. 321 3.2.3. Protocol Dependencies 323 o Since DTLS runs over an unreliable, unordered datagram transport, 324 it does not require any reliability features. 326 o DTLS contains its own length, so although it runs over a datagram 327 transport, it does not rely on the transport protocol supporting 328 framing. 330 o UDP for port numbers used for demultiplexing. 332 o Path MTU discovery. 334 3.3. QUIC with TLS 336 QUIC (Quick UDP Internet Connections) is a new transport protocol 337 that runs over UDP, and was originally designed with a tight 338 integration with its security protocol and application protocol 339 mappings. The QUIC transport layer itself provides support for data 340 confidentiality and integrity. This requires keys to be derived with 341 a separate handshake protocol. A mapping for QUIC over TLS 1.3 342 [I-D.ietf-quic-tls] has been specified to provide this handshake. 344 3.3.1. Protocol Description 346 Since QUIC integrates TLS with its transport, it relies on specific 347 integration points between its security and transport sides. 348 Specifically, these points are: 350 o Starting the handshake to generate keys and provide authentication 351 (and providing the transport for the handshake). 353 o Client address validation. 355 o Key ready events from TLS to notify the QUIC transport. 357 o Exporting secrets from TLS to the QUIC transport. 359 The QUIC transport layer support multiple streams over a single 360 connection. The first stream is reserved specifically for a TLS 361 connection. The TLS handshake, along with further records, are sent 362 over this stream. This TLS connection follows the TLS standards and 363 inherits the security properties of TLS. The handshake generates 364 keys, which are then exported to the rest of the QUIC connection, and 365 are used to protect the rest of the streams. 367 The initial QUIC messages are sent without encryption in order to 368 start the TLS handshake. Once the handshake has generated keys, the 369 subsequent messages are encrypted. The TLS 1.3 handshake for QUIC is 370 used in either a single-RTT mode or a fast-open zero-RTT mode. When 371 zero-RTT handshakes are possible, the encryption first transitions to 372 use the zero-RTT keys before using single-RTT handshake keys after 373 the next TLS flight. 375 3.3.2. Protocol Features 377 o Handshake properties of TLS. 379 o Multiple encrypted streams over a single connection without head- 380 of-line blocking. 382 o Packet payload encryption and complete packet authentication (with 383 the exception of the Public Reset packet, which is not 384 authenticated). 386 3.3.3. Protocol Dependencies 388 o QUIC transport relies on UDP. 390 o QUIC transport relies on TLS 1.3 for authentication and initial 391 key derivation. 393 o TLS within QUIC relies on a reliable stream abstraction for its 394 handshake. 396 3.4. MinimalT 398 MinimalT is a UDP-based transport security protocol designed to offer 399 confidentiality, mutual authentication, DoS prevention, and 400 connection mobility [MinimalT]. One major goal of the protocol is to 401 leverage existing protocols to obtain server-side configuration 402 information used to more quickly bootstrap a connection. MinimalT 403 uses a variant of TCP's congestion control algorithm. 405 3.4.1. Protocol Description 407 MinimalT is a secure transport protocol built on top of a widespread 408 directory service. Clients and servers interact with local directory 409 services to (a) resolve server information and (b) public ephemeral 410 state information, respectively. Clients connect to a local resolver 411 once at boot time. Through this resolver they recover the IP 412 address(es) and public key(s) of each server to which they want to 413 connect. 415 Connections are instances of user-authenticated, mobile sessions 416 between two endpoints. Connections run within tunnels between hosts. 417 A tunnel is a server-authenticated container that multiplexes 418 multiple connections between the same hosts. All connections in a 419 tunnel share the same transport state machine and encryption. Each 420 tunnel has a dedicated control connection used to configure and 421 manage the tunnel over time. Moreover, since tunnels are independent 422 of the network address information, they may be reused as both ends 423 of the tunnel move about the network. This does however imply that 424 the connection establishment and packet encryption mechanisms are 425 coupled. 427 Before a client connects to a remote service, it must first establish 428 a tunnel to the host providing or offering the service. Tunnels are 429 established in 1-RTT using an ephemeral key obtained from the 430 directory service. Tunnel initiators provide their own ephemeral key 431 and, optionally, a DoS puzzle solution such that the recipient 432 (server) can verify the authenticity of the request and derive a 433 shared secret. Within a tunnel, new connections to services may be 434 established. 436 3.4.2. Protocol Features 438 o 0-RTT forward secrecy for new connections. 440 o DoS prevention by client-side puzzles. 442 o Tunnel-based mobility. 444 o (Transport Feature) Connection multiplexing between hosts across 445 shared tunnels. 447 o (Transport Feature) Congestion control state is shared across 448 connections between the same host pairs. 450 3.4.3. Protocol Dependencies 452 o A DNS-like resolution service to obtain location information (an 453 IP address) and ephemeral keys. 455 o A PKI trust store for certificate validation. 457 3.5. CurveCP 459 CurveCP [CurveCP] is a UDP-based transport security protocol from 460 Daniel J. Bernstein. Unlike other transport security protocols, it 461 is based entirely upon highly efficient public key algorithms. This 462 removes many pitfalls associated with nonce reuse and key 463 synchronization. 465 3.5.1. Protocol Description 467 CurveCP is a UDP-based transport security protocol. It is built on 468 three principal features: exclusive use of public key authenticated 469 encryption of packets, server-chosen cookies to prohibit memory and 470 computation DoS at the server, and connection mobility with a client- 471 chosen ephemeral identifier. 473 There are two rounds in CurveCP. In the first round, the client 474 sends its first initialization packet to the server, carrying its 475 (possibly fresh) ephemeral public key C', with zero-padding encrypted 476 under the server's long-term public key. The server replies with a 477 cookie and its own ephemeral key S' and a cookie that is to be used 478 by the client. Upon receipt, the client then generates its second 479 initialization packet carrying: the ephemeral key C', cookie, and an 480 encryption of C', the server's domain name, and, optionally, some 481 message data. The server verifies the cookie and the encrypted 482 payload and, if valid, proceeds to send data in return. At this 483 point, the connection is established and the two parties can 484 communicate. 486 The use of only public-key encryption and authentication, or 487 "boxing", is done to simplify problems that come with symmetric key 488 management and synchronization. For example, it allows the sender of 489 a message to be in complete control of each message's nonce. It does 490 not require either end to share secret keying material. And it 491 allows ephemeral public keys to be associated with connections (or 492 sessions). 494 The client and server do not perform a standard key exchange. 495 Instead, in the initial exchange of packets, the each party provides 496 its own ephemeral key to the other end. The client can choose a new 497 ephemeral key for every new connection. However, the server must 498 rotate these keys on a slower basis. Otherwise, it would be trivial 499 for an attacker to force the server to create and store ephemeral 500 keys with a fake client initialization packet. 502 Unlike TCP, the server employs cookies to enable source validation. 503 After receiving the client's initial packet, encrypted under the 504 server's long-term public key, the server generates and returns a 505 stateless cookie that must be echoed back in the client's following 506 message. This cookie is encrypted under the client's ephemeral 507 public key. This stateless technique prevents attackers from 508 hijacking client initialization packets to obtain cookie values to 509 flood clients. (A client would detect the duplicate cookies and 510 reject the flooded packets.) Similarly, replaying the client's 511 second packet, carrying the cookie, will be detected by the server. 513 CurveCP supports a weak form of client authentication. Clients are 514 permitted to send their long-term public keys in the second 515 initialization packet. A server can verify this public key and, if 516 untrusted, drop the connection and subsequent data. 518 Unlike some other protocols, CurveCP data packets only leave the 519 ephemeral public key, i.e., the connection ID, and the per-message 520 nonce in the clear. Everything else is encrypted. 522 3.5.2. Protocol Features 524 o Forward-secure data encryption and authentication. 526 o Per-packet public-key encryption. 528 o 1-RTT session bootstrapping. 530 o Connection mobility based on a client-chosen ephemeral identifier. 532 o Connection establishment message padding to prevent traffic 533 amplification. 535 o Sender-chosen explicit nonces, e.g., based on a sequence number. 537 3.5.3. Protocol Dependencies 539 o An unreliable transport protocol such as UDP. 541 3.6. tcpcrypt 543 tcpcrypt is a lightweight extension to the TCP protocol to enable 544 opportunistic encryption. 546 3.6.1. Protocol Description 548 tcpcrypt extends TCP to enable opportunistic encryption between the 549 two ends of a TCP connection [I-D.ietf-tcpinc-tcpcrypt]. It is a 550 type of TCP Encryption Protocol (TEP). The use of a TEP is 551 negotiated using TCP headers during the initial TCP handshake. 552 Negotiating a TEP also involves agreeing upon a key exchange 553 algorithm. If and when a TEP is negotiated, the tcpcrypt key 554 exchange occurs within the data segments of the first packets 555 exchanged after the handshake completes. The initiator of a 556 connection sends a list of support AEAD algorithms, a random nonce, 557 and an ephemeral public key share. The responder chooses an AEAD 558 algorithm and replies with its own nonce and ephemeral key share. 559 The traffic encryption keys are derived from the key exchange. 561 Each tcpcrypt session is associated with a unique session ID; the 562 value of which is derived from the current shared secret used for the 563 session. This can be cached and used to later resume a session. 564 Willingness to resume a session is signaled within the TCP-ENO 565 negotiation option during the TCP handshake [I-D.ietf-tcpinc-tcpeno]. 566 Session identifiers are rotated each time they are resumed. Sessions 567 may also be re-keyed if the natural AEAD limit is reached. 569 tcpcrypt only encrypts the data portion of a TCP packet. It does not 570 encrypt any header information, such as the TCP sequence number. 572 3.6.2. Protocol Features 574 o Forward-secure TCP packet encryption. 576 o Session caching and address-agnostic resumption. 578 o Session re-keying. 580 3.6.3. Protocol Dependencies 582 o TCP (with option support). 584 3.7. IKEv2 with ESP 586 IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec 587 protocol suite that encrypts and authenticates IP packets, either as 588 for creating tunnels (tunnel-mode) or for direct transport 589 connections (transport-mode). This suite of protocols separates out 590 the key generation protocol (IKEv2) from the transport encryption 591 protocol (ESP). Each protocol can be used independently, but this 592 document considers them together, since that is the most common 593 pattern. 595 3.7.1. Protocol descriptions 597 3.7.1.1. IKEv2 599 IKEv2 is a control protocol that runs on UDP port 500. Its primary 600 goal is to generate keys for Security Associations (SAs). It first 601 uses a Diffie-Hellman key exchange to generate keys for the "IKE SA", 602 which is a set of keys used to encrypt further IKEv2 messages. It 603 then goes through a phase of authentication in which both peers 604 present blobs signed by a shared secret or private key, after which 605 another set of keys is derived, referred to as the "Child SA". These 606 Child SA keys are used by ESP. 608 IKEv2 negotiates which protocols are acceptable to each peer for both 609 the IKE and Child SAs using "Proposals". Each proposal may contain 610 an encryption algorithm, an authentication algorithm, a Diffie- 611 Hellman group, and (for IKE SAs only) a pseudorandom function 612 algorithm. Each peer may support multiple proposals, and the most 613 preferred mutually supported proposal is chosen during the handshake. 615 The authentication phase of IKEv2 may use Shared Secrets, 616 Certificates, Digital Signatures, or an EAP (Extensible 617 Authentication Protocol) method. At a minimum, IKEv2 takes two round 618 trips to set up both an IKE SA and a Child SA. If EAP is used, this 619 exchange may be expanded. 621 Any SA used by IKEv2 can be rekeyed upon expiration, which is usually 622 based either on time or number of bytes encrypted. 624 There is an extension to IKEv2 that allows session resumption 625 [RFC5723]. 627 MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a 628 set of Security Associations to migrate over different addresses and 629 interfaces [RFC4555]. 631 When UDP is not available or well-supported on a network, IKEv2 may 632 be encapsulated in TCP [I-D.ietf-ipsecme-tcp-encaps]. 634 3.7.1.2. ESP 636 ESP is a protocol that encrypts and authenticates IP and IPv6 637 packets. The keys used for both encryption and authentication can be 638 derived from an IKEv2 exchange. ESP Security Associations come as 639 pairs, one for each direction between two peers. Each SA is 640 identified by a Security Parameter Index (SPI), which is marked on 641 each encrypted ESP packet. 643 ESP packets include the SPI, a sequence number, an optional 644 Initialization Vector (IV), payload data, padding, a length and next 645 header field, and an Integrity Check Value. 647 From [RFC4303], "ESP is used to provide confidentiality, data origin 648 authentication, connectionless integrity, an anti-replay service (a 649 form of partial sequence integrity), and limited traffic flow 650 confidentiality." 652 Since ESP operates on IP packets, it is not directly tied to the 653 transport protocols it encrypts. This means it requires little or no 654 change from transports in order to provide security. 656 ESP packets are sent directly over IP, except when a NAT is present, 657 in which case they are sent on UDP port 4500, or via TCP 658 encapsulation [I-D.ietf-ipsecme-tcp-encaps]. 660 3.7.2. Protocol features 661 3.7.2.1. IKEv2 663 o Encryption and authentication of handshake packets. 665 o Cryptographic algorithm negotiation. 667 o Session resumption. 669 o Mobility across addresses and interfaces. 671 o Peer authentication extensibility based on Shared Secret, 672 Certificates, Digital Signatures, or EAP methods. 674 3.7.2.2. ESP 676 o Data confidentiality and authentication. 678 o Connectionless integrity. 680 o Anti-replay protection. 682 o Limited flow confidentiality. 684 3.7.3. Protocol dependencies 686 3.7.3.1. IKEv2 688 o Availability of UDP to negotiate, or implementation support for 689 TCP-encapsulation. 691 o Some EAP authentication types require accessing a hardware device, 692 such as a SIM card; or interacting with a user, such as password 693 prompting. 695 3.7.3.2. ESP 697 o Since ESP is below transport protocols, it does not have any 698 dependencies on the transports themselves, other than on UDP or 699 TCP for NAT traversal. 701 4. Common Transport Security Features 703 There exists a common set of features shared across the transport 704 protocols surveyed in this document. The mandatory features should 705 be provided by any transport security protocol, while the optional 706 features are extensions that a subset of the protocols provide. For 707 clarity, we also distinguish between handshake and record features. 709 4.1. Mandatory Features 711 4.1.1. Handshake 713 o Forward-secure segment encryption and authentication: Transit data 714 must be protected with an authenticated encryption algorithm. 716 o Private key interface or injection: Authentication based on public 717 key signatures is commonplace for many transport security 718 protocols. 720 o Endpoint authentication: The endpoint (receiver) of a new 721 connection must be authenticated before any data is sent to said 722 party. 724 o Source validation: Source validation must be provided to mitigate 725 server-targeted DoS attacks. This can be done with puzzles or 726 cookies. 728 4.1.2. Record 730 o Pre-shared key support: A record protocol must be able to use a 731 pre-shared key established out-of-band to encrypt individual 732 messages, packets, or datagrams. 734 4.2. Optional Features 736 4.2.1. Handshake 738 o Mutual authentication: Transport security protocols should allow 739 both endpoints to authenticate one another if needed. 741 o Application-layer feature negotiation: The type of application 742 using a transport security protocol often requires features 743 configured at the connection establishment layer, e.g., ALPN 744 [RFC7301]. Moreover, application-layer features may often be used 745 to offload the session to another server which can better handle 746 the request. (The TLS SNI is one example of such a feature.) As 747 such, transport security protocols should provide a generic 748 mechanism to allow for such application-specific features and 749 options to be configured or otherwise negotiated. 751 o Configuration extensions: The protocol negotiation should be 752 extensible with addition of new configuration options. 754 o Session caching and management: Sessions should be cacheable to 755 enable reuse and amortize the cost of performing session 756 establishment handshakes. 758 4.2.2. Record 760 o Connection mobility: Sessions should not be bound to a network 761 connection (or 5 tuple). This allows cryptographic key material 762 and other state information to be reused in the event of a 763 connection change. Examples of this include a NAT rebinding that 764 occurs without a client's knowledge. 766 5. Transport Security Protocol Interfaces 768 This section describes the interface surface exposed by the security 769 protocols described above, with each interface. Note that not all 770 protocols support each interface. 772 5.1. Configuration Interfaces 774 Configuration interfaces are used to configure the security protocols 775 before a handshake begins or the keys are negotiated. 777 o Identity and Private Keys 778 The application can provide its identities (certificates) and 779 private keys, or mechanisms to access these, to the security 780 protocol to use during handshakes. 781 Protocols: TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2 783 o Supported Algorithms (Key Exchange, Signatures and Ciphersuites) 784 The application can choose the algorithms that are supported for 785 key exchange, signatures, and ciphersuites. 786 Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2 788 o Session Cache 789 The application provides the ability to save and retrieve session 790 state (tickets, keying material, server parameters) that may be 791 used to resume the security session. 792 Protocols: TLS, DTLS, QUIC + TLS, MinimalT 794 o Authentication Delegate 795 The application provides access to a separate module that will 796 provide authentication, using EAP for example. 797 Protocols: IKEv2 799 5.2. Handshake Interfaces 801 Handshake interfaces are the points of interaction between a 802 handshake protocol and the application, record protocol, and 803 transport once the handshake is active. 805 o Send Handshake Messages 806 The handshake protocol needs to be able to send messages over a 807 transport to the remote peer to establish trust and negotiate 808 keys. 809 Protocols: All (TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2) 811 o Receive Handshake Messages 812 The handshake protocol needs to be able to receive messages from 813 the remote peer over a transport to establish trust and negotiate 814 keys. 815 Protocols: All (TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2) 817 o Identity Validation 818 During a handshake, the security protocol will conduct identity 819 validation of the peer. This can call into the application to 820 offload validation. 821 Protocols: All (TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2) 823 o Source Address Validation 824 The handshake protocol may delegate validation of the remote peer 825 that has sent data to the transport protocol or application. This 826 involves sending a cookie exchange to avoid DoS attacks. 827 Protocols: QUIC + TLS 829 o Key Update 830 The handshake protocol may be instructed to update its keying 831 material, either by the application directly or by the record 832 protocol sending a key expiration event. 833 Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2 835 o Pre-Shared Key Export 836 The handshake protocol will generate one or more keys to be used 837 for record encryption/decryption and authentication. These may be 838 explicitly exportable to the application, traditionally limited to 839 direct export to the record protocol, or inherently non-exportable 840 because the keys must be used directly in conjunction with the 841 record protocol. 843 * Explict export: TLS (for QUIC), tcpcrypt, IKEv2 845 * Direct export: TLS, DTLS, MinimalT 847 * Non-exportable: CurveCP 849 5.3. Record Interfaces 851 Record interfaces are the points of interaction between a record 852 protocol and the application, handshake protocol, and transport once 853 in use. 855 o Pre-Shared Key Import 856 Either the handshake protocol or the application directly can 857 supply pre-shared keys for the record protocol use for encryption/ 858 decryption and authentication. If the application can supply keys 859 directly, this is considered explicit import; if the handshake 860 protocol traditionally provides the keys directly, it is 861 considered direct import; if the keys can only be shared by the 862 handshake, they are considered non-importable. 864 * Explict import: QUIC, ESP 866 * Direct import: TLS, DTLS, MinimalT, tcpcrypt 868 * Non-importable: CurveCP 870 o Encrypt application data 871 The application can send data to the record protocol to encrypt it 872 into a format that can be sent on the underlying transport. The 873 encryption step may require that the application data is treated 874 as a stream or as datagrams, and that the transport to send the 875 encrypted records present a stream or datagram interface. 877 * Stream-to-Stream Protocols: TLS, tcpcrypt 879 * Datagram-to-Datagram Protocols: DTLS, ESP 881 * Stream-to-Datagram Protocols: QUIC ((Editor's Note: This 882 depends on the interface QUIC exposes to applications.)) 884 o Decrypt application data 885 The application can receive data from its transport to be 886 decrypted using record protocol. The decryption step may require 887 that the incoming transport data is presented as a stream or as 888 datagrams, and that the resulting application data is a stream or 889 datagrams. 891 * Stream-to-Stream Protocols: TLS, tcpcrypt 893 * Datagram-to-Datagram Protocols: DTLS, ESP 895 * Datagram-to-Stream Protocols: QUIC ((Editor's Note: This 896 depends on the interface QUIC exposes to applications.)) 898 o Key Expiration 899 The record protocol can signal that its keys are expiring due to 900 reaching a time-based deadline, or a use-based deadline (number of 901 bytes that have been encrypted with the key). This interaction is 902 often limited to signaling between the record layer and the 903 handshake layer. 904 Protocols: ESP ((Editor's note: One may consider TLS/DTLS to also 905 have this interface)) 907 o Transport mobility 908 The record protocol can be signaled that it is being migrated to 909 another transport or interface due to connection mobility, which 910 may reset address and state validation. 911 Protocols: QUIC, MinimalT, CurveCP, ESP 913 6. IANA Considerations 915 This document has on request to IANA. 917 7. Security Considerations 919 N/A 921 8. Acknowledgments 923 The authors would like to thank Mirja Kuehlewind, Brian Trammell, 924 Yannick Sierra, Frederic Jacobs, and Bob Bradley for their input and 925 feedback on earlier versions of this draft. 927 9. Normative References 929 [CurveCP] "CurveCP -- Usable security for the Internet", n.d.. 931 [I-D.ietf-ipsecme-tcp-encaps] 932 Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 933 of IKE and IPsec Packets", draft-ietf-ipsecme-tcp- 934 encaps-10 (work in progress), May 2017. 936 [I-D.ietf-quic-tls] 937 Thomson, M. and S. Turner, "Using Transport Layer Security 938 (TLS) to Secure QUIC", draft-ietf-quic-tls-04 (work in 939 progress), June 2017. 941 [I-D.ietf-quic-transport] 942 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 943 and Secure Transport", draft-ietf-quic-transport-04 (work 944 in progress), June 2017. 946 [I-D.ietf-tcpinc-tcpcrypt] 947 Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, 948 Q., and E. Smith, "Cryptographic protection of TCP Streams 949 (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-06 (work in 950 progress), March 2017. 952 [I-D.ietf-tcpinc-tcpeno] 953 Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. 954 Smith, "TCP-ENO: Encryption Negotiation Option", draft- 955 ietf-tcpinc-tcpeno-08 (work in progress), March 2017. 957 [I-D.ietf-tls-tls13] 958 Rescorla, E., "The Transport Layer Security (TLS) Protocol 959 Version 1.3", draft-ietf-tls-tls13-20 (work in progress), 960 April 2017. 962 [MinimalT] 963 "MinimaLT -- Minimal-latency Networking Through Better 964 Security", n.d.. 966 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 967 RFC 4303, DOI 10.17487/RFC4303, December 2005, 968 . 970 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 971 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 972 . 974 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 975 (TLS) Protocol Version 1.2", RFC 5246, 976 DOI 10.17487/RFC5246, August 2008, 977 . 979 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 980 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 981 DOI 10.17487/RFC5723, January 2010, 982 . 984 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 985 Extensions: Extension Definitions", RFC 6066, 986 DOI 10.17487/RFC6066, January 2011, 987 . 989 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 990 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 991 January 2012, . 993 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 994 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 995 Transport Layer Security (TLS) and Datagram Transport 996 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 997 June 2014, . 999 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1000 Kivinen, "Internet Key Exchange Protocol Version 2 1001 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1002 2014, . 1004 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1005 "Transport Layer Security (TLS) Application-Layer Protocol 1006 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1007 July 2014, . 1009 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 1010 Ed., "Services Provided by IETF Transport Protocols and 1011 Congestion Control Mechanisms", RFC 8095, 1012 DOI 10.17487/RFC8095, March 2017, 1013 . 1015 Authors' Addresses 1017 Tommy Pauly 1018 Apple Inc. 1019 1 Infinite Loop 1020 Cupertino, California 95014 1021 United States of America 1023 Email: tpauly@apple.com 1025 Christopher A. Wood 1026 Apple Inc. 1027 1 Infinite Loop 1028 Cupertino, California 95014 1029 United States of America 1031 Email: cawood@apple.com