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