IPsec

Conjunto de protocolos de internet
Capa de aplicación
BGP DHCP (v6) DNS FTP HTTP HTTPS IMAP LDAP MGCP MQTT NNTP NTP MÚSICA POP PTP ONC / RPC RTP RTSP ROTURA sorbo SMTP SNMP SSH Telnet TLS / SSL XMPP más...
Capa de transporte
TCP UDP DCCP SCTP RSVP más...
Capa de internet
IP IPv4 IPv6 ICMP (v6) ECN IGMP IPsec más...
Capa de enlace
ARP NDP OSPF Túneles L2TP PPP MAC Ethernet Wifi DSL RDSI FDDI más...
v t mi

Secure network protocol suite

En informática , Internet Protocol Security ( IPsec ) es un conjunto de protocolos de red seguro que autentica y cifra los paquetes de datos para proporcionar una comunicación cifrada segura entre dos computadoras a través de una red de protocolo de Internet . Se utiliza en redes privadas virtuales (VPN).

IPsec incluye protocolos para establecer autenticación mutua entre agentes al comienzo de una sesión y negociación de claves criptográficas para usar durante la sesión. IPsec puede proteger los flujos de datos entre un par de hosts ( host a host ), entre un par de puertas de enlace de seguridad ( red a red ) o entre una puerta de enlace de seguridad y un host ( red a host ). ^[1] IPsec utiliza servicios de seguridad criptográfica para proteger las comunicaciones a través de redes de Protocolo de Internet (IP). Es compatible con la autenticación de pares a nivel de red, la autenticación del origen de los datos, la integridad de los datos, la confidencialidad de los datos (cifrado) y la protección de reproducción.

La suite de IPv4 inicial se desarrolló con pocas disposiciones de seguridad. Como parte de la mejora de IPv4, IPsec es un modelo OSI de capa 3 o un esquema de seguridad de extremo a extremo de la capa de Internet . Por el contrario, mientras que algunos otros sistemas de seguridad de Internet de uso generalizado operan por encima de la capa 3, como Transport Layer Security (TLS) que opera en la capa de transporte y Secure Shell (SSH) que opera en la capa de aplicación, IPsec puede proteger automáticamente las aplicaciones en la capa de IP.

Historia

A principios de la década de 1970, la Agencia de Proyectos de Investigación Avanzada patrocinó una serie de dispositivos de cifrado ARPANET experimentales , al principio para el cifrado de paquetes ARPANET nativo y, posteriormente, para el cifrado de paquetes TCP / IP; algunos de ellos fueron certificados y enviados. De 1986 a 1991, la NSA patrocinó el desarrollo de protocolos de seguridad para Internet bajo su programa Secure Data Network Systems (SDNS). ^[2] Esto reunió a varios proveedores, incluido Motorola, que produjo un dispositivo de cifrado de red en 1988. El trabajo fue publicado abiertamente desde aproximadamente 1988 por NIST y, de estos, Security Protocol at Layer 3(SP3) eventualmente se transformaría en el Protocolo de seguridad de capa de red (NLSP) estándar ISO. ^[3]

De 1992 a 1995, varios grupos llevaron a cabo investigaciones sobre el cifrado de la capa IP.

• 1. En 1992, el Laboratorio de Investigación Naval de EE. UU . (NRL) inició el proyecto Simple Internet Protocol Plus (SIPP) para investigar e implementar el cifrado de IP.
• 2. En 1993, en la Universidad de Columbia y AT&T Bell Labs , John Ioannidis y otros investigaron el software experimental Software IP Encryption Protocol (swIPe) en SunOS .
• 3. En 1993, patrocinado por el proyecto de servicio de Internet Whitehouse, Wei Xu de Trusted Information Systems (TIS) investigó más a fondo los protocolos de seguridad IP de software y desarrolló el soporte de hardware para el estándar de cifrado de datos triple DES , ^[4] que estaba codificado en el BSD 4.1 kernel y soporta arquitecturas x86 y SUNOS. En diciembre de 1994, TIS lanzó su producto Gauntlet Firewall de código abierto patrocinado por DARPA con el cifrado de hardware 3DES integrado a velocidades superiores a T1 . Fue la primera vez que se utilizaron conexiones VPN IPSec entre la costa este y oeste de los Estados, conocido como el primer producto VPN IPSec comercial.
• 4. Bajo el esfuerzo de investigación financiado por DARPA de NRL, NRL desarrolló las especificaciones de seguimiento de estándares IETF (RFC 1825 a RFC 1827) para IPsec, que se codificó en el kernel BSD 4.4 y admitió arquitecturas de CPU x86 y SPARC. ^[5] La implementación de IPsec de NRL se describió en su documento en las Actas de la Conferencia de USENIX de 1996. ^[6] El MIT puso a disposición en línea la implementación de IPsec de código abierto de NRL y se convirtió en la base de la mayoría de las implementaciones comerciales iniciales. ^[7]

El Grupo de Trabajo de Ingeniería de Internet (IETF) formó el Grupo de Trabajo de Seguridad IP en 1992 ^[8] para estandarizar extensiones de seguridad especificadas abiertamente para IP, llamadas IPsec . ^[9] En 1995, el grupo de trabajo organizó algunos de los talleres con miembros de las cinco empresas (TIS, CISCO, FTP, Checkpoint, etc.). Durante los talleres de IPSec, los estándares de la NRL y el software de Cisco y TIS se estandarizan como referencias públicas, publicadas como RFC-1825 a RFC-1827. ^[10]

