From: Nico Schottelius <nico.schottelius@ungleich.ch>
To: "Rémi Lapeyre" <remi.lapeyre@lenstra.fr>
Cc: wireguard@lists.zx2c4.com
Subject: Re: Adding 2FA to WireGuard
Date: Fri, 13 Sep 2019 21:49:28 +0900 [thread overview]
Message-ID: <878sqs8ip3.fsf@line.ungleich.ch> (raw)
In-Reply-To: <CAFsReqSUQYthBTr4o7HQQGdNUgzA33i9hAoJ_UieNUzJbB=hLA@mail.gmail.com>
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 <remi.lapeyre@lenstra.fr> 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@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
--
Your Swiss, Open Source and IPv6 Virtual Machine. Now on www.datacenterlight.ch.
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
next prev parent reply other threads:[~2019-09-13 12:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-12 21:01 Adding 2FA to WireGuard Rémi Lapeyre
2019-09-13 12:49 ` Nico Schottelius [this message]
2019-09-13 13:17 ` Rémi Lapeyre
2019-09-13 13:22 ` Nico Schottelius
2019-09-15 16:46 ` Rene 'Renne' Bartsch, B.Sc. Informatics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878sqs8ip3.fsf@line.ungleich.ch \
--to=nico.schottelius@ungleich.ch \
--cc=remi.lapeyre@lenstra.fr \
--cc=wireguard@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).