Simplify and centralize IPSec management on AIX

Internet Protocol Security (IPSec) helps you secure your data, but implementing IPSec tunnels in a large enterprise with many systems can be a daunting task. In this article, learn to use the centralized IPSec management feature in AIX® to manage IPSec configuration for large numbers of client machines. Examples show how to simplify and centralize management of a configuration using LDAP as a central repository.

Jyoti Tenginakai (jyoti.b.t@in.ibm.com), Software Engineer, IBM

Photo of Jyoti Tenginakai Jyoti Tenginakai works for IBM India as a senior staff software engineer. Jyoti has over nine years of experience in the software industry. At IBM, she initially worked on OpenSource components such as OpenSSH and LSOF. She is now part of AIX Security development and works on security components like Trusted Execution, EFS, AIXpert, and Ipsec. Jyoti completed her bachelor's degree in Electronics and Communications from Visweshwaraiah Technology University. She can be reached at jyoti.b.t@in.ibm.com.



15 July 2013

Also available in Chinese Russian

Overview

Internet Protocol Security is a protocol suite that provides various features for information security. Individual users or organizations use IPSec features to secure traffic for all applications without having to make any modifications to the applications themselves. IPSec protects data traffic using authentication, integrity checking, and encryption. Data security is provided at the IP layer of the communication stack, so applications do not require any modifications. However, each machine must be configured individually to be able to use IPSec.

In this article, learn about an AIX IPSec management feature that simplifies how you apply and manage an IPSec configuration for large networks. The feature provides centralized management of a configuration using the Lightweight Directory Access Protocol (LDAP) as a central repository to maintain and distribute IPSec configurations. This feature is supported from AIX version 61V/71H and up.

The need for IPSEC simplification

Currently, for systems to use IPSec tunnels they must be configured individually using an XML configuration file or command line. It might not be a huge effort when configuring a few systems, but in a large enterprise with many systems the configuration becomes a big task. There are over 20 configuration parameters that need to be configured to create an IPSec tunnel between two systems, and only a few of these are machine dependent.

With the large number of configuration parameters, IPSec configuration is error prone and time consuming. To reduce the effort and risk of misconfiguration, a new feature was added in AIX IPSec that simplifies the whole process for enterprises. The feature provides:

  • The ability to store multiple sets of IPSec configuration policy on the LDAP server for centralized management.
  • The ability to define an IPSec configuration policy and associate it with a set of hosts.

    All the machines associated with an IPSec configuration policy will use the same set of IPSec configurations (rules) defined by an XML file. A machine can be associated to only one policy at a time.

  • Settings that will be refreshed every 60 minutes. If the tunnel configuration has changed, old tunnels will be destroyed and new ones will be created.
  • Support only for certificate-based authentication for phase 1 tunnels.

The new AIX feature creates tunnels for each pair of the IP addresses that are part of the IPSec configuration policy.


Configuring AIX IPSec

The configuration files used by AIX to create IPSec tunnels are in XML format. There are more than 20 configuration parameters that must be configured to create a tunnel between two systems. The configurable parameters are put in the XML file. However, the XML file does not contain IP addresses; these are obtained from the machines that are associated with the policy. AIX IPSec provides a command to load the XML configuration file into the LDAP server.

Listing 1 shows a sample XML configuration file that is stored on the LDAP server.

