The management of keying material for IPsec security associations (SAs) is called key management. Automatic key management requires a secure channel of communication for the creation, authentication, and exchange of keys. Oracle Solaris uses Internet Key Exchange (IKE) to automate key management. IKE eliminates administrative overhead and the security risk of manually distributing secret keys.
IKE can take advantage of available hardware cryptographic acceleration and key storage. Hardware cryptographic accelerators permit CPU-intensive key operations to be handled off the system. Key storage on hardware provides an additional layer of protection.
Oracle Solaris supports two versions of the IKE protocol.
IKE Version 2 (IKEv2), which is based on Internet Key Exchange Protocol Version 2 (IKEv2), RFC 5996
IKE Version 1 (IKEv1), which is based on The Internet Key Exchange (IKE), RFC 2409
On a FIPS 140-2 enabled system, you should configure IKEv2 with FIPS 140-2 approved algorithms only. For more information, see IKEv2 and FIPS 140-2.
The following concepts and terms are common to both versions of IKE. They might be implemented differently in the two versions.
Key negotiation and exchange – The exchange of keying material and the authentication of the peer's identity in a secure manner. The process uses asymmetric cryptographic algorithms. The two main methods are the RSA and the Diffie-Hellman protocols.
IKE creates and manages the IPsec SAs between systems that are running an IKE daemon. IKE negotiates a secure channel that protects the transmission of keying material. The daemon creates the keys from a random number generator by using the /dev/random device. The daemon changes the keys at a configurable rate. The keying material is available to algorithms that are specified in the configuration file for IPsec policy, ipsecinit.conf.
Diffie-Hellman (DH) algorithm – A key exchange algorithm that allows two systems to securely generate a shared secret over an insecure channel.
RSA algorithm – An asymmetric key algorithm that is used to authenticate the identity of peer systems, typically by proving ownership of an X.509 certificate. The algorithm is named for its three creators: Rivest, Shamir, and Adleman.
Alternatively, DSA or ECDSA algorithms may be used for this purpose.
Perfect forward secrecy (PFS) – In PFS, the key that is used to protect transmission of data is not used to derive additional keys. Also, the source of the key that is used to protect data transmission is never used to derive additional keys. Therefore, PFS can prevent the decryption of previously recorded traffic.
Oakley group – Used to negotiate PFS. See Section 6 of The Internet Key Exchange (IKE).
IKE policy – The set of IKE rules which define the acceptable parameters that an IKE daemon uses when attempting to set up a secure key exchange channel with a peer system. This is called an IKE SA in IKEv2 or Phase 1 in IKEv1.
The parameters include algorithms, key sizes, Oakley groups, and authentication method. The Oracle Solaris IKE daemons support preshared keys and certificates as authentication methods.
A system that is running an IKE daemon can negotiate the parameters needed to create a security association (SA) between this system and another system that is running the IKE daemon. The protocol that is used to negotiate this SA and subsequent IPsec SAs is known as IKE. This version of Oracle Solaris supports version 1 (IKEv1) and version 2 (IKEv2) of the IKE protocol.
The IKE security association (also known as the ISAKMP or Phase 1 SA in IKEv1) secures further protocol exchanges between these two IKE systems. These exchanges negotiate cryptographic algorithms, IPsec policy, and other parameters needed to create IPsec SAs.
Systems that are running an IKE daemon can also be configured to negotiate IPsec SAs on behalf of other systems. When configured in this manner, the systems are referred to as security gateways. If the IKE negotiation is successful, the IPsec SAs can be used to protect network packets.
The parameters that are negotiated to create the IKE SA include the cryptographic algorithms that protect the IKE exchanges and some authentication material. The authentication material is used to determine whether the packets that contain the IKE protocol exchanges can be trusted. Trust means that the packets come from a trusted system and not from a system that is pretending to be that system.
Oracle Solaris supports two types of authentication material for IKE, preshared keys and public key certificates.
A preshared key is string of hex or ASCII characters that only the two IKE systems know. The keys are called preshared because both endpoints must know the value of the key before the IKE exchange. This key must be part of the IKE configuration on both systems. The preshared key is used in the generation of the IKE payloads, which make up the packets that implement the IKE protocol. The system that processes these IKE payloads uses the same key to authenticate the payloads that it receives.
The preshared key is not exchanged between the IKE endpoints by using the IKE protocol. Typically, the key is shared with the peer system over a different medium, such as a phone call.
The preshared key on the peers that use this authentication method must be identical. The keys are stored in a file on each system.
Public key certificates and their trust chains provide a mechanism to digitally identify a system without having to manually exchange any secret information. Therefore, public key certificates are more secure than preshared keys.
A public key certificate is a blob of data that encodes a public key value, some information about the generation of the certificate, such as a name and who signed it, a hash or checksum of the certificate, and a digital signature of the hash. Together, these values form the certificate. The digital signature ensures that the certificate has not been modified.
A public key is a value that is mathematically derived from another value, called the private key. The mathematical algorithm that derives the public key from the private key makes retrieving the private key from the public key impractical. Therefore, public key certificates can be freely shared. Examples of algorithms that are used to derive public keys include RSA and Elliptic Curve.
A digital signature is the result of passing the certificate contents through a digital signing algorithm such as RSA, DSA or ECDSA. These algorithms use a private signing key, which is not part of the certificate, and produce a digital signature. The signature is appended to the certificate. Again, calculating the signing key from the certificate contents and the signature is impractical. More to the point, the certificate signature and hence the certificate contents can be easily verified by using a public value, which was derived from the signing key.
A certificate can be self-signed, in which case the signature of the certificate can be verified by the certificate's public key, or it can be signed by a different entity. When a different entity signs the certificate, the public key value that is used to verify the certificate is also distributed as a public key certificate. This second certificate will be signed by a certificate authority (CA) which is trusted, or by an intermediary. The intermediary is ultimately trusted by the signing entity, that is, the root CA or trust anchor.
These public key certificate components, plus the procedures and structures that implement them are often referred to as a public key infrastructure (PKI). The scope of an organization's PKI can vary. A simple PKI could consist of a CA that signs a few certificates for local use. A more extensive PKI would use a globally recognized trust anchor as the authoritative CA.
This section describes the overall steps to create and use public key certificates in IKE. For the specific procedures, see Configuring IKEv2 With Preshared Keys and Configuring IKEv1 With Preshared Keys.
To use either a self-signed certificate or a certificate from a certificate authority (CA), you first generate a public/private key pair.
For a self-signed certificate, IKE peers then exchange these certificates, verify out of band that the certificates are genuine, and then import the peers' certificates into the local keystore. The keystore then contains the original self-signed certificate plus the imported certificates.
For certificates from a CA, you perform several more steps. When you generate the public/private key pair, you also generate a certificate signing request (CSR). A CSR contains the public key and identifiers. A typical identifier is a distinguished name (DN), for example:
DN=O=Example\, Inc, OU=qa, L=Silicon Valley, ST=CA, CN=enigma
Send the CSR to the CA for signature.
In a typical process, you paste the CSR into a web form and submit the form to the CA. The CA might send more than one signed certificate to you.
Get the signed certificates from the CA, then import them into your IKEv2 keystore or IKEv1 database.
You must import all the certificates that the CA sends. These certificates comprise a "chain of trust" from the trust anchor, or root CA, to your individually identified signed certificate.
Repeat the process on an IKE peer.
Use the certificates in IKE rules.
You specify the certificate by an identifier, such as a DN. For CA-signed certificates, you can configure IKE to accept any certificate that is signed by a particular CA.
A signed certificate is trusted as valid because the signing authority assures its validity. If a certificate is compromised or otherwise determined as invalid, the CA will revoke it.
CAs maintain a list of revoked certificates, often called the certificate revocation list (CRL). You can use the Online Certificate Status Protocol (OCSP) to dynamically check the status of a certificate. Some public key certificates have URIs embedded in them. They identify a web location where you can check the CRL or the web location of an OCSP server.
For more information, see Section 3.3 of Internet X.509 Public Key Infrastructure Certificate and CRL Profile, RFC 2459 and the RFC X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP, RFC 2560.
Public key certificates contain the date and time of issue and the time that they remain valid. Therefore, the clocks on systems that generate and use certificates must be accurate. The Network Time Protocol (NTP) software can be used to synchronize the clocks on systems. NTP public domain software from the University of Delaware is included in the Oracle Solaris release. Documentation is available from the NTP Documentation web site. You can also install the service/network/ptp package to configure the Precision Time Protocol (PTP) service. See IEEE 1588 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems (https://www.nist.gov/el/intelligent-systems-division-73500/ieee-1588).
You can require the use of a specific IKE protocol version on a per-rule basis, which enables you to change only the IPsec rule while not changing its corresponding IKE configuration rule. Specifying the IKEv2 protocol in an IPsec rule is a useful step when transitioning systems in an orderly fashion from the legacy IKEv1 protocol. For an example, see Example 33, Configuring IPsec Policy to Use the IKEv2 Protocol Only.
The following table compares the implementation of the IKEv2 and IKEv1 versions on an Oracle Solaris system.