--- 1/draft-ietf-taps-transport-security-00.txt 2018-05-11 12:13:32.481347932 -0700 +++ 2/draft-ietf-taps-transport-security-01.txt 2018-05-11 12:13:32.537349286 -0700 @@ -1,23 +1,23 @@ Network Working Group T. Pauly Internet-Draft Apple Inc. Intended status: Informational C. Perkins -Expires: September 24, 2018 University of Glasgow +Expires: November 12, 2018 University of Glasgow K. Rose Akamai Technologies, Inc. C. Wood Apple Inc. - March 23, 2018 + May 11, 2018 A Survey of Transport Security Protocols - draft-ietf-taps-transport-security-00 + draft-ietf-taps-transport-security-01 Abstract This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog transport services [RFC8095] by describing the interfaces required to add security protocols. It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + @@ -34,21 +34,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 24, 2018. + This Internet-Draft will expire on November 12, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -68,58 +68,56 @@ 3.1.2. Protocol Features . . . . . . . . . . . . . . . . . . 7 3.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 7 3.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Protocol Description . . . . . . . . . . . . . . . . 7 3.2.2. Protocol Features . . . . . . . . . . . . . . . . . . 8 3.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 8 3.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 9 3.3.1. Protocol Description . . . . . . . . . . . . . . . . 9 3.3.2. Protocol Features . . . . . . . . . . . . . . . . . . 9 3.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10 - 3.4. gQUIC . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.4.1. Protocol Description . . . . . . . . . . . . . . . . 10 - 3.4.2. Protocol Dependencies . . . . . . . . . . . . . . . . 10 - 3.5. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.5.1. Protocol Description . . . . . . . . . . . . . . . . 10 - 3.5.2. Protocol Features . . . . . . . . . . . . . . . . . . 11 - 3.5.3. Protocol Dependencies . . . . . . . . . . . . . . . . 11 - 3.6. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 3.6.1. Protocol Description . . . . . . . . . . . . . . . . 12 - 3.6.2. Protocol Features . . . . . . . . . . . . . . . . . . 13 - 3.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 13 - 3.7. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 13 - 3.7.1. Protocol Description . . . . . . . . . . . . . . . . 13 - 3.7.2. Protocol Features . . . . . . . . . . . . . . . . . . 14 - 3.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 15 - 3.8. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 15 - 3.8.1. Protocol descriptions . . . . . . . . . . . . . . . . 15 - 3.8.2. Protocol features . . . . . . . . . . . . . . . . . . 16 + 3.3.4. Differences from Google QUIC . . . . . . . . . . . . 10 + 3.3.5. Protocol Description . . . . . . . . . . . . . . . . 10 + 3.3.6. Protocol Dependencies . . . . . . . . . . . . . . . . 10 + 3.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 10 + 3.4.1. Protocol descriptions . . . . . . . . . . . . . . . . 10 + 3.4.2. Protocol features . . . . . . . . . . . . . . . . . . 12 + 3.4.3. Protocol dependencies . . . . . . . . . . . . . . . . 12 + 3.5. SRTP (with DTLS) . . . . . . . . . . . . . . . . . . . . 13 + 3.5.1. Protocol descriptions . . . . . . . . . . . . . . . . 13 + 3.5.2. Protocol features . . . . . . . . . . . . . . . . . . 14 + 3.5.3. Protocol dependencies . . . . . . . . . . . . . . . . 14 + 3.6. Differences from ZRTP . . . . . . . . . . . . . . . . . . 15 + 3.7. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 15 + 3.7.1. Protocol Description . . . . . . . . . . . . . . . . 15 + 3.7.2. Protocol Features . . . . . . . . . . . . . . . . . . 16 + 3.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 16 + + 3.8. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 16 + 3.8.1. Protocol description . . . . . . . . . . . . . . . . 16 + 3.8.2. Protocol features . . . . . . . . . . . . . . . . . . 17 3.8.3. Protocol dependencies . . . . . . . . . . . . . . . . 17 - 3.9. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 17 - 3.9.1. Protocol description . . . . . . . . . . . . . . . . 17 - 3.9.2. Protocol features . . . . . . . . . . . . . . . . . . 18 - 3.9.3. Protocol dependencies . . . . . . . . . . . . . . . . 18 - 3.10. SRTP (with DTLS) . . . . . . . . . . . . . . . . . . . . 18 - 3.10.1. Protocol descriptions . . . . . . . . . . . . . . . 19 - 3.10.2. Protocol features . . . . . . . . . . . . . . . . . 20 - 3.10.3. Protocol dependencies . . . . . . . . . . . . . . . 20 - 4. Common Transport Security Features . . . . . . . . . . . . . 20 - 4.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 20 - 4.1.1. Handshake . . . . . . . . . . . . . . . . . . . . . . 20 - 4.1.2. Record . . . . . . . . . . . . . . . . . . . . . . . 21 + 3.9. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 17 + 3.9.1. Protocol Description . . . . . . . . . . . . . . . . 18 + 3.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 18 + 3.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 19 + 3.10. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 3.10.1. Protocol Description . . . . . . . . . . . . . . . . 19 + 3.10.2. Protocol Features . . . . . . . . . . . . . . . . . 20 + 3.10.3. Protocol Dependencies . . . . . . . . . . . . . . . 20 + 4. Security Features and Transport Dependencies . . . . . . . . 21 + 4.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 21 4.2. Optional Features . . . . . . . . . . . . . . . . . . . . 21 - 4.2.1. Handshake . . . . . . . . . . . . . . . . . . . . . . 21 - 4.2.2. Record . . . . . . . . . . . . . . . . . . . . . . . 21 - 5. Transport Security Protocol Interfaces . . . . . . . . . . . 21 - 5.1. Configuration Interfaces . . . . . . . . . . . . . . . . 22 - 5.2. Handshake Interfaces . . . . . . . . . . . . . . . . . . 22 - 5.3. Record Interfaces . . . . . . . . . . . . . . . . . . . . 23 + 5. Transport Security Protocol Interfaces . . . . . . . . . . . 23 + 5.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 23 + 5.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 24 + 5.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 9. Normative References . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate @@ -373,21 +371,21 @@ o UDP 4-tuple uniqueness, or the connection identifier extension, for demultiplexing. o Path MTU discovery. 3.3. (IETF) QUIC with TLS QUIC (Quick UDP Internet Connections) is a new standards-track transport protocol that runs over UDP, loosely based on Google's - original proprietary gQUIC protocol. (See Section 3.4 for more + original proprietary gQUIC protocol. (See Section 3.3.4 for more details.) The QUIC transport layer itself provides support for data confidentiality and integrity. This requires keys to be derived with a separate handshake protocol. A mapping for QUIC over TLS 1.3 [I-D.ietf-quic-tls] has been specified to provide this handshake. 3.3.1. Protocol Description As QUIC relies on TLS to secure its transport functions, it creates specific integration points between its security and transport functions: @@ -432,262 +430,51 @@ 3.3.3. Protocol Dependencies o QUIC transport relies on UDP. o QUIC transport relies on TLS 1.3 for authentication and initial key derivation. o TLS within QUIC relies on a reliable stream abstraction for its handshake. -3.4. gQUIC +3.3.4. Differences from Google QUIC - gQUIC is a UDP-based multiplexed streaming protocol designed and - deployed by Google following experience from deploying SPDY, the - proprietary predecessor to HTTP/2. gQUIC was originally known as - "QUIC": this document uses gQUIC to unambiguously distinguish it from - the standards-track IETF QUIC. The proprietary technical forebear of - IETF QUIC, gQUIC was originally designed with tightly-integrated - security and application data transport protocols. + Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol + designed and deployed by Google following experience from deploying + SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally + known as "QUIC": this document uses gQUIC to unambiguously + distinguish it from the standards-track IETF QUIC. The proprietary + technical forebear of IETF QUIC, gQUIC was originally designed with + tightly-integrated security and application data transport protocols. -3.4.1. Protocol Description +3.3.5. Protocol Description ((TODO: write me)) -3.4.2. Protocol Dependencies +3.3.6. Protocol Dependencies ((TODO: write me)) -3.5. MinimalT - - MinimalT is a UDP-based transport security protocol designed to offer - confidentiality, mutual authentication, DoS prevention, and - connection mobility [MinimalT]. One major goal of the protocol is to - leverage existing protocols to obtain server-side configuration - information used to more quickly bootstrap a connection. MinimalT - uses a variant of TCP's congestion control algorithm. - -3.5.1. Protocol Description - - MinimalT is a secure transport protocol built on top of a widespread - directory service. Clients and servers interact with local directory - services to (a) resolve server information and (b) public ephemeral - state information, respectively. Clients connect to a local resolver - once at boot time. Through this resolver they recover the IP - address(es) and public key(s) of each server to which they want to - connect. - - Connections are instances of user-authenticated, mobile sessions - between two endpoints. Connections run within tunnels between hosts. - A tunnel is a server-authenticated container that multiplexes - multiple connections between the same hosts. All connections in a - tunnel share the same transport state machine and encryption. Each - tunnel has a dedicated control connection used to configure and - manage the tunnel over time. Moreover, since tunnels are independent - of the network address information, they may be reused as both ends - of the tunnel move about the network. This does however imply that - the connection establishment and packet encryption mechanisms are - coupled. - - Before a client connects to a remote service, it must first establish - a tunnel to the host providing or offering the service. Tunnels are - established in 1-RTT using an ephemeral key obtained from the - directory service. Tunnel initiators provide their own ephemeral key - and, optionally, a DoS puzzle solution such that the recipient - (server) can verify the authenticity of the request and derive a - shared secret. Within a tunnel, new connections to services may be - established. - -3.5.2. Protocol Features - - o 0-RTT forward secrecy for new connections. - - o DoS prevention by client-side puzzles. - - o Tunnel-based mobility. - - o (Transport Feature) Connection multiplexing between hosts across - shared tunnels. - - o (Transport Feature) Congestion control state is shared across - connections between the same host pairs. - -3.5.3. Protocol Dependencies - - o A DNS-like resolution service to obtain location information (an - IP address) and ephemeral keys. - - o A PKI trust store for certificate validation. - -3.6. CurveCP - - CurveCP [CurveCP] is a UDP-based transport security protocol from - Daniel J. Bernstein. Unlike other transport security protocols, it - is based entirely upon highly efficient public key algorithms. This - removes many pitfalls associated with nonce reuse and key - synchronization. - -3.6.1. Protocol Description - - CurveCP is a UDP-based transport security protocol. It is built on - three principal features: exclusive use of public key authenticated - encryption of packets, server-chosen cookies to prohibit memory and - computation DoS at the server, and connection mobility with a client- - chosen ephemeral identifier. - - There are two rounds in CurveCP. In the first round, the client - sends its first initialization packet to the server, carrying its - (possibly fresh) ephemeral public key C', with zero-padding encrypted - under the server's long-term public key. The server replies with a - cookie and its own ephemeral key S' and a cookie that is to be used - by the client. Upon receipt, the client then generates its second - initialization packet carrying: the ephemeral key C', cookie, and an - encryption of C', the server's domain name, and, optionally, some - message data. The server verifies the cookie and the encrypted - payload and, if valid, proceeds to send data in return. At this - point, the connection is established and the two parties can - communicate. - - The use of only public-key encryption and authentication, or - "boxing", is done to simplify problems that come with symmetric key - management and synchronization. For example, it allows the sender of - a message to be in complete control of each message's nonce. It does - not require either end to share secret keying material. Furthermore, - it allows connections (or sessions) to be associated with unique - ephemeral public keys as a mechanism for enabling forward secrecy - given the risk of long-term private key compromise. - - The client and server do not perform a standard key exchange. - Instead, in the initial exchange of packets, each party provides its - own ephemeral key to the other end. The client can choose a new - ephemeral key for every new connection. However, the server must - rotate these keys on a slower basis. Otherwise, it would be trivial - for an attacker to force the server to create and store ephemeral - keys with a fake client initialization packet. - - Unlike TCP, the server employs cookies to enable source validation. - After receiving the client's initial packet, encrypted under the - server's long-term public key, the server generates and returns a - stateless cookie that must be echoed back in the client's following - message. This cookie is encrypted under the client's ephemeral - public key. This stateless technique prevents attackers from - hijacking client initialization packets to obtain cookie values to - flood clients. (A client would detect the duplicate cookies and - reject the flooded packets.) Similarly, replaying the client's - second packet, carrying the cookie, will be detected by the server. - - CurveCP supports a weak form of client authentication. Clients are - permitted to send their long-term public keys in the second - initialization packet. A server can verify this public key and, if - untrusted, drop the connection and subsequent data. - - Unlike some other protocols, CurveCP data packets leave only the - ephemeral public key, the connection ID, and the per-message nonce in - the clear. Everything else is encrypted. - -3.6.2. Protocol Features - - o Forward-secure data encryption and authentication. - - o Per-packet public-key encryption. - - o 1-RTT session bootstrapping. - - o Connection mobility based on a client-chosen ephemeral identifier. - - o Connection establishment message padding to prevent traffic - amplification. - - o Sender-chosen explicit nonces, e.g., based on a sequence number. - -3.6.3. Protocol Dependencies - - o An unreliable transport protocol such as UDP. - -3.7. tcpcrypt - - Tcpcrypt is a lightweight extension to the TCP protocol to enable - opportunistic encryption with hooks available to the application - layer for implementation of endpoint authentication. - -3.7.1. Protocol Description - - Tcpcrypt extends TCP to enable opportunistic encryption between the - two ends of a TCP connection [I-D.ietf-tcpinc-tcpcrypt]. It is a - family of TCP encryption protocols (TEP), distinguished by key - exchange algorithm. The use of a TEP is negotiated with a TCP option - during the initial TCP handshake via the mechanism described by TCP - Encryption Negotiation Option (ENO) [I-D.ietf-tcpinc-tcpeno]. In the - case of initial session establishment, once a tcpcrypt TEP has been - negotiated the key exchange occurs within the data segments of the - first few packets exchanged after the handshake completes. The - initiator of a connection sends a list of supported AEAD algorithms, - a random nonce, and an ephemeral public key share. The responder - typically chooses a mutually-supported AEAD algorithm and replies - with this choice, its own nonce, and ephemeral key share. An initial - shared secret is derived from the ENO handshake, the tcpcrypt - handshake, and the initial keying material resulting from the key - exchange. The traffic encryption keys on the initial connection are - derived from the shared secret. Connections can be re-keyed before - the natural AEAD limit for a single set of traffic encryption keys is - reached. - - Each tcpcrypt session is associated with a ladder of resumption IDs, - each derived from the respective entry in a ladder of shared secrets. - These resumption IDs can be used to negotiate a stateful resumption - of the session in a subsequent connection, resulting in use of a new - shared secret and traffic encryption keys without requiring a new key - exchange. Willingness to resume a session is signaled via the ENO - option during the TCP handshake. Given the length constraints - imposed by TCP options, unlike stateless resumption mechanisms (such - as that provided by session tickets in TLS) resumption in tcpcrypt - requires the maintenance of state on the server, and so successful - resumption across a pool of servers implies shared state. - - Owing to middlebox ossification issues, tcpcrypt only protects the - payload portion of a TCP packet. It does not encrypt any header - information, such as the TCP sequence number. - - Tcpcrypt exposes a universally-unique connection-specific session ID - to the application, suitable for application-level endpoint - authentication either in-band or out-of-band. - -3.7.2. Protocol Features - - o Forward-secure TCP payload encryption and integrity protection. - - o Session caching and address-agnostic resumption. - - o Connection re-keying. - - o Application-level authentication primitive. - -3.7.3. Protocol Dependencies - - o TCP - - o TCP Encryption Negotiation Option (ENO) - -3.8. IKEv2 with ESP +3.4. IKEv2 with ESP IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec protocol suite that encrypts and authenticates IP packets, either as for creating tunnels (tunnel-mode) or for direct transport connections (transport-mode). This suite of protocols separates out the key generation protocol (IKEv2) from the transport encryption protocol (ESP). Each protocol can be used independently, but this document considers them together, since that is the most common pattern. -3.8.1. Protocol descriptions - -3.8.1.1. IKEv2 +3.4.1. Protocol descriptions +3.4.1.1. IKEv2 IKEv2 is a control protocol that runs on UDP port 500. Its primary goal is to generate keys for Security Associations (SAs). It first uses a Diffie-Hellman key exchange to generate keys for the "IKE SA", which is a set of keys used to encrypt further IKEv2 messages. It then goes through a phase of authentication in which both peers present blobs signed by a shared secret or private key, after which another set of keys is derived, referred to as the "Child SA". These Child SA keys are used by ESP. @@ -710,21 +497,21 @@ There is an extension to IKEv2 that allows session resumption [RFC5723]. MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a set of Security Associations to migrate over different addresses and interfaces [RFC4555]. When UDP is not available or well-supported on a network, IKEv2 may be encapsulated in TCP [RFC8229]. -3.8.1.2. ESP +3.4.1.2. ESP ESP is a protocol that encrypts and authenticates IPv4 and IPv6 packets. The keys used for both encryption and authentication can be derived from an IKEv2 exchange. ESP Security Associations come as pairs, one for each direction between two peers. Each SA is identified by a Security Parameter Index (SPI), which is marked on each encrypted ESP packet. ESP packets include the SPI, a sequence number, an optional Initialization Vector (IV), payload data, padding, a length and next @@ -737,73 +524,218 @@ Since ESP operates on IP packets, it is not directly tied to the transport protocols it encrypts. This means it requires little or no change from transports in order to provide security. ESP packets may be sent directly over IP, but where network conditions warrant (e.g., when a NAT is present or when a firewall blocks such packets) they may be encapsulated in UDP [RFC3948] or TCP [RFC8229]. -3.8.2. Protocol features +3.4.2. Protocol features -3.8.2.1. IKEv2 +3.4.2.1. IKEv2 o Encryption and authentication of handshake packets. o Cryptographic algorithm negotiation. o Session resumption. o Mobility across addresses and interfaces. o Peer authentication extensibility based on shared secret, certificates, digital signatures, or EAP methods. -3.8.2.2. ESP +3.4.2.2. ESP o Data confidentiality and authentication. o Connectionless integrity. o Anti-replay protection. o Limited flow confidentiality. -3.8.3. Protocol dependencies - -3.8.3.1. IKEv2 +3.4.3. Protocol dependencies +3.4.3.1. IKEv2 o Availability of UDP to negotiate, or implementation support for TCP-encapsulation. o Some EAP authentication types require accessing a hardware device, such as a SIM card; or interacting with a user, such as password prompting. -3.8.3.2. ESP +3.4.3.2. ESP o Since ESP is below transport protocols, it does not have any dependencies on the transports themselves, other than on UDP or TCP where encapsulation is employed. -3.9. WireGuard +3.5. SRTP (with DTLS) + + SRTP - Secure RTP - is a profile for RTP that provides + confidentiality, message authentication, and replay protection for + data and control packets [RFC3711]. SRTP packets are encrypted using + a session key, which is derived from a separate master key. Master + keys are derived and managed externally, e.g., via DTLS, as specified + in RFC 5763 [RFC5763], under the control of a signaling protocol such + as SIP [RFC3261] or WebRTC [I-D.ietf-rtcweb-security-arch]. + +3.5.1. Protocol descriptions + + SRTP adds confidentiality and optional integrity protection to RTP + data packets, and adds confidentially and mandatory integrity + protection to RTP control (RTCP) packets. For RTP data packets, this + is done by encrypting the payload section of the packet and + optionally appending an authentication tag (MAC) as a packet trailer, + with the RTP header authenticated but not encrypted. The RTP header + itself is left unencrypted to enable RTP header compression + [RFC2508][RFC3545]. For RTCP packets, the first packet in the + compound RTCP packet is partially encrypted, leaving the first eight + octets of the header as cleartext to allow identification of the + packet as RTCP, while the remainder of the compound packet is fully + encrypted. The entire RTCP packet is then authenticated by appending + a MAC as packet trailer. + + Packets are encrypted using session keys, which are ultimately + derived from a master key and some additional master salt and session + salt. SRTP packets carry a 2-byte sequence number to partially + identify the unique packet index. SRTP peers maintain a separate + rollover counter (ROC) for RTP data packets that is incremented + whenever the sequence number wraps. The sequence number and ROC + together determine the packet index. RTCP packets have a similar, + yet differently named, field called the RTCP index which serves the + same purpose. + + Numerous encryption modes are supported. For popular modes of + operation, e.g., AES-CTR, the (unique) initialization vector (IV) + used for each encryption mode is a function of the RTP SSRC + (synchronization source), packet index, and session "salting key". + + SRTP offers replay detection by keeping a replay list of already seen + and processed packet indices. If a packet arrives with an index that + matches one in the replay list, it is silently discarded. + + DTLS [RFC5764] is commonly used as a way to perform mutual + authentication and key agreement for SRTP [RFC5763]. (Here, + certificates marshal public keys between endpoints. Thus, self- + signed certificates may be used if peers do not mutually trust one + another, as is common on the Internet.) When DTLS is used, + certificate fingerprints are transmitted out-of-band using SIP. + Peers typically verify that DTLS-offered certificates match that + which are offered over SIP. This prevents active attacks on RTP, but + not on the signaling (SIP or WebRTC) channel. + +3.5.2. Protocol features + + o Optional replay protection with tunable replay windows. + + o Out-of-order packet receipt. + + o (RFC5763) Mandatory mutually authenticated key exchange. + + o Partial encryption, protecting media payloads and control packets + but not data packet headers. + + o Optional authentication of data packets; mandatory authentication + of control packets. + +3.5.3. Protocol dependencies + + o External key derivation and management mechanism or protocol, + e.g., DTLS [RFC5763]. + + o External signaling protocol to manage RTP parameters and locate + and identify peers, e.g., SIP [RFC3261] or WebRTC + [I-D.ietf-rtcweb-security-arch]. + +3.6. Differences from ZRTP + + ((TODO: write me)) + +3.7. tcpcrypt + + Tcpcrypt is a lightweight extension to the TCP protocol to enable + opportunistic encryption with hooks available to the application + layer for implementation of endpoint authentication. + +3.7.1. Protocol Description + + Tcpcrypt extends TCP to enable opportunistic encryption between the + two ends of a TCP connection [I-D.ietf-tcpinc-tcpcrypt]. It is a + family of TCP encryption protocols (TEP), distinguished by key + exchange algorithm. The use of a TEP is negotiated with a TCP option + during the initial TCP handshake via the mechanism described by TCP + Encryption Negotiation Option (ENO) [I-D.ietf-tcpinc-tcpeno]. In the + case of initial session establishment, once a tcpcrypt TEP has been + negotiated the key exchange occurs within the data segments of the + first few packets exchanged after the handshake completes. The + initiator of a connection sends a list of supported AEAD algorithms, + a random nonce, and an ephemeral public key share. The responder + typically chooses a mutually-supported AEAD algorithm and replies + with this choice, its own nonce, and ephemeral key share. An initial + shared secret is derived from the ENO handshake, the tcpcrypt + handshake, and the initial keying material resulting from the key + exchange. The traffic encryption keys on the initial connection are + derived from the shared secret. Connections can be re-keyed before + the natural AEAD limit for a single set of traffic encryption keys is + reached. + + Each tcpcrypt session is associated with a ladder of resumption IDs, + each derived from the respective entry in a ladder of shared secrets. + These resumption IDs can be used to negotiate a stateful resumption + of the session in a subsequent connection, resulting in use of a new + shared secret and traffic encryption keys without requiring a new key + exchange. Willingness to resume a session is signaled via the ENO + option during the TCP handshake. Given the length constraints + imposed by TCP options, unlike stateless resumption mechanisms (such + as that provided by session tickets in TLS) resumption in tcpcrypt + requires the maintenance of state on the server, and so successful + resumption across a pool of servers implies shared state. + + Owing to middlebox ossification issues, tcpcrypt only protects the + payload portion of a TCP packet. It does not encrypt any header + information, such as the TCP sequence number. + + Tcpcrypt exposes a universally-unique connection-specific session ID + to the application, suitable for application-level endpoint + authentication either in-band or out-of-band. + +3.7.2. Protocol Features + + o Forward-secure TCP payload encryption and integrity protection. + + o Session caching and address-agnostic resumption. + + o Connection re-keying. + + o Application-level authentication primitive. + +3.7.3. Protocol Dependencies + + o TCP + + o TCP Encryption Negotiation Option (ENO) + +3.8. WireGuard WireGuard is a layer 3 protocol designed to complement or replace IPsec [WireGuard]. Unlike most transport security protocols, which rely on PKI for peer authentication, WireGuard authenticates peers using pre-shared public keys delivered out-of-band, each of which is bound to one or more IP addresses. Moreover, as a protocol suited for VPNs, WireGuard offers no extensibility, negotiation, or cryptographic agility. -3.9.1. Protocol description +3.8.1. Protocol description WireGuard is a simple VPN protocol that binds a pre-shared public key to one or more IP addresses. Users configure WireGuard by associating peer public keys with IP addresses. These mappings are stored in a CryptoKey Routing Table. (See Section 2 of [WireGuard] for more details and sample configurations.) These keys are used upon WireGuard packet transmission and reception. For example, upon receipt of a Handshake Initiation message, receivers use the static public key in their CryptoKey routing table to perform necessary cryptographic computations. @@ -825,316 +757,367 @@ introduced. WireGuard is designed to be entirely stateless, modulo the CryptoKey routing table, which has size linear with the number of trusted peers. If a WireGuard receiver is under heavy load and cannot process a packet, e.g., cannot spare CPU cycles for point multiplication, it can reply with a cookie similar to DTLS and IKEv2. This cookie only proves IP address ownership. Any rate limiting scheme can be applied to packets coming from non-spoofed addresses. -3.9.2. Protocol features +3.8.2. Protocol features o Optional PSK-based session creation. o Mutual client and server authentication. o Stateful, timestamp-based replay prevention. o Cookie-based DoS mitigation similar to DTLS and IKEv2. -3.9.3. Protocol dependencies +3.8.3. Protocol dependencies o Datagram transport. o Out-of-band key distribution and management. -3.10. SRTP (with DTLS) +3.9. MinimalT - SRTP - Secure RTP - is a profile for RTP that provides - confidentiality, message authentication, and replay protection for - data and control packets [RFC3711]. SRTP packets are encrypted using - a session key, which is derived from a separate master key. Master - keys are derived and managed externally, e.g., via DTLS, as specified - in RFC 5763 [RFC5763], under the control of a signaling protocol such - as SIP [RFC3261] or WebRTC [I-D.ietf-rtcweb-security-arch]. + MinimalT is a UDP-based transport security protocol designed to offer + confidentiality, mutual authentication, DoS prevention, and + connection mobility [MinimalT]. One major goal of the protocol is to + leverage existing protocols to obtain server-side configuration + information used to more quickly bootstrap a connection. MinimalT + uses a variant of TCP's congestion control algorithm. -3.10.1. Protocol descriptions +3.9.1. Protocol Description - SRTP adds confidentiality and optional integrity protection to RTP - data packets, and adds confidentially and mandatory integrity - protection to RTP control (RTCP) packets. For RTP data packets, this - is done by encrypting the payload section of the packet and - optionally appending an authentication tag (MAC) as a packet trailer, - with the RTP header authenticated but not encrypted. The RTP header - itself is left unencrypted to enable RTP header compression - [RFC2508][RFC3545]. For RTCP packets, the first packet in the - compound RTCP packet is partially encrypted, leaving the first eight - octets of the header as cleartext to allow identification of the - packet as RTCP, while the remainder of the compound packet is fully - encrypted. The entire RTCP packet is then authenticated by appending - a MAC as packet trailer. + MinimalT is a secure transport protocol built on top of a widespread + directory service. Clients and servers interact with local directory + services to (a) resolve server information and (b) public ephemeral + state information, respectively. Clients connect to a local resolver + once at boot time. Through this resolver they recover the IP + address(es) and public key(s) of each server to which they want to + connect. - Packets are encrypted using session keys, which are ultimately - derived from a master key and some additional master salt and session - salt. SRTP packets carry a 2-byte sequence number to partially - identify the unique packet index. SRTP peers maintain a separate - rollover counter (ROC) for RTP data packets that is incremented - whenever the sequence number wraps. The sequence number and ROC - together determine the packet index. RTCP packets have a similar, - yet differently named, field called the RTCP index which serves the - same purpose. + Connections are instances of user-authenticated, mobile sessions + between two endpoints. Connections run within tunnels between hosts. + A tunnel is a server-authenticated container that multiplexes + multiple connections between the same hosts. All connections in a + tunnel share the same transport state machine and encryption. Each + tunnel has a dedicated control connection used to configure and + manage the tunnel over time. Moreover, since tunnels are independent + of the network address information, they may be reused as both ends + of the tunnel move about the network. This does however imply that + the connection establishment and packet encryption mechanisms are + coupled. - Numerous encryption modes are supported. For popular modes of - operation, e.g., AES-CTR, the (unique) initialization vector (IV) - used for each encryption mode is a function of the RTP SSRC - (synchronization source), packet index, and session "salting key". + Before a client connects to a remote service, it must first establish + a tunnel to the host providing or offering the service. Tunnels are + established in 1-RTT using an ephemeral key obtained from the + directory service. Tunnel initiators provide their own ephemeral key + and, optionally, a DoS puzzle solution such that the recipient + (server) can verify the authenticity of the request and derive a + shared secret. Within a tunnel, new connections to services may be + established. - SRTP offers replay detection by keeping a replay list of already seen - and processed packet indices. If a packet arrives with an index that - matches one in the replay list, it is silently discarded. +3.9.2. Protocol Features - DTLS [RFC5764] is commonly used as a way to perform mutual - authentication and key agreement for SRTP [RFC5763]. (Here, - certificates marshal public keys between endpoints. Thus, self- - signed certificates may be used if peers do not mutually trust one - another, as is common on the Internet.) When DTLS is used, - certificate fingerprints are transmitted out-of-band using SIP. - Peers typically verify that DTLS-offered certificates match that - which are offered over SIP. This prevents active attacks on RTP, but - not on the signaling (SIP or WebRTC) channel. + o 0-RTT forward secrecy for new connections. -3.10.2. Protocol features + o DoS prevention by client-side puzzles. - o Optional replay protection with tunable replay windows. + o Tunnel-based mobility. - o Out-of-order packet receipt. + o (Transport Feature) Connection multiplexing between hosts across + shared tunnels. - o (RFC5763) Mandatory mutually authenticated key exchange. + o (Transport Feature) Congestion control state is shared across + connections between the same host pairs. - o Partial encryption, protecting media payloads and control packets - but not data packet headers. +3.9.3. Protocol Dependencies - o Optional authentication of data packets; mandatory authentication - of control packets. + o A DNS-like resolution service to obtain location information (an + IP address) and ephemeral keys. -3.10.3. Protocol dependencies + o A PKI trust store for certificate validation. - o External key derivation and management mechanism or protocol, - e.g., DTLS [RFC5763]. +3.10. CurveCP - o External signaling protocol to manage RTP parameters and locate - and identify peers, e.g., SIP [RFC3261] or WebRTC - [I-D.ietf-rtcweb-security-arch]. + CurveCP [CurveCP] is a UDP-based transport security protocol from + Daniel J. Bernstein. Unlike other transport security protocols, it + is based entirely upon highly efficient public key algorithms. This + removes many pitfalls associated with nonce reuse and key + synchronization. -4. Common Transport Security Features +3.10.1. Protocol Description + + CurveCP is a UDP-based transport security protocol. It is built on + three principal features: exclusive use of public key authenticated + encryption of packets, server-chosen cookies to prohibit memory and + computation DoS at the server, and connection mobility with a client- + chosen ephemeral identifier. + + There are two rounds in CurveCP. In the first round, the client + sends its first initialization packet to the server, carrying its + (possibly fresh) ephemeral public key C', with zero-padding encrypted + under the server's long-term public key. The server replies with a + cookie and its own ephemeral key S' and a cookie that is to be used + by the client. Upon receipt, the client then generates its second + initialization packet carrying: the ephemeral key C', cookie, and an + encryption of C', the server's domain name, and, optionally, some + message data. The server verifies the cookie and the encrypted + payload and, if valid, proceeds to send data in return. At this + point, the connection is established and the two parties can + communicate. + + The use of only public-key encryption and authentication, or + "boxing", is done to simplify problems that come with symmetric key + management and synchronization. For example, it allows the sender of + a message to be in complete control of each message's nonce. It does + not require either end to share secret keying material. Furthermore, + it allows connections (or sessions) to be associated with unique + ephemeral public keys as a mechanism for enabling forward secrecy + given the risk of long-term private key compromise. + + The client and server do not perform a standard key exchange. + Instead, in the initial exchange of packets, each party provides its + own ephemeral key to the other end. The client can choose a new + ephemeral key for every new connection. However, the server must + rotate these keys on a slower basis. Otherwise, it would be trivial + for an attacker to force the server to create and store ephemeral + keys with a fake client initialization packet. + + Unlike TCP, the server employs cookies to enable source validation. + After receiving the client's initial packet, encrypted under the + server's long-term public key, the server generates and returns a + stateless cookie that must be echoed back in the client's following + message. This cookie is encrypted under the client's ephemeral + public key. This stateless technique prevents attackers from + hijacking client initialization packets to obtain cookie values to + flood clients. (A client would detect the duplicate cookies and + reject the flooded packets.) Similarly, replaying the client's + second packet, carrying the cookie, will be detected by the server. + + CurveCP supports a weak form of client authentication. Clients are + permitted to send their long-term public keys in the second + initialization packet. A server can verify this public key and, if + untrusted, drop the connection and subsequent data. + + Unlike some other protocols, CurveCP data packets leave only the + ephemeral public key, the connection ID, and the per-message nonce in + the clear. Everything else is encrypted. + +3.10.2. Protocol Features + + o Forward-secure data encryption and authentication. + + o Per-packet public-key encryption. + + o 1-RTT session bootstrapping. + + o Connection mobility based on a client-chosen ephemeral identifier. + + o Connection establishment message padding to prevent traffic + amplification. + + o Sender-chosen explicit nonces, e.g., based on a sequence number. + +3.10.3. Protocol Dependencies + + o An unreliable transport protocol such as UDP. + +4. Security Features and Transport Dependencies There exists a common set of features shared across the transport - protocols surveyed in this document. The mandatory features should - be provided by any transport security protocol, while the optional - features are extensions that a subset of the protocols provide. For - clarity, we also distinguish between handshake and record features. + protocols surveyed in this document. Mandatory features constitute a + baseline of functionality that an application may assume for any TAPS + implementation. Optional features by contrast may vary from + implementation to implementation, and so an application cannot simply + assume they are available. Applications learn of and use optional + features by querying for their presence and support. Optional + features may not be implemented, or may be disabled if their presence + impacts transport services or if a necessary transport service is + unavailable. 4.1. Mandatory Features -4.1.1. Handshake + o Segment encryption and authentication: Transit data must be + protected with an authenticated encryption algorithm. - o Forward-secure segment encryption and authentication: Transit data - must be protected with an authenticated encryption algorithm. + o Forward-secure key establishment: Negotiated keying material must + come from an authenticated, forward-secure key exchange protocol. o Private key interface or injection: Authentication based on public key signatures is commonplace for many transport security protocols. o Endpoint authentication: The endpoint (receiver) of a new connection must be authenticated before any data is sent to said party. - o Source validation: Source validation must be provided to mitigate - server-targeted DoS attacks. This can be done with puzzles or - cookies. - -4.1.2. Record - - o Pre-shared key support: A record protocol must be able to use a - pre-shared key established out-of-band to encrypt individual - messages, packets, or datagrams. + o Pre-shared key support: A security protocol must be able to use a + pre-shared key established out-of-band or from a prior session to + encrypt individual messages, packets, or datagrams. 4.2. Optional Features -4.2.1. Handshake - o Mutual authentication: Transport security protocols must allow each endpoint to authenticate the other if required by the application. + * Transport dependency: None. + + * Application dependency: Mutual authentication required for + application support. + + o Connection mobility: Sessions should not be bound to a network + connection (or 5-tuple). This allows cryptographic key material + and other state information to be reused in the event of a + connection change. Examples of this include a NAT rebinding that + occurs without a client's knowledge. + + * Transport dependency: Connections are unreliable or can change + due to unpredictable network events, e.g., NAT re-bindings. + + * Application dependency: None. + + o Source validation: Source validation must be provided to mitigate + server-targeted DoS attacks. This can be done with puzzles or + cookies. + + * Transport dependency: Packets may arrive as datagrams instead + of streams from unauthenticated sources. + + * Application dependency: None. + o Application-layer feature negotiation: The type of application using a transport security protocol often requires features configured at the connection establishment layer, e.g., ALPN [RFC7301]. Moreover, application-layer features may often be used to offload the session to another server which can better handle the request. (The TLS SNI is one example of such a feature.) As such, transport security protocols should provide a generic mechanism to allow for such application-specific features and options to be configured or otherwise negotiated. + * Transport dependency: None. + + * Application dependency: Specification of application-layer + features or functionality. + o Configuration extensions: The protocol negotiation should be extensible with addition of new configuration options. + * Transport dependency: None. + + * Application dependency: Specification of application-specific + extensions. + o Session caching and management: Sessions should be cacheable to enable reuse and amortize the cost of performing session establishment handshakes. -4.2.2. Record + * Transport dependency: None. - o Connection mobility: Sessions should not be bound to a network - connection (or 5-tuple). This allows cryptographic key material - and other state information to be reused in the event of a - connection change. Examples of this include a NAT rebinding that - occurs without a client's knowledge. + * Application dependency: None. 5. Transport Security Protocol Interfaces This section describes the interface surface exposed by the security - protocols described above, with each interface. Note that not all - protocols support each interface. + protocols described above. Note that not all protocols support each + interface. We partition these interfaces into pre-connection + (configuration), connection, and post-connection interfaces. -5.1. Configuration Interfaces +5.1. Pre-Connection Interfaces Configuration interfaces are used to configure the security protocols before a handshake begins or the keys are negotiated. o Identity and Private Keys The application can provide its identities (certificates) and private keys, or mechanisms to access these, to the security protocol to use during handshakes. Protocols: TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2, WireGuard, SRTP o Supported Algorithms (Key Exchange, Signatures, and Ciphersuites) The application can choose the algorithms that are supported for key exchange, signatures, and ciphersuites. Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP - o Session Cache - The application provides the ability to save and retrieve session - state (such as tickets, keying material, and server parameters) - that may be used to resume the security session. + o Session Cache Management The application provides the ability to + save and retrieve session state (such as tickets, keying material, + and server parameters) that may be used to resume the security + session. Protocols: TLS, DTLS, QUIC + TLS, MinimalT o Authentication Delegation The application provides access to a separate module that will provide authentication, using EAP for example. Protocols: IKEv2, SRTP -5.2. Handshake Interfaces + o Pre-Shared Key Import + Either the handshake protocol or the application directly can + supply pre-shared keys for the record protocol use for encryption/ + decryption and authentication. If the application can supply keys + directly, this is considered explicit import; if the handshake + protocol traditionally provides the keys directly, it is + considered direct import; if the keys can only be shared by the + handshake, they are considered non-importable. - Handshake interfaces are the points of interaction between a - handshake protocol and the application, record protocol, and - transport once the handshake is active. + * Explict import: QUIC, ESP - o Send Handshake Messages - The handshake protocol needs to be able to send messages over a - transport to the remote peer to establish trust and to negotiate - keys. - Protocols: All (TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2, - WireGuard, SRTP (DTLS)) + * Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard + * Non-importable: CurveCP - o Receive Handshake Messages - The handshake protocol needs to be able to receive messages from - the remote peer over a transport to establish trust and to - negotiate keys. - Protocols: All (TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2, - WireGuard, SRTP (DTLS)) +5.2. Connection Interfaces o Identity Validation During a handshake, the security protocol will conduct identity validation of the peer. This can call into the application to offload validation. Protocols: All (TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS)) o Source Address Validation The handshake protocol may delegate validation of the remote peer that has sent data to the transport protocol or application. This involves sending a cookie exchange to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard +5.3. Post-Connection Interfaces + + o Connection Termination The security protocol may be instructed to + tear down its connection and session information. This is needed + by some protocols to prevent application data truncation attacks. + Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2 + o Key Update The handshake protocol may be instructed to update its keying material, either by the application directly or by the record protocol sending a key expiration event. Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2 - o Pre-Shared Key Export - The handshake protocol will generate one or more keys to be used - for record encryption/decryption and authentication. These may be - explicitly exportable to the application, traditionally limited to - direct export to the record protocol, or inherently non-exportable - because the keys must be used directly in conjunction with the - record protocol. + o Pre-Shared Key Export The handshake protocol will generate one or + more keys to be used for record encryption/decryption and + authentication. These may be explicitly exportable to the + application, traditionally limited to direct export to the record + protocol, or inherently non-exportable because the keys must be + used directly in conjunction with the record protocol. * Explict export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for SRTP) * Direct export: TLS, DTLS, MinimalT * Non-exportable: CurveCP -5.3. Record Interfaces - - Record interfaces are the points of interaction between a record - protocol and the application, handshake protocol, and transport once - in use. - - o Pre-Shared Key Import - Either the handshake protocol or the application directly can - supply pre-shared keys for the record protocol use for encryption/ - decryption and authentication. If the application can supply keys - directly, this is considered explicit import; if the handshake - protocol traditionally provides the keys directly, it is - considered direct import; if the keys can only be shared by the - handshake, they are considered non-importable. - - * Explict import: QUIC, ESP - - * Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard - - * Non-importable: CurveCP - - o Encrypt application data - The application can send data to the record protocol to encrypt it - into a format that can be sent on the underlying transport. The - encryption step may require that the application data is treated - as a stream or as datagrams, and that the transport to send the - encrypted records present a stream or datagram interface. - - * Stream-to-Stream Protocols: TLS, tcpcrypt - - * Datagram-to-Datagram Protocols: DTLS, ESP, SRTP, WireGuard - - * Stream-to-Datagram Protocols: QUIC ((Editor's Note: This - depends on the interface QUIC exposes to applications.)) - - o Decrypt application data - The application can receive data from its transport to be - decrypted using record protocol. The decryption step may require - that the incoming transport data is presented as a stream or as - datagrams, and that the resulting application data is a stream or - datagrams. - - * Stream-to-Stream Protocols: TLS, tcpcrypt - - * Datagram-to-Datagram Protocols: DTLS, ESP, SRTP, WireGuard - - * Datagram-to-Stream Protocols: QUIC ((Editor's Note: This - depends on the interface QUIC exposes to applications.)) - o Key Expiration The record protocol can signal that its keys are expiring due to reaching a time-based deadline, or a use-based deadline (number of bytes that have been encrypted with the key). This interaction is often limited to signaling between the record layer and the handshake layer. Protocols: ESP ((Editor's note: One may consider TLS/DTLS to also have this interface)) o Transport mobility @@ -1163,27 +1146,27 @@ [BLAKE2] "BLAKE2 -- simpler, smaller, fast as MD5", n.d.. [Curve25519] "Curve25519 - new Diffie-Hellman speed records", n.d.. [CurveCP] "CurveCP -- Usable security for the Internet", n.d.. [I-D.ietf-quic-tls] Thomson, M. and S. Turner, "Using Transport Layer Security - (TLS) to Secure QUIC", draft-ietf-quic-tls-10 (work in - progress), March 2018. + (TLS) to Secure QUIC", draft-ietf-quic-tls-11 (work in + progress), April 2018. [I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed - and Secure Transport", draft-ietf-quic-transport-10 (work - in progress), March 2018. + and Secure Transport", draft-ietf-quic-transport-11 (work + in progress), April 2018. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-14 (work in progress), March 2018. [I-D.ietf-tcpinc-tcpcrypt] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, Q., and E. Smith, "Cryptographic protection of TCP Streams (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-11 (work in progress), November 2017.