draft-ietf-taps-transport-security-03.txt   draft-ietf-taps-transport-security-04.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: April 25, 2019 University of Glasgow Expires: May 9, 2019 University of Glasgow
K. Rose K. Rose
Akamai Technologies, Inc. Akamai Technologies, Inc.
C. Wood C. Wood
Apple Inc. Apple Inc.
October 22, 2018 November 05, 2018
A Survey of Transport Security Protocols A Survey of Transport Security Protocols
draft-ietf-taps-transport-security-03 draft-ietf-taps-transport-security-04
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 39 skipping to change at page 1, line 39
superset of features a TAPS system may need to support. superset of features a TAPS system may need to support.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 April 25, 2019. This Internet-Draft will expire on May 9, 2019.
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 (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 34 skipping to change at page 2, line 34
3. Security Features . . . . . . . . . . . . . . . . . . . . . . 5 3. Security Features . . . . . . . . . . . . . . . . . . . . . . 5
4. Transport Security Protocol Descriptions . . . . . . . . . . 7 4. Transport Security Protocol Descriptions . . . . . . . . . . 7
4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Protocol Description . . . . . . . . . . . . . . . . 7 4.1.1. Protocol Description . . . . . . . . . . . . . . . . 7
4.1.2. Security Features . . . . . . . . . . . . . . . . . . 8 4.1.2. Security Features . . . . . . . . . . . . . . . . . . 8
4.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 9 4.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 9
4.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Protocol Description . . . . . . . . . . . . . . . . 9 4.2.1. Protocol Description . . . . . . . . . . . . . . . . 9
4.2.2. Security Features . . . . . . . . . . . . . . . . . . 10 4.2.2. Security Features . . . . . . . . . . . . . . . . . . 10
4.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10 4.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10
4.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 11 4.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 10
4.3.1. Protocol Description . . . . . . . . . . . . . . . . 11 4.3.1. Protocol Description . . . . . . . . . . . . . . . . 11
4.3.2. Security Features . . . . . . . . . . . . . . . . . . 11 4.3.2. Security Features . . . . . . . . . . . . . . . . . . 11
4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 12 4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 11
4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 12 4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 11
4.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 12 4.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 12
4.4.1. Protocol descriptions . . . . . . . . . . . . . . . . 12 4.4.1. Protocol descriptions . . . . . . . . . . . . . . . . 12
4.4.2. Security Features . . . . . . . . . . . . . . . . . . 14 4.4.2. Security Features . . . . . . . . . . . . . . . . . . 13
4.4.3. Protocol Dependencies . . . . . . . . . . . . . . . . 14 4.4.3. Protocol Dependencies . . . . . . . . . . . . . . . . 14
4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 15 4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 14
4.5.1. Protocol description . . . . . . . . . . . . . . . . 15 4.5.1. Protocol description . . . . . . . . . . . . . . . . 14
4.5.2. Security Features . . . . . . . . . . . . . . . . . . 16 4.5.2. Security Features . . . . . . . . . . . . . . . . . . 15
4.5.3. Protocol Dependencies . . . . . . . . . . . . . . . . 16 4.5.3. Protocol Dependencies . . . . . . . . . . . . . . . . 16
4.5.4. Variant: ZRTP for Media Path Key Agreement . . . . . 16 4.5.4. Variant: ZRTP for Media Path Key Agreement . . . . . 16
4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 17 4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 16
4.6.1. Protocol Description . . . . . . . . . . . . . . . . 17 4.6.1. Protocol Description . . . . . . . . . . . . . . . . 16
4.6.2. Security Features . . . . . . . . . . . . . . . . . . 18 4.6.2. Security Features . . . . . . . . . . . . . . . . . . 17
4.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 18 4.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 18
4.7. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 18 4.7. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 18
4.7.1. Protocol description . . . . . . . . . . . . . . . . 18 4.7.1. Protocol description . . . . . . . . . . . . . . . . 18
4.7.2. Security Features . . . . . . . . . . . . . . . . . . 19 4.7.2. Security Features . . . . . . . . . . . . . . . . . . 19
4.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 19 4.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 19
4.8. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 20 4.8. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 19
4.8.1. Protocol Description . . . . . . . . . . . . . . . . 20 4.8.1. Protocol Description . . . . . . . . . . . . . . . . 19
4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 20 4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 20
4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 21 4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 20
4.9. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.9. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.9.1. Protocol Description . . . . . . . . . . . . . . . . 21 4.9.1. Protocol Description . . . . . . . . . . . . . . . . 20
4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 22 4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 22
4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 22 4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 22
5. Security Features and Transport Dependencies . . . . . . . . 23 5. Security Features and Transport Dependencies . . . . . . . . 22
5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 23 5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 22
5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 23 5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 23
5.3. Optional Feature Availability . . . . . . . . . . . . . . 25 5.3. Optional Feature Availability . . . . . . . . . . . . . . 24
6. Transport Security Protocol Interfaces . . . . . . . . . . . 26 6. Transport Security Protocol Interfaces . . . . . . . . . . . 26
6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 26 6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 26
6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 27 6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 27
6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 27 6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 27
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28
10. Normative References . . . . . . . . . . . . . . . . . . . . 28 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
11. Normative References . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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
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
skipping to change at page 5, line 4 skipping to change at page 5, line 5
format on the wire. A Transport Protocol services an application. format on the wire. A Transport Protocol services an application.
o Application: an entity that uses a transport protocol for end-to- o Application: an entity that uses a transport protocol for end-to-
end delivery of data across the network. This may also be an end delivery of data across the network. This may also be an
upper layer protocol or tunnel encapsulation. upper layer protocol or tunnel encapsulation.
o Security Feature: a feature that a network security layer provides o Security Feature: a feature that a network security layer provides
to applications. Examples include authentication, encryption, key to applications. Examples include authentication, encryption, key
generation, session resumption, and privacy. Features may be generation, session resumption, and privacy. Features may be
Mandatory or Optional for an application's implementation. Mandatory or Optional for an application's implementation.
Security Features extend the set of Transport Features described
in [RFC8095] and provided by Transport Services implementations.
o Security Protocol: a defined network protocol that implements one o Security Protocol: a defined network protocol that implements one
or more security features. Security protocols may be used or more security features. Security protocols may be used
alongside transport protocols, and in combination with other alongside transport protocols, and in combination with other
security protocols when appropriate. security protocols when appropriate.
o Handshake Protocol: a protocol that enables peers to validate each o Handshake Protocol: a protocol that enables peers to validate each
other and to securely establish shared cryptographic context. other and to securely establish shared cryptographic context.
o Record: Framed protocol messages. o Record: Framed protocol messages.
skipping to change at page 5, line 31 skipping to change at page 5, line 34
o Cryptographic context: a set of cryptographic parameters, o Cryptographic context: a set of cryptographic parameters,
including but not necessarily limited to keys for encryption, including but not necessarily limited to keys for encryption,
authentication, and session resumption, enabling authorized authentication, and session resumption, enabling authorized
parties to a session to communicate securely. parties to a session to communicate securely.
o Connection: the shared state of two or more endpoints that o Connection: the shared state of two or more endpoints that
persists across messages that are transmitted between these persists across messages that are transmitted between these
endpoints. A connection is a transient participant of a session, endpoints. A connection is a transient participant of a session,
and a session generally lasts between connection instances. and a session generally lasts between connection instances.
o Connection Mobility: a property of a connection that allows it to
be multihomed or resilient across network interface or address
changes, e.g., NAT rebindings that occur without an endpoint's
knowledge. Mobility allows cryptographic key material and other
state information to be reused in the event of a connection
change.
o Peer: an endpoint application party to a session. o Peer: an endpoint application party to a session.
o Client: the peer responsible for initiating a session. o Client: the peer responsible for initiating a session.
o Server: the peer responsible for responding to a session o Server: the peer responsible for responding to a session
initiation. initiation.
3. Security Features 3. Security Features
In this section, we enumerate Security Features exposed by protocols In this section, we enumerate Security Features exposed by protocols
discussed in the remainder of this document. Security Features discussed in the remainder of this document. Protocol security (and
extend the set of Transport Features described in [RFC8095] and privacy) properties that are unrelated to the API surface exposed by
provided by Transport Services implementations. Protocol security such protocols, such as client or server identity hiding, are not
properties that are unrelated to the API surface exposed by such listed here as features.
protocols, such as client or server identity hiding, are not listed
here as features.
o Forward-secure key establishment: Cryptographic key establishment o Forward-secure key establishment: Cryptographic key establishment
with forward secure properties. with forward secure properties.
o Cryptographic algorithm negotiation: Negotiate support of protocol o Cryptographic algorithm negotiation: Negotiate support of protocol
algorithms, including: encryption, hash, MAC (PRF), and digital algorithms, including: encryption, hash, MAC (PRF), and digital
signature algorithms. signature algorithms.
o Stateful and stateless cross-connection session resumption:
Connection establishment without needing to complete an entirely
new handshake.
o Session caching and management: Manage session state cache used o Session caching and management: Manage session state cache used
for subsequent connections aimed towards amortizing connection for subsequent connections aimed towards amortizing connection
establishment costs. establishment costs.
o Peer authentication (certificate, raw public key, pre-shared key, o Peer authentication (certificate, raw public key, pre-shared key,
or EAP-based): Peer authentication using select or protocol- or EAP-based): Peer authentication using select or protocol-
specific mechanisms. specific mechanisms.
o Mutual authentication: Connection establishment wherein both o Mutual authentication: Connection establishment wherein both
endpoints are authenticated. endpoints are authenticated.
skipping to change at page 6, line 49 skipping to change at page 6, line 40
o Optional record integrity: Optional authentication of certain o Optional record integrity: Optional authentication of certain
records. records.
o Record replay prevention: Protocol detection and defense against o Record replay prevention: Protocol detection and defense against
record replays, e.g., due to in-network retransmissions. record replays, e.g., due to in-network retransmissions.
o Early data support (starting with TLS 1.3): Transmission of o Early data support (starting with TLS 1.3): Transmission of
application data prior to connection (handshake) establishment. application data prior to connection (handshake) establishment.
o Connection mobility: Connection continuation in the presence of o Connection mobility: a property of a connection that allows it to
5-tuple changes beneath the secure transport protocol, e.g., due be multihomed or resilient across network interface or address
to NAT rebindings. changes, e.g., NAT rebindings that occur without an endpoint's
knowledge. Mobility allows cryptographic key material and other
state information to be reused in the event of a connection
change.
o Application-layer feature negotiation: Securely negotiate o Application-layer feature negotiation: Securely negotiate
application-specific functionality, including those necessary for application-specific functionality, including those necessary for
connection handling and management, e.g., the TLS parent connection handling and management, e.g., the TLS parent
connection protocol type via ALPN [RFC7301] or desired application connection protocol type via ALPN [RFC7301] or desired application
identity via SNI [RFC6066]. identity via SNI [RFC6066].
o Configuration extensions: Add protocol features via extensions or o Configuration extensions: Add protocol features via extensions or
configuration options. TLS extensions are a primary example of configuration options. TLS extensions are a primary example of
this feature. this feature.
o Out-of-order record receipt: Processing of records received out- o Out-of-order record receipt: Processing of records received out-
of-order. of-order.
o Source validation (cookie or puzzle based): Peer source validation o Source validation (cookie or puzzle based): Peer source validation
and DoS mitigation via explicit proof of origin (cookie) or work and DoS mitigation via explicit proof of origin (cookie) or work
mechanisms (puzzles). mechanisms (puzzles).
o Connection re-keying: In-band cryptographic handshake re-keying.
o Length-hiding padding: Protocol-drive record padding aimed at o Length-hiding padding: Protocol-drive record padding aimed at
hiding plaintext message length and mitigating amplification hiding plaintext message length and mitigating amplification
attack vectors. attack vectors.
4. Transport Security Protocol Descriptions 4. Transport Security Protocol Descriptions
This section contains descriptions of security protocols currently This section contains descriptions of security protocols currently
used to protect data being sent over a network. used to protect data being sent over a network.
For each protocol, we describe its provided features and dependencies For each protocol, we describe its provided features and dependencies
skipping to change at page 18, line 23 skipping to change at page 17, line 50
4.6.2. Security Features 4.6.2. Security Features
o Forward-secure key establishment. o Forward-secure key establishment.
o Record (channel) confidentiality and integrity. o Record (channel) confidentiality and integrity.
o Stateful cross-connection session resumption. o Stateful cross-connection session resumption.
o Session caching and management. o Session caching and management.
o Connection re-keying.
o Application authentication delegation. o Application authentication delegation.
4.6.3. Protocol Dependencies 4.6.3. Protocol Dependencies
o TCP. o TCP.
o TCP Encryption Negotiation Option (ENO). o TCP Encryption Negotiation Option (ENO).
4.7. WireGuard 4.7. WireGuard
skipping to change at page 20, line 33 skipping to change at page 20, line 7
Connections are instances of user-authenticated, mobile sessions Connections are instances of user-authenticated, mobile sessions
between two endpoints. Connections run within tunnels between hosts. between two endpoints. Connections run within tunnels between hosts.
A tunnel is a server-authenticated container that multiplexes A tunnel is a server-authenticated container that multiplexes
multiple connections between the same hosts. All connections in a multiple connections between the same hosts. All connections in a
tunnel share the same transport state machine and encryption. Each tunnel share the same transport state machine and encryption. Each
tunnel has a dedicated control connection used to configure and tunnel has a dedicated control connection used to configure and
manage the tunnel over time. Moreover, since tunnels are independent manage the tunnel over time. Moreover, since tunnels are independent
of the network address information, they may be reused as both ends of the network address information, they may be reused as both ends
of the tunnel move about the network. This does however imply that of the tunnel move about the network. This does however imply that
the connection establishment and packet encryption mechanisms are connection establishment and packet encryption mechanisms are
coupled. coupled.
Before a client connects to a remote service, it must first establish Before a client connects to a remote service, it must first establish
a tunnel to the host providing or offering the service. Tunnels are a tunnel to the host providing or offering the service. Tunnels are
established in 1-RTT using an ephemeral key obtained from the established in 1-RTT using an ephemeral key obtained from the
directory service. Tunnel initiators provide their own ephemeral key directory service. Tunnel initiators provide their own ephemeral key
and, optionally, a DoS puzzle solution such that the recipient and, optionally, a DoS puzzle solution such that the recipient
(server) can verify the authenticity of the request and derive a (server) can verify the authenticity of the request and derive a
shared secret. Within a tunnel, new connections to services may be shared secret. Within a tunnel, new connections to services may be
established. established.
skipping to change at page 21, line 46 skipping to change at page 21, line 20
under the server's long-term public key. The server replies with a 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 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 by the client. Upon receipt, the client then generates its second
initialization packet carrying: the ephemeral key C', cookie, and an initialization packet carrying: the ephemeral key C', cookie, and an
encryption of C', the server's domain name, and, optionally, some encryption of C', the server's domain name, and, optionally, some
message data. The server verifies the cookie and the encrypted message data. The server verifies the cookie and the encrypted
payload and, if valid, proceeds to send data in return. At this payload and, if valid, proceeds to send data in return. At this
point, the connection is established and the two parties can point, the connection is established and the two parties can
communicate. communicate.
The use of only public-key encryption and authentication, or The use of public-key encryption and authentication, or "boxing", is
"boxing", is done to simplify problems that come with symmetric key done to simplify problems that come with symmetric key management and
management and synchronization. For example, it allows the sender of synchronization. For example, it allows the sender of a message to
a message to be in complete control of each message's nonce. It does be in complete control of each message's nonce. It does not require
not require either end to share secret keying material. Furthermore, either end to share secret keying material. Furthermore, it allows
it allows connections (or sessions) to be associated with unique connections (or sessions) to be associated with unique ephemeral
ephemeral public keys as a mechanism for enabling forward secrecy public keys as a mechanism for enabling forward secrecy given the
given the risk of long-term private key compromise. risk of long-term private key compromise.
The client and server do not perform a standard key exchange. The client and server do not perform a standard key exchange.
Instead, in the initial exchange of packets, each party provides its Instead, in the initial exchange of packets, each party provides its
own ephemeral key to the other end. The client can choose a new own ephemeral key to the other end. The client can choose a new
ephemeral key for every new connection. However, the server must ephemeral key for every new connection. However, the server must
rotate these keys on a slower basis. Otherwise, it would be trivial rotate these keys on a slower basis. Otherwise, it would be trivial
for an attacker to force the server to create and store ephemeral for an attacker to force the server to create and store ephemeral
keys with a fake client initialization packet. keys with a fake client initialization packet.
Servers use cookies for source validation. After receiving a Servers use cookies for source validation. After receiving a
skipping to change at page 23, line 12 skipping to change at page 22, line 30
o An unreliable transport protocol such as UDP. o An unreliable transport protocol such as UDP.
5. Security Features and Transport Dependencies 5. 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. Mandatory features constitute a protocols surveyed in this document. Mandatory features constitute a
baseline of functionality that an application may assume for any TAPS baseline of functionality that an application may assume for any TAPS
implementation. They were selected on the basis that they are either implementation. They were selected on the basis that they are either
(a) required for any secure transport protocol or (b) nearly (a) required for any secure transport protocol or (b) nearly
ubiquitous amongst common secure transport protocols. Optional ubiquitous amongst common secure transport protocols.
features by contrast may vary from implementation to implementation,
and so an application cannot simply assume they are available. Optional features by contrast may vary from implementation to
Applications learn of and use optional features by querying for their implementation, and so an application cannot simply assume they are
presence and support. Optional features may not be implemented, or available. Applications learn of and use optional features by
may be disabled if their presence impacts transport services or if a querying for their presence and support. Optional features may not
necessary transport service is unavailable. be implemented, or may be disabled if their presence impacts
transport services or if a necessary transport service or application
dependency is unavailable. In this context, an application
dependency is one required from an application in order to function.
5.1. Mandatory Features 5.1. Mandatory Features
o Segment or datagram encryption and authentication: Protect transit Mandatory features must be supported regardless of transport and
data with an authenticated encryption algorithm. application services available.
o Record or datagram confidentiality and integrity.
o Forward-secure key establishment. o Forward-secure key establishment.
o Public-key (raw or certificate) based authentication. o Public-key certificate based authentication.
o Unilateral responder authentication. o Unilateral responder authentication.
o Pre-shared key support. Note that most systems provide defailt trust stores used to
authenticate peers based on certificates. In such systems,
applications need not provide any trust information. Applications
running on systems without such a feature must necessary depend on
applications for this information so as to authenticate peers.
5.2. Optional Features 5.2. Optional Features
o Cryptographic algorithm negotiation (AN): In this section we list optional features along with their necessary
application dependencies, if any.
* Transport dependency: None. o Pre-shared key support (PSK):
* Application dependency: Application provisioning and
distribution of pre-shared keys.
o Cryptographic algorithm negotiation (AN):
* Application dependency: Application awareness of supported or * Application dependency: Application awareness of supported or
desired algorithms. desired algorithms.
o Application authentication delegation (AD): o Application authentication delegation (AD):
* Transport dependency: None.
* Application dependency: Application opt-in and policy for * Application dependency: Application opt-in and policy for
endpoint authentication endpoint authentication.
o Mutual authentication (MA): o Mutual authentication (MA):
* Transport dependency: None. * Application dependency: Mutual authentication credentials
required for application support.
* Application dependency: Mutual authentication required for
application support.
o DoS mitigation (DM): o DoS mitigation (DM):
* Transport dependency: None.
* Application dependency: None. * Application dependency: None.
o Connection mobility (CM): o Connection mobility (CM):
* Transport dependency: Connections are unreliable or can change
due to unpredictable network events, e.g., NAT re-bindings.
* Application dependency: None. * Application dependency: None.
o Source validation (SV): o Source validation (SV):
* Transport dependency: Packets may arrive as datagrams instead
of streams from unauthenticated sources.
* Application dependency: None. * Application dependency: None.
o Application-layer feature negotiation (AFN): o Application-layer feature negotiation (AFN):
* Transport dependency: None.
* Application dependency: Specification of application-layer * Application dependency: Specification of application-layer
features or functionality. features or functionality.
o Configuration extensions (CX): o Configuration extensions (CX):
* Transport dependency: None.
* Application dependency: Specification of application-specific * Application dependency: Specification of application-specific
extensions. extensions.
o Session caching and management (SC): o Session caching and management (SC):
* Transport dependency: None.
* Application dependency: None. * Application dependency: None.
o Early data support (ED): o Length-hiding padding (LHP):
* Transport dependency: None. * Application dependency: Knowledge of desired padding policies.
o Early data support (ED):
* Application dependency: Anti-replay protections or hints of * Application dependency: Anti-replay protections or hints of
data idempotency. data idempotency.
o Length-hiding padding (LHP): o Record replay prevention (RP):
* Transport dependency: None. * Application dependency: None.
* Application dependency: Knowledge of desired padding policies. o Out-of-order receipt record (OO):
* Application dependency: None.
5.3. Optional Feature Availability 5.3. Optional Feature Availability
The following table lists the availability of the above-listed The following table lists the availability of the above-listed
optional features in each of the analyzed protocols. "Mandatory" optional features in each of the analyzed protocols. "Mandatory"
indicates that the feature is intrinsic to the protocol and cannot be indicates that the feature is intrinsic to the protocol and cannot be
disabled. "Supported" indicates that the feature is optionally disabled. "Supported" indicates that the feature is optionally
provided natively or through a (standardized, where applicable) provided natively or through a (standardized, where applicable)
extension. extension.
+----------+---+----+----+-----+----+----+-----+----+----+-----+----+ +-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+
| Protocol | A | AD | MA | DM | CM | SV | AFN | CX | SC | LHP | ED | | Pro | P | A | A | M | D | C | S | A | CX | SC | LH | ED | RP | OO |
| | N | | | | | | | | | | | | toc | S | N | D | A | M | M | V | F | | | P | | | |
+----------+---+----+----+-----+----+----+-----+----+----+-----+----+ | ol | K | | | | | | | N | | | | | | |
| TLS | S | S | S | S | U* | M | S | S | S | S | S | +-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+
| | | | | | | | | | | | | | TLS | S | S | S | S | S | U | M | S | S | S | S | S | U | U |
| DTLS | S | S | S | S | S | M | S | S | S | S | U | | | | | | | | * | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| IETF | S | S | S | S | S | M | S | S | S | S | S | | DTL | S | S | S | S | S | S | M | S | S | S | S | U | M | M |
| QUIC | | | | | | | | | | | | | S | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| IKEv2+ES | S | S | M | S | S | M | S | S | S | S | U | | IET | S | S | S | S | S | S | M | S | S | S | S | S | M | M |
| P | | | | | | | | | | | | | F Q | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | UIC | | | | | | | | | | | | | | |
| SRTP+DTL | S | S | S | S | U | M | S | S | S | U | U | | | | | | | | | | | | | | | | |
| S | | | | | | | | | | | | | IKE | S | S | S | M | S | S | M | S | S | S | S | U | M | M |
| | | | | | | | | | | | | | v2+ | | | | | | | | | | | | | | |
| tcpcrypt | S | M | U | U** | U* | M | U | U | S | U | U | | ESP | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| WireGuar | U | S | M | S | U | M | U | U | U | S+ | U | | SRT | S | S | S | S | S | U | M | S | S | S | U | U | M | M |
| d | | | | | | | | | | | | | P+D | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | TLS | | | | | | | | | | | | | | |
| MinimalT | U | U | M | S | M | M | U | U | U | S | U | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | tcp | U | S | M | U | U | U | M | U | U | S | U | U | U | U |
| CurveCP | U | U | S | S | M | M | U | U | U | S | U | | cry | | | | | * | * | | | | | | | | |
+----------+---+----+----+-----+----+----+-----+----+----+-----+----+ | pt | | | | | * | | | | | | | | | |
| | | | | | | | | | | | | | | |
| Wir | S | U | S | M | S | U | M | U | U | U | S+ | U | M | M |
| eGu | | | | | | | | | | | | | | |
| ard | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| Min | U | U | U | M | S | M | M | U | U | U | S | U | U | U |
| ima | | | | | | | | | | | | | | |
| lT | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| Cur | U | U | U | S | S | M | M | U | U | U | S | U | M | M |
| veC | | | | | | | | | | | | | | |
| P | | | | | | | | | | | | | | |
+-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+
M=Mandatory S=Supported but not required U=Unsupported *=On TCP; M=Mandatory S=Supported but not required U=Unsupported *=On TCP;
MPTCP would provide this ability **=TCP provides SYN cookies MPTCP would provide this ability **=TCP provides SYN cookies
natively, but these are not cryptographically strong +=For transport natively, but these are not cryptographically strong +=For transport
packets only packets only
6. Transport Security Protocol Interfaces 6. 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. Note that not all protocols support each protocols described above. Note that not all protocols support each
interface. We partition these interfaces into pre-connection interface. We partition these interfaces into pre-connection
(configuration), connection, and post-connection interfaces, (configuration), connection, and post-connection interfaces,
following conventions in [I-D.ietf-taps-interface] and following conventions in [I-D.ietf-taps-interface] and
[I-D.ietf-taps-arch]. [I-D.ietf-taps-arch].
6.1. Pre-Connection Interfaces 6.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 The application can provide its o Identities and Private Keys The application can provide its
identities (certificates) and private keys, or mechanisms to identities (certificates) and private keys, or mechanisms to
access these, to the security protocol to use during handshakes. access these, to the security 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. Protocols: TLS, DTLS, key exchange, signatures, and ciphersuites. Protocols: TLS, DTLS,
QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP
o Extensions (Application-Layer Protocol Negotiation): The
application enables or configures extensions that are to be
negotiated by the security protocol, such as ALPN [RFC7301].
Protocols: TLS, DTLS, QUIC + TLS
o Session Cache Management The application provides the ability to o Session Cache Management The application provides the ability to
save and retrieve session state (such as tickets, keying material, save and retrieve session state (such as tickets, keying material,
and server parameters) that may be used to resume the security and server parameters) that may be used to resume the security
session. Protocols: TLS, DTLS, QUIC + TLS, MinimalT session. Protocols: TLS, DTLS, QUIC + TLS, MinimalT
o Authentication Delegation The application provides access to a o Authentication Delegation The application provides access to a
separate module that will provide authentication, using EAP for separate module that will provide authentication, using EAP for
example. Protocols: IKEv2, SRTP example. Protocols: IKEv2, SRTP
o Pre-Shared Key Import Either the handshake protocol or the o Pre-Shared Key Import Either the handshake protocol or the
skipping to change at page 27, line 23 skipping to change at page 27, line 25
o Source Address Validation The handshake protocol may delegate o Source Address Validation The handshake protocol may delegate
validation of the remote peer that has sent data to the transport validation of the remote peer that has sent data to the transport
protocol or application. This involves sending a cookie exchange protocol or application. This involves sending a cookie exchange
to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard
6.3. Post-Connection Interfaces 6.3. Post-Connection Interfaces
o Connection Termination The security protocol may be instructed to o Connection Termination The security protocol may be instructed to
tear down its connection and session information. This is needed tear down its connection and session information. This is needed
by some protocols to prevent application data truncation attacks. by some protocols to prevent application data truncation attacks.
Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2 Protocols: TLS, DTLS, QUIC, MinimalT, tcpcrypt, IKEv2
o Key Update The handshake protocol may be instructed to update its o Key Update The handshake protocol may be instructed to update its
keying material, either by the application directly or by the keying material, either by the application directly or by the
record protocol sending a key expiration event. Protocols: TLS, record protocol sending a key expiration event. Protocols: TLS,
DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2 DTLS, QUIC, MinimalT, tcpcrypt, IKEv2
o Pre-Shared Key Export The handshake protocol will generate one or o Pre-Shared Key Export The handshake protocol will generate one or
more keys to be used for record encryption/decryption and more keys to be used for record encryption/decryption and
authentication. These may be explicitly exportable to the authentication. These may be explicitly exportable to the
application, traditionally limited to direct export to the record application, traditionally limited to direct export to the record
protocol, or inherently non-exportable because the keys must be protocol, or inherently non-exportable because the keys must be
used directly in conjunction with the record protocol. used directly in conjunction with the record protocol.
* Explicit export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for * Explicit export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for
SRTP) SRTP)
skipping to change at page 28, line 5 skipping to change at page 28, line 5
* Non-exportable: CurveCP * Non-exportable: CurveCP
o Key Expiration The record protocol can signal that its keys are o Key Expiration The record protocol can signal that its keys are
expiring due to reaching a time-based deadline, or a use-based expiring due to reaching a time-based deadline, or a use-based
deadline (number of bytes that have been encrypted with the key). deadline (number of bytes that have been encrypted with the key).
This interaction is often limited to signaling between the record This interaction is often limited to signaling between the record
layer and the handshake layer. Protocols: ESP ((Editor's note: layer and the handshake layer. Protocols: ESP ((Editor's note:
One may consider TLS/DTLS to also have this interface)) One may consider TLS/DTLS to also have this interface))
o Connection mobility The record protocol can be signaled that it is o Mobility Events The record protocol can be signaled that it is
being migrated to another transport or interface due to connection being migrated to another transport or interface due to connection
mobility, which may reset address and state validation. mobility, which may reset address and state validation and induce
state changes such as use of a new Connection Identifier (CID).
Protocols: QUIC, MinimalT, CurveCP, ESP, WireGuard (roaming) Protocols: QUIC, MinimalT, CurveCP, ESP, WireGuard (roaming)
7. IANA Considerations 7. IANA Considerations
This document has no request to IANA. This document has no request to IANA.
8. Security Considerations 8. Security Considerations
This document summarizes existing transport security protocols and This document summarizes existing transport security protocols and
their interfaces. It does not propose changes to or recommend usage their interfaces. It does not propose changes to or recommend usage
of reference protocols. Moreover, no claims of security and privacy of reference protocols. Moreover, no claims of security and privacy
properties beyond those guaranteed by the protocols discussed are properties beyond those guaranteed by the protocols discussed are
made. For example, metadata leakage via timing side channels and made. For example, metadata leakage via timing side channels and
traffic analysis may compromise any protocol discussed in this traffic analysis may compromise any protocol discussed in this
survey. Applications using Security Interfaces SHOULD take such survey. Applications using Security Interfaces SHOULD take such
limitations into consideration when using a particular protocol limitations into consideration when using a particular protocol
implementation. implementation.
9. Acknowledgments 9. Privacy Considerations
The authors would like to thank Mirja Kuehlewind, Brian Trammell, Analysis of how features improve or degrade privacy is intentionally
Yannick Sierra, Frederic Jacobs, and Bob Bradley for their input and omitted from this survey. All security protocols surveyed generally
feedback on earlier versions of this draft. improve privacy by reducing information leakage via encryption.
However, varying amounts of metadata remain in the clear across each
protocol. For example, client and server certificates are sent in
cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3
[RFC8446]. A survey of privacy features, or lack thereof, for
various security protocols could be addressed in a separate document.
10. Normative References 10. Acknowledgments
The authors would like to thank Bob Bradley, Theresa Enghardt,
Frederic Jacobs, Mirja Kuehlewind, Yannick Sierra, and Brian Trammell
for their input and feedback on earlier versions of this draft.
11. Normative References
[ALTS] "Application Layer Transport Security", n.d.. [ALTS] "Application Layer Transport Security", n.d..
[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-15 (work in (TLS) to Secure QUIC", draft-ietf-quic-tls-16 (work in
progress), October 2018. progress), October 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-15 (work and Secure Transport", draft-ietf-quic-transport-16 (work
in progress), October 2018. in progress), October 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-15 (work in progress), July 2018. rtcweb-security-arch-16 (work in progress), October 2018.
[I-D.ietf-taps-arch] [I-D.ietf-taps-arch]
Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G.,
Perkins, C., Tiesel, P., and C. Wood, "An Architecture for Perkins, C., Tiesel, P., and C. Wood, "An Architecture for
Transport Services", draft-ietf-taps-arch-02 (work in Transport Services", draft-ietf-taps-arch-02 (work in
progress), October 2018. progress), October 2018.
[I-D.ietf-taps-interface] [I-D.ietf-taps-interface]
Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G.,
Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An
Abstract Application Layer Interface to Transport Abstract Application Layer Interface to Transport
Services", draft-ietf-taps-interface-02 (work in Services", draft-ietf-taps-interface-02 (work in
progress), October 2018. progress), October 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-13 (work in (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-14 (work in
progress), September 2018. progress), November 2018.
[I-D.ietf-tcpinc-tcpeno] [I-D.ietf-tcpinc-tcpeno]
Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E.
Smith, "TCP-ENO: Encryption Negotiation Option", draft- Smith, "TCP-ENO: Encryption Negotiation Option", draft-
ietf-tcpinc-tcpeno-19 (work in progress), June 2018. ietf-tcpinc-tcpeno-19 (work in progress), June 2018.
[I-D.ietf-tls-dtls-connection-id] [I-D.ietf-tls-dtls-connection-id]
Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom,
"The Datagram Transport Layer Security (DTLS) Connection "Connection Identifiers for DTLS 1.2", draft-ietf-tls-
Identifier", draft-ietf-tls-dtls-connection-id-01 (work in dtls-connection-id-02 (work in progress), October 2018.
progress), July 2018.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-28 (work in progress), July 1.3", draft-ietf-tls-dtls13-29 (work in progress), October
2018. 2018.
[I-D.ietf-tls-record-limit] [I-D.ietf-tls-record-limit]
Thomson, M., "Record Size Limit Extension for Transport Thomson, M., "Record Size Limit Extension for Transport
Layer Security (TLS)", draft-ietf-tls-record-limit-03 Layer Security (TLS)", draft-ietf-tls-record-limit-03
(work in progress), May 2018. (work in progress), May 2018.
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-28 (work in progress), Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
skipping to change at page 30, line 22 skipping to change at page 30, line 33
Security", n.d.. Security", n.d..
[Noise] "The Noise Protocol Framework", n.d.. [Noise] "The Noise Protocol Framework", n.d..
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, DOI 10.17487/RFC2385, August Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
1998, <https://www.rfc-editor.org/info/rfc2385>. 1998, <https://www.rfc-editor.org/info/rfc2385>.
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508, Headers for Low-Speed Serial Links", RFC 2508,
DOI 10.17487/RFC2508, February 1999, DOI 10.17487/RFC2508, February 1999, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc2508>. editor.org/info/rfc2508>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc3261>. editor.org/info/rfc3261>.
[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and
P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with
High Delay, Packet Loss and Reordering", RFC 3545, High Delay, Packet Loss and Reordering", RFC 3545,
DOI 10.17487/RFC3545, July 2003, DOI 10.17487/RFC3545, July 2003, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc3545>. editor.org/info/rfc3545>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, DOI 10.17487/RFC3948, January 2005, RFC 3948, DOI 10.17487/RFC3948, January 2005,
<https://www.rfc-editor.org/info/rfc3948>. <https://www.rfc-editor.org/info/rfc3948>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>. January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc4302>. editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, Initiation Protocol (SIP)", RFC 4474,
DOI 10.17487/RFC4474, August 2006, DOI 10.17487/RFC4474, August 2006, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc4474>. editor.org/info/rfc4474>.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
<https://www.rfc-editor.org/info/rfc4555>. <https://www.rfc-editor.org/info/rfc4555>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5246>. editor.org/info/rfc5246>.
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
DOI 10.17487/RFC5723, January 2010, DOI 10.17487/RFC5723, January 2010, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5723>. editor.org/info/rfc5723>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <https://www.rfc-editor.org/info/rfc5763>. 2010, <https://www.rfc-editor.org/info/rfc5763>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5764>. editor.org/info/rfc5764>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5869>. editor.org/info/rfc5869>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>. June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6066>. editor.org/info/rfc6066>.
[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
Media Path Key Agreement for Unicast Secure RTP", Media Path Key Agreement for Unicast Secure RTP",
RFC 6189, DOI 10.17487/RFC6189, April 2011, RFC 6189, DOI 10.17487/RFC6189, April 2011,
<https://www.rfc-editor.org/info/rfc6189>. <https://www.rfc-editor.org/info/rfc6189>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
skipping to change at page 32, line 42 skipping to change at page 32, line 51
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
<https://www.rfc-editor.org/info/rfc7539>. <https://www.rfc-editor.org/info/rfc7539>.
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
Ed., "Services Provided by IETF Transport Protocols and Ed., "Services Provided by IETF Transport Protocols and
Congestion Control Mechanisms", RFC 8095, Congestion Control Mechanisms", RFC 8095,
DOI 10.17487/RFC8095, March 2017, DOI 10.17487/RFC8095, March 2017, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc8095>. editor.org/info/rfc8095>.
[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
August 2017, <https://www.rfc-editor.org/info/rfc8229>. August 2017, <https://www.rfc-editor.org/info/rfc8229>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[SIGMA] "SIGMA -- The 'SIGn-and-MAc' Approach to Authenticated [SIGMA] "SIGMA -- The 'SIGn-and-MAc' Approach to Authenticated
Diffie-Hellman and Its Use in the IKE-Protocols", n.d.. Diffie-Hellman and Its Use in the IKE-Protocols", n.d..
[WireGuard] [WireGuard]
"WireGuard -- Next Generation Kernel Network Tunnel", "WireGuard -- Next Generation Kernel Network Tunnel",
n.d.. n.d..
Authors' Addresses Authors' Addresses
Tommy Pauly Tommy Pauly
 End of changes. 73 change blocks. 
165 lines changed or deleted 188 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/