Arquitectura de seguridad

IPsec es un estándar abierto como parte de la suite IPv4. IPsec utiliza los siguientes protocolos para realizar varias funciones: ^{[11] [12]}

• Los encabezados de autenticación (AH) brindan integridad de datos sin conexión y autenticación de origen de datos para datagramas IP y brindan protección contra ataques de reproducción . ^{[13] [14]}
• Las cargas útiles de seguridad encapsuladas (ESP) proporcionan confidencialidad , integridad de datos sin conexión, autenticación de origen de datos , un servicio anti-reproducción (una forma de integridad de secuencia parcial) y confidencialidad limitada del flujo de tráfico. ^[1]
• El protocolo de administración de claves y asociación de seguridad de Internet (ISAKMP) proporciona un marco para la autenticación y el intercambio de claves, ^[15] con material de claves autenticado real proporcionado por configuración manual con claves previamente compartidas , intercambio de claves de Internet (IKE e IKEv2), negociación de Internet kerberizada de claves (KINK) o registros DNS IPSECKEY . ^{[16] [17] [18] [19]} El propósito es generar las Asociaciones de Seguridad (SA) con el conjunto de algoritmos y parámetros necesarios para las operaciones AH y / o ESP.

Encabezado de autenticación

Uso del formato de encabezado de autenticación IPsec en los modos de túnel y transporte

El encabezado de autenticación de seguridad ( AH ) se desarrolló en el Laboratorio de Investigación Naval de EE. UU. A principios de la década de 1990 y se deriva en parte del trabajo de estándares IETF anteriores para la autenticación del Protocolo simple de administración de red (SNMP) versión 2. El encabezado de autenticación (AH) es un miembro de la suite de protocolos IPsec. AH asegura la integridad sin conexión mediante el uso de una función hash y una clave compartida secreta en el algoritmo AH. AH también garantiza el origen de los datos mediante la autenticación de paquetes IP . Opcionalmente, un número de secuencia puede proteger el contenido del paquete IPsec contra ataques de repetición , ^[20] usando la ventana deslizante técnica y descartando paquetes antiguos.

• En IPv4 , AH evita los ataques de inserción de opciones. En IPv6 , AH protege tanto contra ataques de inserción de encabezados como de inserción de opciones.
• En IPv4 , el AH protege la carga útil de IP y todos los campos de encabezado de un datagrama de IP excepto los campos mutables (es decir, aquellos que pueden modificarse en tránsito) y también las opciones de IP como la Opción de seguridad IP (RFC 1108). Los campos de encabezado IPv4 mutables (y por lo tanto no autenticados) son DSCP / ToS , ECN , Flags, Fragment Offset , TTL y Header Checksum . ^[14]
• En IPv6 , el AH protege la mayor parte del encabezado base de IPv6, el propio AH, los encabezados de extensión no mutables después del AH y la carga útil de IP. La protección para el encabezado IPv6 excluye los campos mutables: DSCP , ECN , Etiqueta de flujo y Límite de saltos. ^[14]

AH opera directamente sobre IP, utilizando el protocolo IP número 51 . ^[21]

El siguiente diagrama de paquetes AH muestra cómo se construye e interpreta un paquete AH: ^{[13] [14]}

Formato de encabezado de autenticación

Compensaciones	Octeto 16	0								1								2								3
Octeto 16	Poco 10	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	dieciséis	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Encabezado siguiente								Carga útil Len								Reservado
4	32	Índice de parámetros de seguridad (SPI)
8	64	Secuencia de números
C	96	Valor de verificación de integridad (ICV) ...
...	...

Siguiente encabezado (8 bits)

Tipo de encabezado siguiente, que indica qué protocolo de capa superior estaba protegido. El valor se toma de la lista de números de protocolo IP .

Carga útil Len (8 bits)

La longitud de este encabezado de autenticación en unidades de 4 octetos, menos 2. Por ejemplo, un valor AH de 4 es igual a 3 × (campos AH de longitud fija de 32 bits) + 3 × (campos ICV de 32 bits) - 2 y por lo tanto un valor AH de 4 significa 24 octetos. Aunque el tamaño se mide en unidades de 4 octetos, la longitud de este encabezado debe ser un múltiplo de 8 octetos si se transporta en un paquete IPv6. Esta restricción no se aplica a un encabezado de autenticación transportado en un paquete IPv4.

Reservado (16 bits)

Reservado para uso futuro (todos los ceros hasta entonces).

Índice de parámetros de seguridad (32 bits)

Valor arbitrario que se utiliza (junto con la dirección IP de destino) para identificar la asociación de seguridad de la parte receptora.

Número de secuencia (32 bits)

Un número de secuencia monótona y estrictamente creciente (incrementado en 1 por cada paquete enviado) para evitar ataques de repetición . Cuando la detección de reproducción está habilitada, los números de secuencia nunca se reutilizan, porque se debe renegociar una nueva asociación de seguridad antes de intentar incrementar el número de secuencia más allá de su valor máximo. ^[14]

Valor de verificación de integridad (múltiplo de 32 bits)

Valor de verificación de longitud variable. Puede contener relleno para alinear el campo con un límite de 8 octetos para IPv6 o un límite de 4 octetos para IPv4 .

