Chapter 22 Configuring IKE (Tasks)

This chapter describes how to configure the Internet Key Exchange (IKE) for your systems. After IKE is configured, it automatically generates keying material for IPsec on your network. This chapter contains the following information:

• Configuring IKE (Task Map)

• Configuring IKE With Preshared Keys (Task Map)

• Configuring IKE With Public Key Certificates (Task Map)

• Configuring IKE for Mobile Systems (Task Map)

• Configuring IKE to Find Attached Hardware (Task Map)

• Changing IKE Transmission Parameters (Task Map)

For overview information about IKE, see Chapter 21, Internet Key Exchange (Overview). For reference information about IKE, see Chapter 23, Internet Key Exchange (Reference). For more procedures, see the Examples sections of the ikeadm(1M), ikecert(1M), and ike.config(4) man pages.

Configuring IKE (Task Map)

You can use preshared keys, self-signed certificates, and certificates from a Certificate Authority (CA) to authenticate IKE. A rule links the particular IKE authentication method with the end points that are being protected. Therefore, you can use one or all IKE authentication methods on a system. A pointer to a PKCS #11 library enables certificates to use an attached hardware accelerator.

After configuring IKE, complete the IPsec task that uses the IKE configuration. The following table refers you to task maps that focus on a specific IKE configuration.

Configuring IKE With Preshared Keys (Task Map)

The following table points to procedures to configure and maintain IKE with preshared keys.

Configuring IKE With Preshared Keys

Preshared keys is the simplest authentication method for IKE. If you are configuring two systems to use IKE, and you are the administrator for both of the systems, using preshared keys is a good choice. However, unlike public key certificates, preshared keys are tied to particular IP addresses. Preshared keys cannot be used with mobile systems or systems that might be renumbered. Also, when you use preshared keys, you cannot offload IKE computations to attached hardware.

How to Configure IKE With Preshared Keys

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.

These procedures use the system names enigma and partym. Substitute the names of your systems for the names enigma and partym.

1. On the system console, assume the Primary Administrator role or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

   ---

   Note –

   Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for a secure remote login.

   ---

2. On each system, copy the file /etc/inet/ike/config.sample to the file /etc/inet/ike/config.

3. Enter rules and global parameters in the ike/config file on each system.

   The rules and global parameters in this file should permit the IPsec policy in the system's ipsecinit.conf file to succeed. The following ike/config examples work with the ipsecinit.conf examples in How to Secure Traffic Between Two Systems With IPsec.

   1. For example, modify the /etc/inet/ike/config file on the enigma system:

      ### ike/config file on enigma, 192.168.116.16 ## 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 des } p2_pfs 2 # ## The rule to communicate with partym # Label must be unique { label "enigma-partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 p1_xform { auth_method preshared oakley_group 5 auth_alg md5 encr_alg 3des } p2_pfs 5 }

      ---

      Note –

      All arguments to the auth_method parameter must be on the same line.

      ---

   2. Modify the /etc/inet/ike/config file on the partym system:

      ### ike/config file on partym, 192.168.13.213 ## Global Parameters # p1_lifetime_secs 14400 p1_nonce_len 40 # p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg des } p2_pfs 2 ## The rule to communicate with enigma # Label must be unique { label "partym-enigma" local_addr 192.168.13.213 remote_addr 192.168.116.16 p1_xform { auth_method preshared oakley_group 5 auth_alg md5 encr_alg 3des } p2_pfs 5 }

4. On each system, verify the syntax of the file.

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

5. Generate random numbers for use as keying material.

   If your site has a random number generator, use that generator. On a Solaris system, you can use the od command. For example, the following command prints two lines of hexadecimal numbers:

   % od -X -A n /dev/random | head -2 f47cb0f4 32e14480 951095f8 2b735ba8 0a9467d0 8f92c880 68b6a40e 0efe067d

   For an explanation of the od command, see How to Generate Random Numbers on a Solaris System and the od(1) man page.

   ---

   Note –

   Other operating systems can require ASCII keying material. To generate the identical key in hexadecimal and ASCII formats, see Example 22–1.

   ---

6. From the output of Step 5, construct one key.

   f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e

   The authentication algorithm in this procedure is MD5, as shown in Step 3. The size of the hash, that is, the size of the authentication algorithm's output, determines the minimum recommended size of a preshared key. The output of the MD5 algorithm is 128 bits, or 32 characters. The example key is 56 characters long, which provides additional keying material for IKE to use.

7. Create the file /etc/inet/secret/ike.preshared on each system.

   Put the preshared key in each file.

   1. For example, on the enigma system, the ike.preshared file would appear similar to the following:

      # ike.preshared on enigma, 192.168.116.16 #… { localidtype IP localid 192.168.116.16 remoteidtype IP remoteid 192.168.13.213 # enigma and partym's shared key in hex (192 bits) key f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e }

   2. On the partym system, the ike.preshared file would appear similar to the following:

      # ike.preshared on partym, 192.168.13.213 #… { localidtype IP localid 192.168.13.213 remoteidtype IP remoteid 192.168.116.16 # partym and enigma's shared key in hex (192 bits) key f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e }

   ---

   Note –

   The preshared keys on each system must be identical.

   ---

Example 22–1 Generating Identical Keying Material for Two Systems With Different Operating Systems

Solaris IPsec interoperates with other operating systems. If your system is communicating with a system that requires ASCII preshared keys, you need to generate one key in two formats, hexadecimal and ASCII.

In this example, the Solaris system administrator wants 56 characters of keying material. The administrator uses the following command to generate a hexadecimal key from an ASCII passphrase. The option -tx1 prints the bytes one at a time on all Solaris systems.

# /bin/echo "papiermache with cashews and\c" | od -tx1 | cut -c 8-55 | \
tr -d '\n' | tr -d ' ' | awk '{print}'
7061706965726d616368652077697468206361736865777320616e64

By removing the offsets and concatenating the hexadecimal output, the hexadecimal key for the Solaris system is 7061706965726d616368652077697468206361736865777320616e64. The administrator places this value in the ike.preshared file on the Solaris system.

# Shared key in hex (192 bits)
key 7061706965726d616368652077697468206361736865777320616e64

On the system that requires ASCII preshared keys, the passphrase is the preshared key. The Solaris system administrator telephones the other administrator with the passphrase, papiermache with cashews and.

How to Refresh IKE Preshared Keys

This procedure assumes that you want to replace an existing preshared key at regular intervals.

1. On the system console, assume the Primary Administrator role or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

   ---

   Note –

   Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for a secure remote login.

   ---

2. Generate random numbers and construct a key of the appropriate length.

   For details, see How to Generate Random Numbers on a Solaris System. If you are generating a preshared key for a Solaris system that is communicating with an operating system that requires ASCII, see Example 22–1.

3. Replace the current key with a new key.

   For example, on the hosts enigma and partym, you would replace the value of key in the /etc/inet/secret/ike.preshared file with a new number of the same length.

4. Refresh the IKE keys.

   # svcadm refresh ike

