Adding 2FA to WireGuard

[Rémi Lapeyre]

Le 13 septembre 2019 à 14:49:31, Nico Schottelius
(nico.schottelius at ungleich.ch(mailto:nico.schottelius at ungleich.ch)) a
écrit:

>
> Hey Rémi,
>
> that is very welcome news. We might actually also be interested in
> this. Are you by any change using pyotp for your server?

Hi Nico, yes pyotp is the implementation I use on the server, but anything
Compatible with rfc6238 should work.

> We have written ungleich-otp [0] that extends the otp approach with
> realms similar to kerberos.

This looks interesting, I will move the code that validate the OTP in a
separate class so that another validation backend like one based on this
project can be used instead of reading the seeds from a SQLite file like
I’m doing now.

I did not see any kind of cool down in
https://code.ungleich.ch/ungleich-public/ungleich-otp/blob/master/otpauth/serializer.py.
Are you not worried that someone
could try to brute-force the OTP validation?

> In regard to faking the address: given that there are no other routes /
> servers in your network that can send traffic *from* that particular IP
> range, your assumption should hold.

Thanks :)

> Best,
>
> Nico
>
> [0] https://code.ungleich.ch/ungleich-public/ungleich-otp
>
> Rémi Lapeyre writes:
>
> > Hi everybody! We are using WireeGuard on Mac and Linux which works great
> > but for
> > compliance purpose, we would like to be able to add an OTP challenge on
> > connection.
> >
> > I've been looking at the archive of the mailing list and at the various
> > projects
> > built around WireGuard and started writing an implementation based on the
> > idea
> > from https://lists.zx2c4.com/pipermail/wireguard/2017-September/001741.html:
> >
> >> Alternatively, you could do OTP in-band, in order to authorize that
> >> public key for a certain window of time before inactivity. In this
> >> scheme, you'd disallow access to the network segment based on firewall
> >> rules until a certain in-band challenge is made -- perhaps by
> >> contacting a certain sandboxed server and answering an OTP challenge
> >> there
> >
> > My current implementation (I plan to publish it under MIT license once it's
> > ready) has a Python server on the WireGuard server bound to the wg interface
> > that add an IPTable rule to allow the traffic for a given amount of time
> > when
> > a TOTP is received over TCP. Here are some details
> >
> > - The TOTP is bound to the internal tunnel IP address so the IP address
> > that
> > opens the TCP connection is used to identify the user, as thee packet
> > must
> > have been decrypted, it seems to me that there is no way to spoof this.
> >
> > - A small text protocol let the user log-in, log-out and read the status
> > of the
> > connection.
> >
> > The client needs to send the TOTP just after connecting to the server, for
> > which
> > I had hoped to use the "PostUp" field of wg-quick.
> >
> > {Post,Pre}-{Up,Down} seems to be only available on wg-quick for now but we
> > are
> > using the wireguard-apple client so I have a few questions:
> >
> > 1. Is the absence of support {Post,Pre}-{Up,Down} in wireguard-apple on
> > purpose or would a patch to add this welcomed?
> >
> > 2. Is this way to do the OTP authentication sound?
> >
> > 3. I've seen that TunSafe has added an extension to the WireGuard
> > protocol so
> > the TOTP auth would not be shared by an attacker that succeded to connect
> > when
> > the user is already connected. This seems like a good idea to do, what
> > are your
> > thougts about this? Would you recommend against my "easier"
> > implementation?
> >
> > 4. I know that TunSafe was strongly advised against when it was
> > closed-source.
> > Now that it is AGPL code, is it still the case?
> >
> > One more thing, to simplify the deployment of WireGuard, I would like to
> > propose
> > a change in the way the MacOS client import WireGuard configurations from a
> > file.
> >
> > Our current flow is "Please open the WireGuard app, click on create Tunnel,
> > give
> > it a name, paste this configuration underneath what's already written, hit
> > save
> > and send us your public key". It gives a lot of oportunity to the user to
> > mistype something and make changing the configuration cumbersome ("Edit the
> > tunnel, don't touch the `[Interface]` part but replace what's underneath by
> > this") so I would like to be able to send to the user a configuration file
> > with
> > the PrivateKey missing and have the WireGuard client generate one on the
> > fly but
> > this currently gives an error "Interface’s private key is required". Would
> > sending a patch for this be welcomed too?
> >
> >
> > Thanks for taking the time to help me, I look forward to contribute to
> > WireGuard :)
> >
> > Rémi
> > _______________________________________________
> > WireGuard mailing list
> > WireGuard at lists.zx2c4.com
> > https://lists.zx2c4.com/mailman/listinfo/wireguard
>
>
> --
> Your Swiss, Open Source and IPv6 Virtual Machine. Now on www.datacenterlight.ch.