From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: me.kalin@gmail.com Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 14d2e9a5 for ; Fri, 10 Aug 2018 13:58:47 +0000 (UTC) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 1815af6a for ; Fri, 10 Aug 2018 13:58:46 +0000 (UTC) Received: by mail-oi0-x229.google.com with SMTP id n21-v6so16021861oig.3 for ; Fri, 10 Aug 2018 07:10:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kalin KOZHUHAROV Date: Fri, 10 Aug 2018 17:09:56 +0300 Message-ID: Subject: Re: Reflections on WireGuard Design Goals To: Brian Candler Content-Type: multipart/alternative; boundary="0000000000001a15a50573154daf" Cc: WireGuard mailing list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --0000000000001a15a50573154daf Content-Type: text/plain; charset="UTF-8" Please excuse my brevity, phone typing here... On Fri, 10 Aug 2018, 16:36 Brian Candler, wrote: > Thanks for explaining the project background, and your very sensible > goals of simplicity and robustness. And thanks for releasing this > excellent piece of software. > > From my point of view, the only thing which makes me uncomfortable > about wireguard is the lack of any second authentication factor. Your > private key is embedded in a plaintext file in your device (e.g. > laptop), not even protected with a passphrase. Not always. You can generate it on the fly (say 1st boot, no config file), distribute it and be done. Or you can choose to protect it (e.g. pgp), may be even store it in a HSM. Or throw it (keep in RAM) and regenerate, if needed. Anyone who gains access > to that laptop is able to establish wireguard connections. > > Of course, it can be argued that the laptop holds other information > which is more valuable that the wireguard key, therefore you should > concentrate on properly securing the laptop itself (*). Furthermore, to > be able to talk to the wireguard kernel module you're already root, and > therefore have all sorts of malicious options available to you. etc etc > > But I'd feel a lot happier if a second level of authentication were > required to establish a wireguard connection, if no packets had been > flowing for more than a configurable amount of time - say, an hour. It > would give some comfort around lost/stolen devices. > And what do we do (count or not) keepalive traffic? Whilst I appreciate that wireguard is symmetrical, a common use case is > to have remote "clients" with a central "office". I'm thinking about a > hook whereby the "office" side could request extra authentication when > required - e.g. if it sees a connection from a wireguard public key > which has been idle for more than a configurable amount of time, then it > sends a challenge which requires (e.g.) a Yubikey to complete. I > appreciate that it's not going to be straightforward, requiring the > kernel module to talk to userland components at both ends. > That is way overcomplicated... And how did you solve your key distribution in such scenario BTW? (hint: the functionality you request is part of key handling, i.e. NOT part of wg, AFAIK). The office end can expire any user key and request sidechannel (additional, 2FA or more) authentication via the established link. Who says wg tunnel should be to the network core? Use a standard firewall, plug a RADIUS even, or script your way on top of wg. Feel free to provide a clean interface to wg and documentation and people who want that functionality will use the code. Is there anything (e.g. design-level) that prevents that? Or functionality that is lacking at the core? > > In the absence of that, it would be nice if the private key which is > stored on the laptop were encrypted with a passphrase. Simplest option > may be to extend wg-quick so that the entire config file can be > pgp-encrypted. > Now that also is not 2FA, and yes it should be a few lines of scripting. Kalin. --0000000000001a15a50573154daf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please excuse my brevity, phone typing here...
On Fri, 10 Aug 2018, 16:36 Br= ian Candler, <b.candler@pobox.com= > wrote:
Thanks for explaining the project background, and your very sensible
goals of simplicity and robustness.=C2=A0 And thanks for releasing this excellent piece of software.

=C2=A0From my point of view, the only thing which makes me uncomfortable about wireguard is the lack of any second authentication factor. Your
private key is embedded in a plaintext file in your device (e.g.
laptop), not even protected with a passphrase.=C2=A0
Not always. You can generate it on the fly (say 1st boo= t, no config file), distribute it and be done. Or you can choose to protect= it (e.g. pgp), may be even store it in a HSM. Or throw it (keep in RAM) an= d regenerate, if needed.

Anyone who gain= s access
to that laptop is able to establish wireguard connections.

Of course, it can be argued that the laptop holds other information
which is more valuable that the wireguard key, therefore you should
concentrate on properly securing the laptop itself (*). Furthermore, to be able to talk to the wireguard kernel module you're already root, and=
therefore have all sorts of malicious options available to you. etc etc

But I'd feel a lot happier if a second level of authentication were required to establish a wireguard connection, if no packets had been
flowing for more than a configurable amount of time - say, an hour. It
would give some comfort around lost/stolen devices.
<= /div>
And what do we do (count or not) keepalive traffic?<= /div>

Whilst I appreciate that wireguard is symmetrical, a common use case is to have remote "clients" with a central "office".=C2=A0= I'm thinking about a
hook whereby the "office" side could request extra authentication= when
required - e.g. if it sees a connection from a wireguard public key
which has been idle for more than a configurable amount of time, then it sends a challenge which requires (e.g.) a Yubikey to complete.=C2=A0 I
appreciate that it's not going to be straightforward, requiring the kernel module to talk to userland components at both ends.
=
That is way overcomplicated...=C2=A0
And how did you solve your key distribution in such scenario= BTW? (hint: the functionality you request is part of key handling, i.e. NO= T part of wg, AFAIK). The office end can expire any user key and request si= dechannel (additional, 2FA or more) authentication via the established link= . Who says wg tunnel should be to the network core? Use a standard firewall= , plug a RADIUS even, or script your way on top of wg. Feel free to provide= a clean interface to wg and documentation and people who want that functio= nality will use the code. Is there anything (e.g. design-level) that preven= ts that? Or functionality that is lacking at the core?

In the absence of that, it would be nice if the private key which is
stored on the laptop were encrypted with a passphrase.=C2=A0 Simplest optio= n
may be to extend wg-quick so that the entire config file can be
pgp-encrypted.

Now that also is not 2FA, and yes i= t should be a few lines of scripting.

Kalin.
--0000000000001a15a50573154daf--