How to View IKE Preshared Keys

By default, the ikeadm command prevents you from viewing the actual keys in a dump of a Phase 1 SA. Viewing the keys is useful during debugging.

To view the actual keys, you must increase the privilege level of the daemon. For a description of the privilege levels, see IKE Administration Command.

Before You Begin

IKE is configured and the ike service is running.

1. View the IKE preshared keys.

   # ikeadm ikeadm> dump preshared

2. If you get an error, increase the privilege level of the in.iked daemon.

   1. Increase the privilege level of the in.iked daemon in the SMF repository.

      # svcprop -p config/admin_privilege ike base # svccfg -s ike setprop config/admin_privilege=keymat

   2. Increase the privilege level of the running in.iked daemon.

      # svcadm refresh ike ; svcadm restart ike

   3. (Optional) Confirm that the privilege level is keymat.

      # svcprop -p config/admin_privilege ike keymat

   4. View the keys by running Step 1 again.

3. Return the IKE daemon to the base privilege level.

   1. After you view the keys, return the privilege level to the default.

      # svccfg -s ike setprop config/admin_privilege=base

   2. Refresh and then restart IKE.

      # svcadm refresh ike ; svcadm restart ike

How to Add an IKE Preshared Key for a New Policy Entry in ipsecinit.conf

If you add IPsec policy entries while IPsec and IKE are running, you restart the policy service and refresh the ike service after you add the new keys.

Before You Begin

This procedure assumes the following:

• The enigma system is set up as described in How to Configure IKE With Preshared Keys.

• The enigma system is going to protect its traffic with a new system, ada.

• The in.iked daemon is running on both systems.

• The systems' interfaces are included as entries in the /etc/hosts file on both systems. The following entry is an example.

  192.168.15.7 ada 192.168.116.16 enigma

  This procedure also works with an IPv6 address. In Solaris Express Community Edition, IPv6 addresses are placed in the /etc/hosts file.

• You have added a new policy entry to the /etc/inet/ipsecinit.conf file on both systems. The entries appear similar to the following:

  # ipsecinit.conf file for enigma {laddr enigma raddr ada} ipsec {auth_algs any encr_algs any sa shared}

  # ipsecinit.conf file for ada {laddr ada raddr enigma} ipsec {auth_algs any encr_algs any sa shared}

• You have verified the syntax of the /etc/inet/ipsecinit.conf file on both systems by using the following:

  # ipsecconf -c -f /etc/inet/ipsecinit.conf

1. On the system console, assume the Primary Administrator role or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

   ---

   Note –

   Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for secure remote login.

   ---

2. On this system, generate random numbers and construct a key of 64 to 448 bits.

   For details, see How to Generate Random Numbers on a Solaris System. If you are generating a preshared key for a Solaris system that is communicating with an operating system that requires ASCII, see Example 22–1.

3. By some means, send the key to the administrator of the remote system.

   You both need to add the same preshared key at the same time. Your key is only as safe as the safety of your transmission mechanism. An out-of-band mechanism, such as registered mail or a protected fax machine, is best. You can also use an ssh session to administer both systems.

4. Create a rule for IKE to manage the keys for enigma and ada.

   1. On the enigma system, add the following rule to the /etc/inet/ike/config file:

      ### ike/config file on enigma, 192.168.116.16   ## The rule to communicate with ada {label "enigma-to-ada" local_addr 192.168.116.16 remote_addr 192.168.15.7 p1_xform {auth_method preshared oakley_group 5 auth_alg md5 encr_alg blowfish} p2_pfs 5 }

   2. On the ada system, add the following rule:

      ### ike/config file on ada, 192.168.15.7   ## The rule to communicate with enigma {label "ada-to-enigma" local_addr 192.168.15.7 remote_addr 192.168.116.16 p1_xform {auth_method preshared oakley_group 5 auth_alg md5 encr_alg blowfish} p2_pfs 5 }

5. Ensure that IKE preshared keys are available at reboot.

   1. On the enigma system, add the following information to the /etc/inet/secret/ike.preshared file:

      # ike.preshared on enigma for the ada interface #  { localidtype IP localid 192.168.116.16 remoteidtype IP remoteid 192.168.15.7 # enigma and ada's shared key in hex (32 - 448 bits required) key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d }

   2. On the ada system, add the following information to the ike.preshared file:

      # ike.preshared on ada for the enigma interface #  { localidtype IP localid 192.168.15.7 remoteidtype IP remoteid 192.168.116.16 # ada and enigma's shared key in hex (32 - 448 bits required) key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d }

6. On each system, restart the IPsec policy service to secure the added interface.

   # svcadm restart policy

7. On each system, refresh the ike service.

   # svcadm refresh ike

8. Verify that the systems can communicate.

   See How to Verify That IKE Preshared Keys Are Identical.

Example 22–2 Adding an IKE Preshared Key for a New IPsec Policy Entry

In the following example, the administrator is adding preshared key to a Solaris system that is not running the current Solaris release. The administrator follows the preceding procedure to modify the ike/config and ike.preshared files, and to generate keys and contact the remote system. The administrator uses different commands to read the new IPsec policy and IKE rules into the kernel.

• Before generating the new key, the administrator sets the privilege level of the in.iked daemon to 2.

  # pkill in.iked # /usr/lib/inet/in.iked -p 2 Setting privilege level to 2

• After sending the key to the other system and adding the new key to the system, the administrator lowers the privilege level.

  # ikeadm set priv base

• Then, the administrator reads the new IPsec policy into the kernel.

  # ipsecconf -a /etc/inet/ipsecinit.conf

• Finally, the administrator reads the new IKE rules into the kernel.

  # ikeadm read rules

How to Verify That IKE Preshared Keys Are Identical

If the preshared keys on the communicating systems are not identical, the systems cannot authenticate.

Before You Begin

IPsec has been configured and is enabled between the two systems that you are testing.

1. On the system console on each system, assume the Primary Administrator role or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

   ---

   Note –

   Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for secure remote login.

   ---

2. On each system, check the privilege level of the in.iked daemon.

   # svcprop -p config/admin_privilege ike base

   • If the privilege level is keymat, continue with Step 3.

   • If the privilege level is base or modkeys, increase the privilege level.

     Then, refresh and restart the ike service.

     # svccfg -s ike setprop config/admin_privilege=keymat # svcadm refresh ike ; svcadm restart ike # svcprop -p config/admin_privilege ike keymat

3. On each system, view the preshared key information.

   # ikeadm dump preshared PSKEY: Preshared key (24 bytes): f47cb…/192 LOCIP: AF_INET: port 0, 192.168.116.16 (enigma). REMIP: AF_INET: port 0, 192.168.13.213 (partym).

4. Compare the two dumps.

   If the preshared keys are not identical, replace one key with the other key in the /etc/inet/secret/ike.preshared file.

5. When the verification is complete, return the privilege level to the default on each system.

   # svccfg -s ike setprop config/admin_privilege=base # svcadm restart ike

Configuring IKE With Public Key Certificates (Task Map)

