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/