Chapter 3 Internet Key Exchange (Overview)

The management of keying material that IPsec security associations (SAs) require for secure transmission of IP datagrams is called key management. Automatic key management requires a secure channel of communication for the creation, authentication, and exchange of keys. The Solaris operating environment uses Internet Key Exchange (IKE) to automate key management. IKE easily scales to provide a secure channel for a large volume of traffic. IPsec SAs on IPv4 and IPv6 packets can take advantage of IKE.

When IKE is used on a system with a Sun^TM Crypto Accelerator 1000 board or a Sun Crypto Accelerator 4000 board, the public key operations are off-loaded to the accelerator. Operating system resources are not used for publickey operations. When IKE is used on a system with a Sun Crypto Accelerator 4000 board, the certificates, public keys, and private keys can be stored on the board. Key storage off the system provides an additional layer of protection.

This chapter contains the following information:

• IKE Overview

• IKE Configuration Choices

• IKE and Hardware Acceleration

• IKE and Hardware Storage

• IKE Utilities and Files

For instructions on implementing IKE, see Chapter 4, Administering IKE (Tasks).

IKE Overview

The IKE daemon, in.iked, negotiates and authenticates keying material for SAs in a protected manner. The daemon uses random seeds for keys from internal functions provided by the Solaris operating environment. IKE provides perfect forward secrecy (PFS). In PFS, the keys that protect data transmission are not used to derive additional keys. Also, seeds used to create data transmission keys are not reused. See the in.iked(1M) man page.

When the IKE daemon discovers a remote system's public encryption key, the local system can then use that key. The system encrypts messages by using the remote system's public key. The messages can be read only by that remote system. The IKE daemon performs its job in two phases. The phases are called exchanges.

Phase 1 Exchange

The Phase 1 exchange is known as Main Mode. In the Phase 1 exchange, IKE uses public key encryption methods to authenticate itself with peer IKE entities. The result is an ISAKMP (Internet Security Association and Key Management Protocol) security association (SA). An ISAKMP SA is a secure channel for IKE to negotiate keying material for the IP datagrams. Unlike IPsec SAs, the ISAKMP SAs are bidirectional, so only one security association is needed.

How IKE negotiates keying material in the Phase 1 exchange is configurable. IKE reads the configuration information from the /etc/inet/ike/config file. Configuration information includes the following:

• Global parameters, such as the names of public key certificates

• If perfect forward secrecy (PFS) is used

• The interfaces that are affected

• The algorithms that are used

• The authentication method

The two authentication methods are preshared keys and public key certificates. The public key certificates can be self-signed, or the certificates can be issued by a certificate authority (CA) from a PKI (public key infrastructure) organization. Organizations include Baltimore Technologies, Entrust, GeoTrust, RSA Security, Sun Open Net Environment (Sun ONE) Certificate Server, and Verisign.

Phase 2 Exchange

The Phase 2 exchange is known as Quick Mode. In the Phase 2 exchange, IKE creates and manages the IPsec SAs between systems that are running the IKE daemon. IKE uses the secure channel that was created in the Phase 1 exchange to protect the transmission of keying material. The IKE daemon creates the keys from a random number generator by using the /dev/random device. The daemon refreshes the keys at a configurable rate. The keying material is available to algorithms that are specified in the configuration file for IPsec policy, ipsecinit.conf.

IKE Configuration Choices

The /etc/inet/ike/config configuration file contains IKE policy entries. For two IKE daemons to authenticate each other, the configuration file must be valid. Also, keying material must be available. The entries in the configuration file determine the method for using the keying material to authenticate the Phase 1 exchange. The choices are preshared keys or public key certificates.

The entry auth_method preshared indicates that preshared keys are used. Values for auth_method other than preshared indicate that public key certificates are to be used. Public key certificates can be self-signed, or the certificates can be installed from a PKI organization. See the ike.config(4) man page.

IKE With Preshared Keys

Preshared keys are created by an administrator on one system, and are shared out of band with administrators of remote systems. You should take care to create large random keys and to protect the file and the out-of-band transmission. The keys are placed in the /etc/inet/secret/ike.preshared file on each system. The ike.preshared file is for IKE as the ipseckeys file is for IPsec. Any compromise of the keys in the ike.preshared file compromises all keys that are derived from the keys in the file.

One system's preshared key must be identical to its remote system's key. The keys are tied to a particular IP address. They are most secure when one administrator controls the communicating systems. See the ike.preshared(4) man page.

IKE With Public Key Certificates

Public key certificates eliminate the need for communicating systems to share secret keying material out of band. Public keys use the Diffie-Hellman protocol for authenticating and negotiating keys. Public key certificates come in two flavors. The certificates can be self-signed, or the certificates can be certified by a certificate authority (CA).

