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 las ICR

Intercambio de claves por red (ICR) es un protocolo de administración de claves seguras que se usa para configurar un canal de comunicaciones seguro y autenticado entre dos dispositivos.

ICR hace lo siguiente:

  • Negocia y administra los parámetros ICR e IPsec

  • Autentica el intercambio seguro de claves

  • Proporciona autenticación de par mutuo 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 especificar manualmente en los puntos de conexión).

ICR versiones anteriores

Hay dos versiones de las ICR estándares disponibles:

  • ICR versión 1 - ICR definido en rfc 2409.

  • ICR versión 2 - ICR versión 2 (IKEv2) es la última versión del protocolo ICR definido en la RFC 7296.

Intercambio de claves por red versión 2 (IKEv2) es la versión más reciente del protocolo Intercambio de claves por red (ICR) definido en RFC 7296. Intercambio de claves por red versión 2 (IKEv2) es la versión más reciente del protocolo Intercambio de claves por red (ICR) definido en RFC 7296. Una VPN peer está configurada como IKEv1 o IKEv2. Cuando un elemento del mismo nivel se configura como IKEv2, no puede recurrir a IKEv1 si su punto de conexión remoto inicia la negociación de IKEv1.

Las ventajas de usar IKEv2 sobre IKEv1 son las siguientes:

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

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

  • Aumenta la solidez frente a ataques de denegación de la 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 ninguna respuesta.

Interacción entre ICR e IPSec

IPsec puede establecer una VPN de la siguiente manera:

  • Intercambio de claves por red (ICR): IPsec admite la generación y negociación automatizadas de claves y asociaciones de seguridad mediante el ICR seguro. El ICR 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 manual de claves (ejemplo: teléfono o correo electrónico) en ambos lados para establecer VPN.

Intercambio de mensajes IKEv1

ICR negociación incluye dos fases:

  • Fase 1: negociación de intercambio de propuestas para autenticar y proteger el canal.

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

Fase 1 de la ICR de túnel

La fase 1 de una negociación de túnel Intercambio de claves por red clave automática (ICR) consiste en el intercambio de propuestas para autenticar y proteger el canal. Los participantes intercambiarán propuestas de servicios de seguridad aceptables, tales 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. Juniper Networks admiten hasta cuatro propuestas para negociaciones de fase 1, lo que le permite definir cómo restrictivo va a aceptar un rango de parámetros de seguridad para la negociación de claves. Junos OS proporciona conjuntos predefinidos de propuestas para la fase 1, compatible y estándar También puede definir propuestas personalizadas de fase 1.

Los intercambios de fase 1 pueden tener lugar en el modo principal o en el modo agresivo. Puede elegir el modo durante ICR configuración de políticas.

Este tema incluye las siguientes secciones:

Modo principal

