Draft: draft-ietf-taps-transport-security

Commentary: As promised , here 's the first draft of the OpenVPN section . I think I captured all relevant properties and dependencies , and actually I think OpenVPN is quite an interesting combination . My sources are : - provides a good overview - provides some detailed protocol mechanics - current version , mentions current default ciphers , mobility , cipher negotiation Unfortunately , I could not find a stable reference . The current release is version 2.4.6 . Most books , PDFs , etc . , both refer to older versions and do not contain the relevant information . The only sort - of stable page would be version 1 of this wiki page , which was migrated from an old web server 4 years ago : I 'm still wondering if it makes sense to mention the version this section is based on , if it makes sense to cite more of these web pages , and if it makes sense to call out the lack of stable reference . What do you think ?
Paragraph (version A):
This document provides a survey of commonly used or notable network
security protocols, with a focus on how they interact and integrate
with applications and transport protocols.  Its goal is to supplement
efforts to define and catalog transport services RFC8095 by
describing the interfaces required to add security protocols.  It
examines Transport Layer Security (TLS), Datagram Transport Layer
Security (DTLS), Quick UDP Internet Connections with TLS (QUIC +
TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with
Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and
WireGuard.  This survey is not limited to protocols developed within
the scope or context of the IETF, and those included represent a
superset of features a TAPS system may need to support.
Paragraph (version B):
This document provides a survey of commonly used or notable network
security protocols, with a focus on how they interact and integrate
with applications and transport protocols.  Its goal is to supplement
efforts to define and catalog transport services RFC8095 by
describing the interfaces required to add security protocols.  It
examines Transport Layer Security (TLS), Datagram Transport Layer
Security (DTLS), Quick UDP Internet Connections with TLS (QUIC +
TLS), tcpcrypt, Internet Key Exchange with Encapsulating Security
Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP,
MinimalT.  This survey is not limited to protocols developed within
the scope or context of the IETF, and those included represent a
superset of features a TAPS system may need to support.
Paragraph (version A):
This document provides a survey of commonly used or notable network
security protocols, with a focus on how they interact and integrate
with applications and transport protocols.  Its goal is to supplement
efforts to define and catalog transport services RFC8095 by
describing the interfaces required to add security protocols.  It
examines Transport Layer Security (TLS), Datagram Transport Layer
Security (DTLS), Quick UDP Internet Connections with TLS (QUIC +
TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with
Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and
WireGuard.  For each protocol, this document provides a brief
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.
Paragraph (version B):
This document provides a survey of commonly used or notable network
security protocols, with a focus on how they interact and integrate
with applications and transport protocols.  Its goal is to supplement
efforts to define and catalog transport services RFC8095 by
describing the interfaces required to add security protocols.  It
examines Transport Layer Security (TLS), Datagram Transport Layer
Security (DTLS), Quick UDP Internet Connections with TLS (QUIC +
TLS), tcpcrypt, Internet Key Exchange with Encapsulating Security
Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP, and
MinimalT.  For each protocol, this document provides a brief
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.
Paragraph (version A):
Forward-secure key establishment: Cryptographic key establishment
with forward secure properties.
Paragraph (version B):
Forward-secure session key establishment: Cryptographic key
establishment with forward secure properties.
Paragraph (version A):
Application-layer authentication delegation: Out-of-band peer
authentication performed by applications outside of the connection
establishment.
Paragraph (version B):
Unilateral responder authentication: Required authentication for
the responder of a connection.
Paragraph (version B):
Application authentication delegation: Out-of-band peer
authentication performed by applications outside of the connection
establishment.
Paragraph (version A):
Mandatory server authentication, optional client authentication.
Paragraph (version B):
DTLS relies on UDP.
Paragraph (version B):
For the handshake: Reliable, in-order transport.  DTLS provides
its own reliability.
Paragraph (version B):
For the handshake: Reliable, in-order transport.  QUIC provides
its own reliability.
Paragraph (version A):
IKEv2 is a control protocol that runs on UDP port 500.  Its primary
goal is to generate keys for Security Associations (SAs).  An SA
contains shared (cryptographic) information used for establishing
other SAs or keying ESP; See ESP.  IKEv2 first uses a Diffie-Hellman
key exchange to generate keys for the "IKE SA", which is a set of
keys used to encrypt further IKEv2 messages.  It then goes through a
phase of authentication in which both peers present 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.
Paragraph (version A):
IKEv2 negotiates which protocols are acceptable to each peer for both
the IKE and Child SAs using "Proposals".  Each proposal may contain
an encryption algorithm, an authentication algorithm, a Diffie-
Hellman group, and (for IKE SAs only) a pseudorandom function
algorithm.  Each peer may support multiple proposals, and the most
preferred mutually supported proposal is chosen during the handshake.
Paragraph (version A):
Any SA used by IKEv2 can be rekeyed upon expiration, which is usually
based either on time or number of bytes encrypted.
Paragraph (version A):
MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a
set of Security Associations to migrate over different addresses and
interfaces RFC4555.
Paragraph (version B):
Secure RTP can run over UDP or TCP.
Paragraph (version A):
MinimalT is a secure transport protocol built on top of a widespread
directory service.  Clients and servers interact with local directory
services to (a) resolve server information and (b) public ephemeral
state information, respectively.  Clients connect to a local resolver
once at boot time.  Through this resolver they recover the IP
address(es) and public key(s) of each server to which they want to
connect.
Paragraph (version A):
The use of public-key encryption and authentication, or "boxing", is
done to simplify problems that come with symmetric key management and
synchronization.  For example, it allows the sender of a message to
be in complete control of each message's nonce.  It does not require
either end to share secret keying material.  Furthermore, it allows
connections (or sessions) to be associated with unique ephemeral
public keys as a mechanism for enabling forward secrecy given the
risk of long-term private key compromise.
Paragraph (version A):
CurveCP supports a weak form of client authentication.  Clients are
permitted to send their long-term public keys in the second
initialization packet.  A server can verify this public key and, if
untrusted, drop the connection and subsequent data.
Paragraph (version B):
OpenVPN OpenVPN is a commonly used protocol designed as an
alternative to IPsec.  A major goal of this protocol is to provide a
VPN that is simple to configure and works over a variety of
transports.  OpenVPN encapsulates either IP packets or Ethernet
frames within a secure tunnel and can run over UDP or TCP.
Paragraph (version B):
OpenVPN facilitates authentication using either a pre-shared static
key or using X.509 certificates and TLS.  In pre-shared key mode,
OpenVPN derives keys for encryption and authentication directly from
one or multiple symmetric keys.  In TLS mode, OpenVPN encapsulates a
TLS handshake, in which both peers must present a certificate for
authentication.  After the handshake, both sides contribute random
source material to derive keys for encryption and authentication
using the TLS pseudo random function (PRF).  OpenVPN provides the
possibility to authenticate and encrypt the TLS handshake itself
using a pre-shared key or passphrase.  Furthermore, it supports
rekeying using TLS.
Paragraph (version B):
After authentication and key exchange, OpenVPN encrypts payload data,
i.e., IP packets or Ethernet frames, and signs the payload using an
HMAC function.  The default cipher is BlowFish BlowFish and the
default message digest algorithm is SHA1, but an application can
select an arbitrary cipher, key size, and message digest algorithm
for the HMAC.  OpenVPN peers support cipher negotiation (NCP) since
version 2.4, in which case they will upgrade the cipher to AES-
256-GCM by default.
Paragraph (version B):
OpenVPN can run over TCP or UDP.  When running over UDP, OpenVPN
provides a simple reliability layer for control packets such as the
TLS handshake and key exchange.  It assigns sequence numbers to
packets, acknowledges packets it receives, and retransmits packets it
deems lost.  Similar to DTLS, this reliability layer is not used for
data packets, which prevents the problem of two reliability
mechanisms being encapsulated within each other.  When running over
TCP, OpenVPN includes the packet length in the header, which allows
the peer to deframe the TCP stream into messages.
Paragraph (version B):
For replay protection, OpenVPN assigns an identifier to each outgoing
packet, which is unique for the packet and the currently used key.
In pre-shared key mode or with a CFB or OFB mode cipher, OpenVPN
combines a timestamp with an incrementing sequence number into a
64-bit identifier.  In TLS mode with CBC cipher mode, OpenVPN omits
the timestamp, so identifiers are only 32-bit.  This is sufficient
since OpenVPN can guarantee the uniqueness of this identifier for
each key, as it can trigger rekeying if needed.
Paragraph (version B):
OpenVPN supports connection mobility by allowing a peer to change its
IP address during an ongoing session.  When configured accordingly, a
host will accept authenticated packets for a session from any IP
address.
Paragraph (version B):
Peer authentication using certificates or pre-shared key.
Paragraph (version B):
Mandatory mutual authentication.
Paragraph (version B):
Connection mobility.
Paragraph (version B):
Out-of-order record receipt.
Paragraph (version B):
Length-hiding padding.
Paragraph (version B):
See also the properties of TLS.
Paragraph (version B):
For control packets such as handshake and key exchange: Reliable,
in-order transport.  Reliability is provided either by TCP, or by
OpenVPN's own reliability layer when using UDP.
Paragraph (version A):
Mandatory features must be supported regardless of transport and
application services available.
Paragraph (version A):
Public-key certificate based authentication.
Paragraph (version A):
Application dependency: Mutual authentication credentials
required for application support.
Paragraph (version A):
Application dependency: Knowledge of desired padding policies.