The following table provides pointers to procedures for creating public key certificates for IKE. The procedures include how to accelerate and store the certificates on attached hardware.

Configuring IKE With Public Key Certificates

Public key certificates eliminate the need for communicating systems to share secret keying material out of band. Unlike preshared keys, a public key certificate can be used on a mobile machine or on a system that might be renumbered.

Public key certificates can also be stored on attached hardware. For the procedure, see Configuring IKE to Find Attached Hardware (Task Map).

How to Configure IKE With Self-Signed Public Key Certificates

Self-signed certificates require less overhead than public certificates from a CA, but do not scale very easily.

1. On the system console, assume the Primary Administrator role or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

   ---

   Note –

   Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for a secure remote login.

   ---

2. Add a self-signed certificate to the ike.privatekeys database.

   # ikecert certlocal -ks|-kc -m keysize -t keytype \ -D dname -A altname \ [-S validity-start-time] [-F validity-end-time] [-T token-ID]

   -ks

   Creates a self-signed certificate.

   -kc

   Creates a certificate request. For the procedure, see How to Configure IKE With Certificates Signed by a CA.

   -m keysize

   Is the size of the key. The keysize can be 512, 1024, 2048, 3072, or 4096.

   -t keytype

   Specifies the type of algorithm to use. The keytype can be rsa-sha1, rsa-md5, or dsa-sha1.

   -D dname

   Is the X.509 distinguished name for the certificate subject. The dname typically has the form: C=country, O=organization, OU=organizational unit, CN=common name. Valid tags are C, O, OU, and CN.

   -A altname

   Is the alternate name for the certificate. The altname is in the form of tag=value. Valid tags are IP, DNS, email, and DN.

   -S validity-start-time

   Provides an absolute or relative valid start time for the certificate.

   -F validity-end-time

   Provides an absolute or relative valid end time for the certificate.

   -T token-ID

   Enables a PKCS #11 hardware token to generate the keys. The certificates are then stored in the hardware.

   1. For example, the command on the partym system would appear similar to the following:

      # ikecert certlocal -ks -m 1024 -t rsa-md5 \ -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \ -A IP=192.168.13.213 Creating software private keys. Writing private key to file /etc/inet/secret/ike.privatekeys/0. Enabling external key providers - done. Acquiring private keys for signing - done. Certificate: Proceeding with the signing operation. Certificate generated successfully (…/publickeys/0) Finished successfully. Certificate added to database. -----BEGIN X509 CERTIFICATE----- MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX … 6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU -----END X509 CERTIFICATE-----

   2. The command on the enigma system would appear similar to the following:

      # ikecert certlocal -ks -m 1024 -t rsa-md5 \ -D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \ -A IP=192.168.116.16 Creating software private keys. … Certificate added to database. -----BEGIN X509 CERTIFICATE----- MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV … jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A== -----END X509 CERTIFICATE-----

3. Save the certificate and send it to the remote system.

   You can paste the certificate into an email.

   1. For example, you would send the following partym certificate to the enigma administrator:

      To: admin@ja.enigmaexample.com From: admin@us.partyexample.com Message: -----BEGIN X509 CERTIFICATE----- MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX … 6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU -----END X509 CERTIFICATE-----

   2. The enigma administrator would send you the following enigma certificate:

      To: admin@us.partyexample.com From: admin@ja.enigmaexample.com Message: -----BEGIN X509 CERTIFICATE----- MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV … jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A== -----END X509 CERTIFICATE-----

4. On each system, add the certificate that you received.

   1. Copy the public key from the administrator's email.

   2. Type the ikecert certdb -a command and press the Return key.

      No prompts display when you press the Return key.

      # ikecert certdb -a Press the Return key

   3. Paste the public key. Then press the Return key. To end the entry, press Control-D.

      -----BEGIN X509 CERTIFICATE----- MIIC… … ----END X509 CERTIFICATE----- Press the Return key <Control>-D

5. Verify with the other administrator that the certificate is from that administrator.

   For example, you can telephone the other administrator to compare the values of the public key hash. The public key hash for the shared certificate must be identical on the two systems.

   1. List the stored certificate on your system.

      For example, on the partym system, the public certificate is in slot 1, and the private certificate is in slot 0.

      partym # ikecert certdb -l Certificate Slot Name: 0 Type: rsa-md5 Private Key Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym> Key Size: 1024 Public key hash: B2BD13FCE95FD27ECE6D2DCD0DE760E2 Certificate Slot Name: 1 Type: rsa-md5 Public Certificate (Private key in certlocal slot 0) Points to certificate's private key Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax> Key Size: 1024 Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

   2. Compare this value with the public key hash on the enigma system.

      You can read the public key hash over the telephone.

      enigma # ikecert certdb -l Certificate Slot Name: 4 Type: rsa-md5 Private Key Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax> Key Size: 1024 Public key hash: DF3F108F6AC669C88C6BD026B0FCE3A0 Certificate Slot Name: 5 Type: rsa-md5 Public Certificate (Private key in certlocal slot 4) Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym> Key Size: 1024 Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

