Using WG for transport security in a p2p network

[Ximin Luo]

On Fri, Apr 20, 2018 at 5:20 PM, Ximin Luo <ximin at dfinity.org> wrote:

> (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.
>
>
Here is another option that adds a half-round but is much simpler than
either of my suggestions above and doesn't involve modifying WG, so I think
I'll go with that. Might be useful for other people looking to do dynamic
auth on top of WG.

Peer A first authenticates and locates B via the parent protocol, adds B as
a WG peer, then:
 -> zk-proof "I am A, I am allowed to connect to you B"
Peer B verifies this proof and adds A as a WG peer, triggering the standard
WG protocol flow
 <- WG initiation, Noise_IKpsk2, etc
 ->
 <-, etc

Since it authorises the keys and WG stores these, it shouldn't be necessary
to re-run this after e.g a disconnection, WG should "just work" by itself.

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