Résumé

  • Dans la RFC 1446, une partie SNMPv2 pouvait remplacer son propre secret avant de fabriquer la réponse, laquelle employait alors une clé encore inconnue de la base du gestionnaire.
  • L’absence de réponse ne disait pas si la requête avait été perdue ou si seule la réponse avait disparu après une modification réussie ; le secret privé ne pouvait pas être relu.
  • Une valeur publique reconnaissable servait de témoin, tandis que le gestionnaire devait conserver les deux secrets possibles, y compris après un redémarrage.

Une écriture locale avant la preuve distante

La RFC 1446 organisait le changement d’un secret existant en plusieurs actes. La station responsable créait la nouvelle valeur, envoyait une setRequest protégée, puis attendait la réponse avant de mettre à jour sa base locale. Le destinataire, lui, traitait la requête avant de répondre.

Cette chronologie devenait délicate quand la partie changeait son propre secret. L’agent enregistrait la nouvelle valeur, puis construisait sa réponse avec elle. Au même instant, le gestionnaire possédait encore l’ancienne comme référence. Une réponse correcte pouvait donc échouer à son contrôle d’authenticité.

La commande envoyée, sa livraison, l’écriture locale, la réponse produite et la réponse acceptée n’étaient pas un seul événement. La sécurité du message ne supprimait pas la distance entre les deux bases.

Le silence ne choisissait pas entre deux états

Sans réponse, deux histoires restaient possibles. La requête n’avait jamais atteint l’agent : rien n’avait changé. Ou bien l’agent l’avait exécutée et seule la réponse s’était perdue : les deux extrémités ne partageaient plus le même secret.

La seconde histoire pouvait rendre une simple répétition trompeuse. Une nouvelle requête signée avec l’ancienne clé échouerait parce que la première avait réussi. L’échec suivant ne prouverait ni une attaque, ni une panne, ni même l’échec initial.

La valeur privée était illisible par SNMP. Cette opacité protégeait le secret, mais empêchait de résoudre le doute par une lecture directe. Le registre RFC classe aujourd’hui le texte comme historique : MD5 et DES appartiennent à ce contexte de 1993, pas à une recommandation actuelle. L’incertitude de transaction, elle, vient de l’ordre des opérations.

Un témoin public pour un état privé

Le texte recommandait d’écrire en même temps une valeur publique nouvelle et reconnaissable. partyAuthPublic accompagnait le changement du secret d’authentification ; partyPrivPublic pouvait jouer le même rôle pour la confidentialité. Après une réponse absente, le gestionnaire relisait ce marqueur.

La Party MIB séparait explicitement champs privés, champs publics, horloge et durée de validité. Le marqueur n’était pas une copie affaiblie de la clé. Il attestait qu’une transaction identifiable avait atteint l’état distant sans dévoiler le secret.

Cette preuve restait bornée. Une valeur publique conforme indiquait que la modification avait probablement été appliquée selon le modèle. Elle ne prouvait ni la mise à jour de la base du gestionnaire, ni la conservation après panne, ni le succès d’une requête ultérieure, ni un effet réseau.

Deux clés devaient survivre à la panne

Pendant l’intervalle incertain, la station devait garder l’ancienne et la nouvelle valeur. La RFC précisait que l’attente pouvait se prolonger à cause d’une défaillance du réseau et traverser un redémarrage. Le contrôleur devait donc persister une bifurcation, non seulement son état préféré.

La récupération étendait cette exigence. Identité de partie, horloge d’authentification et secrets privés devaient disposer de représentations non volatiles et incorruptibles. L’horloge devait progresser sans retour en arrière malgré la coupure. Sinon, un message authentique pouvait tomber hors de la fenêtre admise ou la relation pouvait nécessiter une resynchronisation par la station responsable.

Relancer un processus ne rétablissait donc pas automatiquement le contrôle. Il fallait recoller identité, temps, ancien secret, nouveau secret et état du témoin.

L’authentification ne créait pas l’ordre

Le protocole de digest associait intégrité et origine selon un secret partagé. L’horloge et la durée de vie limitaient les retards et relectures excessifs. Mais la RFC disait aussi que ces mécanismes n’empêchaient ni suppression ni perte. L’absence d’une réponse authentifiée ne concluait pas à une panne ; même une notification d’échec pouvait disparaître sous l’effet d’un décalage d’horloge ou d’un désaccord de clé.

SNMP n’imposait pas d’ordre général aux messages de mutation. La station devait attendre l’accusé positif ou l’expiration avant d’envoyer la mutation suivante. Le snmpSetSerialNo de la MIB SNMPv2 apportait un mécanisme distinct d’ordonnancement, non une preuve de persistance ou de résultat.

Le modèle administratif ajoutait parties, contextes et politiques d’accès. Une signature correcte pouvait corroborer l’origine et l’intégrité ; elle ne remplaçait pas l’autorisation sur chaque objet ni l’observation de l’effet demandé.

Le marqueur a survécu au modèle des parties

Le modèle de 1993 n’est pas devenu la forme définitive. La RFC 1910 expérimenta un cadre fondé sur l’utilisateur, l’identité d’agent, le compteur de démarrages, le temps et la politique d’accès. La RFC 2574, puis la RFC 3414, installèrent l’USM de SNMPv3.

Pourtant, le témoin resta. KeyChange modifiait une clé illisible par fonction à sens unique, un verrou protégeait la concurrence et usmUserPublic recevait une valeur aléatoire. Sans réponse, la lecture de cette valeur distinguait encore la requête perdue de la réponse perdue.

La filiation ne réhabilite pas les algorithmes anciens. Elle montre qu’une rotation distante est un problème de cohérence distribuée : le secret peut être sûr et l’état partagé, incertain.

Sources