Internet key exchange (IKE) es un protocolo usado para establecer una Asociación de Seguridad (SA) en el protocolo IPsec. IKE emplea un intercambio secreto de claves de tipo Diffie-Hellman para establecer el secreto compartido de la sesión. Se suelen usar sistemas de clave pública o clave pre-compartida.
Supone una alternativa al intercambio manual de claves. Su objetivo es la negociación de una Asociación de Seguridad para IPSEC. Permite, además, especificar el tiempo de vida de la sesión IPSEC, autenticación dinámica de otras máquinas, etc.
IKE fue definido por primera vez por el IETF en noviembre de 1998 en los RFC 2407, RFC 2408, y RFC 2409.
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.
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:
Explicación:
Supongamos que el HostA tiene un spi A y el HostB tiene un spi B.
Escenario:
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.
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. La implementación de ISAKMP/IKE fue desarrollada juntamente por Cisco y Microsoft.
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:
Escribe un comentario o lo que quieras sobre Internet key exchange (directo, no tienes que registrarte)
Comentarios
(de más nuevos a más antiguos)