En informática, el intercambio de claves de Internet ( IKE , a veces IKEv1 o IKEv2 , según la versión) es el protocolo utilizado para configurar una asociación de seguridad (SA) en el conjunto de protocolos IPsec . IKE se basa en el protocolo Oakley y ISAKMP . [1] IKE utiliza certificados X.509 para la autenticación, ya sea precompartidos o distribuidos mediante DNS (preferiblemente con DNSSEC ), y un intercambio de claves Diffie-Hellman para configurar un secreto de sesión compartido desde el cual las claves criptográficasson derivados. [2] [3] Además, se debe mantener manualmente una política de seguridad para cada par que se conecte. [2]
Historia
El Grupo de trabajo de ingeniería de Internet (IETF) originalmente definió IKE en noviembre de 1998 en una serie de publicaciones ( Solicitud de comentarios ) conocidas como RFC 2407, RFC 2408 y RFC 2409:
- RFC 2407 definió el dominio de interpretación de seguridad IP de Internet para ISAKMP. [4]
- RFC 2408 definió el Protocolo de administración de claves y asociación de seguridad de Internet (ISAKMP). [5]
- RFC 2409 definió el intercambio de claves de Internet (IKE). [6]
RFC 4306 actualizó IKE a la versión dos (IKEv2) en diciembre de 2005. [7] RFC 4718 aclaró algunos detalles abiertos en octubre de 2006. [8] RFC 5996 combinó estos dos documentos más aclaraciones adicionales en el IKEv2 actualizado, [9] publicado en septiembre 2010. Una actualización posterior actualizó el documento de Proposed Standard a Internet Standard , publicado como RFC 7296 en octubre de 2014.
La organización matriz del IETF, The Internet Society (ISOC), ha mantenido los derechos de autor de estos estándares disponibles gratuitamente para la comunidad de Internet.
Arquitectura
La mayoría de las implementaciones de IPsec constan de un demonio IKE que se ejecuta en el espacio del usuario y una pila de IPsec en el kernel que procesa los paquetes IP reales .
Los daemons de espacio de usuario tienen fácil acceso al almacenamiento masivo que contiene información de configuración, como las direcciones de punto final IPsec, claves y certificados, según sea necesario. Los módulos del kernel, por otro lado, pueden procesar paquetes de manera eficiente y con una sobrecarga mínima, lo cual es importante por razones de rendimiento.
El protocolo IKE usa paquetes UDP , generalmente en el puerto 500, y generalmente requiere de 4 a 6 paquetes con 2 o 3 viajes de ida y vuelta para crear una SA (asociación de seguridad) en ambos lados. A continuación, el material de claves negociado se entrega a la pila de IPsec. Por ejemplo, esto podría ser una clave AES , información que identifica los puntos finales IP y los puertos que deben protegerse, así como el tipo de túnel IPsec que se ha creado. La pila IPsec, a su vez, intercepta los paquetes IP relevantes si es apropiado y realiza el cifrado / descifrado según sea necesario. Las implementaciones varían en la forma en que se realiza la interceptación de los paquetes; por ejemplo, algunos usan dispositivos virtuales, otros eliminan una parte del firewall, etc.
IKEv1 consta de dos fases: fase 1 y fase 2. [10]
Fases IKEv1
El propósito de la fase uno de IKE es establecer un canal de comunicación autenticado seguro mediante el uso del algoritmo de intercambio de claves Diffie-Hellman para generar una clave secreta compartida para cifrar las comunicaciones IKE adicionales. Esta negociación da como resultado una única asociación de seguridad ISAKMP bidireccional (SA). [11] La autenticación se puede realizar utilizando una clave previamente compartida (secreto compartido), firmas o cifrado de clave pública. [12] La fase 1 funciona en modo principal o en modo agresivo. El modo principal protege la identidad de los pares y el hash de la clave compartida cifrándolos; El modo agresivo no lo hace. [10]
Durante la fase dos de IKE, los pares de IKE utilizan el canal seguro establecido en la fase 1 para negociar asociaciones de seguridad en nombre de otros servicios como IPsec . La negociación da como resultado un mínimo de dos asociaciones de seguridad unidireccionales (una entrante y otra saliente). [13] La fase 2 funciona solo en el modo rápido. [10]
Problemas con IKE
Originalmente, IKE tenía numerosas opciones de configuración, pero carecía de una función general para la negociación automática de un caso predeterminado bien conocido que se implementa universalmente. En consecuencia, ambos lados de un IKE tenían que acordar exactamente el tipo de asociación de seguridad que querían crear, opción por opción, o no se podía establecer una conexión. Surgieron más complicaciones por el hecho de que en muchas implementaciones la salida de depuración era difícil de interpretar, si es que existía alguna facilidad para producir salida de diagnóstico.
Las especificaciones IKE estaban abiertas a un grado significativo de interpretación, bordeando fallas de diseño ( Dead-Peer-Detection es un caso en el punto [ cita requerida ] ), dando lugar a diferentes implementaciones IKE que no pueden crear una asociación de seguridad acordada en absoluto para muchas combinaciones de opciones, sin importar cómo estén configuradas correctamente, pueden aparecer en cualquier extremo.
Mejoras con IKEv2
El protocolo IKEv2 se describió en el Apéndice A de RFC 4306 en 2005. Se abordaron los siguientes problemas:
- Menos solicitudes de comentarios (RFC): las especificaciones para IKE se cubrieron en al menos tres RFC, más si se tiene en cuenta el cruce de NAT y otras extensiones que son de uso común. IKEv2 combina estos en un RFC , además de realizar mejoras en la compatibilidad con el cruce de NAT ( traducción de direcciones de red (NAT)) y el cruce de firewall en general.
- Soporte de movilidad estándar: Hay una extensión estándar para IKEv2 denominada [rfc: 4555 Mobility and Multihoming Protocol] (MOBIKE) (ver también, IPsec ) que se utiliza para admitir movilidad y multihoming para él y Encapsulating Security Payload (ESP). Mediante el uso de esta extensión, IKEv2 e IPsec pueden ser utilizados por usuarios móviles y de múltiples hosts.
- NAT transversal : la encapsulación de IKE y ESP en el Protocolo de datagramas de usuario (puerto UDP 4500) permite que estos protocolos pasen a través de un dispositivo o firewall que realiza NAT . [14]
- Compatibilidad con el protocolo de transmisión de control de flujo (SCTP): IKEv2 permite el protocolo SCTP como se usa en el protocolo de telefonía de Internet, Voz sobre IP (VoIP).
- Intercambio de mensajes simple: IKEv2 tiene un mecanismo de intercambio inicial de cuatro mensajes donde IKE proporcionó ocho mecanismos de intercambio inicial claramente diferentes, cada uno de los cuales tenía leves ventajas y desventajas.
- Menos mecanismos criptográficos: IKEv2 usa mecanismos criptográficos para proteger sus paquetes que son muy similares a los que usa IPsec ESP para proteger los paquetes IPsec. Esto condujo a implementaciones y certificaciones más simples para Common Criteria y FIPS 140-2 ( Estándar federal de procesamiento de información (FIPS), que requieren que cada implementación criptográfica sea validada por separado.
- Fiabilidad y gestión de estado: IKEv2 utiliza números de secuencia y reconocimientos para proporcionar fiabilidad y exige cierta logística de procesamiento de errores y gestión de estado compartida. IKE podría terminar en un estado muerto debido a la falta de tales medidas de confiabilidad, donde ambas partes esperaban que la otra iniciara una acción, que nunca llegó a suceder. Se desarrollaron soluciones alternativas (como Dead-Peer-Detection ) pero no se estandarizaron. Esto significaba que las diferentes implementaciones de soluciones alternativas no siempre eran compatibles.
- Resistencia al ataque de denegación de servicio (DoS): IKEv2 no realiza mucho procesamiento hasta que determina si el solicitante realmente existe. Esto solucionó algunos de los problemas de DoS que sufría IKE, que realizarían una gran cantidad de procesamiento criptográfico costoso desde ubicaciones falsificadas .
- Suponiendo que HostA tiene un índice de parámetros de seguridad (SPI) de
A
y HostB tiene un SPI deB
, el escenario se vería así:
HostA ------------------------------------------------- - HostB | HDR (A, 0), sai1, kei, Ni --------------------------> | | <---------------------------- HDR (A, 0), N (cookie) | | HDR (A, 0), N (galleta), sai1, kei, Ni ----------------> | | <-------------------------- HDR (A, B), SAr1, ker, Nr |
- Si HostB (el respondedor) está experimentando grandes cantidades de conexiones IKE medio abiertas, enviará un mensaje de respuesta no cifrado
IKE_SA_INIT
al HostA (el iniciador) con un mensaje de notificación del tipoCOOKIE
, y esperará que HostA envíe unaIKE_SA_INIT
solicitud con ese valor de cookie en una carga útil de notificación a HostB . Esto es para asegurar que el iniciador sea realmente capaz de manejar una respuesta IKE del respondedor.
Extensiones de protocolo
El grupo de trabajo IETF ipsecme ha estandarizado una serie de extensiones, con el objetivo de modernizar el protocolo IKEv2 y adaptarlo mejor a entornos de producción de alto volumen. Estas extensiones incluyen:
- Reanudación de la sesión IKE : la capacidad de reanudar una "sesión" IKE / IPsec fallida después de una falla, sin la necesidad de pasar por todo el proceso de configuración de IKE (RFC 5723).
- Redireccionamiento de IKE : redireccionamiento de solicitudes IKE entrantes, lo que permite un equilibrio de carga simple entre varios puntos finales IKE (RFC 5685).
- Visibilidad del tráfico IPsec : etiquetado especial de paquetes ESP que están autenticados pero no cifrados, con el objetivo de facilitar a los intermediarios (como los sistemas de detección de intrusos ) el análisis del flujo (RFC 5840).
- Autenticación EAP mutua : compatibilidad con la autenticación EAP únicamente (es decir, sin certificado) de ambos pares IKE; el objetivo es permitir el uso de métodos modernos de autenticación basados en contraseñas (RFC 5998).
- Detección rápida de fallas : minimiza el tiempo hasta que un par IKE detecta que su par opuesto ha fallado (RFC 6290).
- Extensiones de alta disponibilidad : mejora de la sincronización del protocolo de nivel IKE / IPsec entre un clúster de puntos finales IPsec y un par, para reducir la probabilidad de que se caigan las conexiones después de un evento de conmutación por error (RFC 6311).
Implementaciones
IKE es compatible como parte de la implementación de IPsec en Windows 2000 , Windows XP , Windows Server 2003 , Windows Vista y Windows Server 2008 . [15] La implementación de ISAKMP / IKE fue desarrollada conjuntamente por Cisco y Microsoft. [dieciséis]
Microsoft Windows 7 y Windows Server 2008 R2 admiten parcialmente IKEv2 (RFC 7296) y MOBIKE (RFC 4555) a través de la función de reconexión de VPN (también conocida como Agile VPN ).
Hay varias implementaciones de código abierto de IPsec con capacidades IKE asociadas. En Linux , las implementaciones de Libreswan , Openswan y strongSwan proporcionan un demonio IKE que puede configurar (es decir, establecer SA) para las pilas de IPsec basadas en kernel KLIPS o XFRM / NETKEY. XFRM / NETKEY es la implementación de IPsec nativa de Linux disponible a partir de la versión 2.6.
Las distribuciones de software de Berkeley también tienen una implementación de IPsec y un demonio IKE y, lo que es más importante, un marco criptográfico ( OpenBSD Cryptographic Framework , OCF), que hace que el soporte de aceleradores criptográficos sea mucho más fácil. OCF se ha portado recientemente a Linux.
Un número significativo de proveedores de equipos de red ha creado sus propios demonios IKE (e implementaciones de IPsec) o se han otorgado licencias de pila entre sí.
Hay una serie de implementaciones de IKEv2 y algunas de las empresas que se ocupan de la certificación IPsec y las pruebas de interoperabilidad están comenzando a realizar talleres para las pruebas, así como los requisitos de certificación actualizados para hacer frente a las pruebas IKEv2.
Las siguientes implementaciones de código abierto de IKEv2 están disponibles actualmente:
- OpenIKEv2 ,
- StrongSwan ,
- Libreswan ,
- Openswan ,
- Racoon del proyecto KAME ,
- iked del proyecto OpenBSD .,
- Software VPN Rockhopper
Vulnerabilidades
Las presentaciones filtradas de la NSA publicadas por Der Spiegel indican que IKE está siendo explotado de una manera desconocida para descifrar el tráfico IPSec, al igual que ISAKMP . [17] Los investigadores que descubrieron el ataque Logjam afirman que romper un grupo Diffie-Hellman de 1024 bits rompería el 66% de los servidores VPN, el 18% del millón de dominios HTTPS superiores y el 26% de los servidores SSH, que según los investigadores es coherente con las fugas. [18] Esta afirmación fue refutada tanto por Eyal Ronen como por Adi Shamir en su artículo "Critical Review of Imperfect Forward Secrecy" [19] y por Paul Wouters de Libreswan en un artículo "El 66% de las VPN no están rotas" [20] ]
Las configuraciones de VPN IPSec que permiten la negociación de múltiples configuraciones están sujetas a ataques de degradación basados en MITM entre las configuraciones ofrecidas, tanto con IKEv1 como con IKEv2. [21] Esto puede evitarse mediante una cuidadosa segregación de los sistemas cliente en múltiples puntos de acceso a servicios con configuraciones más estrictas.
Ambas versiones del estándar IKE son susceptibles a un ataque de diccionario fuera de línea cuando se usa una contraseña de baja entropía. Para IKEv1, esto es cierto para el modo principal y el modo agresivo. [22] [23] [24]
Ver también
- IPsec
- Protocolo de acuerdo de claves
- Dominio grupal de interpretación
- Negociación Kerberizada de Claves por Internet
- Red de computadoras
Referencias
- ^ El intercambio de claves de Internet (IKE), RFC 2409, §1 Resumen
- ^ a b RFC 3129: Requisitos para la negociación de claves en Internet kerberizada , Grupo de trabajo de ingeniería de Internet , junio de 2001, p. 1
- ^ RFC 4322: Cifrado oportunista mediante el intercambio de claves de Internet (IKE) , Grupo de trabajo de ingeniería de Internet , junio de 2001, p. 5
- ^ "RFC 2407 El dominio de interpretación de seguridad IP de Internet para ISAKMP" . Grupo de trabajo de ingeniería de Internet (IETF).
- ^ "Protocolo de administración de claves y asociación de seguridad de Internet RFC 2408 (ISAKMP)" . Grupo de trabajo de ingeniería de Internet (IETF).
- ^ D. Harkins. "RFC 2409 El intercambio de claves de Internet (IKE)" . Grupo de trabajo de ingeniería de Internet (IETF).
- ^ C. Kaufman (Microsoft) (diciembre de 2005). "Protocolo de intercambio de claves de Internet RFC 4306 (IKEv2)" . Grupo de trabajo de ingeniería de Internet (IETF).
- ^ Eronen, P .; Hoffman, P. (octubre de 2006). "RFC 4718 IKEv2 Aclaraciones y directrices de implementación" . Grupo de trabajo de ingeniería de Internet (IETF).
- ^ Kaufman, C .; Hoffman, P .; Nir, Y .; Eronen, P. (septiembre de 2010). "Protocolo de intercambio de claves de Internet RFC 5996 (IKEv2)" . Grupo de trabajo de ingeniería de Internet (IETF).
- ^ a b c "RFC 2409 El intercambio de claves de Internet (IKE)", Grupo de trabajo de ingeniería de Internet (IETF), p. 5
- ^ "RFC 2409 El intercambio de claves de Internet (IKE)", Grupo de trabajo de ingeniería de Internet (IETF), p. 6
- ^ "RFC 2409 El intercambio de claves de Internet (IKE)", Grupo de trabajo de ingeniería de Internet (IETF), p. 10-16
- ^ "Protocolo de intercambio de claves de Internet RFC 4306 (IKEv2)", Grupo de trabajo de ingeniería de Internet (IETF), p. 11,33
- ^ "RFC 4306: Protocolo de intercambio de claves de Internet (IKEv2)", Grupo de trabajo de ingeniería de Internet (IETF), p 38-40
- ^ Intercambio de claves de Internet: Seguridad del protocolo de Internet (IPsec): Technet
- ^ Uso de IPSec en Windows 2000 y XP, parte 1
- ^ Capacidad de campo: Revisión de diseño de VPN SPIN9 de extremo a extremo (PDF) , NSA a través de 'Der Spiegel', p. 5
- ^ Adrián, David; Bhargavan, Karthikeyan; Durumeric, Zakir; Gaudry, Pierrick; Green, Matthew; Halderman, J. Alex; Heninger, Nadia ; Springall, Drew; Thomé, Emmanuel; Valenta, Luke; VanderSloot, Benjamin; Wustrow, Eric; Zanella-Béguelin, Santiago; Zimmermann, Paul (octubre de 2015). Secreto imperfecto hacia adelante: cómo falla Diffie-Hellman en la práctica (PDF) . 22ª Conferencia de la ACM sobre seguridad informática y de las comunicaciones (CCS '15). Denver . Consultado el 15 de junio de 2016 .
- ^ Ronen, Eyal; Shamir, Adi (octubre de 2015). "Revisión crítica del secreto hacia adelante imperfecto" (PDF) . Cite journal requiere
|journal=
( ayuda ) - ^ Wouters, Paul (octubre de 2015). "El 66% de las VPN no están rotas" .
- ^ Bhargavan, Karthikeyan; Brzuska, Christina; Fournet, Cédric; Kohlweiss, Markulf; Zanella-Béguelin, Santiago; Green, Matthew (enero de 2016). "Reducir la resiliencia en los protocolos de intercambio de claves" (PDF) .
- ^ Pliam, John (2 de octubre de 1999). "Vulnerabilidades de autenticación en IKE y Xauth con secretos débiles precompartidos" . Universidad Johns Hopkins . Archivado desde el original el 10 de junio de 2002 . Consultado el 5 de febrero de 2020 .
- ^ McGrew, David (5 de julio de 2011). "Gran cifrado, pero de dónde sacaste esa clave" . Blog de Cisco . Archivado desde el original el 9 de julio de 2011 . Consultado el 11 de febrero de 2020 .
- ^ Felsch, Dennis (agosto de 2018). "Los peligros de la reutilización de claves: ataques prácticos en IPsec IKE" . 27º Simposio de Seguridad de USENIX . Consultado el 11 de febrero de 2020 .
enlaces externos
- RFC 2407 Protocolo de administración de claves y asociación de seguridad de Internet (ISAKMP) , Grupo de trabajo de ingeniería de Internet (IETF)
- RFC 2409 Intercambio de claves de Internet (IKE) , Grupo de trabajo de ingeniería de Internet (IETF)
- RFC 7296: Protocolo de intercambio de claves de Internet versión 2 (IKEv2) , Grupo de trabajo de ingeniería de Internet (IETF)
- Descripción general de IKE (de Cisco)