[WireGuard] Pull-based peer configuration

[WireGuard] Pull-based peer configuration

[Baptiste Jonglez]

[-- Attachment #1: Type: text/plain, Size: 942 bytes --]

Hi,

Right now, the only method for configuring peers is "push-based",
i.e. using `wg` to push the public key and AllowedIPs for each peer to the
running wireguard instance.

I'm toying with the idea of a pull-based model, for instance storing peer
configuration in a Radius or SQL database.  But it seems like an
incredibly bad idea to integrate a Radius or SQL library inside the
kernel.

What about having a userspace daemon that wireguard can query from
kernelspace when a new peer connects?  Wireguard would basically ask "Is
this public key allowed to connect, and what are its AllowedIPs?".  The
daemon would then use whatever method it wants (flat file, SQL/Radius
database, LDAP…) to determine whether the peer is allowed and its
configuration.

I guess it looks a bit like the IKE daemon in IPsec (though not exactly,
since wireguard handles rekeying itself), which I'm not sure is a good
sign :)

Baptiste

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [WireGuard] Pull-based peer configuration

[Jason A. Donenfeld]

Hey,

I've thought about the same sort of thing, too. Indeed this would be
different from an IKE daemon, because it would just be a datastructure
provider, rather than a crypto protocol situation.

I envision two uses of a pull model: "please compute this ECDH
multiplication using some daemon-controlled private key" and "do you
recognize this public key? if so, please tell me the allowed-ips for
it." The former would allow easy integration into userspace smartcard
daemons. The latter would allow easy integration into database
systems.

All and all, this isn't that hard to do. All things that have to do
with public key crypto are already strictly ratelimited and running in
a relatively friendly and safe kthread, which can do things like sleep
and yield to userspace processes. It's just a matter of adding the
machinery and exposing the APIs. I can do this.

But it does add _just a tiny little bit_ of extra complexity, which
can quickly snowball into something dreadful. My general plan for
these more enterprise-centric features is to wait until after the
initial codebase is merged into mainline. I'd like to do the best job
we can do on the core principles and components, and once we have a
solid foundation, consider the best ways of building up. (IPsec did
the opposite -- a massive set of committees designed the whole thing,
and oy gevalt...)

What do you think of this approach to that?

Jason

mint (ubuntu) kernel Signing

[john huttley]

Hi Team,
I had been using the git version on my Mint 18.1 laptop

4.4.0-62-generic #83-Ubuntu SMP Wed Jan 18 14:09:55 UTC 2017 i686 i686 
i686 GNU/Linux

After upgrading the kernel to the above, it won't install the module.

I understand that this is because the module must be signed.


Does anyone have any experience with this?

Regards,

John

Re: mint (ubuntu) kernel Signing

[Jason A. Donenfeld]

Hey John,

Indeed if you have a secure-boot enabled kernel, you need to sign your
kernel modules before they can be inserted. One option is just to
disable secureboot and then restart:

sudo apt install mokutil
sudo mokutil --disable-validation

But if you'd like to retain the security of secureboot, then you can
add your own signing key to UEFI and sign the kernel module with it.
You can follow basically the same process as described in this
article: http://www.pellegrino.link/2015/11/29/signing-nvidia-proprietary-driver-on-fedora.html
Except you sign wireguard.ko in the end.

Let me know if you have trouble or require more explanation. If this
becomes a real sore point, I'll write some WireGuard-specific
documentation or even write some automated scripts. But I'd be
interested in your feedback first on the above.

Thanks,
Jason

Re: [WireGuard] Pull-based peer configuration

[jens]

On 22.11.2016 17:31, Jason A. Donenfeld wrote:
> But it does add _just a tiny little bit_ of extra complexity, which
> can quickly snowball into something dreadful. My general plan for
> these more enterprise-centric features is to wait until after the
> initial codebase is merged into mainline. 

just a small comment, freifunk a like we would love to see something
like this, but are also happy to wait a while - because we are used to
prefilled lists/configs with valid keys.
this would make things a lot easier. ;)
thx
-- 

make the world nicer, please use PGP encryption

Re: [WireGuard] Pull-based peer configuration

[Jason A. Donenfeld]

Hey Jens,

This work is in progress. Standby.

Jason

Re: [WireGuard] Pull-based peer configuration

[F. Hölzlwimmer]

Hi,


are there any updates on this?

I searched for a possibility to connect WireGuard to a per-user 
authorized_key store.
Optimally, it would work like SSH, i.e. the client executes `wg connect 
user@server.org -i ~/.ssh/id_rsa`.
The server then runs some user-space daemon to check whether the 
client's `~/.ssh/id_rsa.pub` is listed in the server's 
`~user/.ssh/authorized_keys` file.

Another use case would be to have a database of public keys (e.g. 
FreeIPA) which the user-space daemon checks for the client's public key.


Best,
Florian

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard