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?

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

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.

Best,

Nico

[0] https://code.ungleich.ch/ungleich-public/ungleich-otp

Rémi Lapeyre <[email protected]> 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
> [email protected]
> https://lists.zx2c4.com/mailman/listinfo/wireguard


--
Your Swiss, Open Source and IPv6 Virtual Machine. Now on www.datacenterlight.ch.
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard

Reply via email to