6. On each system, trust both certificates.

   Edit the /etc/inet/ike/config file to recognize the certificates.

   The administrator of the remote system provides the values for the cert_trust, remote_addr, and remote_id parameters.

   1. For example, on the partym system, the ike/config file would appear similar to the following:

      # Explicitly trust the following self-signed certs # Use the Subject Alternate Name to identify the cert # Verified remote address and remote ID # Verified public key hash per telephone call from administrator cert_trust "192.168.13.213" Local system's certificate Subject Alt Name cert_trust "192.168.116.16" Remote system's certificate Subject Alt Name ## Parameters that may also show up in rules. p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg des } p2_pfs 5 { label "US-partym to JA-enigmax" local_id_type dn local_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" local_addr 192.168.13.213 remote_addr 192.168.116.16 p1_xform {auth_method rsa_sig oakley_group 2 auth_alg md5 encr_alg 3des} }

   2. On the enigma system, add enigma values for local parameters in the ike/config file.

      For the remote parameters, use partym values. Ensure that the value for the label keyword is unique. This value must be different from the remote system's label value.

      … { label "JA-enigmax to US-partym" local_id_type dn local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 …

Example 22–3 Verifying That a Certificate From Another Administrator is Valid

In this example, the administrators use the Subject Name to verify that the certificates are identical.

The first administrator saves the output of generating and listing the certificate to a file. Because the output of the ikecert command prints to standard error, the administrator redirects standard error to the file.

sys1# cd /
sys1# ikecert certlocal -ks -m1024 -trsa-md5 \
-D"C=US, O=TestCo, CN=Co2Sys" 2>/tmp/for_co2sys
Certificate added to database.
sys1# ikecert certdb -l "C=US, O=TestCo, CN=Co2Sys" 2>>/tmp/for_co2sys

The administrator verifies the contents of the file.

sys1# cat /tmp/for_co2sys
Creating private key.
-----BEGIN X509 CERTIFICATE-----
MIIB7TCCAVagAwIBAgIEZkHfOTANBgkqhkiG9w0BAQQFADAxMQwwCgYDVQQGEwNV
U0ExEDAOBgNVBAoMB3Rlc3RfY28xDzANBgNVBAMTBkVuaWdtYTAeFw0wODAxMTUx
OTI1MjBaFw0xMjAxMTUxOTI1MjBaMDExDDAKBgNVBAYTA1VTQTEQMA4GA1UECgwH
dGVzdF9jbzEPMA0GA1UEAxMGRW5pZ21hMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQCPxGv0rUzHMnFtkx9uwYuPiWbftmWfa9iDt6ELOEuw3zlboy2qtuRUZohz
FIbCxAJevdCY6a+pktvYy3/2nJL0WATObO5T0FKn3F0bphajinLYbyCrYhEzD9E2
gkiT2D9/ttbSiMvi9usphprEDcLAFaWgCJiHnKPBEkjC0vhA3wIDAQABoxIwEDAO
BgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEEBQADgYEAL/q6xgweylGQylqLCwzN
5PIpjfzsNPf3saTyh3VplwEOW6WTHwRQT17IO/1Oc6Jnz9Mr0ZrbHWDXq+1sx180
F8+DMW1Qv1UR/lGMq3ufDG3qedmSN6txDF8qLlPCUML0YL8m4oGdewqGb+78aPyE
Y/cJRsK1hWbYyseqcIkjj5k=
-----END X509 CERTIFICATE-----
Certificate Slot Name: 2   Key Type: rsa
        (Private key in certlocal slot 2)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

Then, the administrator sends the file in an email to the second administrator.

The second administrator places the file in a secure directory, then imports the certificate from the file.

sys2# cd /
sys2# ikecert certdb -a < /sec/co2sys

The ikecert command imports only the text between the -----BEGIN and -----END lines. The administrator verifies that the local certificate has the same public key hash as the public key hash in the co2sys file.

sys2# ikecert certdb -l
Certificate Slot Name: 1   Key Type: rsa
        (Private key in certlocal slot 1)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

To ensure that the first administrator sent this email, the second administrator telephones the first administrator to verify the Subject Name of the certificate.

Example 22–4 Specifying a Start Time and an End Time for a Certificate

In this example, the administrator on the partym system establishes dates within which the certificate is valid. The certificate is backdated by 2 1/2 days, and is valid for 4 years and 6 months from the date of creation.

# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
-A IP=192.168.13.213 \
-S -2d12h -F +4y6m

The administrator on the enigma system establishes dates within which the certificate is valid. The certificate is backdated by 2 days and is valid until midnight of December 31, 2010.

# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \
-A IP=192.168.116.16 \
-S -2d -F "12/31/2010 12:00 AM"

How to Configure IKE With Certificates Signed by a CA

Public certificates from a Certificate Authority (CA) require negotiation with an outside organization. The certificates very easily scale to protect a large number of communicating systems.

1. On the system console, assume the Primary Administrator role or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

   ---

   Note –

   Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for a secure remote login.

   ---

2. Use the ikecert certlocal -kc command to create a certificate request.

   For a description of the arguments to the command, see Step 2 in How to Configure IKE With Self-Signed Public Key Certificates.

   # ikecert certlocal -kc -m keysize -t keytype \ -D dname -A altname

   1. For example, the following command creates a certificate request on the partym system:

      # ikecert certlocal -kc -m 1024 -t rsa-md5 \ > -D "C=US, O=PartyCompany\, Inc., OU=US-Partym, CN=Partym" \ > -A "DN=C=US, O=PartyCompany\, Inc., OU=US-Partym" Creating software private keys. Writing private key to file /etc/inet/secret/ike.privatekeys/2. Enabling external key providers - done. Certificate Request: Proceeding with the signing operation. Certificate request generated successfully (…/publickeys/0) Finished successfully. -----BEGIN CERTIFICATE REQUEST----- MIIByjCCATMCAQAwUzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGVDb21w … lcM+tw0ThRrfuJX9t/Qa1R/KxRlMA3zckO80mO9X -----END CERTIFICATE REQUEST-----

   2. The following command creates a certificate request on the enigma system:

      # ikecert certlocal -kc -m 1024 -t rsa-md5 \ > -D "C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax, CN=Enigmax" \ > -A "DN=C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax" Creating software private keys. … Finished successfully. -----BEGIN CERTIFICATE REQUEST----- MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu … 8qlqdjaStLGfhDOO -----END CERTIFICATE REQUEST-----

3. Submit the certificate request to a PKI organization.

   The PKI organization can tell you how to submit the certificate request. Most organizations have a web site with a submission form. The form requires proof that the submission is legitimate. Typically, you paste your certificate request into the form. When your request has been checked by the organization, the organization issues you the following two certificate objects and a list of revoked certificates:

   • Your public key certificate – This certificate is based on the request that you submitted to the organization. The request that you submitted is part of this public key certificate. The certificate uniquely identifies you.

   • A Certificate Authority – The organization's signature. The CA verifies that your public key certificate is legitimate.

   • A Certificate Revocation List (CRL) – The latest list of certificates that the organization has revoked. The CRL is not sent separately as a certificate object if access to the CRL is embedded in the public key certificate.

     When a URI for the CRL is embedded in the public key certificate, IKE can automatically retrieve the CRL for you. Similarly, when a DN (directory name on an LDAP server) entry is embedded in the public key certificate, IKE can retrieve and cache the CRL from an LDAP server that you specify.

     See How to Handle a Certificate Revocation List for an example of an embedded URI and an embedded DN entry in a public key certificate.

4. Add each certificate to your system.

   The -a option to the ikecert certdb -a adds the pasted object to the appropriate certificate database on your system. For more information, see IKE With Public Key Certificates.

   1. On the system console, assume the Primary Administrator role or become superuser.

   2. Add the public key certificate that you received from the PKI organization.

      # ikecert certdb -a Press the Return key Paste the certificate: -----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE---- Press the Return key <Control>-D

   3. Add the CA from the PKI organization.

      # ikecert certdb -a Press the Return key Paste the CA: -----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE---- Press the Return key <Control>-D

   4. If the PKI organization has sent a list of revoked certificates, add the CRL to the certrldb database:

      # ikecert certrldb -a Press the Return key Paste the CRL: -----BEGIN CRL----- … -----END CRL---- Press the Return key <Control>-D

5. Use the cert_root keyword to identify the PKI organization in the /etc/inet/ike/config file.

   Use the name that the PKI organization provides.

   1. For example, the ike/config file on the partym system might appear similar to the following:

      # Trusted root cert # This certificate is from Example PKI # This is the X.509 distinguished name for the CA that it issues. cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" ## Parameters that may also show up in rules. p1_xform { auth_method rsa_sig oakley_group 1 auth_alg sha1 encr_alg des } p2_pfs 2 { label "US-partym to JA-enigmax - Example PKI" local_id_type dn local_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" local_addr 192.168.13.213 remote_addr 192.168.116.16 p1_xform {auth_method rsa_sig oakley_group 2 auth_alg md5 encr_alg 3des} }

      ---

      Note –

      All arguments to the auth_method parameter must be on the same line.

      ---

   2. On the enigma system, create a similar file.

      Specifically, the enigma ike/config file should do the following:

      • Include the same cert_root value.

      • Use enigma values for local parameters.

      • Use partym values for remote parameters.

      • Create a unique value for the label keyword. This value must be different from the remote system's label value.

      … cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" … { label "JA-enigmax to US-partym - Example PKI" local_id_type dn local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 …

6. Tell IKE how to handle CRLs.

   Choose the appropriate option:

   • No CRL available

     If the PKI organization does not provide a CRL, add the keyword ignore_crls to the ike/config file.

     # Trusted root cert … cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example,… ignore_crls …

     The ignore_crls keyword tells IKE not to search for CRLs.

   • CRL available

     If the PKI organization provides a central distribution point for CRLs, you can modify the ike/config file to point to that location.

     See How to Handle a Certificate Revocation List for examples.

Example 22–5 Using rsa_encrypt When Configuring IKE

When you use auth_method rsa_encrypt in the ike/config file, you must add the peer's certificate to the publickeys database.

1. Send the certificate to the remote system's administrator.

   You can paste the certificate into an email.

   For example, the partym administrator would send the following email:

   To: admin@ja.enigmaexample.com From: admin@us.partyexample.com Message: -----BEGIN X509 CERTIFICATE----- MII… ----END X509 CERTIFICATE-----

   The enigma administrator would send the following email:

   To: admin@us.partyexample.com From: admin@ja.enigmaexample.com Message: -----BEGIN X509 CERTIFICATE----- MII … -----END X509 CERTIFICATE-----

2. On each system, add the emailed certificate to the local publickeys database.

   # ikecert certdb -a Press the Return key -----BEGIN X509 CERTIFICATE----- MII… -----END X509 CERTIFICATE----- Press the Return key <Control>-D

The authentication method for RSA encryption hides identities in IKE from eavesdroppers. Because the rsa_encrypt method hides the peer's identity, IKE cannot retrieve the peer's certificate. As a result, the rsa_encrypt method requires that the IKE peers know each other's public keys.

Therefore, when you use an auth_method of rsa_encrypt in the /etc/inet/ike/config file, you must add the peer's certificate to the publickeys database. The publickeys database then holds three certificates for each communicating pair of systems:

• Your public key certificate

• The CA certificate

• The peer's public key certificate

Troubleshooting – The IKE payload, which includes the three certificates, can become too large for rsa_encrypt to encrypt. Errors such as “authorization failed” and “malformed payload” can indicate that the rsa_encrypt method cannot encrypt the total payload. Reduce the size of the payload by using a method, such as rsa_sig, that requires only two certificates.

How to Generate and Store Public Key Certificates on Hardware

Generating and storing public key certificates on hardware is similar to generating and storing public key certificates on your system. On hardware, the ikecert certlocal and ikecert certdb commands must identify the hardware. The -T option with the token ID identifies the hardware to the commands.

Before You Begin

• The hardware must be configured.

• The hardware uses the /usr/lib/libpkcs11.so library, unless the pkcs11_path keyword in the /etc/inet/ike/config file points to a different library. The library must be implemented according to the following standard: RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki), that is, a PKCS #11 library.

  See How to Configure IKE to Find the Sun Crypto Accelerator 4000 Board for setup instructions.

