draft-ietf-taps-transport-security-01.txt | draft-ietf-taps-transport-security-02.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: November 12, 2018 University of Glasgow | Expires: January 1, 2019 University of Glasgow | |||
K. Rose | K. Rose | |||
Akamai Technologies, Inc. | Akamai Technologies, Inc. | |||
C. Wood | C. Wood | |||
Apple Inc. | Apple Inc. | |||
May 11, 2018 | June 30, 2018 | |||
A Survey of Transport Security Protocols | A Survey of Transport Security Protocols | |||
draft-ietf-taps-transport-security-01 | draft-ietf-taps-transport-security-02 | |||
Abstract | Abstract | |||
This document provides a survey of commonly used or notable network | This document provides a survey of commonly used or notable network | |||
security protocols, with a focus on how they interact and integrate | security protocols, with a focus on how they interact and integrate | |||
with applications and transport protocols. Its goal is to supplement | with applications and transport protocols. Its goal is to supplement | |||
efforts to define and catalog transport services [RFC8095] by | efforts to define and catalog transport services [RFC8095] by | |||
describing the interfaces required to add security protocols. It | describing the interfaces required to add security protocols. It | |||
examines Transport Layer Security (TLS), Datagram Transport Layer | examines Transport Layer Security (TLS), Datagram Transport Layer | |||
Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + | Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + | |||
TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with | TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with | |||
Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and | Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and | |||
WireGuard. This survey is not limited to protocols developed within | WireGuard. This survey is not limited to protocols developed within | |||
the scope or context of the IETF. | 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 November 12, 2018. | This Internet-Draft will expire on January 1, 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 | (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. Transport Security Protocol Descriptions . . . . . . . . . . 5 | 3. Security Features . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 4. Transport Security Protocol Descriptions . . . . . . . . . . 7 | |||
3.1.1. Protocol Description . . . . . . . . . . . . . . . . 6 | 4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.1.2. Protocol Features . . . . . . . . . . . . . . . . . . 7 | 4.1.1. Protocol Description . . . . . . . . . . . . . . . . 7 | |||
3.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 7 | 4.1.2. Protocol Features . . . . . . . . . . . . . . . . . . 8 | |||
3.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 4.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 9 | |||
3.2.1. Protocol Description . . . . . . . . . . . . . . . . 7 | 4.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.2.2. Protocol Features . . . . . . . . . . . . . . . . . . 8 | 4.2.1. Protocol Description . . . . . . . . . . . . . . . . 9 | |||
3.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 8 | 4.2.2. Protocol Features . . . . . . . . . . . . . . . . . . 10 | |||
3.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 9 | 4.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10 | |||
3.3.1. Protocol Description . . . . . . . . . . . . . . . . 9 | 4.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 10 | |||
3.3.2. Protocol Features . . . . . . . . . . . . . . . . . . 9 | 4.3.1. Protocol Description . . . . . . . . . . . . . . . . 10 | |||
3.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10 | 4.3.2. Protocol Features . . . . . . . . . . . . . . . . . . 11 | |||
3.3.4. Differences from Google QUIC . . . . . . . . . . . . 10 | 4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 11 | |||
3.3.5. Protocol Description . . . . . . . . . . . . . . . . 10 | 4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 11 | |||
3.3.6. Protocol Dependencies . . . . . . . . . . . . . . . . 10 | 4.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 12 | |||
3.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 10 | 4.4.1. Protocol descriptions . . . . . . . . . . . . . . . . 12 | |||
3.4.1. Protocol descriptions . . . . . . . . . . . . . . . . 10 | 4.4.2. Protocol features . . . . . . . . . . . . . . . . . . 13 | |||
3.4.2. Protocol features . . . . . . . . . . . . . . . . . . 12 | 4.4.3. Protocol dependencies . . . . . . . . . . . . . . . . 14 | |||
3.4.3. Protocol dependencies . . . . . . . . . . . . . . . . 12 | 4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 14 | |||
3.5. SRTP (with DTLS) . . . . . . . . . . . . . . . . . . . . 13 | 4.5.1. Protocol description . . . . . . . . . . . . . . . . 14 | |||
3.5.1. Protocol descriptions . . . . . . . . . . . . . . . . 13 | 4.5.2. Protocol features . . . . . . . . . . . . . . . . . . 15 | |||
3.5.2. Protocol features . . . . . . . . . . . . . . . . . . 14 | 4.5.3. Protocol dependencies . . . . . . . . . . . . . . . . 16 | |||
3.5.3. Protocol dependencies . . . . . . . . . . . . . . . . 14 | 4.5.4. Variant: ZRTP for Media Path Key Agreement . . . . . 16 | |||
3.6. Differences from ZRTP . . . . . . . . . . . . . . . . . . 15 | 4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
3.7. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 15 | 4.6.1. Protocol Description . . . . . . . . . . . . . . . . 16 | |||
3.7.1. Protocol Description . . . . . . . . . . . . . . . . 15 | 4.6.2. Protocol Features . . . . . . . . . . . . . . . . . . 17 | |||
3.7.2. Protocol Features . . . . . . . . . . . . . . . . . . 16 | 4.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 18 | |||
3.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 16 | 4.7. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
4.7.1. Protocol description . . . . . . . . . . . . . . . . 18 | ||||
3.8. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 16 | 4.7.2. Protocol features . . . . . . . . . . . . . . . . . . 19 | |||
3.8.1. Protocol description . . . . . . . . . . . . . . . . 16 | 4.7.3. Protocol dependencies . . . . . . . . . . . . . . . . 19 | |||
3.8.2. Protocol features . . . . . . . . . . . . . . . . . . 17 | 4.8. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
3.8.3. Protocol dependencies . . . . . . . . . . . . . . . . 17 | 4.8.1. Protocol Description . . . . . . . . . . . . . . . . 19 | |||
3.9. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 17 | 4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 20 | |||
3.9.1. Protocol Description . . . . . . . . . . . . . . . . 18 | 4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 20 | |||
3.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 18 | 4.9. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
3.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 19 | 4.9.1. Protocol Description . . . . . . . . . . . . . . . . 20 | |||
3.10. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 22 | |||
3.10.1. Protocol Description . . . . . . . . . . . . . . . . 19 | 4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 22 | |||
3.10.2. Protocol Features . . . . . . . . . . . . . . . . . 20 | 5. Security Features and Transport Dependencies . . . . . . . . 22 | |||
3.10.3. Protocol Dependencies . . . . . . . . . . . . . . . 20 | 5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 22 | |||
4. Security Features and Transport Dependencies . . . . . . . . 21 | 5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 23 | |||
4.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 21 | 5.3. Optional Feature Availability . . . . . . . . . . . . . . 25 | |||
4.2. Optional Features . . . . . . . . . . . . . . . . . . . . 21 | 6. Transport Security Protocol Interfaces . . . . . . . . . . . 25 | |||
5. Transport Security Protocol Interfaces . . . . . . . . . . . 23 | 6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 26 | |||
5.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 23 | 6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 27 | |||
5.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 24 | 6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 27 | |||
5.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 24 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 | 10. Normative References . . . . . . . . . . . . . . . . . . . . 28 | |||
9. Normative References . . . . . . . . . . . . . . . . . . . . 25 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 | ||||
1. Introduction | 1. Introduction | |||
This document provides a survey of commonly used or notable network | This document provides a survey of commonly used or notable network | |||
security protocols, with a focus on how they interact and integrate | security protocols, with a focus on how they interact and integrate | |||
with applications and transport protocols. Its goal is to supplement | with applications and transport protocols. Its goal is to supplement | |||
efforts to define and catalog transport services [RFC8095] by | efforts to define and catalog transport services [RFC8095] by | |||
describing the interfaces required to add security protocols. It | describing the interfaces required to add security protocols. It | |||
examines Transport Layer Security (TLS), Datagram Transport Layer | examines Transport Layer Security (TLS), Datagram Transport Layer | |||
Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + | Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + | |||
TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with | TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with | |||
Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and | Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and | |||
WireGuard. This survey is not limited to protocols developed within | WireGuard. For each protocol, this document provides a brief | |||
the scope or context of the IETF. | description, the security features it provides, and the dependencies | |||
it has on the underlying transport. This is followed by defining the | ||||
set of transport security features shared by these protocols. | ||||
Finally, we distill the application and transport interfaces provided | ||||
by the transport security protocols. | ||||
For each protocol, this document provides a brief description, the | Selected protocols represent a superset of functionality and features | |||
security features it provides, and the dependencies it has on the | a TAPS system may need to support, both internally and externally - | |||
underlying transport. This is followed by defining the set of | via an API - for applications [I-D.ietf-taps-arch]. Ubiquitous IETF | |||
transport security features shared by these protocols. Finally, we | protocols such as (D)TLS, as well as non-standard protocols such as | |||
distill the application and transport interfaces provided by the | Google QUIC, are both included despite overlapping features. As | |||
transport security protocols. | such, this survey is not limited to protocols developed within the | |||
scope or context of the IETF. Outside of this candidate set, | ||||
protocols that do not offer new features are omitted. For example, | ||||
newer protocols such as WireGuard make unique design choices that | ||||
have important implications on applications, such as how to best | ||||
configure peer public keys and to delegate algorithm selection to the | ||||
system. In contrast, protocols such as ALTS [ALTS] are omitted since | ||||
they do not represent features deemed unique. | ||||
Authentication-only protocols such as TCP-AO [RFC5925] and IPsec AH | Also, authentication-only protocols such as TCP-AO [RFC5925] and | |||
[RFC4302] are excluded from this survey. TCP-AO adds authenticity | IPsec AH [RFC4302] are excluded from this survey. TCP-AO adds | |||
protections to long-lived TCP connections, e.g., replay protection | authenticity protections to long-lived TCP connections, e.g., replay | |||
with per-packet Message Authentication Codes. (This protocol | protection with per-packet Message Authentication Codes. (This | |||
obsoletes TCP MD5 "signature" options specified in [RFC2385].) One | protocol obsoletes TCP MD5 "signature" options specified in | |||
prime use case of TCP-AO is for protecting BGP connections. | [RFC2385].) One prime use case of TCP-AO is for protecting BGP | |||
Similarly, AH adds per-datagram authenticity and adds similar replay | connections. Similarly, AH adds per-datagram authenticity and adds | |||
protection. Despite these improvements, neither protocol sees | similar replay protection. Despite these improvements, neither | |||
general use and both lack critical properties important for emergent | protocol sees general use and both lack critical properties important | |||
transport security protocols: confidentiality, privacy protections, | for emergent transport security protocols: confidentiality, privacy | |||
and agility. Thus, we omit these and related protocols from our | protections, and agility. Thus, we omit these and related protocols | |||
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 4, line 37 ¶ | skipping to change at page 4, line 48 ¶ | |||
functionality to an application. | functionality to an application. | |||
o Transport Protocol: an implementation that provides one or more | o Transport Protocol: an implementation that provides one or more | |||
different transport services using a specific framing and header | different transport services using a specific framing and header | |||
format on the wire. A Transport Protocol services an application. | format on the wire. A Transport Protocol services an application. | |||
o Application: an entity that uses a transport protocol for end-to- | 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 specific feature that a network security layer | o Security Feature: a feature that a network security layer provides | |||
provides to applications. Examples include authentication, | to applications. Examples include authentication, encryption, key | |||
encryption, key generation, session resumption, and privacy. A | generation, session resumption, and privacy. Features may be | |||
feature may be considered to be Mandatory or Optional to an | Mandatory or Optional for an application's implementation. | |||
application's implementation. | ||||
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 Protocol: a security protocol that allows data to be | o Record Protocol: a security protocol that allows data to be | |||
divided into manageable blocks and protected using a shared | divided into manageable blocks and protected using shared | |||
cryptographic context. | cryptographic context. | |||
o Session: an ephemeral security association between applications. | o Session: an ephemeral security association between applications. | |||
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 | |||
skipping to change at page 5, line 32 ¶ | skipping to change at page 5, line 40 ¶ | |||
be multihomed or resilient across network interface or address | be multihomed or resilient across network interface or address | |||
changes. | changes. | |||
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. Transport Security Protocol Descriptions | 3. Security Features | |||
This section contains descriptions of security protocols that | In this section, we enumerate Security Features exposed by protocols | |||
currently used to protect data being sent over a network. | discussed in the remainder of this document. Protocol security | |||
properties that are unrelated to the API surface exposed by such | ||||
protocols, such as client or server identity hiding, are not listed | ||||
here as features. | ||||
For each protocol, we describe the features it provides and its | o Forward-secure key establishment: Cryptographic key establishment | |||
dependencies on other protocols. | with forward secure properties. | |||
3.1. TLS | o Cryptographic algorithm negotiation: Negotiate support of protocol | |||
algorithms, including: encryption, hash, MAC (PRF), and digital | ||||
signature algorithms. | ||||
o Stateful and stateless cross-connection session resumption: | ||||
Connection establishment without needing to complete an entirely | ||||
new handshake. | ||||
o Peer authentication (certificate, raw public key, pre-shared key, | ||||
or EAP-based): Peer authentication using select or protocol- | ||||
specific mechanisms. | ||||
o Mutual authentication: Connection establishment wherein both | ||||
endpoints are authenticated. | ||||
o Record (channel or datagram) confidentiality and integrity: | ||||
Encryption and authentication of application plaintext bytes sent | ||||
between peers over a channel or in individual datagrams. | ||||
o Partial record confidentiality: Encryption of some portion of | ||||
records. | ||||
o Optional record integrity: Optional authentication of certain | ||||
records. | ||||
o Record replay prevention: Protocol detection and defense against | ||||
record replays, e.g., due to in-network retransmissions. | ||||
o Application-layer feature negotiation: Securely negotiate | ||||
application-specific functionality. | ||||
o Early data support (starting with TLS 1.3): Transmission of | ||||
application data prior to connection (handshake) establishment. | ||||
o Connection mobility: Connection continuation in the presence of | ||||
5-tuple changes beneath the secure transport protocol, e.g., due | ||||
to NAT rebindings. | ||||
o Application-layer authentication delegation: Out-of-band peer | ||||
authentication performed by applications outside of the connection | ||||
establishment. | ||||
o Out-of-order record receipt: Processing of records received out- | ||||
of-order. | ||||
o DoS mitigation (cookie or puzzle based): Peer DoS mitigation via | ||||
explicit proof of origin (cookie) or work mechanisms (puzzles). | ||||
o Connection re-keying: In-band cryptographic handshake re-keying. | ||||
o Optional length-hiding and anti-amplification padding: Protocol- | ||||
drive record padding aimed at hiding plaintext message length and | ||||
mitigating amplification attack vectors. | ||||
4. Transport Security Protocol Descriptions | ||||
This section contains descriptions of security protocols currently | ||||
used to protect data being sent over a network. | ||||
For each protocol, we describe its provided features and dependencies | ||||
on other protocols. | ||||
4.1. TLS | ||||
TLS (Transport Layer Security) [RFC5246] is a common protocol used to | TLS (Transport Layer Security) [RFC5246] is a common protocol used to | |||
establish a secure session between two endpoints. Communication over | establish a secure session between two endpoints. Communication over | |||
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. | |||
3.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 | |||
[I-D.ietf-tls-tls13]. The record protocol is designed to marshal an | [I-D.ietf-tls-tls13]. The record protocol is designed to marshal an | |||
arbitrary, in-order stream of bytes from one endpoint to the other. | arbitrary, in-order stream of bytes from one endpoint to the other. | |||
It handles segmenting, compressing (when enabled), and encrypting | It handles segmenting, compressing (when enabled), and encrypting | |||
data into discrete records. When configured to use an AEAD | data into discrete records. When configured to use an authenticated | |||
algorithm, it also handles nonce generation and encoding for each | encryption with associated data (AEAD) algorithm, it also handles | |||
record. The record protocol is hidden from the client behind a byte | nonce generation and encoding for each record. The record protocol | |||
stream-oriented API. | is 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 with a CertificateRequest handshake message. Assuming strong | server with a CertificateRequest handshake message. Assuming strong | |||
cryptography, an infrastructure for trust establishment, correctly- | cryptography, an infrastructure for trust establishment, correctly- | |||
skipping to change at page 7, line 7 ¶ | skipping to change at page 8, line 33 ¶ | |||
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. | |||
Once a session is disconnected all session keying material must be | Once a session is disconnected all session keying material must be | |||
destroyed, with the exception of secrets previously established | destroyed, with the exception of secrets previously established | |||
expressly for purposes of session resumption. TLS supports stateful | expressly for purposes of session resumption. TLS supports stateful | |||
and stateless resumption. (Here, "state" refers to bookkeeping on a | and stateless resumption. (Here, "state" refers to bookkeeping on a | |||
per-session basis by the server. It is assumed that the client must | per-session basis by the server. It is assumed that the client must | |||
always store some state information in order to resume a session.) | always store some state information in order to resume a session.) | |||
3.1.2. Protocol Features | 4.1.2. Protocol Features | |||
o Key exchange and ciphersuite algorithm negotiation. | o Forward-secure key establishment. | |||
o Stateful and stateless session resumption. | o Cryptographic algorithm negotiation. | |||
o Certificate- and raw public key-based authentication. | o Stateful and stateless cross-connection session resumption. | |||
o Mutual client and server authentication. | o Peer authentication (Certificate, raw public key, and pre-shared | |||
key). | ||||
o Byte stream confidentiality and integrity. | o Mandatory server authentication, optional client authentication. | |||
o Extensibility via well-defined extensions. | o Record (channel) confidentiality and integrity. | |||
o 0-RTT data support (starting with TLS 1.3). | o Record replay prevention. | |||
o Application-layer protocol negotiation. | o Application-layer feature negotiation. | |||
o Transparent data segmentation. | o Early data support (starting with TLS 1.3). | |||
3.1.3. Protocol Dependencies | o Optional length-hiding padding (starting with TLS 1.3). | |||
4.1.3. Protocol Dependencies | ||||
o TCP for in-order, reliable transport. | o TCP for in-order, reliable transport. | |||
o (Optionally) A PKI trust store for certificate validation. | o (Optionally) A PKI trust store for certificate validation. | |||
3.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 UDP instead of TCP. | |||
Since UDP does not guarantee datagram ordering or reliability, DTLS | Since UDP does not guarantee datagram ordering or reliability, DTLS | |||
modifies the protocol to make sure it can still provide the same | modifies the protocol to make sure it can still provide the same | |||
security guarantees as TLS. DTLS was designed to be as close to TLS | security guarantees as TLS. DTLS was designed to be as close to TLS | |||
as possible, so this document will assume that all properties from | as possible, so this document will assume that all properties from | |||
TLS are carried over except where specified. | TLS are carried over except where specified. | |||
3.2.1. Protocol Description | 4.2.1. Protocol Description | |||
DTLS is modified from TLS to account for packet loss, reordering, and | DTLS is modified from TLS to operate with the possibility of packet | |||
duplication that may occur when operating over UDP. To enable out- | loss, reordering, and duplication that may occur when operating over | |||
of-order delivery of application data, the DTLS record protocol | UDP. To enable out-of-order delivery of application data, the DTLS | |||
itself has no inter-record dependencies. However, as the handshake | record protocol itself has no inter-record dependencies. However, as | |||
requires reliability, each handshake message is assigned an explicit | the handshake requires reliability, each handshake message is | |||
sequence number to enable retransmissions of lost packets and in- | assigned an explicit sequence number to enable retransmissions of | |||
order processing by the receiver. Handshake message loss is remedied | lost packets and in-order processing by the receiver. Handshake | |||
by sender retransmission after a configurable period in which the | message loss is remedied by sender retransmission after a | |||
expected response has not yet been received. | configurable period in which the expected response has not yet been | |||
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 allow peers with multiple DTLS | DTLS relies on unique UDP 4-tuples to identify connections. Since | |||
connections between them to demultiplex connections, constraining | all application-layer data is encrypted, demultiplexing over the same | |||
protocol design slightly more than UDP: application-layer | 4-tuple requires the use of a connection identifier extension | |||
demultiplexing over the same 4-tuple is not possible without trial | [I-D.ietf-tls-dtls-connection-id] to permit identification of the | |||
decryption as all application-layer data is encrypted to a | correct connection-specific cryptographic context without the use of | |||
connection-specific cryptographic context. Starting with DTLS 1.3 | trial decryption. (Note that this extension is only supported in | |||
[I-D.ietf-tls-dtls13], a connection identifier extension to permit | DTLS 1.2 and 1.3 {{I-D.ietf-tls-dtls13}.) | |||
multiplexing of independent connections over the same 4-tuple is | Since datagrams can be replayed, DTLS provides optional anti-replay | |||
available [I-D.ietf-tls-dtls-connection-id]. | ||||
Since datagrams may 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]. | |||
3.2.2. Protocol Features | 4.2.2. Protocol Features | |||
o Anti-replay protection between datagrams. | o Record replay protection. | |||
o Basic reliability for handshake messages. | o Record (datagram) confidentiality and integrity. | |||
o See also the features from TLS. | o Out-of-order record receipt. | |||
3.2.3. Protocol Dependencies | o DoS mitigation (cookie-based). | |||
See also the features from TLS. | ||||
4.2.3. Protocol Dependencies | ||||
o Since DTLS runs over an unreliable, unordered datagram transport, | o Since DTLS runs over an unreliable, unordered datagram transport, | |||
it does not require any reliability features. | it does not require any reliability features. | |||
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. | reconstruction of datagrams fragmented over packets. (Note: DTLS | |||
1.3 short header records omit the explicit length field.) | ||||
o UDP 4-tuple uniqueness, or the connection identifier extension, | o UDP 4-tuple uniqueness, or the connection identifier extension, | |||
for demultiplexing. | for demultiplexing. | |||
o Path MTU discovery. | o Path MTU discovery. | |||
3.3. (IETF) QUIC with TLS | 4.3. (IETF) QUIC with TLS | |||
QUIC (Quick UDP Internet Connections) is a new standards-track | QUIC (Quick UDP Internet Connections) is a new standards-track | |||
transport protocol that runs over UDP, loosely based on Google's | transport protocol that runs over UDP, loosely based on Google's | |||
original proprietary gQUIC protocol. (See Section 3.3.4 for more | original proprietary gQUIC protocol [I-D.ietf-quic-transport]. (See | |||
details.) The QUIC transport layer itself provides support for data | Section 4.3.4 for more details.) The QUIC transport layer itself | |||
confidentiality and integrity. This requires keys to be derived with | provides support for data confidentiality and integrity. This | |||
a separate handshake protocol. A mapping for QUIC over TLS 1.3 | requires keys to be derived with a separate handshake protocol. A | |||
[I-D.ietf-quic-tls] has been specified to provide this handshake. | mapping for QUIC over TLS 1.3 [I-D.ietf-quic-tls] has been specified | |||
to provide this handshake. | ||||
3.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. | |||
skipping to change at page 9, line 47 ¶ | skipping to change at page 11, line 31 ¶ | |||
Initial QUIC messages (packets) are encrypted using "fixed" keys | Initial QUIC messages (packets) are encrypted using "fixed" keys | |||
derived from the QUIC version and public packet information | derived from the QUIC version and public packet information | |||
(Connection ID). Packets are later encrypted using keys derived from | (Connection ID). Packets are later encrypted using keys derived from | |||
the TLS traffic secret upon handshake completion. The TLS 1.3 | the TLS traffic secret upon handshake completion. The TLS 1.3 | |||
handshake for QUIC is used in either a single-RTT mode or a fast-open | handshake for QUIC is used in either a single-RTT mode or a fast-open | |||
zero-RTT mode. When zero-RTT handshakes are possible, the encryption | zero-RTT mode. When zero-RTT handshakes are possible, the encryption | |||
first transitions to use the zero-RTT keys before using single-RTT | first transitions to use the zero-RTT keys before using single-RTT | |||
handshake keys after the next TLS flight. | handshake keys after the next TLS flight. | |||
3.3.2. Protocol Features | 4.3.2. Protocol Features | |||
o Handshake properties of TLS. | ||||
o Multiple encrypted streams over a single connection without head- | o DoS mitigation (cookie-based). | |||
of-line blocking. | ||||
o Packet payload encryption and complete packet authentication (with | See also the properties of TLS. | |||
the exception of the Public Reset packet, which is not | ||||
authenticated). | ||||
3.3.3. Protocol Dependencies | 4.3.3. Protocol Dependencies | |||
o QUIC transport relies on UDP. | o QUIC transport relies on UDP. | |||
o QUIC transport relies on TLS 1.3 for authentication and initial | o QUIC transport relies on TLS 1.3 for peer authentication and | |||
key derivation. | initial key derivation. | |||
o TLS within QUIC relies on a reliable stream abstraction for its | o TLS within QUIC relies on QUIC for reliable handshake record | |||
handshake. | transmission and receipt. | |||
3.3.4. Differences from Google QUIC | 4.3.4. Variant: Google QUIC | |||
Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol | Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol | |||
designed and deployed by Google following experience from deploying | designed and deployed by Google following experience from deploying | |||
SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally | SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally | |||
known as "QUIC": this document uses gQUIC to unambiguously | known as "QUIC": this document uses gQUIC to unambiguously | |||
distinguish it from the standards-track IETF QUIC. The proprietary | distinguish it from the standards-track IETF QUIC. The proprietary | |||
technical forebear of IETF QUIC, gQUIC was originally designed with | technical forebear of IETF QUIC, gQUIC was originally designed with | |||
tightly-integrated security and application data transport protocols. | tightly-integrated security and application data transport protocols. | |||
3.3.5. Protocol Description | 4.4. IKEv2 with ESP | |||
((TODO: write me)) | ||||
3.3.6. Protocol Dependencies | ||||
((TODO: write me)) | ||||
3.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 as | protocol suite that encrypts and authenticates IP packets, either as | |||
for creating tunnels (tunnel-mode) or for direct transport | for creating tunnels (tunnel-mode) or for direct transport | |||
connections (transport-mode). This suite of protocols separates out | connections (transport-mode). This suite of protocols separates out | |||
the key generation protocol (IKEv2) from the transport encryption | the key generation protocol (IKEv2) from the transport encryption | |||
protocol (ESP). Each protocol can be used independently, but this | protocol (ESP). Each protocol can be used independently, but this | |||
document considers them together, since that is the most common | document considers them together, since that is the most common | |||
pattern. | pattern. | |||
3.4.1. Protocol descriptions | 4.4.1. Protocol descriptions | |||
3.4.1.1. IKEv2 | ||||
4.4.1.1. IKEv2 | ||||
IKEv2 is a control protocol that runs on UDP port 500. Its primary | IKEv2 is a control protocol that runs on UDP port 500. Its primary | |||
goal is to generate keys for Security Associations (SAs). It first | goal is to generate keys for Security Associations (SAs). An SA | |||
uses a Diffie-Hellman key exchange to generate keys for the "IKE SA", | contains shared (cryptographic) information used for establishing | |||
which is a set of keys used to encrypt further IKEv2 messages. It | other SAs or keying ESP; See Section 4.4.1.2. IKEv2 first uses a | |||
then goes through a phase of authentication in which both peers | Diffie-Hellman key exchange to generate keys for the "IKE SA", which | |||
present blobs signed by a shared secret or private key, after which | is a set of keys used to encrypt further IKEv2 messages. It then | |||
another set of keys is derived, referred to as the "Child SA". These | goes through a phase of authentication in which both peers present | |||
Child SA keys are used by ESP. | blobs signed by a shared secret or private key, after which another | |||
set of keys is derived, referred to as the "Child SA". These Child | ||||
SA keys are used by ESP. | ||||
IKEv2 negotiates which protocols are acceptable to each peer for both | IKEv2 negotiates which protocols are acceptable to each peer for both | |||
the IKE and Child SAs using "Proposals". Each proposal may contain | the IKE and Child SAs using "Proposals". Each proposal may contain | |||
an encryption algorithm, an authentication algorithm, a Diffie- | an encryption algorithm, an authentication algorithm, a Diffie- | |||
Hellman group, and (for IKE SAs only) a pseudorandom function | Hellman group, and (for IKE SAs only) a pseudorandom function | |||
algorithm. Each peer may support multiple proposals, and the most | algorithm. Each peer may support multiple proposals, and the most | |||
preferred mutually supported proposal is chosen during the handshake. | preferred mutually supported proposal is chosen during the handshake. | |||
The authentication phase of IKEv2 may use Shared Secrets, | The authentication phase of IKEv2 may use Shared Secrets, | |||
Certificates, Digital Signatures, or an EAP (Extensible | Certificates, Digital Signatures, or an EAP (Extensible | |||
skipping to change at page 11, line 41 ¶ | skipping to change at page 13, line 12 ¶ | |||
There is an extension to IKEv2 that allows session resumption | There is an extension to IKEv2 that allows session resumption | |||
[RFC5723]. | [RFC5723]. | |||
MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a | MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a | |||
set of Security Associations to migrate over different addresses and | set of Security Associations to migrate over different addresses and | |||
interfaces [RFC4555]. | 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]. | |||
3.4.1.2. ESP | 4.4.1.2. ESP | |||
ESP is a protocol that encrypts and authenticates IPv4 and IPv6 | ESP is a protocol that encrypts and authenticates IPv4 and IPv6 | |||
packets. The keys used for both encryption and authentication can be | packets. The keys used for both encryption and authentication can be | |||
derived from an IKEv2 exchange. ESP Security Associations come as | derived from an IKEv2 exchange. ESP Security Associations come as | |||
pairs, one for each direction between two peers. Each SA is | pairs, one for each direction between two peers. Each SA is | |||
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 12, line 23 ¶ | skipping to change at page 13, line 39 ¶ | |||
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]. | |||
3.4.2. Protocol features | 4.4.2. Protocol features | |||
3.4.2.1. IKEv2 | 4.4.2.1. IKEv2 | |||
o Encryption and authentication of handshake packets. | o Forward-secure key establishment. | |||
o Cryptographic algorithm negotiation. | o Cryptographic algorithm negotiation. | |||
o Session resumption. | o Peer authentication (Certificate, raw public key, pre-shared key, | |||
and EAP). | ||||
o Mobility across addresses and interfaces. | o Mutual authentication. | |||
o Peer authentication extensibility based on shared secret, | o Record (datagram) confidentiality and integrity. | |||
certificates, digital signatures, or EAP methods. | ||||
3.4.2.2. ESP | o Session resumption. | |||
o Data confidentiality and authentication. | o Connection mobility. | |||
o Connectionless integrity. | o DoS mitigation (cookie-based). | |||
o Anti-replay protection. | 4.4.2.2. ESP | |||
o Limited flow confidentiality. | o Record confidentiality and integrity. | |||
3.4.3. Protocol dependencies | o Record replay protection. | |||
3.4.3.1. IKEv2 | ||||
4.4.3. 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. | |||
3.4.3.2. ESP | 4.4.3.2. ESP | |||
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. | |||
3.5. SRTP (with DTLS) | 4.5. Secure RTP (with DTLS) | |||
SRTP - Secure RTP - is a profile for RTP that provides | Secure RTP (SRTP) is a profile for RTP that provides confidentiality, | |||
confidentiality, message authentication, and replay protection for | message authentication, and replay protection for RTP data packets | |||
data and control packets [RFC3711]. SRTP packets are encrypted using | and RTP control protocol (RTCP) packets [RFC3711]. | |||
a session key, which is derived from a separate master key. Master | ||||
keys are derived and managed externally, e.g., via DTLS, as specified | ||||
in RFC 5763 [RFC5763], under the control of a signaling protocol such | ||||
as SIP [RFC3261] or WebRTC [I-D.ietf-rtcweb-security-arch]. | ||||
3.5.1. Protocol descriptions | 4.5.1. Protocol description | |||
SRTP adds confidentiality and optional integrity protection to RTP | SRTP adds confidentiality and optional integrity protection to RTP | |||
data packets, and adds confidentially and mandatory integrity | data packets, and adds confidentially and mandatory integrity | |||
protection to RTP control (RTCP) packets. For RTP data packets, this | protection to RTCP packets. For RTP data packets, this is done by | |||
is done by encrypting the payload section of the packet and | encrypting the payload section of the packet and optionally appending | |||
optionally appending an authentication tag (MAC) as a packet trailer, | an authentication tag (MAC) as a packet trailer, with the RTP header | |||
with the RTP header authenticated but not encrypted. The RTP header | authenticated but not encrypted (the RTP header was left unencrypted | |||
itself is left unencrypted to enable RTP header compression | to enable RTP header compression [RFC2508] [RFC3545]). For RTCP | |||
[RFC2508][RFC3545]. For RTCP packets, the first packet in the | packets, the first packet in the compound RTCP packet is partially | |||
compound RTCP packet is partially encrypted, leaving the first eight | encrypted, leaving the first eight octets of the header as clear-text | |||
octets of the header as cleartext to allow identification of the | to allow identification of the packet as RTCP, while the remainder of | |||
packet as RTCP, while the remainder of the compound packet is fully | the compound packet is fully encrypted. The entire RTCP packet is | |||
encrypted. The entire RTCP packet is then authenticated by appending | then authenticated by appending a MAC as packet trailer. | |||
a MAC as packet trailer. | ||||
Packets are encrypted using session keys, which are ultimately | Packets are encrypted using session keys, which are ultimately | |||
derived from a master key and some additional master salt and session | derived from a master key and an additional master salt and session | |||
salt. SRTP packets carry a 2-byte sequence number to partially | salt. SRTP packets carry a 2-byte sequence number to partially | |||
identify the unique packet index. SRTP peers maintain a separate | identify the unique packet index. SRTP peers maintain a separate | |||
rollover counter (ROC) for RTP data packets that is incremented | roll-over counter (ROC) for RTP data packets that is incremented | |||
whenever the sequence number wraps. The sequence number and ROC | whenever the sequence number wraps. The sequence number and ROC | |||
together determine the packet index. RTCP packets have a similar, | together determine the packet index. RTCP packets have a similar, | |||
yet differently named, field called the RTCP index which serves the | yet differently named, field called the RTCP index which serves the | |||
same purpose. | same purpose. | |||
Numerous encryption modes are supported. For popular modes of | Numerous encryption modes are supported. For popular modes of | |||
operation, e.g., AES-CTR, the (unique) initialization vector (IV) | operation, e.g., AES-CTR, the (unique) initialization vector (IV) | |||
used for each encryption mode is a function of the RTP SSRC | used for each encryption mode is a function of the RTP SSRC | |||
(synchronization source), packet index, and session "salting key". | (synchronization source), packet index, and session "salting key". | |||
SRTP offers replay detection by keeping a replay list of already seen | SRTP offers replay detection by keeping a replay list of already seen | |||
and processed packet indices. If a packet arrives with an index that | and processed packet indices. If a packet arrives with an index that | |||
matches one in the replay list, it is silently discarded. | matches one in the replay list, it is silently discarded. | |||
DTLS [RFC5764] is commonly used as a way to perform mutual | DTLS [RFC5764] is commonly used to perform mutual authentication and | |||
authentication and key agreement for SRTP [RFC5763]. (Here, | key agreement for SRTP [RFC5763]. Peers use DTLS to perform mutual | |||
certificates marshal public keys between endpoints. Thus, self- | certificate-based authentication on the media path, and to generate | |||
signed certificates may be used if peers do not mutually trust one | the SRTP master key. Peer certificates can be issued and signed by a | |||
another, as is common on the Internet.) When DTLS is used, | certificate authority. Alternatively, certificates used in the DTLS | |||
certificate fingerprints are transmitted out-of-band using SIP. | exchange can be self-signed. If they are self-signed, certificate | |||
Peers typically verify that DTLS-offered certificates match that | fingerprints are included in the signalling exchange (e.g., in SIP or | |||
which are offered over SIP. This prevents active attacks on RTP, but | WebRTC), and used to bind the DTLS key exchange in the media plane to | |||
not on the signaling (SIP or WebRTC) channel. | the signaling plane. The combination of a mutually authenticated | |||
DTLS key exchange on the media path and a fingerprint sent in the | ||||
signalling channel protects against active attacks on the media, | ||||
provided the signalling can be trusted. Signalling needs to be | ||||
protected as described in, for example, SIP [RFC3261] Authenticated | ||||
Identity Management [RFC4474] or the WebRTC security architecture | ||||
[I-D.ietf-rtcweb-security-arch], to provide complete system security. | ||||
3.5.2. Protocol features | 4.5.2. Protocol features | |||
o Optional replay protection with tunable replay windows. | o Forward-secure key establishment. | |||
o Out-of-order packet receipt. | o Cryptographic algorithm negotiation. | |||
o (RFC5763) Mandatory mutually authenticated key exchange. | o Mutual authentication. | |||
o Partial encryption, protecting media payloads and control packets | o Partial datagram confidentiality. (Packet headers are not | |||
but not data packet headers. | encrypted.) | |||
o Optional authentication of data packets; mandatory authentication | o Optional authentication of data packets. | |||
of control packets. | ||||
3.5.3. Protocol dependencies | o Mandatory authentication of control packets. | |||
o External key derivation and management mechanism or protocol, | o Out-of-order record receipt. | |||
e.g., DTLS [RFC5763]. | ||||
o External signaling protocol to manage RTP parameters and locate | 4.5.3. Protocol dependencies | |||
and identify peers, e.g., SIP [RFC3261] or WebRTC | ||||
o External key derivation and management protocol, e.g., DTLS | ||||
[RFC5763]. | ||||
o External identity management protocol, e.g., SIP Authenticated | ||||
Identity Management [RFC4474], WebRTC Security Architecture | ||||
[I-D.ietf-rtcweb-security-arch]. | [I-D.ietf-rtcweb-security-arch]. | |||
3.6. Differences from ZRTP | 4.5.4. Variant: ZRTP for Media Path Key Agreement | |||
((TODO: write me)) | ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It | |||
uses standard SRTP to protect RTP data packets and RTCP packets, but | ||||
provides alternative key agreement and identity management protocols. | ||||
3.7. tcpcrypt | Key agreement is performed using a Diffie-Hellman key exchange that | |||
runs on the media path. This generates a shared secret that is then | ||||
used to generate the master key and salt for SRTP. | ||||
ZRTP does not rely on a PKI or external identity management system. | ||||
Rather, it uses an ephemeral Diffie-Hellman key exchange with hash | ||||
commitment to allow detection of man-in-the-middle attacks. This | ||||
requires endpoints to display a short authentication string that the | ||||
users must read and verbally compare to validate the hashes and | ||||
ensure security. Endpoints cache some key material after the first | ||||
call to use in subsequent calls; this is mixed in with the Diffie- | ||||
Hellman shared secret, so the short authentication string need only | ||||
be checked once for a given user. This gives key continuity | ||||
properties analogous to the secure shell (ssh) [RFC4253]. | ||||
4.6. tcpcrypt | ||||
Tcpcrypt is a lightweight extension to the TCP protocol to enable | Tcpcrypt is a lightweight extension to the TCP protocol to enable | |||
opportunistic encryption with hooks available to the application | opportunistic encryption with hooks available to the application | |||
layer for implementation of endpoint authentication. | layer for implementation of endpoint authentication. | |||
3.7.1. Protocol Description | 4.6.1. Protocol Description | |||
Tcpcrypt extends TCP to enable opportunistic encryption between the | Tcpcrypt extends TCP to enable opportunistic encryption between the | |||
two ends of a TCP connection [I-D.ietf-tcpinc-tcpcrypt]. It is a | two ends of a TCP connection [I-D.ietf-tcpinc-tcpcrypt]. It is a | |||
family of TCP encryption protocols (TEP), distinguished by key | family of TCP encryption protocols (TEP), distinguished by key | |||
exchange algorithm. The use of a TEP is negotiated with a TCP option | exchange algorithm. The use of a TEP is negotiated with a TCP option | |||
during the initial TCP handshake via the mechanism described by TCP | during the initial TCP handshake via the mechanism described by TCP | |||
Encryption Negotiation Option (ENO) [I-D.ietf-tcpinc-tcpeno]. In the | Encryption Negotiation Option (ENO) [I-D.ietf-tcpinc-tcpeno]. In the | |||
case of initial session establishment, once a tcpcrypt TEP has been | case of initial session establishment, once a tcpcrypt TEP has been | |||
negotiated the key exchange occurs within the data segments of the | negotiated the key exchange occurs within the data segments of the | |||
first few packets exchanged after the handshake completes. The | first few packets exchanged after the handshake completes. The | |||
skipping to change at page 16, line 9 ¶ | skipping to change at page 17, line 40 ¶ | |||
resumption across a pool of servers implies shared state. | resumption across a pool of servers implies shared state. | |||
Owing to middlebox ossification issues, tcpcrypt only protects the | Owing to middlebox ossification issues, tcpcrypt only protects the | |||
payload portion of a TCP packet. It does not encrypt any header | payload portion of a TCP packet. It does not encrypt any header | |||
information, such as the TCP sequence number. | information, such as the TCP sequence number. | |||
Tcpcrypt exposes a universally-unique connection-specific session ID | Tcpcrypt exposes a universally-unique connection-specific session ID | |||
to the application, suitable for application-level endpoint | to the application, suitable for application-level endpoint | |||
authentication either in-band or out-of-band. | authentication either in-band or out-of-band. | |||
3.7.2. Protocol Features | 4.6.2. Protocol Features | |||
o Forward-secure TCP payload encryption and integrity protection. | o Forward-secure key establishment. | |||
o Session caching and address-agnostic resumption. | o Record (channel) confidentiality and integrity. | |||
o Stateful cross-connection session resumption. | ||||
o Connection re-keying. | o Connection re-keying. | |||
o Application-level authentication primitive. | o Application authentication delegation. | |||
3.7.3. Protocol Dependencies | 4.6.3. Protocol Dependencies | |||
o TCP | o TCP | |||
o TCP Encryption Negotiation Option (ENO) | o TCP Encryption Negotiation Option (ENO) | |||
3.8. WireGuard | 4.7. WireGuard | |||
WireGuard is a layer 3 protocol designed to complement or replace | WireGuard is a layer 3 protocol designed to complement or replace | |||
IPsec [WireGuard]. Unlike most transport security protocols, which | IPsec [WireGuard]. Unlike most transport security protocols, which | |||
rely on PKI for peer authentication, WireGuard authenticates peers | rely on PKI for peer authentication, WireGuard authenticates peers | |||
using pre-shared public keys delivered out-of-band, each of which is | using pre-shared public keys delivered out-of-band, each of which is | |||
bound to one or more IP addresses. Moreover, as a protocol suited | bound to one or more IP addresses. Moreover, as a protocol suited | |||
for VPNs, WireGuard offers no extensibility, negotiation, or | for VPNs, WireGuard offers no extensibility, negotiation, or | |||
cryptographic agility. | cryptographic agility. | |||
3.8.1. Protocol description | 4.7.1. Protocol description | |||
WireGuard is a simple VPN protocol that binds a pre-shared public key | WireGuard is a simple VPN protocol that binds a pre-shared public key | |||
to one or more IP addresses. Users configure WireGuard by | to one or more IP addresses. Users configure WireGuard by | |||
associating peer public keys with IP addresses. These mappings are | associating peer public keys with IP addresses. These mappings are | |||
stored in a CryptoKey Routing Table. (See Section 2 of [WireGuard] | stored in a CryptoKey Routing Table. (See Section 2 of [WireGuard] | |||
for more details and sample configurations.) These keys are used | for more details and sample configurations.) These keys are used | |||
upon WireGuard packet transmission and reception. For example, upon | upon WireGuard packet transmission and reception. For example, upon | |||
receipt of a Handshake Initiation message, receivers use the static | receipt of a Handshake Initiation message, receivers use the static | |||
public key in their CryptoKey routing table to perform necessary | public key in their CryptoKey routing table to perform necessary | |||
cryptographic computations. | cryptographic computations. | |||
skipping to change at page 17, line 24 ¶ | skipping to change at page 19, line 8 ¶ | |||
introduced. | introduced. | |||
WireGuard is designed to be entirely stateless, modulo the CryptoKey | WireGuard is designed to be entirely stateless, modulo the CryptoKey | |||
routing table, which has size linear with the number of trusted | routing table, which has size linear with the number of trusted | |||
peers. If a WireGuard receiver is under heavy load and cannot | peers. If a WireGuard receiver is under heavy load and cannot | |||
process a packet, e.g., cannot spare CPU cycles for point | process a packet, e.g., cannot spare CPU cycles for point | |||
multiplication, it can reply with a cookie similar to DTLS and IKEv2. | multiplication, it can reply with a cookie similar to DTLS and IKEv2. | |||
This cookie only proves IP address ownership. Any rate limiting | This cookie only proves IP address ownership. Any rate limiting | |||
scheme can be applied to packets coming from non-spoofed addresses. | scheme can be applied to packets coming from non-spoofed addresses. | |||
3.8.2. Protocol features | 4.7.2. Protocol features | |||
o Optional PSK-based session creation. | o Forward-secure key establishment. | |||
o Mutual client and server authentication. | o Peer authentication (Public-key and PSK). | |||
o Stateful, timestamp-based replay prevention. | o Mutual authentication. | |||
o Cookie-based DoS mitigation similar to DTLS and IKEv2. | o Record replay prevention (Stateful, timestamp-based). | |||
3.8.3. Protocol dependencies | o DoS mitigation (cookie-based). | |||
4.7.3. Protocol dependencies | ||||
o Datagram transport. | o Datagram transport. | |||
o Out-of-band key distribution and management. | o Out-of-band key distribution and management. | |||
3.9. MinimalT | 4.8. MinimalT | |||
MinimalT is a UDP-based transport security protocol designed to offer | MinimalT is a UDP-based transport security protocol designed to offer | |||
confidentiality, mutual authentication, DoS prevention, and | confidentiality, mutual authentication, DoS prevention, and | |||
connection mobility [MinimalT]. One major goal of the protocol is to | connection mobility [MinimalT]. One major goal of the protocol is to | |||
leverage existing protocols to obtain server-side configuration | leverage existing protocols to obtain server-side configuration | |||
information used to more quickly bootstrap a connection. MinimalT | information used to more quickly bootstrap a connection. MinimalT | |||
uses a variant of TCP's congestion control algorithm. | uses a variant of TCP's congestion control algorithm. | |||
3.9.1. Protocol Description | 4.8.1. Protocol Description | |||
MinimalT is a secure transport protocol built on top of a widespread | MinimalT is a secure transport protocol built on top of a widespread | |||
directory service. Clients and servers interact with local directory | directory service. Clients and servers interact with local directory | |||
services to (a) resolve server information and (b) public ephemeral | services to (a) resolve server information and (b) public ephemeral | |||
state information, respectively. Clients connect to a local resolver | state information, respectively. Clients connect to a local resolver | |||
once at boot time. Through this resolver they recover the IP | once at boot time. Through this resolver they recover the IP | |||
address(es) and public key(s) of each server to which they want to | address(es) and public key(s) of each server to which they want to | |||
connect. | connect. | |||
Connections are instances of user-authenticated, mobile sessions | Connections are instances of user-authenticated, mobile sessions | |||
skipping to change at page 18, line 36 ¶ | skipping to change at page 20, line 18 ¶ | |||
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. | |||
3.9.2. Protocol Features | 4.8.2. Protocol Features | |||
o 0-RTT forward secrecy for new connections. | ||||
o DoS prevention by client-side puzzles. | o Forward-secure key establishment. | |||
o Tunnel-based mobility. | o DoS mitigation (puzzle-based). | |||
o (Transport Feature) Connection multiplexing between hosts across | o Connection mobility (tunnel-based). | |||
shared tunnels. | ||||
o (Transport Feature) Congestion control state is shared across | Additional (orthogonal) transport features include: connection | |||
connections between the same host pairs. | multiplexing between hosts across shared tunnels, and congestion | |||
control state is shared across connections between the same host | ||||
pairs. | ||||
3.9.3. Protocol Dependencies | 4.8.3. Protocol Dependencies | |||
o A DNS-like resolution service to obtain location information (an | o A DNS-like resolution service to obtain location information (an | |||
IP address) and ephemeral keys. | IP address) and ephemeral keys. | |||
o A PKI trust store for certificate validation. | o A PKI trust store for certificate validation. | |||
3.10. CurveCP | 4.9. CurveCP | |||
CurveCP [CurveCP] is a UDP-based transport security protocol from | CurveCP [CurveCP] is a UDP-based transport security protocol from | |||
Daniel J. Bernstein. Unlike other transport security protocols, it | Daniel J. Bernstein. Unlike other transport security protocols, it | |||
is based entirely upon highly efficient public key algorithms. This | is based entirely upon highly efficient public key algorithms. This | |||
removes many pitfalls associated with nonce reuse and key | removes many pitfalls associated with nonce reuse and key | |||
synchronization. | synchronization. | |||
3.10.1. Protocol Description | 4.9.1. Protocol Description | |||
CurveCP is a UDP-based transport security protocol. It is built on | CurveCP is a UDP-based transport security protocol. It is built on | |||
three principal features: exclusive use of public key authenticated | three principal features: exclusive use of public key authenticated | |||
encryption of packets, server-chosen cookies to prohibit memory and | encryption of packets, server-chosen cookies to prohibit memory and | |||
computation DoS at the server, and connection mobility with a client- | computation DoS at the server, and connection mobility with a client- | |||
chosen ephemeral identifier. | chosen ephemeral identifier. | |||
There are two rounds in CurveCP. In the first round, the client | There are two rounds in CurveCP. In the first round, the client | |||
sends its first initialization packet to the server, carrying its | sends its first initialization packet to the server, carrying its | |||
(possibly fresh) ephemeral public key C', with zero-padding encrypted | (possibly fresh) ephemeral public key C', with zero-padding encrypted | |||
skipping to change at page 20, line 29 ¶ | skipping to change at page 22, line 9 ¶ | |||
CurveCP supports a weak form of client authentication. Clients are | CurveCP supports a weak form of client authentication. Clients are | |||
permitted to send their long-term public keys in the second | permitted to send their long-term public keys in the second | |||
initialization packet. A server can verify this public key and, if | initialization packet. A server can verify this public key and, if | |||
untrusted, drop the connection and subsequent data. | untrusted, drop the connection and subsequent data. | |||
Unlike some other protocols, CurveCP data packets leave only the | Unlike some other protocols, CurveCP data packets leave only the | |||
ephemeral public key, the connection ID, and the per-message nonce in | ephemeral public key, the connection ID, and the per-message nonce in | |||
the clear. Everything else is encrypted. | the clear. Everything else is encrypted. | |||
3.10.2. Protocol Features | 4.9.2. Protocol Features | |||
o Forward-secure data encryption and authentication. | ||||
o Per-packet public-key encryption. | o Datagram confidentiality and integrity (via public key | |||
encryption). | ||||
o 1-RTT session bootstrapping. | o 1-RTT session bootstrapping. | |||
o Connection mobility based on a client-chosen ephemeral identifier. | o Connection mobility (based on a client-chosen ephemeral | |||
identifier). | ||||
o Connection establishment message padding to prevent traffic | ||||
amplification. | ||||
o Sender-chosen explicit nonces, e.g., based on a sequence number. | o Optional length-hiding and anti-amplification padding. | |||
3.10.3. Protocol Dependencies | 4.9.3. Protocol Dependencies | |||
o An unreliable transport protocol such as UDP. | o An unreliable transport protocol such as UDP. | |||
4. 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. Optional features by contrast may vary from | implementation. Optional features by contrast may vary from | |||
implementation to implementation, and so an application cannot simply | implementation to implementation, and so an application cannot simply | |||
assume they are available. Applications learn of and use optional | assume they are available. Applications learn of and use optional | |||
features by querying for their presence and support. Optional | features by querying for their presence and support. Optional | |||
features may not be implemented, or may be disabled if their presence | features may not be implemented, or may be disabled if their presence | |||
impacts transport services or if a necessary transport service is | impacts transport services or if a necessary transport service is | |||
unavailable. | unavailable. | |||
4.1. Mandatory Features | 5.1. Mandatory Features | |||
o Segment encryption and authentication: Transit data must be | o Segment or datagram encryption and authentication: Transit data | |||
protected with an authenticated encryption algorithm. | must be protected with an authenticated encryption algorithm. | |||
o Forward-secure key establishment: Negotiated keying material must | o Forward-secure key establishment: Negotiated keying material must | |||
come from an authenticated, forward-secure key exchange protocol. | come from an authenticated, forward-secure key exchange protocol. | |||
o Private key interface or injection: Authentication based on public | o Public-key (raw or certificate) based authentication: | |||
key signatures is commonplace for many transport security | Authentication based on public key signatures is commonplace for | |||
protocols. | many transport security protocols. | |||
o Endpoint authentication: The endpoint (receiver) of a new | o Responder authentication: The endpoint (receiver) of a new | |||
connection must be authenticated before any data is sent to said | connection must be authenticated before any data is sent to said | |||
party. | party. | |||
o Pre-shared key support: A security protocol must be able to use a | o Pre-shared key support: A security protocol must be able to use a | |||
pre-shared key established out-of-band or from a prior session to | pre-shared key established out-of-band or from a prior session to | |||
encrypt individual messages, packets, or datagrams. | encrypt individual messages, packets, or datagrams. | |||
4.2. Optional Features | 5.2. Optional Features | |||
o Mutual authentication: Transport security protocols must allow | o Cryptographic algorithm negotiation (AN): Transport security | |||
each endpoint to authenticate the other if required by the | protocols should permit applications to configure supported or | |||
enabled cryptographic algorithms. | ||||
* Transport dependency: None. | ||||
* Application dependency: Application awareness of supported or | ||||
desired algorithms. | ||||
o Application authentication delegation (AD): Some protocols may | ||||
completely defer endpoint authentication to applications, e.g., to | ||||
reduce online protocol complexity. | ||||
* Transport dependency: None. | ||||
* Application dependency: Application opt-in and policy for | ||||
endpoint authentication | ||||
o Mutual authentication (MA): Transport security protocols should | ||||
allow each endpoint to authenticate the other if required by the | ||||
application. | application. | |||
* Transport dependency: None. | * Transport dependency: None. | |||
* Application dependency: Mutual authentication required for | * Application dependency: Mutual authentication required for | |||
application support. | application support. | |||
o Connection mobility: Sessions should not be bound to a network | o DoS mitigation (DM): Transport security protocols may need to | |||
connection (or 5-tuple). This allows cryptographic key material | support volumetric DoS prevention via, e.g., cookies or initiator- | |||
and other state information to be reused in the event of a | side puzzles. | |||
connection change. Examples of this include a NAT rebinding that | ||||
occurs without a client's knowledge. | * Transport dependency: None. | |||
* Application dependency: None. | ||||
o Connection mobility (CM): Sessions should not be bound to a | ||||
network connection (or 5-tuple). This allows cryptographic key | ||||
material and other state information to be reused in the event of | ||||
a connection change. Examples of this include a NAT rebinding | ||||
that occurs without a client's knowledge. | ||||
* Transport dependency: Connections are unreliable or can change | * Transport dependency: Connections are unreliable or can change | |||
due to unpredictable network events, e.g., NAT re-bindings. | due to unpredictable network events, e.g., NAT re-bindings. | |||
* Application dependency: None. | * Application dependency: None. | |||
o Source validation: Source validation must be provided to mitigate | o Source validation (SV): Source validation must be provided to | |||
server-targeted DoS attacks. This can be done with puzzles or | mitigate server-targeted DoS attacks. This can be done with | |||
cookies. | puzzles or cookies. | |||
* Transport dependency: Packets may arrive as datagrams instead | * Transport dependency: Packets may arrive as datagrams instead | |||
of streams from unauthenticated sources. | of streams from unauthenticated sources. | |||
* Application dependency: None. | * Application dependency: None. | |||
o Application-layer feature negotiation: The type of application | o Application-layer feature negotiation (AFN): The type of | |||
using a transport security protocol often requires features | application using a transport security protocol often requires | |||
configured at the connection establishment layer, e.g., ALPN | features configured at the connection establishment layer, e.g., | |||
[RFC7301]. Moreover, application-layer features may often be used | ALPN [RFC7301]. Moreover, application-layer features may often be | |||
to offload the session to another server which can better handle | used to offload the session to another server which can better | |||
the request. (The TLS SNI is one example of such a feature.) As | handle the request. (The TLS SNI is one example of such a | |||
such, transport security protocols should provide a generic | feature.) As such, transport security protocols should provide a | |||
mechanism to allow for such application-specific features and | generic mechanism to allow for such application-specific features | |||
options to be configured or otherwise negotiated. | and options to be configured or otherwise negotiated. | |||
* Transport dependency: None. | * Transport dependency: None. | |||
* Application dependency: Specification of application-layer | * Application dependency: Specification of application-layer | |||
features or functionality. | features or functionality. | |||
o Configuration extensions: The protocol negotiation should be | o Configuration extensions (CX): The protocol negotiation should be | |||
extensible with addition of new configuration options. | extensible with addition of new configuration options. | |||
* Transport dependency: None. | * Transport dependency: None. | |||
* Application dependency: Specification of application-specific | * Application dependency: Specification of application-specific | |||
extensions. | extensions. | |||
o Session caching and management: Sessions should be cacheable to | o Session caching and management (SC): Sessions should be cacheable | |||
enable reuse and amortize the cost of performing session | to enable reuse and amortize the cost of performing session | |||
establishment handshakes. | establishment handshakes. | |||
* Transport dependency: None. | * Transport dependency: None. | |||
* Application dependency: None. | * Application dependency: None. | |||
5. Transport Security Protocol Interfaces | o Length-hiding padding (LHP): Applications may wish to defer | |||
traffic padding to the security protocol to deter traffic analysis | ||||
attacks. | ||||
* Transport dependency: None. | ||||
* Application dependency: Knowledge of desired padding policies. | ||||
5.3. Optional Feature Availability | ||||
The following table lists the availability of the above-listed | ||||
optional features in each of the analyzed protocols. "Mandatory" | ||||
indicates that the feature is intrinsic to the protocol and cannot be | ||||
disabled. "Supported" indicates that the feature is optionally | ||||
provided natively or through a (standardized, where applicable) | ||||
extension. | ||||
+-----------+----+----+----+-----+----+----+-----+----+----+-----+ | ||||
| Protocol | AN | AD | MA | DM | CM | SV | AFN | CX | SC | LHP | | ||||
+-----------+----+----+----+-----+----+----+-----+----+----+-----+ | ||||
| TLS | S | S | S | S | U* | M | S | S | S | S | | ||||
| | | | | | | | | | | | | ||||
| DTLS | S | S | S | S | S | M | S | S | S | S | | ||||
| | | | | | | | | | | | | ||||
| IETF QUIC | S | S | S | S | S | M | S | S | S | S | | ||||
| | | | | | | | | | | | | ||||
| IKEv2+ESP | S | S | M | S | S | M | S | S | S | S | | ||||
| | | | | | | | | | | | | ||||
| SRTP+DTLS | S | S | S | S | U | M | S | S | S | U | | ||||
| | | | | | | | | | | | | ||||
| tcpcrypt | S | M | U | U** | U* | M | U | U | S | U | | ||||
| | | | | | | | | | | | | ||||
| WireGuard | U | S | M | S | U | M | U | U | U | S+ | | ||||
| | | | | | | | | | | | | ||||
| MinimalT | U | U | M | S | M | M | U | U | U | S | | ||||
| | | | | | | | | | | | | ||||
| CurveCP | U | U | S | S | M | M | U | U | U | S | | ||||
+-----------+----+----+----+-----+----+----+-----+----+----+-----+ | ||||
M=Mandatory | ||||
S=Supported but not required | ||||
U=Unsupported | ||||
*=On TCP; MPTCP would provide this ability | ||||
**=TCP provides SYN cookies natively, but these are not | ||||
cryptographically strong | ||||
+=For transport packets only | ||||
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. | |||
5.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 | o Identity and Private Keys | |||
The application can provide its identities (certificates) and | The application can provide its identities (certificates) and | |||
private keys, or mechanisms to access these, to the security | private keys, or mechanisms to access these, to the security | |||
protocol to use during handshakes. | 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 | |||
skipping to change at page 24, line 4 ¶ | skipping to change at page 26, line 47 ¶ | |||
supply pre-shared keys for the record protocol use for encryption/ | supply pre-shared keys for the record protocol use for encryption/ | |||
decryption and authentication. If the application can supply keys | decryption and authentication. If the application can supply keys | |||
directly, this is considered explicit import; if the handshake | directly, this is considered explicit import; if the handshake | |||
protocol traditionally provides the keys directly, it is | protocol traditionally provides the keys directly, it is | |||
considered direct import; if the keys can only be shared by the | considered direct import; if the keys can only be shared by the | |||
handshake, they are considered non-importable. | handshake, they are considered non-importable. | |||
* Explict import: QUIC, ESP | * Explict import: QUIC, ESP | |||
* Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard | * Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard | |||
* Non-importable: CurveCP | * Non-importable: CurveCP | |||
5.2. Connection Interfaces | 6.2. Connection Interfaces | |||
o Identity Validation | o Identity Validation | |||
During a handshake, the security protocol will conduct identity | During a handshake, the security protocol will conduct identity | |||
validation of the peer. This can call into the application to | validation of the peer. This can call into the application to | |||
offload validation. Protocols: All (TLS, DTLS, QUIC + TLS, | offload validation. Protocols: All (TLS, DTLS, QUIC + TLS, | |||
MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS)) | MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS)) | |||
o Source Address Validation | o Source Address Validation | |||
The handshake protocol may delegate validation of the remote peer | The handshake protocol may delegate validation of the remote peer | |||
that has sent data to the transport protocol or application. This | that has sent data to the transport protocol or application. This | |||
involves sending a cookie exchange to avoid DoS attacks. | involves sending a cookie exchange to avoid DoS attacks. | |||
Protocols: QUIC + TLS, DTLS, WireGuard | Protocols: QUIC + TLS, DTLS, WireGuard | |||
5.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 + TLS, MinimalT, tcpcrypt, IKEv2 | |||
o Key Update | o Key Update | |||
The handshake protocol may be instructed to update its keying | The handshake protocol may be instructed to update its keying | |||
material, either by the application directly or by the record | material, either by the application directly or by the record | |||
protocol sending a key expiration event. | protocol sending a key expiration event. | |||
Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2 | Protocols: TLS, DTLS, QUIC + TLS, 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. | |||
* Explict export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for | * Explicit export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for | |||
SRTP) | SRTP) | |||
* Direct export: TLS, DTLS, MinimalT | * Direct export: TLS, DTLS, MinimalT | |||
* Non-exportable: CurveCP | * Non-exportable: CurveCP | |||
o Key Expiration | o Key Expiration | |||
The record protocol can signal that its keys are expiring due to | The record protocol can signal that its keys are expiring due to | |||
reaching a time-based deadline, or a use-based deadline (number of | reaching a time-based deadline, or a use-based deadline (number of | |||
bytes that have been encrypted with the key). This interaction is | bytes that have been encrypted with the key). This interaction is | |||
skipping to change at page 25, line 6 ¶ | skipping to change at page 28, line 4 ¶ | |||
* Direct export: TLS, DTLS, MinimalT | * Direct export: TLS, DTLS, MinimalT | |||
* Non-exportable: CurveCP | * Non-exportable: CurveCP | |||
o Key Expiration | o Key Expiration | |||
The record protocol can signal that its keys are expiring due to | The record protocol can signal that its keys are expiring due to | |||
reaching a time-based deadline, or a use-based deadline (number of | reaching a time-based deadline, or a use-based deadline (number of | |||
bytes that have been encrypted with the key). This interaction is | bytes that have been encrypted with the key). This interaction is | |||
often limited to signaling between the record layer and the | often limited to signaling between the record layer and the | |||
handshake layer. | handshake layer. | |||
Protocols: ESP ((Editor's note: One may consider TLS/DTLS to also | Protocols: ESP ((Editor's note: One may consider TLS/DTLS to also | |||
have this interface)) | have this interface)) | |||
o Transport mobility | o Connection mobility | |||
The record protocol can be signaled that it is being migrated to | The record protocol can be signaled that it is being migrated to | |||
another transport or interface due to connection mobility, which | another transport or interface due to connection mobility, which | |||
may reset address and state validation. | may reset address and state validation. | |||
Protocols: QUIC, MinimalT, CurveCP, ESP, WireGuard (roaming) | Protocols: QUIC, MinimalT, CurveCP, ESP, WireGuard (roaming) | |||
6. IANA Considerations | 7. IANA Considerations | |||
This document has no request to IANA. | This document has no request to IANA. | |||
7. 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. | of reference protocols. Moreover, no claims of security and privacy | |||
properties beyond those guaranteed by the protocols discussed are | ||||
made. For example, metadata leakage via timing side channels and | ||||
traffic analysis may compromise any protocol discussed in this | ||||
survey. Applications using Security Interfaces SHOULD take such | ||||
limitations into consideration when using a particular protocol | ||||
implementation. | ||||
8. Acknowledgments | 9. Acknowledgments | |||
The authors would like to thank Mirja Kuehlewind, Brian Trammell, | The authors would like to thank Mirja Kuehlewind, Brian Trammell, | |||
Yannick Sierra, Frederic Jacobs, and Bob Bradley for their input and | Yannick Sierra, Frederic Jacobs, and Bob Bradley for their input and | |||
feedback on earlier versions of this draft. | feedback on earlier versions of this draft. | |||
9. Normative References | 10. Normative References | |||
[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-11 (work in | (TLS) to Secure QUIC", draft-ietf-quic-tls-13 (work in | |||
progress), April 2018. | progress), June 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-11 (work | and Secure Transport", draft-ietf-quic-transport-13 (work | |||
in progress), April 2018. | in progress), June 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-14 (work in progress), March 2018. | rtcweb-security-arch-14 (work in progress), March 2018. | |||
[I-D.ietf-taps-arch] | ||||
Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., | ||||
Perkins, C., Tiesel, P., and C. Wood, "An Architecture for | ||||
Transport Services", draft-ietf-taps-arch-00 (work in | ||||
progress), April 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-11 (work in | (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-12 (work in | |||
progress), November 2017. | progress), June 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-18 (work in progress), November 2017. | 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 | "The Datagram Transport Layer Security (DTLS) Connection | |||
Identifier", draft-ietf-tls-dtls-connection-id-00 (work in | Identifier", draft-ietf-tls-dtls-connection-id-00 (work in | |||
progress), December 2017. | progress), December 2017. | |||
[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 | |||
skipping to change at page 27, line 27 ¶ | skipping to change at page 30, line 36 ¶ | |||
[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) | ||||
Transport Layer Protocol", RFC 4253, DOI 10.17487/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-editor.org/info/rfc4302>. | <https://www.rfc-editor.org/info/rfc4302>. | |||
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", | [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", | |||
RFC 4303, DOI 10.17487/RFC4303, December 2005, | RFC 4303, DOI 10.17487/RFC4303, December 2005, | |||
<https://www.rfc-editor.org/info/rfc4303>. | <https://www.rfc-editor.org/info/rfc4303>. | |||
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for | ||||
Authenticated Identity Management in the Session | ||||
Initiation Protocol (SIP)", RFC 4474, | ||||
DOI 10.17487/RFC4474, August 2006, | ||||
<https://www.rfc-editor.org/info/rfc4474>. | ||||
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol | [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol | |||
(MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, | (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, | |||
<https://www.rfc-editor.org/info/rfc4555>. | <https://www.rfc-editor.org/info/rfc4555>. | |||
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | |||
(TLS) Protocol Version 1.2", RFC 5246, | (TLS) Protocol Version 1.2", RFC 5246, | |||
DOI 10.17487/RFC5246, August 2008, | DOI 10.17487/RFC5246, August 2008, | |||
<https://www.rfc-editor.org/info/rfc5246>. | <https://www.rfc-editor.org/info/rfc5246>. | |||
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange | [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange | |||
skipping to change at page 28, line 31 ¶ | skipping to change at page 31, line 45 ¶ | |||
[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-editor.org/info/rfc6066>. | <https://www.rfc-editor.org/info/rfc6066>. | |||
[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: | ||||
Media Path Key Agreement for Unicast Secure RTP", | ||||
RFC 6189, DOI 10.17487/RFC6189, April 2011, | ||||
<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>. | |||
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., | [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., | |||
Weiler, S., and T. Kivinen, "Using Raw Public Keys in | Weiler, S., and T. Kivinen, "Using Raw Public Keys in | |||
Transport Layer Security (TLS) and Datagram Transport | Transport Layer Security (TLS) and Datagram Transport | |||
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, | Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, | |||
June 2014, <https://www.rfc-editor.org/info/rfc7250>. | June 2014, <https://www.rfc-editor.org/info/rfc7250>. | |||
End of changes. 146 change blocks. | ||||
324 lines changed or deleted | 524 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/ |