Internet key exchange

La negociación IKE está compuesta por dos fases: fase 1 y fase 2.[1]

• El objetivo de la primera fase IKE es establecer un canal de comunicación seguro usando el algoritmo de intercambio de claves Diffie-Hellman para generar una clave de secreto compartido y así cifrar la comunicación IKE. Esta negociación establece una única SA ISAKMP Security Association (SA).[2] bidireccional. La autenticación puede ser realizada usando tanto una clave compartida (pre-shared key) (secreto compartido), firmas digitales, o cifrado de clave pública.[3] La fase 1 opera tanto en modo principal como agresivo. El modo principal protege la identidad de los extremos, mientras que el modo agresivo no lo hace.[1]

• En la segunda fase IKE, los extremos usan el canal seguro establecido en la primera fase para negociar una Asociación de Seguridad (SA) en nombre de otros servicios como IPsec. La negociación consiste en un mínimo de dos SAs unidireccionales.[4] Phase 2 opera sólo en Quick Mode.[1]

Originalmente IKE poseía numerosas opciones de configuración, pero carecía de sencillez general para la negociación automática en los entornos donde se implementaba de forma universal. De esta forma, ambos extremos debían estar de acuerdo en implementar exactamente el mismo tipo de asociación de seguridad (SA) (parámetro a parámetro) o la conexión no se establecería. Se añadía a este problema la dificultad de interpretar la salida de depuración (debug), en caso de que existiese.

Las especificaciones de IKE estaban abiertas a diferentes interpretaciones, lo que se interpretaba como fallos en su diseño (Dead-Peer-Detection es un ejemplo), provocando que diferentes implementaciones de IKE no fueran compatibles entre sí, haciendo que no fuera posible establecer una asociación de seguridad dependiendo de las opciones que se eligieran, aunque ambos extremos aparecieran como correctamente configurados.

La necesidad de una revisión del protocolo IKE fue incorporada en el apéndice A del RFC 4306. Los siguientes problemas fueron detallados:

• Menor número de RFCs: Las especificaciones IKE estaban descritas en al menos tres RFCs, más si incluimos NAT transversal y otras extensiones comunes. IKEv2 combina todas estas descripciones en un solo RFC, además de incorporar mejoras al NAT transversal y en general al método de atravesar cortafuegos.

• Soporte estándar en movilidad: Existe una extensión para IKEv2 llamada MOBIKE, con objeto de soportar la movilidad y el multihoming para IKE y ESP. Usando esta extensión, IKEv2 y IPsec puede ser usada por usuarios móviles.

• NAT traversal: La encapsulación de IKE y ESP por UDP en el puerto 4500 permite a estos protocolos atravesar cortafuegos que usan NAT[5]

• Soporte SCTP: IKEv2 permite el uso del protocolo SCTP usado en telefonía IP VoIP.

• Intercambio simple de mensajes: IKEv2 necesita cuatro mensajes para el mecanismo de intercambio inicial, mientras que IKE necesitaba de ocho.

• Menor número de mecanismos criptográficos: IKEv2 emplea mecanismos criptográficos para proteger los paquetes que envía, de forma muy parecida a los que hace el protocolo ESP para proteger los paquetes IPsec. Esto repercute en implementaciones y certificaciones más sencillas y para Common Criteria and FIPS 140-2, que requieren que cada implementación criptográfica sea validada de forma independiente.

• Confiabilidad y administración de estado: IKEv2 usa números de secuencia y acuses de recibo para proporcionar confiabilidad. También provee sistemas de procesamiento de errores y compartición del estado. Se descubrió que IKE podría finalizar la conexión debido a la falta de sistemas que intormen sobre el estado, al estar ambos extremos a la espera de la otra parte para iniciar una acción que nunca se produciría. Se desarrollaron algunas soluciones como Dead-Peer-Detection, pero no se llegaron a estandarizar. Esto implica que diferentes implementaciones de este tipo de soluciones no eran siempre compatibles entre sí.

• Resistencia al ataque de denegación de servicio (DoS): IKEv2 no realiza procesamiento hasta que determina si el extremo que realiza la petición realmente existe. Esto permite evitar el gasto en procesamiento realizado en cifrado/descifrado que se producía al sufrir un ataque desde IP falsas.

Explicación:

Supongamos que el HostA tiene un spi A y el HostB tiene un spi B.

Escenario:

      HostA---------------HostB

Si el Host B recibe una gran cantidad de peticiones de conexión IKE, la respuesta consistirá en un mensaje no cifrado del ike_sa_init con un mensake de notificación tipo cookie. El extremo que ha respondido la conexión esperará una petición de ike_sa_init con esa cookie en el mensaje de respuesta. Esto se realiza para asegurarse de que el iniciador de la conexión es realmente capaz de manejar una respuesta desde el extremo que responde.

     HostA-------------------------------------------------HostB
     HDR(A,0), sai1, kei,Ni----------------------------->
                  <----------------------------HDR(A,0),N(cookie)
     HDR(A,0),N(cookie), sai1, kei,Ni------------------->
                  <--------------------------HDR(A,B), SAr1, ker, Nr

Existen varias implementaciones libres de IPsec con capacidades de negociación IKE. En GNU/Linux, Openswan y strongSwan las diferentes implementaciones incluyen un demonio IKE llamado pluto, que puede establecer SAs a las pilas IPsec del kernel KLIPS o NETKEY. NETKEY es la implementación nativa de IPsec en el kernel 2.6 de Linux.

Las diferentes variedades de BSD también incorporan implementaciones de los demonios IPsec e IKE y, lo que es más importante, un framework (OpenBSD Cryptographic Framework, OCF), que provee de soporte criptográfico sencillo cryptographic accelerators. OCF ha sido recientemente portado a GNU/Linux.

IKE está soportado como parte de la implementación de IPsec en Windows 2000, Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008.[6] La implementación de ISAKMP/IKE fue desarrollada juntamente por Cisco y Microsoft.[7]

Microsoft Windows 7 y Windows Server 2008 R2 soportan plenamente IKEv2 (RFC 4306) al igual que MOBIKE (RFC 4555) a través de la característica VPN Reconnect (también conocida como Agile VPN). Diversos fabricantes de equipos de comunicación han creado sus propios demonios IKE (e implementaciones IPsec), o licenciado a terceros.

Las siguientes implementaciones de IKEv2 están disponibles:

• OpenIKEv2,
• strongSwan,
• IKEv2,
• Racoon2 Archivado el 15 de octubre de 2008 en Wayback Machine. from the KAME project.