Reflections on WireGuard Design Goals

[Konstantin Ryabitsev]

On Fri, Aug 10, 2018 at 02:35:14PM +0100, Brian Candler wrote:
>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.  Anyone who gains access 
>to that laptop is able to establish wireguard connections.

I think one way of solving this is teaching the client-side tools to 
hook into the TPM. We still grab the key and store it in memory (as 
opposed to using TPM's crypto processing directly), but at least this 
way it's not lying around on disk somewhere, and it doesn't require 
changing anything about the protocol. I am hoping to hit up James 
Bottomley about it when I next see him -- he's already written quite a 
few tools that use TPM, including teaching GnuPG how to use it. :)

>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.

I believe this is orthogonal to the design of the protocol, which is 
supposed to behave in a "stateless" fashion and resume transparently 
after even prolonged downtimes. We use 2-factor authentication with 
OpenVPN, and one of the most annoying aspects about it is the fact that 
you have to manually re-auth after each VPN blip. If you don't do it 
quickly enough, all your sessions get reset -- most horrible experience 
if you are hoping your ssh connection to a server doesn't get severed in 
the middle of a yum update.

>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.

I think Wireguard's primary strength is its resilience to network blips 
and fast operation. We intend to use it for site-to-site connectivity 
across disjointed infrastructure where it will certainly operate much 
smoother than OpenVPN or ipsec. For admin-to-site connections we will 
continue to use OpenVPN or some combination thereof, until we figure out 
a straightforward way of "upgrading" access level of a wireguard 
connection. I suspect this is fairly easy with iptables and fwmark, but 
I need to test and streamline it.

-K
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20180810/1e8ed928/attachment-0001.asc>