1. On the system console, assume the Primary Administrator role or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

   ---

   Note –

   Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for a secure remote login.

   ---

2. Generate a self-signed certificate or a certificate request, and specify the token ID.

   Choose one of the following options:

   ---

   Note –

   The Sun Crypto Accelerator 4000 board supports keys up to 2048 bits for RSA. For DSA, this board supports keys up to 1024 bits.

   ---

   • For a self-signed certificate, use this syntax.

     # ikecert certlocal -ks -m 1024 -t rsa-md5 \ > -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \ > -a -T dca0-accel-stor IP=192.168.116.16 Creating hardware private keys. Enter PIN for PKCS#11 token: Type user:password

     The argument to the -T option is the token ID from the attached Sun Crypto Accelerator 4000 board.

   • For a certificate request, use this syntax.

     # ikecert certlocal -kc -m 1024 -t rsa-md5 \ > -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \ > -a -T dca0-accel-stor IP=192.168.116.16 Creating hardware private keys. Enter PIN for PKCS#11 token: Type user:password

   For a description of the arguments to the ikecert command, see the ikecert(1M) man page.

3. At the prompt for a PIN, type the Sun Crypto Accelerator 4000 user, a colon, and the user's password.

   If the Sun Crypto Accelerator 4000 board has a user ikemgr whose password is rgm4tigt, you would type the following:

   Enter PIN for PKCS#11 token: ikemgr:rgm4tigt

   ---

   Note –

   The PIN response is stored on disk as clear text.

   ---

   After you type the password, the certificate prints out:

   Enter PIN for PKCS#11 token: ikemgr:rgm4tigt -----BEGIN X509 CERTIFICATE----- MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu … oKUDBbZ9O/pLWYGr -----END X509 CERTIFICATE-----

4. Send your certificate for use by the other party.

   Choose one of the following options:

   • Send the self-signed certificate to the remote system.

     You can paste the certificate into an email.

   • Send the certificate request to an organization that handles PKI.

     Follow the instructions of the PKI organization to submit the certificate request. For a more detailed discussion, see Step 3 of How to Configure IKE With Certificates Signed by a CA.

5. On your system, edit the /etc/inet/ike/config file to recognize the certificates.

   Choose one of the following options.

   • Self-signed certificate

     Use the values that the administrator of the remote system provides for the cert_trust, remote_id, and remote_addr parameters. For example, on the enigma system, the ike/config file would appear similar to the following:

     # Explicitly trust the following self-signed certs # Use the Subject Alternate Name to identify the cert cert_trust "192.168.116.16" Local system's certificate Subject Alt Name cert_trust "192.168.13.213" Remote system's certificate Subject Alt name # Solaris 10 1/06 release: default path does not have to be typed in #pkcs11_path "/usr/lib/libpkcs11.so" Hardware connection # Solaris 10 release: use this path #pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so" … { label "JA-enigmax to US-partym" local_id_type dn local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 p1_xform {auth_method rsa_sig oakley_group 2 auth_alg md5 encr_alg 3des} }

   • Certificate request

     Type the name that the PKI organization provides as the value for the cert_root keyword. For example, the ike/config file on the enigma system might appear similar to the following:

     # Trusted root cert # This certificate is from Example PKI # This is the X.509 distinguished name for the CA that it issues. cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" # Solaris 10 1/06 release: default path does not have to be typed in #pkcs11_path "/usr/lib/libpkcs11.so" Hardware connection # Solaris 10 release: use this path #pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so" … { label "JA-enigmax to US-partym - Example PKI" local_id_type dn local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 p1_xform {auth_method rsa_sig oakley_group 2 auth_alg md5 encr_alg 3des} }

6. Place the certificates from the other party in the hardware.

   Respond to the PIN request as you responded in Step 3.

   ---

   Note –

   You must add the public key certificates to the same attached hardware that generated your private key.

   ---

   • Self-signed certificate.

     Add the remote system's self-signed certificate. In this example, the certificate is stored in the file, DCA.ACCEL.STOR.CERT.

     # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT Enter PIN for PKCS#11 token: Type user:password

     If the self-signed certificate used rsa_encrypt as the value for the auth_method parameter, add the peer's certificate to the hardware store.

   • Certificates from a PKI organization.

     Add the certificate that the organization generated from your certificate request, and add the certificate authority (CA).

     # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT Enter PIN for PKCS#11 token: Type user:password

     # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CA.CERT Enter PIN for PKCS#11 token: Type user:password

     To add a certificate revocation list (CRL) from the PKI organization, see How to Handle a Certificate Revocation List.

How to Handle a Certificate Revocation List

A certificate revocation list (CRL) contains outdated or compromised certificates from a Certificate Authority. You have four ways to handle CRLs.

• You must instruct IKE to ignore CRLs if your CA organization does not issue CRLs. This option is shown in Step 6 in How to Configure IKE With Certificates Signed by a CA.

• You can instruct IKE to access the CRLs from a URI (uniform resource indicator) whose address is embedded in the public key certificate from the CA.

• You can instruct IKE to access the CRLs from an LDAP server whose DN (directory name) entry is embedded in the public key certificate from the CA.

• You can provide the CRL as an argument to the ikecert certrldb command. For an example, see Example 22–6.

The following procedure describes how to instruct IKE to use CRLs from a central distribution point.

1. Display the certificate that you received from the CA.

   # ikecert certdb -lv certspec

   -l

   Lists certificates in the IKE certificate database.

   -v

   Lists the certificates in verbose mode. Use this option with care.

   certspec

   Is a pattern that matches a certificate in the IKE certificate database.

   For example, the following certificate was issued by Sun Microsystems. Details have been altered.

   # ikecert certdb -lv example-protect.sun.com Certificate Slot Name: 0 Type: dsa-sha1 (Private key in certlocal slot 0) Subject Name: <O=Sun Microsystems Inc, CN=example-protect.sun.com> Issuer Name: <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc> SerialNumber: 14000D93 Validity: Not Valid Before: 2002 Jul 19th, 21:11:11 GMT Not Valid After: 2005 Jul 18th, 21:11:11 GMT Public Key Info: Public Modulus (n) (2048 bits): C575A…A5 Public Exponent (e) ( 24 bits): 010001 Extensions: Subject Alternative Names: DNS = example-protect.sun.com Key Usage: DigitalSignature KeyEncipherment [CRITICAL] CRL Distribution Points: Full Name: URI = #Ihttp://www.sun.com/pki/pkismica.crl#i DN = <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc> CRL Issuer: Authority Key ID: Key ID: 4F … 6B SubjectKeyID: A5 … FD Certificate Policies Authority Information Access

   Notice the CRL Distribution Points entry. The URI entry indicates that this organization's CRL is available on the web. The DN entry indicates that the CRL is available on an LDAP server. Once accessed by IKE, the CRL is cached for further use.

   To access the CRL, you need to reach a distribution point.

2. Choose one of the following methods to access the CRL from a central distribution point.

   • Use the URI.

     Add the keyword use_http to the host's /etc/inet/ike/config file. For example, the ike/config file would appear similar to the following:

     # Use CRL from organization's URI use_http …

   • Use a web proxy.

     Add the keyword proxy to the ike/config file. The proxy keyword takes a URL as an argument, as in the following:

     # Use own web proxy proxy "http://proxy1:8080"

   • Use an LDAP server.

     Name the LDAP server as an argument to the ldap-list keyword in the host's /etc/inet/ike/config file. Your organization provides the name of the LDAP server. The entry in the ike/config file would appear similar to the following:

     # Use CRL from organization's LDAP ldap-list "ldap1.sun.com:389,ldap2.sun.com" …

   IKE retrieves the CRL and caches the CRL until the certificate expires.

Example 22–6 Pasting a CRL Into the Local certrldb Database

If the PKI organization's CRL is not available from a central distribution point, you can add the CRL manually to the local certrldb database. Follow the PKI organization's instructions for extracting the CRL into a file, then add the CRL to the database with the ikecert certrldb -a command.

# ikecert certrldb -a < Sun.Cert.CRL

Configuring IKE for Mobile Systems (Task Map)

The following table points to procedures to configure IKE to handle systems that log in remotely to a central site.

Configuring IKE for Mobile Systems

When configured properly, home offices and mobile laptops can use IPsec and IKE to communicate with their company's central computers. A blanket IPsec policy that is combined with a public key authentication method enables off-site systems to protect their traffic to a central system.

How to Configure IKE for Off-Site Systems

IPsec and IKE require a unique ID to identify source and destination. For off-site or mobile systems that do not have a unique IP address, you must use another ID type. ID types such as DNS, DN, or email can be used to uniquely identify a system.

Off-site or mobile systems that have unique IP addresses are still best configured with a different ID type. For example, if the systems attempt to connect to a central site from behind a NAT box, their unique addresses are not used. A NAT box assigns an arbitrary IP address, which the central system would not recognize.

Preshared keys also do not work well as an authentication mechanism for mobile systems, because preshared keys require fixed IP addresses. Self-signed certificates, or certificates from a PKI enable mobile systems to communicate with the central site.

1. On the system console of the central system, assume the Primary Administrator role or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

   ---

   Note –

   Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for a secure remote login.

   ---

2. Configure the central system to recognize mobile systems.

   1. Set up the /etc/hosts file.

      The central system does not have to recognize specific addresses for the mobile systems.

      # /etc/hosts on central central 192.xxx.xxx.x

   2. Set up the ipsecinit.conf file.

      The central system needs a policy that allows a wide range of IP addresses. Later, certificates in the IKE policy ensure that the connecting systems are legitimate.

      # /etc/inet/ipsecinit.conf on central # Keep everyone out unless they use this IPsec policy: {} ipsec {encr_algs aes encr_auth_algs md5 sa shared}

   3. Set up the ike.config file.

      DNS identifies the central system. Certificates are used to authenticate the system.

      ## /etc/inet/ike/ike.config on central # Global parameters # # Find CRLs by URI, URL, or LDAP # Use CRL from organization's URI use_http # # Use web proxy proxy "http://somecache.domain:port/" # # Use LDAP server ldap_server "ldap-server1.domain.org,ldap2.domain.org:port" # # List CA-signed certificates cert_root "C=US, O=Domain Org, CN=Domain STATE" # # List self-signed certificates - trust server and enumerated others #cert_trust "DNS=central.domain.org" #cert_trust "DNS=mobile.domain.org" #cert_trust "DN=CN=Domain Org STATE (CLASS), O=Domain Org #cert_trust "email=root@central.domain.org" #cert_trust "email=user1@mobile.domain.org" # # Rule for mobile systems with certificate { label "Mobile systems with certificate" local_id_type DNS # Any mobile system who knows my DNS or IP can find me. local_id "central.domain.org" local_addr 192.xxx.xxx.x # Root certificate ensures trust, # so allow any remote_id and any remote IP address. remote_id "" remote_addr 0.0.0.0/0 p2_pfs 5 p1_xform {auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg md5 } }

