IKEv1 frente a IKEv2: autenticación con clave precompartida y qué cambia

Dos puertas de enlace configuradas con la misma clave precompartida completan un protocolo de enlace, y una captura de paquetes no muestra ningún secreto cruzando el cable. Esa es la parte que la gente recuerda. La parte interesante es qué calcula realmente cada versión para demostrar que el secreto se conoce, porque IKEv1 e IKEv2 construyen esa prueba a partir de entradas distintas y exponen información distinta al hacerlo. Lea las dos trazas en paralelo y la diferencia deja de ser cosmética.

Qué debe lograr la prueba

Diffie-Hellman da a ambos pares un valor compartido cuyas mitades públicas también puede calcular cualquiera que observe. Por sí solo eso no demuestra nada sobre la identidad: un atacante que completa un intercambio de claves tiene el mismo valor compartido que su puerta de enlace. El paso de autenticación existe para vincular ese intercambio a un secreto que solo poseen los pares previstos, y a las identidades y parámetros que acordaron.

Ese vínculo es la razón por la que el hash cubre más que la clave. Si cubriera solo el secreto, un atacante podría reutilizarlo en otro intercambio con identidades o propuestas distintas.

IKEv1 Main Mode: derivar SKEYID y luego demostrarlo

Main Mode ejecuta seis mensajes. El primer par negocia la asociación de seguridad, el segundo intercambia valores públicos de Diffie-Hellman y nonces, y el tercero transporta identidades más hashes de autenticación bajo el cifrado que se acaba de establecer. RFC 2409 define la construcción: con autenticación por clave precompartida, SKEYID se deriva del secreto y de ambos nonces, y el material de clave posterior se deriva de SKEYID, del valor compartido de Diffie-Hellman, de las cookies y de las constantes.

El hash de los mensajes cinco y seis se calcula sobre el valor de Diffie-Hellman, las dos cookies, la propuesta y la identidad del emisor, con SKEYID como clave. El receptor lo recalcula con su propio secreto configurado. Una discrepancia termina el intercambio, y en ningún momento el secreto mismo es una carga útil.

Aggressive Mode comprime el mismo trabajo en tres mensajes, lo que significa que las identidades y el hash de autenticación viajan antes de que exista un canal cifrado. Es una exposición real para un secreto adivinable, y es independiente de la cuestión de si el secreto se transmitió. IKEv1 está desaconsejado por RFC 9395, así que una traza heredada es un ejercicio de diagnóstico y no un objetivo de despliegue.

IKEv2: una derivación distinta y una carga AUTH distinta

IKEv2 no reutiliza el calendario de claves de IKEv1. Las claves IKE iniciales provienen de una semilla construida con los nonces y el valor compartido de Diffie-Hellman, y las asociaciones de seguridad hijas se derivan de ella. La clave precompartida no alimenta la semilla en absoluto.

La autenticación aparece entonces como una carga AUTH. Para la autenticación con clave compartida, RFC 7296 especifica una forma rellenada del secreto, producida al aplicar hash al secreto con la cadena fija Key Pad for IKEv2, y luego al aplicar hash a los datos de intercambio firmados y a la identidad con esa clave rellenada. El verificador puede reconstruir el mismo valor; un observador no puede, sin el secreto.

Fíjese en qué cambió. En IKEv1 el secreto está incrustado en el calendario de claves antes de que exista el hash de autenticación; en IKEv2 el calendario de claves es independiente del secreto y la prueba es una carga distinta ligada a los octetos firmados. La misma garantía conceptual, maquinaria distinta, y por eso los nombres de parámetros y las capturas no se corresponden uno a uno.

Qué aprende realmente un observador

Los valores públicos de Diffie-Hellman, las propuestas, los nonces y las cookies son visibles en ambas versiones. Las identidades son visibles en IKEv1 Aggressive Mode y están protegidas en los demás casos. El secreto nunca es visible.

Esa última frase tiene un límite que conviene señalar. Un secreto débil elegido por una persona puede atacarse adivinando: el atacante calcula cuál sería el valor de autenticación para un candidato a secreto y compara. IKEv1 Aggressive Mode lo hace más barato porque la evidencia está a la vista, y los estándares advierten en general sobre secretos de baja entropía. No transmitir nunca el secreto no es lo mismo que hacer seguro un secreto malo.

Qué hacer con la comparación

Use un secreto único por par de pares, genérelo a partir de una fuente aleatoria y rótelo por la misma ruta de aprovisionamiento que lo distribuyó. Si el secreto se guarda en una plantilla de configuración que se envía a cada sucursal, un compromiso en un sitio es un compromiso en todas partes.

Prefiera la autenticación basada en certificados cuando el coste operativo sea aceptable, ya que elimina el problema de adivinar el secreto compartido y da a cada par una identidad distinta. Donde se mantenga una clave precompartida, hágalo larga, limite su alcance y trate la versión de IKE como una decisión de seguridad y no como un detalle de interoperabilidad.