Résumé

  • RFC 5386 autorisait une association IPsec fondée sur une clé publique fournie par le pair, sans prétendre relier cette clé à une identité externe vérifiée.
  • La PAD devait d’abord rechercher les entrées non-BTNS. Un pair correspondant à l’une d’elles mais échouant à son authentification devait être rejeté; il ne pouvait pas tomber dans l’entrée BTNS générique.
  • L’entrée générique devait être logiquement la dernière, ses identités de Child SA ne pouvaient recouvrir celles des relations fortes et la SPD devait accepter explicitement BTNS avec BTNS_OK.

La première recherche attribuait la compétence

Une base de règles n’est pas seulement un inventaire. L’ordre indique quelle règle a le droit de juger un cas. Dans RFC 5386, la première recherche utilise l’identité déclarée par le pair et parcourt les entrées ordinaires de la Peer Authorization Database. Si une entrée connue correspond, elle fixe la méthode d’authentification et les identités de Child SA que cette relation peut porter.

Le résultat négatif n’a pas toujours le même sens. « Aucune entrée ne connaît cette identité » signifie qu’une politique anonyme peut éventuellement s’appliquer. « Une entrée connaît cette identité, mais la preuve exigée a échoué » signifie que la relation reconnue a refusé le pair. Confondre ces résultats donnerait à l’exception la capacité d’annuler la règle principale.

Le texte ferme donc la recherche. Les propositions provenant de pairs qui correspondent à une entrée non-BTNS mais ne s’authentifient pas correctement doivent être rejetées. La décision ne revient pas à l’entrée suivante. Le journal d’un tel rejet est une preuve positive du contrôle : il montre que la relation forte a conservé sa compétence.

Cette discipline reste utile au-delà d’IPsec. Chaque fois qu’un système combine des relations nommées et un accès générique, il doit décider si l’échec d’une preuve nommée est terminal. Sans cette décision explicite, l’ordre apparent des règles peut cacher un chemin de moindre confiance.

La seconde recherche changeait de type d’identité

Si aucune entrée ordinaire ne correspondait, l’implémentation pouvait transformer localement la vue du pair en identité PUBLICKEY. La valeur était la clé publique fournie dans le payload CERT; le nouveau type n’était pas envoyé sur le réseau. La PAD était alors recherchée une seconde fois parmi les entrées BTNS.

Le pair avait malgré tout produit une signature IKEv2 vérifiable avec la clé publique qu’il présentait. Cette preuve établissait la maîtrise de la clé privée pendant l’échange. Elle ne disait pas qui, dans le monde administratif, possédait cette clé. Aucun certificat de confiance, contrat de nommage ou registre externe ne reliait nécessairement le matériel cryptographique à une personne, une entreprise, un nom DNS ou une adresse.

RFC 5386 pouvait parler d’un pair « authentifié » parce que la signature était valide dans ce cadre restreint. Un système d’audit doit conserver le qualificatif. signature_valid et external_identity_bound sont deux champs différents. Le premier peut être vrai alors que le second reste inconnu.

RFC 7670 a ensuite généralisé le transport des clés publiques brutes dans IKEv2 au format SubjectPublicKeyInfo. Il rappelle qu’une procédure hors bande est nécessaire lorsqu’un déploiement veut être certain de l’authenticité de la clé. RFC 7619 a, de son côté, normalisé l’authentification NULL et ID_NULL. Ces textes ultérieurs ne prouvent aucun déploiement de BTNS; ils confirment la nécessité de nommer précisément ce qui a été authentifié.

La dernière entrée ne pouvait pas posséder les adresses des autres

Une admission anonyme n’était que la première moitié de la politique. Un pair IKE négocie aussi les sélecteurs de trafic d’une Child SA. S’il pouvait demander l’adresse ou le réseau réservé à un partenaire authentifié, il obtiendrait indirectement l’autorité que la première recherche lui avait refusée.

RFC 5386 exige donc que les contraintes d’identités de la règle BTNS générique ne recouvrent aucune autre entrée de la PAD. Le document décrit une vérification supplémentaire lors de la négociation des Child SAs. Le système reconsulte la PAD afin de s’assurer que les sélecteurs revendiqués par le pair anonyme n’entrent pas dans le territoire d’une relation connue.

Dans l’exemple de la passerelle, un pair inconnu peut établir une SA pour le service ouvert prévu. Un attaquant qui revendique l’adresse d’un hôte connu rencontre l’une de deux barrières : soit sa revendication tombe sous la règle connue et son authentification échoue, soit la règle BTNS l’admet comme clé anonyme mais la vérification des sélecteurs lui refuse l’adresse réservée.

