Re: [Ipsec-tools-devel] New Debian Maintainer

[Milan P. Stanic <mps@ar...>]

Hi Mathew,

On Wed, 2011-09-28 at 10:38, Matthew Grant wrote:
> Hi!
> 
> I am the new Debian Maintainer for ipsec-tools:
> 
> http://packages.debian.org/sid/ipsec-tools
> 
> Could you please tell me how to run the autoconf configure generation
> process.  There are changes required to be upstreamed for Debian
> GNU/kfreebsd.

./bootstrap
 
> There is also a racoon-tool perl management script that I am building up
> again that should make racoon/setkey use a bit easier for the uninitiated
> once it is more fulled featured.
> 
> http://github.com/grantma/racoon-tool
> 
> Have not yet created project web page up there, but will get around to it.
> 
> Also, looking at helping update FreeBSD ipsec-tools port to 0.8.0 once the
> Debian stuff is building and working fine.
> 
> We use ipsec-tools at work for a encrypting a network of DNS servers.
> 
> Thank you very much for all your help.

I'm not Debian developer but I'm using ipsec-tools for years on Debian
servers.

Sometimes I build Debian packages from source (usually with some
patches) for specific usage and becasue that I have some experience
with it.

Your question about autoconf tells me that you do not have a lot of
experience with autotools (I do not want to offend you, I'm also far
from expert status) and because that I'm ready to help you with
packaging it for Debian if you accept me, of course.

I'm also Perl programmer, so maybe I can help with racoon-tool.

-- 
Kind regards,  Milan
--------------------------------------------------
Arvanta, IT Security        http://www.arvanta.net
Please do not send me e-mail containing HTML code.

Re: [Ipsec-tools-devel] New Debian Maintainer

[Rainer Weikusat <rweikusat@mo...>]

Matthew Grant <matthewgrant5@...> writes:
> I am the new Debian Maintainer for ipsec-tools:
>
> http://packages.debian.org/sid/ipsec-tools
>
> Could you please tell me how to run the autoconf configure generation
> process.  There are changes required to be upstreamed for Debian
> GNU/kfreebsd.

Try running the bootstrap script in the top-level directory.

[Ipsec-tools-devel] New Debian Maintainer

[Matthew Grant <matthewgrant5@gm...>]

Hi!

I am the new Debian Maintainer for ipsec-tools:

http://packages.debian.org/sid/ipsec-tools

Could you please tell me how to run the autoconf configure generation
process.  There are changes required to be upstreamed for Debian
GNU/kfreebsd.

There is also a racoon-tool perl management script that I am building up
again that should make racoon/setkey use a bit easier for the uninitiated
once it is more fulled featured.

http://github.com/grantma/racoon-tool

Have not yet created project web page up there, but will get around to it.

Also, looking at helping update FreeBSD ipsec-tools port to 0.8.0 once the
Debian stuff is building and working fine.

We use ipsec-tools at work for a encrypting a network of DNS servers.

Thank you very much for all your help.

Best Regards,

Matthew Grant

Debian Developer

Re: [Ipsec-tools-devel] [IPsec] New method to resist replay attack in ikev2

[ramaswamy <ramaswamy.bm@gl...>]

Please see my comments inline.

Best Regards ,
Ram

-----Original Message-----
From: ipsec-bounces@... [mailto:ipsec-bounces@...] On Behalf Of
Tero Kivinen
Sent: Tuesday, September 20, 2011 6:16 AM
To: ramaswamy
Cc: ipsec@...; ipsec-tools-devel@...;
ipsec-tools-users@...; ikev2-devel@...
Subject: Re: [IPsec] New method to resist replay attack in ikev2

ramaswamy writes:
> Thanks for the response, I agree with your comments, I think we can 
> use certificates to avoid man in the middle attacks and error message 
> flooding in the INIT phase only, as certificates are signed by trusted 
> certificate authorities authenticity is ensured.
> 
> If certificates are used in INIT message exchanges [mutual 
> authentication], we can effectively avoid afore said attacks as it 
> avoids huge computation of IKE-keys before the client OR server is
authenticated.

RSA operations are already huge computation. There is no big difference
whether you do RSA or Diffie-Hellman.