Listing 1. Sample XML configuration file
$cat ipsec_ldap.xml
<?xml version="1.0"?>
<AIX_VPN
      Version="2.0">
   <IKEProtection
         IKE_Role="Both"
         IKE_Version="2"
         IKE_XCHGMode="Main"
         IKE_KeyOverlap="10"
         IKE_Flags_UseCRL="No"
         IKE_ProtectionName="P1Pol"
         IKE_ResponderKeyRefreshMaxKB="200"
         IKE_ResponderKeyRefreshMinKB="1"
         IKE_ResponderKeyRefreshMaxMinutes="1440"
         IKE_ResponderKeyRefreshMinMinutes="1">
      <IKETransform
            IKE_Encryption="3DES-CBC"
            IKE_Hash="SHA"
            IKE_DHGroup="2"
            IKE_PRF="PRF_HMAC_SHA1"
            IKE_AuthenticationMethod="RSA_signatures"/>
   </IKEProtection>
   <IPSecProposal
         IPSec_ProposalName="P2Prop">
      <IPSecESPProtocol
            ESP_Encryption="ESP_3DES"
            ESP_KeyRefreshKB="0"
            ESP_Authentication="HMAC-SHA"
            ESP_ExtendedSeqNum="0"
            ESP_EncapsulationMode="Tunnel"
            ESP_KeyRefreshMinutes="480"/>
   </IPSecProposal>
   <IPSecProtection
         IPSec_Role="Both"
         IPSec_KeyOverlap="10"
         IPSec_ProposalRefs="P2Prop "
         IPSec_ProtectionName="P2Pol"
         IPSec_InitiatorDHGroup="1"
         IPSec_ResponderDHGroup="NO_PFS GROUP_1 GROUP_2"
         IPSec_Flags_UseLifeSize="No"
         IPSec_Flags_UseCommitBit="No"
         IPSec_ResponderKeyRefreshMaxKB="200"
         IPSec_ResponderKeyRefreshMinKB="1"
         IPSec_ResponderKeyRefreshMaxMinutes="43200"
         IPSec_ResponderKeyRefreshMinMinutes="1"/>
</AIX_VPN>

Configuring LDAP clients as IPSec endpoints

All of the machines that will be endpoints in an IPSec tunnel must have the LDAP client configured. There are two new configuration options in the ldap.cfg file of the AIX LDAP client to support AIX IPSec tunnels, as shown in Listing 2.

Listing 2. Configuration options
# Base Dn where IPSec policy and IPSec host data is stored on LDAP server.
ipsecbasedn:ou=ipsec,cn=aixdata
ip_hostbasedn:ou=Ip_host,cn=aixdata

After the ldap.cfg file has been updated, refresh the secldapclntd daemon with the command in Listing 3.

Listing 3. Refresh
# restart-secldapclntd
The secldapclntd daemon terminated successfully.
Starting the secldapclntd daemon.
The secldapclntd daemon started successfully.

# mkipsecldap -D <binddn> -w <bindpwd>  [-b <basedn> ]

For example, you can use # mkipsecldap -D cn=admin -w adminpwd.

To verify if the parent object for IPSec configuration is added, use the ldapsearch command, as shown in Listing 4.

Listing 4. Verification
# ldapsearch -h vayu17.in.ibm.com -D cn=admin -w
adminpwd -s sub -b "ou=Ip_host,cn=aixdata"
objectclass=*
ou=Ip_host,cn=aixdata
ou=Ip_host
objectClass=organizationalUnit
objectClass=top

# ldapsearch -h vayu17.in.ibm.com -D cn=admin -w
adminpwd -s sub -b " ou=ipsec,cn=aixdata" objectclass=*
ou=ipsec,cn=aixdata
ou=ipsec
objectClass=organizationalUnit
objectClass=top

You also need to ensure that all of the IKE services are active, as shown in Listing 5.

Listing 5. IKE services
# lssrc -g ike
Subsystem         Group            PID          Status
 cpsd             ike              2883782      active
 tmd              ike              5373970      active
 iked             ike              9175268      active

Creating GSKit keyfiles for the client machines

The AIX IPSec simplification feature supports certificate-based authentication. You can create certificates by using the IBM Global Security Kit (GSKit) commands for each client machine.

Creating certificates using GSKit

This section explains how to create certificates using the GSKit for the IPSec certificate authentication mechanism. IBM GSKit is a library and set of command-line tools that is used by many IBM products. IPSec in AIX is one feature that uses these files for an IPSec certificate authentication mechanism. (Further discussion of the GSKit tool is outside the scope of this article.)

