Intercambio de claves por Internet
Protocolo de Internet

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]

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. [4]
  • RFC  2408 definió el Protocolo de administración de claves y de la Asociación de seguridad de Internet (ISAKMP). [5]
  • El 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 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.

Arquitectura

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]

Fases de IKEv1

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]

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, 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.

Mejoras con IKEv2

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

  • Menos solicitudes de comentarios (RFC): las especificaciones de IKE se cubrieron en al menos tres RFC, más si se tiene en cuenta la travesía de NAT y otras extensiones que son de uso común. IKEv2 combina todo esto en una RFC y, además, realiza mejoras en la compatibilidad con la travesía de NAT ( traducción de direcciones de red (NAT)) y la travesía de firewall en general.
  • Compatibilidad con movilidad estándar: existe una extensión estándar para IKEv2 denominada [rfc:4555 Mobility and Multihoming Protocol] (MOBIKE) (consulte también IPsec ) que se utiliza para admitir la movilidad y el multihoming para este protocolo y para Encapsulating Security Payload (ESP). Mediante el uso de esta extensión, los usuarios móviles y multihoming pueden utilizar IKEv2 e IPsec .
  • Travesía NAT : 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 tal como se utiliza en el protocolo de telefonía por Internet, voz sobre IP (VoIP).
  • Intercambio de mensajes simple: IKEv2 tiene un mecanismo de intercambio inicial de cuatro mensajes, mientras que IKE proporcionaba ocho mecanismos de intercambio inicial claramente diferentes, cada uno de los cuales tenía 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 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 se valide por separado.
  • Fiabilidad y gestión de estados: IKEv2 utiliza números de secuencia y reconocimientos para proporcionar fiabilidad y exige cierta logística de procesamiento de errores y gestión de estados compartida. IKE podría acabar en un estado inactivo debido a la falta de tales medidas de fiabilidad, en el que ambas partes esperaban que la otra iniciara una acción, que nunca se materializó. 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 a ataques 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 realizaba una gran cantidad de procesamiento criptográfico costoso desde ubicaciones falsificadas .
Suponiendo que HostA tiene un índice de parámetro de seguridad (SPI) de 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|
Si HostB (el respondedor) está experimentando grandes cantidades 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 garantizar que el iniciador sea realmente capaz de manejar una respuesta IKE del respondedor.

Extensiones de protocolo

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:

  • Reanudación de 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).
  • Redirección IKE : redirección de 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 encriptados, con el objetivo de facilitar que los middleboxes (como los sistemas de detección de intrusiones ) analicen el flujo ( RFC 5840).
  • Autenticación EAP mutua : soporte para autenticación solo 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ña ( RFC 5998).
  • Detección rápida de fallos : 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 interrumpan 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. [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:

Vulnerabilidades

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]

Véase también

Referencias

  1. ^ El intercambio de claves de Internet (IKE), RFC 2409, §1 Resumen
  2. ^ ab Thomas, M. (junio de 2001), RFC 3129: Requisitos para la negociación de claves en Internet mediante Kerberos, Internet Engineering Task Force , 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), Internet Engineering Task Force , pág. 5, doi :10.17487/RFC4322
  4. ^ El dominio de interpretación de seguridad IP de Internet para ISAKMP. doi : 10.17487/RFC2407 . RFC 2407.
  5. ^ Asociación de Seguridad de Internet y Protocolo de Gestión de Claves (ISAKMP). doi : 10.17487/RFC2408 . RFC 2408.
  6. ^ D. Harkins. El intercambio de claves de Internet (IKE). doi : 10.17487/RFC2409 . RFC 2409.
  7. ^ C. Kaufman (Microsoft) (diciembre de 2005). Protocolo de intercambio de claves de Internet (IKEv2). doi : 10.17487/RFC4306 . RFC 4306.
  8. ^ Eronen, P.; Hoffman, P. (octubre de 2006). Aclaraciones y pautas de implementación de IKEv2. doi : 10.17487/RFC4718 . RFC 4718.
  9. ^ Kaufman, C.; Hoffman, P.; Nir, Y.; Eronen, P. (septiembre de 2010). Protocolo de intercambio de claves de Internet (IKEv2). doi : 10.17487/RFC5996 . RFC 5996.
  10. ^ abc "RFC 2409 El intercambio de claves de Internet (IKE)", Grupo de trabajo de ingeniería de Internet (IETF), pág. 5
  11. ^ "RFC 2409 El intercambio de claves de Internet (IKE)", Grupo de trabajo de ingeniería de Internet (IETF), pág. 6
  12. ^ "RFC 2409 El intercambio de claves de Internet (IKE)", Grupo de trabajo de ingeniería de Internet (IETF), págs. 10-16
  13. ^ "RFC 4306 Protocolo de intercambio de claves de Internet (IKEv2)", Grupo de trabajo de ingeniería de Internet (IETF), pág. 11,33
  14. ^ "RFC 4306: Protocolo de intercambio de claves de Internet (IKEv2)", Grupo de trabajo de ingeniería de Internet (IETF), págs. 38-40
  15. ^ Intercambio de claves por Internet: Seguridad del protocolo de Internet (IPsec): Technet
  16. ^ "Uso de IPSec en Windows 2000 y XP, parte 1". Archivado desde el original el 12 de octubre de 2008. Consultado el 24 de diciembre de 2009 .
  17. ^ "OpenIKEv2". GitHub . Consultado el 21 de junio de 2023 .
  18. ^ "iked(8) - Páginas del manual de OpenBSD". man.openbsd.org . Consultado el 21 de junio de 2023 .
  19. ^ Capacidad de campo: Revisión del diseño de SPIN9 de VPN de extremo a extremo (PDF) , NSA a través de 'Der Spiegel', pág. 5
  20. ^ 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). Secreto de reenvío imperfecto: cómo Diffie-Hellman falla 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 .
  21. ^ Ronen, Eyal; Shamir, Adi (octubre de 2015). "Revisión crítica del secreto imperfecto hacia adelante" (PDF) .
  22. ^ Wouters, Paul (octubre de 2015). "El 66% de las VPN en realidad no están rotas".
  23. ^ 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) .
  24. ^ Pliam, John (2 de octubre de 1999). "Vulnerabilidades de autenticación en IKE y Xauth con secretos precompartidos débiles". Universidad Johns Hopkins . Archivado desde el original el 10 de junio de 2002. Consultado el 5 de febrero de 2020 .
  25. ^ McGrew, David (5 de julio de 2011). "Great Cipher, But Where Did You Get That Key" (Gran cifra, 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 .
  26. ^ Felsch, Dennis (agosto de 2018). Los peligros de la reutilización de claves: ataques prácticos a IPsec IKE. ISBN 9781939133045. Recuperado el 11 de febrero de 2020 . {{cite book}}: |website=ignorado ( ayuda )
  • RFC 2407 Asociación de seguridad de Internet y Protocolo de gestión de claves (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)
Obtenido de "https://es.wikipedia.org/w/index.php?title=Intercambio_de_claves_de_Internet&oldid=1245727293"