From patchwork Wed Jul 4 07:53:59 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steffan Karger X-Patchwork-Id: 404 Return-Path: Delivered-To: patchwork@openvpn.net Delivered-To: patchwork@openvpn.net Received: from director8.mail.ord1d.rsapps.net ([172.27.255.56]) by backend30.mail.ord1d.rsapps.net (Dovecot) with LMTP id 1ExDAicKPVuSBwAAIUCqbw for ; Wed, 04 Jul 2018 13:55:51 -0400 Received: from proxy3.mail.iad3a.rsapps.net ([172.27.255.56]) by director8.mail.ord1d.rsapps.net (Dovecot) with LMTP id Y1frEScKPVsyJgAAfY0hYg ; Wed, 04 Jul 2018 13:55:51 -0400 Received: from smtp22.gate.iad3a ([172.27.255.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by proxy3.mail.iad3a.rsapps.net with LMTP id SIfGDycKPVutTAAAYaqY3Q ; Wed, 04 Jul 2018 13:55:51 -0400 X-Spam-Threshold: 95 X-Spam-Score: 0 X-Spam-Flag: NO X-Virus-Scanned: OK X-Orig-To: openvpnslackdevel@openvpn.net X-Originating-Ip: [216.105.38.7] Authentication-Results: smtp22.gate.iad3a.rsapps.net; iprev=pass policy.iprev="216.105.38.7"; spf=pass smtp.mailfrom="openvpn-devel-bounces@lists.sourceforge.net" smtp.helo="lists.sourceforge.net"; dkim=fail (signature verification failed) header.d=sourceforge.net; dkim=fail (signature verification failed) header.d=sf.net; dkim=fail (signature verification failed) header.d=karger-me.20150623.gappssmtp.com; dmarc=none (p=nil; dis=none) header.from=karger.me X-Suspicious-Flag: YES X-Classification-ID: 7c9ed57e-7fb3-11e8-8018-5254005ae9fe-1-1 Received: from [216.105.38.7] ([216.105.38.7:43554] helo=lists.sourceforge.net) by smtp22.gate.iad3a.rsapps.net (envelope-from ) (ecelerity 4.2.1.56364 r(Core:4.2.1.14)) with ESMTPS (cipher=DHE-RSA-AES256-GCM-SHA384) id 71/B1-30269-62A0D3B5; Wed, 04 Jul 2018 13:55:50 -0400 Received: from [127.0.0.1] (helo=sfs-ml-2.v29.lw.sourceforge.com) by sfs-ml-2.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1falzK-0003SA-6O; Wed, 04 Jul 2018 17:54:46 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1falzH-0003Rl-H9 for openvpn-devel@lists.sourceforge.net; Wed, 04 Jul 2018 17:54:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=References:In-Reply-To:Message-Id:Date:Subject:Cc: To:From:Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=tULkX6Errkm2MLeV5W55UUoGVvQOFeM3zBxiUvlSn50=; b=gzokjPpGgoW3AB0t4njcmfmsno tQ97HgJCtvCYw6lw57RdaJvYqF/0WZw7kQ0VXdJFnhpODjWbwRDb46tdrDT/sLHoKN8//2NnOgxZx +AlqSQZ668H3OZ13yh4SI2LoBI/uc+gwzKda2LKmyms1pHsXXsSe56DBlMPl8R860O3Q=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To :MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=tULkX6Errkm2MLeV5W55UUoGVvQOFeM3zBxiUvlSn50=; b=C9PNsxMYw1GiyNVFmn7i/3nVYt 0fzJyJpv5K692z7nkbtmiiw/gkmkc9BanUU+Q/adJ3IMFAnVA/TaO7UKpWZCAk1ZrIOoIk+qc36DL xt71xWelzwLANiBXgCweDKBh+ts8O5cDUXZff9uRAKd3r4+j3ngq4O/+3Hw26qB0Q4dw=; Received: from mail-ed1-f54.google.com ([209.85.208.54]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) id 1falzF-00GkHw-LJ for openvpn-devel@lists.sourceforge.net; Wed, 04 Jul 2018 17:54:43 +0000 Received: by mail-ed1-f54.google.com with SMTP id g15-v6so4561491edr.12 for ; Wed, 04 Jul 2018 10:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karger-me.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=tULkX6Errkm2MLeV5W55UUoGVvQOFeM3zBxiUvlSn50=; b=pKfSSmhFS5wu0ckJgAzvlMV+57/jgnLohay8yr8pI39QRGx1LYTrP7e7150YNTyCMm XpBQ2RezyAujeWRC2C3E8o9PdcGQ03CeBL7UnOXWrQ5CpqR9h5SlQJU5OZAsXpAwgQos lJW5k+GglVNI97CSP6fy0UBpFwzqm9IHXJpbvTi0hUivq+0h9DtJ3/qOpWHVYs2wgW4M SGNxUTWpr+cvIdFiqhnsNZyhKGiAWBjPQdpD0Q3O2f+2F4x9AUr935G/EwUYI3xJF5Ut yNRAffN4h8J5tFTVdBoNwW0D5tb/KwZhmwkokQKPOdm17M4o5BeHA51oDJSvs4fYb4OL /vMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=tULkX6Errkm2MLeV5W55UUoGVvQOFeM3zBxiUvlSn50=; b=eUcIsYjr/KbzAsROxwjAuedyjEGiuHcgN/WsUwhWugk5By7pFJdBHB1ug6vH3vwWS/ j2RmRk362jHWeYClGoS0mRlD7SGSTxatnuHEPMNSSe5Za6ir0iHv+8zg7wYL0JOGY+8U RBnLMPnN3Z8JhIwD/Wo4sh46BNZAjR6o9j/p1eNH3kbGCNZEApC6eaaARH1AIzQECEju iWr0no8lkthA3t7ImybSFEda0oGmbzF3h/cQcQccYDdFOOlXRf33wfCvBP5ffxSMEkV7 Be72Dax5vdob6RAjT1gM/OfoMaePEz2FZtob4/zstGwPlr69zcF6+8hMZVbHAB0rX6Tv lMqw== X-Gm-Message-State: APt69E11E7tT7Vnh3kpkEsIX8TCHYodO6IlnEGWj5DUEpXHX8S+9Qi7L SjJGK17X+NrBH9Vs+x9P9AqtZFoAyWI= X-Google-Smtp-Source: AAOMgpfFe1CY2HZGtsEYFOkERXgp+gKvV6dlbCY8PYid3ZGOMeE5lxQOJjf0dPaJYyzjPuKeREWJFw== X-Received: by 2002:a50:adaa:: with SMTP id a39-v6mr3808300edd.194.1530726874813; Wed, 04 Jul 2018 10:54:34 -0700 (PDT) Received: from vesta.fritz.box ([2001:985:e54:1:f598:331e:3cdf:2649]) by smtp.gmail.com with ESMTPSA id o2-v6sm1948961edd.84.2018.07.04.10.54.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jul 2018 10:54:34 -0700 (PDT) From: Steffan Karger To: openvpn-devel@lists.sourceforge.net Date: Wed, 4 Jul 2018 19:53:59 +0200 Message-Id: <20180704175404.22371-4-steffan@karger.me> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20180704175404.22371-1-steffan@karger.me> References: <1512734870-17133-1-git-send-email-steffan.karger@fox-it.com> <20180704175404.22371-1-steffan@karger.me> X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.208.54 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.208.54 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.0 T_DKIMWL_WL_MED DKIMwl.org - Whitelisted Medium sender X-Headers-End: 1falzF-00GkHw-LJ Subject: [Openvpn-devel] [PATCH v2 4/9] tls-crypt-v2: add specification to doc/ X-BeenThere: openvpn-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: openvpn-devel-bounces@lists.sourceforge.net X-getmail-retrieved-from-mailbox: Inbox 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 --- doc/tls-crypt-v2.txt | 164 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 164 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 00000000..578b2f9b --- /dev/null +++ b/doc/tls-crypt-v2.txt @@ -0,0 +1,164 @@ +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 clients 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 loosing 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 (clients 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 OpenVPN's ``--genkey``. This key + contains 4 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: PEM-encode ``Kc || WKc`` and store 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 its config, and: + + 1. loads ``Kc`` as its tls-crypt key, + 2. stores ``WKc`` in memory for sending to the server. + +2. To start the connection, the client creates a P_CONTROL_HARD_RESET_CLIENT_V3 + message without payload, wraps it with tls-crypt using ``Kc`` as the key, + and appends ``WKc``. (``WKc`` must not be encrypted, to prevent a + chicken-and-egg problem.) + +3. The server receives the P_CONTROL_HARD_RESET_CLIENT_V3 message, and + + a. unwraps ``WKc`` and strips ``WKc`` from the message. + b. uses unwrapped ``Kc`` to verify the remaining + P_CONTROL_HARD_RESET_CLIENT_V3 message's authentication. + + The message is dropped and no error response is sent when either a or b + fails (DoS protection). + +4. Server optionally checks metadata using a --tls-crypt-v2-verify script + + Metadata could for example contain the users certificate serial, such that + the incoming connection can be verified against a CRL, or a notAfter + timestamp that limits the key's validity period. + + This allows early abort of connection, *before* we expose any of the + notoriously dangerous TLS, X.509 and ASN.1 parsers and thereby reduces the + attack surface of the server. + + 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.) + + RFC: should the server send a 'key rejected' message if the key is e.g. + revoked or expired? That allows for better client-side error reporting, but + also reduces the DoS resilience. + +6. Client and server use ``Kc`` for (un)wrapping any following control channel + messages. + + +Considerations +-------------- + +To allow for a smooth transition, the server implementation allows +``tls-crypt`` or ``tls-auth`` to be used simultaneously with ``tls-crypt-v2``. +This specification does not allow simultaneously using ``tls-crypt-v2`` and +connections without any control channel wrapping, because that would break DoS +resilience. RFC: should we add an option along the lines of +--tls-crypt-v2-allow-insecure-fallback to allow admins to enable this anyway? +It might help with transitioning. + +``tls-crypt-v2`` uses fixed crypto algorithms, because: + + * The crypto is used before we can do any negotiation, so the algorithms have + to be predefined. + * The crypto primitives are chosen conservatively, making problems with these + primitives unlikely. + * Making anything configurable adds complexity, both in implementation and + usage. We should not add anymore complexity than is absolutely necessary. + +Potential ``tls-crypt-v2`` risks: + + * Slightly more work on first connection (``WKc`` unwrap + hard reset unwrap) + than with ``tls-crypt`` (hard reset unwrap) or ``tls-auth`` (hard reset auth). + * Flexible metadata allow mistakes + (So we should make it easy to do it right. Provide tooling to create client + keys based on cert serial + CA fingerprint, provide script that uses CRL (if + available) to drop revoked keys.)