Carga útil de seguridad encapsulada

Uso de la carga útil de seguridad encapsulante (ESP) IPsec en los modos de túnel y transporte

El IP Encapsulating Security Payload (ESP) ^[22] se desarrolló en el Laboratorio de Investigación Naval a partir de 1992 como parte de un proyecto de investigación patrocinado por DARPA , y fue publicado abiertamente por el IETF SIPP ^[23] Working Group redactado en diciembre de 1993 como seguridad extensión para SIPP. Este ESP se derivó originalmente del protocolo SP3D del Departamento de Defensa de EE. UU. , En lugar de derivarse del Protocolo de seguridad de capa de red ISO (NLSP). La especificación del protocolo SP3D fue publicada por NISTa fines de la década de 1980, pero diseñado por el proyecto Secure Data Network System del Departamento de Defensa de EE. UU. La carga útil de seguridad encapsulada (ESP) es un miembro del conjunto de protocolos IPsec. Proporciona origen autenticidad a través de la fuente de autentificación , integridad de los datos a través de las funciones de hash y confidencialidad a través de cifrado de protección de IP paquetes . El ESP también admite configuraciones de solo cifrado y autenticación , pero se desaconseja encarecidamente el uso de cifrado sin autenticación porque no es seguro. ^{[24] [25] [26]}

A diferencia del encabezado de autenticación (AH) , ESP en modo de transporte no proporciona integridad y autenticación para todo el paquete IP . Sin embargo, en el modo de túnel , donde todo el paquete IP original se encapsula con un nuevo encabezado de paquete agregado, la protección ESP se otorga a todo el paquete IP interno (incluido el encabezado interno) mientras que el encabezado externo (incluidas las opciones externas de IPv4 o extensión IPv6 encabezados) permanece desprotegido. ESP opera directamente sobre IP, utilizando el protocolo IP número 50. ^[21]

El siguiente diagrama de paquetes ESP muestra cómo se construye e interpreta un paquete ESP: ^{[1] [27]}

Formato de carga útil de seguridad encapsulada

Compensaciones	Octeto 16	0								1								2								3
Octeto 16	Poco 10	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	dieciséis	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Índice de parámetros de seguridad (SPI)
4	32	Secuencia de números
8	64	Datos de carga útil
...	...
...	...
...	...									Relleno (0-255 octetos)
...	...																	Longitud de la almohadilla								Encabezado siguiente
...	...	Valor de verificación de integridad (ICV) ...
...	...

Índice de parámetros de seguridad (32 bits)

Valor arbitrario utilizado (junto con la dirección IP de destino) para identificar la asociación de seguridad de la parte receptora.

Número de secuencia (32 bits)

Un número de secuencia que aumenta monótonamente (incrementado en 1 por cada paquete enviado) para proteger contra ataques de repetición . Hay un contador separado para cada asociación de seguridad.

Datos de carga útil (variable)

El contenido protegido del paquete IP original, incluidos los datos utilizados para proteger el contenido (por ejemplo, un vector de inicialización para el algoritmo criptográfico). El tipo de contenido que se protegió se indica mediante el campo Siguiente encabezado .

Relleno (0-255 octetos)

Relleno para el cifrado, para extender los datos de la carga útil a un tamaño que se ajuste al tamaño del bloque de cifrado del cifrado y para alinear el siguiente campo.

Longitud de la almohadilla (8 bits)

Tamaño del relleno (en octetos).

Siguiente encabezado (8 bits)

Tipo del siguiente encabezado. El valor se toma de la lista de números de protocolo IP .

Valor de verificación de integridad (múltiplo de 32 bits)

Valor de verificación de longitud variable. Puede contener relleno para alinear el campo con un límite de 8 octetos para IPv6 o un límite de 4 octetos para IPv4 .

Asociación de seguridad

Artículo principal: Asociación de seguridad

Los protocolos IPsec utilizan una asociación de seguridad , donde las partes que se comunican establecen atributos de seguridad compartidos, como algoritmos y claves. Como tal, IPsec proporciona una gama de opciones una vez que se ha determinado si se utiliza AH o ESP. Antes de intercambiar datos, los dos hosts acuerdan qué algoritmo se utiliza para cifrar el paquete IP, por ejemplo DES o IDEA , y qué función hash se utiliza para garantizar la integridad de los datos, como MD5 o SHA . Estos parámetros se acuerdan para la sesión en particular, para lo cual se debe acordar una vida útil y una clave de sesión . ^[28]

El algoritmo de autenticación también se acuerda antes de que se lleve a cabo la transferencia de datos e IPsec admite una variedad de métodos. La autenticación es posible a través de una clave precompartida , donde una clave simétrica ya está en posesión de ambos hosts, y los hosts se envían entre sí hash de la clave compartida para demostrar que están en posesión de la misma clave. IPsec también admite el cifrado de clave pública , donde cada host tiene una clave pública y una privada, intercambian sus claves públicas y cada host envía al otro un nonce cifrado con la clave pública del otro host. Alternativamente, si ambos hosts poseen un certificado de clave pública de una autoridad de certificación , esto se puede usar para la autenticación IPsec.^[29]

Las asociaciones de seguridad de IPsec se establecen mediante la Asociación de seguridad de Internet y el Protocolo de administración de claves (ISAKMP). ISAKMP se implementa mediante configuración manual con secretos previamente compartidos, intercambio de claves de Internet (IKE e IKEv2), negociación de claves de Internet kerberizada (KINK) y el uso de registros DNS IPSECKEY . ^{[19] [30] [31]} RFC 5386 define Better-Than-Nothing Security (BTNS) como un modo no autenticado de IPsec usando un protocolo IKE extendido. C. Meadows, C. Cremers y otros han utilizado métodos formales para identificar diversas anomalías que existen en IKEv1 y también en IKEv2. ^[32]

Para decidir qué protección se proporcionará para un paquete saliente, IPsec utiliza el Índice de parámetros de seguridad (SPI), un índice de la base de datos de asociación de seguridad (SADB), junto con la dirección de destino en un encabezado de paquete, que en conjunto identifica de forma única una asociación de seguridad para ese paquete. Se realiza un procedimiento similar para un paquete entrante, donde IPsec recopila claves de descifrado y verificación de la base de datos de la asociación de seguridad.

Para la multidifusión IP, se proporciona una asociación de seguridad para el grupo y se duplica en todos los receptores autorizados del grupo. Puede haber más de una asociación de seguridad para un grupo, utilizando diferentes SPI, lo que permite múltiples niveles y conjuntos de seguridad dentro de un grupo. De hecho, cada remitente puede tener múltiples asociaciones de seguridad, lo que permite la autenticación, ya que un receptor solo puede saber que alguien que conoce las claves envió los datos. Tenga en cuenta que el estándar relevante no describe cómo se elige y se duplica la asociación en todo el grupo; se supone que una parte responsable habrá tomado la decisión.

Modos de funcionamiento

Los protocolos IPsec AH y ESP se pueden implementar en un modo de transporte de host a host, así como en un modo de túnel de red.

Modos IPsec

Modo de transporte

En el modo de transporte, solo la carga útil del paquete IP suele estar cifrada o autenticada. El enrutamiento está intacto, ya que el encabezado IP no está modificado ni encriptado; sin embargo, cuando se utiliza el encabezado de autenticación , las direcciones IP no se pueden modificar mediante la traducción de direcciones de red , ya que esto siempre invalida el valor hash . Las capas de transporte y aplicación siempre están protegidas por un hash, por lo que no se pueden modificar de ninguna manera, por ejemplo, traduciendo los números de puerto .

Los documentos RFC que describen el mecanismo NAT-T han definido un medio para encapsular los mensajes IPsec para el cruce de NAT .

Modo túnel

Artículo principal: Protocolo de tunelización

En el modo de túnel, todo el paquete IP está encriptado y autenticado. Luego se encapsula en un nuevo paquete IP con un nuevo encabezado IP. El modo túnel se utiliza para crear redes privadas virtuales para comunicaciones de red a red (p. Ej., Entre enrutadores a sitios de enlace), comunicaciones de host a red (p. Ej. Acceso de usuario remoto) y comunicaciones de host a host (p. Ej. Chat privado). ^[33]

El modo de túnel admite NAT transversal.

Algoritmos

Algoritmos de cifrado simétrico

Los algoritmos criptográficos definidos para su uso con IPsec incluyen:

• HMAC - SHA1 / SHA2 para protección de integridad y autenticidad.
• TripleDES - CBC para la confidencialidad
• AES- CBC y AES-CTR de confidencialidad.
• AES- GCM y ChaCha20 - Poly1305 brindan confidencialidad y autenticación juntas de manera eficiente.

Consulte RFC 8221 para obtener más detalles.

Algoritmos de intercambio de claves

• Diffie – Hellman (RFC 3526)
• ECDH (RFC 4753)

Algoritmos de autenticación

• RSA
• ECDSA (RFC 4754)
• PSK (RFC 6617)

Implementaciones

El IPsec se puede implementar en la pila de IP de un sistema operativo , lo que requiere la modificación del código fuente. Este método de implementación se realiza para hosts y puertas de enlace de seguridad. Varias pilas de IP compatibles con IPsec están disponibles en empresas como HP o IBM. ^[34] Una alternativa es la implementación de bump-in-the-stack (BITS), donde el código fuente del sistema operativo no tiene que ser modificado. Aquí, IPsec se instala entre la pila de IP y los controladores de red . De esta manera, los sistemas operativos se pueden actualizar con IPsec. Este método de implementación también se usa tanto para hosts como para puertas de enlace. Sin embargo, al actualizar IPsec, la encapsulación de paquetes IP puede causar problemas para ladescubrimiento de ruta MTU , donde se establece el tamaño máximo de la unidad de transmisión (MTU) en la ruta de red entre dos hosts IP. Si un host o puerta de enlace tiene un criptoprocesador separado , que es común en el ejército y también se puede encontrar en sistemas comerciales, es posible una implementación de IPsec llamada bump-in-the-wire (BITW). ^[35]

Cuando se implementa IPsec en el kernel , la gestión de claves y la negociación ISAKMP / IKE se llevan a cabo desde el espacio de usuario. La "API de administración de claves PF_KEY, versión 2" desarrollada por NRL y especificada abiertamente se utiliza a menudo para permitir que la aplicación de administración de claves del espacio de la aplicación actualice las asociaciones de seguridad IPsec almacenadas dentro de la implementación de IPsec del espacio del núcleo. ^[36] Las implementaciones de IPsec existentes generalmente incluyen ESP, AH e IKE versión 2. Las implementaciones de IPsec existentes en sistemas operativos similares a UNIX, por ejemplo, Solaris o Linux, generalmente incluyen PF_KEY versión 2.

