IKE Public Key Databases and Commands

The ikecert(1M) command manipulates the local host's public-key databases. Because IKE uses these databases to authenticate the Phase 1 exchange when the ike.config file requires public key certificates, the directories must be populated before activating the in.iked daemon. Three subcommands handle each of the three databases: certlocal, certdb, and certrldb.

ikecert certlocal Command

The certlocal subcommand manages the private-key database in the /etc/inet/secret/ike.privatekeys directory. Options to the subcommand enable you to add, view, and remove private keys. The command also creates either a self-signed certificate or a certificate request. The -ks option creates a self-signed certificate, and the -kc option creates a certificate request.

Parameters that you pass to the certlocal subcommand when you create a private key must be reflected in the ike.config file, as shown in the following table.

Table 21-2 Correspondences Between ike certlocal and ike.config Values

certlocal options	ike.config entry	Notes
-A Subject Alternate Name	cert_trust Subject Alternate Name	A nickname that uniquely identifies the certificate. Possible values are IP address, email address, and domain name.
-D X.509 Distinguished Name	cert_root X.509 Distinguished Name	The full name of the certificate authority that includes Country, Organization name, Organizational Unit, and Common Name.
-t dsa-sha1	auth_method dss_sig	Slightly slower than RSA. Is not patented.
-t rsa-md5 -t rsa-sha1	auth_method rsa_sig	Slightly faster than DSA. Patent expired in September 2000. The RSA public key must be large enough to encrypt the biggest payload, Typically, an identity payload, such as Distinguished Name, is the biggest.
-t rsa-md5 -t rsa-sha1	auth_method rsa_encrypt	RSA encryption hides identities in IKE from eavesdroppers, but requires that the IKE peers know each other's public keys.

If you issue a certificate request with the ikecert certlocal -kc command, you send the output of the command to your vendor. The vendor then creates keying material. You use the vendor's keying material as input to the certdb and certrldb subcommands.

ikecert certdb Command

The certdb subcommand manages the public-key database, /etc/inet/ike/publickeys. Options to the subcommand enable you to add, view, and remove public keys and certificates. The command accepts, as input, certificates that were generated by the ikecert certlocal -ks command on a communicating system. See "How to Configure IKE With Self-Signed Public Certificates" for the procedure. The command also accepts the certificate that you receive from a PKI or CA as input. See "How to Configure IKE With Public Keys Signed by a Certificate Authority" for the procedure.

ikecert certrldb Command

The certrldb subcommand manages the certificate revocation list (CRL) database, /etc/inet/ike/crls. The crls database maintains the revocation lists for public keys. Certificates that are no longer valid are on this list. When PKIs provide you with CRLs, you install them in the CRL database with the ikecert certrldb command. See "How to Update a Certificate Revocation List" for the procedure.

/etc/inet/ike/publickeys Directory

The /etc/inet/ike/publickeys directory contains the public part of a public-private key pair and its certificate in files, or "slots". The /etc/inet/ike directory is protected at 0755. The public-key databases that are stored under it are world-readable (0644). You use the ikecert certdb command to populate the directory.

The files contain, in encoded form, the X.509 distinguished name of a certificate that was generated on another system. If you are using self-signed certificates, you use the certificate that you receive from the administrator of the communicating system as input to the command. If you are using certificates from a PKI, you install two pieces of keying material from the vendor into this database -- a certificate based on material you sent to the vendor, and a CA from the vendor.

An evaluation copy of the iPlanet CMS, a PKI, is available on the Media Kit in the installation package.

/etc/inet/secret/ike.privatekeys Directory

The ike.privatekeys directory holds private key files that are part of a public-private key pair, keying material for ISAKMP SAs. The directory is protected at 0700. The private key in this database must have a public key counterpart in the publickeys database.The ikecert certlocal command populates this directory. Private keys are not effective until their public key counterparts, self-signed certificates or CAs, are installed in the /etc/inet/ike/publickeys directory.

/etc/inet/ike/crls Directory

The /etc/inet/ike/crls directory contains certificate revocation list (CRL) files. Each file corresponds to a public certificate file in the /etc/inet/ike/publickeys/ directory. PKI vendors provide the CRLs for their certificates. You use the ikecert certrldb command to populate the database.

Implementing IKE Task Map

The ikeadm(1M), ikecert(1M), and ike.config(4) man pages contain useful procedures in their respective Examples sections.

Table 21-3 Implementing IKE Task Map

