Internet Key Exchange
Managing the 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 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 packets can take advantage of IKE.
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 SunOS™. IKE provides Perfect Forward Secrecy (PFS), that is, the keys that protect data transmission are not used to derive additional keys, and 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 encrypt messages destined for the remote host whose public key it has discovered. The IKE daemon performs its job in two phases 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, which 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 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 they can be issued by a Certificate Authority (CA) from a PKI (Public Key Infrastructure) vendor. Vendors include iPlanet™ Certificate Management System, 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 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 (/dev/random), refreshes them at a configurable rate, and provides the keying material to algorithms specified in the IPsec policy configuration file.
Negotiating IKE
For two IKE daemons to authenticate each other requires a valid IKE configuration policy file, ike.config(4), and keying material. The policy file contains IKE policy entries that determine whether pre-shared keys or public key certificates are to be used to authenticate the Phase 1 exchange.
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 they can be installed from a PKI vendor.
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 derived from them.
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-Helman method of authenticating and negotiating keys. Public key certificates come in two flavors, self-signed, and certified by a Certificate Authority (CA).
Self-signed public key certificates are created by an administrator. The ikecert local -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 machine that may be renumbered. To do this, the administrator uses a DNS (www.example.org) or EMAIL (root@domain.org) alternative name.
Public keys can be delivered by a PKI or a CA vendor. 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 vendor, rather than by the administrator of the site. In a sense, CAs are notarized certificates. Like self-signed certificates, they can be used on a mobile machine, or one that may be renumbered. Unlike self-signed certificates, they very easily scale to protecting a large number of communicating systems.
IKE Utilities and Files
This section describes the IKE configuration files and various commands that implement IKE. For instructions about how to implement IKE for your IPv4 network, see "Implementing IKE Task Map".
Table 21-1 List of IKE Files and Commands
File or Command | Description |
|---|---|
in.iked(1M) daemon | Internet Key Exchange (IKE) daemon. Activates automated key management. |
ikeadm(1M) | IKE administration command. For viewing and modifying IKE policy. |
ikecert(1M) | Certificate database management command. For manipulating local public-key certificate databases. |
/etc/inet/ike/config file | IKE policy configuration file. Contains the site's rules for matching inbound IKE requests and preparing outbound IKE requests. If this file exists, the in.iked daemon starts automatically at boot time. |
/etc/inet/secret/ike.preshared file | Pre-shared keys file. Contains secret keying material for Phase 1 authentication. |
/etc/inet/secret/ike.privatekeys file | Private keys directory. Contains the private keys that are part of a public-private key pair. |
/etc/inet/ike/publickeys directory | Directory to hold public keys and certificate files. By default, includes Sun certificates. Contains the public key part of a public-private key pair. |
/etc/inet/ike/crls directory | Directory to hold revocation lists for public keys and certificate files. |
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 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 IKE configuration policy file /etc/inet/ike/config exists.
When the IKE daemon runs, the system authenticates itself to its peer IKE entity (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 (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 via 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 and modify it. The ikecert(1M) command enables the administrator to view and manage the public-key databases, ike.privatekeys and publickeys.
IKE Policy File
The IKE configuration policy file, /etc/inet/ike/config, provides the keying material for the IKE daemon itself, and for the IPsec SAs that it 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, 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 set up in the IPsec configuration policy file, /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 those for the ipsecinit.conf file. See "Security Considerations" for details.
IKE Administration Command
The ikeadm command can check the syntax of the IKE configuration file, view aspects of the IKE daemon process, and change the parameters passed to the IKE daemon. The command can also gather statistics and 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 modified. There are 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 pre-shared 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 those for the ipseckey command. See "Security Considerations" 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 the administrator creates these keys manually. The secret directory is protected at 0700 and its files are protected at 0600.
The ike.preshared file is created by an administrator when the ike.config file requires pre-shared keys. The file contains keying material for ISAKMP SAs, that is, for IKE authentication. Because IKE uses the pre-shared keys to authenticate the Phase 1 exchange, the ike.preshared file must be valid before the in.iked daemon starts.
The ipseckeys file contains keying material for IPsec SAs. For IPv6 hosts, the administrator manually creates and updates 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.