>>>>>>>>>>> [Ram] I agree with you, but we have certificate verification
done at AUTH phase, our suggestion is the same can be moved to initial phase
of ikev2 exchanges and this will ensure authenticity before IKEv2-KEYS[seven
keys] are generated.
As IKE users are already authenticated there is no need of CERT message
exchanges in AUTH phase and also which in turn will help to avoid man in the
middle attacks and error message flooding at IKEv2-INIT level only.
And also it will avoid unnecessary computation of ikev2-keys[seven keys:
which involves huge computation] at server end  due to INIT-REQESTS sent by
attackers. 
>>>>>>>>>>>>>>>>>>>>>>>>>>>

> To avoid Replay attacks:
> By using RSA private key of certificate to encrypt the nonce (Ni) in 
> INIT_REQUEST message we can avoid replay attacks, at the receiving 
> end, first certificate is verified using root CA and nonce is 
> decrypted using public key of the received certificate which ensures 
> that sender holds the valid private key of the certificate and not an 
> attacker.  By using nonce we can avoid Replay attacks[Packets can be 
> rejected if the same nonce is received within a particular session].

So you plan to store that nonce forever, and always verify that the nonce is
not used before? That would be extremely expensive way to
solve the replay attack.	

>>>>>>>>>>> [Ram] I agree that storing nonce forever is not an best solution
to solve replay attacks, but our suggestion is to store the nonce from
particular client for particular session [time limit Eg: 2 minutes]. If it
receives same nonce with in the permissible time limit it should rejected.
If it more than permissible limit server will throw an error SKEW_ERROR,
handling of which is explained below.

To do it more effectively Ikev2 client should be clock synchronized with
server by negotiating client time by using encrypted nonce(Ni) --> timestamp
[Ni is encrypted by RSA private key of certificate of ikev2 client
certificate]  in INIT-REQUEST it self, and server can check the received
time [encrypted nonce(Ni):timestamp] and if it is more than permissible time
limit say Eg: 2 minutes it can throw an clock skew error[SKEW_ERROR], by
putting its server time using  encrypted server nonce (Nr) using RSA private
key of certificate of ikev2 server certificate.

Upon receipt of skew error ikev2 client must compute the difference (in
seconds) between the two clocks based upon the client and server time
contained in the SKEW_ERROR message. The client should store this clock
difference in non-volatile memory and must use it to adjust ikev2 client
timestamps[Ni] in subsequent INIT-REQ request messages by adding the clock
skew to its local clock value each time.
If the encrypted nonce differs from server time by permissible limit it can
reject the INIT-REQ and avoid replay attacks. 
>>>>>>>>>>>>>>>>>> 


--
kivinen@...
_______________________________________________
IPsec mailing list
IPsec@...
https://www.ietf.org/mailman/listinfo/ipsec

[Ipsec-tools-devel] Why no interface aware rules in ipsec-tools?

[c0re <nr1c0re@gm...>]

Hello!

Can't understand, why ipsec-tools did not work with interfaces.

Imagine this network:

1.1.1.0/24-------------------------\
8.0.0.0/24-------------------------  \
192.168.0.0/16-----------------    \
172.16.0.0/24-------------------     \   -----
1.1.1.0/24----[.1___router1___.1]----2.2.2.0/30----[2___router2___.1]----3.3.3.0/24-----other_networks_and_internet
10.10.0.0/16---------------------     /
10.3.0.0/20-----------------------   /
......---------------------------------- /
totaly about 30 networks-----/
all networks are stub


2.2.2.0/30 - leased line, but I must encrypt all traffic between router1 and
router2.

I'ts easy when all stub networks talk with remote networks, that's rules to
encrypt on router1:

spdadd 1.1.1.0/24 0.0.0.0/0 any -P out ipsec
esp/tunnel/2.2.2.1-2.2.2.2/require;
spdadd 0.0.0.0/0 1.1.1.0/24 any -P in ipsec
esp/tunnel//2.2.2.2-2.2.2.1/require;
and other 29 networks - total 60 rules.


But those networks can't communicate with each others networks via router1.
To resolve this I have to make rules like this:

spdadd 1.1.1.0/24 8.0.0.0/24 any -P in none;
spdadd 1.1.1.0/24 8.0.0.0/24 any -P out none;
spdadd 8.0.0.0/24 1.1.1.0/24 any -P in none;
spdadd 8.0.0.0/24 1.1.1.0/24 any -P out none;

this rules must be first rules.


That's 4 additional rules for 2 networks.

for 30 networks it's 2*(29+28+27...+2)=868 rules total

That's pretty dirty...

It can be much better if spdadd rules can handle interface.

like router1 interface eth0 with 2.2.2.1