Ce double contrôle distingue admission du pair et délégation de trafic. L’acceptation de la clé ne crée pas un droit sur tous les paquets que le pair souhaiterait représenter.

BTNS_OK localisait le risque

La Security Policy Database reçoit un drapeau supplémentaire. Le trafic d’un pair BTNS ne peut correspondre qu’à une entrée dont BTNS_OK est actif. L’existence du mode dans le logiciel ne l’active donc pas pour l’ensemble de la machine.

Cette restriction est un choix de gouvernance. Un opérateur peut accepter l’absence d’identité réseau pour un service public précis tout en exigeant une authentification classique pour l’administration, le stockage ou un réseau partenaire. Le drapeau appartient à la règle de trafic, pas à une réputation générale du pair.

Une interface qui affiche seulement « tunnel IPsec établi » masque cette allocation. Il faut voir l’entrée PAD, le mode de preuve, l’entrée SPD, le drapeau et les sélecteurs. Sinon, un tunnel techniquement correct peut sembler autorisé pour une surface que la politique n’avait jamais ouverte.

RFC 7619 reprend plus tard ce principe pour l’authentification NULL : seules les règles SPD explicitement prévues peuvent accepter un pair non authentifié, et l’option faible ne devrait pas remplacer une authentification possible pour les mêmes sélecteurs.

La continuité n’était pas un nom

RFC 5387 qualifie la garantie faible de BTNS de « continuité d’association ». Pendant la vie d’une SA, les protections IPsec peuvent garantir intégrité, anti-rejeu et confidentialité contre certaines attaques. Si la création initiale n’a pas été détournée, les paquets restent liés au même pair non authentifié.

La limite temporelle est essentielle. La continuité ne traverse pas automatiquement deux SAs et ne devient pas l’identité d’un propriétaire. Un attaquant actif peut intercepter l’établissement initial. Une nouvelle SA créée lors d’un rekey peut également être détournée si rien ne la lie à la précédente.

Le connection latching associe un flux de couche supérieure à une succession de SAs. Le channel binding relie ensuite l’authentification de la couche supérieure aux propriétés de ce canal. Dans Channel-Bound BTNS, cette combinaison peut détecter un intermédiaire qui a concaténé deux SAs.

Mais la détection arrive plus tard. L’échange IKE non authentifié peut réussir et consommer des ressources avant que l’authentification applicative échoue. RFC 5387 avertit qu’un mécanisme supérieur révélant un mot de passe ou un dérivé attaquable ne doit pas être exposé dans cette séquence. « Détectable ensuite » n’est pas équivalent à « impossible avant ».

BTNS n’était ni le clair ni un passe-droit

RFC 5386 ne définit pas un mode qui retombe en IP non protégé lorsque le pair ne supporte pas IKEv2. Il ne spécifie pas non plus entièrement le leap of faith ou le latching. Son objet est plus étroit : établir des SAs IPsec sans identité réseau vérifiée, dans des politiques qui l’acceptent explicitement.

RFC 5387 formule la règle d’emploi : BTNS doit remplacer l’absence de sécurité, pas une sécurité plus forte. La formule « better than nothing » désigne ainsi une borne inférieure. Elle n’autorise pas une suite d’essais où l’on descend progressivement de certificat en clé inconnue puis en clair jusqu’à obtenir une connexion.

Les protections obtenues restent réelles. ESP peut préserver la confidentialité et l’intégrité. Une SA peut repousser certaines injections hors chemin. Pourtant, le nom du pair demeure non prouvé et l’accès anonyme augmente l’exposition aux ressources et aux attaques par déni de service. Le registre doit porter simultanément les deux vérités.

Limite de preuve

Les sources décrivent les règles des RFC, leur historique et leurs menaces déclarées. Elles ne démontrent pas qu’un produit actuel implémente BTNS, qu’un réseau l’a déployé ou qu’une attaque précise s’est produite. L’ancien contexte de clé RSA brute de RFC 4306 a évolué; RFC 7296 l’a retiré et RFC 7670 a réintroduit une forme générique. Toute affirmation opérationnelle exige donc des preuves de version, de configuration et d’exécution.

La grille de Lu Heng aide à garder chaque couche à sa place : identité déclarée, signature, décision PAD, autorisation des sélecteurs, décision SPD, SA installée, paquet protégé, principal applicatif et résultat métier. Le danger ne vient pas de l’existence d’une voie faible clairement nommée. Il vient de la capacité de cette voie à absorber silencieusement l’échec d’une voie forte.