Se puede utilizar IPsec integrado para garantizar la comunicación segura entre aplicaciones que se ejecutan en sistemas de recursos limitados con una pequeña sobrecarga. ^[37]

Estado de las normas

IPsec se desarrolló junto con IPv6 y originalmente se requería que fuera compatible con todas las implementaciones compatibles con los estándares de IPv6 antes de que RFC 6434 lo convirtiera solo en una recomendación. ^[38] IPsec también es opcional para implementaciones de IPv4 . IPsec se usa más comúnmente para proteger el tráfico IPv4. ^{[ cita requerida ]}

Los protocolos IPsec se definieron originalmente en RFC 1825 a través de RFC 1829, que se publicaron en 1995. En 1998, estos documentos fueron reemplazados por RFC 2401 y RFC 2412 con algunos detalles de ingeniería incompatibles, aunque conceptualmente idénticos. Además, se definió un protocolo de autenticación mutua e intercambio de claves Internet Key Exchange (IKE) para crear y administrar asociaciones de seguridad. En diciembre de 2005, se definieron nuevos estándares en RFC 4301 y RFC 4309, que son en gran parte un superconjunto de las ediciones anteriores con una segunda versión del estándar IKEv2 de intercambio de claves de Internet . Estos documentos de tercera generación estandarizaron la abreviatura de IPsec en mayúsculas "IP" y minúsculas "sec". “ESP” generalmente se refiere a RFC 4303, que es la versión más reciente de la especificación.

Desde mediados de 2008, un grupo de trabajo de mantenimiento y extensiones de IPsec (ipsecme) está activo en el IETF. ^{[39] [40]}

Presunta interferencia de la NSA

En 2013, como parte de las filtraciones de Snowden , se reveló que la Agencia de Seguridad Nacional de EE. UU . Había estado trabajando activamente para "Insertar vulnerabilidades en sistemas de cifrado comerciales, sistemas de TI, redes y dispositivos de comunicaciones de punto final utilizados por los objetivos" como parte del programa Bullrun. . ^[41] Hay acusaciones de que IPsec era un sistema de cifrado dirigido. ^[42]

La pila IPsec de OpenBSD apareció más tarde y también se copió ampliamente. En una carta que el desarrollador principal de OpenBSD, Theo de Raadt, recibió el 11 de diciembre de 2010 de Gregory Perry, se alega que Jason Wright y otros, que trabajaban para el FBI, insertaron "una serie de puertas traseras y mecanismos de fuga de claves de canales laterales " en la criptografía de OpenBSD código. En el correo electrónico reenviado de 2010, Theo de Raadt no expresó al principio una posición oficial sobre la validez de las afirmaciones, aparte del respaldo implícito del reenvío del correo electrónico. ^[43]La respuesta de Jason Wright a las acusaciones: "Todas las leyendas urbanas se vuelven más reales mediante la inclusión de nombres, fechas y horas reales. El correo electrónico de Gregory Perry entra en esta categoría ... Declararé claramente que no agregué puertas traseras a las operaciones de OpenBSD sistema o el marco de cifrado OpenBSD (OCF) ". ^[44] Unos días después, de Raadt comentó que "creo que probablemente se contrató a NETSEC para escribir puertas traseras como se alega ... Si esas fueron escritas, no creo que hayan llegado a nuestro árbol". ^[45] Esto fue publicado antes de las filtraciones de Snowden.

Una explicación alternativa presentada por los autores del ataque Logjam sugiere que la NSA comprometió las VPN IPsec al socavar el algoritmo Diffie-Hellman utilizado en el intercambio de claves. En su artículo ^[46] alegan que la NSA construyó especialmente un clúster de computación para precalcular subgrupos multiplicativos para primos y generadores específicos, como para el segundo grupo Oakley definido en RFC 2409. En mayo de 2015, el 90% de las VPN IPsec direccionables admitían la segundo grupo Oakley como parte de IKE. Si una organización calculara previamente este grupo, podría derivar las claves que se intercambian y descifrar el tráfico sin insertar ninguna puerta trasera de software.

Una segunda explicación alternativa que se presentó fue que Equation Group utilizó exploits de día cero contra equipos VPN de varios fabricantes que fueron validados por Kaspersky Lab como vinculados al Equation Group ^[47] y validados por esos fabricantes como exploits reales. algunos de los cuales eran exploits de día cero en el momento de su exposición. ^{[48] [49] [50]} Los firewalls Cisco PIX y ASA tenían vulnerabilidades que fueron utilizadas para escuchas telefónicas por la NSA ^{[ cita requerida ]} .

Además, las VPN IPsec que utilizan la configuración de "Modo agresivo" envían un hash del PSK sin cifrar. Esto puede ser y aparentemente es el objetivo de la NSA mediante ataques de diccionario fuera de línea. ^{[51] [52] [53]}

Documentación de IETF

Pista de estándares

