[strongSwan] Support of PFS for IKE SA

[Arun Makkar]

Dear Team,



This is Arun Makkar from Aricent. We are using strongswan stack v4.2.8 for
IpSec feature develop in our BTS SW.

Please find below the snippet of the IpSecConf file that we have generated
in our SW.



config setup

                cachecrls=no

                charonstart=yes

                plutostart=no

                strictcrlpolicy=no

                uniqueids=keep



ca section1

                cacert=/tmp/RootCert10ee04_7c120b3e.pem

                auto=add



conn IpSecSA_1

                ikelifetime=86400s

                keyexchange=ikev2

                keyingtries=%forever

                keylife=86400s

                *pfs=yes*

                reauth=no

                rekey=yes

                mobike=no

                dpdaction=clear

                dpddelay=10

                rekeymargin=4320s

                ike=aes128-sha1-modp1024,3des-sha1-modp1024!

                esp=3des-sha1-modp1024,aes128-sha1-modp1024!

                authby=rsasig

                left=7.7.7.7

                leftsubnet=172.18.21.25/32

                right=10.10.10.2

                rightsubnet=10.3.4.38/32

                leftprotoport=sctp/49152

                rightprotoport=sctp/49152

                leftid=192.168.255.230

                leftcert=/tmp/BTScert_16bbc8.pem

                rightid=%any

                auto=add



Ø  I have a query regarding the support of "pfs" flag for IKE SAs. Do we
use the status "pfs" flag (whether it is "yes" or "no") for achieving
perfect forward secrecy during re-keying of an IKE SA? Or are there any
other mechanism supported by strongswan stack for achieving  perfect
forward secrecy during re-keying of an IKE SA? Otherwise my query can be
stated in this way how we can achieve perfect forward secrecy during re-key
of an IKE SA?


ReRegards

ArArun Makkar

Ar


A

S

S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20140311/7b9f7c49/attachment.html>