Résumé

  • La RFC 2367 normalise un socket privilégié entre une application de gestion de clés et le Key Engine local. Une réponse PF_KEY témoigne de cette interface, pas d’un résultat de sécurité réparti entre deux machines.
  • SADB_GET, SADB_DUMP et les états LARVAL, MATURE, DYING, DEAD décrivent le cycle d’un enregistrement local. Ils ne prouvent ni l’autorité du pair, ni la politique applicable, ni l’usage par un paquet.
  • La preuve utile relie l’auteur privilégié, la transaction PF_KEY, la garde de la clé, la négociation distante, le SPD, le traitement AH/ESP, l’observation à distance et l’effet applicatif.

Le modèle conceptuel de 1998 répartit déjà les responsabilités. Le démon de gestion de clés parle au noyau par PF_KEY. Pour joindre l’entité distante, il utilise PF_INET ou PF_INET6. Le traitement IPsec dans le noyau consulte encore le Key Engine par une interface interne. Confondre ces trois chemins revient à faire témoigner une réponse locale sur une conversation réseau qu’elle n’a pas vue.

PF_KEY offre des opérations puissantes. SADB_ADD installe une association complète ; SADB_GETSPI puis SADB_UPDATE permettent de réserver l’identifiant avant de fournir tous les paramètres ; SADB_GET rend une copie locale. ACQUIRE, EXPIRE, DELETE et FLUSH expriment d’autres transitions. Cette richesse décrit une surface de contrôle, non une cérémonie end-to-end.

Le vocabulaire d’état s’arrête dans la base

LARVAL signifie qu’un SPI a été créé. MATURE signifie que l’entrée a été ajoutée ou mise à jour. DYING et DEAD suivent les échéances souple et dure. Aucun de ces mots n’indique que le pair a installé l’association inverse, que son identité a été authentifiée ou autorisée, ni qu’un paquet a sélectionné cette entrée.

Les champs restent aussi bornés. Le SPI sert à la recherche ; il n’est pas un justificatif d’identité. Le nom d’un algorithme indique une configuration ; il ne prouve ni la garde de la clé ni l’exécution. Une durée de vie compte localement. Une valeur nulle peut même indiquer l’absence d’authentification ou de chiffrement pour l’association. Lire honnêtement la structure vaut mieux que résumer sa présence par « tunnel sécurisé ».

Le DUMP paraît fournir la vue absolue : chaque association de la table locale, puis un message de fin. La RFC le réserve pourtant au débogage, le déconseille en exploitation et interdit d’en faire une dépendance normale. En outre, la livraison des messages PF_KEY n’est pas garantie ; la saturation des tampons du noyau ou du socket peut en faire perdre. Un inventaire vert peut donc être exact à un instant, incomplet dans son historique et déjà différent de l’autre extrémité.

L’autorité précède l’association

Seuls des processus fiables et privilégiés devaient ouvrir ce socket brut. L’interface manuelle donne une maîtrise étendue des associations du noyau. La section sécurité dit clairement qu’un système qui permet ces opérations à un utilisateur non privilégié ne peut pas fournir le service de sécurité correspondant.

L’audit commence donc par l’appelant : identité du processus, binaire, version de configuration, décision de l’opérateur et droits effectifs. Il faut ensuite suivre l’origine et la protection des clés sans les publier. Une réponse UPDATE diffusée ne contient justement pas la clé, car certains auditeurs peuvent observer l’état sans être autorisés à lire le secret. Témoignage d’état et garde cryptographique ne sont pas la même preuve.

L’autre moitié vit hors de PF_KEY

La RFC 4301 place la décision dans le SPD : BYPASS, DISCARD ou PROTECT. Une entrée SAD peut survivre à la règle SPD qui l’a créée ; une association manuelle peut n’avoir aucune règle correspondante. La présence de la SA ne démontre donc pas que le flux visé devait l’utiliser.

La RFC 7296 ajoute le dialogue IKEv2 : authentification des identités, autorisation dans le PAD, sélecteurs de trafic et Child SAs directionnelles. Des fenêtres temporelles peuvent laisser les pairs en désaccord sur leur état. Le noyau local ne peut pas reconstituer ces décisions distantes à partir du seul mot MATURE.

Enfin, la RFC 4303 applique ESP paquet par paquet. Les services dépendent des options de la SA et de la topologie ; la transformation sortante et la vérification entrante restent des événements exécutés. Après eux viennent encore le transfert, la réception distante, le transport et l’application.

Le dossier défendable associe donc neuf témoins : autorité de l’appelant, requête et réponse PF_KEY, génération SAD, génération SPD, provenance protégée de la clé, échange distant authentifié, sélection du paquet, résultat AH/ESP, puis réception et résultat applicatif. Un identifiant commun et des horodatages relient les événements ; une lacune demeure une lacune.

Sources