Hi Rèmi,
I suggested to use use FIDO2/CTAP2 hardware tokens about a week ago.
For in-band signaling I suggest to use OrchidV2 addresses derived from
the public key (https://www.rfc-editor.org/rfc/pdfrfc/rfc7343.txt.pdf).
That way any peer can calculate the addresses of the other peers from
their public keys without the need of a lookup table.
Regards,
Renne
Am 12.09.19 um 23:01 schrieb Rémi Lapeyre:
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
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard
