draft-ietf-taps-transport-security-00.txt | draft-ietf-taps-transport-security-01.txt | |||
---|---|---|---|---|
Network Working Group T. Pauly | Network Working Group T. Pauly | |||
Internet-Draft Apple Inc. | Internet-Draft Apple Inc. | |||
Intended status: Informational C. Perkins | Intended status: Informational C. Perkins | |||
Expires: September 24, 2018 University of Glasgow | Expires: November 12, 2018 University of Glasgow | |||
K. Rose | K. Rose | |||
Akamai Technologies, Inc. | Akamai Technologies, Inc. | |||
C. Wood | C. Wood | |||
Apple Inc. | Apple Inc. | |||
March 23, 2018 | May 11, 2018 | |||
A Survey of Transport Security Protocols | A Survey of Transport Security Protocols | |||
draft-ietf-taps-transport-security-00 | draft-ietf-taps-transport-security-01 | |||
Abstract | Abstract | |||
This document provides a survey of commonly used or notable network | This document provides a survey of commonly used or notable network | |||
security protocols, with a focus on how they interact and integrate | security protocols, with a focus on how they interact and integrate | |||
with applications and transport protocols. Its goal is to supplement | with applications and transport protocols. Its goal is to supplement | |||
efforts to define and catalog transport services [RFC8095] by | efforts to define and catalog transport services [RFC8095] by | |||
describing the interfaces required to add security protocols. It | describing the interfaces required to add security protocols. It | |||
examines Transport Layer Security (TLS), Datagram Transport Layer | examines Transport Layer Security (TLS), Datagram Transport Layer | |||
Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + | Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + | |||
skipping to change at page 1, line 45 ¶ | skipping to change at page 1, line 45 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | 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 Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 37 ¶ | skipping to change at page 2, line 37 ¶ | |||
3.1.2. Protocol Features . . . . . . . . . . . . . . . . . . 7 | 3.1.2. Protocol Features . . . . . . . . . . . . . . . . . . 7 | |||
3.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 7 | 3.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 7 | |||
3.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.2.1. Protocol Description . . . . . . . . . . . . . . . . 7 | 3.2.1. Protocol Description . . . . . . . . . . . . . . . . 7 | |||
3.2.2. Protocol Features . . . . . . . . . . . . . . . . . . 8 | 3.2.2. Protocol Features . . . . . . . . . . . . . . . . . . 8 | |||
3.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 8 | 3.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 8 | |||
3.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 9 | 3.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 9 | |||
3.3.1. Protocol Description . . . . . . . . . . . . . . . . 9 | 3.3.1. Protocol Description . . . . . . . . . . . . . . . . 9 | |||
3.3.2. Protocol Features . . . . . . . . . . . . . . . . . . 9 | 3.3.2. Protocol Features . . . . . . . . . . . . . . . . . . 9 | |||
3.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10 | 3.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10 | |||
3.4. gQUIC . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 3.3.4. Differences from Google QUIC . . . . . . . . . . . . 10 | |||
3.4.1. Protocol Description . . . . . . . . . . . . . . . . 10 | 3.3.5. Protocol Description . . . . . . . . . . . . . . . . 10 | |||
3.4.2. Protocol Dependencies . . . . . . . . . . . . . . . . 10 | 3.3.6. Protocol Dependencies . . . . . . . . . . . . . . . . 10 | |||
3.5. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 10 | 3.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 10 | |||
3.5.1. Protocol Description . . . . . . . . . . . . . . . . 10 | 3.4.1. Protocol descriptions . . . . . . . . . . . . . . . . 10 | |||
3.5.2. Protocol Features . . . . . . . . . . . . . . . . . . 11 | 3.4.2. Protocol features . . . . . . . . . . . . . . . . . . 12 | |||
3.5.3. Protocol Dependencies . . . . . . . . . . . . . . . . 11 | 3.4.3. Protocol dependencies . . . . . . . . . . . . . . . . 12 | |||
3.6. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 3.5. SRTP (with DTLS) . . . . . . . . . . . . . . . . . . . . 13 | |||
3.6.1. Protocol Description . . . . . . . . . . . . . . . . 12 | 3.5.1. Protocol descriptions . . . . . . . . . . . . . . . . 13 | |||
3.6.2. Protocol Features . . . . . . . . . . . . . . . . . . 13 | 3.5.2. Protocol features . . . . . . . . . . . . . . . . . . 14 | |||
3.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 13 | 3.5.3. Protocol dependencies . . . . . . . . . . . . . . . . 14 | |||
3.7. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 13 | 3.6. Differences from ZRTP . . . . . . . . . . . . . . . . . . 15 | |||
3.7.1. Protocol Description . . . . . . . . . . . . . . . . 13 | 3.7. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
3.7.2. Protocol Features . . . . . . . . . . . . . . . . . . 14 | 3.7.1. Protocol Description . . . . . . . . . . . . . . . . 15 | |||
3.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 15 | 3.7.2. Protocol Features . . . . . . . . . . . . . . . . . . 16 | |||
3.8. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 15 | 3.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 16 | |||
3.8.1. Protocol descriptions . . . . . . . . . . . . . . . . 15 | ||||
3.8.2. Protocol features . . . . . . . . . . . . . . . . . . 16 | 3.8. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
3.8.1. Protocol description . . . . . . . . . . . . . . . . 16 | ||||
3.8.2. Protocol features . . . . . . . . . . . . . . . . . . 17 | ||||
3.8.3. Protocol dependencies . . . . . . . . . . . . . . . . 17 | 3.8.3. Protocol dependencies . . . . . . . . . . . . . . . . 17 | |||
3.9. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 17 | 3.9. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
3.9.1. Protocol description . . . . . . . . . . . . . . . . 17 | 3.9.1. Protocol Description . . . . . . . . . . . . . . . . 18 | |||
3.9.2. Protocol features . . . . . . . . . . . . . . . . . . 18 | 3.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 18 | |||
3.9.3. Protocol dependencies . . . . . . . . . . . . . . . . 18 | 3.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 19 | |||
3.10. SRTP (with DTLS) . . . . . . . . . . . . . . . . . . . . 18 | 3.10. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
3.10.1. Protocol descriptions . . . . . . . . . . . . . . . 19 | 3.10.1. Protocol Description . . . . . . . . . . . . . . . . 19 | |||
3.10.2. Protocol features . . . . . . . . . . . . . . . . . 20 | 3.10.2. Protocol Features . . . . . . . . . . . . . . . . . 20 | |||
3.10.3. Protocol dependencies . . . . . . . . . . . . . . . 20 | 3.10.3. Protocol Dependencies . . . . . . . . . . . . . . . 20 | |||
4. Common Transport Security Features . . . . . . . . . . . . . 20 | 4. Security Features and Transport Dependencies . . . . . . . . 21 | |||
4.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 20 | 4.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 21 | |||
4.1.1. Handshake . . . . . . . . . . . . . . . . . . . . . . 20 | ||||
4.1.2. Record . . . . . . . . . . . . . . . . . . . . . . . 21 | ||||
4.2. Optional Features . . . . . . . . . . . . . . . . . . . . 21 | 4.2. Optional Features . . . . . . . . . . . . . . . . . . . . 21 | |||
4.2.1. Handshake . . . . . . . . . . . . . . . . . . . . . . 21 | 5. Transport Security Protocol Interfaces . . . . . . . . . . . 23 | |||
4.2.2. Record . . . . . . . . . . . . . . . . . . . . . . . 21 | 5.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 23 | |||
5. Transport Security Protocol Interfaces . . . . . . . . . . . 21 | 5.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 24 | |||
5.1. Configuration Interfaces . . . . . . . . . . . . . . . . 22 | 5.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 24 | |||
5.2. Handshake Interfaces . . . . . . . . . . . . . . . . . . 22 | ||||
5.3. Record Interfaces . . . . . . . . . . . . . . . . . . . . 23 | ||||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 | |||
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
9. Normative References . . . . . . . . . . . . . . . . . . . . 25 | 9. Normative References . . . . . . . . . . . . . . . . . . . . 25 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
1. Introduction | 1. Introduction | |||
This document provides a survey of commonly used or notable network | This document provides a survey of commonly used or notable network | |||
security protocols, with a focus on how they interact and integrate | security protocols, with a focus on how they interact and integrate | |||
skipping to change at page 9, line 9 ¶ | skipping to change at page 9, line 9 ¶ | |||
o UDP 4-tuple uniqueness, or the connection identifier extension, | o UDP 4-tuple uniqueness, or the connection identifier extension, | |||
for demultiplexing. | for demultiplexing. | |||
o Path MTU discovery. | o Path MTU discovery. | |||
3.3. (IETF) QUIC with TLS | 3.3. (IETF) QUIC with TLS | |||
QUIC (Quick UDP Internet Connections) is a new standards-track | QUIC (Quick UDP Internet Connections) is a new standards-track | |||
transport protocol that runs over UDP, loosely based on Google's | 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 | details.) The QUIC transport layer itself provides support for data | |||
confidentiality and integrity. This requires keys to be derived with | confidentiality and integrity. This requires keys to be derived with | |||
a separate handshake protocol. A mapping for QUIC over TLS 1.3 | a separate handshake protocol. A mapping for QUIC over TLS 1.3 | |||
[I-D.ietf-quic-tls] has been specified to provide this handshake. | [I-D.ietf-quic-tls] has been specified to provide this handshake. | |||
3.3.1. Protocol Description | 3.3.1. Protocol Description | |||
As QUIC relies on TLS to secure its transport functions, it creates | As QUIC relies on TLS to secure its transport functions, it creates | |||
specific integration points between its security and transport | specific integration points between its security and transport | |||
functions: | functions: | |||
skipping to change at page 10, line 19 ¶ | skipping to change at page 10, line 19 ¶ | |||
3.3.3. Protocol Dependencies | 3.3.3. Protocol Dependencies | |||
o QUIC transport relies on UDP. | o QUIC transport relies on UDP. | |||
o QUIC transport relies on TLS 1.3 for authentication and initial | o QUIC transport relies on TLS 1.3 for authentication and initial | |||
key derivation. | key derivation. | |||
o TLS within QUIC relies on a reliable stream abstraction for its | o TLS within QUIC relies on a reliable stream abstraction for its | |||
handshake. | handshake. | |||
3.4. gQUIC | 3.3.4. Differences from Google QUIC | |||
gQUIC is a UDP-based multiplexed streaming protocol designed and | Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol | |||
deployed by Google following experience from deploying SPDY, the | designed and deployed by Google following experience from deploying | |||
proprietary predecessor to HTTP/2. gQUIC was originally known as | SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally | |||
"QUIC": this document uses gQUIC to unambiguously distinguish it from | known as "QUIC": this document uses gQUIC to unambiguously | |||
the standards-track IETF QUIC. The proprietary technical forebear of | distinguish it from the standards-track IETF QUIC. The proprietary | |||
IETF QUIC, gQUIC was originally designed with tightly-integrated | technical forebear of IETF QUIC, gQUIC was originally designed with | |||
security and application data transport protocols. | tightly-integrated security and application data transport protocols. | |||
3.4.1. Protocol Description | 3.3.5. Protocol Description | |||
((TODO: write me)) | ((TODO: write me)) | |||
3.4.2. Protocol Dependencies | 3.3.6. Protocol Dependencies | |||
((TODO: write me)) | ((TODO: write me)) | |||
3.5. MinimalT | 3.4. IKEv2 with ESP | |||
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 | ||||
IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec | IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec | |||
protocol suite that encrypts and authenticates IP packets, either as | protocol suite that encrypts and authenticates IP packets, either as | |||
for creating tunnels (tunnel-mode) or for direct transport | for creating tunnels (tunnel-mode) or for direct transport | |||
connections (transport-mode). This suite of protocols separates out | connections (transport-mode). This suite of protocols separates out | |||
the key generation protocol (IKEv2) from the transport encryption | the key generation protocol (IKEv2) from the transport encryption | |||
protocol (ESP). Each protocol can be used independently, but this | protocol (ESP). Each protocol can be used independently, but this | |||
document considers them together, since that is the most common | document considers them together, since that is the most common | |||
pattern. | pattern. | |||
3.8.1. Protocol descriptions | 3.4.1. Protocol descriptions | |||
3.4.1.1. IKEv2 | ||||
3.8.1.1. IKEv2 | ||||
IKEv2 is a control protocol that runs on UDP port 500. Its primary | IKEv2 is a control protocol that runs on UDP port 500. Its primary | |||
goal is to generate keys for Security Associations (SAs). It first | goal is to generate keys for Security Associations (SAs). It first | |||
uses a Diffie-Hellman key exchange to generate keys for the "IKE SA", | 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 | which is a set of keys used to encrypt further IKEv2 messages. It | |||
then goes through a phase of authentication in which both peers | then goes through a phase of authentication in which both peers | |||
present blobs signed by a shared secret or private key, after which | 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 | another set of keys is derived, referred to as the "Child SA". These | |||
Child SA keys are used by ESP. | Child SA keys are used by ESP. | |||
skipping to change at page 16, line 12 ¶ | skipping to change at page 11, line 41 ¶ | |||
There is an extension to IKEv2 that allows session resumption | There is an extension to IKEv2 that allows session resumption | |||
[RFC5723]. | [RFC5723]. | |||
MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a | MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a | |||
set of Security Associations to migrate over different addresses and | set of Security Associations to migrate over different addresses and | |||
interfaces [RFC4555]. | interfaces [RFC4555]. | |||
When UDP is not available or well-supported on a network, IKEv2 may | When UDP is not available or well-supported on a network, IKEv2 may | |||
be encapsulated in TCP [RFC8229]. | 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 | ESP is a protocol that encrypts and authenticates IPv4 and IPv6 | |||
packets. The keys used for both encryption and authentication can be | packets. The keys used for both encryption and authentication can be | |||
derived from an IKEv2 exchange. ESP Security Associations come as | derived from an IKEv2 exchange. ESP Security Associations come as | |||
pairs, one for each direction between two peers. Each SA is | pairs, one for each direction between two peers. Each SA is | |||
identified by a Security Parameter Index (SPI), which is marked on | identified by a Security Parameter Index (SPI), which is marked on | |||
each encrypted ESP packet. | each encrypted ESP packet. | |||
ESP packets include the SPI, a sequence number, an optional | ESP packets include the SPI, a sequence number, an optional | |||
Initialization Vector (IV), payload data, padding, a length and next | Initialization Vector (IV), payload data, padding, a length and next | |||
skipping to change at page 16, line 39 ¶ | skipping to change at page 12, line 23 ¶ | |||
Since ESP operates on IP packets, it is not directly tied to the | Since ESP operates on IP packets, it is not directly tied to the | |||
transport protocols it encrypts. This means it requires little or no | transport protocols it encrypts. This means it requires little or no | |||
change from transports in order to provide security. | change from transports in order to provide security. | |||
ESP packets may be sent directly over IP, but where network | ESP packets may be sent directly over IP, but where network | |||
conditions warrant (e.g., when a NAT is present or when a firewall | 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 | blocks such packets) they may be encapsulated in UDP [RFC3948] or TCP | |||
[RFC8229]. | [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 Encryption and authentication of handshake packets. | |||
o Cryptographic algorithm negotiation. | o Cryptographic algorithm negotiation. | |||
o Session resumption. | o Session resumption. | |||
o Mobility across addresses and interfaces. | o Mobility across addresses and interfaces. | |||
o Peer authentication extensibility based on shared secret, | o Peer authentication extensibility based on shared secret, | |||
certificates, digital signatures, or EAP methods. | certificates, digital signatures, or EAP methods. | |||
3.8.2.2. ESP | 3.4.2.2. ESP | |||
o Data confidentiality and authentication. | o Data confidentiality and authentication. | |||
o Connectionless integrity. | o Connectionless integrity. | |||
o Anti-replay protection. | o Anti-replay protection. | |||
o Limited flow confidentiality. | o Limited flow confidentiality. | |||
3.8.3. Protocol dependencies | 3.4.3. Protocol dependencies | |||
3.4.3.1. IKEv2 | ||||
3.8.3.1. IKEv2 | ||||
o Availability of UDP to negotiate, or implementation support for | o Availability of UDP to negotiate, or implementation support for | |||
TCP-encapsulation. | TCP-encapsulation. | |||
o Some EAP authentication types require accessing a hardware device, | o Some EAP authentication types require accessing a hardware device, | |||
such as a SIM card; or interacting with a user, such as password | such as a SIM card; or interacting with a user, such as password | |||
prompting. | prompting. | |||
3.8.3.2. ESP | 3.4.3.2. ESP | |||
o Since ESP is below transport protocols, it does not have any | o Since ESP is below transport protocols, it does not have any | |||
dependencies on the transports themselves, other than on UDP or | dependencies on the transports themselves, other than on UDP or | |||
TCP where encapsulation is employed. | 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 | WireGuard is a layer 3 protocol designed to complement or replace | |||
IPsec [WireGuard]. Unlike most transport security protocols, which | IPsec [WireGuard]. Unlike most transport security protocols, which | |||
rely on PKI for peer authentication, WireGuard authenticates peers | rely on PKI for peer authentication, WireGuard authenticates peers | |||
using pre-shared public keys delivered out-of-band, each of which is | 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 | bound to one or more IP addresses. Moreover, as a protocol suited | |||
for VPNs, WireGuard offers no extensibility, negotiation, or | for VPNs, WireGuard offers no extensibility, negotiation, or | |||
cryptographic agility. | 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 | WireGuard is a simple VPN protocol that binds a pre-shared public key | |||
to one or more IP addresses. Users configure WireGuard by | to one or more IP addresses. Users configure WireGuard by | |||
associating peer public keys with IP addresses. These mappings are | associating peer public keys with IP addresses. These mappings are | |||
stored in a CryptoKey Routing Table. (See Section 2 of [WireGuard] | stored in a CryptoKey Routing Table. (See Section 2 of [WireGuard] | |||
for more details and sample configurations.) These keys are used | for more details and sample configurations.) These keys are used | |||
upon WireGuard packet transmission and reception. For example, upon | upon WireGuard packet transmission and reception. For example, upon | |||
receipt of a Handshake Initiation message, receivers use the static | receipt of a Handshake Initiation message, receivers use the static | |||
public key in their CryptoKey routing table to perform necessary | public key in their CryptoKey routing table to perform necessary | |||
cryptographic computations. | cryptographic computations. | |||
skipping to change at page 18, line 29 ¶ | skipping to change at page 17, line 24 ¶ | |||
introduced. | introduced. | |||
WireGuard is designed to be entirely stateless, modulo the CryptoKey | WireGuard is designed to be entirely stateless, modulo the CryptoKey | |||
routing table, which has size linear with the number of trusted | routing table, which has size linear with the number of trusted | |||
peers. If a WireGuard receiver is under heavy load and cannot | peers. If a WireGuard receiver is under heavy load and cannot | |||
process a packet, e.g., cannot spare CPU cycles for point | process a packet, e.g., cannot spare CPU cycles for point | |||
multiplication, it can reply with a cookie similar to DTLS and IKEv2. | multiplication, it can reply with a cookie similar to DTLS and IKEv2. | |||
This cookie only proves IP address ownership. Any rate limiting | This cookie only proves IP address ownership. Any rate limiting | |||
scheme can be applied to packets coming from non-spoofed addresses. | 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 Optional PSK-based session creation. | |||
o Mutual client and server authentication. | o Mutual client and server authentication. | |||
o Stateful, timestamp-based replay prevention. | o Stateful, timestamp-based replay prevention. | |||
o Cookie-based DoS mitigation similar to DTLS and IKEv2. | o Cookie-based DoS mitigation similar to DTLS and IKEv2. | |||
3.9.3. Protocol dependencies | 3.8.3. Protocol dependencies | |||
o Datagram transport. | o Datagram transport. | |||
o Out-of-band key distribution and management. | 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 | MinimalT is a UDP-based transport security protocol designed to offer | |||
confidentiality, message authentication, and replay protection for | confidentiality, mutual authentication, DoS prevention, and | |||
data and control packets [RFC3711]. SRTP packets are encrypted using | connection mobility [MinimalT]. One major goal of the protocol is to | |||
a session key, which is derived from a separate master key. Master | leverage existing protocols to obtain server-side configuration | |||
keys are derived and managed externally, e.g., via DTLS, as specified | information used to more quickly bootstrap a connection. MinimalT | |||
in RFC 5763 [RFC5763], under the control of a signaling protocol such | uses a variant of TCP's congestion control algorithm. | |||
as SIP [RFC3261] or WebRTC [I-D.ietf-rtcweb-security-arch]. | ||||
3.10.1. Protocol descriptions | 3.9.1. Protocol Description | |||
SRTP adds confidentiality and optional integrity protection to RTP | MinimalT is a secure transport protocol built on top of a widespread | |||
data packets, and adds confidentially and mandatory integrity | directory service. Clients and servers interact with local directory | |||
protection to RTP control (RTCP) packets. For RTP data packets, this | services to (a) resolve server information and (b) public ephemeral | |||
is done by encrypting the payload section of the packet and | state information, respectively. Clients connect to a local resolver | |||
optionally appending an authentication tag (MAC) as a packet trailer, | once at boot time. Through this resolver they recover the IP | |||
with the RTP header authenticated but not encrypted. The RTP header | address(es) and public key(s) of each server to which they want to | |||
itself is left unencrypted to enable RTP header compression | connect. | |||
[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 | Connections are instances of user-authenticated, mobile sessions | |||
derived from a master key and some additional master salt and session | between two endpoints. Connections run within tunnels between hosts. | |||
salt. SRTP packets carry a 2-byte sequence number to partially | A tunnel is a server-authenticated container that multiplexes | |||
identify the unique packet index. SRTP peers maintain a separate | multiple connections between the same hosts. All connections in a | |||
rollover counter (ROC) for RTP data packets that is incremented | tunnel share the same transport state machine and encryption. Each | |||
whenever the sequence number wraps. The sequence number and ROC | tunnel has a dedicated control connection used to configure and | |||
together determine the packet index. RTCP packets have a similar, | manage the tunnel over time. Moreover, since tunnels are independent | |||
yet differently named, field called the RTCP index which serves the | of the network address information, they may be reused as both ends | |||
same purpose. | 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 | Before a client connects to a remote service, it must first establish | |||
operation, e.g., AES-CTR, the (unique) initialization vector (IV) | a tunnel to the host providing or offering the service. Tunnels are | |||
used for each encryption mode is a function of the RTP SSRC | established in 1-RTT using an ephemeral key obtained from the | |||
(synchronization source), packet index, and session "salting key". | 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 | 3.9.2. Protocol Features | |||
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 | o 0-RTT forward secrecy for new connections. | |||
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.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 | 3.9.3. Protocol Dependencies | |||
but not data packet headers. | ||||
o Optional authentication of data packets; mandatory authentication | o A DNS-like resolution service to obtain location information (an | |||
of control packets. | 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, | 3.10. CurveCP | |||
e.g., DTLS [RFC5763]. | ||||
o External signaling protocol to manage RTP parameters and locate | CurveCP [CurveCP] is a UDP-based transport security protocol from | |||
and identify peers, e.g., SIP [RFC3261] or WebRTC | Daniel J. Bernstein. Unlike other transport security protocols, it | |||
[I-D.ietf-rtcweb-security-arch]. | 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 | There exists a common set of features shared across the transport | |||
protocols surveyed in this document. The mandatory features should | protocols surveyed in this document. Mandatory features constitute a | |||
be provided by any transport security protocol, while the optional | baseline of functionality that an application may assume for any TAPS | |||
features are extensions that a subset of the protocols provide. For | implementation. Optional features by contrast may vary from | |||
clarity, we also distinguish between handshake and record features. | 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. 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 | o Forward-secure key establishment: Negotiated keying material must | |||
must be protected with an authenticated encryption algorithm. | come from an authenticated, forward-secure key exchange protocol. | |||
o Private key interface or injection: Authentication based on public | o Private key interface or injection: Authentication based on public | |||
key signatures is commonplace for many transport security | key signatures is commonplace for many transport security | |||
protocols. | protocols. | |||
o Endpoint authentication: The endpoint (receiver) of a new | o Endpoint authentication: The endpoint (receiver) of a new | |||
connection must be authenticated before any data is sent to said | connection must be authenticated before any data is sent to said | |||
party. | party. | |||
o Source validation: Source validation must be provided to mitigate | o Pre-shared key support: A security protocol must be able to use a | |||
server-targeted DoS attacks. This can be done with puzzles or | pre-shared key established out-of-band or from a prior session to | |||
cookies. | encrypt individual messages, packets, or datagrams. | |||
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. | ||||
4.2. Optional Features | 4.2. Optional Features | |||
4.2.1. Handshake | ||||
o Mutual authentication: Transport security protocols must allow | o Mutual authentication: Transport security protocols must allow | |||
each endpoint to authenticate the other if required by the | each endpoint to authenticate the other if required by the | |||
application. | 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 | o Application-layer feature negotiation: The type of application | |||
using a transport security protocol often requires features | using a transport security protocol often requires features | |||
configured at the connection establishment layer, e.g., ALPN | configured at the connection establishment layer, e.g., ALPN | |||
[RFC7301]. Moreover, application-layer features may often be used | [RFC7301]. Moreover, application-layer features may often be used | |||
to offload the session to another server which can better handle | to offload the session to another server which can better handle | |||
the request. (The TLS SNI is one example of such a feature.) As | the request. (The TLS SNI is one example of such a feature.) As | |||
such, transport security protocols should provide a generic | such, transport security protocols should provide a generic | |||
mechanism to allow for such application-specific features and | mechanism to allow for such application-specific features and | |||
options to be configured or otherwise negotiated. | 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 | o Configuration extensions: The protocol negotiation should be | |||
extensible with addition of new configuration options. | 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 | o Session caching and management: Sessions should be cacheable to | |||
enable reuse and amortize the cost of performing session | enable reuse and amortize the cost of performing session | |||
establishment handshakes. | establishment handshakes. | |||
4.2.2. Record | * Transport dependency: None. | |||
o Connection mobility: Sessions should not be bound to a network | * Application dependency: None. | |||
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. | ||||
5. Transport Security Protocol Interfaces | 5. Transport Security Protocol Interfaces | |||
This section describes the interface surface exposed by the security | This section describes the interface surface exposed by the security | |||
protocols described above, with each interface. Note that not all | protocols described above. Note that not all protocols support each | |||
protocols support each interface. | 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 | Configuration interfaces are used to configure the security protocols | |||
before a handshake begins or the keys are negotiated. | before a handshake begins or the keys are negotiated. | |||
o Identity and Private Keys | o Identity and Private Keys | |||
The application can provide its identities (certificates) and | The application can provide its identities (certificates) and | |||
private keys, or mechanisms to access these, to the security | private keys, or mechanisms to access these, to the security | |||
protocol to use during handshakes. | protocol to use during handshakes. | |||
Protocols: TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2, | Protocols: TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2, | |||
WireGuard, SRTP | WireGuard, SRTP | |||
o Supported Algorithms (Key Exchange, Signatures, and Ciphersuites) | o Supported Algorithms (Key Exchange, Signatures, and Ciphersuites) | |||
The application can choose the algorithms that are supported for | The application can choose the algorithms that are supported for | |||
key exchange, signatures, and ciphersuites. | key exchange, signatures, and ciphersuites. | |||
Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP | Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP | |||
o Session Cache | o Session Cache Management The application provides the ability to | |||
The application provides the ability to save and retrieve session | save and retrieve session state (such as tickets, keying material, | |||
state (such as tickets, keying material, and server parameters) | and server parameters) that may be used to resume the security | |||
that may be used to resume the security session. | session. | |||
Protocols: TLS, DTLS, QUIC + TLS, MinimalT | Protocols: TLS, DTLS, QUIC + TLS, MinimalT | |||
o Authentication Delegation | o Authentication Delegation | |||
The application provides access to a separate module that will | The application provides access to a separate module that will | |||
provide authentication, using EAP for example. | provide authentication, using EAP for example. | |||
Protocols: IKEv2, SRTP | 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 | * Explict import: QUIC, ESP | |||
handshake protocol and the application, record protocol, and | ||||
transport once the handshake is active. | ||||
o Send Handshake Messages | * Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard | |||
The handshake protocol needs to be able to send messages over a | * Non-importable: CurveCP | |||
transport to the remote peer to establish trust and to negotiate | ||||
keys. | ||||
Protocols: All (TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2, | ||||
WireGuard, SRTP (DTLS)) | ||||
o Receive Handshake Messages | 5.2. Connection Interfaces | |||
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)) | ||||
o Identity Validation | o Identity Validation | |||
During a handshake, the security protocol will conduct identity | During a handshake, the security protocol will conduct identity | |||
validation of the peer. This can call into the application to | validation of the peer. This can call into the application to | |||
offload validation. Protocols: All (TLS, DTLS, QUIC + TLS, | offload validation. Protocols: All (TLS, DTLS, QUIC + TLS, | |||
MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS)) | MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS)) | |||
o Source Address Validation | o Source Address Validation | |||
The handshake protocol may delegate validation of the remote peer | The handshake protocol may delegate validation of the remote peer | |||
that has sent data to the transport protocol or application. This | that has sent data to the transport protocol or application. This | |||
involves sending a cookie exchange to avoid DoS attacks. | involves sending a cookie exchange to avoid DoS attacks. | |||
Protocols: QUIC + TLS, DTLS, WireGuard | 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 | o Key Update | |||
The handshake protocol may be instructed to update its keying | The handshake protocol may be instructed to update its keying | |||
material, either by the application directly or by the record | material, either by the application directly or by the record | |||
protocol sending a key expiration event. | protocol sending a key expiration event. | |||
Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2 | Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2 | |||
o Pre-Shared Key Export | o Pre-Shared Key Export The handshake protocol will generate one or | |||
The handshake protocol will generate one or more keys to be used | more keys to be used for record encryption/decryption and | |||
for record encryption/decryption and authentication. These may be | authentication. These may be explicitly exportable to the | |||
explicitly exportable to the application, traditionally limited to | application, traditionally limited to direct export to the record | |||
direct export to the record protocol, or inherently non-exportable | protocol, or inherently non-exportable because the keys must be | |||
because the keys must be used directly in conjunction with the | used directly in conjunction with the record protocol. | |||
record protocol. | ||||
* Explict export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for | * Explict export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for | |||
SRTP) | SRTP) | |||
* Direct export: TLS, DTLS, MinimalT | * Direct export: TLS, DTLS, MinimalT | |||
* Non-exportable: CurveCP | * 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 | o Key Expiration | |||
The record protocol can signal that its keys are expiring due to | The record protocol can signal that its keys are expiring due to | |||
reaching a time-based deadline, or a use-based deadline (number of | reaching a time-based deadline, or a use-based deadline (number of | |||
bytes that have been encrypted with the key). This interaction is | bytes that have been encrypted with the key). This interaction is | |||
often limited to signaling between the record layer and the | often limited to signaling between the record layer and the | |||
handshake layer. | handshake layer. | |||
Protocols: ESP ((Editor's note: One may consider TLS/DTLS to also | Protocols: ESP ((Editor's note: One may consider TLS/DTLS to also | |||
have this interface)) | have this interface)) | |||
o Transport mobility | o Transport mobility | |||
skipping to change at page 25, line 32 ¶ | skipping to change at page 25, line 42 ¶ | |||
[BLAKE2] "BLAKE2 -- simpler, smaller, fast as MD5", n.d.. | [BLAKE2] "BLAKE2 -- simpler, smaller, fast as MD5", n.d.. | |||
[Curve25519] | [Curve25519] | |||
"Curve25519 - new Diffie-Hellman speed records", n.d.. | "Curve25519 - new Diffie-Hellman speed records", n.d.. | |||
[CurveCP] "CurveCP -- Usable security for the Internet", n.d.. | [CurveCP] "CurveCP -- Usable security for the Internet", n.d.. | |||
[I-D.ietf-quic-tls] | [I-D.ietf-quic-tls] | |||
Thomson, M. and S. Turner, "Using Transport Layer Security | Thomson, M. and S. Turner, "Using Transport Layer Security | |||
(TLS) to Secure QUIC", draft-ietf-quic-tls-10 (work in | (TLS) to Secure QUIC", draft-ietf-quic-tls-11 (work in | |||
progress), March 2018. | progress), April 2018. | |||
[I-D.ietf-quic-transport] | [I-D.ietf-quic-transport] | |||
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed | Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed | |||
and Secure Transport", draft-ietf-quic-transport-10 (work | and Secure Transport", draft-ietf-quic-transport-11 (work | |||
in progress), March 2018. | in progress), April 2018. | |||
[I-D.ietf-rtcweb-security-arch] | [I-D.ietf-rtcweb-security-arch] | |||
Rescorla, E., "WebRTC Security Architecture", draft-ietf- | Rescorla, E., "WebRTC Security Architecture", draft-ietf- | |||
rtcweb-security-arch-14 (work in progress), March 2018. | rtcweb-security-arch-14 (work in progress), March 2018. | |||
[I-D.ietf-tcpinc-tcpcrypt] | [I-D.ietf-tcpinc-tcpcrypt] | |||
Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, | Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, | |||
Q., and E. Smith, "Cryptographic protection of TCP Streams | Q., and E. Smith, "Cryptographic protection of TCP Streams | |||
(tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-11 (work in | (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-11 (work in | |||
progress), November 2017. | progress), November 2017. | |||
End of changes. 64 change blocks. | ||||
446 lines changed or deleted | 429 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |