Hispanopedia Wiki
Articulo de referencia

Intercambio de claves de Internet

En informática, el Intercambio de Claves de Internet ( IKE , versionado como IKEv1 e IKEv2 ) es el protocolo utilizado para establecer una asociación de seguridad (SA) en el con...

Hispanopedia WikiContenido en espanolLectura gratuita

En informática, el Intercambio de Claves de Internet ( IKE , versionado como IKEv1 e IKEv2 ) es el protocolo utilizado para establecer una asociación de seguridad (SA) en el conjunto de protocolos IPsec . IKE se basa en el protocolo Oakley e 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 establecer un secreto de sesión compartido a partir del cual se derivan las claves criptográficas . [ 2 ] [ 3 ] Actualmente se está redactando un borrador de la IETF para proporcionar un establecimiento de clave resistente a la computación cuántica mediante ML-KEM . [ 4 ] Además, se debe mantener manualmente una política de seguridad para cada par que se conectará. [ 2 ]

Historia

El Grupo de Trabajo de Ingeniería de Internet (IETF) definió originalmente 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. [ 5 ] 
  • RFC 2408 definió el Protocolo de administración de claves y asociación de seguridad de Internet (ISAKMP). [ 6 ] 
  • RFC 2409 definió el Intercambio de Claves de Internet (IKE). [ 7 ] 

RFC 4306 actualizó IKE a la versión dos (IKEv2) en diciembre de 2005. [ 8 ] RFC 4718 aclaró algunos detalles abiertos en octubre de 2006. [ 9 ] RFC 5996 combinó estos dos documentos más aclaraciones adicionales en la versión actualizada de IKEv2, [ 10 ] publicada en septiembre de 2010. Una actualización posterior elevó el documento de Estándar Propuesto a Estándar de Internet , publicado como RFC 7296 en octubre de 2014.    

La organización matriz del IETF, la Internet Society (ISOC), ha mantenido los derechos de autor de estas normas, poniéndolas a disposición de la comunidad de Internet de forma gratuita.

Arquitectura

La mayoría de las implementaciones de IPsec constan de un demonio IKE que se ejecuta en el espacio de usuario y una pila IPsec en el núcleo que procesa los paquetes IP propiamente dichos.

Los demonios del espacio de usuario tienen fácil acceso al almacenamiento masivo que contiene información de configuración, como las direcciones de los puntos finales IPsec, las claves y los 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 utiliza paquetes UDP , generalmente en el puerto 500, y suele requerir de 4 a 6 paquetes con 2 a 3 viajes de ida y vuelta para crear una asociación de seguridad (SA) ISAKMP en ambos extremos. El material de clave negociado se entrega a la pila IPsec. Por ejemplo, podría tratarse de una clave AES , información que identifique los puntos finales IP y los puertos que se van a proteger, así como el tipo de túnel IPsec creado. La pila IPsec, a su vez, intercepta los paquetes IP pertinentes cuando corresponde y realiza el cifrado/descifrado según sea necesario. Las implementaciones varían en cuanto a cómo se realiza la interceptación de los paquetes; por ejemplo, algunas utilizan dispositivos virtuales, otras acceden a una porción del firewall, etc.

IKEv1 consta de dos fases: fase 1 y fase 2. [ 11 ]

Fases de IKEv1

El propósito de la primera fase de IKE es establecer un canal de comunicación seguro y autenticado mediante el algoritmo de intercambio de claves Diffie-Hellman para generar una clave secreta compartida que encripta las comunicaciones IKE posteriores. Esta negociación da como resultado una única asociación de seguridad ISAKMP bidireccional. [ 12 ] La autenticación puede realizarse mediante clave precompartida (clave secreta compartida), firmas o cifrado de clave pública. [ 13 ] La fase 1 opera en modo principal o en modo agresivo. El modo principal protege la identidad de los pares y el hash de la clave compartida encriptando dichos datos; el modo agresivo no lo hace. [ 11 ]

Durante la fase dos de IKE, los pares 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 de entrada y una de salida). [ 14 ] La fase 2 opera solo en modo rápido. [ 11 ]

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 compatible universalmente. Como resultado, ambos extremos debían coincidir exactamente en cada parámetro de la asociación de seguridad —como algoritmos de cifrado, métodos de intercambio de claves y tiempos de vida— o la conexión fallaría. Esto provocó frecuentes problemas de interoperabilidad entre las implementaciones de diferentes proveedores. [ 15 ] [ 16 ] La resolución de problemas se complicaba aún más debido a la información de depuración limitada o críptica en muchas implementaciones. [ 17 ]

