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.