Introducción

Una VPN (Virtual Private Network) conecta dos subredes seguras a través de una red insegura, como Internet. Permite que las empresas puedan usar Internet para conectar sus oficinas remotas o sus trabajadores remotos de forma segura.
Propiedades:
- Encapsulado: los datos son encapsulados en otro protocolo que incluye la cabecera con información para el encaminamiento para atravesar la red insegura. El encapsulado en otro protocolo se denomina tunneling (tunelización).
- Autenticación: garantiza la identidad del origen del mensaje.
- Confidencialidad: garantiza la confidencialidad de los datos que viajan a través de una red insegura.
- Integridad: garantiza que los datos no han sido alterados por el camino.
- Antirreproducción: detección de un ataque de reproducción.

Topologías basadas en VPN

Host-host: la VPN ofrece una conexión directa entre las dos máquinas.
Host-network: la VPN ofrece una conexión directa entre una máquina y una subred. Resuelve la conexión de un trabajador remoto con la red de la empresa.
Network-network: la VPN ofrece una conexión directa entre dos subredes. Resuelve la conexión entre 2 oficinas remotas.

Ventajas/Inconvenientes

Ventajas
- Seguridad
- Transparencia para los usuarios
- Reducción de costes
Inconvenientes
- Configuración y gestión
- Generación de claves
- Problemas con NAT y firewalls.
- Interoperabilidad de las implementaciones.

Protocolos

PPTP (Point-to-point Tunneling Protocol), RFC-2637. Desarrollado por un consorcio formado por Microsoft. Protocolo no seguro (2 días).
L2TP (Layer 2 Tunneling Protocol), RFC 2661, incluye todas las características de PPTP y Cisco L2F (Layer 2 Forward). Nueva versión L2TPv3 (RFC-3931)
IPSec es un protocolo de nivel de red creado por el IETF que puede enviar datos cifrados para redes IP. Requiere modificaciones en el nivel IP. Muy flexible, muy complejo.
SSLv3/TLSv1 (Secure Sockets Layer/Transport Layer Security). Protocolo que se encuentra entre el nivel de aplicación y el nivel de transporte. Lo usan las aplicaciones para asegurar sus comunicaciones:
- HTTPS, SMTPS, FTPS, OpenVPN, etc.

OpenVPN

Open Source creado en 2002 para construir VPN entre subredes que puede utilizar dos modelos de seguridad diferentes:
- protocolos SSL/TLS
- claves compartidas previamente
Envía los datos cifrados a través de una red insegura, utilizando para ello una comunicación UDP o TCP, puerto por defecto 1194.
- Estudiaremos el caso de UDP, TCP es conveniente en ciertos entornos pero los algoritmos de control de congestión pueden afectar a la eficiencia de la transmisión.
Muy fácil de instalar.
Funciona con el paradigma cliente/servidor.
Puede crear túneles de nivel de enlace o de nivel de red.

Sesión OpenVPN

Dentro de la misma sesión OpenVPN establece dos canales diferentes de comunicación:
- Canal de control:
  - Establecimiento de la comunicación SSL/TLS, intercambio de claves, establecimiento de los algoritmos de seguridad, autenticación, etc.
  - El establecimiento de la comunicación SSL/TLS requiere un protocolo fiable, como openVPN usa UDP, se introducen mensajes ACK para confirmar la recepción de los mensajes. Los mensajes utilizados en el canal de control son P_CONTROL y los asentimientos P_ACK.
- Canal de datos:
  - Se utiliza una vez establecida la comunicación SSL/TLS, usará mensajes UDP sin asentimientos.
  - Los mensajes utilizados son P_DATA que van cifrados.

Cabecera de los mensajes openVPN

OpenVPN introduce una cabecera en todos los mensajes que contiene los siguientes campos:
- Longitud del paquete (16 bits) sólo en TCP.
- opcode (5 bits) sólo en el modo TLS. Es el tipo de mensaje.
- key_id (3 bits) sólo en el modo TLS. Hace referencia a la sesión TLS negociada. La sesión TLS se renegocia usando un nuevo key_id.

Tipo de mensajes OpenVPN (opcode)

