WireGuard Archive on lore.kernel.org
 help / color / 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
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.



[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

  reply index

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-12 21:01 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 publically 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:

* 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 \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

WireGuard Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/wireguard/0 wireguard/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 wireguard wireguard/ https://lore.kernel.org/wireguard \
	public-inbox-index wireguard

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git