Internet Key Exchange (IKE) is responsible for which two functions? (Choose two)

Internet Key Exchange (IKE) negotiates the IPSec security associations (SAs). This process requires that the IPSec systems first authenticate themselves to each other and establish ISAKMP (IKE) shared keys.

NOTE

A security association (SA) is a relationship between two or more entities that describes how the entities will use security services to communicate securely.

In phase 1 of this process, IKE creates an authenticated, secure channel between the two IKE peers, called the IKE security association. The Diffie-Hellman key agreement is always performed in this phase.

In phase 2, IKE negotiates the IPSec security associations and generates the required key material for IPSec. The sender offers one or more transform sets that are used to specify an allowed combination of transforms with their respective settings. The sender also indicates the data flow to which the transform set is to be applied. The sender must offer at least one transform set. The receiver then sends back a single transform set, which indicates the mutually agreed-upon transforms and algorithms for this particular IPSec session. A new Diffie-Hellman agreement may be done in phase 2, or the keys may be derived from the phase 1 shared secret.

Figure 1 shows the role that IKE takes in the IPSec VPN creation process.

Figure 1 The function of IKE.

IKE authenticates the peer and the IKE messages between the peers during IKE phase 1. Phase 1 consists of main mode or aggressive mode. (These modes are described later in this article.) Potential peers in an IPSec session must authenticate themselves to each other before IKE can proceed. Peer authentication occurs during the main mode exchange during IKE phase 1. The IKE protocol is very flexible and supports multiple authentication methods as part of the phase 1 exchange. The two entities must agree on a common authentication protocol through a negotiation process.

IKE phase 1 has three methods to authenticate IPSec peers in Cisco products:

• Pre-shared keys. A key value entered into each peer manually (out of band) and used to authenticate the peer.

• RSA signatures. Uses a digital certificate authenticated by an RSA signature.

• RSA encrypted nonces. Uses RSA encryption to encrypt a nonce value (a random number generated by the peer) and other values.

A common value used by all authentication methods is the peer identity (ID), which helps identify the peer. Some ID values used are as follows:

• IP address of the peer (four octets), such as 172.30.2.2.

• Fully qualified domain name (FQDN), such as .

2. Pre-Shared Keys | Next Section

IPsec and IKE Administration Guide

The management of keying material that IPsec 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 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 packets can take advantage of IKE.

When IKE is used on a system with a SunTM Crypto Accelerator 1000 card, the public key operations are off-loaded to the card. Operating system resources are not used for public-key operations.

This chapter contains the following information:

IKE Overview

The Internet Key Exchange (IKE) daemon, in.iked(1M), negotiates and authenticates keying material for security associations in a protected manner. The daemon uses random seeds for keys from internal functions provided by the SunOSTM. 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.

When the IKE daemon discovers a remote host's public encryption key, the local system can then use that key. The system encrypts messages by using the remote host's public key. The messages can be read only by that remote host. 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. An ISAKMP security association is a secure channel for IKE to negotiate keying material for the IP datagrams. Unlike IPsec SAs, the ISAKMP security associations 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 interfaces that are affected, the algorithms that are used, the authentication method, and if PFS is used. The two authentication methods are pre-shared 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 SunTM Open Net Environment (Sun ONE) Certificate Server, Entrust, 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 hosts that are running the IKE daemon. IKE uses the secure channel that was created in Phase 1 to protect the transmission of keying material. The IKE daemon creates the keys from a random number generator by using the /dev/random. 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.

IKE Configuration Choices

For two IKE daemons to authenticate each other, the configuration file for IKE policy, ike.config(4), must be valid. Also, keying material must be available. The configuration file contains IKE policy entries. The entries determine the method for authenticating the Phase 1 exchange. The choices are pre-shared keys or public key certificates.

The key pair auth_method preshared indicates that pre-shared keys are used. Values for auth_method other than preshared are one indication 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.

Using Pre-Shared Keys

Pre-shared keys are created by an administrator on one system, and shared out of band with administrators of communicating systems. The administrator 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(4) file is for IKE as the ipseckeys file is for IPsec. Compromise of the keys in the ike.preshared file compromises all keys that are derived from the keys in the file.