spdadd 1.1.1.0/24 0.0.0.0/0 any -P out via eth0 ipsec
esp/tunnel/2.2.2.1-2.2.2.2/require;
spdadd 0.0.0.0/0 1.1.1.0/24 any -P in via eth0 ipsec
esp/tunnel//2.2.2.2-2.2.2.1/require;

So I do not need to make "-P in none" policies.

I know that I can make it much better making gre tunnel between router1 and
router2 and in policy just make 2 rules:

spdadd 2.2.2.1 2.2.2.2 any -P out ipsec esp/transport//require;
spdadd 2.2.2.2 2.2.2.1 any -P in ipsec esp/transport///require;

And make routing work to move packets via gre tunnel.
Yeah, it's better.
But in cisco it's not required, I just configure cryptomap on interface, so
others interfaces just excluded from ipsec policy checks.

What you think about it?

Re: [Ipsec-tools-devel] [IPsec] New method to resist replay attack in ikev2

[ramaswamy <ramaswamy.bm@gl...>]

Please see my comments inline.

Best Regards ,
Ram

-----Original Message-----
From: ipsec-bounces@... [mailto:ipsec-bounces@...] On Behalf Of
Tero Kivinen
Sent: Tuesday, September 20, 2011 6:16 AM
To: ramaswamy
Cc: ipsec@...; ipsec-tools-devel@...;
ipsec-tools-users@...; ikev2-devel@...
Subject: Re: [IPsec] New method to resist replay attack in ikev2

ramaswamy writes:
> Thanks for the response, I agree with your comments, I think we can use
> certificates to avoid man in the middle attacks and error message flooding
> in the INIT phase only, as certificates are signed by trusted certificate
> authorities authenticity is ensured.
> 
> If certificates are used in INIT message exchanges [mutual
authentication],
> we can effectively avoid afore said attacks as it avoids huge computation
of
> IKE-keys before the client OR server is authenticated.

RSA operations are already huge computation. There is no big
difference whether you do RSA or Diffie-Hellman.

>>>>>>>>>>> [Ram] I agree with you, but we have certificate verification
done at AUTH phase, our suggestion is the same can be moved to initial phase
of ikev2 exchanges and this will ensure authenticity before IKEv2-KEYS[seven
keys] are generated.
As IKE users are already authenticated there is no need of CERT message
exchanges in AUTH phase and also which in turn will help to avoid man in the
middle attacks and error message flooding at IKEv2-INIT level only.
And also it will avoid unnecessary computation of ikev2-keys[seven keys:
which involves huge computation] at server end  due to INIT-REQESTS sent by
attackers. 
>>>>>>>>>>>>>>>>>>>>>>>>>>>

> To avoid Replay attacks:
> By using RSA private key of certificate to encrypt the nonce (Ni) in
> INIT_REQUEST message we can avoid replay attacks, at the receiving end,
> first certificate is verified using root CA and nonce is decrypted using
> public key of the received certificate which ensures that sender holds the
> valid private key of the certificate and not an attacker.  By using nonce
we
> can avoid Replay attacks[Packets can be rejected if the same nonce is
> received within a particular session].

So you plan to store that nonce forever, and always verify that the
nonce is not used before? That would be extremely expensive way to
solve the replay attack.	

>>>>>>>>>>> [Ram] I agree that storing nonce forever is not an best solution
to solve replay attacks, but our suggestion is to store the nonce from
particular client for particular session [time limit Eg: 2 minutes]. If it
receives same nonce with in the permissible time limit it should rejected.
If it more than permissible limit server will throw an error SKEW_ERROR,
handling of which is explained below.

To do it more effectively Ikev2 client should be clock synchronized with
server by negotiating client time by using encrypted nonce(Ni) --> timestamp
[Ni is encrypted by RSA private key of certificate of ikev2 client
certificate]  in INIT-REQUEST it self, and server can check the received
time [encrypted nonce(Ni):timestamp] and if it is more than permissible time
limit say Eg: 2 minutes it can throw an clock skew error[SKEW_ERROR], by
putting its server time using  encrypted server nonce (Nr) using RSA private
key of certificate of ikev2 server certificate.

Upon receipt of skew error ikev2 client must compute the difference (in
seconds) between the
two clocks based upon the client and server time contained in the SKEW_ERROR
message. The client should store this clock difference in non-volatile
memory and must use it to adjust ikev2 client timestamps[Ni] in subsequent
INIT-REQ request messages by adding the clock skew to its local clock value
each time.
If the encrypted nonce differs from server time by permissible limit it can
reject the INIT-REQ and avoid replay attacks. 
>>>>>>>>>>>>>>>>>> 


