Questions
- What's New?
- Can I configure IKE tunnels from the command line?
- How can I view the ikedb DTD?
- Where can I find sample XML files for ikedb?
- How do you import and export IKE tunnels between 2 AIX systems?
- How does an AIX VPN interoperate with a Linux VPN?
- How are IKE 'groups' useful, and can you give me a sample of a 'group' definition?
- Why would I want to use Digital Certificates?
- How can I configure an IKE tunnel to use Digital Certificates?
- What's a Certificate Revocation List?
- How can I configure an IKE tunnel to use CRL Checking?
- What is the EZ Config task guide?
- What is the IKE Tunnel Wizard (V 5.0)?
- What happens when you 'build the 3DES database' from the GUI?
- Which mode of authentication should I use? Preshared keys or RSA signature?
- Is the preshared key used for encryption?
- How can the Parse Payload log output used for debugging?
- How do I Import and Export Manual tunnels?
- How do I determine what type of tunnel to use - manual, IBM or IKE?
FAQs and tips
Q: What's new?
The current version of IP Security supports Network Address Translation (NAT). This allows sites to take full advantage of NAT gateways and have the safety of IP Security.
IKE supports Dynamic Host Configuration Protocol (DHCP) or Dynamically Assigned Addresses. A unique feature to AIX IP security is a Group ID, which allows one DHCP tunnel definition to work for all DHCP clients.
AIX 5L Version 2 (5.2) IKE has been enhanced to support a generic Data Management tunnel. When a generic Data Management tunnel is defined, it allows any address to match the generic tunnel definition and be used, as long as the rigorous security validation was successful in the Key Management negotiation phase. This feature is beneficial in DHCP environments where the IP addresses are dynamically assigned.
IKE has been enhanced to support another Diffie Hellman group, group 5 (DH group 5). Diffie Hellman Key exchange is a public key crypto system where public values are exchanged to arrive at a symmetric key. Each DH group defines a prime and a generator function to use when deriving a symmetric key. Symmetric keys derived using DH group 5 are more secure that the currently implemented DH groups (groups 1 and 2).
IP security static filter rules have been enhanced to allow a user to input an eighty character maximum description. This feature is convenient if a customer has many filter rules because it allows customization of the rules and makes them easily identifiable.
SMIT user interface has been added to include IKE tunnel support and basic IKE database functions. The SMIT interfaces use underlying XML command functions to perform additions, deletions, and modifications to the IKE tunnel definitions. IKE SMIT is useful in configuring IKE tunnel quickly and gives a user examples of the XML syntax used to create IKE tunnel definitions. The functions of backing up, restoring, and initializing the IKE database are new to SMIT also.
In AIX 5L Version 2, a new version of the cryptographically secure random number generator is provided for any cryptographic applications requiring high-quality, secure random numbers. AIX IKE is currently using this random number generator to increase its security.
Q. Can I configure IKE tunnels from the command line?
A. Yes, with the ikedb command you can create, view and delete tunnel definitions through the command line. The ikedb command is shipped in the bos.net.ipsec.keymgt fileset.
ikedb allows you to configure your tunnel definition with simple XML files and can also convert Linux configuration files into IKE tunnel definitions that AIX can support.
Refer to the FAQ in /usr/samples/ipsec/README for More information and the on-line publications in the AIX Commands Reference and System Management Guide: Networking and Communications.
Q. How can I view the ikedb DTD?
A. The command 'ikedb -o' will display the IKE DTD.
Q. Where can I find sample XML files for ikedb?
A. The sample XML files for ikedb are located in the directory /usr/samples/ipsec. The samples provided are for commonly used Data Management policies, gateway to gateway tunnels, and tunnels to Microsoft Windows 2000.
Q. How do you import and export IKE tunnels between 2 AIX systems?
A. To export the IKE tunnel information, the command 'ikedb -g' will retrieve the objects currently defined in the database. This output can be redirected to a file:
ikedb -g > ./export_file.xml
You can then copy this file to a remote machine, and import the object definitions with the ikedb command on the remote machine.
When you import the tunnels in the the database, the '-s' flag of ikedb will switch the remote and local endpoints:
ikedb -ps ./export_file.xml
NOTE: 'ikedb -g' by default does not retrieve the pre-shared keys. If you plan to use pre-shared key authentication, you need to also write the pre-shared keys to the export file before you send it to the remote machine:
ikedb -g -t IKEPresharedKey >> ./export_file.xml
These 2 commands will append the information in the export_file.xml file to any existing IKE tunnel definitions the database contains.
Q. How does an AIX VPN interoperate with a Linux VPN?
A. The IPsec implementation for Linux is provided by FreeS/WAN (www.freeswan.org). FreeS/WAN IPsec is available for Linux kernels 2.2 and later. Linux provides a subset of the IPsec functionality provided by AIX.
AIX provides a conversion facility through the ikedb command to facilitate interoperability with Linux. The -c option of ikedb provides an easy way for the user to configure a tunnel between a Linux and AIX machine. To use the -c option, define the tunnel between Linux and AIX on the Linux system. Two files are created, ipsec.conf and ipsec.secrets, located in /etc directory. The ipsec.conf file contains information about the tunnel while ipsec.secrets holds the keys. A sample ipsec.conf and ipsec.secrets file are as follows:
---------------------------------------------
ipsec.conf file:
config setup
interfaces=%defaultroute
klipsdebug=all
plutodebug=all
plutoload=%search
plutostart=%search
uniqueids=yes
conn %default
keyingtries=1
type=tunnel
auth=esp
authby=secret
pfs=no
keylife=1800s
rekeymargin=900s
rekeyfuzz=90%
auto=add
left=%defaultroute
conn aix
left=192.168.1.10
leftsubnet=192.168.2.0/24
right=192.168.1.20
rightsubnet=192.168.3.0/24
---------------------------------------------
ipsec.secrets file
# This file holds shared secrets or
RSA private keys for inter-Pluto
# authentication. See IPsec_pluto(8)
manpage, and HTML documentation.
192.168.1.10 192.168.1.20 : "secret"
---------------------------------------------
Once these files are created on Linux, move the files to the AIX machine by ftp or any other method. Use the ikedb command, -c option, to convert the Linux configuration to the corresponding AIX configuration and load the information into the AIX database. In the example that follows, it is assumed that the user already has the ipsec.conf and ipsec.secrets file in the /tmp directory.
>cd /tmp
>ikedb -c # This converts the Linux config
to aix and loads it
Before the tunnel can be activated, the daemons should be started. The commands for starting (restarting) the daemons are as follows:
Linux : ipsec setup restart
AIX : stopsrc -g ike
startsrc -g ike
The tunnel can be activated from either Linux or AIX. The command to activate the tunnel as per this example is as follows:
Linux : ipsec auto --up aix AIX : ike cmd=activate
Q. How are IKE 'groups' useful, and can you give me a sample of a 'group' definition?
A. A group is a collection of IDs to be used in a tunnel definition in order to associate IKE IDs to the same security policy so that users do not need to define a separate tunnel for each ID. It helps admins to easily configure tunnels with several remote hosts and, if changes need to be made to a security policy, an admin would need to only make the changes to a single definition.
Group IDs can be used in both phase 1 and phase 2 tunnels, but only as a remote ID. Groups are defined using the command line interface, ikedb. Example XML code is shown below to define a group, then an IKE tunnel.
For example, you can define a group "P1_tun1_Group_1" which includes 4 different ID types (FQDN, IPv4 address, User@FQDN, and IPv6 address) as following:
<!-- BEGIN IKEGroup P1_tun1_Group_1 -->
<IKEGroup IKE_GroupName="P1_tun1_Group_1">
<IKEID Protocol="0" Port="0">
<FQDN Value="rockyroad.com">
<IPV4_Address Value="1.2.3.4"/>
</FQDN>
</IKEID>
<Protocol="0" Port="0">
<IPV4_Address Value="1.2.3.5"/>
</IKEID>
<IKEID Protocol="0" Port="0">
<User_FQDN Value="me@chocolate.com">
<IPV6_Address Value="1:2:3:4:5:6:7:76"/>
</User_FQDN>
</IKEID>
<IKEID Protocol="0" Port="0">
<IPV6_Address Value="1:2:3:4:5:6:7:76"/>
</IKEID>
</IKEGroup>
<!-- END IKEGroup P1_tun1_Group_1 -->
Then you can use this group name, "P1_tun1_Group_1", as the remote ID in the tunnel definition. The XML syntax is:
<!-- BEGIN IKETunnel P1_tun1 -->
<IKETunnel
AutoStart="Yes"
IKE_Flags_MakeRuleWithOptionalIP="No"
IKE_TunnelName="P1_tun1"
IKE_ProtectionRef="P1_tun1_Pol">
<IKELocalIdentity>
<FQDN Value="ripple.com">
<IPV4_Address Value="2.2.2.1"/>
</FQDN>
</IKELocalIdentity>
<IKERemoteIdentity>
<IKEGroupRef IKE_GroupNameRef="P1_tun1_Group_1"/>
</IKERemoteIdentity>
</IKETunnel>
<!-- END IKETunnel P1_tun1 -->
Then you would run the command "ikedb -p xml_filename.xml" to put (add) the above examples to the IKE databases.
Q: Why would I want to use Digital Certificates?
A: Digital Certificates provide a means of authentication in an IKE negotiation. Certificates are digital documents attesting to the binding of a public key to an individual or other entity. They allow verification of the claim that a given public key does in fact belong to a given individual. Certificates help prevent someone from using a phony key to impersonate someone else.
In their simplest form, certificates contain a public key and a name. As commonly used, a certificate also contains an expiration date, the name of the certifying authority that issued the certificate, a serial number, and perhaps other information. Most importantly, it contains the digital signature of the certificate issuer. The most widely accepted format for certificates is defined by the ITU-T X.509 international standard.
Information security is playing a major role in today's corporate IT departments and e-commerce. To cope, the industry is moving towards PKI enabling their applications, and certificates are becoming the most sought after and secure means of authentication. The AIX VPN product supports the signature mode of authentication, so that a user/device can use digital certificates for authentication in establishing a Key management tunnel.
Q: How can I configure an IKE tunnel to use Digital Certificates?
A:
- Ensure that the gskit.rte or gskkm.rte fileset is installed from the AIX Bonus Pack.
- Run the iKeyman GUI tool by issuing the following command 'gsk4ikm' or the command 'certmgr'.
- Create an iKeyman database by doing:
- Click on Key Database File
- Select New
- By default, the filename is key.kdb, change the name to ikekey.kdb
- Enter a location to store the file, it should be /etc/security/
- Click OK
- Enter a password for the database
- Check the Stash Password option
- Click OK and a new key database file will be created
- Use iKeyman to generate a personal certificate request
- Select the Personal Certificate Requests option from the list box
- Click on the New button
- Enter the information prompted for:
NOTE: If the local endpoint ID is an IP address, FQDN, or user@FQDN, you will need to enter the "subject alternate name" field in iKeyman. You will need to input the local endpoint value (i.e., IP address, FQDN, or user@FQDN) in the subject alternate name. See example screen shot below. - Enter the name of the file to store the Certificate request
- Create a directory to store the certificates, ex./home/user/cert_rep/
- Click Ok, A new Certificate Request Key label will appear
- Use the certificate request to get a certificate from a Certificate Authority (CA).
The example used below (for testing purposes) is the SSH testing site, another CA can be used.- Go to the SSH web site, www.ssh.fi (link resides outside of ibm.com)
- Click on TECH CORNER - IP Sec Testing Zone - SSH Certificate Enrollment Testing X.509 Certificate Enrollment Test Page
- Cut and Paste the Certificate Request from the iKeyman file in the space provided on the web page.
- Click on Next Page, Enter the information. Subject Name is parsed by default.
- Subject alternate name fields like IP Address, Domain name(FQDN), e-mail ,URL, or Directory name (LDAP name) should be entered if required. Otherwise, the fields should be left blank.
- Make sure that Digital Signature box is clicked. Again click on next page.
- Cut and paste the Final Certificate in a file.
- Using any editor, remove the 'X.509' string from the lines in the certificate file. iKeyman can not parse the certificate if 'X.509' is present.
-----BEGIN X.509 CERTIFICATE-----
It should look like:
----BEGIN CERTIFICATE-----
Do the same for end of the certificate:
-----END CERTIFICATE-----
- Obtain the CA certificate and add it in the iKeyman database
- Click on TECH CORNER - IP Sec Testing Zone - SSH Certificate Enrollment Testing
- Click on - 'Our Test CA 1 files [1024 bit RRSA]'
- Cut and paste the certificate in a file.
- Add the CA certificate to the iKeyman database.
- Add the personal certificate into the iKeyman database
- Using WebSM, create a tunnel that uses RSA signature mode for authentication.
- Activate the tunnel
Q: What's a Certificate Revocation List
A: A CRL is a list of digital certificate serial numbers that have been revoked before their expiration date. A CRL is published by a Certificate Authority and is used during the IKE negotiation to validate a digital certificate.
Q: How can I configure an IKE tunnel to use CRL Checking?
A: When defining an IKE tunnel, choose "RSA Signature with CRL checking" as the authentication method. This can be done from the 'Basic tunnel Wizard' or from the IKE Key Management Add/Change Transform dialog. Of course, if RSA Signature is chosen, a digital certificate must be loaded in the iKeyman tool (see question above about how to load iKeyman tool).
Also, you need to configure either an LDAP and/or HTTP server name to indicate where the IKE processes should obtain the CRL. This configuration information can be entered from the IKE object in the GUI. Select 'Manage Certificates', then the 'CRL Configuration' action. You can specify an LDAP server, an HTTP servers or both. You can also specify the order to search. Most of the information about the server, except the server name, is defaulted on the dialogs.
Q: What is the EZ Config task guide?
A: The task guide is a fast way to define IKE tunnels using preshared keys. The task guide does not separate the Key management and Data management tunnel definitions, this information is transparent to the user. It prompts the user to enter the basic configuration information which includes the following:
- Tunnel Name
- Local and Remote IP addresses and Netmasks
- Preshared Key
- Encryption and Hash algorithms
- Diffie Hellman groups
- IP security Transform
- Encapsulation mode
Most of these fields have default values.
The task guide creates a Key Management and a Data management tunnel based on the above information and the tunnels are ready to be activated. A default key lifetime of 480 minutes (8 hours) is used and a key life size of 0 (meaning no restriction on the key life size) KiloBytes is used.
Q: What is the IKE Tunnel Wizard?
A: The EZ Config task guide is called a 'wizard' in version 5.0. The wizard has expanded functionality over the previous version. The wizard takes 6 steps and you can create an IKE tunnel using preshared keys, digital certificates and CRL checking. It allows for a tunnel definition of host to host or host to gateway. You can access the wizard from the VPN 'Overview ant tasks plug in (WebSM GUI) by selecting the "Configure a basic tunnel connection".
Q: What happens when you 'build the 3DES database' from the GUI?
A: If policies using triple DES encryption algorithm are needed, the 3DES database can be built from the GUI. The 3DES database entries may not be automatically added if you don't install the highest level of encryption. Building the 3DES database creates the following policies: IBM_high_prekey and IBM_high_Certsig which use 3DES as the encryption algorithm.
To build the 3DES database from the GUI:
- Start the GUI by issuing the command 'wsm network'.
- Select (highlight) the Internet Key Exchange Tunnels option under the Virtual Private Networks menu.
- Click on 'Selected' option in the menu for the window.
- From the selected menu click on 'Build 3DES Database' option
- .
Q: Which mode of authentication should I use? Preshared keys or RSA signature?
A: In Preshared key mode, the keying material has to be chosen and entered manually for an IKE exchange. In signature mode, a Digital Certificate is used for authentication and there is no need of entering a key manually.
When the number of users is small, Preshared Keys can be used, because they are manageble. For a larger number of users, Digital Certificates are the preferred means of authentication and also they are Public Key authentication mechanisms.
Considerations of the amount of resources spent on a public key infrastructure compared to the simplicity of preshared keys need to be made.
Q: Is the preshared key used for encryption?
A: Yes, indirectly. The preshared key is a part of the pseudo–random function used for generating the keying material.
Q: How can the Parse Payload log output be used for debugging?
A: Parse Payload is a useful logging tool which helps in debugging problems encountered during an IKE message exchange. It prints out the different payloads exchanged, when the daemon logging level is set to 'information'.
An example of how to debug a policy mismatch follows:
The initiator and responder policies are SIG_BOTH_MAIN_3DES_SHA, SIG_BOTH_MAIN_DES_MD5 respectively and an IKE exchange takes place and fails to establish a Security Association. By viewing the Parse Payload output in the log file, the cause can be determined.
A portion of the responder side log looks like this:
Responder side log:
9.3.97.217 <<< 9.3.97.135 (
The time is : Sat Oct 30 20:36:26 1999
ISAKMP_MSG_HEADER
Icookie : 0x828c3984cd206df6,
Rcookie : 0x0000000000000000
Next Payload : 1(SA), Maj Ver : 1, Min Ver : 0
Xchg Type : 2 (ID protected), Flag= 0, Encr :
No,COMMIT : No
Msg ID : 0x00000000
len : 0x50(80)
SA Payload:
Next Payload : 0(NONE), Payload len : 0x34(52)
DOI : 0x1(INTERNET)
bitmask : 1(SIT_IDENTITY_ONLY
Proposal Payload:
Next Payload : 0(NONE), Payload len : 0x28(40)
Proposal # : 0x1(1), Protocol-ID : 1(ISAKMP)
SPI size : 0x0(0), # of Trans : 0x1(1)
Transform Payload:
Next Payload : 0(NONE), Payload len : 0x20(32)
Trans # : 0x1(1), Trans.ID : 1(KEY_IKE)
Attr : 1(Encr.Alg ), len=0x2(2)
Value=0x5(5),(3DES-cbc) <--------------
Attr : 2(Hash Alg ), len=0x2(2)
Value=0x2(2),(SHA) <--------------
Attr : 3(Auth Method ), len=0x2(2)
Value=0x3(3),(RSA Signature)
Attr : 4(Group Desc ), len=0x2(2)
Value=0x1(1),(default 768-bit MODP group)
Attr : 11(Life Type ), len=0x2(2)
Value=0x1(1),(seconds)
Attr : 12(Life Duration), len=0x2(2)
Value=0x7080(28800)
.
.
.
.
.
.
9.3.97.217 >>> 9.3.97.135 (
The time is : Sat Oct 30 20:36:26 1999
ISAKMP_MSG_HEADER
Icookie : 0x828c3984cd206df6,
Rcookie : 0x0000000000000000
Next Payload : 11(Notification),
Maj Ver : 1, Min Ver : 0
Xchg Type : 5 (Informational), Flag= 0,
Encr : No,COMMIT : No
Msg ID : 0x00000000
len : 0x38(56)
Notify Payload:
Next Payload : 0(NONE),
Payload len : 0xc(12)
DOI: 1, Protocol: 1(ISAKMP),
SPI size: 0x10(16)
Notify Message Type: 14(No proposal Chosen)
.
.
By analyzing the payloads, you can see that the transform payload received from 9.3.97.135 had 3DES-cbc as the encyption algorithm and SHA as the authentication method. The responder side transform is using DES and MD5 respectively for encryption and authentication. This causes the responder to send a notify payload with a type of 'No proposal chosen'.
Q: How do I Import and Export Manual tunnels?
A: Manual tunnel definitions can be exported from one host and imported to another host. This feature allows a user to set up a tunnel between two peers efficiently.
This can be done from WebSM, SMIT, or the Command line in the following way:
WebSM: Go to the manual tunnels container. The tunnel menu has import and export options. From the import tunnel or export tunnel container, select the tunnels to be imported or exported. Specify the directory name as to where the tunnel definition file can be saved.
SMIT: Type 'smitty ips4_basic' on the command line, which brings up the Basic IP Security configuration panel. Select 'Import IP Security tunnel' or 'Export IP security tunnel' and specify the directory where the tunnel has to be imported from or exported to. This will import definition to an ascii file.
Command Line: Use the 'imptun' command to import a tunnel and the 'exptun' command to export a tunnel.
How to configure between two hosts:
- Create a manual tunnel you want to export (go to step 2 if you already have one)
- Using WebSM, SMIT or the command line, export the tunnel
- The export functionality writes the tunnel definition to an ascii file, with an option of exporting the user defined filter rules for the tunnel definition. The file names of the exported tunnel definition and the exported filter rules are ipsec_tun_manu.exp, ipsec_fltr_rule.exp respectively.
- ftp/rcp (or by any other means) the file to the remote host
- Using WebSM, SMIT or command line, import the tunnel definition files. The source and destination values of the tunnel definition fields are automatically reversed by the import function.
- The tunnel is defined on both the hosts and is ready to be activated.
Q: How do I determine what type of tunnel to use - manual, or IKE?
A: IKE tunnels offer the most effective security of all types. IKE is based on the ISAKMP/Oakley standards developed by the IETF. With this protocol, security parameters are negotiated and refreshed, and keys are exchanged securely. Two types of authentication are supported: preshared key and X.509v3 digital certificate signatures.
Manual Tunnels
Manual tunnels provide backward compatibility and will interoperate with machines that do not support IKE key management protocols. The disadvantage of manual tunnels is that the key values are static. In other words, the encryption and authentication keys are the same for the life of the tunnel and must be manually updated.