One system's pre-shared key must be identical to its communicating system's key. The keys are tied to a particular IP address, and are most secure when one administrator controls the communicating systems.

Using 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 method of 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 communicating system. The communicating 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 hosts.

Self-signed certificates are a halfway point between pre-shared keys and CAs. Unlike pre-shared keys, a self-signed certificate can be used on a mobile machine, or a system that might be renumbered. To self-sign a certificate, the administrator uses a DNS (www.example.org) or EMAIL () alternative name.

Public keys can be delivered by a PKI or a CA organization. The public keys and their accompanying CAs are installed in the /etc/inet/ike/publickeys directory by the administrator. Vendors also issue certificate revocation lists (CRLs). Along with installing the keys and CAs, the administrator is 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. Like self-signed certificates, CAs can be used on a mobile machine, or on a system that might be renumbered. Unlike self-signed certificates, CAs very easily scale to protecting 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 card to handle the public key operations. For information on how to configure IKE to offload its computations to the accelerator card, see How to Use the Sun Crypto Accelerator 1000 Card With IKE.

IKE Utilities and Files

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

IKE Daemon

The in.iked(1M) daemon automates the management of cryptographic keys for IPsec on a Solaris host. The daemon negotiates with a remote host 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 hosts that plan to communicate securely.

The IKE daemon is automatically loaded at boot time if the configuration file for 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 Phase 1. The peer is defined in the IKE policy file, as are the authentication methods. The daemon then establishes the keys for the session in Phase 2. 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 programs support the IKE daemon. The ikeadm(1M) command enables the administrator to view IKE policy. You can also use the command to modify IKE policy. The ikecert(1M) command enables the administrator to view and manage the public-key databases, ike.privatekeys and publickeys.

IKE Policy File

The configuration file for IKE policy, /etc/inet/ike/config, provides the keying material 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 hosts or networks that the keying material is for, and specifies the authentication method. See IKE Tasks for examples of valid policy files. See the ike.config(4) man page for examples and descriptions of its parameters.

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

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

• Debug IKE processes

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

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

At the modkeys level of privilege, you can remove, change, and add pre-shared keys.

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.

Pre-Shared Keys Files

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

• The ike.preshared file is created by an administrator when the ike/config file requires pre-shared keys. The ike.preshared file contains keying material for ISAKMP SAs, that is, for IKE authentication. Because the pre-shared 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. For IPv6 hosts, you manually create and update the keys in this file. See IPsec Tasks 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.

IKE Public Key Databases and Commands

The ikecert(1M) command manipulates the local host's public-key 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.

ikecert certlocal Command

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

When you create a private key, the certlocal subcommand relies on values in the ike/config file. The correspondences between certlocal 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. If your company runs its own PKI, you send the output to your PKI administrator. The organization or your PKI administrator then creates keying material. You use the keying material that is returned to you as input to the certdb and certrldb subcommands.

ikecert certdb Command

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

ikecert certrldb Command

The certrldb subcommand manages the certificate revocation list (CRL) database, /etc/inet/ike/crls. The crls database maintains the revocation lists for public keys. Certificates that are no longer valid are on this list. When PKIs provide you with CRLs, you install the CRLs in the CRL database with the ikecert certrldb command. See How to Access 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. You use the ikecert certdb command to populate the directory.

The files contain, in encoded form, the X.509 distinguished name of a certificate that was generated on another system. If you are using self-signed certificates, you use the certificate that you receive from the administrator of the communicating system as input to the command. If you are using certificates from a PKI, you install two pieces of keying material from the 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 ike.privatekeys directory holds private key files that are part of a public-private key pair, keying material for ISAKMP SAs. The directory is protected at 0700. The private key in this database must have a public key counterpart in the publickeys database.The ikecert certlocal command populates this directory. Private keys are not effective until their public key counterparts, self-signed certificates or CAs, are installed in the /etc/inet/ike/publickeys directory.

/etc/inet/ike/crls Directory

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

• © 2010, Oracle Corporation and/or its affiliates