--- 1/draft-ietf-taps-transport-security-08.txt 2019-09-28 08:14:23.771741201 -0700 +++ 2/draft-ietf-taps-transport-security-09.txt 2019-09-28 08:14:24.039747964 -0700 @@ -1,25 +1,25 @@ Network Working Group C. Wood, Ed. Internet-Draft Apple Inc. Intended status: Informational T. Enghardt -Expires: February 8, 2020 TU Berlin +Expires: March 31, 2020 TU Berlin T. Pauly Apple Inc. C. Perkins University of Glasgow K. Rose Akamai Technologies, Inc. - August 07, 2019 + September 28, 2019 A Survey of Transport Security Protocols - draft-ietf-taps-transport-security-08 + draft-ietf-taps-transport-security-09 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 by describing the interfaces required to add security protocols. This survey is not limited to protocols developed within the scope or context of the IETF, and those included represent a superset of features a Transport @@ -35,21 +35,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 February 8, 2020. + This Internet-Draft will expire on March 31, 2020. Copyright Notice Copyright (c) 2019 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 @@ -314,21 +314,21 @@ 4. Transport Security Protocol Descriptions This section contains descriptions of security protocols currently used to protect data being sent over a network. For each protocol, we describe its provided features and dependencies on other protocols. 4.1. TLS - TLS (Transport Layer Security) [RFC5246] is a common protocol used to + TLS (Transport Layer Security) [RFC8446] is a common protocol used to establish a secure session between two endpoints. Communication over this session "prevents eavesdropping, tampering, and message forgery." TLS consists of a tightly coupled handshake and record protocol. The handshake protocol is used to authenticate peers, negotiate protocol options, such as cryptographic algorithms, and derive session-specific keying material. The record protocol is used to marshal (possibly encrypted) data from one peer to the other. This data may contain handshake messages or raw application data. 4.1.1. Protocol Description @@ -410,21 +410,21 @@ 4.1.3. Protocol Dependencies o In-order, reliable bytestream transport. o (Optionally) A PKI trust store for certificate validation. 4.2. DTLS DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS, - but differs in that it is designed to run over unrelaible datagram + but differs in that it is designed to run over unreliable datagram protocols like UDP instead of TCP. DTLS modifies the protocol to make sure it can still provide the same security guarantees as TLS even without reliability from the transport. DTLS was designed to be as similar to TLS as possible, so this document assumes that all properties from TLS are carried over except where specified. 4.2.1. Protocol Description DTLS is modified from TLS to operate with the possibility of packet loss, reordering, and duplication that may occur when operating over @@ -443,21 +443,21 @@ handshake messages across records. The receiver must reassemble records before processing. DTLS relies on unique UDP 4-tuples to identify connections, or a similar mechanism in other datagram transports. Since all application-layer data is encrypted, demultiplexing over the same 4-tuple requires the use of a connection identifier extension [I-D.ietf-tls-dtls-connection-id] to permit identification of the correct connection-specific cryptographic context without the use of trial decryption. (Note that this extension is only supported in - DTLS 1.2 and 1.3 {{?I-D.ietf-tls-dtls13}.) + DTLS 1.2 and 1.3 [I-D.ietf-tls-dtls13].) Since datagrams can be replayed, DTLS provides optional anti-replay detection based on a window of acceptable sequence numbers [RFC6347]. 4.2.2. Security Features o Record replay protection. o Record (datagram) confidentiality and integrity. @@ -525,21 +525,21 @@ as the Initial and Handshake packets. 4.3.2. Security Features o DoS mitigation (cookie-based). See also the properties of TLS. 4.3.3. Protocol Dependencies - o QUIC transport relies on UDP. + o QUIC transport assumes an unreliable transport, e.g., UDP. o QUIC transport relies on TLS 1.3 for key exchange, peer authentication, and shared secret derivation. o For the handshake: Reliable, in-order transport. QUIC provides its own reliability. 4.3.4. Variant: Google QUIC Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol @@ -581,21 +581,21 @@ Diffie-Hellman group, and (for IKE SAs only) a pseudorandom function algorithm. Each peer may support multiple proposals, and the most preferred mutually supported proposal is chosen during the handshake. The authentication phase of IKEv2 may use Shared Secrets, Certificates, Digital Signatures, or an EAP (Extensible Authentication Protocol) method. At a minimum, IKEv2 takes two round trips to set up both an IKE SA and a Child SA. If EAP is used, this exchange may be expanded. - Any SA used by IKEv2 can be rekeyed before expiration, which is + Any SA used by IKEv2 can be re-keyed before expiration, which is usually based either on time or number of bytes encrypted. 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 outer IP addresses and interfaces [RFC4555]. When UDP is not available or well-supported on a network, IKEv2 may @@ -709,28 +709,28 @@ 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 to perform mutual authentication and key agreement for SRTP [RFC5763]. Peers use DTLS to perform mutual certificate-based authentication on the media path, and to generate the SRTP master key. Peer certificates can be issued and signed by a certificate authority. Alternatively, certificates used in the DTLS exchange can be self-signed. If they are self-signed, certificate - fingerprints are included in the signalling exchange (e.g., in SIP or + fingerprints are included in the signaling exchange (e.g., in SIP or WebRTC), and used to bind the DTLS key exchange in the media plane to the signaling plane. The combination of a mutually authenticated DTLS key exchange on the media path and a fingerprint sent in the - signalling channel protects against active attacks on the media, - provided the signalling can be trusted. Signalling needs to be + signaling channel protects against active attacks on the media, + provided the signaling can be trusted. Signaling needs to be protected as described in, for example, SIP [RFC3261] Authenticated - Identity Management [RFC4474] or the WebRTC security architecture + Identity Management [RFC8224] or the WebRTC security architecture [I-D.ietf-rtcweb-security-arch], to provide complete system security. 4.5.2. Security Features o Forward-secure session key establishment. o Cryptographic algorithm negotiation. o Mutual authentication. @@ -744,21 +744,21 @@ o Out-of-order record receipt. 4.5.3. Protocol Dependencies o Secure RTP can run over UDP or TCP. o External key derivation and management protocol, e.g., DTLS [RFC5763]. o External identity management protocol, e.g., SIP Authenticated - Identity Management [RFC4474], WebRTC Security Architecture + Identity Management [RFC8224], WebRTC Security Architecture [I-D.ietf-rtcweb-security-arch]. 4.5.4. Variant: ZRTP for Media Path Key Agreement ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It uses standard SRTP to protect RTP data packets and RTCP packets, but provides alternative key agreement and identity management protocols. Key agreement is performed using a Diffie-Hellman key exchange that runs on the media path. This generates a shared secret that is then @@ -770,21 +770,21 @@ requires endpoints to display a short authentication string that the users must read and verbally compare to validate the hashes and ensure security. Endpoints cache some key material after the first call to use in subsequent calls; this is mixed in with the Diffie- Hellman shared secret, so the short authentication string need only be checked once for a given user. This gives key continuity properties analogous to the secure shell (ssh) [RFC4253]. 4.6. tcpcrypt - Tcpcrypt is a lightweight extension to the TCP protocol for + Tcpcrypt [RFC8548] is a lightweight extension to the TCP protocol for opportunistic encryption. Applications may use tcpcrypt's unique session ID for further application-level authentication. Absent this authentication, tcpcrypt is vulnerable to active attacks. 4.6.1. Protocol Description Tcpcrypt extends TCP to enable opportunistic encryption between the two ends of a TCP connection [RFC8548]. 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 @@ -861,21 +861,21 @@ cryptographic computations. WireGuard builds on Noise [Noise] for 1-RTT key exchange with identity hiding. The handshake hides peer identities as per the SIGMA construction [SIGMA]. As a consequence of using Noise, WireGuard comes with a fixed set of cryptographic algorithms: o x25519 [Curve25519] and HKDF [RFC5869] for ECDH and key derivation. - o ChaCha20+Poly1305 [RFC7539] for packet authenticated encryption. + o ChaCha20+Poly1305 [RFC8439] for packet authenticated encryption. o BLAKE2s [BLAKE2] for hashing. There is no cryptographic agility. If weaknesses are found in any of these algorithms, new message types using new algorithms must be introduced. If a WireGuard receiver is under heavy load and cannot process a packet, e.g., cannot spare CPU cycles for expensive public key cryptographic operations, it can reply with a cookie similar to DTLS @@ -1073,22 +1073,22 @@ OpenVPN facilitates authentication using either a pre-shared static key or using X.509 certificates and TLS. In pre-shared key mode, OpenVPN derives keys for encryption and authentication directly from one or multiple symmetric keys. In TLS mode, OpenVPN encapsulates a TLS handshake, in which both peers must present a certificate for authentication. After the handshake, both sides contribute random source material to derive keys for encryption and authentication using the TLS pseudo random function (PRF). OpenVPN provides the possibility to authenticate and encrypt the TLS handshake itself - using a pre-shared key or passphrase. Furthermore, it supports - rekeying using TLS. + using a pre-shared key or passphrase. Furthermore, it supports re- + keying using TLS. After authentication and key exchange, OpenVPN encrypts payload data, i.e., IP packets or Ethernet frames, and authenticates the payload using HMAC. Applications can select an arbitrary encryption algorithm (cipher) and key size, as well hash function for HMAC. The default cipher and hash functions are AES-GCM and SHA1, respectively. Recent versions of the protocol support cipher negotiation. OpenVPN can run over TCP or UDP. When running over UDP, OpenVPN provides a simple reliability layer for control packets such as the @@ -1100,21 +1100,21 @@ TCP, OpenVPN includes the packet length in the header, which allows the peer to deframe the TCP stream into messages. For replay protection, OpenVPN assigns an identifier to each outgoing packet, which is unique for the packet and the currently used key. In pre-shared key mode or with a CFB or OFB mode cipher, OpenVPN combines a timestamp with an incrementing sequence number into a 64-bit identifier. In TLS mode with CBC cipher mode, OpenVPN omits the timestamp, so identifiers are only 32-bit. This is sufficient since OpenVPN can guarantee the uniqueness of this identifier for - each key, as it can trigger rekeying if needed. + each key, as it can trigger re-keying if needed. OpenVPN supports connection mobility by allowing a peer to change its IP address during an ongoing session. When configured accordingly, a host will accept authenticated packets for a session from any IP address. 4.10.2. Protocol Features o Peer authentication using certificates or pre-shared key. @@ -1343,21 +1343,21 @@ example. Protocols: IKEv2, SRTP 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 + * Explicit import: QUIC, ESP * Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard * Non-importable: CurveCP 6.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)) @@ -1429,42 +1429,49 @@ improve privacy by reducing information leakage via encryption. However, varying amounts of metadata remain in the clear across each protocol. For example, client and server certificates are sent in cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3 [RFC8446]. A survey of privacy features, or lack thereof, for various security protocols could be addressed in a separate document. 10. Acknowledgments The authors would like to thank Bob Bradley, Frederic Jacobs, Mirja - Kuehlewind, Yannick Sierra, and Brian Trammell for their input and - feedback on earlier versions of this draft. + Kuehlewind, Yannick Sierra, Brian Trammell, and Magnus Westerlund for + their input and feedback on this draft. 11. Informative References - [ALTS] "Application Layer Transport Security", n.d.. + [ALTS] Ghali, C., Stubblefield, A., Knapp, E., Li, J., Schmidt, + B., and J. Boeuf, "Application Layer Transport Security", + . - [BLAKE2] "BLAKE2 -- simpler, smaller, fast as MD5", n.d.. + [BLAKE2] Aumasson, J., Neves, S., Wilcox-O'Hearn, Z., and C. + Winnerlein, "BLAKE2 -- simpler, smaller, fast as MD5", + . [Curve25519] - "Curve25519 - new Diffie-Hellman speed records", n.d.. + Bernstein, D., "Curve25519 - new Diffie-Hellman speed + records", . - [CurveCP] "CurveCP -- Usable security for the Internet", n.d.. + [CurveCP] Bernstein, D., "CurveCP -- Usable security for the + Internet", . [I-D.ietf-quic-tls] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", - draft-ietf-quic-tls-22 (work in progress), July 2019. + draft-ietf-quic-tls-23 (work in progress), September 2019. [I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed - and Secure Transport", draft-ietf-quic-transport-22 (work - in progress), July 2019. + and Secure Transport", draft-ietf-quic-transport-23 (work + in progress), September 2019. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-20 (work in progress), July 2019. [I-D.ietf-taps-arch] Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., Perkins, C., Tiesel, P., and C. Wood, "An Architecture for Transport Services", draft-ietf-taps-arch-04 (work in progress), July 2019. @@ -1479,27 +1486,37 @@ [I-D.ietf-taps-minset] Welzl, M. and S. Gjessing, "A Minimal Set of Transport Services for End Systems", draft-ietf-taps-minset-11 (work in progress), September 2018. [I-D.ietf-tls-dtls-connection-id] Rescorla, E., Tschofenig, H., and T. Fossati, "Connection Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- id-06 (work in progress), July 2019. + [I-D.ietf-tls-dtls13] + Rescorla, E., Tschofenig, H., and N. Modadugu, "The + Datagram Transport Layer Security (DTLS) Protocol Version + 1.3", draft-ietf-tls-dtls13-32 (work in progress), July + 2019. + [MinimalT] - "MinimaLT -- Minimal-latency Networking Through Better - Security", n.d.. + Petullo, W., Zhang, X., Solworth, J., Bernstein, D., and + T. Lange, "MinimaLT -- Minimal-latency Networking Through + Better Security", + . - [Noise] "The Noise Protocol Framework", n.d.. + [Noise] Perrin, T., "The Noise Protocol Framework", + . - [OpenVPN] "OpenVPN cryptographic layer", n.d.. + [OpenVPN] "OpenVPN cryptographic layer", . [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 1998, . [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, DOI 10.17487/RFC2508, February 1999, . @@ -1530,26 +1547,20 @@ January 2006, . [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . - [RFC4474] Peterson, J. and C. Jennings, "Enhancements for - Authenticated Identity Management in the Session - Initiation Protocol (SIP)", RFC 4474, - DOI 10.17487/RFC4474, August 2006, - . - [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange @@ -1601,58 +1612,67 @@ [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, . - [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF - Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, - . - [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed., "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms", RFC 8095, DOI 10.17487/RFC8095, March 2017, . + [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, + "Authenticated Identity Management in the Session + Initiation Protocol (SIP)", RFC 8224, + DOI 10.17487/RFC8224, February 2018, + . + [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, August 2017, . + [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF + Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, + . + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8449] Thomson, M., "Record Size Limit Extension for TLS", RFC 8449, DOI 10.17487/RFC8449, August 2018, . [RFC8547] Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547, DOI 10.17487/RFC8547, May 2019, . [RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, Q., and E. Smith, "Cryptographic Protection of TCP Streams (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, . - [SIGMA] "SIGMA -- The 'SIGn-and-MAc' Approach to Authenticated - Diffie-Hellman and Its Use in the IKE-Protocols", n.d.. + [SIGMA] Krawczyk, H., "SIGMA -- The 'SIGn-and-MAc' Approach to + Authenticated Diffie-Hellman and Its Use in the IKE- + Protocols", . [WireGuard] - "WireGuard -- Next Generation Kernel Network Tunnel", - n.d.. + Donenfeld, J., "WireGuard -- Next Generation Kernel + Network Tunnel", + . Authors' Addresses Christopher A. Wood (editor) Apple Inc. One Apple Park Way Cupertino, California 95014 United States of America Email: cawood@apple.com