fbpx
Wikipedia

Internet key exchange

Enero 19, 2022

Internet key exchange (IKE) no 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.

Historia

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.

Arquitectura

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.

Fases IKE

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]​

Problemas de IKE

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.

Mejoras introducidas con IKEv2

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

Implementaciones

Implementaciones libres

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.

Implementaciones propietarias

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 from the KAME project.

Referencias

  1. ↑ "RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), p. 5
  2. "RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), p. 6
  3. "[RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), p. 10-16
  4. "RFC 4306 Internet Key Exchange (IKEv2) Protocol", Internet Engineering Task Force (IETF), p. 11,33
  5. "[RFC 4306: Internet Key Exchange (IKEv2) Protocol", Internet Engineering Task Force (IETF), p 38-40
  6. Internet Key Exchange: Internet Protocol Security (IPsec): Technet
  7. Using IPSec in Windows 2000 and XP, Part 1

Enlaces externos

  • 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)
  •   Datos: Q2455266

Enero 19, 2022
internet, exchange, protocolo, usado, para, establecer, asociación, seguridad, protocolo, ipsec, emplea, intercambio, secreto, claves, tipo, diffie, hellman, para, establecer, secreto, compartido, sesión, suelen, usar, sistemas, clave, pública, clave, comparti. Internet key exchange IKE no es un protocolo usado para establecer una Asociacion 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 sesion Se suelen usar sistemas de clave publica o clave pre compartida Supone una alternativa al intercambio manual de claves Su objetivo es la negociacion de una Asociacion de Seguridad para IPSEC Permite ademas especificar el tiempo de vida de la sesion IPSEC autenticacion dinamica de otras maquinas etc Indice 1 Historia 2 Arquitectura 2 1 Fases IKE 2 2 Problemas de IKE 2 3 Mejoras introducidas con IKEv2 3 Implementaciones 3 1 Implementaciones libres 3 2 Implementaciones propietarias 4 Referencias 5 Enlaces externosHistoria EditarIKE 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 interpretacion en la Internet IP para ISAKMPRFC 2408 Internet Security Association and Key Management Protocol ISAKMP RFC 2409 define el Intercambio de claves en Internet The Internet Key Exchange IKE Se desarrollo una segunda version 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 Segun van surgiendo nuevas necesidades en el desarrollo del protocolo se van publicando mas RFCs con actualizaciones La Sociedad Internet ISOC organizacion que engloba a la IETF mantiene los derechos de propiedad intelectual de estos estandares publicandolos como de libre disposicion para la comunidad Arquitectura EditarLa mayoria 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 facil acceso a la informacion de configuracion 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 modulos 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 traves del puerto 500 y generalmente requiere entre 4 y 6 paquetes con dos o tres turnos para crear una Asociacion de seguridad SA por sus siglas en ingles en ambos extremos La claves negociadas son entregadas a la pila IPsec Por ejemplo esta negociacion puede contener la clave definida con cifrado AES informacion de la direccion IP de los extremos a contactar puertos a proteger en la comunicacion y tipo de tunel IPsec que se va a crear La pila IPsec captura esta informacion en el otro extremo y realiza las operaciones de cifrado descifrado Fases IKE Editar La negociacion IKE esta compuesta por dos fases fase 1 y fase 2 1 El objetivo de la primera fase IKE es establecer un canal de comunicacion seguro usando el algoritmo de intercambio de claves Diffie Hellman para generar una clave de secreto compartido y asi cifrar la comunicacion IKE Esta negociacion establece una unica SA ISAKMP Security Association SA 2 bidireccional La autenticacion puede ser realizada usando tanto una clave compartida pre shared key secreto compartido firmas digitales o cifrado de clave publica 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 Asociacion de Seguridad SA en nombre de otros servicios como IPsec La negociacion consiste en un minimo de dos SAs unidireccionales 4 Phase 2 opera solo en Quick Mode 1 Problemas de IKE Editar Originalmente IKE poseia numerosas opciones de configuracion pero carecia de sencillez general para la negociacion automatica en los entornos donde se implementaba de forma universal De esta forma ambos extremos debian estar de acuerdo en implementar exactamente el mismo tipo de asociacion de seguridad SA parametro a parametro o la conexion no se estableceria Se anadia a este problema la dificultad de interpretar la salida de depuracion debug en caso de que existiese Las especificaciones de IKE estaban abiertas a diferentes interpretaciones lo que se interpretaba como fallos en su diseno Dead Peer Detection es un ejemplo provocando que diferentes implementaciones de IKE no fueran compatibles entre si haciendo que no fuera posible establecer una asociacion de seguridad dependiendo de las opciones que se eligieran aunque ambos extremos aparecieran como correctamente configurados Mejoras introducidas con IKEv2 Editar La necesidad de una revision del protocolo IKE fue incorporada en el apendice A del RFC 4306 Los siguientes problemas fueron detallados Menor numero de RFCs Las especificaciones IKE estaban descritas en al menos tres RFCs mas si incluimos NAT transversal y otras extensiones comunes IKEv2 combina todas estas descripciones en un solo RFC ademas de incorporar mejoras al NAT transversal y en general al metodo de atravesar cortafuegos Soporte estandar en movilidad Existe una extension para IKEv2 llamada MOBIKE con objeto de soportar la movilidad y el multihoming para IKE y ESP Usando esta extension IKEv2 y IPsec puede ser usada por usuarios moviles NAT traversal La encapsulacion 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 telefonia IP VoIP Intercambio simple de mensajes IKEv2 necesita cuatro mensajes para el mecanismo de intercambio inicial mientras que IKE necesitaba de ocho Menor numero de mecanismos criptograficos IKEv2 emplea mecanismos criptograficos para proteger los paquetes que envia de forma muy parecida a los que hace el protocolo ESP para proteger los paquetes IPsec Esto repercute en implementaciones y certificaciones mas sencillas y para Common Criteria and FIPS 140 2 que requieren que cada implementacion criptografica sea validada de forma independiente Confiabilidad y administracion de estado IKEv2 usa numeros de secuencia y acuses de recibo para proporcionar confiabilidad Tambien provee sistemas de procesamiento de errores y comparticion del estado Se descubrio que IKE podria finalizar la conexion 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 accion que nunca se produciria 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 si Resistencia al ataque de denegacion de servicio DoS IKEv2 no realiza procesamiento hasta que determina si el extremo que realiza la peticion realmente existe Esto permite evitar el gasto en procesamiento realizado en cifrado descifrado que se producia al sufrir un ataque desde IP falsas Explicacion 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 conexion IKE la respuesta consistira en un mensaje no cifrado del ike sa init con un mensake de notificacion tipo cookie El extremo que ha respondido la conexion esperara una peticion de ike sa init con esa cookie en el mensaje de respuesta Esto se realiza para asegurarse de que el iniciador de la conexion es realmente capaz de manejar una respuesta desde el extremo que responde HostA HostB HDR A 0 sai1 kei Ni gt lt HDR A 0 N cookie HDR A 0 N cookie sai1 kei Ni gt lt HDR A B SAr1 ker NrImplementaciones EditarImplementaciones libres Editar Existen varias implementaciones libres de IPsec con capacidades de negociacion 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 implementacion nativa de IPsec en el kernel 2 6 de Linux Las diferentes variedades de BSD tambien incorporan implementaciones de los demonios IPsec e IKE y lo que es mas importante un framework OpenBSD Cryptographic Framework OCF que provee de soporte criptografico sencillo cryptographic accelerators OCF ha sido recientemente portado a GNU Linux Implementaciones propietarias Editar IKE esta soportado como parte de la implementacion de IPsec en Windows 2000 Windows XP Windows Server 2003 Windows Vista and Windows Server 2008 6 La implementacion 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 traves de la caracteristica VPN Reconnect tambien conocida como Agile VPN Diversos fabricantes de equipos de comunicacion han creado sus propios demonios IKE e implementaciones IPsec o licenciado a terceros Las siguientes implementaciones de IKEv2 estan disponibles OpenIKEv2 strongSwan IKEv2 Racoon2 from the KAME project Referencias Editar a b c RFC 2409 The Internet Key Exchange IKE Internet Engineering Task Force IETF p 5 RFC 2409 The Internet Key Exchange IKE Internet Engineering Task Force IETF p 6 RFC 2409 The Internet Key Exchange IKE Internet Engineering Task Force IETF p 10 16 RFC 4306 Internet Key Exchange IKEv2 Protocol Internet Engineering Task Force IETF p 11 33 RFC 4306 Internet Key Exchange IKEv2 Protocol Internet Engineering Task Force IETF p 38 40 Internet Key Exchange Internet Protocol Security IPsec Technet Using IPSec in Windows 2000 and XP Part 1Enlaces externos EditarIKE 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 Datos Q2455266 Obtenido de https es wikipedia org w index php title Internet key exchange amp oldid 140942421, wikipedia, wiki, leyendo, leer, libro, biblioteca,

español

, española, descargar, gratis, descargar gratis, mp3, video, mp4, 3gp, jpg, jpeg, gif, png, imagen, música, canción, película, libro, juego, juegos