wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
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

  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).