Intercambio de claves por red
Introducción a IKE
El intercambio de claves por internet (IKE) es un protocolo de administración de claves segura que se utiliza para configurar un canal de comunicación seguro y autenticado entre dos dispositivos.
IKE hace lo siguiente:
Negocia y administra parámetros IKE e IPsec
Autentica el intercambio seguro de claves
Proporciona autentificación mutua por pares mediante secretos compartidos (no contraseñas) y claves públicas
Proporciona protección de identidad (en el modo principal)
Emplea métodos Diffie-Hellman y es opcional en IPsec (las claves compartidas se pueden ingresar manualmente en los puntos de conexión).
Versiones de IKE
Hay disponibles dos versiones de los estándares de ICR:
IKE versión 1: protocolo IKE definido en RFC 2409.
IKE versión 2 - IKE versión 2 (IKEv2) es la versión más reciente del protocolo IKE definido en el RFC 7296.
El 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 el RFC 7296. Un par vpn está configurado como IKEv1 o IKEv2. Cuando un par está configurado como IKEv2, no puede volver 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 SA IPsec y aumenta la velocidad de establecimiento de conexión.
Aumenta la robustez frente a los ataques de DOS.
Mejora la confiabilidad mediante el uso de números de secuencia, reconocimientos 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 una 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 ICR para negociar VPN entre dos puntos de conexión ofrece más seguridad que el intercambio manual de claves.
Intercambio manual de claves: IPsec admite el uso y el intercambio de claves de forma manual (ejemplo: por teléfono o correo electrónico) en ambos lados para establecer una VPN.
Intercambio de mensajes IKEv1
La negociación de ICR incluye dos fases:
Fase 1: negocia el intercambio de propuestas sobre cómo autenticar y proteger el canal.
Fase 2: negocia asociaciones de seguridad (SA) para proteger los datos que atraviesan el túnel IPsec.
Fase 1 de la negociación de túnel de ICR
La fase 1 de una negociación de túnel de intercambio de claves por internet (IKE) de clave automática consiste en el intercambio de propuestas sobre cómo autenticar y proteger el canal. Los participantes intercambian propuestas de servicios de seguridad aceptables, como:
Algoritmos de cifrado: estándar de cifrado de datos (DES), triple estándar de cifrado de datos (3DES) y estándar de cifrado avanzado (AES). (Ver Descripción general de IPsec.)
Algoritmos de autenticación: síntesis del mensaje 5 (MD5) y algoritmo hash seguro (SHA). (Ver Descripción general de IPsec.)
Grupo Diffie-Hellman (DH). (Ver Descripción general de IPsec.)
Certificados RSA/DSA o clave precompartida. (Ver Descripción general de IPsec.)
Una negociación de fase 1 correcta concluye cuando ambos extremos del túnel acuerdan aceptar al menos un conjunto de los parámetros de seguridad de fase 1 propuestos y, luego, procesarlos. Los dispositivos Juniper Networks admiten hasta cuatro propuestas para negociaciones de fase 1, lo que le permite definir cómo se restringe un rango de parámetros de seguridad para la negociación de claves que aceptará. Junos OS ofrece conjuntos predefinidos de propuestas de fase 1 básicas, compatibles y estándar. También puede definir propuestas de fase 1 personalizadas.
Los intercambios de fase 1 pueden tener lugar en el modo principal o en el modo agresivo. Puede elegir el modo durante la configuración de la política de IKE.
Este tema incluye 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 pseudoaleatario.
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 "de forma clara".
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 pseudoaleatico y su identidad IKE.
Cuando configure el modo agresivo con varias propuestas para 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 pseudoaleativo, 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.
Dado que las identidades de los participantes se intercambian sin claridad (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 de túnel de IKE
Después de que los participantes hayan establecido un canal seguro y autenticado, pasan por la fase 2, en la cual 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 de 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 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.
Este tema incluye las siguientes secciones:
ID de proxy
En la fase 2, los pares intercambian ID de proxy. Un ID de proxy consta 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 de las claves anteriores y no relacionadas con ellas. Alternativamente, la propuesta de fase 1 crea la clave (la clave SKEYID_d) de la cual se derivan todas las claves de fase 2. La SKEYID_d clave puede generar claves de fase 2 con un mínimo de procesamiento de CPU. Lamentablemente, si una parte no autorizada obtiene acceso a la clave de SKEYID_d, todas sus claves de cifrado se verán comprometidas.
PFS aborda este riesgo de seguridad forzando un nuevo intercambio de claves DH para que ocurra en cada túnel de fase 2. Por lo tanto, el uso de PFS es más seguro, aunque el procedimiento de reenclavado en la fase 2 puede tardar un poco más con PFS habilitado.
Protección contra repeticiones
Un ataque de repetición se produce cuando una persona no autorizada intercepta una serie de paquetes y los utiliza más tarde para inundar el sistema, causar una denegación de servicio (DoS) u obtener acceso a la red de confianza. Junos OS proporciona una función de protección de reproducción que permite a los dispositivos comprobar cada paquete IPsec para ver si se recibió 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. Simplemente tiene la opción de comprobar o no los números de secuencia.
Consulte también
Intercambio de mensajes IKEv2
La versión 2 de IKE es el sucesor del método IKEv1. Proporciona un canal de comunicación VPN seguro entre dispositivos VPN pares y define la negociación y la autenticación para asociaciones de seguridad (SA) de IPsec de manera protegida.
IKEv2 no incluye las fases 1 y 2 similares a IKEv1, pero hay cuatro intercambios de mensajes que se producen para negociar un túnel IPsec con IKEv2. El intercambio de mensajes en IKEv2 son:
Negocia los atributos de seguridad para establecer el túnel IPsec. Esto incluye intercambiar 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 detección de líneas en vivo, eliminación de relaciones de SA e informes de mensajes de error.
- Carga de configuración de IKEv2
- Reenrutamiento y autenticación de IKEv2
- Fragmentación de IKEv2
- Selectores de tráfico para IKEv2
Carga de configuración de IKEv2
La carga de configuración es una opción 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 se admite 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.
Reenrutamiento y autenticación de IKEv2
Con IKEv2, la reenrutación y la reautenticación son procesos independientes.
La reenclave establece nuevas claves para la asociación de seguridad (SA) de IKE y restablece los contadores de ID de mensaje, pero no vuelve a autenticar los pares.
La reautoentificació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 ICR y las SA secundarias; ya no se necesitan las claves de cualquier SA de IKE o SA secundaria pendiente. Después de crear las SA nuevas ICR e secundarias, se eliminan las IKE antiguas y las SA secundarias.
La reautenticación IKEv2 está deshabilitada de forma predeterminada. Puede habilitar la reautenticación configurando un valor de frecuencia de reautenticación entre 1 y 100. La frecuencia de reautenticación es el número de claves de IKE que se produce antes de que se produzca la reautenticación. Por ejemplo, si la frecuencia de reautenticación configurada es 1, la reautenticación se produce cada vez que hay una rekey de ICR. Si la frecuencia de reautenticación configurada es 2, la reautenticación se produce en cada otra rekey de ICR. Si la frecuencia de reautenticación configurada es 3, la reautenticación se produce en cada tercera rekey de ICR, y así sucesivamente.
Fragmentación de IKEv2
Cuando se utiliza la autenticación basada en certificados, los paquetes IKEv2 pueden superar la MTU de ruta si se transmiten varios certificados. Si el tamaño del mensaje de ICR supera la ruta MTU, los mensajes se fragmentan en el nivel de IP. Algunos equipos de red, como los dispositivos TDR, no permiten que los fragmentos de IP pasen a través, lo que impide el establecimiento de túneles IPsec.
La fragmentación de mensajes de IKEv2, como se describe en RFC 7383, Fragmentación de mensajes del protocolo de intercambio de claves de Internet versión 2 (IKEv2), permite que IKEv2 funcione en entornos en los que los fragmentos de IP podrían bloquearse y los pares no podrían establecer una asociación de seguridad IPsec (SA). 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 que el mensaje original se cifrado y autentifique, de modo que cada fragmento se cifra y autentica por separado. En el receptor, los fragmentos se recopilan, verifican, descifran y se 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 ajuste a un selector de tráfico a través de la asociación de seguridad asociada (SA). 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 rutas) 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 se admite para VPN basadas en rutas y políticas. Sin embargo, el ID de varios proxy solo se admite para VPN basadas en rutas. El ID de varios proxys 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. Se define un selector de tráfico dentro de una VPN basada en rutas específica, lo que puede dar lugar a varias SA de 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 de direcciones de red (TDR-T)
El recorrido de traducción de direcciones de red (TDR-T) es un método para evitar los problemas de traducción de direcciones IP que se encuentran cuando los datos protegidos por IPsec pasan a través de un dispositivo TDR para la traducción de direcciones.
Cualquier cambio en el direccionamiento IP, que es la función de TDR, hace que IKE descarte paquetes. Después de detectar uno o más dispositivos TDR 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 de IKE y ESP dentro de UDP con el puerto 4500 utilizado como puerto de origen y destino. Debido a que los dispositivos TDR envejecen las traducciones UDP rancios, se requieren mensajes de mantención entre los pares.
La ubicación de un dispositivo TDR puede ser tal que:
Solo el iniciador IKEv1 o IKEv2 está detrás de un dispositivo TDR. Varios iniciadores pueden estar detrás de dispositivos TDR separados. Los iniciadores también pueden conectarse al responder a través de varios dispositivos TDR.
Solo el respondedor IKEv1 o IKEv2 está detrás de un dispositivo TDR.
Tanto el iniciador IKEv1 o IKEv2 como el respondedor están detrás de un dispositivo TDR.
Suites criptográficas Suite B y PRIME
La suite B es un conjunto de algoritmos criptográficos designados por la Agencia de Seguridad Nacional de ee. UU. para permitir que los productos comerciales protejan el tráfico que se clasifica en niveles secretos o de alto secreto. Los protocolos de suite B se definen en RFC 6379, Suites criptográficas de suite B para IPsec. Las suites criptográficas de Suite B proporcionan integridad y confidencialidad de la carga de seguridad de encapsulación (ESP) y deben usarse cuando se requiere tanto la protección de integridad como el cifrado de esp. El protocolo 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 de IKEv2.
Se admiten los siguientes conjuntos criptográficos:
Suite-B-GCM-128
ESP: Cifrado de estándar de cifrado avanzado (AES) con claves de 128 bits y valor de comprobación de integridad de 16 octetos (ICV) en el modo de contador de Galois (GCM).
IKE: Cifrado AES con claves de 128 bits en modo de encadenamiento de bloque de cifrado (CBC), integridad mediante autenticación SHA-256, establecimiento de claves mediante el grupo Diffie-Hellman (DH) 19 y autenticación mediante el algoritmo de firma digital de curva elíptica (ECDSA) de 256 bits.
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 autentificación mediante ECDSA de 256 bits de firmas de curva elíptica.
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 el uso de firmas de curva elíptica de 384 bits de ECDSA.
Las suites criptográficas de Suite-B son compatibles con IKEv1 y IKEv2. Las suites criptográficas PRIME solo admiten IKEv2.