IKE Configuration Choices
The /etc/inet/ike/config configuration file contains IKE policy entries. For two IKE daemons to
authenticate each other, the entries must be valid. Also, keying material must be
available. The entries in the configuration file determine the method for using the
keying material to authenticate the Phase 1 exchange. The choices are preshared keys
or public key certificates.
The entry auth_method preshared indicates that preshared keys are used. Values for auth_method other
than preshared indicate 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. For more information, see the ike.config(4) man page.
IKE With Preshared Keys
Preshared keys are created by an administrator on one system. The keys are
then shared out of band with administrators of remote systems. You 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 file is for IKE as the ipseckeys file is for
IPsec. Any compromise of the keys in the ike.preshared file compromises all
keys that are derived from the keys in the file.
One system's preshared key must be identical to its remote system's key. The
keys are tied to a particular IP address. Keys are most secure
when one administrator controls the communicating systems. For more information, see the ike.preshared(4) man
IKE With 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 protocol (DH) for 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 you, the administrator. The ikecert certlocal -ks command
creates the private part of the public-private key pair for the system. You
then get the self-signed certificate output in X.509 format from the remote system.
The remote 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 systems. When you use the -T option, the certificates reside on
Self-signed certificates are a halfway point between preshared keys and CAs. Unlike preshared
keys, a self-signed certificate can be used on a mobile machine or on
a system that might be renumbered. To self-sign a certificate for a system
without a fixed number, use a DNS (www.example.org) or email ([email protected]) alternative
Public keys can be delivered by a PKI or a CA organization.
You install the public keys and their accompanying CAs in the /etc/inet/ike/publickeys directory.
When you use the -T option, the certificates reside on attached hardware. Vendors
also issue certificate revocation lists (CRLs). Along with installing the keys and CAs,
you are responsible for installing the CRL in the /etc/inet/ike/crls directory.
CAs have the advantage of being certified by an outside organization, rather than
by the site administrator. In a sense, CAs are notarized certificates. As with
self-signed certificates, CAs can be used on a mobile machine or on a
system that might be renumbered. Unlike self-signed certificates, CAs can very easily scale
to protect a large number of communicating systems.