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.

   ---

2. Check that the 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: 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 23-9.

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.

   ---

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 to 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 23-9   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.

   ---

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. Reboot the system.

   Or, stop and start the in.iked daemon.

Example 23-10   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 23-11   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