Tipos de mensajes en el canal de control:
- Método 1 de clave, establecimiento de identificador de sesión TLS desde el cliente.
- Método 1 de clave, establecimiento de identificador de sesión TLS desde el servidor.
- Método 2 de clave, establecimiento de identificador de sesión TLS desde el cliente.
- Método 2 de clave, establecimiento de identificador de sesión TLS desde el servidor.
- Establecimiento de nueva sesión TLS, hay una ventana en la que se usarán tanto la antigua como la nueva.
- Canal de control para establecer el algoritmo de seguridad dentro del túnel. En este tipo de mensajes viajará el mecanismo para el establecimiento de las claves TLS/SSL.
- Asentimiento de los mensajes de P_CONTROL.
Tipos de mensajes en el canal de datos:
- Datos cifrados en el túnel.
- Datos cifrados en el túnel y la identificación de los extremos.

Intercambio de mensajes OpenVPN

Inicialmente se intercambian los mensajes para establecer el identificador de sesión TLS desde el cliente y el servidor.

OpenVPN implementa 2 métodos de claves:

-   Método 1 de clave: deriva claves aleatorias a partir de la
    función `rand_bytes()`.

-   Método 2 de clave: mezcla información aleatoria de los dos
    extremos de la conexión usando la función TLS PRF. Éste es el
    método por defecto para OpenVPN 2.0.

Estos mensajes deben ir asentidos desde cada extremo:
A continuación se establecen los parámetros de seguridad en el establecimiento de la sesión TLS a través de los mensajes que deberán ir asentidos .
- Los mensajes P_CONTROL_V1 contendrán la información de la sesión TLS donde se intercambiarán los mensajes Client Hello, Server Hello, intercambio de claves y certificados, especificación de algoritmos de cifrado.
Una vez establecida la configuración de seguridad a través de TLS se pueden enviar/recibir datos cifrados a través del túnel, utilizando el canal de datos:

Formato de mensajes P_CONTROL_V1

Local session_id (8 bytes):

número aleatorio para identificar la sesión TLS local.
HMAC signature de la cabecera entera :

para integridad (si se ha especificado --tls-auth).
Message packet-id array length (1 byte):

longitud del siguiente campo.
packet-id array:

identificadores de paquetes que se asienten.
Remote session_id (8 bytes):

número de identificador de la sesión TLS remota.
Message packet-id (4 bytes):

Identificador de paquete sólo en los mensajes de control.
TLS payload ciphertext (n bytes):

sólo en P_CONTROL_V1.

Ejemplo de mensaje P_CONTROL_V1

Ejemplo de mensaje P_ACK_V1

Ejemplo de mensaje P_DATA_V1

Algunos mensajes P_DATA_V1 llevan información de control, se utilizan como mensajes keepalive, consulta de MTU, etc.
OpenVPN establece que no puede pasar mucho tiempo sin que se envíen mensajes P_DATA. Dependiendo de la configuración si pasa mucho tiempo puede desactivarse la configuración del túnel.

IPSec

IPSec proporciona una comunicación IP segura entre 2 entidades, IPSec peers. Un IPSec peer puede ser un router o una máquina final.
IPSec establece un túnel IPSec entre 2 entidades IPsec peers para proteger los datos. Dos IPSec peer pueden definir varios túneles IPSec.
IPSec utiliza los siguientes protocolos:
- AH (Authentication Header, código de protocolo=51): protocolo para la autenticación, integridad de datos y no repudio.
- ESP (Encapsulation Security Payload, código de protocolo=50): protocolo que proporciona confidencialidad y/o autenticación.
IPSec utiliza el protocolo IKE (Internet Key Exchange) para gestionar las claves. Durante la fase de negociación, IKE especifica el flujo de tráfico que hará uso de la conexión IPsec: protocolo, direcciones IP, ToS.

Nomenclatura IPSec

Una política de seguridad (Security Policy, (SP)) es una regla programada en la implementación de IPSec que indica si un paquete debe usar IPsec o directamente la pila TCP/IP. Las SPs se almacenan en la Security Policy Database (SPD).
Una asociación de seguridad (Security Associations, SA) definen los parámetros de una comunicación entre dos IPSec peers en un sentido de la comunicación determinado (para la comunicación bidireccional son necesarias 2 SAs):
- protocolo de seguridad, modo de cifrado de datos, atributos de la comunicación, claves, tiempo de vida, etc.
IPSec puede establecer el túnel si se acuerdan los mismos parámetros entre los extremos de una SA. Las SAs se almacenan en la Security Association Database (SAD).

Cuando se envía un paquete se consulta SPD para saber si requiere IPSec. En caso afirmativo, SPD referencia una SA de SAD. La SA indica cómo debe ser cifrado/autenticado dicho paquete.

SA (Security Association)

