En informática, el intercambio de claves de Internet ( IKE , versionado como IKEv1 e IKEv2 ) 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 del que se derivan las claves criptográficas . [2] [3] Además, se debe mantener manualmente una política de seguridad para cada par que se conectará. [2]
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 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 de 2010. Una actualización posterior actualizó 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 estos estándares a libre disposición de la comunidad de Internet.
La mayoría de las implementaciones de IPsec consisten en un demonio IKE que se ejecuta en el espacio del usuario y una pila IPsec en el kernel que procesa los paquetes IP reales .
Los daemons del espacio de usuario tienen fácil acceso al almacenamiento masivo que contiene información de configuración, como direcciones de puntos finales de IPsec, claves y certificados, según sea necesario. Los módulos del núcleo, 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 , normalmente en el puerto 500, y generalmente requiere 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 lados. El material de clave negociado se entrega luego a la pila IPsec. Por ejemplo, podría ser una clave AES , información que identifique los puntos finales y puertos IP que se van a proteger, 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 necesario 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 toman una porción del firewall, etc.
IKEv1 consta de dos fases: fase 1 y fase 2. [10]
El objetivo de la primera fase 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 posteriores. Esta negociación da como resultado una única asociación de seguridad ISAKMP bidireccional. [11] La autenticación se puede realizar mediante una clave precompartida (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 segunda fase 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 modo rápido. [10]
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, ambas partes de un IKE tenían que ponerse de acuerdo exactamente sobre 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 debido a que en muchas implementaciones la salida de depuración era difícil de interpretar, si es que había alguna función para producir una salida de diagnóstico.
Las especificaciones IKE estaban abiertas a un grado significativo de interpretación, al borde de fallas de diseño ( siendo Dead Peer Detection un claro ejemplo [ cita requerida ] ), lo que dio lugar a que diferentes implementaciones de IKE no pudieran crear una asociación de seguridad acordada en absoluto para muchas combinaciones de opciones, por más correctamente configuradas que pudieran parecer en cada extremo.
El protocolo IKEv2 se describió en el Apéndice A del RFC 4306 en 2005. Se abordaron los siguientes problemas:
Ay HostB tiene un SPI de B, el escenario se vería así:AnfitriónA ------------------------------------------------- - Anfitrión B |HDR(A,0),sai1,kei,Ni--------------------> | | <----------------------------HDR(A,0),N(galleta)| |HDR(A,0),N(galleta),sai1,kei,Ni----------------> | | <---------------------------HDR(A,B),SAr1,ker,Nr|
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 garantizar que el iniciador sea realmente capaz de manejar una respuesta IKE del respondedor.El grupo de trabajo de 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 gran volumen. Estas extensiones incluyen:
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. [16]
Microsoft Windows 7 y Windows Server 2008 R2 admiten parcialmente IKEv2 ( RFC 7296) así como 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 de Libreswan , Openswan y strongSwan proporcionan un demonio IKE que puede configurar (es decir, establecer SA) las pilas 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.
Berkeley Software Distributions también implementa IPsec, el demonio IKE a través del marco criptográfico OpenBSD (OCF), lo que facilita enormemente la compatibilidad con aceleradores criptográficos . OCF se ha adaptado recientemente a Linux.
Varios proveedores de equipos de red han creado sus propios daemons IKE (e implementaciones IPsec) o adquieren licencias de una pila de otros.
Hay varias implementaciones de IKEv2 y algunas de las empresas que trabajan en certificación IPsec y pruebas de interoperabilidad están comenzando a realizar talleres para pruebas, así como requisitos de certificación actualizados para abordar las pruebas IKEv2.
Las siguientes implementaciones de código abierto de IKEv2 están disponibles:
Las 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. [19] 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 más importantes y el 26% de los servidores SSH, lo que los investigadores afirman que es consistente con las filtraciones. [20] Esta afirmación fue refutada en 2015 tanto por Eyal Ronen como por Adi Shamir en su artículo "Revisión crítica de la confidencialidad directa imperfecta" [21] y por Paul Wouters de Libreswan en un artículo de 2015 "El 66% de las VPN [ sic ] no están rotas de hecho". [22]
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. [23] Esto se puede evitar mediante una segregación cuidadosa de los sistemas cliente en múltiples puntos de acceso al servicio con configuraciones más estrictas.
Ambas versiones del estándar IKE son susceptibles a un ataque de diccionario fuera de línea cuando se utiliza una contraseña de baja entropía. En el caso de IKEv1, esto es cierto tanto para el modo principal como para el modo agresivo. [24] [25] [26]
{{cite book}}: |website=ignorado ( ayuda )