3. Log in to each mobile system, and configure the system to find the central system.

   1. Set up the /etc/hosts file.

      The /etc/hosts file does not need an address for the mobile system, but can provide one. The file must contain a public IP address for the central system.

      # /etc/hosts on mobile mobile 10.x.x.xx central 192.xxx.xxx.x

   2. Set up the ipsecinit.conf file.

      The mobile system needs to find the central system by its public IP address. The systems must configure the same IPsec policy.

      # /etc/inet/ipsecinit.conf on mobile # Find central {raddr 192.xxx.xxx.x} ipsec {encr_algs aes encr_auth_algs md5 sa shared}

   3. Set up the ike.config file.

      The identifier cannot be an IP address. The following identifiers are valid for mobile systems:

      • DN=ldap-directory-name

      • DNS=domain-name-server-address

      • email=email-address

      Certificates are used to authenticate the mobile system.

      ## /etc/inet/ike/ike.config on mobile # Global parameters # # Find CRLs by URI, URL, or LDAP # Use CRL from organization's URI use_http # # Use web proxy proxy "http://somecache.domain:port/" # # Use LDAP server ldap_server "ldap-server1.domain.org,ldap2.domain.org:port" # # List CA-signed certificates cert_root "C=US, O=Domain Org, CN=Domain STATE" # # Self-signed certificates - trust me and enumerated others #cert_trust "DNS=mobile.domain.org" #cert_trust "DNS=central.domain.org" #cert_trust "DN=CN=Domain Org STATE (CLASS), O=Domain Org #cert_trust "email=user1@domain.org" #cert_trust "email=root@central.domain.org" # # Rule for off-site systems with root certificate { label "Off-site mobile with certificate" local_id_type DNS # NAT-T can translate local_addr into any public IP address # central knows me by my DNS local_id "mobile.domain.org" local_addr 0.0.0.0/0 # Find central and trust the root certificate remote_id "central.domain.org" remote_addr 192.xxx.xxx.x p2_pfs 5 p1_xform {auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg md5 } }

4. Enable the ike service.

   # svcadm enable svc:/network/ipsec/ike

Example 22–7 Configuring a Central Computer to Accept IPsec Traffic From a Mobile System

IKE can initiate negotiations from behind a NAT box. However, the ideal setup for IKE is without an intervening NAT box. In the following example, root certificates have been issued by a CA. The CA certificates have been placed on the mobile system and the central system. A central system accepts IPsec negotiations from a system behind a NAT box. main1 is the company system that can accept connections from off-site systems. To set up the off-site systems, see Example 22–8.

## /etc/hosts on main1
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on main1
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs md5 sa shared}

## /etc/inet/ike/ike.config on main1
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://cache1.domain.org:8080/"
#
# Use LDAP server
ldap_server   "ldap1.domain.org,ldap2.domain.org:389"
#
# List CA-signed certificate
cert_root "C=US, O=ExamplePKI Inc, OU=PKI-Example, CN=Example PKI"
#
# Rule for off-site systems with root certificate
{
  label "Off-site system with root certificate"
  local_id_type DNS
  local_id "main1.domain.org"
  local_addr 192.168.0.100

# Root certificate ensures trust,
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg md5}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg 3des auth_alg md5}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg 3des auth_alg sha}
}

Example 22–8 Configuring a System Behind a NAT With IPsec

In the following example, root certificates have been issued by a CA and placed on the mobile system and the central system. mobile1 is connecting to the company headquarters from home. The Internet service provider (ISP) network uses a NAT box to enable the ISP to assign mobile1 a private address. The NAT box then translates the private address into a public IP address that is shared with other ISP network nodes. Company headquarters is not behind a NAT. For setting up the computer at company headquarters, see Example 22–7.

## /etc/hosts on mobile1
mobile1 10.1.3.3
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on mobile1
# Find main1
{raddr 192.168.0.100} ipsec {encr_algs aes encr_auth_algs md5 sa shared}

## /etc/inet/ike/ike.config on mobile1
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://cache1.domain.org:8080/"
#
# Use LDAP server
ldap_server   "ldap1.domain.org,ldap2.domain.org:389"
#
# List CA-signed certificate
cert_root "C=US, O=ExamplePKI Inc, OU=PKI-Example, CN=Example PKI"
#
# Rule for off-site systems with root certificate
{
  label "Off-site mobile1 with root certificate"
  local_id_type DNS
  local_id "mobile1.domain.org"
  local_addr 0.0.0.0/0

# Find main1 and trust the root certificate
  remote_id "main1.domain.org"
  remote_addr 192.168.0.100

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg md5 }
}

Example 22–9 Accepting Self-Signed Certificates From a Mobile System

In the following example, self-signed certificates have been issued and are on the mobile and the central system. main1 is the company system that can accept connections from off-site systems. To set up the off-site systems, see Example 22–10.

## /etc/hosts on main1
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on main1
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs md5 sa shared}

## /etc/inet/ike/ike.config on main1
# Global parameters
#
# Self-signed certificates - trust me and enumerated others
cert_trust    "DNS=main1.domain.org"
cert_trust    "jdoe@domain.org"
cert_trust    "user2@domain.org"
cert_trust    "user3@domain.org"
#
# Rule for off-site systems with trusted certificate
{
  label "Off-site systems with trusted certificates"
  local_id_type DNS
  local_id "main1.domain.org"
  local_addr 192.168.0.100

# Trust the self-signed certificates
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg md5 }
}

Example 22–10 Using Self-Signed Certificates to Contact a Central System

In the following example, mobile1 is connecting to the company headquarters from home. The certificates have been issued and placed on the mobile and the central system. The ISP network uses a NAT box to enable the ISP to assign mobile1 a private address. The NAT box then translates the private address into a public IP address that is shared with other ISP network nodes. Company headquarters is not behind a NAT. To set up the computer at company headquarters, see Example 22–9.

## /etc/hosts on mobile1
mobile1 10.1.3.3
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on mobile1
# Find main1
{raddr 192.168.0.100} ipsec {encr_algs aes encr_auth_algs md5 sa shared}

## /etc/inet/ike/ike.config on mobile1
# Global parameters

# Self-signed certificates - trust me and the central system
cert_trust    "jdoe@domain.org"
cert_trust    "DNS=main1.domain.org"
#
# Rule for off-site systems with trusted certificate
{
  label "Off-site mobile1 with trusted certificate"
  local_id_type email
  local_id "jdoe@domain.org"
  local_addr 0.0.0.0/0

# Find main1 and trust the certificate
  remote_id "main1.domain.org"
  remote_addr 192.168.0.100

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg md5 }
}

