Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Intercambio de claves por red

Introducción a IKE

El intercambio de claves por red (IKE) es un protocolo de administración de claves segura que se utiliza para configurar un canal de comunicaciones 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 autenticación mutua por pares mediante 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 introducir manualmente en los puntos de conexión).

Versiones de IKE

Hay dos versiones de los estándares de 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.

El intercambio de claves por red versión 2 (IKEv2) es la última versión del protocolo de intercambio de claves por red (IKE) definido en RFC 7296. El intercambio de claves por red versión 2 (IKEv2) es la última versión del protocolo de intercambio de claves por red (IKE) definido en RFC 7296. Un par VPN se configura como IKEv1 o IKEv2. Cuando un par se configura como IKEv2, no puede volver a IKEv1 si su par remoto inicia la negociación IKEv1.

Las ventajas de usar IKEv2 sobre IKEv1 son las siguientes:

  • Reemplaza ocho intercambios iniciales por un único intercambio de cuatro mensajes.

  • Reduce la latencia para la configuración de SA de IPsec y aumenta la velocidad del establecimiento de la conexión.

  • Aumenta la solidez contra los ataques 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 ICR 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 e intercambio de claves manualmente (por ejemplo: teléfono o correo electrónico) en ambos lados para establecer VPN.

Intercambio de mensajes IKEv1

La negociación de ICR incluye dos fases:

  • Fase 1: negocia el intercambio de propuestas para autenticar y proteger el canal.

  • Fase 2: negocie asociaciones de seguridad (SA) para proteger los datos que atraviesan el túnel IPsec.

Fase 1 de negociación de túnel IKE

La fase 1 de una negociación de túnel de intercambio de claves por red (IKE) de clave automática consiste en el intercambio de propuestas para cómo autenticar y proteger el canal. Los participantes intercambian propuestas de servicios de seguridad aceptables como:

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, luego, procesarlos. Los dispositivos de Juniper Networks admiten hasta cuatro propuestas para negociaciones de fase 1, lo que le permite definir cómo restrictivo un rango de parámetros de seguridad para la negociación de claves que aceptará. Junos OS ofrece conjuntos de propuestas de fase 1 predefinidos, compatibles y básicos. 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 la política 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 lograr 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 "de manera 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 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 porque el grupo DH no se puede negociar. 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 usa certificados, el certificado del destinatario.

  • Tercer mensaje: el iniciador autentica al destinatario, confirma el intercambio y, si usa certificados, envía el certificado del iniciador.

