IKEv1 face à IKEv2 : authentification par clé pré-partagée et ce qui change

Deux passerelles configurées avec la même clé pré-partagée terminent une poignée de main, et une capture de paquets ne montre aucun secret traverser le fil. C'est la partie dont les gens se souviennent. La partie intéressante est ce que chaque version calcule réellement pour prouver que le secret est connu, car IKEv1 et IKEv2 construisent cette preuve à partir d'entrées différentes et exposent des informations différentes ce faisant. Lisez les deux traces côte à côte et la différence cesse d'être cosmétique.

Ce que la preuve doit accomplir

Diffie-Hellman donne aux deux pairs une valeur partagée dont les moitiés publiques peuvent aussi être calculées par quiconque observe. À elle seule, elle ne prouve rien sur l'identité : un attaquant qui termine un échange de clés possède la même valeur partagée que votre passerelle. L'étape d'authentification existe pour lier cet échange à un secret que seuls les pairs prévus détiennent, ainsi qu'aux identités et paramètres convenus.

Ce lien est la raison pour laquelle le hachage couvre plus que la clé. S'il ne couvrait que le secret, un attaquant pourrait le rejouer dans un autre échange avec des identités ou des propositions différentes.

IKEv1 Main Mode : dériver SKEYID, puis le prouver

Main Mode se déroule en six messages. La première paire négocie l'association de sécurité, la deuxième échange les valeurs publiques Diffie-Hellman et les nonces, et la troisième transporte les identités plus les hachages d'authentification sous le chiffrement qui vient d'être établi. La RFC 2409 définit la construction : avec une authentification par clé pré-partagée, SKEYID est dérivé du secret et des deux nonces, et le matériel de clé ultérieur est dérivé de SKEYID, de la valeur partagée Diffie-Hellman, des cookies et des constantes.

Le hachage des messages cinq et six est calculé sur la valeur Diffie-Hellman, les deux cookies, la proposition et l'identité de l'expéditeur, avec SKEYID comme clé. Le destinataire le recalcule avec son propre secret configuré. Une divergence met fin à l'échange, et à aucun moment le secret lui-même n'est une charge utile.

Aggressive Mode comprime le même travail en trois messages, ce qui signifie que les identités et le hachage d'authentification circulent avant qu'un canal chiffré existe. C'est une exposition réelle pour un secret devinable, et cela reste distinct de la question de savoir si le secret a été transmis. IKEv1 est déprécié par la RFC 9395, donc une trace héritée est un exercice de diagnostic plutôt qu'une cible de déploiement.

IKEv2 : une dérivation différente et une charge AUTH différente

IKEv2 ne réutilise pas le calendrier de clés d'IKEv1. Les clés IKE initiales proviennent d'une graine construite à partir des nonces et de la valeur partagée Diffie-Hellman, et les associations de sécurité enfant en dérivent. La clé pré-partagée n'alimente pas du tout la graine.

L'authentification apparaît ensuite comme une charge AUTH. Pour l'authentification par clé partagée, la RFC 7296 spécifie une forme complétée du secret, produite en hachant le secret avec la chaîne fixe Key Pad for IKEv2, puis en hachant les données d'échange signées et l'identité avec cette clé complétée. Le vérificateur peut reconstruire la même valeur ; un observateur ne le peut pas, sans le secret.

Remarquez ce qui a changé. Dans IKEv1, le secret est intégré au calendrier de clés avant que le hachage d'authentification n'existe ; dans IKEv2, le calendrier de clés est indépendant du secret et la preuve est une charge distincte liée aux octets signés. Même garantie conceptuelle, machinerie différente, et c'est pourquoi les noms de paramètres et les captures ne se correspondent pas un à un.

Ce qu'un observateur apprend réellement

Les valeurs publiques Diffie-Hellman, les propositions, les nonces et les cookies sont visibles dans les deux versions. Les identités sont visibles en IKEv1 Aggressive Mode et protégées dans les autres cas. Le secret n'est jamais visible.

Cette dernière phrase a une limite qui mérite d'être énoncée. Un secret faible choisi par un humain peut être attaqué par devinement : l'attaquant calcule ce que serait la valeur d'authentification pour un secret candidat et compare. IKEv1 Aggressive Mode rend cela le moins coûteux parce que la preuve est en clair, et les normes mettent en garde en général contre les secrets à faible entropie. Ne jamais transmettre le secret n'est pas la même chose que rendre un mauvais secret sûr.

Que faire de cette comparaison

Utilisez un secret unique par paire de pairs, générez-le à partir d'une source aléatoire et faites-le tourner par le même chemin de provisionnement qui l'a distribué. Si le secret est stocké dans un modèle de configuration envoyé à chaque agence, une compromission à un endroit est une compromission partout.

Préférez l'authentification par certificat lorsque le coût opérationnel est acceptable, car elle élimine le problème du devinement du secret partagé et donne à chaque pair une identité distincte. Là où une clé pré-partagée demeure, gardez-la longue, limitez sa portée et traitez la version d'IKE comme une décision de sécurité plutôt que comme un détail d'interopérabilité.