Self-signed public key certificates are created by an administrator. The ikecert certlocal -ks command creates the private part of the public-private key pair for the system. The administrator then gets the self-signed certificate output in X.509 format from the remote system. The remote system's certificate is input to the ikecert certdb command for the public part of the key pair. The self-signed certificates reside in the /etc/inet/ike/publickeys directory on the communicating systems. When you use the -T option, the certificates reside on attached hardware.

Self-signed certificates are a halfway point between preshared keys and CAs. Unlike preshared keys, a self-signed certificate can be used on a mobile machine, or on a system that might be renumbered. To self-sign a certificate for a system without a fixed number, use a DNS (www.example.org) or EMAIL (root@domain.org) alternative name.

Public keys can be delivered by a PKI or a CA organization. You install the public keys and their accompanying CAs in the /etc/inet/ike/publickeys directory. When you use the -T option, the certificates reside on attached hardware. Vendors also issue certificate revocation lists (CRLs). Along with installing the keys and CAs, you are responsible for installing the CRLs in the /etc/inet/ike/crls directory.

CAs have the advantage of being certified by an outside organization, rather than by the administrator of the site. In a sense, CAs are notarized certificates. As with self-signed certificates, CAs can be used on a mobile machine, or on a system that might be renumbered. Unlike self-signed certificates, CAs can very easily scale to protect a large number of communicating systems.

IKE and Hardware Acceleration

IKE algorithms are computationally expensive, particularly in the Phase 1 exchange. Systems that handle a large number of exchanges can use a Sun Crypto Accelerator 1000 board to handle the public key operations. The Sun Crypto Accelerator 4000 board can also be used to handle expensive Phase 1 computations.

For information on how to configure IKE to off-load its computations to the accelerator board, see How to Use the Sun Crypto Accelerator 1000 Board With IKE. For information on how to store keys, see How to Use the Sun Crypto Accelerator 4000 Board With IKE.

IKE and Hardware Storage

Public key certificates, private keys, and public keys can be stored on a Sun Crypto Accelerator 4000 board. For RSA, the board supports keys up to 2048 bits. For DSA, the board supports keys up to 1024 bits.

For information on how to configure IKE to access the board, see How to Use the Sun Crypto Accelerator 1000 Board With IKE. For information on how to add certificates and public keys to the board, see How to Generate and Store Public Key Certificates on Hardware.

IKE Utilities and Files

This section describes the configuration files for IKE policy, and the various commands that implement IKE. For instructions about how to implement IKE for your network, see Configuring IKE (Task Map).

IKE Daemon

The in.iked daemon automates the management of cryptographic keys for IPsec on a Solaris system. The daemon negotiates with a remote system that is running the same protocol to provide authenticated keying materials for security associations in a protected manner. The daemon must be running on all systems that plan to communicate securely.

The IKE daemon is automatically loaded at boot time if the configuration file for the IKE policy, /etc/inet/ike/config, exists. The daemon checks the syntax of the configuration file.

When the IKE daemon runs, the system authenticates itself to its peer IKE entity in the Phase 1 exchange. The peer is defined in the IKE policy file, as are the authentication methods. The daemon then establishes the keys for the Phase 2 exchange. At an interval specified in the policy file, the IKE keys are refreshed automatically. The in.iked daemon listens for incoming IKE requests from the network and for requests for outbound traffic through the PF_KEY socket. See the pf_key(7P) man page for more information.

Two commands support the IKE daemon. The ikeadm command enables you to view and modify the IKE policy. The ikecert command enables you to view and manage the publickey databases. This command manages the local databases, ike.privatekeys and publickeys. This command also manages public key operations and the storage of public keys on hardware.

IKE Policy File

The configuration file for the IKE policy, /etc/inet/ike/config, provides the keying rules and global parameters for the IKE daemon itself, and for the IPsec SAs that the file manages. The IKE daemon itself requires keying material in the Phase 1 exchange. Rules in the ike/config file establish the keying material. A valid rule in the policy file contains a label. The rule identifies the systems or networks that the keying material secures, and specifies the authentication method. See Configuring IKE With Preshared Keys (Task Map) for examples of valid policy files. For examples and descriptions of its entries, see the ike.config(4) man page.

The IPsec SAs are used on the IP datagrams that are protected according to policies that are set up in the configuration file for the IPsec policy, /etc/inet/ipsecinit.conf. The IKE policy file determines if PFS is used when creating the IPsec SAs.

The ike/config file can include the path to a library that is implemented according to the following standard: RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki). IKE uses this PKCS #11 library to access hardware for key acceleration and key storage.

The security considerations for the ike/config file are similar to the considerations for the ipsecinit.conf file. See Security Considerations for ipsecinit.conf and ipsecconf for details.

IKE Administration Command

You can use the ikeadm command to do the following:

• View aspects of the IKE daemon process

• Change the parameters that are passed to the IKE daemon

• Display statistics on SA creation during the Phase 1 exchange

• Debug IKE processes

See the ikeadm(1M) man page for examples and a full description of this command's options. The privilege level of the running IKE daemon determines which aspects of the IKE daemon can be viewed and modified. You can choose from three levels of privilege.

0x0, or base level

At the base level of privilege, you cannot view or modify keying material. The base level is the default level at which the in.iked daemon runs.

0x1, or modkeys level

At the modkeys level of privilege, you can remove, change, and add preshared keys.

0x2, or keymat level

At the keymat level of privilege, you can view the actual keying material with the ikeadm command.

The security considerations for the ikeadm command are similar to the considerations for the ipseckey command. See Security Considerations for ipseckey for details.

Preshared Keys Files

The /etc/inet/secret directory contains the preshared keys for ISAKMP SAs and IPsec SAs. When you create preshared keys manually, the ike.preshared file contains the preshared keys for ISAKMP SAs, and the ipseckeys file contains the preshared keys for IPsec SAs. The secret directory is protected at 0700. The files in the secret directory are protected at 0600.

• You create an ike.preshared file when you configure the ike/config file to require preshared keys. You enter keying material for ISAKMP SAs, that is, for IKE authentication, in the ike.preshared file. Because the preshared keys are used to authenticate the Phase 1 exchange, the file must be valid before the in.iked daemon starts.

• The ipseckeys file contains keying material for IPsec SAs. See How to Manually Create IPsec Security Associations for examples of manually managing the file. The IKE daemon does not use this file. The keying material that IKE generates for IPsec SAs is stored in the kernel.

Preshared keys cannot take advantage of hardware storage. Preshared keys are generated and stored on the system.

IKE Public Key Databases and Commands

The ikecert command manipulates the local system's publickey databases. You use this command when the ike/config file requires public key certificates. Because IKE uses these databases to authenticate the Phase 1 exchange, the databases must be populated before activating the in.iked daemon. Three subcommands handle each of the three databases: certlocal, certdb, and certrldb.

The ikecert command also handles key storage on the Sun Crypto Accelerator 4000 board. The tokens argument to the ikecert command lists the token IDs that are available on the board. The command finds the board through the PKCS #11 library that is specified in the /etc/inet/ike/config file. The PKCS #11 entry must be present. Otherwise, the -T option to the ikecert commands cannot work. The entry appears similar to the following:

pkcs11_path "/opt/SUNWconn/lib/libpkcs11.so"

For more information, see the ikecert(1M) man page.

ikecert tokens Command

The tokens argument lists the token IDs that are available on the Sun Crypto Accelerator 4000 board. Token IDs enable the ikecert certlocal and ikecert certdb commands to generate public key certificates and certificate requests on the board.

ikecert certlocal Command

The certlocal subcommand manages the private-key database. Options to this subcommand enable you to add, view, and remove private keys. This subcommand also creates either a self-signed certificate or a certificate request. The -ks option creates a self-signed certificate. The -kc option creates a certificate request. Keys are stored on the system in the /etc/inet/secret/ike.privatekeys directory, or on attached hardware with the -T option..

When you create a private key, the ikecert command relies on entries in the ike/config file. The correspondences between ikecert options and ike/config entries are shown in the following table.

If you issue a certificate request with the ikecert certlocal –kc command, you send the output of the command to a PKI organization or a certificate authority (CA). If your company runs its own PKI, you send the output to your PKI administrator. The PKI organization, the CA, or your PKI administrator then creates certificates. The certificates that the PKI or CA returns to you are input to the certdb subcommand. The CRL that the PKI returns to you is input for the certrldb subcommand.

ikecert certdb Command

The certdb subcommand manages the publickey database. Options to the subcommand enable you to add, view, and remove certificates and public keys. The command accepts, as input, certificates that were generated by the ikecert certlocal –ks command on a remote system. See How to Configure IKE With Self-Signed Public Key Certificates for the procedure. This command also accepts the certificate that you receive from a PKI or CA as input. See How to Configure IKE With Certificates Signed by a CA for the procedure.

On the system, the certificates and public keys are stored in the /etc/inet/ike/publickeys directory. The -T option stores the certificates, private keys, and public keys on attached hardware.

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 the CRLs in the CRL database with the ikecert certrldb command. See How to Handle 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 ikecert certdb command populates the directory. The -T option stores the keys on the Sun Crypto Accelerator 4000 board rather than in the publickeys directory.

The slots 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 remote system as input to the command. If you are using certificates from a PKI, you install two pieces of keying material from the PKI into this database. You install a certificate that is based on material that you sent to the PKI. You also install a CA from the PKI.

/etc/inet/secret/ike.privatekeys Directory

The /etc/inet/secret/ike.privatekeys directory holds private key files that are part of a public-private key pair, which is keying material for ISAKMP SAs. The directory is protected at 0700. The ikecert certlocal command populates the ike.privatekeys directory. Private keys are not effective until their public key counterparts, self-signed certificates or CAs, are installed. The public key counterparts are stored in the /etc/inet/ike/publickeys directory or on a Sun Crypto Accelerator 4000 board.

/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 organizations provide the CRLs for their certificates. You use the ikecert certrldb command to populate the database.