Configuring IKE to Find Attached Hardware (Task Map)

The following table points to procedures that inform IKE about attached hardware. You must inform IKE about attached hardware before IKE can use the hardware. To use the hardware, follow the hardware procedures in Configuring IKE With Public Key Certificates.

Configuring IKE to Find Attached Hardware

Public key certificates can also be stored on attached hardware, the Sun Crypto Accelerator 1000 board and the Sun Crypto Accelerator 4000 board. With the Sun Crypto Accelerator 4000 board, public key operations can also be offloaded from the system to the board.

How to Configure IKE to Find the Sun Crypto Accelerator 1000 Board

Before You Begin

The following procedure assumes that a Sun Crypto Accelerator 1000 board is attached to the system. The procedure also assumes that the software for the board has been installed and that the software has been configured. For instructions, see the Sun Crypto Accelerator 1000 Board Version 1.1 Installation and User's Guide.

1. On the system console, assume the Primary Administrator role or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

   ---

   Note –

   Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for a secure remote login.

   ---

2. Check that the PKCS #11 library is linked.

   Type the following command to determine whether a PKCS #11 library is linked:

   # ikeadm get stats Phase 1 SA counts: Current: initiator: 0 responder: 0 Total: initiator: 0 responder: 0 Attempted: initiator: 0 responder: 0 Failed: initiator: 0 responder: 0 initiator fails include 0 time-out(s) PKCS#11 library linked in from /usr/lib/libpkcs11.so #

3. Solaris 10 1/06: Starting in this release, you can store keys in the softtoken keystore.

   For information on the keystore that is provided by the Solaris cryptographic framework, see the cryptoadm(1M) man page. For an example of using the keystore, see Example 22–11.

How to Configure IKE to Find the Sun Crypto Accelerator 4000 Board

Before You Begin

The following procedure assumes that a Sun Crypto Accelerator 4000 board is attached to the system. The procedure also assumes that the software for the board has been installed and that the software has been configured. For instructions, see the Sun Crypto Accelerator 4000 Board Installation and User's Guide. The guide is available from the http://www.sun.com/products-n-solutions/hardware/docs web site, under Network and Security Products.

1. On the system console, assume the Primary Administrator role or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

   ---

   Note –

   Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for a secure remote login.

   ---

2. Check that the PKCS #11 library is linked.

   IKE uses the library's routines to handle key generation and key storage on the Sun Crypto Accelerator 4000 board. Type the following command to determine whether a PKCS #11 library has been linked:

   $ ikeadm get stats … PKCS#11 library linked in from /usr/lib/libpkcs11.so $

   ---

   Note –

   The Sun Crypto Accelerator 4000 board supports keys up to 2048 bits for RSA. For DSA, this board supports keys up to 1024 bits.

   ---

3. Find the token ID for the attached Sun Crypto Accelerator 4000 board.

   $ ikecert tokens Available tokens with library "/usr/lib/libpkcs11.so": "Sun Metaslot "

   The library returns a token ID, also called a keystore name, of 32 characters. In this example, you could use the Sun Metaslot token with the ikecert commands to store and accelerate IKE keys.

   For instructions on how to use the token, see How to Generate and Store Public Key Certificates on Hardware.

   The trailing spaces are automatically padded by the ikecert command.

Example 22–11 Finding and Using Metaslot Tokens

Tokens can be stored on disk, on an attached board, or in the softtoken keystore that the Solaris encryption framework provides. The softtoken keystore token ID might resemble the following.

$ ikecert tokens
Available tokens with library "/usr/lib/libpkcs11.so":

"Sun Metaslot                   "

To create a passphrase for the softtoken keystore, see the pktool(1) man page.

A command that resembles the following would add a certificate to the softtoken keystore. Sun.Metaslot.cert is a file that contains the CA certificate.

# ikecert certdb -a -T "Sun Metaslot" < Sun.Metaslot.cert
Enter PIN for PKCS#11 token: Type user:passphrase

Changing IKE Transmission Parameters (Task Map)

The following table points to procedures to configure transmission parameters for IKE.

Changing IKE Transmission Parameters

When IKE negotiates keys, the speed of transmission can affect the success of the negotiation. Normally, you would not need to change the default values for IKE transmission parameters. However, when optimizing key negotiation over very dirty lines, or when reproducing a problem, you might want to change the transmission values.

Longer duration times enable IKE to negotiate keys over unreliable transmission lines. You can lengthen certain parameters so that initial attempts succeed. If the initial attempt does not succeed, you can space subsequent attempts to offer more time for success.

Shorter duration times enable you to take advantage of reliable transmission lines. You can more quickly retry a failed negotiation to speed up the negotiation. When diagnosing a problem, you might also want to speed up the negotiation for a quick failure. Shorter durations also enable the Phase 1 SAs to be used for their lifetime.

How to Change the Duration of Phase 1 IKE Key Negotiation

1. On the system console, assume the Primary Administrator role or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

   ---

   Note –

   Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for a secure remote login.

   ---

2. Change the default values of the global transmission parameters on each system.

   On each system, modify Phase 1 duration parameters the /etc/inet/ike/config file.

   ### ike/config file on system ## Global parameters # ## Phase 1 transform defaults # #expire_timer 300 #retry_limit 5 #retry_timer_init 0.5 (integer or float) #retry_timer_max 30 (integer or float)

   expire_timer

   The number of seconds to let a not-yet-complete IKE Phase I negotiation linger before deleting the negotiation attempt. By default, the attempt lingers for 30 seconds.

   retry_limit

   The number of retransmits before any IKE negotiation is aborted. By default, IKE tries five times.

   retry_timer_init

   The initial interval between retransmits. This interval is doubled until the retry_timer_max value is reached. The initial interval is 0.5 seconds.

   retry_timer_max

   The maximum interval in seconds between retransmits. The retransmit interval stops growing at this limit. By default, the limit is 30 seconds.

3. Refresh the ike service.

   # svcadm refresh svc:/network/ipsec/ike

Example 22–12 Lengthening IKE Phase 1 Negotiation Times

In the following example, a system is connected to its IKE peers by a high-traffic transmission line. The original settings are in comments in the file. The new settings lengthen the negotiation time.

### ike/config file on partym
## Global Parameters
#
## Phase 1 transform defaults
#expire_timer   300
#retry_limit      5
#retry_timer_init 0.5 (integer or float)
#retry_timer_max 30   (integer or float)
#
expire_timer  600
retry_limit  10
retry_timer_init  2.5
retry_timer_max  180

Example 22–13 Shortening IKE Phase 1 Negotiation Times

In the following example, a system is connected to its IKE peers by a high-speed line with little traffic. The original settings are in comments in the file. The new settings shorten the negotiation time.

### ike/config file on partym
## Global Parameters
#
## Phase 1 transform defaults
#expire_timer   300
#retry_limit      5
#retry_timer_init 0.5 (integer or float)
#retry_timer_max 30   (integer or float)
#
expire_timer  120
retry_timer_init  0.20