Las especificaciones de IKEv1 también permitían un grado significativo de interpretación, a veces rozando fallos de diseño. Un ejemplo es la detección de pares inactivos (DPD), que se implementó de forma inconsistente entre los distintos proveedores. Incluso con configuraciones correctamente coincidentes, esto podía provocar fallos de negociación o caídas de túneles. [ 18 ]

Mejoras con IKEv2

El protocolo IKEv2 se describió en el Apéndice A del RFC 4306 en 2005. Se abordaron los siguientes temas:

  • Menos solicitudes de comentarios (RFC): Las especificaciones de IKE se detallaban en al menos tres RFC, e incluso más si se tienen en cuenta la traducción de direcciones de red (NAT) y otras extensiones de uso común. IKEv2 las combina en una sola RFC, además de mejorar la compatibilidad con la traducción de direcciones de red ( NAT) y la superación de cortafuegos en general.
  • Compatibilidad con movilidad estándar: Existe una extensión estándar para IKEv2 denominada [rfc:4555 Mobility and Multihoming Protocol] (MOBIKE) (véase también IPsec ) que permite la movilidad y la multiconexión, así como la encapsulación de la carga útil de seguridad (ESP). Mediante esta extensión, los usuarios móviles y con múltiples conexiones pueden utilizar IKEv2 e IPsec .
  • Travesía de NAT : La encapsulación de IKE y ESP en el Protocolo de datagramas de usuario (puerto UDP 4500) permite que estos protocolos atraviesen un dispositivo o cortafuegos que realiza NAT . [ 19 ]
  • Compatibilidad con el protocolo de transmisión de control de flujo (SCTP): IKEv2 permite el uso del protocolo SCTP , tal como se utiliza en el protocolo de telefonía por Internet, Voz sobre IP (VoIP).
  • Intercambio de mensajes sencillo: IKEv2 tiene un mecanismo de intercambio inicial de cuatro mensajes, mientras que IKE proporcionaba ocho mecanismos de intercambio inicial distintos, cada uno con ligeras ventajas y desventajas.
  • Menos mecanismos criptográficos: IKEv2 utiliza mecanismos criptográficos para proteger sus paquetes que son muy similares a los que utiliza IPsec ESP para proteger los paquetes IPsec. Esto dio lugar a implementaciones y certificaciones más sencillas para los Criterios Comunes y FIPS 140-2 ( Estándar Federal de Procesamiento de Información (FIPS), que requieren que cada implementación criptográfica se valide por separado.
  • Fiabilidad y gestión del estado: IKEv2 utiliza números de secuencia y acuses de recibo para garantizar la fiabilidad, e incluye cierta logística de procesamiento de errores y gestión compartida del estado. IKE podría quedar inactivo debido a la falta de estas medidas de fiabilidad, donde ambas partes esperarían que la otra iniciara una acción, lo cual nunca ocurrió. Se desarrollaron soluciones alternativas (como la detección de pares inactivos ), pero no se estandarizaron. Esto significaba que las diferentes implementaciones de estas soluciones no siempre eran compatibles.
  • Resistencia a ataques de denegación de servicio (DoS): IKEv2 no realiza mucho procesamiento hasta que determina si el solicitante existe realmente. Esto solucionó algunos de los problemas de DoS que sufría IKE, que realizaba un procesamiento criptográfico costoso desde ubicaciones falsificadas .
Suponiendo que HostA tiene un índice de parámetros de seguridad (SPI) de Ay HostB tiene un SPI de B, 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) experimenta una gran cantidad de conexiones IKE semiabiertas, enviará un mensaje de respuesta sin cifrar IKE_SA_INITa HostA (el iniciador) con un mensaje de notificación de tipo COOKIE, y esperará que HostA envíe una IKE_SA_INITsolicitud 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 ipsecme de la IETF 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 sesión IKE : la capacidad de reanudar una "sesión" IKE/IPsec fallida después de un fallo, sin necesidad de pasar por todo el proceso de configuración de IKE ( RFC 5723 ). 
  • Redirección IKE : redirección de las solicitudes IKE entrantes, lo que permite un equilibrio de carga simple entre múltiples 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 dispositivos intermedios (como los sistemas de detección de intrusiones ) el análisis del flujo ( RFC 5840 ). 
  • Autenticación EAP mutua : admite la autenticación solo con EAP (es decir, sin certificado) de ambos pares IKE; el objetivo es permitir el uso de métodos de autenticación modernos basados ​​en contraseñas ( RFC 5998 ). 
  • Detección rápida de fallos : minimizar 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 a nivel IKE/IPsec entre un grupo 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. [ 20 ] La implementación ISAKMP/IKE fue desarrollada conjuntamente por Cisco y Microsoft. [ 21 ]