Una SA contiene toda la información necesaria para descifrar/autenticar un paquete IPSec: algoritmos y claves, número de secuencia actual, tiempo de vida de SA, etc.
Una SA queda identificado por 3 parámetros:
- Security Parameter Index (SPI)
- Dirección IP destino
- Protocolo de seguridad (AH o ESP)
Una SA puede configurarse manualmente o a través del protocolo IKE que negocia las claves y mantiene los SAs.

Dos SAs: r1 $\rightarrow$ r2 y r1 $\leftarrow$ r2

SP (Security Policy)

Una SP es una regla que indica los valores que debe tener un datagrama para aplicarle una configuración IPSec. Se examina la cabecera IP y la cabecera de nivel de transporte para consultar los siguientes campos
- Direcciones IP origen/destino
- Protocolo de nivel de transporte
- Puertos origen/destino
Las reglas SP también se denominan selectores de tráfico (TS, Traffic Selectors).
Las reglas SP se almacenan en SPD.

Envío y recepción de paquetes IPSec

Envío: se consulta SPD para encontrar una política y saber si es necesario aplicar IPSec.
- Si no es necesario, el paquete se procesa utilizando la pila TCP/IP.
- Si es necesario, se busca si existe SA, se utiliza la información para construir paquete IPSec. Si no existe, se crea utilizando IKE.
Recepción: se consulta SAD usando la información del paquete $<$SPI,dirIPDestino,Protocolo$>$, se descifra/autentica el paquete y se consulta SPD para saber si existía una política asociada a dicho paquete.

AH (Authentication Header)

Garantiza:
- autenticación de origen y no repudio
- integridad de la cabecera IP y de los datos.
El emisor y el receptor del paquete comparten una clave secreta:
- La clave se utiliza en el cáculo de HMAC.
- La clave se configura a través de IKE y se guarda en el SA, junto con el algoritmo de hash utilizado: MD5, SHA.
- El emisor calcula HMAC del paquete IP original y los campos de la cabecera AH y almacena ese valor en la cabecera AH. El receptor también calcula el HMAC y lo compara junto con el valor que recibe en la cabecera AH para ver si los datos se han modificado en el trayecto.
Dos modos:
- Modo transporte: inserta la cabecera AH entre la cabecera IP y los datos IP del paquete original.
- Modo túnel: no modifica el paquete IP original, construye una nueva cabecera IP junto con la cabecera AH, a continuación adjunta el paquete IP original.

Cabecera AH en modo transporte

Protocolo = AH = 51 Sig. Cab. = Protocolo datagrama IP original

Cabecera AH en modo túnel

Protocolo = AH = 51 Sig. Cab. = IPv4 = 4

AH: Modo transporte vs túnel

En modo transporte:
- Los extremos de la comunicación deben soportar IPSec.
- Quedan protegidos todos los campos inmutables¹ de la cabecera IP original, los datos del paquete IP original y los campos de la cabecera AH.
- No soporta NAT, hay extensiones.
En modo túnel:
- Se protege la identidad de los extremos que están comunicándose pues la cabecera externa oculta las direcciones IP de los extremos.
- Quedan protegidos todos los campos inmutables de la cabecera externa, el datagrama original completo y los campos de la cabecera AH.

Campos de la cabecera AH

Sig. Cab.: Siguiente cabecera o tipo de datos que van a continuación de la cabecera AH. En modo transporte este campo llevará el protocolo de nivel de transporte y en modo túnel llevará el protocolo IP.
Long. datos: Longitud de la cabecera AH.
SPI: junto con dirección IP destino y protocolo AH identifica SA.
Número de secuencia: se incrementa cada vez que se envía un paquete utilizando una determinada SA. Evita ataques de reproducción.
ICV: cálculo de HMAC utilizando el algoritmo fijado.

ESP (Encapsulation Security Payload)

Garantiza:
- Confidencialidad a través de cifrado.
- Integridad del paquete cifrado a través de HMAC, o combinándolo con AH.
ESP distingue los siguientes componentes en su formato:
- ESP Header: contiene SPI y número de secuencia. Viaja antes que los datos cifrados.
- Datos cifrados.
- ESP Trailer: relleno o padding para alinear los datos cifrados, longitud del relleno y el campo sig. cabecera. Viaja después de los datos cifrados.
- ESP Authentication Data: ICV si ESP ha elegido proporcionar integridad al paquete cifrado.

Formato del mensaje ESP

El campo Sig. Cab. va cifrado e indica de qué protocolo son los datos que van cifrados.

ESP: Modo transporte vs túnel

En modo transporte:
- Los extremos de la comunicación deben soportar IPSec.
- Sólo se cifran los datos del datagrama IP.
En modo túnel:
- Se cifra el datagrama IP completo.
- Se oculta cuáles son las direcciones IP de los extremos que se están comunicando.

ESP en modo transporte

Protocolo = ESP = 50 Sig. Cab. = Protocolo de nivel de transporte que llevaba el datagrama IP original

ESP en modo túnel

Protocolo = ESP = 50 Sig. Cab. = IPv4 = 4

Internet Key Exchange (IKE)

IKE (RFC-2409), IKEv2 (RFC-7296) es una optimización de la versión anterior con menor número de mensajes y otras funcionalidades como poder atravesar un NAT.
Simplifica la configuración de IPSec ya que establece una SA en IPSec.
IKE es un protocolo de nivel de aplicación sobre UDP en el puerto 500 y/o 4500. Se construye sobre el protocolo Internet Security Association and Key Management Protocol (ISAKMP).
Fases IKE:
- Primera fase: establecimiento de canal seguro utilizando claves Diffie-Hellman para generar una clave secreta que se usará para cifrar las comunicaciones IKE. Para ello se establece una IKE_SA bidireccional (asociación de seguridad para intercambiar mensajes IKE). La autenticación se puede realizar con diferentes mecanismos: pre-shared-key, PKI.
- Segunda fase: los extremos usan el canal seguro para establecer SA para IPSec, lo que se denomina CHILD_SA

Formato de los mensajes ISAKMP

Los intercambios de mensajes ISAKMP son de tipo solicitud/respuesta.
Las comunicaciones usando IKE son fiables, IKEv2 implementa un mecanismo de retransmisión si no se recibe respuesta a una solicitud.
Los mensajes ISAKMP están formados por una primera cabecera seguida de 1 o más campos de datos ISAKMP.

Tipos de datos dentro de un mensaje ISAKMP

Security Association, SA (33)
Key Exchange, KE (34)
Identidades IDi/IDr (35/36)
Certificate, CERT (37)
Certificate Request, CERTREQ (38)
Authentication (39)
Nonce (40)
Notify (41)
Contenido cifrado y autenticado (46)
...

Primera cabecera ISAKMP

IKE_SA Initiator SPI (8 bytes): SPI del que inicia la comunicación
IKE_SA Responder SPI (8 bytes): SPI del que responde a la comunicación (inicialmente a cero).
Campo siguiente tipo de datos ISAKMP: indica qué tipo de datos vienen a continuación.
Número de versión mayor=2, número de versión menor=0.
Tipo de intercambio (1 byte):
- IKE_SA_INIT
- IKE_AUTH
- CREATE_CHILD_SA
- INFORMATIONAL
Flags:
- R: respuesta=1, solicitud=0
- I: initiator=1, responder=0
- V: bit de versión, V=1 implementa versión superior, V=0 no la implementa.
- C: critical, qué hacer si el receptor no entiende el tipo de cabecera, C=0 lo ignora, C=1 envía mensaje.
Identificador de mensaje: es un número de sencuencia para identificar solicitud/respuesta. Se utiliza para las retransmisiones.

Establecimiento IPSec SA

Para establecer IPSec SA a través de IKEv2 serán necesarios 4 mensajes:
- Primera fase: 2 mensajes para establecer IKE SA, algoritmos y claves para cifrar/autenticar la comunicación que negociará IPSec SA.
  - Initiator -> Responder:
  - Initiator <-Responder:
- Segunda fase: 2 mensajes para establecer IPSec SA, algoritmos y claves para cifrar/autenticar la comunicación IPSec. Estos dos mensajes irán cifrados y autenticados con las claves derivadas del primer intercambio de IKE_SA_INIT.
  - Initiator -> Responder:
  - Initiator <- Responder:

Intercambio IKE_SA_INIT

Negocia IKE_SA
SAi1: SA de initiator para enviar una propuesta de los algoritmos que soporta
SAr1: SA de responder, elige un algoritmo para cada operación: cifrar, integridad, función pseudo-random
KEi, KEr son los valores Diffie Hellman (DH).
Ni, Nr: nonces
Opcionalmente, responder puede solicitar un certificado
A partir de los mensajes IKE_SA_INIT intercambiados se genera una clave de sesión SKEYSEED de la cuál derivarán las claves necesarias para cifrar SK_e, para firmar SK_a y para obtener el digest SK_d.

