[Enciclopedia Online Gratuita] Diccionario de Internet y Tecnologías de la Información y la Comunicación (TIC):

ıllı Internet key exchange wiki: info, historia y vídeos

  Internet key exchange 

IKE fue definido por vez primera por el IETF en el mes de noviembre de mil novecientos noventa y ocho en los RFC dos mil cuatrocientos siete, RFC dos mil cuatrocientos ocho, y RFC dos mil cuatrocientos nueve.

• RFC dos mil cuatrocientos siete define el dominio de interpretación en la Internet IP para ISAKMP

• RFC dos mil cuatrocientos ocho Internet Security Association and Key Management Protocol (ISAKMP)

• RFC dos mil cuatrocientos nueve define el Intercambio de claves en Internet (The Internet Key Exchange, IKE)

Se desarrolló una segunda versión de IKE (IKEv2) en el último mes del año de dos mil cinco, publicada en el RFC cuatro mil trescientos seis. IKEv2 fue ampliada más tarde en los RFCs cuatro mil trescientos uno (Security Architecture for the Internet Protocol) y RFC cuatro mil trescientos nueve (Using AES CCM Mode with IPsec ESP). Conforme van brotando nuevas necesidades en el desarrollo del protocolo, se marchan publicando más RFCs con actualizaciones.

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

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

Los diablos que corren en el espacio de usuario tienen simple 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 almacenaje. Por otra parte, los módulos del kernel pueden procesar eficazmente los bultos sin sobrecargar el sistema, lo que es fundamental para lograr un buen desempeño.

El protocolo IKE utiliza bultos UDP, generalmente a través del puerto quinientos, y por norma general requiere entre cuatro y seis bultos con 2 o bien 3 turnos para crear una Asociación de seguridad, (sociedad anónima por sus iniciales en inglés) en los dos extremos. La claves negociadas son entregadas a la pila IPsec. Por poner un 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 resguardar en la comunicación, y tipo de túnel IPsec que se creará. La pila IPsec atrapa esta información en el otro extremo y efectúa las operaciones de cifrado/descifrado.

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

• El objetivo de la primera fase IKE es establecer un canal de comunicación seguro utilizando el algoritmo de intercambio de claves Diffie-Hellman para producir una clave de secreto compartido y de esta manera cifrar la comunicación IKE. Esta negociación establece una sola sociedad anónima ISAKMPSecurity Association (S.A.). bidireccional. La autentificación puede ser efectuada utilizando tanto una clave compartida (pre-shared key) (secreto compartido), firmas digitales, o bien cifrado de clave pública. La fase 1 opera tanto en modo primordial como beligerante. El modo perfecto primordial resguarda la identidad de los extremos, al paso que el modo perfecto beligerante no lo hace.

• En la segunda fase IKE, los extremos utilizan el canal seguro establecido en la primera fase para negociar una Asociación de Seguridad (S.A.) representando a otros servicios como IPsec. La negociación consiste en un mínimo de 2 SAs unidireccionales. Phase dos opera solo en Quick Mode.

Problemas de IKE

Originalmente IKE tenía numerosas opciones de configuración, mas carecía de sencillez general para la negociación automática en los ambientes donde se incorporaba de forma universal. De esta manera, los dos extremos habían de estar conforme en incorporar el mismo género de asociación de seguridad (S.A.) (factor a factor) o bien la conexión no se establecería. Se agregaba a este inconveniente la complejidad de interpretar la salida de depuración (debug), caso de que existiera.

Las especificaciones de IKE estaban abiertas a diferentes interpretaciones, lo que se interpretaba como fallos en su diseño (Dead-Peer-Detection es un caso), provocando que diferentes implementaciones de IKE no fuesen compatibles entre sí, haciendo que no fuese posible establecer una asociación de seguridad en dependencia de las opciones que se escogieran, si bien los dos extremos apareciesen como adecuadamente configurados.

Mejoras introducidas con IKEv2

La necesidad de una revisión del protocolo IKE fue incorporada en el apéndice A del RFC cuatro mil trescientos seis. Los próximos inconvenientes fueron detallados:

• Menor número de RFCs: Las especificaciones IKE estaban descritas en cuando menos 3 RFCs, más si incluimos NAT trasversal y otras extensiones comunes. IKEv2 combina todas y cada una estas descripciones en un RFC, aparte de agregar mejoras al NAT trasversal y generalmente al procedimiento de atravesar cortafuegos.

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

• Soporte SCTP: IKEv2 deja el empleo del protocolo SCTP utilizado en telefonía IP VoIP.

• Intercambio simple de mensajes: IKEv2 precisa 4 mensajes para el mecanismo de intercambio inicial, al tiempo que IKE precisaba de 8.

• Menor número de mecanismos criptográficos: IKEv2 emplea mecanismos criptográficos para resguardar los bultos que manda, de forma muy similar a los que hace el protocolo ESP para resguardar los bultos IPsec. Esto afecta a implementaciones y certificaciones más fáciles y para Common Criteria and FIPS ciento cuarenta-dos, que requieren que cada implementación criptográfica sea ratificada de forma independiente.

• Confiabilidad y administración de estado: IKEv2 emplea números de secuencia y acuses de recibo para otorgar fiabilidad. Asimismo provee sistemas de procesamiento de fallos y compartición del estado. Se descubrió que IKE podría concluir la conexión debido a la carencia de sistemas que intormen sobre el estado, al estar los dos extremos a la espera de la otra parte para empezar una acción que jamás se generaría.Se desarrollaron ciertas soluciones como Dead-Peer-Detection, mas no se llegaron a normalizar. Esto implica que diferentes implementaciones de esta clase de soluciones no eran siempre y en toda circunstancia compatibles entre sí.

• Resistencia al ataque de denegación de servicio (DoS): IKEv2 no efectúa procesamiento hasta el momento en que determina si el extremo que efectúa la solicitud verdaderamente existe. Esto deja eludir el gasto en procesamiento efectuado en cifrado/descifrado que se generaba al padecer 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 un sinnúmero de solicitudes de conexión IKE, la contestación va a consistir en un mensaje no cifrado del ike_sa_init con un mensake de notificación tipo cookie. El extremo que ha contestado la conexión aguardará una solicitud de ike_sa_init con esa cookie en el mensaje de contestación. Esto se efectúa para cerciorarse de que el iniciador de la conexión es verdaderamente capaz de manejar una contestación 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

Implementaciones libres

Existen múltiples implementaciones libres de IPsec con capacidades de negociación IKE. En GNU/Linux, Openswan y strongSwan las distintas implementaciones incluyen un diablo IKE llamado pluto, que puede establecer SAs a las pilas IPsec del kernel KLIPS o bien NETKEY. NETKEY es la implementación nativa de IPsec en el kernel veintiseis de Linux.

Las diferentes variedades de BSD asimismo incorporan implementaciones de los diablos IPsec y también IKE y, lo que es más esencial, un framework (OpenBSD Cryptographic Framework, OCF), que provee de soporte criptográfico fácil cryptographic accelerators. OCF ha sido últimamente portado a GNU/Linux.

Implementaciones propietarias

IKE está soportado como una parte de la implementación de IPsec en Windows dos mil, Windows XP, Windows Server dos mil tres, Windows Vista and Windows Server dos mil ocho. La implementación de ISAKMP/IKE fue desarrollada juntamente por Cisco y Microsoft.

MicrosoftWindows siete y Windows Server dos mil ocho R2 aguantan de manera plena IKEv2 (RFC cuatro mil trescientos seis) de la misma manera que MOBIKE (RFC cuatro mil quinientos cincuenta y cinco) mediante la característica VPN Reconnect (asimismo famosa como Agile VPN). Diferentes fabricantes de equipos de comunicación han creado sus diablos IKE (y también implementaciones IPsec), o bien diplomado a terceros.

Las siguientes implementaciones de IKEv2 están disponibles:

  ELIGE TU TEMA DE INTERÉS: 

---

Internet y Tecnologias

• Anterior
• Siguiente