draft-ietf-taps-transport-security-06.txt | draft-ietf-taps-transport-security-07.txt | |||
---|---|---|---|---|
Network Working Group C. Wood, Ed. | Network Working Group C. Wood, Ed. | |||
Internet-Draft Apple Inc. | Internet-Draft Apple Inc. | |||
Intended status: Informational T. Enghardt | Intended status: Informational T. Enghardt | |||
Expires: September 12, 2019 TU Berlin | Expires: January 25, 2020 TU Berlin | |||
T. Pauly | T. Pauly | |||
Apple Inc. | Apple Inc. | |||
C. Perkins | C. Perkins | |||
University of Glasgow | University of Glasgow | |||
K. Rose | K. Rose | |||
Akamai Technologies, Inc. | Akamai Technologies, Inc. | |||
March 11, 2019 | July 24, 2019 | |||
A Survey of Transport Security Protocols | A Survey of Transport Security Protocols | |||
draft-ietf-taps-transport-security-06 | draft-ietf-taps-transport-security-07 | |||
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 by describing the | |||
describing the interfaces required to add security protocols. It | interfaces required to add security protocols. This survey is not | |||
examines Transport Layer Security (TLS), Datagram Transport Layer | limited to protocols developed within the scope or context of the | |||
Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + | IETF, and those included represent a superset of features a Transport | |||
TLS), tcpcrypt, Internet Key Exchange with Encapsulating Security | Services system may need to support. | |||
Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP, | ||||
MinimalT. This survey is not limited to protocols developed within | ||||
the scope or context of the IETF, and those included represent a | ||||
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 https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on September 12, 2019. | This Internet-Draft will expire on January 25, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 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 | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
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 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Security Features . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Security Features . . . . . . . . . . . . . . . . . . . . . . 6 | |||
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 . . . . . . . . . . . . . . . . 8 | |||
4.1.2. Security Features . . . . . . . . . . . . . . . . . . 8 | 4.1.2. Security Features . . . . . . . . . . . . . . . . . . 9 | |||
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 . . . . . . . . . . . . . . . . 10 | |||
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. 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 . . . . . . . . . . . . . . . . . . 12 | |||
4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 12 | 4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 12 | |||
4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 12 | 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. IKEv2 Protocol Description . . . . . . . . . . . . . 12 | |||
4.4.2. Security Features . . . . . . . . . . . . . . . . . . 14 | 4.4.2. ESP Protocol Description . . . . . . . . . . . . . . 13 | |||
4.4.3. Protocol Dependencies . . . . . . . . . . . . . . . . 14 | 4.4.3. IKEv2 Security Features . . . . . . . . . . . . . . . 14 | |||
4.4.4. ESP Security Features . . . . . . . . . . . . . . . . 14 | ||||
4.4.5. IKEv2 Protocol Dependencies . . . . . . . . . . . . . 14 | ||||
4.4.6. ESP Protocol Dependencies . . . . . . . . . . . . . . 15 | ||||
4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 15 | 4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 15 | |||
4.5.1. Protocol description . . . . . . . . . . . . . . . . 15 | 4.5.1. Protocol description . . . . . . . . . . . . . . . . 15 | |||
4.5.2. Security Features . . . . . . . . . . . . . . . . . . 16 | 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 . . . . . 17 | |||
4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 17 | 4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
4.6.1. Protocol Description . . . . . . . . . . . . . . . . 17 | 4.6.1. Protocol Description . . . . . . . . . . . . . . . . 17 | |||
4.6.2. Security Features . . . . . . . . . . . . . . . . . . 18 | 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 . . . . . . . . . . . . . . . . 19 | |||
4.7.2. Security Features . . . . . . . . . . . . . . . . . . 19 | 4.7.2. Security Features . . . . . . . . . . . . . . . . . . 19 | |||
4.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 19 | 4.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 20 | |||
4.8. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 20 | 4.8. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
4.8.1. Protocol Description . . . . . . . . . . . . . . . . 20 | 4.8.1. Protocol Description . . . . . . . . . . . . . . . . 20 | |||
4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 21 | 4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 21 | |||
4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 21 | 4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 21 | |||
4.9. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 21 | 4.9. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
4.9.1. Protocol Description . . . . . . . . . . . . . . . . 22 | 4.9.1. Protocol Description . . . . . . . . . . . . . . . . 22 | |||
4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 22 | 4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 23 | |||
4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 23 | 4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 23 | |||
4.10. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . 23 | 4.10. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
4.10.1. Protocol Description . . . . . . . . . . . . . . . . 23 | 4.10.1. Protocol Description . . . . . . . . . . . . . . . . 23 | |||
4.10.2. Protocol Features . . . . . . . . . . . . . . . . . 24 | 4.10.2. Protocol Features . . . . . . . . . . . . . . . . . 24 | |||
4.10.3. Protocol Dependencies . . . . . . . . . . . . . . . 24 | 4.10.3. Protocol Dependencies . . . . . . . . . . . . . . . 25 | |||
5. Security Features and Application Dependencies . . . . . . . 24 | 5. Security Features and Application Dependencies . . . . . . . 25 | |||
5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 25 | 5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 25 | |||
5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 25 | 5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 26 | |||
5.3. Optional Feature Availability . . . . . . . . . . . . . . 27 | 5.3. Optional Feature Availability . . . . . . . . . . . . . . 27 | |||
6. Transport Security Protocol Interfaces . . . . . . . . . . . 29 | 6. Transport Security Protocol Interfaces . . . . . . . . . . . 29 | |||
6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 29 | 6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 29 | |||
6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 30 | 6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 30 | |||
6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 30 | 6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 30 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 | |||
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31 | 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31 | |||
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
11. Normative References . . . . . . . . . . . . . . . . . . . . 31 | 11. Informative References . . . . . . . . . . . . . . . . . . . 31 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 | |||
1. Introduction | 1. Introduction | |||
This document provides a survey of commonly used or notable network | Services and features provided by transport protocols have been | |||
security protocols, with a focus on how they interact and integrate | cataloged in [RFC8095]. This document supplements that work by | |||
with applications and transport protocols. Its goal is to supplement | surveying commonly used and notable network security protocols, and | |||
efforts to define and catalog transport services [RFC8095] by | identifying the services and features a Transport Services system (a | |||
describing the interfaces required to add security protocols. It | system that provides a transport API) needs to provide in order to | |||
examines Transport Layer Security (TLS), Datagram Transport Layer | add transport security. It examines Transport Layer Security (TLS), | |||
Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + | Datagram Transport Layer Security (DTLS), QUIC + TLS, tcpcrypt, | |||
TLS), tcpcrypt, Internet Key Exchange with Encapsulating Security | Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + | |||
Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP, and | ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimalT. For each | |||
MinimalT. For each protocol, this document provides a brief | protocol, this document provides a brief description, the security | |||
description, the security features it provides, and the dependencies | features it provides, and the dependencies it has on the underlying | |||
it has on the underlying transport. This is followed by defining the | transport. This is followed by defining the set of transport | |||
set of transport security features shared by these protocols. | security features shared by these protocols. Finally, the document | |||
Finally, we distill the application and transport interfaces provided | distills the application and transport interfaces provided by the | |||
by the transport security protocols. | 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 Transport Services system may need to support, both internally and | |||
via an API - for applications [I-D.ietf-taps-arch]. Ubiquitous IETF | externally (via an API) for applications [I-D.ietf-taps-arch]. | |||
protocols such as (D)TLS, as well as non-standard protocols such as | Ubiquitous IETF protocols such as (D)TLS, as well as non-standard | |||
Google QUIC, are both included despite overlapping features. As | protocols such as Google QUIC, are both included despite overlapping | |||
such, this survey is not limited to protocols developed within the | features. As such, this survey is not limited to protocols developed | |||
scope or context of the IETF. Outside of this candidate set, | within the scope or context of the IETF. Outside of this candidate | |||
protocols that do not offer new features are omitted. For example, | set, protocols that do not offer new features are omitted. For | |||
newer protocols such as WireGuard make unique design choices that | example, newer protocols such as WireGuard make unique design choices | |||
have important implications on applications, such as how to best | that have important implications on applications, such as how to best | |||
configure peer public keys and to delegate algorithm selection to the | configure peer public keys and to delegate algorithm selection to the | |||
system. In contrast, protocols such as ALTS [ALTS] are omitted since | system. In contrast, protocols such as ALTS [ALTS] are omitted since | |||
they do not represent features deemed unique. | they do not represent features deemed unique. | |||
Also, authentication-only protocols such as TCP-AO [RFC5925] and | Authentication-only protocols such as TCP-AO [RFC5925] and IPsec AH | |||
IPsec AH [RFC4302] are excluded from this survey. TCP-AO adds | [RFC4302] are excluded from this survey. TCP-AO adds authenticity | |||
authenticity protections to long-lived TCP connections, e.g., replay | protections to long-lived TCP connections, e.g., replay protection | |||
protection with per-packet Message Authentication Codes. (This | with per-packet Message Authentication Codes. (This protocol | |||
protocol obsoletes TCP MD5 "signature" options specified in | obsoletes TCP MD5 "signature" options specified in [RFC2385].) One | |||
[RFC2385].) One prime use case of TCP-AO is for protecting BGP | prime use case of TCP-AO is for protecting BGP connections. | |||
connections. Similarly, AH adds per-datagram authenticity and adds | Similarly, AH adds per-datagram authenticity and adds similar replay | |||
similar replay protection. Despite these improvements, neither | protection. Despite these improvements, neither protocol sees | |||
protocol sees general use and both lack critical properties important | general use and both lack critical properties important for emergent | |||
for emergent transport security protocols: confidentiality, privacy | transport security protocols: confidentiality, privacy protections, | |||
protections, and agility. Thus, we omit these and related protocols | and agility. Such protocols are thus omitted from this survey. | |||
from our survey. | ||||
2. Terminology | 2. Terminology | |||
The following terms are used throughout this document to describe the | The following terms are used throughout this document to describe the | |||
roles and interactions of transport security protocols: | roles and interactions of transport security protocols: | |||
o Transport Feature: a specific end-to-end feature that the | o Transport Feature: a specific end-to-end feature that the | |||
transport layer provides to an application. Examples include | transport layer provides to an application. Examples include | |||
confidentiality, reliable delivery, ordered delivery, message- | confidentiality, reliable delivery, ordered delivery, message- | |||
versus-stream orientation, etc. | versus-stream orientation, etc. | |||
skipping to change at page 6, line 5 ¶ | skipping to change at page 6, line 13 ¶ | |||
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 session key establishment: Cryptographic key | o Forward-secure session key establishment: Establishing | |||
establishment with forward secure properties. | cryptographic keys with forward-secure properties. | |||
o Cryptographic algorithm negotiation: Negotiate support of protocol | o Cryptographic algorithm negotiation: Negotiating support of | |||
algorithms, including: encryption, hash, MAC (PRF), and digital | protocol algorithms, including algorithms for encryption, hashing, | |||
signature algorithms. | MAC (PRF), and digital signatures. | |||
o Session caching and management: Manage session state cache used | o Session caching and management: Managing session state caches used | |||
for subsequent connections aimed towards amortizing connection | for subsequent connections, with the aim of amortizing connection | |||
establishment costs. | establishment costs. | |||
o Peer authentication (certificate, raw public key, pre-shared key, | o Peer authentication: Authenticating peers using generic or | |||
or EAP-based): Peer authentication using select or protocol- | protocol-specific mechanisms, such as certificates, raw public | |||
specific mechanisms. | keys, pre-shared keys, or EAP methods. | |||
o Unilateral responder authentication: Required authentication for | o Unilateral responder authentication: Requiring authentication for | |||
the responder of a connection. | the responder of a connection. | |||
o Mutual authentication: Connection establishment wherein both | o Mutual authentication: Establishing connections in which both | |||
endpoints are authenticated. | endpoints are authenticated. | |||
o Application authentication delegation: Out-of-band peer | o Application authentication delegation: Delegating to applications | |||
authentication performed by applications outside of the connection | out-of-band to perform peer authentication. | |||
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 | Encrypting and authenticating 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: Encrypting some portion of | |||
records. | records. | |||
o Optional record integrity: Optional authentication of certain | o Optional record integrity: Optionally authenticating certain | |||
records. | records. | |||
o Record replay prevention: Protocol detection and defense against | o Record replay prevention: Detecting and defending against record | |||
record replays, e.g., due to in-network retransmissions. | replays, which can be due to in-network retransmissions. | |||
o Early data support (starting with TLS 1.3): Transmission of | o Early data support: Transmitting application data prior to secure | |||
application data prior to connection (handshake) establishment. | connection establishment via a handshake. For TLS, this support | |||
begins with TLS 1.3. | ||||
o Connection mobility: a property of a connection that allows it to | o Connection mobility: Allowing a connection to be multihomed or | |||
be multihomed or resilient across network interface or address | resilient across network interface or address changes, such as NAT | |||
changes, e.g., NAT rebindings that occur without an endpoint's | rebindings that occur without an endpoint's knowledge. Mobility | |||
knowledge. Mobility allows cryptographic key material and other | allows cryptographic key material and other state information to | |||
state information to be reused in the event of a connection | be reused in the event of a connection change. | |||
change. | ||||
o Application-layer feature negotiation: Securely negotiate | o Application-layer feature negotiation: Securely negotiating | |||
application-specific functionality, including those necessary for | application-specific functionality. Such features may be | |||
connection handling and management, e.g., the TLS parent | necessary for further application processing, such as the TLS | |||
connection protocol type via ALPN [RFC7301] or desired application | parent connection protocol type via ALPN [RFC7301] or desired | |||
identity via SNI [RFC6066]. | application identity via SNI [RFC6066]. | |||
o Configuration extensions: Add protocol features via extensions or | o Configuration extensions: Adding protocol features via extensions | |||
configuration options. TLS extensions are a primary example of | or 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): Validating peers and | |||
and DoS mitigation via explicit proof of origin (cookie) or work | mitigating denial-of-service (DoS) attacks via explicit proof of | |||
mechanisms (puzzles). | origin (cookies) or work mechanisms (puzzles). | |||
o Length-hiding padding: Protocol-drive record padding aimed at | o Length-hiding padding: Adding padding to records in order to hide | |||
hiding plaintext message length and mitigating amplification | plaintext message length and mitigate amplification attack | |||
attack vectors. | 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 | |||
on other protocols. | on other protocols. | |||
4.1. TLS | 4.1. TLS | |||
skipping to change at page 7, line 48 ¶ | skipping to change at page 8, line 7 ¶ | |||
this session "prevents eavesdropping, tampering, and message | this session "prevents eavesdropping, tampering, and message | |||
forgery." TLS consists of a tightly coupled handshake and record | forgery." TLS consists of a tightly coupled handshake and record | |||
protocol. The handshake protocol is used to authenticate peers, | protocol. The handshake protocol is used to authenticate peers, | |||
negotiate protocol options, such as cryptographic algorithms, and | negotiate protocol options, such as cryptographic algorithms, and | |||
derive session-specific keying material. The record protocol is used | derive session-specific keying material. The record protocol is used | |||
to marshal (possibly encrypted) data from one peer to the other. | to marshal (possibly encrypted) data from one peer to the other. | |||
This data may contain handshake messages or raw application data. | This data may contain handshake messages or raw application data. | |||
4.1.1. Protocol Description | 4.1.1. Protocol Description | |||
TLS is the composition of a handshake and record protocol | TLS is the composition of a handshake and record protocol [RFC8446]. | |||
[I-D.ietf-tls-tls13]. The record protocol is designed to marshal an | The record protocol is designed to marshal an arbitrary, in-order | |||
arbitrary, in-order stream of bytes from one endpoint to the other. | stream of bytes from one endpoint to the other. It handles | |||
It handles segmenting, compressing (when enabled), and encrypting | segmenting, compressing (when enabled), and encrypting data into | |||
data into discrete records. When configured to use an authenticated | discrete records. When configured to use an authenticated encryption | |||
encryption with associated data (AEAD) algorithm, it also handles | with associated data (AEAD) algorithm, it also handles nonce | |||
nonce generation and encoding for each record. The record protocol | generation and encoding for each record. The record protocol is | |||
is hidden from the client behind a bytestream-oriented API. | hidden from the client behind a bytestream-oriented API. | |||
The handshake protocol serves several purposes, including: peer | The handshake protocol serves several purposes, including: peer | |||
authentication, protocol option (key exchange algorithm and | authentication, protocol option (key exchange algorithm and | |||
ciphersuite) negotiation, and key derivation. Peer authentication | ciphersuite) negotiation, and key derivation. Peer authentication | |||
may be mutual; however, commonly, only the server is authenticated. | may be mutual; however, commonly, only the server is authenticated. | |||
X.509 certificates are commonly used in this authentication step, | X.509 certificates are commonly used in this authentication step, | |||
though other mechanisms, such as raw public keys [RFC7250], exist. | though other mechanisms, such as raw public keys [RFC7250], exist. | |||
The client is not authenticated unless explicitly requested by the | The client is not authenticated unless explicitly requested by the | |||
server. | server. | |||
The handshake protocol is also extensible. It allows for a variety | The handshake protocol is also extensible. It allows for a variety | |||
of extensions to be included by either the client or server. These | of extensions to be included by either the client or server. These | |||
extensions are used to specify client preferences, e.g., the | extensions are used to specify client preferences, e.g., the | |||
application-layer protocol to be driven with the TLS connection | application-layer protocol to be driven with the TLS connection | |||
[RFC7301], or signals to the server to aid operation, e.g., Server | [RFC7301], or signals to the server to aid operation, e.g., Server | |||
Name Indication (SNI) [RFC6066]. Various extensions also exist to | Name Indication (SNI) [RFC6066]. Various extensions also exist to | |||
tune the parameters of the record protocol, e.g., the maximum | tune the parameters of the record protocol, e.g., the maximum | |||
fragment length [RFC6066] and record size limit | fragment length [RFC6066] and record size limit [RFC8449]. | |||
[I-D.ietf-tls-record-limit]. | ||||
Alerts are used to convey errors and other atypical events to the | Alerts are used to convey errors and other atypical events to the | |||
endpoints. There are two classes of alerts: closure and error | endpoints. There are two classes of alerts: closure and error | |||
alerts. A closure alert is used to signal to the other peer that the | alerts. A closure alert is used to signal to the other peer that the | |||
sender wishes to terminate the connection. The sender typically | sender wishes to terminate the connection. The sender typically | |||
follows a close alert with a TCP FIN segment to close the connection. | follows a close alert with a TCP FIN segment to close the connection. | |||
Error alerts are used to indicate problems with the handshake or | Error alerts are used to indicate problems with the handshake or | |||
individual records. Most errors are fatal and are followed by | individual records. Most errors are fatal and are followed by | |||
connection termination. However, warning alerts may be handled at | connection termination. However, warning alerts may be handled at | |||
the discretion of the implementation. | the discretion of the implementation. | |||
skipping to change at page 9, line 30 ¶ | skipping to change at page 9, line 38 ¶ | |||
o Application-layer feature negotiation. | o Application-layer feature negotiation. | |||
o Configuration extensions. | o Configuration extensions. | |||
o Early data support (starting with TLS 1.3). | o Early data support (starting with TLS 1.3). | |||
o Optional record-layer padding (starting with TLS 1.3). | o Optional record-layer padding (starting with TLS 1.3). | |||
4.1.3. Protocol Dependencies | 4.1.3. Protocol Dependencies | |||
o TCP for in-order, reliable transport. | o In-order, reliable bytestream transport. | |||
o (Optionally) A PKI trust store for certificate validation. | o (Optionally) A PKI trust store for certificate validation. | |||
4.2. DTLS | 4.2. DTLS | |||
DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS, | DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS, | |||
but differs in that it is designed to run over UDP instead of TCP. | but differs in that it is designed to run over unrelaible datagram | |||
Since UDP does not guarantee datagram ordering or reliability, DTLS | protocols like UDP instead of TCP. DTLS modifies the protocol to | |||
modifies the protocol to make sure it can still provide the same | make sure it can still provide the same security guarantees as TLS | |||
security guarantees as TLS. DTLS was designed to be as close to TLS | even without reliability from the transport. DTLS was designed to be | |||
as possible, so this document will assume that all properties from | as similar to TLS as possible, so this document assumes that all | |||
TLS are carried over except where specified. | properties from TLS are carried over except where specified. | |||
4.2.1. Protocol Description | 4.2.1. Protocol Description | |||
DTLS is modified from TLS to operate with the possibility of packet | DTLS is modified from TLS to operate with the possibility of packet | |||
loss, reordering, and duplication that may occur when operating over | loss, reordering, and duplication that may occur when operating over | |||
UDP. To enable out-of-order delivery of application data, the DTLS | UDP. To enable out-of-order delivery of application data, the DTLS | |||
record protocol itself has no inter-record dependencies. However, as | record protocol itself has no inter-record dependencies. However, as | |||
the handshake requires reliability, each handshake message is | the handshake requires reliability, each handshake message is | |||
assigned an explicit sequence number to enable retransmissions of | assigned an explicit sequence number to enable retransmissions of | |||
lost packets and in-order processing by the receiver. Handshake | lost packets and in-order processing by the receiver. Handshake | |||
message loss is remedied by sender retransmission after a | message loss is remedied by sender retransmission after a | |||
configurable period in which the expected response has not yet been | configurable period in which the expected response has not yet been | |||
received. | received. | |||
As the DTLS handshake protocol runs atop the record protocol, to | As the DTLS handshake protocol runs atop the record protocol, to | |||
account for long handshake messages that cannot fit within a single | account for long handshake messages that cannot fit within a single | |||
record, DTLS supports fragmentation and subsequent reconstruction of | record, DTLS supports fragmentation and subsequent reconstruction of | |||
handshake messages across records. The receiver must reassemble | handshake messages across records. The receiver must reassemble | |||
records before processing. | records before processing. | |||
DTLS relies on unique UDP 4-tuples to identify connections. Since | DTLS relies on unique UDP 4-tuples to identify connections, or a | |||
all application-layer data is encrypted, demultiplexing over the same | similar mechanism in other datagram transports. Since all | |||
application-layer data is encrypted, demultiplexing over the same | ||||
4-tuple requires the use of a connection identifier extension | 4-tuple requires the use of a connection identifier extension | |||
[I-D.ietf-tls-dtls-connection-id] to permit identification of the | [I-D.ietf-tls-dtls-connection-id] to permit identification of the | |||
correct connection-specific cryptographic context without the use of | correct connection-specific cryptographic context without the use of | |||
trial decryption. (Note that this extension is only supported in | trial decryption. (Note that this extension is only supported in | |||
DTLS 1.2 and 1.3 {{I-D.ietf-tls-dtls13}.) | DTLS 1.2 and 1.3 {{?I-D.ietf-tls-dtls13}.) | |||
Since datagrams can be replayed, DTLS provides optional anti-replay | Since datagrams can be replayed, DTLS provides optional anti-replay | |||
detection based on a window of acceptable sequence numbers [RFC6347]. | detection based on a window of acceptable sequence numbers [RFC6347]. | |||
4.2.2. Security Features | 4.2.2. Security Features | |||
o Record replay protection. | o Record replay protection. | |||
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 DTLS relies on an unreliable datagram transport. | |||
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 Uniqueness of the session within the transport flow (only one DTLS | |||
for demultiplexing. | connection on a UDP 4-tuple, for example); or else support for the | |||
connection identifier extension to enable demultiplexing. | ||||
o Path MTU discovery. | o Path MTU discovery. | |||
o For the handshake: Reliable, in-order transport. DTLS provides | o For the handshake: Reliable, in-order transport. DTLS provides | |||
its own reliability. | its own reliability. | |||
4.3. (IETF) QUIC with TLS | 4.3. QUIC with TLS | |||
QUIC (Quick UDP Internet Connections) is a new standards-track | QUIC is a new standards-track transport protocol that runs over UDP, | |||
transport protocol that runs over UDP, loosely based on Google's | loosely based on Google's original proprietary gQUIC protocol | |||
original proprietary gQUIC protocol [I-D.ietf-quic-transport]. (See | [I-D.ietf-quic-transport] (See Section 4.3.4 for more details). The | |||
Section 4.3.4 for more details.) The QUIC transport layer itself | QUIC transport layer itself provides support for data confidentiality | |||
provides support for data confidentiality and integrity. This | and integrity. This requires keys to be derived with a separate | |||
requires keys to be derived with a separate handshake protocol. A | handshake protocol. A mapping for QUIC of TLS 1.3 | |||
mapping for QUIC over TLS 1.3 [I-D.ietf-quic-tls] has been specified | [I-D.ietf-quic-tls] has been specified to provide this handshake. | |||
to provide this handshake. | ||||
4.3.1. Protocol Description | 4.3.1. Protocol Description | |||
As QUIC relies on TLS to secure its transport functions, it creates | As QUIC relies on TLS to secure its transport functions, it creates | |||
specific integration points between its security and transport | specific integration points between its security and transport | |||
functions: | functions: | |||
o Starting the handshake to generate keys and provide authentication | o Starting the handshake to generate keys and provide authentication | |||
(and providing the transport for the handshake). | (and providing the transport for the handshake). | |||
o Client address validation. | o Client address validation. | |||
o Key ready events from TLS to notify the QUIC transport. | o Key ready events from TLS to notify the QUIC transport. | |||
o Exporting secrets from TLS to the QUIC transport. | o Exporting secrets from TLS to the QUIC transport. | |||
The QUIC transport layer support multiple streams over a single | The QUIC transport layer support multiple streams over a single | |||
connection. QUIC implements a record protocol for TLS handshake | connection. QUIC implements a record protocol for TLS handshake | |||
messages to establish a connection. These messages are sent in | messages to establish a connection. These messages are sent in | |||
special INITIAL and CRYPTO frames [I-D.ietf-quic-transport], types of | CRYPTO frames [I-D.ietf-quic-transport] in Initial and Handshake | |||
which are encrypted using different keys. INITIAL frames are | packets. Initial packets are encrypted using fixed keys derived from | |||
encrypted using "fixed" keys derived from the QUIC version and public | the QUIC version and public packet information (Connection ID). | |||
packet information (Connection ID). CRYPTO frames are encrypted | Handshake packets are encrypted using TLS handshake secrets. Once | |||
using TLS handshake secrets. Once TLS completes, QUIC uses the | TLS completes, QUIC uses the resulting traffic secrets to for the | |||
resultant traffic secrets to for the QUIC connection to protect the | QUIC connection to protect the rest of the frames. QUIC supports | |||
rest of the streams. QUIC supports 0-RTT (early) data using | 0-RTT data using previously negotiated connection secrets Early data | |||
previously negotiated connection secrets. Early data is sent in | is sent in 0-RTT packets, which may be included in the same datagram | |||
0-RTT packets, which may be included in the same datagram as the | as the Initial and Handshake packets. | |||
Initial and Handshake packets. | ||||
4.3.2. Security Features | 4.3.2. Security Features | |||
o DoS mitigation (cookie-based). | o DoS mitigation (cookie-based). | |||
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. | |||
skipping to change at page 12, line 35 ¶ | skipping to change at page 12, line 45 ¶ | |||
4.4. IKEv2 with ESP | 4.4. IKEv2 with ESP | |||
IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec | IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec | |||
protocol suite that encrypts and authenticates IP packets, either for | protocol suite that encrypts and authenticates IP packets, either for | |||
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. IKEv2 Protocol Description | |||
4.4.1.1. IKEv2 | ||||
IKEv2 is a control protocol that runs on UDP ports 500 or 4500 and | IKEv2 is a control protocol that runs on UDP ports 500 or 4500 and | |||
TCP port 4500. Its primary goal is to generate keys for Security | TCP port 4500. Its primary goal is to generate keys for Security | |||
Associations (SAs). An SA contains shared (cryptographic) | Associations (SAs). An SA contains shared (cryptographic) | |||
information used for establishing other SAs or keying ESP; See | information used for establishing other SAs or keying ESP; See | |||
Section 4.4.1.2. IKEv2 first uses a Diffie-Hellman key exchange to | Section 4.4.2. IKEv2 first uses a Diffie-Hellman key exchange to | |||
generate keys for the "IKE SA", which is a set of keys used to | generate keys for the "IKE SA", which is a set of keys used to | |||
encrypt further IKEv2 messages. IKE then performs a phase of | encrypt further IKEv2 messages. IKE then performs a phase of | |||
authentication in which both peers present blobs signed by a shared | authentication in which both peers present blobs signed by a shared | |||
secret or private key that authenticates the entire IKE exchange and | secret or private key that authenticates the entire IKE exchange and | |||
the IKE identities. IKE then derives further sets of keys on demand, | the IKE identities. IKE then derives further sets of keys on demand, | |||
which together with traffic policies are referred to as the "Child | which together with traffic policies are referred to as the "Child | |||
SA". These Child SA keys are used by ESP. | 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 specifies an | the IKE and Child SAs using "Proposals". Each proposal specifies an | |||
skipping to change at page 13, line 31 ¶ | skipping to change at page 13, line 38 ¶ | |||
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 outer IP | set of Security Associations to migrate over different outer IP | |||
addresses and 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.2. ESP Protocol Description | |||
ESP is a protocol that encrypts and authenticates IPv4 and IPv6 | ESP is a protocol that encrypts and authenticates IPv4 and IPv6 | |||
packets. The keys used for both encryption and authentication can be | packets. The keys used for both encryption and authentication can be | |||
derived from an IKEv2 exchange. ESP Security Associations come as | derived from an IKEv2 exchange. ESP Security Associations come as | |||
pairs, one for each direction between two peers. Each SA is | pairs, one for each direction between two peers. Each SA is | |||
identified by a Security Parameter Index (SPI), which is marked on | identified by a Security Parameter Index (SPI), which is marked on | |||
each encrypted ESP packet. | each encrypted ESP packet. | |||
ESP packets include the SPI, a sequence number, an optional | ESP packets include the SPI, a sequence number, an optional | |||
Initialization Vector (IV), payload data, padding, a length and next | Initialization Vector (IV), payload data, padding, a length and next | |||
skipping to change at page 14, line 10 ¶ | skipping to change at page 14, line 19 ¶ | |||
Since ESP operates on IP packets, it is not directly tied to the | Since ESP operates on IP packets, it is not directly tied to the | |||
transport protocols it encrypts. This means it requires little or no | transport protocols it encrypts. This means it requires little or no | |||
change from transports in order to provide security. | change from transports in order to provide security. | |||
ESP packets may be sent directly over IP, but where network | ESP packets may be sent directly over IP, but where network | |||
conditions warrant (e.g., when a NAT is present or when a firewall | conditions warrant (e.g., when a NAT is present or when a firewall | |||
blocks such packets) they may be encapsulated in UDP [RFC3948] or TCP | blocks such packets) they may be encapsulated in UDP [RFC3948] or TCP | |||
[RFC8229]. | [RFC8229]. | |||
4.4.2. Security Features | 4.4.3. IKEv2 Security Features | |||
4.4.2.1. IKEv2 | ||||
o Forward-secure session 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 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). | |||
4.4.2.2. ESP | 4.4.4. ESP Security Features | |||
o Record confidentiality and integrity. | o Record confidentiality and integrity. | |||
o Record replay protection. | o Record replay protection. | |||
4.4.3. Protocol Dependencies | 4.4.5. IKEv2 Protocol Dependencies | |||
4.4.3.1. IKEv2 | ||||
o Availability of UDP to negotiate, or implementation support for | o Availability of UDP to negotiate, or implementation support for | |||
TCP-encapsulation. | TCP-encapsulation. | |||
o Some EAP authentication types require accessing a hardware device, | o Some EAP authentication types require accessing a hardware device, | |||
such as a SIM card; or interacting with a user, such as password | such as a SIM card; or interacting with a user, such as password | |||
prompting. | prompting. | |||
4.4.3.2. ESP | 4.4.6. ESP Protocol Dependencies | |||
o Since ESP is below transport protocols, it does not have any | o Since ESP is below transport protocols, it does not have any | |||
dependencies on the transports themselves, other than on UDP or | dependencies on the transports themselves, other than on UDP or | |||
TCP where encapsulation is employed. | TCP where encapsulation is employed. | |||
4.5. Secure RTP (with DTLS) | 4.5. Secure RTP (with DTLS) | |||
Secure RTP (SRTP) is a profile for RTP that provides confidentiality, | Secure RTP (SRTP) is a profile for RTP that provides confidentiality, | |||
message authentication, and replay protection for RTP data packets | message authentication, and replay protection for RTP data packets | |||
and RTP control protocol (RTCP) packets [RFC3711]. | and RTP control protocol (RTCP) packets [RFC3711]. | |||
skipping to change at page 17, line 30 ¶ | skipping to change at page 17, line 36 ¶ | |||
4.6. tcpcrypt | 4.6. tcpcrypt | |||
Tcpcrypt is a lightweight extension to the TCP protocol for | Tcpcrypt is a lightweight extension to the TCP protocol for | |||
opportunistic encryption. Applications may use tcpcrypt's unique | opportunistic encryption. Applications may use tcpcrypt's unique | |||
session ID for further application-level authentication. Absent this | session ID for further application-level authentication. Absent this | |||
authentication, tcpcrypt is vulnerable to active attacks. | 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 [RFC8548]. It is a family of TCP | |||
family of TCP encryption protocols (TEP), distinguished by key | encryption protocols (TEP), distinguished by key exchange algorithm. | |||
exchange algorithm. The use of a TEP is negotiated with a TCP option | The use of a TEP is negotiated with a TCP option during the initial | |||
during the initial TCP handshake via the mechanism described by TCP | TCP handshake via the mechanism described by TCP Encryption | |||
Encryption Negotiation Option (ENO) [I-D.ietf-tcpinc-tcpeno]. In the | Negotiation Option (ENO) [RFC8547]. In the case of initial session | |||
case of initial session establishment, once a tcpcrypt TEP has been | establishment, once a tcpcrypt TEP has been negotiated the key | |||
negotiated the key exchange occurs within the data segments of the | exchange occurs within the data segments of the first few packets | |||
first few packets exchanged after the handshake completes. The | exchanged after the handshake completes. The initiator of a | |||
initiator of a connection sends a list of supported AEAD algorithms, | connection sends a list of supported AEAD algorithms, a random nonce, | |||
a random nonce, and an ephemeral public key share. The responder | and an ephemeral public key share. The responder typically chooses a | |||
typically chooses a mutually-supported AEAD algorithm and replies | mutually-supported AEAD algorithm and replies with this choice, its | |||
with this choice, its own nonce, and ephemeral key share. An initial | own nonce, and ephemeral key share. An initial shared secret is | |||
shared secret is derived from the ENO handshake, the tcpcrypt | derived from the ENO handshake, the tcpcrypt handshake, and the | |||
handshake, and the initial keying material resulting from the key | initial keying material resulting from the key exchange. The traffic | |||
exchange. The traffic encryption keys on the initial connection are | encryption keys on the initial connection are derived from the shared | |||
derived from the shared secret. Connections can be re-keyed before | secret. Connections can be re-keyed before the natural AEAD limit | |||
the natural AEAD limit for a single set of traffic encryption keys is | for a single set of traffic encryption keys is reached. | |||
reached. | ||||
Each tcpcrypt session is associated with a ladder of resumption IDs, | Each tcpcrypt session is associated with a ladder of resumption IDs, | |||
each derived from the respective entry in a ladder of shared secrets. | each derived from the respective entry in a ladder of shared secrets. | |||
These resumption IDs can be used to negotiate a stateful resumption | These resumption IDs can be used to negotiate a stateful resumption | |||
of the session in a subsequent connection, resulting in use of a new | of the session in a subsequent connection, resulting in use of a new | |||
shared secret and traffic encryption keys without requiring a new key | shared secret and traffic encryption keys without requiring a new key | |||
exchange. Willingness to resume a session is signaled via the ENO | exchange. Willingness to resume a session is signaled via the ENO | |||
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 | |||
skipping to change at page 18, line 30 ¶ | skipping to change at page 18, line 35 ¶ | |||
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 for in-order, reliable transport. | |||
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 as an alternative to IPsec | WireGuard is a layer 3 protocol designed as an alternative to IPsec | |||
[WireGuard] for certain use cases. It uses UDP to encapsulate IP | [WireGuard] for certain use cases. It uses UDP to encapsulate IP | |||
datagrams between peers. Unlike most transport security protocols, | datagrams between peers. Unlike most transport security protocols, | |||
which rely on PKI for peer authentication, WireGuard authenticates | which rely on PKI for peer authentication, WireGuard authenticates | |||
peers using pre-shared public keys delivered out-of-band, each of | peers using pre-shared public keys delivered out-of-band, each of | |||
skipping to change at page 24, line 46 ¶ | skipping to change at page 25, line 15 ¶ | |||
4.10.3. Protocol Dependencies | 4.10.3. Protocol Dependencies | |||
o For control packets such as handshake and key exchange: Reliable, | o For control packets such as handshake and key exchange: Reliable, | |||
in-order transport. Reliability is provided either by TCP, or by | in-order transport. Reliability is provided either by TCP, or by | |||
OpenVPN's own reliability layer when using UDP. | OpenVPN's own reliability layer when using UDP. | |||
5. Security Features and Application Dependencies | 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 | |||
implementation. They were selected on the basis that they are either | Transport Services implementation. They were selected on the basis | |||
(a) required for any secure transport protocol or (b) nearly | that they are either (a) required for any secure transport protocol | |||
ubiquitous amongst common secure transport protocols. | or (b) nearly 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. | dependency is unavailable. | |||
In this context, an application dependency is an aspect of the | In this context, an application dependency is an aspect of the | |||
skipping to change at page 28, line 16 ¶ | skipping to change at page 28, line 16 ¶ | |||
| Pro | P | A | A | M | D | C | S | A | CX | SC | LH | ED | RP | OO | | | Pro | P | A | A | M | D | C | S | A | CX | SC | LH | ED | RP | OO | | |||
| toc | S | N | D | A | M | M | V | F | | | P | | | | | | toc | S | N | D | A | M | M | V | F | | | P | | | | | |||
| ol | K | | | | | | | N | | | | | | | | | ol | K | | | | | | | N | | | | | | | | |||
+-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+ | +-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+ | |||
| TLS | S | S | S | S | S | U | M | S | S | S | S | S | U | U | | | TLS | S | S | S | S | S | U | M | S | S | S | S | S | U | U | | |||
| | | | | | | * | | | | | | | | | | | | | | | | | * | | | | | | | | | | |||
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |||
| DTL | S | S | S | S | S | S | M | S | S | S | S | U | M | M | | | DTL | S | S | S | S | S | S | M | S | S | S | S | U | M | M | | |||
| S | | | | | | | | | | | | | | | | | S | | | | | | | | | | | | | | | | |||
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |||
| IET | S | S | S | S | S | S | M | S | S | S | S | S | M | M | | | QUI | S | S | S | S | S | S | M | S | S | S | S | S | M | M | | |||
| F Q | | | | | | | | | | | | | | | | | C | | | | | | | | | | | | | | | | |||
| UIC | | | | | | | | | | | | | | | | ||||
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |||
| IKE | S | S | S | M | S | S | M | S | S | S | S | U | M | M | | | IKE | S | S | S | M | S | S | M | S | S | S | S | U | M | M | | |||
| v2+ | | | | | | | | | | | | | | | | | v2+ | | | | | | | | | | | | | | | | |||
| ESP | | | | | | | | | | | | | | | | | ESP | | | | | | | | | | | | | | | | |||
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |||
| SRT | S | S | S | S | S | U | M | S | S | S | U | U | M | M | | | SRT | S | S | S | S | S | U | M | S | S | S | U | U | M | M | | |||
| P+D | | | | | | | | | | | | | | | | | P+D | | | | | | | | | | | | | | | | |||
| TLS | | | | | | | | | | | | | | | | | TLS | | | | | | | | | | | | | | | | |||
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |||
| tcp | U | S | M | U | U | U | M | U | U | S | U | U | U | U | | | tcp | U | S | M | U | U | U | M | U | U | S | U | U | U | U | | |||
skipping to change at page 31, line 23 ¶ | skipping to change at page 31, line 23 ¶ | |||
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. Privacy Considerations | 9. Privacy Considerations | |||
Analysis of how features improve or degrade privacy is intentionally | Analysis of how features improve or degrade privacy is intentionally | |||
omitted from this survey. All security protocols surveyed generally | omitted from this survey. All security protocols surveyed generally | |||
improve privacy by reducing information leakage via encryption. | improve privacy by reducing information leakage via encryption. | |||
However, varying amounts of metadata remain in the clear across each | However, varying amounts of metadata remain in the clear across each | |||
protocol. For example, client and server certificates are sent in | protocol. For example, client and server certificates are sent in | |||
cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3 | cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3 | |||
[RFC8446]. A survey of privacy features, or lack thereof, for | [RFC8446]. A survey of privacy features, or lack thereof, for | |||
various security protocols could be addressed in a separate document. | various security protocols could be addressed in a separate document. | |||
10. Acknowledgments | 10. Acknowledgments | |||
The authors would like to thank Bob Bradley, Theresa Enghardt, | The authors would like to thank Bob Bradley, Frederic Jacobs, Mirja | |||
Frederic Jacobs, Mirja Kuehlewind, Yannick Sierra, and Brian Trammell | Kuehlewind, Yannick Sierra, and Brian Trammell for their input and | |||
for their input and feedback on earlier versions of this draft. | feedback on earlier versions of this draft. | |||
11. Normative References | 11. Informative 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 TLS to Secure QUIC", | Thomson, M. and S. Turner, "Using TLS to Secure QUIC", | |||
draft-ietf-quic-tls-18 (work in progress), January 2019. | draft-ietf-quic-tls-22 (work in progress), July 2019. | |||
[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-18 (work | and Secure Transport", draft-ietf-quic-transport-22 (work | |||
in progress), January 2019. | in progress), July 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-18 (work in progress), February 2019. | rtcweb-security-arch-20 (work in progress), July 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-04 (work in | |||
progress), October 2018. | progress), July 2019. | |||
[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., Wood, C., and T. | |||
Abstract Application Layer Interface to Transport | Pauly, "An Abstract Application Layer Interface to | |||
Services", draft-ietf-taps-interface-02 (work in | Transport Services", draft-ietf-taps-interface-04 (work in | |||
progress), October 2018. | progress), July 2019. | |||
[I-D.ietf-tcpinc-tcpcrypt] | ||||
Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, | ||||
Q., and E. Smith, "Cryptographic protection of TCP Streams | ||||
(tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-15 (work in | ||||
progress), December 2018. | ||||
[I-D.ietf-tcpinc-tcpeno] | ||||
Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. | ||||
Smith, "TCP-ENO: Encryption Negotiation Option", draft- | ||||
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., and T. Fossati, "Connection | Rescorla, E., Tschofenig, H., and T. Fossati, "Connection | |||
Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- | Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- | |||
id-04 (work in progress), March 2019. | id-06 (work in progress), July 2019. | |||
[I-D.ietf-tls-dtls13] | ||||
Rescorla, E., Tschofenig, H., and N. Modadugu, "The | ||||
Datagram Transport Layer Security (DTLS) Protocol Version | ||||
1.3", draft-ietf-tls-dtls13-30 (work in progress), | ||||
November 2018. | ||||
[I-D.ietf-tls-record-limit] | ||||
Thomson, M., "Record Size Limit Extension for Transport | ||||
Layer Security (TLS)", draft-ietf-tls-record-limit-03 | ||||
(work in progress), May 2018. | ||||
[I-D.ietf-tls-tls13] | ||||
Rescorla, E., "The Transport Layer Security (TLS) Protocol | ||||
Version 1.3", draft-ietf-tls-tls13-28 (work in progress), | ||||
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.. | [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 | |||
skipping to change at page 36, line 19 ¶ | skipping to change at page 35, line 39 ¶ | |||
<https://www.rfc-editor.org/info/rfc8095>. | <https://www.rfc-editor.org/info/rfc8095>. | |||
[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation | [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation | |||
of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, | of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, | |||
August 2017, <https://www.rfc-editor.org/info/rfc8229>. | August 2017, <https://www.rfc-editor.org/info/rfc8229>. | |||
[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>. | |||
[RFC8449] Thomson, M., "Record Size Limit Extension for TLS", | ||||
RFC 8449, DOI 10.17487/RFC8449, August 2018, | ||||
<https://www.rfc-editor.org/info/rfc8449>. | ||||
[RFC8547] Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. | ||||
Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547, | ||||
DOI 10.17487/RFC8547, May 2019, | ||||
<https://www.rfc-editor.org/info/rfc8547>. | ||||
[RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, | ||||
Q., and E. Smith, "Cryptographic Protection of TCP Streams | ||||
(tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, | ||||
<https://www.rfc-editor.org/info/rfc8548>. | ||||
[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) | Christopher A. Wood (editor) | |||
End of changes. 71 change blocks. | ||||
232 lines changed or deleted | 207 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/ |