IPsec: Default to rekey=no

IPsec: Default to rekey=no

[Larsen]

[-- Attachment #1: Type: text/plain, Size: 653 bytes --]

Hi,

we noticed interruptions with our IPsec roadwarrriors. The problem turned  
out to be caused by the server trying to rekey with the client that is  
sitting behind a NAT (Windows 7 client at colleague's home). See  
https://wiki.strongswan.org/projects/strongswan/wiki/Windows7#Rekeying-behavior

This was solved by adding "rekey=no" to "/etc/ipsec.user.conf" for each  
connection.
I wonder if this should be added by IPFire by default as I guess that all  
roadwarriors behind a NAT (probably the majority) might have this problem.

So, adding
     print CONF "\trekey=no\n";
to
     /srv/web/ipfire/cgi-bin/vpnmain.cgi


Lars

Re: IPsec: Default to rekey=no

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1632 bytes --]

Hi,

obviously we cannot make this as a default option for anything. The
rekeying is a very important process in the security of a VPN. Without
that brute-force attacks are getting much more feasible and if they
succeed all the data that has been transferred in this session can be
decrypted afterwards.

The link that you provided does at no point say that disabling rekeying
is a recommended strategy to do that. It just points out some issues and
incompatibilities with the Windows client.

I CCed Wolfgang Apolinarski who recently worked on this whole matter. He
seems to use the rekey=no option, too. Maybe he can contribute some
insight why this is needed from his point of view.

Best,
-Michael

On Tue, 2015-05-19 at 17:19 +0200, Larsen wrote:
> Hi,
> 
> we noticed interruptions with our IPsec roadwarrriors. The problem turned  
> out to be caused by the server trying to rekey with the client that is  
> sitting behind a NAT (Windows 7 client at colleague's home). See  
> https://wiki.strongswan.org/projects/strongswan/wiki/Windows7#Rekeying-behavior
> 
> This was solved by adding "rekey=no" to "/etc/ipsec.user.conf" for each  
> connection.
> I wonder if this should be added by IPFire by default as I guess that all  
> roadwarriors behind a NAT (probably the majority) might have this problem.
> 
> So, adding
>      print CONF "\trekey=no\n";
> to
>      /srv/web/ipfire/cgi-bin/vpnmain.cgi
> 
> 
> Lars
> _______________________________________________
> Development mailing list
> Development(a)lists.ipfire.org
> http://lists.ipfire.org/mailman/listinfo/development

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: IPsec: Default to rekey=no

[Larsen]

[-- Attachment #1: Type: text/plain, Size: 2315 bytes --]

If I understand it corretly, adding "rekey=no" only disables the server  
trying to rekey, so this is left to the client and should not be a  
security problem therefore.

If this is not added, clients behind a NAT will experience an interruption  
in their vpn connection. I think this depends on the lifetime of something  
(ikelifetime? keylifetime?). Anyhow, as long as the server tries to rekey,  
the connection will be disturbed.
In the end, the user might not use IPsec anymore because of that.


Lars



On Tue, 19 May 2015 17:45:52 +0200, Michael Tremer  
<michael.tremer(a)ipfire.org> wrote:

> Hi,
>
> obviously we cannot make this as a default option for anything. The
> rekeying is a very important process in the security of a VPN. Without
> that brute-force attacks are getting much more feasible and if they
> succeed all the data that has been transferred in this session can be
> decrypted afterwards.
>
> The link that you provided does at no point say that disabling rekeying
> is a recommended strategy to do that. It just points out some issues and
> incompatibilities with the Windows client.
>
> I CCed Wolfgang Apolinarski who recently worked on this whole matter. He
> seems to use the rekey=no option, too. Maybe he can contribute some
> insight why this is needed from his point of view.
>
> Best,
> -Michael
>
> On Tue, 2015-05-19 at 17:19 +0200, Larsen wrote:
>> Hi,
>>
>> we noticed interruptions with our IPsec roadwarrriors. The problem  
>> turned
>> out to be caused by the server trying to rekey with the client that is
>> sitting behind a NAT (Windows 7 client at colleague's home). See
>> https://wiki.strongswan.org/projects/strongswan/wiki/Windows7#Rekeying-behavior
>>
>> This was solved by adding "rekey=no" to "/etc/ipsec.user.conf" for each
>> connection.
>> I wonder if this should be added by IPFire by default as I guess that  
>> all
>> roadwarriors behind a NAT (probably the majority) might have this  
>> problem.
>>
>> So, adding
>>      print CONF "\trekey=no\n";
>> to
>>      /srv/web/ipfire/cgi-bin/vpnmain.cgi
>>
>>
>> Lars
>> _______________________________________________
>> Development mailing list
>> Development(a)lists.ipfire.org
>> http://lists.ipfire.org/mailman/listinfo/development

Re: IPsec: Default to rekey=no

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2784 bytes --]

On Tue, 2015-05-19 at 17:56 +0200, Larsen wrote:
> If I understand it corretly, adding "rekey=no" only disables the server  
> trying to rekey, so this is left to the client and should not be a  
> security problem therefore.

Yes, the client may still trigger creating a new child sa. I just
wouldn't trust the client to do that.

> If this is not added, clients behind a NAT will experience an interruption  
> in their vpn connection. I think this depends on the lifetime of something  
> (ikelifetime? keylifetime?). Anyhow, as long as the server tries to rekey,  
> the connection will be disturbed.
> In the end, the user might not use IPsec anymore because of that.

Of course the usability would be worse. But I am sure that security is
coming first.

IPsec has always had these woes. That is the main reason why those awful
SSL VPN solutions exist.

> Lars
> 
> 
> 
> On Tue, 19 May 2015 17:45:52 +0200, Michael Tremer  
> <michael.tremer(a)ipfire.org> wrote:
> 
> > Hi,
> >
> > obviously we cannot make this as a default option for anything. The
> > rekeying is a very important process in the security of a VPN. Without
> > that brute-force attacks are getting much more feasible and if they
> > succeed all the data that has been transferred in this session can be
> > decrypted afterwards.
> >
> > The link that you provided does at no point say that disabling rekeying
> > is a recommended strategy to do that. It just points out some issues and
> > incompatibilities with the Windows client.
> >
> > I CCed Wolfgang Apolinarski who recently worked on this whole matter. He
> > seems to use the rekey=no option, too. Maybe he can contribute some
> > insight why this is needed from his point of view.
> >
> > Best,
> > -Michael
> >
> > On Tue, 2015-05-19 at 17:19 +0200, Larsen wrote:
> >> Hi,
> >>
> >> we noticed interruptions with our IPsec roadwarrriors. The problem  
> >> turned
> >> out to be caused by the server trying to rekey with the client that is
> >> sitting behind a NAT (Windows 7 client at colleague's home). See
> >> https://wiki.strongswan.org/projects/strongswan/wiki/Windows7#Rekeying-behavior
> >>
> >> This was solved by adding "rekey=no" to "/etc/ipsec.user.conf" for each
> >> connection.
> >> I wonder if this should be added by IPFire by default as I guess that  
> >> all
> >> roadwarriors behind a NAT (probably the majority) might have this  
> >> problem.
> >>
> >> So, adding
> >>      print CONF "\trekey=no\n";
> >> to
> >>      /srv/web/ipfire/cgi-bin/vpnmain.cgi
> >>
> >>
> >> Lars
> >> _______________________________________________
> >> Development mailing list
> >> Development(a)lists.ipfire.org
> >> http://lists.ipfire.org/mailman/listinfo/development

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

IPsec: Default to rekey=no

[Wolfgang Apolinarski]

[-- Attachment #1: Type: text/plain, Size: 2331 bytes --]

Hi!

I first want to say that I do not like the standard configuration of ipsec in
ipfire, because I am mainly using Windows and Android clients (phone/PC) and
the standard configs just do not work with that. This is why I added some
configuration templates to the ipfire wiki (which are mostly taken from the
Strongswan docu with some added information specific to ipfire).

When rekey is set to no, the server does not initiate any rekey, which is
mandatory for Windows, because Windows does not like the server to take the
initiative. Windows clients are initiating the rekey every 58-59 minutes
(according to the strongswan docu, I did not check that in the logs).

There is (at least one) other alternatives than rekey=no:
Set the lifetime of the child SA to something like 90 minutes. Then Windows
clients initiate the rekey after 58-59 minutes and rekey can be set to yes.

One could also set rekey=no, but fix the lifetime of the CHILD_SA. The
CHILD_SA is then thrown away and the client needs to rekey (and apparently
does so). If I understand the strongswan docu [1] correctly, the default is
set to 1h (attention to the margin!) and should also be used when rekey=no. So
rekey=no is a safe setting, security wise (someone should test this behavior,
though).

If connecting two ipfire devices via ipsec is one of the user scenarios that
should be supported, a default setting of rekey=no might not make sense since
both ipfire devices would not rekey, i.e., the connection would be dropped. A
longer CHILD_SA lifetime could be an alternative.

What is on my whish list:
An option menu when creating a new ipsec vpn connection that offers specific
configurations (Windows 7 (X.509 Machine Auth), Windows Phone (X.509 User Auth
over EAP-TLS), Android (IKEV1, X.509, xauth)).
I did not add this, because of a) time and b) my weird configuration that uses
the ipfire DHCP and ends the tunnel directly in the green network (which -
from what I understood while reading the old documentation - is not the normal
configuration).

> On Tue, 19 May 2015 18:06:06 +0200, Michael Tremer
> <michael.tremer(a)ipfire.org> wrote:
(...)
> IPsec has always had these woes. That is the main reason why those awful
> SSL VPN solutions exist.

Yes! :-)

Cheers,
Wolfgang

[1] https://wiki.strongswan.org/projects/strongswan/wiki/ExpiryRekey

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6834 bytes --]