Chapter 24

Internet Key Exchange (Reference)

This chapter contains the following reference information about IKE:

For instructions on implementing IKE, see Chapter 23, Configuring IKE (Tasks). For overview information, see Chapter 22, Internet Key Exchange (Overview).

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 (SAs) 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. For more information, see the pf_key(7P) man page.

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 public key 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, manages the keys for the interfaces that are being protected in the IPsec policy file, /etc/inet/ipsecinit.conf. The IKE policy file manages keys for IKE, and for the IPsec SAs. The IKE daemon itself requires keying material in the Phase 1 exchange.

Key management with IKE includes rules and global parameters. An IKE rule identifies the systems or networks that the keying material secures. The rule also specifies the authentication method. Global parameters include such items as the path to an attached hardware accelerator. For examples of IKE policy files, see Configuring IKE With Preshared Keys (Task Map). For examples and descriptions of IKE policy entries, see the ike.config(4) man page.

The IPsec SAs that IKE supports protect the IP datagrams 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 perfect forward security (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. For details, see Security Considerations for ipsecinit.conf and ipsecconf.

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.

For examples and a full description of this command's options, see the ikeadm(1M) man page. 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	You cannot view nor modify keying material. The base level is the default level at which the `in.iked` daemon runs.
`0x1`, or modkeys level	You can remove, change, and add preshared keys.
`0x2`, or keymat level	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. For details, see Security Considerations for ipseckey.

IKE Preshared Keys Files

When you create preshared keys manually, the keys are stored in files in the /etc/inet/secret directory. The ike.preshared file contains the preshared keys for Internet Security Association and Key Management Protocol (ISAKMP) SAs. The ipseckeys file contains the preshared keys for IPsec SAs. The files are protected at 0600. The secret directory is protected at 0700.

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. For examples of manually managing the file, see How to Manually Create IPsec Security Associations. The IKE daemon does not use this file. The keying material that IKE generates for IPsec SAs is stored in the kernel.

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

IKE Public Key Databases and Commands

The ikecert command manipulates the local system'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.

The ikecert command also handles key storage. Keys can be stored on disk, on an attached Sun Crypto Accelerator 4000 board, or in a softtoken keystore. The softtoken keystore is available when the metaslot in the Solaris cryptographic framework is used to communicate with the hardware device. The ikecert command uses the PKCS #11 library to locate key storage.

Solaris 10 1/06: In this release, the library does not have to be specified. By default, the PKCS #11 library is /usr/lib/libpkcs11.so.
Solaris 10: In this release, the PKCS #11 entry must be specified. Otherwise, the -T option to the ikecert command cannot work. The entry appears similar to the following:
pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so"

For more information, see the ikecert(1M) man page. For information about metaslot and the softtoken keystore, see the cryptoadm(1M) man page.

`ikecert tokens` Command

The tokens argument lists the token IDs that are available. Token IDs enable the ikecert certlocal and ikecert certdb commands to generate public key certificates and certificate requests. The certificates and certificate requests can also be stored by the cryptographic framework in the softtoken keystore, or on an attached Sun Crypto Accelerator 4000 board. The ikecert command uses the PKCS #11 library to locate certificate storage.

`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 options to the ikecert certlocal command must have related entries in the ike/config file. The correspondences between ikecert options and ike/config entries are shown in the following table.

Table 24-1 Correspondences Between ikecert Options and ike/config Entries

`ikecert` Option	`ike/config` Entry	Description
`-A` subject-alternate-name	`cert_trust` subject-alternate-name	A nickname that uniquely identifies the certificate. Possible values are an IP address, an email address, or a domain name.
`-D` X.509-distinguished-name	X.509-distinguished-name	The full name of the certificate authority that includes the country (C), organization name (ON), organizational unit (OU), and common name (CN).
`-t dsa-sha1`	`auth_method dss_sig`	An authentication method that is slightly slower than RSA.
`-t rsa-md5` and `-t rsa-sha1`	`auth_method rsa_sig`	An authentication method that is slightly faster than DSA. The RSA public key must be large enough to encrypt the biggest payload. Typically, an identity payload, such as the X.509 distinguished name, is the biggest payload.
`-t rsa-md5` and `-t rsa-sha1`	`auth_method rsa_encrypt`	RSA encryption hides identities in IKE from eavesdroppers, but requires that the IKE peers know each other's public keys.
`-T`	`pkcs11_path`	The PKCS #11 library handles key acceleration on the Sun Crypto Accelerator 1000 board and the Sun Crypto Accelerator 4000 board. The library also provides the tokens that handle key storage on the Sun Crypto Accelerator 4000 board.

If you issue a certificate request with the ikecert certlocal -kc command, you send the output of the command to a PKI organization or to 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 certificate revocation list (CRL) that the PKI returns to you is input for the certrldb subcommand.