-- 
kivinen@...
_______________________________________________
IPsec mailing list
IPsec@...
https://www.ietf.org/mailman/listinfo/ipsec

Re: [Ipsec-tools-devel] [IPsec] New method to resist replay attack in ikev2

[Tero Kivinen <kivinen@ik...>]

ramaswamy writes:
> Thanks for the response, I agree with your comments, I think we can use
> certificates to avoid man in the middle attacks and error message flooding
> in the INIT phase only, as certificates are signed by trusted certificate
> authorities authenticity is ensured.
> 
> If certificates are used in INIT message exchanges [mutual authentication],
> we can effectively avoid afore said attacks as it avoids huge computation of
> IKE-keys before the client OR server is authenticated.

RSA operations are already huge computation. There is no big
difference whether you do RSA or Diffie-Hellman.

> To avoid Replay attacks:
> By using RSA private key of certificate to encrypt the nonce (Ni) in
> INIT_REQUEST message we can avoid replay attacks, at the receiving end,
> first certificate is verified using root CA and nonce is decrypted using
> public key of the received certificate which ensures that sender holds the
> valid private key of the certificate and not an attacker.  By using nonce we
> can avoid Replay attacks[Packets can be rejected if the same nonce is
> received within a particular session].

So you plan to store that nonce forever, and always verify that the
nonce is not used before? That would be extremely expensive way to
solve the replay attack.
-- 
kivinen@...

Re: [Ipsec-tools-devel] [IPsec] New method to resist replay attack in ikev2

[ramaswamy <ramaswamy.bm@gl...>]

Thanks for the response, I agree with your comments, I think we can use
certificates to avoid man in the middle attacks and error message flooding
in the INIT phase only, as certificates are signed by trusted certificate
authorities authenticity is ensured.

If certificates are used in INIT message exchanges [mutual authentication],
we can effectively avoid afore said attacks as it avoids huge computation of
IKE-keys before the client OR server is authenticated.

To avoid Replay attacks:
By using RSA private key of certificate to encrypt the nonce (Ni) in
INIT_REQUEST message we can avoid replay attacks, at the receiving end,
first certificate is verified using root CA and nonce is decrypted using
public key of the received certificate which ensures that sender holds the
valid private key of the certificate and not an attacker.  By using nonce we
can avoid Replay attacks[Packets can be rejected if the same nonce is
received within a particular session].

Please assert and also let us know if any related drafts/rfc to avoid these
attacks.

Best Regards ,
Ram

-----Original Message-----
From: Tero Kivinen [mailto:kivinen@...] 
Sent: Tuesday, August 30, 2011 2:41 PM
To: ramaswamy
Cc: ipsec@...; ipsec-tools-devel@...;
ipsec-tools-users@...; ikev2-devel@...
Subject: [IPsec] New method to resist replay attack in ikev2

ramaswamy writes:
> Proposed new negotiations 
> 
> Before initial exchange begins initiator looks up to the pre shared
> secret with the intended responder and does the hash value on first
> half of pre shared secret, nonce of the initiator. Once the
> responder receives the request it looks up the correspondence pre
> shared key in its table and it takes the nonce form initiator
> request message then it does a hash value to authenticate the
> initiator.

This is bit like how IKEv1 did it, and it has same problem than IKEv1
had with that, meaning it does not provide ANY identity protection at
all. 

The responder needs to find the pre-shared key for the initiator based
only with the information that are in the first IKE_SA_INIT packet.
This DOES NOT include identity of the initiator, and SAi1, KEi, and Ni
does not help at all in this process. The only information that
responder has which it can use is the source IP-address of the
IKE_SA_INIT packet.

This has the effect that the pre-shared key will be tied to the source
IP-address of the initiator, which mean every passive listener will
also see that same IP-address and will know the identity of the
initiator.

The method in IKEv2 where the PSK is not tied to the IP-address of the
initiator offers much better identity protection, as now the responder
identity is only releaved to the active attacker.
-- 
kivinen@...

Re: [Ipsec-tools-devel] How to implement policy "from any to 192.168.0.0/16"?

[c0re <nr1c0re@gm...>]

Experimentally I found solution.

Topology:

1.1.1.0/24 ---- [.1___R1___.12 ] ----
172.20.0.0/24----[.2___R2___.2]----2.2.2.0/24(and other networks)

1.1.1.0/24 - stub network.
______________________________________

So at R1 configuration (I used ubuntu server):
ipsec-tools.conf:

# we do not want to encrypt traffic between R1 and it's stub network.
spdadd 1.1.1.0/24 1.1.1.0/24 any -P in none;
spdadd 1.1.1.0/24 1.1.1.0/24 any -P out none;
# securing 1.1.1.0/24 stub network
spdadd 0.0.0.0/0 1.1.1.0/24 any -P in ipsec
esp/tunnel/172.20.0.2-172.20.0.12/require;
spdadd 1.1.1.0/24 0.0.0.0/0 any -P out ipsec
esp/tunnel/172.20.0.12-172.20.0.2/require;

racoon.conf:

listen {
    isakmp 172.20.0.12 [500];
}

remote 172.20.0.2 {
    exchange_mode main;
    lifetime time 1 hour;
    proposal {
        encryption_algorithm rijndael 128;
        hash_algorithm sha1;
        authentication_method pre_shared_key;
        dh_group 2;
    }
}

sainfo subnet 1.1.1.0/24 any subnet 0.0.0.0/0 any {
    pfs_group 2;
    encryption_algorithm rijndael 128;
    authentication_algorithm non_auth;
    compression_algorithm deflate;
    lifetime time 1 hour;
}

And R2 configuration:
ipsec-tools.con

spdadd 0.0.0.0/0 1.1.1.0/24 any -P out ipsec
esp/tunnel/172.20.0.2-172.20.0.12/require;
spdadd 1.1.1.0/24 0.0.0.0/0 any -P in ipsec
esp/tunnel/172.20.0.12-172.20.0.2/require;

listen {
    isakmp 172.20.0.2 [500];
}

remote 172.20.0.12 {
    exchange_mode main;
    lifetime time 1 hour;
    proposal {
        encryption_algorithm rijndael 128;
        hash_algorithm sha1;
        authentication_method pre_shared_key;
        dh_group 2;
    }
}

sainfo subnet 0.0.0.0/0 any subnet 1.1.1.0/24 any {
    pfs_group 2;
    encryption_algorithm rijndael 128;
    authentication_algorithm non_auth;
    compression_algorithm deflate;
    lifetime time 1 hour;
}
___________________________

And it works.

2011/9/19 c0re <nr1c0re@...>

> Hello ipsec users and developers!
>
> In cisco I can configure cryptomap with access-list like this
> permit ip 192.168.0.0 0.0.255.255 any
>
> That means that I encrypt all traffic going to/from 192.168.0.0/16network.
>
> But I can't find how to do it with setkey and racoon.
>
> Give me please an example.
>
> Thanks!
>

[Ipsec-tools-devel] How to implement policy "from any to 192.168.0.0/16"?

[c0re <nr1c0re@gm...>]

Hello ipsec users and developers!

In cisco I can configure cryptomap with access-list like this
permit ip 192.168.0.0 0.0.255.255 any

That means that I encrypt all traffic going to/from 192.168.0.0/16 network.

But I can't find how to do it with setkey and racoon.

Give me please an example.

Thanks!

Re: [Ipsec-tools-devel] IPSec version compatibility

[VANHULLEBUS Yvan <vanhu@fr...>]

On Mon, Aug 15, 2011 at 12:47:59AM +0300, Andrew wrote:
>   Dear Sirs,

Hi,and sorry for the late reply.


>    I have been using IPSec 0.6.5 rpm coming with Fedora Core6 to
>   build a VPN tunnel between 2 machines, automatic key exchange with
>   racoon was configured, everything was OK for 2 years.
>   I updated one of the machines to Fedora 14 coming with IPSec 0.7.3
>   and the tunnel broke. Tried to get it running without racoon by
>   configuring manual keys (the same manual key exchange
>   configuration is working between FC6 ? FC6), still no
>   success. Ping request is passing through the tunnel both ways with
>   encryption, no response from the recepient as if he is deaf.

So looks this is not an IKE issue, but an IPsec stack issue.
The best would then be to ask to linux kernel people, to see if there
have been some changes between FC6's kernel and FC14's kernel...


>    I read that RFC 1825-1829 conventions have been updated for ESP
> to RFC2401-2414, no field is present in the packet with info about
> the current version used by the sender. Could it be that there is
> incompatibility between the different versions of IPSec, namely
> 0.6.5 and 0.7.3? Is the newest version 0.8 of IPSec compatible with
> 0.7.3 and is it possible to use different IPSec versions at both
> ends of a tunnel?

Again, that's a kernel issue, ipsec-tools has almost nothing to do
with that, sorry.


Yvan.