• RFC 1829: Transformada ESP DES-CBC
• RFC 2403: El uso de HMAC-MD5-96 dentro de ESP y AH
• RFC 2404: El uso de HMAC-SHA-1-96 dentro de ESP y AH
• RFC 2405: El algoritmo de cifrado ESP DES-CBC con IV explícito
• RFC 2410: El algoritmo de cifrado NULL y su uso con IPsec
• RFC 2451: Algoritmos de cifrado ESP CBC-Mode
• RFC 2857: El uso de HMAC-RIPEMD-160-96 dentro de ESP y AH
• RFC 3526: Más grupos Diffie-Hellman exponenciales modulares (MODP) para el intercambio de claves de Internet (IKE)
• RFC 3602: El algoritmo de cifrado AES-CBC y su uso con IPsec
• RFC 3686: Uso del modo de contador del estándar de cifrado avanzado (AES) con carga útil de seguridad encapsulada IPsec (ESP)
• RFC 3947: Negociación de NAT-Traversal en el IKE
• RFC 3948: Encapsulación UDP de paquetes ESP IPsec
• RFC 4106: El uso de Galois / Counter Mode (GCM) en IPsec Encapsulating Security Payload (ESP)
• RFC 4301: Arquitectura de seguridad para el protocolo de Internet
• RFC 4302: Encabezado de autenticación de IP
• RFC 4303: Carga útil de seguridad de encapsulación IP
• RFC 4304: Apéndice del número de secuencia extendido (ESN) al dominio de interpretación de IPsec (DOI) para la asociación de seguridad de Internet y el protocolo de administración de claves (ISAKMP)
• RFC 4307: Algoritmos criptográficos para su uso en Internet Key Exchange versión 2 ( IKEv2 )
• RFC 4308: Suites criptográficas para IPsec
• RFC 4309: Uso del modo CCM del estándar de cifrado avanzado (AES) con carga útil de seguridad encapsulante IPsec (ESP)
• RFC 4543: El uso del código de autenticación de mensajes de Galois (GMAC) en IPsec ESP y AH
• RFC 4555: Protocolo de movilidad y alojamiento múltiple IKEv2 (MOBIKE)
• RFC 4806: Extensiones del Protocolo de estado de certificado en línea (OCSP) para IKEv2
• RFC 4868: uso de HMAC-SHA-256, HMAC-SHA-384 y HMAC-SHA-512 con IPsec
• RFC 4945: Perfil PKI de seguridad IP de Internet de IKEv1 / ISAKMP, IKEv2 y PKIX
• RFC 5280: Certificado de infraestructura de clave pública X.509 de Internet y perfil de lista de revocación de certificados (CRL)
• RFC 5282: Uso de algoritmos de cifrado autenticados con la carga útil cifrada del protocolo de intercambio de claves de Internet versión 2 (IKEv2)
• RFC 5386: Seguridad mejor que nada: un modo no autenticado de IPsec
• RFC 5529: Modos de funcionamiento de camelia para su uso con IPsec
• RFC 5685: Mecanismo de redireccionamiento para la versión 2 del Protocolo de intercambio de claves de Internet (IKEv2)
• RFC 5723: Reanudación de sesión del Protocolo de intercambio de claves de Internet versión 2 (IKEv2)
• RFC 5857: Extensiones IKEv2 para admitir una sólida compresión de encabezados a través de IPsec
• RFC 5858: Extensiones de IPsec para admitir una sólida compresión de encabezados a través de IPsec
• RFC 7296: Protocolo de intercambio de claves de Internet versión 2 (IKEv2)
• RFC 7321: Requisitos de implementación de algoritmos criptográficos y guía de uso para encapsular la carga útil de seguridad (ESP) y el encabezado de autenticación (AH)
• RFC 7383: Fragmentación de mensajes del Protocolo de intercambio de claves de Internet versión 2 (IKEv2)
• RFC 7427: Autenticación de firma en Internet Key Exchange Version 2 (IKEv2)
• RFC 7634: ChaCha20, Poly1305 y su uso en el Protocolo de intercambio de claves de Internet (IKE) e IPsec

RFC experimentales

• RFC 4478: Autenticación repetida en el protocolo de intercambio de claves de Internet (IKEv2)

RFC informativas

• RFC 2367: Interfaz PF_KEY
• RFC 2412: Protocolo de determinación de claves de OAKLEY
• RFC 3706: un método basado en el tráfico para detectar pares muertos en el intercambio de claves de Internet (IKE)
• RFC 3715: Requisitos de compatibilidad de traducción de direcciones de red (NAT) IPsec
• RFC 4621: Diseño del protocolo IKEv2 Mobility and Multihoming (MOBIKE)
• RFC 4809: Requisitos para un perfil de gestión de certificados IPsec
• RFC 5387: Declaración de problema y aplicabilidad para una seguridad mejor que nada (BTNS)
• RFC 5856: Integración de una sólida compresión de encabezados sobre asociaciones de seguridad IPsec
• RFC 5930: Uso del modo de contador estándar de cifrado avanzado (AES-CTR) con el protocolo de intercambio de claves de Internet versión 02 (IKEv2)
• RFC 6027: Declaración del problema del clúster IPsec
• RFC 6071: Hoja de ruta de documentos IPsec e IKE
• RFC 6379: Suites criptográficas Suite B para IPsec
• RFC 6380: Perfil de Suite B para seguridad de protocolo de Internet (IPsec)
• RFC 6467: Marco de contraseña segura para el intercambio de claves de Internet versión 2 (IKEv2)

RFC de mejores prácticas actuales

• RFC 5406: Directrices para especificar el uso de IPsec versión 2

RFC obsoletas / históricas

