WireGuard Archive on lore.kernel.org
 help / color / Atom feed
* Adding 2FA to WireGuard
@ 2019-09-12 21:01 Rémi Lapeyre
  2019-09-13 12:49 ` Nico Schottelius
  2019-09-15 16:46 ` Rene 'Renne' Bartsch, B.Sc. Informatics
  0 siblings, 2 replies; 5+ messages in thread
From: Rémi Lapeyre @ 2019-09-12 21:01 UTC (permalink / raw)
  To: wireguard

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

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

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

<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body><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&#39;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">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&#39;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&#39;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 &quot;PostUp&quot; 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&#39;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 &quot;easier&quot; 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 &quot;Please open the WireGuard app, click on create Tunnel, give </div><div style="margin:0px">it a name, paste this configuration underneath what&#39;s already written, hit save</div><div style="margin:0px">and send us your public key&quot;. It gives a lot of oportunity to the user to</div><div style="margin:0px">mistype something and make changing the configuration cumbersome (&quot;Edit the </div><div style="margin:0px">tunnel, don&#39;t touch the `[Interface]` part but replace what&#39;s underneath by </div><div style="margin:0px">this&quot;) 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 &quot;Interface’s private key is required&quot;. 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></body></html>

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

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Adding 2FA to WireGuard
  2019-09-12 21:01 Adding 2FA to WireGuard Rémi Lapeyre
@ 2019-09-13 12:49 ` Nico Schottelius
  2019-09-13 13:17   ` Rémi Lapeyre
  2019-09-15 16:46 ` Rene 'Renne' Bartsch, B.Sc. Informatics
  1 sibling, 1 reply; 5+ messages in thread
From: Nico Schottelius @ 2019-09-13 12:49 UTC (permalink / raw)
  To: Rémi Lapeyre; +Cc: wireguard


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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Adding 2FA to WireGuard
  2019-09-13 12:49 ` Nico Schottelius
@ 2019-09-13 13:17   ` Rémi Lapeyre
  2019-09-13 13:22     ` Nico Schottelius
  0 siblings, 1 reply; 5+ messages in thread
From: Rémi Lapeyre @ 2019-09-13 13:17 UTC (permalink / raw)
  To: Nico Schottelius; +Cc: wireguard

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Adding 2FA to WireGuard
  2019-09-13 13:17   ` Rémi Lapeyre
@ 2019-09-13 13:22     ` Nico Schottelius
  0 siblings, 0 replies; 5+ messages in thread
From: Nico Schottelius @ 2019-09-13 13:22 UTC (permalink / raw)
  To: Rémi Lapeyre; +Cc: wireguard


Hey Rémi,

Rémi Lapeyre <remi.lapeyre@lenstra.fr> writes:
> Hi Nico, yes pyotp is the implementation I use on the server, but anything
> Compatible withrfc6238 should work.

That sounds about right!

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

That is a good point! We will certainly want to fix that, as the seed
entropy is not *that* big.

Best regards,

Nico


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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Adding 2FA to WireGuard
  2019-09-12 21:01 Adding 2FA to WireGuard Rémi Lapeyre
  2019-09-13 12:49 ` Nico Schottelius
@ 2019-09-15 16:46 ` Rene 'Renne' Bartsch, B.Sc. Informatics
  1 sibling, 0 replies; 5+ messages in thread
From: Rene 'Renne' Bartsch, B.Sc. Informatics @ 2019-09-15 16:46 UTC (permalink / raw)
  To: wireguard

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-12 21:01 Adding 2FA to WireGuard 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

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