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. |
IKE administration command. For viewing and modifying IKE policy. |
|
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. |
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.
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.
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.
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.
The ikecert(1M) command manipulates the local host's public-key databases. Because IKE uses these databases to authenticate the Phase 1 exchange when the ike.config file requires public key certificates, the directories must be populated before activating the in.iked daemon. Three subcommands handle each of the three databases: certlocal, certdb, and certrldb.
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.
Parameters that you pass to the certlocal subcommand when you create a private key must be reflected in the ike.config file, as shown in the following table.
Table 21–2 Correspondences Between ike certlocal and ike.config Values
certlocal options |
ike.config entry |
Notes |
---|---|---|
-A Subject Alternate Name |
cert_trust Subject Alternate Name |
A nickname that uniquely identifies the certificate. Possible values are IP address, email address, and domain name. |
-D X.509 Distinguished Name |
cert_root X.509 Distinguished Name |
The full name of the certificate authority that includes Country, Organization name, Organizational Unit, and Common Name. |
-t dsa-sha1 |
Slightly slower than RSA. Is not patented. |
|
-t rsa-md5 -t rsa-sha1 |
auth_method rsa_sig |
Slightly faster than DSA. Patent expired in September 2000. The RSA public key must be large enough to encrypt the biggest payload, Typically, an identity payload, such as Distinguished Name, is the biggest. |
-t rsa-md5 -t rsa-sha1 |
RSA encryption hides identities in IKE from eavesdroppers, but requires that the IKE peers know each other's public keys. |
If you issue a certificate request with the ikecert certlocal –kc command, you send the output of the command to your vendor. The vendor then creates keying material. You use the vendor's keying material as input to the certdb and certrldb subcommands.
The certdb subcommand manages the public-key database, /etc/inet/ike/publickeys. Options to the subcommand enable you to add, view, and remove public keys and certificates. 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.
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 them in the CRL database with the ikecert certrldb command. See How to Update a Certificate Revocation List for the procedure.
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 public-key databases that are stored under it are world-readable (0644). 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 vendor into this database — a certificate based on material you sent to the vendor, and a CA from the vendor.
An evaluation copy of the iPlanet CMS, a PKI, is available on the Media Kit in the installation package.
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.
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 vendors provide the CRLs for their certificates. You use the ikecert certrldb command to populate the database.