WireGuard Archive on lore.kernel.org
 help / color / Atom feed
From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <ml@bartschnet.de>
To: wireguard@lists.zx2c4.com
Subject: Re: Adding 2FA to WireGuard
Date: Sun, 15 Sep 2019 18:46:37 +0200
Message-ID: <1de15e68-20b1-0b36-f3f1-d1182764306a@bartschnet.de> (raw)
In-Reply-To: <CAFsReqSUQYthBTr4o7HQQGdNUgzA33i9hAoJ_UieNUzJbB=hLA@mail.gmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 3974 bytes --]

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
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard

[-- Attachment #1.2: Type: text/html, Size: 7983 bytes --]

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi Rèmi,<br>
    <br>
    I suggested to use use FIDO2/CTAP2 hardware tokens about a week ago.<br>
    For in-band signaling I suggest to use OrchidV2 addresses derived
    from the public key
    (<a class="moz-txt-link-freetext" href="https://www.rfc-editor.org/rfc/pdfrfc/rfc7343.txt.pdf">https://www.rfc-editor.org/rfc/pdfrfc/rfc7343.txt.pdf</a>).<br>
    That way any peer can calculate the addresses of the other peers
    from their public keys without the need of a lookup table.<br>
    <br>
    Regards,<br>
    Renne<br>
    <p><br>
    </p>
    <div class="moz-cite-prefix">Am 12.09.19 um 23:01 schrieb Rémi
      Lapeyre:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAFsReqSUQYthBTr4o7HQQGdNUgzA33i9hAoJ_UieNUzJbB=hLA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <style>body{font-family:Helvetica,Arial;font-size:13px}</style>
      <div style="font-family:Helvetica,Arial;font-size:13px">
        <div style="margin:0px">Hi everybody! We are using WireeGuard on
          Mac and Linux which works great but for </div>
        <div style="margin:0px">compliance purpose, we would like to be
          able to add an OTP challenge on connection.</div>
        <div style="margin:0px"><br>
        </div>
        <div style="margin:0px">I've been looking at the archive of the
          mailing list and at the various projects</div>
        <div style="margin:0px">built around WireGuard and started
          writing an implementation based on the idea</div>
        <div style="margin:0px">from <a
href="https://lists.zx2c4.com/pipermail/wireguard/2017-September/001741.html"
            moz-do-not-send="true">https://lists.zx2c4.com/pipermail/wireguard/2017-September/001741.html</a>:</div>
        <div style="margin:0px"><br>
        </div>
        <div style="margin:0px">&gt; Alternatively, you could do OTP
          in-band, in order to authorize that</div>
        <div style="margin:0px">&gt; public key for a certain window of
          time before inactivity. In this</div>
        <div style="margin:0px">&gt; scheme, you'd disallow access to
          the network segment based on firewall</div>
        <div style="margin:0px">&gt; rules until a certain in-band
          challenge is made -- perhaps by</div>
        <div style="margin:0px">&gt; contacting a certain sandboxed
          server and answering an OTP challenge</div>
        <div style="margin:0px">&gt; there</div>
        <div style="margin:0px"><br>
        </div>
        <div style="margin:0px">My current implementation (I plan to
          publish it under MIT license once it's </div>
        <div style="margin:0px">ready) has a Python server on the
          WireGuard server bound to the wg interface</div>
        <div style="margin:0px">that add an IPTable rule to allow the
          traffic for a given amount of time when</div>
        <div style="margin:0px">a TOTP is received over TCP. Here are
          some details</div>
        <div style="margin:0px"><br>
        </div>
        <div style="margin:0px">  - The TOTP is bound to the internal
          tunnel IP address so the IP address that</div>
        <div style="margin:0px">  opens the TCP connection is used to
          identify the user, as thee packet must </div>
        <div style="margin:0px">  have been decrypted, it seems to me
          that there is no way to spoof this.</div>
        <div style="margin:0px"><br>
        </div>
        <div style="margin:0px">  - A small text protocol let the user
          log-in, log-out and read the status of the </div>
        <div style="margin:0px">  connection.</div>
        <div style="margin:0px"><br>
        </div>
        <div style="margin:0px">The client needs to send the TOTP just
          after connecting to the server, for which</div>
        <div style="margin:0px">I had hoped to use the "PostUp" field of
          wg-quick.</div>
        <div style="margin:0px"><br>
        </div>
        <div style="margin:0px">{Post,Pre}-{Up,Down} seems to be only
          available on wg-quick for now but we are</div>
        <div style="margin:0px">using the wireguard-apple client so I
          have a few questions:</div>
        <div style="margin:0px"><br>
        </div>
        <div style="margin:0px">  1. Is the absence of support
          {Post,Pre}-{Up,Down} in wireguard-apple on</div>
        <div style="margin:0px">  purpose or would a patch to add this
          welcomed?</div>
        <div style="margin:0px"><br>
        </div>
        <div style="margin:0px">  2. Is this way to do the OTP
          authentication sound?</div>
        <div style="margin:0px"><br>
        </div>
        <div style="margin:0px">  3. I've seen that TunSafe has added an
          extension to the WireGuard protocol so</div>
        <div style="margin:0px">  the TOTP auth would not be shared by
          an attacker that succeded to connect when</div>
        <div style="margin:0px">  the user is already connected. This
          seems like a good idea to do, what are your </div>
        <div style="margin:0px">  thougts about this? Would you
          recommend against my "easier" implementation?</div>
        <div style="margin:0px"><br>
        </div>
        <div style="margin:0px">  4. I know that TunSafe was strongly
          advised against when it was closed-source.</div>
        <div style="margin:0px">  Now that it is AGPL code, is it still
          the case?</div>
        <div style="margin:0px"><br>
        </div>
        <div style="margin:0px">One more thing, to simplify the
          deployment of WireGuard, I would like to propose</div>
        <div style="margin:0px">a change in the way the MacOS client
          import WireGuard configurations from a file.</div>
        <div style="margin:0px"><br>
        </div>
        <div style="margin:0px">Our current flow is "Please open the
          WireGuard app, click on create Tunnel, give </div>
        <div style="margin:0px">it a name, paste this configuration
          underneath what's already written, hit save</div>
        <div style="margin:0px">and send us your public key". It gives a
          lot of oportunity to the user to</div>
        <div style="margin:0px">mistype something and make changing the
          configuration cumbersome ("Edit the </div>
        <div style="margin:0px">tunnel, don't touch the `[Interface]`
          part but replace what's underneath by </div>
        <div style="margin:0px">this") so I would like to be able to
          send to the user a configuration file with</div>
        <div style="margin:0px">the PrivateKey missing and have the
          WireGuard client generate one on the fly but</div>
        <div style="margin:0px">this currently gives an error
          "Interface’s private key is required". Would</div>
        <div style="margin:0px">sending a patch for this be welcomed
          too?</div>
        <div style="margin:0px"><br>
        </div>
        <div style="margin:0px"><br>
        </div>
        <div style="margin:0px">Thanks for taking the time to help me, I
          look forward to contribute to WireGuard :)</div>
        <div style="margin:0px"><br>
        </div>
        <div style="margin:0px">Rémi</div>
        <div><br>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
WireGuard mailing list
<a class="moz-txt-link-abbreviated" href="mailto:WireGuard@lists.zx2c4.com">WireGuard@lists.zx2c4.com</a>
<a class="moz-txt-link-freetext" href="https://lists.zx2c4.com/mailman/listinfo/wireguard">https://lists.zx2c4.com/mailman/listinfo/wireguard</a>
</pre>
    </blockquote>
  </body>
</html>

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

      parent 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
2019-09-13 13:22     ` Nico Schottelius
2019-09-15 16:46 ` Rene 'Renne' Bartsch, B.Sc. Informatics [this message]

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=1de15e68-20b1-0b36-f3f1-d1182764306a@bartschnet.de \
    --to=ml@bartschnet.de \
    --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
	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.git