The following steps show typical commands used to create the necessary GSKit keyfiles for two machines that will communicate with each other over IPSec. The certificates in both machines' keyfiles are signed by the same certificate authority (CA). After the keyfiles are generated, they must be installed into the /etc/security directory of each machine.

  1. Create two key database files using the gskit command. To create the database for machine 1, use the code in Listing 6.
    Listing 6. Create database, machine 1
    #gsk7cmd -keydb -create -db /GSK_CERTS/ikekey -pw
    123456 -type cms –stash

    To create the database for machine 2, use the code in Listing 7.
    Listing 7. Create database, machine 2
    #gsk7cmd -keydb -create -db /GSK_CERTS/ikekey1 -pw
    123456 -type cms –stash
  2. Generate a root certificate authority in the first machine's keyfile using the command in Listing 8.
    Listing 8. Root authority certificate
    #gsk7cmd  -cert -create -db /GSK_CERTS/ikekey.kdb -pw
    123456 -size 1024 -dn "C=IN,O=IBM,CN=ipsecroot"
    -label Root_CA -default_cert  yes -ca yes
  3. To list the database contents, use the command in Listing 9.
    Listing 9. List database contents
    #gsk7cmd -cert -list -db /GSK_CERTS/ikekey.kdb -pw 123456
    Certificates in database: /GSK_CERTS/ikekey.kdb
       Entrust.net Global Secure Server Certification Authority
       Entrust.net Global Client Certification Authority
       Entrust.net Client Certification Authority
       Entrust.net Certification Authority (2048)
       Entrust.net Secure Server Certification Authority
       VeriSign Class 3 Secure Server CA
       VeriSign Class 3 Public Primary Certification Authority
       VeriSign Class 2 Public Primary Certification Authority
       VeriSign Class 1 Public Primary Certification Authority
       VeriSign Class 4 Public Primary Certification Authority - G2
       VeriSign Class 3 Public Primary Certification Authority - G2
       VeriSign Class 2 Public Primary Certification Authority - G2
       VeriSign Class 1 Public Primary Certification Authority - G2
       VeriSign Class 4 Public Primary Certification Authority - G3
       VeriSign Class 3 Public Primary Certification Authority - G3
       VeriSign Class 2 Public Primary Certification Authority - G3
       VeriSign Class 1 Public Primary Certification Authority - G3
       Thawte Personal Premium CA
       Thawte Personal Freemail CA
       Thawte Personal Basic CA
       Thawte Premium Server CA
       Thawte Server CA
       Root_CA

Root_CA is the new certificate authority that was created.

After the root CA is created, create a certificate request for a user certificate for the first machine. Listing 10 shows an example.

Listing 10. Certificate request
#gsk7cmd -certreq -create -db /GSK_CERTS/ikekey.kdb
-pw 123456 -label Test_Cert1 -dn
"C=IN,ST=KA,L=BA,O=IBM,OU=ISL,CN=test1" -size 1024
-file /GSK_CERTS/cert1_csr.arm

Now that the certificate request is created, generate the user certificate by signing the certificate request using the Root_CA certificate, as in Listing 11.

Listing 11. Sign the certificate request
#gsk7cmd -cert -sign -db /GSK_CERTS/ikekey.kdb  -pw
123456 -label Root_CA -target /GSK_CERTS/Test_Cert1.cer
-format ascii -expire 100 -file /GSK_CERTS/cert1_csr.arm

After the certificate is created, add it to the GSKit key database of the first machine. Listing 12 shows an example.

Listing 12. Add certificate
#gsk7cmd -cert -receive -file /GSK_CERTS/Test_Cert1.cer
-db /GSK_CERTS/ikekey.kdb  -pw 123456 -type cms -format ascii

You can list the database using the command shown in Listing 13.