Microsoft Windows 7 y Windows Server 2008 R2 admiten parcialmente IKEv2 ( RFC 7296 ) y MOBIKE ( RFC 4555 ) a través de la función VPN Reconnect (también conocida como Agile VPN ).  

Existen varias implementaciones de código abierto de IPsec con capacidades IKE asociadas. En Linux , las implementaciones Libreswan , Openswan y strongSwan proporcionan un demonio IKE que puede configurar (es decir, establecer SA) las pilas IPsec basadas en el kernel KLIPS o XFRM/NETKEY. XFRM/NETKEY es la implementación nativa de IPsec para Linux disponible a partir de la versión 2.6.

Las distribuciones de software de Berkeley también implementan IPsec y el demonio IKE a través del marco criptográfico de OpenBSD (OCF), lo que facilita enormemente la compatibilidad con aceleradores criptográficos . Recientemente, OCF se ha adaptado a Linux.

Varios proveedores de equipos de red han creado sus propios demonios IKE (e implementaciones de IPsec), o bien se licencian unos a otros para crear conjuntos de protocolos.

Existen diversas implementaciones de IKEv2 y algunas de las empresas que se dedican a la certificación IPsec y a las pruebas de interoperabilidad están empezando a organizar talleres de pruebas, así como a actualizar los requisitos de certificación para abordar las pruebas de IKEv2.

Las siguientes implementaciones de código abierto de IKEv2 están disponibles:

Vulnerabilidades

Presentaciones filtradas de la NSA publicadas en 2014 por Der Spiegel indican que IKE está siendo explotado de una manera desconocida para descifrar el tráfico IPsec, al igual que ISAKMP. [ 24 ] 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 principales y el 26% de los servidores SSH, lo que, según los investigadores, es consistente con las filtraciones. [ 25 ] Esta afirmación fue refutada en 2015 tanto por Eyal Ronen y Adi Shamir en su artículo "Critical Review of Imperfect Forward Secrecy" [ 26 ] como por Paul Wouters de Libreswan en un artículo de 2015 titulado "66% de las VPN [ sic ] no están rotas de hecho". [ 27 ]

Las configuraciones de VPN IPsec que permiten la negociación de múltiples configuraciones son susceptibles a ataques de degradación basados ​​en MITM entre las configuraciones ofrecidas, tanto con IKEv1 como con IKEv2. [ 28 ] Esto se puede evitar mediante una segregación cuidadosa de los sistemas cliente en múltiples puntos de acceso de servicio con configuraciones más estrictas.

Ambas versiones del estándar IKE son susceptibles a un ataque de diccionario sin conexión cuando se utiliza una contraseña de baja entropía. Para IKEv1, esto es cierto tanto para el modo principal como para el modo agresivo. [ 29 ] [ 30 ] [ 31 ]

Véase también

