Comment l’authentification hybride IKEv1 se transpose dans l’authentification utilisateur IKEv2

Tout profil VPN hérité qui demande un certificat de serveur puis un nom d’utilisateur porte deux événements d’authentification dans un seul échange, et cette forme survit au protocole qui l’a introduite. Le mode hybride IKEv1 a été conçu exactement pour cela : la passerelle se prouve avec une clé publique tandis que l’utilisateur se prouve plus tard via XAuth. IKEv2 exprime la même idée en deux temps avec une mécanique différente, et c’est dans ces différences que les migrations échouent. Aucun numéro de version ne convertit l’un en l’autre, et recopier les anciens noms d’options dans un nouveau profil donne un client qui négocie puis n’authentifie rien.

Ce que faisait le mode hybride dans IKEv1

Dans un profil hybride, le répondeur signe l’échange de la phase un avec son certificat tandis que l’initiateur n’en présente aucun, volontairement. La preuve d’identité est donc asymétrique, et c’est ce qui a permis à une passerelle de garder son PKI existant pendant que les utilisateurs gardaient leurs mots de passe d’annuaire. Une fois la phase un terminée, XAuth s’exécute comme une requête et une réponse qui transportent les attributs de nom d’utilisateur et de mot de passe dans le canal ISAKMP désormais chiffré.

Notez où se situe la confiance. Le certificat répond à quelle passerelle le client s’est adressé ; XAuth répond à quel utilisateur veut accéder. Ni l’un ni l’autre ne remplace l’autre, et un client configuré pour accepter n’importe quel certificat de serveur a discrètement écarté la première réponse. L’étiquette hybride sert aussi au mode agressif à clé pré-partagée plus XAuth, un agencement différent pour une expérience utilisateur identique, alors lisez le profil plutôt que le nom. Les deux variantes viennent de brouillons jamais devenus des normes, ce qui explique que deux éditeurs puissent implémenter le mode hybride sans interopérer avec aucun.

Comment IKEv2 arrive aux deux mêmes preuves

IKEv2 répartit le travail entre IKE_SA_INIT et IKE_AUTH. Le premier échange négocie propositions et clés sans aucune identité ; le second transporte IDi, IDr et les charges AUTH. Sous EAP, la première charge AUTH de l’initiateur part vide, le répondeur s’authentifie d’abord avec son certificat et sa signature, puis la conversation EAP se déroule dans les messages IKE_AUTH.

Le mécanisme qui rend cela sûr, c’est le matériel de clés. Une méthode EAP réussie exporte une clé de session, et la charge AUTH finale de l’initiateur est calculée à partir d’elle, si bien que la preuve de l’utilisateur et les clés du tunnel sont liées. XAuth n’a pas d’équivalent : ses attributs arrivent après la phase un et n’apportent rien aux clés. C’est précisément ce manque que le cadre IKEv2 a été conçu pour combler, et c’est pourquoi une connexion IKEv2 qui fonctionne valide le certificat du serveur avant de demander quoi que ce soit.

Cet ordre est aussi un bon diagnostic. Quand un client se plaint des identifiants avant de vous avoir montré un certificat, il ne fait pas du tout un échange EAP IKEv2.

Gardez trois identités distinctes

Une migration tourne mal quand trois identités s’effondrent dans un seul champ. Il y a l’identité de passerelle que le client valide, généralement un nom DNS dans le sujet ou le SAN du certificat. Il y a l’identité utilisateur présentée dans EAP, qui peut être un identifiant de domaine, une adresse ou une chaîne d’identité EAP explicite. Et il y a la source d’autorisation qui associe cet utilisateur à des réseaux et des routes.

La syntaxe swanctl de strongSwan rend la séparation visible : la connexion fixe remote { auth = pubkey } pour la passerelle et local { auth = eap-mschapv2 } pour l’utilisateur, l’identité EAP étant transportée à part.

Quand l’identité utilisateur du nouveau profil diffère des anciens attributs XAuth, par exemple un UPN au lieu d’un nom court, le serveur d’authentification voit un utilisateur inconnu et la panne ressemble à un mauvais mot de passe. Vérifiez la chaîne d’identité avant de vérifier l’identifiant.

Mappez les options, puis attendez-vous aux pièges

La correspondance est courte et chaque ligne a un piège qui n’apparaît qu’au moment de l’authentification.

Aucune de ces lignes n’est un simple renommage. La charge de configuration livre adresses et résolveurs via une liste d’attributs typés, alors que l’espace d’attributs de XAuth était sa propre invention ; les traiter comme interchangeables, c’est ainsi qu’un profil finit par demander un réglage que la passerelle n’enverra jamais.

Les sélecteurs de trafic méritent leur propre avertissement. IKEv1 exprimait le trafic intéressant par des identifiants de proxy liés à un échange en mode rapide, tandis qu’IKEv2 négocie les sélecteurs pendant IKE_AUTH et le répondeur peut les restreindre. Un désaccord produit une IKE SA établie sans SA enfant, que certains clients affichent volontiers comme connectée.

Traitez l’ancienne connexion comme une frontière

La RFC 9395 déprécie IKEv1, donc une connexion hybride héritée est une frontière de compatibilité avec une date, pas une fondation. Faites tourner les deux profils côte à côte pendant le changement, car le test qui compte n’est pas de savoir si le nouveau profil monte, mais si le même utilisateur sur le même appareil atteint les mêmes ressources.

Gardez la validation des certificats stricte de bout en bout. Dès que le client cesse de présenter son propre certificat, la tentation est de relâcher le contrôle du serveur jusqu’à ce que la poignée de main aboutisse, et cela échange la seule preuve restante contre une icône verte.

Notez quatre choses avant de retirer l’ancien profil : la méthode EAP, la chaîne d’identité, la source d’autorisation et la date de fin du support.