From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ximin@dfinity.org Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 99d58c65 for ; Fri, 20 Apr 2018 15:44:23 +0000 (UTC) Received: from mail-io0-f173.google.com (mail-io0-f173.google.com [209.85.223.173]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id cb51961a for ; Fri, 20 Apr 2018 15:44:23 +0000 (UTC) Received: by mail-io0-f173.google.com with SMTP id f3-v6so11031698iob.13 for ; Fri, 20 Apr 2018 08:44:37 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Ximin Luo Date: Fri, 20 Apr 2018 17:44:36 +0200 Message-ID: Subject: Re: Using WG for transport security in a p2p network To: "Jason A. Donenfeld" Content-Type: multipart/alternative; boundary="000000000000c24919056a499040" Cc: WireGuard mailing list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --000000000000c24919056a499040 Content-Type: text/plain; charset="UTF-8" On Fri, Apr 20, 2018 at 5:20 PM, Ximin Luo wrote: > (reposting to the list, I'll learn one of these days..) > > On Fri, Apr 6, 2018 at 7:59 PM, Jason A. Donenfeld > 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 --000000000000c24919056a499040 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 20, 2018 at 5:20 PM, Ximin Luo <ximin@dfinity.org> w= rote:
(reposting to the list, I'll learn = one of these days..)
<= br>On Fri, Apr 6, 2018 at 7:59 PM, Jason A. Donenfeld <= ;Jason@zx2c4.com&g= t; 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=20 authenticate them. I was wondering what the options are for dynamic=20 authentication, of peer keys that one doesn't know beforehand. The=20 typical example would be a PAKE but for us it would be an alternative=20 zero-knowledge proof that the initiator's key belongs to some=20 allowed-set of peers wrt the responder's key, as defined by the rest of= =20 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=20 authenticate a client on the first packet without requiring further=20 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=20 recent global shared source of randomness (we have that in our=20 protocol). So one way would be for WG to hook into a custom function=20 that reads a custom certificate from the first incoming packet and say=20 whether it passes the test.

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

Other suggestions would be much appreciated.<= br>

Here is another option that adds a half-round but is much simpler than ei= ther of my suggestions above and doesn't involve modifying WG, so I thi= nk I'll go with that. Might be useful for other people looking to do dy= namic auth on top of WG.

Peer A first authenticates and l= ocates B via the parent protocol, adds B as a WG peer, then:
= =C2=A0-> 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
=C2=A0<- WG initiation, Noi= se_IKpsk2, etc
=C2=A0->
=C2=A0<-, etc
=
=C2=A0
Since it authorises the keys and WG stores = these, it shouldn't be necessary to re-run this after e.g a disconnecti= on, WG should "just work" by itself.

X

<= /div>
--000000000000c24919056a499040--