• RFC 1825: Arquitectura de seguridad para el protocolo de Internet (obsoleto por RFC 2401)
• RFC 1826: Encabezado de autenticación de IP (obsoleto por RFC 2402)
• RFC 1827: Carga útil de seguridad de encapsulación IP (ESP) (obsoleta por RFC 2406)
• RFC 1828: Autenticación de IP usando Keyed MD5 (histórico)
• RFC 2401: Arquitectura de seguridad para el protocolo de Internet (descripción general de IPsec) (obsoleto por RFC 4301)
• RFC 2406: Carga útil de seguridad de encapsulación IP (ESP) (obsoleta por RFC 4303 y RFC 4305)
• RFC 2407: El dominio de interpretación de seguridad IP de Internet para ISAKMP (obsoleto por RFC 4306)
• RFC 2409: Intercambio de claves de Internet (obsoleto por RFC 4306)
• RFC 4305: Requisitos de implementación de algoritmos criptográficos para encapsular la carga útil de seguridad (ESP) y el encabezado de autenticación (AH) (obsoleto por RFC 4835)
• RFC 4306: Protocolo de intercambio de claves de Internet (IKEv2) (obsoleto por RFC 5996)
• RFC 4718: Aclaraciones y directrices de implementación de IKEv2 (obsoleto por RFC 7296)
• RFC 4835: Requisitos de implementación de algoritmos criptográficos para encapsular la carga útil de seguridad (ESP) y el encabezado de autenticación (AH) (obsoleto por RFC 7321)
• RFC 5996: Protocolo de intercambio de claves de Internet versión 2 (IKEv2) (obsoleto por RFC 7296)

Ver también

• Red privada virtual multipunto dinámica
• Seguridad de información
• NAT transversal
• Cifrado oportunista
• tcpcrypt

Referencias

