Intercambio de claves por red
Introducción a IKE
El intercambio de claves por Internet (IKE) es un protocolo de administración segura de claves que se utiliza para configurar un canal de comunicaciones seguro y autenticado entre dos dispositivos.
IKE hace lo siguiente:
Negocia y administra parámetros de IKE e IPsec
Autentica el intercambio seguro de claves
Proporciona autenticación mutua entre pares por medio de secretos compartidos (no contraseñas) y claves públicas
Proporciona protección de identidad (en modo principal)
Emplea métodos Diffie-Hellman y es opcional en IPsec (las claves compartidas se pueden especificar manualmente en los extremos).
Versiones de IKE
Hay dos versiones de los estándares IKE disponibles:
IKE versión 1: protocolo IKE definido en RFC 2409.
IKE versión 2: IKE versión 2 (IKEv2) es la última versión del protocolo IKE definido en RFC 7296.
Intercambio de claves por Internet versión 2 (IKEv2) es la versión más reciente del protocolo de intercambio de claves por Internet (IKE) definido en RFC 7296. Un par VPN se configura como IKEv1 o IKEv2. Cuando un par se configura como IKEv2, no puede recurrir a IKEv1 si su par remoto inicia la negociación de IKEv1.
Las ventajas de usar IKEv2 sobre IKEv1 son las siguientes:
Reemplaza ocho intercambios iniciales con un solo intercambio de cuatro mensajes.
Reduce la latencia para la configuración de la SA de IPsec y aumenta la velocidad de establecimiento de la conexión.
Aumenta la robustez frente a ataques de DOS.
Mejora la confiabilidad mediante el uso de números de secuencia, confirmaciones y corrección de errores.
Mejora la confiabilidad, ya que todos los mensajes son solicitudes o respuestas. El iniciador es responsable de retransmitir si no recibe respuesta.
Interacción entre IKE e IPSec
IPsec puede establecer una VPN de cualquiera de las siguientes maneras:
Protocolo de intercambio de claves por Internet (IKE): IPsec admite la generación y negociación automatizadas de claves y asociaciones de seguridad mediante el protocolo IKE. El uso de IKE para negociar VPN entre dos puntos de conexión proporciona más seguridad que el intercambio manual de claves.
Intercambio manual de claves: IPsec admite el uso y el intercambio de claves manualmente (ejemplo: teléfono o correo electrónico) en ambos lados para establecer VPN.
Intercambio de mensajes IKEv1
La negociación de IKE consta de dos fases:
Fase 1: Negociar el intercambio de propuestas sobre cómo autenticar y asegurar el canal.
Fase 2: Negociar asociaciones de seguridad (SA) para proteger los datos que atraviesan el túnel IPsec.
Fase 1 de la negociación del túnel de IKE
La fase 1 de una negociación de túnel de intercambio de claves por Internet (IKE) de AutoKey consiste en el intercambio de propuestas sobre cómo autenticar y proteger el canal. Los participantes intercambian propuestas de servicios de seguridad aceptables como los siguientes ejemplos:
Algoritmos de cifrado: estándar de cifrado de datos (DES), estándar de cifrado de datos triple (3DES) y estándar de cifrado avanzado (AES). (Consulte Información general sobre IPsec.)
Algoritmos de autenticación: resumen del mensaje 5 (MD5) y algoritmo de hash seguro (SHA). (Consulte Información general sobre IPsec.)
Grupo Diffie-Hellman (DH). (Consulte Información general sobre IPsec.)
Clave previamente compartida o certificados RSA/DSA. (Consulte Información general sobre IPsec.)
Una negociación exitosa de fase 1 concluye cuando ambos extremos del túnel acuerdan aceptar al menos un conjunto de los parámetros de seguridad de fase 1 propuestos y, a continuación, procesarlos. Los dispositivos Juniper Networks admiten hasta cuatro propuestas para negociaciones de fase 1, lo que le permite definir qué tan restrictivo será un rango de parámetros de seguridad para la negociación de claves que aceptará. Junos OS proporciona conjuntos predefinidos de propuestas de fase 1 de tipo básico, compatible y estándar. También puede definir propuestas de fase 1 personalizadas.
Los intercambios de fase 1 pueden tener lugar en modo principal o en modo agresivo. Puede elegir el modo durante la configuración de políticas de IKE.
En este tema, se incluyen las siguientes secciones:
Modo principal
En el modo principal, el iniciador y el destinatario envían tres intercambios bidireccionales (seis mensajes en total) para cumplir con los siguientes servicios:
Primer intercambio (mensajes 1 y 2): propone y acepta los algoritmos de cifrado y autenticación.
Segundo intercambio (mensajes 3 y 4): ejecuta un intercambio DH, y el iniciador y el destinatario proporcionan un número pseudoaleatorio.
Tercer intercambio (mensajes 5 y 6): envía y verifica las identidades del iniciador y del destinatario.
La información transmitida en el tercer intercambio de mensajes está protegida por el algoritmo de cifrado establecido en los dos primeros intercambios. Por lo tanto, las identidades de los participantes se cifran y, por lo tanto, no se transmiten "en claro".
Modo agresivo
En el modo agresivo, el iniciador y el destinatario logran los mismos objetivos que con el modo principal, pero en solo dos intercambios, con un total de tres mensajes:
Primer mensaje: el iniciador propone la asociación de seguridad (SA), inicia un intercambio DH y envía un número pseudoaleatorio y su identidad IKE.
Cuando configure el modo agresivo con varias propuestas para las negociaciones de fase 1, utilice el mismo grupo DH en todas las propuestas, ya que no se puede negociar el grupo DH. Se pueden configurar hasta cuatro propuestas.
Segundo mensaje: el destinatario acepta la SA; autentica al iniciador; y envía un número pseudoaleatorio, su identidad IKE y, si utiliza certificados, el certificado del destinatario.
Tercer mensaje: el iniciador autentica al destinatario, confirma el intercambio y, si utiliza certificados, envía el certificado del iniciador.
Debido a que las identidades de los participantes se intercambian sin cifrar (en los dos primeros mensajes), el modo agresivo no proporciona protección de identidad.
Los modos principal y agresivo solo se aplican al protocolo IKEv1. El protocolo IKEv2 no negocia el uso de los modos principal y agresivo.
Consulte también
Fase 2 de la negociación del túnel de IKE
Después de que los participantes han establecido un canal seguro y autenticado, avanzan a través de la fase 2, en la que negocian asociaciones de seguridad (SA) para proteger los datos que se transmitirán a través del túnel IPsec.
De manera similar al proceso para la Fase 1, los participantes intercambian propuestas para determinar qué parámetros de seguridad emplear en la SA. Una propuesta de fase 2 también incluye un protocolo de seguridad, ya sea carga de seguridad de encapsulación (ESP) o encabezado de autenticación (AH), y algoritmos de cifrado y autenticación seleccionados. La propuesta también puede especificar un grupo Diffie-Hellman (DH) si se desea una confidencialidad directa perfecta (PFS).
Independientemente del modo utilizado en la fase 1, la fase 2 siempre funciona en modo rápido e implica el intercambio de tres mensajes.
En este tema, se incluyen las siguientes secciones:
ID de proxy
En la fase 2, los pares intercambian ID de proxy. Un ID de proxy se compone de un prefijo de dirección IP local y remota. El ID de proxy de ambos pares debe coincidir, lo que significa que la dirección IP local especificada para un par debe ser la misma que la dirección IP remota especificada para el otro par.
Confidencialidad directa perfecta
PFS es un método para derivar claves de fase 2 independientes y no relacionadas con las claves anteriores. Como alternativa, la propuesta de fase 1 crea la clave (la clave SKEYID_d) de la que se derivan todas las claves de fase 2. La clave SKEYID_d puede generar claves de fase 2 con un mínimo de procesamiento de CPU. Desafortunadamente, si una parte no autorizada obtiene acceso a la clave SKEYID_d, todas sus claves de cifrado se verán comprometidas.
PFS resuelve este riesgo de seguridad forzando un nuevo intercambio de claves DH para cada túnel de fase 2. Por lo tanto, el uso de PFS es más seguro, aunque el procedimiento de reintroducción de claves en la fase 2 puede tardar un poco más con PFS habilitado.
Protección contra reproducción
Un ataque de reproducción se produce cuando una persona no autorizada intercepta una serie de paquetes y los utiliza más tarde para inundar el sistema, lo cual provoca una denegación de servicio (DoS), o bien los usa para obtener acceso a la red de confianza. Junos OS proporciona una función de protección contra reproducción que permite que los dispositivos comprueben todos los paquetes IPsec para ver si se recibieron anteriormente. Si los paquetes llegan fuera de un rango de secuencia especificado, Junos OS los rechaza. El uso de esta función no requiere negociación, ya que los paquetes siempre se envían con números de secuencia. Tiene la opción de simplemente activar o no la comprobación de los números de secuencia.
Consulte también
Intercambio de mensajes IKEv2
La versión 2 de IKE es la sucesora del método IKEv1. Proporciona un canal de comunicación VPN seguro entre dispositivos VPN pares y define la negociación y autenticación para las asociaciones de seguridad (SA) IPsec de manera protegida.
IKEv2 no incluye la fase 1 y la fase 2 similares a IKEv1, pero hay cuatro intercambios de mensajes que se producen para negociar un túnel IPsec con IKEv2. Los intercambios de mensajes en IKEv2 son:
Negocia los atributos de seguridad para establecer el túnel IPsec. Esto incluye el intercambio de los protocolos/parámetros utilizados y los grupos Diffie-Hellman.
Cada par establece o autentica sus identidades mientras se establece el túnel IPsec.
Pares para crear asociaciones de seguridad adicionales entre sí.
Los pares realizan la detección de vivacidad, eliminan las relaciones SA y notifican mensajes de error.
- Carga de configuración de IKEv2
- Reintroducción y reautenticación de IKEv2
- Fragmentación IKEv2
- Selectores de tráfico para IKEv2
Carga de configuración de IKEv2
La carga de configuración es una opción de IKEv2 que se ofrece para propagar la información de aprovisionamiento de un respondedor a un iniciador. La carga de configuración de IKEv2 solo es compatible con VPN basadas en rutas.
RFC 5996, Protocolo de intercambio de claves por Internet versión 2 (IKEv2), define 15 atributos de configuración diferentes que el respondedor puede devolver al iniciador.
Reintroducción y reautenticación de IKEv2
Con IKEv2, la reintroducción de claves y la reautenticación son procesos separados.
La reintroducción de claves establece nuevas claves para la asociación de seguridad (SA) de IKE y restablece los contadores de ID de mensajes, pero no vuelve a autenticar a los pares.
La reautenticación verifica que los pares de VPN conserven su acceso a las credenciales de autenticación. La reautenticación establece nuevas claves para la SA de IKE y las SA secundarias; ya no se necesitan las reclaves de ninguna SA IKE o SA secundaria pendiente. Después de crear el nuevo IKE y las SA secundarias, se eliminan el IKE antiguo y las SA secundarias.
La reautenticación IKEv2 está deshabilitada de forma predeterminada. Para habilitar la reautenticación, configure un valor de frecuencia de reautenticación entre 1 y 100. La frecuencia de reautenticación es el número de reclaves IKE que se producen antes de que se produzca la reautenticación. Por ejemplo, si la frecuencia de reautenticación configurada es 1, se produce una nueva autenticación cada vez que hay una reclave IKE. Si la frecuencia de reautenticación configurada es 2, la reautenticación se produce en cada dos reclaves de IKE. Si la frecuencia de reautenticación configurada es 3, se produce una nueva autenticación en cada tercera reclave IKE, y así sucesivamente.
Fragmentación IKEv2
Cuando se utiliza la autenticación basada en certificados, los paquetes IKEv2 pueden superar la ruta MTU si se transmiten varios certificados. Si el tamaño del mensaje IKE supera la ruta MTU, los mensajes se fragmentan en el nivel IP. Algunos equipos de red, como los dispositivos NAT, no permiten el paso de fragmentos IP, lo que impide el establecimiento de túneles IPsec.
La fragmentación de mensajes IKEv2, como se describe en RFC 7383, Fragmentación de mensajes del Protocolo de intercambio de claves por Internet versión 2 (IKEv2), permite que IKEv2 funcione en entornos donde los fragmentos de IP podrían estar bloqueados y los pares no podrían establecer una asociación de seguridad (SA) IPsec. La fragmentación de IKEv2 divide un mensaje IKEv2 grande en un conjunto de mensajes más pequeños para que no haya fragmentación en el nivel de IP. La fragmentación tiene lugar antes de cifrar y autenticar el mensaje original, de modo que cada fragmento se cifra y autentica por separado. En el receptor, los fragmentos se recopilan, verifican, descifran y fusionan en el mensaje original.
Selectores de tráfico para IKEv2
Puede configurar selectores de tráfico en IKEv2 utilizados durante la negociación de IKE. Un selector de tráfico es un acuerdo entre pares de IKE para permitir el tráfico a través de un túnel VPN si el tráfico coincide con un par especificado de direcciones locales y remotas. Solo se permite el tráfico que se ajusta a un selector de tráfico a través de la asociación de seguridad (SA) asociada. Los selectores de tráfico se utilizan durante la creación del túnel para configurar el túnel y determinar qué tráfico se permite a través del túnel.
Proxy ID
Se utiliza un ID de proxy durante la fase 2 de las negociaciones de red privada virtual (VPN) de intercambio de claves por Internet (IKE). Ambos extremos de un túnel VPN tienen un ID de proxy configurado manualmente (VPN basada en ruta) o simplemente usan una combinación de IP de origen, IP de destino y servicio en una política de túnel. Cuando se negocia la fase 2 de IKE, cada extremo compara el ID de proxy local y remoto configurado con lo que realmente se recibe.
Selectores de tráfico
El ID de proxy es compatible con VPN basadas en rutas y en políticas. Sin embargo, el ID de proxy múltiple solo se admite para VPN basadas en rutas. El ID de proxy múltiple también se conoce como selector de tráfico. Un selector de tráfico es un acuerdo entre pares de IKE para permitir el tráfico a través de un túnel, si el tráfico coincide con un par especificado de direcciones locales y remotas. Puede definir un selector de tráfico dentro de una VPN basada en ruta específica, lo que puede dar lugar a varias SA IPsec de fase 2. Solo se permite el tráfico que se ajuste a un selector de tráfico a través de una SA. El selector de tráfico suele ser necesario cuando los dispositivos de puerta de enlace remota no son dispositivos de Juniper Networks.
Traducción transversal de direcciones de red (NAT-T)
Network Address Translation-Traversal (NAT-T) es un método para evitar los problemas de traducción de direcciones IP que se producen cuando los datos protegidos por IPsec pasan a través de un dispositivo NAT para la traducción de direcciones.
Cualquier cambio en el direccionamiento IP, que es la función de NAT, hace que IKE descarte paquetes. Después de detectar uno o más dispositivos NAT a lo largo de la ruta de datos durante los intercambios de fase 1, NAT-T agrega una capa de encapsulación del Protocolo de datagramas de usuario (UDP) a los paquetes IPsec para que no se descarten después de la traducción de direcciones. NAT-T encapsula el tráfico IKE y ESP dentro de UDP con el puerto 4500 utilizado como puerto de origen y destino. Debido a que los dispositivos NAT caducan las traducciones UDP obsoletas, se requieren mensajes keepalive entre los pares.
La ubicación de un dispositivo NAT puede ser tal que:
Solo el iniciador IKEv1 o IKEv2 está detrás de un dispositivo NAT. Múltiples iniciadores pueden estar detrás de dispositivos NAT separados. Los iniciadores también pueden conectarse al respondedor a través de varios dispositivos NAT.
Solo el respondedor IKEv1 o IKEv2 está detrás de un dispositivo NAT.
Tanto el iniciador IKEv1 o IKEv2 como el respondedor están detrás de un dispositivo NAT.
Suite B y PRIME Cryptographic Suites
Suite B es un conjunto de algoritmos criptográficos designados por la Agencia de Seguridad Nacional de los Estados Unidos para permitir que los productos comerciales protejan el tráfico clasificado en niveles secretos o de alto secreto. Los protocolos del conjunto B se definen en RFC 6379, Conjuntos criptográficos de conjunto B para IPsec. Los conjuntos criptográficos Suite B proporcionan integridad y confidencialidad de la carga de seguridad encapsuladora (ESP) y deben usarse cuando se requieren protección y cifrado de integridad ESP. Protocol Requirements for IP Modular Encryption (PRIME), un perfil IPsec definido para redes del sector público en el Reino Unido, se basa en el conjunto criptográfico Suite B, pero utiliza AES-GCM en lugar de AES-CBC para las negociaciones IKEv2.
Se admiten los siguientes conjuntos criptográficos:
Suite-B-GCM-128
ESP: Cifrado estándar de cifrado avanzado (AES) con claves de 128 bits y valor de comprobación de integridad (ICV) de 16 octetos en modo de contador de Galois (GCM).
IKE: Cifrado AES con claves de 128 bits en modo de encadenamiento de bloques de cifrado (CBC), integridad mediante autenticación SHA-256, establecimiento de claves mediante el grupo 19 de Diffie-Hellman (DH) y autenticación mediante firmas de curva elíptica de 256 bits del algoritmo de firma digital de curva elíptica (ECDSA).
Suite-B-GCM-256
ESP: Cifrado AES con claves de 256 bits e ICV de 16 octetos en GCM para ESP.
IKE: Cifrado AES con claves de 256 bits en modo CBC, integridad mediante autenticación SHA-384, establecimiento de claves mediante el grupo DH 20 y autenticación mediante firmas de curva elíptica ECDSA de 384 bits.
PRIME-128
ESP: Cifrado AES con claves de 128 bits e ICV de 16 octetos en GCM.
IKE: Cifrado AES con claves de 128 bits en GCM, establecimiento de claves mediante el grupo DH 19 y autenticación mediante firmas de curva elíptica ECDSA de 256 bits.
PRIME-256
ESP: Cifrado AES con claves de 256 bits e ICV de 16 octetos en GCM para ESP.
IKE: Cifrado AES con claves de 256 bits en GCM, establecimiento de claves mediante el grupo DH 20 y autenticación mediante firmas de curva elíptica ECDSA de 384 bits.
Las suites criptográficas Suite-B admiten IKEv1 e IKEv2. Las suites criptográficas PRIME solo admiten IKEv2.