System Administration Guide: IP Services

Chapter 21 Internet Key Exchange (Overview)

Internet Key Exchange (IKE) automates key management for IPsec. This chapter contains the following information about IKE:

For instructions on implementing IKE, see Chapter 22, Configuring IKE (Tasks). For reference information, see Chapter 23, Internet Key Exchange (Reference). For information about IPsec, see Chapter 18, IP Security Architecture (Overview).

What's New in IKE?

Solaris Express Community Edition: Starting in this release, the Service Management Facility (SMF) manages IKE as a service. By default, the svc:/network/ipsec/ike:default service is disabled. Also in this release, the Network IPsec Management rights profile is provided for administering IPsec and IKE.

Solaris Express, Developer Edition 1/08: Starting in this release, IKE can use the AES algorithm and can be configured in the global zone for use in non-global zones.

The SO_ALLZONES socket option enables IKE to handle traffic in non-global zones.
For a complete listing of new Solaris features and a description of Solaris releases, see Solaris Express Developer Edition What’s New.

Key Management With IKE

The management of keying material for IPsec security associations (SAs) is called key management. Automatic key management requires a secure channel of communication for the creation, authentication, and exchange of keys. The Solaris Operating System 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 can be offloaded to the accelerator. Operating system resources are not used for public key 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 that is off the system provides an additional layer of protection.

IKE Key Negotiation

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 System. 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.

IKE Key Terminology

The following table lists terms that are used in key negotiation, provides their commonly used acronyms, and gives a definition and use for each term.

Table 21–1 Key Negotiation Terms, Acronyms, and Uses


Key Negotiation Term	Acronym	Definition and Use
Key exchange		The process of generating keys for asymmetric cryptographic algorithms. The two main methods are RSA protocols and the Diffie-Hellman protocol.
Diffie-Hellman protocol	DH	A key exchange protocol that involves key generation and key authentication. Often called authenticated key exchange.
RSA protocol	RSA	A key exchange protocol that involves key generation and key transport. The protocol is named for its three creators, Rivest, Shamir, and Adleman.
Perfect forward secrecy	PFS	Applies to authenticated key exchange only. PFS ensures that long-term secret material for keys does not compromise the secrecy of the exchanged keys from previous communications. In PFS, the key that is used to protect transmission of data is not used to derive additional keys. Also, the source of the key that is used to protect data transmission is never used to derive additional keys.
Oakley method		A method for establishing keys for Phase 2 in a secure manner. This protocol is analogous to the Diffie-Hellman method of key exchange. Similar to Diffie-Hellman, Oakley group key exchange involves key generation and key authentication. The Oakley method is used to negotiate PFS.

IKE 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 Internet Security Association and Key Management Protocol (ISAKMP) 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
Whether perfect forward secrecy (PFS) is used
The interfaces that are affected
The security protocols and their algorithms
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 public key infrastructure (PKI) organization. Organizations include beTrusted, Entrust, GeoTrust, RSA Security, and Verisign.

IKE 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 entries 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. For more information, see the ike.config(4) man page.

IKE With Preshared Keys

Preshared keys are created by an administrator on one system. The keys are then 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. Keys are most secure when one administrator controls the communicating systems. For more information, 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 (DH) 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 you, the administrator. The ikecert certlocal -ks command creates the private part of the public-private key pair for the system. You then get 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 CRL in the /etc/inet/ike/crls directory.

CAs have the advantage of being certified by an outside organization, rather than by the site administrator. 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 offload its computations to the accelerator board, see How to Configure IKE to Find the Sun Crypto Accelerator 1000 Board. For information on how to store keys, see How to Configure IKE to Find the Sun Crypto Accelerator 4000 Board, and the cryptoadm(1M) man page.

IKE and Hardware Storage

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

For information on how to configure IKE to access the board, see How to Configure IKE to Find the Sun Crypto Accelerator 1000 Board. 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

The following table summarizes the configuration files for IKE policy, the storage locations for IKE keys, and the various commands and services that implement IKE. For more about services, see Chapter 16, Managing Services (Overview), in System Administration Guide: Basic Administration.

Table 21–2 IKE Configuration Files, Key Storage Locations, Commands, and Services


File, Location, Command, or Service	Description	For More Information
`svc:/network/ipsec/ike`	The SMF service that manages IKE.	smf(5)
`/usr/lib/inet/in.iked` daemon	Internet Key Exchange (IKE) daemon. Activates automated key management when the `ike` service is enabled.	in.iked(1M)
`/usr/sbin/ikeadm` command	IKE administration command for viewing and modifying the IKE policy.	ikeadm(1M)
`/usr/sbin/ikecert` command	Certificate database management command for manipulating local databases that hold public key certificates. The databases can also be stored on an attached Sun Crypto Accelerator 4000 board.	ikecert(1M)
`/etc/inet/ike/config` file	Default configuration file for the IKE policy in the `/etc/inet` directory. Contains the site's rules for matching inbound IKE requests and preparing outbound IKE requests. If this file exists, the `in.iked` daemon starts when the `ike` service is enabled. The location of this file can be changed by the `svccfg` command.	ike.config(4)
`ike.preshared` file	Preshared keys file in the `/etc/inet/secret` directory. Contains secret keying material for authentication in the Phase 1 exchange. Used when configuring IKE with preshared keys.	ike.preshared(4)
`ike.privatekeys` directory	Private keys directory in the `/etc/inet/secret` directory. Contains the private keys that are part of a public-private key pair.	ikecert(1M)
`publickeys` directory	Directory in the `/etc/inet/ike` directory that holds public keys and certificate files. Contains the public key part of a public-private key pair.	ikecert(1M)
`crls` directory	Directory in the `/etc/inet/ike` directory that holds revocation lists for public keys and certificate files.	ikecert(1M)
Sun Crypto Accelerator 1000 board	Hardware that accelerates public key operations by offloading the operations from the operating system.	ikecert(1M)
Sun Crypto Accelerator 4000 board	Hardware that accelerates public key operations by offloading the operations from the operating system. The board also stores public keys, private keys, and public key certificates.	ikecert(1M)

Changes to IKE for the Solaris 10 Release

Since the Solaris 9 release, IKE includes the following functionality:

IKE can be used to automate key exchange for IPsec over IPv6 networks. For more information, see Key Management With IKE.

Note –
IKE cannot be used to manage keys for IPsec in a non-global zone.
Public key operations in IKE can be accelerated by a Sun Crypto Accelerator 1000 board or a Sun Crypto Accelerator 4000 board. The operations are offloaded to the board. The offloading accelerates encryption, thereby reducing demands on operating system resources. For more information, see IKE and Hardware Acceleration. For procedures, see Configuring IKE to Find Attached Hardware (Task Map).
Public key certificates, private keys, and public keys can be stored on a Sun Crypto Accelerator 4000 board. For more information on key storage, see IKE and Hardware Storage.
IKE can be used to automate key exchange for IPsec from behind a NAT box. The traffic must use an IPv4 network. Also, the NAT-traversing IPsec ESP keys cannot be accelerated by hardware. For more information, see IPsec and NAT Traversal. For procedures, see Configuring IKE for Mobile Systems (Task Map).
Retransmission parameters and packet time out parameters have been added to the /etc/inet/ike/config file. These parameters tune the IKE Phase 1 (Main Mode) negotiation to handle network interference, heavy network traffic, and interoperation with platforms that have different implementations of the IKE protocol. For details about the parameters, see the ike.config(4) man page. For procedures, see Changing IKE Transmission Parameters (Task Map).