1. Kent, S .; Atkinson, R. (noviembre de 1998). Carga útil de seguridad de encapsulación IP (ESP) . IETF . doi : 10.17487 / RFC2406 . RFC 2406 .
2. "Implementación del protocolo IPSec - publicación de la conferencia IEEE". doi : 10.1109 / ACCT.2012.64 . S2CID 16526652 . 
3. "Copia archivada" . Archivado desde el original el 3 de septiembre de 2014 . Consultado el 18 de febrero de 2014 .
4. "La historia de la creación de VPN" .
5. " http://web.mit.edu/network/isakmp/ "
6. " https://www.usenix.org/legacy/publications/library/proceedings/sd96/atkinson.html "
7. " http://web.mit.edu/network/isakmp/ "
8. "Historial del grupo de trabajo del protocolo de seguridad IP IETF (ipsec)" .
9. "RFC4301: Arquitectura de seguridad para el protocolo de Internet" . Grupo de trabajo en red del IETF. Diciembre de 2005. p. 4. Se prefiere la ortografía "IPsec" y se utiliza en todo este y todos los estándares IPsec relacionados. Todas las demás capitalizaciones de IPsec [...] están en desuso.
10. "Logros de NRL ITD - IPSec e IPv6" (PDF) . Laboratorios de Investigación Naval de EE . UU .
11. Thayer, R .; Doraswamy, N .; Glenn, R. (noviembre de 1998). Hoja de ruta del documento de seguridad IP . IETF . doi : 10.17487 / RFC2411 . RFC 2411 .
12. Hoffman, P. (diciembre de 2005). Suites criptográficas para IPsec . IETF . doi : 10.17487 / RFC4308 . RFC 4308 .
13. Kent, S .; Atkinson, R. (noviembre de 1998). Encabezado de autenticación de IP . IETF . doi : 10.17487 / RFC2402 . RFC 2402 .
14. Kent, S. (diciembre de 2005). Encabezado de autenticación de IP . IETF . doi : 10.17487 / RFC4302 . RFC 4302 .
15. El intercambio de claves de Internet (IKE), RFC 2409, §1 Resumen
16. Harkins, D .; Carrel, D. (noviembre de 1998). El intercambio de claves de Internet (IKE) . IETF . doi : 10.17487 / RFC2409 . RFC 2409 .
17. Kaufman, C. (ed.). IKE versión 2 . IETF . doi : 10.17487 / RFC4306 . RFC 4306 .
18. Sakane, S .; Kamada, K .; Thomas, M .; Vilhuber, J. (noviembre de 1998). Negociación Kerberizada de Claves por Internet (KINK) . IETF . doi : 10.17487 / RFC4430 . RFC 4430 .
19. Richardson, M. (febrero de 2005). Un método para almacenar material de claves IPsec en DNS . IETF . doi : 10.17487 / RFC4025 . RFC 4025 .
20. Peter Willis (2001). Redes IP a escala de operador: diseño y operación de redes de Internet . IET. pag. 270. ISBN 9780852969823.
21. "Números de protocolo" . IANA . IANA . 2010-05-27. Archivado desde el original el 29 de mayo de 2010.
22. "Carga útil de seguridad encapsulante SIPP" . Grupo de trabajo IETF SIPP. 1993. Archivado desde el original el 9 de septiembre de 2016 . Consultado el 7 de agosto de 2013 .
23. "Proyecto de especificación SIPP" . IETF. 1993. p. 21.
24. Bellovin, Steven M. (1996). "Áreas problemáticas para los protocolos de seguridad IP" ( PostScript ) . Actas del Sexto Simposio de Seguridad de Usenix Unix . San José, CA. págs. 1-16 . Consultado el 9 de julio de 2007 .
25. Paterson, Kenneth G .; Yau, Arnold KL (24 de abril de 2006). "Criptografía en teoría y práctica: el caso de la encriptación en IPsec" (PDF) . Eurocrypt 2006, Lecture Notes in Computer Science Vol. 4004 . Berlina. págs. 12-29 . Consultado el 13 de agosto de 2007 .
26. Degabriele, Jean Paul; Paterson, Kenneth G. (9 de agosto de 2007). "Atacando los estándares IPsec en configuraciones de solo cifrado" (PDF) . Simposio de IEEE sobre seguridad y privacidad, IEEE Computer Society . Oakland, CA. págs. 335–349 . Consultado el 13 de agosto de 2007 .
27. Kent, S. (diciembre de 2005). Carga útil de seguridad de encapsulación IP (ESP) . IETF . doi : 10.17487 / RFC4303 . RFC 4303 .
28. Peter Willis (2001). Redes IP a escala de operador: diseño y operación de redes de Internet . IET. pag. 271. ISBN 9780852969823.
29. Peter Willis (2001). Redes IP a escala de operador: diseño y operación de redes de Internet . IET. págs. 272–3. ISBN 9780852969823.
30. RFC 2406, §1, página 2
31. Thomas, M. (junio de 2001). Requisitos para la negociación de claves en Internet kerberizada . doi : 10.17487 / RFC3129 . RFC 3129 .
32. C. Cremers, Key Exchange in IPsec Revisited: Formal Analysis of IKEv1 and IKEv2, ESORICS 2011, publicado por Springer: " https://link.springer.com/chapter/10.1007/978-3-642-23822-2_18 "
33. William, S. y Stallings, W. (2006). Criptografía y seguridad de la red, 4 / E. Pearson Education India. pag. 492-493
34. Peter Willis (2001). Redes IP a escala de operador: diseño y operación de redes de Internet . IET. pag. 266. ISBN 9780852969823.
35. Peter Willis (2001). Redes IP a escala de operador: diseño y operación de redes de Internet . IET. pag. 267. ISBN 9780852969823.
36. RFC 2367, API de administración de claves PF_KEYv2 , Dan McDonald, Bao Phan y Craig Metz (julio de 1998)
37. Hamad, Mohammad; Prevelakis, Vassilis (2015). Implementación y evaluación del desempeño de IPsec embebido en microkernel OS . Simposio mundial de 2015 sobre redes informáticas y seguridad de la información (WSCNIS) . IEEE. doi : 10.1109 / wscnis.2015.7368294 . ISBN 9781479999064. S2CID 16935000.
38. RFC 6434, "IPv6 Node Requirements", E. Jankiewicz, J. Loughney, T. Narten (December 2011)
39. "ipsecme charter". Retrieved 2015-10-26.
40. "ipsecme status". Retrieved 2015-10-26.
41. "Secret Documents Reveal N.S.A. Campaign Against Encryption". New York Times.
42. John Gilmore. "Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"".
43. Theo de Raadt. "Allegations regarding OpenBSD IPSEC".
44. Jason Wright. "Allegations regarding OpenBSD IPSEC".
45. Theo de Raadt. "Update on the OpenBSD IPSEC backdoor allegation".
46. David Adrian; Karthikeyan Bhargavan; Zakir Durumeric; Pierrick Gaudry; Matthew Green; J. Alex Halderman; Nadia Heninger; Drew Springall; Emmanuel Thomé; Luke Valenta; Benjamin VanderSloot; Eric Wustrow; Santiago Zanella-Béguelink; Paul Zimmermann. "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice" (PDF).
47. Goodin, Dan (August 16, 2016). "Confirmed: hacking tool leak came from "omnipotent" NSA-tied group". Ars Technica. Retrieved August 19, 2016.
48. Thomson, Iain (August 17, 2016). "Cisco confirms two of the Shadow Brokers' 'NSA' vulns are real". The Register. Retrieved September 16, 2016.
49. Pauli, Darren (August 24, 2016). "Equation Group exploit hits newer Cisco ASA, Juniper Netscreen". The Register. Retrieved September 16, 2016.
50. Chirgwin, Richard (August 18, 2016). "Fortinet follows Cisco in confirming Shadow Broker vuln". The Register. Retrieved September 16, 2016.
51. https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf
52. What are the problems of IKEv1 aggressive mode (compared to IKEv1 main mode or IKEv2)?
53. https://nohats.ca/wordpress/blog/2014/12/29/dont-stop-using-ipsec-just-yet/

External links

• Computer Security at Curlie
• All IETF active security WGs
  • IETF ipsecme WG ("IP Security Maintenance and Extensions" Working Group)
  • IETF btns WG ("Better-Than-Nothing Security" Working Group) (chartered to work on unauthenticated IPsec, IPsec APIs, connection latching)]
• Securing Data in Transit with IPsec WindowsSecurity.com article by Deb Shinder
• IPsec on Microsoft TechNet
  • Microsoft IPsec Diagnostic Tool on Microsoft Download Center
• An Illustrated Guide to IPsec by Steve Friedl
• Security Architecture for IP (IPsec) Data Communication Lectures by Manfred Lindner Part IPsec
• Creating VPNs with IPsec and SSL/TLS Linux Journal article by Rami Rosen