En el modo principal, el iniciador y el destinatario envían intercambios de 3 2 (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 pseudoaleativo.

  • Tercer intercambio (mensajes 5 y 6): envía y verifica las identidades del iniciador y el 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 "sin cifrar".

Modo de borrado intenso

En el modo intenso, el iniciador y el destinatario logran los mismos objetivos que con el modo principal, pero solo en 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 pseudoaleativo y su ICR identidad.

    Cuando configure el modo intenso con varias propuestas para las negociaciones de la 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 ICR identidad 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 formato (en los dos primeros mensajes), el modo agresivo no proporciona protección de identidad.

Los modos principal y intenso solo se aplican al protocolo IKEv1. El protocolo IKEv2 no negocia el uso de los modos principal y agresivo.

Fase 2 de la ICR de túnel

Después de que los participantes han establecido un canal seguro y autenticado, avanzan en 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 se emplearán 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 una confidencialidad directa perfecta (PFS).

Independientemente del modo usado 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:

IDs de proxy

En la fase 2, los identificadores de proxy Exchange del mismo nivel. El ID de proxy se compone de un prefijo de dirección IP local y remota. El ID. de proxy de ambos interlocutores debe coincidir, lo que significa que la dirección IP local especificada para un interlocutor debe ser la misma que la dirección IP remota especificada para el otro interlocutor.

Confidencialidad directa perfecta

PFS es un método para derivar claves de fase 2 independientes de las claves anteriores y no relacionadas con estas. Como alternativa, la propuesta de fase 1 crea la clave (SKEYID_d clave) desde 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. 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 que se produzca en cada túnel de fase 2. Por lo tanto, el uso de PFS es más seguro, aunque el procedimiento de reclame 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 más tarde para inundar el sistema, causando un ataque de denegación de servicio (DoS), o para obtener acceso a la red de confianza. Junos OS proporciona una característica de protección contra reproducción que permite que los dispositivos comprueben todos los paquetes IPsec para ver si se han recibido anteriormente. Si los paquetes llegan fuera de un rango de secuencia especificado, Junos OS los rechazará. El uso de esta característica no requiere negociación, ya que los paquetes siempre se envían con números de secuencia. Sólo tiene la opción de activar o no la comprobación de los números de secuencia.

Intercambio de mensajes IKEv2

ICR versión 2 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 autenticación para asociaciones de seguridad IPsec (SA) de forma protegida.

La IKEv2 no incluye las fases 1 y 2 similares a las de IKEv1, pero se producen cuatro intercambios de mensajes para negociar un túnel IPsec con IKEv2. El intercambio de mensajes en IKEv2 es:

  • Negocia los atributos de seguridad para establecer el túnel IPsec. Esto incluye intercambiar los protocolos o 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 liveliness, eliminación de 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 de IKEv2 solo se admite con VPN basadas en rutas.

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

Reclave y reauteticación IKEv2

Con IKEv2, la regeneración de claves y la nueva autenticación son procesos independientes.

El cambio de claves establece nuevas claves para el SA (ICR Security Association) y restablece los contadores de ID de mensajes, pero no reautentica los homólogos.

La nueva autenticación comprueba que los homólogos VPN conservan su acceso a las credenciales de autenticación. La reautenticación establece claves nuevas para el ICR SA y las SA secundarias; ya no son necesarias las claves de cualquier SA pendiente ICR o SA secundaria. Después de que se crean las nuevas SA de ICR y secundarias, se eliminan el ICR antiguo y las SA secundarias.

La reautenticación de IKEv2 está deshabilitada de forma predeterminada. La reautenticación se habilita configurando un valor de frecuencia de reautenticación entre 1 y 100. La frecuencia de reautenticación es el número de reICR claves que tienen lugar antes de que se produzca una nueva autenticación. Por ejemplo, si la frecuencia configurada para la reautenticación es 1, la nueva autenticación se realiza cada vez que se produce un ICR regeneración de claves. Si la frecuencia configurada para la reautenticación es 2, la reautenticación se produce en todos los demás ICR las claves de regeneración. Si la frecuencia configurada para la reautenticación es 3, la reautenticación se produce cada tres ICR regeneración de claves, y así sucesivamente.

Fragmentación ikEv2

Cuando se usa la autenticación basada en certificados, los paquetes IKEv2 pueden superar la MTU de ruta de acceso si se transmiten varios certificados. Si el tamaño del mensaje ICR supera la unidad MTU de ruta de acceso, los mensajes se fragmentan en el nivel de IP. Algunos equipos de red, como los dispositivos TDR, no permiten que pasen los fragmentos de 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 Intercambio de claves por red versión 2 (IKEv2), permite que IKEv2 funcione en entornos en los que es posible que se bloqueen fragmentos de IP y los pares no puedan establecer una asociación de seguridad IPsec (SA). La fragmentación de IKEv2 divide un mensaje IKEv2 grande en un conjunto de otros más pequeños, de modo que no hay fragmentación en el nivel de IP. La fragmentación tiene lugar antes de que el mensaje original se cifre y se autentique, de forma que cada fragmento se cifre y se autentique por separado. En el receptor, los fragmentos se recolectan, comprueban, descifran y se combinan en el mensaje original.

Selectores de tráfico para IKEv2

Puede configurar selectores de tráfico en IKEv2 usados durante ICR negociación. Un selector de tráfico es un acuerdo entre ICR interlocutores 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. Durante la creación de túnel, se utilizan selectores de tráfico para configurar el túnel y determinar qué tráfico se permite a través del túnel.

ID de proxy

Se utiliza un ID de proxy durante la fase 2 de Intercambio de claves por red (ICR) negociaciones de red privada virtual (VPN). 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 ICR, 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 directivas. Sin embargo, el ID. de varios proxies sólo es compatible con VPN basadas en rutas. El ID. de proxy múltiple también se conoce como el selector de tráfico. Un selector de tráfico es un acuerdo entre ICR interlocutores 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. Un selector de tráfico se define dentro de una VPN basada en ruta específica, lo que puede dar como resultado varias SA de IPsec de fase 2. Solo se permite el tráfico que se ajusta a un selector de tráfico a través de una SA. Normalmente, el selector de tráfico es necesario cuando los dispositivos de puerta de enlace remota son dispositivos no Juniper Networks.

ICR de acceso (clave previamente compartida y autenticación basada en certificados)

La ICR negociación proporciona la capacidad de establecer un canal seguro mediante el cual dos partes puedan 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.

Una 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, mediante un intercambio verbal o mediante mecanismos menos seguros, incluso por correo electrónico.

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

  • La clave previamente compartida no debe usar una palabra descarado.

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

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

Las partes verifican los certificados para confirmar si están firmados por un proveedor de AC.

Las claves previamente compartidas se implementan por lo general 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 idóneos en entornos a gran escala con muchos sitios pares que no todos deberían compartir una clave previamente compartida.

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

Traducción de direcciones de red-transversal (TDR-T) es un método para evitar problemas de traducción de direcciones IP cuando los datos protegidos por IPsec pasan por un dispositivo de TDR para la traducción de direcciones.

Cualquier cambio en el direccionamiento IP, que es la función de TDR, hace que ICR descarte los 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 ICR y ESP dentro de UDP con el puerto 4500 que se utiliza como puerto de origen y destino. Dado que TDR dispositivos caducan las traducciones UDP obsoletas, es necesario disponer de mensajes de KeepAlive entre los interlocutores.

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 de TDR independientes. Los iniciadores también se pueden conectar al interlocutor que responde a través de varios dispositivos TDR.

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

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

Conjuntos criptográficos Suite B y PRIME

Suite B es un conjunto de algoritmos de cifrado designados por la Agencia de seguridad nacional de EE. UU. para permitir que los productos comerciales protejan el tráfico clasificado en los niveles secreto o secreto principal. 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 para encapsular carga de seguridad (ESP) y deben utilizarse cuando se requiere protección de integridad ESP y cifrado. Requisitos de protocolo para cifrado IP modular (PRIME), un perfil IPsec definido para redes del sector público en el Reino Unido, se basa en la serie de servicios criptográficos Suite B, pero utiliza AES-GCM en vez de AES-CBC para las negociaciones de IKEv2.

Se admiten los siguientes conjuntos criptográficos:

  • Suite-B-GCM-128

    • SENSORIAL El cifrado de la norma de cifrado avanzado (AES) con claves de 128 bits y el valor de comprobación de la integridad de 16 octetos (ICV) en el modo de contador Galois (GCM).

    • ICR: 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 con grupo Diffie-Hellman (DH) 19 y autenticación usando el algoritmo de firma digital de curva elíptica (ECDSA) 256 elíptica de bits firmas de curva.

  • Suite-B-GCM-256

    • SENSORIAL Cifrado AES con claves de 256 bits y ICV de 16 octetos en GCM para ESP.

    • ICR: Cifrado AES con claves de 256 bits en modo CBC, integridad mediante autenticación SHA-384, establecimiento de claves con el grupo DH 20 y autenticación con firmas de curvas elípticas de 384 de bits de ECDSA.

  • PRIME-128

    • SENSORIAL Cifrado AES con claves de 128 bits y ICV de 16 octetos en GCM.

    • ICR: Cifrado AES con claves de 128 bits en GCM, el establecimiento de claves con el grupo DH 19 y la autenticación con firmas de curvas elípticas de 256 bits de ECDSA.

  • PRIME-256

    • SENSORIAL Cifrado AES con claves de 256 bits y ICV de 16 octetos en GCM para ESP.

    • ICR: Cifrado AES con claves de 256 bits en GCM, el establecimiento de claves con el grupo DH 20 y la autenticación con firmas de curvas elípticas de 384 bits de ECDSA.

Los conjuntos criptográficos Suite-B son compatibles con IKEv1 e IKEv2. Los conjuntos criptográficos PRIMOs solo admiten IKEv2.