Un sistema que ejecuta un daemon IKE puede negociar los parámetros necesarios para crear una asociación de seguridad (SA) entre este sistema y el otro sistema que ejecuta el daemon IKE. El protocolo que se utiliza para negociar esta SA y las SA subsiguientes de IPsec se conoce como IKE. Esta versión de Oracle Solaris admite la versión 1 (IKEv1) y la versión 2 (IKEv2) del protocolo IKE.
La asociación de seguridad de IKE (también conocida como SA de ISAKMP o de Fase 1 en IKEv1) protege otros intercambios de protocolos entre estos dos sistemas IKE. Estos intercambios negocian los algoritmos criptográficos, la política de IPsec y otros parámetros necesarios para crear SA de IPsec.
Los sistemas que ejecutan un daemon IKE también se pueden configurar para negociar las SA de IPsec en nombre de otros sistemas. Cuando se configuran de esta forma, los sistemas se denominan puertas de enlace de seguridad. Si la negociación de IKE negociación es correcta, las SA de IPsec se puede utilizar para proteger los paquetes de red.
Si debe cumplir con un requisito estricto de usar únicamente criptografía validada por FIPS 140-2, debe estar ejecutando la versión Oracle Solaris 11.1 SRU 5.5 o la versión Oracle Solaris 11.1 SRU 3. Oracle completó una validación de FIPS 140-2 respecto de la estructura criptográfica en estas dos versiones específicas. Oracle Solaris 11.2 parte de esta base validada e incluye mejoras de software que se centran en el rendimiento, la funcionalidad y la confiabilidad. Siempre que sea posible, debe configurar Oracle Solaris 11.2 en FIPS 140-2 para aprovechar estas mejoras.
Los parámetros que se negocian para crear la SA de IKE incluyen algoritmos criptográficos que protegen los intercambios de IKE y algún material de autenticación. El material de autenticación se utiliza para determinar si los paquetes que contienen los intercambios del protocolo IKE son de confianza. Confianza significa que los paquetes proceden de un sistema de confianza y no desde un sistema que suplanta a ese sistema.
Oracle Solaris admite dos tipos de material de autenticación para IKE, claves compartidas previamente y certificados de clave pública.
Una clave compartida previamente es una cadena de caracteres hexadecimales o ASCII que solamente conocen dos sistemas. Las claves se denominan compartidas previamente porque ambos puntos finales deben conocer el valor de la clave antes del intercambio de IKE. Esta clave debe ser parte de la configuración de IKE en ambos sistemas. La clave compartida previamente se utiliza en la generación de cargas útiles de IKE, que componen los paquetes que implementa el protocolo IKE. El sistema que procesa estas cargas útiles de IKE usa la misma clave para autenticar las cargas que recibe.
La clave compartida previamente no se intercambia entre los puntos finales de IKE mediante el protocolo IKE. Normalmente, la clave se comparte con el sistema par mediante un medio diferente, como una llamada telefónica.
La clave compartida previamente en los pares que usan este método de autenticación debe ser idéntica. Las claves se almacenan en un archivo en cada sistema.
Los certificados de clave pública y sus cadenas de confianza proporcionan un mecanismo para comprobar digitalmente un sistema si intercambiar manualmente ninguna información secreta. Por lo tanto, los certificados de clave pública son más seguros que las claves compartidas previamente.
Un certificado de clave pública son datos sin formato que cifran un valor de clave pública, información sobre la generación del certificado, como el nombre y quién lo firmó, un hash o una suma de comprobación del certificado, y una firma digital del hash. Juntos, estos valores forman el certificado. La firma digital garantiza que el certificado no se ha modificado.
Un valor de clave pública es un valor que se deriva matemáticamente de otro valor, denominado clave privada. El algoritmo matemático que deriva la clave pública de la clave privada hace que la recuperación de la clave privada de la clave pública sea poco práctica. Por lo tanto, los certificados de claves públicas se pueden compartir libremente. Ejemplos de algoritmos que se utilizan para derivar las claves públicas incluyen RSA y curva elíptica.
Una firma digital es el resultado de la transferencia del contenido del certificado a través de un algoritmo de firma digital como RSA, DSA o ECDSA. Estos algoritmos utilizan una clave de firma privada, que no forma parte del certificado, y generan una firma digital. La firma se incluye en el certificado. De nuevo, calcular la clave de firma del contenido del certificado y la firma es poco práctico. Más específicamente, la firma del certificado y, por lo tanto, el contenido del certificado, se pueden verificar fácilmente mediante el uso de un valor público, que se deriva de la clave de firma.
Un certificado puede ser autofirmado; en este caso, la firma del certificado puede ser verificada por la clave pública del certificado o puede ser firmada por una entidad diferente. Cuando otra entidad firma el certificado, el valor de la clave pública que se usa para verificar el certificado también se distribuye como certificado de clave pública. Este segundo certificado será firmado por una autoridad de certificación (CA) de confianza o mediante un intermediario. El entidad que firma confía en el intermediario, es decir, la CA raíz o el anclaje de confianza.
Estos componentes de certificado de claves públicas, además de los procedimientos y las estructuras que los implementan, se conocen a menudo como una infraestructura de clave pública (PKI). El ámbito de la PKI de una organización puede variar. Una PKI simple podría consistir de una CA que firma unos pocos certificados para uso local. Una PKI más amplia podría usar un anclaje de confianza con reconocimiento global como la CA con autoridad.
En esta sección, se describen los pasos generales para crear y utilizar certificados de claves públicas en IKE. Para obtener procedimientos específicos, consulte Configuración de IKEv2 con claves compartidas previamente and Configuración de IKEv1 con claves compartidas previamente.
Para utilizar un certificado autofirmado o un certificado de una autoridad de certificación (CA), primero debe generar un par de claves pública/privada.
Para un certificado autofirmado, los pares de IKE a continuación intercambian estos certificados, comprueban que los certificados sean originales fuera de banda y, a continuación, importan los certificados de los pares en el almacén de claves local. Luego, almacén de claves contiene el certificado autofirmado original más los certificados importados.
Para certificados de una CA, debe realizar muchos pasos más. Cuando general el par de claves pública/privada, también genera una solicitud de firma de certificado (CSR). Una CSR contiene la clave pública y los identificadores. Un identificador típico es un nombre distintivo (DN), por ejemplo:
DN=”O=Example\, Inc, OU=qa, L=Silicon Valley, ST=CA, CN=enigma”
Envíe la CSR a la CA para que sea firmada.
En un proceso típico, pega la CRS en un formulario web y envía el formulario a la CA. Es posible que la CA le envíe más de un certificado firmado.
Obtenga los certificados firmados de la CA, a continuación, impórtelos en el almacén de claves de IKEv2 o en la base de datos de IKEv1.
Debe importar todos los certificados que envía la CA. Estos certificados están compuestos por una "cadena de confianza" del anclaje de confianza, o una CA raíz, para el certificado firmado que se identifica individualmente.
Repita el proceso en un par de IKE.
Utilice los certificados en las reglas de IKE.
Especifica el certificado mediante un identificador, como un DN. Para los certificados firmados por una CA, puede configurar IKE para que acepte cualquier certificado firmado por una CA determinada.
Un certificado firmado se considera válido y de confianza porque la autoridad de firma garantiza su validez. Si un certificado está en peligro o, de lo contrario, se determina como no válido, la CA lo revocará.
Las CA mantienen una lista de certificados revocados, a menudo denominada lista de revocación de certificados (CRL). Puede utilizar Online Certificate Status Protocol (OCSP) para comprobar dinámicamente el estado de un certificado. Algunos certificados de clave pública tienen URI incrustadas. Identifican una ubicación web o la ubicación donde puede comprobar la CRL o la ubicación web de un servidor de OCSP.
Para obtener más información, consulte RFC 2459: Certificate and CRL Profile and RFC 2560: Online Certificate Status Protocol - OCSP.
Los certificados de clave pública contienen la fecha y la hora de emisión, y el tiempo que conservan su validez. Por lo tanto, los relojes de los sistemas que generar y utilizan los certificados deben ser exactos. El software del Protocolo de hora de red (NTP) se puede usar para sincronizar los relojes en los sistemas. El software de dominio público NTP de la Universidad de Delaware se incluye en la versión Oracle Solaris. La documentación está disponible en el sitio web de NTP Documentation. También puede instalar el depósito de paquetes service/network/ptp para configurar el servicio de Protocolo de tiempo de precisión (PTP). Consulte IEEE 1588 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems.