Internet key exchange

IKE fue definido por primera vez por el IETF en noviembre de 1998 en los RFC 2407, RFC 2408, y RFC 2409.

• RFC 2407 define el dominio de interpretación en la Internet IP para ISAKMP
• RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP)
• RFC 2409 define el Intercambio de claves en Internet (The Internet Key Exchange, IKE)

Se desarrolló una segunda versión de IKE (IKEv2) en diciembre de 2005, publicada en el RFC 4306. IKEv2 fue ampliada posteriormente en los RFCs 4301 (Security Architecture for the Internet Protocol) y RFC 4309 (Using AES CCM Mode with IPsec ESP). Según van surgiendo nuevas necesidades en el desarrollo del protocolo, se van publicando más RFCs con actualizaciones.

La Sociedad Internet (ISOC), organización que engloba a la IETF, mantiene los derechos de propiedad intelectual de estos estándares, publicándolos como de libre disposición para la comunidad.

La mayoría de las implementaciones de IPsec consisten en un demonio IKE que corre en el espacio de usuario y una pila IPsec dentro del kernel que procesa los paquetes IP.

Los demonios que corren en el espacio de usuario tienen fácil acceso a la información de configuración (como las direcciones IP de los otros extremos a contactar, las claves y los certificados que se vayan a emplear) contenida en los dispositivos de almacenamiento. Por otro lado, los módulos del kernel pueden procesar eficientemente los paquetes sin sobrecargar el sistema, lo que es muy importante para conseguir un buen rendimiento.

El protocolo IKE usa paquetes UDP, normalmente a través del puerto 500, y generalmente requiere entre 4 y 6 paquetes con dos o tres turnos para crear una Asociación de seguridad, (SA por sus siglas en inglés) en ambos extremos. La claves negociadas son entregadas a la pila IPsec. Por ejemplo, esta negociación puede contener la clave definida con cifrado AES, información de la dirección IP de los extremos a contactar, puertos a proteger en la comunicación, y tipo de túnel IPsec que se va a crear. La pila IPsec captura esta información en el otro extremo y realiza las operaciones de cifrado/descifrado.

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.

• IKE VPN server discovery and fingerprinting
• RFC 2407 The Internet IP Security Domain of Interpretation for ISAKMP, Internet Engineering Task Force (IETF)
• RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP), Internet Engineering Task Force (IETF)
• RFC 2409 The Internet Key Exchange (IKE), Internet Engineering Task Force (IETF)
• RFC 4306: Internet Key Exchange (IKEv2) Protocol), Internet Engineering Task Force (IETF)
• Overview of IKE (from Cisco)