Re: [Openvpn-devel] [PATCH v2] tls-crypt-v2: add specification to doc/

[Steffan Karger]

Hi Antonio,

Sorry for taking so long to respond - life was getting in the way.

On 16-04-18 15:03, Antonio Quartulli wrote:
> there was a comment in my previous review that remained unanswer.
> Please, see it below
> 
> On 09/03/18 04:23, Steffan Karger wrote:
> [CUT]
>> +   The metadata is checked *after* the OpenVPN three-way handshake has
>> +   completed, to prevent DoS attacks.  (That is, once the client has proved 
>> to
>> +   the server that it possesses Kc, by authenticating a packet that 
>> contains the
>> +   session ID picked by the server.)
> 
> 
> just a thought here: the metadata is actually created by the
> server/provider and it is authenticated/encrypted with the server key.
> 
> Isn't this enough to ensure that its content is not malicious and thus
> allow the server to parse it right after having received the
> HARD_RESET_V3 (instead of performing a "three-way handshake" first)?

Not really, because a mitm attacker can simply record the cookie, and
replay it.  By postponing our parsing, we reduce the impact of a DoS by
an attacker that is setting up many new connections with the cookie
attached.  Instead of performing a potential expensive check (running a
script) for each HARD_RESET_V3, all we do is unwrap and reply.  In more
formal terms, we require a proof-of-possession of Kc before we will do
any (potential) expensive operations.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2] tls-crypt-v2: add specification to doc/

[Antonio Quartulli]

Hi,

there was a comment in my previous review that remained unanswer.
Please, see it below

On 09/03/18 04:23, Steffan Karger wrote:
[CUT]
> +   The metadata is checked *after* the OpenVPN three-way handshake has
> +   completed, to prevent DoS attacks.  (That is, once the client has proved 
> to
> +   the server that it possesses Kc, by authenticating a packet that contains 
> the
> +   session ID picked by the server.)


just a thought here: the metadata is actually created by the
server/provider and it is authenticated/encrypted with the server key.

Isn't this enough to ensure that its content is not malicious and thus
allow the server to parse it right after having received the
HARD_RESET_V3 (instead of performing a "three-way handshake" first)?


Cheers,


-- 
Antonio Quartulli



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH v2] tls-crypt-v2: add specification to doc/

[Steffan Karger]

From: Steffan Karger 

This is a preliminary description of tls-crypt-v2.  It should give a good
impression about the reasoning and design behind tls-crypt-v2, but might
need some polishing and updating.

Signed-off-by: Steffan Karger 
---
v2: update text for --tls-crypt-v2-genkey, fix typo

 doc/tls-crypt-v2.txt | 165 +++
 1 file changed, 165 insertions(+)
 create mode 100644 doc/tls-crypt-v2.txt

diff --git a/doc/tls-crypt-v2.txt b/doc/tls-crypt-v2.txt
new file mode 100644
index ..cb061aee
--- /dev/null
+++ b/doc/tls-crypt-v2.txt
@@ -0,0 +1,165 @@
+Client-specific tls-crypt keys (--tls-crypt-v2)
+===
+
+This document describes the ``--tls-crypt-v2`` option, which enables OpenVPN
+to use client-specific ``--tls-crypt`` keys.
+
+Rationale
+-
+
+``--tls-auth`` and ``tls-crypt`` use a pre-shared group key, which is shared
+among all client and servers in an OpenVPN deployment.  If any client or
+server is compromised, the attacker will have access to this shared key, and it
+will no longer provide any security.  To reduce the risk of losing pre-shared
+keys, ``tls-crypt-v2`` adds the ability to supply each client with a unique
+tls-crypt key.  This allows large organisations and VPN providers to profit
+from the same DoS and TLS stack protection that small deployments can already
+achieve using ``tls-auth`` or ``tls-crypt``.
+
+Also, for ``tls-crypt``, even if all these peers succeed in keeping the key
+secret, the key lifetime is limited to roughly 8000 years, divided by the
+number of clients (see the ``--tls-crypt`` section of the man page).  Using
+client-specific keys, we lift this lifetime requirement to roughly 8000 years
+for each client key (which "Should Be Enough For Everybody (tm)").
+
+
+Introduction
+
+
+``tls-crypt-v2`` uses an encrypted cookie mechanism to introduce
+client-specific tls-crypt keys without introducing a lot of server-side state.
+The client-specific key is encrypted using a server key.  The server key is the
+same for all servers in a group.  When a client connects, it first sends the
+encrypted key to the server, such that the server can decrypt the key and all
+messages can thereafter be encrypted using the client-specific key.
+
+A wrapped (encrypted and authenticated) client-specific key can also contain
+metadata.  The metadata is wrapped together with the key, and can be used to
+allow servers to identify clients and/or key validity.  This allows the server
+to abort the connection immediately after receiving the first packet, rather
+than performing an entire TLS handshake.  Aborting the connection this early
+greatly improves the DoS resilience and reduces attack service against
+malicious clients that have the ``tls-crypt`` or ``tls-auth`` key.  This is
+particularly relevant for large deployments (think lost key or disgruntled
+employee) and VPN providers (client are not trusted).
+
+To allow for a smooth transition, ``tls-crypt-v2`` is designed such that a
+server can enable both ``tls-crypt-v2`` and either ``tls-crypt`` or
+``tls-auth``.  This is achieved by introducing a P_CONTROL_HARD_RESET_CLIENT_V3
+opcode, that indicates that the client wants to use ``tls-crypt-v2`` for the
+current connection.
+
+For an exact specification and more details, read the Implementation section.
+
+
+Implementation
+--
+
+When setting up a tls-crypt-v2 group (similar to generating a tls-crypt or
+tls-auth key previously):
+
+1. Generate a tls-crypt-v2 server key using ``--tls-crypt-v2-genkey``.  This
+   key contains 2 512-bit keys, of which we use:
+
+   * the first 256 bits of key 1 as AES-256-CTR encryption key ``Ke``
+   * the first 256 bits of key 2 as HMAC-SHA-256 authentication key ``Ka``
+
+2. Add the tls-crypt-v2 server key to all server configs
+   (``tls-crypt-v2 /path/to/server.key``)
+
+
+When provisioning a client, create a client-specific tls-crypt key:
+
+1. Generate 2048 bits client-specific key ``Kc``
+2. Optionally generate metadata
+3. Create a wrapped client key ``WKc``, using the same nonce-misuse-resistant
+   SIV conruction we use for tls-crypt:
+
+   ``T = HMAC-SHA256(Ka, Kc || metadata)``
+
+   ``IV = 128 most significant bits of T``
+
+   ``WKc = T || AES-256-CTR(Ke, IV, Kc || metadata)``
+
+4. Create a tls-crypt-v2 client key using ``--tls-crypto-v2-genkey``.  This
+   PEM-encodes ``Kc || WKc`` and stores it in a file, using the header
+   ``-BEGIN OpenVPN tls-crypt-v2 client key-`` and the footer
+   ``-END OpenVPN tls-crypt-v2 client key-``.  (The PEM format is
+   simple, and following PEM allows us to use the crypto lib function for
+   en/decoding.)
+5. Add the tls-crypt-v2 client key to the client config
+   (``tls-crypt-v2 /path/to/client-specific.key``)
+
+
+When setting up the openvpn connection:
+
+1. The client reads the tls-crypt-v2 key from