Listing 13. List the database
#gsk7cmd -cert -list -db /GSK_CERTS/ikekey.kdb -pw 123456
Certificates in database: /GSK_CERTS/ikekey.kdb
   Entrust.net Global Secure Server Certification Authority
   Entrust.net Global Client Certification Authority
   Entrust.net Client Certification Authority
   Entrust.net Certification Authority (2048)
   Entrust.net Secure Server Certification Authority
   VeriSign Class 3 Secure Server CA
   VeriSign Class 3 Public Primary Certification Authority
   VeriSign Class 2 Public Primary Certification Authority
   VeriSign Class 1 Public Primary Certification Authority
   VeriSign Class 4 Public Primary Certification Authority - G2
   VeriSign Class 3 Public Primary Certification Authority - G2
   VeriSign Class 2 Public Primary Certification Authority - G2
   VeriSign Class 1 Public Primary Certification Authority - G2
   VeriSign Class 4 Public Primary Certification Authority - G3
   VeriSign Class 3 Public Primary Certification Authority - G3
   VeriSign Class 2 Public Primary Certification Authority - G3
   VeriSign Class 1 Public Primary Certification Authority - G3
   Thawte Personal Premium CA
   Thawte Personal Freemail CA
   Thawte Personal Basic CA
   Thawte Premium Server CA
   Thawte Server CA
   Test_Cert1
   Root_CA

Note that the other entries in the list are created by default when the key database is created, and they can be removed.

Create a certificate for the second machine following a similar process. First, create the certificate request, as in Listing 14.

Listing 14. Create certificate request for machine 2
(0) root @ vayu09: 6.1.0.0: /GSK_CERTS
# gsk7cmd -certreq -create -db /GSK_CERTS/ikekey.kdb
    -pw 123456 -label Test_Cert2 -dn
    "C=IN,ST=KA,L=BA,O=IBM,OU=ISL,CN=test2" -size 1024 -
    file /GSK_CERTS/cert2_csr.arm

The next step is to sign the certificate with the ROOT_CA certificate authority certificate. Listing 15 shows an example.

Listing 15. Sign certificate
(0) root @ vayu09: 6.1.0.0: /GSK_CERTS
# gsk7cmd -cert -sign -db /GSK_CERTS/ikekey.kdb  -pw
    123456 -label Root_CA -target /GSK_CERTS/Test_Cert2.cer
    -format ascii -expire 100 -file
    /GSK_CERTS/cert2_csr.arm

Import the signed certificate into the GSKit keyfile, as in Listing 16.

Listing 16. Import signed certificate
(0) root @ vayu09: 6.1.0.0: /GSK_CERTS
# gsk7cmd -cert -receive -file
    /GSK_CERTS/Test_Cert2.cer -db /GSK_CERTS/ikekey.kdb -
    pw 123456 -type cms -format ascii

You can verify that both certificates are in the file using the code in Listing 17.

Listing 17. Verification
# gsk7cmd -cert -list -db /GSK_CERTS/ikekey.kdb -pw
123456
Certificates in database: /GSK_CERTS/ikekey.kdb
   Test_Cert2
   Test_Cert1
   Root_CA

At this point, the client machines' certificates are all stored in one master keyfile. You can copy the certificates into separate files so that they can be distributed to each of the client machines. Make sure Root_CA is also copied to the client machine's GSKit files. Listing 18 shows an example.

Listing 18. Copy certificates into separate files
#gsk7cmd -cert -export -db /GSK_CERTS/ikekey1.kdb -pw
 123456 -label Root_CA -type cms -target
 /GSK_CERTS/ikekey1.kdb -target_pw 123456 -target_type
cms

(127) root @ vayu09: 6.1.0.0: /GSK_CERTS
# gsk7cmd -cert -export -db /GSK_CERTS/ikekey1.kdb -pw
 123456 -label Test_Cert2  -type cms -target
 /GSK_CERTS/ikekey1.kdb -target_pw 123456 -target_type
cms

You can verify the contents of the new keyfile by listing its contents, as shown in Listing 19.

Listing 19. Verify contents
# gsk7cmd -cert -list -db /GSK_CERTS/ikekey1.kdb -pw
 123456
Certificates in database: /GSK_CERTS/ikekey1.kdb
   Root_CA
   Test_Cert2

Next, you delete Test_Cert2 from the master keyfile so that it will only contain the certificate for the first machine. Listing 20 shows an example.