Mensaje de solicitud IKE_SA_INIT

Mensaje de solicitud enviado por el lado que inicia la comunicación

Mensaje de respuesta IKE_SA_INIT

Mensaje de respuesta enviado por el lado que responde la comunicación

Secreto compartido a partir de los valores DF: KEi, KEr

Initiator y Responder pueden calcular el secreto Diffie-Hellman de la siguiente forma: $g^{xy} \mod p$
En la cabecera Key Exchange se indica el grupo que se está utilizando: 3072 bit MODP group, que especifica el primo y el generador:
- Primo:
  
  $p=2^{3072} - 2^{3008} -1 + 2^{64} [(2^{2942} \pi) + 1690314]$
- Generador: g=2
Cada lado generará un número a partir de un secreto individual:
- Initiator genera $x$ y envía a Responder $X=g^x \mod p$
- Responder genera $y$ y envía a Initiator $Y=g^y \mod p$
El secreto Diffie-Hellman compartido por ambos y que ellos pueden calcular es:
- Initiator calcula $Y^x \mod p=(g^y)^x \mod p = g^{yx} \mod p$
- Responder calcula $X^y \mod p=(g^x)^y \mod p = g^{xy} \mod p$
prf(key, msg): prf es la función pseudo-aleatoria con clave (keyed pseudo-random function), cuya clave se proporciona en el parámetro key, utilizada para generar una salida determinista del mensaje msg y que parece pseudo-aleatoria. prf se utilizan para el cálculo de claves y para la autenticación (por ejemplo keyed MAC).

Intercambio IKE_AUTH

Autentica los extremos y establece CHILD_SA.
La notación SK { ...} significa que el contenido está cifrado utilizando las claves SK_e y SK_a de cada sentido de la comunicación.
Initiator envía su identidad dentro de IDi, puede enviar su certificado y una petición de certificados y puede enviar la identidad del Responder IDr.
Initiator comienza la negociación de CHILD_SA enviando su propuesta SAi2: algoritmos de cifrado/autenticación, SPI, protocolo ESP/AH.
TSi y TSr son selectores de tráfico: son los rangos de direcciones IP y puertos desde los que se va a aplicar el túnel y hasta los que se va a aplicar el túnel.
Responder envía su identidad IDr, opcionalmente enviará certificados. La autenticación y la integridad del mensaje se comprueban a través de AUTH.
Responder completa la negociación de CHILD_SA enviando su propuesta SAr2.

Mensaje de solicitud IKE_AUTH

Mensaje de solicitud enviado por el lado que inicia la comunicación. Este mensaje va cifrado por la claves que se han derivado de la negociación IKE_SA_INIT (en la figura se muestra descifrado porque se han utilizado las claves para descifrar el contenido).

Mensaje de respuesta IKE_AUTH

Mensaje de respuesta enviado por el lado que responde la comunicación. Este mensaje va cifrado por la claves que se han derivado de la negociación IKE_SA_INIT (en la figura se muestra descifrado porque se han utilizado las claves para descifrar el contenido).

Recálculo de claves: CREATE_CHILD_SA

Cada lado puede recalcular sus claves en cualquier momento.
El recálculo puede afectar a IKE SA o a CHILD_SA.
- En IKE SA: El nuevo IKE SA hereda todos los CHILD_SA.
- En CHILD_SA: se genera un nuevo SA y se borra el antiguo.

Intercambio de mensajes INFORMATIONAL

Se utilizan para el control y la notificación de errores.
Van cifrados con los parámetros del IKE SA.
Contienen los siguientes tipos de datos: NOTIFICATION, DELETE, CONFIGURATION.
Si no contiene datos se utiliza para saber si el otro extremo aún sigue activo.

Bibliografía

VPNs Illustrated, Tunnels, VPNs and IPSec, Jon C. Snader, Addison-Wesley.
OpenVPN Security Overview (https://openvpn.net/index.php/open-source/documentation/security-overview.html)
RFC 4301: Security Architecture for the Internet Protocol, S.Kent, K. Seo, December 2005.
RFC 4303: IP Encapsulation Security Payload (ESP), S.Kent, December 2005.
RFC 4302: IP Authentication Header, S. Kent. December 2005
RFC 7296: Internet Key Exchange Protocol Version 2 (IKEv2), Oct 2104, C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen.

¹. Todos son inmutables excepto algunos campos que varían en el trayecto, ToS, TTL, flags de fragmentación, offset fragmentación y checksum ↩