draft-ietf-taps-transport-security-10.txt | draft-ietf-taps-transport-security-11.txt | |||
---|---|---|---|---|
Network Working Group T. Enghardt | Network Working Group T. Enghardt | |||
Internet-Draft TU Berlin | Internet-Draft TU Berlin | |||
Intended status: Informational T. Pauly | Intended status: Informational T. Pauly | |||
Expires: May 21, 2020 Apple Inc. | Expires: 6 September 2020 Apple Inc. | |||
C. Perkins | C. Perkins | |||
University of Glasgow | University of Glasgow | |||
K. Rose | K. Rose | |||
Akamai Technologies, Inc. | Akamai Technologies, Inc. | |||
C. Wood, Ed. | C.A. Wood, Ed. | |||
Apple Inc. | Apple Inc. | |||
November 18, 2019 | 5 March 2020 | |||
A Survey of the Interaction Between Security Protocols and Transport | A Survey of the Interaction Between Security Protocols and Transport | |||
Services | Services | |||
draft-ietf-taps-transport-security-10 | draft-ietf-taps-transport-security-11 | |||
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 by describing the | efforts to define and catalog transport services by describing the | |||
interfaces required to add security protocols. This survey is not | interfaces required to add security protocols. This survey is not | |||
limited to protocols developed within the scope or context of the | limited to protocols developed within the scope or context of the | |||
IETF, and those included represent a superset of features a Transport | IETF, and those included represent a superset of features a Transport | |||
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 May 21, 2020. | This Internet-Draft will expire on 6 September 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2020 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/ | |||
(https://trustee.ietf.org/license-info) in effect on the date of | license-info) in effect on the date of publication of this document. | |||
publication of this document. Please review these documents | Please review these documents carefully, as they describe your rights | |||
carefully, as they describe your rights and restrictions with respect | and restrictions with respect to this document. Code Components | |||
to this document. Code Components extracted from this document must | extracted from this document must include Simplified BSD License text | |||
include Simplified BSD License text as described in Section 4.e of | as described in Section 4.e of the Trust Legal Provisions and are | |||
the Trust Legal Provisions and are provided without warranty as | 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 | |||
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Transport Security Protocol Descriptions . . . . . . . . . . 6 | 3. Transport Security Protocol Descriptions . . . . . . . . . . 6 | |||
3.1. Application Payload Security Protocols . . . . . . . . . 6 | 3.1. Application Payload Security Protocols . . . . . . . . . 6 | |||
3.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 3.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.1.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . 6 | 3.1.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.2. Application-Specific Security Protocols . . . . . . . . . 6 | 3.2. Application-Specific Security Protocols . . . . . . . . . 7 | |||
3.2.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . 6 | 3.2.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.2.2. ZRTP for Media Path Key Agreement . . . . . . . . . . 7 | ||||
3.3. Transport-Layer Security Protocols . . . . . . . . . . . 7 | 3.3. Transport-Layer Security Protocols . . . . . . . . . . . 7 | |||
3.3.1. QUIC with TLS . . . . . . . . . . . . . . . . . . . . 7 | 3.3.1. IETF QUIC . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.3.2. Google QUIC . . . . . . . . . . . . . . . . . . . . . 7 | 3.3.2. Google QUIC . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.3.3. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . 7 | 3.3.3. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.3.4. MinimalT . . . . . . . . . . . . . . . . . . . . . . 7 | 3.3.4. MinimalT . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.3.5. CurveCP . . . . . . . . . . . . . . . . . . . . . . . 8 | 3.3.5. CurveCP . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.4. Packet Security Protocols . . . . . . . . . . . . . . . . 8 | 3.4. Packet Security Protocols . . . . . . . . . . . . . . . . 9 | |||
3.4.1. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . 8 | 3.4.1. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . 9 | |||
3.4.2. WireGuard . . . . . . . . . . . . . . . . . . . . . . 8 | 3.4.2. WireGuard . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.4.3. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . 8 | 3.4.3. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
4. Transport Dependencies . . . . . . . . . . . . . . . . . . . 9 | 4. Transport Dependencies . . . . . . . . . . . . . . . . . . . 9 | |||
4.1. Reliable Byte-Stream Transports . . . . . . . . . . . . . 9 | 4.1. Reliable Byte-Stream Transports . . . . . . . . . . . . . 10 | |||
4.2. Unreliable Datagram Transports . . . . . . . . . . . . . 9 | 4.2. Unreliable Datagram Transports . . . . . . . . . . . . . 10 | |||
4.2.1. Datagram Protocols with Defined Byte-Stream Mappings 10 | 4.2.1. Datagram Protocols with Defined Byte-Stream | |||
4.3. Transport-Specific Dependencies . . . . . . . . . . . . . 10 | Mappings . . . . . . . . . . . . . . . . . . . . . . 11 | |||
5. Application Interface . . . . . . . . . . . . . . . . . . . . 10 | 4.3. Transport-Specific Dependencies . . . . . . . . . . . . . 11 | |||
5.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 11 | 5. Application Interface . . . . . . . . . . . . . . . . . . . . 11 | |||
5.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 13 | 5.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 12 | |||
5.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 13 | 5.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 14 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | 5.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 15 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 | 5.4. Summary of Interfaces Exposed by Protocols . . . . . . . 16 | |||
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 | |||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | |||
10. Informative References . . . . . . . . . . . . . . . . . . . 15 | 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
10. Informative References . . . . . . . . . . . . . . . . . . . 18 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 | ||||
1. Introduction | 1. Introduction | |||
Services and features provided by transport protocols have been | Services and features provided by transport protocols have been | |||
cataloged in [RFC8095]. This document supplements that work by | cataloged in [RFC8095]. This document supplements that work by | |||
surveying commonly used and notable network security protocols, and | surveying commonly used and notable network security protocols, and | |||
identifying the services and features a Transport Services system (a | identifying the interfaces between these protocols and both transport | |||
system that provides a transport API) needs to provide in order to | protocols and applications. It examines Transport Layer Security | |||
add transport security. It examines Transport Layer Security (TLS), | (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google | |||
Datagram Transport Layer Security (DTLS), QUIC + TLS, tcpcrypt, | QUIC (gQUIC), tcpcrypt, Internet Key Exchange with Encapsulating | |||
Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + | Security Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, | |||
ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimalT. For each | CurveCP, and MinimalT. For each protocol, this document provides a | |||
protocol, this document provides a brief description, the | brief description. Then, it describes the interfaces between these | |||
dependencies it has on the underlying transports, and the interfaces | protocols and transports in Section 4 and the interfaces between | |||
provided to applications. | these protocols and applications in Section 5. | |||
Selected protocols represent a superset of functionality and features | Selected protocols represent a superset of functionality and features | |||
a Transport Services system may need to support, both internally and | a Transport Services system may need to support, both internally and | |||
externally (via an API) for applications [I-D.ietf-taps-arch]. | externally (via an API) for applications [I-D.ietf-taps-arch]. | |||
Ubiquitous IETF protocols such as (D)TLS, as well as non-standard | Ubiquitous IETF protocols such as (D)TLS, as well as non-standard | |||
protocols such as Google QUIC, are both included despite overlapping | protocols such as gQUIC, are both included despite overlapping | |||
features. As such, this survey is not limited to protocols developed | features. As such, this survey is not limited to protocols developed | |||
within the scope or context of the IETF. Outside of this candidate | within the scope or context of the IETF. Outside of this candidate | |||
set, protocols that do not offer new features are omitted. For | set, protocols that do not offer new features are omitted. For | |||
example, newer protocols such as WireGuard make unique design choices | example, newer protocols such as WireGuard make unique design choices | |||
that have implications and limitations on application usage. In | that have implications and limitations on application usage. In | |||
contrast, protocols such as ALTS [ALTS] are omitted since they do not | contrast, protocols such as ALTS [ALTS] are omitted since they do not | |||
provide interfaces deemed unique. | provide interfaces deemed unique. | |||
Authentication-only protocols such as TCP-AO [RFC5925] and IPsec AH | Authentication-only protocols such as TCP-AO [RFC5925] and IPsec AH | |||
[RFC4302] are excluded from this survey. TCP-AO adds authenticity | [RFC4302] are excluded from this survey. TCP-AO adds authenticity | |||
skipping to change at page 4, line 50 ¶ | skipping to change at page 4, line 50 ¶ | |||
between versions, security protocols have subtly different guarantees | between versions, security protocols have subtly different guarantees | |||
and vulnerabilities. Thus, any implementation needs to only use the | and vulnerabilities. Thus, any implementation needs to only use the | |||
set of protocols and algorithms that are requested by applications or | set of protocols and algorithms that are requested by applications or | |||
by a system policy. | by a system policy. | |||
2. Terminology | 2. Terminology | |||
The following terms are used throughout this document to describe the | The following terms are used throughout this document to describe the | |||
roles and interactions of transport security protocols: | roles and interactions of transport security protocols: | |||
o Transport Feature: a specific end-to-end feature that the | * Transport Feature: a specific end-to-end feature that the | |||
transport layer provides to an application. Examples include | transport layer provides to an application. Examples include | |||
confidentiality, reliable delivery, ordered delivery, message- | confidentiality, reliable delivery, ordered delivery, message- | |||
versus-stream orientation, etc. | versus-stream orientation, etc. | |||
o Transport Service: a set of Transport Features, without an | * Transport Service: a set of Transport Features, without an | |||
association to any given framing protocol, which provides | association to any given framing protocol, which provides | |||
functionality to an application. | functionality to an application. | |||
o Transport Protocol: an implementation that provides one or more | * Transport Protocol: an implementation that provides one or more | |||
different transport services using a specific framing and header | different transport services using a specific framing and header | |||
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- | * 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 Protocol: a defined network protocol that implements one | * Security Protocol: a defined network protocol that implements one | |||
or more security features, such as authentication, encryption, key | or more security features, such as authentication, encryption, key | |||
generation, session resumption, and privacy. Security protocols | generation, session resumption, and privacy. Security protocols | |||
may be used alongside transport protocols, and in combination with | may be used alongside transport protocols, and in combination with | |||
other security protocols when appropriate. | other security protocols when appropriate. | |||
o Handshake Protocol: a protocol that enables peers to validate each | * 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. | * Record: Framed protocol messages. | |||
o Record Protocol: a security protocol that allows data to be | * Record Protocol: a security protocol that allows data to be | |||
divided into manageable blocks and protected using shared | divided into manageable blocks and protected using shared | |||
cryptographic context. | cryptographic context. | |||
o Session: an ephemeral security association between applications. | * Session: an ephemeral security association between applications. | |||
o Connection: the shared state of two or more endpoints that | * 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 Peer: an endpoint application party to a session. | * Peer: an endpoint application party to a session. | |||
o Client: the peer responsible for initiating a session. | * Client: the peer responsible for initiating a session. | |||
o Server: the peer responsible for responding to a session | * Server: the peer responsible for responding to a session | |||
initiation. | initiation. | |||
3. Transport Security Protocol Descriptions | 3. Transport Security Protocol Descriptions | |||
This section contains brief descriptions of the various security | This section contains brief descriptions of the various security | |||
protocols currently used to protect data being sent over a network. | protocols currently used to protect data being sent over a network. | |||
The interfaces between these protocols and transports are described | These protocols are grouped based on where in the protocol stack they | |||
in Section 4; the interfaces between these protocols and applications | are implemented, which influences which parts of a packet they | |||
are described in Section 5. | protect: Generic application payload, application payload for | |||
specific application-layer protocols, both application payload and | ||||
transport headers, or entire IP packets. | ||||
Note that not all security protocols can be easily categorized, e.g., | ||||
as some protocols can be used in different ways or in combination | ||||
with other protocols. One major reason for this is that channel | ||||
security protocols often consist of two components: | ||||
* A handshake protocol, which is responsible for negotiating | ||||
parameters, authenticating the endpoints, and establishing shared | ||||
keys. | ||||
* A record protocol, which is used to encrypt traffic using keys and | ||||
parameters provided by the handshake protocol. | ||||
For some protocols, such as tcpcrypt, these two components are | ||||
tightly integrated. In contrast, for IPsec, these components are | ||||
implemented in separate protocols: AH and ESP are record protocols, | ||||
which can use keys supplied by the handshake protocol IKEv2, by other | ||||
handshake protocols, or by manual configuration. Moreover, some | ||||
protocols can be used in different ways: While the base TLS protocol | ||||
as defined in [RFC8446] has an integrated handshake and record | ||||
protocol, TLS or DTLS can also be used to negotiate keys for other | ||||
protocols, as in DTLS-SRTP, or the handshake protocol can be used | ||||
with a separate record layer, as in QUIC. | ||||
3.1. Application Payload Security Protocols | 3.1. Application Payload Security Protocols | |||
The following protocols provide security that protects application | The following protocols provide security that protects application | |||
payloads sent over a transport. They do not specifically protect any | payloads sent over a transport. They do not specifically protect any | |||
headers used for transport-layer functionality. | headers used for transport-layer functionality. | |||
3.1.1. TLS | 3.1.1. TLS | |||
TLS (Transport Layer Security) [RFC8446] is a common protocol used to | TLS (Transport Layer Security) [RFC8446] is a common protocol used to | |||
skipping to change at page 6, line 52 ¶ | skipping to change at page 7, line 28 ¶ | |||
The following protocols provide application-specific security by | The following protocols provide application-specific security by | |||
protecting application payloads used for specific use-cases. Unlike | protecting application payloads used for specific use-cases. Unlike | |||
the protocols above, these are not intended for generic application | the protocols above, these are not intended for generic application | |||
use. | use. | |||
3.2.1. Secure RTP | 3.2.1. Secure RTP | |||
Secure RTP (SRTP) is a profile for RTP that provides confidentiality, | Secure RTP (SRTP) is a profile for RTP that provides confidentiality, | |||
message authentication, and replay protection for RTP data packets | message authentication, and replay protection for RTP data packets | |||
and RTP control protocol (RTCP) packets [RFC3711]. | and RTP control protocol (RTCP) packets [RFC3711]. SRTP provides a | |||
record layer only, and requires a separate handshake protocol to | ||||
provide key agreement and identity management. | ||||
3.2.2. ZRTP for Media Path Key Agreement | The commonly used handshake protocol for SRTP is DTLS, in the form of | |||
DTLS-SRTP [RFC5764]. This is an extension to DTLS that negotiates | ||||
the use of SRTP as the record layer, and describes how to export keys | ||||
for use with SRTP. | ||||
ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It | ZRTP [RFC6189] is an alternative key agreement and identity | |||
uses standard SRTP to protect RTP data packets and RTCP packets, but | management protocols for SRTP. ZRTP Key agreement is performed using | |||
provides alternative key agreement and identity management protocols. | a Diffie-Hellman key exchange that runs on the media path. This | |||
Key agreement is performed using a Diffie-Hellman key exchange that | generates a shared secret that is then used to generate the master | |||
runs on the media path. This generates a shared secret that is then | key and salt for SRTP. | |||
used to generate the master key and salt for SRTP. | ||||
3.3. Transport-Layer Security Protocols | 3.3. Transport-Layer Security Protocols | |||
The following security protocols provide protection for both | The following security protocols provide protection for both | |||
application payloads and headers that are used for transport | application payloads and headers that are used for transport | |||
services. | services. | |||
3.3.1. QUIC with TLS | 3.3.1. IETF QUIC | |||
QUIC is a new standards-track transport protocol that runs over UDP, | QUIC is a new standards-track transport protocol that runs over UDP, | |||
loosely based on Google's original proprietary gQUIC protocol | loosely based on Google's original proprietary gQUIC protocol | |||
[I-D.ietf-quic-transport] (See Section 3.3.2 for more details). The | [I-D.ietf-quic-transport] (See Section 3.3.2 for more details). The | |||
QUIC transport layer itself provides support for data confidentiality | QUIC transport layer itself provides support for data confidentiality | |||
and integrity. This requires keys to be derived with a separate | and integrity. This requires keys to be derived with a separate | |||
handshake protocol. A mapping for QUIC of TLS 1.3 | handshake protocol. A mapping for QUIC of 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.2. Google QUIC | 3.3.2. Google QUIC | |||
Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol | Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol | |||
designed and deployed by Google following experience from deploying | designed and deployed by Google following experience from deploying | |||
SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally | SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally | |||
known as "QUIC": this document uses gQUIC to unambiguously | known as "QUIC": this document uses gQUIC to unambiguously | |||
distinguish it from the standards-track IETF QUIC. The proprietary | distinguish it from the standards-track IETF QUIC. The proprietary | |||
technical forebear of IETF QUIC, gQUIC was originally designed with | technical forebear of IETF QUIC, gQUIC was originally designed with | |||
tightly-integrated security and application data transport protocols. | tightly-integrated security and application data transport protocols. | |||
3.3.3. tcpcrypt | 3.3.3. tcpcrypt | |||
Tcpcrypt [RFC8548] is a lightweight extension to the TCP protocol for | Tcpcrypt [RFC8548] is a lightweight extension to the TCP protocol for | |||
opportunistic encryption. Applications may use tcpcrypt's unique | opportunistic encryption. Applications may use tcpcrypt's unique | |||
session ID for further application-level authentication. Absent this | session ID for further application-level authentication. Absent this | |||
skipping to change at page 8, line 10 ¶ | skipping to change at page 8, line 44 ¶ | |||
MinimalT is a UDP-based transport security protocol designed to offer | MinimalT is a UDP-based transport security protocol designed to offer | |||
confidentiality, mutual authentication, DoS prevention, and | confidentiality, mutual authentication, DoS prevention, and | |||
connection mobility [MinimalT]. One major goal of the protocol is to | connection mobility [MinimalT]. One major goal of the protocol is to | |||
leverage existing protocols to obtain server-side configuration | leverage existing protocols to obtain server-side configuration | |||
information used to more quickly bootstrap a connection. MinimalT | information used to more quickly bootstrap a connection. MinimalT | |||
uses a variant of TCP's congestion control algorithm. | uses a variant of TCP's congestion control algorithm. | |||
3.3.5. CurveCP | 3.3.5. CurveCP | |||
CurveCP [CurveCP] is a UDP-based transport security protocol from | CurveCP [CurveCP] is a UDP-based transport security protocol from | |||
Daniel J. Bernstein. Unlike other security protocols, it is based | Daniel J. Bernstein. Unlike many other security protocols, it is | |||
entirely upon highly efficient public key algorithms. This removes | based entirely upon public key algorithms. CurveCP provides its own | |||
many pitfalls associated with nonce reuse and key synchronization. | reliability for application data as part of its protocol. | |||
CurveCP provides its own reliability for application data as part of | ||||
its protocol. | ||||
3.4. Packet Security Protocols | 3.4. Packet Security Protocols | |||
The following protocols provide protection for IP packets. These are | The following protocols provide protection for IP packets. These are | |||
generally used as tunnels, such as for Virtual Private Networks | generally used as tunnels, such as for Virtual Private Networks | |||
(VPNs). Often, applications will not interact directly with these | (VPNs). Often, applications will not interact directly with these | |||
protocols. However, applications that implement tunnels will | protocols. However, applications that implement tunnels will | |||
interact directly with these protocols. | interact directly with these protocols. | |||
3.4.1. IKEv2 with ESP | 3.4.1. IKEv2 with ESP | |||
skipping to change at page 8, line 39 ¶ | skipping to change at page 9, line 28 ¶ | |||
(transport-mode). This suite of protocols separates out the key | (transport-mode). This suite of protocols separates out the key | |||
generation protocol (IKEv2) from the transport encryption protocol | generation protocol (IKEv2) from the transport encryption protocol | |||
(ESP). Each protocol can be used independently, but this document | (ESP). Each protocol can be used independently, but this document | |||
considers them together, since that is the most common pattern. | considers them together, since that is the most common pattern. | |||
3.4.2. WireGuard | 3.4.2. WireGuard | |||
WireGuard is an IP-layer protocol designed as an alternative to IPsec | WireGuard is an IP-layer protocol designed as an alternative to IPsec | |||
[WireGuard] for certain use cases. It uses UDP to encapsulate IP | [WireGuard] for certain use cases. It uses UDP to encapsulate IP | |||
datagrams between peers. Unlike most transport security protocols, | datagrams between peers. Unlike most transport security protocols, | |||
which rely on PKI for peer authentication, WireGuard authenticates | which rely on Public Key Infrastructure (PKI) for peer | |||
peers using pre-shared public keys delivered out-of-band, each of | authentication, WireGuard authenticates peers using pre-shared public | |||
which is bound to one or more IP addresses. Moreover, as a protocol | keys delivered out-of-band, each of which is bound to one or more IP | |||
suited for VPNs, WireGuard offers no extensibility, negotiation, or | addresses. Moreover, as a protocol suited for VPNs, WireGuard offers | |||
cryptographic agility. | no extensibility, negotiation, or cryptographic agility. | |||
3.4.3. OpenVPN | 3.4.3. OpenVPN | |||
OpenVPN [OpenVPN] is a commonly used protocol designed as an | OpenVPN [OpenVPN] is a commonly used protocol designed as an | |||
alternative to IPsec. A major goal of this protocol is to provide a | alternative to IPsec. A major goal of this protocol is to provide a | |||
VPN that is simple to configure and works over a variety of | VPN that is simple to configure and works over a variety of | |||
transports. OpenVPN encapsulates either IP packets or Ethernet | transports. OpenVPN encapsulates either IP packets or Ethernet | |||
frames within a secure tunnel and can run over UDP or TCP. | frames within a secure tunnel and can run over either UDP or TCP. | |||
For key establishment, OpenVPN can use TLS as a handshake protocol or | ||||
pre-shared keys. | ||||
4. Transport Dependencies | 4. Transport Dependencies | |||
Across the different security protocols listed above, the primary | Across the different security protocols listed above, the primary | |||
dependency on transport protocols is the presentation of data: either | dependency on transport protocols is the presentation of data: either | |||
an unbounded stream of bytes, or framed messages. Within protocols | an unbounded stream of bytes, or framed messages. Within protocols | |||
that rely on the transport for message framing, most are built to run | that rely on the transport for message framing, most are built to run | |||
over transports that inherently provide framing, like UDP, but some | over transports that inherently provide framing, like UDP, but some | |||
also define how their messages can be framed over byte-stream | also define how their messages can be framed over byte-stream | |||
transports. | transports. | |||
4.1. Reliable Byte-Stream Transports | 4.1. Reliable Byte-Stream Transports | |||
The following protocols all depend upon running on a transport | The following protocols all depend upon running on a transport | |||
protocol that provides a reliable, in-order stream of bytes. This is | protocol that provides a reliable, in-order stream of bytes. This is | |||
typically TCP. | typically TCP. | |||
Application Payload Security Protocols: | Application Payload Security Protocols: | |||
o TLS | * TLS | |||
Transport-Layer Security Protocols: | Transport-Layer Security Protocols: | |||
o tcpcrypt | * tcpcrypt | |||
Packet Security Protocols: | ||||
o OpenVPN | ||||
4.2. Unreliable Datagram Transports | 4.2. Unreliable Datagram Transports | |||
The following protocols all depend on the transport protocol to | The following protocols all depend on the transport protocol to | |||
provide message framing to encapsulate their data. These protocols | provide message framing to encapsulate their data. These protocols | |||
are built to run using UDP, and thus do not have any requirement for | are built to run using UDP, and thus do not have any requirement for | |||
reliability. Running these protocols over a protocol that does | reliability. Running these protocols over a protocol that does | |||
provide reliability will not break functionality, but may lead to | provide reliability will not break functionality, but may lead to | |||
multiple layers of reliability if the security protocol is | multiple layers of reliability if the security protocol is | |||
encapsulating other transport protocol traffic. | encapsulating other transport protocol traffic. | |||
Application Payload Security Protocols: | Application Payload Security Protocols: | |||
o DTLS | * DTLS | |||
o SRTP | * ZRTP | |||
o ZRTP | * SRTP | |||
Transport-Layer Security Protocols: | Transport-Layer Security Protocols: | |||
o QUIC | * QUIC | |||
o MinimalT | * MinimalT | |||
o CurveCP | * CurveCP | |||
Packet Security Protocols: | Packet Security Protocols: | |||
o IKEv2 and ESP | * IKEv2 and ESP | |||
o WireGuard | * WireGuard | |||
* OpenVPN | ||||
4.2.1. Datagram Protocols with Defined Byte-Stream Mappings | 4.2.1. Datagram Protocols with Defined Byte-Stream Mappings | |||
Of the protocols listed above that depend on the transport for | Of the protocols listed above that depend on the transport for | |||
message framing, some do have well-defined mappings for sending their | message framing, some do have well-defined mappings for sending their | |||
messages over byte-stream transports like TCP. | messages over byte-stream transports like TCP. | |||
Application Payload Security Protocols: | Application Payload Security Protocols: | |||
o SRTP [RFC7201] | * DTLS when used as a handshake protocol for SRTP [RFC7850] | |||
* ZRTP [RFC4571] | ||||
* SRTP [RFC4571] | ||||
Packet Security Protocols: | Packet Security Protocols: | |||
o IKEv2 and ESP [RFC8229] | * IKEv2 and ESP [RFC8229] | |||
4.3. Transport-Specific Dependencies | 4.3. Transport-Specific Dependencies | |||
One protocol surveyed, tcpcrypt, has an direct dependency on a | One protocol surveyed, tcpcrypt, has an direct dependency on a | |||
feature in the transport that is needed for its functionality. | feature in the transport that is needed for its functionality. | |||
Specific, tcpcrypt is designed to run on top of TCP, and uses the TCP | Specific, tcpcrypt is designed to run on top of TCP, and uses the TCP | |||
Encryption Negotiation Option (ENO) [RFC8547] to negotiate its | Encryption Negotiation Option (ENO) [RFC8547] to negotiate its | |||
protocol support. | protocol support. | |||
QUIC, CurveCP, and MinimalT provide both transport functionality and | QUIC, CurveCP, and MinimalT provide both transport functionality and | |||
security functionality. They have a dependencies on running over a | security functionality. They have a dependencies on running over a | |||
framed protocol like UDP, but they add their own layers of | framed protocol like UDP, but they add their own layers of | |||
reliability and other transport services. Thus, an application that | reliability and other transport services. Thus, an application that | |||
uses one of these protocols cannot decouple the security from | uses one of these protocols cannot decouple the security from | |||
transport functionality. | transport functionality. | |||
5. Application Interface | 5. Application Interface | |||
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. We partition these interfaces into pre- | |||
interface. We partition these interfaces into pre-connection | connection (configuration), connection, and post-connection | |||
(configuration), connection, and post-connection interfaces, | 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]. | |||
Note that not all protocols support each interface. The table in | ||||
Section 5.4 summarizes which protocol exposes which of the | ||||
interfaces. In the following sections, we provide abbreviations of | ||||
the interface names to use in the summary table. | ||||
5.1. Pre-Connection 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 Identities and Private Keys: The application can provide its | * Identities and Private Keys (IPK): 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. | |||
* TLS | - TLS | |||
* DTLS | - DTLS | |||
* SRTP | - ZRTP | |||
* QUIC | - QUIC | |||
* MinimalT | - MinimalT | |||
* CurveCP | - CurveCP | |||
* IKEv2 | - IKEv2 | |||
* WireGuard | - WireGuard | |||
o Supported Algorithms (Key Exchange, Signatures, and Ciphersuites): | - OpenVPN | |||
The application can choose the algorithms that are supported for | ||||
key exchange, signatures, and ciphersuites. | ||||
* TLS | * Supported Algorithms (Key Exchange, Signatures, and Ciphersuites) | |||
(ALG): The application can choose the algorithms that are | ||||
supported for key exchange, signatures, and ciphersuites. | ||||
* DTLS | - TLS | |||
* SRTP | - DTLS | |||
* QUIC | - ZRTP | |||
* tcpcrypt | - QUIC | |||
* MinimalT | - tcpcrypt | |||
* IKEv2 | - MinimalT | |||
o Extensions (Application-Layer Protocol Negotiation): The | - IKEv2 | |||
- OpenVPN | ||||
* Extensions (Application-Layer Protocol Negotiation) (EXT): The | ||||
application enables or configures extensions that are to be | application enables or configures extensions that are to be | |||
negotiated by the security protocol, such as ALPN [RFC7301]. | negotiated by the security protocol, such as ALPN [RFC7301]. | |||
* TLS | - TLS | |||
* DTLS | - DTLS | |||
* QUIC | - QUIC | |||
o Session Cache Management: The application provides the ability to | * Session Cache Management (CM): The application provides the | |||
save and retrieve session state (such as tickets, keying material, | ability to save and retrieve session state (such as tickets, | |||
and server parameters) that may be used to resume the security | keying material, and server parameters) that may be used to resume | |||
session. | the security session. | |||
* TLS | - TLS | |||
* DTLS | - DTLS | |||
* QUIC | - ZRTP | |||
* MinimalT | - QUIC | |||
o Authentication Delegation: The application provides access to a | - tcpcrypt | |||
separate module that will provide authentication, using EAP for | ||||
- MinimalT | ||||
* Authentication Delegation (AD): The application provides access to | ||||
a separate module that will provide authentication, using EAP for | ||||
example. | example. | |||
* SRTP | - IKEv2 | |||
* IKEv2 | - tcpcrypt | |||
o Pre-Shared Key Import: Either the handshake protocol or the | * Pre-Shared Key Import (PSKI): Either the handshake protocol or the | |||
application directly can supply pre-shared keys for the record | application directly can supply pre-shared keys for use in | |||
protocol use for encryption/decryption and authentication. If the | encrypting (and authenticating) communication with a peer. | |||
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. | ||||
* Explicit import: QUIC, ESP | - TLS | |||
* Direct import: TLS, DTLS, tcpcrypt, MinimalT, WireGuard | - DTLS | |||
* Non-importable: CurveCP | - ZRTP | |||
- QUIC | ||||
- ESP | ||||
- IKEv2 | ||||
- OpenVPN | ||||
- tcpcrypt | ||||
- MinimalT | ||||
- WireGuard | ||||
5.2. Connection Interfaces | 5.2. Connection Interfaces | |||
o Identity Validation: During a handshake, the security protocol | * Identity Validation (IV): During a handshake, the security | |||
will conduct identity validation of the peer. This can call into | protocol will conduct identity validation of the peer. This can | |||
the application to offload validation. | call into the application to offload validation. | |||
* TLS | - TLS | |||
* DTLS | - DTLS | |||
* SRTP | - ZRTP | |||
* QUIC | - QUIC | |||
* MinimalT | - MinimalT | |||
* CurveCP | - CurveCP | |||
* IKEv2 | - IKEv2 | |||
* WireGuard | - WireGuard | |||
* OpenVPN | - OpenVPN | |||
o Source Address Validation: The handshake protocol may delegate | * Source Address Validation (SAV): The handshake protocol may | |||
validation of the remote peer that has sent data to the transport | delegate validation of the remote peer that has sent data to the | |||
protocol or application. This involves sending a cookie exchange | transport protocol or application. This involves sending a cookie | |||
to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard | exchange to avoid DoS attacks. | |||
* DTLS | - DTLS | |||
* QUIC | - QUIC | |||
* WireGuard | - IKEv2 | |||
- WireGuard | ||||
5.3. Post-Connection Interfaces | 5.3. Post-Connection Interfaces | |||
o Connection Termination: The security protocol may be instructed to | * Connection Termination (CT): The security protocol may be | |||
tear down its connection and session information. This is needed | instructed to tear down its connection and session information. | |||
by some protocols to prevent application data truncation attacks. | This is needed by some protocols, e.g., to prevent application | |||
data truncation attacks in which an attacker terminates an | ||||
underlying insecure connection-oriented protocol to terminate the | ||||
session. | ||||
* TLS | - TLS | |||
* DTLS | - DTLS | |||
* QUIC | - ZRTP | |||
* tcpcrypt | - QUIC | |||
* MinimalT | ||||
* IKEv2 | - tcpcrypt | |||
o Key Update: The handshake protocol may be instructed to update its | - MinimalT | |||
keying material, either by the application directly or by the | ||||
record protocol sending a key expiration event. | ||||
* TLS | - IKEv2 | |||
* DTLS | - OpenVPN | |||
* QUIC | * Key Update (KU): The handshake protocol may be instructed to | |||
update its keying material, either by the application directly or | ||||
by the record protocol sending a key expiration event. | ||||
* tcpcrypt | - TLS | |||
* MinimalT | - DTLS | |||
* IKEv2 | - QUIC | |||
o Pre-Shared Key Export: The handshake protocol will generate one or | - tcpcrypt | |||
more keys to be used for record encryption/decryption and | ||||
authentication. These may be explicitly exportable to the | ||||
application, traditionally limited to direct export to the record | ||||
protocol, or inherently non-exportable because the keys must be | ||||
used directly in conjunction with the record protocol. | ||||
* Explicit export: TLS (for QUIC), DTLS (for SRTP), tcpcrypt, | - MinimalT | |||
IKEv2 | ||||
* Direct export: TLS, DTLS, MinimalT | - IKEv2 | |||
* Non-exportable: CurveCP | * Shared Secret Export (PSKE): The handshake protocol may provide an | |||
interface for producing shared secrets for application-specific | ||||
uses. | ||||
o Key Expiration: The record protocol can signal that its keys are | - TLS | |||
expiring due to reaching a time-based deadline, or a use-based | ||||
- DTLS | ||||
- tcpcrypt | ||||
- IKEv2 | ||||
- OpenVPN | ||||
- MinimalT | ||||
* Key Expiration (KE): The record protocol can signal that its keys | ||||
are expiring due to reaching a time-based deadline, or a use-based | ||||
deadline (number of bytes that have been encrypted with the key). | 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. | layer and the handshake layer. | |||
* ESP | - ESP | |||
o Mobility Events: The record protocol can be signaled that it is | * Mobility Events (ME): The record protocol can be signaled that it | |||
being migrated to another transport or interface due to connection | is being migrated to another transport or interface due to | |||
mobility, which may reset address and state validation and induce | connection mobility, which may reset address and state validation | |||
state changes such as use of a new Connection Identifier (CID). | and induce state changes such as use of a new Connection | |||
Identifier (CID). | ||||
* QUIC | - QUIC | |||
* MinimalT | ||||
* CurveCP | - MinimalT | |||
* ESP | - CurveCP | |||
* WireGuard | - IKEv2 [RFC4555] | |||
- WireGuard | ||||
5.4. Summary of Interfaces Exposed by Protocols | ||||
The following table summarizes which protocol exposes which | ||||
interface. | ||||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | ||||
| Protocol |IPK|ALG | EXT |CM|AD| PSKI |IV| SAV |CT|KU| PSKE |KE|ME| | ||||
+===========+===+====+=====+==+==+======+==+=====+==+==+======+==+==+ | ||||
| TLS | x | x | x |x | | x |x | |x |x | x | | | | ||||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | ||||
| DTLS | x | x | x |x | | x |x | x |x |x | x | | | | ||||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | ||||
| ZRTP | x | x | |x | | x |x | |x | | | | | | ||||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | ||||
| QUIC | x | x | x |x | | x |x | x |x |x | | |x | | ||||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | ||||
| tcpcrypt | | x | |x |x | x | | |x |x | x | | | | ||||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | ||||
| MinimalT | x | x | |x | | x |x | |x |x | x | |x | | ||||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | ||||
| CurveCP | x | | | | | |x | | | | | |x | | ||||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | ||||
| IKEv2 | x | x | | |x | x |x | x |x |x | x | |x | | ||||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | ||||
| ESP | | | | | | x | | | | | |x | | | ||||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | ||||
| WireGuard | x | | | | | x |x | x | | | | |x | | ||||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | ||||
| OpenVPN | x | x | | | | x |x | |x | | x | | | | ||||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | ||||
Table 1 | ||||
x=Interface is exposed (blank)=Interface is not exposed | ||||
6. IANA Considerations | 6. IANA Considerations | |||
This document has no request to IANA. | This document has no request to IANA. | |||
7. Security Considerations | 7. 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 | |||
skipping to change at page 16, line 5 ¶ | skipping to change at page 18, line 29 ¶ | |||
Kuehlewind, Yannick Sierra, Brian Trammell, and Magnus Westerlund for | Kuehlewind, Yannick Sierra, Brian Trammell, and Magnus Westerlund for | |||
their input and feedback on this draft. | their input and feedback on this draft. | |||
10. Informative References | 10. Informative References | |||
[ALTS] Ghali, C., Stubblefield, A., Knapp, E., Li, J., Schmidt, | [ALTS] Ghali, C., Stubblefield, A., Knapp, E., Li, J., Schmidt, | |||
B., and J. Boeuf, "Application Layer Transport Security", | B., and J. Boeuf, "Application Layer Transport Security", | |||
<https://cloud.google.com/security/encryption-in-transit/ | <https://cloud.google.com/security/encryption-in-transit/ | |||
application-layer-transport-security/>. | application-layer-transport-security/>. | |||
[CurveCP] Bernstein, D., "CurveCP -- Usable security for the | [CurveCP] Bernstein, D.J., "CurveCP -- Usable security for the | |||
Internet", <http://curvecp.org>. | Internet", <http://curvecp.org>. | |||
[I-D.ietf-quic-tls] | [I-D.ietf-quic-tls] | |||
Thomson, M. and S. Turner, "Using TLS to Secure QUIC", | Thomson, M. and S. Turner, "Using TLS to Secure QUIC", | |||
draft-ietf-quic-tls-23 (work in progress), September 2019. | Work in Progress, Internet-Draft, draft-ietf-quic-tls-27, | |||
21 February 2020, <http://www.ietf.org/internet-drafts/ | ||||
draft-ietf-quic-tls-27.txt>. | ||||
[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-23 (work | and Secure Transport", Work in Progress, Internet-Draft, | |||
in progress), September 2019. | draft-ietf-quic-transport-27, 21 February 2020, | |||
<http://www.ietf.org/internet-drafts/draft-ietf-quic- | ||||
transport-27.txt>. | ||||
[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-04 (work in | Transport Services", Work in Progress, Internet-Draft, | |||
progress), July 2019. | draft-ietf-taps-arch-06, 23 December 2019, | |||
<http://www.ietf.org/internet-drafts/draft-ietf-taps-arch- | ||||
06.txt>. | ||||
[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., Wood, C., and T. | Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. | |||
Pauly, "An Abstract Application Layer Interface to | Pauly, "An Abstract Application Layer Interface to | |||
Transport Services", draft-ietf-taps-interface-04 (work in | Transport Services", Work in Progress, Internet-Draft, | |||
progress), July 2019. | draft-ietf-taps-interface-05, 4 November 2019, | |||
<http://www.ietf.org/internet-drafts/draft-ietf-taps- | ||||
interface-05.txt>. | ||||
[MinimalT] | [MinimalT] Petullo, W.M., Zhang, X., Solworth, J.A., Bernstein, D.J., | |||
Petullo, W., Zhang, X., Solworth, J., Bernstein, D., and | and T. Lange, "MinimaLT -- Minimal-latency Networking | |||
T. Lange, "MinimaLT -- Minimal-latency Networking Through | Through Better Security", | |||
Better Security", | ||||
<http://dl.acm.org/citation.cfm?id=2516737>. | <http://dl.acm.org/citation.cfm?id=2516737>. | |||
[OpenVPN] "OpenVPN cryptographic layer", <https://openvpn.net/ | [OpenVPN] "OpenVPN cryptographic layer", <https://openvpn.net/ | |||
community-resources/openvpn-cryptographic-layer/>. | community-resources/openvpn-cryptographic-layer/>. | |||
[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>. | |||
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | |||
skipping to change at page 17, line 9 ¶ | skipping to change at page 19, line 39 ¶ | |||
<https://www.rfc-editor.org/info/rfc3711>. | <https://www.rfc-editor.org/info/rfc3711>. | |||
[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-editor.org/info/rfc4302>. | <https://www.rfc-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>. | |||
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol | ||||
(MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, | ||||
<https://www.rfc-editor.org/info/rfc4555>. | ||||
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) | ||||
and RTP Control Protocol (RTCP) Packets over Connection- | ||||
Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July | ||||
2006, <https://www.rfc-editor.org/info/rfc4571>. | ||||
[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-editor.org/info/rfc5246>. | <https://www.rfc-editor.org/info/rfc5246>. | |||
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer | ||||
Security (DTLS) Extension to Establish Keys for the Secure | ||||
Real-time Transport Protocol (SRTP)", RFC 5764, | ||||
DOI 10.17487/RFC5764, May 2010, | ||||
<https://www.rfc-editor.org/info/rfc5764>. | ||||
[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>. | |||
[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>. | |||
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP | ||||
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, | ||||
<https://www.rfc-editor.org/info/rfc7201>. | ||||
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. | [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. | |||
Kivinen, "Internet Key Exchange Protocol Version 2 | Kivinen, "Internet Key Exchange Protocol Version 2 | |||
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October | (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October | |||
2014, <https://www.rfc-editor.org/info/rfc7296>. | 2014, <https://www.rfc-editor.org/info/rfc7296>. | |||
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, | [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, | |||
"Transport Layer Security (TLS) Application-Layer Protocol | "Transport Layer Security (TLS) Application-Layer Protocol | |||
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>. | |||
[RFC7850] Nandakumar, S., "Registering Values of the SDP 'proto' | ||||
Field for Transporting RTP Media over TCP under Various | ||||
RTP Profiles", RFC 7850, DOI 10.17487/RFC7850, April 2016, | ||||
<https://www.rfc-editor.org/info/rfc7850>. | ||||
[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-editor.org/info/rfc8095>. | <https://www.rfc-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>. | |||
skipping to change at page 18, line 20 ¶ | skipping to change at page 21, line 16 ¶ | |||
Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547, | Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547, | |||
DOI 10.17487/RFC8547, May 2019, | DOI 10.17487/RFC8547, May 2019, | |||
<https://www.rfc-editor.org/info/rfc8547>. | <https://www.rfc-editor.org/info/rfc8547>. | |||
[RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, | [RFC8548] 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)", RFC 8548, DOI 10.17487/RFC8548, May 2019, | (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, | |||
<https://www.rfc-editor.org/info/rfc8548>. | <https://www.rfc-editor.org/info/rfc8548>. | |||
[WireGuard] | [WireGuard] | |||
Donenfeld, J., "WireGuard -- Next Generation Kernel | Donenfeld, J.A., "WireGuard -- Next Generation Kernel | |||
Network Tunnel", | Network Tunnel", | |||
<https://www.wireguard.com/papers/wireguard.pdf>. | <https://www.wireguard.com/papers/wireguard.pdf>. | |||
Authors' Addresses | Authors' Addresses | |||
Theresa Enghardt | Theresa Enghardt | |||
TU Berlin | TU Berlin | |||
Marchstr. 23 | Marchstr. 23 | |||
10587 Berlin | 10587 Berlin | |||
Germany | Germany | |||
Email: theresa@inet.tu-berlin.de | Email: ietf@tenghardt.net | |||
Tommy Pauly | Tommy Pauly | |||
Apple Inc. | Apple Inc. | |||
One Apple Park Way | One Apple Park Way | |||
Cupertino, California 95014 | Cupertino, California 95014, | |||
United States of America | United States of America | |||
Email: tpauly@apple.com | Email: tpauly@apple.com | |||
Colin Perkins | Colin Perkins | |||
University of Glasgow | University of Glasgow | |||
School of Computing Science | School of Computing Science | |||
Glasgow G12 8QQ | Glasgow G12 8QQ | |||
United Kingdom | United Kingdom | |||
skipping to change at page 19, line 4 ¶ | skipping to change at page 21, line 45 ¶ | |||
Email: tpauly@apple.com | Email: tpauly@apple.com | |||
Colin Perkins | Colin Perkins | |||
University of Glasgow | University of Glasgow | |||
School of Computing Science | School of Computing Science | |||
Glasgow G12 8QQ | Glasgow G12 8QQ | |||
United Kingdom | United Kingdom | |||
Email: csp@csperkins.org | Email: csp@csperkins.org | |||
Kyle Rose | Kyle Rose | |||
Akamai Technologies, Inc. | Akamai Technologies, Inc. | |||
150 Broadway | 150 Broadway | |||
Cambridge, MA 02144 | Cambridge, MA 02144, | |||
United States of America | United States of America | |||
Email: krose@krose.org | Email: krose@krose.org | |||
Christopher A. Wood (editor) | Christopher A. Wood (editor) | |||
Apple Inc. | Apple Inc. | |||
One Apple Park Way | One Apple Park Way | |||
Cupertino, California 95014 | Cupertino, California 95014, | |||
United States of America | United States of America | |||
Email: cawood@apple.com | Email: cawood@apple.com | |||
End of changes. 136 change blocks. | ||||
232 lines changed or deleted | 356 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/ |