Résumé

  • RFC 5387 admet des authentifications unidirectionnelles ou réparties entre plusieurs couches, mais la liaison au canal doit être échangée et vérifiée par les deux extrémités.
  • Sans cette réciprocité, un intermédiaire peut assembler deux associations IPsec parfaitement valides. Le chiffrement de chaque tronçon reste réel ; l’identité du canal de bout en bout, elle, est fausse.

L’asymétrie utile

Un serveur public prouve souvent qui il est sans exiger la même preuve de chaque visiteur. À l’inverse, un système interne peut authentifier fortement l’utilisateur alors que l’infrastructure réseau identifie surtout le service. Dans un stockage distant, l’identité applicative et l’identité comprise par IKE ne coïncident pas nécessairement.

RFC 5387 ne traite pas cette asymétrie comme une anomalie. Son inventaire distingue les modes symétriques et asymétriques de Better-Than-Nothing Security. Il décrit même un cas où l’authentification du client intervient dans la couche supérieure et celle du serveur dans IKE. Les deux directions peuvent alors contribuer à une authentification mutuelle sans vivre dans la même couche.

La décision d’authentifier dans un seul sens relève de la politique du service. La preuve que les deux parties utilisent le même canal relève d’une autre question. Pour empêcher l’homme du milieu, RFC 5387 exige que la liaison au canal soit appliquée aux deux extrémités. Chacune doit recevoir et vérifier une valeur qui décrit le même fait cryptographique inférieur.

Cette séparation est une règle de gouvernance. L’autorité peut être distribuée de manière asymétrique ; la cohérence d’un fait partagé ne peut pas être décrétée par un seul témoin.

Deux cadenas ne font pas un seul corridor

Le scénario dangereux ne demande pas de casser IPsec. Un mandataire placé sur le chemin établit une première association de sécurité avec le client, puis une seconde avec le serveur. Les deux associations peuvent offrir confidentialité, intégrité et protection contre le rejeu. Le mandataire reçoit néanmoins le contenu entre elles et relaie l’échange de la couche supérieure.

Chaque équipe peut donc produire un journal exact : « notre SA était valide ». Le désaccord porte sur la conclusion ajoutée ensuite : « nous avions un canal direct avec l’autre application ». Les extrémités d’une SA réseau ne sont pas automatiquement les extrémités de la session applicative.

La liaison au canal transforme cette conclusion en test. Les informations issues de la création de la paire de SA, suffisamment précises pour distinguer cette instance, sont incorporées dans l’authentification supérieure. Si un relais a construit deux canaux, les observations ne coïncident pas et l’authentification liée doit échouer.

Dire « IPsec actif » ne constitue donc pas un reçu. Le nom de la technologie décrit une capacité. Le reçu doit désigner l’instance, les extrémités, le résultat de vérification des deux côtés et le comportement adopté en cas de divergence.

Le verrou de connexion protège une invariance

RFC 5387 définit le canal IPsec par un flux pour lequel l’identité du pair et la qualité de protection restent constantes. Le verrouillage de connexion associe ces propriétés à la session supérieure. Il ne s’agit pas de conserver aveuglément une SA ; il s’agit de conserver les propriétés qui rendaient le canal acceptable.

RFC 5660 a ensuite précisé ce mécanisme. Le verrou surveille les modifications des bases de politiques et d’associations. Il retient notamment le type de protection, le mode transport ou tunnel, la qualité cryptographique, l’identité locale et celle du pair. Si ces éléments deviennent incompatibles avec la promesse initiale, l’application doit être avertie avant que le flux continue silencieusement.

Une renégociation de clés peut remplacer la SA sans interrompre le canal, mais elle ne reçoit pas automatiquement l’autorité de l’ancienne. La transition doit démontrer que les propriétés verrouillées sont préservées. Sinon, le canal est rompu, même si le nouvel échange cryptographique a réussi.

On retrouve la même exigence dans un transfert opérationnel. Un nouveau certificat, un nouvel agent ou un nouveau prestataire peut reprendre une fonction. Il doit recevoir un mandat et une preuve de continuité portant sur l’objet exact, pas seulement un nom de rôle identique.

Détecter plus tard n’efface pas l’intervalle

Avec une authentification IKE complète, un intermédiaire devrait échouer pendant la création de l’association réseau. Avec CBB, l’IKE non authentifié peut réussir. Les associations existent avant que l’authentification supérieure, liée au canal, révèle le mandataire.

Cette détection tardive est utile, mais elle a un coût. Des ressources ont été allouées. Des messages d’authentification ont circulé. Si le protocole supérieur révèle un mot de passe ou une matière dérivée exploitable hors ligne, constater ensuite l’échec ne répare pas l’exposition.

Un test d’acceptation doit donc répondre à deux questions. La divergence de liaison a-t-elle interrompu la session ? Qu’est-ce qui a été transmis, calculé ou autorisé avant cette interruption ? Les limites de ressources avant authentification, la nature des preuves échangées et le moment d’élévation des privilèges font partie du contrôle.

Un tableau de bord unique « sécurisé » masque cette chronologie. Il faut distinguer association réseau établie, liaison vérifiée et principal applicatif autorisé.

Une épreuve qui ne triche pas

Le laboratoire doit contenir trois machines : client, serveur et relais contrôlé. On commence par une connexion directe. Les deux extrémités enregistrent la valeur de liaison, les propriétés verrouillées et le résultat de l’authentification. Elles doivent prouver qu’elles observent le même canal.

On introduit ensuite le relais, qui établit deux associations fortes et transmet l’échange supérieur sans le modifier. Les algorithmes restent bons ; les paquets ne sont pas corrompus. La liaison doit néanmoins échouer parce que les deux applications ne voient pas la même paire de SA.

Le scénario est répété avec authentification du serveur seulement, du client seulement, des deux, puis avec les directions réparties entre IKE et l’application. La politique d’identité change. La vérification bilatérale du canal, non.

Enfin, on renouvelle les clés pendant un flux long. Une transition qui conserve le pair et la qualité doit pouvoir être prouvée. Une transition qui change l’une de ces propriétés doit casser le verrou avant l’acceptation de nouvelles données. Les journaux doivent montrer quelle extrémité a détecté l’écart, combien de données ont précédé l’échec et quelle erreur a été rendue à l’application.

Un reçu de composition

La leçon de RFC 5387 n’est pas que les contrôles locaux sont inutiles. Elle est qu’ils ne possèdent pas la conclusion globale. Deux signatures peuvent viser deux contenus. Deux registres peuvent employer le même nom pour deux objets. Deux connexions chiffrées peuvent aboutir à un intermédiaire.

Le point de jonction a besoin de son propre reçu : identifiant exact du canal inférieur, session supérieure, extrémités, direction des authentifications, décision aux deux bouts, propriétés verrouillées et historique des transitions. L’absence ou la divergence d’une valeur doit fermer le chemin.

Cette discipline rejoint la distinction entre le teneur de registre et l’autorité. Celui qui maintient un état local utile ne peut pas transformer cet état en vérité de bout en bout. La vérité commune appartient aux principaux reliés par une preuve vérifiable, non à l’intermédiaire qui possède le plus beau cadenas.

Sources