IKEv1 fronte a IKEv2: autenticación con clave precompartida e que cambia

Dous pasarelas configuradas coa mesma clave precompartida completan unha aperta de mans, e unha captura de paquetes non mostra ningún segredo cruzando o cable. Esa é a parte que a xente lembra. A parte interesante é que calcula realmente cada versión para demostrar que o segredo se coñece, porque IKEv1 e IKEv2 constrúen esa proba a partir de entradas distintas e expoñen información distinta ao facelo. Lea as dúas trazas en paralelo e a diferenza deixa de ser cosmética.

Que debe acadar a proba

Diffie-Hellman dá a ambos os pares un valor compartido cuxas metades públicas tamén pode calcular calquera que observe. Por si só iso non demostra nada sobre a identidade: un atacante que completa un intercambio de claves ten o mesmo valor compartido que a súa pasarela. O paso de autenticación existe para vincular ese intercambio a un segredo que só posúen os pares previstos, e ás identidades e parámetros que acordaron.

Ese vínculo é a razón pola que o hash cobre máis que a clave. Se só cobrise o segredo, un atacante podería reutilizalo noutro intercambio con identidades ou propostas distintas.

IKEv1 Main Mode: derivar SKEYID e despois demostralo

Main Mode executa seis mensaxes. O primeiro par negocia a asociación de seguridade, o segundo intercambia valores públicos de Diffie-Hellman e nonces, e o terceiro transporta identidades máis hashes de autenticación baixo o cifrado que se acaba de establecer. RFC 2409 define a construción: coa autenticación por clave precompartida, SKEYID derívase do segredo e de ambos os nonces, e o material de clave posterior derívase de SKEYID, do valor compartido de Diffie-Hellman, das cookies e das constantes.

O hash das mensaxes cinco e seis calcúlase sobre o valor de Diffie-Hellman, as dúas cookies, a proposta e a identidade do emisor, con SKEYID como clave. O receptor recalcúlao co seu propio segredo configurado. Unha discrepancia termina o intercambio, e en ningún momento o segredo mesmo é unha carga útil.

Aggressive Mode comprime o mesmo traballo en tres mensaxes, o que significa que as identidades e o hash de autenticación viaxan antes de que exista unha canle cifrada. Iso é unha exposición real para un segredo adiviñable, e é independente da cuestión de se o segredo se transmitiu. IKEv1 está desaconsellado por RFC 9395, así que unha traza herdada é un exercicio de diagnóstico e non un obxectivo de despregamento.

IKEv2: unha derivación distinta e unha carga AUTH distinta

IKEv2 non reutiliza o calendario de claves de IKEv1. As claves IKE iniciais proveñen dunha semente construída cos nonces e o valor compartido de Diffie-Hellman, e as asociacións de seguridade fillas derívanse dela. A clave precompartida non alimenta a semente en absoluto.

A autenticación aparece entón como unha carga AUTH. Para a autenticación con clave compartida, RFC 7296 especifica unha forma rechea do segredo, producida ao aplicar hash ao segredo coa cadea fixa Key Pad for IKEv2, e despois ao aplicar hash aos datos de intercambio asinados e á identidade con esa clave rechea. O verificador pode reconstruír o mesmo valor; un observador non pode, sen o segredo.

Fíxese en que cambiou. En IKEv1 o segredo está incrustado no calendario de claves antes de que exista o hash de autenticación; en IKEv2 o calendario de claves é independente do segredo e a proba é unha carga distinta ligada aos octetos asinados. A mesma garantía conceptual, maquinaria distinta, e por iso os nomes de parámetros e as capturas non se corresponden un a un.

Que aprende realmente un observador

Os valores públicos de Diffie-Hellman, as propostas, os nonces e as cookies son visibles en ambas as versións. As identidades son visibles en IKEv1 Aggressive Mode e están protexidas nos demais casos. O segredo nunca é visible.

Esa última frase ten un límite que convén sinalar. Un segredo débil escollido por unha persoa pode atacarse adiviñando: o atacante calcula cal sería o valor de autenticación para un candidato a segredo e compara. IKEv1 Aggressive Mode faino máis barato porque a evidencia está á vista, e os estándares advirten en xeral sobre segredos de baixa entropía. Non transmitir nunca o segredo non é o mesmo que facer seguro un segredo malo.

Que facer coa comparación

Use un segredo único por par de pares, xéreo a partir dunha fonte aleatoria e rótao pola mesma ruta de aprovisionamento que o distribuíu. Se o segredo se garda nun modelo de configuración que se envía a cada sucursal, un compromiso nun sitio é un compromiso en todas partes.

Preferide a autenticación baseada en certificados cando o custo operativo sexa aceptable, xa que elimina o problema de adiviñar o segredo compartido e dá a cada par unha identidade distinta. Onde se manteña unha clave precompartida, fagana longa, limite o seu alcance e trate a versión de IKE como unha decisión de seguridade e non como un detalle de interoperabilidade.