WireGuard Archive on lore.kernel.org
 help / color / Atom feed
From: "Rémi Lapeyre" <remi.lapeyre@lenstra.fr>
To: Nico Schottelius <nico.schottelius@ungleich.ch>
Cc: wireguard@lists.zx2c4.com
Subject: Re: Adding 2FA to WireGuard
Date: Fri, 13 Sep 2019 15:17:56 +0200
Message-ID: <CAFsReqTThNXkkPH+_YHOhC_DEbKwY5rPdmRDVJxLiTQbhfAbDA@mail.gmail.com> (raw)
In-Reply-To: <878sqs8ip3.fsf@line.ungleich.ch>

Le 13 septembre 2019 à 14:49:31, Nico Schottelius
(nico.schottelius@ungleich.ch(mailto:nico.schottelius@ungleich.ch)) a
écrit:

>
> 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?

Hi Nico, yes pyotp is the implementation I use on the server, but anything
Compatible with rfc6238 should work.

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

This looks interesting, I will move the code that validate the OTP in a
separate class so that another validation backend like one based on this
project can be used instead of reading the seeds from a SQLite file like
I’m doing now.

I did not see any kind of cool down in
https://code.ungleich.ch/ungleich-public/ungleich-otp/blob/master/otpauth/serializer.py.
Are you not worried that someone
could try to brute-force the OTP validation?

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

Thanks :)

> Best,
>
> Nico
>
> [0] https://code.ungleich.ch/ungleich-public/ungleich-otp
>
> Rémi Lapeyre 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 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
2019-09-13 13:17   ` Rémi Lapeyre [this message]
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:
  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=CAFsReqTThNXkkPH+_YHOhC_DEbKwY5rPdmRDVJxLiTQbhfAbDA@mail.gmail.com \
    --to=remi.lapeyre@lenstra.fr \
    --cc=nico.schottelius@ungleich.ch \
    --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

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 \
		wireguard@lists.zx2c4.com zx2c4-wireguard@archiver.kernel.org
	public-inbox-index wireguard

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.zx2c4.lists.wireguard


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