draft-ietf-taps-transport-security-04.txt | draft-ietf-taps-transport-security-05.txt | |||
---|---|---|---|---|
Network Working Group T. Pauly | Network Working Group C. Wood, Ed. | |||
Internet-Draft Apple Inc. | Internet-Draft Apple Inc. | |||
Intended status: Informational C. Perkins | Intended status: Informational T. Enghardt | |||
Expires: May 9, 2019 University of Glasgow | Expires: August 30, 2019 TU Berlin | |||
T. Pauly | ||||
Apple Inc. | ||||
C. Perkins | ||||
University of Glasgow | ||||
K. Rose | K. Rose | |||
Akamai Technologies, Inc. | Akamai Technologies, Inc. | |||
C. Wood | February 26, 2019 | |||
Apple Inc. | ||||
November 05, 2018 | ||||
A Survey of Transport Security Protocols | A Survey of Transport Security Protocols | |||
draft-ietf-taps-transport-security-04 | draft-ietf-taps-transport-security-05 | |||
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 + | |||
TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with | TLS), tcpcrypt, Internet Key Exchange with Encapsulating Security | |||
Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and | Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP, | |||
WireGuard. This survey is not limited to protocols developed within | MinimalT. This survey is not limited to protocols developed within | |||
the scope or context of the IETF, and those included represent a | the scope or context of the IETF, and those included represent a | |||
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 http://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 9, 2019. | This Internet-Draft will expire on August 30, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2019 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 | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
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 . . . . . . . . . . . . . . . . . . 10 | 4.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 11 | |||
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 . . . . . . . . . . . . . . . . 11 | 4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 12 | |||
4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 11 | 4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 12 | |||
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 . . . . . . . . . . . . . . . . . . 13 | 4.4.2. Security Features . . . . . . . . . . . . . . . . . . 14 | |||
4.4.3. Protocol Dependencies . . . . . . . . . . . . . . . . 14 | 4.4.3. Protocol Dependencies . . . . . . . . . . . . . . . . 14 | |||
4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 14 | 4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 15 | |||
4.5.1. Protocol description . . . . . . . . . . . . . . . . 14 | 4.5.1. Protocol description . . . . . . . . . . . . . . . . 15 | |||
4.5.2. Security Features . . . . . . . . . . . . . . . . . . 15 | 4.5.2. Security Features . . . . . . . . . . . . . . . . . . 16 | |||
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 . . . . . . . . . . . . . . . . . . . . . . . . 16 | 4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
4.6.1. Protocol Description . . . . . . . . . . . . . . . . 16 | 4.6.1. Protocol Description . . . . . . . . . . . . . . . . 17 | |||
4.6.2. Security Features . . . . . . . . . . . . . . . . . . 17 | 4.6.2. Security Features . . . . . . . . . . . . . . . . . . 18 | |||
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 . . . . . . . . . . . . . . . . . . . . . . . . 19 | 4.8. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
4.8.1. Protocol Description . . . . . . . . . . . . . . . . 19 | 4.8.1. Protocol Description . . . . . . . . . . . . . . . . 20 | |||
4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 20 | 4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 21 | |||
4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 20 | 4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 21 | |||
4.9. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 20 | 4.9. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
4.9.1. Protocol Description . . . . . . . . . . . . . . . . 20 | 4.9.1. Protocol Description . . . . . . . . . . . . . . . . 22 | |||
4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 22 | 4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 22 | |||
4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 22 | 4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 23 | |||
5. Security Features and Transport Dependencies . . . . . . . . 22 | 4.10. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 22 | 4.10.1. Protocol Description . . . . . . . . . . . . . . . . 23 | |||
5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 23 | 4.10.2. Protocol Features . . . . . . . . . . . . . . . . . 24 | |||
5.3. Optional Feature Availability . . . . . . . . . . . . . . 24 | 4.10.3. Protocol Dependencies . . . . . . . . . . . . . . . 24 | |||
6. Transport Security Protocol Interfaces . . . . . . . . . . . 26 | 5. Security Features and Application Dependencies . . . . . . . 24 | |||
6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 26 | 5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 25 | |||
6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 27 | 5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 25 | |||
6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 27 | 5.3. Optional Feature Availability . . . . . . . . . . . . . . 27 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 | 6. Transport Security Protocol Interfaces . . . . . . . . . . . 29 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 | 6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 29 | |||
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28 | 6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 30 | |||
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 | 6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 30 | |||
11. Normative References . . . . . . . . . . . . . . . . . . . . 28 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 | |||
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31 | ||||
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 | ||||
11. Normative References . . . . . . . . . . . . . . . . . . . . 31 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 | ||||
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 | |||
Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + | Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + | |||
TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with | TLS), tcpcrypt, Internet Key Exchange with Encapsulating Security | |||
Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and | Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP, and | |||
WireGuard. For each protocol, this document provides a brief | MinimalT. For each protocol, this document provides a brief | |||
description, the security features it provides, and the dependencies | description, the security features it provides, and the dependencies | |||
it has on the underlying transport. This is followed by defining the | it has on the underlying transport. This is followed by defining the | |||
set of transport security features shared by these protocols. | set of transport security features shared by these protocols. | |||
Finally, we distill the application and transport interfaces provided | Finally, we distill the application and transport interfaces provided | |||
by the transport security protocols. | by the transport security protocols. | |||
Selected protocols represent a superset of functionality and features | Selected protocols represent a superset of functionality and features | |||
a TAPS system may need to support, both internally and externally - | a TAPS system may need to support, both internally and externally - | |||
via an API - for applications [I-D.ietf-taps-arch]. Ubiquitous IETF | via an API - for applications [I-D.ietf-taps-arch]. Ubiquitous IETF | |||
protocols such as (D)TLS, as well as non-standard protocols such as | protocols such as (D)TLS, as well as non-standard protocols such as | |||
skipping to change at page 5, line 49 ¶ | skipping to change at page 6, line 5 ¶ | |||
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. Protocol security (and | discussed in the remainder of this document. Protocol security (and | |||
privacy) properties that are unrelated to the API surface exposed by | privacy) properties that are unrelated to the API surface exposed by | |||
such protocols, such as client or server identity hiding, are not | such protocols, such as client or server identity hiding, are not | |||
listed here as features. | listed here as features. | |||
o Forward-secure key establishment: Cryptographic key establishment | o Forward-secure session key establishment: Cryptographic key | |||
with forward secure properties. | establishment 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 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 Unilateral responder authentication: Required authentication for | ||||
the responder of a connection. | ||||
o Mutual authentication: Connection establishment wherein both | o Mutual authentication: Connection establishment wherein both | |||
endpoints are authenticated. | endpoints are authenticated. | |||
o Application-layer authentication delegation: Out-of-band peer | o Application authentication delegation: Out-of-band peer | |||
authentication performed by applications outside of the connection | authentication performed by applications outside of the connection | |||
establishment. | establishment. | |||
o Record (channel or datagram) confidentiality and integrity: | o Record (channel or datagram) confidentiality and integrity: | |||
Encryption and authentication of application plaintext bytes sent | Encryption and authentication of application plaintext bytes sent | |||
between peers over a channel or in individual datagrams. | between peers over a channel or in individual datagrams. | |||
o Partial record confidentiality: Encryption of some portion of | o Partial record confidentiality: Encryption of some portion of | |||
records. | records. | |||
skipping to change at page 8, line 40 ¶ | skipping to change at page 8, line 46 ¶ | |||
Once a session is disconnected all session keying material must be | Once a session is disconnected all session keying material must be | |||
destroyed, with the exception of secrets previously established | destroyed, with the exception of secrets previously established | |||
expressly for purposes of session resumption. TLS supports stateful | expressly for purposes of session resumption. TLS supports stateful | |||
and stateless resumption. (Here, "state" refers to bookkeeping on a | and stateless resumption. (Here, "state" refers to bookkeeping on a | |||
per-session basis by the server. It is assumed that the client must | per-session basis by the server. It is assumed that the client must | |||
always store some state information in order to resume a session.) | always store some state information in order to resume a session.) | |||
4.1.2. Security Features | 4.1.2. Security Features | |||
o Forward-secure key establishment. | o Forward-secure session key establishment. | |||
o Cryptographic algorithm negotiation. | o Cryptographic algorithm negotiation. | |||
o Stateful and stateless cross-connection session resumption. | o Stateful and stateless cross-connection session resumption. | |||
o Session caching and management. | o Session caching and management. | |||
o Peer authentication (Certificate, raw public key, and pre-shared | o Peer authentication (Certificate, raw public key, and pre-shared | |||
key). | key). | |||
o Mandatory server authentication, optional client authentication. | o Unilateral responder authentication. | |||
o Mutual authentication. | ||||
o Application authentication delegation. | o Application authentication delegation. | |||
o Record (channel) confidentiality and integrity. | o Record (channel) confidentiality and integrity. | |||
o Record replay prevention. | o Record replay prevention. | |||
o Application-layer feature negotiation. | o Application-layer feature negotiation. | |||
o Configuration extensions. | o Configuration extensions. | |||
skipping to change at page 10, line 30 ¶ | skipping to change at page 10, line 39 ¶ | |||
o Record (datagram) confidentiality and integrity. | o Record (datagram) confidentiality and integrity. | |||
o Out-of-order record receipt. | o Out-of-order record receipt. | |||
o DoS mitigation (cookie-based). | o DoS mitigation (cookie-based). | |||
See also the features from TLS. | See also the features from TLS. | |||
4.2.3. Protocol Dependencies | 4.2.3. Protocol Dependencies | |||
o DTLS relies on UDP. | ||||
o The DTLS record protocol explicitly encodes record lengths, so | o The DTLS record protocol explicitly encodes record lengths, so | |||
although it runs over a datagram transport, it does not rely on | although it runs over a datagram transport, it does not rely on | |||
the transport protocol's framing beyond requiring transport-level | the transport protocol's framing beyond requiring transport-level | |||
reconstruction of datagrams fragmented over packets. (Note: DTLS | reconstruction of datagrams fragmented over packets. (Note: DTLS | |||
1.3 short header records omit the explicit length field.) | 1.3 short header records omit the explicit length field.) | |||
o UDP 4-tuple uniqueness, or the connection identifier extension, | o UDP 4-tuple uniqueness, or the connection identifier extension, | |||
for demultiplexing. | for demultiplexing. | |||
o Path MTU discovery. | o Path MTU discovery. | |||
o For the handshake: Reliable, in-order transport. DTLS provides | ||||
its own reliability. | ||||
4.3. (IETF) QUIC with TLS | 4.3. (IETF) QUIC with TLS | |||
QUIC (Quick UDP Internet Connections) is a new standards-track | QUIC (Quick UDP Internet Connections) is a new standards-track | |||
transport protocol that runs over UDP, loosely based on Google's | transport protocol that runs over UDP, loosely based on Google's | |||
original proprietary gQUIC protocol [I-D.ietf-quic-transport]. (See | original proprietary gQUIC protocol [I-D.ietf-quic-transport]. (See | |||
Section 4.3.4 for more details.) The QUIC transport layer itself | Section 4.3.4 for more details.) The QUIC transport layer itself | |||
provides support for data confidentiality and integrity. This | provides support for data confidentiality and integrity. This | |||
requires keys to be derived with a separate handshake protocol. A | requires keys to be derived with a separate handshake protocol. A | |||
mapping for QUIC over TLS 1.3 [I-D.ietf-quic-tls] has been specified | mapping for QUIC over TLS 1.3 [I-D.ietf-quic-tls] has been specified | |||
to provide this handshake. | to provide this handshake. | |||
skipping to change at page 11, line 47 ¶ | skipping to change at page 12, line 12 ¶ | |||
See also the properties of TLS. | See also the properties of TLS. | |||
4.3.3. Protocol Dependencies | 4.3.3. Protocol Dependencies | |||
o QUIC transport relies on UDP. | o QUIC transport relies on UDP. | |||
o QUIC transport relies on TLS 1.3 for key exchange, peer | o QUIC transport relies on TLS 1.3 for key exchange, peer | |||
authentication, and shared secret derivation. | authentication, and shared secret derivation. | |||
o For the handshake: Reliable, in-order transport. QUIC provides | ||||
its own reliability. | ||||
4.3.4. Variant: Google QUIC | 4.3.4. Variant: 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. | |||
skipping to change at page 12, line 22 ¶ | skipping to change at page 12, line 39 ¶ | |||
creating tunnels (tunnel-mode) or for direct transport connections | creating tunnels (tunnel-mode) or for direct transport connections | |||
(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. | |||
4.4.1. Protocol descriptions | 4.4.1. Protocol descriptions | |||
4.4.1.1. IKEv2 | 4.4.1.1. IKEv2 | |||
IKEv2 is a control protocol that runs on UDP port 500. Its primary | IKEv2 is a control protocol that runs on UDP ports 500 or 4500 and | |||
goal is to generate keys for Security Associations (SAs). An SA | TCP port 4500. Its primary goal is to generate keys for Security | |||
contains shared (cryptographic) information used for establishing | Associations (SAs). An SA contains shared (cryptographic) | |||
other SAs or keying ESP; See Section 4.4.1.2. IKEv2 first uses a | information used for establishing other SAs or keying ESP; See | |||
Diffie-Hellman key exchange to generate keys for the "IKE SA", which | Section 4.4.1.2. IKEv2 first uses a Diffie-Hellman key exchange to | |||
is a set of keys used to encrypt further IKEv2 messages. It then | generate keys for the "IKE SA", which is a set of keys used to | |||
goes through a phase of authentication in which both peers present | encrypt further IKEv2 messages. IKE then performs a phase of | |||
blobs signed by a shared secret or private key, after which another | authentication in which both peers present blobs signed by a shared | |||
set of keys is derived, referred to as the "Child SA". These Child | secret or private key that authenticates the entire IKE exchange and | |||
SA keys are used by ESP. | the IKE identities. IKE then derives further sets of keys on demand, | |||
which together with traffic policies are referred to as the "Child | ||||
SA". These Child SA keys are used by ESP. | ||||
IKEv2 negotiates which protocols are acceptable to each peer for both | IKEv2 negotiates which protocols are acceptable to each peer for both | |||
the IKE and Child SAs using "Proposals". Each proposal may contain | the IKE and Child SAs using "Proposals". Each proposal specifies an | |||
an encryption algorithm, an authentication algorithm, a Diffie- | encryption and authentication algorithm, or an AEAD algorithm, a | |||
Hellman group, and (for IKE SAs only) a pseudorandom function | Diffie-Hellman group, and (for IKE SAs only) a pseudorandom function | |||
algorithm. Each peer may support multiple proposals, and the most | algorithm. Each peer may support multiple proposals, and the most | |||
preferred mutually supported proposal is chosen during the handshake. | preferred mutually supported proposal is chosen during the handshake. | |||
The authentication phase of IKEv2 may use Shared Secrets, | The authentication phase of IKEv2 may use Shared Secrets, | |||
Certificates, Digital Signatures, or an EAP (Extensible | Certificates, Digital Signatures, or an EAP (Extensible | |||
Authentication Protocol) method. At a minimum, IKEv2 takes two round | Authentication Protocol) method. At a minimum, IKEv2 takes two round | |||
trips to set up both an IKE SA and a Child SA. If EAP is used, this | trips to set up both an IKE SA and a Child SA. If EAP is used, this | |||
exchange may be expanded. | exchange may be expanded. | |||
Any SA used by IKEv2 can be rekeyed upon expiration, which is usually | Any SA used by IKEv2 can be rekeyed before expiration, which is | |||
based either on time or number of bytes encrypted. | usually based either on time or number of bytes encrypted. | |||
There is an extension to IKEv2 that allows session resumption | There is an extension to IKEv2 that allows session resumption | |||
[RFC5723]. | [RFC5723]. | |||
MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a | MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a | |||
set of Security Associations to migrate over different addresses and | set of Security Associations to migrate over different outer IP | |||
interfaces [RFC4555]. | addresses and interfaces [RFC4555]. | |||
When UDP is not available or well-supported on a network, IKEv2 may | When UDP is not available or well-supported on a network, IKEv2 may | |||
be encapsulated in TCP [RFC8229]. | be encapsulated in TCP [RFC8229]. | |||
4.4.1.2. ESP | 4.4.1.2. ESP | |||
ESP is a protocol that encrypts and authenticates IPv4 and IPv6 | ESP is a protocol that encrypts and authenticates IPv4 and IPv6 | |||
packets. The keys used for both encryption and authentication can be | packets. The keys used for both encryption and authentication can be | |||
derived from an IKEv2 exchange. ESP Security Associations come as | derived from an IKEv2 exchange. ESP Security Associations come as | |||
pairs, one for each direction between two peers. Each SA is | pairs, one for each direction between two peers. Each SA is | |||
skipping to change at page 13, line 43 ¶ | skipping to change at page 14, line 14 ¶ | |||
ESP packets may be sent directly over IP, but where network | ESP packets may be sent directly over IP, but where network | |||
conditions warrant (e.g., when a NAT is present or when a firewall | conditions warrant (e.g., when a NAT is present or when a firewall | |||
blocks such packets) they may be encapsulated in UDP [RFC3948] or TCP | blocks such packets) they may be encapsulated in UDP [RFC3948] or TCP | |||
[RFC8229]. | [RFC8229]. | |||
4.4.2. Security Features | 4.4.2. Security Features | |||
4.4.2.1. IKEv2 | 4.4.2.1. IKEv2 | |||
o Forward-secure key establishment. | o Forward-secure session key establishment. | |||
o Cryptographic algorithm negotiation. | o Cryptographic algorithm negotiation. | |||
o Peer authentication (Certificate, raw public key, pre-shared key, | o Peer authentication (certificate, raw public key, pre-shared key, | |||
and EAP). | and EAP). | |||
o Unilateral responder authentication. | ||||
o Mutual authentication. | o Mutual authentication. | |||
o Record (datagram) confidentiality and integrity. | o Record (datagram) confidentiality and integrity. | |||
o Session resumption. | o Session resumption. | |||
o Connection mobility. | o Connection mobility. | |||
o DoS mitigation (cookie-based). | o DoS mitigation (cookie-based). | |||
skipping to change at page 15, line 44 ¶ | skipping to change at page 16, line 20 ¶ | |||
the signaling plane. The combination of a mutually authenticated | the signaling plane. The combination of a mutually authenticated | |||
DTLS key exchange on the media path and a fingerprint sent in the | DTLS key exchange on the media path and a fingerprint sent in the | |||
signalling channel protects against active attacks on the media, | signalling channel protects against active attacks on the media, | |||
provided the signalling can be trusted. Signalling needs to be | provided the signalling can be trusted. Signalling needs to be | |||
protected as described in, for example, SIP [RFC3261] Authenticated | protected as described in, for example, SIP [RFC3261] Authenticated | |||
Identity Management [RFC4474] or the WebRTC security architecture | Identity Management [RFC4474] or the WebRTC security architecture | |||
[I-D.ietf-rtcweb-security-arch], to provide complete system security. | [I-D.ietf-rtcweb-security-arch], to provide complete system security. | |||
4.5.2. Security Features | 4.5.2. Security Features | |||
o Forward-secure key establishment. | o Forward-secure session key establishment. | |||
o Cryptographic algorithm negotiation. | o Cryptographic algorithm negotiation. | |||
o Mutual authentication. | o Mutual authentication. | |||
o Partial datagram confidentiality. (Packet headers are not | o Partial datagram confidentiality. (Packet headers are not | |||
encrypted.) | encrypted.) | |||
o Optional authentication of data packets. | o Optional authentication of data packets. | |||
o Mandatory authentication of control packets. | o Mandatory authentication of control packets. | |||
o Out-of-order record receipt. | o Out-of-order record receipt. | |||
4.5.3. Protocol Dependencies | 4.5.3. Protocol Dependencies | |||
o Secure RTP can run over UDP or TCP. | ||||
o External key derivation and management protocol, e.g., DTLS | o External key derivation and management protocol, e.g., DTLS | |||
[RFC5763]. | [RFC5763]. | |||
o External identity management protocol, e.g., SIP Authenticated | o External identity management protocol, e.g., SIP Authenticated | |||
Identity Management [RFC4474], WebRTC Security Architecture | Identity Management [RFC4474], WebRTC Security Architecture | |||
[I-D.ietf-rtcweb-security-arch]. | [I-D.ietf-rtcweb-security-arch]. | |||
4.5.4. Variant: ZRTP for Media Path Key Agreement | 4.5.4. Variant: ZRTP for Media Path Key Agreement | |||
ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It | ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It | |||
skipping to change at page 16, line 43 ¶ | skipping to change at page 17, line 22 ¶ | |||
requires endpoints to display a short authentication string that the | requires endpoints to display a short authentication string that the | |||
users must read and verbally compare to validate the hashes and | users must read and verbally compare to validate the hashes and | |||
ensure security. Endpoints cache some key material after the first | ensure security. Endpoints cache some key material after the first | |||
call to use in subsequent calls; this is mixed in with the Diffie- | call to use in subsequent calls; this is mixed in with the Diffie- | |||
Hellman shared secret, so the short authentication string need only | Hellman shared secret, so the short authentication string need only | |||
be checked once for a given user. This gives key continuity | be checked once for a given user. This gives key continuity | |||
properties analogous to the secure shell (ssh) [RFC4253]. | properties analogous to the secure shell (ssh) [RFC4253]. | |||
4.6. tcpcrypt | 4.6. tcpcrypt | |||
Tcpcrypt is a lightweight extension to the TCP protocol to enable | Tcpcrypt is a lightweight extension to the TCP protocol for | |||
opportunistic encryption with hooks available to the application | opportunistic encryption. Applications may use tcpcrypt's unique | |||
layer for implementation of endpoint authentication. | session ID for further application-level authentication. Absent this | |||
authentication, tcpcrypt is vulnerable to active attacks. | ||||
4.6.1. Protocol Description | 4.6.1. Protocol Description | |||
Tcpcrypt extends TCP to enable opportunistic encryption between the | Tcpcrypt extends TCP to enable opportunistic encryption between the | |||
two ends of a TCP connection [I-D.ietf-tcpinc-tcpcrypt]. It is a | two ends of a TCP connection [I-D.ietf-tcpinc-tcpcrypt]. It is a | |||
family of TCP encryption protocols (TEP), distinguished by key | family of TCP encryption protocols (TEP), distinguished by key | |||
exchange algorithm. The use of a TEP is negotiated with a TCP option | exchange algorithm. The use of a TEP is negotiated with a TCP option | |||
during the initial TCP handshake via the mechanism described by TCP | during the initial TCP handshake via the mechanism described by TCP | |||
Encryption Negotiation Option (ENO) [I-D.ietf-tcpinc-tcpeno]. In the | Encryption Negotiation Option (ENO) [I-D.ietf-tcpinc-tcpeno]. In the | |||
case of initial session establishment, once a tcpcrypt TEP has been | case of initial session establishment, once a tcpcrypt TEP has been | |||
skipping to change at page 17, line 36 ¶ | skipping to change at page 18, line 16 ¶ | |||
option during the TCP handshake. Given the length constraints | option during the TCP handshake. Given the length constraints | |||
imposed by TCP options, unlike stateless resumption mechanisms (such | imposed by TCP options, unlike stateless resumption mechanisms (such | |||
as that provided by session tickets in TLS) resumption in tcpcrypt | as that provided by session tickets in TLS) resumption in tcpcrypt | |||
requires the maintenance of state on the server, and so successful | requires the maintenance of state on the server, and so successful | |||
resumption across a pool of servers implies shared state. | resumption across a pool of servers implies shared state. | |||
Owing to middlebox ossification issues, tcpcrypt only protects the | Owing to middlebox ossification issues, tcpcrypt only protects the | |||
payload portion of a TCP packet. It does not encrypt any header | payload portion of a TCP packet. It does not encrypt any header | |||
information, such as the TCP sequence number. | information, such as the TCP sequence number. | |||
Tcpcrypt exposes a universally-unique connection-specific session ID | ||||
to the application, suitable for application-level endpoint | ||||
authentication either in-band or out-of-band. | ||||
4.6.2. Security Features | 4.6.2. Security Features | |||
o Forward-secure key establishment. | o Forward-secure session 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 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 | |||
WireGuard is a layer 3 protocol designed to complement or replace | WireGuard is a layer 3 protocol designed as an alternative to IPsec | |||
IPsec [WireGuard] for certain use cases. It uses UDP to encapsulate | [WireGuard] for certain use cases. It uses UDP to encapsulate IP | |||
IP datagrams between peers. Unlike most transport security | datagrams between peers. Unlike most transport security protocols, | |||
protocols, which rely on PKI for peer authentication, WireGuard | which rely on PKI for peer authentication, WireGuard authenticates | |||
authenticates peers using pre-shared public keys delivered out-of- | peers using pre-shared public keys delivered out-of-band, each of | |||
band, each of which is bound to one or more IP addresses. Moreover, | which is bound to one or more IP addresses. Moreover, as a protocol | |||
as a protocol suited for VPNs, WireGuard offers no extensibility, | suited for VPNs, WireGuard offers no extensibility, negotiation, or | |||
negotiation, or cryptographic agility. | cryptographic agility. | |||
4.7.1. Protocol description | 4.7.1. Protocol description | |||
WireGuard is a simple VPN protocol that binds a pre-shared public key | WireGuard is a simple VPN protocol that binds a pre-shared public key | |||
to one or more IP addresses. Users configure WireGuard by | to one or more IP addresses. Users configure WireGuard by | |||
associating peer public keys with IP addresses. These mappings are | associating peer public keys with IP addresses. These mappings are | |||
stored in a CryptoKey Routing Table. (See Section 2 of [WireGuard] | stored in a CryptoKey Routing Table. (See Section 2 of [WireGuard] | |||
for more details and sample configurations.) These keys are used | for more details and sample configurations.) These keys are used | |||
upon WireGuard packet transmission and reception. For example, upon | upon WireGuard packet transmission and reception. For example, upon | |||
receipt of a Handshake Initiation message, receivers use the static | receipt of a Handshake Initiation message, receivers use the static | |||
skipping to change at page 19, line 11 ¶ | skipping to change at page 19, line 35 ¶ | |||
WireGuard is designed to be entirely stateless, modulo the CryptoKey | WireGuard is designed to be entirely stateless, modulo the CryptoKey | |||
routing table, which has size linear with the number of trusted | routing table, which has size linear with the number of trusted | |||
peers. If a WireGuard receiver is under heavy load and cannot | peers. If a WireGuard receiver is under heavy load and cannot | |||
process a packet, e.g., cannot spare CPU cycles for point | process a packet, e.g., cannot spare CPU cycles for point | |||
multiplication, it can reply with a cookie similar to DTLS and IKEv2. | multiplication, it can reply with a cookie similar to DTLS and IKEv2. | |||
This cookie only proves IP address ownership. Any rate limiting | This cookie only proves IP address ownership. Any rate limiting | |||
scheme can be applied to packets coming from non-spoofed addresses. | scheme can be applied to packets coming from non-spoofed addresses. | |||
4.7.2. Security Features | 4.7.2. Security Features | |||
o Forward-secure key establishment. | o Forward-secure session key establishment. | |||
o Peer authentication (Public-key and PSK). | o Peer authentication (public-key and PSK). | |||
o Mutual authentication. | o Mutual authentication. | |||
o Record replay prevention (Stateful, timestamp-based). | o Record replay prevention (Stateful, timestamp-based). | |||
o DoS mitigation (cookie-based). | o DoS mitigation (cookie-based). | |||
4.7.3. Protocol Dependencies | 4.7.3. Protocol Dependencies | |||
o Datagram transport. | o Datagram transport. | |||
o Out-of-band key distribution and management. | o Out-of-band key distribution and management. | |||
4.8. MinimalT | 4.8. CurveCP | |||
MinimalT is a UDP-based transport security protocol designed to offer | ||||
confidentiality, mutual authentication, DoS prevention, and | ||||
connection mobility [MinimalT]. One major goal of the protocol is to | ||||
leverage existing protocols to obtain server-side configuration | ||||
information used to more quickly bootstrap a connection. MinimalT | ||||
uses a variant of TCP's congestion control algorithm. | ||||
4.8.1. Protocol Description | ||||
MinimalT is a secure transport protocol built on top of a widespread | ||||
directory service. Clients and servers interact with local directory | ||||
services to (a) resolve server information and (b) public ephemeral | ||||
state information, respectively. Clients connect to a local resolver | ||||
once at boot time. Through this resolver they recover the IP | ||||
address(es) and public key(s) of each server to which they want to | ||||
connect. | ||||
Connections are instances of user-authenticated, mobile sessions | ||||
between two endpoints. Connections run within tunnels between hosts. | ||||
A tunnel is a server-authenticated container that multiplexes | ||||
multiple connections between the same hosts. All connections in a | ||||
tunnel share the same transport state machine and encryption. Each | ||||
tunnel has a dedicated control connection used to configure and | ||||
manage the tunnel over time. Moreover, since tunnels are independent | ||||
of the network address information, they may be reused as both ends | ||||
of the tunnel move about the network. This does however imply that | ||||
connection establishment and packet encryption mechanisms are | ||||
coupled. | ||||
Before a client connects to a remote service, it must first establish | ||||
a tunnel to the host providing or offering the service. Tunnels are | ||||
established in 1-RTT using an ephemeral key obtained from the | ||||
directory service. Tunnel initiators provide their own ephemeral key | ||||
and, optionally, a DoS puzzle solution such that the recipient | ||||
(server) can verify the authenticity of the request and derive a | ||||
shared secret. Within a tunnel, new connections to services may be | ||||
established. | ||||
4.8.2. Protocol Features | ||||
o Forward-secure key establishment. | ||||
o DoS mitigation (puzzle-based). | ||||
o Connection mobility (based on tunnel identifiers). | ||||
Additional (orthogonal) transport features include: connection | ||||
multiplexing between hosts across shared tunnels, and congestion | ||||
control state is shared across connections between the same host | ||||
pairs. | ||||
4.8.3. Protocol Dependencies | ||||
o A DNS-like resolution service to obtain location information (an | ||||
IP address) and ephemeral keys. | ||||
o A PKI trust store for certificate validation. | ||||
4.9. 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 transport security protocols, it | Daniel J. Bernstein. Unlike other transport security protocols, it | |||
is based entirely upon highly efficient public key algorithms. This | is based entirely upon highly efficient public key algorithms. This | |||
removes many pitfalls associated with nonce reuse and key | removes many pitfalls associated with nonce reuse and key | |||
synchronization. | synchronization. | |||
4.9.1. Protocol Description | 4.8.1. Protocol Description | |||
CurveCP is a UDP-based transport security protocol. It is built on | CurveCP is a UDP-based transport security protocol. It is built on | |||
three principal features: exclusive use of public key authenticated | three principal features: exclusive use of public key authenticated | |||
encryption of packets, server-chosen cookies to prohibit memory and | encryption of packets, server-chosen cookies to prohibit memory and | |||
computation DoS at the server, and connection mobility with a client- | computation DoS at the server, and connection mobility with a client- | |||
chosen ephemeral identifier. | chosen ephemeral identifier. | |||
There are two rounds in CurveCP. In the first round, the client | There are two rounds in CurveCP. In the first round, the client | |||
sends its first initialization packet to the server, carrying its | sends its first initialization packet to the server, carrying its | |||
(possibly fresh) ephemeral public key C', with zero-padding encrypted | (possibly fresh) ephemeral public key C', with zero-padding encrypted | |||
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 public-key encryption and authentication, or "boxing", is | The use of public-key encryption and authentication, or "boxing", | |||
done to simplify problems that come with symmetric key management and | simplifies problems that come with symmetric key management and nonce | |||
synchronization. For example, it allows the sender of a message to | synchronization. For example, it allows the sender of a message to | |||
be in complete control of each message's nonce. It does not require | be in complete control of each message's nonce. It does not require | |||
either end to share secret keying material. Furthermore, it allows | either end to share secret keying material. Furthermore, it allows | |||
connections (or sessions) to be associated with unique ephemeral | connections (or sessions) to be associated with unique ephemeral | |||
public keys as a mechanism for enabling forward secrecy given the | public keys as a mechanism for enabling forward secrecy 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 | |||
skipping to change at page 21, line 48 ¶ | skipping to change at page 21, line 13 ¶ | |||
client's initial packet, encrypted under the server's long-term | client's initial packet, encrypted under the server's long-term | |||
public key, a server generates and returns a stateless cookie that | public key, a server generates and returns a stateless cookie that | |||
must be echoed back in the client's following message. This cookie | must be echoed back in the client's following message. This cookie | |||
is encrypted under the client's ephemeral public key. This stateless | is encrypted under the client's ephemeral public key. This stateless | |||
technique prevents attackers from hijacking client initialization | technique prevents attackers from hijacking client initialization | |||
packets to obtain cookie values to flood clients. (A client would | packets to obtain cookie values to flood clients. (A client would | |||
detect the duplicate cookies and reject the flooded packets.) | detect the duplicate cookies and reject the flooded packets.) | |||
Similarly, replaying the client's second packet, carrying the cookie, | Similarly, replaying the client's second packet, carrying the cookie, | |||
will be detected by the server. | will be detected by the server. | |||
CurveCP supports a weak form of client authentication. Clients are | CurveCP supports client authentication by allowing clients to send | |||
permitted to send their long-term public keys in the second | their long-term public keys in the second initialization packet. A | |||
initialization packet. A server can verify this public key and, if | server can verify this public key and, if untrusted, drop the | |||
untrusted, drop the connection and subsequent data. | connection and subsequent data. | |||
Unlike some other protocols, CurveCP data packets leave only the | Unlike some other protocols, CurveCP data packets leave only the | |||
ephemeral public key, the connection ID, and the per-message nonce in | ephemeral public key, connection ID, and per-message nonce in the | |||
the clear. Everything else is encrypted. | clear. All other data is encrypted. | |||
4.9.2. Protocol Features | 4.8.2. Protocol Features | |||
o Datagram confidentiality and integrity (via public key | o Datagram confidentiality and integrity (via public key | |||
encryption). | encryption). | |||
o Peer authentication (public-key). | ||||
o Unilateral responder authentication. | ||||
o Mutual authentication. | ||||
o Connection mobility (based on a client-chosen ephemeral | o Connection mobility (based on a client-chosen ephemeral | |||
identifier). | identifier). | |||
o Optional length-hiding and anti-amplification padding. | o Optional length-hiding and anti-amplification padding. | |||
o Source validation (cookie-based) | ||||
4.8.3. Protocol Dependencies | ||||
o An unreliable transport protocol such as UDP. | ||||
4.9. MinimalT | ||||
MinimalT is a UDP-based transport security protocol designed to offer | ||||
confidentiality, mutual authentication, DoS prevention, and | ||||
connection mobility [MinimalT]. One major goal of the protocol is to | ||||
leverage existing protocols to obtain server-side configuration | ||||
information used to more quickly bootstrap a connection. MinimalT | ||||
uses a variant of TCP's congestion control algorithm. | ||||
4.9.1. Protocol Description | ||||
MinimalT is a secure transport protocol built on top of a widespread | ||||
directory service. Clients and servers interact with local directory | ||||
services to (a) resolve server information and (b) publish ephemeral | ||||
state information, respectively. Clients connect to a local resolver | ||||
once at boot time. Through this resolver they recover the IP | ||||
address(es) and public key(s) of each server to which they want to | ||||
connect. | ||||
Connections are instances of user-authenticated, mobile sessions | ||||
between two endpoints. Connections run within tunnels between hosts. | ||||
A tunnel is a server-authenticated container that multiplexes | ||||
multiple connections between the same hosts. All connections in a | ||||
tunnel share the same transport state machine and encryption. Each | ||||
tunnel has a dedicated control connection used to configure and | ||||
manage the tunnel over time. Moreover, since tunnels are independent | ||||
of the network address information, they may be reused as both ends | ||||
of the tunnel move about the network. This does however imply that | ||||
connection establishment and packet encryption mechanisms are | ||||
coupled. | ||||
Before a client connects to a remote service, it must first establish | ||||
a tunnel to the host providing or offering the service. Tunnels are | ||||
established in 1-RTT using an ephemeral key obtained from the | ||||
directory service. Tunnel initiators provide their own ephemeral key | ||||
and, optionally, a DoS puzzle solution such that the recipient | ||||
(server) can verify the authenticity of the request and derive a | ||||
shared secret. Within a tunnel, new connections to services may be | ||||
established. | ||||
Additional (orthogonal) transport features include: connection | ||||
multiplexing between hosts across shared tunnels, and congestion | ||||
control state is shared across connections between the same host | ||||
pairs. | ||||
4.9.2. Protocol Features | ||||
o Record or datagram confidentiality and integrity. | ||||
o Forward-secure session key establishment. | ||||
o Peer authentication (public-key). | ||||
o Unilateral responder authentication. | ||||
o DoS mitigation (puzzle-based). | ||||
o Out-of-order receipt record. | ||||
o Connection mobility (based on tunnel identifiers). | ||||
4.9.3. Protocol Dependencies | 4.9.3. Protocol Dependencies | |||
o An unreliable transport protocol such as UDP. | o An unreliable transport protocol such as UDP. | |||
5. Security Features and Transport Dependencies | o A DNS-like resolution service to obtain location information (an | |||
IP address) and ephemeral keys. | ||||
o A PKI trust store for certificate validation. | ||||
4.10. OpenVPN | ||||
OpenVPN [OpenVPN] is a commonly used protocol designed as an | ||||
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 | ||||
transports. OpenVPN encapsulates either IP packets or Ethernet | ||||
frames within a secure tunnel and can run over UDP or TCP. | ||||
4.10.1. Protocol Description | ||||
OpenVPN facilitates authentication using either a pre-shared static | ||||
key or using X.509 certificates and TLS. In pre-shared key mode, | ||||
OpenVPN derives keys for encryption and authentication directly from | ||||
one or multiple symmetric keys. In TLS mode, OpenVPN encapsulates a | ||||
TLS handshake, in which both peers must present a certificate for | ||||
authentication. After the handshake, both sides contribute random | ||||
source material to derive keys for encryption and authentication | ||||
using the TLS pseudo random function (PRF). OpenVPN provides the | ||||
possibility to authenticate and encrypt the TLS handshake itself | ||||
using a pre-shared key or passphrase. Furthermore, it supports | ||||
rekeying using TLS. | ||||
After authentication and key exchange, OpenVPN encrypts payload data, | ||||
i.e., IP packets or Ethernet frames, and signs the payload using an | ||||
HMAC function. The default cipher is BlowFish [BlowFish] and the | ||||
default message digest algorithm is SHA1, but an application can | ||||
select an arbitrary cipher, key size, and message digest algorithm | ||||
for the HMAC. OpenVPN peers support cipher negotiation (NCP) since | ||||
version 2.4, in which case they will upgrade the cipher to AES- | ||||
256-GCM by default. | ||||
OpenVPN can run over TCP or UDP. When running over UDP, OpenVPN | ||||
provides a simple reliability layer for control packets such as the | ||||
TLS handshake and key exchange. It assigns sequence numbers to | ||||
packets, acknowledges packets it receives, and retransmits packets it | ||||
deems lost. Similar to DTLS, this reliability layer is not used for | ||||
data packets, which prevents the problem of two reliability | ||||
mechanisms being encapsulated within each other. When running over | ||||
TCP, OpenVPN includes the packet length in the header, which allows | ||||
the peer to deframe the TCP stream into messages. | ||||
For replay protection, OpenVPN assigns an identifier to each outgoing | ||||
packet, which is unique for the packet and the currently used key. | ||||
In pre-shared key mode or with a CFB or OFB mode cipher, OpenVPN | ||||
combines a timestamp with an incrementing sequence number into a | ||||
64-bit identifier. In TLS mode with CBC cipher mode, OpenVPN omits | ||||
the timestamp, so identifiers are only 32-bit. This is sufficient | ||||
since OpenVPN can guarantee the uniqueness of this identifier for | ||||
each key, as it can trigger rekeying if needed. | ||||
OpenVPN supports connection mobility by allowing a peer to change its | ||||
IP address during an ongoing session. When configured accordingly, a | ||||
host will accept authenticated packets for a session from any IP | ||||
address. | ||||
4.10.2. Protocol Features | ||||
o Peer authentication using certificates or pre-shared key. | ||||
o Mandatory mutual authentication. | ||||
o Connection mobility. | ||||
o Out-of-order record receipt. | ||||
o Length-hiding padding. | ||||
See also the properties of TLS. | ||||
4.10.3. Protocol Dependencies | ||||
o For control packets such as handshake and key exchange: Reliable, | ||||
in-order transport. Reliability is provided either by TCP, or by | ||||
OpenVPN's own reliability layer when using UDP. | ||||
5. Security Features and Application 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. | ubiquitous amongst common secure transport protocols. | |||
Optional features by contrast may vary from implementation to | Optional features by contrast may vary from implementation to | |||
implementation, and so an application cannot simply assume they are | implementation, and so an application cannot simply assume they are | |||
available. Applications learn of and use optional features by | available. Applications learn of and use optional features by | |||
querying for their presence and support. Optional features may not | querying for their presence and support. Optional features may not | |||
be implemented, or may be disabled if their presence impacts | be implemented, or may be disabled if their presence impacts | |||
transport services or if a necessary transport service or application | transport services or if a necessary transport service or application | |||
dependency is unavailable. In this context, an application | dependency is unavailable. | |||
dependency is one required from an application in order to function. | ||||
In this context, an application dependency is an aspect of the | ||||
security feature which can be exposed to the application. An | ||||
application dependency may be required for the security feature to | ||||
function, or it may provide additional information and control to the | ||||
application. For example, an application may need to provide | ||||
information such as keying material or authentication credentials, or | ||||
it may want to restrict which cryptographic algorithms to allow for | ||||
negotiation. | ||||
5.1. Mandatory Features | 5.1. Mandatory Features | |||
Mandatory features must be supported regardless of transport and | Mandatory features must be supported regardless of transport and | |||
application services available. | application services available. Note that not all mandatory features | |||
are provided by each surveyed protocol above. For example, tcpcrypt | ||||
does not provide responder authentication and CurveCP does not | ||||
provide forward-secure session key establishment. | ||||
o Record or datagram confidentiality and integrity. | o Record or datagram confidentiality and integrity. | |||
o Forward-secure key establishment. | * Application dependency: None. | |||
o Public-key certificate based authentication. | o Forward-secure session key establishment. | |||
* Application dependency: None. | ||||
o Unilateral responder authentication. | o Unilateral responder authentication. | |||
Note that most systems provide defailt trust stores used to | * (Optional) Application dependency: Application-provided trust | |||
authenticate peers based on certificates. In such systems, | information. System trust stores may also be used to | |||
applications need not provide any trust information. Applications | authenticate responders. | |||
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 | |||
In this section we list optional features along with their necessary | In this section we list optional features along with their necessary | |||
application dependencies, if any. | application dependencies, if any. | |||
o Pre-shared key support (PSK): | o Pre-shared key support (PSK): | |||
* Application dependency: Application provisioning and | * Application dependency: Application provisioning and | |||
distribution of pre-shared keys. | distribution of pre-shared keys. | |||
o Mutual authentication (MA): | ||||
* Application dependency: Mutual authentication credentials | ||||
required. | ||||
o Cryptographic algorithm negotiation (AN): | 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): | |||
* Application dependency: Application opt-in and policy for | * Application dependency: Application opt-in and policy for | |||
endpoint authentication. | endpoint authentication. | |||
o Mutual authentication (MA): | ||||
* Application dependency: Mutual authentication credentials | ||||
required for application support. | ||||
o DoS mitigation (DM): | o DoS mitigation (DM): | |||
* Application dependency: None. | * Application dependency: None. | |||
o Connection mobility (CM): | o Connection mobility (CM): | |||
* Application dependency: None. | * Application dependency: None. | |||
o Source validation (SV): | o Source validation (SV): | |||
skipping to change at page 24, line 14 ¶ | skipping to change at page 26, line 46 ¶ | |||
o Configuration extensions (CX): | o Configuration extensions (CX): | |||
* 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): | |||
* Application dependency: None. | * Application dependency: None. | |||
o Length-hiding padding (LHP): | o Length-hiding padding (LHP): (Optional) Application dependency: | |||
Knowledge of desired padding policies. Some protocols, such as | ||||
* Application dependency: Knowledge of desired padding policies. | IKE, can negotiate application-agnostic padding policies. | |||
o Early data support (ED): | 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 Record replay prevention (RP): | o Record replay prevention (RP): | |||
* Application dependency: None. | * Application dependency: None. | |||
skipping to change at page 27, line 25 ¶ | skipping to change at page 30, 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, MinimalT, tcpcrypt, IKEv2 | Protocols: TLS, DTLS, QUIC, tcpcrypt, IKEv2, MinimalT | |||
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, MinimalT, tcpcrypt, IKEv2 | DTLS, QUIC, tcpcrypt, IKEv2, MinimalT | |||
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 50 ¶ | skipping to change at page 31, line 50 ¶ | |||
The authors would like to thank Bob Bradley, Theresa Enghardt, | The authors would like to thank Bob Bradley, Theresa Enghardt, | |||
Frederic Jacobs, Mirja Kuehlewind, Yannick Sierra, and Brian Trammell | Frederic Jacobs, Mirja Kuehlewind, Yannick Sierra, and Brian Trammell | |||
for their input and feedback on earlier versions of this draft. | for their input and feedback on earlier versions of this draft. | |||
11. Normative References | 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.. | |||
[BlowFish] | ||||
"The Blowfish Encryption Algorithm", 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 TLS to Secure QUIC", | |||
(TLS) to Secure QUIC", draft-ietf-quic-tls-16 (work in | draft-ietf-quic-tls-18 (work in progress), January 2019. | |||
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-16 (work | and Secure Transport", draft-ietf-quic-transport-18 (work | |||
in progress), October 2018. | in progress), January 2019. | |||
[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-16 (work in progress), October 2018. | rtcweb-security-arch-18 (work in progress), February 2019. | |||
[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-14 (work in | (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-15 (work in | |||
progress), November 2018. | progress), December 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, | |||
"Connection Identifiers for DTLS 1.2", draft-ietf-tls- | "Connection Identifiers for DTLS 1.2", draft-ietf-tls- | |||
dtls-connection-id-02 (work in progress), October 2018. | dtls-connection-id-02 (work in progress), October 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-29 (work in progress), October | 1.3", draft-ietf-tls-dtls13-30 (work in progress), | |||
2018. | November 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), | |||
March 2018. | March 2018. | |||
[MinimalT] | [MinimalT] | |||
"MinimaLT -- Minimal-latency Networking Through Better | "MinimaLT -- Minimal-latency Networking Through Better | |||
Security", n.d.. | Security", n.d.. | |||
[Noise] "The Noise Protocol Framework", n.d.. | [Noise] "The Noise Protocol Framework", n.d.. | |||
[OpenVPN] "OpenVPN cryptographic layer", 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, <https://www.rfc- | DOI 10.17487/RFC2508, February 1999, | |||
editor.org/info/rfc2508>. | <https://www.rfc-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, <https://www.rfc- | DOI 10.17487/RFC3261, June 2002, | |||
editor.org/info/rfc3261>. | <https://www.rfc-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, <https://www.rfc- | DOI 10.17487/RFC3545, July 2003, | |||
editor.org/info/rfc3545>. | <https://www.rfc-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, <https://www.rfc- | DOI 10.17487/RFC4302, December 2005, | |||
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>. | |||
[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, <https://www.rfc- | DOI 10.17487/RFC4474, August 2006, | |||
editor.org/info/rfc4474>. | <https://www.rfc-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, <https://www.rfc- | DOI 10.17487/RFC5246, August 2008, | |||
editor.org/info/rfc5246>. | <https://www.rfc-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, <https://www.rfc- | DOI 10.17487/RFC5723, January 2010, | |||
editor.org/info/rfc5723>. | <https://www.rfc-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, <https://www.rfc- | DOI 10.17487/RFC5764, May 2010, | |||
editor.org/info/rfc5764>. | <https://www.rfc-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, <https://www.rfc- | DOI 10.17487/RFC5869, May 2010, | |||
editor.org/info/rfc5869>. | <https://www.rfc-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, <https://www.rfc- | DOI 10.17487/RFC6066, January 2011, | |||
editor.org/info/rfc6066>. | <https://www.rfc-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 51 ¶ | skipping to change at page 36, line 8 ¶ | |||
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, <https://www.rfc- | DOI 10.17487/RFC8095, March 2017, | |||
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>. | |||
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | |||
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | |||
<https://www.rfc-editor.org/info/rfc8446>. | <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 | |||
Christopher A. Wood (editor) | ||||
Apple Inc. | ||||
One Apple Park Way | ||||
Cupertino, California 95014 | ||||
United States of America | ||||
Email: cawood@apple.com | ||||
Theresa Enghardt | ||||
TU Berlin | ||||
Marchstr. 23 | ||||
10587 Berlin | ||||
Germany | ||||
Email: theresa@inet.tu-berlin.de | ||||
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 | |||
Email: csp@csperkins.org | Email: csp@csperkins.org | |||
Kyle Rose | Kyle Rose | |||
Akamai Technologies, Inc. | Akamai Technologies, Inc. | |||
skipping to change at page 34, line 4 ¶ | skipping to change at line 1708 ¶ | |||
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 | ||||
Apple Inc. | ||||
One Apple Park Way | ||||
Cupertino, California 95014 | ||||
United States of America | ||||
Email: cawood@apple.com | ||||
End of changes. 80 change blocks. | ||||
216 lines changed or deleted | 361 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/ |