Dado que las identidades de los participantes se intercambian de forma clara (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 modos principales y agresivos.

Fase 2 de negociación de túnel IKE

Después de que los participantes han establecido un canal seguro y autenticado, pasan por 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 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 (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 la 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 consta de un prefijo de dirección IP local y remota. El ID de proxy para 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. 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 para cada túnel de fase 2. Por lo tanto, el uso de PFS es más seguro, aunque el procedimiento de rekeying en la fase 2 podría 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 posteriormente para inundar el sistema, lo que provoca una denegación de servicio (DoS) o para obtener entrada a la red de confianza. Junos OS ofrece 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 intervalo 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 comprobar los números de secuencia.

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 par y define la negociación y la autenticación para asociaciones de seguridad IPsec (SA) 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 el intercambio de protocolos/parámetros utilizados y 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 la vida real, la eliminación de las relaciones de SA y la generación de mensajes de error.

Carga de configuración 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 IKEv2 solo se admite con VPN basadas en rutas.

RFC 5996, Protocolo de intercambio de claves por red versión 2 (IKEv2), define 15 atributos de configuración diferentes que el respondedor puede devolver al iniciador.

Reenclave y reautorización IKEv2

Con IKEv2, la reenclave y la autentificación son procesos independientes.

La reintroducción de claves 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 a los pares.

La reautorización verifica que los pares vpn conserven su acceso a las credenciales de autenticación. La reautorización establece nuevas claves para la SA de IKE y las SA secundarias; ya no se necesitan las reclaves de cualquier SA O SA de IKE pendiente o secundaria. Después de crear las nuevas SA IKE y secundarias, se eliminan las SA IKE y secundarias antiguas.

La autenticación de IKEv2 está deshabilitada de forma predeterminada. Habilite la reautenticación configurando un valor de frecuencia de reautorización entre 1 y 100. La frecuencia de reautorización es el número de reclaves de IKE que se produce antes de que se produzca la reautorización. Por ejemplo, si la frecuencia de reautorización configurada es 1, la reautorización se produce cada vez que hay una reclave de IKE. Si la frecuencia de reautorización configurada es 2, la reautorización se produce en cada otra clave de IKE. Si la frecuencia de reautorización configurada es 3, la reautorización se produce en cada tercera reclave de IKE, y así sucesivamente.

Fragmentación 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 IKE supera la MTU de ruta, los mensajes se fragmentan en el nivel ip. Algunos equipos de red, como los dispositivos TDR, no permiten el paso de fragmentos ip, lo que impide el establecimiento de túneles IPsec.

La fragmentación de mensajes IKEv2, tal como se describe en RFC 7383, fragmentación de mensajes del protocolo de intercambio de claves por red versión 2 (IKEv2), permite que IKEv2 funcione en entornos en los que se podrían bloquear fragmentos ip y los pares no podrían establecer una asociación de seguridad IPsec (SA). La fragmentación IKEv2 divide un mensaje IKEv2 grande en un conjunto de 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 cifra y autentica, 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 ajusta a un selector de tráfico mediante 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

Un ID de proxy se utiliza durante la fase 2 de las negociaciones de la red privada virtual (VPN) del 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 utilizan 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 basadas en políticas. Sin embargo, el ID de multi proxy solo se admite para VPN basadas en rutas. El ID de multi proxy 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 específica basada en rutas, lo que puede dar como resultado 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.

Autenticación IKE (clave previamente compartida y autenticación basada en certificados)

Las negociaciones de ICR ofrecen la capacidad de establecer un canal seguro sobre el cual dos partes pueden comunicarse. Puede definir cómo las dos partes se autentican entre sí mediante una autenticación de clave previamente compartida o una autenticación basada en certificados.

Autenticación de clave previamente compartida

Autenticación basada en certificados

Forma común de establecer una conexión VPN.

Forma segura de establecer una conexión VPN.

  • La clave previamente compartida es una contraseña que es la misma para ambas partes. Esta contraseña se intercambia de antemano mediante un teléfono, a través de un intercambio verbal, o a través de mecanismos menos seguros, incluso correo electrónico.

  • La clave previamente compartida debe estar formada por al menos 8 caracteres (se recomienda 12 o más) mediante una combinación de letras, números y caracteres no alfanuméricos, junto con diferentes casos para las letras.

  • La clave previamente compartida no debe usar una palabra de diccionario.

Los certificados se componen de una clave pública y privada, y se pueden firmar con un certificado principal conocido como autoridad de certificación (CA)

Las partes se autentican entre sí mediante el cifrado de la clave previamente compartida con la clave pública del par, que se obtiene en el intercambio Diffie-Hellman.

Las partes comprueban los certificados para confirmar si están firmados por una CA de confianza.

Las claves previamente compartidas se implementan comúnmente para VPN IPsec de sitio a sitio, ya sea dentro de una sola organización o entre diferentes organizaciones.

Los certificados también son mucho más ideales en entornos de mayor escala con numerosos sitios par que no todos deben compartir una clave previamente compartida.

Traducción-traversal de direcciones de red (TDR-T)

El traversal de direcciones de red (TDR-T) es un método para solucionar los problemas de traducción de direcciones IP que se producen cuando los datos protegidos por IPsec pasan a través de un dispositivo TDR para la traducción de direcciones.

Cualquier cambio en la dirección 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, TDR-T agrega una capa de encapsulación del protocolo de datagrama de usuario (UDP) a los paquetes IPsec para que no se descarten después de la traducción de direcciones. TDR-T encapsula el tráfico de IKE y ESP dentro de UDP con el puerto 4500 utilizado como puerto de origen y destino. Dado que los dispositivos TDR agotan las traducciones UDP obsoletas, se requieren mensajes de keepalive 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 independientes. Los iniciadores también pueden conectarse al respondedor a través de varios dispositivos TDR.

  • Solo el respondedor IKEv1 o IKEv2 está detrás de un dispositivo TDR.

  • El iniciador IKEv1 o IKEv2 y el respondedor están detrás de un dispositivo TDR.

Suites criptográficas Suite B y PRIME

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, Suite B Cryptographic Suites for IPsec. Los conjuntos criptográficos de Suite B proporcionan integridad y confidencialidad de carga de seguridad de encapsulación (ESP) y se deben usar cuando se requiera protección de integridad ESP y cifrado. Los requisitos de protocolo para el cifrado modular IP (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 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 de 16 octetos (ICV) en el modo 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 Diffie-Hellman (DH) 19 y autenticación mediante el algoritmo de firma digital de curva elíptica (ECDSA) firmas de curva elíptica de 256 bits.

  • Suite-B-GCM-256

    • ESP: Cifrado AES con claves de 256 bits y 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 y 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 y 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 de 384 bits ECDSA.

Las suites criptográficas Suite-B son compatibles con IKEv1 y IKEv2. Los conjuntos criptográficos PRIME solo admiten IKEv2.