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.
If you have a strict requirement to use only FIPS 140-2 validated cryptography, you must be running the Oracle Solaris 11.1 SRU 5.5 release or the Oracle Solaris 11.1 SRU 3 release. Oracle completed a FIPS 140-2 validation against the Cryptographic Framework in these two specific releases. Oracle Solaris 11.2 builds on this validated foundation and includes software improvements that address performance, functionality, and reliability. Whenever possible, you should configure Oracle Solaris 11.2 in FIPS 140-2 mode to take advantage of these improvements.
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 RFC 2459: Certificate and CRL Profile and RFC 2560: Online Certificate Status Protocol - OCSP.
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.