IKEv1 davant IKEv2: autenticació amb clau prèviament compartida i què canvia

Dues passarel·les configurades amb la mateixa clau prèviament compartida completen un intercanvi de salutació i una captura de paquets no mostra cap secret creuant el cable. Aquesta és la part que la gent recorda. La part interessant és què calcula realment cada versió per demostrar que el secret és conegut, perquè IKEv1 i IKEv2 construeixen aquesta prova a partir d'entrades diferents i exposen informació diferent mentre ho fan. Llegiu els dos traços costat a costat i la diferència deixa de ser cosmètica.

Què ha d'aconseguir la prova

Diffie-Hellman dona a tots dos iguals un valor compartit les meitats públiques del qual també pot calcular qualsevol que ho observi. Això sol no demostra res sobre la identitat: un atacant que completa un intercanvi de claus té el mateix valor compartit que la vostra passarel·la. El pas d'autenticació existeix per lligar aquest intercanvi a un secret que només posseeixen els iguals previstos, i a les identitats i paràmetres que han acordat.

Aquest lligam és la raó per la qual el hash cobreix més que la clau. Si només cobrís el secret, un atacant podria reutilitzar-lo en un altre intercanvi amb identitats o propostes diferents.

IKEv1 Main Mode: derivar SKEYID i després demostrar-lo

Main Mode executa sis missatges. La primera parella negocia l'associació de seguretat, la segona intercanvia valors públics de Diffie-Hellman i nonces, i la tercera porta identitats més hashes d'autenticació sota el xifratge que s'acaba d'establir. RFC 2409 defineix la construcció: amb autenticació per clau prèviament compartida, SKEYID es deriva del secret i de tots dos nonces, i el material de clau posterior es deriva de SKEYID, del valor compartit de Diffie-Hellman, de les galetes i de les constants.

El hash dels missatges cinc i sis es calcula sobre el valor de Diffie-Hellman, les dues galetes, la proposta i la identitat de l'emissor, amb SKEYID com a clau. El receptor el recalcula amb el seu propi secret configurat. Una discrepància acaba l'intercanvi, i en cap moment el secret mateix no és una càrrega útil.

Aggressive Mode comprimeix la mateixa feina en tres missatges, cosa que significa que les identitats i el hash d'autenticació viatgen abans que existeixi un canal xifrat. Això és una exposició real per a un secret endevidable, i és independent de la qüestió de si el secret es va transmetre. IKEv1 està desaconsellat per RFC 9395, així que un traç antic és un exercici de diagnòstic i no un objectiu de desplegament.

IKEv2: una derivació diferent i una càrrega AUTH diferent

IKEv2 no reutilitza el calendari de claus d'IKEv1. Les claus IKE inicials vénen d'una llavor construïda amb els nonces i el valor compartit de Diffie-Hellman, i les associacions de seguretat filles en deriven. La clau prèviament compartida no alimenta la llavor en absolut.

L'autenticació apareix llavors com una càrrega AUTH. Per a l'autenticació amb clau compartida, RFC 7296 especifica una forma emplenada del secret, produïda fent el hash del secret amb la cadena fixa Key Pad for IKEv2, i després fent el hash de les dades d'intercanvi signades i de la identitat amb aquesta clau emplenada. El verificador pot reconstruir el mateix valor; un observador no pot, sense el secret.

Fixeu-vos en què ha canviat. A IKEv1 el secret s'incorpora al calendari de claus abans que existeixi el hash d'autenticació; a IKEv2 el calendari de claus és independent del secret i la prova és una càrrega distinta lligada als octets signats. La mateixa garantia conceptual, maquinària diferent, i per això els noms dels paràmetres i les captures no es corresponen u a u.

Què aprèn realment un observador

Els valors públics de Diffie-Hellman, les propostes, els nonces i les galetes són visibles en totes dues versions. Les identitats són visibles a IKEv1 Aggressive Mode i protegides en els altres casos. El secret no és mai visible.

Aquesta darrera frase té un límit que val la pena esmentar. Un secret feble triat per una persona es pot atacar endevinant: l'atacant calcula quin seria el valor d'autenticació per a un candidat a secret i compara. IKEv1 Aggressive Mode ho fa el més barat perquè l'evidència és a la vista, i els estàndards adverteixen en general sobre secrets de baixa entropia. No transmetre mai el secret no és el mateix que fer segur un secret dolent.

Què fer amb la comparació

Useu un secret únic per a cada parella d'iguals, genereu-lo a partir d'una font aleatòria i renoveu-lo pel mateix camí de subministrament que el va distribuir. Si el secret s'emmagatzema en una plantilla de configuració que s'envia a cada sucursal, un compromís en un lloc és un compromís a tot arreu.

Preferiu l'autenticació basada en certificats quan el cost operatiu sigui acceptable, ja que elimina el problema d'endevinar el secret compartit i dona a cada igual una identitat distinta. On es mantingui una clau prèviament compartida, feu-la llarga, limiteu-ne l'abast i tracteu la versió d'IKE com una decisió de seguretat i no com un detall d'interoperabilitat.