Listing 20. Delete Test_Cert2
#gsk7cmd -cert -delete -db ikekey.kdb  -pw 123456 -
    label " Test_Cert2”

To verify that each file has only the certificates needed for its machine, list the contents of each, as in Listing 21.

Listing 21. List contents
# gsk7cmd -cert -list -db /GSK_CERTS/ikekey1.kdb -pw
123456
Certificates in database: /GSK_CERTS/ikekey1.kdb
   Root_CA
   Test_Cert2

# gsk7cmd -cert -list -db /GSK_CERTS/ikekey.kdb -pw
123456
Certificates in database: /GSK_CERTS/ikekey.kdb
   Test_Cert1
   Root_CA

After the certificates are ready, copy the key database in the /etc/security path in each machine.

Make sure all the IPSec-related services are up and running, as in Listing 22.

Listing 22. Check IPSec-related services
# lssrc -g ike
Subsystem         Group            PID          Status
 cpsd             ike              2883782      active
 tmd              ike              5373970      active
 iked             ike              9175268      active

You're now ready to establish the tunnels between the two machines by creating the policies on the LDAP server.


Defining IPSec policies with client machines

To associate an IPSec policy with the first machine, use the ikedb command, as in Listing 23.

Listing 23. Associate an IPSec policy with machine 1
# ikedb -R LDAP -A testpolicy -f ldap.xml -h vayu09.in.ibm.com -C
"/C=IN/ST=KA/L=BA/O=IBM/OU=ISL/CN=test1"

testpolicy is the name of the policy, and -C takes a distinguished name string as input. This distinguished name must be the same as the one passed to the –dn option to generate the certificate for the first machine.

Similarly, to associate the same policy with the second machine, use the code in Listing 24.

Listing 24. Associate same policy with machine 2
# ikedb -R LDAP -A testpolicy -f ldap.xml -h
vayu07.in.ibm.com -C
"/C=IN/ST=KA/L=BA/O=IBM/OU=ISL/CN=test2"

After the commands have completed successfully, you're ready to create tunnels.


Starting IPSec tunnels between client machines

To create IPSec tunnels between all client machines defined in the LDAP server, use the ike command, as in Listing 25.

Listing 25. ike command
# ike cmd=activate
Phase 2 tunnel 1 On_Demand activate request initiated.

To verify that the tunnels are working, issue a ping command from one client machine to another. You can also then run the ike cmd=list command to list the tunnels created. Listing 26 shows an example.

Listing 26. List tunnels
# ike cmd=list
Phase  Tun Id  Status      Local Id                        Remote Id
1      1       Active      9.124.101.209                   9.126.85.157
2      1       Active      9.124.101.209                   9.126.85.157

Other useful commands

To display the XML file for a policy, use: # ikedb –R LDAP –g <policy name>

To dump the DTD for an XML file stored on the LDAP server, use: # ikedb -R LDAP –o

To delete a policy on the LDAP server, use: #ikedb –R LDAP –D <policy name>

To refresh the tunnel configurations, use: # ikedb -R LDAP

The AIX IPSec feature also has an auto refresh capability. To enable the auto refresh, use ikedb –R LDAP –p from the secldapclntd LDAP daemon. The IPSec tunnels will be refreshed at the interval duration defined by the IPSECrefreshInterval parameter in the ldap.cfg file.


Conclusion

This article showed how to use the centralized IPSec management feature in AIX to manage the IPSec configuration for a large number of client machines.

Resources

Learn

Get products and technologies

  • Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, or use a product in a cloud environment.

Discuss

  • Get involved in the developerWorks Community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Security on developerWorks


  • Bluemix Developers Community

    Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.

  • Security

    Pragmatic, intelligent, risk-based IT Security practices.

  • DevOps Services

    Software development in the cloud. Register today to create a project.

  • IBM evaluation software

    Evaluate IBM software and solutions, and transform challenges into opportunities.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Security, AIX and UNIX
ArticleID=937020
ArticleTitle=Simplify and centralize IPSec management on AIX
publish-date=07152013