Using WG for transport security in a p2p network

[Ximin Luo]

(reposting to the list, I'll learn one of these days..)

On Fri, Apr 6, 2018 at 7:59 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:

> [..]
>
> Let me know if you have any more questions or ways in which I can help
> you guys out with the p2p protocol.
>
>
Hey, thanks for the reply. Another issue came up while I've been looking
into this:

At present, one has to manually add specific peers in order for WG to
authenticate them. I was wondering what the options are for dynamic
authentication, of peer keys that one doesn't know beforehand. The typical
example would be a PAKE but for us it would be an alternative
zero-knowledge proof that the initiator's key belongs to some allowed-set
of peers wrt the responder's key, as defined by the rest of the protocol
(I'm being vague because the details are TBD, actually).

It would be nice to keep WG's current property of being able to
authenticate a client on the first packet without requiring further
communication. To reduce the DoS-potential of having to verify a complex zk
proof, we can probably also include a proof-of-work linked to a recent
global shared source of randomness (we have that in our protocol). So one
way would be for WG to hook into a custom function that reads a custom
certificate from the first incoming packet and say whether it passes the
test.

Alternatively we can listen on another socket, perform the custom check on
incoming packets here, and then forward passing packets with our custom
portion stripped out onto the local WG socket. Hopefully this would "just
work" if the "from" address on the UDP packet is correct. However,
initiating these would be tricky, we'd have to intercept the WG initial
outgoing packet and rewrite it.

Other suggestions would be much appreciated.

X
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20180420/0836c1ea/attachment.html>