Referencias

  1. ↑ El Intercambio de Claves de Internet (IKE), RFC 2409, §1 Resumen
  2. 1 2 Thomas, M. (junio de 2001), RFC 3129: Requisitos para la negociación de claves de Internet mediante Kerberos , Grupo de trabajo de ingeniería de Internet , pág. 1, doi : 10.17487/RFC3129 
  3. ↑ Richardson, M.; Redelmeier, DH (junio de 2001), RFC 4322: Cifrado oportunista mediante el Intercambio de Claves de Internet (IKE) , Grupo de Trabajo de Ingeniería de Internet , pág. 5, doi : 10.17487/RFC4322 
  4. ↑ Kampanakis, Panos; Ravago, Gerardo (2024-11-04). Intercambio de claves híbrido post-cuántico con ML-KEM en el protocolo de intercambio de claves de Internet versión 2 (IKEv2) (Informe). Grupo de trabajo de ingeniería de Internet.
  5. ↑ El dominio de interpretación de seguridad IP de Internet para ISAKMP . IETF . doi : 10.17487/RFC2407 . RFC 2407 .
  6. ↑ Protocolo de administración de claves y asociación de seguridad de Internet (ISAKMP) . IETF . doi : 10.17487/RFC2408 . RFC 2408 .
  7. ↑ D. Harkins. El Intercambio de Claves de Internet (IKE) . IETF . doi : 10.17487/RFC2409 . RFC 2409 .
  8. ↑ C. Kaufman (Microsoft) (diciembre de 2005). Protocolo de intercambio de claves de Internet (IKEv2) . IETF . doi : 10.17487/RFC4306 . RFC 4306 .
  9. ↑ Eronen, P.; Hoffman, P. (octubre de 2006). Aclaraciones y directrices de implementación de IKEv2 . IETF . doi : 10.17487/RFC4718 . RFC 4718 .
  10. ↑ Kaufman, C.; Hoffman, P.; Nir, Y.; Eronen, P. (septiembre de 2010). Protocolo de intercambio de claves de Internet (IKEv2) . IETF . doi : 10.17487/RFC5996 . RFC 5996 .
  11. 1 2 3 "RFC 2409 El intercambio de claves de Internet (IKE)", Grupo de trabajo de ingeniería de Internet (IETF), pág. 5
  12. ↑ "RFC 2409 El intercambio de claves de Internet (IKE)", Grupo de trabajo de ingeniería de Internet (IETF), pág. 6
  13. ↑ "RFC 2409 El intercambio de claves de Internet (IKE)", Grupo de trabajo de ingeniería de Internet (IETF), págs. 10-16
  14. ↑ "RFC 4306 Protocolo de intercambio de claves de Internet (IKEv2)", Grupo de trabajo de ingeniería de Internet (IETF), pág. 11,33
  15. ↑ Configuración de la Fase 1 de IPsec , Documentación de Netgate , consultado el 7 de agosto de 2025.
  16. ↑ Interoperabilidad de VPN IPsec , Proyecto Libreswan , consultado el 7 de agosto de 2025.
  17. ↑ Solución de problemas de VPN IPsec NSX-T , Broadcom TechDocs , consultado el 7 de agosto de 2025.
  18. ↑ Comprensión de la detección de pares inactivos , Base de conocimientos de Palo Alto Networks , consultado el 7 de agosto de 2025.
  19. ↑ "RFC 4306: Protocolo de intercambio de claves de Internet (IKEv2)", Grupo de trabajo de ingeniería de Internet (IETF), págs. 38-40
  20. ↑ Intercambio de claves de Internet: Seguridad del protocolo de Internet (IPsec): Technet
  21. ↑ "Uso de IPSec en Windows 2000 y XP, Parte 1" . Archivado del original el 12 de octubre de 2008. Consultado el 24 de diciembre de 2009 .
  22. ↑ "OpenIKEv2" . GitHub . Consultado el 21 de junio de 2023 .
  23. ↑ "iked(8) - Páginas del manual de OpenBSD" . man.openbsd.org . Consultado el 21 de junio de 2023 .
  24. ↑ Capacidad desplegada: Revisión del diseño de VPN SPIN9 de extremo a extremo (PDF) , NSA vía 'Der Spiegel', pág. 5 
  25. ↑ Adrian, 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). Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice (PDF) . 22.ª Conferencia ACM sobre Seguridad Informática y de Comunicaciones (CCS '15). Denver . Recuperado el 15 de junio de 2016 .
  26. ↑ Ronen, Eyal; Shamir, Adi (octubre de 2015). "Revisión crítica de Imperfect Forward Secrecy" (PDF) .
  27. ↑ Wouters, Paul (octubre de 2015). "El 66% de las VPN no están realmente rotas" .
  28. ^ Bhargavan, Karthikeyan; Brzuska, Cristina; Fournet, Cédric; Kohlweiss, Markulf; Zanella-Béguelin, Santiago; Verde, Matthew (enero de 2016). "Degradar la resiliencia en los protocolos de intercambio de claves" (PDF) .
  29. ↑ Pliam, John (2 de octubre de 1999). "Vulnerabilidades de autenticación en IKE y Xauth con secretos precompartidos débiles" . Universidad Johns Hopkins . Archivado del original el 10 de junio de 2002. Recuperado el 5 de febrero de 2020 .
  30. ↑ McGrew, David (5 de julio de 2011). "Gran cifrado, pero ¿de dónde sacaste esa clave?" . Blog de Cisco . Archivado del original el 9 de julio de 2011. Consultado el 11 de febrero de 2020 .
  31. ↑ Felsch, Dennis (agosto de 2018). Los peligros de la reutilización de claves: ataques prácticos a IPsec IKE . ISBN 9781939133045. Consultado el 11 de febrero de 2020 .{{cite book}}: |website=ignorado ( ayuda )
  • 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 El 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)