Task	Description	For Instructions, Go To ...
Configure IKE with pre-shared keys	Involves creating a valid IKE policy file and ike.preshared file. IPsec files are also set up before booting the system to use the IKE-generated keys.	"How to Configure IKE With Pre-Shared Keys"
Refresh pre-shared keys on a running IKE system	Involves checking the IKE privilege level and editing the ipseckeys file with fresh keying material on communicating systems.	"How to Refresh Existing Pre-Shared Keys"
Add pre-shared keys to a running IKE system	Involves checking the IKE privilege level and running the ikeadm command with fresh keying material on communicating systems.	"How to Add New Pre-Shared Keys"
Configure IKE with self-signed public key certificates	Involves creating self-signed certificates with the ikecert certlocal -ks command, and adding the public key from a communicating system with the ikecert certdb command.	"How to Configure IKE With Self-Signed Public Certificates"
Configure IKE with a PKI Certificate Authority	Involves sending output from the ikecert certlocal -kc command to a PKI, and installing the public key, CA, and CRL from the vendor.	"How to Configure IKE With Public Keys Signed by a Certificate Authority"
Update the CA revocation lists	Involves installing a PKI vendor's CRL with the ikecert certrldb command.	"How to Update a Certificate Revocation List"

IKE Tasks

This section provides procedures that enable you to automatically manage the keys that secure traffic between two systems with IPv4 addresses. The IKE implementation offers algorithms whose keys vary in length. The key length that you choose is determined by site security. In general, longer keys provide more security than shorter keys.

How to Configure IKE With Pre-Shared Keys

1. Become superuser on the system console.

   ---

   Note - Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the total security of the system is reduced to the security of the remote login session.

   ---

2. On each system, create an /etc/inet/ike/config file with global parameters and rules that permit the IPsec policy in ipsecinit.conf to succeed. For example,

   ### ike/config file on enigma, 192.168.66.1 ## Global parameters # ## Phase 1 transform defaults p1_lifetime_secs 14400 p1_nonce_len 40 # ## Defaults that individual rules can override. p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg 3des } p2_pfs 2 # ## The rule to communicate with partym { label "Enigma-Partym" localid 192.168.66.1 remoteid 192.168.55.2 p1_xform { auth_method preshared oakley_group 5 auth_alg md5 encr_alg des } p2_pfs 5 }

   ### ike/config file on partym, 192.168.55.2 ## Global Parameters # p1_lifetime_secs 14400 p1_nonce_len 40 # p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg 3des } p2_pfs 2 ## The rule to communicate with enigma { label "Partym-Enigma" localid 192.168.55.2 remoteid 192.168.66.1 p1_xform { auth_method preshared oakley_group 5 auth_alg md5 encr_alg des } p2_pfs 5 }

   ---

   Note - These machine names are examples only. Use the names and addresses of your machines when securing traffic between them.

   ---

3. On each machine, check the validity of the file:

   # /usr/lib/inet/in.iked -c -f /etc/inet/ike/config

4. Generate random keys.

   On a Solaris system, you can use the od command. For example,

   # od -x </dev/random | head -4 0000000 df97 6d2f 4ef5 2c28 02d5 02aa f9de 481d 0000020 2ae8 b949 67e6 b9b0 dd16 e6d4 b7ea 7278 0000040 ac07 7cc6 99c1 7055 848a 3cf3 4377 980a 0000060 5ad7 5b40 b428 9f3a da20 7daa 65a4 83fe

5. Create the file /etc/inet/secret/ike.preshared on each system and put the pre-shared key in each file.

   The encryption algorithm in this example (see Step 2) is DES, so the pre-shared key must be at least 64 bits. However, a longer key length is a good idea. For example,

   # ike.preshared on enigma, 192.168.66.1 { localidtype IP localid 192.168.66.1 remoteidtype IP remoteid 192.168.55.2 # enigma and partym's shared key in hex (128 bits) key ac077cc699c17055848a3cf34377980a }

   # ike.preshared on partym, 192.168.55.2 { localidtype IP localid 192.168.55.2 remoteidtype IP remoteid 192.168.66.1 # partym and enigma's shared key in hex (128 bits) key ac077cc699c17055848a3cf34377980a }

   ---

   Note - The pre-shared keys must be identical.

   ---

6. On each system, add the address and host name for the other system in the /etc/hosts file. For example,

   On a system named partym:

   # Secure communication with enigma 192.168.66.1 enigma

   On a system named enigma:

   # Secure communication with partym 192.168.55.2 partym

7. On each system, edit the /etc/inet/ipsecinit.conf file by adding the following lines:

   On enigma:

   {laddr enigma raddr partym} ipsec {auth_algs any sa shared}

   On partym:

   {laddr partym raddr enigma} ipsec {auth_algs any sa shared}

8. Enable secure communication by rebooting each system.

   # /usr/sbin/reboot